The pitch for stablecoin settlement is that money arrives in minutes instead of days. That is true and it is not the interesting part. The interesting part is which obligations moved, which did not, and why the constraint that stops most projects has nothing to do with speed.
What a correspondent chain is really charging for
A bank sending money to a country where it has no presence uses a bank that does. That bank may use another. Each hop is a genuine transfer between two institutions that hold accounts with one another, and each applies its own screening before passing the value along.
The delay is not computation. It is a sequence of independent institutions each satisfying themselves about parties they did not onboard, under rules they are individually accountable for. Fees follow the same shape: each intermediary prices its own risk and its own balance-sheet use.
The failure mode that matters most is not slowness but withdrawal. When an intermediary decides a country or a customer type is not worth the risk, the route closes. The effect is not higher prices; it is the absence of a route at all, and it falls hardest on exactly the economies least able to build an alternative.
What the ledger leg replaces
Substituting a public-ledger transfer for the intermediary chain collapses the middle into a single movement with a published fee, a settlement time measured in minutes, and a record both parties can verify independently without asking each other.
That last property is underrated. A large part of the operational cost of cross-border payments is the two sides not sharing a view of what happened, and resolving that by correspondence. A common record removes a category of work rather than speeding it up.
What does not move
The payer starts with money in a bank account and the beneficiary needs money in a bank account. Those two facts are untouched by anything that happens in between, and they are where every obligation now concentrates.
- Onboarding. Somebody must verify the business, its ownership and its purpose before an account exists. This is generally the longest step in getting a corridor live, and it is a legal requirement on the institution providing the account rather than a formality.
- Holding the money. Funds received on behalf of a customer are the customer’s. They are safeguarded, usually at a separate institution, and must be returnable if the firm fails.
- Conversion. Local currency to stablecoin and back is a regulated activity at both ends, performed by an institution permitted to do it there, at that institution’s price.
- Information travelling with the payment. Most major regimes require details of the originator and beneficiary to accompany a transfer. A public ledger does not carry this by default, so it is carried alongside.
- Monitoring and reporting. Unchanged, and now concentrated on fewer parties than before.
Attribution is the quiet engineering problem
When value arrives on a public network, the receiving side has to know whose it is. There are two workable patterns: give each customer their own deposit address, or use a shared address with a per-customer reference that the sender must include.
Per-customer addresses are cleaner and cost nothing to attribute. Shared addresses with references are cheaper to operate and fail whenever a sender omits the reference — which they will. Choosing between them is a reconciliation decision, not a payments one, and it is worth making before the first live payment rather than after the first unattributable one.
Why coverage, not technology, is the binding constraint
A corridor works only if an institution can reach local rails at both ends. That depends on which currencies and countries the institutions available to you are actually permitted and willing to serve — and that set is uneven, changes without notice, and is frequently the reason a technically complete design cannot be used for a particular payment.
The practical implication for anyone planning: establish coverage for your specific corridor before designing around it. The question is not “can stablecoins do this” but “which licensed institution will receive this currency in this country for this customer type, and what do they need from me”.
What this means for pooling
A tempting simplification is to hold one balance on behalf of many end users and track their shares internally. This is usually the point at which a software company becomes an unlicensed deposit-taker. Where end users each need a recognised relationship with the institution, giving them one is not an inconvenience to design around — it is the thing keeping the arrangement lawful.
The payments page walks the same route step by step, and the licensing page sets out which permission sits behind each institution in it.