Open Banking APIs: How to Expose Payment & Account Data Without Losing Control

Open banking mandates that banks expose customer account and payment data to authorised third-party providers (TPPs).

What it does not mandate is how you expose it — and the gap between a compliant API and a well-governed one is where most banking teams get into trouble.

The problem is not technical. Every major bank can serve an HTTP endpoint. The problem is control: knowing exactly who is calling which endpoint, on behalf of which consent, under which contractual terms, and being able to prove all of that when a regulator, auditor, or incident response team asks.

This is the architecture that gives you both.

The control surface you need before any TPP calls hit your core

An open banking API gateway is not just a reverse proxy in front of your account and payment services. It is a policy enforcement layer that must handle several distinct concerns before a request is allowed through:

mTLS for TPP identity verification. TPPs are licensed entities. Under eIDAS and the FAPI security profile, they present a qualified certificate issued by a QTSP (Qualified Trust Service Provider). Your gateway must validate that certificate — confirming it is issued by a trusted CA, has not been revoked, and matches the TPP's registered identity. A bearer token alone is not sufficient for high-assurance payment flows.

OAuth 2.0 / OIDC token validation with consent binding. Every access token must be validated against your authorisation server. The validation must confirm not just that the token is valid, but that the scope matches the requested resource and that the underlying consent is active. A token issued for read access to account information cannot be used for payment initiation, even if the token is technically valid.

Consent lifecycle management. Consent is not a one-time event. It has a validity window. It can be revoked by the customer at any time. It specifies which accounts, which data types, and which operations are permitted. Your gateway needs to check consent state on every request — not cache it indefinitely and assume it is still valid.

Per-TPP access control and rate limiting. Different TPPs have different authorisations. A PFM app has read access to account balances and transactions. A payment initiation service provider has the right to submit payment instructions but not to read account history. A data aggregator may be authorised for a limited set of account types.

Rate limits must be per-TPP, not global. A single high-volume aggregator consuming your entire API capacity harms every other TPP — which is exactly the discriminatory access problem open banking regulation is designed to prevent.

The audit trail regulators actually ask for

When a regulator investigates a complaint from a TPP — or when a customer disputes a payment initiated through a third party — you will be asked to produce a detailed record of what happened.

The record they need:

Which TPP made the request, identified by certificate subject and licence number
Which customer's consent authorised the access
Which account or payment resource was accessed
What operation was performed (read, initiate, confirm)
The exact timestamp
Whether the consent was valid at the time of the request
Whether the request was approved or rejected, and why

This is not a report you can generate from application logs after the fact. It requires that the gateway captures structured, queryable data at request time — not aggregated metrics, but per-request records that can be filtered by TPP, consent, account, and time window.

If your current logging infrastructure requires a data warehouse join to answer "show me all payment initiations by this TPP in March," you do not have a compliant audit trail.

Separation of concerns: what lives in the gateway vs what lives in the core

A mistake common in open banking implementations is letting the core banking system shoulder compliance responsibilities that belong in the gateway layer.

The gateway owns:

Certificate validation and mTLS termination
Token validation and consent state checking
Access control policy enforcement (which TPP can call which endpoint)
Per-TPP rate limiting
Audit logging at the request level
Request and response transformation (normalising error codes, stripping internal fields)

The core banking system owns:

Business logic — executing the payment, returning the account balance
Data — the authoritative record of accounts and transactions

This separation matters for a practical reason: when the regulatory standard changes (and it will — FAPI 2.0, new SCA requirements, revised consent frameworks), you update the gateway layer. You do not touch the core. Teams that build compliance logic into their core banking integration are rebuilding from scratch with every regulatory revision.

What happens when a TPP is revoked

TPP licences are revoked. It happens. A payment provider loses its authorisation. A data aggregator is sanctioned. An eIDAS certificate expires or is revoked by the QTSP.

Your gateway needs to handle this in real time.

When a TPP licence is revoked by the national competent authority, your gateway should be able to block all traffic from that TPP immediately — without a deployment, without an engineering ticket, and without waiting for a certificate to expire. This means your access control model must include a TPP blocklist that can be updated through your gateway's admin interface and takes effect on the next request.

When a certificate is revoked, your OCSP or CRL check at the gateway catches it. This only works if your gateway performs live certificate validation — not just signature verification at connection time and nothing more.

Sandbox and production: same controls, different data

TPPs develop and test against a sandbox before they go live. The sandbox should use the same authentication, consent, and access control flows as production. Not a simplified mock — the same enforcement logic, with synthetic data.

Why it matters: TPPs that test against a sandbox with relaxed authentication discover real security problems in production. The consent flow that works fine in the sandbox fails in production because the SCA redirect behaves differently. The certificate validation that is skipped in the sandbox fails in production because the QTSP certificate chain is different.

Same gateway, same enforcement, separate data environments. That is the model.

The operational picture: knowing what is happening across your TPP estate

Once you are live with open banking, you need ongoing visibility into what is happening. Not just "are the APIs up" — but:

Which TPPs are active and what volume are they generating?
Are any TPPs approaching their rate limits?
Are there consent validation failures — and if so, are they the TPP's fault or yours?
Are there patterns of requests that look like credential stuffing or scraping beyond what consent covers?
Which TPP integrations are failing with 4xx errors, and why?

This requires observability at the TPP level, not just aggregate gateway metrics. Your monitoring dashboard should let you filter by TPP, product, and time window — and alert on anomalies per TPP, not just when global error rates cross a threshold.

Zerq handles mTLS certificate validation, per-TPP access control, consent-aware token enforcement, per-request audit logging, and self-service TPP onboarding through the developer portal. See the open banking use case or request a demo to walk through your open banking API control architecture.