FDX: A Common Technical Language for Open Banking
The Financial Data Exchange specification gives financial institutions, fintech companies, data platforms, and other authorized participants a common way to exchange user-permissioned financial data through secure APIs.
What is the FDX specification?
FDX is a family of API specifications and companion documents designed to make permissioned financial-data sharing consistent across different organizations and technology platforms.
A shared data model
Without a common standard, every bank and fintech could describe accounts, balances, transactions, customers, and permissions differently. FDX defines reusable data structures and API behaviours so participating systems can interpret the same information consistently.
The result is similar to agreeing on a common language: implementers still build their own systems, but they use the same vocabulary, field structures, request patterns, and security expectations at the connection point.
Built for permissioned sharing
FDX is centred on an end user choosing to connect a financial account to an app or service. The user authenticates with their account provider, reviews what is being requested, and grants permission without giving their banking password to the receiving application.
Permission can be limited by purpose, account, data type, and duration, depending on the governing rules and the implementation.
What is an API?
An application programming interface is a controlled way for one software system to request information or an action from another. It is the agreed doorway between systems—not the database itself and not unrestricted access to everything behind it.
How FDX is used in an open banking journey
The exact screens and legal requirements vary, but a permissioned data-sharing connection commonly follows this sequence.
-
1
The user chooses a service
A person asks a budgeting app, lender, accounting platform, tax service, or other eligible application to connect to one of their financial accounts.
-
2
The app requests a connection
The data recipient or its data-access platform starts an authorization request identifying the organization, requested data, intended use, and other consent details.
-
3
The user authenticates with the account provider
The user is securely transferred to their financial institution. Authentication happens there, so the receiving app does not need to collect or store the user’s banking credentials.
-
4
The user reviews and authorizes
The user reviews the accounts and data involved and decides whether to grant permission. Consent records support transparency and future management.
-
5
Secure tokens replace shared passwords
If permission is granted, the authorized application receives a limited security token. The token represents the approved connection without revealing the user’s login credentials.
-
6
Standardized data is delivered
The app requests permitted information through FDX endpoints. The provider responds using standardized data objects—commonly represented as JSON—so the app can process the response consistently.
-
7
The connection is managed over time
Depending on the service and governing framework, participants may refresh data, send event notifications, update consent, or end the connection. The user should be able to understand and manage active sharing.
Who does what in an FDX connection?
End user
The consumer or business that owns or is authorized to use the financial account and chooses whether to share data.
Data provider
The financial institution or other organization that holds the account data and makes authorized information available through an API.
Data-access platform
A platform that supplies connectivity or aggregation services between providers and receiving applications. Not every implementation requires a separate intermediary.
Data recipient
The authorized app or service that receives the permitted information to provide a product requested by the user.
What the FDX standard covers
FDX combines core API resources with security, consent, registration, experience, and certification guidance. Support for individual capabilities depends on the API version and each participant’s implementation.
Accounts and customers
Standard structures for customer information, account identifiers, account types, balances, and account details.
Transactions and holdings
Common representations for transaction histories, deposits, lending, credit cards, investments, and other financial relationships.
Consent
Models and behavioural guidance for recording and managing user permission, including the data and accounts involved.
Registration and discovery
Capabilities that help participants identify and register authorized recipients and support interoperable connections.
Events and fraud notifications
Frameworks for notifying participants about relevant events, including supported fraud-related messages.
Money movement
Extension models for supported payment and money-movement use cases, separate from basic read-only data access.
Tax and payroll data
Specialized structures supporting tax information and payroll-related use cases such as income or employment verification.
Security and experience guidance
Companion documents address financial-grade security, control considerations, user experience, taxonomy, and certification expectations.
FDX publishes versioned releases. Its Spring 2025 announcement identifies FDX API v6.4 and highlights updates to consent, security, user-experience guidance, YAML structures, and the FDX Consensus Standard Data Format. Implementers should confirm the version required by their market and counterparties.
The five FDX principles
FDX describes its work through five principles for user-permissioned financial-data sharing.
Control
Users should be able to grant, change, and withdraw permission for services they choose to use.
Access
Account owners should be able to use their data and decide which authorized parties may receive it.
Transparency
Users should understand who is receiving data, when it is used, and the purpose for which it was permissioned.
Traceability
Data-sharing activity should be traceable across the parties involved in the connection.
Security
Financial data should be protected while being requested, transmitted, processed, and stored.
How FDX supports secure data sharing
The FDX ecosystem uses established internet and financial-grade security patterns rather than inventing a completely separate security system.
OAuth 2.0 authorization
Limited tokens allow approved access without sending the user’s financial-institution password to the app.
OpenID Connect
Identity-layer capabilities support secure authentication and identity assertions where required.
Financial-grade API profiles
Higher-assurance security profiles strengthen client authentication, message integrity, and authorization flows for financial use cases.
Mutual TLS and protected transport
Strong transport security can authenticate systems to one another and protect information while it travels.
Scoped and manageable consent
Permissions and tokens can be limited to approved accounts, data, purposes, and time periods, subject to the applicable framework.
FDX APIs compared with credential-based screen scraping
| Area | FDX-style API connection | Credential-based screen scraping |
|---|---|---|
| Authentication | User authenticates directly with the financial institution. | A third-party service may collect or use the user’s login credentials. |
| Permission | Access can be represented by scoped, revocable authorization tokens. | Credentials may provide broader practical access than the service needs. |
| Data format | Structured fields and behaviours follow a common specification. | Software may need to interpret web pages designed for people. |
| Reliability | Purpose-built endpoints can be versioned and monitored. | Website redesigns or security changes can interrupt collection. |
| Traceability | API calls and tokens provide clearer records of participating systems. | Activity may resemble the user logging in and can be harder to distinguish. |
| Consumer control | Connections can be displayed and disconnected through consent-management experiences. | Ending collection may require changing credentials or managing the service elsewhere. |
This is a general comparison. Actual security and consumer outcomes depend on implementation, operational controls, and the rules governing participating organizations.
How FDX can support consumer-driven banking in Canada
FDX operates in both Canada and the United States and can provide a practical technical foundation for interoperable financial-data sharing. Canadian policy and regulatory requirements remain the controlling authority.
A common implementation target
Banks, credit unions, fintechs, and connectivity platforms can build against common endpoint patterns and data objects instead of negotiating every integration from scratch.
Support for consent and transparency
Consent models and experience guidance can help implement clear permission journeys and connection-management tools, subject to Canadian requirements.
Reduced credential sharing
Token-based API connections can move the market away from giving banking credentials to third-party applications.
Cross-border technical familiarity
Organizations operating across North America can reuse knowledge and technology while applying the regulatory profile required in each jurisdiction.
What different participants gain from standardization
Consumers and businesses
- More consistent connection experiences
- Less need to share financial credentials
- Clearer permission and connection management
- Broader choice of compatible financial services
Financial institutions
- A common model for external data-sharing APIs
- Improved visibility into authorized traffic
- Reusable security and consent patterns
- Less integration fragmentation over time
Fintechs and data recipients
- Consistent account and transaction structures
- More reliable connections than page parsing
- Clearer authorization and error handling
- Faster expansion across compatible providers
The wider ecosystem
- A shared vocabulary for implementation
- A forum for coordinated standards development
- Stronger interoperability and testability
- A base for certification and conformance work
FDX implementation is more than mapping fields
A successful deployment combines the API specification with governance, security, operations, testing, and a clear user experience.
Select the applicable profile and version. Confirm the required API release, supported resources, optional extensions, and market-specific rules.
Define supported use cases. Identify exactly which products, accounts, data clusters, and user journeys are in scope.
Implement financial-grade authorization. Configure clients, certificates, redirect handling, tokens, scopes, and secure key management.
Map internal data carefully. Align source-system values with FDX objects while preserving meaning, accuracy, and data quality.
Build consent lifecycle controls. Record grants, changes, expirations, revocations, and the parties involved.
Design the user journey. Make the organization, purpose, accounts, data, duration, and consequences understandable.
Plan for operations. Establish availability targets, monitoring, incident response, fraud handling, support, and version migration.
Test interoperability. Validate schemas, authorization flows, errors, pagination, performance, security, and end-to-end behaviour.
FDX and open banking FAQ
Is FDX the same thing as open banking?
No. Open banking is the broader system of legal rules, governance, authorized participants, consumer rights, security, and technical connectivity. FDX is a technical standard and implementation framework that can support that system.
Does FDX store everyone’s financial data?
No. FDX defines standards; it is not a central database holding all consumer information. Data remains with the organizations participating in each implementation and is exchanged through their systems.
Does an FDX connection give an app unlimited access?
It should not. API authorization is intended to be limited to the permissioned connection. The actual scope and duration depend on the consent, implementation, applicable rules, and capabilities of the participants.
Can FDX support payments as well as data access?
FDX includes money-movement extension models and related capabilities. A market’s legal and operational rules determine whether and how payment initiation is enabled.
Is every FDX implementation identical?
No. Implementations may support different versions, resources, optional capabilities, and jurisdictional profiles. Interoperability improves when participants clearly agree on profiles and validate conformance.
Is FDX officially mandated for Canada?
This page does not characterize FDX as a legal mandate. FDX is an established North American industry standard that can support Canadian implementation. Organizations should follow current Canadian legislation, regulations, technical standards, and official implementation guidance.