BIS Innovation Hub
Nexus - Short ReportAbout the BIS Innovation Hub
  • Introduction
    • Nexus Overview
    • How to use this site
    • Overview Report
    • Terminology
  • Payment Setup
    • Key Points
    • Scope of Nexus payments
    • Steps 1-2: Country, Currency & Amount
    • Steps 3-6: Exchange Rates
    • Steps 7-9: Addressing, Proxy Resolution & Confirmation of Payee
    • Steps 10-11: Sanctions screening
    • Step 12: Ask the Sender for approval
    • Step 13-16: Set up and send the payment instruction
    • Step 17: Accept the confirmation and notify Sender
  • Addressing & Proxy Resolution
    • Key Points
    • Overview of Payment Addressing in Nexus
      • Addressing via Proxies (Aliases)
      • Addressing via Account Details
    • Address Types & Inputs
      • Address Types
      • Address Inputs
      • Financial Institution Identification
      • List of PSPs
      • Examples
    • Proxy & Account Resolution Process
      • Step 1: Sender inputs proxy or account details
      • Step 2: Proxy Resolution Messaging Sequence
      • Step 3: Account Resolution Messaging Sequence
      • Step 4: Source PSP processes the results
      • Masking of Display Names
    • Role of the Proxy Directory Operator (PDO)
      • Obligations on the Proxy Directory Operator
      • Obligations of PSPs using the Proxy Directory
      • Onboarding a Proxy Directory Operator onto Nexus
  • FX Provision
    • Key Points
    • Role of the FX Provider
    • How Third-Party FX provision works in Nexus
    • Joining Nexus as a third-party FXP
    • Accessing Instant Payment Systems
    • Onboarding PSPs
    • Obligations & Compliance
    • Revenue model for FXPs
    • Rates from Third-Party FX Providers
      • Improving rates for larger transactions
      • Improving rates for specific PSPs
    • Quotes
    • Managing Liquidity
  • Payment Processing
    • Key Points
    • Accounts & Relationships
    • Maximum value of a Nexus payment
    • Payment Flow (Happy Path)
      • Detailed Flow in Source Country (Sending)
      • Detailed Flow in Destination Country (Receiving)
      • Booking flow for Source PSPs
      • Notifying FXPs of completed payments
    • Validations, Duplicates & Fraud
    • Time critical vs non-time critical payments
    • Special Scenarios
    • Payment setup for PSPs who provide their own FX
    • Unsuccessful Payments (Exceptions)
      • Rejects
      • Recall Requests
      • Returns
      • Investigation & Enquiry
      • Disputes
      • Reconciliation reports
    • Fees
    • Role and responsibilities of the Instant Payment System Operator (IPSO)
    • Ensuring settlement certainty
    • Annex: 4-step vs 5-step Processes in Domestic Clearing and Settlement
    • Annex: Sponsoring PSPs and Sponsored Entities
  • Settlement Access Provision
    • Key Points
    • Role of the Settlement Access Provider (SAP)
    • Joining Nexus as an SAP
    • SAP onboarding of FXPs (or foreign PSPs)
    • Costs and Revenue for SAPs
    • Obligations on the SAP
    • Processing payments as an SAP
      • Payment Process for the Source SAP
      • Payment Process for the Destination SAP
      • How the Destination IPS initiates the payment via the Destination SAP
    • Managing Liquidity as an SAP
  • Messaging & Translation
    • Key Points
    • General Usage of ISO 20022
      • Adherence to CPMI Harmonised ISO 20022 Data Requirements
    • Compatibility with Instant Payments Plus (IP+)
    • Message transformation by Nexus
    • Specific Message Elements
    • Purpose Codes
    • Message Guidelines (Excel)
    • MESSAGE acmt.023 Identification Verification Request
    • MESSAGE acmt.024 Identification Verification Report
    • MESSAGE: pacs.008 FI to FI Customer Credit Transfer
      • pacs.008 Differences from CPMI Harmonisation Requirements
    • MESSAGE pacs.002 Payment Status Report
      • pacs.002 Differences from CPMI/CBPR+ Guidelines
    • MESSAGE: pacs.004 Payment Return (Not yet supported)
    • MESSAGE: camt.054 Bank to Customer Debit Credit Notification
    • Translation To/From Domestic Message Formats
    • Translating To/From ISO 20022 Codes
  • APIs
    • Overview
    • Countries
    • Currencies
    • Address Types and Inputs
    • Financial Institutions
    • Fees and Amounts
    • Intermediary Agents (SAPs)
    • Quotes
    • ISO 20022 Messages
  • About
    • Contact the Nexus Team
  • LEGAL
    • Terms and Conditions of Use
    • Privacy Notice
    • Cookies Notice
Powered by GitBook
On this page
  • The sanctions screening requirement
  • Step 10: Review the data available for sanctions screening; ask the Sender for Recipient data if necessary
  • Step 11: Screen the payment against applicable sanctions lists
Export as PDF
  1. Payment Setup

Steps 10-11: Sanctions screening

PreviousSteps 7-9: Addressing, Proxy Resolution & Confirmation of PayeeNextStep 12: Ask the Sender for approval

Last updated 8 months ago

The sanctions screening requirement

All cross-border payments through Nexus will need to be screened by the PSPs involved in a payment against the sanctions lists that apply in their jurisdiction (‘sanctions screening’).

In most cases, sanctions screening software used by the PSP will first compare the name of the Sender or Recipient and look for similar names on the sanctions lists. If a positive ‘hit’ is found, the software can use additional data, such as address, date and place of birth, or national identity number, to confirm whether the Sender or Recipient is actually the person on the sanctions list or just a similar name (a “false positive”).

requires the following information to be included in cross-border payments:

SENDER
RECIPIENT

  • The name of account holder (Mandatory)

  • The account number

  • AT LEAST ONE OF THE FOLLOWING:

    1. Address

    2. Place and date of birth

    3. National ID number or another unique customer identification number

  • Account Number

  • Name

Additional requirements may apply in each jurisdiction. For example, a particular country might define the Debtor > Postal Address element to be mandatory.

Each IPS can define this required information in Nexus so that it can be shared with PSPs in the response to GET /countries.

The PSP should therefore ensure that all pacs.008 payment instructions to Nexus include the Recipient’s name and account number as a minimum. Adding further information in addition to the name will reduce the likelihood of the payment triggering a false positive alert and being delayed.

Step 10: Review the data available for sanctions screening; ask the Sender for Recipient data if necessary

The PSP should now review the acmt.024 response to confirm whether:

  • Name is present

  • Account number is present

If the Name element is blank, the PSP must display a form asking the Sender for the Recipient’s full name. (The Recipient’s name is required as a minimum, in line with FATF Recommendation 16.)

Failure to include the Recipient's name is likely to result in the payment failing the sanctions screening of PSPs and and the payment being rejected.

The Source PSP can display fields for them to enter the Recipient’s address. The Source PSP should check the information it received from GET /countries/{countryCode}/ to establish if these additional fields are mandatory in the Destination IPS.

Although the Source PSP could also ask for Date and Place of Birth and National Identity number, Recipients may be uncomfortable with sharing this information directly with the Sender. (In contrast, when the Destination PSP shares the information in response to an acmt.023 account resolution request, the information is shared securely through Nexus and not shown to the Sender, except for the display name).

Step 11: Screen the payment against applicable sanctions lists

Before the PSP send the payment instruction the Source PSP will need to screen the Recipient against the sanctions lists applicable in the PSP’s jurisdiction. (It is assumed that the Source PSP has already screened the Sender as part of the PSP’s regular KYC, AML and screening processes.)

This step can be done later if the PSP's screening software requires a complete pacs.008 payment instruction.

If the Destination PSP supports the acmt.023/acmt.024 account resolution process, Nexus will already have issued a acmt.023 request to the Destination PSP during the proxy and account resolution process.

FATF’s Recommendation 16
If information about the Recipient can't be retrieved through either the proxy resolution or account resolution, the Source PSP will need to ask the Sender to provide that information.