Understand and Download Checklist

The CEG Checklist is ultimately intended to drive certain behaviours and functionality in the ecosystem in order to:

• Deliver excellent customer experiences that are simple and secure.
• Promote innovation. 
• Ultimately, encourage adoption of Open Banking by both TPPs and consumers

This includes ensuring that:

• Any supplementary information that is ancillary to the journey provides clear customer benefit.
• ASPSPs are able to demonstrate that their implementations “do not give rise to unnecessary delay, friction or any other attributes that would mean that PSUs are directly or indirectly dissuaded from using the services of PISPs, AISPs and CBPIIs“.
• ASPSPs provide the full level of functionality available to PSUs available through the direct online channel irrespective of the TPP channel and authentication method.

It should be noted that for the CMA9 and any other ASPSP that adopts the Open Banking standard, it is expected that a completed CEG Checklist is submitted at least for a.) each dedicated interface, and b.) each brand and segment (Personal Current Accounts and Business Current Accounts). We note that brands may have the same implementations and dedicated interfaces, which means the same CEG Checklist can be submitted. Further, we encourage those completing the CEG Checklist to consider if any further submissions may be appropriate, for example if an ASPSP has “app-only” customers, where having a consolidated CEG Checklist could lead to different answers being provided. Each CEG Checklist submission should be signed off by the relevant business owner.

The CEG Checklist is not intended to be a check on technical functionality or technical performance. The CEG Checklist relates to the Customer Experience Guidelines only. 

In developing the CEG Checklist questions, we have defined some key principles that each question must adhere to:

• OBJECTIVE – be fact based and not rely upon the judgement of the ASPSP or TPP.
• CLEAR – standalone, single clause, closed questions which demand a “yes or no” answer.
• DEFINED – unambiguous and tightly constructed with links to definitions where appropriate.
• TRACEABLE – based on regulatory requirements and/or the OB Standard Implementation Requirements (rationale for inclusion and classification will be made explicit).