ISO…So What?

Financial messaging formats and standards have progressed in sophistication along with the computer age. Believe it or not, banking has actually been one of the biggest drivers of interconnected computer systems technology (yes, the internet). ISO 20022 standards are a next step in better interoperability. But, why should you care? In some respects, diving into the details of financial messaging standards is like the driver of a car knowing the size of the tires or viscosity of the oil. Interesting for the enthusiast, necessary for a mechanic, but not very relevant to actually driving the car and getting from point A to point B. In fact, most drivers go their entire lives not knowing either of those things.

So, while it’s important for finance and accounting professionals to know something about the ISO 20022 standards and implementation, it’s more important to understand the big picture -- why the standards are important and why they matter to you. Otherwise “ISO 20022” becomes little more than a meaningless buzzword that eats a sizable chunk of you budget and delivers little to no additional value. So, let’s start from the beginning and get some straight forward answers. The marketing definition of “ISO 20022” is “a single standardization approach (methodology, process, repository) to be used by all financial standards initiatives.” That definition is sufficiently vague to allow the reader to assign all kinds of details and benefits to the broad topic of ISO financial messaging standards first published in December 2004.

What is ISO 20022?

A flexible format for financial messages The current set includes message types for payments, securities, trade service, FX, card, ATM management, bank statements and account service, among others.

XML (eXtensible Markup Language) This is the latest preferred syntax by developers, even described as “de facto” technical standard for electronic communication.

The next step to bank and clearing system interoperability If you have a project that requires financial messages, you should go with the latest and greatest, as long as your bank supports it and it fits the need.

A technical standard used to accelerate new payment schemes and the modernization of legacy payment schemes Some schemes are being created from the ground up, like SEPA or payment systems in emerging economies. Others are initiatives to modernize legacy mainframe, paper-based or client\server processes that are crumbling under the modern digital economy.

A cost-effective method for some new implementations The market is flush with tools and technology partners to help make ISO 20022 implementation easier and faster.

What ISO 20022 is not:

A clearing system While certain clearing systems use ISO 20022 as input, that’s all it is: data.

A global unified standard for financial messaging That’s right: not. There is interpretation and variety in the wild (read The ISO 20022 “Standard” below).

A cost effective replacement to existing standards, like NACHA Despite initiatives from NACHA, there is no reason for ISO 20022 payment messaging to replace tried and true, in-place protocols like the NACHA format. NACHA is already ingrained in almost every system that does US domestic payments. NACHA already has the structure for including virtually unlimited remittance (the ability of the format to include remittance is not the limiter). And including an ISO 20022 payment message inside a NACHA CTX is just complication with the pretext of progress. Replacing NACHA would cost billions and not delivery any additional value. The same argument can be made for retention of other existing mature formats that still meet a business need.

The ISO 20022 “Standard”

While XML (and ISO 20022) is built on better technology and is a better file structure, it is still just another standard; a format that is meant for computers to talk back and forth. In this respect, it is similar to a simple text file, CSV, EDI or BAI file. As long as both end points agree on the structure, everything works. You might be thinking, “wait, wasn’t the whole idea to create a global standard for financial messaging”? Yes, mostly. We have to consider the loftiness of that goal and if it’s actually possible. When trying to make one tool for all financial messaging, you might end up making a very, very, very complicated tool that still is not fit for every use. The framers know this. That is why at the heart of the ISO standard is an attempt to create a common language or dictionary that would be used by everyone. But there is still flexibility on how it would be implemented -- from bank to bank, from country to country, from clearing system to clearing system. Some fields and branches are used where others are not.

Other differences includes code words and field modifiers. We’ve all heard the saying “Standards are great, everyone has one.” Previous attempts suffered from this as well. For example, EDI implementations vary from bank to bank. Even the tightly controlled SWIFT MT FIN messages have a variety in the wild, from the use of optional fields to the “free-form” MT 199. ISO 20022 is beginning to be affected by the “in the wild” implementation variety as well. ISO documentation is sprinkled with poisonous words like “unstructured data” and “bilaterally agreed” fields. It either takes continuous coding and development to account for the built-in flexibility inherent in ISO 20022 messages or, more likely, just create a separate map, branch, format etc. for each variation. Otherwise each slight change would require extensive testing of everything all over again.

Why you shouldn’t care about ISO 20022 

“If it ain’t broke, don’t fix it” Don’t initiate a costly project to implement ISO 20022 unless you are implementing something new – a bank, country, TMS, ERP or payment hub. Proven methods like NACHA, BAI or EDI should not be up-ended unless there is a clear business reason and value. That would be like tearing up all houses built before the turn of the century because building codes and materials are better now.

ISO 20022 is a tool not a solution You only use tools when you have a project. Don’t create a project just to use the new shiny tool.

XML is just a format Let the developers worry about the best format and syntax to use. It's not relevant for the day-to-day of a treasury, finance or accounting profession. Remember, your job is just to drive the car, not worry about the viscosity of the oil.

It involves another set of expensive expertise Just as organizations wince under the weight of having on-staff SWIFT or EDI experts, ISO 20022 has a steep curve and it’s potentially even more complicated. Instead of investing in an ISO20022 specialist, find a technology partner or bureau that makes that layer invisible. Just as you don’t need to know how IP addresses work to use the internet, you shouldn’t have to know the details of an ISO 20022 pain 001.001.05 (or .02, .03 or.04) message to send your bank an STP wire.

Why you should care about ISO 200221

ISO 20022 messages are better than the alternatives Simply put, XML is a better file structure. It allows for more rapid integrations at a lower cost. It also gives some measure of future proofing, at least for now.

It can provide ROI and business value No project should start with the goal of implementing ISO 20022. That is effort and money wasted for the sake of making the developers happy, but in itself, delivers little to no ROI or business value. Instead allocate budget on projects that increase cash visibility, bank interoperability, payment STP, reduce manual operations and have better audit and compliance. If ISO messages help achieve those goals, then use them to achieve business value.

ISO 20022 is a potentially useful tool for the treasury and finance toolbox, one that may or may not be of benefit. Arm yourself with the information you need so you’ll have confidence to choose the solutions that are of actual benefit and discard the ones that are just buzz. Jamie’s 15+ years of B2B payment experience has spanned numerous roles focused on helping organizations simplify their corporate payment and accounts payable systems. He is a frequent speaker at customer forums and industry conferences and is currently a Senior Solutions Consultant with Bottomline Technologies.