A number of events can cause the payment to be unsuccessful (aside from technical timeouts). For example:
The Source SAP, Destination SAP or Destination PSP applies sanctions screening and decides it does not want to process the payment, due to issues with either the Sender or the Recipient
The Source PSP may have insufficient funds in their IPS settlement account to make the payment
The Destination SAP checks that balance of the FXP’s account and finds it is insufficient to cover this payment
The Destination SAP’s own settlement account at the IPS has insufficient funds to make the payment to the Destination PSP
The Destination PSP finds that the Recipient’s account is closed, dormant or frozen
In the scenarios above, the participant that triggers the failure will send a pacs.002
with a status code of RJCT
(reject). This will flow back through the system and lead to the payment being reversed.
In a real-time gross system:
If reservations/locks were made against funds held by either the Source PSP or the Destination SAP, these reservations will be released/unlocked.
If funds have already been transferred between (a) the Source PSP and Source SAP OR (b) the Destination SAP and the Destination PSP, these transfers must be reversed.
In a Deferred Net Settlement system:
The record of obligation between (a) the Source PSP and Source SAP OR (b) the Destination SAP and the Destination PSP, must be cancelled or reversed.
This section describes in detail the messages and processing required to achieve the flow of funds above.
We will give a typical payment flow through Nexus below, in detail. However, in practice Nexus is agnostic to exactly what happens within the domestic IPS, as long as the IPS can give two assurances:
the payment does not create unsecured credit risk between the Source PSP and S-SAP or between the D-SAP and Destination PSP, and
that the payment can be reversed if necessary.
These two requirements are described in more detail in Settlement and reversal requirements on IPSs.
The process can be split into distinct parts or “legs” – the Source Leg, the Nexus Leg and the Destination Leg.
Note that Nexus does not require:
Any changes to domestic settlement cycles; there is no need to synchronise settlement cycles between countries
Any awareness within the IPS of any currency other than the domestic currency. The IPS does not need to record balances or transfers in any other currency. (It only needs to ensure that the ISO 20022 payment message going through the IPS retain the necessary information to allow Nexus to manage the FX conversion.)
In the Source leg of the payment, the payment is processed in the Source IPS:
The Sender approves the payment
The Source PSP sends a payment instruction (ISO 20022 message pacs.008
) to the Source IPS (Message 2 in the diagram)
(In some real-time gross models, the IPS will now place a reservation or lock against the funds in the Source PSP’s account, so that those funds cannot be used for other payments.)
The Source IPS forwards the payment instruction (ISO 20022 message pacs.008
) to the Source SAP (who is also a member of the Source IPS) (Message 3)
The Source SAP reviews the payment instruction. As this is a cross-border payment, it must also apply sanctions screening. If it is happy to accept the payment on behalf of the FXP (its customer), it will respond with a payment status message (ISO 20022 message pacs.002) to confirming that it will accept the payment (Message 4)
The next step depends on the settlement model used in the IPS:
The Source IPS now recognises the payment as a Nexus payment, and forwards the original pacs.008
payment instruction message to the Source Nexus Gateway (Message 5).
Note: unlike a domestic payment, the Source IPS would not send a pacs.002
to the two PSPs yet. Instead, it waits to receive the response from Nexus.
Some IPSs may still choose to send a pacs.002 with a status code that informs the PSP that the payment has successfully been sent to Nexus. This would be at the discretion of the IPS and is not required or specified by Nexus.
The Source Nexus Gateway then validates and transforms the payment instruction to prepare it for the second leg by:
changing the instructing and instructed agents to the Destination SAP and Destination PSP respectively
validating the quote that is referenced, updating the currency and applying the currency conversion to the “Interbank Settlement Amount” (for example, validating the quote that is referenced in the message, converting the amount into the destination currency, and updating the instructed and instructing agents).
The Source Nexus Gateway then forwards the payment instruction to the Destination Nexus Gateway (Message 6).
The Destination Nexus Gateway immediately forwards the payment instruction to the Destination IPS (Message 7).
In the Destination Leg, the payment is processed by the Destination IPS:
(Note: in some real-time gross models, the Destination IPS will immediately place a reservation or lock on the funds in the Destination SAP’s account so that they cannot be used for other payments.)
The Destination IPS forwards the pacs.008
payment instruction message that it received from Nexus to the Destination Settlement Account Provider (D-SAP) (Message 8).
The Destination SAP confirms that the FX Provider has sufficient funds with them, and applies sanctions screening and compliance checks.
If the Destination SAP is happy to proceed with the payment, it will:
debit the FXP’s account with them by the amount of the payment, and
submit the pacs.008
payment instruction message to the Destination IPS (Message 9), effectively giving the IPS the instruction to forward the payment to the Destination PSP
The Destination IPS sends the pacs.008
payment instruction message to the Destination PSP (Message 10).
The Destination PSP will apply sanctions screening and compliance checks before deciding whether to accept the payment.
If the Destination PSP is happy to accept the payment they will then return a pacs.002
payment status message accepting the payment instruction (Message 11).
The next step depends on the settlement model used in the IPS:
The Destination IPS sends a confirmation (pacs.002
) of the successful transfer to the Destination SAP (Message 12a)
The Destination IPS sends a confirmation (ISO 20022 message pacs.002
) of the successful transfer to the Destination PSP (Message 12b)
The Destination PSP credits the Recipient’s account and informs the Recipient (9) that they have received funds. (Message 12c)
The Destination IPS then sends a pacs.002
acceptance message to the Destination Nexus Gateway to inform Nexus that Destination leg is complete (Message 13).
The Destination Nexus Gateway transforms the pacs.002
and forwards it to the Source Nexus Gateway (Message 14).
The Source Nexus Gateway forwards the message to the Source IPS (Message 15).
If the Source IPS uses a real-time gross settlement model and placed a reservation on the funds in bullet 1(a) above, they will now finalise the payment between the Source PSP and Source SAP by:
debiting the Source PSP’s settlement account at the central bank, and
simultaneously crediting the Source SAP’s settlement account at the central bank
The Source IPS will send the Source SAP a pacs.002
confirmation that the payment has been successful (Message 16a)
The Source IPS will send the Source PSP a pacs.002
confirmation that the payment has been successful (Message 16b)
The Source PSP can now inform their Sender that the payment is complete (Message 16c).
Finally, the Source Gateway informs the FXP that a payment has been processed using their quote (Message 17); this is important to enable the FXP to keep track of their liquidity.
(The FXP may also be separately updated of their account balances by the Source and Destination Settlement Account Providers.)
The Destination PSP is responsible for immediately crediting the Recipient with funds. In practice this means that the payment should be visible on the Recipient’s statement and the funds should be available for them to spend.
The Source PSP is responsible for immediately notifying the Sender that this payment was successfully completed. It is up to the Source PSP to choose how to do this, but the Sender should be able to establish with certainty that the payment is complete.
SETTLEMENT MODEL
ACTION
Deferred Net Settlement
Record an obligation from the Source PSP to the Source SAP by
debiting the Source PSP and
simultaneously crediting the Source SAP
Real-time Gross – Reservation Model
No action taken (because the funds are secured and the debit/credit action will only be done when the Destination Leg is complete).
Real Time Gross – No Reservation Model
Immediately transfer funds from the Source PSP to the Source SAP by:
debiting the Source PSP’s settlement account at the central bank, and
simultaneously crediting the Source SAP’s settlement account at the central bank
SETTLEMENT MODEL
ACTION
Deferred Net Settlement
Record an obligation from the Destination SAP to the Destination PSP by
debiting the Destination SAP and
simultaneously crediting the Destination PSP
Real-time gross – Reservation Model
Immediately transfer funds from the Destination SAP to the Destination PSP by:
debiting the Destination SAP’s settlement account at the central bank, and
simultaneously crediting the Destination PSP’s settlement account at the central bank
Real-time Gross – No Reservation Model
Same as for Real-time gross - Reservation Model