Appendices

Common Error Scenarios – Preferred Status and Reasons

This version is:

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

This document is to help participants including ASPSPs, TPPs and consumer experts of which errors are required / recommended to be shared in specific scenarios. The attempt is to put some common scenarios to start with. There could be other scenarios that are not listed here but a similar approach has to be taken by the ASPSPs to provide an appropriate ISO 20022 reason of failure as a first preference. If an appropriate reason is not available then OBL proprietary reason codes can be provided. ASPSPs can provide a customised reason code in exceptional circumstances when an appropriate reason is not available or in instances where a bespoke reason is provided by the PSU in specific scenarios.

Other pages in this section

The full list of ISO external status reasons and OB proprietary reasons can be found here

Awaiting Authorisation

ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGet CBPII
1When the customer has attempted to authorise but has failed for acceptable number of times.
The reason why it is still in the state,
PSU attempted but took no action
OAUTH errors can be mapped to this state.		[U036] Authorisation not completed

ü



ü



ü

2This should be used in extremely exceptional situations where exact reason cannot be provided.[U000] UK.OB.UnexpectedError

ü



ü



ü

3This should be used if funds check is done at the time of account selection, and ASPSP not marking the consent as authorised due to insufficient funds. This will enable the PSU to fund the account and authorise again.[AM04] InsufficientFunds

ü

Awaiting Further Authorisation

ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used to inform the PISP if one of the authenticators have failed[U037] Authorisation failed

ü

Note: Awaiting Further Authorisation is not applicable to AIS.

Authorised

ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used when authorisation code is invalid.[TK01] TokenInvalid

ü



ü



ü



ü

2This should be used when authorisation code has expired.
This could also be used if Token is already used.		[TKXP] TokenExpired

ü



ü



ü



ü

3The should be used when bank has suspended access due to any reason[U028] UK.OB.Reauthenticate

ü



ü



ü

Cancelled

ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This is to be used when the ASPSP cancels an ongoing access token for valid reasons. If reauthentication is not permitted then the TPP need to be provided with a appropriate reason.[TKSP] TokenSuspended
AND
[U039] Reinstate not allowed any more.

ü



ü



ü

2This should be used when the ASPSP cancels an ongoing access token for valid reasons. If reauthentication is required then the TPP need to be provided with a appropriate reason.[TKSP] TokenSuspended
AND
[U028] UK.OB.Reauthenticate

ü



ü



ü

3This should be used when the PSU cancels an ongoing access on their access dashboard at the ASPSP.
If PSU is allowed to capture the reason then the same may be shared with the TPP
[TKSP] TokenSuspended
AND
[U028] UK.OB.Reauthenticate
AND
[NARR] Customer provided reason

ü

Consumed

ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used when consent is consumed[U038] Consent consumed successfully

ü

Payment Status

Status code name – [ACCP]
Status code value - Accepted Customer Profile
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used when customer profile is validated

ü

Status code name – [ACTC] or [PATC]
Status code value - Accepted Technical Validation OR Partially Accepted Technically Correct
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1ACTC status should be used when all technical validations on the payment order are successfully completed by the ASPSP.

ü

2PATC status should be used when there are multiple authenticators that need to authentication at the ASPSP but the technical validations on payment order has been successfully completed by the ASPSP.

ü

Status code name – [ACFC]
Status code value - Accepted Funds Checked
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used once technical validation and customer profile checks are successful and automatic funds check are positive

ü

Status code name – [ACSP]
Status code value - Accepted Settlement in Process
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used when the ASPSP is processing the payment. Any reason the processing is blocked in a certain state for longer then SLA time must be updated with appropriate reason

ü

Status code name – [ACWC]
Status code value - Accepted with change
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This must be used to update the status so the PISP should know that there might be a delay as the payment need to be resubitted because CI has returned 1181.[1181] Duplicate Payment (FPID). Resubitting with change

ü

2This should be used to notify the PISP when the bank over rides the execution date.
Eg. due to it falling on a non-working day.		[DT06] ExecutionDateChanged

ü

Status code name – [ACSC]
Status code value - Accepted Settlement Completed Debitor Account
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be the final status at the sending bank before the payment is sent to the receiving bank. Not to be considered as final status of the payment by the PISP.[U034] Debit to Debtor's account completed. Sent to next agent/scheme

ü

Status code name – [BLCK]
Status code value - Blocked
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used when the receiving bank sends this to the sending ASPSP.[AC06] Blocked Account

ü

2This should be used when the receiving bank has blocked the amount and sends the code to the sending ASPSP.[AM07] BlockedAmount

ü

Status code name – [ACWP]
Status code value - Accepted Without Posting
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This should be used if the CI is not available after sending it to CI[ED06] SettlementSystemNotAvailable

ü

2This must be used when received from FPS[0080] Expected within unspecified period but within PSD guidelines

ü

3This must be used when received from FPS[0081] Expected on same day

ü

4This must be used when received from FPS[0082] Expected on next Calendar Day

ü

5This must be used when received from FPS[0083] Expected on next Working Day

ü

6This must be used when received from FPS[0084] Expected after next working day but within PSD guidelines

ü

Status code name – [ACCC]
Status code value - Accepted Settlement Completed Creditor Account
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1This must be used when 0000 is received from FPS.[0000] Credited to beneficiary account

ü

Rejected – Consent / Payment

Status code name – [RJCT]
Status code value - Rejected
ID noScenario[Reason Code] Reason DescriptionGET PIS ConsentGET PaymentGET AISGET CBPII
1For Payment - This should be used when other authorisers refuses to authorise the payment when redirected.
For Consent - This should be used when the first and final authoriser successfully authenticates but rejects after being redirected.		[CN01] AuthorisationCancelled

ü



ü



ü

2This should be used when authorisation code is invalid.[TK01] TokenInvalid

ü



ü



ü

3This should be used when authorisation code has expired.
This could also be used if Token is already used.		[TKXP] TokenExpired

ü



ü



ü

4This should be used when customer is not able to authorise when redirected to the debtor agent (customer's bank)[AB11] TimeoutDebtorAgent

ü

5This should be used when the customer fails x consecutive authentications and the bank wants to reject the request.[U037] AuthorisationFailed

ü



ü



ü

6This should be used when the sending bank does not support a FDP that far away. Reason description should mention howmany days forward is accetable.[CH03] RequestedExecutionDateOrRequestedCollectionDateTooFarInFuture

ü

7These should be used when the payment is received after cutoff date or time. The sending bank may also have alternate options to change the execution date and proceed. In that case [DT06] should be used along with [Acceptedwithchange] status.[DT05] InvalidCutOffDate
[TM01] InvalidCutOffTime

ü

8This should be used when payment order cannot be submitted against a already consumed consent[U035] Consent already consumed

ü

9This should be used when field is not as per the OB proprietory allowable enumerations.[FF05] InvalidLocalInstrumentCode

ü

10This should be used when field is not one of the ISO Category Purpose code value.[FF06 ] InvalidCategoryPurposeCode

ü

11This should be used when field is not one of the ISO Payment Purpose code value.[FF07] InvalidPurpose

ü

12This should be used when the End to End Id is not provided or length not as expected.[FF08] InvalidEndToEndId

ü

13PS to add scenario[RR10] Invalid CharacterSet

ü



ü

14This should be used when payment from the account is not permitted.[AG01] TransactionForbidden

ü



ü

15This should be used when the transaction failed or could not be completed due to invalid or missing user or access rights.[AG08] InvalidAccessRights

ü



ü

16This should be used when syntax of any field is incorrect. But necessary information is provided the reason description.[FF02] SyntaxError

ü



ü

17For Consent - This should be used when PSU is initiating a SIP and account does not have sufficient funds.
For Payment order - This should be used when there are insufficient funds to complete the transaction. After receiving the payment order and any point until the customer's account is debited.
For FDP & SO, at the point in time funds check is done while debiting the customer's account.		[AM04] InsufficientFunds

ü



ü

18This should be used when payment exceeds available limit on the PSU's account[AM14] AmountExceedsAgreedLimit

ü

19There may be no reason associated with this as the sending bank may not receive a reason. But if received it should be included in the Reason Description field.[1100] Payment rejected by receiving bank

ü

20This should be used when you receive 1160 Receiving account closed[AC07] ClosedCreditorAccountNumber

ü

21This should be used when you receive 1161 Receiving account stopped[1161] Receiving account stopped

ü

22This should be used when you receive 1162 Receiving account name does not match.[1162] Receiving account name does not match

ü

23This should be used when you receive 1163 Receiving account requires reference data[1163] Account requires reference data

ü

24These should be used when you receive 1164 Reference data incorrect[RR09] InvalidStructuredCreditorReference
[RF01] NotUniqueTransactionReference
[S001] UETRFlaggedForCancellation

ü

25This should be used when FPS sends 1165[1165] Account is not in currency quoted. Check receiving account details

ü

26This should be used when FPS sends 1166[1166] Account transferred. Check receiving account details

ü

27This should be used when you receive 1167 Beneficiary Deceased[MD07] EndCustomerDeceased

ü

28For scheme -This should be used when you receive 1169 Payment cannot be made due to sensitivities - Advise PISP payment cannot be made to this account.
For consent, sending bank should return AG01 if the type of account is not supported		[AG01] TransactionForbidden
or
[AC06] BlockedAccount

ü

29This should be used when you receive 1170 T&C’s prevent payment be received - Advise PISP payment cannot be made to this account.[AG03] TransactionNotSupported

ü

30These should be used when you receive 1176 Receiving agency account / sort code unknown[AC03] InvalidCreditorAccountNumber
[UCRD] UnknownCreditor

ü

31This should be used when you receive 1177, receiving agency account closed[1177] Receiving agency account closed

ü

32This should be used when you receive 1178, receiving agency account stopped[1178] Receiving agency account stopped

ü

33This should be used when you receive 1180, account Transferred.Check receiving account details[1180] Account Transferred.Check receiving account details

ü

34This should be used when creditor name is required and is missing.[BE22] MissingCreditorName

ü

35In relation to file upload, these are some of the error reasons[AM10] InvalidControlSum
[AM16] InvalidGroupControlSum
[AM17] InvalidPaymentInfoControlSum
[AM18] InvalidNumberOfTransactions
[AM19] InvalidGroupNumberOfTransactions
[AM20] InvalidPaymentInfoNumberOfTransactions
[FF01] InvalidFileFormat
[TA01] TransmissonAborted
[TD01] NoDataAvailable
[TD02] FileNonReadable
[TD03] IncorrectFileStructure
[TS01] TransmissionSuccessful

ü