ISO 20022: Worth the risk?

What has paralyzed progress in the U.S. on the global standard for financial messaging, ISO 20022? In a word: risk. Across Europe, 20 financial organizations have already gone live with payments messaging services that meet the standard, thanks largely to the E.U.’s Single Euro Payments Area (SEPA) requirements that make not supporting ISO 20022 a risky option. But in the U.S., with tens of billions of electronic payments each year — and a decades-old system that works reliably — banks, payment networks and the Federal Reserve have been in no rush to put that system at risk with big changes.

U.S. banks say there’s no customer demand for ISO 20022 and its ability to link transaction details to payments. Financial networks don’t see a need to go with an international standard, when offering proprietary formats will keep the risk down. And the regional Federal Reserve banks — who have just unveiled a plan to combine better payments messaging with real-time settlement and security improvements in a major overhaul of payments infrastructure — say that overhaul will take years to complete, and even longer to become profitable for banks and networks.

But for the businesses that actually make the electronic payments, there are risks in pushing ahead to meet the new standard, but other risks in getting further behind trading partners in Europe and the rest of the world with continued foot-dragging.

And those risks are within the businesses themselves, at the financial network level, and across the whole financial system.

For most large businesses, the easiest way for to make the shift to ISO 20022 is to get an upgrade from the business’s ERP vendor. Thanks to Europe’s five-year lead, major vendors are on top of the problem, including making sure their systems all talk to each other — which cuts risk.

But many big U.S. businesses have customized standard ERP software to match their business processes. That creates the risk of creating unexpected interactions with any changes the ERP vendor makes. Those risks are higher for businesses that haven’t kept up with upgrades, and who will have to jump versions to get to one that reliably supports ISO 20022 — but will first have to be customized all over again.

On the other hand, some businesses may try to implement their own ISO 20022 financial messaging software, either on top of an ERP system or their own legacy accounting software. Generating and parsing XML messages really isn’t that difficult; the risk comes in not being able to exhaustively test to make sure that homegrown software (or products from smaller vendors) will interoperate properly with other ISO 20022 implementations to reliably exchange payments messages with business partners.

At the network level, why can’t NACHA and other payments networks just add ISO 20022 messaging so that all its users can make the transition when it’s convenient to them? Aside from the expense — which NACHA would have to pass on to customers — NACHA’s reliability and stability come largely from the fact that the four-decade-old network has four decades of experience doing what it does, and virtually none handling ISO 20022 messages.

In addition, shifting the risks to a major network like NACHA centralizes those risks. One major problem could bring down both the ISO 20022 messaging and traditional ACH messaging for every business that uses the network.

NACHA’s risk in not moving toward the new standard is that some startup could pick up the ball and run with ISO 20022. Appealing as that may sound for businesses, even a startup with lots of expertise in ISO 20022 probably doesn’t have enough experience in the high traffic volumes that any new infrastructure will have to be designed for — raising the risk of downtime or that messages could be corrupted, misdelivered or delayed.

And a major network infrastructure upgrade, like the one being considered by the Fed, is a risky project just because it’s so large in scope. Big technology projects fail far more often than small ones, and projects with multiple goals are riskier than tightly focused projects with a clearly understood endpoint.

The Fed’s idea of using real-time transaction clearing as the big benefit, to counterbalance a less-appealing security upgrade and ISO 20022 implementation, is probably the most politically viable (and least politically risky) way to do it. But technically it’s the approach that’s most at risk because of the size and complexity of the project.

Then there’s the risk that money spent on a changeover to ISO 20022 could fail to produce a return on investment in a reasonable time frame. In practice, that’s almost a certainty under the Fed’s plan, which estimates that new payments network infrastructure to support ISO 20022, real-time transactions and other key features won’t turn profitable until 2025.

The rule of thumb for all technology projects is that the longer you wait, the less cost and risk there will be. The rule for business projects is that timing is everything: too early and you risk a long wait for payoff, too late and you risk lost opportunities because you’re not ready.

Because SEPA has kick-started ISO 20022 in the Euro zone, we have some idea of how transactions will ramp up. But Europe’s past experience doesn’t guarantee future results for the U.S. and other slow-to-get-on-board trading partners.

It also can’t eliminate the risk that a business will suddenly need ISO 20022 capability because a big customer has set a time line for ISO 20022 implementation that’s earlier than the business’s own time line. U.S. suppliers have been through this before in financial messaging with EDI, and in other areas such as UPC barcodes and RFID tags.

Failing to meet a big customer’s requirements risks payment penalties or even a loss of the customer. At that point, the biggest ISO 20022 business risk becomes the risk to profits.