Request to Pay VS Open Banking
The question is a great one as ultimately both Request to Pay and Open Banking are payment initiation services with the core payment processing being performed by another party. Couple this with the ongoing “Will they? Won’t they?” melodrama between Pay.UK and OBIE that resembles an episode of Love Island. And we have an interesting pot to stir.
My starting point is to first make a sweeping statement on Europe. Open banking has proved significantly more difficult to deliver than in the UK. There is no standard API and the EBA still needs to provide guidance on what good looks like is symptomatic of the abandonment of the spirit of the legislation. With no intervention by a comparable body like the UK’s Competition Market Authority (CMA) in place, there is little drive to positive market outcomes.
With this backdrop the June launch of SEPA Request to Pay by the European Payments Council looks very interesting. Citing the 4,000+ different European open banking APIs required to achieve market coverage Erwin Kulk from EBA Clearing and Francis De Roeck from BNP Paribas highlight how Request to Pay has the potential to out compete open banking particularly around the standardisation of the APIs1.
This isn’t the case in the UK. The CMA has provided clear direction to the Open Banking Implementation Entity (OBIE) and continues to do so ruling recently, to much protestation, that Variable Recurring Payments (currently limited to the sweeping use case) should be a mandated deliverable by banks to a standard defined by OBIE.
VRP allows for the creation of a payment mandate covering a series of future payments between payment accounts. In this sense VRPs are analogous to Direct Debits (delivered by Pay.UK). Direct Debits themselves are subject to the New Payments Architecture that promises to evolve our systemically important payment systems.
We see RtP as being complementary to Direct Debits (and hence also to VRP). There are a lot of people who are very happy with their Direct Debits, they happen seamlessly in the background with very little friction (once set up!). However, there is a growing section of society that either can’t or won’t set up a Direct Debit as they perhaps require more control of when exactly funds are leaving their payment accounts. It is for this reason that Request to Pay was established.
There are 4 steps to Request to Pay
1. A biller digitally sends out a request using a PSP
2. A payer receives that request via a PSP (doesn’t have to be the same as the biller)
3. A payer can pay in full, part pay, ask for more info, ask for a deadline extension or reject the request
4. Finally, the payer can pay, using any of the payment methods that their application offers
The most similar OBIE service is a single immediate payment (SIP). A single immediate payment though has far broader application due to its simplicity – it can be used in-store, for eCommerce as well as for bill payments. Due to the mandatory 5 options that have to be displayed to a payer when receiving a request this really does limit Request to Pay to bill payments, charity donations and some more far out scenarios such as pro-rata salary payments.
Focusing on the bill payment aspect, there are a number of companies who are attempting to use single immediate payments to deliver these services. These are typically Pay by Link organisations that generate a payment link that is sent via SMS or e-mail that when clicked on will generate an open banking journey.
Request to Pay better serves the bill payment use case as, referring back to the 4 steps, it handles both the generation and delivery of the request between secure applications, not just the payment initiation.
Another important distinction is the payment method that is initiated as a result of a SIP or RtP. Open banking is limited to those providers mandated to provide APIs under PSD2 – so typically banks or eWallet providers. Request to Pay is payment method agnostic. So, a very real possibility is you could use Request to Pay to initiate a request, receive the request and initiate a payment using SIP (step 4). Equally that payment could be a card based payment, bank transfer or even cash. The payers app would manage the payment processing then initiate a bank transfer to the biller so the biller is only ever managing a single cash collection by bank transfer process.
The biggest differences though between both RtP and SIP has to be availability and business model. Remember SIP is a result of the PSD2 mandate so banks were forced to make available APIs for third parties to initiate payments. RtP is different as there is no mandate and banks can absolutely charge for their services. With both card schemes adopting RtP and major UK banks signalling their intent, availability can rival open banking but with banks having much more incentive to make it work.
So, there is definitely overlap between the two services with Request to Pay more purpose built for a particular use case. SIP has broader application and can actually work in partnership with RtP.
Peter is the Commercial Director at answer pay and a payments product specialist with over 10 years experience in the payment arena with Santander, Vodafone, Amazon and Paysafe.