Explore the capabilities of Dynamic Recurring Payments (DRP) with Token.io. This article will provide an insightful overview of why DRPs have transformative potential within Europe’s payment ecosystem.
What are Dynamic Recurring Payments?
With Dynamic Recurring Payments (DRPs), consumers in continental Europe will be able to authorise a service provider to initiate payments from their bank, subject to predefined, user-consented parameters such as amount, frequency, and lifespan.
In straightforward terms, this can unlock the ability to make 1-click payments and direct-debit-like recurring transactions, but with all the advantages of open banking-enabled payments.
This innovation has the potential to become a cornerstone of Europe’s broader payments system, with the promise of substantial benefits for both consumers and businesses.
Before we consider use cases, though, it’s important to understand how DRPs differ from the UK’s Variable Recurring Payments and how we got to where we are today.
How did we get here?
The revised Payment Services Directive (PSD2) mandated that banks (Account Servicing Payment Service Providers, or ASPSPs) exposed interfaces (typically Application Programming Interfaces [APIs]) that would allow third parties (often fintechs) to prepopulate bank transfer details in bank apps and websites at the user’s instruction.
In practice, this means consumers can do things like make bank transfers to merchants in the flow of an ecommerce transaction (often called Pay by Bank) without having to manually enter the merchant’s bank account details. Rather, all they have to do is log in to their bank app and approve the payment, providing a much easier and more secure way to pay than typing in card details.
PSD2 entered into force in January 2016 and Member States then had until January 2018 to transpose the Directive into national law. However, the nature of a Directive is that each Member State has leeway in interpreting how they implement it, which results in differing outcomes country-by-country. Combined with the lack of an implementation and oversight body to ensure the APIs exposed by ASPSPs met a consistent and adequate standard, this has meant that the rollout of Pay by Bank has been somewhat fragmented across the EU.
By way of example, some banks do not allow you to approve payments within your bank app and make you log in to their website instead (thus requiring username/password, which is more cumbersome than biometric app login), while others may require you to enter extra information within the journey (instead of simply approving the payment), which adds unnecessary friction.
Under PSD2, there was no mandate for the banks to facilitate any functionality beyond that which existed in the bank’s own interfaces. Single Immediate Payments —one-off transactions that you approve in real-time — were the primary payment instrument available under regulations.
Further, banks were not permitted to charge fintechs for this service (this point may seem irrelevant now, but its significance will become clear later on).
As a result of the patchwork of different APIs exposed by banks, the limited functionality, and the lack of commercial incentives, open banking-enabled payments in the EU work tremendously well for some, but not all, use cases. With the SEPA Payment Account Access Scheme (SPAA), though, that all has the potential to change.
SEPA Payment Account Access Scheme explained
While open banking functionality available under PSD2 may have limitations, the European Payments Council (EPC) has released the SPAA framework in an attempt to remedy the situation.
SPAA aims to provide a basis upon which ASPSPs can offer ‘premium’ services – i.e. on a commercial basis – to third parties. In other words, banks can leverage development work they have already completed to comply with PSD2 as a base, build additional functionality on top, and charge for the resulting premium services.
Before we jump into the specific functionality of these resulting services (one of which is DRP), it’s important to understand some of the terminology.
The SPAA scheme defines a set of premium data and transactional/payment assets (or functionality) that can be further enhanced by the use of additional premium features.
From our perspective, the most interesting functionality introduced under the SPAA scheme is Dynamic Recurring Payments (DRPs), a type of premium Transactional Asset.
DRPs enable Asset Owners to provide consent, with Strong Customer Authentication (SCA), to establish a set of payment rules that include time period type for the ruleset (e.g. day, month), start/end date, and a maximum aggregate value in said time period.
Once consent has been provided with SCA, transactions requested by the Asset User can be initiated by the Asset Broker on behalf of the Asset Owner. Requests are screened against the consented parameters by the Asset Holder and are either approved or declined, without the Asset Owner needing to be present.
DRP in action
For the purposes of providing a real-world example of how DRPs would work ‘under the hood’, let’s consider the scenario of a one-click ecommerce payment.
In SPAA terminology, in this example:
A consumer is the Asset Owner
A merchant is the Asset User
A PISP like Token.io is the Asset Broker
The user’s bank is the Asset Holder
The starting point is a consumer navigating to a merchant’s checkout page and selecting the option to “set up one-click checkout”.
In the merchant’s environment, the consumer would agree to set up a one-click payment mandate with rules including start/end date, maximum aggregate value in a given time period, and the time period itself (e.g. day/month). Let’s say the consumer opts for the mandate to start today, run indefinitely (no end date), and allow payments of up to €250 per day.
The PISP would then redirect the consumer to their bank’s environment for them to confirm this ruleset using Strong Customer Authentication, then deliver the consumer back to the merchant’s checkout.
In the background, the PISP communicates a success notification to the merchant for them to log a record of the consented mandate against that consumer’s account with the merchant, enabling them to initiate the first payment there and then.
When the consumer returns to the merchant’s website next time, the merchant will be able to display the option to “use one-click checkout”. If the consumer selects this, the merchant will initiate a payment via the PISP on behalf of the consumer, the consumer’s bank will verify the existence of the payment mandate and, if the transaction is below the consented aggregate value (€250 per day in this case), the payment will be approved and completed immediately.
The resulting experience for a returning consumer is a genuine one-click purchase, with all the security provided by open banking APIs.
In practice, we think SPAA functionality promises significant improvements on current Pay by Bank experiences within the EU. We’ll discuss more use cases for DRP later on.
DRP vs. VRP
As some savvy readers may have noticed, the broad functionality of VRP in the UK and DRP in the EU is largely similar, and the underlying payments use cases that they unlock are analogous.
However, there are a few important differences to note between the two.
As mentioned earlier, the EU implementation of PSD2 involved no bloc-wide oversight body, which created a patchwork of different API standards with limited consistency of implementation.
In contrast, the UK’s Competition & Markets Authority (CMA) created the Open Banking Implementation Entity (OBIE), which helped ensure that banks built and implemented APIs to a single consistent and performant standard. As part of its remit, the OBIE defined an API specification that it mandated for the UK’s largest ASPSPs, and a constituent part of this standard was VRP for sweeping use cases (‘me-to-me’ transactions). While ‘non-sweeping’ (me-to-merchant) VRP transactions aren’t yet fully supported by UK banks, the underlying functionality is nonetheless largely already in place and only relatively small changes are required to technically unlock non-sweeping (also referred to as ‘commercial’) VRP.
In the EU, no DRP functionality has been built as part of banks’ PSD2 delivery, and it was not required under regulation.
Although development of existing PSD2 functionality has laid a solid foundation to build upon, all proposed SPAA functionality will therefore require more incremental technical development. As a result DRPs will require a ‘larger’ build than that required by the UK banks to make commercial VRP a reality. Therefore, DRP will take longer to deliver.
Applications of Dynamic Recurring Payments
The use cases enabled by DRP in the EU are largely similar to those enabled by VRP in the UK. (More detail on these can be found in my previous blog post: Bringing the benefits of Variable Recurring Payments to life.
In short, consumer-initiated one-click transactions are a potential killer use case for DRP.
The first time a user chooses this payment method, they would set up DRP consent by authorising a specific third party to initiate transactions on their behalf, subject to timing and maximum value constraints. After this, every time the consumer returns to that merchant, they could leverage this preset rule to complete payments in one click, minimising friction and making life easier for consumers and merchants alike.
Enhanced ‘direct-debit-like’ transactions will also be possible, providing an upgrade on existing alternatives.
Direct debits can easily fail due to a user having insufficient funds in their bank account, and the lack of reattempt functionality can cause significant operational headaches for merchants chasing missed payments. There is also potential for consumer harm here, since missed payments can result in late payment fees.
DRPs could be combined with open-banking-enabled account information services to give merchants the ability to know whether the consumer has sufficient funds in their account. Merchants could then communicate with their customers about the potential for missed payments, proactively remediating potential issues ahead of time.
DRP will also reduce fraud, with SCA being completed by the user during setup, as opposed to direct debit which does not have SCA. This, combined with a lower friction setup process (as opposed to manual entry of IBAN with direct debit), means there is a pretty compelling proposition for DRP to replace direct debit. (Learn more in this previous blog post: A deep dive on the benefits of Variable Recurring Payments.
The future of Dynamic Recurring Payments
This all sounds great, I hear you say, but when will it become reality?
As mentioned above, SPAA is a market-driven initiative rather than a regulatory initiative with associated compliance deadlines. As a result, supply and demand will ultimately determine the speed and success of the scheme rollout.
From a process perspective, the first version of the SPAA Rulebook was published in November 2022. In June 2023, an updated version of the rulebook was published, which detailed a Minimum Viable Product (MVP): a set of mandatory functionality that Asset Holders (ASPSPs/banks) would need to support to participate in the Scheme.
Importantly, DRP was included as part of the MVP, meaning if an Asset Holder (bank) wants to participate in SPAA, they will have to make DRP available.
A further element of the scheme came in November 2023, when version 1.0 of the SPAA Scheme Default Fees were published. These fees represent the baseline pricing that Asset Holders (banks) can charge Asset Brokers (TPPs/PISPs/AISPs) for accessing SPAA services. Parties are also free to negotiate lower fees.
Ultimately, a bank’s assessment of (i) the technical build requirements for offering the MVP functionality, and (ii) the associated potential commercial benefits, will likely determine how quickly banks engage with the SPAA initiative.
To help drive us towards making SPAA a reality, we think it’s critical that willing banks and TPPs now start coming together to develop pilot initiatives that provide real-world testing of the model and functionality envisaged under the SPAA scheme.
One factor on the 2024 roadmap that may help support adoption is the mandated support for SEPA Instant payments, which is set to be introduced by the European Commission’s Instant Payments Regulation. As a result, all institutions offering standard SEPA transactions (which typically settle within 3 days), will also have to offer SEPA Instant (which typically settles within 10 seconds). Banks will not be able to charge a higher price for SCT Instant payments than they charge for standard SCT payments. This is welcome news, because widespread availability of instant payments will make Pay by Bank an even more attractive payment method to businesses and consumers.
Supercharging customer experiences
In summary, we think the SPAA Scheme has the potential to provide a firm foundation for future enhancements to Pay by Bank propositions in the EU.
The SPAA scheme is a market-driven initiative so supply and demand will ultimately determine the speed and success of the scheme rollout. While speed of adoption is currently unclear, we expect to see indications from the market over the next six months as to its appetite to adopt.
There is an enormous opportunity for SPAA-enabled open banking journeys to not only create a richer payments landscape, but also to create a significant positive impact in a broader context.
In particular, Dynamic Recurring Payments stand as a prime example of how collaboration in the industry could lead to groundbreaking innovations, showing us a glimpse of the future of open banking — and open finance. In this new world, DRPs will play a pivotal role in enabling secure, frictionless, and customer-centric payment experiences.
Stay tuned as we continue to explore and realise the potential of this innovative payment mechanism.
For more on Variable Recurring Payments and Dynamic Recurring Payments:
For more information on all things VRP and DRP, download a copy of our recent Industry Survey Report: The future of Dynamic and Variable Recurring Payments: Industry Survey Report