Multinational Banking Corporation Accelerates Digital Transformation with GridGain

A leading multinational banking and financial services corporation faced a fundamental infrastructure dilemma: legacy mainframe systems that had run reliably for decades were no longer capable of supporting the explosion in digital banking demand. Mobile usage alone had grown 7x, PSD2 open banking regulations were adding unpredictable external load, and a looming shift to distributed Linux infrastructure meant high availability could no longer be guaranteed at the hardware layer. The bank chose GridGain (built on Apache Ignite) as a strategic in-memory computing platform — deploying it across multiple mission-critical workloads including mainframe shielding, SEPA Direct Debit processing, real-time payments, and a bank-wide internal developer service.

Legacy Infrastructure at Breaking Point

The bank's core banking systems — customer data, payment processing, and account management — had been running on mainframes for over 20 years. These systems were deeply embedded across the organization and could not easily be replaced. Yet several converging forces were pushing the infrastructure beyond its limits:

• Explosive Growth in Digital Interactions: The migration of customers from browser to mobile banking multiplied per-customer interaction rates by a factor of seven, increasing overall load on back-end systems dramatically.
• PSD2 Open Banking Mandate: The European Commission's Payment Services Directive (PSD2) required the bank to expose account and transaction data via APIs to authorized third-party providers, adding large, unpredictable external load on top of existing customer demand.
• Unacceptable Integration Latency: The bank's TIBCO-based middleware integration layer introduced 200—300ms latency on every transaction. Attempts to vertically scale the mainframe showed it had reached its theoretical ceiling — a 3x capacity increase was not achievable.
• Loss of Infrastructure-Level High Availability: The bank's IT infrastructure team announced that dedicated HA hardware clusters (Sun, AIX, Windows) would be decommissioned in favor of standard Linux boxes. High availability would have to be achieved at the software layer, not the hardware layer.
• Regulatory Data Center Distance Requirements: The European Commission required disaster recovery data centers to be at least 15—50 km apart (up from 5 km), forcing a shift from synchronous to asynchronous replication — increasing the complexity of maintaining four-nines (99.99%) availability.
• SEPA Direct Debit Volume Surge: As a central processing hub for multiple banks in its group, the bank's SEPA Direct Debit volumes spiked from 10 million to 100 million transactions per month, with peak days reaching 16 million transactions requiring processing within a strict daily cut-off window.
• Internal Branch Centralization Load: Migrating 6,000—7,000 branch staff from a fat-client, branch-partitioned system to a centralized web application suddenly added thousands of concurrent internal users to the same systems already serving retail customers.

GridGain as a Multi-Workload In-Memory Platform

The bank selected GridGain — combining open-source Apache Ignite with GridGain commercial capabilities — as its strategic in-memory computing foundation. GridGain's combination of in-memory data grid, distributed compute, Java-native architecture, professional support, and open-source foundation aligned with the bank's technology strategy. Deployments spanned four distinct use cases:

1. Mainframe Shielding

The bank's most strategic GridGain deployment, "Shielding," created a high-performance caching and data distribution layer in front of the legacy mainframe. Rather than requiring real-time mainframe access for every API call, data mutations were pushed to the GridGain cluster via a Kafka event bus and held in-memory, pre-transformed for downstream consumption. Benefits included:

• Mainframe offload — serving customer and reference data from the in-memory layer without touching the mainframe on every request
• Push-based freshness — data updated at the source was pushed to the cache immediately, guaranteeing consistency
• Colocation of compute and data — transformations executed where data resided, eliminating network round-trips
• Cassandra used as a persistent backing store for non-critical session and reference data

2. SEPA Direct Debit Processing

To handle exploding direct debit volumes — up to 16 million transactions on peak days, processed within a fixed daily cut-off window — the bank implemented a parallel processing pipeline on GridGain. ISO 20022 XML files were ingested via Kafka, parsed by distributed compute tasks, validated using colocation-aware affinity routing, and made queryable in real time via SQL-based REST APIs for both internal staff and PSD2-compliant third parties.

3. Real-Time Payments Gateway (SEPA Instant)

The SEPA Instant Payment initiative mandated end-to-end payment settlement between banks in under five seconds. The bank deployed GridGain as a high-throughput transformation engine bridging the external STET settlement network to its internal mainframe payment engines. The distributed compute layer — without maintaining a large persistent data store — handled ISO-to-COBOL format translation and back, processing millions of concurrent messages within the five-second SLA.

4. GridGain as a Developer Service

Recognizing GridGain's growing adoption across internal teams, the bank's infrastructure "Building Blocks" team productized it as an internal developer service. Engineers received standardized Docker images pre-configured with GridGain dependencies, the GridGain Web Console for monitoring, and company-standard encryption and security — reducing time-to-production for new GridGain-based applications.

Scalable, Real-Time Banking Infrastructure Delivered

Performance and Throughput

• 10x Acceleration in Direct Debit Processing: The GridGain-based pipeline processed 10 million transactions per hour — a transformation from what the legacy platform could sustain, enabling the bank to confidently absorb 100 million transactions per month across its group hub.
• 7x Increase in Digital Load Absorbed: The Shielding layer successfully absorbed the seven-fold increase in customer digital interactions without requiring mainframe scaling, decoupling front-end demand from back-end capacity constraints.
• 200—300ms Middleware Latency Eliminated: By moving data transformation to the in-memory layer and removing TIBCO as a blocking middleware, the bank eliminated the primary latency bottleneck in its electronic banking stack.
• Sub-5-Second SEPA Instant Payment Processing: The Real-Time Gateway met the SEPA Instant mandate, processing high-volume ISO/COBOL message transformation within the required five-second round-trip window.
• 73% Improvement in Data Retrieval Performance: Benchmarking of in-memory distributed queries versus relational database access demonstrated a 73% reduction in data retrieval time, with further gains from distributed query parallelism.

Architectural and Operational Impact

• Software-Level High Availability: GridGain's built-in clustering and replication capabilities enabled the bank to meet four-nines availability requirements on commodity Linux infrastructure — without reliance on proprietary HA hardware.
• PSD2 and Open Banking Readiness: The Shielding and Direct Debit platforms exposed data via REST/SQL APIs, positioning the bank to comply with open banking requirements and onboard third-party PSD2 consumers.
• Scalable Multi-Cluster Architecture: After initial experience with a single shared cluster, the bank adopted a multi-cluster model, allowing individual application teams to deploy and upgrade independently — aligning software architecture with agile delivery cadences.
• Internal Developer Productivity: The GridGain-as-a-Service offering standardized in-memory infrastructure for internal engineering teams, reducing setup overhead and accelerating time to production for new workloads.