Community
ISO - International Organization for Standardization, is an organization based in Geneva that creates standards for goods and services, including transactions. They can also be viewed as a glossary of terms that can be edited by the members. The structure is similar-ish to NACHA but international.
ISO 20022 is a communications standard used by Financial Institutions to pass messages to each other about a payment. Introduced in 2004, it is used for large transactions because the format allows for a lot of data to be included but it is becoming widely adopted globally.
ISO 8583 is a communication standard introduced in 1987 and is mostly used for card-related transactions. This format allows less information to be included with the payment and is being replaced by ISO 20022.
STP - Straight Through Processing is a mechanism that allows a payment to go from initiation to settlement with 0 human intervention. The ultimate goal of better communication systems (like ISO 20022) is to achieve the true STP status.
ISO 8583 can be thought of as morse code: simple and to the point but lacking details and open to interpretation that results in human intervention being required.
ISO 20022 can be thought of as a 10 page essay that covers all edge-cases and leaves nothing to interpretation. Rarely requires human intervention.
Going through this whole article can help you better select your payment processing partners, payment rails and support you in negotiations.
ISO issues hundreds and thousands of standards for all kinds of fields like Steel, Photography, Cement and of course, payments - like ISO 20022. The payments standards is what I’ll talk about in this article.
It is one of the most well known ISO numbers in payments. In a formal definition, ISO 20022 is a “multi part International Standard prepared by ISO Technical Committee TC68 Financial Services.”
The whole point of my writing is digesting things like this 👆 into something more understandable. SO, in simple terms: ISO 20022 is a communication standard used by FIs to pass messages to each other about a transaction. ISO 20022 is used to pass information about payments like FedNow, RTP, Fedwire, SWIFT wire and some card transactions.
Before I go further into the technicalities, I want to make sure you actually know how to pronounce this so you can use it in a conversation. ISO 20022 is pronounced by knowledgeable people as [eye-so-twenty-oh-twenty-two].
Back to the technicalities. ISO 20022 has introduced a new method of “tagging” information, rather than using free text format used in older standard of ISO 8583. This means that rather than using free text, you would input codes that would represent a specific feature you are trying to describe.
For example, in the older formats, to pass the information about the sender’s address, normally you would use a 3-line method with character limit of 35 per line. Like so: 10 Chapel Drive, (Line 1, 35 character limit) Los Angeles 91607-71029 (Line 2, 35 character limit) California (Line 3, 35 character limit)
With ISO 20022 the input would look verrrrry different, like so:
As you can tell, the input options are far broader than those presented by a standard 3-line method. And here lies the beauty of ISO 20022 - data richness. More input options presented → more edge-cases covered → less failed payments → faster fund delivery → cheaper maintenance of the system allowing for the true STP (Straight Through Processing).
The whole point of ISO 20022 is how data rich it is and how many edge-cases it covers. It would be easier to say what is not included in these messages, but here are some key elements that can be included in the payments message that utilizes ISO 20022 standard:
Unique ID for the payment and creation date of the said payment. Helps with tracking each payment and keeping things organized.
Originator’s information: Financial Institution that is processing the transaction for the payor, includes name, address and BIC (Bank Identifier Code). Screenshot below shows examples of information that can be provided for this section:
Payor’s information: the person or entity that is going to actually pay on the transaction. Includes name, address and account that will be debited.
Payee’s information: the person or entity that is actually receiving the payment. Includes name, address, contact info and account that will be credited.
Amount and currency. Self-explanatory.
Payment type/Transaction code: describes which rail is involved (RTP, Wire etc.) and covers what the payment is for.
Settlement instructions: settlement system selected (RTGS, DNS or other country-specific choice), operator that will be doing the clearing, settlement date etc. IF you don’t understand the sentence above, I highly encourage you to read my article about US interbank payments ecosystem. Yet another screenshot from the documentation that shows the information included in an ISO 20022 message and some definitions:
Fees involved: covers who owes who and how much for processing this transaction.
The list goes on and on and on but I believe these are the key pieces of information included. It is important to remember that the information above is included in most other messaging standards like ISO 8583, but ISO 20022 is MUCH MUCH richer. So, when you think ISO 20022, think - I can write a book through the tags included in the payments message.
ISO 8583 is an old payments communication system introduced in 1980s that allows minimal information to be passed quickly. It is predominantly used by card networks and for card-related transactions. Networks like Visa and Mastercard continue to use ISO 8583 for their card authorization messages. It is because this format is much simpler than ISO 20022 and requires less input which minimizes risk of a declined transaction but also limits fraud prevention and increases the number of false positive fraud blocks. It is a double-edged sword, that, I’m sure, will be replaced with ISO 20022 with the further adoption of solutions like Account Funding Transactions (AFT) and others that can allow larger transactions to be initiated via a card. I have been in payments for only about 3 years and absolutely do not have the expertise to speculate on this further.
ISO 20022 is data-rich system that was introduced in 2004 that allows a lot more information to be passed through but is currently predominantly used for the larger sized transactions.
ISO 8583: There are two warships going through the ocean. One of them spots a potential enemy and wants to communicate that to their ally. They send a morse code message “Potential enemy ahead, alert” and sends it off. The ally ship will quickly understand the message and be ready - more or less.
ISO 20022: Same scenario, but now instead of 4 words, our protagonist sends their ally a 10 page report sharing all the data on the spotted enemy. Distance, perceived size, current speed, position related to them and related to the ally, protagonist’s current distance from the ally, available arsenal onboard of the protagonist, number of people on deck etc.
You get the point (hopefully). And probably see why I believe that ISO 20022 will be replacing ISO 8583 for card-related transactions as well. The card networks ought to get adjusted to read the “10 page reports” rather than morse code messages. We have the tech for this, it’s just the question of implementation.
It may sound like something that was introduced in the recent few years but in reality ISO 20022 has been around since 2004. It in itself is ancient but not nearly as ancient as the older systems used.
Specific rails only operate on ISO 20022 messages, like RTP, FedNow, SWIFT wires and therefore it is widely adopted by the banks involved. It is also adopted by the operators that process the payments: TCH, CHIPS and Federal Reserve.
Here is the rough timeline of its introductions:
In the beginning, I mentioned that this information is mostly for your general understanding of the payments ecosystem, but it might come handy. Here are the key ways to utilize it:
Ask your provider if they are “ISO 20022 compliant”. This just means that they are capable of accepting this messaging standard and by default if a PSP offers specific rails like FedNow or RTP - they are ISO 20022 compliant. The real test here is to see if they even understand your question. If they don’t, you might be speaking to the wrong person or company altogether.
Selecting payment rails used for your operations. Now you know that most card-related transactions aren’t using ISO 20022 as well as some legacy rails like ACH and a few other rails outside of the US. It might be worth checking what messaging system is used for the rail that you’re considering adopting.
General education. You are now officially and ubiquitously more knowledgeable about the payments space than you were 5 minutes ago. Mmmmm feels good, doesn’t it?
Contract negotiation with vendors. The more knowledgeable you are, the more likely you get favorable terms from partners in all fields. This, of course, applies to payments as well.
Name-drop ISOs. Going back to the previous point, you can use your newly acquired knowledge to impress colleagues, partners, providers, your significant others (they love listening about payments) and anyone else who needs to be impressed with your immense knowledge of the payments space.
The screenshots that I’ve shared earlier are a tiny glimpse into the depths of the documentation I’ve used for this article. More specifically, it is 784 pages long. If you want to see the full report, you can find it here and search based on the specifics that you’re interested in.
Article by Digital Transformation that covers the transition from older messaging formats to ISO 20022, can be found here.
Article by Checkout.com explaining ISO 8583 further can be found here.
See you all in the next article and don't forget to follow my Substack where these posts come up first: https://aftfinance.substack.com/
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Sam Boboev Founder at Fintech Wrap Up
23 November
Paul Weathersby Chief Product Officer, Identity & Fraud at Experian
21 November
Viacheslav Kostin CEO at WislaCode Solutions
John Reese Business Analyst | Platform Growth Expert at Hashcodex
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.