How a remittance dollar actually reaches Dhaka: the rails behind cross-border payments to Bangladesh

When a Bangladeshi worker in Dubai sends money home, the funds travel through at least seven distinct systems before they land in their family's account. Most of those systems are invisible to both the sender and the recipient — and that opacity is exactly where friction, delay, and cost accumulate.

This post is a guided tour of that journey. It's a companion piece to our earlier deep-dive on the SWIFT Payments Scheme and Bangladesh's Gateway Intermediary opportunity — if you haven't read that one, it explains why the architecture below is about to become commercially significant. This post focuses on the what and the how: the rails, the messages, and the compliance gates.

The diagram

Tap any node to see what happens at that step.

Stage 1 — Origination and the SWIFT cross-border leg

The journey begins at an originating bank abroad. Roughly 70% of inbound remittances to Bangladesh come through correspondent banking relationships routed over SWIFT, with the rest split between MTOs like Western Union, MoneyGram, and Wise, and direct bilateral arrangements.

When the originating bank accepts the instruction, it generates an ISO 20022 pacs.008 message — the modern replacement for the older MT103. This message carries the structured data SWIFT GPI needs: a unique end-to-end transaction reference (UETR) that lets every party in the chain look up the payment's live status, plus the full FATF travel-rule data set on both sender and beneficiary.

The bank screens the sender against OFAC, UN, and EU sanctions lists, verifies source of funds for larger amounts, and only then releases the message onto the SWIFT network. From this point on, the payment is trackable end-to-end via the GPI tracker.

Stage 2 — The Gateway Intermediary

This is the new piece. Under the SWIFT Payments Scheme launching this year, every scheme-compliant retail payment destined for Bangladesh routes through a designated Gateway Intermediary — currently City Bank — which acts as the bridge between SWIFT's global network and Bangladesh's domestic rails.

The GI does four things in rapid sequence: validates the beneficiary against the core banking system of the destination bank, runs domestic sanctions and fraud checks, books the FX conversion, and then injects a credit message onto NPSB. It then reports the credit confirmation back up the GPI tracker on behalf of the beneficiary bank — which is what closes the loop for the sender's tracking app.

The commercial significance: in a $30B-a-year market, the GI becomes the default routing point for all inbound retail flows. That's the strategic position the earlier post unpacks in detail.

Stage 3 — Bangladesh-side compliance

Before the funds touch a domestic rail, they pass through a second compliance layer specific to Bangladesh:

• BFIU screening against the domestic sanctions list, PEP database, and name-match heuristics. Threshold breaches automatically generate suspicious-transaction reports (STRs) or cash-transaction reports (CTRs).
• Purpose-of-remittance coding under Bangladesh Bank's foreign-exchange circulars. Every inbound payment is tagged with a code that feeds the country's balance-of-payments statistics.
• 2.5% government cash incentive calculation. Eligible remittances to NRB accounts receive an additional 2.5% top-up funded by the government — added at this stage so it flows through to the beneficiary in the same credit.

Stage 4 — NPSB and the last mile

NPSB — the National Payment Switch of Bangladesh — is the domestic rail that delivers the funds to the beneficiary bank or MFS wallet. It uses ISO 8583 (the same message standard cards have used for decades), runs 24/7, and clears in seconds.

For our remittance flow, the relevant NPSB primitive is the Inter-Bank Over-the-Counter Funds Transfer (Credit) message. The GI sends a 0200 request; the beneficiary bank validates and posts the credit; a 0210 response comes back with an approval code. The whole round-trip typically completes in under five seconds.

NPSB also supports MFS interoperability, meaning the same credit-push can land in a bKash, Nagad, or Rocket wallet — critical for beneficiaries who don't have a traditional bank account. Roughly 60% of Bangladesh's adult population uses MFS as their primary financial channel, so this isn't a niche path.

One important nuance: NPSB confirms that the bank credited the account. It doesn't carry a "the human has seen the money" signal. True end-beneficiary acknowledgement — proof-of-delivery to the actual person — has to be built as a separate notification layer on top, typically via SMS, push notification, or a portal confirmation. This is one of the gaps a well-architected GI platform can productize.

Why this architecture matters

Stitched together, these rails deliver something that didn't exist five years ago: an inbound remittance to Bangladesh that can clear from a sender's account in Dubai to a beneficiary's bKash wallet in Sylhet in under a minute, with full end-to-end traceability and automated regulatory reporting.

The pieces are all in place. What's still being built is the orchestration layer — the software that ties SWIFT GPI, the Gateway Intermediary's compliance stack, NPSB messaging, MFS routing, and beneficiary acknowledgement into a single straight-through pipeline. That's the work that will define which institutions own the inbound remittance corridor for the next decade.

For the strategic and commercial framing of why the GI position is the one to watch, see the companion post on the SWIFT Payments Scheme.

Dr. Faizul Bari combines deep academic training with hands-on industry leadership. A BUET graduate and PhD in Computer Science from the University of Waterloo, he has worked across research, teaching, and global industry, including at Huawei. He now leads Spectrum Software & Consulting Ltd. (SSCL), where he drives the design and delivery of impactful software and AI systems for real-world problems.