Appendices
This version is:
This is the latest version Published 9 months ago 28 Jun 2024The 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:
- The status any time after payment submission for all supported payment types, including Single Immediate Domestic, Single Future-dated Domestic, Standing-order Domestic, Single Immediate International, Single Future-dated International, Standing-order International and Bulk/Batch payments, VRP for sweeping (sVRPs) and commercial VRPs (cVRPs).
- A meaningful status message to a PISP request for each processing phase and particularly when settlement on the debtor’s account has been completed thus providing the PISP with a sufficient status message that the payment will be sent to the receiving bank.
- A confirmation that the payment has been executed and has been received by the payee bank (e.g. provide the status message ‘ACCC’ which means ‘Accepted Settlement Completed Creditor Account’)
- Enriched and more granular list of payment status messages and reasons for failure/rejection as per the ISO 20022 standard and other standards through the payment initiation, processing and and execution stages of payments at the sending bank and the receiving bank.

All below figures read – Green in Bold as required and Orange in Italic as recommended
CX and other processing requirements
A. Payment Consent Response Status
Payment Consent Response Status
- After payment consent has been staged by the PISP to the ASPSP.
- If the request is successful, a new payment consent resource is created. The status of the payment consent at this state must be ‘AWAU’ which means ‘Awaiting Authorisation’. The ASPSP responds back to the PISP that the request has been successful (201 message) including the payment consent status.
- If the request fails, a 4xx series message with a failure reason code(s) are sent back to the PISP. There could be one or more reasons for failure.
- A ‘GET’ status call by the PISP at this stage should also respond with status ‘AWAU’. If the staging is unsuccessful the PISP must rely on the reason code(s) provided by the ASPSP in the error message.
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.

Status Code | Status Reason Code | Status Reason Description |
---|---|---|
AWAU | U036 | Authorisation not completed |
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 payment consent is set up successfully, the PSU is redirected to the ASPSP for authentication. If the PSU authenticates successfully, then:
- if there is no call to action for the PSU (such as in journey Single Domestic Payments – a/c selection @ PISP) the status of the payment consent should become ‘Authorised’
- If there is a call to action for the PSU (such as in supplementary information journey Single Domestic Payments – Supplementary info, then the PSU decision to proceed with the payment should make the status of the payment consent become ‘AUTH’ means ‘Authorised’ .

Status Code | Status Reason Code | Status Reason Description |
---|---|---|
AUTH |
If the PSU call to action leads to the PSU cancelling the payment, then the status of the payment 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.:

Status Code | Status Reason Code | Status Reason Description |
---|---|---|
RJCT | AM04 | Insufficient Funds |
RJCT | U037 | Authorisation failed (after x attempts) |
RJCT | CN01 | Authorisation Cancelled |
A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment 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 payment 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.

Status Code | Status Reason Code | Status Code Description |
---|---|---|
AWAU | U036 | Authorisation not completed |
AWAU | U000 | UK.OB.UnexpectedError |
AWAU | AM04 | Insufficient Funds |
AWAU | U037 | Authorisation failed |
C. Payment Initiation Response Status

In the case that the payment consent has been authenticated by the PSU, the PISP will submit the payment order to the ASPSP. if the payment order request has been successfully submitted to the sending bank:
- the payment consent resource status should become ‘COND’ which means ‘Consumed’

Status Code | Status Reason Code | Status Reason Description |
---|---|---|
COND | U038 | Consent consumed successfully |
Status Code | Status Reason Code | Status Reason Description |
---|---|---|
RCVD | U030 | Payment order successfully received |
- a new payment order resource is created. The status of the payment order at this state should be ‘RCVD’ which means ‘Received’. The ASPSP responds back to the PISP that the request has been successful (201 message) including the payment order status.
- A PISP could make a call to the ‘GET’ consent status endpoint at this stage to confirm that the payment consent resource has been updated to ‘COND’ which means ‘Consumed’ as part of the payment order initiation.
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 payment order was not successfully created. Depending on the reason code the PISP could make the decision whether to submit the payment order again or not.
D. Further Payment Initiation Status

If the payment order submission is successful, the payment order resource is created (with ‘RCVD’ which means ‘Received’ status), there are further checks and validations that will take place at the ASPSP as part of the payment initiation.
Status Code | Status Reason Code | Status Reason Description |
---|---|---|
PDNG | U031 | All checks yet to start |
If the payment order cannot be processed immediately on receipt due to pending checks and validations needing to be done, the payment resource is updated with ‘PDNG’ which means ‘Pending’ status and an appropriate status reason is provided.
If the payment order cannot be processed immediately on receipt because it is a Standing Order or a future-dated payment, the payment resource is updated with ‘PDNG’ which means ‘Pending’ status and appropriate status reason is provided.
Future dated payments that are warehoused at the ASPSP until they are processed on the actual payment date can be cancelled by the PSU at their ASPSP within agreed time limits . Once cancelled, the ASPSP must update the payment order status to ‘CANC’ which means ‘Cancelled’. The PSU could also cancel a Standing Order at the ASPSP, after which the payment order status must be updated to ‘CANC’ 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 Code | Status Reason Code | Status Reason Description |
---|---|---|
RJCT | AM04 | Insufficient Funds |
ACSP |
Depending on the status reason code(s) the PISP could make the decision whether to submit the payment order again or whether it is a one-off error due to insufficient funds at that instance, e.g. if it is a Standing order payment.
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 Code | Status Reason Code | Status Reason Description |
---|---|---|
ACTC | ||
PATC | U040 | Awaiting multiple authentication |
ACCP | U032 | Customer profile checks completed |
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.
Note: Sequence of whether ACTC is done prior to ACCP or vice versa is upto each individual ASPSP
Status Code | Status Reason Code | Status Reason Description |
---|---|---|
RJCT | AM14 | Amount Exceeds Agreed Limit |
ACFC | U040 | |
ACSP | U032 |
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 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’).
Note: In several situations (such as in single domestic payments), the progress from payment initiation to payment processing 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 or #D. This may also depend on the implementation by various ASPSPs.
E. Payment Processing Status

The payment order during payment processing may undergo further checks. Further to these checks:
Status Code | Status Reason Code | Status Reason Description |
---|---|---|
RJCT | AM04 | Insufficient Funds |
If any of the checks fail, then the status of the payment order resource must become ‘RJCT’ which means ‘Rejected’.
Status Code | Status Reason Code | Status Reason Description |
---|---|---|
ACWC | DT06 | Execution Date Changed |
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 Code | Status Reason Code | Status Reason Description |
---|---|---|
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

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 Code | Status Reason Code | Status Reason Description |
---|---|---|
RJCT | 1160 | Receiving account closed |
If any of the checks fail, then the status of the payment order resource status must become ‘RJCT’ which means ‘Rejected’.
Status Code | Status Reason Code | Status Reason Description |
---|---|---|
BLCK | AC06 | Blocked Account |
BLCK | AM07 | Blocked Amount |
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 Code | Status Reason Code | Status Reason Description |
---|---|---|
ACWP | 0081 | Expected on same day |
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 Code | Status Reason Code | Status Reason Description |
---|---|---|
ACCC | 0000 | Credited to beneficiary account |
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’ status endpoint at this stage to find out if the payment execution has been successful (i.e. payment order resource status is ‘ACWP’ which means ‘Accepted Without Posting’) or ‘ACCC’ which means ‘AcceptedSettlementCompletedCreditorAccount’), or the payment execution has failed (i.e. payment order 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 State | Meaning |
---|---|
‘CANC’ – Cancelled | PSU 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’ – Rejected | Either the sending bank or receiving bank have rejected the payment. |
‘BLCK’ – Blocked | The receiving bank has blocked the funds |
‘ACWP’ – Accepted Without Posting | The receiving bank has accepted the payment, but the credit will not be immediate. |
‘ACCC’ – Accepted Settlement Completed Creditor Account | The receiving bank has accepted the payment and credit is applied to the beneficiary account. |
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.
Payment Systems specific information – FPS payment types and status
UK Faster Payments and payment status code
Faster Payments is the UK’s low value near-real time payment syste with deferred settlement cycles. Faster Payments support the following payment types:
1. Single Immediate Payment (SIPs): SIPs are single payments processed synchronously by the FPS Members and the Central Infrastructure. Synchronous payments have specific SLAs for response times and thus in the majority of them the round trip time from Sender Bank sending the request till receiving the response from the Receiver Bank is usually less than 15 seconds. The receiving bank may:
a. Accept the payment: There are 2 ways the receiving bank can accept the incoming payment:
i. Unqualified Accept: The payment is accepted without qualification and the credit will be applied to the customer’s account within the faster payments SLA time (max 2 hours). Typically, in a lot of cases the credit is applied to the customers account within seconds presumably to meet the requirements of the Payment Services Regulations 2017 (PSRs). The payment is irrevocable under the PSRs once consent has been given to the PISP to initiate it. In the case the credit cannot be applied to the beneficiary account, the receiving bank has to initiate a Return payment providing the reason for the return. Several of the return reasons relate to the beneficiary account details not being sent correctly or the beneficiary account not being able to receive the funds.
ii. Qualified Accept: The qualified accept is used in cases where the receiving bank cannot guarantee that credit will be applied to the beneficiary account within the standard SLA defined by the FPS Scheme (i.e. 2 hours max). Different qualifier codes are used to indicate the timelines of the credit such as same day, next calendar day, next working day, at unspecified time and date within the PSRs etc. Typical cases when qualified codes are being used are the following:
– The received payment is for an indirect member bank (agency bank). The receiving FPS settlement bank accepts the payment on behalf of the agency bank but provides a qualifier code of when the agency bank will apply the credit to the beneficiary account. Please note that while the receiving FPS settlement bank can perform some checks before accepting, they cannot check the business rules of the beneficiary account and thus the payment may still fail at the agency bank, even if it has been accepted by the receiving FPS settlement bank. In this case, the rejected payment by the agency bank also has to be returned by the FPS settlement bank.
– The received payment is for an FPS member bank but there are technical issues and the bank is not able to apply the credit to the beneficiary account within the agreed SLA.
b. Reject the payment: When receiving the payment and before responding back to the sending bank, the receiving bank will perform and number of checks in the received payment instruction. Some of these checks will include the checking of the following:
– beneficiary account sort code and number belong to the receiving bank (or sort code to one of its agencies), beneficiary account name has been provided and matches the account number
– payment details are correct in terms of currency, payment reference etc
– the beneficiary account in not stopped, closed, or transferred, the T&Cs allow the account to receive the credit and there are no beneficiary sensitivities or any other business reasons for not crediting.
If any of the above checks fail, the payment is rejected and the rejection message including the rejection reason code is sent to the sending bank. Considering that that the PISP will be initiating a payment for a known beneficiary (e.g. in case of a merchant) a lot of the above rejection codes can be avoided before the payment initiation.
Note 1: Synchronous payments are considered time critical as the expectation is that they are payments where the PSU is present initiating the payment and waiting for a result or any outcome to take place.
Note 2: Faster Payments can also be rejected by the servicing Central Infrastructure (CI). In fact, the CI continuously monitors the FPS members’ connected gateways for technical issues and availability. If member systems are unable to receive payments, the CI will reject the payments sent by the sender bank.
2. Future Dated Payments (FDPs): FDPs are single payments which are non-urgent and thus do not need to be executed immediately. They have an execution date in the future, which allows sending banks to warehouse them and process them on they day requested by the PSUs. They are being processed asynchronously by FPS member banks, which means the following:
– The sending bank is sending the payment request to the CI. The CI confirms back to the sending bank that the payment has been accepted. From the sending bank’s perspective, the payment has been successfully submitted and they can update their status accordingly.
– The CI is sending the payment request to the receiving bank. The receiving bank will perform the necessary checks and respond back to the CI if the payment is successfully accepted or not (same checks apply with SIP payments).
– If the receiving bank rejects the payment, then the CI will send a special type of return payment (called Scheme Return payment) to the sending bank. This is because for the sending bank, the payment has been successful and the PSU’s account has been debited. The Scheme Return will apply credit to the PSU’s account in order to restore the original balance that was prior the payment was made from the account.
Note: Asynchronous future dated payments are usually processed by the banks overnight on the required execution date on 365 basis (for FPS member banks). This provides a window of several hours for the payment to be processed and executed and credited to the beneficiary account before the end of the calendar day. On several bank implementations, if funds checking fails during the original attempt to process the payment, the payment will be retried again later on the same day. The cut-off point for submitting a future dated payment depends on each bank’s implementation.
3. Standing Orders (SOs): SOs are recurring payments of fixed amount to a fixed beneficiary which again are non-urgent and thus do not need to be executed immediately. They are also processed asynchronously by the FPS member banks. Thus, similarly to the FDPs, once checked by the CI, they are confirmed back to the sending bank and being considered successful. Again, if they are rejected by the receiving banks, the CI will send a Scheme Return back to the sending bank in order to return the credit back to the PSU. SOs, are being processed during week business days and the majority of them (e.g. over 90%) are expected to be processed during the FPS 1stsettlement cycle, from midnight to 6am. Finally, similarly to FDPs, on several bank implementations, if funds checking fails during the original attempt to process the payment, the payment will be retried again later on the same day. SOs scheduled for a weekend, will be processed on the first available business day of the following week.