OpenID Foundation Comments on CFPB Rule 1033 Regarding Open Banking

Published January 3, 2024

Blog authored by Mark Haine.

The OpenID Foundation submitted comments to the CFPB on the recent Open Banking rule 1033 on Friday, December 29, 2023. The cover note to the CFPB is provided in full below, and the detailed comments can be viewed here

We are proud to support the CFPB in their due diligence on this rule to date, and we look forward to continued support of the CFPB and the US Open Banking community in the months and years ahead.

Any questions on our comments can be directed to director@oidf.org

 


 

OpenID Foundation
5000 Executive Parkway Suite 302
San Ramon, CA 94583

Consumer Finance Protection Bureau
1700 G St NW
Washington, DC 20552

December 29, 2023

 

Dear Sir or Madam

My name is Nat Sakimura, and I am the Chairman of the OpenID Foundation (Foundation)1 and am one of the Chairs of the FAPI Working Group (FAPI WG)2. The OpenID Foundation would like to thank the CFPB for the opportunity to provide feedback on the recent draft Open Banking 1033 Rulemaking, and provide ongoing support as may be useful in your due process.


Introduction

The OpenID Foundation is a non-profit organization whose mission is to lead the global community in creating open standards that are secure, interoperable and privacy-preserving. As part of that mission, the OpenID Foundation closely collaborates with several significant ecosystems internationally that have Open Banking and Consumer Financial data sharing systems requirements, and, in some cases, the OpenID Foundation provides services to help those ecosystems operate and scale their deployments.

Delivery of Open Banking on a national basis is a big challenge. The complexity of multi-party ecosystems that process millions of transactions should not be underestimated. In the financial services security and privacy are critical concerns for consumers and are important in maintaining the reputation of the ecosystem. The costs arising from meeting these requirements can be challenging to manage and the burden of those costs should not fall unfairly on any entity type as that will reduce participation and limit the overall success of the ecosystem. The use of open standards that have had input from hundreds of industry experts, have been through formal security assessment, can be delivered using off-the-shelf software components, and have been demonstrated to successfully support Open Banking ecosystems elsewhere, and that demonstrably achieve positive outcomes for millions of consumers can help minimize both cost and risk overall. The OpenID Foundation provides highly applicable open standards, years of hands-on experience and supporting services to several Open Banking and Consumer Data right ecosystems around the globe.

We have structured our feedback in two ways, one being along a number of themes, the second being by specifically addressing a number of the specific questions that the CFPB included in their consultation paperwork. These are attached as a spreadsheet.

1 https://openid.net/
2 https://openid.net/wg/fapi/


Key Themes

  • Standardized “Communication Protocol” & security
  • Conformance & certification
  • Software availability and cost
  • Lifecycle of standards
  • Digital identity attributes
  • Entity metadata and trust
  • How the OpenID Foundation can contribute


Standardized “Communication Protocol” & security

  • The most important item of feedback that the OpenID Foundation would like to offer is that use of an open industry standard, or “Standardized Communication Protocol”, should be required within the CFPB 1033 rulemaking. We define this “Standardized Communication Protocol” in the context of Open Banking as “the secure exchange of messages between the Consumer, Data Provider and the Third Party for the purpose of consumer authorization of access to data and services, and subsequent issuance of a Secure Access Token to the Third Party”.
  • The Communication Protocol is critically important for maintaining the security of data being passed (security being a feature that is focussed on preventing unauthorized access or modification).
  • A proven, rigorously tested open standard based Standardized Communication Protocol protects all ecosystem participants and addresses the need to authorize access to data and services, orchestrate authentication and provide Secure Access Tokens. These capabilities should be included by the CFPB as requirements of a Standardized Communication Protocol for Open Banking.
  • Without a Standardized Communication Protocol there is a significant cost incurred by all parties, but most notably by third parties’ where integration costs compound due to multiple different implementations provided by the Data Providers. The result of this being market dynamics that favor the largest entities over the smallest.


The OpenID Foundation provides one example of a Standardized Communication Protocol: the “FAPI profile of OpenID Connect.” This standard has been selected by many public and private Open Finance, Open Data, and Consumer Data Right ecosystems (e.g. the Australian Consumer Data Right, Australia’s ConnectID, UK Open Banking, Brazil Open Banking, Brazil Open Insurance, Saudi Arabia Open Banking, UAE Open Finance, USA FDX, Canada FDX, and HelseID Norway). These standards are proven at scale in many production deployments, both regulatory-driven and commercial. As a result, the OpenID Foundation has first-hand experience observing the pitfalls faced by ecosystems that lacked Standardized Communication Protocol mandates vs the benefits to those that had mandates.

In short, the OpenID Foundation strongly recommends the CFPB mandate use of a qualified industry Standardized Communication Protocol with a clear definition of its features in the final rule.


Conformance & certification

The OpenID Foundation's experience of working with multiple Open Banking ecosystems shows that while standards are very important they need support from complementary tools and services, specifically conformance testing tools and certification services.

The delivery of secure and interoperable Communication Protocol depends on Data Providers and third parties implementing it consistently and correctly. This can be tested empirically through the use of conformance testing tools. Tests significantly reduce time to detect implementation errors and reduce the cost and complexity for all parties. Public certification of conformance significantly increases the chances of interoperability being delivered across an ecosystem and provides evidence that the security aspects of the protocol have been implemented correctly too, increasing all parties’ confidence in the ecosystem as a whole.

In ecosystems that went ahead without a requirement for conformance testing, there were issues with interoperability and security. Where conformance testing is performed there have been several instances where significant security issues have been identified earlier in the lifecycle and were privately shared back to the Data Provider or Third Party to remediate prior to production deployment of vulnerable services.

The OpenID Foundation provides open source conformance testing tools for various specifications (including all versions of FAPI). These tools are written in close collaboration with the standards authors and contributors. While CFPB or nominated technical support partners can write their own conformance testing tools, re-use of existing test tools further reduces cost, risk, and time-to-market for implementations that use these OpenID Foundation maintained Standardized Communication Protocols. There is also a possibility to collaborate on specific additional CFPB or Qualified Industry Standards body requirements.

It is the recommendation of the OpenID Foundation that the CFPB rules should state that all ecosystem participants have their production implementations certified as conformant to the Standardized Communications Protocol prior to launch and periodically thereafter (we recommend at least annually) in order that implementations mitigate risks around interoperability and security. The certification should be backed by successful use of empirical testing conformance tools. As seen in other ecosystems, if this is not a clear requirement there is a significant risk that implementation errors will persist for longer than necessary and adverse consumer outcomes arise.

Furthermore, the OpenID Foundation recommends that conformance testing results be published publicly to improve consumer trust and transparency.


Software availability and cost

When ecosystems and implementers elsewhere have been considering how to deliver Open Banking the question of cost has arisen and it is worth stating that there is a less obvious benefit of having a Standardized Communication Protocol. Software vendors now offer “off-the-shelf” components that can deliver existing Standardized Communication Protocols needed, this often reduces the cost of implementation. Using an existing, widely deployed Standardized Communication Protocol has the additional benefit of reducing the time to market for that ecosystem as well as capitalizing on existing skills and experience developed in the delivery of Open Banking elsewhere. The final significant cost reduction factor relating to a Standardized Communication Protocol is that Third Parties in particular can not only use off-the-shelf components but re-use it across their integrations with multiple Data Providers.

 

Entity metadata and trust

One area that seems absent from the rule making is how Data Providers may make reasonable decisions about whether to trust a Third Party that connects to them. The way the rules are currently drafted, it seems that this is a decision that is left up to each Data Provider. This could become a significant source of risk and cost to both the Data Providers as well as the consumers as Data Providers individually take decisions about third party access. It may even result in significant cost for Third Parties as they may be required to go through bi-lateral due-diligence procedures with many Data Providers in order to sufficiently mitigate these risks. An alternative approach would be to allow for some intermediary to define and apply supporting processes, and technology to do due-diligence on third parties and provide a streamlined system for establishing trust between third parties and data providers. If this is done in concert with a qualified industry standard communication protocol then the communication of that entity’s technical metadata will also allow much quicker technical integration once the due-diligence is done.

The OpenID Foundation recommends adding in additional rules to address how trust can be established in an interoperable and scalable fashion without bilateral, point-to-point trust requirements. This allows entities to onboard once, have a source of truth for trust and configuration that uses a standard communication protocol. It is also recommended to have a qualified industry standard specific to the exchange of this trust information and the associated integration details. The OpenID Foundation develops and maintains standards for this purpose.

 

Lifecycle of standards

One topic that has been challenging and should be considered carefully in the rulemaking is striking a balance between the use of a small number of critical standards and the agility of the ecosystem when it comes to change over time. To future-proof the rulemaking, it would be appropriate for the rules to include a mechanism for on-going maintenance and versioning of qualified industry standards in a way that the benefits of standardization are realized, while mitigating the risk of inertia and cost of change to the ecosystem. To this end, we recommend the following processes are established:

  • Review proposed changes to the qualified industry standards at an ecosystem level and in partnership with relevant standards bodies, balancing the impact of change against the benefits that may be realized via the updates.
  • Process to ensure conformance to the updated standards. The current practice is a cadence of regular standards review, followed by a notice period on standards and any changes to requirements, and then a period of conformance and certification to ensure implementations reflect the updated requirements.


Failure to account for the lifecycle of standards can lead to resistance by key ecosystem participants who seek to minimize conformance costs at the expense of security, operational and user experience benefits. From a national perspective, this inflexibility can also reduce US competitiveness, when global open banking and open data use cases emerge and ecosystems seek to interoperate. As an example, domestic implementations of FAPI 1 and other standards like India’s UPI are not currently interoperable, but the use cases and path to global interoperability are emerging as domestic deployments mature. This global landscape and path to global interoperability is discussed in the 2023 OIDF whitepaper “Open Banking, Open Data: Ready to Cross Borders?”3.

The OpenID Foundation manages the lifecycle of its specifications in an open collaborative forum with a clearly documented process. Representatives of user communities around the world participate and their interests and needs are taken into account. The latest version of the OpenID Foundation’s Communications Protocol (FAPI 2.0 Security Profile) is currently going to a membership vote on “Final”, having successfully gone through previous stages of the process, including formal security analysis. As an example of good lifecycle management, having analyzed the benefits, many ecosystems are updating their roadmaps to migrate to FAPI 2.0.

3 https://openid.net/2023/02/06/final-version-of-open-banking-and-open-data-ready-to-cross-borders-wh itepaper-published/


Digital identity attributes

The current rule on Open Banking includes “Basic Account Information” in the scope. If this information remains in scope, then the CFPB should be able to answer the following questions affirmatively, as any answers to the contrary may have unintended consequences.

  1. If Basic Account Information g. “name, address, email address, and phone number” are requested, is there the intent or even a requirement for this PII data to be requested separately with separate and explicit informed consent of this PII by the user?
  2. If Basic Account Information g. “name, address, email address, and phone number” are requested, are there security requirements for Third Parties holding this information, how it can be used (e.g. a relevant purpose / use case) and are there requirements on Data Providers disclosing it (e.g. a higher authentication assurance level to share the PII vs bank account information), as this information arguably has additional risks relating to identity theft.


The scope of the CFPB is clearly financial services and attributes such as “name, address, email address, and phone number” are typically maintained by financial services organizations for communication with the customer and fraud mitigation purposes. There is a risk that including this information in the rule might allow a pseudo-assured identity market to emerge based on this basic account verification information. If this is the intent of the CFPB, then we recommend guidance for (1) and (2) to avert unintended outcomes, and ensure the user’s data rights are respected and this sensitive data is suitably protected. If it is not the intent of the CFPB to enable identity assurance use cases (based on ‘AML backed” digital identity data), we recommend the CFPB clarify the intent of the rule making and to make more explicit the use cases that are in and out of scope of the rulemaking.

Separately, the current requirement for Data Providers to “make available covered data when it receives information sufficient to: Authenticate the consumer’s identity…” is not very explicit about authentication and could be interpreted in various ways, some of which could have a significant risk of the incorrect consumer being identified and consequently consumer finance data being inadequately protected. A range of standards for consumer authentication that are sufficiently robust for use in financial services exist and all of these involve the consumer authenticating directly to each party rather than doing so via a third party. It is done this way mainly for enabling a variety of options for secure authentication and ensuring that consumer credentials do not need to be shared with a third party.

The OpenID Foundation does not address authentication directly other than requiring authentication to be done when the FAPI profile is used. This permits a range of choices for Authentication to be provided in the context of the Standardized Communication Protocol and Authentication of the consumer by the Data Provider directly.

 

The OpenID Foundation contribution

In accordance with our mission and vision, the OpenID Foundation will continue to actively engage with US market stakeholders (as we do with any market engaging in Open Data) to support the local market development, support due-diligence checks of our specifications, and adapt our operational capabilities to serve local ecosystems. In context of the current rules, the OpenID Foundation is keen to continue engaging and innovating along with key stakeholders in the US market, including the CFPB. The OIDF is willing to act as a Qualified Industry Standard Body or participate as part of a consortium that jointly act as a Qualified Industry Standards Body, or play both roles as required by the US market participants.

Should any OpenID Foundation standards be selected by any Qualified Industry Standards Body (either directly or as part of joint offering) there would be no charge for access to or use of OpenID Foundation specifications. Similarly, there is open source conformance testing software provided to test implementations of the key OpenID Foundation standards. These Open Source tools are made available to all for free. The OpenID Foundation also currently operates a cloud instance of the conformance testing tools that can be used by any party free of charge.

Self-certification of conformance to key standards can be asserted and published on the OpenID Foundation website for a small fee. To support ecosystems with deployment, we are also open to ecosystem-specific, strategic partnerships to deliver local stakeholder requirements.

Should any organization or individual wish to contribute to the OpenID Foundation’s on-going developments or maintenance of FAPI and related standards the only requirement would be the signing of the Intellectual Property Rights agreement, membership and fees do not apply. That said, membership of the OpenID Foundation entitles three key benefits: voting on the specifications at key milestones in their lifecycle, a significant discount on self-certification, and the opportunity to direct funds to projects of benefit to the OpenID Foundation community.

Please see attached our detailed comments on the CFPB rulemaking. We would be delighted to clarify any points in this cover letter or the attached documents, just contact us via director@oidf.org.

 

Sincerely,

Nat Sakimura
Chairman & Co-Chair FAPI WG
OpenID Foundation

 

Tagged