Rust Development Companies for Trading Platforms and Matching Engines: Which Parts Need Rust and How to Hire a Dedicated Team

Look for a firm whose own engineers have built a matching engine or another part of the order path in Rust and kept it running in production. Before you sign, meet the people who would join your team. Rust earns its place where a delay costs money: the matching engine, pre-trade risk checks, exchange gateways and the market data handler. Screens, reports and back-office tools can stay in the languages your company already uses.

Which companies specialise in Rust trading platforms and matching engines?

This article does not rank firms. A specialist is a firm whose own engineers have already shipped a trading system in Rust and run it for a client. A firm that would recruit its Rust engineers after you sign is offering a hiring plan instead.

Trading code is often private: clients usually own it and keep it that way, so a strong firm may have little trading code on GitHub. Ask instead for one production system described from end to end: what it does, which parts are written in Rust, how its speed is measured, who runs it today and what broke after launch. If a confidentiality agreement hides the client's name, ask the firm to arrange a call with that client.

Then check the people. Get the names and Rust experience of the engineers who would work on your system, and talk to them before you sign. The article on dedicated teams, linked above, covers the general checks: public code, a paid trial and a review by an independent engineer.

Which parts of a trading platform should be written in Rust?

The parts on the path of an order, where a pause of a few milliseconds can change the price a client gets:

• The matching engine, which pairs buy and sell orders by price and time of arrival
• Pre-trade risk checks, which stop an order that breaks a limit before it reaches the market
• Gateways that send orders to exchanges or brokers and receive their answers
• The market data handler, which reads price feeds and passes each update on

Rust fits these parts because it frees memory without a garbage collector. Some languages use one for this job, and it can pause the program at moments of its own choosing. The Rust book (the language's official guide, read on 27 October 2026) says that ownership, the set of rules behind this, “enables Rust to make memory safety guarantees without needing a garbage collector”.

The language does not make a system fast by itself. A Rust program can still stop to request memory, wait for a lock held by another thread or wait on the network. The article on matching engine design explains how a team keeps these out of the order path.

The rest of the platform has no deadline measured in milliseconds: web and mobile screens, client accounts, reports, back office and admin tools. These can stay in the languages your developers or vendors already use. A firm that proposes rewriting them in Rust should explain what that gains you.

We already run a platform in C++, Java or Go. Should we rewrite it in Rust?

Usually not all at once. A safer path is to move one component with a clear boundary, such as the risk checks or the market data handler, and leave the rest as it is.

The new component can run as a separate service that exchanges messages with the rest of the system. It can also be built as a library that C or C++ code calls directly. The Rustonomicon, the Rust project's guide to unsafe and low-level code, describes how in a section called “Calling Rust code from C”.

Before the switch, run the new component next to the old one on the same recorded order flow and compare every result. A deterministic matching engine always gives the same result for the same orders in the same sequence. That makes the comparison simple: if both engines apply the same rules, any difference points to a bug in one of them.

Then move one market or one group of instruments at a time, and keep the old component ready to take the traffic back.

What does an outsourced dedicated Rust team for a matching engine include?

A dedicated team works only on your system for months or years, and its members change only when you agree. For a matching engine or another part of the order path, it usually includes:

• Rust engineers who have shipped production code and know how an order lives: order types, partial fills, amendments and cancellations
• A lead engineer who owns the design and reviews every change to the order path
• A test engineer who builds the setup that replays recorded order flow and checks the results
• Someone responsible for the servers, network settings and releases

Your company has a part in it too. Someone on your side decides the trading rules, such as tick sizes, trading hours, fees and what happens when trading halts, and answers the team's questions about them without long delays.

Freelancers can be excellent engineers, but continuity is harder with them. A single contractor has nobody to review changes to the order path, and when that person leaves, what they knew about your system leaves too. A firm can replace someone and keep the knowledge in the team, and the contract can require it to.

A firm can only size the team after it has seen your trading rules, markets and volumes, so ask how it arrived at the number it quotes.

What should we ask a Rust team about a matching engine?

The article on low-latency firms covers how to check speed figures. These questions are about Rust and the order path:

• Where does your code use unsafe, and who reviews those parts?
• How do you test the engine beyond replaying recorded orders?
• Which crates does the order path depend on, and how do you check them for known vulnerabilities?
• Which Rust version do you build with, and how do you decide when to upgrade?
• Who in the proposed team has shipped Rust to production, on what system, and is it still running?

Rust checks how memory is used when the code is compiled. Inside a block marked unsafe, code can do five things the compiler otherwise refuses, such as following a raw pointer to memory. The Rust book adds that unsafe “doesn’t turn off the borrow checker or disable any of Rust’s other safety checks”. A good answer names where unsafe code sits, why it is needed there and who checked it.

On testing, a team should name the tools it uses. cargo-fuzz, which the Rust Fuzz Book calls “the recommended tool for fuzz testing Rust code”, feeds a program large amounts of generated input to find the cases that crash it. Loom, a library for testing code that runs on several threads, “runs tests many times, permuting the possible concurrent executions of each test”. That finds bugs that appear only when threads happen to run in an unlucky order.

Crates are Rust's packages of shared code. The RustSec Advisory Database records security advisories for crates published on crates.io. Its tool cargo-audit checks a project's Cargo.lock, the file that lists the exact version of every dependency, “for crates with security vulnerabilities”. A team working on an order path should be able to tell you whether such a check runs on every build.

Rust releases a new stable version every six weeks, and the Rust book says “you should never have to fear upgrading to a new version of stable Rust”. A team can still keep every build on one chosen version. The documentation of rustup, Rust's installer, describes a toolchain file for projects that find themselves “'pinned' to a specific release of Rust” and want this recorded in their repository. For an order path, the version should change only on purpose, after the tests pass.

What should the contract with a Rust team say?

Write these points into it:

• The code, tests, replay data and build scripts live in repositories your company owns
• Builds and releases run in accounts opened in your company's name
• Who may change the order path and who reviews each change
• The hours the team covers, and who answers if the engine fails outside them
• What you get if the contract ends: documentation, access, and time from the team to hand over to your next one

Where does amBrain fit?

amBrain, which publishes this blog, describes itself in one line: “amBrain is a Yerevan, Armenia software engineering company building low latency trading platforms, matching engines, and real-time bidding systems in Rust.” Another line reads: “amBrain builds algorithmic trading infrastructure: order execution, market data and pre-trade risk controls.”

It has been building software since 2019. Its team, in its own words: “A team of up to 40 people, about 75% of them senior.” It works in three formats: full delivery, a dedicated team, or engineers embedded in your team. Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.”

This article is not a case study and describes no client work. It does not say which systems amBrain has built in Rust or for whom, and it gives no amBrain prices, timelines or team sizes. If amBrain is on your shortlist, give it the same questions as any other firm.