Over the past five weeks we've asked whether payments are getting faster, whether customers can actually see where their money is, and what it really costs when a cross-border payment doesn't work.
Every one of those questions has an answer available today - if you're one of a handful of global banks with the engineering budget and integration teams to build it. The G20's fourth cross-border goal is the one that asks the harder question: does it work for everyone else too?
Speed, transparency and cost improvements aren't evenly distributed. A tier-one bank with hundreds of engineers can afford to integrate Swift gpi tracking, stand up its own anomaly detection and build parallel connections into EU VoP, UK CoP, Kinexys/Liink and FedNow/RTP one at a time. A regional or mid-sized bank - often the one with tighter margins and a more price-sensitive customer base - usually can't. Not on the same timeline, and not without pulling its whole IT roadmap sideways for a year. If modernization only reaches the banks that already had the resources to modernize, the G20's goals don't get met at the industry level. They get met at the top of it, while everyone else keeps quoting the same return fees and the same “we're looking into it.”
The instinct is to treat this as a budget problem, but it's really an integration problem wearing a budget's clothes. Each scheme; EU VoP, UK CoP, Swift pre-validation, Liink Confirm has its own onboarding process, its own data format, its own update cycle. A bank that wants to be reachable across all of them either builds and maintains a separate connection to each one, or finds a partner who's already done that work once and reuses it on their behalf. The first path scales with headcount; the second doesn't need to. That's the real dividing line between “accessible” and “not”. It is not whether a bank can afford one integration, but whether it can keep pace with five schemes evolving independently, indefinitely, without a team dedicated to just that.
This is the problem Global Payee Verification was built to remove, not just work around. One API routes a payment across every scheme we support and fails over automatically if one is unavailable - a bank plugs in once, not five times. The name-matching, the interface language, the case-management workflows are configurable to how a bank already operates, not a template it has to grow into. And because it drops in as SaaS or on-prem, on top of the existing core, a typical integration runs in weeks with a developer sandbox, not the multi-year programme a from-scratch build would require. The fastest path to keeping up with five moving schemes isn't owning all five relationships in-house.
The €20–60 it costs to handle a misdirected payment doesn't change based on the size of the bank absorbing it, but the resources available to prevent it do. A cross-border payments system only meets the G20's goals once the smallest bank on the network can meet them as easily as the largest. That's not a technology question anymore. It's a question of who modernization is actually designed to include.