Customer Experience Guidelines

Change Log

This version is:

Published 4 years ago 25 Jun 2020
A summary list of changes from V3.1.5 to V3.1.6  Changes are indicated as follows. Copy…

Other pages in this section

A summary list of changes from V3.1.5 to V3.1.6 

Changes are indicated as follows. Copy which has been removed is struck out and copy which has been added is in blue.

ID/SectionLocationChangeReason for Change
Introduction
1Customer Experience PrincipleTest Phase Engagement
OBIE will maintain an open inclusive dialogue with all participants.  OBIE will actively encourage all participants to engage in testing for the benefit of the individual participants in the ecosystem as a whole.  Depending on the ecosystem maturity of the participants, OBIE will guide participants to the appropriate testing 'entry point' for them and support them through testing.
Removed Section as it is covered under TPP Guidelines.
OBIE Internal Review
2Customer JourneyInserted codification of consent content:
 Set-Up: Codification of the Customer Data Agreement
Consent: Codification of AIS Consent (PSD2)		OBIE Internal Review
3Redirection Based AuthenticationNew section added Error scenarios during redirection


Error scenarios during redirection
As per OIDC, there are 2 main scenarios when an error occurs at the ASPSP side during the authorisation process:

Malformed Authorisation Request: The authorisation request may be malformed when submitted by the TPP. For example, it may include an invalid redirection URL, invalid parameters, invalid signature on the request object etc.OAuth2 and OIDC define a whole list of potential errors. These are abnormal situations which indicate a significant technical issue at the TPP’s end or even an attacker trying to act as a TPP. For safety (and as per the standards) the ASPSP must not redirect the PSU back to the TPP in such situations. The ASPSP must display an error message and stop the execution at this point. It is at the ASPSPs’ discretion to display to the PSU the message they find most appropriate for this error case, however an error message must be displayed.
In this situation, TPPs do not receive a response back from the ASPSPs about the malformed authorisation request. Therefore, TPPs are not able to display any message to the PSU in this situation.

The PSU relies completely on the ASPSP to be notified about the occurrence of an error.

User interaction error: An error occurred during user interaction, for example, users click on cancel or are unable to validate their credentials, the debtor account in the authorisation request does not belong to PSU etc. In this case, the ASPSP must redirect the PSU back to the TPP and provide in the response the appropriate OIDC error message.
The ASPSP could potentially display an error message to the PSU before redirecting back to the TPP, but it is solely at their discretion. The TPP should check the OIDC error code and display additional messages to the PSU with further information. messages.

Error responses are documented as below:

For OIDC: https://openid.net/specs/openid-connect-core-1_0.html#AuthError

For OAuth 2: https://tools.ietf.org/html/rfc6749#section-4.1.2.1

Please note that both of the above scenarios are strictly checked by the FAPI conformance suite from OIDF.

Following the above guidelines in the case these error scenarios, will prevent occurrences of bad customer experience due to errors managed insufficiently.
 Ticket OBSD -14630 https://openbanking.atlassian.net/browse/OBSD-14630.
Appendices
4TPP permissions and CASS considerations
Recommendation from CASS to add more guidance to participants that TPP permissions will not be switched as part of CASS
 CASS participants are expected to inform customers that permissions for Third Party Providers (TPPs) to access to their payment accounts will not be transferred from their old account to their new account as part of the Current Account Switch Service.

The following wording is recommended and can be adapted to meet specific needs:  

  • Before you close your old account, check whether you have any Third Party Provider permissions set up and if so, who with. You can see the permissions you have via the access dashboard.

  • Once your new account is open, you will need to contact your Third Party Provider to enable access your new account by providing them with your new account details and following any further necessary steps, required by the Third Party Provider. You will need to contact the Third Party Provider directly yourself to set this up.

  • If you are unsure as to whether your New Bank Current Account Provider will support the  Third Party Provider permissions on your account, you will need to discuss this ahead of your switch with your New Current Account Provider who will be able to advise you of this.


    • Please check your new provider's terms and conditions for more information about Third-Party Providers permissions.    		CASS Requirement #3