Leveraging ISO 20022 to Improve Sanctions Screening in Financial Institutions

Historically, much of the data linked to payments has been underutilized or entirely neglected, primarily because processing systems were not designed to extract and operationalize this data. This inefficiency has placed significant strain on Anti-Money Laundering (AML) and sanctions screening processes.

Can ISO 20022 Address the Limitations?

Sanctions screening is a critical control mechanism used to detect, prevent, and disrupt financial crime, particularly related to sanctions risk. The process involves comparing one string of text against another to identify similarities that could indicate a potential match. This screening compares data from an FI’s operations, such as customer and transactional records, against lists of names and other indicators of sanctioned entities or locations.

These sanctioned entity lists are typically sourced from regulatory authorities and are often supplied, updated, and maintained by external vendors. These vendors specialize in amalgamating, enhancing, formatting, and delivering the lists in a way that is usable for sanctions screening.

           

Key Screening Controls in Financial Institutions: Transaction and Customer Screening

Financial Institutions (FIs) employ two primary screening controls to achieve compliance and mitigate risks: Transaction Screening and Customer Screening.

1. Transaction Screening

Transaction screening involves monitoring the movement of value within an FI's records, such as funds, goods, or assets, between parties or accounts. To mitigate risks associated with trade finance transactions and international wire transfers, FIs perform real-time screening of cross-border transactions against Sanctions Lists. This process is crucial when any of the involved banks—Sending Bank, Originating Bank, Receiving Bank, Intermediary Bank, or Beneficiary Bank—are located in different countries.

2. Customer or Name Screening

Customer or Name Screening entails checking the full legal name and any other name provided by the customer, including known aliases, against relevant official sanctions lists. While generating an alert through this screening process is not necessarily an indication of sanctions risk, it is the initial step toward identifying potential exposure, which can be confirmed or dismissed with further investigation.

Understanding the Complexity of Screening

Screening may seem straightforward, but determining a “true match” across various variables—such as alphabets, names, addresses, spelling, abbreviations, acronyms, and aliases—can become highly complex. Certain data elements, like transaction amounts, dates, and reference numbers, offer minimal risk mitigation and are not usually relevant for screening purposes.

Common Transactional Attributes for Screening

FIs commonly screen several key attributes in transactions, including:

  • Parties Involved: The remitter and beneficiary in a transaction.
  • Agents and Intermediaries: Including other FIs involved in the transaction.
  • Vessels: International Maritime Organisation (IMO) numbers, typically relevant in Trade Finance transactions.
  • Bank Information: Bank names, Bank Identifier Code (BIC), and other routing codes.
  • Free Text Fields: Payment reference information or the stated purpose of payment in Field 70 of a SWIFT message.
  • Product Identifiers: International Securities Identification Numbers (ISINs) or other risk-relevant identifiers, particularly in securities-related transactions.
  • Trade Finance Documentation: Includes details of the importer, exporter, manufacturer, drawee, drawer, notify party, and signatories, as well as shipping companies, freight forwarders, facilitators like insurance companies, agents, brokers, and FIs such as Issuing, Advising, Confirming, Negotiating, Claiming, Collecting, Reimbursing, and Guarantor Banks.
  • Geographical Data: A wide range of addresses, countries, cities, towns, regions, ports, and airports are screened, particularly within SWIFT Fields 50 and 59, and places related to the transport of goods (e.g., Place of Taking in Charge, Place of Receipt, Place of Dispatch, Place of Delivery, Place of Final Destination, Country of Origin, Country of Destination, and Airport of Departure/Destination).

 


The Impact of Legacy Systems on Data Quality and False Positives

Legacy systems and outdated processes have made it increasingly difficult to differentiate between True Hits and False Hits, primarily due to poor data quality. While completely preventing false positives is challenging, minimizing them is possible if data is structured properly.

The Problem of Poor Data Quality

Data can become "bad" for numerous reasons, such as:

- Inconsistent data sources across the enterprise
- Inflexible legacy systems not designed to interact with modern technology
- Lack of budget or resources to clean up years of inaccurate data
- Human error

At the core of these challenges lies poor data quality, which exacerbates issues in screening processes.

Scope of the Issue

A false-positive rate of just 5% in a million transactions results in fifty thousand false positives. Investigating and clearing these false positives demands significant time, effort, and resources. Unfortunately, a 5% false-positive rate is considered low; most organizations experience false-positive alerts 50% to 70% of the time.

Addressing the Issue with Structured Data

Financial Institutions (FIs) often attempt to solve these issues with algorithms or by applying AI and ML. However, these solutions fail to address the root problem: bad data.

Recognizing the need for structured data, organizations like Wolfsberg, Market Infrastructures, and FIs have agreed to align their data requirements with the adoption of ISO 20022 messaging standards in payment markets. This shift toward structured ISO 20022 data is a critical step in addressing data quality issues.

The Role of ISO 20022 in Structured Data

Previously, we discussed the importance of structured data in the ISO 20022 migration. Fields like F50F and 59F in MT messages introduce a basic structure through qualifiers, expanding the scope of data elements mapped to the ISO 20022 format. Additionally, ISO 20022 introduces three new parties: Ultimate Debtor, Initiating Party, and Ultimate Creditor. These fields relate to "Payment on Behalf Of" scenarios, which are absent in current MT formats.

The delay in ISO 20022 implementation provides banks with ample time to remediate existing static data and prepare for the new structured format.

Benefits of ISO 20022 Implementation

This back-end process offers significant advantages, including:

- Improved Straight-Through Processing (STP): Lower likelihood of errors leads to higher customer satisfaction.

- Reduction of False Positives: With less data being parsed, the focus shifts to elements that pose actual sanctions risks, leading to reduced data storage needs, accurate reporting, and lower headcount requirements at L1, L2, and L3 levels.

Over the next few years, more than 11,000 banks on the SWIFT network will migrate to ISO 20022. This migration presents a unique opportunity for banks to develop and implement a robust data strategy, enabling them to:

- Optimize profitable accounts and design new products to make less profitable accounts viable.
- Enhance risk controls and minimize fraud.
- Review and reduce correspondent bank charges.

Nth Exception: Your Partner in ISO 20022 Transition

If your institution is planning to adopt ISO 20022, Nth Exception, a SWIFT partner, is here to assist. As a specialist consultancy and technology firm, we work with financial institutions globally to implement best-in-class payment solutions.

Introducing Nucleus: Enabling ISO 20022 Rich Data

Nucleus, an ISO 20022 Data Fabric, is purpose-built to help banks and financial institutions monetize ISO 20022. It leverages rich ISO 20022 messages categorized by domain, scheme, and message version, and federates this rich data to internal systems, enabling large-scale change and disruption. Out of the box, Nucleus enables institutions to comply with CBPR+ and HVPS+ structured data requirements.

Key Features of Nucleus

- Internalize the ISO 20022 data language and definitions.

- Update systems to receive data as per ISO 20022 definitions.

- Capture payments metadata from payment messages.

- Extend rich contextual payments data to existing organizational systems that are not ISO 20022 native.

Key Benefits of Nucleus

- Bridges the gap between legacy data platforms and ISO 20022.

- Designed for financial institutions to accelerate value extraction from ISO 20022.

-ISO 20022 native data store for pre- and post-translation messages: 10 years.

- Structured address enablement.

- LEI validation and creation.

- Automated purpose and remittance codes.

- Automated, independent truncation management.

- Advanced analytics.

- API native.

- Available on-premise and in the cloud.

With Nucleus, your institution can seamlessly transition to ISO 20022, unlocking new efficiencies and capabilities in cross-border payments.