BIS Tests Settlement Engine at 10,000 TPS: What OTC Desks Should Understand About Execution Architecture
When a $2 million crypto or FX ticket hits a brokerage's OTC desk and gets sliced into six tranches across six price points, the standard explanation is market depth. The order book couldn't absorb the flow at a single price. Liquidity was thin. The market moved.
But the BIS has just spent months testing whether the real constraint might be upstream, in the settlement architecture itself. Project FuSSE (Fully Scalable Settlement Engine) is a BIS Innovation Hub project that aims to modernise financial market infrastructures for the demands of the digital age. The proof-of-concept, released this week, explored whether modular, microservices-based systems could handle complex, high-volume flows without the kind of architectural fragmentation that destroys execution integrity.
The results matter for anyone running a dealing operation. The design allows for integration into various usage scenarios, from payment systems to securities settlements. Whether it's more transactions, an increasing number of participants, or a diverse range of asset types, FuSSE is designed to be a system that can grow. In controlled testing, the architecture demonstrated the feasibility of processing high transaction volumes, 10,000 transactions per second, while scaling computing resources less than proportionally as throughput increased.
That sub-linear scaling characteristic matters. Traditional settlement systems often hit performance walls where each incremental increase in volume demands disproportionate increases in resources, latency, and operational complexity. Those walls don't just slow things down, they create the pressure points that force large orders to fragment.
Project FuSSE aims to design and test backend functionality that can be adapted to multiple types of infrastructures, allowing them to process a continuously growing number of transactions. FuSSE aims to test highly scalable systems in three dimensions: the number of transactions, the types of assets and the number of participants. The architecture enables independent scaling of individual services, including cryptographic services, illustrating one way to manage performance bottlenecks that would otherwise force execution flows to break apart.
The operational reality for OTC desks is familiar. Liquidity refers to how easily an asset can be bought or sold without affecting its price. In a highly liquid market, there are plenty of buyers and sellers at various price levels, so large orders can be filled near the expected price. In a low-liquidity environment there may not be enough orders near your desired price. Your order then "eats through" the order book, matching with progressively worse prices until it's filled. Large orders consume liquidity across multiple price levels, depleting the best available prices and forcing subsequent portions of the trade to execute at progressively worse rates.
The standard response has been to treat this as a market condition to be managed, splitting orders into smaller pieces, using TWAP or VWAP algorithms, timing execution for periods of deeper liquidity. For substantial trades, over-the-counter desks offer a practical solution to minimise slippage and market disruption. Unlike public exchanges, OTC trading occurs directly between buyers and sellers without involving the exchange's order book. OTC desks exist precisely to handle this: fixed quotes, off-book execution, no information leakage to the market.
But here's the question Project FuSSE forces: what if the tranche-by-tranche execution isn't primarily a market depth issue, but an infrastructure constraint masquerading as one? If the settlement layer can't maintain execution integrity at scale, if the architecture itself creates pressure to fragment flows, then no amount of clever order routing solves the underlying problem.
In its first phase, the project delivered a proof-of-concept for a basic settlement mechanism. This was developed as a modular flexible architecture incorporating quantum-resistant cryptography. The BIS report is explicit that this is experimental infrastructure, not production-ready. It does not assert compliance with the Principles for Financial Market Infrastructures (PFMI) or define operational models. But the proof-of-concept demonstrates that clear service boundaries facilitate future adaptation to evolving security, message, and regulatory requirements, the kind of adaptability that legacy monolithic systems struggle to achieve.
The report also highlights trade-offs. Microservices increase operational complexity and attack surface. Post-quantum cryptography, which FuSSE incorporates for future-proofing, can add computational and bandwidth overhead. The architecture requires careful orchestration and adaptable governance frameworks.
Central banks are paying attention to these questions. At the Tokenisation Summit, Sasha Mills outlined the innovation priorities for the coming year: progressing the systemic stablecoins regime, clarifying how tokenised collateral can operate under UK EMIR, and expanding the Digital Securities Sandbox. The Bank of England's Executive Director for Financial Market Infrastructure has signalled that 2026 will be "fundamental in shaping the UK's digital financial future." The Bank views digitalisation of wholesale financial markets as a way to improve their function and efficiency through the use of new and innovative approaches to technologies and using data. Tokenisation of assets and smart contracts on programmable and shared ledgers can deepen existing markets, unlock new ones, and change how asset classes, capital, and balance sheets can be mobilised within the financial system.
The implication for dealing desks isn't that Project FuSSE offers a solution to deploy next quarter. It doesn't. In the technology area, FuSSE will support the development of financial technology and market infrastructures to reduce the costs of implementing complex infrastructures, promote standardisation, and create solid foundations on which additional elements can be built to integrate more advanced financial services. The modular architecture of the tool will give each central bank the flexibility to choose which elements to implement and the possibility to adapt the system's functions to local needs.
The implication is diagnostic. If central bank researchers are building settlement engines that maintain execution integrity at 10,000 TPS without fragmenting flows, then the fragmentation you see in your own operation, the six tranches, the six price points, the slippage your desk calls unavoidable, might be more design artifact than market necessity.
The question worth sitting with: how much of what your desk treats as a liquidity problem is actually an infrastructure problem you've been treating as normal?
