Problem
Binary options brokers don't expose anything MetaTrader can talk to natively. There's no MQL5-compatible API, no shared order model, and every broker disagrees on transport (WebSocket-only versus REST plus WebSocket), authentication (OAuth, tokens, API keys), and rate limits. A trader running an MT5-based strategy who wants exposure across multiple binary options brokers ends up mirroring trades by hand across separate terminals. That stops working at any real trade frequency, and it makes consistent risk enforcement across brokers close to impossible.
The goal was to let an MT5 Expert Advisor emit a trade decision once and have it executed uniformly, reliably, and auditably across any of three brokers, without broker-specific logic ever touching the strategy layer.
Architecture
Five layers, each doing one job.
MT5 edge. An MQL5 Expert Advisor (plus a signal-bridge variant) detects trade actions and order transactions and serializes them into an immutable TradeEvent before anything leaves the terminal.
Transport. A TCP socket layer using explicit [length][payload] framing. This layer only moves bytes; it knows nothing about trade semantics, brokers, or risk.
Bridge core. Ingestion handles schema validation and normalization. A centralized execution engine runs risk checks, broker routing, and retries. Persistence stores events for replay and audit.
Broker modules. One adapter per broker, each behind a shared BrokerInterface. Protocol, auth, and field-mapping differences live entirely inside the adapter, so nothing broker-specific leaks upstream.
Operator surface. A Textual TUI and a PySide6 desktop console both read the same runtime state and log stream as the gateway process, so an operator can watch and configure the bridge without sitting inside its execution path.
Implementation
Every event carries a globally unique event_id and is treated as immutable end to end. Nothing downstream mutates a TradeEvent; it's only referenced, replayed, or superseded by a new event. That single decision is what makes replay and audit tractable, since the persistence layer can reconstruct bridge state at any point in history just by re-applying the event log.
Ingestion validates every incoming frame against a strict schema before it reaches execution, and it rejects anything malformed rather than guessing at what was probably meant. A malformed trade instruction shouldn't get a best-effort interpretation.
Adding a new broker means implementing the shared interface and nothing else. The execution engine, risk validation, and persistence layers are broker-agnostic by construction. Each broker module owns its own client, mapper, and authentication helpers, and keeps its connection long-lived and non-blocking so a slow broker never holds up another broker's fills.
Challenges
The three brokers agree on almost nothing except the concept of buy and sell. One is WebSocket-first with its own reconnect behavior. Another mixes REST and WebSocket and enforces a hard rate ceiling. The third has dynamic payout ratios that need polling. Building a single execution engine that could route to any of them meant pushing every broker-specific quirk (auth refresh, rate limiting, payout polling) behind the adapter boundary and refusing to let any of it surface in the shared execution path.
The transport protocol needed a second pass to get right. The first version put message-type information in the frame header. Moving typing into the payload schema, and keeping the frame purely [length][payload], ended up mattering once multiple edge clients (an MT4 alert monitor, the MT5 EA, and a separate signal-bridge EA) needed to speak the same wire protocol without the transport layer needing to understand any of their differences.
Results
The bridge collapses three independent, broker-specific integrations into one execution surface. An MT5 strategy emits a single TradeEvent, and routing, retries, and broker mechanics get handled uniformly no matter which broker executes it. Because every event is persisted before execution and stays immutable afterward, any trade (successful, retried, or rejected) can be replayed and audited later, which the old workflow of three terminals and manual mirroring could never offer.
Latency budgets (sub-10ms MT5-to-gateway, sub-50ms gateway-to-broker) were design targets from the protocol layer up rather than something bolted on afterward, and that was only possible because the transport layer stayed free of business logic from the start.