Icon Solutions and MongoDB have released results from a joint benchmark. The benchmark showed IPF processing 6,000 payments per second end to end. The Icon Payments Framework (IPF) ran on MongoDB Atlas during the benchmark. It processed about 430,000 database operations every second. The platform also recorded mean end-to-end latency of 0.51 seconds. Additionally, it recovered from application and database node failures without losing data.
Account-to-account payment volumes continue moving toward instant payment rails. Meanwhile, traffic is shifting from net-settlement schemes to instant schemes. Direct debit volumes are also expected to partly move toward request-to-pay models. These models can use instant schemes for settlement. As a result, banks face sharper traffic peaks across their payment infrastructure. They also handle more transactions subject to payment scheme SLAs.
Many of those SLAs require processing within only a few seconds. Therefore, payment platforms must maintain availability during intense transaction periods. Banks also have little tolerance for downtime in instant payment environments. However, institutions often underestimate the infrastructure required for several thousand transactions per second.
Legacy platforms create another challenge for financial institutions. Retrofitting those systems for continuous processing can require significant effort. IPF addresses these requirements through a cloud-native, event-driven architecture. Tier 1 banks, including Citi, NatWest and BNP Paribas, trust the framework. The platform was designed for environments requiring scale, resilience and continuous availability. The latest benchmark specifically tested those capabilities under demanding conditions.
“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.”
Benchmark Tests Instant Payment Processing at Scale
The benchmark followed a reference SEPA Instant outbound payment flow. Each payment completed 12 individual processing steps. Those steps included duplicate checking and message validation. The flow also covered scheme-rule validation and fraud screening. Sanctions screening formed another part of the process. The workflow also included FX retrieval, funds reservation and booking.
Finally, the process generated the required scheme message. Simulators represented the bank’s surrounding systems during the benchmark. IPF and MongoDB Atlas completed a ladder test during the evaluation. The test increased target throughput from 500 to 6,000 payment transactions per second. This approach allowed the teams to observe performance throughout the testing range. They measured throughput, latency and database load at every stage.
The teams then introduced failure scenarios under live transaction loads. This helped evaluate how the platform handled operational disruptions. The benchmark produced several significant findings for banks and payment service providers. 6,000 payments per second end to end. IPF processed 6,000 payment transactions every second. Each transaction completed all 12 required processing steps. That throughput required approximately 430,000 database operations per second. Two MongoDB Atlas clusters supported this database activity.
The IPF Event Journal performed around 236K operations/sec. Meanwhile, the IPF Operational Data Store was running about 196,000 operations per second. There was still latency in instant payment SLA’s. The average end-to-end latency at the peak throughput was 0.51 seconds. That was still far short of the 10-second window usually provided by instant payment schemes. Persistence latency was below 30 milliseconds at peak load.
That scaling was predictable. Both application and database performance scaled from 500 transactions per second to 6,000 transactions per second. CPU and insert rate per shard increased proportionally at each ladder step. Latency also stayed pretty consistent until the highest throughput we tested. This behavior gives banks a greater degree of confidence when forecasting infrastructure needs. It also supports capacity planning via measurable infrastructure growth.
IPF Remains Resilient in Face of Application and Database Failures
The benchmark also showed spare capacity at peak load. MongoDB Atlas hot-shard CPU utilization remained at ~50%. IPF payment service pods were operating at around 60% utilization. There was no write queue build up in WiredTiger during the peak of the test. Replication lag was also low during the whole benchmark. The results showed that the platform has more operational headroom. Failure recovery with zero data loss. IPF processed 3,500 transactions per second for application failures.
The framework that recovered from an ungraceful application node failure in under 90 seconds. It also recovered from a planned node outage in about 60 seconds. In both cases, every transaction achieved a final state. The tests caused no data loss and needed no manual intervention. IPF’s shard rebalancing redistributes in-flight transactions to remaining nodes. The framework then rehydrates transaction state from persisted events .
Seconds of database fail over. MongoDB Atlas also performed a primary node failover test. For this situation, the team used the built-in failover test of Atlas. Customers can run this test independently in their environments. The failover was on average about five seconds. Payment processing was ongoing for the duration of the event. The test also showed no loss of pay. Also applications did not need to be restarted after the database failover.
Platform wins drive payment performance. The benchmark also compared MongoDB Atlas 8.0 vs 8.3. Upgrading to MongoDB Atlas 8.3 cut persistence latency in half. Latency was halved from around 40 milliseconds to 20 milliseconds. The improvement came at 4,000 transactions processed a second. Thus, the upgrade of the platform can directly improve the performance of payment processing.
Distributed Architecture Supports Future Payment Growth
For banks and payment service providers, the results have practical implications. They can plan capacity using measured performance instead of relying on assumptions. They can also recover from failures without manual intervention. At the same time, they gain another path toward modern payment infrastructure. This approach can reduce the need to build payment platforms entirely in-house. It can also avoid extensive retrofitting of legacy systems.
The benchmark results depend heavily on the underlying architecture. The teams used distributed scale-out infrastructure instead of oversized hardware. IPF operated 12 application pods on Kubernetes across three availability zones. All three zones operated within one cloud region. Akka supported concurrent and fault-tolerant processing across the environment. The IPF Connector Framework also used back-pressured streams.
These streams helped prevent downstream systems from becoming overwhelmed. The protected systems included fraud, sanctions and accounting platforms. Kafka streamed processing data into the Operational Data Store. Meanwhile, persistence followed event-sourcing and CQRS patterns. MongoDB Atlas supported both major IPF data components. The IPF Event Journal operated on a five-shard cluster.
The IPF Operational Data Store was on a six shard cluster. Each shard was configured with a 32 vCPUs and 128 GB of RAM M80-class tier. Banks can be scaled further by additional sharding. It can also split services into different payment criteria. For example, institutions may make a distinction between bulk payments and payments made to individuals. They can also split payment initiation, execution and settlement flows.
Geographical separation provides another potential scaling approach. Therefore, the benchmark provides a path beyond 6,000 transactions per second. Banks and payment service providers can use separate services for additional capacity. Each segregated service can support several thousand transactions per second independently.
“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.”
Explore Finance Tech News for the latest innovations in financial technologies and expert insights shaping the future of digital finance!
News Source: Businesswire.com
