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](https://konghq.com/blog/news/api-summit-2025-recap)API Summit 2025, Mark Beerens, 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.

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,” Beerens 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,” Beerens 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,” Beerens 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](https://konghq.com/resources/e-book/monolith-to-microservices-migration)monolithic systems to microservices, create consistency across teams, and empower developers while maintaining a strong security and compliance posture.

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.

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.

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.”

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," Beerens said.

These guardrails allow teams to move quickly while maintaining compliance. Boundaries became a core part of enabling responsible autonomy.

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.

ING’s move from a monolithic architecture to an API-driven platform has delivered significant improvements across performance, engineering efficiency, and organizational alignment.

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.

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.

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.

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.

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.