Understanding the new 2019/2020 ISO 20022 pain.001 message version

The ISO 20022 pain.001 message is widely used for corporate to bank payments. To date the most prevalent version of the ISO 20022 pain.001 message has been the pain.001.001.03, or version 3, released in 2009 and first brought into widespread usage as a result of SEPA in Europe. But adoption of the new version 9 of the pain.001 message from 2019-2020 is growing. 

Adoption of pain.001 version 9 is especially likely in markets where new payment market infrastructures are being deployed e.g. in Canada and the Nordic region. For corporations and banks long used to working with version 3 of the pain.001 message, it is useful to consider the differences between the versions carefully.

Here, we explain the main differences in pain.001, between:

• version 3, and
• the newer version 9, from 2019-2020.

The Namespace

When looking at differences,  it’s important to keep in mind that there's one core value that must be correct for the version to be used: namespace. The bank cannot accept a message where the namespace does not match the version that they support, even if the payment data in the message is formatted exactly as the bank requires.  

The reason? It’s because the namespace attribute within <Document> changes in ISO messages, between versions, and this difference alone means the schema validation will fail at the receiving end. 

Supplementary Data

The most drastic change between versions is that pain.001.001.09 (and other newer ISO messages) support the usage of the “SupplementaryData” field. Supplementary Data elements in the ISO message are defined as "xs:any", which means that they can contain any element, without restrictions on the data. For this reason, banks might release their own SupplementaryData schemas which are not related to ISO 20022 in any way.

For corporate users, in cases where your bank supports Supplementary Data elements, it’s likely that most changes in the payment message will be in this area.

If the bank has released their own SupplementaryData schemas, the namespaces of those schemas have to be included in the payment message; namespace definitions will have to be present in the XML message as well  ̶  all of which makes the XML message more complicated than a message without Supplementary Data.

On the other hand, if the bank does not publish their own SupplementaryData schemas, there is no need to include namespace information in the XML message. But this approach has the effect of making the testing process difficult, as schema validation will not be able to find incorrect usage within Supplementary Data elements.

Supplementary Data elements are optional in the pain.001.001.09 message and if the bank chooses not to use the elements, a corporate user will not have to worry about this change at all. 

Changes in element definitions

Finally, there are differences in the element definitions between the ISO message versions.

• An important one is the difference on how RequestedExecutionDate is defined. Version 3 mandates the usage of format ISODate, whereas version 9 has an option to use either ISODate or ISODateTime. The schema is structured so that RequestedExecutionDate is a complexType element expecting either Dt or DtTm elements, as opposed to version 3 where RequestedExecutionDate is a simpleType element. Therefore, converting pain.001.001.03 to pain.001.001.09 will have to take this into account, as otherwise this change alone would always lead to a schema validation fail.
• Another noteworthy change is that version 9 supports many more PstlAdr elements. However, all the PstlAdr elements used in version 3 are included in version 9.
• Regarding the previous point, it is a good idea to pay attention to the usage of AdrLine element within PstlAdr. AdrLine is supported in version 9, but it will be removed in future versions. This means that a corporate user who is currently sending AdrLine data will have to make sure to organise the data further in future versions, and put content directly into structured PstlAdr elements, such as StrtNm, BldgNb, BldgNm, TwnNm.

While these are the most important differences that we have encountered, market practices and the choices of individual banks can result in many more differences. The devil is in the detail.

We’ll watch with interest to see the various usages of pain.001 version 9 across different markets. We are especially interested to monitor the adoption of Supplementary Data elements. Use of Supplementary Data gives more flexibility, but it also allows for more divergence from a standards-based approach and widespread usage may result in a higher number of technical errors in payments transactions.