I began by asking Chat GPT what Open Banking is for.
Open Banking is a framework designed to give consumers and businesses more control over their financial data and more choice in how they manage their money. Its main purpose is to increase competition, innovation, and transparency in the financial sector.
I am not going to disagree with that. In the following I am focusing on competition, but first …
One distinct advantage of the Open Banking approach is that it shares no credentials with third parties, although to make the most of this as an advantage, you would need to consider it to be a problem that needed fixing.
The sharing of consumer financial data – the non-payment end of Open Banking – is brilliant, and it certainly opens the doors to competitive financial services and activities that must benefit consumers.
But, and it’s a big “but”, there is no business case for making consumer financial data available to 3rd parties, and many of the 3rd party business models depend on consumer financial data being provided for free! To this end, a minimum commitment to the provision of Open Banking consumer financial data is required by the Competition and Markets Authority, and this is recognised in the UK National Payment Vision [3.27].
If you have seen the apple wallet recently, you can’t have helped noticing that the payment history relating to card transactions has dramatically improved. Instead of being able to see only the card transactions completed by the wallet, we can now see everything! The apple wallet, and therefore the apple wallet consumer proposition, is benefitting from consumer financial data provided for free but delivered at a not insignificant cost to the data providers!
Competition
As I recall, one of the reasons given for the support and development of Open Banking was to challenge the dominance of the card monopolies. This would have meant supporting developments on the payment side rather than the financial data side, and then defining clear demarcation between the two alternative payment options.
Open Banking transactions are fundamentally different to those derived from Cards. Open Banking payments are real-time payments that deliver real-time credits to retailer accounts, whereas card payments are aggregated and settled post event. For small retailers – both F2F and e-comm – this will present some challenges but is broadly manageable; for larger retailers, the nature of the Open Banking payment will become an issue. This challenge is also recognised in the UK National Payment Vision [3.15] but the same document doesn’t identify any potential solutions.
A Possible Solution
One solution to the logical mismatch of mechanisms and processes is to create the concept of a “Merchant of Record”: a sort of intermediary that takes the real-time element of the Open Banking authentication and authorisation request, grabs the cash and then delivers it to the merchant with all the other account credits for the day, along with an accompanying settlement file.
If the “Merchant of Record” is standing in for the true merchant and is first in line to receive the cash destined for the true merchant, then I wonder what is going to be shown on the consumer’s bank statement.
The consumer will see their account debited immediately but the true merchant will receive it at some time in the future; in the meantime, it sits with the “Merchant of Record”. This means that the feature of Open Banking that adds most value – immediate, real-time payments – no longer applies as the payment to the true merchant is delayed until settlement. Also, the true merchant is going to need confirmation of payment (or a guarantee) rather than simply the confirmation of instruction – subtle but important!
It seems to me that if we are going to implement Open Banking for all merchants, then we are going to need to adopt a “Merchant of Record” approach to counter the issues likely to be caused by the inevitable increase in the number of account credits. In principle, the “Merchant of Record” approach seems to address a lot of the high-level challenges, but at the lower levels, there are many reasons why it does not.
But, if we accept that the “Merchant of Record” approach is a good one (Hmmm!), and we also accept that card technologies are going to be around for a long time to come, then we are also recognising that we have two payment channels where we used to have one (not counting cash).
Any merchant adopting Open Banking will therefore be duplicating the effort of accepting payments with a separate authentication, authorisation and settlement process for both, which is going to be expensive, unless …
The Challenges – resolved!
We have given away our national payments infrastructure to the card schemes (one of ‘em!), so maybe we can all see where this is going.
It’s interesting that both Visa and Mastercard (and the others) are looking towards Open Banking even though it isn’t a core competence, essentially in a bid to make sure that they are not left behind. However, there is a fundamental difference between Open Banking and card-based transaction technologies, so what is going on?
Merchants, like most of us, prefer simplicity over complexity, apart from those amongst us that equate complexity with cleverness. A merchant would be much more likely to adopt a new payment mechanism if that payment mechanism was somehow incorporated into existing payment mechanism flows, with similar logic and back-end processes.
Incorporating the “Merchant of Record” into the card scheme settlement processes would, in the big scheme of things, be a fairly trivial matter, requiring a few new record types and some additional remediation logic.
The Open Banking approach to authentication and authorisation processes could be implemented alongside the card authorisation, with the result being passed to the “Merchant of Record” for the settlement part of the transaction.
One difficulty that would need resolving is the fact that a card authorisation represents a guaranteed payment that will follow in settlement whereas the Open Banking transaction completes with a confirmed payment request rather than a confirmed payment. Merchants need to know (I believe) that the cash is in the account before they release the goods, which is not going to work particularly well at supermarket checkouts!
Delayed payments – we tell consumers that they should allow up to two hours for a Faster Payment to land – are an issue for the Open banking transaction flow, and this falls outside the control of the transaction process.
The solution would have to be to treat a confirmation of a payment request as if it were a payment, much the same as a card authorisation is treated as a payment, and rules would be required to support this.
A Card Scheme Solution
The Card Schemes can deploy Open Banking as an additional authentication and authorisation mechanism, with the advantage of it not sharing any consumer payment credentials, if that’s what you are worried about.
The Card Schemes can use the “Merchant of Record” approach, either internally or externally, to aggregate the individual account credits and also link them to an associated retail payment.
Aside: it would be possible to use OB as a front-end authentication and authorisation mechanism that linked directly into card rails without the need for a “Merchant of Record” or Faster Payments, which would be interesting!
The Card Schemes can define Card Scheme Rules that would guarantee Open Banking payments in those circumstance where guarantees might be necessary (and I have been victim to said circumstances, so I think the concerns are valid).
The Card Schemes can merge the “Merchant of Record” records with the Card transaction records of the day and deliver a single settlement file along with a single settlement (accepting that large merchants could have multiple settlements depending on their business model).
What does this mean?
The Card Schemes have manoeuvred themselves into a situation where they have ticked ALL the Open Banking implementation boxes. Logically there isn’t really an alternative approach, and the UK National Payment Vision seems to accept this.
The potential for a competitive payment ecosystem providing multiple payment options from multiple sources is destroyed if the only way to implement the alternative is as an adjunct to the existing service model.
The pricing imperative becomes academic as the new Open Banking services are incorporated into existing card-based services. The pricing of the Faster Payment element of the Open Banking transaction becomes only a small part of the overall pricing of the service as a whole.
Innovation becomes restricted as all roads to new products and services lead to a relationship with a card scheme, this is not what was intended.
Instead of extending the range of payment services provided within a region, the incorporation of Open Banking into Card Scheme portfolios only serves to strengthen their position as the payment option of no-choice.
Conclusion
The apple wallet is extending its functionality on the back of Open Banking, growing the usability of the apple wallet and extending its reach into the marketplace.
The Card Schemes are benefiting from an Open Banking vision that has become clouded. The original vision was one of competition, innovation and transparency; the modified “vision” is one driven by a blind obsession to see Open Banking as a mainstream payment option, with little regard for the consequences.
Open Banking is clever, but the fact that it works very well for HMRC doesn’t mean it will work for Tesco.
We should be innovating, we should be adding value rather than consolidating power, and we should be enhancing the lives of consumers and merchants through that innovation. We should not be giving the game away.
