ISO20022 messages are like teenagers.
They’re new and loud and need attention and monitoring.
And while they may all look quite similar they all have their very own problems.
But most important, they are our future.
So lets get to know them a bit better.
Scope of complexity
ISO20022 complications begin with names.
MX and ISO20022 is often used as synonym however there is a destinction. ISO20022 defines an ISO standard. The MX Messages are in fact a subset of SWIFT defined and owned ISO20022 messages. This is similar to ISO15022 and FIN messages.
Message types
It is important to note that only the full xml namespace uniquely distinguishes ISO20022 messages. (urn:iso:std:20022:tech:xsd:sese.024.001.03)
Sources for these definitions are the iso20022.org page or SWIFT MyStandards.
Services
Services are used on the SWIFT Network and define a collection of ISO20022 messages for a specific business area (swift.if.ia specifies FUNDs messages). Customers can register their own services on the swift network (vp.services was registered by VP Securities of Denmark). This is required because many ISO20022 messages do not currently have a service via which they can be sent over the Swift network in. (All messages may sent via FileAct of course)
Message Structures
ISO20022 messages are generally sent as Document and Header pair.
A service on the SWIFT network defines not only the ISO20022 messages to use (these are stored in the document section) but also specify a header section. Currently two headers are used. $ahv10 and head.001.001.01
A business message for T2S or for FUNDs, sent via the SWIFT network, must include the correct header.
However the header and document are actually two separate messages which are on the same level. As such they need a surrounding XML envelope (wrapper) to become valid XML.
Addressing and Envelopes
Example logical mapping of the old ISO15022 and the new ISO20022 messages in regard to network information such as sender and receiver.
Please note that the ISO20022 message document section does not contain any of this information with the exception of an ID. (There are plans to move the ID to the header section)
The header section defined by the Services contain From and To but these do NOT contain the network sender / receiver information equivalents to the BICs in the ISO15022.
This means that there must be an additional envelope surrounding the payload header and document which also contains the sender and receiver information. The envelope is however NOT defined by any ISO20022 standard and is specific to the various network interface software vendors (SAA, SAG, T2S Connector, WBIFN, SIA Colt, all have different envelopes.)
Variations in T2S service
In T2S the header element to use is the head.001.001.01. The T2S guidelines also specify the exact fields to fill and expect in responses.
The T2S service specifies a list of over 100 ISO20022 messages. Although T2S uses ISO20022 based messages these are not available on the ISO20022.org website. They are instead published on the MyStandards platform from SWIFT.
Network Connectivity
There are multiple options to be exchange ISO20022 messages as these do not mandate any specific network. However some services such as the new T2S platform in Europe dictates a clear network interface along with the messaging standards
T2S network specialties
T2S direct connectivity is provided via SWIFT using the T2S connector option of the SAA software or via SIA Colt, using their SI connectivity Software.
In case of the SWIFT T2S connector, no envelope is used in the data communication. This means the data sent via MQ queue is NOT XML valid and needs special handling before XML parsing can begin. Sender and Receiver information must be passed to the interface inside an RFH2 header (this is a special IBM MQ queue storage section which is passed along with every sent message)
The RFH2 header also contains the routing and ID correlation information and is specified in the SWIFT T2S Connector documentation
T2S processing pitfalls
There are a lot of possible problems with implementing T2S connectify many of which are generic to processing ISO20022 messages. Here a small list:
Fileact monitoring. (Via admi response messages) The T2S connector bulks some messages into files before sending them out. It can be important to know which messages belong to which file as T2S will send responses to the Fileact and this must then be correlated to all the messages contained in the bulk.
Sequencing, T2S messages are sequenced. However Fileact deliveries be take a while to unpack on the T2S connector. This means other messages can overtake and the middleware may need to resequence.
Validation, Messages defined in T2S sometimes contain additional messages embedded inside the document which can make handling and validation tricky.
T2S connector sends data over MQ using MQ segmentation. This requires software capable of handling segmented data to correctly process the information.
Large messages
Very large reda.012 reports are common in T2S messaging. These can be maximum 100MB and in implemented projects we routinely process multiple > 30MB mesages every day.
It is important to have parallel processing streams setup for ISO20022 message handling to ensure that single big messages do not block the high speed processing channels that should be in place for all new query response messages.
These large messages also have a big impact on data storage and on the required settings of your messaging infrastructure such as Databases, MQ Queues etc.
Conclusions
- Shield internal applications from external message formats via middleware
- Consider sequencing. Ideally solve this in the target application
- Split processing into multiple channels to handle large messages
- Consider implementing monitoring
- Build up ISO20022 experts.
- Define an internal messaging wrapper for ISO20022