[September 08, 2026]

Icon Solutions and MongoDB Benchmark Shows IPF Processing 6,000 Payments per Second with Zero Data Loss Under Failure

Icon Solutions and MongoDB today published the results of a joint benchmark showing that the Icon Payments Framework (IPF), running on MongoDB Atlas, processed 6,000 end-to-end payment transactions per second (around 430,000 database operations per second) with a mean end-to-end latency of 0.51 seconds, and recovered from both application and database node failures with zero data loss.

Account-to-account payment volumes are moving rapidly onto instant rails. Traffic is migrating from net-settlement schemes to instant schemes, and direct debit volumes are expected to partially move to request-to-pay with settlement through instant schemes. For banks, that means sharper traffic peaks, a growing share of payments bound to scheme SLAs of a few seconds, and no tolerance for downtime. Sustaining several thousand payments per second while maintaining resilience, availability and low latency is routinely underestimated by institutions that self-build, and retro-fitting legacy platforms for always-on processing is a significant challenge.

IPF is an internationally proven payments development framework trusted by Tier 1 banks including Citi, NatWest and BNP Paribas. Built on a cloud-native, event-driven architecture, it was designed from the outset for environments where scale, resilience and continuous availability are baseline requirements. The benchmark was designed to test exactly that.

The benchmark used a reference SEPA Instant outbound payment flow in which every payment completes 12 individual processing steps - including duplicate checking, message and scheme-rule validation, fraud and sanctions screening, FX retrieval, funds reservation and booking, and scheme message generation - with the bank's surrounding systems represented by simulators. IPF and MongoDB Atlas were run through a "ladder" test from 500 to 6,000 target payment transactions per second, so that throughput, latency and database load could be observed at every stage rather than only at peak. Failure scenarios were then executed under live transaction load.

Key findings

• 6,000 payments per second, end to end. IPF processed 6,000 payment transactions per second, each completing all 12 processing steps. That business throughput was underpinned by around 430,000 database operations per second across two MongoDB Atlas clusters: roughly 236,000 on the IPF Event Journal and 196,000 on the IPF Operational Data Store.
• Latency well inside instant payment SLAs. Mean end-to-end latency at 6,000 transactions per second was 0.51 seconds, a fraction of the 10-second window that instant payment schemes typically allow. Persistence latency stayed below 30 milliseconds even at peak.
• Near-linear, predictable scaling. From 500 to 6,000 transactions per second, application and database scaled in lockstep: per-shard CPU and insert rates rose in proportion with each step of the ladder, and latency stayed essentially flat until the top of the range. Capacity can therefore be forecast with confidence and growth planned as a function of infrastructure rather than a leap into the unknown.
• Headroom to spare. At peak load, hot-shard CPU utilisation on MongoDB Atlas sat at around 50%, IPF payment service pods ran at around 60%, the WiredTiger write queue stayed at zero and replication lag remained low throughout.
• Recovery from failure with zero data loss. Under a live load of 3,500 transactions per second, IPF recovered from an ungraceful application node failure in under 90 seconds and from a planned node shutdown in around 60 seconds. In both cases every transaction reached a terminal state with zero data loss and no manual intervention: IPF's shard rebalancing redistributes in-flight transactions to the remaining nodes and rehydrates their state from persisted events.
• Database failover measured in seconds. Separately, a MongoDB Atlas primary node failover - run using Atlas's built-in failover test, which customers can run themselves - completed in about 5 seconds on average, with payment processing continuing throughout and no payment loss or application restarts.
• Platform gains translate directly into payments performance. Moving from MongoDB Atlas 8.0 to 8.3 reduced persistence latency by about 50% - from around 40 milliseconds to around 20 milliseconds at 4,000 transactions per second.

The results were achieved through a distributed, scale-out architecture rather than oversized hardware. IPF ran as 12 application pods on Kubernetes across three availability zones in a single cloud region, using Akka for concurrent, fault-tolerant processing, the IPF Connector Framework's back-pressured streams to keep downstream fraud, sanctions and accounting systems from being overwhelmed as load climbed, and Kafka to stream processing data to the Operational Data Store. Persistence follows event-sourcing and CQRS patterns, with MongoDB Atlas backing both the IPF Event Journal (a five-shard cluster) and the IPF Operational Data Store (a six-shard cluster). Each shard ran on an M80-class tier with 32 vCPUs and 128 GB of RAM.

Capacity can be added by sharding further and by segregating services: separating bulk from individual payments, splitting flows across payment initiation, execution and clearing, or separating geographically. The benchmark therefore points to a clear path beyond 6,000 transactions per second for the banks and payment service providers that need it. Each segregated service is capable of several thousand transactions per second in its own right.

"Banks need payment infrastructure that can adapt to an instant economy," said Toine van Beusekom, Strategy Director at Icon Solutions. "Yet sustaining thousands of payments per second while maintaining resilience, availability, scalability and ultra-low latency is not easy, particularly for institutions relying on legacy architecture or building everything themselves. This benchmark demonstrates that IPF offers an alternative approach that has been designed to meet the unprecedented demands of an always-on world, enabling banks to lead payments forward with confidence."

"At 6,000 payments per second, the data layer handles nearly half a million database operations a second, with five-second node failure recovery and zero data loss," said Boris Bialek, Vice President of Industries and Global Field CTO, MongoDB. "Instant payments require a dynamic, event-driven data foundation, not simply a static system of record, and this benchmark shows what MongoDB delivers in real time, with headroom to spare. Scale, resilience, and operational performance in a single managed platform. That is the engine of modern payments."

Access the benchmark report: Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments.

The complete dataset, including the full metrics ladder for every step from 500 to 6,000 payment transactions per second and further detail on how the results were achieved, is available on request from Icon Solutions or MongoDB.

About Icon Solutions

Icon Solutions is a fintech company that has been designing and implementing state-of-the-art payments systems since 2009. Its core product, the Icon Payments Framework (IPF), is an internationally proven payments development framework trusted by Tier 1 banks including Citi, NatWest and BNP Paribas. IPF helps banks accelerate the transformation of their payments infrastructure by enabling them to build, test and deploy payment processing solutions faster while maintaining control of timelines and costs.

About MongoDB

MongoDB, headquartered in New York, is focused on helping innovators create, transform, and disrupt industries with software. Its unified, intelligent data platform is built to power the next generation of applications, with integrated capabilities for operational data, search, real-time analytics, and AI-powered retrieval. Millions of developers and more than 67,000 customers across nearly every industry, including roughly 75% of the Fortune 100, rely on MongoDB for their most important applications.

View source version on businesswire.com: https://www.businesswire.com/news/home/20260908361272/en/

[ Back To TMCnet.com's Homepage ]