Your architecture team is proposing to replace the commercial API gateway — IBM API Connect, MuleSoft, or similar — with an open-source alternative. The pitch leads with the licensing cost: six or seven figures annually that could be eliminated. Kong or Envoy are cited. The migration is scoped as a six-month project. The pitch is not wrong, but it is incomplete in ways that have derailed similar programmes at peer institutions. Before you approve it, there are three decisions buried inside the technical proposal that need explicit answers.

Replacing a commercial gateway is not a cost reduction. It is a capability transfer. You are moving responsibility for policy enforcement, consumer lifecycle management, and security tooling from a vendor to your own team. The licence cost disappears. The operational cost does not.

The decision your team is framing as technical

The first thing to understand is what an API gateway actually does at a regulated bank. It is not merely a reverse proxy. It is the enforcement point for three things that matter to the regulator: consumer authentication and authorisation (who is allowed to call this API and with what credentials), rate limiting and quota enforcement (what the consumer is contractually entitled to call), and audit logging (a durable, tamper-evident record of every call that crossed the regulated boundary). Commercial gateways package these as product features with vendor support behind them. Open-source gateways offer the same capabilities as configuration, with your team responsible for keeping that configuration correct and current.

The decision your architecture team is presenting as “which tool” is actually “do we have the operational depth to own this enforcement point ourselves?” That is a leadership question, not a technical one. The answer depends on team capability, not on Kong’s feature set.

What SAMA cares about

SAMA’s Open Banking Framework and Cyber Security Framework both reference the API layer as a regulated boundary. Two things surface in every integration architecture review. The first is certificate lifecycle: the gateway must enforce mTLS for partner traffic, and every partner certificate must be registered, monitored for expiry, and rotated on a tracked schedule. Commercial gateways typically provide a UI for this. Open-source gateways provide an API; the workflow must be built. When an examiner asks “show me the certificate inventory for your Open Banking partners,” the answer needs to come from a system, not a spreadsheet.

The second is rate-limit auditability. If a partner claims they were incorrectly throttled — which happens — you need to produce the per-partner quota counters for the disputed period. This requires durable rate-limit audit logs, not just gateway access logs. Open-source rate limiting is typically backed by Redis, which is an in-memory store. The audit log trail is in the access log, but correlating a 429 response to the specific quota window that triggered it requires deliberate logging design, not the default configuration.

The real cost of the migration

Licensing savings are visible in year one. The costs that are harder to forecast are in years two and three. Open-source tool upgrade cycles are faster and less managed than commercial vendor release trains. Kong has released major versions with breaking plugin API changes; Envoy’s xDS API has had non-trivial version transitions. Each upgrade is an engineering project, not a vendor-managed update. The team that owns the gateway needs to treat it as a product with a roadmap, not as infrastructure that runs itself.

There is also the support model to consider. When a DataPower gateway behaves unexpectedly under load, the IBM support ticket escalates to engineers who built that product. When Kong behaves unexpectedly, you are filing a GitHub issue against a maintainer community or paying for Kong Enterprise support, which is itself a licence cost that narrows the saving. Before approving the migration, ask for the support model to be explicitly scoped — including who holds the pager for the gateway at 2am on a settlement day.

The trade-off the business needs to make

There are three scenarios where the open-source migration is the right call. The first is when you are building a cloud-native platform from scratch and there is no existing commercial gateway to migrate from — open-source starts with no migration cost and no legacy policy to translate. The second is when the team already runs Kubernetes at scale and has Istio operational experience; the incremental cost of adding Kong is genuinely low. The third is when the commercial gateway vendor relationship is broken — support quality has degraded, the roadmap does not align with your direction, and the renewal negotiation has become unproductive.

There are also scenarios where it is the wrong call. If your platform team is already stretched across fifteen integration domains and does not have bandwidth to own another mission-critical component, adding gateway operations to that team will degrade everything, not just the gateway. If your SAMA certification timeline is within six months, a gateway migration introduces change risk at exactly the wrong moment. And if the migration is motivated primarily by avoiding an upcoming licence renewal conversation, there is a faster path: negotiate the renewal first, buy yourself two years, and do the migration with time to do it properly.

Four questions worth asking before approving

Who owns gateway operations after the migration? Name a team and a lead. “The platform team” is not an answer if the platform team lead is not in the room agreeing to the scope.

What is the migration strategy for partner APIs? Partners will not automatically rotate their client certificates or update their endpoint URLs. The migration plan must include a partner communication campaign, a dual-running period, and a tested rollback procedure. Ask to see it before the project is approved.

What is the certificate inventory and rotation workflow? If the answer requires someone to manually track expiry dates in a spreadsheet, that is a gap that needs to be filled before go-live, not after.

What does the commercial vendor offer in exchange for the renewal? Sometimes the right answer is a better commercial deal, not an open-source migration. The negotiation leverage is highest before you have committed to the alternative. Use it.

The teams that run open-source gateways well in regulated environments are not the ones with the most sophisticated tooling. They are the ones where leadership made the capability question explicit before the technical design was locked, staffed it with engineers who have operated these systems in production before, and treated the gateway as a product rather than a deployment. The technology is available and it is excellent. The organisational discipline is what determines the outcome.

For the technical depth behind these trade-offs—Kong architecture, FAPI 2.0 configuration, Envoy sidecar topology, and migration procedures—see the companion Lab article: Kong & Envoy at the Edge: Open-Source Gateway Strategies for Financial Services.