API management for financial services

Why API management for financial services is a regulated function

A bank, payment provider or fintech that must expose APIs to third parties is answering to regulators and partners in the same breath. The API gateway sits directly on regulated data paths: it terminates customer-facing and partner traffic, enforces who may call what, and records the evidence of that enforcement. That makes its security, its availability and the documentation of the software and vendors behind it examined as controls, not treated as plumbing. Under DORA, for example, every ICT services contract must state where services are provided and data processed, and an exit strategy must be documented and tested for services that support critical or important functions.

The short answer on platforms is that Apache APISIX or Kong Gateway is the usual self-hosted gateway layer, with Keycloak commonly handling identity, OAuth 2.0 and OpenID Connect for both staff and third-party clients. Both gateways are licensed under Apache-2.0, and both can run inside your own cloud accounts or data centers. The choice between them should not be made on preference. It should be made against a written requirements set covering mutual TLS, FAPI 2.0 alignment, consent handling, per-third-party rate limits, deployment mode and the control plane location. Confirm each of those requirements against the current release notes and documentation of the candidate you shortlist, because gateway features change between versions.

DeployOpen plans, implements and documents this layer in your own infrastructure, including the configuration, access model, high availability design and evidence your assessors will ask for. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and your compliance team should agree early on which evidence each assessor expects from the gateway and its identity provider.

Which regulatory and security requirements shape the gateway build

This table maps each regulation or security framework that commonly applies to a financial API gateway to what it means for gateway configuration, logging, change control and access. Read each row against your own licence type, regulator and card or payment flows, since applicability depends on your entity type and data.

Requirement	What it means for the gateway	Evidence an assessor will expect
DORA Article 28(3): register of ICT contractual arrangements	Every gateway component, hosting location, subcontractor and API partner integration needs a recorded entry. Tag routes and consumers to the contract that supports them.	Register entries that name the gateway software, hosting provider, support partner and the functions each arrangement supports
DORA Article 28(8): tested exit strategy and transition plan	Keep gateway routes, plugins and consumer definitions in version-controlled declarative configuration so a second environment or replacement gateway can take over. Confirm the exit path for each critical or important function.	A documented exit plan, a dated test of restoring configuration elsewhere, and transition steps for partner routes
DORA Article 30(2): contract terms	Contracts with the implementation partner and any hosting provider should state where gateway logs and configuration are stored, notice of location changes, and data return on termination or insolvency.	Signed contract clauses on data location, change notice and data return, checked against your ICT third-party policy
PCI DSS v4.0.1 where cardholder data crosses the API layer	Scope the gateway into the cardholder data environment if it carries card data. Enforce strong cryptography for transit, protect public-facing APIs, and restrict administrative and service accounts that can change routes or plugins.	Network and data flow diagrams, a scoping decision for the gateway, and the Report on Compliance or Self-Assessment Questionnaire the payment brands require
Swift Customer Security Controls Framework v2026 for connected payment systems	If the gateway fronts or connects to Swift-connected systems, confirm which of the 32 controls (26 mandatory, 6 advisory) touch its administration, access and logging. Separate the gateway admin plane from payment operator accounts.	Independent assessment results and the annual attestation submitted in the KYC-SA application, with gateway control mapping
FTC Safeguards Rule, 16 CFR 314.4(c)(5): multi-factor authentication	For non-bank institutions under FTC jurisdiction, require MFA for every person accessing gateway administration consoles, the Admin API and the identity provider that signs partner tokens, unless the Qualified Individual approves an equivalent control in writing.	Written MFA policy, identity provider configuration exports, and any signed exception from the Qualified Individual
SEC Release 33-8810: IT general control areas for listed firms	Gateway changes map to program changes, and gateway operations and access map to computer operations and access controls. Require tested change approval, segregated deployment rights, and logged access to routes that affect financial reporting.	Change tickets linked to Git commits, access review records for gateway administrators, and job and deployment logs tied to control owners
FAPI 2.0 security profile (naming only)	Confirm which FAPI 2.0 profile and conformance requirements apply to your open banking or partner APIs, including mutual TLS and sender-constrained tokens, against the current specification with your assessor. Do not treat this row as a checklist until that review is complete.	A written profile decision, the specification version used, and gateway and identity provider settings that the assessor has reviewed

Which open source gateways and identity components fit financial APIs

A financial API program usually needs a gateway that enforces transport security and per-partner limits, and an identity provider that issues the tokens behind those limits. The cards below cover the two gateway candidates and the identity components that pair with them, with the version and support questions to settle before selection.

Apache APISIX for partner gateways

APISIX is an Apache-2.0 gateway built on NGINX and etcd, with more than 100 built-in plugins covering authentication, traffic control and observability. Its openid-connect plugin works with Keycloak, Okta and Microsoft Entra ID, so token validation can sit at the edge while consent and scope checks stay in your services. Standalone and decoupled deployment modes let you keep the control plane in a restricted zone. Version 3.19.0 was released September 28, 2026, and the release page does not mark it as long-term support, so confirm your upgrade policy before you commit.

Kong Gateway as an alternative

Kong Gateway is also licensed under Apache-2.0 and is a common choice for teams that already run Kong in other parts of the estate. Before selecting it, compare the plugins you need for mutual TLS, per-consumer rate limits and token validation against the APISIX list, since the feature sets and their licensing boundaries differ. Ask your partner to confirm which capabilities are in the open-source edition and which require a commercial subscription, because a regulated program often depends on those features.

Keycloak for consent and client identity

Keycloak is an Apache 2.0 identity server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, with clients, scopes and fine-grained authorization for partner onboarding. It needs a synchronously replicated database in any high availability design and supports PostgreSQL 14 to 18 among its production databases. The Operator recommends manual approval for updates, which suits change control in a regulated environment. Confirm the database, availability zone layout and upgrade schedule with your team before sizing the cluster.

Red Hat build of Keycloak for support

Red Hat build of Keycloak is Red Hat's supported distribution of the open-source Keycloak project and replaces Red Hat Single Sign-On. Choose it when your organization needs a vendor-backed support contract and lifecycle commitments for the identity layer that issues partner tokens. Red Hat's product page showed 26.6 as its latest version, which differs from the upstream release, so confirm which build and support window your contract covers. Ask how patches for the upstream project reach the supported build.

Match the gateway to team skills

The choice between APISIX and Kong should follow the team that will run it, not only the feature list. APISIX custom plugins can be written in Lua or through plugin runners in Java, Go and Python, while Kong has its own plugin model, so check which languages your engineers already support. Also verify that the plugins behind your partner-facing controls are maintained in the version you deploy. A proof of concept against your own partner flows will show gaps that a feature matrix does not.

How mutual TLS, consent and per-third-party limits work together

Four checks have to agree before a partner request reaches a financial API: the client certificate, the token bound to that client, the consent behind the token, and the rate limit applied to that third party. At the gateway, mutual TLS means the listener requests a client certificate and validates it against the trusted certificate authorities for partners. In a self-hosted APISIX deployment, the certificate's identity must be mapped to a consumer or client ID that the other checks can read, so the gateway can tell which third party is calling. Confirm in the proof of concept which certificate fields your partners' certificates carry and how the gateway exposes them to plugins, because mapping on the wrong field is a common source of cross-partner exposure.

Token binding is where the certificate and the token meet. Sender-constrained tokens are issued to a specific client certificate, and the resource server must reject a token presented over a different connection. The APISIX openid-connect plugin covers token validation, introspection and the authorization code, client credentials and PKCE flows, and works with identity providers such as Keycloak, but the binding check and the consent check depend on what your authorization server issues. Consent is evaluated by comparing the scopes or consent identifier in the token with the operation requested. Gateways can enforce coarse scope rules on routes, while the fine-grained question of whether this customer's account data may be read by this partner usually stays in the application or the consent service. Treat that split as a design decision to record, and test a token issued to partner A being replayed by partner B.

Rate limits must be keyed by third party, not by route alone. A global limit lets one partner's batch job starve every other partner, so the limiter key should be the authenticated client identifier, with separate budgets for each partner tier. APISIX traffic control plugins can use consumer or header-derived keys, and you should confirm that the key is taken from the validated identity rather than a client-supplied header. Ask the implementation partner to demonstrate three things in the proof of concept: a rejected certificate, a token used outside its binding, and one partner exhausting its quota without affecting another. Anything the gateway cannot express, including per-account consent limits, belongs in the application backlog with an owner.

Deployment choices that regulators and availability targets constrain

In traditional mode, the data plane and control plane run together on the same nodes, and both depend on an etcd cluster that stores routes, consumers, upstreams and plugin settings. Every gateway node handles client traffic and also reaches the Admin API, so the placement of those nodes is also the placement of your configuration store. For a financial services estate, this means the etcd cluster and the gateway nodes inherit the same network zone, backup schedule and access controls as the rest of the API layer.

Data and control plane placement: Client traffic and configuration management share one process group, so a single node failure removes both capacity and admin access on that node.
etcd dependency: etcd is required for configuration state. Confirm its quorum design, its backup and restore tests, and who can write to it.
Port 9080 exposure: Traffic listens on port 9080 for clients. Expose it only to the upstream load balancer or the partner-facing edge, not to the internet directly.
Port 9180 exposure: The Admin API listens on port 9180. Restrict it to a management network, enforce authentication on it, and keep it off any partner-reachable segment.
Change path: Route and plugin changes go through the Admin API into etcd, so changes must be captured in your change management records and in Git-backed pipelines.

Before approving this mode, confirm which teams can reach port 9180, where etcd backups are stored, and how a control plane outage would affect partner traffic.

Standalone mode removes etcd from the picture. Configuration comes from a YAML or JSON file, or from the Admin API, and each node holds its own copy. When the file-driven option is used, APISIX checks conf/apisix.yaml or conf/apisix.json for changes every second and hot-reloads without restarting. This makes configuration a versioned file that can be reviewed, signed and rolled out through a pipeline, which many change control processes find easier to evidence than a live key-value store.

Data and control plane placement: Each node is self-contained, so there is no shared control plane to fail, but there is also no central point to enforce consistency across nodes.
etcd dependency: None in this mode. Your evidence set shifts to the configuration file, its repository history and the deployment tooling that distributes it.
Reload behavior: APISIX checks the file every second. Confirm how your pipeline writes the file, since a partial write could be picked up before a rollout completes.
Port exposure: Port 9080 serves traffic and the Admin API on port 9180 is available if enabled. Disable or restrict the Admin API in this mode if the file is the only intended source of change.
Drift risk: Nodes that receive different files will behave differently. Require checksum verification and a fleet-wide view of the deployed configuration version.

Confirm that your change pipeline writes the file atomically, that the Admin API is disabled or locked down, and that you can show which configuration version each node runs at any point in time.

How a financial API gateway rollout moves from scope to audit-ready

The sequence turns an open banking or partner API idea into a gateway that is documented, tested and cut over under change control. Each phase produces an artifact that an auditor, regulator or internal risk function can inspect before the next phase starts.

Define scope and the register of ICT services
The client's architecture, risk and third-party management teams agree which APIs, consumers and data flows are in scope, and which business functions they support. DeployOpen documents the gateway, identity provider, database, hosting location and support providers as ICT services, and records where services run and where data is processed. The output is a register entry for each service, aligned with the register of information DORA Article 28(3) requires, and a written scope agreed before work starts.
Produce the reference design and threat model
The team selects the deployment mode for Apache APISIX or Kong, the control plane location, the identity provider and the mutual TLS trust model, then records the choices against the FAPI 2.0 and sector requirements that apply. A threat model covers the OWASP API risks the gateway cannot address, such as object-level authorization that stays in the application. The output is a design document signed by the client's security and architecture owners, with open questions listed and assigned.
Build identity and mTLS in a non-production environment
DeployOpen builds the Keycloak or client identity integration, the openid-connect plugin flows, client certificate handling and per-third-party rate limits in a non-production environment that mirrors production topology. Configuration is kept in version control so each change can be reviewed and reproduced. The output is a working build with test evidence for token validation, certificate rejection, consent enforcement and limit behavior, and a list of configuration differences from production.
Run a partner onboarding pilot
A small group of partners connects to the non-production gateway under the agreed onboarding process, covering certificate issuance, client registration, consent handling and support escalation. The pilot shows whether the documented procedures work for people outside the delivery team. The output is a pilot report listing defects, changed procedures and the partner onboarding runbook updated with what the pilot taught the team.
Complete penetration testing and the tested exit plan
Security testers assess the APIs, the gateway configuration and the identity flows, and the findings are fixed and retested before go-live. In parallel, the team writes an exit strategy and transition plan for each ICT service supporting a critical or important function, as DORA Article 28(8) requires, and rehearses at least the data return and gateway replacement steps. The output is a test report with remediation evidence and an exit plan that the client has walked through in a documented exercise.
Cut over to production under change control
The approved configuration moves to production through the client's change process, with a rollback plan, a named approver for each change and a cutover window agreed in advance. Post-cutover checks confirm routing, authentication, limits and logging behave as tested. The output is a change record, the production configuration in version control and a sign-off that links the design, test and exit evidence to the live system.
Hand over evidence for audit readiness
DeployOpen compiles the evidence pack: the register entries, signed design, test results, pilot report, exit plan, change records and access logs. The client's internal audit, compliance or an external assessor reviews it, and DeployOpen does not issue any audit opinion or attestation. The output is an indexed evidence set that maps each artifact to the control or regulatory expectation it supports, with gaps and owners listed for the client to confirm.

Evidence that auditors and supervisors ask for from the gateway

This table lists the records an auditor or supervisor is likely to request from a self-hosted gateway and identity layer, what each one proves, and which component produces it. DeployOpen prepares this evidence inside the client's infrastructure, but independent auditors, certification bodies and supervisors decide whether it is sufficient. Confirm each requirement against your own supervisory expectations and contracts before you finalize the evidence set.

Evidence item	What it proves	Component that produces it
Gateway configuration in Git with change history	Routes, plugins and policies were defined in reviewed code and changed through approved commits	Git repository, pull request reviews and the configuration pipeline
Admin API and client access logs	Who changed gateway settings and which third-party calls reached protected APIs, with timestamps	APISIX Admin API on port 9180 and gateway access logs shipped to central storage
Keycloak admin event records	Administrative changes to realms, clients and users were made by named accounts and are traceable	Keycloak admin events and audit logging forwarded to a SIEM
Rate limit configuration exports	Each third party has a documented request ceiling that matches its contract and plan	Gateway configuration export with per-consumer rate limit plugin settings
mTLS and certificate configuration exports	Partner connections require client certificates and only approved certificate authorities are trusted	Gateway TLS configuration export and certificate inventory from the issuing authority
DORA register and contract clauses	Each ICT arrangement behind the gateway is recorded, with service locations, data processing locations and data return terms	Third-party register maintained by the risk function and signed contracts held by legal
Exit plan test records	Documented exit strategy for critical or important functions was rehearsed and results were recorded	Exit runbooks, test reports and transition plan sign-off from the operations and risk teams
TLPT results where a threat-led test is required	A threat-led penetration test was run and its findings were tracked to closure	Test provider's report and the remediation tracker, where the supervisor or framework requires a threat-led test

What financial institutions ask before running an API gateway in-house

What drives the cost of a self-hosted gateway and identity build?

The cost depends on the scope agreed in writing, not on the software license, because APISIX and Kong Gateway are open source under Apache-2.0. The main cost components are infrastructure in your own cloud accounts or data centers, the implementation work (routes, authentication, consent flows, rate limit policies and observability), security testing, and ongoing operations. Recurring costs include infrastructure, upgrades, certificate and key management, and support. Costs rise with the number of APIs, partner onboarding flows, high-availability requirements and the number of environments. Ask any implementation partner for a fixed-scope quote that separates one-time build work from recurring operations and support, and ask which items are priced per environment or per partner.

How long does a fixed-scope gateway rollout take?

The duration depends on scope, so no general timeline applies. The factors that change it most are how many APIs and partners onboard in the first release, whether you need FAPI 2.0 conformance work and mutual TLS for each third party, how many identity providers must integrate, and whether you run a single cluster or a multi-site high-availability design. Keycloak, for example, requires a synchronously replicated database in each of its supported high-availability designs, which adds planning work. Request a written timeline with milestones, dependencies on your change windows and the acceptance tests for each phase before work starts.

What does the work need from our internal teams?

Your teams supply decisions, access and sign-off, and the partner supplies the build. Expect to name owners for the identity provider, network and firewall rules, certificate authority, database platform, security operations and each API product. Your risk and compliance function should confirm control ownership and evidence formats early, and your business owners should approve partner onboarding and consent rules. Ask the partner to list every access request, environment and approval gate in the written scope so that delays in your organization are visible and planned for.

Can our own team run the gateway after go-live?

Yes, if your team has the skills and the operating model to run it, and many institutions choose to keep operations in-house after a partner build. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your infrastructure, and ongoing support, upgrades and continuous testing are available as retainers. Before deciding, confirm who will handle on-call response, certificate renewal, Keycloak and APISIX upgrades, backup restore tests and access reviews. Ask the partner to hand over runbooks and configuration stored in version control as part of the fixed-scope deliverables.

How is DORA documentation handled for an in-house gateway?

DeployOpen prepares the technical documentation and evidence that your team needs for its DORA register and contract files, but your institution owns the register of information and its legal interpretation. DORA Article 28(3) requires a register covering all contractual arrangements for ICT services, and Article 30(2) requires contracts to state where services are provided and data processed. Article 28(8) requires documented, tested exit strategies for services supporting critical or important functions. Confirm with your legal and third-party risk teams which open-source components and partner services must appear in the register, and agree the document list in the written scope.

Does open source avoid vendor lock-in, and what does exit planning require?

Open source reduces dependence on one license holder, but it does not remove operational dependence on the partner or on specific configuration. APISIX is Apache-2.0 licensed and Kong Gateway is also Apache-2.0, and Keycloak is Apache 2.0, so you can run these platforms without a license purchase. Exit planning still needs a documented, tested transition path: exported routes and plugin configuration in Git, a tested data return process, identity migration steps and a rollback plan. Note that the Red Hat build of Keycloak is a separate supported distribution, so confirm which build and support terms you depend on before signing.

How are gateway upgrades tested before they reach production?

Upgrades should move through the same environments as new configuration, with regression tests for authentication, mutual TLS, consent flows and rate limits before any production change. APISIX 3.19.0 was released on September 28, 2026, and the downloads page does not mark any release as long-term support, so your upgrade policy should set the version cadence explicitly. Keycloak plans four minor releases a year, and its Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended upgrades. Keycloak also migrates its database schema at startup by default, so ask whether your partner will apply migrations manually for a controlled change window.

Questions to ask an implementation partner before signing

Start with testing, because a gateway that passes a generic load test can still fail a FAPI-profile check. Ask the partner how they verify mutual TLS and certificate-bound token behavior on the APISIX or Kong routes that carry third-party traffic, which test tooling they use, and whether the results are kept as dated evidence in your environment. Ask who fixes a failed test and whether that fix is re-tested before go-live. Ask them to show the test cases for consent enforcement and per-third-party rate limits, not only the happy path. Confirm that the identity provider, typically Keycloak, is tested with the same client registrations you will run in production.

Ask how gateway configuration is kept in Git and who can merge to the production branch. For APISIX in standalone mode, the routing and plugin definitions live in conf/apisix.yaml or conf/apisix.json, so ask how changes are reviewed, how secrets are kept out of the repository, and how a rollback is performed. Ask how the partner documents Admin API access on port 9180 in traditional mode, since that interface must not be reachable from partner networks. For Keycloak, ask how realm exports and the Keycloak Operator custom resources are versioned, and whether the partner will hand you the repository with every commit history intact.

Ask for a sample ICT third-party file before you sign. It should show how the partner supports your register of information under DORA Article 28(3), where contract clauses on service locations, data processing and data return under Article 30(2) are tracked, and what the exit strategy and transition plan under Article 28(8) contain. Ask how the partner's own subcontractors are recorded and how they would be notified of change. For Keycloak upgrades, ask how they run the Operator in manual approval mode, which the Keycloak Operator documentation strongly recommends, and how they decide between automatic schema migration and manual SQL. Finally, ask who holds the register, the test reports and the configuration repository after handover, and whether you hold admin credentials and signing keys from day one.

Where DeployOpen fits in a financial API program

A financial API program touches scoping, infrastructure, security testing and assessor evidence, and a gap in any one of them shows up later as a finding. DeployOpen covers the implementation side of each step inside the client's own infrastructure. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do.

Scoping in writing

Before any gateway is built, the in-scope APIs, third-party consumers, data flows and cardholder or customer data paths are agreed in a written scope. Most engagements are fixed-scope, so deliverables and timelines are defined before work starts. Check that the scope names which APIs fall under the PCI DSS cardholder data environment and which third parties are covered by your DORA register of information.

Build in your infrastructure

The gateway, its etcd or standalone configuration, the identity provider integration and the observability stack run in your cloud accounts, data centers or air-gapped network. Ask where the data plane and control plane sit, whether the configuration is kept in Git, and how it is backed up. Those answers determine where contractual location and data return terms under DORA Article 30(2) must point.

Security testing of APIs and identity

Testing covers the gateway, the APIs behind it and the identity layer that issues tokens, including authorization flaws that a gateway cannot enforce on its own. Testing findings feed back into plugin configuration, token lifetimes and rate limits per third party. Confirm whether the test scope includes mutual TLS, sender-constrained tokens and the consent flows your partners use.

Evidence preparation for assessors

Assessors ask for configuration exports, access reviews, change records, logs and the exit plan for each ICT service, and those artifacts have to exist before the assessment starts. DeployOpen prepares the systems, controls and evidence for these reviews, but the assessment itself and any resulting report or attestation belong to your independent auditor or certification body. Ask for the evidence list in writing at the start of scoping.

How DeployOpen scopes, builds and supports financial API gateways

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source gateways inside the institution's own cloud accounts, data centers or air-gapped networks. For financial API programs, the work starts with a written scope that ties each gateway control to the security requirements, third-party obligations and evidence the institution already needs.

How we scope

Inventory the partner APIs, third parties, consent flows and traffic volumes that the gateway must serve
Map which APIs support critical or important functions, so exit and contract requirements are scoped early
Agree in writing which FAPI 2.0 profile elements, mutual TLS and rate limits per third party are in scope

How we build

Deploy Apache APISIX or Kong Gateway in the deployment mode the institution's network and control plane rules allow
Integrate OpenID Connect with the institution's identity provider and configure certificate-bound token handling
Test authentication, throttling, routing and gateway hardening against the agreed scope before any partner onboarding

How we hand over

Deliver configuration in version control with documented change, approval and rollback procedures
Document where services run, where data is processed and how the gateway's ICT third-party information is recorded
Provide runbooks for exit, data return and gateway migration so the institution can test them independently

How we support

Plan gateway upgrades, plugin changes and security patches as scheduled, tested releases
Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build
Prepare control evidence for the institution's auditors, who issue any assessment report or attestation