Examples and additional detail for CEG Checklist questions
| Ref | Topic | |
|---|---|---|
| 1 | Equivalence covers a range of topics including: • Functionality. • Access rights (if a joint account holder can access all account information or initiate payments without any action on the part of the other account holder directly with the ASPSP, then this functionality should be available when using a TPP). • Authentication methods (and the order in which they are presented). • The process covering mistakes when inputting an authentication element (e.g. typo of a password). • Length of journey / number of steps (this means that having to manually open a browser or an app must be avoided as that is not required in a direct experience, except for the generation of a code on a mobile app). • Version control and equivalence for authentication i.e. authentication works with all available versions of the app. • Visual display including branding, imaging, fonts and text formatting. For clarity, the experience should match the associated channel e.g. if biometric can be used on an app, then this should be available to the PSU when a TPP is involved. | * Length of journey / number of steps (this means that having to manually open a browser or an app must be avoided as that is not required in a direct experience, except for the generation of a code on a mobile app). * Visual display including branding, imaging, fonts and text formatting. * Version control and equivalence for authentication i.e. authentication works with all available versions of the app. |
| 2 | Additional checks of consent While an ASPSP may provide additional information and clarification throughout the journey, at no stage should the ASPSP seek to reconfirm or check that the PSU wants the TPP to perform the activity they have consented to. For example, language such as "Are you sure you want to grant access to the TPP..." or “The TPP has asked us to initiate a payment, please confirm you are happy with this...“ should be avoided. Further explanation and clarification of this point is found throughout the Customer Experience Guidelines journeys. |
|
| 3 | Identifying your firm as genuine For example have personalised greetings during authentication so that the PSU knows they are authenticating with their own ASPSP and not a fake. |
|
| 5a | App-to-app redirection As provided in the P3/P4 Evaluation letter, the OBIE definition of App-to-App is: 'App-to-App' redirection allows the TPP to redirect a PSU from the TPP application (in a mobile web browser or mobile app) to the ASPSP’s mobile app, installed on the PSU's device, where the TPP is able to transmit details of the request along with PSU preferences (e.g. product type, one-step authentication) and deep link the PSU into the ASPSP app login screen or function. The PSU is then authenticated through their app using the same credentials/methods as normally used when the PSU directly accesses their account using the app (typically biometric). This must not involve any additional steps (such as being redirected first to a web page to select which ASPSP app to use) and must not require the PSU to provide any PSU identifier or other credentials to the ASPSP if their current ASPSP app does not require this. Where the PSU does not have the ASPSP's mobile app, they should experience a redirection flow which should not involve additional steps than would be the case when the PSU authenticates with the ASPSP directly (e.g. be redirected to the ASPSP's mobile website). |
|
| 7 | Error Codes: ASPSPs must provide TPPs with the error codes included in the Read/Write API specification for failed requests (see Section Standard Error Codes. TPPs should then use the error code provided to determine the content of the message displayed to the PSU. This message should describe, in user-friendly language, what has gone wrong and what the PSU should do next. (OBIE will carry out research into effective PSU error/failure messaging from the TPP and include the output in the next revision of these guidelines). |
|
| 8 | Consent PSUs must be able to understand the nature of the service being provided to them, and the consent should be clear and specific. |
|
| 14 | Functionality – account information Note this refers to account information as defined in the PSRs. Please consult Permissions and Data Clusters for AIS journeys (Optional Data) for clarity around "Optional Data" (e.g. "Party data"). |
|
| 15 | Functionality – joint accounts If a joint account holder can access all account information without any action on the part of the other account holder directly with the ASPSP, then this functionality should be available when using an AISP. |
|
| 17 | Authenticating to refresh access There an example in Refreshing AISP access that clarifies this. In this example, nothing in the consent request has changed (e.g. the PSU gave consent for account information to be shared for the payment account and wishes the TPP to continue to have access to the account). If the PSU has an opportunity to reselect or change the consent request and accounts being shared, this requires a full end to end journey as per the initial consent journey including account selection as in Account Information Consent. The point of this question is to ensure that the journey in Refreshing AISP access is shorter than that in Account Information Consent. |
|
| 19&20 | Supplementary Information: ASPSPs should determine the situations where Supplementary Information is required to be shown to the PSU, having regard to the principle that parity should be maintained between Open Banking journeys and ASPSP direct online channel journeys. Supplementary Information may be required: •Where fees and charges apply (e.g. for single CHAPS payment). •Where interest rates apply. •To facilitate confirmation of payee (for UK implementations, where ASPSPs applied COP validation and found inconsistency between payee account name. •To display a PSU warning that the relevant payment account will become overdrawn / exceed an overdraft limit as a result of the intended payment. | * If the relevant payment submission cut-off time has elapsed and the ASPSP wishes to offer an execution date/time. * Where the PSU has been identified by the ASPSPs as a vulnerable customer (who therefore receives tailored journeys and messages in ASPSP’s own online platforms). * To show value-add information based on functionality implemented by ASPSPs in competitive space which provides positive customer outcome (e.g. cashflow prediction engine). * For high value transactions using a different payment scheme. * Where the payments may be duplicated by the customer in a short period (e.g. ASPSP may display a warning that payment appears to be duplicated). |
| 21 | Functionality – payment initiation For example, even if an international payment can only be made through a web browser when a PSU accesses the ASPSP directly, the PSU must be able to make an international payment via a PISP irrespective of authentication channel. |
|
| 25 | Functionality – payment status This deals with the status of payment and more specifically, to meet the regulatory requirement as per PSR Reg. 69(2)(b). Currently, the "Payment Status End point" allows an ASPSP to provide the TPP with a status message regarding the payment initiation and payment execution (pending, rejected, or accepted) at the point in time, when the ASPSP receives the payment order from the PISP for execution. |
|