Fiserv — Always-On Digital Banking at 10-Million-User Scale

01 The Challenge

Fiserv processes core banking for thousands of financial institutions. When a mainframe core goes down for maintenance or migration, the banks that run on it need their customers’ online and mobile banking to keep working anyway. Fiserv set out to build a cloud-native stand-in system: a platform that continuously ingests account and transaction data from many different core banking platforms, stores it in the cloud, and serves digital banking traffic in the core’s place.

The numbers made it hard. The platform had to be designed for 2,000+ banks and roughly 10 million end customers, ingest large extract files from multiple heterogeneous core formats, isolate every tenant, protect PII to a bank-regulator standard, and stand up fast — with a distributed team of more than sixty engineers across onshore and offshore.

02 The Approach

Leopard Data served as the top technologist responsible for overall technical delivery. The first deliverable was the system specification itself — the document that turned Fiserv’s goals into an architecture the program could execute: file ingestion from Sterling File Gateway into Azure Blob Storage, parallelized parsers for the core extract formats, a Cosmos DB data layer designed for multi-tenant scale, REST services for accounts and transactions, and event-driven processing throughout.

Key architecture decisions were made in the open with Fiserv’s architects. We wrote the formal Kubernetes/KEDA vs. serverless comparison that drove the compute model decision, designed the import pipeline to parse banking files in parallel without losing transaction ordering, led the Cosmos DB design sessions, and designed the tenant onboarding and rollback machinery to scale to 2,000 future tenants. To de-risk the autoscaling model we stood up KEDA with Kubernetes locally and validated the pattern before the program committed to it.

Security was designed in, not bolted on: format-preserving encryption for PII fields (Voltage), a documented SFG-to-Blob transfer design with security controls, secrets management, and OAuth 2 service authorization. The architecture passed Fiserv’s formal security review for a platform fronting 2,000 banks.

03 The Delivery

Running a 60+ person program remotely takes communication discipline. Leopard Data ran daily onshore/offshore coordination, weekly code reviews wired into Azure DevOps notifications across every repository, formal pull-request reviews, and technical design reviews with Fiserv leadership on each deliverable component — and translated the technology into plain English for program leadership every day.

We also stayed hands-on in the code: REST services for retrieving imports by tenant, the Cosmos DB import rollback function running on KEDA/Kubernetes, and demo applications proving the data layer. When the program needed to show progress at the top, Leopard Data ran the importer demo live for the Fiserv CIO — the executive sponsoring the project.

05 Tech Stack