How the Destination IPS initiates the payment via the Destination SAP

When Nexus sends a payment instruction to the Destination IPS, the Destination IPS must send that to the Destination SAP. Nexus does not prescribe the process by which the Destination IPS sends the Nexus payment instruction to the Destination SAP; this is the responsibility of the Destination IPS. Possible options are described below.

Requirements for submission of payment instructions to the Destination SAP

Nexus does have a set of minimum requirements regarding this process to ensure that Nexus remains fair, safe, efficient, transparent and open.

Open and fair

• The payment initiation process towards D-SAPs:

  • should be capable of supporting multiple SAPs and should not be designed specifically for a single SAP

  • should be open to any PSP eligible to be an SAP and any PSP which adheres to the Nexus requirements for an SAP

  • must not be limited to specific currency pairs or specific corridors. It should not restrict SAPs to provide services to FXPs for other/additional currencies

  • should be designed to minimize the development, implementation and operational impact on PSPs performing the role of SAP

• SAPs providing services to an FXP should not be limited to providing services to other FXPs for different or the same currency pairs

Use of standards

• The payment initiation process towards D-SAPs should reuse existing domestic standard messages or industry standard messages where possible to minimize impact on PSPs, IPSs and SAPs

• The payment initiation process towards D-SAPs must support real-time payment processing and not introduce delays

Minimizing risks

• The payment initiation process towards D-SAPs should not introduce settlement risks. Settlement should be guaranteed and not be reversible.

• The payment initiation process towards D-SAPs should not introduce credit risks towards the FXP, unless otherwise agreed between the SAP and the FXP. For example, a balance check on the account of the FXP upon executing a payment should not be skipped unless there is an agreement in place to provide a line of credit.

Possible payment initiation methods

For the D-SAP, the submission of the payment instruction from Nexus or Destination IPS to the Destination SAP can be done in multiple ways. The Destination IPS is free to implement one of more of the presented models, as well as design their own model.

Method 1: Payment initiation via Nexus in a pacs.008 message

Upon receiving the payment from the Source Nexus Gateway, the Nexus Gateway forwards the received pacs.008 as a payment initiation request to the D-SAP (via the Destination IPS), to be processed by the D-SAP. In this scenario, the D-SAP treats the FXP as a financial institution to which it provides settlement services.

Process

• After the processing in the Source IPS has completed its first phase, it sends the Nexus pacs.008 to the Nexus Gateway.

• The Nexus Gateway sends the Nexus pacs.008 to the Destination IPS.

• The Destination IPS validates the received Nexus pacs.008 and (upon successful validation) initiates the payment towards the Destination SAP in a pacs.008 (either in Nexus format or enhanced domestic format) message.

  • The D-SAP is able to recognize that it is playing the role of D-SAP because the D-SAP is not identified as Creditor Agent, but as Instructing Agent (in the Nexus pacs.008 format).

• The D-SAP validates the message, validates the identified FXP account and if successful, initiates the destination process of Nexus by sending a pacs.008 message (or domestic equivalent) to the D-IPS. The D-IPS will then process this instruction by making the transfer from D-SAP to D-PSP

  • Depending on the process as designed by the D-IPS, a pacs.002 confirming or rejecting the original pacs.008 message from the D-IPS can also be used.

Implications for the D-SAP

• The D-SAP must be able to receive a pacs.008 instruction and process the pacs.008 similar to a payment initiation request, including payment, account and compliance validations, debit authorization and booking.

• Depending on the requirements of the D-IPS, the D-SAP either responds to the pacs.008 by initiating the domestic processing to the D-IPS (in a pacs.008 or domestic format message) or acknowledges the Nexus pacs.008 with a pacs.002 with code ACTC, followed by the initiation of the domestic processing.

• The D-SAP should be able to reconcile the result of the settlement back to the payment instruction.

Method 2a: Debit Authorization via message or API

In this setup, the D-IPS receives the Nexus pacs.008, and then prepares a debit authorization request which it sends to the D-SAP, via an API call or an ISO20022 camt.103 Create Reservation message. The request specifies the amount to be debited, the account details for the FXP, and an ID that can be reconciled with the IPS’s settlement report.

Process

PlantUML diagram

• After the processing in the Source IPS has completed its first phase, the Source Nexus Gateway sends the Nexus pacs.008 to the Destination Nexus Gateway. The Nexus Gateway has two options:

  • In option 1, the Nexus Gateway sends the Nexus pacs.008 to the Destination IPS. The D-IPS initiates a debit authorization request to the D-SAP.

  • In option 2, the Nexus Gateway initiates the debit authorization request directly to the D-SAP.

• The D-SAP validates the account and the available funds on the FXPs account at the D-SAP.

• The D-SAP can accept or reject the request.

  • In option 1, in case of a positive response, the D-IPS initiates the domestic payment process by sending a pacs.008 to the D-PSP.

  • In option 2, the D-SAP responds to the Nexus Gateway, and the Nexus Gateway initiates the domestic payment process by sending the pacs.008 to the D-IPS, and the D-IPS sends the pacs.008 to the D-PSP.

• The D-SAP ultimately receives the detailed payment information through the settlement report from the D-IPS.

Implications for the D-SAP

• The D-SAP must be able to receive and respond to a debit authorization request via API and should be able to make a funds reservation on the FXP’s account as a result of the request.

• The D-SAP must be able to reconcile the pacs.002 and the settlement report with the debit authorization/funds reservation on the FXP's account and with the settlement of the transaction.

The D-SAP must also be able to rely on the compliance screening done by the D-PSP, as the D-SAP does not receive the full payment information until after settlement.

Whether the D-SAP is willing to rely on the compliance screening done by the D-PSP will depend on local regulations and market practice. However, the fact that the D-SAP does not see the full payment information until after the payment has been completed may mean that Method 2a is not acceptable in a number of jursidictions.

2b. Payment Initiation via API with full payment information

Expanding on the debit authorization method 2a (above), in this model the Nexus Gateway or the Destination IPS (depending on the setup preference) sends a full payment initiation request to the D-SAP via API.

This method is very similar to method 2a of sending a debit authorization via API, with the added benefit of making the full payment information available to the D-SAP.

Process

• After the processing in the Source IPS has completed its first phase, the Source IPS sends the Nexus pacs.008 to the Nexus Gateway.

• The Nexus Gateway sends the pacs.008 to the D-IPS.

• The D-IPS initiates the payment towards the D-SAP by sending the full payment information via a payment initiation API exposes by the D-SAP.

• This allows the D-SAP to perform a full compliance validation on the payment, before confirming the payment.

To confirm the payment, the D-SAP has two options:

• Option 1: the D-SAP confirms the payment by initiating a pacs.008 to the D-IPS, or

• Option 2: the D-SAP confirms the payment by sending an acceptance status to the API and subsequently, the D-IPS forwards the pacs.008 message originally sent from Nexus.

Implications for the D-SAP

Depending on the option chosen, the D-SAP must be able to receive a payment instruction via API, perform the required validations (including, if required by local legislation, compliance checks) and:

• respond to the API call and reconcile the pacs.002 and settlement report back to the payment instruction

• initiate the local settlement via a pacs.008. The D-SAP should be able to reconcile the local settlement with the payment initiation instruction, depending on their requirements

Method 3. Payment Initiation a pain.001 message

In this method, the payment is initiated as a corporate payment by the D-IPS submitting a pain.001 Customer Credit Transfer Initiation message to the D-IPS via the corporate channel of the D-SAP. This allows the D-SAP to reuse an existing payment initiation process that they provide to corporates. They may still need to recognize this as a Nexus payment for compliance reasons, depending on local legislation.

Process

• After the processing in the Source IPS has completed its first phase, the Source IPS sends the Nexus pacs.008 to the Nexus Gateway.

• The Nexus Gateway sends the pacs.008 to the D-IPS.

• The D-IPS initiates the domestic process by sending a pain.001 message to the corporate channel of the D-SAP. After receiving the pain.001 message, the D-SAP must perform all required validations and compliance checks, debit the FXP’s account and initiate the local settlement via a pacs.008 message to the D-IPS.

The D-IPS will need to correlate the pacs.008 received from Nexus with the pacs.008 received from the D-SAP, as the pain.001 cannot contain all the information from the pacs.008 received from Nexus. The following fields cannot be transported in a pain.001 (which are present in the Nexus pacs.008 message):

pain.001 Group Header

The settlement information section is not part of a pain.001, specifically:

• The settlement method is not present

• The clearing system/code is not

pain.001 Transaction information

In the transaction information section, the following fields are missing:

• The Transaction Identification is not present, as this is assigned by the first instructing party

• The Clearing System Reference is not present, as for a pain.001, no settlement has typically taken place yet

• A pain.001 only contains the Instructed Amount in a single currency, with no place for the different Nexus amount fields (such as the Charges Amounts)

• The pain.001 contains a requested execution date instead of an interbank settlement date

• The Acceptance Date Time is not present, as this is typically assigned by the first instructing party

• The Charges Information is not present, as this is typically assigned by the first instructing party

• The Previous Instructing Agent is not present, as there typically is no previous agent for a pain.002 message

• The Instructing Agent and Instructed Agent fields are not present, but the Intermediary Agents and Debtor/Creditor Agents are available.

Consequences for the D-SAP

• The D-SAP must open up its corporate channel for payment initiation coming from the Nexus Gateway or D-IPS. This means that the pain.001 serves the same purposes as a payment instruction coming directly from the FXP (i.e. the FXP telling its PSP to debit its account and initiate a payment towards the Receiver).

Consequences for the D-IPS

• The D-IPS must correlate the pacs.008 received from the D-SAP with the pacs.008 from the Nexus Gateway to enrich the payment with the additional information which cannot be carried in the pain.001.