Central Bank Digital Currencies for Cross-Border Payments: A Finance Leader’s Guide
CBDCs could improve cross-border settlement without solving every problem in an international payout. Here is how finance teams can distinguish infrastructure progress from a usable payment service.
Central bank digital currencies for cross border payments can help participating institutions settle in central bank money, coordinate currency exchanges, and reduce some intermediary steps. They do not automatically make international vendor or contractor payments instant, inexpensive, or universally available. Access rules, FX liquidity, compliance checks, and the final credit to the recipient still determine the outcome.
For finance teams running international payout batches, the practical question is not whether CBDCs can move money. It is whether a particular arrangement provides a legally available, fundable, and supportable route from your account to your recipient’s usable balance.
Treat a CBDC as a potential settlement component, not a complete payout service. That distinction should guide both procurement and treasury planning.
What a cross-border CBDC payment actually involves
A CBDC is digital money that is a direct liability of a central bank. Its permitted holders and uses depend on its design. It is not simply a commercial bank balance recorded on a blockchain, and distributed ledger technology is not a requirement for every CBDC.
- Wholesale CBDCs are intended for eligible financial institutions and wholesale settlement. A business could benefit through its bank without holding CBDC itself.
- Retail CBDCs are intended for broader use by individuals and businesses, subject to local eligibility, distribution models, and holding restrictions.
A stablecoin generally has a private issuer or arrangement rather than a central bank as the obligor. A tokenized commercial bank deposit remains a claim on that bank. These distinctions matter because settlement assets carry different legal rights, access conditions, and redemption mechanisms.
The joint report on CBDCs for cross-border payments frames the opportunity around cross-border access and coordination between systems, rather than assuming domestic CBDC issuance alone fixes international payments.
Follow the full payment chain
In a possible wholesale arrangement, a company instructs its bank to pay an overseas supplier. The bank obtains or allocates settlement funds, arranges FX, and transfers value through the participating infrastructure. The receiving institution then credits the supplier under its own account and compliance rules.
The interbank settlement might be fast while the supplier’s account credit is delayed. Finance teams must therefore distinguish instruction acceptance, FX execution, settlement finality, and beneficiary funds availability.
How CBDC systems can connect across borders
The BIS analysis of multi-CBDC arrangements describes approaches ranging from compatible systems to interlinked systems and common infrastructure. The following operational assessments explain what each approach could mean for a payout buyer; they are not rankings of live services.
| Arrangement | Connection mechanism | Potential operational fit | Finance team’s key question |
|---|---|---|---|
| Compatible systems | Aligned standards and practices | Reducing data and processing friction | Who actually executes the cross-border transfer? |
| Interlinked systems | Connections between separate platforms | Connecting distinct domestic designs | What happens if one system is unavailable? |
| Common platform | Shared multicurrency infrastructure | Coordinated settlement among participants | Which banks and currencies are accessible? |
Technical compatibility does not establish legal permission to transact. Shared infrastructure also requires agreement on governance, participant admission, dispute handling, data access, and settlement rules.
What mBridge demonstrates—and what it does not
According to the BIS Project mBridge overview, the project reached minimum viable product stage in mid-2024. It explored a shared multi-CBDC platform for participating central banks and commercial banks, designed to support instant cross-border payments and settlement.
That milestone is evidence of infrastructure development, not proof that any business can route a payout through it. Before relying on a project announcement, obtain current confirmation of participating institutions, permitted transaction types, currency access, and production service terms. Historical pilot participation is not a current availability guarantee.
Where CBDCs could improve payment economics
Coordinating the two sides of an FX trade
Payment-versus-payment settlement makes the final transfer of one currency conditional on the final transfer of the other. Where supported, this can reduce the risk of paying away one currency without receiving the currency purchased.
It does not remove the need for an FX provider. Spreads still depend on liquidity, competition, transaction size, and market conditions. A faster settlement mechanism cannot manufacture a competitive quote for a thinly traded currency.
Reducing intermediary steps and reconciliation gaps
A shared platform may let eligible institutions transact more directly and observe consistent settlement records. That could reduce some correspondent handoffs and uncertainty over payment status.
However, your invoice reference must survive the journey. A ledger transaction identifier alone is insufficient to match a supplier payment to an approved payable. Require a traceable connection between the business payment ID, settlement record, FX trade, fees, and beneficiary credit.
Changing liquidity requirements
Faster settlement can shorten the time funds spend in transit, but it can also require immediately available balances. Ask whether the service uses prefunded CBDC holdings, on-demand conversion, or another liquidity arrangement—and what happens when funding services are closed.
Assess the total funding requirement across currencies and institutions, not just settlement speed. The same discipline underpins real-time treasury management: knowing where money is does not necessarily mean it is available where the next obligation falls due.
What a new settlement asset does not solve
The IMF’s retail CBDC design and policy analysis emphasizes decisions about nonresident access, foreign financial institutions, and interoperability. A domestic wallet or account should not be assumed to support foreign business payments.
- Compliance: Customer due diligence, sanctions screening, and transaction monitoring obligations still apply. Automated checks need clear responsibility and exception handling.
- Country-specific data: Beneficiary identity, account or wallet identifiers, payment-purpose information, and supporting documents remain corridor-dependent. A CBDC does not create a universal onboarding form.
- Capital and currency controls: Technical connectivity does not override restrictions on cross-border transfers or currency conversion.
- Privacy: Establish which institutions can access identity and transaction data, where information is stored, and how disclosure requests are handled.
- Errors and returns: Final settlement is not the same as a reversible payment. Recovery may require a separate return transaction and recipient cooperation.
These limitations also explain why linked instant-payment systems, conventional bank routes, and other digital settlement arrangements remain relevant. Evaluate the route that serves the obligation, rather than assuming CBDC participation is inherently superior.
A practical CBDC readiness checklist
Ask a prospective provider for a corridor-specific service specification, not a general CBDC roadmap.
- Prove access. Identify the sending and receiving institutions, eligible business types, currencies, and permitted payment purposes. Distinguish production access from sandbox participation.
- Define the payment promise. Obtain separate status definitions for acceptance, FX execution, final settlement, and recipient availability. Identify the evidence behind each status.
- Price the complete route. Include provider fees, FX spread, funding costs, recipient charges, and exception handling. Compare the same destination amount and delivery requirement.
- Document liquidity operations. Confirm funding windows, conversion procedures, balance limits, and responsibility for stranded or unused funds.
- Map compliance and data. Assign ownership for screening, documentary checks, data retention, and regulatory reporting. Validate required beneficiary fields before release.
- Test failure recovery. Cover unavailable participants, expired FX quotes, rejected beneficiaries, duplicate instructions, and uncertain settlement states.
- Require reconciliation evidence. Confirm that downloadable records or API events connect the payable, currency conversion, fees, settlement, and beneficiary credit.
Use the same corridor evaluation discipline used for a mass payout platform. Passing a technical demonstration should not waive finance or compliance acceptance criteria.
Hypothetical example: settlement succeeds, supplier credit stalls
Suppose a company’s bank settles a supplier payment through a wholesale CBDC platform, but the receiving bank holds the supplier credit pending payment-purpose documentation. The settlement infrastructure has performed correctly; the commercial obligation remains unresolved.
The payout workflow should preserve both states: interbank settlement confirmed and beneficiary availability unconfirmed. Operations should request the missing documentation rather than automatically resend through another rail. An automatic fallback could create a duplicate payment.
This suggests a useful design principle: keep business payment status separate from rail status. Your ERP and accounting integrations should preserve those distinctions instead of treating every successful settlement event as proof that the supplier has usable funds.
Build for new rails without depending on them
CBDCs could improve the settlement layer of international payments. Their business value depends on accessible institutions, usable FX markets, legal certainty, and reliable delivery beyond that layer.
Start by mapping a priority corridor from approved payable to recipient credit. Identify the actual bottleneck, then ask whether a CBDC-enabled service removes it without creating new funding or recovery risks.
For the operating layer, explore Payouts.com’s payout automation to organize global payment execution. Evaluate any CBDC connectivity separately: a broad payment platform should not be assumed to support a particular central bank arrangement without explicit confirmation.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
32 commentsRelated resources
Real-Time Treasury Explained: How Finance Teams Are Rethinking Liquidity in Motion
Real-time treasury moves beyond batch reporting and end-of-day snapshots, giving CFOs and controllers a live, actionable picture of every dollar in motion. This guide explains the mechanics, the operational payoff, and what it takes to build it.
How to Evaluate a Mass Payout Platform: Test Corridors, Not Country Counts
Country coverage is not proof that a platform can deliver your payment run. Use a corridor-level acceptance test to evaluate costs, recipient requirements, delivery evidence, and failure handling.
Contractor Payment Terms: From Contract to Cross-Border Credit
Net 30 is only part of the agreement. Learn how to define contractor payment terms that connect invoice acceptance, currency, fees, and payment completion across borders.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The mBridge section is important because we've had three vendors mention it in pitch decks this quarter as if it's something we could use today. The distinction between MVP infrastructure milestone and production availability is exactly the kind of discipline procurement needs right now.
Same here. We've seen slide decks showing mBridge architecture diagrams and multi-currency settlement flows, but when we ask for contract terms or even which correspondent banks we'd actually route through, the conversation pivots to 'strategic partnership discussions.' The article's insistence on current confirmation of participating institutions and production service terms is the right filter.
The point about prefunding requirements is underrated. A lot of the CBDC pitch decks show faster settlement as pure upside, but nobody mentions that you might need to park liquidity in multiple wallets across different central bank systems just to be ready to transact. That's a treasury headache, not a simplification.
We're modeling this now for a potential multi-currency CBDC setup and the working capital hit is not trivial. It's essentially moving from credit-based correspondent relationships to cash-in-advance across multiple systems. The settlement speed improvement has to be weighed against the opportunity cost of that trapped liquidity.
We're modeling this now for a potential multi-currency CBDC setup and the working capital implications are significant. You essentially end up replicating the nostro problem at the central bank level instead of solving it.
The article correctly frames CBDCs as a settlement layer rather than a complete service, but I'd add that most finance teams will never interact with wholesale CBDCs directly—what matters is whether their existing banking partners join a useful arrangement and pass through any actual speed or cost improvements without adding new account requirements or minimum balances.
Agreed, and that's why the question 'which banks and currencies are accessible' in the table matters more than the technical architecture. If only three institutions in a region participate, the pass-through benefit is limited no matter how elegant the settlement design.
Exactly. We're not going to change our entire banking setup to chase a settlement rail. The real test is whether Citi or HSBC or whoever we already use integrates it cleanly and whether we see any difference in same-day funding costs for APAC payouts.
The practical distinction between infrastructure readiness and actually routing a production payout is something we learned the hard way during a real-time rails evaluation in APAC last year. A platform can technically settle in seconds but if your bank isn't a participant or the compliance queue on the receiving end takes three days, the infrastructure speed is irrelevant to your supplier's cash flow.
We ran into the exact same thing with a pilot in Latin America. The platform worked beautifully in test mode, but when we went to production the local compliance engine on the receiving side added 24-48 hours regardless of how fast the settlement layer moved. The article's point about following the full payment chain is what finally forced us to map every handoff and stop confusing fast settlement with fast credit.
We saw the same gap. The settlement confirmation came back in under a minute but the beneficiary bank's compliance team still took 36 hours to release funds because their AML workflow wasn't updated for the new rail. Infrastructure speed and participant readiness are two completely different things.
The framing around 'legally available, fundable, and supportable route' is what we used to evaluate a blockchain-based settlement option last quarter. The vendor kept showing speed demos but couldn't answer which of our eighteen banking partners could actually connect to it or what happened during Asian holiday closures.
Same experience. The demo looked great but when we asked about fallback procedures during maintenance windows or if one participant dropped off the network, we got vague answers about 'coordinated downtime windows.' That's not how our payment calendar works.
We had a similar conversation with our treasury bank about their CBDC roadmap. They kept emphasizing settlement speed but when pressed on operational rollout they admitted only four correspondent relationships would be live in the first phase and none covered Southeast Asia where we have significant payables volume.
The section on PvP settlement is spot-on but I think it understates the operational headache. Even when both legs settle simultaneously, the accounting close doesn't happen at the same instant across entities. We've had to rebuild month-end recon workflows every time settlement windows compress, and nobody at the infrastructure level wants to talk about that part.
Same experience here. The settlement timestamp and the general ledger cut-off are completely different control points, and you end up with a reconciliation buffer that defeats half the benefit of faster settlement. We had to add exception queues for anything that lands after our internal close time even if it settled same-day on their side.
This is a real problem. We ended up keeping parallel shadow records for three days after settlement just to bridge the gap between treasury close and AP close. The speed improvement at the settlement layer actually made our internal control documentation more complicated, not less.
The distinction between settlement finality and beneficiary funds availability is something our treasury team had to learn the hard way during a same-day ACH rollout. We assumed faster interbank settlement meant faster supplier credits, and it absolutely did not in practice because the receiving banks still batched their posting cycles.
We experienced exactly this with a treasury platform upgrade last year. The settlement rails were technically instant but the beneficiary banks still ran their compliance and fraud checks on their usual schedule, so credits sometimes posted the next business day anyway. The article's point about following the full payment chain is spot on.
We experienced the same thing with an international real-time rail. The interbank piece settled in minutes but the beneficiary bank still batched end-of-day credits to business accounts, so our suppliers saw funds the next morning anyway. Speed only matters if it extends all the way through.
The table breaking down compatible vs interlinked vs common platform is useful, but the real question for us has been who actually bears the FX risk during the settlement window. Even with PvP, if there's a gap between when we lock a rate with our bank and when the settlement executes, we're still exposed to basis risk that nobody wants to own.
This is exactly why we keep asking for explicit rate guarantee windows in the SLA. Most banks we've worked with treat the settlement finality as the fix point, but if that's 30 seconds or 30 minutes after we committed to the rate, we're exposed either way.
This is exactly why we keep asking for explicit rate guarantee windows in the SLA. Most banks we've talked to either can't or won't commit to holding a rate through the settlement cycle on a CBDC rail, which makes the whole speed advantage less valuable for budgeting purposes.
"Faster settlement can shorten the time funds spend in transit, but it can also require immediately available balances" - this is exactly the tension our treasury team is dealing with. Moving from T+2 to instant settlement sounds great until you realize you need liquid positions in four currencies at once instead of managing a rolling funding window. Has anyone modeled the working capital impact of switching a supplier payment program to real-time CBDC rails?
We're seeing the same thing. The liquidity optimization models we built assuming two-day float don't work anymore when everything settles same-day. Now we're basically choosing between holding more idle cash or risking failed settlements.
We hit the same wall. The bank wanted us to maintain prefunded balances in their CBDC wallet equivalent for each corridor, which basically meant parking more working capital instead of less. The speed gain disappeared once we factored in the funding overhead.
I appreciate the distinction between wholesale and retail CBDCs here because most of the hype pieces skip right over it. We're never going to hold CBDC directly as a mid-market company, so the real question is whether our banks will pass through any cost or speed benefit, and historically that's been a tough sell.
Exactly right. We've seen this pattern with every infrastructure upgrade over the last decade. The correspondent banking tech gets better but our FX spreads barely budge because we're still too small to negotiate. Unless the CBDC arrangement forces true pass-through pricing or opens up new liquidity providers, I'm skeptical we'll see much change at our end.
This is the right lens. We evaluated a few correspondent banking upgrades last year and the settlement improvement was measurable but the pricing to us barely moved. The banks kept most of the efficiency gain, and we still had to reconcile the same way on our side.
The point about invoice references surviving the journey is critical and often overlooked in these infrastructure discussions. We've had settlement rails that worked perfectly but gave us ledger IDs we couldn't reconcile back to our ERP without manual intervention. If mBridge or any CBDC system doesn't preserve remittance data in a format we can ingest, it's not solving the problem we actually have.
We built a custom middleware layer to translate settlement notifications back to AP document numbers, but it breaks whenever the payment provider changes their message schema. The article's point about needing a traceable connection between business payment ID and settlement record should be table stakes, but somehow it never is.
We ran into the same issue with a real-time gross settlement pilot. The settlement confirmation came back with a hash that meant nothing to our AP team. Ended up building a middleware layer just to preserve the original payment instruction reference through to the final statement line. If the infrastructure doesn't support end-to-end reference data, you're just moving the reconciliation problem around.