Enhancing Cross-Border Payments: Building Blocks of a Global Roadmap in Practice
The global roadmap identifies infrastructure and policy changes that can improve international payments. Finance teams need a dependency-based implementation plan to turn those changes into better recipient outcomes.
Enhancing cross-border payments: building blocks of a global roadmap refers to the framework of 19 building blocks developed through the BIS Committee on Payments and Market Infrastructures as part of the FSB-coordinated work behind the G20 roadmap. These building blocks address the infrastructure, regulation, data, and coordination problems that make international payments expensive, slow, difficult to access, or opaque.
For companies paying vendors, contractors, or sellers internationally, the practical lesson is not to wait for a globally seamless payment network. It is to identify which building blocks can improve their payment flows—and which dependencies still prevent those improvements from reaching recipients.
A faster rail is an input. A predictable, fully reconciled payment is the outcome. The gap between them should determine your implementation priorities.
Understand the building blocks before applying them
The original framework grouped its 19 building blocks into five focus areas. This summary of the BIS and FSB building-block framework explains its place in the three-stage process that produced the roadmap. The G20 endorsed the roadmap in November 2020.
The table below summarizes those original areas and translates them into operational questions. These are business interpretations, not additional official building blocks.
| Original focus area | What it addresses | Question for finance teams |
|---|---|---|
| Public and private sector commitment | Shared goals and coordinated action | Who owns each payment handoff? |
| Regulatory, supervisory, and oversight frameworks | Consistency across jurisdictions | Which local requirements still apply? |
| Existing payment infrastructures and arrangements | Access, operating hours, and settlement | Can the route settle when needed? |
| Data and market practices | Message quality and interoperability | Does required data survive the journey? |
| New payment infrastructures and arrangements | Alternative infrastructure designs | Is the service operational or experimental? |
Later implementation work has concentrated on three priority themes: payment system interoperability and extension; legal, regulatory, and supervisory frameworks; and data exchange and message standards. These themes organize ongoing work rather than replacing the original framework with a new set of payment rails.
Why policy progress is not a delivery guarantee
The FSB’s October 2025 consolidated progress report found that most international policy work had been completed, but end-user improvements remained limited. It judged satisfactory global improvements unlikely within the roadmap’s 2027 timetable.
That is a dated, global assessment—not a prediction for every corridor or provider. A particular route may improve substantially even while aggregate results remain disappointing. Conversely, a provider’s infrastructure upgrade may deliver little benefit to your recipients.
The distinction matters for investment decisions. Do not approve a migration because it is described as “roadmap aligned.” Require an explanation of the bottleneck it removes, the dependencies it leaves intact, and the evidence that recipients will benefit.
Translate the framework into implementation dependencies
Payment-system access: identify who actually settles
Building Block 10 addresses direct access to payment systems by banks, non-banks, and payment infrastructures. Broader access can create opportunities for competition and reduce dependence on intermediary arrangements. It does not mean every payment provider has direct access everywhere.
The CPMI’s 2025 monitoring survey examines jurisdictional progress on measures including payment-system access and operating hours. For a corporate buyer, the next step is to establish the provider’s actual participation model in each relevant market.
- Which entity submits and settles the domestic payment?
- Does the provider participate directly or use a sponsoring institution?
- Which party holds funding and handles returns?
- What happens if a sponsor or settlement connection becomes unavailable?
Direct access is not automatically the best commercial choice. An indirect participant may offer better coverage or operational support. The objective is to understand the dependency, not to award a blanket preference.
Operating hours: connect availability to usable liquidity
Longer settlement hours can reduce delays caused by mismatched business days. But an always-available recipient rail does not make the full funding chain continuously available.
Trace when funds can move from your source account, when FX can be executed, when the provider recognizes available balances, and when the destination institution credits the recipient. A weekend payout may still require liquidity positioned before the weekend.
Holding destination currency can reduce dependence on just-in-time conversion, but creates cash-allocation and currency-exposure tradeoffs. Services such as Payouts.com Global Accounts support collecting and holding multiple currencies; treasury still needs policies for balance ownership, replenishment, and exposure limits.
Data harmonization: preserve meaning, not just format
Standardized messages can improve straight-through processing and reconciliation. They cannot repair inaccurate beneficiary details or resolve every difference in local information requirements.
Maintain a requirements register by destination, recipient type, currency, and rail. Record applicable account identifiers, bank identifiers, address fields, payment-purpose information, and supporting-document requirements. Obtain current requirements from the provider handling that route rather than assuming one universal country template.
Then test the entire data path. A structured address collected during onboarding is of limited use if an integration flattens it into free text. An invoice reference is not useful for reconciliation if it is lost before the recipient receives the payment.
Assign ownership to each field: who collects it, who validates it, which system stores the authoritative value, and who corrects it after a rejection.
Regulatory alignment: distinguish common principles from local obligations
International coordination can reduce inconsistent approaches, but it does not create a single global license or eliminate jurisdiction-specific screening and documentation requirements.
For each payment flow, document the regulated entities involved and the division of responsibilities. Specify which party performs recipient checks, requests additional information, investigates a hold, and communicates with the recipient.
Better data exchange also needs access controls and appropriate handling rules. Sending every available personal-data field to every participant is not a sound substitute for identifying what each party actually needs.
Interlinking and new infrastructure: test the complete service
Connecting fast payment systems can improve cross-border delivery. Yet the connection must still accommodate currency conversion, funding, transaction limits, compliance controls, and exception handling.
Separate a technical demonstration from a production service available to your legal entity and recipient population. Ask whether the route supports your payment purpose, currencies, amounts, and return process—not merely whether the infrastructure exists.
Use a corridor-based platform evaluation to assess those dependencies. A domestic instant-payment capability alone does not establish an end-to-end international delivery commitment.
Build a dependency register, not another technology wish list
The useful unit of planning is a specific payment flow: sending entity, funding currency, destination currency, recipient type, and delivery rail. For each material flow, create a dependency register containing:
- Observed friction: Describe the failure or delay using payment records, not assumptions.
- Relevant building block: Identify whether access, hours, data, regulation, or infrastructure is the likely constraint.
- Controllable change: Separate your own process changes from provider work and public-sector dependencies.
- Acceptance evidence: Define what will prove the change works.
- Fallback and owner: Name the escalation path and accountable team.
Hypothetical example: A marketplace has a fast domestic payout option, but international seller payments frequently wait for additional information. Moving to another instant rail may not address the problem. Investigation finds that payment-purpose data is collected only after submission. The appropriate first change is destination-specific onboarding validation, followed by testing whether the provider receives and accepts the information without manual repair.
If payments still wait after that change, investigate funding availability and beneficiary-bank processing separately. Treating each dependency independently prevents an expensive infrastructure project from masking a simpler process defect.
Measure whether the building blocks reach the recipient
Agree on event definitions before comparing performance. “Submitted,” “accepted,” “settled,” and “credited” are different states. Where recipient-credit confirmation is unavailable, label that limitation instead of treating provider acceptance as completion.
- Speed: Track approval-to-release and release-to-confirmed-credit separately.
- Cost: Include explicit fees, FX costs, known deductions, and return charges.
- Data quality: Track repair requests and rejections by field and route.
- Reliability: Monitor delivery against the promised window and exception age.
- Transparency: Record whether the expected recipient amount and payment status are available.
Segment results by corridor and recipient type. Otherwise, a shift toward easier routes can make aggregate performance look better without improving any underlying process.
Make the roadmap actionable inside finance
The global roadmap establishes a direction; your dependency register establishes an executable plan. Start with a material payment flow, identify its binding constraint, assign an owner, and demand evidence of improvement before expanding the change.
Payouts.com brings global payouts, treasury, and financial automation together on one ledger. Explore Payouts Automation with your requirements register and acceptance criteria in hand. The right discussion is not whether a platform supports modernization in principle, but how it helps your team control the handoffs that determine recipient outcomes.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
35 commentsRelated resources
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.
Jobber Instant Payouts: Fees, Timing, and Cash-Flow Decisions
Jobber Instant Payouts accelerates access to eligible customer-payment funds, but it does not make every collection immediately available. Here is how to evaluate timing, fees, reconciliation, and the next payment your business needs to make.
Payout Support: Build a Clear Escalation and Resolution Model
Reliable payout support connects recipient questions to payment evidence, accountable owners, and controlled actions. Here is how finance and operations teams can build that operating model 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 question about who actually owns each payment handoff is harder than it sounds when you're dealing with a provider that uses different sponsoring banks across markets. We recently traced a LatAm payment that touched four different entities before local settlement, and when something broke nobody could tell us which handoff failed or who was responsible for fixing it.
This is why the article's question about which party holds funding and handles returns is so important. When a payment breaks mid-chain like that, you need to know who can actually resolve it and who just points to the next entity. We started requiring providers to document the full settlement chain upfront, including fallback procedures for each participant.
This is why the article's question about which party holds funding and handles returns is so important. In multi-entity chains like that, return handling is often the place where gaps in ownership become obvious. Did you eventually get visibility into which entity was supposed to resolve it?
The distinction between 'a faster rail is an input' and 'a predictable, fully reconciled payment is the outcome' should be printed on a poster. We wasted six months implementing a new provider because their marketing emphasized speed, but they couldn't tell us which intermediary was truncating remittance data in three of our key corridors until we were already live.
We had the exact same issue with remittance data getting stripped at the correspondent bank level. Turned out the provider was using a legacy correspondent relationship that only supported 35-character unstructured fields. The article's point about testing the entire data path is spot on—you need to verify what actually reaches the recipient, not just what leaves your system.
We had the exact same issue with remittance data getting stripped at the correspondent bank level. The article's advice to test the entire data path is something we now do before any migration, not after. Asking the provider which entity actually submits the payment helped us identify where the truncation was happening.
The point about maintaining a requirements register by destination, recipient type, currency, and rail resonates, but the reality is most teams don't have bandwidth to maintain something like that manually. Has anyone automated this using provider APIs or built tooling that pulls current requirements directly instead of maintaining static documentation that goes stale?
We haven't automated it completely, but we do pull static field requirements from a couple providers via API and validate against them before submission. The harder part is tracking when requirements change without notice—no API helps with that. We still rely on monitoring failure codes and periodic manual audits.
We haven't automated it completely, but we do pull static field requirements from a couple providers via API and store them in a structured config file that feeds our validation layer. The problem is most providers don't expose current local requirements programmatically—they update PDF docs or help center articles instead. So we still end up with a hybrid: API-sourced schema where available, manual updates for everything else, and a quarterly review cycle to catch drift.
The part about tracing when FX can be executed is something we didn't consider until we had a multi-day delay on what the provider claimed was a 'real-time' rail. The recipient system was live, but our treasury couldn't release funds for conversion until Monday morning, so a Friday instruction sat pending all weekend.
We hit this exact scenario. The fix was moving to a pre-funded model where we allocate liquidity Thursday afternoon for Friday-initiated payouts. Not elegant, but it eliminated the weekend queue entirely.
Same issue. We now map out the full liquidity chain before committing to any SLA with vendors. The article's point about connecting availability to usable liquidity is something we should have addressed in our treasury playbook from day one instead of troubleshooting it incident by incident.
The section on operating hours is a good reminder that availability doesn't equal liquidity. We've had situations where a rail is technically open but our provider can't execute FX until their liquidity partner opens on Monday, so weekend payouts still require Friday funding. Would be helpful to see more discussion on how to map out those liquidity dependencies when evaluating new corridors.
We run into this constantly. The article's point about tracing the full chain—source account availability, FX execution window, provider balance recognition, and destination crediting—maps exactly to what we now document for every high-volume corridor. Turns out the biggest gap for us wasn't the settlement rail at all, it was when our provider's treasury team could actually access interbank FX markets.
We built a simple matrix showing funding cutoffs vs settlement windows for each provider/corridor pair. Turned out half our 'instant' rails still needed T-1 positioning because of liquidity constraints upstream. Now treasury knows exactly when balances need to be in place instead of scrambling on Fridays.
The requirements register by destination, recipient type, currency, and rail is something we should have built two years ago. We're still chasing down address format requirements case by case, and half the time the provider's documentation is either outdated or contradicts what their API actually validates.
We ended up treating the requirements register as a living document that gets updated every time a validation fails in production. Not ideal, but at least now when the API rejects something we update the register immediately with what actually worked. The gap between provider documentation and implementation is real.
Same problem. We finally started tracking divergences between documentation and actual validation errors in a shared sheet. Turned out three of our providers were enforcing different state/province rules than their own specs claimed, and one was silently truncating beneficiary names at 32 characters despite accepting 70 in the payload.
The point about not approving a migration just because it's 'roadmap aligned' is something we learned the expensive way. Our provider upgraded to a new settlement infrastructure and marketed it heavily around G20 compliance, but our LATAM recipients saw zero improvement in delivery times because the last-mile correspondent arrangements didn't change at all.
Sounds familiar. The article's point about identifying the actual bottleneck rather than just the rail upgrade is what we should have done upfront. In our case the new settlement infrastructure worked fine but the local banking partner relationships and their end-of-day cutoffs didn't change at all.
Exactly this. We had a similar experience in Southeast Asia where the provider kept citing their participation in regional faster payment schemes, but what they didn't tell us upfront was that they were using a correspondent bank for final settlement in two of our highest-volume corridors. The building block progress looked great on paper, but our actual dependency chain hadn't changed at all.
The advice to require an explanation of the bottleneck removed, dependencies left intact, and evidence of recipient benefit before approving a migration is something we should have followed two years ago. We moved to a new provider based on their roadmap alignment messaging and only realized six months in that the actual settlement model hadn't changed at all for our LATAM corridors.
Six months is actually a fast realization. We didn't discover our provider's settlement dependency on a third-party sponsor until a compliance audit eighteen months in, which explained why certain corridors had unpredictable delays the whole time.
The framework translation table is useful, but I wish there was more discussion about how to prioritize building blocks when you're operating in 15+ markets with different maturity levels. We can't tackle regulatory harmonization and payment system access simultaneously across all corridors, so how do you decide which markets get attention first—volume, strategic importance, or current failure rate?
We've started scoring corridors by payment volume, complaint rate, and whether the provider has direct settlement access in that jurisdiction. That gives us a shortlist where addressing BB10 or operating hours actually moves the needle. For lower-volume markets we just document the dependency and revisit annually.
We use a simple triage: score each corridor by monthly volume and recipient pain (complaints, late arrivals, reconciliation failures). Then map the specific building block gaps causing that pain. In practice, payment system access issues in one high-volume market will usually outrank data harmonization in three low-volume ones. The hard part isn't choosing—it's accepting that some corridors just won't get fixed this year.
The part about holding destination currency vs just-in-time conversion hits hard for mid-size companies. We don't have treasury sophistication to manage exposure across eight currencies, but eating 200+ bps on every conversion plus weekend delays was unsustainable. Ended up pre-funding EUR and GBP only, which helped the most common corridors but left the dependency problem everywhere else.
We made the same call for EUR and GBP, but the treasury policy became the hard part. Who decides when to replenish? What exposure limit applies to each entity? Six months in, we're still fighting over whether AP owns the balances or treasury does.
We made the same call for EUR and GBP, but the treasury policy became the hard part. Who decides exposure limits when AP needs liquidity but treasury wants minimal balances? Ended up with a weekly replenishment model that still causes friction during high-volume weeks.
I appreciate the distinction between infrastructure upgrades and actual recipient outcomes. Our payments team got burned last year when a provider sold us on their new real-time rail partnership, but it turned out they were still batching on their side for fraud review. The rail could settle instantly but we were still looking at T+1 because of their internal process.
Same experience. The article's point about tracing when funds can actually move through the full chain is critical. We now require providers to document not just the final leg settlement time but their own internal processing windows, including fraud holds, compliance checks, and any batching they do before releasing to the rail.
Same experience here. We learned to ask for the full timing breakdown from when they receive our file to when funds actually credit the recipient account. Turns out 'real-time capable' and 'real-time operational' are very different things, especially when compliance holds are still manual.
The question 'Does required data survive the journey?' is exactly the right one to ask. We've had structured remittance data make it through our ERP and gateway perfectly, only to arrive at the recipient as truncated garbage because an intermediate correspondent bank still operates on 35-character limits. Now we map every new corridor before we promise vendors they'll get invoice numbers.
We've seen the same thing with ISO 20022 adoption. The sender formats everything correctly, but if even one bank in the chain hasn't upgraded their core system, the structured data gets dumped into unstructured fields. The real test isn't what your provider supports—it's whether you can trace a sample payment all the way to the recipient's bank statement and confirm the remittance info actually arrived intact.
This is why we now ask providers for complete chain-of-custody documentation showing every intermediary and their message formats before onboarding a new corridor. If they can't map it, we assume the data won't survive intact.