Open Banking: How hard can it be?
In this section I am going to lift the lid on Open Banking and take a look at the logic. This is a piece of “be the transaction” analysis rather than a deep dive into the low-level workings of the Internet, which whilst applying very clever mechanisms to protect and secure the transactional information, doesn’t add any value to the logic!
Open Banking is still a transaction processing infant, and will take time to develop and mature, so anything could happen. It was introduced as a means of opening up consumer financial data to regulated and controlled third parties, to encourage improved consumer services and higher levels of competition. It was also envisioned as a cheaper alternative to established mechanisms for consumer payments, introducing competition to the space previously dominated by card payments.
There is much excitement in the industry in relation to the opportunities presented by Open Banking, but in the spirit of openness – no pun intended – my own excitement is somewhat muted. I think the information sharing aspect of the Open Banking vision is solid, with the potential to deliver improved financial services for the consumer, but I do not share the same optimism for the Open Banking payments.
The Open Banking payment model is fundamentally different from the 4-Party card payment model, which currently dominates retail payments.
Is the 4-Party model going to be hard to displace?
Introduction
I have been aware of the Open Banking and the transaction processes since the early days, and I was always struck by its complexity.
The Open Banking authentication and authorisation flow supports two distinct functions:
- sharing financial information in a controlled and regulated environment,
- authorising push payments to 3rd party accounts, like merchants.
Before the sharing of sensitive financial data belonging to a consumer, it makes perfect sense for all parties – the entity storing the data, the data owner and the data recipient – to be authenticated. It also makes sense for the nature and the duration of the sharing to be defined and agreed. The Open Banking regulations provide for this.
To me, the Open Banking payment feels overly complicated for a payment function. Payments should be simple in principle, with the complexities built in response to business needs. The Open Banking process seems to be complex in principle but immovable and unresponsive to the needs of business. On many occasions, I have heard payment professionals telling me it’s only a payment, and then asking how hard can it be. Compared to the traditional card payment model, I would say that it’s now unbelievably complicated and largely set in stone.
I have had first hand experience of Open Banking payment issues, from a customer perspective and from that of a troubleshooting payment professional of many years. I also understand the Merchant’s situation and the changing nature of the challenges that emerge with scale – Open Banking does not scale well.
Experiencing Open Banking Payments
I speak from experience.
When I was working with Paysend, I was reviewing – and also testing – one of the customer propositions, which involved some analysis of the Open Banking solution provided by one of our suppliers. I set myself up with a Paysend account, loaded some cash and then sent £20 to another of my personal accounts.
I could use Open Banking to load money onto my account and send money to another account. The processes had been tested internally and externally, they had been approved by all parties, and they were operating in the live environment.
The money I added to my account was real, it was being moved across a certified production platform from a valid Paysend account to a valid recipient account, and it went missing!
Without letting on that I was an employee and was engaged in testing the processes, I contacted the Customer Support Team, who really didn’t want to know – they told me that I should wait and see. I finally managed to have my missing cash logged for investigation, which I know was duly processed as it landed on my desk!
I contacted the Open Banking service provider, and we were able to identify the transaction initiation exchange. The Open Banking service provider had no overall responsibility for the transaction, and since there was no evidence of any payment being completed, was unwilling to engage further.
I contacted the TSB, where the cash should have landed, explained the situation and was passed to someone in the Open Banking technical space. Together, we were able to follow the process and confirm receipt of the initial transaction messages, but not the Faster Payment.
Following the money, I was able to identify the location of the missing funds, but no one seemed to have the authority to fix it.
Eventually, even though I was told that it was only twenty pounds as though it didn’t matter, I received a payment of £20 into the initiating account. The £20 wasn’t a reversal of the original payment, but a complementary credit, I suppose for my trouble.
I think the missing cash is probably still sitting there.
Open Banking: data or payments
The logic behind the Open Banking transaction flow is very similar in principle to that of the 3d-Secure flow used for authenticating e-commerce transactions. In common, both of these transaction flows move and secure the exchange of data; they are not mechanisms of value transfer.
When applied to the exchange of sensitive financial data, the Open Banking mechanism means that all parties are authenticated and the exchange of information is authorised before any exchange of information takes place. The information exchange is then actioned as a separate, consecutive process, triggered as and when required with applied restrictions and an agreed expiry date.
The Open Banking mechanism when applied to payments follows a similar abstraction of activities. The initial process establishes the parties, accounts and the amount involved, and once authenticated and authorised, another process is triggered to initiate a single Faster Payment for the agreed amount.
For both Open Banking transaction types, there is an authentication and authorisation process that is followed by the original reason for the transaction – money or data. In contrast, and for a cash-focused comparison, a card transaction can be similarly partitioned, with authentication followed by authorisation, followed by settlement. For cards, authentication is managed by the card, authorisation is supported by the network making connections between the transaction parties, and settlement taking place after the main event is concluded.
The difference – and this is significant for an analysis of my own Open Banking experience – is that all network messaging related to cards includes a financial component. The authorisation message carries the initial authorisation amount and the settlement record carries the final transaction amount, which may be different.
Following the money makes it relatively simple to track down issues with card transactions, because an error is likely to have a financial impact, and the value of the error can be matched to individual authorisation requests and settlement records. This point is somewhat oversimplified, but highlights the big issue with Open Banking – you can’t tell where the issue lies and it’s difficult to apportion responsibility as OB uses multiple endpoints two distinct platforms.
As an authentication and authorisation method, Open Banking has much to offer, accepting its dependence on computers or mobile technology, and it works well in granting and managing access to personal financial information. Whilst it does offer an alternative to card payments, it isn’t the better option!
3D-Secure data flow
(for comparison of complexity)
Open Banking: payment applications
There is a lot more to a payment than the payment service specification outlining the authorisation message set and the structure of the settlement records, and payment services do not include built-in scalability.
A small internet merchant does not have the same payment service requirements as a small High Street store, which in turn does not feel the same needs as the likes of TK Maxx or Tesco. Relationships between parties also differ, because the needs of retail customers are not the same as those of taxpayers interacting with HMRC.
Small Internet Store
A small internet store with relatively low transaction volumes will be able to reconcile individual transactions without too much effort. Adding a QR code to the checkout will create an additional payment flow, and the shopping cart software should be able to manage the reconciliation. Introducing Open Banking is going to increase the complexity and therefore the processing effort, but as the initial effort is low this may not be significant and the cost of the extra effort may be offset by the savings associated with Open Banking payments.
Small High Street Store
A small High Street store could also opt for the QR code option, but this isn’t particularly favoured in the UK, so we are more likely to see stand-alone hardware devices serving a similar function to POS devices, triggered by a tap of a mobile phone. However, whilst some regions are accepting of multiple POS devices on the counter, this has never been the case in the UK, and so we might need to wait for Open Banking to be incorporated into the existing POS terminal hardware.
The interface between the checkout and the POS device is simplified as a direct result of the PCI-DSS, so the basic connection should be reasonably straightforward, but will need enhancing if it is to support Open Banking. The backend processing will also need enhancing to distinguish card transactions from OB.
An authorised card transaction is guaranteed, and so the merchant doesn’t need to wait for settlement. In contrast, confirmation of an OB transaction is not the same as seeing the cash land in the bank account, and I have first hand experience of that! Without a guarantee of funds, the merchant is probably going to need confirmation of the payment landing, which is going to cause delay if the the payment takes longer than a few seconds.
The Faster Payment service, whilst confirming payment initiation, does not provide confirmation of the cash landing in the target account, so the Open Banking platform is not able to confirm delivery of funds. The merchant’s need for a confirmation of payment is doubly confounded by the lack of support (although I believe this is growing) for incoming payment (account credits) notifications.
Also, if I need more, the data that defines the Open Banking payment and the subsequent confirmation of that payment is not carried forward to the Faster Payment. This means that even if the Faster Payment landed immediately, and even if there were notification mechanisms for account credits, the account credit is not capable of carrying the original transaction identifiers – there isn’t enough space!
Since there is no Faster Payment confirmation of funds received, the responsibility would fall to the merchant’s bank to provide confirmation of every credit made to the account, in a form that could be used by the retail POS systems to complete the last leg of the transaction.
Merchants may, of course, choose to go with the limitations of the Open Banking and Faster Payment services and accept the transaction risk associated with non-confirmation. This would be a decision for Risk Management.
Large High Street Store
The challenges associated with the small High Street store as described above apply equally to the large High Street store, and to Chains. In addition, for larger stores, the delays in confirmation of transaction completion may result in unacceptable delays in customer throughput.
As footfall increases, so to does the volume of transactions, and whilst this is a good thing for the bottom line, the challenges accounting increase considerably. Reconciliation processes for large stores and chains are far removed from those applied to small shops.
For any store (actually for any MID), authorised transactions are grouped by Business Day (usually) and are submitted in bulk, in the clearing file delivered to the acquirer. Individual transactions are aggregated into a single settlement credit, which should reconcile to the total business for that day.
Individual transactions and the settlement files to which they belong can be reconciled at the store (or MID) level. Settlement files and bank account credits can then be reconciled at Regional Office or Head Office level, whichever makes more business sense. Organisations like Tesco with 3400 stores are then able to focus on reconciling the settlement files with the incoming bank credits, which is a challenge in itself, rather than reconciling each individual transaction.
Open Banking payment transactions are not aggregated, and so every purchase must be checked against every incoming credit, and as previously noted, the incoming credit doesn’t contain the information needed to identify the original payment request.
The issue of transaction volumes could be addressed using an Open Banking intermediary, which could recognise business day cutovers and aggregate settlements, reducing the reconciliation task considerably. However, this would mean the intermediary would be receiving the cash, and that would mean that the intermediary would effectively become the Merchant.
The relationship between the real Merchant and the intermediary, the so-called “Merchant of Record” feels unconventional and problematic since the intermediary is in receipt of customer payments, the customer doesn’t know who they are paying and the intermediary has no relationship with the customer.
It seems to me that the potential advantages that might fall to small merchants, although they are not guaranteed, evaporate rather rapidly when you attempt to scale them up.
HMRC
This use case works and it works very well. It works very well because it falls exactly onto the Open Banking sweetspot!
The relationship between taxpayers and the HMRC is on an account to account basis, and is focused solely on the secure transfer of funds between one party and the other. Each customer of the HMRC has a personal bank account and a tax account at the HMRC, which is not shared by anyone else.
The Open Banking process means that all parties are authenticated, the payment to the HMRC is authorised and then initiated. A Faster Payment is probably easier if the customer knows what they are doing, but a Faster Payment initiated over Open Banking means that they don’t need to.
Each tax payment made using Open Banking will show as an incoming credit on the bank statement containing the Tax Reference in the Reference field, which is all that is necessary to apply the funds to the correct tax account. As an auditable and reconcilable process, tax payments over Open Banking rails beats card payments hands down.
Tax payments to HMRC using Open Banking is exactly what Open Banking is for, however, the fact that it has been successful for this application does not mean that it is appropriate for all the others.
Open Banking: usability
There is no doubt that the Open Banking transaction mechanism is clever, in the same way that 3d-secure, in its day, was clever. They both serve to authenticate parties to an exchange of information so that the exchange of information might be secure. The question is: if they are used to front-end a payment, do they work for the consumer?
The history of payments is essentially the history of payment innovation, and that innovation has mostly been presented to consumers payment innovators rather than consumers as consumers generally go shopping for shirts rather than the experience of paying for shirts.
If consumers are looking for anything, they are looking for payments that are easy to bolt on at the end of shopping for a shirt, and are unlikely to cause any problems: payments should be unobtrusive, robust and secure. They should also work wherever and whenever you might want to buy something.
Consumers are not payment innovators, they are not generally early adopters and the reality is that they don’t really know what they want from a payment service, other than the ability to make a payment. They can tell very quickly, however, what they don’t want!
Cards work everywhere (mostly) and banks issue cards, and as long as I have a bank account, the bank will keep on sending me cards – I don’t need to do anything! Cards are inexpensive, they work everywhere (mostly), and if I lose my card, the bank will send me another one. Cards work online, offline in F2F environments, for recurring payments and and if I want to send some money to a friend, I can now do that too. Why would I want to adopt Open Banking payments?
I need a mobile phone before I can start. Do I need to download the Open Banking app thing? There is no Open Banking app thing! In fact, I searched my banking apps for Open Banking and was underwhelmed by what I saw. I guess the banks don’t want to be encouraging the sharing of “their” customer data, so I wonder how that will play out with payments.
Open Banking payments are unlikely to be available everywhere (see previous section), and so at best, are going to be the payment option of second resort.
Multiple options at checkout will introduce additional delays whilst the preferred option is selected. Tesco don’t ask how you want to pay, the logic applied to the till sequencing doesn’t require it; Aldi ask if you want to pay using cash or card, and then press a button. It is inevitable that if Open Banking is applied to the F2F checkout, there is going to be an Open Banking impact!
I don’t know how this might work, and I might be off track, but if the Open Banking payment is linked to NFC, so that it might be incorporated in the POS (albeit contactless only), then either the consumer or the checkout operator, or both are going to be needing to push the transaction in one direction or the other. In all cases, it is inevitable that this is going to introduce delay, and then there is the SACAT.
Aldi SACATs already ask the shopper to make unnecessary selections – like the choice of either contact or contactless card. Adding another payment option to the logic demands the addition of another screen option, notwithstanding the challenges faced by the technologists trying to insert the Open Banking payment model into the existing NFC contactless payment flow, or maybe there is an alternative QR code solution, with its own option!
One of the principle uses of contactless cards is in transport ticketing, such as the London Underground (TfL) with its 30000+ gates. The logic of the TfL is based on collecting taps at the gates, converting them into journeys and then pricing the journey based on time of day, daily and weekly fare caps and zones – all the processing takes place post-event using ticketing taps, but Open Banking payments are real-time payments.
There are so many more specific use cases where cards work but Open Banking falters.
Why would you want to “Pay by Bank” sometimes, when you can pay by bank most times using the debit card your bank sent you?
Open Banking: the cost of transactions
I remember when suppliers were bidding for services to replace mobile top-up vouchers with cards. Every bid was based on the assumption that the commision rate for card top-ups would be the same as that for vouchers, and some vouchers were running at 40%. It never occured to the bid managers that one of the reasons for investing in card technologies was to force the unfeasibly high commision rates down to a couple of percent.
The headline pricing for Open Banking is focussed on the cost of a Faster Payment, which is considerably less expensive than a card transaction. However, as service providers see the opportunity to add value to their propositions, so the cost of those propositions will increase. The cost of those propositions will also increase to take up some of the headroom built into the processes by card transaction pricing, even though Open Banking is meant to deliver competition!
Merchants are going to be looking to Open Banking as a route to less expensive transaction processing, although potential savings over the equivalent card payments may struggle to meet the additional, ongoing costs of supporting payments driven by Open Banking.
Current card transactions are unnecessarily expensive, and given that the technologies needed to support Open Banking would also support an alternative approach to card payments, especially CNP transactions, the cost associated with card transactions could be reduced dramatically.
If Open Banking gets to the point where it becomes a serious threat to traditional card payments, based on pricing, there is enough headroom in the pricing of card transactions to reset the game and redraw playing field.
Open Banking: Conclusions
The Open Banking proposition is a solution of two parts: the authentication and authorisation, which is then followed by a Data Share or a Faster Payment (in the UK).
Data or Payments
Open Banking is good for authentication and authorisation, which is what it was designed for. Using it as a means of allowing access to personal financial data serves the interests of the consumers of financial services, and should lead to better services and more options. Using it as a means of payment, however, appears to be overly complex and therefore has a limited usability.
Payment Applications
Open Banking payments appear better suited to Account to Account applications rather than retail applications, where there are numerous practical considerations to be addressed.
The Open Banking payment works well for HMRC, but that does not imply it is a viable solution for a large supermarket.
Usability
Open Banking payments require effort on the part of the consumer and an intellectual buy-in, they require a mobile phone and they are unlikely to be as widely accepted as the established card alternative (this is unlikely to change over time). They offer little incentive to the shopper, although they do represent an opportunity for enhanced loyalty, but this is unlikely to be realised without some out of the box thinking about loyalty.
It does not matter how simple the Open Banking experience may be presented to the consumer, it’s going to be more complex than taking a card from your pocket and tapping it on a POS.
And it isn’t going to work for transit ticketing.
The Cost of Transactions
The cost of an Open Banking transaction can only move in one direction. The feature is fresh to market and price incentivisation will be key to establishing an early lead, but this is likely to correct itself as Open Banking becomes a mainstream payment option. In contrast, the traditional card payment has the pricing headroom to allow transaction costs to be reduced significantly.
Careful consideration should be applied before building a business case based on Open Banking pricing.
Overall
The Data Share proposition supports competition and consumer choice by opening up the financial market.
The Open Banking payment supports Account to Account transfers, and from the evidence of the HMRC, it does it very well.
The application of Open Banking to retail payments is flawed.
Explore the Future of Payments
The global payment ecosystems continues to evolve with technologies like AI, tokenisation, and real-time payments.
Stay ahead of the game by diving deeper into the world of payment processing.
Have questions or need expert insights? Contact us.
