Rust in banking and insurance: Choosing which bill to pay

By Alexander Walter (ERNI Switzerland)

For decades, financial institutions have relied on different technologies for different types of systems. C++ remains a natural choice for trading and other systems where every fraction of a millisecond matters. Java has become a mainstay of enterprise applications thanks to its reliability, maintainability and developer productivity. Both have served the financial industry well, both make different trade-offs.

Today, banks and insurers are under pressure from several directions at once. Technology landscapes need to be integrated and modernised for the open banking era. Operational resilience and cybersecurity are receiving ever greater regulatory attention. At the same time, the growth of AI and increasing environmental, social, and governance (ESG) expectations are putting greater focus on how efficiently computing resources are used. All these developments have something in common: they make the economics of software more important.

Rust combines native execution with strong memory-safety guarantees in safe code and modern language features. For banks and insurers, this does not make Rust a general replacement for C++, Java or Go. It makes Rust a candidate for selected components where security exposure, tail latency or resource consumption has become material enough to justify another technology stack.

Finance runs on two clocks

Financial institutions operate software with fundamentally different requirements. At one end are market data systems, pricing engines, order execution, options pricing and real-time fraud scoring. Here, predictable performance is critical. Applications need close control over memory and computing resources, and even small variations in latency can matter. C++ is well suited to this world.

At the other end are payment services, claims applications, customer platforms, KYC (Know Your Customer)/AML (Anti-Money Laundering) workflows, and regulatory reporting. These applications need to remain reliable and adaptable for decades. Maintainability, integration and the ability to evolve business logic often matter more than reducing latency. Java has become the established technology for these requirements.

Insurers face a related, though not identical, contrast. Pricing, risk modelling and fraud detection require high computational throughput or real-time decisions, while policy, claims and customer platforms must remain reliable and adaptable. These different requirements have led to similarly distinct technology and engineering traditions.

These are engineering traditions rather than hard boundaries. Java is also used in latency-sensitive systems, and C++ can support long-lived platforms. The interesting question is how financial institutions pay for the advantages each one provides.

Different technologies, different bills

C++ gives developers extensive control over memory, hardware resources and execution. This makes it extremely powerful for performance-critical systems. But memory ownership and concurrent access need to be handled carefully. Errors can evade testing and only surface under production conditions, resulting in difficult-to-reproduce defects, outages or security vulnerabilities with a potentially large blast radius.

For Swiss financial institutions, this has a direct connection to operational risk. FINMA’s Circular 2023/1 specifically addresses ICT, critical data and cyber risks and incorporates operational-resilience principles into its supervisory framework for banks.

C++ therefore comes with what we could call an engineering and risk bill: the institution gains performance while paying through specialist expertise, testing, security assurance and disciplined engineering.

Java solves a different problem. Its managed runtime and automatic memory management remove much of this complexity from developers. Combined with an exceptionally mature ecosystem, this makes Java highly productive for enterprise software.

The cost moves towards runtime infrastructure. For one application, the additional overhead of the Java Virtual Machine may be insignificant. Across hundreds or thousands of services, containers and environments, however, resource consumption can become a significant part of the total cost of ownership (TCO). This becomes increasingly visible as financial institutions move towards cloud and container platforms, where CPU and memory usage translate directly into infrastructure capacity and ultimately cost.

Java therefore comes with a runtime and operations bill. The institution reduces part of the low-level engineering burden, but in return accepts a managed runtime that needs to be provisioned, tuned and operated. At scale, even small differences in resource consumption can affect container density, infrastructure capacity and recurring operating costs.

Rust takes a different approach. Like C++, Rust compiles to native code and does not require a garbage collector. At the same time, Rust is a modern, high-level general-purpose language that, like Java, provides strong abstractions, modularity, rich libraries, and mature tooling for building large-scale enterprise business applications.

Rust therefore comes with an upfront prevention and resilience bill: its strict compiler creates a steeper learning curve and can slow initial delivery. Its enterprise ecosystem and experienced talent pool are smaller, so adoption requires focused use cases, training and deliberate capability building for platform maintenance. This bill can be justified, but only when the workload creates a visible cost or risk that established platforms cannot address economically.

Paying up front and saving later

Rust’s approach shifts more responsibility – and therefore more cost – towards development and compile time. Its compiler forces developers to address some problems while writing the code that other languages may allow to surface later. This strictness is an advantage. A defect discovered during development is usually easier and cheaper to resolve than the same defect discovered during system testing. Once a problem reaches production, the impact can grow rapidly: more teams become involved, customers may be affected, incidents must be investigated and regulatory attention may follow.

Memory Safety

A global internet infrastructure provider provides a powerful example of why memory safety matters. In 2017, a defect in its C-based HTML processing software caused an incident, exposing sensitive server memory that included cookies, authentication tokens and submitted data. The company later replaced the high-risk framework with a Rust-based system that processes millions of responses per second with comparable performance. The migration moved the critical processing logic into memory-safe Rust while limiting unsafe code to the interface with the existing C platform. For financial institutions, the lesson is clear: using Rust for components that handle sensitive or untrusted data can prevent entire classes of memory-safety vulnerabilities before they reach production.

Deterministic Execution

A large consumer messaging platform provides another instructive example – this time focused on runtime behaviour. Its high-throughput state-management service manages billions of state records with hundreds of thousands of cache updates per second. The original Go implementation had significant latency and CPU spikes roughly every two minutes due to garbage collection. After rewriting the service in Rust, the latency spikes disappeared. Following further optimisation, the Rust implementation outperformed the heavily tuned Go version across latency, CPU and memory consumption.

The example is particularly relevant to financial services. A payment engine, market-data service or real-time risk component may perform well on average while still suffering from occasional latency spikes at exactly the wrong moment, when it is needed most.

Cybersecurity

Languages with stronger compile-time guarantees are also receiving increasing attention in cybersecurity. Deep vulnerabilities such as Heartbleed demonstrated the consequences of unsafe memory handling in C. Although Java is mostly memory-safe, its type system still permits certain errors to surface only at runtime – for example, null-reference errors or data races that can result in unexpected failures or denial-of-service conditions. Rust identifies these issues at compile time when they are easy to fix. For a bank or insurer, Rust does not create regulatory compliance by itself, but eliminating classes of technical failure by design supports the broader objective of building more robust, secure, and resilient systems.

Resource Use

A bank in Southeast Asia migrated a critical authentication service for its mobile and internet banking platforms from Java to Rust. The bank reported that start-up time fell from about 32 seconds to less than one second, while central processing unit (CPU) use dropped from three cores to a quarter of a core and memory use from 3.8 GB to 8 MB. These figures relate to one service and should not be generalised, but they illustrate how a targeted use of Rust can reduce the infrastructure required for a high-volume banking workload.

Maintainability

A major technology company’s mobile operating system provides unusually strong evidence that Rust can improve maintainability. The company compared similarly sized Rust and C++ changes made by substantially overlapping groups of the operating system’s engineers between 2023 and 2025. Rust changes required about 20% fewer revisions and spent 25% less time in code review. Medium and large changes were also around four times less likely to be rolled back. For long-lived financial software, this suggests that critical components can be changed with lower review effort and greater confidence.

Where Rust creates the greatest value

Rust is not a replacement for an entire technology landscape. Its value is highest where existing technologies create a measurable cost or risk.

Performance-critical systems

Market data, pricing, execution, protocol handling and real-time risk services need predictable performance and efficient use of hardware. Traditionally, this has been C++ territory. Rust provides a new option when banks want native performance but also want to reduce some of the engineering and security risks associated with manual memory management. New market-data components, pricing engines, protocol handlers or execution services can therefore be particularly interesting candidates.

Modernising critical C/C++ components

Financial institutions often depend on mature libraries and components that cannot simply be replaced. Rust can work alongside existing C and C++ code, making incremental modernisation possible. Institutions can target specific components where security, maintainability or concurrency complexity have become costly.

The most realistic Rust strategy for an established bank is to focus on bounded, high-risk and high-value components where the benefit can be measured, and the surrounding system can remain unchanged. A protocol parser, market-data adapter, security-sensitive library or compute-intensive service, for example, can be modernised independently without putting decades of proven business logic at risk.

High-volume and compute-intensive services

Towards the enterprise side, Java remains an excellent choice for many banking and insurance applications. There is little reason to replace stable business applications simply because another language might consume fewer resources.

However, some services run at such high volume that central processing unit and memory consumption become economically relevant. Examples include payment processing, event-stream processing, fraud detection, data transformation, risk calculations and infrastructure surrounding AI applications. Here, Rust’s low runtime overhead can potentially improve workload density and reduce infrastructure requirements.

Not every Java service should be rewritten in Rust. In many cases, the productivity and ecosystem benefits of Java – or the simplicity of Go – will outweigh potential infrastructure savings. Rust becomes interesting when the scale or criticality of the workload makes resource efficiency, predictable latency or low-level control material to the business case.

AI and sustainability

AI is already being applied to process optimisation, data generation, customer interaction and many other areas. But AI applications do not operate in isolation. They require data pipelines, APIs, integration services, security controls, event processing and additional infrastructure. Software that needs less CPU and memory can allow an institution to process more workloads with the same infrastructure.

This also has a sustainability dimension. The International Energy Agency expects global electricity consumption by data centres to approximately double from 485 TWh in 2025 to 950 TWh by 2030. Electricity consumption from AI-focused data centres is expected to triple over the same period. Programming languages alone will not solve the sustainability challenge. But software determines how efficiently infrastructure is used.

An example comes from a widely used open-source AI platform. Their widely used Tokenizers library is implemented in Rust. They report that its Rust implementation delivered up to a tenfold improvement in overall inference latency in its serving infrastructure. This example shows how Rust can improve the efficiency of the infrastructure surrounding AI models. For banks and insurers expanding their use of AI, efficiency therefore becomes both a TCO and an ESG consideration.

What about Go?

Go is a credible choice for cloud-native services because it offers fast development, straightforward deployment and a substantially lighter runtime than traditional Java stacks. For banking APIs, orchestration platforms and distributed transaction services, however, Rust provides the stronger strategic foundation. Go’s simplicity depends partly on a garbage-collected runtime, which introduces additional memory overhead, consumes CPU capacity and retains some latency variability – important considerations when systems must perform predictably under peak transaction loads. More fundamentally, Go permits nil-reference failures and does not prevent data races statically; its race detector can identify issues only in code paths exercised during testing. Rust addresses these risks by design: explicit optional values eliminate null references in safe code, while its ownership and type systems prevent data races and broad classes of memory defects at compile time.

The strategic choice is therefore not Go or Rust for banking. Go often optimises delivery and operational simplicity; Rust optimises control, predictable resource use and compile-time prevention. The workload decides which bill is cheaper.

Start small and measure

A sensible way to get started with Rust is to select one bounded component where there is already a visible cost or risk. The next step is a focused proof of value:

1. Establish the current baseline, including throughput, tail latency, CPU, memory, infrastructure cost, failure behaviour and engineering effort.
2. Select a bounded workload and determine whether the existing implementation can first be improved more economically.
3. Build the Rust alternative with production-like observability, dependency controls and deployment processes.
4. Compare performance and TCO alongside delivery effort, unsafe-code usage, operational readiness and maintainability.
5. Scale only if the benefits survive this complete comparison and the organisation has sufficient engineers to own the result.

Shaping the next generation of financial software

Financial institutions have spent decades building software around two different clocks. C++ provides the control and performance required for the fastest systems. Java provides the productivity, reliability and ecosystem needed for long-lived enterprise applications. Rust creates a new option between these worlds.

Its value lies in combining characteristics that have traditionally been difficult to achieve together: native performance, memory safety and efficient resource use, complemented by modern language features that make software easier to develop safely and maintain over time.

Rust is a specialist option for places where native performance, memory safety or resource efficiency is materially valuable – and where the institution is prepared to pay the capability bill. For Swiss banks and insurers, the opportunity is to identify bounded components where the current trade-off has become expensive, compare Rust with the existing solution, and scale if the evidence supports it.