Open Banking in South Africa

Last week I met several banks in South Africa, courtesy of Ping Identity and Ubusha. Over the course of two days, I spoke to Nedbank, Absa and Standard Bank, as well as a number of challengers.

I was interested to see what they thought of the work the Open Banking Implementation Entity (OBIE) has been doing in the UK to develop a standard and certification process, and how this could help these banks meet regulatory and/or market needs regarding Open Banking APIs.

Open Banking will deliver significant customer benefit

Open Banking APIs should offer a more secure, reliable alternative to screen scraping. This will reduce costs and increase the opportunities for money management tools, helping personal and business customers make more of their money.

I believe the most exciting potential is in payments?—?to offer a better, lower cost, more reliable, faster, more transparent alternative to card schemes. For this potential to be realised, banks need to implement APIs which meet both regulatory and market needs.

Introducing the OBIE standard

Version 3 is a truly global standard, which should allow any bank in Europe and beyond to build a great API interface which complies with regulations (e.g. the CMA Order and PSD2).

The OBIE standard is the result of a massive collaboration over two years, involving thousands of stakeholders, including banks, third parties, vendors, consultancies and other standards bodies. All have been able to contribute in an open forum online and in person?—?over 50 workshops to date and counting.

The security model has been developed in conjunction with the Open ID Foundation, and the standard has now adopted the FAPI (Financial Grade API) and CIBA (Client Initiated Backchannel Authentication) profiles. This allows for great customer experience and best in class security to protect banks, third parties and end customers. OBIE has also committed to supporting Dynamic Client Registration, which enables third parties to onboard automatically with banks, reducing the friction, risk and cost of manual processes.

The standard also includes comprehensive Customer Experience Guidelines which define what banks and third parties must do (to meet regulatory requirements) and should do (to meet market/best practice needs) when authenticating a customer’s access to their bank account.

The largest banks in the UK have been live since January and third parties have been connecting and going live with real customers. As of September 2018, these banks are now live with v2 of the standard, and many more are actively building their PSD2 interface using v3.

The OBIE has committed to a roadmap well into 2019, which will add even more functionality and value to the standard.

So, in summary, this is already a proven standard, which is getting better all the time.

Going beyond the standard

However, there have been a number of documented issues, and it still too early to see any significant evidence of end-user benefit. OBIE are doing several things to address this:

1. They have developed a suite of conformance tools and a certification process. This is currently focused on the security profile, but OBIE are extending this to cover the functional APIs and Customer Experience Guidelines. This will be a massive benefit to banks (to help them test and prove compliance to the standard), regulators (to help them evaluate whether banks are compliant), and also third parties (so they can see which banks have implemented correctly).
2. OBIE have also developed a trust framework for banks and third parties. This is called the Directory, and includes a number of features which reduce barriers and risks for banks and third parties. The Directory has been live since late 2017, and the next version will meet all PSD2 requirements, including compatibility with eIDAS certificates.
3. Both OBIE and third party developers provide reference code libraries, including a model (sandbox) banks. This has been essential to speed up development and adoption.
4. Finally, OBIE provide additional support services to help banks and third parties test and connect with each other, before, during and after go live.

As an implementation entity (rather than just a standards body), there is much more OBIE are doing in this space. Ultimately the goal is to drive adoption of the Open Banking ecosystem.

Open Banking in South Africa

Unlike the UK and Europe, the regulators in South Africa have not yet mandated Open Banking. Personally I do not believe Open Banking will work without some regulation. Customers need assurance when they use a third party provider, that they are dealing with a regulated entity. They also need a means to recourse in the event something goes wrong.

Does this mean that banks in South Africa should be ‘forced’ by the regulator to provide unlimited API functionality and access for free? Or is it enough to just create some basic rules and leave the rest to market forces?

I don’t know the answer, but maybe it’s somewhere in the middle. In my experience, companies produce better products when these are aligned to their core business objectives and when they have a financial incentive. I am also convinced that having a great API should be at the heart of any bank’s strategy, so that they can use this to build partnerships with third parties who in turn can bring in more customers and more revenue.

Perhaps the biggest incentive for any bank in any market is the move that big tech giants are making in this space. They will bring customers at scale and will want APIs which offer a great user experience, great functionality, and are fast, reliable and highly available. They also want these APIs to be secure and built to a well-documented standard. And while they may not be knocking on the door of South African banks just yet, it is only a matter of time.

Next steps?

I would urge all banks in any market where there is not yet a regulatory mandate for Open Banking to get on the front foot and build a great API. Banks who do this will realise several benefits:

1. A competitive advantage, in particular by developing (commercial) relationships with third parties ahead of other banks.
2. Reduced likelihood of being forced by a regulator to do this for free and/or in short timeframes.
3. Reduced delivery risk, in the event the regulator does step in, since much of the required functionally may already be delivered.

Banks who follow a standard will find it easier to build their API, as this will reduce the cost and risk of reinventing the wheel. Since OBIE have done the hard work here, I would strongly urge all banks to start by looking at this standard.

Banks should pay particular attention to the developer community, whether small start-ups or larger, more established third parties. Making sure the API is well documented and easy to use is just the start. Banks should also provide sandbox implementations and get feedback via events and hackathons.

Finally, Identity is key to delivering Open Banking APIs securely and with a great user experience. To do this, banks need the right technology, especially in the Identity and Access Management space. Ping Identity has a proven track record with many banks in the UK, Europe and Globally. And Ubusha have the expertise and local market presence to help banks in South Africa implement and integrate IAM solutions and hence deliver Open Banking APIs.