Why cross-border payments fail

Cross-border payments fail for four main reasons: the data describing the beneficiary is wrong or badly formatted, a compliance check stops the payment in the chain, a cut-off time or funding gap strands it partway, or the receiving end cannot apply it to an account. None of these is exotic. What makes them expensive is the structure they happen inside: a correspondent chain where each institution holds the payment, checks it, and passes it on, so a single defect can surface three banks and two days away from the sender who could have fixed it.

The cost is measurable. Accuity, a LexisNexis Risk Solutions company, put the cost of failed payments to the global economy at $118.5 billion in 2020, counting fees, labor, and lost business. Banks in that study averaged about $360,000 a year in failed payment costs, corporates just over $200,000, and 60% of organizations reported losing customers over failed payments.

Wrong or badly formatted data

The Accuity research found that account number problems caused roughly one third of failed payments, and inaccurate beneficiary details another third. Two thirds of failures, in other words, are data defects that existed before the payment left.

The defect travels well. A payment instruction hops from the sending bank through one or more intermediary banks, each of which reads and re-transmits the message. Legacy formats truncated long names and addresses; free-text fields invited creative abbreviation; and the account identifier is often validated only at the final bank, days into the journey.

This is the failure mode the ISO 20022 migration attacks. The new message standard carries structured, richer data, with defined fields for names, addresses, and identifiers, and Swift’s coexistence period for cross-border payments ended in November 2025, making structured messages the norm on the interbank network. Structure does not make wrong data right, which is why the complementary fix is pre-validation: checking beneficiary details against the receiving institution before the payment is sent. The CPMI has recommended that payment service providers prioritize pre-validation APIs, and the FATF’s revised Recommendation 16, finalized in June 2025, requires beneficiary institutions to run alignment checks that detect misdirected payments.

Compliance holds

Every institution in the chain screens the payment: sanctions lists, embargo rules, its own risk policies. We map where those checks happen in where sanctions screening happens in a payment. For failure purposes the relevant fact is that screening happens repeatedly, at each hop, against each institution’s own lists and thresholds, and any hop can stop the payment.

A hold is not a rejection. Most screening alerts resolve as false positives after an analyst reviews them. But review takes hours or days, the query often goes back down the chain to the originator by message, and a hold that outlasts the day’s cut-off converts into a full day of delay. When queries go unanswered long enough, the payment comes back as a return, having accumulated fees in both directions.

Missed cut-offs and funding gaps

A payment can fail operationally without any defect in its data. If it reaches an intermediary after that institution’s daily deadline, it waits, and a wait can cascade into a miss at the next hop. And because correspondent settlement runs on pre-funded accounts, a payment can arrive at a bank whose nostro account in the destination currency is short that day. The payment queues until funding arrives. If the queue outlasts the value date the sender promised, downstream obligations start to slip in sympathy.

Returns and repairs

When a payment cannot be applied, it turns around. The return trip crosses the same chain in reverse, often minus a handling fee per hop, and lands weeks of reconciliation work on both treasuries: matching the returned amount (rarely the sent amount) to the original instruction, discovering what went wrong, and re-sending. Repair, the industry term for fixing and re-processing a defective payment, is manual, analyst-time-expensive work, which is how the per-payment costs compound into the six-figure annual totals the Accuity study measured.

What actually reduces failure rates

The evidence points at three levers. Structured data, so defects are caught by schema rather than by a beneficiary bank’s back office. Pre-validation, so the account is confirmed to exist before value moves. And fewer hops, because every intermediary is a place where data is re-read, re-screened, and re-queued. The G20’s cross-border payments program pushes the first two; the FSB’s 2025 progress report is candid that outcomes for end users are improving only slightly. The third lever is structural, and it is where the settlement model itself comes in.

Where Frame fits

Frame is the settlement layer for global finance: one integration to orchestrate payments at scale across fiat rails, stablecoins, and tokenized deposits, with compliance enforced on every transaction and settlement in seconds instead of days.

Failure modes shrink when the chain does. Frame routes each payment across whichever rail fits the corridor and the policy that governs it, which removes the relay of intermediaries re-reading the same instruction. And the checks that stop payments mid-journey run differently: Frame’s Rules Engine evaluates every transaction against its governing policies before it settles, so a payment that cannot satisfy its conditions does not leave, and one that settles produces verifiable evidence that its conditions were met. A failure caught before value moves is an error message. The same failure caught two intermediaries later is an investigation.

See how a rail-neutral settlement layer approaches this in the Frame Blueprint.