Diaspora Remittance as Infrastructure

The diaspora remittance flow into Kenya is one of the largest financial inflows to the country. Per Central Bank of Kenya statistics, 2024 diaspora remittances totalled USD 4.9 billion — a figure comparable in magnitude to the country's tea exports, larger than tourism receipts, and an order of magnitude larger than annual official development assistance. The flow is substantial, predictable, and — this is the distinctive feature — composed largely of small payments from known senders to known receivers with known purposes.

That last observation is the one that matters for the Lab's finance programme. Most remittance senders are paying for something specific: a school fee, a utility bill, a rent payment, a family member's asset-finance instalment, a medical treatment, a planned purchase. The general-purpose cash transfer that diaspora remittance currently becomes is a technical artefact of the payment infrastructure, not a reflection of the sender's actual intent. The question the Lab's diaspora brief asks is what happens if the infrastructure starts reflecting intent.

A diaspora sender in Amsterdam or Rotterdam wishing to pay her sister's boda-boda ride-to-own instalment in Nairobi today executes, if we trace the steps carefully, approximately twelve distinct payment operations between the initial intent and the eventual satisfaction of the obligation. A representative sequence:

1. Sender identifies an international remittance provider

   She chooses from among a handful of licensed providers (WorldRemit, Wise, Sendwave, Remitly, the major banks) based on price, speed, and reliability. The choice consumes minutes to hours of effort per transaction.

2. Sender funds the remittance provider from her home-market account

   She initiates a transfer from her SEPA bank account to the provider's aggregator account. Settlement: same-day or next-day, depending on route.

3. Remittance provider performs compliance screening

   Sanctions, AML, KYC checks run on sender and receiver. Delays are not uncommon; holds on suspicious transfers can persist for days.

4. Remittance provider credits receiver's mobile-money wallet

   Typically M-Pesa, via the provider's integration with Safaricom. Receiver sees a generic mobile-money inflow credited to her wallet; there is no structured metadata identifying the intended obligation.

5. Receiver initiates settlement of the specific obligation

   Receiver, having seen the inflow, now opens her mobile-money wallet and initiates a payment to the ride-to-own financier's till number. The sender's intent is now dependent on the receiver's manual routing.

6. Financier reconciles the payment against the specific contract

   The financier's system matches the inbound till payment to the specific asset-finance contract, updates the contract's payment-history ledger, and releases any conditional locks on the asset. This step is internal to the financier but consumes operator back-office time.

Each step consumes cost, time, and trust. The total transfer cost — from sender-funded SEPA account to obligation-cleared status on the financier's books — is typically 6–9 percentage points, before considering the residual risk that receiver misroutes the funds (uses them for a different purpose, delays payment, retains them for emergency expenses). The risk is not hypothetical; it is a well-documented feature of remittance flows in many corridors.

Three reasons combine to explain why the remittance-to-obligation gap has not been a central concern of the mainstream remittance-policy conversation.

First, the remittance-policy conversation has, for good reason, focused intensively on the cost of cross-border transfer — the 6–9% figure mentioned above, which the Sustainable Development Goals ambition to reduce to 3% or lower. The focus on cost per transaction has, however, displaced the parallel conversation about what happens to the money once it arrives. A 6% transfer cost followed by a 2% downstream routing cost is not the same problem as an 8% transfer cost, even if the total is superficially similar.

Second, the receiver's manual routing step is invisible to the remittance provider. From the provider's perspective, the transaction terminates when the receiver's wallet is credited. What the receiver then does with the funds is, in the provider's operational view, out of scope. The effect is that the actors who measure remittance outcomes are not the actors who see the downstream inefficiency.

Third, the technical vocabulary needed to discuss direct-obligation addressability has, until recently, been specific to payments-infrastructure research rather than to remittance-policy research. Bridging the two conversations is, itself, part of the Lab's contribution.

The constructive claim in this brief is that if the interoperability primitives described in the Lab's interoperability deep-dive were deployed in the Kenyan diaspora corridor, the twelve-step flow above compresses to roughly four steps.

1. The receiver's ride-to-own contract carries a portable addressable identifier

   The identifier is a direct, addressable reference to the specific instalment schedule. It is publishable by the receiver (via QR code, via a shared link, via a family-group message) and verifiable by the sender before any funds move.

2. The sender initiates payment directly to the obligation reference

   Using a diaspora-facing web or mobile client compatible with the interoperability layer, she pays into the specific instalment schedule. Compliance checks run in the background as today; nothing about the screening disappears.

3. The interoperability layer routes the value across networks

   From the sender's euro-denominated source to the financier's Kenyan-shilling-denominated obligation, with appropriate currency conversion and inter-network settlement — all executed automatically and visible to both sender and receiver in real time.

4. The financier sees the inbound payment as a structured credit against the specific contract

   No manual reconciliation is required; the inbound payment arrives with structured metadata identifying the obligation. The contract's payment-history ledger is updated automatically; the receiver is notified that the instalment has been met.

Several aspects of this compressed flow deserve emphasis. The receiver is no longer a payment router; she is informed of the payment, but the payment has already reached its destination when she is informed. The sender's intent is preserved through the flow; at no point is the sender's specific purpose reduced to a generic cash transfer. The financier's reconciliation is automatic; the structural operator back-office cost is eliminated.

The constructive picture above is, deliberately, an optimistic one. Three reservations balance it.

First, the compressed flow does not address the base cross-border-transfer cost. Much of the 6–9% transfer cost is attributable to foreign-exchange margins, compliance overhead, and licensed-corridor economics — costs that are not directly addressable by an interoperability layer acting above existing payment networks. A direct-obligation architecture could, however, create competitive pressure on those costs by making corridor choice more granular and comparable than it currently is.

Second, not every diaspora remittance is for a specific obligation, and not every specific obligation is one that would benefit from direct addressability. Household consumption spending, emergency transfers, and unanticipated family support will continue to need general-purpose cash transfers, and the interoperability layer should be additive to — not a replacement for — the existing remittance infrastructure. The brief's argument applies specifically to the share of remittance flow that funds known, specific, recurring obligations.

Third, receiver privacy and agency are first-class design considerations. A receiver whose obligations are externally addressable is, in a meaningful sense, made financially legible to senders in a way that requires her active consent and revocable control. The addressability primitives described here are specified to put the receiver in control of disclosure — she publishes the identifier, she can revoke it, she can control which senders are authorised against which obligations. A deployment that did not honour receiver agency would be worse than the status quo. The Lab's research design treats this as a hard constraint.

A final observation, developed further in the Lab's finance programme. The diaspora is not, in the Lab's view, merely a source of remittance flow. It is a latent infrastructure actor in its own right — a population of skilled professionals, financial service users, and software developers with direct familial and economic stakes in the inclusion outcomes the finance programme cares about.

The conventional picture of the diaspora as a sender of funds understates what the community contributes. A meaningful share of the engineering talent that has built the Kenyan fintech sector — the Daraja ecosystem, the M-KOPA integrations, the ride-hailing platforms, the battery-swap back-ends — is diaspora-affiliated by history, by training, or by active circulation between markets. Any serious programme of work on payment-rail interoperability in the Kenyan corridor has to engage that community as co-designers and not merely as transaction counterparties.

The Lab's research plan for the diaspora strand includes structured engagement with the Dutch–Kenyan corridor specifically — through the Lab's Delft research base, through established Dutch–Kenyan professional networks, and through the Netherlands-hosted academic and policy institutions (Kenya Diaspora Alliance Netherlands, Dutch Ministry of Foreign Affairs migration-diaspora programmes, the Centre for Frugal Innovation in Africa) whose remit overlaps the Lab's.