PSD2 and Open Banking Integration: A Developer's Field Guide

Notice the extra steps in the UK flow: client credentials grant first, consent resource creation, signed JWT request object for the redirect. It's more work but it's also more secure and more standardized.

Token lifecycles are aggressively short. Access tokens typically live 600 seconds (10 minutes) in FAPI implementations. Build your token management around frequent refresh. And AIS consents expire after a maximum 90 days - after which the user must re-authenticate entirely. Build re-auth flows as a first-class UX concern, not an afterthought.

Integration Walkthrough: From Zero to First API Call

Here's the actual sequence you'll follow. I'll be specific about what costs time.

Step 1: NCA Authorization

Submit an application to your National Competent Authority. AISP registration is lighter (no capital requirement). PISP authorization requires minimum €50,000 capital plus a lot more paperwork - business model documentation, data privacy controls, governance structures, financial stability evidence, integrity checks on directors.

Timeline: weeks to months depending on the NCA. The FCA is relatively fast. BaFin is... not. Factor this into project timelines. Your engineering work is blocked until authorization is granted because you need the authorization number for your eIDAS certificates.

Step 2: Obtain eIDAS Certificates

Generate RSA key pairs, create CSRs with PSD2 OIDs, submit to a QTSP, wait for validation.

Your organizationIdentifier encodes your authorization: PSDGB-FCA-123456 for a UK FCA-authorized firm, PSDDE-BAFIN-654321 for a German BaFin-authorized firm, etc.

Store private keys in an HSM. Not in a file on disk. Not in a Kubernetes secret. In an actual hardware security module. More on this in the hosting section.

Step 3: Directory Enrollment (UK)

UK-specific. Register with the Open Banking Directory, create Software Statements, upload certificates, generate Software Statement Assertions (SSAs). The Directory provides JWKS endpoints, OCSP for revocation checking, and APIs for discovering enrolled ASPSPs.

Step 4: Dynamic Client Registration

For each bank you want to connect to, you perform DCR:

1. Query their OIDC discovery endpoint: GET /.well-known/openid-configuration
2. Construct and sign a registration JWT containing the SSA (UK) or eIDAS cert (EU)
3. POST it to the bank's registration endpoint over mTLS

# Example DCR call
curl -X POST https://api.bank.com/register \
  --key qwac.key \
  --cert qwac.crt \
  -H 'Content-Type: application/jose' \
  -d 'eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InF3YWMta2V5LTEifQ...'

The response gives you OAuth client credentials (client_id, maybe client_secret), confirmed redirect URIs, and authorized scopes. You repeat this for every bank. If you're connecting to 50 banks, that's 50 DCR registrations, each potentially failing in different ways.

Step 5: Consent and Data Access

Now you can actually make API calls. Here's a full Berlin Group AIS integration in Python:

import requests
import uuid

# Configure mTLS session
session = requests.Session()
session.cert = ('qwac.crt', 'qwac.key')
session.verify = True  # verify bank's server cert

BASE_URL = 'https://xs2a.bank.com'

# 1. Create consent
consent_response = session.post(
    f'{BASE_URL}/v1/consents',
    headers={
        'Content-Type': 'application/json',
        'X-Request-ID': str(uuid.uuid4()),
        'PSU-IP-Address': '192.168.8.78',
        'TPP-Redirect-URI': 'https://your-tpp.com/callback',
        'TPP-Nok-Redirect-URI': 'https://your-tpp.com/callback/error',
    },
    json={
        'access': {
            'accounts': [{'iban': 'DE89370400440532013000'}],
            'balances': [{'iban': 'DE89370400440532013000'}],
            'transactions': [{'iban': 'DE89370400440532013000'}],
        },
        'recurringIndicator': True,
        'validUntil': '2021-06-30',
        'frequencyPerDay': 4,
    }
)

consent = consent_response.json()
consent_id = consent['consentId']
sca_redirect = consent['_links']['scaRedirect']['href']

print(f'Redirect user to: {sca_redirect}')
# User authenticates at bank, gets redirected back with auth code

# 2. Exchange auth code for tokens
token_response = session.post(
    f'{BASE_URL}/oauth/token',
    data={
        'grant_type': 'authorization_code',
        'code': 'AUTH_CODE_FROM_CALLBACK',
        'redirect_uri': 'https://your-tpp.com/callback',
    }
)
tokens = token_response.json()

# 3. Fetch accounts
accounts_response = session.get(
    f'{BASE_URL}/v1/accounts',
    headers={
        'Authorization': f'Bearer {tokens["access_token"]}',
        'X-Request-ID': str(uuid.uuid4()),
        'Consent-ID': consent_id,
    }
)
accounts = accounts_response.json()

# 4. Fetch transactions for first account
account_id = accounts['accounts'][0]['resourceId']
txn_response = session.get(
    f'{BASE_URL}/v1/accounts/{account_id}/transactions',
    headers={
        'Authorization': f'Bearer {tokens["access_token"]}',
        'X-Request-ID': str(uuid.uuid4()),
        'Consent-ID': consent_id,
    },
    params={
        'dateFrom': '2020-01-01',
        'dateTo': '2020-12-31',
        'bookingStatus': 'booked',
    }
)
transactions = txn_response.json()

And the equivalent in Go for those of us who prefer it:

package main

import (
    "bytes"
    "crypto/tls"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "net/http"

    "github.com/google/uuid"
)

type ConsentRequest struct {
    Access             Access `json:"access"`
    RecurringIndicator bool   `json:"recurringIndicator"`
    ValidUntil         string `json:"validUntil"`
    FrequencyPerDay    int    `json:"frequencyPerDay"`
}

type Access struct {
    Accounts     []AccountRef `json:"accounts"`
    Balances     []AccountRef `json:"balances"`
    Transactions []AccountRef `json:"transactions"`
}

type AccountRef struct {
    IBAN string `json:"iban"`
}

func newMTLSClient(certFile, keyFile string) (*http.Client, error) {
    cert, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        return nil, fmt.Errorf("load eIDAS cert: %w", err)
    }
    return &http.Client{
        Transport: &http.Transport{
            TLSClientConfig: &tls.Config{
                Certificates: []tls.Certificate{cert},
                MinVersion:   tls.VersionTLS12,
            },
        },
    }, nil
}

func createConsent(client *http.Client, baseURL, iban string) (string, string, error) {
    req := ConsentRequest{
        Access: Access{
            Accounts:     []AccountRef{{IBAN: iban}},
            Balances:     []AccountRef{{IBAN: iban}},
            Transactions: []AccountRef{{IBAN: iban}},
        },
        RecurringIndicator: true,
        ValidUntil:         "2021-06-30",
        FrequencyPerDay:    4,
    }

    body, _ := json.Marshal(req)
    httpReq, _ := http.NewRequest("POST", baseURL+"/v1/consents", bytes.NewReader(body))
    httpReq.Header.Set("Content-Type", "application/json")
    httpReq.Header.Set("X-Request-ID", uuid.New().String())
    httpReq.Header.Set("PSU-IP-Address", "192.168.8.78")
    httpReq.Header.Set("TPP-Redirect-URI", "https://your-tpp.com/callback")

    resp, err := client.Do(httpReq)
    if err != nil {
        return "", "", fmt.Errorf("consent request: %w", err)
    }
    defer resp.Body.Close()

    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)

    consentID := result["consentId"].(string)
    links := result["_links"].(map[string]interface{})
    scaRedirect := links["scaRedirect"].(map[string]interface{})["href"].(string)

    return consentID, scaRedirect, nil
}

Berlin Group also requires HTTP Signature headers for request signing with your QSeal certificate. You'll need Digest (SHA-256 of request body), Signature (computed using QSeal), and TPP-Signature-Certificate (base64 QSeal cert). Not every bank enforces this in practice, but it's in the spec and the compliant ones will reject you without it.

Hosting and Deployment: Infrastructure for Regulated Fintech

Now the part most PSD2 guides skip entirely: actually running this thing in production. You're dealing with regulated financial infrastructure. The bar is higher than your average SaaS deployment.

Reference Architecture

I run this on Kubernetes (EKS in my case, but GKE or self-managed works fine). The key architectural decisions:

Separate the bank adapter layer. Each API standard (Berlin Group, STET, OB UK, PolishAPI) gets its own adapter service that translates between your internal canonical model and the bank-specific API. This is where most of the per-bank customization lives. I use a Go service for this because the HTTP client configuration (mTLS, custom headers, cert-bound tokens) is much cleaner in Go than in Java's HttpClient.

Consent management is its own service. Consent states (AwaitingAuthorisation, Authorised, Rejected, Revoked, Expired), expiry tracking, 90-day re-auth scheduling, and rate limiting (4 requests/day cap) - this gets complex enough to warrant isolation. PostgreSQL backend with advisory locks for concurrent consent state transitions.

Async everything from the bank adapter outward. Bank APIs are unreliable. Timeouts, 5xx errors, rate limits - you don't want synchronous request chains. I use NATS JetStream (or Kafka if you prefer) for bank API events, retry queues, and webhook delivery. Bank adapter → NATS → consumer services → PostgreSQL.

Audit logging is not optional. PSD2 requires you to demonstrate what data you accessed, when, with what consent, for how long. Every bank API call gets logged to an append-only audit table: timestamp, consent ID, bank, endpoint, response code, data hash (not the data itself). PostgreSQL with SERIALIZABLE isolation on the audit table.

Private Key Management

Do not store eIDAS private keys in Kubernetes secrets. Do not store them in environment variables. Do not store them in a file on disk with chmod 600 and call it a day. Auditors will find it. Regulators will not be amused.

Hardware Security Modules are the gold standard:

For the signing operations (QSeal → HTTP Signature / JWS), you can use a PKCS#11 interface to the HSM from your Go/Java services. Performance isn't an issue - you're signing a few hundred requests per second at most, not doing bulk crypto.

If you're a startup and HSM costs are prohibitive, the QTSP remote signing service is a viable bridge. You call their API, they sign with your key held in their HSM, you get the signature back. Latency adds ~50ms per request but for PSD2 API calls that's noise.

API Gateway Selection

Your gateway needs to handle mTLS, OAuth 2.0 token validation, and eIDAS certificate attribute parsing. This rules out lightweight proxies like Nginx (without significant Lua scripting).

I use Kong with a custom Lua plugin that extracts organizationIdentifier and QCStatement OIDs from the client certificate and adds them as upstream headers. The adapter services then validate the TPP role against the requested endpoint without re-parsing the certificate.

GDPR Intersection

PSD2 and GDPR create a Venn diagram of overlapping and sometimes conflicting requirements.

PSD2 consent (user authorizes account access) and GDPR consent (legal basis for data processing) are different legal mechanisms. PSD2 access typically relies on GDPR's "contractual necessity" or "legitimate interest" basis, not GDPR consent. You need both, but they're separate.

Data minimization: request only the permissions you actually need. If you only need balances, don't request ReadTransactionsDetail just because you can.

Data retention creates tension: AML rules want 5+ years of records, GDPR deletion rights pull the other direction. I keep financial data in hot storage for the consent duration plus 90 days, then archive to encrypted cold storage with restricted access for the AML retention period.

Cross-border hosting: keep data within the EU/EEA. If you're using AWS, eu-west-1 or eu-central-1. Standard Contractual Clauses if you must use non-EU hosting. Don't make this harder than it needs to be.

Aggregator Platforms: The Middleware That Makes PSD2 Usable

The fragmentation described above created an entire industry of platforms that absorb the complexity and expose a unified API. For most developers, this is the practical path to production. I'll cover each one with technical specifics.

Tink

Swedish. Connected to 3,400+ European banks through a single API covering AIS and PIS. By August 2019, Tink had 110+ engineers working full-time on PSD2 integration, racing to connect 100+ bank APIs covering ~90% of the European population before the September deadline. That effort is instructive - if a company with 110 engineers found it a massive undertaking, imagine doing it with a team of 3.

Tink's differentiator is data enrichment: transaction categorization, spending analysis, income detection, financial insights built on top of raw PSD2 data. Their Tink Link widget provides a pre-built bank selection and authentication UI that you embed in your application. Useful for prototyping and MVPs, but you'll want your own UX for production.

TrueLayer

London-based. Licensed as both AISP and PISP. Connects to 98% of UK banks and 95%+ of European bank accounts entirely through APIs - no screen scraping. They provide SDKs for JavaScript, Python, Java, and .NET, with webhook notifications for payment status rather than polling.

If your primary use case is account-to-account payments for e-commerce checkout, crypto exchanges, or investment platforms, TrueLayer is strong. Pricing is transaction-based, typically 0.3–1.5% depending on volume.

Yapily

Pure infrastructure play. ~2,000 banks, 19 European countries, direct API connections with no intermediary layers. The key differentiator is white-label flexibility - Yapily doesn't impose rigid workflows. You build fully customized user journeys. They also let enterprises operate under Yapily's regulatory license without obtaining their own - useful if your NCA authorization is still in progress.

If I were building a deeply customized single-market integration where UX control matters, Yapily would be my first call.

Token.io

Infrastructure "plumbing" rather than a consumer-facing product. Selected by Mastercard to power its open banking connectivity hub. Their TokenOS platform processes $150 billion+ in annualized transaction volume and was the first PISP to complete testing with all CMA9 banks. Bank clients include HSBC (Open Payments), BNP Paribas (Instanea), and Santander.

Token.io is what you use when you need bank-grade reliability and your counterparties are enterprise banks that need assurance from a Mastercard-backed provider.

Nordigen

The disruptor. Launched a free-tier model for account data. Their logic: PSD2 mandates free API access from banks, so the underlying cost approaches zero. The incumbents charge because they built expensive screen-scraping infrastructure. Nordigen connects only to regulated PSD2 APIs - no screen scraping, no credential storage.

Free tier: account information (balances, transactions, account holder details), 90-day recurring consent, 4x daily background refresh, 2,300+ European banks. Revenue comes from premium features: ML transaction categorization, credit scoring, financial insights, enterprise support.

If you're a startup or indie developer prototyping a European fintech product, Nordigen is the path of least resistance. Sign up, get an API key, connect to a sandbox, and you're querying bank accounts within an hour. The data quality is only as good as the underlying bank APIs (which varies), but for prototyping and small-scale production, it works.

Salt Edge

Uniquely serves both sides: their Open Banking Gateway (Priora) provides PSD2 connections for TPPs, while simultaneously helping banks deploy PSD2-compliant APIs. 3,100+ financial institutions across 61 countries. They use a hybrid approach - PSD2 API connections where available, screen scraping where not.

Salt Edge also publishes some of the best technical analysis of eIDAS certificate challenges. If you're debugging certificate renewal across multiple banks, their blog posts are worth reading.

Direct vs. Aggregator Decision Matrix

My recommendation for most teams: start with an aggregator, go direct for high-volume single-bank integrations. The operational burden of managing eIDAS certificates, handling bank-specific quirks, and keeping up with spec changes across four standards is not something a small team should take on unless the economics of per-transaction fees don't work at your scale.

What Actually Goes Wrong: Field Notes from Production

This section is the one I wish I'd had before I started. These aren't theoretical concerns - they're what I've hit in production, what aggregator engineering teams have documented publicly, and what the PSD2 developer community collectively curses about.

Bank sandboxes are broken. Tink spent three months testing over 100 bank sandboxes before September 2019 and concluded: the APIs are "far from ready." A large number of banks completely faked authentication steps, making it impossible to test the actual end-user journey. Sandbox environments were often built by different teams than production - integrations that worked in sandbox broke in production. Enable Banking's country assessment found Finnish sandboxes were "pretty good" but Baltic banks were "quite limited in functionality with quite many omissions making them quite far from their live counterparts." I've had banks where the sandbox URL wasn't documented anywhere - I had to email their developer support (which took 3 weeks to respond) to get it.

Every bank is a unique snowflake, even within the same standard. Berlin Group v1.3.6 is a spec. Banks interpret it. Differently. Date formats vary. Optional fields appear or disappear. Error codes are inconsistent. Documentation is sometimes local-language only. Tink's engineering team described it as "thousands of interpretations" producing "a big old mess." A clean bank API takes 2–4 days to integrate. Most take around two weeks. Some never quite work right.

SCA redirect flows are a UX nightmare. Start in your app → redirect to bank → two-factor auth → redirect back. On desktop it's tolerable. On mobile it's a disaster: browser-to-app handoffs fail, banks' mobile apps don't handle incoming auth requests correctly, users get stuck in redirect loops. Each bank has different timeout durations and error handling. I've seen redirect URIs break because the bank URL-encodes query parameters differently from the spec.

The 90-day re-authentication wall. RTS Article 10: banks may optionally exempt AIS access from SCA for 90 days, after which re-auth is mandatory. "Optionally" - some banks apply it, some don't, some use shorter intervals. For an app aggregating data from 5 banks, users face staggered re-auth prompts. Your background data refresh (4x/day per consent) just stops working on day 91 if you don't handle this. Build re-auth scheduling into your consent manager. Track per-bank, per-consent expiry. Notify users before expiry, not after.

Certificate renewal will ruin your week. Salt Edge documented this across 49 European banks. Results: 26 banks required manual developer portal login for renewal. 5 required creating entirely new applications - invalidating ALL existing user consents. 6 required new DCR with different client names. 11 had no documented renewal process at all. There are no EU-level guidelines on renewal procedures. Every bank does it differently.

My mitigation: I run a certificate renewal tracking table in PostgreSQL with per-bank renewal procedures documented as runbooks, 30-day advance alerting, and automated DCR re-registration where the bank supports it. Manual for the rest. It's ugly but it works.

PSD2 mandates the bare minimum of data. Basic account details, balances, transaction history. No spending categories, no merchant identification, no income classification, no investment holdings. If you're building anything beyond a basic account viewer, you'll need to enrich the data yourself or use an aggregator that does it for you. The regulation created access to raw plumbing, not finished products.

Conclusion

PSD2 is simultaneously one of the most important pieces of financial regulation in European history and one of the worst-executed technical mandates I've encountered. The regulatory intent was sound: break the bank monopoly on account data, enable innovation, protect consumers with strong authentication. The implementation - four competing standards, thousands of inconsistent bank APIs, operationally nightmarish certificate management, and sandboxes that don't reflect production - has created a full-employment program for fintech middleware companies and a lot of suffering for individual developers.

The structural lesson is clear: standardization requires an implementation body, not just legislation. The UK's OBIE-driven approach produced materially better APIs than the EU's "technology-neutral" approach. This isn't a subtle difference - it's the difference between integrating a bank in 2 days versus 2 weeks.

If you're building in this space today, my practical advice:

Use an aggregator for multi-market coverage unless you have a dedicated fintech engineering team of 5+. For single-market deep integrations with specific banks, go direct. Invest heavily in error handling and retry logic - bank APIs are unreliable in ways you haven't yet imagined. Build consent re-authentication as a first-class UX flow. Treat eIDAS certificate lifecycle management as critical infrastructure. And budget 3x the integration time you think you need.

The infrastructure is messy. The standards are fragmented. The bank APIs are frequently terrible. But the underlying capability - programmatic access to bank account data and payment initiation across 31 countries - is genuinely transformative. We're building on a shaky foundation, but we're building.