FIX API and MT4 integration should be designed as a controlled translation and evidence layer—not as a connector that forwards orders. A MetaTrader ticket, FIX ClOrdID, counterparty OrderID and execution identifier are not interchangeable. Treating them as one identifier creates incorrect statuses, duplicated fills or incorrect balances when partial fills, cancel/replace chains, reconnects or end-of-day corrections occur.

POLADO’s engineering position is straightforward: retain source-native events unchanged; translate them into a canonical order and execution model; make every consumer idempotent; and do not treat a client-visible status, balance or operational action as final until external execution truth has been reconciled.

This article is deliberately narrower than our guides to FIX API integration, order-state management and reconciliation. Its subject is the integration architecture needed when MetaTrader-specific tickets, symbols, account groups and execution behaviour must interoperate with FIX or external brokerage APIs.

A bridge has to manage two truths, not merely submit an order

In MetaTrader, orders, deals and positions can be separate objects. MetaTrader 5 documents that orders and deals receive tickets associated with their relevant position. A FIX execution report, meanwhile, can carry a client order identifier, venue order identifier and execution identifier as separate concepts. In FIX, cancel/replace chains use ClOrdID and OrigClOrdID, while ExecID identifies a distinct execution event. A production bridge therefore cannot assume that one ticket equals one trade.

The difference is visible in the MetaTrader 5 trading model and the FIX Execution Report reference. On MT4, the available broker-side interface and server configuration must also be established during discovery: MetaTrader’s official MT4 API page describes the Manager API as an interface for additional functionality and platform integration.

The POLADO bridge model: native event, canonical model, projection

Separate the bridge into three data layers:

  1. Native evidence: retain the raw FIX message, broker webhook, REST response or MT4/MT5 server event with source, receipt timestamp and payload hash.
  2. Canonical execution model: translate the source into source-independent objects such as OrderIntent, OrderRevision, Execution, CancelRequest, PositionEffect and ReconciliationBreak.
  3. Operational projections: construct trader views, back-office queues, exposure, client history, reporting and ledger inputs from canonical events.

This separation lets the team correct a mapping rule, replay a late execution or investigate a disputed callback without rewriting history. No client-facing status or financial projection should depend on source payload that has been discarded.

1. Manage identifiers as an identity graph, not a lookup table

A single trade intent may require all of the following identifiers:

  • Canonical intent ID: an immutable internal bridge identifier.
  • Client request ID: the identifier generated by the terminal, internal OMS or administrative workflow.
  • MT order, deal and position tickets: native platform-object identifiers.
  • FIX ClOrdID and OrigClOrdID: the client-order and amendment chain.
  • FIX OrderID, broker order ID and venue order ID: identifiers assigned by external systems.
  • Execution or deal ID: the idempotency anchor for each fill, trade cancellation or correction.

A simple mt_ticket → fix_order_id mapping is insufficient. One intent may have multiple revisions; one revision may route to multiple destinations; one route can generate multiple fills; and an execution can later be cancelled or corrected. The model must preserve these relationships explicitly. In particular, the prior order can still fill until a replace has been accepted; a modify request must not automatically close the previous order.

Implementation rule

Write the meaning and uniqueness boundary of each identifier into the data contract. For example: is ExecID unique per counterparty, account or trading day? Is an MT ticket unique only within a server and account? Can a ClOrdID be reused? “We store the string” is not an identity strategy that can survive production reconciliation.

2. Put symbol and contract-size normalization behind a versioned instrument master

EURUSD, EURUSD.a and EUR/USD may refer to the same economic pair but are not automatically the same tradable contract. A suffix or prefix can coexist with different digits, minimum lot, lot step, contract size, settlement currency, margin treatment, swap rules or trading sessions.

For every execution, store not only the source symbol but the effective version of the instrument mapping:

  • canonical instrument ID and source-specific symbol;
  • asset class, base/quote and settlement currency;
  • contract size, quantity unit, lot multiplier, minimum and increment;
  • price precision, tick size and rounding policy;
  • hedging/netting behaviour and position-aggregation rule;
  • mapping effective-from and effective-to timestamps.

Do not make lots the canonical quantity. Store the economic quantity in the canonical model and convert to or from lots in the adapter. Otherwise, exposure, commission and P&L can be wrong when the same displayed lot size represents different contract sizes across groups or counterparties. This is the practical continuation of instrument-master governance and pricing normalization.

3. Process fills and order status as separate facts

An order state is not an execution. An order may be accepted, working, partially filled, cancelled or filled, while also receiving multiple fills, a trade cancellation or an execution correction. In the canonical model:

  • Execution carries an execution ID, price, quantity, routing or liquidity context, execution time and source evidence.
  • Order state is a projection derived from valid lifecycle and execution facts.
  • Position effect is calculated separately under the account’s netting or hedging rule.

The FIX Execution Report distinguishes OrderID, ExecID, ExecType, OrdStatus, ClOrdID and, where applicable, OrigClOrdID. Compressing these fields into a single status column destroys the evidence needed to explain what happened.

Idempotency rule

Build a deterministic de-duplication key for every incoming execution, such as counterparty + account + execution_id + execution_version/event_type. If a counterparty cannot provide a stable execution ID, construct a fallback fingerprint from message ID, trade ID, order reference, timestamp, price and quantity—but mark it as weaker evidence. A duplicate must not be silently discarded: keep the native record and make the de-duplication decision inspectable.

4. Protect cancel, modify and reconnect races with an explicit state machine

The failure case that matters is familiar: an MT4/MT5 user sends a modify or cancel, the bridge transmits it, connectivity fails, and a fill and cancel response later arrive. Replacing the local status with whichever message arrived last is unsafe.

The state machine should distinguish at least: request created, request transmitted, acknowledgement uncertain, pending cancel/replace, replacement accepted, replacement rejected, fill received, cancellation confirmed, external state unknown and reconciled final state. “Unknown” is not a failed production state. It is safer than declaring an order cancelled or filled without evidence.

FIX session recovery is necessary at the transport level, but it is not business recovery. Message storage, sequence numbers and resend/gap-fill behaviour need durable handling; QuickFIX/J’s documented session settings include message persistence, resend behaviour and refresh on logon. After a reconnect, the bridge must still retrieve authoritative snapshots of open orders, recent executions and positions, then reconcile its projection against that source truth and the replayed event stream.

5. Treat account and group mapping as an authorization boundary

An MT login, MetaTrader group, CRM client, legal entity, FIX account tag and liquidity profile are different concepts. Joining them by a display name risks routing an order through the wrong profile, applying the wrong leverage rules or exposing another tenant’s data.

Maintain a separately versioned entitlement mapping that answers:

  • which internal account links to which MT login and FIX or broker account;
  • which instruments, order types, maximum volume and routing profile are permitted;
  • when a group assignment became effective;
  • who created, approved and revoked the mapping.

Privileged mapping changes need maker-checker approval, audit logging and a rollback path. The bridge should conform to the broader account-management control model, rather than becoming an uncontrolled route around it.

6. End-of-day reconciliation is not an optional bridge feature

Intraday processing supports speed; end-of-day reconciliation closes the evidence loop. For each trading day, compare:

  • source orders with canonical orders;
  • source fills/deals with canonical executions by count, quantity, price and fee;
  • open orders and pending requests;
  • position quantity and average price;
  • cash, commission, swap and other financial effects;
  • the instrument-mapping and account/group-mapping versions used.

A break should not create an automatic balance correction. It should enter an owned queue with severity, source evidence, likely cause and an approved remediation path. Until external execution truth agrees, client statements and ledger postings should not be presented as final.

Implementation sequence for a production bridge

  1. Discovery and contract inventory: document order types, identifiers, rate limits, recovery methods, snapshot endpoints and trading-day cut-offs for every MT server, broker API and FIX counterparty.
  2. Canonical schema: version the contracts for orders, revisions, executions, position effects, instruments, account mappings and reconciliation breaks.
  3. Instrument and entitlement onboarding: do not enable live routing before symbol/contract mappings and account/group permissions have been reviewed and approved.
  4. Adapters with durable inbox/outbox processing: isolate source receipt from business processing so retries are safe, traceable and replayable.
  5. Lifecycle simulation: automate partial-fill, reject, cancel/replace race, duplicate callback, out-of-order event, disconnect and restart cases.
  6. Shadow mode: compare bridge outputs with the existing operational process before enabling client-facing projections or live routing.
  7. Runbooks and day-two controls: approve operator actions for sequence gaps, unknown external state, mapping changes, reconciliation breaks and counterparty outages.

Release checklist

  • Can the team explain the relationship among every client request, MT ticket, broker/FIX order ID and execution ID?
  • Are symbol mappings versioned with contract size, quantity conversion and effective dates?
  • Can duplicate and out-of-order executions be accepted safely without changing the projection twice?
  • Does the model allow the prior order to fill until a cancel/replace is actually accepted?
  • Does reconnect recovery combine session replay, authoritative snapshots and reconciliation?
  • Is an unknown external state visible to operators rather than converted into an unsupported terminal state?
  • Are account/group mapping changes approved, auditable and reversible?
  • Do end-of-day breaks stay out of balances until an owner has reviewed the evidence and approved remediation?

When a custom MetaTrader-to-FIX bridge is justified

A large bridge is not automatically the right answer for a process that can safely run on one or two reviewed exports. But once a business operates multiple MT servers, liquidity providers or broker APIs, different account groups, partial-fill exposure, client-facing status data, internal risk controls and reconciliation requirements, a forwarding script becomes an operational risk.

The value of a bridge is not that it can send an order. Its value is the controlled boundary that preserves native evidence, translates it under governed mappings, recovers safely and makes external execution truth testable before it affects clients or financial operations. POLADO designs FinTech and trading integrations around that boundary—without pretending that MT4/MT5 should be replaced by a generic middleware layer.