Documentation
Integration
overview.
What connects where, what a certified FIX session actually involves, and what each of the five systems does. Full technical documentation is provided during onboarding.
Platform coverage
The bridge integrates at the server level of your trading platform:
- MetaTrader 5 — first-class integration over the MT5 Gateway API for order flow and the Manager API for accounts, groups and symbol administration. This is the lead integration path.
- MetaTrader 4 — supported via the MT4 server API surface; sequenced after MT5 in the integration roadmap.
- cTrader — via cTrader's server-side connectivity (FIX and Open API); sequenced with early-access demand.
- Proprietary platforms / OMS — direct FIX 4.4 into the bridge; if your stack speaks FIX, it can sit where a platform sits.
If your deployment depends on a specific platform version or server build, raise it in the request-access form — sequencing is demand-driven during early access.
FIX sessions and what "certified" means
Each liquidity provider connects over a dedicated FIX 4.4 session. "Certified" is a process, not an adjective: before a session carries an order, it goes through the counterparty's own conformance testing — message flows, cancel/replace behavior, reject handling, sequence-number recovery — and is signed off on both sides. One session per LP, certified per venue, documented in the journal from day one.
Connect
Venue connectivity. The bridge terminates your platform's order flow on one side and holds certified LP sessions on the other. Market data from every configured LP is normalized and aggregated into a single book: one price stream, with per-source attribution preserved for the journal. Symbols are mapped once, centrally, with per-group visibility rules.
Execute
Order routing and lifecycle. Every order moves through a defined lifecycle — received, validated, routed, acknowledged, filled or rejected, closed — and every transition is journaled before it is acted on. That is what makes recovery a replay instead of a reconstruction, and the full order history replayable to any timestamp. Routing policy decides where an order goes: a single LP, best-price across LPs, or split across several when that wins the price.
Control
Desk policy and risk. A-book, B-book or hybrid, set per client group. Markups, spreads and routing policy live in one place and apply at the session layer, not in a plugin bolted onto the platform. Exposure is live by book, symbol and group. Every policy decision the system takes is attributable and replayable from the journal.
Issue
Design notes — ROADMAP. Tokenized real-world instruments with custody, verification, compliance and redemption designed into the instrument itself. This is design-stage work: the instrument model and its compliance hooks are specified; nothing here is in production. Published so you can evaluate the direction, not buy it today.
Settle
Design notes — ROADMAP. One settlement layer across banking and tokenized rails: one ledger of record, rails as adapters underneath it, one reconciliation and one audit trail regardless of how value moved. Design-stage; the architecture argument is in the journal (Settling across traditional and tokenized rails without fragmentation).
Technical documentation
Full integration documentation — FIX dictionaries, session parameters, sandbox access — is provided to counterparties during onboarding. If you need it earlier to evaluate, ask: access@mmsys.xyz.