Transforming ISO 20022 payments data for better reporting and analysis
Over recent years, starting with the SEPA scheme, and now with SWIFT and CHAPS, there has been a convergence onto the ISO 20022 standard messaging format. As payment messages in ISO 20022 are formatted in XML, storing payments data based on these messages into a database is not straightforward. Although a document database could be used, there are limitations around indexing, and ISO 20022 messages can be very large. Further, messages can be complex.
This leaves Financial Institutions and corporations with the challenge of how to store and report on payments, especially when trying to centralise payments data from multiple data sources into a single data store.
Problems with storing ISO 20022 messages
A typical approach to storing ISO 20022 data is to store data into a document database with minimal change. However, extra data does need to be stored for each message, and it can be difficult to piece data together to understand the lifecycle of a payment. Consider the following example:
- – A payment can be received in a pain.001 although its status is in a separate pain.002 message,
- – The pain.001 could in turn cause a pacs.008 to be generated, although the status for that is in a pacs.002.
While incoming and outgoing messages are both in pacs.008 messages, there is no clear way in the message itself to easily decide if the payment is incoming or outgoing. Thus, enquiring and reporting against these structures can be difficult. Even if these structures are flattened automatically as part of storage, enquiries will be complex, and difficult to express in query languages.
This leads to the challenge of transforming payments messages into a more consumable structure for enquiries and analysis. Creating a model for this is difficult as:
- 1. While the ISO standard does have an associated business object model from which messages are derived, this business model is not normalised,
- 2. Terms in the model do not always correspond to field names in payment messages, or even structures, and so there are mapping spreadsheets associated with the messages. To those familiar with the ISO 20022 messages themselves, the model is simply not intuitive.
Icon’s data model for storing ISO 20022 payments
In order to solve this problem, Icon has developed an ISO 20022 compliant logical data model for storing payments as an accelerator for our clients. Our data model is based on the ISO 20022 messages themselves rather than the business model, meaning that payments data stored in the model is easy to understand, and that transformation into/out of the model is straightforward.
The model is normalised and is extensible. It can be used for creating a physical data schema for any kind of database. A particular use case would be for consumption layers for reporting or enquiries.
Icon can help reduce cost and time to market
In summary, for clients looking to build their own payments data stores, our data model accelerator offers significant benefits in reducing cost and time to market, as well as providing superior outcomes compared to the usual approach for storing ISO 20022 payments messages.
For further information on the Icon data model for ISO 20022 payments, or to discuss how to best derive value from ISO 20022 payments data, get in touch with your usual Icon contact or contact us here.
Adam Richardson