By Brigitte De Wilde, Head of Financial Crime Intelligence and Services, SWIFT
Banks have many reasons to be concerned about the quality of their payments data. Regulators have implemented stricter requirements for beneficiary information in payments messages, in addition to prior rules about originator information. Accurate originator and beneficiary data is a critical success factor for effective transactions screening and AML (anti-money laundering) monitoring. Beyond this, data quality also affects straight-through processing and operational efficiency.
Addressing the problems.
Tackling financial crime and terrorist financing continues to be a high priority for regulators, who are taking steps to improve the transparency and traceability of payments. And this includes asking banks to provide more information in their payments messages.
Banks have long needed to include specific originator information in financial messages, but in some cases they are now also being asked to include beneficiary information. FATF (Financial Action Task Force) Recommendation 16, for example, specifies that banks should provide information about beneficiaries as well as originators in their outgoing messages. Banks are also expected to check that incoming transactions include the required information and to resolve any recurrent issues.
If the quality of their payments data is substandard, banks may fail to comply with regulations, risking fines and other regulatory-enforcement actions. For example, incomplete data can result in illicit transactions passing undetected through sanctions-screening filters. Poor quality data can also lead to the need for manual interventions when processing transactions, reducing operational efficiency and straight-through processing rates.
Not all data-quality issues are equal, and payments data may be substandard for a number of reasons:
Errors. Data elements may be missing, transposed, repeated or incorrect. This can mean that essential compliance checks are not carried out, which may result in policy breaches or even sanctions violations.
Unstructured data. Data elements, such as country names, can appear in different forms and/or may be translated into different languages. When unstructured data is used—in a free-format field, for example—it can be difficult for banks to identify a specific data element.
Truncated data. Constraints in the size of a payments message can make it impossible to include all the required information in the relevant fields, resulting in truncation.
Some of these issues are more difficult to address than others. Correcting basic errors is relatively straightforward once those errors have been identified. But in other cases, a lack of information from regulators can make it difficult for banks to ensure that their data ticks all the right boxes.
Grey areas include the definition of name (“doing business as” or legal) and complete address (street, city, country), and the issue of lack of space for complete customer information in a payments message or clearing system.
How should data be prioritised?
The issue of data truncation has become particularly pressing in the last couple of years. With regulators asking for more information, banks have increasingly struggled to include all the required data in their payments messages. And it is not always clear exactly what information banks must retain in such cases.
So, while one bank may decide to include the name of a single accountholder and the full address, another may include the names of all accountholders and omit their addresses. In either case, there is a risk that the message will not include the information needed to meet compliance requirements.
The industry is working to provide greater clarity on these issues. Developments currently underway include guidance being developed by the Wolfsberg Group, as well as an initiative by SWIFT to replace certain free-format fields with structured fields.
Wolfsberg Group guidance
The Wolfsberg Group is working to produce clear industry guidance stipulating when and how payment information should be prioritised, among other recommendations.
Although the principles published by the Wolfsberg Group in 2007 are still valid, the Group is drafting expanded Payment Transparency Principles in an effort to drive consistency on how banks populate payments data. The paper will provide industry guidance on the preferred name and address to use for the originator of the payment, as well as recommend an approach to prioritise certain elements of a complete address if the full address will not fit in the payments message.
From free format to structured fields
SWIFT is now in the process of replacing free-format fields in MT 103 payments messages with structured fields that systematically capture originator and beneficiary information.
Structured fields have already been introduced for fields 50 (originator information) and 59 (beneficiary information), and the free-format option for these fields will be removed in the November 2020 standards release to maximise the benefits for the industry.
Both of these initiatives can be viewed as medium-term solutions to a longer-term problem. The bottom line is that truncation should not happen. Banks are doing this because they have no choice, so guidelines will help to provide an acceptable way forward, as the industry waits for a long-term solution to this issue.
But this won’t happen overnight. Unless existing MT 103 and MT 202COV messages are changed to carry additional data and party fields, banks will continue to struggle. So far, progress has been limited, as it requires support from the entire industry. And to move forward, alignment between the operations, business and compliance areas within each bank is vital.
What can banks do now?
Despite the challenges, banks can take action today to improve their payments data. There is no reason to wait until 2020 before adopting the new MT structured message formats: banks can adopt these formats straightaway to improve efficiency on all sides.
Payments data quality
Banks can also start to assess the quality of their payments data and identify areas for improvement. SWIFT has developed a Payments Data Quality service that enables banks to evaluate the quality of the originator and beneficiary information in the messages they send and receive.
This service supports compliance with the originator and beneficiary data requirements of FATF Recommendation 16, the EU Funds Transfer Regulation 2015 (EU FTR 2015) and the US Travel Rule—and by extension facilitates effective transaction screening and AML monitoring. It also enhances operational efficiency and straight-through processing by identifying areas in which poorly formatted messages may be blocked or delayed, and it enables banks to alert correspondents to their own data shortcomings.
Beyond these solutions, there are opportunities for banks to drive consistency in the definitions of required payments data and message standards by working with industry groups. And in the longer-term, banks need to review their customer data and payment systems with a view to pushing for implementation of the ISO 20022 message.
Payments Data Quality. Allows banks to evaluate the quality of originator and beneficiary information in their SWIFT payments messages, thereby supporting compliance with FATF Recommendation 16.
Compliance Analytics. Analyses a bank’s SWIFT payments traffic, providing a global view of branch and correspondent activity across all group entities. The tool can highlight any nested activity behind payments messages received by the bank, indicating compliance-risk exposures.
The KYC Registry. A secure, shared platform allowing banks to share standardised Know Your Customer data and documents with chosen counterparties in an agreed format.