OFA Response to JROC SWG: Payments Strategy Sprint
27 September 2022
Summary of input to Payments Strategy Sprint
We provide a set of 7 issues in order of priority for our members. Addressing these issues will be key to ensuring the continued success of open banking and its further development.
1. Payment Limits / Transaction Blocks
Open banking has the potential to provide large savings for merchants, especially for high value payments, where cards are very expensive.
However, bank transaction limits are impacting the success of open banking payments. This is because transaction limits designed to safeguard manual bank transfers against APP fraud, are being applied to open banking payments despite the risk profile of open banking payments being different, i.e. lower (as explained here).
Recommended approach:
- FCA should take supervisory action against banks not complying with FCA guidance/ PSD2 rules in accordance with its April note.
- We suggest the transaction limits be standardised across banks – and suggest banks align at a single transaction limit of minimum £25,000 for open banking payments.
- OBIE has issued new standards that enable banks to better understand the risk of open banking payments, including for new transaction risk indicators (TRIs), but the implementation of these is voluntary (for both banks and TPPs). This data transfer capability will be needed as part of the long term solution to transaction limits.
- OBIE should coordinate and require implementation of TRIs to enable longer term solutions to transaction limits and transaction risk sharing.
- Finally, there are some beneficiaries to which payments will always be very low risk. e.g. government departments like HMRC. The future entity should manage a register of the names and account details of these beneficiaries, and open banking payments to these organisations should not be subject to transaction limits. This will enable e.g. high value business tax payments to be made using open banking.
2. Enabling non-sweeping VRP
The current definition of Sweeping prevents VRP APIs from being used by TPPs to enable payments to businesses, and competitive alternatives to direct debits and card on file. There is an expectation that TPPs and banks agree on commercial terms for use of VRP APIs for these types of payments. However, obstacles exist:
- Coverage – Banks are not incentivised to enable a new payment type that could potentially cannibalise existing card issuing revenue – so the majority of banks have made no move towards developing non-sweeping VRP APIs.
- Cost – If banks were to develop the APIs (outside of restrictions on charging), there is a risk they would charge excessively high fees to protect or recoup lost card issuing revenue, and therefore make non-sweeping VRP too costly for TPPs to provide.
Recommended approach:
- We propose that regulators should mandate coverage of non-sweeping VRP, and explore approaches to ensure bank provision of non-sweeping APIs in such a way that enables non-sweeping VRP to compete with other payment types. Some options to consider include:
-
- non-sweeping VRP maintains single OB payments model of no charge to PISPs (bank revenue from businesses
- Fee cap at (10-20bps) – We suggest a fee cap of 0.10% to 0.20%. Members estimated that UK businesses stand to save nearly £1.5 billion annually in payment processing fees for consumer payments by extending CVRPs to use cases beyond sweeping. This is based on a fee cap of 10 bps compared to fees for direct debit and cards.
- Market driven with guiding regulatory principles/requirements/oversight (FRAND pricing, prices must be objectively justifiable etc)
- Market driven with regulatory monitoring (regulator watches with threat of intervention if prices too high)
-
- Banks should not be allowed to restrict non-sweeping VRP use cases.
3. VRP user experience (sweeping and non-sweeping)
One driver behind VRP is that it gives more control to users (than e.g. card on file, which many consumers struggle to cancel and get into subscription traps). However, there are several shortcomings in the VRP standards which will impact VRP user experience:
- Location of VRP controls in banking app – One driver behind VRP is that it gives more control to users (than e.g. card on file, which many consumers struggle to cancel and get into subscription traps). However, OBIE has previously required banks to implement VRP mandate control tools alongside so-called ‘consent dashboards’. These have often been hidden in hard to reach parts of banking apps. E.g. for Halifax bank to find this area the journey on the app is: Profile & settings > settings > open banking & connected accounts.
Illustration of where VRP controls should be located
- How VRP payments appear on bank statements – As it currently stands, all VRP payments must have the same mandate reference *and* payment reference. This means that, when an end user views their bank statement, and they have made a number of VRP payments under a single mandate in that month, they will see a number of transactions with the same description. For example, if they have set up a mandate to enable payments within certain parameters to Amazon, they might see on their statement ‘Amazon’ several times, but not ‘Amazon – Toothbrush’, ‘Amazon – Toothpaste’.
- Software statements – TPPs need to go through a very cumbersome process of creating separate software statements for every business who uses open banking payments/ data, in order for these businesses (usually the customer facing entity) to be visible on the bank access dashboard. This takes on extra importance now VRP is being rolled-out, so that consumers can see who their payment mandates are set-up for on their banking app.
Recommended approach:
- Controlling VRP payments in bank app – regulators should require banks to place VRP mandate controls in banking apps and websites in the same area as tools to control direct debits and standing orders.
- How VRP payments appear in bank statements – PISPs should be able to customise the payment reference in order to display more information to the PSU
- We also recommend adding more data to the payment reference, so that more than 35 characters of data can be communicated – for example, the geographic location of the transaction, or detailed order information to communicate what exactly an end-user purchased.
- How VRP information is transmitted (software statements) – We recommend that standards are changed in order to have the relevant information provided in the consent message, rather than in software statements – as per previous change requests submitted to OBIE
4. Payment certainty / introduction of payment guarantee – the risk of payment delay is a barrier to OB adoption at point of sale or user-in-session sales.
When a customer pays for goods or services, the merchant often requires certainty that they will receive payment, before they can ‘ship’ and while the user is ‘in session’ with the merchant.
With cards this is provided via an ‘authorisation code’ which acts as a payment guarantee. The merchant can ship the goods, despite the fact that they will often receive the corresponding funds days later. The card scheme ensures that once they receive the authorisation code, they are almost certainly guaranteed to receive payment.
In open banking payments, PISPs currently rely on the fact that OB payments are instant, and the merchant can ship once they have received funds in (almost) real time.
As things currently stand – this is still too slow to serve many e-commerce use cases. A card will have an authorisation code within around 3 seconds, Open Banking payments take ten to twelve seconds for the funds to arrive – but can also take several hours or days to be approved by sending banks.
Recommended approach:
- Introduction of a payment guarantee message in open banking – the sending bank must send a guarantee to the PISP that a payment will be sent to the receiving bank within 3.5 seconds, or the payment must be rejected. This does not mean that the payment must be received instantly, just that the payment will be sent.
- We would expect that the sending bank should also retry this payment in the case of a failure from the Faster Payments scheme.
5. Prohibitive faster payment cost for low value payments
It costs a sending bank and a receiving bank around ~1p to submit and receive payments through Faster Payments (see Section 13 of Faster Payments Service Principles). This compares to the €0.002 (i.e. less than half a penny) central infrastructure cost paid by European banks sending/receiving instant payments via TIPS.
Merchants are then typically charged by their banks much higher fees (by way of example fees between 10p and £1 have been identified) to receive a single Faster Payment into their bank account. By comparison, when using Card payments, low value transactions are typically charged at a single, variable basis points based fee. The BRC recently reported that merchants on average pay 26bps of turnover to accept debit cards (small merchants can pay significantly more than this). On an absolute basis this amounts to 3p for a £10 sale. If they were to transition to Open Banking, this would cost the merchant at least double, making Open Banking Payments uncompetitive in the low-value retail forum.
This situation is likely to get worse with the introduction of the NPA. We understand that over the next few years, banks are expecting the cost of faster payments to increase, because of the costs of implementing the New Payments Architecture. NPA is expected to cost £400m, spread over all the direct FPS participants based on usage. Depending on how many years the cost is amortised over, this could add between 1 and 6 pence per payment to the cost of settling an inbound FPS.
Recommended approach:
- Explore how Faster Payments fees charged by banks to merchants accepting Open Banking payments can be reduced. This could include:
-
- Encouraging development of more cost reflective pricing from banks for incoming Faster Payments and/or pricing models that reflect the higher volume of incoming Faster Payments that will be associated with wider usage of Open Banking payments.
- Reducing core infrastructure costs: Prioritise reduction in per transaction pricing at the infrastructure level for the NPA. Economies of scale from greater instant payment volumes (associated with wider usage of open banking payments) should be able to support lower unit costs at the infrastructure level.
- Explore development of innovative settlement solutions for incoming Faster Payments linked to Open Banking payments. For example:
-
- Banks could provide Merchant Accounts for PISPs which do not bear a charge for receiving internal payments. Internal transactions should not bear a cost, as they are not submitted to Faster Payments. PISPs would instruct any payments which do not require instant settlement to the internal bank account, from which the PISP can batch and reconcile payments to its merchants as it wishes. This is the simplest solution for a sending bank to implement, however does require PISPs to be given and manage accounts with each bank.
- Alternatively – Banks could batch payments made over the course of a day, sending one payment which will account for a number of underlying retail payments. I.e. if 1000 payments of £10 are made to a retailer over the course of a day, the bank should batch these payments up, and send one payment of £10,000 at the close of the day’s business.
-
-
6. Bulk payments
Banks impose limits on number of payments in a batch and on their value:
- Trusted beneficiaries – several banks require that every payee in a batch is a “trusted” payee. However, there is no mechanism envisioned in the API allowing programmatic creation of these trusted payees. This means that users are forced to manually set up payees within the bank’s app before they can make OB bulk payments. This negates any advantages offered by OB over non-OB solutions.
- Limits on a number of payments in a batch – one bank imposes a minimum of 5 payments in a batch, which creates a no-man’s land of 2-4 payments that aren’t served by either single or bulk scenarios;
- Across different banks the max number in a batch ranges from 15 to 1,750. These limits are arbitrary and result in various contortions and deterioration of user experience.
- Value limits – one bank additionally imposes a limit of £50K on the aggregate value of payments in a batch, which excludes many scenarios (like payroll)
- Another bank only executes bulk payments via BACS, which means that any batch must be forward-dated by at least 3 business days.
- No banks offer selecting specific time of payment for forward-dated payments. This offers far inferior functionality compared with specialist payroll companies that allow scheduling payments for 10AM next Friday, say.
- Another bank does not support forward-dated batches
Recommended approach:
- We recommend the future entity be tasked with developing improved standards for batch payments and ensures consistent implementation across banks.
7. Standing orders
The existing OB API standard already has well-designed endpoints for initiation of SOs. However, only one bank has implemented it in its entirety. Most UK banks implemented heavily reduced versions. Worst shortcomings include:
- No ability to specify final date or number of payments;
- No ability to specify odd first/last payment
- Additionally, the current standard provides only for initiation of the SO, but has no endpoints to either cancel it, or to query status of individual payments.
In combination, these render SO functionality unusable, even though there is an enormous market for this type of transactions.
Recommended approach:
- We recommend the future entity be tasked with developing improved standards for standing order payments and ensures consistent implementation across banks
CONTACT
Join us and be the voice of Open Finance in the EU and UK.
Copyright OFA 2022