Headers in ISO20022 messages appear to be a confusing matter. This post intends to bring some light into the matter.
As is well known, the ISO 20022 and SWIFT MX messages require both an AppHdr and Document section for a valid message payload.
The following pictures illustrate that the sender and receiver information used by the SWIFT network is not contained in the message payload but instead must be placed in a message wrapper.
Please note that the Interact Request wrapper used here is proprietary to the SWIFT Network and should not be used for internal message transportation due to legal and versioning issues.
The information shown in the following pictures was compiled from multiple sources including SWIFT, IBM and Incentage. All information from these sources is legal property of the relevant owners.
While care has been taken I can take no responsibility for correctness of the data and strongly advice for actual implementation to use the xsd schema definitions for all the described messages.
Please note also that the pictures focus on the fields of interest and do not take into account all possible mandatory fields or field restrictions as defined by the XML schema or relevant service rules.
The single most important point of confusion surrounding the use of the MX / ISO20022 headers is the fact that the To and From elements are not an equivalent to the LT address and Correspondent address defined within the ISO15022 FIN messages. These network addresses must be provided outside of the business payload within the wrapper.
The To and From blocks are in fact optional elements of the original ISO20022 headers.
The ISo20022 messages are currently in productive use with a variety of message headers. Currently active on the SWIFT network in the Funds service (swift.if.ia) is the SWIFT proprietary $ahv10 header with optional From and To elements. Newer ISO20022 based message services mandate the use of the official ISO20022 Business Application Header (BAH). While this has mandatory Fr and To elements the schema still allows for large variations therein
As established above the network addressing is not handled by the ISO20022 or MX standard headers. This is left to the network wrappers which carry the header and document elements as payload.
These containers are called wrappers or envelopes and are proprietary for each networks and the software used. For example SWIFT Alliance Access (SAA) uses a DataPDUV2 wrapper while the SWIFT Alliance Gateway (SAG) used an Swift Interact Request for interact messages
The transport of the Headers as part of the payload is defined by the Swift network however this does not specify how the information is to be passed to the network gateway software. In the example of the IBM Swift Gateway, WBIFN, the header elements are placed in an MQ message RFH2 header leaving only the Document element as message in the MQ payload
While the ah$v10 is currently in productive use in the FUNDs service, the BAH is the header of choice for all newer services registered on SWIFT.
Implementation of the headers in has proven to be effort intensive causing reluctance in the market for further changes. However clear deficits have been identified and are being addressed in ongoing SWIFT usergroups.
In addition to planning for BAH enhancements some markets have decided to integrate the required data from the header messages into variants of ISO20022 based documents. As example in SIC4 the swiss market has defined proprietary variants of ISO20022 payment messages which are self contained with all the header fields included in the Document element.
There is a need in the market for a wrapper that can be used to hold both Header and Document in the payload and allows for the required address information and network specific details to be handled without licensing restrictions. While this should obviously be something that is internationally agreed no and published on ISO20022 you are welcome to download a license free example of such an envelope here: transportwrapper-v04_2_schema
