Customer Experience Guidelines

Change Log v4.0

This version is:

This is the latest version Published 4 weeks ago 28 Jun 2024

A summary of changes from V3.1.11 to V4.0

Copy that has been removed is ~~struck out~~ and copy which has been added is in blue.

Other pages in this section

Customer Experience Guidelines Changes: V3.1.11 to V4.0

ID/Section	Sub section/Location	Change	Reason for Change
AIS Access Dashboard	Figure 8: ASPSP access revocation journey for AIS Added new no 5	Figure 8: ASPSP access revocation journey for AIS Added new no 5 On 3rd screen next to confirm add red 5 blob (5) ASPSP should update the status of the consent. If the status of the consent is updated then they must provide appropriate reasons. ASPSP could allow the PSU to capture a reason and provide it to the AISP when queried using the relevant GET consent endpoint. New Reference – 10g	Information Flow
AIS Consent Dashboard	Revocation Journey	(4) AISPs must inform the ASPSP that the PSU has revoked consent by making a call to DELETE the account-access-consent resource as soon as practically possible (as described in Version 3 onwards of the API specifications). This will ensure that no further account information is shared. ASPSPs must support the Delete process as described in ~~the Version 3~~ API Specifications (This is not visible to the PSU but will ensure no further account information is provided by the ASPSP to the AISP).	Information Flow
AIS Consent Dashboard	Re-authentication of access New Reference -17d Changed (6) to (7)	New (6) If the ASPSP has marked the consent status as 'CANC’ which means ‘Cancelled' when the PSU cancelled their access on the Access Dashboard or the ASPSP has marked it as ‘CANC’ which means 'Cancelled' for any reason where a reinstate is possible, then the ASPSP must mark the status back to 'Authorised' after the PSU has successfully re-authenticated at the ASPSP.	Information Flow
AIS Consent Dashboard	Re-authentication of access Figure 12: Re-authenticate AIS access from the Consent Dashboard.	Added new no 6, Changed 6 to 7	Information Flow
AIS Consent Dashboard	Figure 7: Re-authenticate PIS-VRP access from the Consent Dashboard New Reference -17d Aded new no 6, Changed (6) to (7)	New (6) If the ASPSP has marked the consent status as 'CANC’ which means ‘Cancelled' when the PSU cancelled their access on the Access Dashboard or the ASPSP has marked it as ‘CANC’ which means 'Cancelled' for any reason where a reinstate is possible, then the ASPSP must mark the status back to 'Authorised' after the PSU has successfully re-authenticated at the ASPSP.	Information Flow
CBPII Access Dashboard	Figure 5: ASPSP access revocation journey for CBPII Added new no 3, Changed 3 to 4	(3) ASPSP should update the status of the consent. If the status of the consent is updated then they must provide appropriate reasons.  ASPSP could allow the PSU to capture a reason and provide it to the CBPII when queried using the relevant GET consent endpoint. New Reference – 10g	Information Flow
CBPII Dashboard Revocation	Wireframe updated Added new no 5, Changed 5 to 6	(5) ASPSP should update the status of the consent. If the status of the consent is updated then they must provide appropriate reasons.  ASPSP could allow the PSU to capture a reason and provide it to the CBPII when queried using the relevant GET consent endpoint. New Reference – 10g	Information Flow
PSU Notifications	Synchronisation between Consent and Access Dashboards	It is important that PSUs are not presented with contrasting information on their Consent and Access Dashboards when it comes to the status of the connection. Due to the regulatory changes in the UK RTS, the ASPSPs does not need to authenticate the PSU every 90 days as the AISP will reconfirm consent every 90 days with the PSU instead. Since there is no requirement on the AISP to inform the ASPSP when they have reconfirmed consent with the PSU, it may be challenging for the ASPSP to show the PSU whether consent is active or not on their Access Dashboard. We recommend that the ASPSP provides information on when data was last shared with the AISP (e.g. shown as ‘data last shared’ – date & time, today, yesterday, 7 days ago or 24 hrs ago, etc.) as this gives the greatest clarity to the PSU. The ASPSP must ensure any messaging provided to the PSU is clear and consistent and presented in a manner that does not cause confusion. There are a series of technical solutions in place that are designed to ensure the TPP is notified of a change made through the Access Dashboard, particularly revocation of access. The most common issue that occurs today is where a PSU revokes access at the ASPSP access dashboard and the TPP consent dashboard is not updated at the same time. To address this issue, “Cancelled” status is introduced. This enables the ASPSP to mark the Consent status as “CANC’ means ‘Cancelled” if the PSU cancels (revokes) access given to a TPP on their access dashboard. The PSU can provide a reason for cancellation which the ASPSP may want to capture and share it on the GET status endpoint with the PISP. The ASPSP needs to provide an appropriate reason against the cancelled access. The reason can be either provided by the PSU themselves or one of the ISO reasons or OB proprietary reasons specifying whether reauthentication is required to reinstate the consent or no further action is possible e.g. Fraud These solutions can be split into “push” notifications from ASPSP to TPP, and “pull” notifications whereby the TPP “asks” the ASPSP if there have been any changes to the status of access tokens.	Information Flow
Information Flow - Payment Status	User journey	The Open Banking Standard ~~have~~ 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 ~~each processing phase.~~ Confirmation that the payment order has been ~~executed and~~ 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 (these are not currently available for other payment schemes).	Information Flow
Information Flow - Payment Status		The Open Banking Standard ~~have~~ has been updated to allow ASPSPs to provide 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 ~~successful~~ 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 ~~‘AcceptedCreditSettlementCompleted’~~ ‘Accepted Settlement Completed Creditor Account’) Enriched and more granular list of payment status messages and reasons for failure/rejection ~~of status information~~ 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.	Information Flow
Information Flow - Payment Status	Payment Consent Response Status	Figure 1 and Example 1 added After payment consent has been ~~posted~~ 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 ~~should~~ 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. Extract of error message for a Failed to stage Consent "ErrorCode": "U001", "Message": "UK.OB.Field.Expected", "Path": "Data.Initiation.CreditorAccount.Name"	Information Flow
	PSU Authentication Status	Figure 2, 3, 4 and Example 2, 3, 4 added 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’ 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 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’~~. by the PSU.~~ If the PSU does not authenticate successfully, then there is no authorisation code sent back to the PISP. However, ASPSP ~~will~~ 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. Note: For various reasons the consent may not move to its next natural stage ‘Authorised’ or ‘Rejected’, in which case the ASPSP must populate appropriate status reason codes. There could be more than one reasons of failure.	Information Flow
	Payment Initiation Response Status	Figure 5 and Example 5,6 added In the case that the payment consent has been ~~authorised~~ 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’ a new payment order resource is created. The status of the payment order at this state should be ~~‘Pending’~~ ‘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 ~~a failure~~ 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.	Information Flow
	Further Payment Initiation Status	Figure 6 and Example 7,8,9 added ~~In case~~ If the payment order submission is successful, the payment order resource is created (with ~~‘Pending’~~ ‘RCVD’ which means ‘Received’ status), there are further checks and validations that will take place at the ASPSP as part of the payment initiation. 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’. 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. 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. Note: Sequence of whether ACTC is done prior to ACCP or vice versa is upto each individual ASPSP 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 ~~out if~~the status of the payment after initiation ~~has been successful~~ (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 ~~subsequent~~ 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.	Information Flow
	Payment Processing Status	Figure 7 and Example 10, 11, 12 added The payment order during payment processing may undergo further checks. Further to these checks: If any of the checks fail, then the status of the payment order resource ~~should~~ must become ‘RJCT’ which means ‘Rejected’. 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. If all aspects of the payment processing are successful, then: The PSU account is debited with the amount of the payment. The payment order resource should then become ‘ACSC’ which means ~~‘AcceptedSettlementCompleted’~~ ‘Accepted Settlement Completed Debitor Account’ The payment is sent by the sending ASPSP to the underlying payment system for execution. 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 ~~‘AcceptedSettlementCompleted’~~ ‘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.	Information Flow
	Payment Execution Status	Figure 8 and Table 13, 14, 15, 16, 17 added ~~In case~~ If the payment processing is successful and the payment is sent to the underlying payment system ~~for execution,~~ 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 Payments Status specific information-FPS Payments types and status.Further to these checks:  If any of the checks fail, then the status of the payment order resource status must become ‘RJCT’ which means ‘Rejected’.  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.  If all aspects of the payment execution are successful, then:  If the receiving ASPSP ~~or bank~~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. If the receiving ASPSP or bank 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 ~~‘AcceptedCreditSettlementCompleted’~~ ‘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 Payments Status specific information-FPS Payments 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 in shown the table.	Information Flow
Information Flow - Payment Status for Standing Order	Appendices	New page added Information Flow - Payment Status for Standing Order	Information flow
Transaction Risk and Indicators (TRI) definitions and guidance	Appendices	New page for guidance on Transaction Risk Indicators - Definition and Usage	OBL Internal Review
Common Error Scenarios	Appendices	Replace page Read/Write API Specification-Standard Error Codes with New page Common Error Scenarios – Preferred Status and Reasons	Information flow
API Specifications		Specifications for MI Reporting of ASPSPs to Open Banking. MI specification includes detailed Data Dictionary and examples of MI reporting template. ~~(Requires access to Confluence Collaboration Space)~~	OBL Internal Review
API Specifications		Specifications for MI Reporting of TPPs to Open Banking. MI specification includes detailed Data Dictionary and examples of MI reporting template. ~~(Requires access to Confluence Collaboration Space)~~	OBL Internal Review
Security Profiles and API Specifications		New tab & New Page Getting started– Open Banking API Security Profile Tab – Financial Grade API ~~https://openid.net/specs/openid-financial-api-part-2-wd-06.html~~ https://openid.net/specs/openid-financial-api-part-2-1_0.html	FAPI Change
CEG Checklist		Checklist updated reflecting change in blue	Information flow
Reference Library		Security and Counter Fraud Artefact removed and replaced by External Internal Codeset	To align to mainwebsite as it is not relevant.

Read/Write API Specification – Standard Error Codes Previous

Operational Guidelines Next

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.