
ING Constructs High-Velocity Banking Architecture with Kong
A multinational banking leader with 38M+ customers overhauled its global banking infrastructure with Kong, breaking the monolith and enabling cloud-scale innovation across 40+ markets.
in outage-related bottlenecks
performance
gateway configuration accuracy

ING Group is one of the world’s largest and most internationally distributed banks, serving over 38 million customers across 40+ markets.
Modernizing banking infrastructure for a behemoth-sized enterprise
ING is one of the world’s leading digital banks, operating in over 40 countries and serving millions of customers through a vast and highly distributed technology ecosystem. Behind every payment, authentication workflow, security check, and internal application lies ING Private Cloud (IPC), the platform group responsible for the computing, networking, and API infrastructure powering the bank’s global operations.
At API Summit 2025, Mark Behrens, Product Manager, Cloud API Management, ING Private Cloud, said that ING transformed its enterprise architecture with Kong, enabling hybrid-cloud scalability, developer self-service, and a modern API ecosystem that supports ING’s next decade of digital banking innovation.
“Software doesn’t degrade overnight. You rush code reviews, skip refactoring, and before you know it, you have a complex, unmaintainable monolith. We knew we had to fix it.”
Untangling a legacy monolith at enterprise scale
As a global digital bank serving 38 million customers, ING depends on a resilient, compliant, high-performing digital landscape. Payments, identity services, fraud detection, and core banking all rely on systems that can’t afford downtime.
But as ING grew, so did the complexity of its underlying architecture. A large monolithic application sat at the center of critical services, slowing development and degrading performance. Across global DevOps teams, the monolith became known as the “spinning wheel of death.”
“For many of you, it’s a thing of the past,” Behrens said. “But at ING, it’s what most DevOps teams associated my department with.”
As ING expanded into new markets and pursued a microservices-first strategy, this bottleneck became untenable. Deployments lagged, performance issues escalated, and modernization efforts stalled. Teams remained dependent on a centralized operations model that couldn’t keep pace with demand.
“We ran on the same infrastructure as our consumers. If our tool went down, we couldn’t fix it because we needed that same tool to fix the problem,” Behrens said. “Software doesn’t collapse overnight; it’s small compromises piling up until the system becomes unmaintainable.”
The monolith hindered scaling, risked updates, and made modernization difficult without affecting dependent services. As teams built API-driven services, they lacked a consistent way to expose, secure, and operate them. Varied tooling led to fragmented delivery, inconsistent security, long release cycles, dependency issues impacting reliability, and uncertainty about moving to safe self-service.
The largest obstacle, however, was cultural, as engineers accustomed to centralized operations resisted API ownership.
“Some teams didn’t see this as empowerment. They saw it as being left alone,” Behrens said. “The transition from passenger to driver is a big psychological step.”
To modernize without disrupting operations, ING needed a model that introduced shared standards, strong governance, and self-service workflows — without slowing down development. The team sought an approach to transition safely from monolithic systems to microservices, create consistency across teams, and empower developers while maintaining a strong security and compliance posture.
“One of the main reasons Kong fits so well is that its evolution mirrors how we operate. We needed a partner that matched our speed and architectural direction.”
Standardizing governance and developer experience with Kong
ING selected Kong as the foundation for its API modernization strategy for its flexibility, hybrid deployment support, and alignment with how IPC wants to operate: fast, iterative, and developer-centric.
Hybrid control plane and on-prem data planes for clean separation of concerns
A major requirement was eliminating the circular dependencies that slowed down incident response. IPC redesigned the architecture so that the control plane runs in Azure Public Cloud and the data planes run in on-prem environments.
This clean separation ensures that configuration is always available, even if on-prem systems are impacted. Behrens said that this downward flow of configuration means “no more single points of failure or circular dependencies,” a fundamental step toward resilient banking infrastructure.
A self-service model embedded directly into existing workflows
Rather than asking engineers to adopt new tooling, IPC built self-service into the CI/CD workflows developers already use. Teams define all gateway configuration, like workspaces, routes, plugins, and consumers directly in their repositories.
A custom pipeline extension wraps DEC for safe, automated deployment. This minimizes context switching and creates a unified experience where teams no longer distinguish between “doing work on their API and updating the gateway configuration.”
Governance as a guardrail, not a gate
IPC introduced reusable templates, plugin presets, and standardized security and resiliency policies.
“Self-service is liberating, until someone misconfigures rate limiting and brings down production," Behrens said.
These guardrails allow teams to move quickly while maintaining compliance. Boundaries became a core part of enabling responsible autonomy.
Cultural transformation powered by early adopters
The shift to self-service required not just technology, but trust. IPC segmented teams by maturity, nurtured early adopters, and embedded themselves into community discussions. Lead engineers began gathering on their own to discuss ideas. IPC joined them and turned those conversations into working groups that shaped best practices and platform direction.
This collaborative approach turned Kong from a tool into a shared ecosystem, built with teams instead of for them.

A faster, more resilient ecosystem and a culture of shared ownership
ING’s move from a monolithic architecture to an API-driven platform has delivered significant improvements across performance, engineering efficiency, and organizational alignment.
Dramatically improved performance and stability
By routing traffic through Kong, ING has nearly eliminated the UI latency issues that once plagued internal teams. Behrens said that the “spinning wheel of death is almost gone,” with a modern UI now communicating with backend systems through a stable gateway layer. Critical services respond faster, and deployments are no longer bottlenecked by the monolith.
Streamlined engineering workflows with fewer or no errors
Gateway configurations deploy automatically through CI/CD, leading to cleaner, more predictable releases. Teams no longer juggle separate tools or manual steps, resulting in:
Faster onboarding
Reduced misconfigurations
Consistent implementation across teams
The platform now supports the velocity expected in a modern digital bank.
“The goal is not just to have a gateway, but a full API management solution this time, built with our teams, not for them.”
Stronger compliance and built-in security
Centralized governance ensures every API follows ING’s standards for authentication, traffic management, and observability. Teams innovate independently, but within a framework that guarantees regulatory and operational safety.
A more collaborative engineering culture
Early adopters, architects, and product owners have formed a strong internal community around the Arch. Instead of isolated pockets of innovation, ING now has shared patterns, reusable components, and a cross-team dialogue that accelerates delivery.
The shift wasn’t just about moving from dependency to partnership, but a cultural transformation that helped platform and product teams come hand in hand to contribute to one another’s success.
A foundation for ING’s future digital capabilities
Beeren shared that their API management platform has grown beyond gateway functionality. IPC is extending it to include:
Predictive analytics on logs and traces
A full-fledged developer portal for discoverability
Automated consumption models tied to governance
Every addition is evaluated through the same lens: it must empower teams while preserving the governance the bank requires.
“When we started this journey, the spinning Wheel of Death wasn't just an annoyance—it was a symptom of everything broken within our landscape: slow deployments, dependent teams. Today, the spinning wheel of death is almost gone.”