OFA Response to JROC SWG: Data Strategy Sprint
03 October 2022
Summary of input to Data Strategy Sprint
1. Ensure compliance with existing PSD2 and CMA order data requirements
- Banks must be held accountable and implement fully against existing OB standards. If banks are not held accountable for compliance with existing standards, it is unlikely that expanding use cases and standards will be successful. The uncertain future of OBIE poses risks to compliance with the CMA order.
- This should be achieved by the development of a strong, independent future entity, working in conjunction with the FCA’s payments supervision team (who are competent authority for ensuring compliance with PSD2).
2. The need for a strong, independent future entity to develop data sharing beyond open banking
The success of UK open banking was underpinned by the existence of an independent standards body, with powers to coordinate how API standards were implemented by banks. The difference in progress between open banking in the EU (where no similarly empowered standards bodies exist) and the UK, demonstrates the importance of this approach to open banking.
It is crucial that OBIE is developed into a future entity that is capable of developing new standards, and managing their implementation.
The future entity will require:
- powers to compel and enforce data holders to provide data via APIs, focused on:
- Data completeness
- Data cleanliness (no repetitions)
- Data enriched with meta data
- subject matter expertise in specific industries where open finance is extended to
- funding to ensure adequate resource and technical expertise to maintain effective oversight
- reporting and transparency
3. Extend data access incrementally beyond payment accounts
All the data in banking apps should be available to TPPs via APIs eventually. JROC should look to extend open banking access to include access to data commonly available via consumer/ business banking apps. For example savings, mortgages and loan accounts. If this data is available via a banking app, it should not be difficult to make it available via an API (afterall, many banking apps are connected to back-end bank systems via APIs).
Basic data should remain free on the basis it is the consumer’s data. Access to payment accounts alone 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.
Suggested approach:
- We appreciate this will be a major deliverable, so in the medium term, JROC should look at whether it can require banks to make retail savings accounts accessible by TPPs (as part of Open Banking plus).
4. The need for further consideration of operating models to progress data sharing beyond open banking
Many aspects of the UK open banking ecosystem are working well. Open Banking adoption is ahead of many EU countries and the work that OBIE has done over the last few years has delivered an effective open banking ecosystem. This is all without any contracts between PISPs and banks (given the regulations prohibit any such contracts).
In order to progress open banking beyond existing regulatory requirements, and the specific aims of the CMA order, there are a number of options open to Government and regulators:
- Continue to legislate/ regulate to further open up payments and data (regulatory-only approach)
- Leave further development of open banking to the market (market-led approach)
- Take a mixed approach of regulating to open up access, whilst fostering industry collaboration/ commercial conditions (mixed approach)
We believe that successful development of open banking and open finance will rely on the mixed approach because:
- Financial institutions are not incentivised to open up access to valuable data and functionality (hence why PSD2 and the CMA order were needed to make open banking a success) – they will need to be required to open up. A market-led approach will not result in the coverage needed to support further open banking services
- However, we appreciate that forcing institutions to provide APIs as a compliance exercise (rather than a commercial product), is not sustainable, and can ultimately undermine the quality of the services being provided. Therefore we believe supply-side institutions e.g. banks need to be able to benefit commercially in some way, as well as demand-side (TPPs).
Are multilateral agreements the solution to facilitate continued development of open banking?
We do not think that contractual arrangements on their own will be sufficient to foster further development of open banking. There also needs to be regulatory intervention to require financial institutions to enable functionality beyond current regulatory requirements.
Suggested approach:
- The future entity should be tasked with considering in what areas multilateral frameworks can add value, and what they should cover (beyond standards and regulatory requirements).
- If multilateral frameworks are developed into a ‘rule book’, as suggested by UK Finance, we would support the future entity having the role of administering and maintaining that rule book.
5. More data sharing between TPPs and banks/ account providers to reduce transaction limiting and blocking
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).
OBIE has issued new standards that enable banks to understand better the risk of open banking payments, including 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/ future entity should coordinate and require implementation of TRIs to enable longer term solutions to transaction limits and transaction risk sharing.
- 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.
6. A need for more detailed and consistent account holder identity information to power anti-fraud measures and verification
- We suggest that banks/ account providers should be required to provide the following information to TPPs, via API call, in order to help anti-fraud measures and verification:
- Consumer details
- Name of account holder (rather than account name or party name, which are not always reliable)
- Opening date of account
- Account holder address
- Account holder date of birth
- Business entity details
- Business name, address, phone, and email on file
- Tax ID number
- Business entity type
- Officers of the business that are on file
- Consumer details
- Further work should be done by the future entity to define a standard data set that includes identity information, and to ensure this is made available consistently by all banks/ account providers.
- We also recommend coordination with the Joint Money Laundering Steering Group (JMLSG) to provide clarification that identity information obtained through open banking APIs can be used to ID&V customers by obliged entities.
7. Replacing software statements as the means to identify customer-facing entity in bank dashboards
TPPs currently 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.
This issue has already been subject to a change request to OBIE that was considered, but discounted as part of the development of OBIE v. 3.1.10. OBIE concluded that this issue should be considered by the future entity.
Recommended approach:
- We recommend that standards are changed in order to have the relevant information provided in the consent message, rather than in software statements. This should be coordinated by the existing OBIE, or future entity.
CONTACT
Join us and be the voice of Open Finance in the EU and UK.
Copyright OFA 2022