API Connect

 View Only

Q&A with the Head of Technology at Open Banking Ltd.

By Alan Glickenhouse posted Fri November 16, 2018 03:48 PM

Industry standards and regulatory requirements are coming to your industry - it is just a matter of time (and place).  In the case of Banking, the time is now, and the place is Europe.  Recently, I discussed Open Banking, PSD2, and more with Chris Michael (@cjemichael) who is the head of technology at the Open Banking Ltd also known as the Open Banking Implementation Entity.    Here are the key points from our discussion:

AG: Let’s just get a few basics set up front.  Can you give us a brief definition of Open Banking, PSD2, and the positioning?

CM: Open Banking is a global construct which can be thought of as the first use case for open data.  PSD2 is the second payment services directive which is European legislation which came into force earlier this year but is due to be implemented across Europe in 2019.  Effectively what PSD2 does is put some boundaries around open banking.  It defines how customers can give access to their bank account to regulated third parties.


AG: Please tell me about the Open Banking Implementation Entity

CM: The Open Banking Implementation Entity was set up by the Competition and Markets Authority in the UK in 2016 and our remit was to create a standard for the 9 largest current account providers in the UK, called the CMA 9.  The CMA 9 would implement these standards which were designed to be in line with PSD2 albeit a subset of PSD2.  Effectively the Entity has been creating standards but also ensuring that the ecosystem gets off the ground.  So, we create the standards but also help the banks and third parties implement those standards.


AG: What are the PSD2 obligations for a European bank?

CM: PSD2 puts in place a framework for how third parties can be regulated for distinct types of activity either the Read API or read access to access transactional and account information, or the write access or payment initiation to access the account to initiate a payment.  So, those two things together are the primary use cases for PSD2.  PSD2 has put in place the regulatory technical standards which are a definition of how banks should ensure they are only talking to a regulated third party.  PSD2 also put in place the requirements for strong customer authentication that requires two factor authentication so that it is not based solely on information that can be shared (such as a Userid/Password).  The regulatory technical standards for PSD2 come in to force in September 2019.  So, by September 2019 all banks across Europe must comply with these technical standards.  Banks either must put in place a dedicated interface (i.e. API interface) which meets those requirements or must provide a modified version of their existing customer interface which effectively means an upgraded version of screen scraping.  In either case, banks must make sure that it is only a customer or regulated authorized third parties who are accessing an account.


AG: How has Open Banking adoption gone in the UK?

CM: We are getting increased adoption of both non-CMA 9 Banks and regulated third parties who are building against the standard.  It is still too early to see massive customer adoption.  But we are starting to see that some of the larger third parties are starting to get a reasonable number of customers on-board.  It is still too early to say there has been a significant end customer impact.  We expect that to happen during next year.


AG: Without getting into too much detail, can you describe the Open Banking standards from a functional, security, and customer experience perspective?

CM: There are three core parts to the standard.  The functional API standards define the request / response payloads for various use cases.  The primary standards we have now are:

  • an API standard for account information, that is the Read API,

  • a standard for payment initiation that covers different payment types – single payments, recurring payments, future date payments, bulk and batch payments,

  • another API for confirmation of funds.

  • we have a fourth API called event notification to enable banks to notify third parties of a change in status of payments for example, and

  • we are also building an API specification for management information for reporting on things like performance and availability.

The security standards break into two areas.  There is a standard that covers redirect flows where a customer is redirected to their bank account and then redirected back to the third party.  And, we have a decoupled flow which caters for scenarios such as when a customer is accessing a third party application on a web site, but they want to authenticate using their banking App on their mobile phone.  We have been developing both the redirect and decoupled flows in collaboration with the OpenID foundation, so they are not an Open Banking Ltd standard – they are OpenID foundation standards.

We have also developed a set of customer experience guidelines which define at quite a granular level what banks must do or should do in terms of the authentication experience.  One of the challenges we had when we started to go live in January was the variance in how banks authenticated customers - how many screens they put in place, and that was perceived to be somewhat of a barrier.  So, we put some detailed customer experience guidelines in place.


AG: How will banks use the standards to satisfy PSD2 and, beyond that, achieve commercial benefits?

CM: PSD2 places several requirements that banks need to fulfill but on its own it does not provide what the market needs.  There is some contention between banks that might want to only do the bare minimum versus third parties in the ecosystem who want an awful lot more.  An example of this is when you look at the information returned in an API.  Banks are only obliged to return the same information that is available to customers via the online interface.  But there may be much more information that the banks might have on the transactions.  For example, if it is an ATM withdrawal, the geo location of the ATM is known to the bank and would be very useful to third parties.  But, the banks do not have to provide it from a regulatory point of view.  What we have tried to make sure is that the standard does enable banks to provide this extra information if they choose to perhaps under some costing model.  Under PSD2 banks are not allowed to require third parties to have a contract and third parties can have access to the PSD2 required information, with the customer’s consent, at no charge.  By ensuring that the standards go beyond the minimum requirement we can provide a framework where banks can provide additional functionality and additional data where they might be able to charge for this value.  This could provide additional revenue streams for banks and at the same time meet the needs of the market.


AG: PSD2 defines multiple roles working in an ecosystem.  Can you explain the key services required by the ecosystem: conformance, certification, directory and support services?

CM: PSD2 defines roles for different actors - for several types of third parties and for banks and what their roles are.  However, PSD2 doesn’t even say that there needs to be standards.  It just says that banks need to meet the requirements of the regulations and technical standards.  So, what we have done as well as provide a standard is build a suite of conformance tools that are open source that banks or third parties can download and use to test that their implementation does meet the standard.  This is incredibly useful because it helps banks know that they have built things correctly and allows third parties to test as well.

On top of that we have also been building a certification framework so that, as well as using the tools to test conformance, we can help banks prove to the ecosystem that they have met the requirements by enabling them to publish a certification on our web site.  The bank can then point to this, and third parties and regulators can see that there is a proof point that the bank has met the requirement.  It is largely self-certification so there is a limited amount of validation that we do. But, this is an incredibly valuable service.

The third element is a trust framework or directory.  This is a look-up service.  PSD2 requires that banks or third parties identify themselves using eIDAS certificates which are certificates for both web sites and message signing.  However, just relying on certificates alone is not enough because it does not supply the real time status of an organization, nor does it provide the ability for banks or third parties to look each other up and discover who is in the ecosystem and, nor does it require some of the more granular requirements regarding security around things like recycling keys.  So, we built something called the Open Banking Directory which is a platform that meets all these requirements and this is something we have been live with in the UK since January.

We also provide a huge amount of support.  We have been doing this since before January, so this has been helping banks and third parties using the standards, using the conformance tools, helping them with certification, helping them integrate with the directory, and helping them integrate with each other.  We do an awful lot of hand holding and helping people resolve issues.

So, all these four things: conformance, certification, directory, and support - these are not requirements of PSD2, but without them it is difficult to see how an ecosystem can get off the ground.


AG: Europe has been leading in Open Banking, but this is now expanding to other regions and industries.  Can you give me your perspective on Open APIs, beyond Europe and beyond banking?

CM: What we are seeing outside Europe is other markets looking at open banking.  Probably the most talked about now is Australia.  Australia has introduced an open banking regulation which is part of something called the Consumer Data Right.  And we are seeing several other markets looking at open banking and the question is whether the regulators in these markets force the banks to implement this or just provide some sort of framework to allow the banks to do this.  And, there is an interesting thought here which is – do the banks provide better APIs if they are doing this for commercial reasons or will they provide better APIs if they are required to do it by regulation?  The reality may be somewhere in between.  Open banking is something that almost every country is considering whether it is the regulators thinking about it or the banks thinking about it but typically it is both.

What you are seeing in Australia is that they are looking beyond open banking.  They are looking at extending this to Telecommunications and Utilities as well.  And, there are obvious use cases for open APIs in industries like Healthcare.  Anywhere that a customer has data held by a third party, the principle is that it is the customer’s data – whether it is a person or a business customer – it is their data and they should be able to get access to the data and an API is the best way to do this.  The question is should they be able to give that data to anyone or should there be some sort of regulation as to who is allowed access.  For example in banking you are providing financial services with the data and this requires that you need to be regulated.  So, it makes sense that only regulated entities can have access to the data, obviously with the customer’s consent.

This is moving fast.  Almost every country is talking about open banking and quite a few countries are talking about open data as well.

I would like to thank Chris for his interesting insights and direct you to the open banking web site: https://www.openbanking.org.uk/ for additional information.


IBM provides an Open Banking Sandbox as part of the IBM "PSD2 Solution Framework". This is built on the experience of 30+ customers using IBM API Connect for their PSD2 implementations across Europe and beyond.


To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website.  IBM API Connect is IBM’s complete foundation to Create, Secure, Manage, Test, and Monitor APIs.  You can find more information about IBM API Connect at the API Connect website.  And you can also experience a trial version of API Connect.


If you have questions, please let me know.  Connect with me through comments here or via twitter @Arglick to continue the discussion.