How to Build an Open Banking Platform with PSD2 and FDX APIs

Every open banking platform rests on three pillars: consent management, data aggregation, and payment initiation. You can build a viable product with just one or two, but the most valuable platforms combine all three.

Consent management handles how users authorize access to their bank data, how that consent is stored and renewed, and how it is revoked. PSD2 mandates explicit consent with 90-day renewal cycles. FDX requires consumer-directed access with clear data sharing agreements. Get consent wrong and you face regulatory action.

Data aggregation connects to bank APIs, retrieves account balances and transaction history, normalizes data across different banks, and enriches it with categorization and merchant identification. This is the feature that powers personal finance apps, lending platforms, and accounting tools.

Payment initiation (PISP under PSD2) allows your platform to initiate payments directly from a user's bank account, bypassing card networks. This is the feature that disrupts credit card processing by enabling Account-to-Account transfers at a fraction of the cost.

If you have already built a fintech app, adding open banking capabilities is a natural extension. Here is the technical guide for building it properly.

Consent management is not just a UI flow. It is a legal and technical framework that governs your entire platform.

PSD2 Consent Flow

Under PSD2, the consent flow works like OAuth: your application redirects the user to their bank's website, the user authenticates with Strong Customer Authentication (two of three factors: knowledge, possession, inherence), the user explicitly consents to data sharing, and the bank redirects back to your application with an authorization token. This token grants access to specific accounts for a maximum of 90 days, after which the user must re-consent.

Build a consent management service that: stores active consents with expiration dates, tracks which accounts each consent covers, sends renewal reminders before consent expires, handles re-consent flows seamlessly, and maintains an audit trail of all consent events.

FDX Consent in the US

The FDX (Financial Data Exchange) standard uses a similar OAuth-based flow but with different terminology and implementation details. Section 1033 of the CFPB's rule establishes consumer data rights, requiring banks to share data through standardized APIs. The FDX consent framework includes data recipient registration, consumer authorization, and ongoing access management.

Consent Screen Design

Each bank has its own consent screen, which means you cannot control the user experience at the most critical point in the flow. What you can control: the pre-consent explanation (tell users exactly what data you need and why), the post-consent confirmation (show which accounts are connected), and the consent management dashboard (let users view, modify, and revoke consents at any time). Clear, transparent communication reduces drop-off during the consent flow.

On paper, PSD2 standardizes bank APIs. In practice, each of the 5,000+ European banks implements the standard differently. FDX in the US faces similar fragmentation across 10,000+ financial institutions.

API Standards and Variations

PSD2 banks in Europe use one of several API standards: Berlin Group NextGenPSD2, UK Open Banking Standard, STET (French standard), or PolishAPI. Each has different endpoint structures, data models, and authentication flows. Even within the same standard, individual banks add their own quirks.

In the US, FDX provides a common data standard, but many banks still offer proprietary APIs or rely on screen scraping (which is increasingly being blocked). The transition from scraping to API-based access is ongoing in 2026.

Building an Adapter Layer

Design your integration architecture with a clean adapter pattern: define an internal canonical data model for accounts, transactions, and balances. Build a separate adapter for each bank or API standard that translates between the bank's format and your canonical model. This abstraction lets your application code work with a single data model while the adapters handle bank-specific translations.

Error Handling and Resilience

Bank APIs are unreliable. Expect: rate limiting (4 to 10 requests per second per customer), intermittent outages (2 to 5 times per month for major banks), stale data during maintenance windows, and inconsistent error codes. Build circuit breakers that detect failing bank connections and route to cached data. Implement retry logic with exponential backoff. Monitor bank API health in real time and maintain a status dashboard.

Raw bank transaction data is messy: cryptic merchant names, inconsistent amount formats, missing categories. Enrichment transforms this raw data into usable information.

Merchant Identification

Bank transaction descriptions are often unhelpful: "VISA DEBIT POS 0923 SBUX STORE 12345" instead of "Starbucks." Build or integrate a merchant identification service that maps raw transaction strings to clean merchant names, logos, and categories. Plaid, Ntropy, and Heron Data offer merchant enrichment APIs. Building your own requires a large training dataset and ongoing maintenance.

Transaction Categorization

Categorize transactions into standard categories: groceries, dining, transportation, entertainment, utilities, rent, etc. Start with rule-based categorization (merchant name mapping) and add ML-based categorization for ambiguous transactions. Use user feedback (manual re-categorization) as training data to improve accuracy over time.

Recurring Transaction Detection

Identify recurring transactions (subscriptions, rent, salary) by analyzing transaction patterns: similar amounts, regular intervals, consistent merchant names. This powers features like subscription management, cash flow forecasting, and income verification for lending applications.

Data Normalization

Normalize data across banks: convert all amounts to a standard currency representation (cents as integers, not floating-point), standardize date formats to ISO 8601, deduplicate transactions that appear in both pending and posted states, and handle credit versus debit conventions (some banks use positive/negative, others use separate fields). Build comprehensive unit tests for normalization because errors here propagate throughout your application.

Payment initiation is the highest-value open banking feature because it enables Account-to-Account (A2A) transfers that bypass card networks and their 2 to 3% processing fees.

PSD2 Payment Initiation

As a PISP (Payment Initiation Service Provider), you can initiate payments from a user's bank account to a specified beneficiary. The flow: your application submits a payment instruction (amount, beneficiary, reference), the user authenticates with their bank via redirect (SCA required), the bank processes the payment, and you receive a status callback (executed, rejected, pending). The user experience is similar to Apple Pay but uses their bank account directly.

Variable Recurring Payments (VRP)

VRP is the game-changer for subscription businesses. Instead of initiating individual payments each billing cycle, VRP allows pre-authorized recurring payments from bank accounts. The user consents once (with defined limits: maximum amount per payment, maximum cumulative amount, payment frequency), and subsequent payments execute without redirect authentication. UK Open Banking launched VRP for sweeping use cases, with broader commercial VRP expected to expand across the EU.

Payment Status Tracking

Unlike card payments (instant authorization), A2A payments settle through the banking system with variable timing: Faster Payments in the UK settle in seconds, SEPA Instant in the EU settles within 10 seconds, but standard SEPA transfers take 1 to 2 business days. Build a payment status tracking system that polls bank APIs for status updates and notifies your application when payments are confirmed, rejected, or pending.

Merchant Integration

For platforms offering A2A payments to merchants, build checkout SDKs (JavaScript widgets, mobile SDKs) that make bank payment as seamless as card payment. The conversion challenge: users are accustomed to entering card numbers. Bank payment redirects add friction. Minimize clicks and provide clear progress indicators to reduce checkout abandonment.

Open banking platforms handle some of the most sensitive consumer data. Security must be foundational, not an afterthought.

Token Management

Bank API tokens (OAuth access tokens and refresh tokens) must be stored encrypted (AES-256) with access controls limiting which services can use them. Implement token rotation: refresh access tokens before they expire, handle refresh token expiration gracefully (re-consent flow), and revoke tokens immediately when users disconnect accounts. Use AWS KMS or HashiCorp Vault for encryption key management.

Mutual TLS (mTLS)

PSD2 requires eIDAS certificates for secure communication between TPPs (Third Party Providers) and banks. Implement mTLS for all bank API calls using your eIDAS certificate. This adds complexity to your HTTP client configuration but is a regulatory requirement. Manage certificates carefully: track expiration dates, automate renewal, and maintain backup certificates.

Data Minimization

Only request and store the data you actually need. PSD2 requires data minimization, and GDPR reinforces it. If your application only needs account balances, do not request transaction history. If you need transactions for categorization, define a retention policy and delete data after the retention period. Build data deletion workflows that remove all traces of consumer data when they disconnect their accounts.

Penetration Testing

Conduct regular penetration testing (quarterly for production systems). Use both automated scanning (OWASP ZAP, Burp Suite) and manual testing by experienced security researchers. Open banking platforms are high-value targets for attackers, and any breach destroys consumer trust permanently. For API-first platforms, ensure your API security covers authentication, authorization, rate limiting, and input validation comprehensively.

Recommended tech stack for an open banking platform:

• Backend: Node.js with TypeScript (NestJS) or Go for high-performance API services
• Database: PostgreSQL for transactional data, with row-level encryption for sensitive fields
• Token storage: AWS KMS or HashiCorp Vault for encrypted credential management
• Queue: AWS SQS or Kafka for bank API polling, webhook processing, and payment status tracking
• Cache: Redis for balance caching and rate limiting
• Monitoring: Datadog or Grafana for bank API health monitoring, with PagerDuty for alerts
• Frontend: Next.js for developer portal and admin dashboard
• SDK: TypeScript and Python SDKs for API consumers

Timeline

A basic account aggregation platform (5 to 10 bank integrations, consent management, transaction enrichment) takes 5 to 8 months. Adding payment initiation adds 2 to 3 months. Regulatory licensing (PSD2 AISP/PISP) runs in parallel but takes 6 to 12 months. Start with a regulated partner or agent model while your own license application processes.

Getting Started

Build your first integration with a neobank that has a developer-friendly API (Revolut, Monzo, Starling in the UK). These banks have the best sandbox environments and fastest integration cycles. Once your adapter pattern is proven, expand to major retail banks (which have worse APIs but larger customer bases).

We build fintech platforms with secure bank integrations and payment processing. Book a free strategy call to discuss your open banking platform requirements.