Other pages in this section
The Customer Experience Guidelines and Checklist form part of the Standard Implementation Requirements, and set out the customer experience required to deliver a successful Open Banking ecosystem, alongside technical, performance, non-functional requirements and dispute resolution practices.
The CEG Checklist has been developed for ASPSPs and TPPs to assess compliance to this aspect of the OBIE Standard Implementation Requirements.
The CEG and CEG Checklist are consistent with:
In developing its Standard Implementation Requirements, OBIE has undertaken extensive engagement with different market participants, and analysis to ensure that its standards have been designed in line with relevant regulatory and market requirements.
On this basis, where an ASPSP seeking an exemption notifies the relevant National Competent Authority (NCA) (e.g. the FCA in the UK) that its dedicated interface follows the OBIE Standard Implementation Requirements, we expect this will provide a level of assurance that the ASPSP meets the requirement of RTS Article 30(5). Conversely, when an ASPSP has deviated from the Standard Implementation Requirements, we expect that the NCA may require additional information to enable it to consider more closely whether the ASPSP’s implementation is compliant with the relevant regulatory requirements. This may include the NCA requesting additional details on how and why there has been a deviation.
For this purpose, we would expect an ASPSP to complete and submit the CEG Checklist, providing supporting evidence as appropriate, to OBIE. This can then be provided to the NCA in support of its application for an exemption.
The CEG Checklist takes the form of key questions that have been designated as either “required” or “recommended”.
The CEG Checklist sets out which specific requirements are relevant to the Open Banking Standard Implementation Requirements, PSD2, the RTS and the CMA Order. Where relevant, it provides a regulatory reference (as per the CMA Order, PSD2/PSRs and the RTS on SCA and CSC). These are marked as either mandatory, optional or conditional in line with the definitions used across the Open Banking Standards.
For TPPs, certifying against the CEG Checklist is considered as a signal of best practice to the marketplace.
OBIE will consider the CEG Checklist for quality assurance and compliance purposes alongside other sources of information.
Customer insight and regulation-driven principles underpin the core customer journeys described in four sections:
ASPSPs should be familiar with their own role and that of other participants across all these proposition types.
TPPs (AISPs, PISPs and CBPIIs) will naturally focus on the proposition types that are relevant to their business model, but they should still be aware of the roles of all participants in order to ensure they understand the lines of demarcation and differences between each type.
Each unique journey has been broken out and described over a number of pages. They can be then be referenced in a number of ways according to individual priority e.g. whether the reader is, for example, a Regulatory Expert, Product Owner, Technical Lead or CX Designer. The page types are:
For the purposes of the Customer Experience Guidelines as explained on the previous page, for each core use case customer journey, interaction and hand off have been broken into a set of clear, highly simplified white-label ‘wireframes’. These are intended to be platform agnostic, to place focus on only the key elements within (e.g. messages, fields, checkboxes) and the specific number of steps that the customer must navigate. In all cases they are constructed around the primary Open Banking Customer Journey, which is illustrated to the right.
At the core of all Open Banking customer journeys is the mechanism by which the PSU gives consent to a TPP (AISP or PISP or CBPII) to access account information held at their ASPSP or to initiate payments from their ASPSP account.
In general, simplified terms, the consent request is initiated in the TPP domain (step 1 right). The PSU is then directed to the domain of its ASPSP for authentication (step 2 right). Then, once authentication is complete, the ASPSP will be able to respond to the TPP’s account information or payment initiation request and redirect the PSU back to the TPP for confirmation and completion of the journey (step 3 right).
Get Started Previous
Introduction (section A) Next