The rapid migration of account-to-account payment volumes toward instant settlement rails is forcing financial institutions to confront a difficult reality: legacy architectures and self-built systems often struggle to maintain the low latency and high availability required by modern scheme SLAs. To address this, Icon Solutions and MongoDB have released joint benchmark results demonstrating that the Icon Payments Framework (IPF), running on MongoDB Atlas, can process 6,000 end-to-end payment transactions per second. This performance level was achieved with a mean end-to-end latency of 0.51 seconds and, crucially, zero data loss during simulated application and database node failures. For Tier 1 banks, this provides a technical blueprint for managing sharper traffic peaks and the strict uptime requirements of an always-on, instant-payment economy.
Icon Payments Framework Achieves High-Throughput Benchmarks
The joint benchmark utilized a reference SEPA Instant outbound payment flow, requiring each transaction to complete 12 distinct processing steps. These steps included duplicate checking, message and scheme-rule validation, fraud and sanctions screening, FX retrieval, funds reservation and booking, and scheme message generation. To achieve the 6,000 transactions per second (TPS) business throughput, the underlying infrastructure managed approximately 430,000 database operations per second. This workload was distributed across two MongoDB Atlas clusters: the IPF Event Journal, which handled roughly 236,000 operations, and the IPF Operational Data Store, which managed approximately 196,000 operations.
The testing methodology employed a "ladder" approach, scaling from 500 to 6,000 TPS to observe how throughput, latency, and database load behaved at every increment. The results indicated near-linear, predictable scaling, where per-shard CPU and insert rates rose in proportion to the load, while latency remained essentially flat until reaching the 6,000 TPS ceiling. At this peak, the system maintained significant operational headroom; hot-shard CPU utilization on MongoDB Atlas sat at approximately 50%, and IPF payment service pods operated at roughly 60%. Furthermore, the benchmark demonstrated that moving from MongoDB Atlas 8.0 to 8.3 could reduce persistence latency by approximately 50%, dropping from 40 milliseconds to 20 milliseconds at a load of 4,000 TPS.
Resilience and Recovery in Instant Payment Environments
As transaction volumes shift from net-settlement to instant schemes, the margin for error regarding downtime and data integrity has effectively vanished. The Icon Solutions and MongoDB benchmark specifically tested system resilience by executing failure scenarios under live transaction loads. During a test at 3,500 transactions per second, the IPF recovered from an ungraceful application node failure in under 90 seconds and from a planned node shutdown in approximately 60 seconds. In both instances, the framework achieved a terminal state for every transaction with zero data loss and no requirement for manual intervention, utilizing shard rebalancing to redistribute in-flight transactions.
The database layer also demonstrated rapid recovery capabilities. A MongoDB Atlas primary node failover, conducted using built-in failover testing, completed in an average of five seconds. Throughout this process, payment processing continued without application restarts or data loss. This level of resilience is positioned as a direct alternative to the challenges institutions face when attempting to retrofit legacy platforms for always-on processing. The architecture relies on a distributed, scale-out model using 12 application pods on Kubernetes across three availability zones, employing Akka for fault-tolerant processing and Kafka to stream data to the Operational Data Store. By utilizing event-sourcing and CQRS patterns, the system is designed to handle the continuous availability requirements of modern banking.
Key Takeaways
- The Icon Payments Framework (IPF) on MongoDB Atlas processed 6,000 end-to-end payment transactions per second with a mean latency of 0.51 seconds.
- The system demonstrated zero data loss during recovery from both application node failures (under 90 seconds) and planned node shutdowns (approximately 60 seconds).
- Database operations reached approximately 430,000 per second, supported by two MongoDB Atlas clusters utilizing M80-class tiers with 32 vCPUs and 128 GB of RAM.
FinanceInsyte's Take
In our view, this benchmark highlights a critical inflection point for institutional payment infrastructure. As regulators and consumer expectations drive the adoption of instant settlement, the "build vs. buy" debate for banks is shifting toward "modernize vs. replace." The ability to demonstrate 6,000 TPS with sub-second latency and—more importantly—guaranteed data integrity during node failure addresses the primary fear of C-suite executives: the operational risk of instant payments. This signals that the future of high-volume financial messaging lies in cloud-native, event-driven architectures that treat data as a dynamic stream rather than a static record. For banks currently struggling with the "leap into the unknown" when scaling legacy systems, this benchmark provides a validated path toward predictable, linear scalability that can be planned through infrastructure rather than guesswork.
Questions & Answers
How does the Icon Payments Framework handle transaction integrity during a system failure?
The framework utilizes a distributed architecture with event-sourcing and CQRS patterns. During a failure, such as an ungraceful application node failure, the system uses shard rebalancing to redistribute in-flight transactions to remaining nodes and rehydrates their state from persisted events, ensuring zero data loss without manual intervention.
What are the specific latency implications for instant payment scheme compliance?
The benchmark recorded a mean end-to-end latency of 0.51 seconds at a peak of 6,000 TPS. This is significantly lower than the typical 10-second window allowed by many instant payment schemes, providing a substantial buffer for banks to meet strict Service Level Agreements (SLAs).
Can the demonstrated 6,000 TPS capacity be scaled further for larger institutions?
Yes. The benchmark suggests that capacity can be expanded by further sharding and segregating services. This includes separating bulk payments from individual payments, splitting flows between initiation and clearing, or separating services geographically, with each segregated service capable of several thousand TPS.
What technical components underpin the high-throughput database performance?
The performance is driven by MongoDB Atlas running on M80-class tiers (32 vCPUs, 128 GB RAM) across two clusters: a five-shard IPF Event Journal and a six-shard IPF Operational Data Store. The architecture also leverages Akka for concurrent processing and Kafka for streaming data to the operational store.
Source: Businesswire
