Technical Impacts of Open Banking and Financial Data Exchange on Financial Systems

Building on a discussion laid out in Securing Open Finance in 2025, Open Banking is changing how financial data is shared and secured, catering to the growing power of consumer financial access, flexibility and decision making. International Open Banking programs and industry-led programs like Financial Data Exchange (FDX) are designed to make it easy for banks, fintech, and consumers to share data. These programs prioritize security, transparency, and consumer consent. Highlighting baseline requirements and dissecting essential compliance requirements in Open Banking simplifies gap analysis and prepares security and platform teams to build plans for safely deploying digital-first financial services.

 

API Security for Open Banking

From the perspective of technology implementers, the core of Open Banking is API technology, facilitating secure data exchanges. This API-first approach is responsible for exposing sensitive financial data (e.g., account balances, transactions, payment initiations) to approved third-party providers. This open interactivity between financial services comes with increased risk should API security recommendations fail to meet documented governance models, including:

• Compromised consumer data
• Fraud and known attack vectors (e.g., MITM or injection attacks) undermining consumer trust in traditional banking institutions
• Regulatory fines for failures to comply with federally mandated standards (this does require a governing body to have authority to enforce financial damages)

Evolving API security requirements to accommodate the growing breadth of consumer financial application use is crucial for protecting consumer and business data. As Open Banking provides actionable recommendations keeping parity with one or more existing standards, including PSD2 (EU), FDX (North America), UK Open Banking, and CDR (Australia).

 

Figure 1: Consumers are interacting less with institutional banking and more with digital financial solutions

Consumers are increasingly making use of fintech services decoupled from their primary traditional banking institutions. This is the main reason for the current state of decentralized financial (DeFi) solutions. We need to understand how API-first communications affect the system and how to secure the complex communication it has created.

 

Key API Security Requirements

We’ve all read this before but we're going to print it again since headlines prove not everyone's paying attention. What were once considered "best" practices should now be considered minimal operational policy and will be determining factors for successful financial programs moving forward. To validate appropriate API security programs for Open Banking participation, we're re-validating a common set of policy and practices checks for the following requirements:

 

1. Authentication and Authorization

Authentication verifies who the client is, while authorization decides what they can do. In Open Banking, Strong Customer Authentication (SCA) is legally required in some frameworks, e.g., PSD2. But let's be honest, it should be required for all participating frameworks.

Recommended Practices:

• OAuth 2.0 and OpenID Connect:
  • Use OAuth 2.0 frameworks for secure token-based access.
  • Implement OpenID Connect to strengthen client identity verification.
• Strong Customer Authentication (SCA):
  • Employ multi-factor authentication (MFA), such as:
    • Knowledge: Password or PIN.
    • Possession: One-time passcode (OTP) through something BESIDES SMS/Text.
    • Inherence: Biometric identifiers like fingerprints or facial recognition.
  • Access Scopes:
    • Allow TPPs to access only the data explicitly authorized by the customer (e.g., read-only transaction history, no write permissions for transfers unless permitted).

Basic checklist for AuthN/AuthZ:

• Implement OAuth 2.0 with refresh token mechanisms.
• Use time-limited access tokens (short-lived).
• Enforce strong password policies and use biometrics. (prefer stronger auth methods with SMS as last resort)
• Provide customer-accessible consent for API calls.
• Separate authentication from authorization to tighten access controls and provide clarity on consent.

 

2. Data Encryption

Financial data in Open Banking systems must always be encrypted in transit and at rest to prevent unauthorized interception. While the industry calls for a minimum of TLS 1.2, come on.... You and I both know we can just as easily do TLS 1.3. The more recent addendums call for institutions to implement NIST recommended hybrid PQC cryptographic models, which this author fully endorses for both data in flight and at rest, to prevent the "Harvest Now, Decrypt Later" frenzied discussion.

Best Practices:

• Transport Layer Security (TLS):
  • Use TLS 1.2 or higher for encrypting API traffic. (common sense recommends 1.3)
  • Enable Perfect Forward Secrecy (PFS) to prevent long-lived data leaks.
• Secure Data Encryption Standards:
  • Encrypt sensitive data at-rest using AES-256.
  • Implement NIST recommended Hybrid Post Quantum Cryptography protocols where applicable and start to implement a cryptography agility program for future PQC changes. A note on PQC follows this article's main body.
• End-to-End Encryption:
  • Financial data must remain encrypted/secured throughout its lifecycle, not just during API transit.

Baseline checklist:

• Enforce TLS 1.2 AT MINIMUM for all connections. There's no reason we can't do TLS 1.3.
• Encrypt sensitive data using industry-standard encryption (AES-256).
• Use modern (PQC+) public key cryptography for secure key exchanges.
• Regularly verify encryption methodologies for vulnerabilities.

 

3. API Access Control

Access to data must be limited to authorized parties and controlled with least privileged access based on the transactional need of the API request.

Recommended Practices:

• Role-Based Access Control (RBAC):
  • Assign access permissions based on predefined roles (e.g., read-only for data collection, write-access for payment initiation).
  • Attribute-Based Access Control (ABAC):
    • Tie access permissions to conditions, such as device IDs, IP addresses, or geolocations or data classification.
• Least Privilege Principle:
  • Restrict access to the minimum amount of data/functionality needed for the user's purpose.
• Rate Limiting:
  • Limit the number of API requests per user, client ID, or IP address to prevent abuse.

Your favorite checklist:

• Implement RBAC and ABAC for fine-grained access controls.
• Restrict data access based on consented scopes.
• Enforce API rate limiting with realistic client throughput.
• Monitor authentication/authorization attempts.

 

4. Consent Management and Audit Trails

Transparency in data sharing and auditability is critical in Open Banking to ensure both compliance and security.

Recommended Practices:

• Granular Consent Management:
  • Include what data is being shared, for how long, and with whom.
  • Allow users to revoke consent, easily, triggering real-time updates in the system.
• Audit Trails:
  • Log all API interactions:
    • What data was accessed?
    • Who accessed it?
    • When and what method requested it?
• Regulatory Reporting:
  • Adhere to frameworks like GDPR and CCPA for consumer data protection and transparency.

Yet another checklist:

• Provide clear consent screens with user-friendly context.
• Enable real-time revocation of permissions by users.
• Record detailed audit logs for all API interactions.
• Deploy dashboards for regulatory and internal reporting.
• Run audit and compliance tests to ensure all recorded data is quickly accessible for compliance queries or incident management.

 

5. Threat Detection and Monitoring

Failure to detect and respond to threats like API attacks or suspicious behavior ultimately compromises consumer data and exposes systems to financial fraud.

Recommended Practices:

• Real-time Monitoring:
  • Use proven anomaly detection to identify unusual transaction patterns or API calls.
• API Gateway Security:
  • Automate deploying API gateway security policies as APIs are deployed (e.g., signatures, IP whitelisting, rate limiting, authN/authZ).
• Web Application Firewall (WAF):
  • Block SQL injection, cross-site scripting (XSS), and other malicious payloads targeting API URL/URIs.
• Fraud Detection Systems:
  • Continuously monitor authentication attempts, unusual geolocations, or multiple failed token exchanges. Take advantage of intelligent AI-based systems that can dynamically understand and adapt to human vs. automated threats and tune accordingly.

The best checklist:

• Automate robust API gateway and security services and policies to protect at deployment.
• Implement real-time fraud detection systems.
• Use WAF rules for common attack patterns and application specific signature tuning.
• Enable automated alerts for suspicious or anomalous API traffic.

 

API security in Open Banking is non-negotiable. The included checklists initiate a discussion on the security services needed towards achieving compliance across Open Banking programs worldwide. The practices to maintain adherence are several full-time jobs even for the more nimble fintech and financial application providers. But this is the new norm. Malicious behavior is increasing and accidental configurations exposing customer data will never go away. Attach this to an expanding attack surface of API-first financial services, good enough security is bad security.

Figure 2: Assume threat and required security services beyond traditional perimeter controls

 

Financial Data Exchange (FDX) API 6.0

Open Banking security recommendations and practices lean towards customer control over financial data. FDX is an industry backed design to standardize financial data sharing within North America and leans towards financial institutions and fintech, still adopting many Open Banking programs supporting customer granular control over data.

The current FDX API, version 6 enables access to over 600 financial data elements. Due to this increased availability of data, risks associated with insecure APIs are significant. FDX is evolving to cover more financial transactional aspects under the core program, which will bring it to parity with many Open Banking standards. The below table highlights some comparisons between existing efforts.

 

Comparing Open Banking and Financial Data Exchange

 

The customer-first focus of Open Banking is not lost on larger financial institutions losing market share and customer engagement to digital first intermediaries or smaller single service-based applications. There's continued push back on many Open Banking programs and efforts. Fortunately for consumers, companies operating under organizations like the European Union are helping put customer needs first, enabling enforcement for failures to comply. Forcing fintech and the global banking industry forward secures our data moving forward, short and long-term, ultimately providing a safer and better digital tomorrow.

Notes:

Hybrid Post-Quantum Cryptography in Open Banking

Today's current cryptographic standards are secure against classical computing cryptanalysis but are potentially vulnerable to methods enabled through emerging quantum computing and long understood algorithmic research in the field of quantum cryptography. The National Institute of Standards and Technology (NIST) and researchers have long studied methods to protect data using classical mathematics with the understanding that quantum cryptography itself is still impractical for public key infrastructure (PKI). NIST internal report 8547 highlights a rather reasonable path forward for deprecating and disallowing quantum-vulnerable cryptography while adopting a hybrid strategy to integrate new crypto primitives resistant to quantum methods.

Many vendors are rapidly working towards or have already implemented NIST’s proposed cryptographic primitives needed to comply for classical and quantum cryptographic ciphers currently discussed as Hybrid PQC. Given the financial open standards discussed in this article, Hybrid PQC is a critical requirement and step for future-proofing customer and business financial data. Working with all security vendors in a security tool chain, any gaps in PQC plans should be highlighted with contingency plans put in place now so businesses are not left scrambling by 2030. It's not that far away, folks.

NIST's offers cryptographic guidance on Post-Quantum Cryptography and has approved three FIPS levels to help adopters stay ahead of compliance deadlines.

• FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• FIPS 204, Module-Lattice-Based Digital Signature Standard
• FIPS 205, Stateless Hash-Based Digital Signature Standard

 

Recent Changes On Consumer Financial Protect Bureau Section 1033

On January 8th, the Consumer Financial Protection Bureau (CFPB) announced their intent to use the Financial Data Exchange (FDX) as a standards-setting body, highlighting the non-profit's goal to align the financial industry around a common standard for secure and easy access of consumer and business financial data. Section 1033 of the Dodd-Frank act provided consumers the right to access and share their financial data, pushing financial service providers to make available information in those providers' control.

In a recent legal filing, the CFPB will petition a court to have 1033 open banking rules rescinded. Section 1033 is unpopular with many traditional financial institutions, who cite potential data breaches and the inability to charge for access to user data as primary complaints. While this preserves the control of data with the US largest financial institutions, there is no method in place to force compliance with modern security practices moving forward.

This author can count several US financial services whose only method of multi-factor authentication is SMS, a long known insecure method and widely exploited communication standard. Striking down 1033 benefits these institutions to operate with reduced security and liability compared to the rest of the digitally competent global banking markets. While the Financial Technology Association (FTA) has called the sudden shift in policy a "handout to Wall Street banks", the FDX will continue to push alignment to global Open Banking standards and promote a better digital financial future for consumers and businesses moving forward.