How Nexus helps with sanctions screening

All payments going through the Nexus network must be screened against sanctions lists by the banks involved, using screening software that they have built themselves or bought from external vendors. Nexus itself does not provide a sanctions screening service.
However, Nexus assists with the sanctions screening process by:
Ensuring better quality data: Putting better quality data into sanctions screening engines should (a) reduce the number of false matches and (b) allow the sanctions screening software to automatically eliminate more false matches, reducing the number of unnecessary alerts.

Automating the Request for Information process: If the screening software itself can automatically (via an API) request further information from the other bank, it may be able to automatically review and reject a higher number of false matches.

Acquire the Sender’s consent to share additional data when (a) the bank doesn’t already have permission to share that data and (b) the payment cannot pass sanctions screening without the extra data
The functionality below is designed to:
Reduce the percentage of payments that trigger alerts
Increase the percentage of alerts that can be resolved automatically, without manual (human) intervention.
Performing Sanctions Screening before payment instructions
Where possible, Nexus requires that sanctions screening is performed before the payment instruction is sent. This approach aims to identify any reasons why the payment would fail sanctions screening and to automatically resolve these issues where possible, while the Sender is still using their banking app. This ensures that when the Sender clicks “Send payment” they have a high degree of certainty that the payment will complete in seconds rather than being held up due to unexpected sanctions screening alerts.
The strong preference is for banks to work towards screening before the payment instruction is sent. Modern API-based sanctions screening software can support this flow, but some banks” legacy systems may not. For example, some bank screening systems are only triggered when the bank has received funds (and before they credit the Recipient). The Nexus process flows accommodate these scenarios, although the user experience is negatively impacted. (For example, Senders whose payments trigger an alert will see an error some seconds after clicking “Send payment”.)
Improving Data Quality and Accuracy
Nexus will enforce data quality and completeness. Specifically:
1.Nexus will require a full name for Sender. To aid accurate screening, the Nexus scheme will set the obligation for banks to provide the full name in all payments. The Nexus software will also apply a simple text validation on the payment message from the Source Bank to check that the Sender and Recipient name fields include names (ie phrases of 2 letters or more). Of course, Nexus is not able to validate that the name provided by the Source Bank is actually the genuine name of the account holder, although Confirmation of Payee may help with this.
This addresses the common problem in traditional cross-border payments where the data in the name field is abbreviated or incomplete. Poor quality data here leads to greater false matches against the sanctions list.
1.Where possible, Nexus will retrieve the Recipient name from the Destination Bank rather than the Source Bank.
In traditional cross-border payments, the Sender provides the Recipient’s name to the Source Bank, who includes it in the payment instruction. But this opens a number of sources of potential data inaccuracy: the sender may misspell the name, use short names or nicknames or mix up the order of first and middle names. All of these errors may increase the chance of triggering alerts against sanctions lists and make it harder to establish whether alerts are false or true matches. In addition, all of the above may be used intentionally by criminals with the intention of making a payment through to someone on a sanctions list whilst evading sanctions checks. For this reason, it is preferrable to retrieve the Recipient name from the Destination Bank.
The Destination IPS’s SLD will define whether it is possible to retrieve the Recipient’s name from the Destination Bank in question. Some alias services automatically return the Recipient’s real name, while in others, a separate process may be needed.
In some cases, a bank’s legacy systems may not be able to retrieve this data in response to an API call. In other cases, a country’s data protection rules may not allow sharing of the account name across borders. In both these cases, the Source Bank will still need to collect the Recipient Name from the Sender at the same time as asking them for the Recipient’s account number or alias.
1.Nexus will reject any payment that does not include the minimum information required by FATF guidelines. Without this required information, the Source Bank will receive error message from the Account or Payment APIs.
​FATF’s Recommendation 16 requires the following information:
For the Sender:
​
1.The name of account holder (Mandatory)
2.The account number
3.AT LEAST ONE OF THE FOLLOWING
1.Address
2.Place and date of birth
3.National ID number or another unique customer identification number
For the Recipient:
1.Recipient (Beneficiary) Account Number
1.Recipient (Beneficiary) name
For businesses, the Source Bank can also provide:
​
1.Registered business name
2.Registered address
In Nexus, the Recipient’s details may be provided by the Destination Bank rather than by the Sender. For example, if an alias is used, the Sender does not know the account number. Likewise, where Nexus can retrieve the Recipient Name from the Destination Bank, it will do this rather than asking the Sender to input the Recipient Name (for the reasons given above).
1.Nexus will provide a Request-for-Information (RFI) API service for banks to query each other for additional information
When a proposed payment triggers an alert and this can’t be identified as a false match based on the data in the payment message alone, Nexus will provide an API method for any bank to query the other bank(s) on the Sender or Recipient. This is intended to automate the majority of Requests for Information, reducing the number of payments that are rejected outright and reducing the number of payments that require human intervention.
1.Applying ISO 20022 standard for messages
Nexus uses the ISO 20022 data standard for payment messages between Nexus Gateways. The ISO 20022 format provides better structure and more space for the comprehensive data required to allow effective sanctions screening. See Messaging Standards for more detail.
Supporting Automated Communication Between Banks
To support privacy and data protection, the Source Bank should start by sharing only the minimum data which is required by FATF regulations. If this minimum data triggers an alert, then the RequestForInformation API should be used to requested further information, such as Date and Place of Birth or a national identity number.
In some cases, the Sender may need to be asked for specific consent to provide further information to the Destination Bank. In this case, it would be explained that the payment cannot be processed without the additional information.

Responsibility for sanctions screening in Nexus

When manual intervention is still required

Last modified 9mo ago

Export as PDF

Copy link

Contents

Performing Sanctions Screening before payment instructions

Improving Data Quality and Accuracy

Supporting Automated Communication Between Banks