Open banking API patterns that ship

Most fintech teams underestimate how much of an open banking API integration is regulatory choreography rather than code. The HTTP calls are trivial. The consent lifecycle, SCA redirects, token refresh windows, and per bank quirks are what push a six week estimate into a two quarter slog.

This is a working engineer's view of the patterns that hold up in production, drawn from what our fintech engineers see when they embed into scale up teams across Europe.

How does open banking work under PSD2?

Open banking works by forcing banks to expose customer account data and payment initiation through regulated APIs, with the customer's explicit consent, to licensed third parties. Under PSD2 in the EU and the equivalent CMA framework in the UK, banks must offer two capability classes: Account Information Services (AIS) and Payment Initiation Services (PIS). Access is gated by Strong Customer Authentication and a signed consent artifact that expires.

The protocol layer is OAuth 2.0 with FAPI profiles, mTLS, and signed request objects. The regulatory layer is where teams get stuck.

Comparing open banking API providers in the UK and EU

There is no single open banking API. There are aggregators such as Tink, TrueLayer, Yapily, and Plaid's European product, and there are direct bank integrations against national standards like the UK Open Banking Standard, Berlin Group NextGenPSD2, STET in France, and Poland's PolishAPI.

A rough decision rule for engineering leaders picking open banking API providers:

• If you need coverage across five or more countries and speed matters more than margin, use an aggregator.
• If you are a licensed AISP or PISP, your unit economics only work with direct integrations at scale.
• If your product is payments led, prioritise providers with strong PIS coverage and refund handling, not just AIS.
• If you operate in the UK only, the UK open banking API ecosystem is mature enough to go direct to the CMA9 without an aggregator.

Most teams start with an aggregator, hit the margin wall around Series B, then rebuild against direct bank integration APIs. Plan for that migration on day one by keeping the provider behind an internal port.

Implementing the payment initiation API: consent flows and token refresh

The open banking payment initiation API is where the sharpest edges live. A payment consent is not a token. It is a resource with its own lifecycle: created, authorised, consumed, expired, revoked. Your state machine needs all five states, plus a sixth for the bank specific limbo state where authorisation succeeds but the payment status endpoint returns pending for hours.

Consent flow patterns that survive audit

Three patterns worth codifying:

1. Persist the consent id and its expiry on creation, not after redirect. Users abandon SCA flows constantly and you need to reconcile.
2. Treat the redirect back from the bank as untrusted. Verify the consent status server side against the bank's API before granting access in your product.
3. Store the exact scope granted, not the scope requested. Banks routinely downgrade AIS scopes and your reads will 403 silently otherwise.

Token refresh edge cases

Access tokens for AIS typically live 5 to 90 minutes. Refresh tokens under PSD2 expire after 90 days for account access, and require a fresh SCA when they do. This is not a bug, it is the regulation.

Build a refresh worker that runs ahead of expiry, not on 401. Track the SCA re authentication deadline per consent and surface it to the user before the refresh fails, or your reconciliation dashboards will fill with stale accounts on day 91.

Bank integration API patterns for embedded fintech teams

When we place engineers into fintech teams, four architecture patterns come up repeatedly.

The provider port. Wrap every aggregator or direct bank integration API behind a single internal interface. Your domain code should never import a vendor SDK directly. This is the migration insurance policy.

The consent aggregate. Model consent as a first class domain aggregate with its own event stream. Payments, account reads, and webhook events all reference a consent id. When regulators ask for evidence of consent at the time of an action, you have it.

Idempotent payment submission. Every payment initiation call needs a client generated idempotency key persisted before the request. Retries on network failure are constant. Duplicate payments are career ending.

Webhook plus poll. Never trust bank webhooks alone. Reconcile with a scheduled poll of the payment status endpoint for anything that has not reached a terminal state within the SLA window. Banks drop webhooks. Auditors ask why you did not notice.

Open banking regulations engineers actually need to know

Engineers do not need to read the full PSD2 text, but a handful of open banking regulations shape the code directly:

• SCA exemptions. Low value, trusted beneficiary, and TRA exemptions change which flows require a redirect. Get this wrong and conversion tanks.
• 90 day re authentication. For AIS, the customer must re authenticate every 90 days. PSD3 and the PSR are relaxing parts of this, but the 90 day rule still applies in most markets in 2025.
• eIDAS certificates. QWAC and QSeal certificates are required to call production bank APIs directly. Sandbox certificates from the aggregator do not work in production.
• Article 32 fallback. Banks must provide a fallback interface if their dedicated API fails. Your monitoring should flag when you hit it, because performance drops sharply.

The European Banking Authority publishes the RTS on SCA and the opinions clarifying it, and they are the closest thing to a canonical engineering spec.

Architecture patterns for shipping compliant banking APIs in weeks

The teams that ship open banking payments in weeks rather than quarters do three things differently.

They scope the first release to a single country and a single flow, usually single immediate payment or account balance read, and refuse to generalise until the second country is live. Premature abstraction across bank standards is the single biggest source of delay.

They put a senior engineer on the consent model on day one. This is the piece that leaks into every other service if you get it wrong, and refactoring it later is a multi month project.

They treat the sandbox as a lie. Sandboxes for banking APIs are notoriously divergent from production. Book production certificate procurement and a real bank pilot into the first sprint, not the last.

A shipping checklist

Before your first production payment:

• Consent aggregate with full state machine and event log
• Idempotency keys persisted before every write
• Refresh worker running ahead of token expiry
• Reconciliation job polling non terminal payments
• eIDAS certificates provisioned and rotation documented
• SCA exemption logic covered by tests per country
• Provider port isolating vendor SDKs from domain code

Where Devspace fits

Most of our fintech engagements start with a team that has an aggregator prototype working and a regulator or investor asking harder questions. We embed senior engineers with prior PSD2 and FAPI experience through our remote development team service, typically alongside the client's existing lead, in two to four weeks.

The pattern that ships is not more people. It is the right consent model, the right provider abstraction, and a senior engineer who has already debugged token refresh at 3am against a bank sandbox that lied. Everything else is prose around those three.