OBIE is releasing this guide of ‘quick wins’ which can be taken by participants today, in August 2020, to optimise conversion rates and reduce the frequency of consumers abandoning in-app user journeys prior to completion. These suggestions build on our existing Customer Experience Guidelines, and will be complemented by OBIE’s investigation into the “root causes” of low conversion rates overall, as part of item A7 of the Revised Roadmap. 1. Customer Experience One of the key factors that participants can control relating to conversion rates is the customer experience they provide to their users. OBIE’s Customer Experience Guidelines (CEGs) were developed over a significant period of time and reflect a wide range of stakeholder input, including customer research conducted by OBIE. While the CEGs continue to be monitored and updated, the guidance and suggestions within it for how to implement authentication procedures for users across a range of journeys are widely considered to be best practice, and we encourage all TPPs and ASPSPs to align to them as closely as possible. This can be done in a variety of ways: Removing unnecessary friction The core journeys discussed in the CEGs are based on a very simple but effective 3-step consent model of: Gathering consent at the TPP; Redirecting the customer to their ASPSP to authenticate; Confirming success back at the TPP. This can be done in a very streamlined and simple way, particularly when biometrics can be leveraged. Example 1: Simple AIS journey Unsurprisingly, research and market data show that customers are more likely to fail to complete a journey when they are required to navigate unnecessary steps or additional screens to complete authentication, particularly for low-risk transactions or access requests. TPPs and ASPSPs should focus on what they can do to help the user first time round and again when they are repeating a journey. For example, a customer should not be required to select their account at the ASPSP if they have already provided it to the PISP. Example 2: Sort code and account number provided to the PISP Of course, removing unnecessary friction and optimising journeys does not necessarily mean making them “short” or “fast”. There are many scenarios where consumer risk plays a larger role, for example, mortgage approval or a large international payment. In these instances, we remind participants to consider the whole journey, including messaging, the smoothness or “cadence” of the experience, and the ability for customers to use the channel of their choice. Example 3: A “long” but customer-friendly journey Of course, there are also long and customer-unfriendly journeys. Some examples live today redirect customers several times to multiple parties, greatly increasing the likelihood of drop-out. TPPs must consider the full end-to-end flow – especially when working with third parties – to ensure that their journey provides a balance; one that is both streamlined and transparent in relation to third parties. Improving 90-days re-authentication A significant pain point prominent in the market today is the requirement to re-authenticate AIS connections at least every 90 days. While this remains a legal requirement (given the terms of the RTS and the recent EBA Opinion), we encourage all participants to think about ways they can reduce the burden on the end-user. In particular, intelligent communication with customers can be used to inform them about an upcoming expiration and allow them to more easily control the AISP access. TPPs must take the initiative to proactively encourage consumers to refresh their access, thinking more in terms of when a “good” time is rather than simply “every 90 days” and helpfully directing them to their ASPSP to do so. For example, if a user has logged in to review their spending and can see they have made progress against their goals an AISP could take advantage of this as an opportunity to remind them that their access is set to expire in the near future. Example 4: “Happy path” re-authentication to refresh access It should be noted that consent to a TPP can last longer than 90 days, and there is no requirement for the customer to re-confirm a valid consent with the AISP. AISPs that agree a longer consent duration will benefit from a shorter ‘refresh’ authentication journey in the domain of the ASPSPs as shown in the CEGs. To that end, we are aware that some TPPs are not always taking advantage of the benefit of the streamlined 90-day re-authentication journey offered by many ASPSPs and are instead taking the customer through a new consent journey every 90 days. We strongly encourage TPPs to correct this, provided that their service offering supports this, as it is likely to improve re-authentication rates on the levels being seen today. While entering formal arrangements is obviously at the discretion of organisations, there are potential benefits given it may remove the needed for customers to go through an authentication journey at their ASPSP. OBIE has provided an example of an AISP performing SCA on behalf of an ASPSP to reduce friction here. Using customer-friendly language The amount, tone and type of messaging customers encounter during interactions with TPPs and ASPSPs have been tested and analysed by OBIE in the past and we have released guidance on how to improve consumer comprehension. That said, we see a divergence from this advice in many journeys live today. For example, while OBIE is supportive of the Contingency Reimbursement Model (CRM) Code and aware of the need to protect consumers from increasingly sophisticated scams, we are concerned with the complexity and messaging used in some implementations we have seen. Similarly, customers should feel reassured when using a journey and, if they encounter different messaging or terminology to their “normal” experience, then this is likely to put them off. A common example of this is an ASPSP displaying the legal name of a TPP rather than a brand name during a journey. A powerful but often overlooked part of the Standard is the ability for TPPs to communicate a brand – as opposed to legal – name to ASPSPs and this should be taken advantage of by participants. More information can be found here. The look and feel of a journey is also important and ASPSPs should ensure their parts of the journey are strongly branded so that their visual display gives the customer the confidence that they are providing their security credentials safely within their domain. If TPPs or ASPSPs are seeing lower conversion rates than they would expect, we strongly encourage they revisit all aspects of the messaging they use and conduct market research to refine it. Example 5: Simple and effective consent page copy As well as the messaging used during journeys, ASPSPs should ensure any messaging relating to open banking services provided through their website, customer service agents or advertisements does not deter customers from using services that are as secure as direct banking experiences. Explaining why something has gone wrong Clear, user-friendly explanations as to why an authentication journey has failed will make it more likely for a customer to reattempt the process. Screens with random error codes that mean nothing to a normal user are going to end in frustration! Additionally, helping customers re-try and get back to their TPP to “start over” is much better than getting them stuck in limbo. As part of this, it is essential that the user is being directed to the appropriate channel. TPPs must work with ASPSPs to ensure users are directed to the appropriate journey depending on their starting channel and type of account. This may include the launch of a mobile-based browser during a journey, though this should be avoided if possible. Example 6: Good vs. bad messaging within journeys As well as explaining what has gone wrong, we are aware that there could be a more consistent approach taken by ASPSPs and TPPs when referring customers to information relating to open banking, such as the list of regulated providers. Participants are encouraged to think about what information may be useful for customers and reassure them about using their services. Giving customers what they want Ultimately, customers should be in control and able to do things the way they want to. The introduction of app-to-app authentication has been a significant success story, offering users an improved customer journey with lower friction and at the same time higher security through the use of biometrics and device/behavioural analytics. Data shows a direct correlation between making app-based authentication available and higher consent success rates, and digital-only “neo-banks” have higher levels of consent success overall. TPPs are strongly encouraged to provide app-based offerings to improve customer experience and overall conversion rates. Moving forward, both ASPSPs and TPPs should continue to innovate in the space to provide customers with simple and secure ways to authenticate, capitalising on advances in biometrics and geolocation device pairing to make highly informed risk-based decisions. Example 7: Biometric authentication One major addition to the OBIE Standard is known as decoupled authentication, where the customer uses a separate device to authenticate with their ASPSP e.g. using a mobile phone to authenticate a desktop payment. This model allows for a number of innovative solutions, taking advantage of biometrics for SCA, for example where a customer is engaging with a PISP through a point of sale (POS) device. While OBIE does not yet have any hard data in this regard, we have heard reports of enhanced customer satisfaction from both TPPs and ASPSPs when this is offered. Launch interactive demo Example 8: Making a decoupled payment As a general guiding principle, ASPSPs should provide customers with the exact same authentication experience when a TPP is involved as when it is not. 2. Technical performance Equally important to conversion rates is the technical performance of the APIs and any underlying systems required for the service delivered to the customer. OBIE’s Operational Guidelines (OGs) cover many of these issues in greater detail, but we have summarised some key parts here. Reliability, availability and performance of APIs Any delays or lags in journeys due to poorly performing APIs will cause unnecessary dropouts, and ASPSPs should strive for seamless journeys with minimal time between screens/loading times. Additionally, ASPSPs must resolve issues with poor API availability or excessive downtime in a timely manner, as this may prevent a customer from being able to authenticate and grant access to a TPP. OBIE is aware of issues caused by ASPSPs updating their APIs to implement a new version of the Standard and deprecating old versions without sufficient testing with TPPs, so we strongly encourage this is done to ensure a smooth transition that is invisible to customers. Further information and expectations relating to these issues is provided in the Availability and Performance section of the OGs. While a significant level of expectation is placed upon the ASPSP community here, TPPs also need to ensure they update interfaces with ASPSPs as and when updated versions of the API Specifications and/or Security Profiles are implemented. Overall responsiveness and speed of the customer interface Aside from issues relating to user experience and design, another major factor is the overall responsiveness and speed of the customer interface, be it web or native mobile applications. While the number of clicks and screens are important, the load time of each screen and number of redirects are also fundamental to the overall user experience. Load times should be lower than 1 second wherever possible, and a maximum of 3 seconds in any event, to keep an experience feeling “real-time”. While this may ultimately depend on the speed of any underlying core banking platforms, optimising load times and making technological improvement is critical. Clear communication and collaboration All participants need to work collaboratively to ensure customers do not experience interrupted service. As noted above, ASPSPs need to ensure sufficient testing with TPPs before switching off old versions and, in this regard, effective communication allows ASPSPs and TPPs to manage expectations and inform customers about planned downtime. ASPSPs should also consider using the (optional) real time event notification functionality specified in the OBIE Standards to notify TPPs at the time of an update, instead of relying on TPPs to request this information. ASPSPs must implement appropriate processes to enable a timely response and resolution to issues reported by TPPs (e.g. via the OBIE service desk). OBIE is continuously working to optimise the service desk, monitor CMA9 conformance, and enhance the management information data collected on a monthly basis to improve our understanding of the ecosystem. We have provided some guidance on these matters in the OGs under Procedures, Processes and Systems for Problem Resolution. Of course, TPPs also have data that is of interest to ASPSPs and are always welcome to approach them directly to discuss issues as and when they arise. Many ASPSPs have provided feedback that more consistent data sharing by TPPs would be mutually beneficial and we therefore strongly encourage TPPs to consider what could be done in this regard. 3. Final thoughts Customers will only use open banking products and services if their experience matches or betters their expectations, and when information is presented in an intuitive manner that allows them to make informed decisions. It is therefore important that the interplay between the TPP and the ASPSP is as seamless as possible while providing customer control in a secure environment. In particular, it is essential that customers are clearly informed about the consent they are providing and the service they are receiving. The above suggestions are intended to provide participants with useful suggestions to enhance and improve customer journeys, with the expectation that all participants are eager to contribute to the success of open banking in the UK and beyond and are committed to ensuring the best possible experience for customers. While we await the outcome of the Root Cause Analysis exercise, OBIE will continue to engage with the ecosystem on the matter of consent success, and encourages all participants to contact us with any suggestions or concerns relating to customer authentication journeys. We hope that this guide gives food for thought, and, at the very least, we strongly recommend all participants keep their applications in line with the very latest version of the Customer Experience Guidelines and Operational Guidelines as we work towards even greater adoption of open banking.