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
  • pacs.002 Status for time-critical payments
  • pacs.002 Status for non-time critical payments
Export as PDF
  1. Payment Setup

Step 17: Accept the confirmation and notify Sender

PreviousStep 13-16: Set up and send the payment instructionNextKey Points

Last updated 7 months ago

When the Destination PSP accepts the pacs.008 payment instruction, they will respond with a pacs.002 status report, which will be sent back to Nexus. Nexus will forward the pacs.002 to the Source IPS, who will forward it to the Source PSP.

pacs.002 Status for time-critical payments

For a pacs.008 with an instruction priority of HIGH, the pacs.002 will have one of the following status codes (found in /Document/FIToFIPmtStsRpt/TxInfAndSts/TxSts/):

  • ACCC: the Destination PSP has accepted the payment and credited the Recipient’s account

    • The Source PSP should inform the Sender that the payment has successfully reached the Recipient

  • RJCT: the Destination PSP payment has been rejected. A reason code may provide further information. In the Source IPS, any reservation of funds against the Source PSP has been cancelled and any movement of funds from the Source PSP to the Source Settlement Account Provider has been reversed.

    • The Source PSP should inform the Sender that the payment could not be made.

pacs.002 Status for non-time critical payments

For a pacs.008 with an instruction priority of NORM, two addition status codes are possible (in addition to ACCC and RJCT):

  • ACWP (Accepted Without Posting): The funds have reached the Destination PSP, but have not yet been credited to the Recipient’s account. This may be because the payment triggered a sanctions screening alert which needs to be manually reviewed.

    • When ACWP is received, the Source PSP must inform the Sender that the payment is still being processed but has not yet been credited to the Recipient. The Source PSP should ensure the Sender knows how to confirm if/when the payment has been completed (eg via a notification from the app, or by checking their statement)

An ACWP response must be followed up later with one of the following outcomes. The follow-up response must be sent within the Service Level Agreement time defined in the Nexus Rulebook (currently proposed to be 2 hours):

  • A pacs.002 with the status ACCC, meaning that the Recipient’s account has been credited.

  • A pacs.002 with the transaction status BLCK, meaning that the funds will not be returned to the Sender and have not been credited to the Recipient. This is most likely in the case that the payment was identified to be illicit after sanctions screening.

  • A pacs.002 with the transaction status ACWC (Accepted With Changes) meaning that the Destination PSP has been unable to ascertain whether the payment can be accepted or not. This may mean that the Destination PSP was unable to resolve a sanctions screening alert within the time limit defined in the Nexus Scheme Rulebook.

    • This will be followed by a pacs.008 or message returning the funds.

    • The Source PSP should inform the Sender that the payment has been unsuccessful and that the funds will be returned to the Sender’s account.

If the ACCC message is received, the Sender should be notified (possibly through a notification or update on the app/online banking, or via an update to their statement).

What to read next?

Further information on each step is given in the corresponding sections:

pacs.004
Addressing and Proxy Resolution
FX Provision
Payment Processing
Settlement Access Provision
Messaging & Translation
Most payments should complete in 60 seconds