OFA Response to JROC SWG: Payments Strategy Sprint
27 September 2022
Summary of input to Payments Strategy Sprint
1. Payment Limits / Transaction Blocks
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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
- We recommend the future entity be tasked with developing improved standards for batch payments and ensures consistent implementation across banks.
7. Standing orders
- 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.
- We recommend the future entity be tasked with developing improved standards for standing order payments and ensures consistent implementation across banks
Copyright OFA 2022