Cross-Border Payment Reconciliation Doesn't Fail at the Border. It Fails in the Data.

A payment operations team at a mid-size bank might process thousands of cross-border transactions per day across four corridors. Each corridor involves a different correspondent bank, a different message format, a different set of regulatory fields, and a different expectation for how beneficiary names, addresses, and purpose codes should be structured. Every morning, the reconciliation team opens a spreadsheet with hundreds of exceptions from the previous day's settlement cycle. Most of them aren't actual payment failures. They're data mismatches — a truncated name here, a missing intermediary BIC there, a purpose code that exists in one jurisdiction's taxonomy but not another's.

This is what cross-border payment reconciliation looks like in practice. Not a single dramatic failure, but a slow, grinding accumulation of data friction that consumes hours, delays settlements, and quietly erodes confidence in the numbers.

The Financial Stability Board published its final report on recommendations to promote alignment and interoperability across data frameworks related to cross-border payments in December 2024. The report is dense, carefully scoped, and — if you actually work in payment operations or financial data infrastructure — uncomfortably precise about problems that most organizations have been treating as unsolvable background noise.

But the FSB report is a policy document. It tells you what should change. It doesn't tell you what to do Monday morning when your reconciliation queue is full of breaks and your team has four hours before the next settlement window.

That gap — between the policy direction and the operational reality — is where the real work lives.

The Interoperability Problem Isn't Technical. It's Structural.

When people hear "interoperability" in the context of cross-border payments, they tend to think about APIs, message formats, and ISO 20022 migration timelines. Those matter. But the FSB report highlights something more fundamental: the data frameworks themselves — the rules governing what data is collected, how it's validated, and what format it must take — differ across jurisdictions in ways that create systematic reconciliation failures.

Consider a simple example. A payment originating in the EU under PSD2 requires specific payer and payee identification fields. The same payment landing in a Southeast Asian jurisdiction may require a different set of fields, with different validation rules, different character set tolerances, and different expectations for how legal entity names map to account identifiers. The payment itself moves fine. The data describing the payment doesn't survive the journey intact.

This is not a new observation. What the FSB report adds is a structured taxonomy of where these misalignments occur and a set of recommendations for how standard-setting bodies, regulators, and financial institutions should begin to close the gaps. The recommendations cover areas like harmonizing data definitions, promoting the use of common identifiers (LEIs, UTIs), and encouraging bilateral and multilateral arrangements to reduce friction in data exchange.

All of this is directionally correct. But here's the operational reality: even within a single institution, data frameworks for cross-border payments are rarely consistent. The compliance team validates against one set of rules. The treasury team reconciles against another. The correspondent banking team maintains its own mapping tables. And the operations team — the people actually investigating the daily exceptions — are left to reconcile not just the payments, but the data models themselves.

The FSB's recommendations implicitly acknowledge this. Recommendation 4, for instance, calls for authorities to "promote the use of internationally agreed data standards and identifiers in their data frameworks." That's a multi-year, multi-jurisdiction effort. In the meantime, the reconciliation team still needs to match records across systems that define "beneficiary" differently.

Validation Gaps Compound Across Every Hop

One of the less-discussed dynamics in cross-border payment processing is how validation failures compound. A single missing or malformed field at origination might not cause an immediate rejection. Instead, it propagates through the correspondent chain, picking up additional inconsistencies at each hop, until it arrives at the beneficiary bank as an exception that's nearly impossible to trace back to a root cause.

SafeBooks.ai's analysis of reconciliation best practices highlights this pattern explicitly: data discrepancies that seem minor in isolation become significant when they interact with other discrepancies downstream. A truncated beneficiary name combined with a missing intermediary identifier combined with a purpose code mismatch doesn't produce one exception — it produces three, each logged in a different system, each investigated by a different team, each resolved independently without anyone connecting them back to the same originating transaction.

This is where the FSB's emphasis on traceability becomes operationally critical. The report recommends that data frameworks support end-to-end traceability of payment data across borders. In theory, this means that every transformation, truncation, or substitution applied to a payment's data fields should be logged and auditable. In practice, most institutions can't even trace a data field's transformation within their own internal systems, let alone across correspondent banks in different jurisdictions.

The OCC's $250 million fine against JPMorgan for data control lapses in trade surveillance, as reported by Custodia Technology, underscores what happens when traceability gaps persist unchecked. That enforcement action wasn't about a single bad trade or a single missing field. It was about a systemic inability to demonstrate that data controls were functioning as intended across the organization. Cross-border payment data faces the same structural risk, multiplied by the number of jurisdictions, correspondents, and regulatory frameworks involved.

And the regulatory environment is not standing still. The reconciliation provisions in the July 2025 legislation introduced new reporting and compliance validation requirements for banking institutions. FDIC's evolving posture on bank mergers has added data integration and reconciliation scrutiny to merger assessments. Atlan's research on 2025 compliance challenges documents how frameworks like BCBS 239 and evolving AI governance rules are pushing institutions toward metadata-driven governance — embedding validation and lineage tracking directly into data workflows rather than bolting them on after the fact.

All of these pressures converge on the same operational bottleneck: the ability to validate, compare, and reconcile financial data across systems that were never designed to talk to each other.

What Practitioners Actually Need vs. What Policy Prescribes

The FSB report contains a set of recommendations covering key themes: promoting common data definitions, encouraging the use of standardized identifiers, supporting interoperability arrangements, and enhancing governance and oversight of data frameworks. Each recommendation is sound. Each addresses a real structural problem. And each will take years to implement at scale.

This is not a criticism. Policy frameworks operate on policy timescales. The problem is that operational teams can't wait for global data framework harmonization before they fix their reconciliation processes.

What practitioners need right now falls into a few concrete categories.

First, they need the ability to compare data across schemas without requiring both sides to conform to the same schema first. When you're matching rows from a SWIFT MT message extract against a core banking GL export, the fields don't align neatly. Beneficiary names are formatted differently. Dates use different conventions. Amount fields may or may not include fee components. The comparison logic needs to be flexible enough to handle these variations without generating thousands of false exceptions.

Second, they need validation rules that can be configured per corridor, per correspondent, per regulatory regime — without requiring a six-month IT project for each change. The FSB report acknowledges that data requirements differ across jurisdictions. The operational implication is that validation logic must be modular and adaptable, not hard-coded into a monolithic system that was configured for domestic payments in 2014.

Third, they need audit trails that survive the full lifecycle of a data comparison. When a regulator asks why a particular transaction was flagged, investigated, and cleared, the answer can't be "someone on the team looked at it and it seemed fine." The trail needs to show what data was compared, what rules were applied, what discrepancies were found, and how they were resolved. This isn't just a compliance requirement — it's the only way to do root cause analysis at scale.

Fourth, and perhaps most importantly, they need infrastructure that treats data integrity as a continuous process, not a batch job. The FSB's vision of end-to-end traceability implies real-time or near-real-time visibility into data quality across the payment chain. Most institutions are still running reconciliation as an overnight batch process, discovering yesterday's problems this morning, and resolving them — if they're lucky — before tomorrow's settlement window.

None of these needs are exotic. None of them require artificial intelligence or blockchain or any other technology that gets more attention than it deserves. They require careful, modular infrastructure that's designed around the specific operational realities of financial data comparison and validation.

That's a different kind of problem than the one the FSB is solving. The FSB is working to align the rules of the game across jurisdictions. Practitioners need tools that let them play the game as it exists today — messy, inconsistent, and unforgiving of errors — while remaining adaptable as those rules evolve.

The gap between policy intent and operational capability is where most of the real cost lives in cross-border payments. Not in the payment rails themselves, which have gotten faster and cheaper. Not in the messaging standards, which are converging around ISO 20022. But in the unglamorous, detail-intensive work of making sure the data attached to every payment is correct, complete, consistent, and traceable across every system it touches.

That work doesn't get a lot of attention. It doesn't make headlines. It just determines whether your settlement reconciliation closes cleanly or whether your team spends another morning working through exceptions that shouldn't exist.

We're collecting real operational challenges from finance and data teams to decide what to build next. Submit yours → link