Secure the FDX API to Defend Data in Open Banking

F5

At the recent FDX Global Summit Spring 2021, I participated as a panelist representing F5, along with other panelists from Cequence Security and Mastercard-Nudata. We discussed the work of the FDX API security working group, which brings financial institutions, aggregators, and security vendors together to collaborate on defining a secure and open banking standard for data sharing.

Financial Data Exchange (FDX) is a non-profit organization focused on developing the FDX API (Application Programming Interface) standard to create a common interoperable data standard. This enables consumers and businesses to reliably and securely access their financial data and will set the benchmark for open banking in the United States and Canada.

Open banking presents an exciting opportunity for greater innovation and collaboration in the financial services industry—providing access for FinTechs and other authorized third parties to innovate and provide value added services with consumer financial information. Open banking standards provide consumers with the ability to consent to and permit secure fine-grained access by third parties to specific financial consumer data (e.g., balances, transactions) and functions (e.g., payments). There are exciting possibilities for third parties and FinTechs to provide value added services including:

• Aggregation of accounts/services at multiple institutions into one place
• Payment initiation
• Financial product comparison
• Provide banking services not already provided by the institution
• Provide decisioning/insights based on financial data—such as identity verification, credit serviceability assessment, etc.

F5 has been working closely with our financial services customers worldwide implementing and securing open banking APIs. F5 and Twimbit collaborated to publish research on the worldwide trends in open banking.

Inherent value of consumer financial information

Consumer financial information is a commodity traded on darknet marketplaces for between $35 USD (for accounts with low balances that can be utilized as mule accounts for other fraud) and $150 USD upwards (for accounts with larger balances). This relatively low traded value of consumer financial information is a result of the overwhelming supply of compromised accounts and credentials available. Adversaries have therefore leveraged automation—APIs—in order to scale their operations, which trade in thousands of stolen accounts; therefore financial APIs have become a primary threat surface to be protected.

Attackers Focus on APIs in Open Banking

In recent times, cybercriminals targeting the financial services sector are starting to focus more of their attacks on application programming interfaces (APIs). Applications have moved toward an increasingly distributed and decentralized model, with APIs as the connection points. The most recent F5 research shows that the number of API security incidents is growing every year, and most API incidents during the last two years were related to a low level of security maturity, which is often caused by tool sprawl. Different development teams working on multiple applications often use disparate tool sets. That means traditional security teams may not own a centralized point of control to enforce security. This requires a standard set of tools to embed the right controls into the API development and management processes.

An evolution—OFX and screen scraping

APIs are not the only threat surface that require attention. Traditionally, third parties and financial aggregators who have required access to consumer data have leveraged two mechanisms:

• OFX (Open Financial eXchange)—which was initially built to connect consumer financial applications (e.g., MS Money, Intuit QuickBooks) to a user’s financial institutions.
• Screen scraping—where consumers provide their banking credentials to a third party, and the third-party logs into and scrapes that information from the financial services web channel.

OFX can be utilized as a channel for adversaries to do large-scale credential stuffing/account validation and takeover—both directly and via financial aggregators:

• F5 regularly observes OFX being utilized as a channel for adversaries to do large-scale credential stuffing/account validation and takeover—both directly and via financial aggregators.
• Providing third parties with credentials for screen scraping exposes those credentials to the security posture of that third party.
• These mechanisms do not provide the consumer with fine-grained consent and control over what information the third party has access to, resulting in breaches of privacy.

OFX has joined FDX and will ultimately merge into a unified standard, representing the opportunity to modernize security controls and address the security challenges of the past. Screen scraping-based approaches continue to be a challenge for financial institutions.

Recommendations to improve security

FDX has published comprehensive advice regarding the controls that should be implemented in order to protect from threats and risks to consumer accounts information and service integrity. These controls include:

• Software security—control for the OWASP top 10 and other software vulnerabilities—including deploying a web application firewall (WAF)
• Network and systems security
• Operational security
• Physical security
• Business continuity and disaster recovery
• Supplier security
• Design patterns for authN/authZ including controls for credential stuffing
• Patterns for a secure gateway architecture (SGA), including API security controls baked into the API gateway

Finally, F5 open banking solutions guide provides a comprehensive approach to F5 solutions for open banking.

Special thanks to members of our Financial Services team who contributed to this article: Benn Alp, Chad Davis, and Andy Franklin.

About the Author

F5

More blogs by F5