Updated
Trading platform debugging & rescue
When the platform breaks,
we find out why.
Trading systems fail in ways ordinary software doesn't: orders rejected at the bridge, prices that spike for one client group, a terminal that lags on news, balances that disagree between the CRM and MetaTrader 5. We debug and fix live trading platforms — including code we didn't write — and leave you with the monitoring to catch the next problem early.
Work starts with an urgent incident or a fixed-scope audit, and ends with a written root-cause report, the fix, and the tests that keep it fixed. Our troubleshooting guide covers the most common failures in detail.
In short
- Nima Dorostkar's team debugs and fixes live trading platforms, including systems other teams built.
- Typical problems: rejected or stuck orders, MT5 plugin and Manager API failures, FIX session drops, price spikes, terminal lag, and balances that don't reconcile.
- Every engagement ends with a written root-cause report, the fix, and a test or monitor that keeps it fixed.
What we build
Trading platform debugging:
what's included.
Order rejections & execution
Rejected, requoted, or stuck orders traced across terminal, trading server, bridge, and liquidity provider.
MT5 plugins & Manager API
Crashing or slow server plugins, dropped Manager API connections, and regressions after a MetaQuotes upgrade.
FIX & liquidity bridge sessions
Logon failures, sequence number gaps, provider rejects, and latency between you and your liquidity providers.
Price feed quality
Spikes, stale quotes, wrong symbol mapping, and feed failover that doesn't actually fail over.
Terminal & app performance
Lag during news, WebSocket disconnects, memory leaks, and slow charts on mobile.
Reconciliation & data integrity
Balances, deposits, and commissions that don't match between CRM, payment providers, and the platform.
How we build it
Engineered for
real money, from day one.
- 01Reproduce before we fix
Logs, FIX messages, and platform journals are replayed on staging until the failure can be reproduced.
- 02Root cause, in writing
A report for your team and your compliance file: what failed, why, and what changed.
- 03Fix with a test
Every fix ships with a regression test or a monitor, so the same failure can't return silently.
- 04Leave monitoring behind
Dashboards and alerts for fills, rejects, latency, and feed health that your team keeps.
Platforms & technology
- MT5 Server API
- MT5 Manager API
- FIX 4.4
- Go
- Python
- C++
- Grafana
- Prometheus
Questions
Trading platform debugging FAQ
Can you debug a trading platform another company built?
Yes. We start with read access to logs, platform journals, FIX logs, and the source code if you have it, reproduce the problem on a staging environment, and fix it there before anything changes in production.
What does MT5 error 10030 (invalid order filling type) mean?
MetaTrader 5 return code 10030, TRADE_RETCODE_INVALID_FILL, means the order's filling policy — Fill or Kill, Immediate or Cancel, or Return — is not allowed for that symbol. The request has to use one of the filling modes the symbol permits.
Why do FIX sessions with a liquidity provider keep disconnecting?
The usual causes are a heartbeat interval (HeartBtInt, tag 108) that doesn't match the provider's, test requests left unanswered because a busy thread delays replies, and sequence numbers (tag 34) that fall out of step after a restart. The FIX logs on both sides show which one it is.
What access do you need to debug a live trading platform?
Read-only access is enough to start: platform journals, plugin and bridge logs, FIX logs, and monitoring. Nothing in production changes until the fix has been reproduced and tested on staging and your team has approved it.
Start a project
Talk to an engineer about
trading platform debugging.
Tell us what you run today and what you need. You'll hear back from a senior engineer with questions, a proposed architecture, and a realistic timeline.