Open finance vs open banking: what changes for your API platform

Your open banking stack was built for one job. It exposes payment accounts to licensed third parties, it knows one kind of caller, and its consent check asks one question: does this TPP hold a valid consent for this account? Then a memo says the next regime covers savings, investments, pensions, insurance and credit. The question on the platform team's desk is open finance vs open banking: is this five more API sets on the same gateway, or a different platform?

For most banks it is closer to the second. Open finance multiplies four things: the data domains you expose, the backend systems behind them, the participant types calling you, and the granularity of the consent you honor on every request. A gateway built around one PSD2 surface absorbs the first new domain. By the third, the cracks show in access scoping, consent logic and evidence.

Open finance vs open banking: what multiplies

Ask what the difference between open finance and open banking is for banks, and the regulatory answer is scope. The engineering answer is cardinality. PSD2-style open banking was one API domain, payment accounts, served to one class of caller, licensed third party providers. Open finance turns each singular into a list.

Data domains come first. As proposed in 2023, the EU's Financial Data Access Regulation (FiDA) would cover mortgages, loans, savings, investments, insurance-based investment products, crypto-assets, pension rights, non-life insurance and firm creditworthiness data, and would leave payment accounts to PSD2; negotiators have since moved toward a narrower, phased scope. Each domain has its own data model and its own line between shareable customer data and proprietary material such as pricing logic and risk scores.

Backend systems follow. Payment account data comes from core banking. A pension summary comes from a pension administration system, an investment position from a custody platform, a motor policy from a policy administration system, each with its own credentials and failure modes.

Participant types widen. The FiDA proposal's in-scope entities would run from credit institutions to investment firms, insurers, intermediaries and occupational pension providers, and the proposal would create a new license for financial information service providers (FISPs).

Consent granularity is the fourth multiplier. Open finance regimes expect consent that is purpose-specific, visible to the customer and revocable through the data holder. FiDA proposes a permission dashboard listing each data user, purpose, data category and duration; Brazil requires consent to name the specific data shared. The request-path question becomes "does this consent cover this domain, this data category and this purpose, right now".

Where the regimes stand in October 2026

EU: FiDA was proposed in June 2023; the European Parliament's Legislative Train lists it as blocked as of September 2026, with no provisional agreement. An April 2026 Commission non-paper sketched phased third-party access, starting with consumer credit, accounts, savings and motor insurance.
UK: the Data (Use and Access) Act 2025 enables smart data schemes, and the FCA's April 2026 roadmap names SME lending and mortgages as first open finance priorities.
Brazil: investments, insurance and pensions were in scope from 2020, and the regime was renamed Open Finance in 2022.
UAE: the Central Bank's Open Finance Regulation is cross-sectoral from the outset, with banks and insurers onboarded first through a central API Hub. See our UAE breakdown.
Saudi Arabia: SAMA's Open Banking Framework started with account information services, the payment initiation release was announced in September 2024, and fintech licensing began in March 2026, with no central traffic hub. See our Saudi open banking post.
Australia: the Consumer Data Right runs in banking and energy and is extending to non-bank lenders through 2026 and 2027.

The common thread is phasing. Regimes switch on data sharing in stages, usually domain by domain (Brazil's four phases, FiDA's sketched three) and sometimes by participant type or size (the UAE's banks and insurers first, Australia's larger non-bank lenders first). The platform must add a domain or participant class without reworking the live ones.

Why gateways built for one PSD2 surface strain

Most open banking API platforms were built as one API product with one consumer class. In Apigee that is an API product and a developer app per TPP; in Azure API Management, a product and a subscription; in AWS API Gateway, a usage plan and an API key; in Kong, a consumer with a plugin chain per route. All of these model one surface well. The strain comes with participant-by-domain scoping across many products, plus logic spanning several backends.

Aggregation is the first pressure point. A retirement summary needs pension and investment data combined and trimmed. On most stacks that work moves elsewhere: Lambda functions behind AWS API Gateway, policy code in Apigee and Azure, or an integration tier such as MuleSoft. Consent checks drift into a sidecar or a custom plugin. Each choice is defensible alone. When that work lands in Lambda functions, an integration tier or a consent sidecar, access, consent and data shaping end up in three places with three sets of logs.

Evidence is the second. When an examiner asks which participants could reach pension data last quarter, the answer should come from one place, not a spreadsheet stitched from per-domain gateways.

Structuring an open finance estate on Zerq

Zerq maps onto the four multipliers: collections for domains, each collection's Target Endpoint and Credentials for backends, clients and profiles for participants, and workflows for consent-shaped checks, with one observability and audit layer across them. The object model is on the capabilities page.

The architecture, end to end

A participant's call reaches your ingress, which terminates TLS, handles the client certificate, and forwards to the Zerq gateway with X-Client-ID, X-Profile-ID and the bearer token. The gateway first applies the client's policy, keyed on X-Client-ID (429), then authenticates the credential (401), checks the profile's IP allowlist (403) and allowed methods (405), and matches the path to one of the client's collections (404), all before any proxy or workflow runs.

For mtls profiles the gateway does not check the certificate itself, so the ingress must set X-Client-ID and X-Profile-ID from the validated certificate and overwrite any caller-supplied values, including the forwarded certificate header that RFC 8705 checks rely on. For every profile type, the ingress should also strip any caller-sent X-Proxy-ID header, which Zerq treats as a test-console call and leaves out of request logs. The gateway must be reachable only through that ingress.

Behind the gateway sits one collection per data domain: /accounts, /savings, /investments, /pensions, /insurance, /credit. Each has its own Target Endpoint and Credentials for that domain's system of record, so no two backends share a secret. Proxies that need more than forwarding carry a workflow that calls your consent service and, where needed, several backends. Requests land in the request logs tagged with collection, client ID and profile ID; configuration changes land in the audit log. See the architecture page.

Two things stay outside Zerq. It has no consent store, so the permission dashboard, purpose records and revocation live in your systems and the gateway calls them. Tokens come from your authorization server; oidc profiles can require RFC 8705 certificate-bound tokens, which Zerq checks against the forwarded client certificate. DPoP is not supported. See security.

One collection per data domain

Give each domain its own collection with a unique Base Path. If the scheme publishes its open finance API specs in OpenAPI 3.0 or 3.1, Import from OpenAPI builds the proxies in draft. Draft makes phasing workable: a pensions collection can be built and tested while unreachable through the gateway and hidden in the Developer Portal. When the phase opens, publish the proxies, then the collection.

Clients per participant, scoped by collection

Every participant becomes a client, and a client can only call endpoints in its assigned collections. Two participants, summarized as management UI settings (not an import format):

# One collection per data domain, each with its own backend
collections:
  - name: accounts       # base_path: /accounts    status: published
  - name: savings        # base_path: /savings     status: published
  - name: insurance      # base_path: /insurance   status: published
  - name: pensions       # base_path: /pensions    status: draft (next phase)

# Participant 1: account aggregator, licensed for banking data only
client:
  name: tpp-aggregator-017
  collections: [accounts, savings]   # insurance and pensions are unreachable
  policy: of-standard                # one bucket across all its profiles
  profiles:
    - name: production
      auth_type: oidc                # tokens from your authorization server
      requireCertificateBoundToken: true   # RFC 8705, set via API or MCP
      allowed_methods: [GET]
      # leave IP restrictions empty: Zerq sees the ingress address;
      # enforce egress ranges at the ingress

# Participant 2: insurance comparison data user
client:
  name: du-insurance-compare-004
  collections: [insurance]           # pensions added when that phase opens
  policy: of-standard
  profiles:
    - name: production
      auth_type: mtls                # ingress validates the cert and sets X-Client-ID/X-Profile-ID from it;
                                     # the ingress also sets a non-empty Authorization header
      allowed_methods: [GET]

Three details matter. Allowed methods sit on the profile and apply to every collection the client reaches, so a read-only domain gets its boundary on the proxies: define insurance proxies with GET only. Policies cover all of a client's active profiles combined, so a second profile does not double an allowance. And requireCertificateBoundToken is set through the management API or MCP. When a license extends to a new domain, adding the collection to the client takes effect on the next request and is recorded in the audit log.

For the steps behind each participant client, from register check to certificate-bound production profile, see our TPP onboarding guide.

Workflows for aggregation and consent-shaped checks

Where a response needs more than one backend, or a consent check finer than "this client may call this collection", attach a workflow to the proxy with Edit Workflow. A retirement summary for a data user:

http_trigger
  -> http_request_node   consent service: permission for this data user,
                         domains "pensions" and "investments", purpose, expiry
  -> condition_node      permission active and covers these categories?
       denied  -> response_node   403 with a machine-readable reason
       allowed -> parallel_node
                    -> http_request_node   pension administration system
                    -> http_request_node   investment platform
                  -> merge_node
                  -> set_node        keep shareable fields, drop risk scores
                  -> response_node   200

An aggregating proxy sits in one collection but reads another domain's backend, so its workflow must check the permission for every domain it returns. Collection scoping only covers the collection the proxy lives in.

Workflows fit because the consent question changes per domain, and each check lives on its own proxy rather than in one shared plugin. See the workflow orchestration use case.

Per-domain observability and one audit trail

Because domains are collections, the dashboard's Collection filter gives each domain its own view: Total Requests, Success Rate, Avg Response Time and Error Count. When pension calls slow while accounts stay healthy, you know which backend to look at. Request logs filter by Collection, Client ID, Profile ID and status code, so a spike of 403s from one data user in one domain takes three filters: Client ID, Collection and status 403. More on observability.

The audit log is the other half. Configuration changes are recorded with Actor ID, Action, Resource type and the management URL, which carries the resource ID, and only the Auditor role can view them, so the people who review changes cannot make them (the shipped config also maps admin into OIDC_AUDITOR_ROLES; remove it for strict separation). The audit log shows who changed access and when; request logs show what the gateway enforced on each call. Where a regime allows access charges, as FiDA's capped compensation would, export request logs to your billing pipeline and group them by client and collection there.

What this looks like in practice

Consider a banking group with a bank, an insurer and an asset manager that runs open banking on a PSD2-era gateway with a consent sidecar, while the insurer runs its own gateway. Its first open finance draft has three gateways, three partner registers and consent logic in two codebases.

Consolidated onto one Zerq deployment per environment, each domain becomes a collection with its own backend and credential, pensions sitting in draft until its phase, and each participant becomes a client scoped to its license. Consent stays in the group's own consent store, called from workflows. Adding savings then takes an OpenAPI import, a credential, a publish, and a client update.

Before consolidation, answering which participants can reach insurance data, and who granted it, would take exports from three systems. After it, the answer comes from the insurance collection's Access tab and the audit log filtered by resource type.

An open finance readiness checklist

List every in-scope data domain and the system of record behind it.
Per domain, separate shareable customer data from proprietary or derived fields, and strip the latter.
Map every participant type to clients and derive each client's collections from its license.
Decide where consent and the permission dashboard live, and which attributes the gateway checks per request: domain, data category, purpose, expiry.
Confirm your sender-constraint requirement: RFC 8705 certificate-bound tokens work on oidc profiles; DPoP does not. Oidc profiles verify RS256-family JWT access tokens, not PS256, ES256 or opaque tokens, so test one of your authorization server's tokens first.
Keep sandbox traffic away from production data: use a separate non-production deployment, or the ingress host split in our TPP onboarding guide, where the sandbox host forwards only /sandbox and is rate-limited at the ingress. Every profile on a client shares its collections and one policy bucket, so without that split a sandbox profile on a production client reaches every collection the client holds.
Set GATEWAY_ENABLE_CACHE=false: the shipped default caches GET responses ahead of auth, consent workflows and logging.
Build each new domain as a draft collection and publish it on the phase date.
Watch 401, 403, 404, 405 and 5xx in request logs, with alerting in your existing tooling. Gateway rejections carry the Client ID but no collection, so per-domain views cover workflow and backend responses. Count 429s per client at the ingress: policy rejections are not request-logged, and policies apply per client, not per domain.
Give compliance the Auditor role, and enforce audit and request log retention in your MongoDB and SIEM to your regulator's expectation.

The short version

Open finance vs open banking is less about endpoint count than about the dimensions your gateway keeps straight: domains, backends, participants and consent. Model each domain as a collection and each participant as a scoped client, put aggregation and consent-shaped checks in per-proxy workflows, and keep observability and audit in one place, so each new phase adds collections, client scopes and workflows on the same gateway instead of standing up another one. For the banking patterns underneath, see the open banking use case.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.