ISO20022 is a highly structured and data-rich financial messaging standard that will replace the existing SWIFT (ISO 15022) system. The New Payments Platform (NPP) was built using ISO20022 messaging schema.
The general features of the ISO 20022 standard are:
- Open standard – the message definitions are publicly available from the ISO 20022 website.
- Flexible – definitions can be adapted for new requirements and technologies as they emerge.
- Enhanced data content – ISO 20022 messages have an improved data structure (e.g. defined fields) and expanded capacity (e.g. increased field size and support for extended remittance information).
- Network independent – the adoption of the standard is not tied to a particular network provider.
It was created to give the financial industry a common platform for sending payments messages and exchanging payments data
Global adoption of ISO 20022 will create a common language and model for payments data. It will provide higher quality data which translates to better quality payments for everyone in the financial industry, with an open standard that can adapt to changing needs and new approaches.
Using modern, mainstream XML technology ISO 20022 will:
- reach every market infrastructure and payments system to pave the way for more efficient integration.
- Improved analytics, requiring less manual intervention and will
- result in a more accurate compliance process, improved security and fraud prevention.
It improves liquidity management by providing a new level of financial communication. The ability to capture more data in a uniform way, it enables the adoption of data analysis solutions and added value services that can provide customer insights and generate new revenue streams for banks, for example Request to Pay and e-invoicing.
ISO20022 definitions are captured in a highly structured model, which can then export those definitions to developers and users of applications, screens, messages, API calls and any other data representation that needs to speak the language of financial transactions with clarity and precision.
Syntax and Semantics
Financial institutions agree on how to organise the data they want to exchange in structured formats (syntax) and meaning (semantics). Based on such message definitions, they will exchange messages, as illustrated by the following extract of a simple payment instruction.
<CdtTrfTxInf>
<IntrBkSttlmAmt Ccy=‘USD’>12500</IntrBkSttlmAmt>
<IntrBkSttlmDt>2022-04-06</IntrBkSttlmDt>
<Dbtr>
<Nm>ACME NV.</Nm>
<PstlAdr>
<StrtNm>Amstel</StrtNm>
<BldgNb>344</BldgNb>
<TwnNm>Amsterdam</TwnNm>
<Ctry>NL</Ctry>
</PstlAdr>
</Dbtr>
<DbtrAcct>
<Id>
<Othr>
<Id>8754219990</Id>
</Othr>
</Id>
</DbtrAcct>
<DbtrAgt>
<FinInstnId>
<BIC>EXABNL2U</BIC>
</FinInstnId>
</DbtrAgt>
</CdtTrfTxInf>
The above example is an excerpt from an ISO 20022 Customer Credit Transfer in the XML syntax.
Syntax
The syntax is the format in which the information in a message is structured. Unless the reader understands a specific syntax, it’s not possible to understand the message content. There’s a lot of confusion about the difference between a standard and a syn- tax. The standard describes the agreement on what information is expressed, while the syntax is the format, or the ‘language’ used to express that information.
In ISO 20022, the most widely used syntax is eXtensible Mark-up Language (XML). The use of short tag names (like to represent a postal address) is also part of the syntax.
Semantics
For example, what some players in the payments industry call an Ordering Customer, others refer to as Payer or Payor, while still others talk about a Payment Originator or Initiator. The con- text also plays a role here: the Payment Originator/Initiator is a Debtor/Payor in a credit transfer, while that Payment Originator/ Initiator is a Creditor/Payee in a direct debit. These different names create difficulties when you’re looking at end-to-end integration
ISO 20022 is the agreed methodology used by the financial industry to create consistent message standards across all the business processes of the industry.
ISO Layers
The ISO 20022 method is based on the concept of separate layers. We distinguish between three layers:
-
the top layer provides the key business processes and concepts;
-
the middle layer provides logical data models and flows; and
-
the bottom layer deals with syntax.
Top Layer: Business Processes and concepts
-
there’s a distinction between the business and the way it’s represented in a message, that is, the syntax.
-
The ISO methodology starts with the creation of the business model: i.e. the definition of the activity or business process, the business roles and actors involved in that activity and the business information needed for the activity to take place.
-
The business information is organised into business components containing business elements. For example, when looking at the processes involved in a credit transfer, key notions such as debtor (the party that pays), creditor (the money receiver), debtor agent (the bank of the debtor), creditor agent (the bank of the creditor) and payment are identified. These in turn have inner layers.
-
a simplified business information model, represented in Unified Modeling Language (UML).
- Central is the payment itself, which is associated with the debtor agent and creditor agent, which are both financial institutions. The payment is also associated with a debtor and creditor, which are both parties (in other words, persons or organisations, finan- cial or other) which, in turn, have elements such as a name and address. Additionally, these parties may be owners of an account. Behind these elements lie further details. A payment, for exam- ple, contains elements such as currency and amount, a requested execution date and settlement date, and remittance information.
Middle Layer: Local messages and API resources
-
Using the business concepts, ISO20022 defines logical models which make up the middle layer.
-
A logical model is a description of all the information that’s needed to perform a specific business activity, independent of syntax.
-
It’s composed of message or data components organised in a hierarchical structure. A component contains one or more elements and is derived from a business component by using one, some or all of its elements. The logical structure for the excerpt of the Customer Credit Transfer message can be seen:
-
CreditTransferTransactionInformation could specify an API resource instead of a message. In a later step, API resource actions can then be specified to manage the credit transfer resource (for example, create the credit transfer, change it, view it and so on).
Bottom Layer: Syntax
-
The syntax is the physical representation of the logical model. ISO 20022 uses XML and specifies how to convert a message model to XML.
-
ISO 20022 uses XML and specifies how to convert a message model to XML