From domestic payments to cross-border

Overview

This chapter describes how a Nexus payment is processed across two instant payment systems (IPS). We start with a description of the typical payment process for a domestic payment, before building up to a full explanation of how Nexus payments would work across two independent IPSs.

Readers who are familiar with domestic IPS settlement methods (including deferred net settlement and real time gross settlement) may wish to skip to Flow of funds through Nexus or Detailed messaging and processing.

Typical domestic payment process (5-message flow)

To understanding the Nexus payment sequence, it’s helpful to start with the typical 5-message process typically used within an IPS for a domestic payment:

1. The Source PSP sends a payment instruction (usually ISO 20022 message pacs.008) to the IPS (Message 2)

2. The IPS forwards the payment instruction (pacs.008) to the Destination PSP who is also a member of the IPS (Message 3)

3. The Destination PSP reviews the payment instruction. If it is happy to accept the payment on behalf of the Recipient, it will confirm by responding to the IPS with a payment status message (ISO 20022 message pacs.002) (Message 4)

4. The IPS will then process a payment from the Source PSP to the Destination PSP by:

   1. debiting the Source PSP, and

   2. simultaneously crediting the Destination PSP

5. The IPS sends a confirmation (pacs.002) of the successful transfer to the Destination PSP (Message 5a)

   1. The Destination PSP will credit the recipient and notify them (Message 7)

6. The IPS sends a confirmation (pacs.002) of the successful transfer to the Source PSP (Message 5b)

   1. The Source PSP will notify the Sender that the payment has been successful.

In instant payment systems, this process typically takes a few seconds.

Real-time Gross vs Deferred Net Settlement (DNS)

IPSs typically follow one of two settlement models:

Immediate settlement in central bank money, in which individual transactions are processed by immediately transferring central bank money between IPS members.

• This model is also known as real-time gross settlement, but may be a distinct platform from the “RTGS” platforms commonly used for larger and wholesale payments between financial institutions.

Examples of IPSs that use real-time gross settlement include TIPS in the Eurosystem, Brazil’s PIX, and Australia’s New Payments Platform (NPP)

Deferred Net Settlement, in which:

• individual transactions are processed immediately, creating obligations between the IPS members

• on a pre-determined schedule, the gross flows between IPS Members are netted, and the net differences are settled by a transfer of central bank money across accounts at the central bank

Examples of IPSs that use Deferred Net Settlement include Singapore’s FAST, Malaysia's RPP and the UK’s Faster Payments Service.

Step 4 above differs slightly depending on the settlement model used in the IPS.

If the IPS uses a real-time gross model, step 4 triggers the immediate transfer of funds between accounts at the central bank:

• The Source PSP’s settlement account at the central bank is debited

• The Destination PSP’s settlement account at the central bank is credited

Settlement is therefore immediate (real-time) and there is no netting of obligations (so the gross value of the transaction is settled).

In contrast, in a Deferred Net Settlement (DNS) model, settlement takes place at a later time (ie it is deferred). This works as follows:

• Message 4 triggers a debit/credit operation which creates a record of an obligation from the Source PSP to the Destination PSP. Every other payment creates similar obligations.

• At pre-set times each day, the IPS will net this obligation against the obligations created by many other payments, and will calculate the net obligation that each PSP must pay. This obligation might be positive (the PSP owes money to other PSPs) or negative (the PSP is owed money).

• These net obligations are then settled through transfers between settlement accounts at the central bank.

Nexus is designed to be compatible with both DNS and real-time gross settlement models, although there are some variations that are addressed below.

Extending the process across 2 IPSs

The challenge for Nexus is to achieve the same outcome – a near-instant transfer from the Sender’s account to the Recipient’s account – when:

1. The Source PSP and the Destination PSP are in different countries

2. The Source PSP is not a member of the IPS in the Recipient’s country (the Destination IPS), and the Destination PSP is not a member of the IPS in the Sender’s country (the Source IPS)

3. The Source IPS and Destination IPS operate in different currencies

4. The Source PSP does not hold the Recipient’s currency, and the Destination PSP will not accept the Sender’s currency

To make a transfer between PSP-A and PSP-B work, we need to add two key elements:

1. A system that allows communication and coordination between the Source IPS and Destination IPS – this is facilitated by Nexus, through the Nexus Gateways

2. A party who is willing and able to accept the Sender’s currency in exchange for paying out the Recipient’s currency. This is the FX Provider (FXP)

   • The FX Provider must be able to send and receive payments in both the Source IPS and Destination IPS

   • The FXP will receive funds from the Source PSP via the Source IPS

   • The FXP will pay out funds to the Destination PSP via the Destination IPS

The FXP may be a member of both IPSs. However, if they are not, they can open accounts with a PSP that is already a member of the IPS; this PSP then acts as Settlement Account Provider (SAP) to the FXP. For further details, please see Accessing instant payment systems.

For the examples below, we will assume that the FXP is not a member of either IPS and so uses an SAP in the Source IPS (the Source SAP) and an SAP in the Destination IPS (the Destination SAP).

FIGURE: Participants required to process a Nexus payment

We can now identify all the parties involved in processing a Nexus payment:

1. The Source PSP, who initiates the payment on behalf of the Sender (their customer)

2. The Source Settlement Account Provider (S-SAP), which holds an account on behalf of the FXP (their customer) and accepts funds in the source currency into that account

3. The Source IPS, who is responsible for processing the payment between the Source PSP and Source SAP

4. The Destination PSP, who holds an account on behalf of the Recipient (its customer)

5. The Destination Settlement Account Provider (D-SAP), which hold an account on behalf of the FXP (its customer) and pays out funds from that account to the Destination PSP

6. The Destination IPS, which is responsible for processing the payment from the Destination SAP to the Destination PSP.

7. The Nexus Gateways in both the Source and Destination countries. These Gateways handle cross-border communication and transformation of some messages as they pass from one IPS to another

8. The FX Provider. However, although the FXP provides its rates to Nexus earlier, the FXP itself is not part of the communication chain when a Nexus payment is processed. (This is because the S-SAP and D-SAP can assume that if they receive a Nexus payment instruction, the instruction will be (or has already been) validated against the quote provided by the FXP, and that if validation of the quote fails, the payment will be immediately reversed.