Apache APISIX for financial services

Why Apache APISIX for financial services APIs fits regulated partner traffic

Apache APISIX fits a financial institution that must keep routing, authentication, rate limits and logs under its own control for partner and open banking style APIs. The gateway is a top-level Apache Software Foundation project released under the Apache License 2.0, so the institution can run it in its own data centers or cloud accounts without a per-instance licence decision tied to a vendor. It is built on NGINX and etcd and supports dynamic routing with hot-loading of configuration and plugins, which lets partner routes change without rebuilding the edge. Its documentation describes more than 100 built-in plugins covering authentication, security, traffic control and observability, so many partner controls can be configured rather than written from scratch.

For the team, the change is ownership. Routes, consumers, plugin settings and the configuration files or etcd data that hold them become assets the bank maintains, reviews and backs up. The three deployment modes (traditional, decoupled and standalone) let architects choose how far configuration sits from the data plane, and a file-driven standalone setup can be kept in version control and reviewed like code. Teams should confirm which mode fits their change process and network zones, and who holds the Admin API on port 9180 in traditional mode, since that interface is the most sensitive part of the deployment.

APISIX does not replace the controls that sit around it. It does not make a payment environment compliant with PCI DSS, issue an attestation, or provide the register of ICT contracts and exit plans that DORA requires for critical or important functions. Identity remains with the identity provider the institution selects, whether that is an OpenID Connect provider through the openid-connect plugin or another system. Before committing, the team should confirm which vendor-supported options it needs, such as commercial support or lifecycle management, with the vendor, because the downloads page does not mark any release as long-term support.

Which financial regulations shape the gateway build and what each means for it

This table maps the regulations and frameworks most likely to touch a financial APISIX gateway to the concrete build decisions they affect. Read each row as a question to answer before routes go live, and confirm applicability with your compliance team, assessor or supervisor.

Requirement and source	What it asks for	What it means for the APISIX build
PCI DSS v4.0.1 scope (PCI SSC)	Applies to entities that store, process or transmit cardholder data, or could affect the security of that environment, including service providers	Map every route that carries cardholder data or can reach the cardholder data environment. Keep those routes on a separate gateway instance or route group, and confirm with your QSA which components are in scope.
PCI DSS v4.0.1 network and access controls (12 requirements, six goals)	Secure network and system configuration, access restriction and logging across the cardholder data environment	Restrict Admin API and etcd access to named management networks, scope consumer credentials per partner, and send gateway access logs to protected storage.
PCI DSS assessment evidence (PCI SSC FAQ 1220)	A Report on Compliance by a QSA or a Self-Assessment Questionnaire, each with an Attestation of Compliance	Keep route configuration, plugin settings and change records in version control so the assessor can trace each control. DeployOpen prepares evidence; only the QSA or the assessment process issues the attestation.
DORA ICT contract register (Article 28(3))	A register of information covering all contractual arrangements for ICT services	Record APISIX, its vendors and any support or subscription contract (including API7 Enterprise if chosen) in your register. Note the component versions you run and who maintains them.
DORA exit strategy (Article 28(8))	Documented, tested exit strategies and transition plans for ICT services that support critical or important functions	Keep route definitions exportable as code, and test that you can run the same routes behind another gateway or in standalone mode. Document the rollback path before cutover.
DORA contract terms (Article 30(2))	Contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination	When buying implementation or support, ask that the written scope fix hosting locations, change notice, and data return. Confirm the hosting locations of any managed or cloud component.
DORA ICT risk and testing (Chapters II and IV)	Documented ICT risk management, incident handling and digital operational resilience testing	Route gateway logs and alerts into your incident process. Include the gateway in penetration testing scope and retest after plugin or version changes.
Swift Customer Security Controls Framework v2026 (Swift CSP)	32 controls (26 mandatory, 6 advisory) assessed independently and attested annually in KYC-SA	If the gateway fronts Swift-connected systems, map the relevant controls to gateway access, MFA on administrative paths, and log retention. Confirm the applicable control IDs with Swift documentation.
FTC Safeguards Rule (16 CFR 314.4(c)(5))	Multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing	Protect Admin API, dashboards and operator access with MFA through your identity provider. Record any approved equivalent control in writing before go-live.
SEC ICFR guidance (Release 33-8810)	IT general control areas for SOX 404: program changes, computer operations, and access to programs and data	Gate every route and plugin change through review and approval, log who changed what, and restrict who can alter production configuration. Keep a change history auditors can sample.

How partner, open banking style and internal APIs need different APISIX setups

Partner systems that call your APIs without a human present, such as a payment processor's batch job or a corporate treasury system, usually authenticate as a client rather than as a user. In APISIX, the usual choices are the mutual TLS client certificate check, the hmac-auth plugin for request signing, or key-auth where a static key is acceptable for a narrow use. Each partner should map to its own consumer object so that rate limits, logs and revocation act on one partner at a time.

Consumer per partner: Create one consumer for each legal entity or integration, not one shared key for a partner group, so a revoked credential affects one connection only.
mTLS for transport identity: Require client certificates issued by a CA you control and validate the certificate subject or fingerprint against the consumer record.
HMAC for message integrity: Use request signing where the partner must prove that the body and headers were not altered in transit, and plan the clock tolerance and signature algorithm with the partner in advance.
Key rotation paths: Design overlapping validity windows so that a partner can move to a new certificate or secret without a service outage.
Per-consumer limits: Attach the limit-count or limit-req plugin to each consumer so one partner's traffic cannot consume another's quota.

Confirm with your security team which algorithms, certificate profiles and rotation intervals your policy requires before the partner onboarding starts.

Open banking style APIs often serve third-party applications that act on behalf of a customer. These need delegated authorization, so the gateway should validate tokens issued by your identity provider rather than hold long-lived keys. The openid-connect plugin supports token introspection and the client credentials and authorization code flows, and it works with providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta. Your choice of provider determines which flows and scopes are available to each application.

Token validation at the edge: Configure the openid-connect plugin to introspect or verify tokens against the issuer, so expired or revoked tokens are refused before reaching backend services.
Scope mapping per route: Tie each route to the scopes a consent grant allows, and keep the mapping in version-controlled configuration.
PKCE for public clients: Require PKCE for mobile and browser applications that cannot keep a client secret.
Consumer linkage: Decide whether the gateway creates a consumer per application, per user or per tenant, and align it with the rate limit model.
Standalone checks: Where the gateway also needs an API key for partner onboarding, combine key-auth with openid-connect through multi-auth rather than mixing them ad hoc.

Confirm the consent, token lifetime and scope model with your identity team and the regulatory obligations that apply to your open banking program.

Which APISIX plugins and settings matter most for banks and payment providers

Financial APIs fail audits on the details: who each caller is, how much traffic each partner may send, and what the gateway writes down. The cards below cover the APISIX configuration decisions that carry that weight, so you can confirm each one against the plugin version you plan to run.

Per-partner rate limits through consumer design

Rate limits only mean something when the gateway knows which partner is calling. Model each partner, and each application a partner operates, as a consumer with its own credential, so limits, quotas and revocation apply per partner rather than to the whole route. Ask your team to confirm which rate-limiting plugin and key options fit your partner tiers in the version you deploy, and test what happens when one partner reaches its ceiling while others keep normal access.

mTLS and HMAC for machine clients

Payment and open banking style integrations usually rely on machine clients, not people at a browser. Decide which partners authenticate with client certificates, which sign each request with an HMAC key, and how each key is issued, rotated and revoked. Confirm in your version's documentation how the gateway verifies client certificates and signatures, and plan the certificate authority, expiry alerts and key ownership before the first partner onboards.

OpenID Connect against your identity provider

For staff tools, customer-facing apps and partner portals, the openid-connect plugin can delegate sign-in to an identity provider such as Keycloak, Microsoft Entra ID or Okta. The plugin supports authorization code, client credentials, token introspection and PKCE flows. Map each flow to a specific client type, confirm token lifetimes and claim checks with your identity team, and document which routes accept which flow so auditors can trace access decisions.

Admin API and etcd separation

The Admin API changes every route, consumer and plugin, and etcd holds that configuration. Place the Admin API on a network segment that only your operations team reaches, and do not expose it on the client listener. In traditional mode, client traffic and the Admin API use separate ports, so confirm your firewall rules and mutual trust between the gateway and etcd. Restrict who can write configuration, and log every change as a control over program changes.

Keeping account data out of gateway logs

Access logs, error logs and plugin output can capture account numbers, card data or personal identifiers that appear in URLs, headers or request bodies. Review your log format before go-live, and decide which fields are dropped, masked or never captured. Cardholder data that passes through the gateway can bring it into PCI DSS scope, so confirm with your assessor which log fields are in scope and how long logs are kept.

Planned integration with WAF and SIEM

Gateway logs only protect you when security operations can read them. Plan how APISIX forwards access and error logs to your SIEM, which events trigger alerts, and whether a web application firewall sits in front of or behind the gateway. Agree on log retention and on who reviews blocked requests, and test the full path with sample traffic so the evidence for your DORA incident and PCI DSS monitoring processes exists before an incident.

How a regulated APISIX rollout runs from scoping to parallel running

The sequence moves a financial services gateway from a scoped register entry to a tested, parallel-run cutover with a documented exit plan. Each phase closes with a named artifact that the risk, security and compliance owners can review before the next phase starts.

Scope the service and enter it in the register
Agree in writing which APIs, partners and data flows move onto the gateway, and whether any of them support a critical or important function. Record the gateway as an ICT service in your register of information, including the providers, the hosting locations and the data processed. Your risk and compliance owners sign off the scope document. It is done when the scope, the register entry and the list of contractual arrangements agree with each other, and a DeployOpen engagement scope is confirmed in writing where a partner is used.
Design the environment and data center layout
Choose the deployment mode for each environment (traditional, decoupled or standalone) and map where the data plane, control plane, etcd and Admin API will run in your regulated data centers. Define network zones, ingress paths for partner traffic, DNS, certificate authorities and the logging destination. The output is an architecture record and a hosting map that names every location where data is processed, so it can be tied to contract terms on location and notice of change.
Inventory routes, consumers and partner obligations
Export the routes, upstreams, authentication methods and rate limits from the current gateway, then group them by partner, product and sensitivity. For each machine client, record the agreed authentication method (mTLS, HMAC or OAuth client credentials), the owner, and the per-partner limits. Flag routes that carry cardholder data or other sensitive authentication data, since they set the scope of your PCI DSS assessment. The inventory is complete when every route has an owner, an authentication method and a classification.
Harden the gateway and test it against the design
Lock down the Admin API and control paths, restrict access to etcd, set TLS and certificate policy, and define how stored secrets are encrypted and rotated. Configure logging so that payment data, tokens and personal data stay out of gateway logs. Then run security testing against the routes and the gateway itself, and track each finding to closure. The phase closes when the hardening baseline is documented and the test report has no open items that the risk owner has not accepted in writing.
Run the existing and new gateways in parallel
Route a defined share of partner and internal traffic through APISIX while the existing gateway continues to serve the rest. Compare responses, latency, error rates, authentication decisions and rate-limit behavior across both paths, and reconcile the logs from each. Partners should be told which endpoints change and when. The phase produces a parallel-run report with each difference explained, and a go or no-go decision recorded by the service owner.
Cut over and rehearse the rollback
Move traffic to APISIX in steps that match the inventory groups, starting with the lowest-risk partner routes. Before each step, rehearse the rollback path so the previous gateway can take traffic back within the window your operations team agreed. Record the change, the approval and the monitoring checks for each wave. The cutover is complete when all in-scope routes are served by APISIX, the rollback was rehearsed for each wave, and the change records are filed with the register entry.
Operate the gateway and keep an exit plan current
After go-live, run the gateway under your own change, patching, backup and incident processes, with on-call coverage and dashboards for the metrics agreed in the design. Review access to the Admin API and the route inventory on a schedule you set. Keep a documented exit strategy and transition plan that names the fallback gateway, the configuration export and the data return steps, and test it at intervals your risk policy requires. The output is a current runbook set and an exit plan that the register owner can present to a supervisor on request.

What the gateway can evidence for PCI DSS and DORA audits

A self-hosted APISIX gateway can produce useful operational evidence, but the evidence it produces is raw material for an assessment, not the assessment itself. Assessors decide what satisfies a requirement. In PCI DSS, that decision is documented in a Report on Compliance completed by a Qualified Security Assessor, or in a Self-Assessment Questionnaire, each backed by an Attestation of Compliance. The PCI SSC does not validate entities, and the payment brands decide who must validate. PCI DSS v4.0.1 is the only active version, so the evidence pack should be mapped to its requirements, not to v4.0 or v3.2.1 wording. Confirm with your assessor which of your gateway controls fall inside the cardholder data environment and which are supporting controls.

The most defensible evidence comes from configuration held as code. In file-driven standalone mode, the gateway reads conf/apisix.yaml or conf/apisix.json and reloads when either changes, so the file history in version control can show what routes, consumers, TLS settings and plugins were active on a given date. Access logs, Admin API audit trails from your own logging pipeline, consumer inventories exported from the consumer model, TLS protocol and cipher settings, and change tickets linked to commits can together show who changed what and when. In traditional or decoupled mode, etcd holds the live configuration, so you need to define how exports are taken and retained. Ask your assessor which samples they will request and test that you can produce them within a day.

For DORA, the evidence feeds ICT risk management and third-party oversight rather than a certificate. DORA sets no certification scheme, and the only authority-issued attestation it provides for is that a threat-led penetration test met the requirements under Article 26(7). Your register of information under Article 28(3), exit plans under Article 28(8) and contract terms under Article 30(2) remain your own documents. Gateway configuration export, tested rollback and documented change records support those artifacts but do not replace supervisory review. Plan for the competent authority in your member state to ask how the gateway is operated, not only what it does.

Compliance considerations for a financial services APISIX gateway

A gateway in front of payment, partner and account APIs touches several regimes at once. The cards below cover the decisions that most often shape scope and evidence, and each one names what to confirm with your assessor, regulator or control owner before the design is fixed.

PCI DSS scope and approach

If the gateway stores, processes or transmits cardholder data, or could affect the security of the cardholder data environment, it sits inside PCI DSS scope. Decide early whether the gateway is in scope, because that choice changes network segmentation, logging and the evidence your assessor collects. PCI DSS v4.0.1 is the only active version, so design against it. Where a requirement cannot be met as written, ask your QSA whether the customized approach is available to you, since it must meet the stated objective in a different way.

DORA ICT third-party duties

Self-hosted APISIX is open-source software, but the services and support your team buys around it can still count as ICT third-party arrangements. Confirm with your regulator how DORA applies to your contracts, and keep the register of information current for each one. Contracts should state where services are provided and data is processed, and cover data return on termination. Document an exit strategy for any gateway that supports a critical or important function.

Swift CSP controls for connected systems

If the gateway fronts Swift-connected systems or payment messaging interfaces, the Swift Customer Security Controls Framework applies to the connected environment. Map each gateway function, such as access control, logging and secure configuration, to the relevant Swift control IDs. Swift users must have controls independently assessed and attest annually in the KYC-SA application. Confirm with your Swift security officer which controls your architecture touches and who owns the evidence.

MFA for administrative access

Under the FTC Safeguards Rule, non-bank financial institutions under FTC jurisdiction must use multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. For APISIX, that covers the Admin API, the dashboard, and operator access to etcd and the hosts running the gateway. Record the approval if you choose an equivalent control, and confirm the scope with your counsel or compliance lead.

ICFR IT general controls for change and access

For public companies, SEC guidance on internal control over financial reporting names program changes and access to programs and data as IT general control areas. Route gateway route, plugin and policy changes through reviewed, versioned change records, and restrict who can alter them. Keep evidence of who approved each change and who has access to the Admin API and configuration store. Ask your external auditor which gateway changes they will test and what sample evidence they expect.

GDPR log minimization

Gateway access logs often capture client IP addresses, identifiers in URLs, and request headers, all of which can be personal data under GDPR. Decide which fields your logs need for security and fraud investigation, and drop or mask the rest before they leave the gateway. Set retention periods with your data protection officer, and document the lawful basis for the logging. Test your log configuration against real request samples before go-live.

What financial institutions ask before hiring a partner for APISIX

What drives the cost of an APISIX implementation for a bank or payment provider?

The scope drives the cost more than the software, which is Apache-2.0 licensed and carries no license fee. The main cost drivers are the number of route groups and partner APIs, how many authentication methods must be built (OAuth and OpenID Connect, mTLS, HMAC, API keys), the custom plugins needed, the number of environments and the evidence package required for PCI DSS or DORA reviews. Infrastructure, etcd operations, and internal staff time recur after go-live. Ask any partner to split the quote into one-time build work, migration work, testing and recurring support, and to name which items are fixed and which depend on a discovery phase.

How long does an APISIX rollout take in general terms?

Duration depends on how many APIs move, how many partners connect through them, and how much of the existing gateway policy must be reproduced. A typical sequence is discovery and architecture, a build in non-production environments, partner onboarding and security testing, then a staged cutover with parallel running. Each stage depends on partner readiness and on your change approval calendar, so no single duration applies. Ask for a timeline tied to named milestones in the written scope, with the dependencies that could move each one, rather than a single overall estimate.

What must our institution provide before a partner starts the work?

A partner needs three things from you before design starts:

An architecture overview covering network zones, data centers, cloud accounts and where the existing gateway and identity provider sit
A route inventory listing each API, its consumers, its authentication method, rate limits and current logging
Named owners for identity, security, payments or open banking operations, and the regulatory owner who signs off on DORA or PCI DSS evidence

Also confirm which data centers are permitted for hosting, since DORA Article 30(2) requires contracts to state where services are provided and data processed.

Can our internal team run APISIX without outside help?

Yes, many teams operate APISIX with internal staff, because the project is open source and documented. The questions to answer honestly are whether your team already runs etcd or Kubernetes, has Lua or plugin-runner skills if custom plugins are needed, and can own on-call response for the gateway. Gaps in those areas usually justify a partner for the initial build, knowledge transfer and runbooks, with internal staff taking over operations. Your internal team should also be able to show the exit strategy and transition plan that DORA Article 28(8) requires for ICT services supporting critical or important functions.

What recurs after go-live, and what is one-time?

The build, initial hardening, the migration and the first evidence package are one-time work. Recurring items include running the gateway and etcd, applying APISIX releases and plugin updates, monitoring and log retention, periodic access reviews, security testing and evidence refresh. APISIX 3.19.0 was released on September 28, 2026 according to the project downloads page, and the page does not mark any release as long-term support, so your upgrade plan should set your own support policy. Ask whether a retainer covers upgrades, testing and on-call support, and how each is priced.

What should we request in a fixed-scope quote?

A fixed-scope quote should state the scope in writing, the deliverables, the environments covered, the milestones, the acceptance criteria and the responsibilities split between your team and the partner. Ask for the list of APIs and partners in scope, the authentication methods, the plugins to be configured or built, the testing approach, the documentation handed over, and what happens if a dependency such as partner onboarding slips. Also ask which evidence is prepared for PCI DSS or DORA reviews, and confirm that DeployOpen prepares evidence but does not issue audit reports, attestations or certifications, which independent assessors provide.

Does an APISIX deployment alone make us compliant with PCI DSS or DORA?

No. A gateway supports controls, but compliance depends on the whole environment and on an assessment by the right party. For PCI DSS, the assessment is documented as a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the current active version is v4.0.1, published on 11 June 2024. DORA applies since 17 January 2025 and sets no certification scheme, so supervisors review evidence directly. A partner can prepare systems, controls and evidence for these reviews, but the assessment itself comes from the independent assessor or supervisor.

What to ask an implementation partner before signing a financial services scope

Start with mTLS and HMAC partner onboarding. Ask the partner to show how they have issued client certificates, rotated them, and revoked them for machine clients, and how they handled HMAC key distribution, clock skew and signature verification in APISIX plugins such as hmac-auth or a custom equivalent. Ask who creates partner consumers, where the certificate authority private key lives, and how a partner's access is removed within your own procedure. Ask for a written description of the onboarding steps for one partner, so you can test whether the process is repeatable for the tenth partner as well as the first.

Next, ask how the partner handles regulated change control. Gateway routes, plugin settings and consumer changes can alter who reaches a payment or account API, so ask whether changes are made as version-controlled configuration, how each change is reviewed and approved, and how a rollback is run. Ask who holds the Admin API key on port 9180 and who can write to etcd in traditional or decoupled mode, and whether those credentials are separated from people who deploy applications. Also ask about DORA exit and data location terms: the contract should state where configuration, logs and partner data are held, how changes to those locations are notified, and how you would take the register entries, configuration and logs back if the engagement ends. Confirm each point with your own counsel and your register of information owner, since DeployOpen does not issue audit reports or certifications, and independent auditors and certification bodies do.

Finally, ask how the written scope covers testing and evidence. Request a list of the tests that will run before go-live, such as route and authentication negative tests, rate limit checks per partner and TLS configuration review, and who records the results. Ask which evidence the partner will hand over for PCI DSS or DORA-related reviews, and which parts remain your responsibility, including the assessment itself. A fixed-scope agreement should name each deliverable and acceptance criterion in writing before work starts.

How DeployOpen scopes and delivers APISIX for financial institutions

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including data centers and restricted networks. For APISIX in financial services, that means agreeing the partner API catalog, machine-client controls and evidence requirements in writing before any gateway configuration is built.

How we scope

Inventory partner, open banking style and internal APIs with their consumers, data classes and hosting locations.
Agree the authentication model for each machine client, covering mTLS, HMAC or OAuth, and the per-partner rate limit rules.
Record the written scope, deliverables and timelines before work starts, since engagements are fixed-scope.

How we build

Deploy APISIX in the deployment mode your architecture needs, in the data centers or cloud accounts you control.
Configure routes, consumers, authentication plugins and rate limits, then test them against the agreed partner scenarios.
Map gateway logging, access control and encryption settings to the PCI DSS and DORA evidence your assessors request.

How we hand over

Deliver configuration as code, runbooks for route changes and documentation of every control and its owner.
Provide evidence packs that show how controls operate, while noting that auditors and assessors issue the formal opinions.
Walk your operations and security teams through the Admin API restrictions, certificate rotation and rollback steps.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped to your APISIX release line.
Plan upgrades to new APISIX releases in a test environment first, with rollback steps recorded for each change.
Confirm with your team which support responsibilities sit with DeployOpen and which stay with your own staff.