Overview of Payment Flow

The overall flow of a single payment flowing through Nexus is presented below:
A payment through Nexus goes through the following stages (each step is described in more detail below):
  1. 1.
    Retrieving the Service Level Description (SLD): After the Sender has selected the Destination Country, The Source Bank will ask Nexus for the SLD of the Destination IPS, so it can ask the customer for the correct information (eg an alias or account number, and possibly the Recipient’s name depending on the type of Confirmation of Payee offered). This uses the SLD API.
  2. 2.
    Retrieving a Quote: The Source Bank will also ask Nexus for quotes to the Destination Country. It can ask for the best quote available, or specify a specific FX Provider (including, in some cases, itself). This uses the Quote API.
  3. 3.
    Account Validation: After the Sender has provided an account number or alias, the Source Bank will ask Nexus to validate the account. This involves (a) mapping the alias (if used) to an account number, (b) checking that the Recipient’s bank is enabled to receive Nexus payments and (c) checking that the Recipient’s account is technically able to accept payments (ie it is not closed or frozen). This uses the Account API.
  4. 4.
    Confirmation of Payee: This process allows the Sender to verify that the holder of the Destination Account is actually the person (or business) they intend to pay. Some CoP models require the Sender to provide the expected name and then compare this to the real name on the account. They return the degree to which the two names match (eg Exact, Close, None). Other models simply retrieve the real name from the Destination Bank, and return it (possibly partially masked for data protection). The real name is then shown to the Sender. This uses the Payee API.
  5. 5.
    Sanctions Pre-Screening: The banks involved in a Nexus payment perform screening on the Sender and Recipient according to regulatory requirements. If either Sender or Recipient trigger an alert, the banks can communicate through a Nexus-provided Request-for-Information API to request further information on the Sender or Recipient. This further information can be provided immediately or simply included in the final payment instruction. This uses the Sanctions Screening Pre-Approval API.
  6. 6.
    Final payment instruction: When all the checks above have been completed, there is a much higher degree of confidence that the payment will successfully complete. The payment instruction can now be sent from the Source Bank to the Source IPS. Once the payment is complete in the Source IPS, the Nexus Gateway will communicate with the Nexus Gateway in the Destination Country, who will trigger the second stage of the process in the Destination IPS. Once this stage is complete, the Recipient will be credited and notified, and the Sender will be notified that their payment was successful. (This instruction is sent directly to the Source IPS in the local message format, so does not use a Nexus API.)
Nexus also manages some supporting processes which take place outside of the core payment flow:
  • Compiling quotes from the FX providers (a frequent and continuous process).
  • Synchronizing copies of SLDs of IPSs (an infrequent, ad-hoc process).
Two important processes sit entirely outside the Nexus arrangement:
  1. 1.
    Settlement in the domestic IPS, for IPSs that use deferred net settlement. IPSs using a DNS model settle up in central bank money at pre-defined points times in the day (ie the end of the settlement cycle). This settlement process occurs independently of any processes in Nexus. Nexus does not require IPS settlement times to be changed from their current schedules and does not require settlement times to be synchronized between countries. Nexus is fully compatible both with IPSs running Deferred Net Settlements and Real-Time Gross settlement models (such as TIPS or the New Payments Platform in Australia).
  2. 2.
    Any bilateral settlement of cross-border exposures between FX Providers and Liquidity Providers at either end of the payment flow. These exposures are for the FX Provider to manage through bilateral agreements with its Liquidity Providers.