Sanctions Screening
NEXUS GATEWAY & SCHEME
Powered By GitBook
User enters Recipient details
Payments need to be addressed to a specific bank account, but bank account number formats are different in different countries. Some countries also use aliases, for example allowing payments to be sent to a mobile number.
For a Nexus payment, the Recipient can give the Sender the same account details they would use to request a domestic payment. This means that the Recipient does not need to find an IBAN number, BIC code or other international account details.
This is possible because Nexus “inherits” the address and alias formats that are used in the destination country. For example, if payments can be sent to a phone number (an alias for a specific account) in the Destination Country, the same phone number can be used to route a payment through Nexus. In general, whatever details are valid for addressing a domestic payment within the destination country are also valid for addressing an international payment to that country via Nexus.
Once the user has selected the Destination Country, Nexus will provide the user with all the account address and alias formats that are accepted in the Destination Country.
    1.
    The Sender selects the address format that they were given by the recipient. For example, if the payment is going to Australia, the Sender would be offered the option to input: a BSB code and account number; an email address; a mobile phone number; or a company registration number. (See examples of alias schemes in different countries in Addressing payments).
    2.
    The Sender enters the alias or destination account number.
    3.
    The Sender may be asked to enter the name of the Recipient, if the Destination Bank requires that to provide a Confirmation of Payee check (See Confirmation of Payee).
    4.
    The Source Bank’s app validates that these details are correctly formatted (eg correct number of digits, no unexpected characters)
    5.
    The Source Bank calls Nexus’s Account API, which (depending on the functionality available in the Destination country):
      1.
      Maps the alias to an account number
      2.
      Checks the Destination Bank is able to accept Nexus payments
      3.
      Confirms that the Destination Bank is “available” (ie it does not have scheduled or unscheduled downtime right now)
      4.
      Checks that the account is active (not closed or frozen)
    6.
    If the checks above have all been passed successfully, then we have confirmed with a high degree of confidence that the payment can be credited to the Recipient account.
    7.
    Where Confirmation of Payee is available, the Source Bank will call Nexus’s Payee API. This will involve either (a) providing the real account name attached to the Destination Account, so that it can be shown to the Sender, or (b) comparing an expected Recipient name provided by the Sender to the real name on account.
    8.
    Now the various banks or PSPs involved in the payment perform sanctions screening to confirm that neither the Sender nor Recipient are on international sanctions lists. They will do screening against the sanctions lists that apply in their country and communicate through Nexus’s Payment APIs if any of the banks require further information on either the Sender or the Receiver. (See Sanctions Screening for more detail on this process.)
    9.
    Finally, if both banks and the Liquidity Providers approve the Sender and Recipient against sanctions screening, they can agree to accept the payment. The Source app will then proceed to the next screen (below)
Request to Pay
We have not yet designed a Request-to-Pay process for Nexus. Request to Pay essentially allows the Recipient to send a payment request to the Sender, who then approves it. In the most basic implementation, the message (embedded in a link or QR code) sent by the Recipient to the Sender would include all the information required by the Sender to initiate the payment, such as the recipient’s alias or account numbers. More advanced implementations could also include, for example, an invoice ID so that the payment can be reconciled within a specific purchase in the merchant’s point of sale systems.
Request to Pay could be added as a future iteration to Nexus, or as an overlay service.
If a Request to Pay process was used, then the user would skip most of the steps above and proceed straight to Confirmation of Payee.
Last modified 2mo ago
Copy link