Future of Secure API Design: Data Exchange in Finance

Jane Ginn

3 weeks ago

The Financial Data Exchange (FDX) published the API v6.4.0 update on Monday, June 16^th. As part of the updated specification, they have published a Security Model to guide the design characteristics of an implementation for DevSecOps teams for API security. This standard is available for adoption by any or all of the 4,500+ FDIC-insured financial institutions and FinTech’s in the United States and Canada and is recommended for international firms doing business in the U.S. or Canada.

The Security Model is designed to ensure secure, interoperable, and regulatory-compliant access to consumer financial data. For technical teams building or integrating with FDX APIs, understanding this security model is crucial for both implementation and ongoing compliance. Here’s a short walkthrough of the core components and design philosophy of the FDX API v6.4.0 Security Model. For more information go to the press release from the FDX.

A Dual-Profile Security Architecture

At the heart of the FDX Security Model is a dual-profile approach, allowing implementers to choose between two robust, standards-based security profiles:

Green Profile:
Based on OAuth 2.0 (RFC 6749), the Green Profile is tailored for organizations that require strong security but do not need the advanced features of financial-grade APIs. It mandates the use of confidential clients, short-lived access tokens (≤ 900 seconds), and strict scope validation. The client credentials grant is the primary flow for most endpoints, ensuring that only authorized, registered clients can interact with sensitive data. Additional requirements include audience-restricted tokens, refresh token rotation (per RFC 9700), and suppression of referrer headers to minimize data leakage.
Blue Profile:
Built on the OpenID Foundation’s FAPI 2.0 standard, the Blue Profile is intended for organizations needing the highest level of security and interoperability. It incorporates all the Green Profile’s requirements and adds immediate token revocation upon consent withdrawal, as well as further alignment with FAPI 2.0’s advanced security features. This profile is especially relevant for organizations subject to stringent regulatory and interoperability requirements12.

Agreements between implementers determine which profile is used, but full compliance with the chosen profile’s requirements is mandatory for conformance.

Conditional Security Enhancements

FDX v6.4.0 recognizes that not all data exchanges require the same level of protection. Therefore, two additional security standards are conditionally applied based on mutual agreements:

Message Encryption:
Where sensitive data or regulatory requirements dictate, FDX supports application-level encryption using nested JWTs (JWS for signing, encapsulated in JWE for encryption). This approach enables both payload- and field-level encryption, ensuring confidentiality and integrity even if transport-level security is compromised. Key management is rigorous: asymmetric keys for signing and encryption must be stored in FIPS 140-2 Level 3 or Common Criteria EAL4-compliant systems, with crypto-periods capped at two years.
Step-Up Authentication:
For high-risk or sensitive operations, FDX adopts the OAuth 2.0 Step-Up Authentication Challenge Protocol (RFC 9470). This allows a resource server to challenge a client when an access token lacks sufficient authentication strength or recentness. The client then redirects the user to the authorization server for re-authentication, after which a new, higher-assurance token is issued.

Token Handling and Consent Validation

Token-based access is foundational to FDX security. Every API request must include a valid access token in the HTTP header. The resource server is responsible for:

Verifying that the token’s scopes match the consented scopes.
Ensuring the consent record entitles the requester to the requested action.
Checking the issuer (iss) and audience (aud) claims for authenticity and intended recipient validation.
Enforcing strict expiration (≤ 900 seconds) and secure transmission (never in URLs).

If a user revokes consent, all related tokens must be immediately invalidated (especially under the Blue Profile).

Endpoint-Specific Security Requirements

Different FDX endpoints have tailored security requirements:

Core, Customer, Money Movement, and Meta APIs:
Use the client credentials grant (OAuth 2.0 or FAPI 2.0, depending on the profile).
Notifications Publishing:
Requires either TLS client certificate authentication or private_key_jwt.
Other Endpoints:
Must comply with the authentication requirements specified for their category in the chosen security profile.

These updates reflect ongoing industry collaboration and are designed to help build API solutions that align with emerging data access expectations—whether regulatory or market-driven.

Principles of Data Minimization and Interoperability

FDX’s security model is tightly coupled with its principles of data minimization and interoperability. Scopes must be limited to the minimum necessary for the client’s operations, and all security flows are designed to be interoperable across diverse financial institutions and third parties.

Compliance and Evolution

The FDX API v6.4.0 Security Model is recognized by the Consumer Financial Protection Bureau (CFPB) as a consensus standard, supporting compliance with Section 1033 of the Dodd-Frank Act. FDX continues to evolve its standards in response to regulatory changes, market needs, and emerging threats, ensuring that its security model remains both practical and future-proof.

Conclusion

The FDX API v6.4.0 Security Model offers a layered, flexible, and standards-driven approach to financial data security. By allowing organizations to select the appropriate security profile, supporting advanced encryption and authentication mechanisms, and enforcing rigorous token and consent management, FDX provides a blueprint for secure, compliant, and interoperable data sharing in the financial sector.

To read more in this series on the FDX API v6.4.0 standard see:

References:

Jane Ginn CTIN President & Co-Founder

Jane Ginn ~ As the co-founder of the US-based Cyber Threat Intelligence Network (CTIN), a consultancy with partners in Europe, Ms. Ginn has been pivotal in the development of the STIX international standard for modeling and sharing threat intelligence. She also served as the Secretary of the OASIS Threat Actor Context Technical Committee, contributing to the creation of a semantic technology ontology for cyber threat actor analysis. Her efforts in this area and her earlier work with the Cyber Threat Intelligence (CTI) TC earned her the 2020 Distinguished Contributor award from OASIS. She is currently supporting the analysis services of Datos Insights, an advisory firm focusing on the financial services sector. In public service, she advised five Secretaries of the US Department of Commerce on international trade issues from 1994 to 2001 and served on the Washington District Export Council for five years. In the EU, she was an appointed member of the European Union's ENISA Threat Landscape Stakeholders' Group for four years. A world traveler and amateur photojournalist, she has visited over 50 countries, further enriching her global outlook and professional insights.

See Full Bio