The reality of open banking payments

The reality of open banking payments

Nikita Septucha, Head of Technical Sales and Implementations, dives into how the open banking payments market is developing and stacking up against the card world. 

Some of you know me from my card payment days, where I spent a number of years in technical sales and implementations for large merchants and financial institutions. So, I'd like to think I know my stuff. I often get asked questions by people who are also considered experts in card payments, but haven’t had much exposure to open banking. “So, how does it compare to card payments?” “Do you really think open banking payments will take off?” “How complicated is it to implement?” Given these questions and the ongoing dialogue in the market, I thought I would share my view from an implementation standpoint and draw parallels with the card world.

Onboarding with banks

To take payments in the card world, a merchant needs a gateway and an acquirer (I know, I am simplifying a bit, but bear with me). The acquirer will have a relationship with schemes through which they access all of the issuing banks around the world. Connect to Visa and Mastercard, and you are pretty much sorted.

In Open Banking, you need to connect to every single bank (that’s the issuer for everyone in the card world) with whom you wish to be able to initiate payments. Did I mention that there are about 4500 banks in Europe? Multiply that number by all of what I’m about to peel back the layers on and you’ll get a picture of the complexity we’re dealing with and why having the right solution (and partner) in place is critical to reaping the benefits of open banking payments and data.

If you embarked on this journey alone, what you would find is that all of the banks have implemented subtly different API standards. I know someone will say “hang on, what about Berlin Group standard, or OBIE and STET? These are really the only three that the banks use.” What I’ve uncovered in terms of variation across banks leads me to refer to these less as standards and more as frameworks. For example, some banks have taken a standard and decided to implement their own bespoke headers. Others have added a requirement for additional redirection as part of the user authentication, and the list goes on and on. 

Once you finish integrating with a bank, you need to register to access the production environment. This process can also be very inconsistent. Some banks support registration through the API, and others require it to be done through their Developer Portals. I have also seen a PDF application form from one of the banks. In my personal opinion, the major banks in Germany are winning with an API-based approach, but in other territories there are very significant variations holding back market growth.

To access production interfaces, you also need to use eIDAS certificates, of which there are two types. And you guessed it, there is also more variation in what banks require. Only regulated third party providers (TPPs) can access banks’ interfaces and obtain eIDAS certificates from one of the Qualified Trust Service Providers (QTSPs). Getting an eIDAS certificate probably requires a mini blog post of its own (I’ll add that to the queue). Token went through this process in the summer of 2019 when open banking was starting to take off and it’s safe to say that we have some war stories to share, but I’m happy to report that the industry has moved on since then. There is now much more clarity and QTSPs have done their job to make TPPs’ lives easier.

User Experience

In the card world, the user enters a card number and then Secure Customer Authentication (SCA) kicks in (aka 3DS). That is where there are actually a lot of similarities between open banking and cards, as over time (and we already see that trend now), SCA for 3DS and open banking payment authorisation will be similar. 

But let’s look at what happens in the open banking scenario before SCA kicks in. The user has to let the merchant know which bank they would like to use for initiating their payment (the good news is that in some countries, this is all the user has to do). After that, they are redirected to the bank’s environment, authenticated, asked to select an account they would like to pay with and voila, payment initiated. The UK, France, Portugal and Poland are good examples of this flow. In some territories, however, a user is required to provide their IBAN before they are redirected to their bank. This is where things can get a bit tricky. In Germany this isn’t a big problem - consumers are used to that (thank you Sofort!) and IBANs are printed on their debit cards. But in other countries, consumers will need to be educated and get comfortable with these flows.

When I said “voila, payment initiated,” I didn’t mention any details regarding authentication and how users actually get to do that. Banks support different methods - redirection, embedded and decoupled. Not all banks support all methods; there are user experience inconsistencies and integration variations, which add to the challenges. There is also universal linking redirection to bank mobile apps (where supported, of course) and how to recover from those also adds some complexity. 

Reconciliation

Cards are a well-oiled machine when it comes to reconciliation. Acquirers or gateways ensure you will always receive a gross or net payment accompanied by a report that is reasonably easy to reconcile.

There are a number of things to look for in open banking. First, references are used for reconciliation. If you are familiar with SEPA payments and ISO 200022, open banking APIs in Europe largely map to the remittance information fields from the ISO standard. However some banks only support unstructured remittance, and in some cases, structured needs to be populated. In some countries, there are local requirements, where specific fields need to be used for domestic payments. So again, if you are building a pan-European solution and want to accept payments from customers around Europe, having a consistent reference that can be easily reconciled is a consideration.

It’s worth pointing out the speed of transfer and fees. The UK is a great example where Faster Payments rails are used by all major banks and it is free for consumers to use. In Europe, not every bank supports SEPA Instant and if they do, they can charge consumers up to 1 Euro per transaction. Merchants will need to review which endpoint on the bank side they want to use, and balance speed and cost of transfer.

Partnership is critical to success    

Open banking can be complicated, but I’m not highlighting this just to paint a picture of the complexities in what is still a developing market. When it all comes together, it is a great user experience. In the UK, in my opinion, the user experience amongst the CMA9 banks is reasonably consistent and with some banks, I would categorise it as amazing. We have the OBIE’s hard work to thank for this. I would personally choose it over my debit card if more merchants provided this option. Open Banking is still in its infancy but it will soon revolutionise payments. I have no doubt that it will have the same impact on debit card payments as iDeal has had in the Netherlands. 

There is a light at the end of the tunnel. Having the right solution in place to help you overcome fragmentation in the market is critical to delivering value back to your organisation. What started as a journey to solve PSD2 compliance has taken us to a place where we can confidently say that we have solved, or are actively solving, a lot of the roadblocks that I’ve shared. Token is working with industry associations and banks across Europe to build the open banking infrastructure that will deliver real value to everyone in the ecosystem. The benefits that open banking payments bring to merchants, lowering costs and increasing conversions, are unmatched. 

If you have feedback or questions, we’d love to hear from you.