HoneyCoin × PesaLink
This document is confidential.
Enter the access PIN to continue.
×
Confidential Joint Venture Partnership · 20 Apr 2026
Customer Journey Architecture

Building the stablecoin layer
for Kenyan Banking.

How PesaLink can serve as the orchestration layer between banks, stablecoin issuers, and remittance operators — without building a new clearing system or disintermediating its own members.

Prepared for PesaLink Commercial & Product
Prepared by HoneyCoin
Workshop reference 15 Apr 2026, Nairobi
Status Pre-LOI, for review
Context

What we agreed to map.

Following our workshop, the next artifact owed to the PesaLink team is a set of customer journey diagrams that show how end users, banks, remittance operators, and stablecoin issuers would interact with the proposed infrastructure — without abstracting away the mechanics that matter for compliance, risk, and operations.

We have framed three journeys. Together they cover the bulk of the economic activity that the new rail is expected to carry in year one: inter-bank settlement, remittance inflow into domestic termination, and the custody relationship between banks and licensed stablecoin issuers (including KESC, the local KES-denominated stablecoin).

Each journey is presented as a sequence of actor interactions with the blockchain shown as a settlement surface and PesaLink as the orchestration layer. The existing CAPS / KEPPS rails remain in place and are unaffected — the stablecoin network runs in parallel.

01

Inter-Bank Transfers on the Stablecoin Network

Three sub-scenarios sit inside this flow, in order of complexity: treasury moves between bank master wallets, customer-to-customer transfers across banks, and external blockchain wallets sending inbound to a bank-issued customer wallet. CBK observability is continuous across all three via the analytics dashboard.

The scenario most worth pressure-testing first with stakeholders is 1B (customer-to-customer), since it is the one that touches the existing 999,999 KES transaction limit and the real-time webhook contract between banks.

Flow 1 — Inter-Bank Transfers on the Stablecoin Network Three sub-scenarios: bank treasury moves, customer-to-customer transfers, and external blockchain inbound. PesaLink acts as the orchestration layer. Value moves on-chain. CBK has observer visibility via analytics. On-chain value movement (stablecoin) Orchestration / authentication message User-initiated API call Observability / reporting Bank (Master + Customer wallets) PesaLink orchestration Blockchain network Customer CBK analytics (observer) External blockchain wallet 1A · Bank-to-Bank Master Wallet Transfer Treasury / liquidity move between bank master wallets. No customer involvement. Bank A Master Wallet (Treasury) PesaLink Orchestration Layer Blockchain Network USDC / KESC / USDT Bank B Master Wallet (Treasury) 1 Bank A submits signed transfer intent (amount, token, destination bank ID, reference) 2 Authenticate, check AML rules, route to Bank B's master Validates signature, limits, sanctions, whitelist 3 Trigger on-chain transfer (gasless, relayer pays) 4 Stablecoin burns/debits from Bank A master → credits Bank B master 5 Tx hash confirmed → PesaLink emits receipt webhook to both banks CBK analytics dashboard receives event: balances, counterparties, amount, tx hash (near real-time) 1B · Customer-to-Customer Transfer Across Banks End-user at Bank A sends stablecoins to a customer wallet at Bank B. Sender Bank A customer Bank A Customer wallet (debit) PesaLink Orchestration Blockchain USDC / KESC Bank B Customer wallet (credit) Receiver Bank B customer 1 Initiates "Send KESC" in Bank A app specifies recipient wallet ID at Bank B + amount 2 Bank A signs & submits intent Customer wallet is source; debits checked locally 3 Validate: recipient exists, limits, AML, tier ≤ 999,999 KES per tx unless tiered exemption 4 On-chain transfer: Bank A customer wallet → Bank B customer wallet Gasless (relayer pays gas), non-custodial (Bank holds keys) 5 Notify Bank A (debit receipt) Notify Bank B (credit receipt) 6 Debit confirmation 6 Credit notification CBK dashboard records: sending wallet, receiving wallet, amount, token, tx hash, timestamp. All sub-second. 1C · External Blockchain Wallet → Bank Customer Wallet Optional: customer receives from any supported external wallet (exchange, self-custody, etc.). External Wallet Binance, MetaMask, etc. Blockchain Network Listener / indexer PesaLink Screening + routing Bank Customer wallet Customer Recipient 1 External wallet broadcasts on-chain transfer destination = bank's registered customer wallet address 2 Indexer event: incoming tx to registered bank wallet 3 Source screening (Chainalysis / TRM) Risk score, sanctions, mixer/darknet exposure check 4 Forward event + risk profile to Bank Bank decides: auto-credit, hold for review, or reject 5 Customer sees credit CBK dashboard flags external inbounds separately with source risk score for supervisory review. HoneyCoin × PesaLink · Inter-Bank Transfer Journeys · Joint Venture Partnership Confidential · Joint Venture Partnership
What's new
Actual value moves on-chain instead of being cleared later through CAPS. Suspense accounts are not required for stablecoin settlement, though they remain for traditional rails.
Bank experience
Banks submit signed transfer intents through PesaLink as they do today. No direct blockchain interaction required. Keys live in secure enclaves, gas is paid by the relayer.
Supervisory posture
CBK sees every transaction near real-time — sending wallet, receiving wallet, amount, token, tx hash, and timestamp — via the PesaLink analytics dashboard.
02

Remittance Inflow into Domestic Termination

Roughly 60% of the remittance operators connected to PesaLink today are already using stablecoins on the originating side and then converting at the border. This journey shows the model where they bypass correspondent banking entirely — funding a domestic float position at a Kenyan bank directly in stablecoins, then drawing on it for last-mile payouts over M-Pesa, or PesaLink directly.

Choice Bank has indicated this is the wedge they want to lead with. The commercial attraction is clear: no SWIFT delay, no correspondent credit risk, and 24/7 funding — all while the payout leg continues to use existing rails.

Flow 2 — Remittance Inflow into Domestic Termination Remittance operator funds a domestic float position at a Kenyan bank using stablecoins, then draws on it for last-mile payouts. Replaces SWIFT + correspondent banking (2–5 days) with instant funding. Eliminates bank credit risk on inbound float. On-chain stablecoin movement Orchestration message API call Domestic fiat payout rail (M-Pesa / KEPPS / pay-in) Remittance operator (e.g., WorldRemit, Lemfi, Thunes) Bank (Master + per-operator sub-wallet) PesaLink Blockchain M-Pesa / Domestic payout rails End beneficiary (Kenyan recipient) Phase 1 · Funding the Domestic Float Position Remittance operator pre-funds bank with stablecoins. Bank creates a sub-ledger wallet in their name. Remittance Operator Treasury wallet Blockchain Network USDC / USDT PesaLink Orchestration + Screening Bank · Master Wallet Holds total stablecoin balance Bank · Operator Sub-Wallet Debit position allocated to operator 1 Broadcast stablecoin transfer destination = Bank's master wallet address · memo = operator ID 2 Event: inbound to registered bank wallet 3 Screen source, match to licensed operator Chainalysis / TRM score + whitelist check + operator KYB verified 4 Notify Bank + allocation instruction 5 Credit operator's sub-wallet Ledger allocation within master; no second on-chain move needed 6 Bank → Operator: "Float position funded. Balance: $X. Ready for payouts." Why this is better than today's correspondent banking model · Instant funding (minutes vs 2–5 days via SWIFT) · No credit risk on inbound nostro balances · 24/7 availability, including weekends · Operator's liquidity is not trapped in correspondent float · Bank earns clearing fees without taking bridge-financing risk Phase 2 · Last-Mile Payout to Kenyan Beneficiary Operator draws on funded sub-wallet. Bank executes payout over existing domestic rails. Remittance Op API client PesaLink Orchestration Operator Sub-Wallet Debit position Bank Operations Stablecoin → KES Payout Rail M-Pesa / KEPPS / Bank Beneficiary Kenyan recipient 1 POST /payouts beneficiary, amount KES, rail 2 Check sub-wallet balance, limits, KYC 3 Instruct debit 4 Draw from sub-wallet into bank ops Bank converts to KES (internal treasury / redeem from issuer) 5 Push KES via selected rail 6 Credit beneficiary M-Pesa wallet / bank account / pay-in point 7 Payout rail → PesaLink: delivery confirmation 8 Webhook: SUCCESS payout_id, rail_ref, balance End-user impact Today: 3-hop remittance with currency conversions at each step (operator → correspondent → Kenyan bank → beneficiary). With stablecoins: single settlement + local payout. Cost per $100 drops from ~$6–8 to ~$1–2. HoneyCoin × PesaLink · Remittance Inflow Journey · Joint Venture Partnership Confidential · Joint Venture Partnership
Operator experience
Funding cycle collapses from 2–5 days via SWIFT to minutes. Liquidity is no longer trapped in correspondent nostro balances. 24/7, including weekends and holidays.
Bank economics
Bank earns custody plus FX conversion fees without taking bridge-financing risk. Stablecoin inflow is settled on-chain before any KES is released to beneficiaries.
End-user impact
Cost per $100 sent drops from roughly $6–$8 today to $1–$2 by removing the three-hop currency conversion chain.
03

Bank as Custodian for a Licensed Stablecoin Issuer

The upcoming VASP regime establishes a stablecoin issuer category with a 500M KES minimum capital requirement. Issuers will need banks to hold their fiat reserves on a segregated, ring-fenced basis. This journey describes how that relationship works operationally — mint, burn, proof-of-reserves — and how a single bank can custody for multiple competing issuers at once.

We flag KESC (a KES-denominated stablecoin) specifically because it is the instrument most relevant to PesaLink's members: settlement stays in local currency, there is no FX exposure, and CBK monetary visibility is preserved.

Flow 3 — Bank as Custodian for a Licensed Stablecoin Issuer Mint, burn, and ecosystem interactions — with focus on KESC (KES-denominated stablecoin). Bank holds segregated fiat reserves 1:1 against tokens in circulation. Proof-of-reserves visible to CBK and public attestations. Mint / token issuance (on-chain) Burn / redemption (on-chain) Fiat movement (KES bank rails) Instruction / orchestration CBK oversight / proof-of-reserves Licensed stablecoin issuer Bank (custodian) Blockchain smart contract PesaLink CBK Token holder (bank, operator, customer) Phase A · Mint — Issuer creates new stablecoin supply Issuer deposits fiat with bank → bank confirms receipt → issuer mints equivalent tokens on-chain. KESC Issuer Licensed VASP (500M KES capital) Bank · Reserve Account Segregated, ring-fenced Bank · Attestor Signs reserve proofs PesaLink Mint orchestrator KESC Smart Contract mint() — gated by issuer key CBK Supervisor 1 Wire 100M KES (fiat) to segregated reserve account 2 Funds cleared 3 Sign reserve attestation "+100M KES held, ring-fenced, pledged" 4 Signed attestation Oversight copy 5 Mint permitted 6 Issuer calls mint(100,000,000 KESC) — attestation hash attached 7 100M KESC minted to issuer's treasury wallet → ready for distribution to banks / users Reserve integrity controls · Reserve account is legally segregated and cannot be used for bank's own balance sheet · On-chain supply is publicly verifiable · Bank publishes signed daily proof-of-reserves (Merkle root on-chain) · CBK has continuous read-access via PesaLink dashboard Phase B · Burn / Redemption — Token holder exits to fiat Holder returns tokens to issuer → tokens burned on-chain → bank releases equivalent KES. Token Holder Bank / operator / customer KESC Smart Contract burn() KESC Issuer Redemption desk PesaLink Orchestrator Bank · Reserve Account Releases KES on instruction CBK Observer 1 Request: redeem X KESC → X KES, specify bank account 2 Transfer tokens → burn address (or issuer calls burn() on holder-approved tokens) 3 Burn event observed 4 Redemption instruction 5 Release X KES 6 Wire KES to holder's bank account (RTGS / PesaLink fiat rail / internal transfer) 7 Dashboard: supply ↓, reserves ↓ (1:1 maintained) The burn–reserve release loop is atomic from a supervisory view: total on-chain supply always matches total fiat in reserve accounts. Any drift is immediately visible to CBK. Part C · Multi-Issuer Ecosystem — How the Bank Sits Among Issuers A bank can custody for multiple issuers. Each issuer operates independently; PesaLink is neutral. Bank (Custodian) Holds segregated reserve accounts, one per issuer. Signs attestations. Revenue: custody fees + float on reserves + treasury services KESC Issuer (KES-pegged) Backed 1:1 by KES held at Bank Primary use: domestic settlement, inter-bank clearing, wallet balances USDC / USDT Issuer Offshore issuer; Bank holds tokens but not fiat reserves (custody-only relationship) Alt. KES Stablecoin Competing issuer — same custodian pattern, separate reserve account PesaLink Neutral orchestrator across all issuers. Does not favor or pick winners. Clears transactions. Retail customers Hold KESC in bank-issued wallets; pay / receive locally. Remittance operators Use USDC/USDT for inbound, convert to KESC or cash-out. Corporates (Bidco, Unilever, etc.) Treasury rails, supplier payments, cross-border FX. Other banks Accept KESC via PesaLink for inter-bank settlement. KESC — why a local KES stablecoin matters · Eliminates FX risk for domestic users · Settlement in local currency = no IFRS re-translation for banks · CBK monetary visibility preserved (supply + velocity tracked) · Interoperable with USDC/USDT via atomic swap or bank-level FX desk · Positions Kenya as regional reference point for stablecoin settlement (like Singapore's XSGD model) HoneyCoin × PesaLink · Bank-as-Custodian Journey · Joint Venture Partnership Confidential · Joint Venture Partnership
Reserve integrity
Bank publishes signed daily proof-of-reserves with a Merkle root on-chain. On-chain supply is always verifiable against fiat held in ring-fenced accounts.
Neutrality
PesaLink stays neutral across issuers — same orchestration, same economics, whether the token is KESC, USDC, USDT, or a competing KES stablecoin. No winner-picking.
Revenue streams for the bank
Custody fees on reserves, float on balances held, FX conversion at redemption, and treasury services to the issuer. New fee line with no incremental balance-sheet risk.
Next

From diagrams to a signed LOI.

These journeys are the common reference point for the commercial and technical artifacts that follow. None of them require PesaLink to build a new clearing system or take on custody risk.

01
LOI Draft TBS

HoneyCoin to share draft LOI by end of week outlining commercial model (60/40), scope, timelines, IP, confidentiality.

02
Technical Workshop with Engineers on Development Build

Joint session between HoneyCoin and PesaLink engineering to align on wallet architecture, enclave topology, integration touchpoints, and the sequence of delivery.

03
Negotiation and Execution of Master Service Agreement

Commercial terms, SLAs, compliance obligations, custody arrangements, and revenue sharing finalised and executed by both parties.

04
Testnet Pilot

End-to-end flow that PesaLink stakeholders and a pilot bank can interact with before go-live.