Payments Data Strategy in the period of Payments Modernization

Historically, much of the data linked to payments has been underused (or not at all used) — in large part because processing systems were not set up to extract and operationalize this data. AML and Sanctions screening have faced much of heat with the limitations. 

Can the new standard fix it? 

Sanctions screening is a control used in the detection, prevention, and disruption of financial crime and, in particular, sanctions risk. It is a permutation combination of one string of text against another to detect similarities which would suggest a possible match. It compares data sourced from an FI’s operations, such as customer and transactional records, against lists of names and other indicators of sanctioned parties or locations.

The sanctioned entity lists are typically derived from regulatory sources and often supplied, updated, and maintained through external vendors specializing in the amalgamation, enhancement, formatting, and delivery of these lists. 
           

Most FIs have deployed two main screening controls to achieve their objectives: Transaction screening and Customer screening.

1. Transaction Screening - The process of screening a movement of value within the FI’s records, including funds, goods, or assets, between parties or accounts. In order to mitigate risk associated with trade finance transactions and international wire transfers, FIs conduct real-time screening of cross border transactions against Sanctions Lists, where any of the Sending Bank, Originating Bank, Receiving Bank, Intermediary Bank or Beneficiary Bank are located in different countries. 

2. Customer or Name Screening-  The screening of full legal name and any other name provided by the customer, such as known aliases, against applicable official sanctions lists. 
Generating an alert as a result of the process of screening is not, by itself, an indication of sanctions risk. It is the first step towards detecting a risk of sanctions exposure, which can be confirmed or discounted with additional information. While the concept sounds simple, determining what actually constitutes a “true match” across a range of variables such as alphabets, names, addresses, spelling, abbreviations, acronyms and aliases, can get very complex.

Certain data elements offer little or no risk mitigation through screening, for example, amounts, dates and transaction reference numbers have no relevance from a screening perspective. Some of the most common transactional attributes screened include: 
- The parties involved in a transaction, including the remitter and beneficiary. 
- Agents, intermediaries, and FIs.
- Vessels, including International Maritime Organisation (IMO) numbers, normally in Trade Finance related transactions. 
- Bank Names, Bank Identifier Code (BIC), and other routing codes. - Free text fields, such as payment reference information or the stated purpose of the payment in Field 70 of a SWIFT message. 
- International Securities Identification Number (ISINs) or other risk-relevant product identifiers, including those that relate to Sectoral -Sanctions Identifications within securities-related transactions.
- Trade finance documentation, including the: 

• Importer and exporter, manufacturer, drawee, drawer, notify party, signatories. 
• Shipping companies, freight forwarders o Facilitators, such as insurance companies, agents and brokers. 
• FIs, including Issuing / Advising / Confirming / Negotiating / Claiming / Collecting / Reimbursing / Guarantor Banks.

- Geography, including a multitude of addresses, countries, cities, towns, regions, ports, airports, such as: 

• Within SWIFT Fields 50 and 59. 
• Place of taking in Charge / Place of Receipt / Place of Dispatch / Place of Delivery / Place of Final Destination. 
• Country of origin of the goods /services/country of destination/country of transhipment. 
• Airport of Departure / Destination.

Legacy processes and systems have made it more challenging to segregate True Hits versus False Hits, majorly due to the data quality. False positives cannot be completely prevented however, they can be minimized if data is in a structured format. 

There are countless ways data can become “bad” data, be the data sources across the enterprise, inflexible legacy systems that were not built to interact with modern-day technology, lack of budget or resources to clean up years’ worth of inaccurate data entry, or simply human error, poor data quality is at the core of screening problems. 

Scope of the issue - 

A 5% false-positive rate on one million transactions would result in the detection of fifty thousand false positives. Significant cost, time, and effort are required to investigate and clear false positives. Sadly, a 5% false-positive rate is on the low side, which is really a nominal figure since most organizations see false-positive alerts between 50% and 70% of the time.

Typically, FIs attempt to fix these issues by matching an algorithm or applying AI and ML. However, it does not solve the problem as the Data itself is ‘Bad’. 

Recognizing the issue with unstructured data, Wolfsberg, Market Infrastructures, and FIs proposed and agreed to align the requirements for structured data with the adoption of ISO20022 messages in payment markets rather than tackling the issue independently. However, the focus is on structured ISO20022.

Earlier, we looked into the basics of structured data and the focus it carries as part of ISO20022 migration. 
F50F and 59F of MT bring in the basic level of the structure by the qualifiers. This increases the scope of data elements mapped to a structured MX / ISO20022 format. In addition, three new parties are introduced as part of ISO20022 - Ultimate Debtor, Initiating party and Ultimate creditor, relate these fields to ‘Payment on Behalf Of’ which are not part of current MT.

Delay in ISO20022 implementation gives banks a substantial amount of time to conduct full-fledged remediation of existing static data and get ready to consume the new. 

As this is a back end process, build your case based on two key factors - Improved straight-through processing as the likelihood of errors is low (customer satisfaction). And, the massive reduction of false positives as less data is parsed and targeting the elements that could pose an actual sanctions risk. (Lesser data storage, right reporting, lesser headcount at L1, L2 and L3, address the actual problem). 

Over the next 5 years, 11000+ banks on the SWIFT network will migrate to ISO 20022. This gives banks a unique opportunity to develop and implement their own data strategy which will enable them to harness the rich data and leverage it to -

• Optimise profitable accounts and design new products to make the least profitable accounts profitable. 
• Improve risk controls and minimise fraud. 
• Review and take steps to decrease the correspondent bank charges in line with the IMF recommendations. 

Banks who fail to do so, may see themselves out of the payments business.