The Hidden Cost of Cross-Border Payments

Two weeks ago we asked whether faster is actually better. Last week we asked where a payment actually is while it’s in flight. This week we’re asking a blunter question, one every bank already tracks somewhere in a spreadsheet: what does it cost when a cross-border payment doesn’t just work?

The answer banks usually reach for is the return fee, or the reimbursement on a confirmed fraud case. Those are real, but they’re the visible part of the cost. The bigger number is the one that doesn’t show up on an invoice: the hours an operations team spends chasing down what happened to a payment that’s stuck, misdirected, or bounced back with no explanation.

Why this matters for banks

A failed or misdirected payment doesn’t resolve itself. Someone on the ops side has to open a case, work out which leg of the correspondent chain it stalled on, contact the counterpart bank, wait for a reply, and relay an answer back to a customer who’s already called in twice. Handling a single misdirected or returned payment this way costs a bank somewhere in the range of €20–60; for corporates, a failed transaction adds roughly €100 in knock-on cost once you count the reconciliation and follow-up on their side too. None of that is exotic, it’s the ordinary cost of a manual process most banks have simply absorbed as the price of doing cross-border business.

It adds up faster than the per-case number suggests. Banks report spending upwards of €10 million a year on fraud-related reimbursements alone, and that’s before counting the ops hours on cases that were never fraud at all - just a name mismatch, a stale IBAN, or a payment that took the wrong rail. In an illustrative case built from a European bank’s roadmap, cutting a returned-payment rate from 100,000 to 25,000 a year, on 5 million cross-border payments, was worth an estimated €1.5 million in annual savings from prevention alone, before touching the cost of investigating the ones that still get returned.

Build vs buy

Faced with that bill, a bank’s instinct is often to build: add a validation step here, a status dashboard there, patch the gap internally. The problem isn’t the first version, it’s what comes after it ships. Payee verification isn’t one rulebook, it’s a moving target across EU VoP, UK CoP, Swift pre-validation, Kinexys/Liink and NACHA, each with its own onboarding, its own data format, and its own update cycle. A team that builds this in-house isn’t signing up for a project; they’re signing up for a permanent maintenance line - one more system to keep current every time a scheme changes its rules, competing for engineering time against everything else on the roadmap.

That’s the cost most build-vs-buy comparisons understate, because it doesn’t show up until year two. The honest comparison isn’t “cost to build” against “cost to license”, it’s the ongoing cost of staying current, measured against a partner whose entire business is staying current on a bank’s behalf.

Our view

This is why we have focused on both our Global Payee Verification and our Post-Payment API with Exception & Investigation (E&I) and Payment Tracking. Verification cuts the number of payments that fail in the first place - routing across every scheme we support and catching mismatches before money moves. For the ones that still need a human, E&I replaces the email-and-phone-call loop with a structured, self-service case a customer can open and track themselves, so the ops team isn’t the only channel for “what happened to my payment.” Both drop into a bank’s existing systems without a rebuild, and both stay current as schemes evolve, because keeping pace with 35+ countries of payee data is our job, not a side project bolted onto someone else’s.

The question to sit with

Cost is the G20 goal that’s easiest to measure and hardest to see whole, because it’s spread across return fees, ops hours, reimbursements, and whatever a bank is currently paying to maintain its own patchwork of checks. Add it up properly and the number is rarely small. The real question isn’t whether a bank can afford to fix it, it’s whether it can afford to keep maintaining the fix itself.

Next in this series: cost isn’t just about what modernization saves but about who can afford to modernize at all. Next week: why modern payments shouldn’t only be for tier-one banks.