Sibos 2026: Why scalability and resiliency is more important than ever

Another Sibos has been and gone. And now it’s time for the industry to digest and reflect on the interesting conversations that began at this year’s event.

Conversations at Sibos highlighted some illuminating insights and opinions on key themes impacting the industry, particularly surrounding digital assets, AI in payments, finding the balance between buy vs build and how payments types are becoming more fluid and interchangeable.

At Sibos, it was a pleasure to take to the stage and share some insights into the world of non-functionals in our session ‘Scale without sacrifice: architecting high-volume, always-on payment systems’, accompanied by MongoDB’s Luis Pazmiño Días, Industry Principal for Financial Services.

During the session we explored a significant challenge facing banks: how do you scale payments without sacrificing performance, resilience or cost efficiency?

As transaction volumes grow and instant payments become the norm, payments infrastructure needs to operate 24/7, handle significant increases in demand and recover quickly when things go wrong. That puts growing pressure on legacy platforms designed around batch processing with less stringent SLAs.

Scaling starts with architecture

A key message from the session was that scalability is not simply about adding more processing power. It starts with how the payments estate is designed.

That means segregating the value chain (order management, execution and clearing & settlement) and logically breaking up different payment types, e.g. bulk instructions vs. individual instructions, so that they can be scaled independently. It also means simplifying processing flows and data exchanges, while using modern architectural patterns and technologies to support distributed processing, resilience and low latency.

The goal is to create an architecture where increased volume or a failure in one component does not bring the entire payments process to a halt.

Putting the theory to the test

Our benchmark with MongoDB put these principles into practice. We tested an Icon payment solution run with MongoDB, under increasing transaction volumes and simulated failures.

The platform achieved 6,000 transactions per second (TPS), equating to almost 430,000 database operations per second. Each transaction involved 12 steps (events), reflecting the complexity of a real payment journey, including balance verification, core banking integration and fraud detection.

The benchmark also tested resilience. In this test, we ran the application at 3,500 TPS and simulated an application node failure. The test proved that IPF and MongoDB suffered zero data loss as a result of the successful transaction rebalancing in the cluster and the throughput recovered to 3,500 TPS in just 90 seconds.

Latency remained relatively stable as volumes increased, with average (P50) end-to-end latency of 0.39 seconds at 500 transactions per second, rising to 0.51 seconds at 6,000 transactions per second.

The results provide a useful reference point for what is possible when scalability and resilience are designed and embedded within the architecture from the outset.

The key takeaways from our benchmark report were covered “at a glance” during the session but here’s a closer look at the 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.

Building for what comes next

The broader lesson from our benchmark, and one we explored during our Sibos session, is that payments modernisation cannot be treated purely as a functional exercise - a sentiment that was echoed by other industry experts at the event.

Banks need infrastructure that can scale as volumes grow, maintain low latency under pressure, recover quickly from failure and operate continuously. It also needs to support new payment schemes without significant redevelopment, to make sure that no transaction is lost along the way

Scaling without sacrifice requires more than powerful technology. It requires the right architecture, the right technology and the right approach to designing the payments estate.

The questions raised during the Q&A reflected the growing focus on how banks can build payment infrastructure that is ready for what comes next. The non-functional requirements of payments infrastructure can often be taken for granted, but as transaction volumes continue to grow exponentially, these capabilities will become increasingly critical.

Agile platforms that can adapt to evolving payment schemes and technologies will be essential for banks looking to build resilience, scale effectively and keep pace with a rapidly changing payments landscape. And significantly, the architecture is as important as the platform itself for evolving a bank’s capabilities.

It was great to be involved in Sibos this year to share key findings from our benchmark report and thank you to all who joined us for the session. Now it’s time to rest, recharge and get ready for next year.

Afraid you’re missing out? Read the full benchmark report, Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments (Instant Payments Benchmark 2026), by following this link.