Quant-FX
Get started
QUANT-FX INFRASTRUCTURE LTD · Co. no. 17496299

Quant development in low-latency C++ for our engine and for yours

The research and the C++20 engine it runs on are written in-house, and our own master strategy trades on that engine. Companies bring us new strategies to build and C++ trading systems that need to be faster.

Bring us a projectRun it under your brand

What we build with

We prefer tools that are well understood and easy to measure in production.

EngineStrategy and execution code on the hot path.
  • C++17 and C++20
  • Multithreading
  • Lock-free queues and atomics
  • Tick-to-trade optimisation
ConnectivityFIX sessions for orders, UDP multicast for market data.
  • FIX protocol
  • TCP/UDP multicast market data
  • MetaTrader 5 client accounts
ResearchEvery strategy is tested on data it was not fitted to.
  • Python prototypes on AWS
  • Parallel backtesting
  • Walk-forward and out-of-sample tests
  • Monte Carlo resampling
Monitoring and analysisEach live engine exports metrics to Prometheus.
  • Prometheus
  • Grafana
  • P&L and execution analysis
  • Latency distributions

Tick-to-trade latency

Tick-to-trade is the time from a market data update arriving to the order leaving the engine. We measure each stage on that path, fix the slowest one, then measure again.

Hot threads
Each latency-critical thread does one job. Logging, persistence and analytics run on other threads, so the path from tick to order stays short.
Lock-free handoffs
Threads pass data through lock-free queues with explicit memory ordering instead of waiting on a mutex.
Allocation
Memory is reserved at startup, so a busy market never sends the engine into the allocator.
Gateways
Sequence gaps, retransmits and reconnects are handled in the gateway, away from the strategy thread.
Existing systems
We profile strategies that are already live and refactor the slow parts without changing their logic.
Real latency budgets depend on the venue, the broker and the hosting. We measure them per deployment.

Monitoring and research compute

Monitoring

Prometheus and Grafana

Fills, slippage, per-stage latency, positions and process health go to Grafana dashboards. Alerts fire when live behaviour drifts from the backtest, and we can trace a bad fill back to the stage that caused it.

Research compute

Python on AWS

Ideas are prototyped in Python on AWS, where a backtest sweep spreads across as many workers as it needs. The ones worth keeping are rewritten in C++20 and tested again before they trade.

2,000 backtests of 20 minutes eachIllustrative
On one worker
about 28 days
On 64 workers
about 10.4 hours

Analysis tooling

Built in-house

Tools for P&L attribution, execution quality and latency distributions. After launch, fills, latency and P&L are tracked against the backtest, trade by trade.

What a project looks like

Most projects start with a short written brief from you. The work then runs in three stages, and each one ends with something you can review.

  1. Scoping

    You tell us what the system has to do. We ask for the data you have, the venue or broker you trade through, the account type, and your limits on latency, hosting and risk.

    You get

    A written scope and test plan, before any code is written.

  2. Build

    We write it in C++20, with FIX or MT5 connectivity where it needs it. Client strategies go through the same backtests and out-of-sample tests as our own.

    You get

    Source code you can read, with review notes and a backtest report at each checkpoint.

  3. Handover or operation

    You run it on your own servers, or we run it for you as white-label infrastructure and monitor it against its backtest.

    You get

    The source and its documentation, or a live deployment we operate.

Need an Expert Advisor for MetaTrader rather than a C++ system? See custom MT5 Expert Advisor development.

Client money never passes through us

The engine copies each trade from our master account into the client's own MT5 account. The client's broker executes it and holds the money.

Read the risk disclosure

Questions we get asked

Yes. We build systematic strategies and trade-copy engines for companies in C++17/20 and test them the same way we test our own. Once a strategy is live, you run it yourself or we run it for you as white-label infrastructure.

Yes. We time each stage of its tick-to-trade path and refactor the slowest parts without changing the strategy logic. We also build and repair FIX and multicast connectivity.

Ideas are prototyped in Python on AWS and swept in parallel backtests across instruments, parameters and market regimes. The ones worth keeping are rewritten in C++20 and tested again with walk-forward analysis, out-of-sample holdouts and Monte Carlo resampling, with spread, costs and slippage modelled. A strategy that passes goes live at small size and is monitored against its backtest.

No. Client money stays in each client's own MT5 account at their own regulated broker. We never hold, pool, manage or withdraw it, and we do not give investment advice.

Both, and in both cases the engine runs on our infrastructure, hosted and managed by us. Companies run the QuantFX engine under their own brand, copying trades from our master account into their clients' own MT5 accounts, and we also build bespoke strategies and copy engines and run them for you. Nothing is installed on your side.

Bring us your quant project

Send a short description of the system and what it has to do. Typical requests look like these.

  • A strategy taken from research to live C++
  • An existing engine profiled and made faster
  • FIX or multicast connectivity to a broker or venue
  • A backtest suite moved onto parallel cloud workers
  • Monitoring for a system that is already live
  • A copy engine built and run under your brand
Bring us a projectinfo@quant-fx.com