Appendices

Information flow – Payment Status – Standing Orders

This version is:

This is the latest version Published 2 months ago 28 Jun 2024

The Open Banking Standard has been updated to allow ASPSPs to provide PISPs with enhanced payment status information for supported payment types (as described in the User Journey section below) , including:

  • Status any time after staging the payment and submission. 
  • Meaningful status messages and reasons why the staged payment or submitted payment is stuck in a particular state. 
  • Confirmation that the payment order has been received and executed. 
  • Enriched list of payment status messages and reasons for failures through the initiation, processing and execution stages. 
  • List of faster payment reasons for failure post execution at the receiving bank (other payment schemes not provided). 

Other pages in this section

User Journey

The Open Banking Standard has been updated to allow ASPSPs to provide the PISPs with the following payment status information: 

All below figures read – Green in Bold as required and Orange in Italic as recommended

CX and other processing requirements

Payment Consent Response Status

Note: For various reasons the consent may not move to its next natural stage of ‘Authorised’ or ‘Rejected’ if the PSU is not redirected to the ASPSP for authentication. In this case, the ASPSP must populate the appropriate reason code(s) after timeout.

Figure 1 : Staged Consent
Status CodeStatus Reason CodeStatus Reason Description
AWAUU036Authorisation not completed
Example 1 : Staged Consent

Extract of error message for a Failed to stage Consent
“ErrorCode”: “U001”,
            “Message”: “UK.OB.Field.Expected”,
“Path”: “Data.Initiation.CreditorAccount.Name”

B. PSU Authentication Status

If standing order consent is set up successfully, the PSU is redirected to the ASPSP for authentication. If the PSU authenticates successfully, then: 

Figure 2 : Authenticated Consent
Status CodeStatus Reason CodeStatus Reason Description
AUTH
Example 2 : Authenticated Consent

If the PSU call to action leads to the PSU cancelling the payment, then the status of the standing order consent should become ‘RJCT’ which means ‘Rejected.

Note: For various reasons, the consent may be considered as ‘Rejected’, in which case the ASPSP must populate the appropriate reason codes, e.g.:

Figure 3 : Rejected Consent
Status CodeStatus Reason CodeStatus Reason Description
RJCTU037Authorisation failed (after x attempts)
RJCTCN01Authorisation Cancelled
Example 3 : Rejected Consent

A PISP could make a call to the ‘GET’ standing order consent status endpoint at this stage to find out if the standing order consent resource has been updated to ‘AUTH’ which means ‘Authorised‘ or ‘RJCT’ which means ‘Rejected’.

If the PSU does not authenticate successfully, then there is no authorisation code sent back to the PISP. However, ASPSP must respond with error information back to the PISP. The error information must include the reason(s) codes as specified below. The status of the standing order consent resource should still be ‘AWAU’ which means ‘Awaiting Authorisation’. The PISP may notify the PSU in order to decide whether to redirect the PSU again to the ASPSP or take some other action.

Figure 4 : Awaiting Authentication Consent
Status CodeStatus Reason CodeStatus Code Description
AWAUU036Authorisation not completed 
AWAUU000UK.OB.UnexpectedError
AWAUU037Authorisation failed
Example 4 : Awaiting Authentication Consent
C. Payment Initiation Response Status

In the case that the standing order consent has been authenticated by the PSU, the PISP will submit the standing order to the ASPSP. If the standing order request has been successfully submitted to the sending bank:

  • the standing order consent resource status should become ‘COND’ which means ‘Consumed’.

  • ASPSP should use the additional status ‘ACTC’ which means ‘Accepted Technical Validation’ to indicate that technical validations on the standing order resource have been successfully completed.

  • ASPSP should use the additional status ‘PATC’ which means ‘Partially Accepted Technical Correct’ instead of ‘ACTC’ to indicate that though technical validations are completed, the standing order needs multiple authentications to be completed before the ASPSP starts further processing.

  • ASPSP should also use the additional status ‘ACCP’ which means ‘Accepted Customer Profile’ when the customer profile checks have been completed

Figure 5 : Consent Consumed
Status CodeStatus Reason CodeStatus Reason Description
CONDU038Consent consumed successfully
Example 5 : Consent Consumed
Status CodeStatus Reason CodeStatus Reason Description
RCVDU030Standing order successfully received
Example 6 : PO Received
  • a new standing order resource is created. The status of the standing order at this state should be  ‘RCVD’ which means ‘Received’. The ASPSP responds to the PISP that the request has been successful (201 message) including the standing order status.

If the request fails, a 4xx series message with status reason code(s) is sent back to the PISP. In such a situation the PISP will have to rely on the status reason(s) provided in the error message as the standing order was not successfully created. Depending on the reason code the PISP could make the decision whether to submit the standing order again or not.

Status CodeStatus Reason CodeStatus Reason Description
PDNGU031All checks yet to start
Example 7: standing order is pending processing

If the standing order cannot be processed immediately on receipt due to pending checks and validations needing to be done, the standing order resource is updated with ‘PDNG’ which means ‘Pending’ status and an appropriate status reason is provided.

Status CodeStatus Reason CodeStatus Reason Description
INCOU0xxInitiation of Standing order is completed
INFAInitiation of Standing order failed
Example 8: standing order is pending processing

The ASPSP then completes initiation of the standing order and marks the standing order resource status as ‘INCO’ which means ‘Initiation completed’. This is a terminal state allowing the ASPSP to then process individual payments from the standing order as setup. 

In case the Initiation has failed, the ASPSP could use status ‘INFA’ which means ‘Initiation failed’ or ‘RJCT’ which means ‘Rejected’. Provided an appropriate reason(s) is given using the Status Reason code of the GET call.

D. Further Payment Initiation Status
Figure 6: Individual payment from SO lifecycle

If the standing order is initiated successfully and the standing order resource is in state ‘INCO’ which means ‘Initiation complete’ status), then the ASPSP must initiate individual payments on expected date.

Standing order can be cancelled by the PSU at their ASPSP within agreed time limits . Once cancelled, the ASPSP must update the standing order status to ‘CANC’ which means ‘Cancelled’ with appropriate reason.

On the payment date, the sending bank processes the payment and updates the status to ‘ACSP’ which means ‘Accepted Settlement In Process’).

If the payment fails initiation, then the status must be updated to ‘RJCT’ means ‘Rejected’.

For those that fail initiation due to business or technical validations, the ASPSP must provide all the appropriate status reason codes when the PISP makes a call to the GET payment status endpoint.

For those that fail initiation due to business or technical validations, the ASPSP must provide a 4xx series message with a failure status reason code(s) to the PISP. The same status reason code(s) is updated against the ‘RJCT’ status of the payment order resource.

Status CodeStatus Reason CodeStatus Reason Description
RJCTAM04Insufficient Funds
ACSP
Example 9: Payment order ACSP

Depending on the status reason code(s) the PISP could make the decision whether to submit an individual payment order again or whether it is a one-off error due to insufficient funds at that instance.

ASPSP should use the additional status ‘ACTC’ which means ‘Accepted Technical Validation’ to indicate that technical validations on the payment order resource have been successfully completed.

ASPSP should use the additional status ‘PATC’ which means ‘Partially Accepted Technical Correct’ instead of ‘ACTC’ to indicate that though technical validations are completed, the payment order needs multiple authentications to be completed before the ASPSP starts further processing.

ASPSP should also use the additional status ‘ACCP’ which means ‘Accepted Customer Profile’ when the customer profile checks have been completed.

Status CodeStatus Reason CodeStatus Reason Description
RJCTAM14Amount Exceeds Agreed Limit
ACFCU040
ACSPU032
Example 10: Payment order ACSP

If all the checks are completed, the payment order resource status should become ‘ACSP’ which means ‘Accepted Settlement In Process’ unless the ASPSP is performing a funds check prior to this stage which means the payment order status is changed to ‘ACFC’ which means ‘Accepted Funds Checked’.  The payment will then proceed to the payment processing phase.

If any of the checks fail, the payment order resource status should become ‘RJCT’ means ‘Rejected’.

A PISP could make a call to the ‘GET’ payment details status endpoint at this stage to find the status of the payment after (i.e., payment order resource status is ‘ACSP’ which means ‘Accepted Settlement In Process’) and the payment progressed to the payment processing stage, or the payment initiation has failed (i.e., payment order resource status is ‘RJCT’) means ‘Rejected’).

E. Payment Processing Status
Figure 7: Individual payment from SO processing statuses

The payment order during payment processing may undergo further checks. Further to these checks:

Status CodeStatus Reason CodeStatus Reason Description
RJCTAM04Insufficient Funds
Example 11: PO processing rejections

If any of the checks fail, then the status of the payment order resource must become ‘RJCT’ which means ‘Rejected’.

Status CodeStatus Reason CodeStatus Reason Description
ACWCDT06Execution Date Changed
Example 12: PO processing status ACWC

In some instances, the ASPSP may process the payment with a change (e.g., the desired future date may be changed if, for example, it falls on a date payments aren’t sent like a weekend, or the payment method might be changed e.g. from faster payment to Bacs) in which case the ASPSP should mark the status as ‘ACWC’ which means ‘Accepted with Change’ and provide an appropriate status reason for the PISP to check using the GET payment order status and GET payment order status detail endpoints.

Status CodeStatus Reason CodeStatus Reason Description
ACSC
Example 13: PO processing status ACSC
  • A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment processing has been successful (i.e. payment order resource status is ‘ACSC’ which means ‘AcceptedSettlementCompletedDebitorAccount’) and the payment has progressed to the payment execution stage, or the payment processing has failed. (i.e. payment order resource status is ‘RJCT’ which means ‘Rejected’).

Note: In several situations (such as in single domestic payments), the progress from payment initiation to payment processing and further to payment execution will happen extremely quickly and the status that could be returned by the payment order submission response or call(s) to the GET status endpoint, will be one of the statuses described in items C, D or E. This may also depend on the implementation by various ASPSPs.

F. Payment Execution Status
Figure 8: Individual payment from SO execution statuses

If the payment processing is successful and the payment is sent to the underlying payment system, the payment may undergo further checks by the payment system (or scheme if applicable), intermediary Financial Institutions and the receiving ASPSPs and banks. These checks may include technical and business parameters/rules specific to the underlying payment system, fraud/sanctions and business rules checking at the intermediary or receiving banks and other checking and validations related to the payment execution (subject to various implementations by relevant parties). For further details of these checks for faster payments, please refer to section Payment Systems specific information – FPS payment types and status.

Further to these checks:

Status CodeStatus Reason CodeStatus Reason Description
RJCT1160Receiving account closed
Example 14: PO execution rejections

If any of the checks fail, then the status of the payment order resource status must become ‘RJCT’ which means ‘Rejected’.

Status CodeStatus Reason CodeStatus Reason Description
BLCKAC06Blocked Account
BLCKAM07Blocked Amount
Example 15: PO execution blocked

If for any reason, the receiving bank identifies that the beneficiary account is blocked or the funds need to be blocked, the funds will not be returned to the sending bank, then the status of the payment order resource status must become ‘BLCK’ which means ‘Blocked’. There are limitations on some payment rails in providing this information as they may not be ISO 20022 enabled.

Status CodeStatus Reason CodeStatus Reason Description
ACWP0081Expected on same day
Example 16: PO execution ACWP

If all aspects of the payment execution are successful, then:

  • If the receiving ASPSP confirms that they have received the payment but have not credited the beneficiary account yet, then the payment order resource status must become ‘ACWP’ which means ‘Accepted Without Posting’. The receiving ASPSP will provide a specific reason code in such instances to the sending ASPSP. The sending ASPSP must provide this alongside the payment order resource status under the status reason code.
Status CodeStatus Reason CodeStatus Reason Description
ACCC0000Credited to beneficiary account
Example 17: PO execution completed

If the receiving ASPSP confirms that they have received the payment and have applied the credit to the beneficiary account, then the payment order resource status should become ‘ACCC’ which means ‘Accepted Settlement Completed Creditor Account’.

A PISP could make a call to the ‘GET’ payment details status endpoint at this stage to find out if the payment execution has been successful (i.e. payment order details resource status is ‘ACWP’ which means ‘Accepted Without Posting’) or ‘ACCC’ which means ‘AcceptedSettlementCompletedCreditorAccount’), or the payment execution has failed (i.e. payment order details resource status is ‘RJCT’ which means ‘Rejected’).

Note: There are edge cases where the payment has been received by the receiving ASPSP but the payment cannot be applied to the PSU account and thus is returned to the originating ASPSP. These cases cannot be covered by the payment status as they are returned payments and will appear as incoming credits to the PSUs account. For details on edge cases for faster payments, please refer to the  section Payment Systems specific information – FPS payment types and status.

The PISP should be able to check all the statuses that the payment has gone through from payment initiation to payment execution using the GET status payment details endpoint. It should also enable the PISP to see the various historical reasons of why the payment has been in a specific state before it reached the terminal state.

The only terminal states are

Terminal StateMeaning
‘CANC’ – CancelledPSU has cancelled a non immediate payment at their ASPSP. This could be a Future Dated Payment that is warehoused at the ASPSP or a Standing Order or a VRP.
‘RJCT’ – RejectedEither the sending bank or receiving bank have rejected the payment.
‘BLCK’ – BlockedThe receiving bank has blocked the funds
‘ACWP’ – Accepted Without PostingThe receiving bank has accepted the payment, but the credit will not be immediate.
‘ACCC’ – Accepted Settlement Completed Creditor AccountThe receiving bank has accepted the payment and credit is applied to the beneficiary account.
Example 18: PO terminal statuses

Wireframes

CX Considerations
1.

ASPSP should be able to provide the PISP with payment status information across the whole payment journey, from payment initiation, to payment processing and payment execution. This payment status information should include both high level ISO processing payment status, and also lower lever payment status information specific to the underlying payment system (for example qualified and unqualified accept for UK faster payments).
PISP should use this information to determine the confidence level about the status of the payment and inform the PSU (and the receiving party if relevant) about the status of the payment.