Skip to content
ofa_logo_no-font

OFA Response to JROC SWG: Ecosystem Strategy Sprint

13 October 2022

 

Summary of input to ecosystem strategy sprint 

The Open Finance Association believes the priorities for developing the open banking ecosystem should be: 
  • Strong future entity – There needs to be a strong, independent future entity with powers to coordinate and monitor implementation and performance of API standards
  • Further work on the open banking operating model – The future entity needs to consider the right operating model for open banking + and open finance, whether that be a continuation of open APIs (as under PSD2 and the CMA order); a multilateral approach/ rule book; or governance under a new scheme. In doing this it needs to collaborate extensively with industry as that is how the best outcomes for all ecosystem participants will be identified
  • Balance of requirements and incentives – A strong open banking/ open finance ecosystem will always need a degree of regulatory intervention due to different incentives of the supply and demand side of the market (it can’t be purely market led) but commercial incentives for the supply side should be considered as long as they don’t hamper competition 
  • Address current open banking gaps – Key existing gaps need to be addressed before effort is exerted on future functionality. These existing gaps are summarised below 
  • Interoperability – There needs to be better interaction between open banking and other initiatives e.g. the New Payments Architecture project, Authorised Push Payment (APP) fraud work and the Joint Money Laundering Steering Group. In particular, without coordination between APP work and open banking, APP fraud proposals could lead to problems for open banking payments, including further transaction limits and poor user journeys
The gaps in open banking that hold back further innovation and user benefit: 
  • Consistency: banks largely determine how open banking works. How much a customer can pay using open banking varies depending on which bank they use
  • Functionality: while TPPs can initiate single immediate payments, there are limitations on their ability to initiate recurring payments
  • User experience: while the user experience of open banking has been improving, there are limitations  — such as consumer experience of bank authentication, the speed at which banks process API calls and payments settle, lack and inconsistency of error messages/ status codes, — that ultimately impact user experience
  • Scope: only current accounts and credit cards are accessible via open banking. Savings, investments, pensions and mortgages are yet to be opened up
We have summarised our input on payments here and data here. The issues we have raised across all sprints are as follows: 
  1. Transaction limits on high value payments – lack of consistency across banks in terms of where they set their transaction value limits, impacts open banking payment providers’ ability to initiate high value payments, e.g. for tax or car purchase. This prevents savings for businesses and organisations during a cost of living crisis 
  2. 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.
  3. User experience – There are shortcomings in API standards and consumer experience guidelines which mean that the overall user experience of open banking can be sub-optimal (and make customer adoption less likely)
  4. Payment certainty – 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. Open banking payments, although near instant – can in some cases be too slow for retail and ecommerce use 
  5. Costs of accepting Faster Payments – Merchants are typically charged by their banks fees between 10p and £1 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. This makes it less likely that open banking will be adopted for low value transactions 
  6. Bulk payments – banks impose limits on the number of payments in a batch and on their value and this varies from bank to bank. This makes it difficult to build viable open banking services for bulk payments. 
  7. Standing orders – The existing Open Banking API standard already has well-designed endpoints for initiation of standing orders. However, only one bank has implemented it in its entirety. This makes it difficult to build viable open banking services for bulk payments. 
  8. Fraud prevention and identity verification  – Current open banking standards allow for provision by banks to the TPP of information identifying the bank account owners/beneficiaries. This information can help a TPP to make a  risk-based assessment before initiating a payment. However, many banks choose to opt out from providing these identity details. Better access to identity information will enable the following use cases to thrive: Identity verification and confirmation, AML and KYC checks, financial crime, account holder verification, affordability checks, proxy credit scoring for the underbanked and e.g. tenant screening. 
  9. Errors and failures (status codes) – When a data access request of payment initiation fails, TPPs are entitled (under PSD2) to error messages. However, these have been implemented differently across UK banks and the level of detail provided is often insufficient to ensure end-users can be properly informed what is happening. 
  10. Lack of transparent, comparable, accessible API performance reporting – The reliability and performance of APIs is a constant issue and impacts conversion rates (a metric measuring whether users complete OB journeys or not), and also perception and confidence in Open Banking. Frequent downtime and maintenance windows are seen from a variety of banks and these are poorly communicated. The result of this is that we are unable to articulate these issues to users to advise and advise whether they should try again, which typically leads to drop outs from payments and data flows.
  11. Scope of data – In the short term, JROC should look at whether it can require banks to make savings accounts accessible by TPPs (as part of Open Banking plus). In the medium term, all the data in banking apps should be available to TPPs via APIs (inc. savings, mortgages and loan accounts). Basic data should remain free on the basis it is the consumer’s data.  Access to current accounts is insufficient for TPPs to enable customers to fully plan their financial future or have full control over their financial decisions, which will drive further innovation and competition in this space.

CONTACT

Join us and be the voice of Open Finance in the EU and UK.