CMA, APIs & PSD2: The knowns and the unknowns

The Competition and Markets Authority (CMA) recently mandated that larger banks adopt and maintain a common standard for open APIs (Application Programming Interface) to help create more innovation and competition in the marketplace. In addition, PSD2 (Payments Service Directive 2), due to go live from January 2018, requires banks to open access to customers’ account data and give third parties providers (TTP) the ability to initiate payments on the behalf of the customer.

This introduces a major risk and challenge to banks. Sahana Hussain, Icon’s Solutions Architect currently working with a major Tier 1 Bank on their Open Banking platform, shares her views:

1. The known knowns

The primary driver behind both initiatives is to enable Open Banking. Currently under the CMA mandate, we know that banks must open up their products, data and services to the world via APIs. However, the nature of this open banking landscape will entirely depend on what the regulatory authorities enforce and how the regulation is realised in defining technical standards, security protocols, and establishing governance model.

At a minimum, we know we need to expose public data (like products, locations services for ATMs and Branches) and private data (like customer transaction history, payment initiation and customer account information), but the details of how to be compliant with PSD2 are still missing.

2. The Known Unknowns

There is still a lack of clarity around the TPP on-boarding process and there is still lots to be done to set the standards for the industry Trust model while making sure it works for CMA as well as PSD2. We have also realised that there is a need for a central authority in each EU member state to define governance around issuing licenses for TPP, provide cross-country passporting requirements and enable the end-to-end trust model for ASPSPs (Account Servicing Payment Service Provider, i.e. banks) to transact with the TPP.

We do know that there will be a Registry (central or local) in each member state who will provide the TPP licences and identify them as a trusted TPP. Each bank will then need to have an onboarding process to give them access to the specific APIs depending on their profile (i.e if they are a PISP or AISP). However, we don’t yet have any details around the web certificate that central registry needs to issue and how inter operable it will be for the 27 member states in Europe.

There are also uncertainties around SCA (Secure Customer Authentication). It’s difficult to say whether the banks’ existing two-factor authentication model will fit with the PSD2 requirement or not. I don’t think anyone has even really begun to look at Data Protection and privacy either for the AISP or PISP service yet.

3. The Unknown Unknowns

What hasn’t really been explored yet is how you can architect the Open Banking in such a way that it will provide a frictionless customer experience between online banking and the API journey. Currently, we could end up with customers having a mobile device, a dongle and a password but having to take them everywhere would make it useless for retail.

The ‘unknown unknown’ here really is the user experience user acceptance – no one knows because the customer hasn’t been asked! I imagine there will be two distinct customer groups. The tech savvy ones who are early adopters and happy to explore new things and delegate access to the TPPs to access their private data. Whereas the more conservative won’t want to trust the TPPs to access their data. API analytics will expose the customer behaviours – watch this space!

4. The Ideal

The ideal of course would be to have clearly defined industry wide standards and a flexible, reusable design. Banks should have a ‘compete’ strategy where being compliant with the regulation should not be the end goal – leveraging the commercial opportunity based on a good technology platform should be. Open Banking should be a recognised function, channel and operation within the bank with a clear objective of converting Open Banking to a new revenue stream.

In my view, the ideal ‘SWAT team’ in banks should consist of architects/analysts/technical resources who can interpret the regulations, find the impacts in the existing banking platform and design a strategic solution to deliver a platform that is not only regulatory compliant, but also flexible enough to convert regulatory requirements to a commercial opportunity.  A lot of the things we are building now can be easily re-used for non-PSD2 monetised products.

The Open Banking and API economy will be a game changer for the banking industry – any banking team now standing up to deliver PSD2, CMA or Open Banking should be considered a long term investment rather than a one-shot deal this year. Once a bank has an operational API platform and program, they can expect future digital success to grow, provided they invest and continue to develop their market.