ZagTrader FIX Engine

Sessions that look after themselves, so your operators deal with exceptions, not routine.

• Outbound and inbound sessions in one engine, each with its own threads, so one slow counterparty does not hold up the others.
• Daily, weekly or round-the-clock schedules in the venue's time zone, limited to the days the market trades.
• Heartbeats, test requests, automatic gap detection, resend and gap fill, with possible-duplicate handling.
• The next expected sequence number can be agreed at logon, so reconnects recover faster.
• Automatic reconnection, with backup addresses per session: if the primary does not answer, the session moves to the next one.
• Sequence reset rules set per counterparty: at logon, at logout, on disconnect, or never.
• Sent messages are stored on disk, so resends after a restart work.
• The FIX session and the order logic run as separate processes. If an order application restarts, the venue stays connected and the messages wait for it.

Every FIX version from 4.0 to 5.0 SP2, including FIXT 1.1 transport.

• FIX 4.0, 4.1, 4.2, 4.3 and 4.4, and FIX 5.0, 5.0 SP1 and 5.0 SP2 over FIXT 1.1.
• Every message is checked against the FIX data dictionary of its session.
• Each counterparty can have its own dictionary, so custom tags and groups are validated like standard ones.
• Validation strictness set per counterparty: field order, empty fields, user-defined fields, unknown fields and values.
• Messages with a stale sending time can be refused.
• Timestamps at the precision each venue asks for, down to nanoseconds.

A tag rule engine per session normalises each venue's FIX, without custom code.

• Tag rules per session, in both directions: add, remove, copy or rewrite tags, with conditions, pattern matching and repeating-group support.
• Value maps per session are kept in the database, and each venue's own time-in-force codes are mapped for you.
• Custom tags and party roles per market and per message type are set in the platform's market screen.
• Venues that only offer WebSocket or REST APIs are wrapped so they behave like FIX sessions. Your workflows do not change.
• Orders go to the right session by market, by custodian or counterparty, by customer or by algorithm, as set in the platform.
• One FIX connection can serve several desks or sub-clients, routed by OnBehalfOf and DeliverTo, and messages can be forwarded between sessions.

Order routing is one of several flows the engine carries.

• New, amend and cancel orders over FIX, with every execution report booked straight to the order.
• Market, limit, stop, stop limit, market-to-limit, iceberg and venue-specific order types.
• Order status checks against the venue, one order or all at once.
• When a venue rejects an order at the session level, the order is marked rejected in the platform, not left pending.
• Inbound DMA: client orders arrive over FIX and pass the same market, timing and cash checks as every other channel. Execution reports go back to the client automatically.
• Drop copy: receive-only sessions capture fills from other brokers and venues and book them as orders.
• FIX market data: clients subscribe to snapshots, streaming updates and security lists, and market data from FIX venues feeds the platform.
• Trade capture reports, crossed trades reported as trade reports, market-making quotes and depository messages.
• Trading session and instrument status on request, and venue news over FIX becomes a platform announcement.

Each session is secured on its own terms, and the console has its own controls.

• TLS 1.2 and 1.3 per session, with certificate validation.
• Clients connecting in must log on with the username and password you issue them. A wrong logon is refused and the connection closed.
• Logon credentials set per outbound session.
• Signed logons for digital-asset exchanges that need API-key or signature logons over FIX.
• When a venue reports an expired password at logon, the engine sends the password change and keeps the session running.
• Database credentials can come from Azure Key Vault or HashiCorp Vault instead of a file.
• The operator console has Viewer, Operator and Administrator roles, HTTPS, sign-in throttling and an audit trail of every command.

The engine comes with its own operator tools, and the platform shows each order's FIX conversation.

• Operator console: every FIX session at a glance, with its status, sequence numbers in and out, and the state of the application behind it.
• Operators fix session problems from the browser: reconnect, resend, reset sequences, suspend and resume a session, request order status or send a message, without a restart.
• Certification test actions that venues ask for: sequence gaps, delayed heartbeats and corrected retransmits after a reject.
• FIX Investigator: searches days of logs, decodes each message with its session's dictionary, and follows one order from first send to last fill. It flags sequence gaps, resets and malformed messages, and exports the results.
• Per-order FIX trail: every message can be stored in the database and opened from the platform's order screen, decoded tag by tag.
• Daily logs per session, with messages, events and errors kept apart, opened straight from the console. Heartbeat noise can be left out.
• Alerts: e-mail and SMS when an order needs a person to look at it, and a home dashboard alert in the back office if a FIX session stops reporting.

Runs on Windows or Linux as a service, with no runtime to install.

• Ships as a self-contained build for Windows and Linux, and runs as a Windows service or a systemd unit.
• New sessions can inherit their settings from an existing one.
• Orders are processed in parallel, and each order's reports are applied in the order they arrive.
• Busy markets can be split across several senders.