From my experience, once you start working in the financial sector as an engineer, you have to learn a lot of acronyms and popular keywords in the industry quite quickly. So you could get on the same page with the business users or product owners while discussing the requirements. Also, it’s unusual for an engineer to be in an environment where he is not the one saying all the magic words. Jokes aside, in this post, I will try to summarize and explain the critical aspects of the Swift ISO 20022 Financial Standard in an understandable way for a software engineer, who might not have financial services experience, but would like to learn more. This post might also serve as a seed for the Swift standard/financial services blog post series, which I am thinking of writing.
What Are The Financial Standards?
To start at the very beginning. What are the financial standards? Financial standards are the glue which holds financial services together. Keyword standard means that it defines a structured model which allows data of financial transactions (covered by the standard) to be shared via various channels (API calls, messages, etc.) by all parties who understand that structured model.
There are many different standards in financial services. Which differ by geographical locations and areas of business they are covering. A big part of financial institutions even has their separate standards for internal use. Having so many different messaging formats in place causes much trouble when for example, funds need to be transferred from one geographical location to another or money from your Current account to your Foreign Exchange account to invest in some foreign currency (Zimbabwe Dollars?). An analogy of the issue in the Software world would be having a lot of services that “talks” in different APIs. To help the Services to understand the information being sent to each other first we would make sure all of them use the same syntax/structure. Unless the reader understands a specific syntax, it’s impossible to understand the message content.
In ISO 20022, the most common syntax is XML. Despite that, even if all the parties involved use the same syntax, another potentially more troublesome standardization issue exists. The receiver has to know the meaning of the content in the message. Different business domains or countries have developed their message definitions over time. In which other parameters might have the same concept, or worse, the same parameter could have different meanings. A good example is given in ISO 20022 documentation: “In the payments industry, an Ordering Customer in one country can be called Payer or Payor in the other one”. I guess there is no need to explain this issue further as every engineer in his career saw a bad API or an Object design where an Id or a Name means different things. Imagine the costs and effort involved in making the changes when an object definition issue like this occurs between the two big banks. Helping financial institutions avoid these issues is a driving force behind ISO 20022 standard.
SWIFT and ISO 20022
In short – SWIFT is a company/organization, and ISO 20022 is a financial standard they develop to make the lives of financial institutions easier all over the world. A lot more information and the dates with the milestones for each business domain under the standard (which I don’t think is relevant in this context) can be found on the SWIFT website. Where SWIFT also offers tools and services for developers of ISO 20022 content.
ISO 20022 Benefits
Now that we know who is who, let’s take a better look at the value the ISO 20022 brings to the industry.
Business Processes and Concepts
The standard enables users to map the business processes utilizing the provided XML message definitions, and then the data model describing the whole process (for example, Request to Pay) can be used to do the automation, and create the programable interface. Once the process is mapped out, the components describing it can be reused across all the messages. Let’s take a better look at the “Request to Pay” definition from the Payments catalogue.
As shown in the diagram “Request to Pay” (RTP) process is constructed from two sub-processes: Creditor Enrolment and Debtor Activation. The documentation clearly describes both processes, but for example, we will analyze only the Creditor Enrolment process.
Diagram from ISO 20022 documentation.
Creditor Enrolment process details as per documentation:
| Item | Description |
| Definition | The enrolment is initiated by a Payee/Creditor via its Request to Pay providers to distribute in the RTP eco-system the information about the enrolment (registration) of this Payee/Creditor. |
| Trigger | Creditor decides to support the request-to-pay for Request to Pay. |
| Pre-conditions | The required (enrolment) information is available to initiate the enrolment. |
| Post-conditions | The Creditor is ready to send request-to-pay messages to any Debtor who has activated the service. |
| Role | Creditor |
Also, documentation provides a list of message definitions tied to the process and schemas where they can be found:
| Message Definition | Message Identifier |
| RequestToPayCreditorEnrolmentRequest | reda.066 |
| RequestToPayCreditorEnrolmentAmendmentRequest | reda.067 |
| RequestToPayCreditorEnrolmentCancellationRequest | reda.068 |
| RequestToPayCreditorEnrolmentStatusReport | reda.069 |
RequestToPayCreditorEnrolmentRequest from reda.066.001.01.xsd
.....
<xs:complexType name="RequestToPayCreditorEnrolmentRequestV01">
<xs:sequence>
<xs:element name="Hdr" type="EnrolmentHeader2"/>
<xs:element maxOccurs="unbounded" minOccurs="1" name="CdtrEnrlmnt" type="CreditorEnrolment3"/>
<xs:element name="ActvtnData" type="CreditorInvoice3"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="SplmtryData" type="SupplementaryData1"/>
</xs:sequence>
</xs:complexType>
......
I hope now you see the benefits of ISO 20022. Standard provides really good documentation for each process in the catalogues. So as developers if we have a business case we could find the mapped-out process in the message definition catalogue, learn how it is mapped, find the XSD schema and create an API to run the operations utilizing schema for the process.
Reusable Components
Reusability is one of the favouring topics among software engineers while designing a new piece of functionality, and ISO 20022 enables reusability at its core. Once the process is mapped out, the components describing the flow can be reused globally. For example, the component ‘PostalAddress’ can hold the value of an address in a credit transfer, a credit card payment or a foreign exchange transaction. This enables the users to create new messages more straightforwardly and faster as the building block can be reused. Or let’s take a “Request to Pay Creditor Enrolment” process again RequestToPayCreditorEnrolmentRequestV01 element is reused three times in its main schema reda.066.001.01.xsd alone.
Benefits of XML Syntax
This one is a bit controversial for me, as I’m not a big XML fan, because of its clunkiness. What can be easily described in JSON takes way more space and time in XML, but looking into it from the perspective of poorly structured messages which were and still are so popular in the financial space and strict audit requirements of the financial industry. XML syntax feels like magic, easy to automate and human-readable what else could we dream of?
Where is ISO 20022 Used?
ISO 20022 is widely used across key areas of the financial sector:
- Payments
- Cards
- Funds
- Securities clearing and settlement
- Forex
- Trade
- Global cross-border payments (By the end of 2025)
Listed financial domains have a catalogue of messages provided on the ISO 20022 website and they can be used to implement the ISO 20022 standard to satisfy your business needs or curiosity, and if intended, any organization can develop a new ISO 20022 catalogue or extend the existing one too. There are specific rules to be followed. Also, valid business justification will have to be defended against a committee. But capabilities are there.
Conclusion
I hope now you have a better picture of what financial standards are. What is ISO 20022 standard, who is developing it and what benefits does the standard brings to the table. I think it’s a big step forward as ISO 20022 opens up many automation possibilities, makes the overall development more accessible by introducing reusability, helps to comply with audit requirements and is error-proof compared to legacy standards.
Leave a Reply
You must be logged in to post a comment.