The Importance of Data Structure: ISO 20022 and the Future of Payments

8 9 The Importance of Data Structure: ISO 20022 and the Future of Payments Treasury and Trade Solutions Focus Area 2: Operations and Investigations The failure of payments due to repair or investigations across the banking chain is another key pain point in the current cross-border payments system. It results in potentially lengthy payments delays for end users and contributes to the cost of payments processing for banks, impacting overall client experience. In many cases, payment repairs and investigations result from poorly formatted or incomplete payments messages. Repair The current MT standard makes it difficult to validate whether payment details are complete in advance and their open and unstructured nature also leads to incorrect use of fields by senders and sending institutions. One common reason why non-STP payments require manual intervention is because of incorrect intermediary/ beneficiary bank information and a lack of upfront validation. For example, the beneficiary bank in field 57 of an MT103 is often incorrectly formatted. Below is an example of this occurring and how these messages are repaired at present. A targeted screening approach avoids false positives linked to mismatches between information type (such as a debtor name being confused with a vessel name or a street name matching embargo data). Structured data applies logic to the screening process, facilitating automation and eliminating post-facto manual monitoring. By providing more detailed information about all parties involved in a payment, the new message format speeds up payments, increases transparency, and improves the effectiveness and accuracy of sanctions screening. The example below shows how this works in practice. John Smith, who lives at 126 Cuba Ave in NYC, wants to send a payment. • Using the MT free format option in field 50K there is no way to determine without human intervention if Cuba relates to the country or the street name. • However, when formatted with ISO 20022 we see that Cuba Ave is tagged to street name and not the country field; therefore it will pass screening without registering a false positive. 4 A Business Identifier Code (BIC) is a universal standard used for routing transactions to identify financial and non-financial institutions in a payments chain. The more structured and higher data quality offered by ISO 20022 could facilitate the use of new technologies like artificial intelligence (AI) and machine learning (ML), which would automatically eliminate false hits, reducing manual intervention and accelerating payments processing. Moreover, ISO 20022 could streamline compliance by making processes faster, more efficient, and more accurate. This would lessen one of the greatest friction points in cross-border payments and make compliance with regulatory mandates on processing completeness and quality data more straightforward. However, in the short term, banks need to be mindful of the unintended consequences of adopting full ISO 20022 messages. Given their extensive unstructured data fields, if data is of poor quality it could result in an increase in false positives unless banks build ignore patterns or find other ways to manage exceptions. Institutions considering the potential upside of ISO 20022 implementation should review their internal hit rates, including the number of false positives, with a view to moving towards a fully structured data model in the future. Because field 57D does not have a specific tag, many players enter the name of the institution when only a business identifier code (BIC) is required (detailing financial or non-financial institutions). 4 With ISO 20022, it is clear from the tag that only the BIC — BICFI in this example — should be included in this field; there is no need to incorporate the institution’s name or another identifier. Investigations Investigations could greatly benefit from the adoption of ISO 20022. On average, 2%-5% of all payments prompt an enquiry. Management of exceptions, alerts and investigations is extremely labor intensive for a financial institution because it hinders increased automation. The requirement for investigations is largely due to the widespread use of free-format messages combined with a lack of industry rules. Furthermore, many banks use the unstructured MTn99 message type for investigations. These messages require human intervention to read, identify the issue and then determine the proper course of action. In many cases inquires can take days to resolve due to inefficient processes. Banks need to address their dependence on MTn99 messages in the immediate term. Benefits • Financial data management • Enhanced client experience • Harmonization across global jurisdictions • Greater transparency MT103 (Customer Payment) {1:F01CITIUS33AXXX0000000000} {2:O103TESTUS33XXX}} :20: ABC123REFERENCE :32A:150505USD12666,00 :50K:/123456789 JANE DOE :57D:BANK OF WIRE TRANSFERS MIAMI, FLORIDA USA <CdtrAgt> <FinInstnId> <BICFI>BOWTUS33 </BICFI> </FinInstnId> </CdtrAgt> MT103 (Customer Payment) {1:F01CITIUS33AXXX0000000000} {2:O103TESTUS33XXX}} :20: ABC123REFERENCE :32A:150505USD12666,00 :50K:/123456789 JANE DOE :57A:BOWTUS33 :59:/12345678 JOHN DOE :70:CONGRATULATIONS :72:/ACC/IMPORTANT PAYMENT :59:/12345678 JOHN DOE :70:CONGRATULATIONS :72:/ACC/IMPORTANT PAYMENT Manual Repair ISO 20022 pacs.008 Beneficiary Bank Example Incorrect Beneficiary bank formatting MT – free format option :50K:/ CITIUS33XXX JOHN SMITH CUBA AVE 126 NEW YORK CITY 10306 United States ID: 1234567890 ISO 20022 Debtor data element example Credit Transfer Transaction Information Debtor Name JOHN SMITH Postal Address Department Sub Department Street Name CUBA AVE Building Number 126 Post Code 10306 Town Name NEW YORK CITY Country US Identification Legal entity identification (LEI) 1234001234567891 2312 Debtor Account Identification IBAN US253902000000 012345 Debtor Agent FI Identification Finical Institution BIC CITIUS33XXX <Dbtr> <Nm> MR JOHN SMITH </Nm> <PstlAdr> <StrtNm> CUBA AVE </StrtNm> <BldgNb> 126 </BldgNb> <PstCd> 10306 </PstCd> <TwnNm> NEW YORK CITY </TwnNm> <Ctry> US </Ctry> </PstlAdr> <Id> <OrgId> <LEI> 12340012345678912312 </LEI> </OrgId> </Id> </Dbtr> <DbtrAcct> <Id> <IBAN> US253902000000012345 </IBAN> </Id> </DbtrAcct> <DbtrAgt> <FinInstnId> <BICFI> CITIUS33XXX </BICFI> </FinInstnId> </DbtrAgt> . MX message XML Example for Debtor: Source: Citi material Source: Citi material