Term · Financial Data Exchange

FDX

Published May 9, 2026
Definition

FDX — the Financial Data Exchange — is an industry-led open standard for consumer financial data exchange between aggregators, institutions, and consumer-facing applications. It defines a tokenized OAuth-based access model (replacing credential-based screen-scraping), a shared JSON resource taxonomy (Account, Holding, Transaction, Customer, Statement), and a conformance certification with phase levels. Major US aggregators and institutions are FDX members or affiliates.

FDX exists because the prior model — aggregator-to-institution data exchange via screen-scraping with stored customer credentials — was a security, reliability, and compliance problem. Stored credentials are a high-value target for compromise; screen-scrapers break whenever the institution updates its website; the model is incompatible with multi-factor authentication; and consumers had no transparent way to see or revoke aggregator access.

FDX replaces this model with OAuth-style tokenized access. The customer authenticates directly with the institution; the institution issues a refresh token to the aggregator; the aggregator presents the refresh token to access subsequent API calls. Customers can revoke tokens through the institution's interface. MFA works because authentication is at the institution's own UI. Aggregators don't store credentials.

The schema side defines a hierarchy of JSON resources: Customer at the top, Accounts owned by Customer, Holdings within Investment Accounts, Transactions on accounts, Statements as periodic reports. The schemas are versioned (FDX 5.x at general adoption, FDX 6.x in active rollout as of late 2025) and have phase-level conformance: Phase 1 is baseline read access; Phase 4 is full bidirectional capability including transaction-level detail and tax-document depth.

For wealth-tech platforms, FDX matters because it's the direction the industry is moving. Akoya is FDX-native; Plaid, Yodlee, and MX are progressively migrating institutions onto FDX-conformant access; Fidelity, US Bank, Wells, and other major institutions are FDX board members. The CFPB's Section 1033 rule (finalized 2024) creates regulatory pressure toward FDX-aligned access for consumer banking. The wealth-management piece is following.

The gotcha: FDX defines an access model and a schema baseline, but it doesn't mandate per-institution data depth. Two FDX-conformant institutions can return holdings data of dramatically different fidelity — one with full lot-level basis, the other with aggregate-only. Conformance levels (Phase 1 through Phase 4) capture some of this, but a Phase 2 conformant institution still has substantial latitude on what fields are populated.

Why this matters for synthetic data

FDX-aware synthetic data needs to span the conformance levels — a corpus that includes only Phase 4 fully-populated households will not exercise the migration scenarios where most production integrations live. Realistic test data spans Phase 1 (baseline read), Phase 2 (transaction history), Phase 3 (statement/tax-document depth), and Phase 4 (advanced/bidirectional) conformance levels, with optional fields populated at varying rates per institution.

Common pitfalls

  • Assuming all FDX-conformant institutions return the same data depth — conformance phases don't fully constrain field-level fidelity.
  • Treating FDX migration as binary — institutions are typically partially FDX-migrated, with some account types or product lines on FDX and others still on legacy access models.
  • Ignoring FDX version differences — FDX 5.x and FDX 6.x have schema differences that the integration layer has to handle if both versions are in production.
  • Not testing the token-revocation flow — a customer revokes FDX access through the institution; the aggregator's next call returns an unauthorized error; the platform has to handle re-auth gracefully.

Examples

FDX 6.x InvestmentAccount resource (simplified)

An institutional account in FDX shape carries common fields (accountId, accountNumber, productName, accountType, balanceAsOf) plus investment-specific fields (positions, lots if Phase 4, openOrders, dividendOptions). The schema is JSON Schema with versioned releases; institutions and aggregators publish their conformance levels publicly so consuming platforms can route accordingly.

{
  "accountId": "A-2025-9821",
  "accountType": "BROKERAGE",
  "productName": "Individual Brokerage",
  "balanceAsOf": "2025-09-30T16:00:00-04:00",
  "currentValue": 142850.32,
  "fdxVersion": "6.0",
  "conformanceLevel": "phase3",
  "investmentAccount": {
    "marginAccount": false,
    "positions": [/* per FDX Position schema */],
    "lots": [/* present at phase 4; absent at phase 1-3 */]
  }
}

Frequently asked questions

Is FDX a regulator standard?+
No — FDX is industry-led, governed by a member organization (Financial Data Exchange, Inc.) with major aggregators and institutions on the board. The CFPB's Section 1033 rule (consumer banking data) is regulator-led but largely aligned with FDX conventions. SEC and FINRA have not issued analogous wealth-management rules, but industry direction is FDX-aligned.
What's the difference between FDX and the EU's PSD2 / Open Banking?+
PSD2 is regulator-mandated; FDX is industry-led with regulatory pressure (CFPB 1033). PSD2 covers payment initiation in addition to data access; FDX is data-access-only at the moment. PSD2 has tighter compliance enforcement; FDX has broader scope (investments, retirement) that PSD2 doesn't directly address. The two are conceptually similar but operationally distinct.
Should I integrate against FDX directly or via an aggregator?+
Aggregator, in most cases. FDX defines the access model and schemas, but consuming FDX directly means handling per-institution OAuth flows, per-institution conformance differences, and per-institution token management for thousands of institutions. Aggregators (Akoya especially, but also Plaid/Yodlee/MX in their FDX-conformant modes) handle these concerns and present a single integration surface. Direct FDX integration is appropriate for institutional platforms that have a direct relationship with a small number of FDX institutions.