BIS Innovation Hub
Nexus - Short ReportAbout the BIS Innovation Hub
  • Introduction
    • Nexus Overview
    • How to use this site
    • Overview Report
    • Terminology
  • Payment Setup
    • Key Points
    • Scope of Nexus payments
    • Steps 1-2: Country, Currency & Amount
    • Steps 3-6: Exchange Rates
    • Steps 7-9: Addressing, Proxy Resolution & Confirmation of Payee
    • Steps 10-11: Sanctions screening
    • Step 12: Ask the Sender for approval
    • Step 13-16: Set up and send the payment instruction
    • Step 17: Accept the confirmation and notify Sender
  • Addressing & Proxy Resolution
    • Key Points
    • Overview of Payment Addressing in Nexus
      • Addressing via Proxies (Aliases)
      • Addressing via Account Details
    • Address Types & Inputs
      • Address Types
      • Address Inputs
      • Financial Institution Identification
      • List of PSPs
      • Examples
    • Proxy & Account Resolution Process
      • Step 1: Sender inputs proxy or account details
      • Step 2: Proxy Resolution Messaging Sequence
      • Step 3: Account Resolution Messaging Sequence
      • Step 4: Source PSP processes the results
      • Masking of Display Names
    • Role of the Proxy Directory Operator (PDO)
      • Obligations on the Proxy Directory Operator
      • Obligations of PSPs using the Proxy Directory
      • Onboarding a Proxy Directory Operator onto Nexus
  • FX Provision
    • Key Points
    • Role of the FX Provider
    • How Third-Party FX provision works in Nexus
    • Joining Nexus as a third-party FXP
    • Accessing Instant Payment Systems
    • Onboarding PSPs
    • Obligations & Compliance
    • Revenue model for FXPs
    • Rates from Third-Party FX Providers
      • Improving rates for larger transactions
      • Improving rates for specific PSPs
    • Quotes
    • Managing Liquidity
  • Payment Processing
    • Key Points
    • Accounts & Relationships
    • Maximum value of a Nexus payment
    • Payment Flow (Happy Path)
      • Detailed Flow in Source Country (Sending)
      • Detailed Flow in Destination Country (Receiving)
      • Booking flow for Source PSPs
      • Notifying FXPs of completed payments
    • Validations, Duplicates & Fraud
    • Time critical vs non-time critical payments
    • Special Scenarios
    • Payment setup for PSPs who provide their own FX
    • Unsuccessful Payments (Exceptions)
      • Rejects
      • Recall Requests
      • Returns
      • Investigation & Enquiry
      • Disputes
      • Reconciliation reports
    • Fees
    • Role and responsibilities of the Instant Payment System Operator (IPSO)
    • Ensuring settlement certainty
    • Annex: 4-step vs 5-step Processes in Domestic Clearing and Settlement
    • Annex: Sponsoring PSPs and Sponsored Entities
  • Settlement Access Provision
    • Key Points
    • Role of the Settlement Access Provider (SAP)
    • Joining Nexus as an SAP
    • SAP onboarding of FXPs (or foreign PSPs)
    • Costs and Revenue for SAPs
    • Obligations on the SAP
    • Processing payments as an SAP
      • Payment Process for the Source SAP
      • Payment Process for the Destination SAP
      • How the Destination IPS initiates the payment via the Destination SAP
    • Managing Liquidity as an SAP
  • Messaging & Translation
    • Key Points
    • General Usage of ISO 20022
      • Adherence to CPMI Harmonised ISO 20022 Data Requirements
    • Compatibility with Instant Payments Plus (IP+)
    • Message transformation by Nexus
    • Specific Message Elements
    • Purpose Codes
    • Message Guidelines (Excel)
    • MESSAGE acmt.023 Identification Verification Request
    • MESSAGE acmt.024 Identification Verification Report
    • MESSAGE: pacs.008 FI to FI Customer Credit Transfer
      • pacs.008 Differences from CPMI Harmonisation Requirements
    • MESSAGE pacs.002 Payment Status Report
      • pacs.002 Differences from CPMI/CBPR+ Guidelines
    • MESSAGE: pacs.004 Payment Return (Not yet supported)
    • MESSAGE: camt.054 Bank to Customer Debit Credit Notification
    • Translation To/From Domestic Message Formats
    • Translating To/From ISO 20022 Codes
  • APIs
    • Overview
    • Countries
    • Currencies
    • Address Types and Inputs
    • Financial Institutions
    • Fees and Amounts
    • Intermediary Agents (SAPs)
    • Quotes
    • ISO 20022 Messages
  • About
    • Contact the Nexus Team
  • LEGAL
    • Terms and Conditions of Use
    • Privacy Notice
    • Cookies Notice
Powered by GitBook
On this page
  • Time-critical payments
  • Non-time critical payments
  • Following up on an ACWP response
Export as PDF
  1. Payment Processing

Time critical vs non-time critical payments

A payment can be time critical when the use case requires near-instant confirmation of rejection, for example when paying in-store, or non-time critical, for example when using Nexus for bill payments.

Whether a payment is time-critical or not is flagged using the pacs.008 Instruction Priority element(/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/).

In general the Source PSP should set the Instruction Priority, based on what it knows about the type of payment that is being initiated. For example, payments to a retail business, or initiated by scanning a QR code, are more likely to be time sensitive. If the Sender is asked to select the priority, they should be informed of the implications of their choice.

Time-critical payments

Time-critical payments must only be accepted by the Destination PSP when the Destination PSP is (a) able to perform real-time sanction screening, AND (b) if the screening is OK, the Destination PSP is able to credit the recipient in real time.

  • The Source PSP should set the pacs.008 Instruction Priority to HIGH

  • Within the timeout SLA of the Destination IPS, the Destination PSP must process the payment and return a pacs.002 with one of the following status codes:

    • ACCC – accepted and credited to recipient

    • RJCT – rejected

    • BLCK - funds blocked and will not be returned (due to suspicious or illicit activity)

  • The pacs.002 will flow from the Destination PSP to Destination IPS, to Nexus, to the Source IPS and finally to the Source PSP.

Non-time critical payments

  • The Source PSP should set the pacs.008 Instruction Priority to NORM (pacs.008 element /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/ ) when the payment is non-time-critical.

  • Within the technical timeout SLA of the Destination IPS, the Destination PSP must process the payment and send back a pacs.002 with one of the following status codes:

    • ACCC – accepted and credited to recipient

    • RJCT – rejected

    • BLCK – funds blocked and will not be returned (due to suspicious or illicit activity)

    • ACWP – accepted without posting to the Recipient’s account

  • The pacs.002 will flow from the Destination PSP to Destination IPS, to Nexus, to the Source IPS and finally to the Source PSP.

  • (Note: The Source SAP may only respond with ACCC or RJCT.)

Note that the Destination PSP must still respond with one of the above status codes within the timeout of the Destination IPS (typically 30 seconds or less), to ensure the Sender has certainty about the status of the payment.

If the Destination PSP responds with the status code ACWP, the Destination IPS must still complete the transfer between the Destination SAP and Destination PSP, but the Destination PSP will not immediately credit funds to the Recipient.

Following up on an ACWP response

When the Destination PSP responds with ACWP, the Destination IPS will finalize the settlement, and send a confirmation to Nexus. From Nexus's perspective, all payment processing through the IPSs is now complete and the payment has been settled. But further steps are required to update the Sender on the final status of the payment.

After the Destination PSP responds with ACWP, then within the time limit set in the Nexus Scheme Rulebook, the Destination PSP must respond with:

  • ACCC (Accepted and Credited to Creditor Account) – funds now credited to the recipient

  • BLCK (Blocked) – funds blocked and will not be returned (due to suspicious or illicit activity)

  • ACWC (Accepted with Changes) with status reason code (StsRsnInf/Rsn/Cd) RUTA (Return upon Unable To Apply) - in this case, the Destination PSP was not able to reach a definitive answer within the time limit specified in the Nexus Scheme Rulebook. The Destination PSP must initiate a new Nexus payment to return the funds to the Source PSP

Note: This process assumes the Destination PSP is the party performing the compliance checks. In some jurisdictions (f.e. India), it is the Destination SAP who performs the compliance validations. In this case, the Destination SAP is able to respond with either:

- A new pacs.008 for the initiation of the destination leg of the Nexus payment

- A pacs.002 with RJCT in case the Destination SAP is not able to process the payment

As the Source SAP has not received funds, it cannot block any funds. It is also not able to accept the payment without posting (ACWP), as this only applies to the Recipient’s account. As a result, for these jurisdictions, the non-time critical may not result in different processing.

The Nexus Scheme Rulebook defines the maximum time in which an ACWP payment must be credited to the Recipient, blocked or returned.

PreviousValidations, Duplicates & FraudNextSpecial Scenarios

Last updated 1 month ago