Photo credit: Rodion Kutsaev on Unsplash

The average consumer could be forgiven for having no idea what an ‘Open Banking Variable Recurring Payment’ is. In fact, even the average payments professional could be granted similar forgiveness. To the wider industry, recurring payments currently come in a few different forms familiar to the average ‘payer’; Direct Debits, Standing Orders and Continuous Payment Authorities (CPAs). All of these forms of recurring payment have their own set of pros and cons for the customer, and businesses will choose to offer them as payment methods as appropriate to their needs.

So, what’s all the fuss about a new way to pay regularly?

First of all, to understand Variable Recurring Payments (VRP), you need to understand the basics of Open Banking – a customer allows a third-party business to access their bank account in order to access data or to perform actions with their explicit consent - no different to when we let an app access our Facebook data to provide us with a ‘What famous celebrity would you be?’' quiz. Open Banking relies on ‘Open API’ specifications which are interoperable technical standards that define what the third party must provide in their request, what the data holder must provide in their response and what the customer must do to prove their identity (authenticate) and provide their consent (authorise).

Once you have this kind of consent-based model you can allow third party companies to provide all kinds of value-add services to customers.

To take a basic example, if I want a loan, then instead of going through a lengthy form, I can consent to the loan provider directly accessing my banking data to retrieve my transactions and give me an instant credit decision and for good measure perhaps an instant loan. Weeks become potentially seconds. Which leads us on to the matter at hand – Open Banking Variable Recurring Payments.

‘VRP’ is an extension of the Open Banking API specifications to allow a third party to request consent from a customer to execute payments on their behalf, on a recurring basis within variable limits. At a high level the Open Banking API specifications in their current form allow for two ‘concepts’:

1. Third parties accessing data

2. Third parties executing payments

Although under UK payment services laws all payment account providers in the UK must allow customers to provide consent for both access to ‘account information’ and ‘payment initiation’ the use of account information services towers over payments. In the UK there were close to 800 million third-party requests for customer account information just in the month of July. In comparison, payments-related requests tipped the scales at just over eight million. The answer to the reasons behind this deserves its own separate post, but it would be fair to say that from a customer perspective, giving an app access to your bank data is wildly more familiar than giving an app access to make a payment from your bank account. And from the perspective of the regulators that defined and mandated the adoption of these standards, account information services are fast becoming a roaring success and payment initiations are, so far, a damp squib.

But is all this about to change?

First, let’s examine what the Open API specifications for payment initiation currently allow a customer to do. If I can do all these things from my bank account directly, I can also consent to a third party doing them on my behalf – making a payment, making a scheduled payment, or setting up a standing order. There are some good use cases for the above - for example if I’m a sports betting app and I want my customer to top up funds, I could get the customer’s consent to take a one-off payment directly from their bank account without ever having to ask for, or indeed store the customer’s card details which comes with PCI DSS standards attached which are expensive to comply with. But very few merchants, certainly none I personally have used, offer consent-based Open Banking payments at check-out. Why not? Whilst different regulatory barriers and market forces currently hinder widespread adoption of Open Banking payments, it fundamentally lies in the familiarity, ease and security with which customers can currently make card-based payments online. And this is only exacerbated by the technological backing of big tech. Apple, Google and Samsung pay all allow a card payment to be made with two-factor authentication as standard, in one click.

In 2007, Barclaycard introduced the first ‘wave and pay’ credit card which can lay strong claim to being the first contactless payment card. Despite the ubiquity of contactless as a form of payment in 2021, initial uptake was slow. Chip and PIN had only been introduced in 2003 and customers had become accustomed to the greater security of providing a passcode to make payments even though magnetic stripe was still very much on the scene. It wasn’t until Transport For London (TFL) introduced contactless payment on the tube that contactless started to feel like something it was more unusual not to do, than to do.

After all who wants to carry an oyster card around when you can just ‘tap and go’ with what you’re already going to get out of your pocket at the pub anyway? By December 2015, TFL recorded its busiest single day – 1.24 million journeys were taken by 500,000 unique contactless cards. Change comes gradually, and then suddenly.

Why is this example relevant to Open Banking Variable Recurring Payments?

Sociologist Evert Rogers described the five groups that consumers can be generally divided into – Innovators, Early Adopters, Early Majority, Late Majority and Laggards. Geoffrey Moore went onto expand on this in his book ‘Crossing the Chasm’ which introduced a concept of a gap between the innovators and the early adopters that any product or technology must bridge to reach a critical mass and become normalised. Open Banking payments have not yet been able to cross the chasm between innovation and early adoption because there is not yet a truly ‘killer’ use case to make consumers sit up and take notice.

Three weeks ago, I lost my debit card. No big deal these days, didn’t even have to cancel it initially. Click a button in my banking app and it’s redundant. When it becomes apparent that it’s irretrievably lost rather than misplaced, click another button and a new one arrives in two days, almost as hassle free as you can imagine.

But alas there’s a catch.

Week 1, Netflix subscription fails. Week 2, Spotify. Week 3, Zwift. I know why this is, and so does my bank who kindly lets me know via the app – failed payments are after all not good for anyone. A cancelled card means any Continuous Payment Authorities (CPAs) linked to that card will fail and I will have to go into the individual account subscriptions to re-register payment with a new card.

Can I remember my login details? Nope. Do I know my new card number? Also no. Despite now having all the above information have I done anything about it yet? Yes and no - I hadn’t even been using Zwift so why bother – because of the friction in the journey, the business has now lost a customer.

How would this collective journey, across multiple merchants differ in an ‘Open Banking Variable Recurring Payment’ scenario? Well, aside from the lost card bit, it wouldn’t happen at all, and therein lies the potential. Thousands of CPAs are set up every day and thousands of cards are likewise lost every day. I would simply give consent to a merchant or merchant payment solution to take a set of payments, directly from my bank account, where I have complete control over the start and end date, the maximum individual payment, the payment frequency, and the total payment amount within a given period – all via a neatly presented consent request in my banking app. Better still, due to the permission I’m able to grant as part of the journey, if for whatever reason I don’t have the cash when the time comes to take a payment the third party will know not to even bother to attempt it.

Couldn’t the merchants just use direct Debits? Direct Debits whilst widely adopted face a few issues. Firstly, Direct Debits take can take a full five days to travel from your account to your payee’s account, Open Banking payments come via the UK’s ‘faster payments’ rails and are instant. Not great for businesses who want to get paid quickly. They’re also not as flexible as Open Banking VRPs owing to the rigidity of the Direct Debit mandate versus the potentially endless number of variables that could be captured in an Open Banking consent. So, depending on your perspective, Open Banking VRPs are either an ideal solution to replace Continuous Payment Authorities, or they are a somewhat enhanced version of the ‘bank to bank’ Direct Debit. Or you could re-add your card details for every subscription you have every time your card expires - you lose it - it’s stolen, or your dog eats it.

Here’s hoping that there’s an imminent killer use case that can raise the visibility of the wider potential of Open API-based technology in the payments sphere and that the TFL moment for Open Banking payments is just around the corner.