Why Two Money Transfer Apps Never Quote You the Same Number (A Builder's Look at Cross-Border Pricing)
TL;DR: If you've ever wondered why a "£0 fee" transfer can still cost more than a competitor charging £3.99, the answer isn't marketing, it's how FX pricing, liquidity, and payout rails actually work under the hood. This is a quick breakdown from the payments side, not the consumer-tips side.
The problem most fintech explainers skip
Most "how to send money abroad" content stops at "compare fees." That's surface level. The real cost of a cross-border transfer is built from a few layers most users never see, and honestly, a lot of builders outside payments don't think about either:
The FX spread: Every provider sources currency at, or close to, the interbank mid-market rate, then marks it up before quoting the sender. That markup is the actual profit margin on a "free" transfer. You can watch this live by comparing any provider's quoted rate against the mid-market rate published by XE.com or Reuters at the same moment.
Liquidity and settlement rails: Corridors like UK to Nigeria, UK to India, or UK to the Philippines don't all settle the same way. Some route through correspondent banking, some through local mobile money aggregators, some through licensed payout partners. Each hop adds cost and latency, and that cost gets priced into the spread, not itemised as a fee line.
Regulatory overhead per corridor: A provider licensed to operate in the UK still needs the receiving side to be compliant. For Nigeria specifically, that means holding an International Money Transfer Operator (IMTO) licence recognised by the Central Bank of Nigeria, on top of UK obligations like FCA authorisation and HMRC money laundering registration. None of that is free to maintain, and it shows up in pricing.
Why "zero fee" is a UI decision, not a cost decision
A provider can absolutely charge £0 upfront and still make more money than a competitor charging a flat fee, simply by widening the FX spread. From a product perspective, this is a deliberate framing choice: users respond to a visible fee number far more than an invisible rate gap, even when the rate gap is the bigger cost.
If you're building or evaluating anything in this space, the number that actually matters is total cost: fee plus spread, benchmarked against the real mid-market rate, not the advertised fee in isolation.
What determines whether a corridor is "easy" or "hard" to build for
Some corridors are structurally harder than others, independent of how good your app is:
Payout method fragmentation, a recipient in one country might expect a bank transfer, another might expect mobile money, another might expect cash pickup. Supporting all three, and doing it reliably, is an integration and reconciliation problem, not just a UI toggle.
Local licensing requirements, being FCA-authorised on the sending side covers you in the UK. It says nothing about whether you're legally allowed to pay out in Lagos, Nairobi, or Manila. Each receiving country has its own rules, and providers that skip this step are the ones that eventually get flagged or shut down.
Settlement time variance. Same-day payout in one corridor might be a two or three business day wait in another, purely because of how the local rail clears funds, not because of provider laziness.
Takeaway for anyone building in payments or fintech
If you're building anything adjacent to cross-border payments, the lesson generalises: hidden cost usually lives wherever transparency is hardest to enforce, and regulation is usually a proxy for whether the operational plumbing actually works.
Belyfted's own build has had to account for all three layers above across corridors into Nigeria, Ghana, Kenya, Bangladesh, Pakistan, India, the Philippines, and Vietnam, which is part of why "just compare the fee" is such incomplete advice for users of any app in this space, ours included.
Curious how others building in this space have handled the licensing-per-corridor problem, would love to hear how you approached it if you've shipped anything similar.
Top comments (0)