Business cases, and concerns, have been clear
Many banks have an API strategy to facilitate integration with internal groups or software providers. This approach has benefits with marginal 10% to 15% cost reductions from reduced complexity and redundant builds.
However, the full benefit of APIs is achieved with external integration. Open APIs allow the secure sharing of data and applications with third-parties which can enable a wide variety of new services. By enabling third-party collaboration, unforeseen product development and an upgrade to the overall financial experience can occur. For example, a consumer who can share responsible financial habits that are not part of standard credit scores, such as bill payment history or a track record of savings, could change how a bank evaluates a loan approval. Banks can also look to extend their core systems. Consider a consumer who can open a savings account through a third-party retail merchant, or a digital-only bank that can facilitate cash deposit capabilities through a chain of physical retail stores.
Common denominators for each of these examples is an effort to digitally expand the addressable market and monetize when APIs are invoked. Taking into consideration that further ongoing cost reductions at many financial institutions may produce only marginal ROE improvements, newfound methods to reaccelerate growth may be required to generate incremental returns. For an average mid-size bank that struggles to produce ROE above 8% to 9%, we estimate digital or API-based product expansion could generate an incremental 2% to 4% in returns.1
1 - “Opening the bank for a new era of growth”, PwC, June 2018
FDX addresses consumer, industry, regulatory, and security concerns
FDX is a member-supported organization formed to unite the financial services industry around a common technology standard and operating framework for data sharing. Ultimately it is the business case that will take open banking API frameworks from concept to reality. But concerns such as data security and a lack of standards are squarely what FDX means to address.
Despite its launch, the concept behind FDX was years in the making. Open Financial Exchange (OFX), an alternative open standard, was deployed by many firms in the financial services industry, but the technology has become fragmented, numerous versions exist, and it has become costly to support, due, at least in part, to a loose governance structure of volunteer members and no board.
Over the past several years, industry momentum to unite around a single open standard found support within security teams. This eventually led to the development of Durable Data API (DDA) by a working group within the Financial Services Information Sharing and Analysis Center (FS-ISAC). In an effort to position DDA as the standard for banks to securely share data, FDX was launched as a subsidiary of FS-ISAC and now owns the DDA technology.
The FDX aims to provide consumers with authorization controls over their financial data while unifying financial institutions around a secure standardized framework. This effort checks several boxes because it 1) addresses section 1033 of the Dodd-Frank Act, which mandates the consumer’s right to access their financial data, 2) is an industry-led initiative, an approach encouraged by several agencies (CFPB, Treasury), and 3) is positioned to emerge as a single de facto standard. On the last point, it is important to note that select founding members of FDX have been instrumental to OFX. As such, we expect OFX to eventually be merged into DDA, creating a single common standard for customer data sharing in the financial services industry.
Ingredients to succeed
As discussed, Bluetooth is a successful example of the technology industry supporting a common standard. Within financial services, there are examples of industry-established standards such as the Mortgage Industry Standards and Maintenance Organization (MISMO) and others such as NACHA, which coordinates the development of interoperable standards-based APIs (through Afinis) in addition to the affiliated ACH network utility for the transaction processing.
Common denominators for industry standards to succeed can include 1) a large community to support the standard, 2) recommended use of the standard by an industry utility or regulator, and 3) a clear business case to validate the commercial rationale.
FDX has specific goals to unite the industry to a common standard. As mentioned, we expect the alternative OFX to ultimately merge with the FDX-aligned effort which would be a significant catalyst for broad industry support. Importantly, the focus on security and data privacy by FDX and DDA are instrumental elements to grow industry support.
As for regulatory or utility-driven adoption, US regulators issued guidelines in the hope that data sharing regulation can be resolved by the industry through standards or self-adoption. There is an adequate foundation for future regulation should this not transpire but coordination between regulators and the FDX could occur, and would strengthen support for the initiative. It is important to note that efforts in the US are clearly different than other jurisdictions given the industry-led approach rather than regulatory or policy-driven.
In addition to data privacy and security, the clear business case is a critical ingredient. Many banks understand the need to be customer-centric which may require technical flexibility to deploy third-party solutions through APIs. Standard-based APIs make it much easier to expose services and data in order to monetize an open API effort. And given technology often removes traditional boundaries, the ability for banks to distribute third party or out of footprint products through open APIs can increase lifetime value of the customer. However, these efforts are early and will take time to see commercial validation.
At a minimum, all FIs should reassess their client data policies
The adoption of open-banking API frameworks is a natural component for a consumer-oriented innovation strategy. This, however, does not come without challenges. Beyond security and data privacy, banks need to consider compliance requirements, partner needs, culture differences, and technology architecture.
Even if financial institutions are not ready to move forward with an open-banking framework, there is a clear urgency to assess existing assumptions surrounding their data privacy and sharing policies. Consumer data is already shared willingly and unwillingly, through bilateral agreements and screen scraping, but organizations may not have full visibility into what data has been shared, why it has been shared, and which third parties it has been shared with.
At a minimum, most financial institutions should test existing assumptions surrounding their data privacy policies. For the many organizations aiming to comply with General Data Protection Regulation (GDPR), a data inventory and mapping exercise is a likely starting point. This process should be continually tested for effectiveness—particularly as data aggregators proliferate. Other standard processes, such as batch file transfers, could also be a source of concern as organizations may not have recently assessed the automated scripts or may not be aware of what data is being sent.
This sharing of data with external parties is the next step for the information governance process in moving beyond just eDiscovery or reducing the footprint for cybersecurity reasons to understanding where data is located and how it is used once it leaves the organization. Many data mapping exercises will focus on data creation and how the data internally traverses the organization, but they may lack visibility into whether data is then shared externally, under what consent, and whether the shared data is, in fact, appropriate.
As institutions begin to pursue open API frameworks, a rethink of the technology architecture is also encouraged. A future-state open-banking approach puts customer-centricity at the focal point. A well-conceived API-centric architecture, most likely cloud-based, can scale up or scale down based on real-time demand, or reconfigure services to tailor individual customer needs based on personalized data. Moving to this type of architecture may parallel or be a significant part of a broader application modernization or digital transformation strategy.
For many banks the next steps will be to evaluate the rationale for adopting an open-banking framework, examining growth opportunities, improved efficiencies, organizational flexibility, and competitive positioning. By augmenting some of the best attributes of banks (large installed base, scale, regulatory controls) and non-banks (rapid pace of innovation, technology talent, modern infrastructure), financial organizations can look to accelerate growth and enhance the customer experience.