Open Banking APIs are, by necessity, secure. In the United Kingdom, an entity wishing to make a call to a UK financial service provider must be a trusted TPP (Third Party Provider). The exact model is different in other geographies, but the fundamental idea is similar – the TPP will be given access to a certificate that proves who they are and credentials that allow for secure mutually authenticated communication between their servers and the institution they are connecting to.
This all has to take place before an individual user can get to the authentication stage that we’re all familiar with and use OAuth to sign into a service. There are also some added security wrinkles such as the certificates having to be stored securely in a FIPS-compliant storage system.
Open Banking APIs
Over the past few months, we have been working with Fractal Labs to set up Open Banking APIs on production endpoints for numerous UK banks and financial institutions. This involved using the Dynamic Client Registration API when available to register our software statement and signing it with our OBSEAL certificate and connecting to the endpoint using mutual TLS using the OBWAC certificate.
We also had to choose which of the available authentication methods to use at that stage, be it tls_client_auth, private_key_jwt, or client_secret_post. This defines the exact way user authentication is handled.
*Helpful* Open Banking APIs
The most helpful open banking APIs would return meaningful error messages to assist if a parameter was wrong – others would require support emails. Most of the required parameters can be derived from the banks’ published OpenID connect well-known JSON. But that information would often need to be augmented with details from the OBIE Directory, or from the banks’ own support documentation. Usually a website, but sometimes just a PDF document. If dynamic client registration was not available, we would need to contact the bank directly to register as a TPP.
Once registered, the first step was to use a client_credentials auth flow so we could call the account access consent APIs. Here too there can be differences between the banks about what parameters they expect. Sometimes the hardest part here though was finding the full URL to use – that information is often quite hidden!
After consents are working, getting a user authenticated access token involved signing the authorization request and completing a token exchange with a real bank account. Here the exact contents of the request object sometimes needed correcting, but given we’d managed to get this far, it was usually the most straightforward.
In Theory…
In theory, the open banking process is fully detailed and defined by the OBUK standards. But in practice, it’s been somewhat more complicated. Of the 35 institutions which we have been working to onboard, 18 took a few days for one engineer to set up – less than an hour per bank. The next 10 took almost 6 weeks to complete, most of that time spent in days of waiting for responses from support teams followed by hours of wasted time working through random variations of what was suggested.
For Open Banking to succeed we need clear and functional open banking standards, which are secure but also as frictionless as possible to set up.
Given that some banks can make the journey fairly frictionless, there’s no excuse for their peers not to too.
But we clearly have a long way to go before everyone in Open Banking is doing this the way they should.
