MT5 Manager API service and real-time risk monitor

The problem

A live prop-trading firm has to enforce loss limits on every trader's account. Its platform read trading data through MetaTrader 5's HTTP Web API. One positions call could take several seconds, and breach checks ran from a periodic backend job, so a trader could keep trading past a limit for minutes. For a prop firm that is real money.

Why it was hard

• The native MT5 Manager API is a Windows SDK with its own connection lifecycle and a locally pumped cache. It is fast, and it is not thread-safe.
• A risk engine acts on what it reads: it disables trading and fails accounts. A wrong number is worse than a slow one.
• Rules differ by account type and phase, and the monitor and the backend must never disagree about whether an account has failed.
• The change had to go live on a running platform with real traders, on separate demo and live servers.

Architecture

1. 01Built the MetaTrader 5 integration service in C#/.NET 7 on the native Manager API: account, position, deal, order and daily-history endpoints, batch reads and trading-rights control, secured with API keys and an IP allow-list, running as separate demo and live Windows services.
2. 02Moved position reads from multi-second network requests to the Manager API's local pumped cache.
3. 03Designed the real-time breach monitor: it checks every active account against its daily-loss, max-loss and instant-account rules every few seconds, using rule snapshots the backend publishes to Redis, and fails breached accounts through an idempotent backend callback.
4. 04Built end-to-end marketing attribution: first-touch UTM and click-ID capture across the website and the hash-routed trader app, campaign short links, a clicks → registrations → trials → purchases funnel, and cohort retention reporting.
5. 05Rebuilt the admin dashboard in React 19, TypeScript and React Query: KYC review, MT5 account statistics with guarded admin actions (manual pass/fail, freeze, close all positions), affiliate reporting and a promotions wizard.
6. 06Added login IP and geolocation history with duplicate-IP risk flags for fraud review, and MT5 service health monitoring with alert emails, crash notification and auto-reconnect.

Decisions and challenges

• Read from the pumped cache, keep the request as a fallback

  Position reads moved from multi-second network requests to the local copy the Manager API keeps up to date. The slower request stays for the rare moment the cache is not ready.

• Serialise every SDK call

  Under concurrent load some accounts read another account's figures. I traced it to the SDK not being thread-safe, put every call behind one lock, locked connect and shutdown as well, and added a guard that the login returned is the login requested. Slower batch reads were an acceptable price for correct ones.

• Refuse to act on numbers that do not add up

  The monitor skips an account instead of failing it when the data looks wrong. No account is promoted unless its equity agrees across two independent MT5 sources.

• Make the fail flow idempotent and loud

  A breach is reported through a callback that is safe to repeat. The fail flow throws if MT5 refuses the rights change, so the database and MT5 cannot silently disagree. That closed a bug where an inverted rights bitmask let failed accounts keep trading.

• One fail calculation

  The calculation lives in one shared service. That ended false fails from swap being counted twice and from instant accounts that have no daily limit.

• Deploy with the monitor off

  The runbook stops both services, deploys, verifies a known-bad and a known-good account by hand with the monitor off, and only then switches it on.

Stories worth telling

Verified outcomes

• ✓Position reads moved from multi-second network requests to the local pumped cache.
• ✓Every active account is checked against its loss rules about every 5 seconds, where checks used to run from a periodic job.
• ✓No account is promoted unless equity agrees across two independent MT5 sources.
• ✓The cross-account data incident was traced to its cause and guarded against.
• ✓In production, as separate demo and live services.

Numbers

• ~250 commits in 6 months
• 5 repositories
• Breach checks every ~5 s
• 2 equity sources before any promotion