Enriched Data and Structured Data: What is it really all about?
When talking about ISO 20022 –two terms consistently emerge: “Enriched Data” and “Structured Data”. Let’s explore what they mean, their benefits and why they matter.
The Importance of Data
Data lies at the heart of every modern business. However, raw data alone isn’t enough. It’s like having a vast library without a catalogue—you may have valuable information, but without organisation, it becomes challenging to extract meaningful insights.
Enriched data goes beyond basic details. It’s data that has been enhanced with additional context and value. While humans can interpret context intuitively, computers require structure to avoid misunderstanding and errors. This is where structured data comes into play.
Structured data provides a framework for organising information – when specific pieces of information are provided in a predefined format (individual fields) that can easily be understood and processed by computers . Structure helps to avoid ambiguity and inconsistency in the data, and enables machines to interpret the context and value of each piece of information. Therefore, although enriched data and structured data are separate things, the maximum value is only realised when they are provided together. ISO 20022 enables exchanging richer data in a structured format.
Basic Payments Data |
||
12345678, John Smith, HSBCGB2L, 98765432, Ashley Toby, CHASUS33, GBP 100
|
||
In the example above, we only know that there is a GBP 100 transaction between John Smith and Ashley Toby and who they bank with. We are unable to tell anything else. |
||
Enriched Payments Data |
||
abc123ref2345, HSBCGB2L, 12345678, John Smith, No. 123 Main Lane, London, W1K 1PN, United Kingdom, 01011995, England, CHASUS33, 98765432, Ashley Toby, 123 Main Street, Apartment 4B, New York, NY 10001, United States, 01012000, NY, USA, GBP 100, Supplier Payment, INV0123
|
||
With enriched data, we now know more about the two individuals and the payment. We have more information about the payments including the address, reference number, Bank BIC, currency, purpose of the payment and the invoice number. |
||
Enriched and Structured Data |
|
|
Debtor: First Name: John Last Name: Smith Address: Building Number: 123 Street Name: Main Lane City: London Post Code: W1K 1PN Date of Birth: 01/01/1995 Country of Birth: England
|
Creditor: First Name: Ashley Last Name: Toby Building Number: 123 Street Name: Main Street Room: 4B City: New York Post Code: 10001 Country: United States Date of Birth: 01/01/2000 Country of Birth: NY, USA
|
Reference: abc123ref2345 Debtor Agent: HSBCGB2L Debtor Account: 12345678 Creditor Agent: CHASUS33 Creditor Account: 98765432 Amount: 100 Currency: GBP Purpose: Supplier Payment Invoice Reference: INV0123 |
Enriched and structured data is where true value is added. In our example, we can now clearly distinguish the sender and receiver, their bank details, reference, and purpose of the payment along with the invoice number. This structured data eliminates the potential misinterpretations that could arise from unstructured data. |
||
By leveraging enriched and structured data, companies can build a more precise and complete picture about their business operations and customers.
The talk is not just about compliance and technical interoperability, but much more than that.
1. Structured Name and Postal Address provides a way to unambiguously identify the parties involved. This can assist greatly with KYC and accurate sanctions screening to not only identify sanctioned parties in a payment, but also decrease the number of false positives generated by a filtering system (see use case 3).
2. Structured Remittance Information allows for information such as invoice numbers, order numbers and other references relating to what the payment is being made for to be passed within the payment messages. It can provide Enterprise Resource Planning (ERP) systems with the ability to receive and process richer remittance data which can lead to automated reconciliation and improve cash flow management.
3. Legal Entity Identifier (LEI) provides more transparency in payments to clearly identify specific entities involved which can assist with improved KYC, automated sanctions screening and reconciliation.
4. Purpose Codes provide an insight into the reason for payments and when used consistently, it can bring multiple benefits such as identifying key customer trends and therefore enabling the development of innovative services, fraud prevention and payment prioritisation for processing. As an example, the Bank of England is planning to use the purpose code to identify and prioritise time-critical payments such as property purchases.
5. Multiple Payment Identifiers enables every party to include their unique references to identify the payment which improves the reconciliation process.
6. Ultimate Debtors and Creditors also known as OBO – ‘on behalf of’ – payments provide information on the true end party that is paying or receiving the fund.
All the data combined, can provide businesses with detailed information to analyse their payments sent and received. This can lead to better decision making not only for enhanced fraud detection and prevention, but also improved customer experience and optimising internal processes.
Real-world impact
Let’s explore some use cases:
Use Case 1 – Commonwealth Bank of Australia (CBA) – benefit finder
Finding and applying for some government benefits can be quite complex, leading to millions of dollars being left unclaimed every year. CBA found that by using purpose codes they could accurately identify their student customers and so help them get access to benefits they were missing. This tailored approach made the banking experience for each student more personalized and relevant.
Use Case 2 – retail corporation invoice reconciliation
Many large retail corporations struggle with having to manually reconcile invoices from various suppliers, each with its own unique data format, which leads to increased costs which can impact their bottom line. Banks are able to provide services to corporates which matches feeds of incoming payments to invoice details provided by the customer’s ERP engine, which gives automatic reconciliation and accurate reporting. This is only possible because the right data is in the right field.
Use Case 3 – accurate sanctions screening
Payments are often delayed due to false hits on payer or payee names (false positives), which leads to customer dissatisfaction, with possible revenue loss and increased costs for banks due to manual investigations.
Examples:
Mohammed Ali and Maria Chavez are internationally common names that also appear on sanctions lists. A payment sanctions check could be alerted due to this name. However, by way of fictional example, Mohammed Ali from London born in 1997 or Maria Chavez from New York, born in 1980 is different from Mohammed Ali from Egypt born in 1965 or Maria Chavez from Mexico, born in 1967 who may be on the OFAC list.
By incorporating additional data like addresses, date of births and other attributes, screening systems can provide more accurate alerts, saving financial institutions on screening and investigation costs and importantly improving the customer experience.