ON THIS PAGE
Separate the price path from the order path
A bridge receives market data and transmits orders, but those flows have different failure modes. We document price sources, aggregation or selection logic, symbol normalization and downstream distribution separately from order routing, execution reports and rejection handling.
Symbol mapping is a production control
Broker symbols and liquidity-provider instruments rarely align perfectly. Mapping must cover names, contract sizes, precision, trading sessions and any instrument-specific rules. A controlled mapping table prevents silent inconsistencies between what clients see and what execution venues accept.
- Price-flow and order-flow architecture
- LP/FIX session and endpoint inventory
- Symbol and contract-specification mapping
- Routing and rejection observability
- Disconnect/reconnect and failover policy
- Bridge acceptance and incident test cases
Routing policy should be observable
Whether routing is simple or conditional, operators need to know which destination was selected and why. We design around explicit routing rules, session state, order lifecycle events, reject reasons and logs so incidents can be investigated without guessing.
Connectivity failure must have defined behaviour
Disconnects, stale prices and unavailable endpoints are normal operational scenarios. Reconnect timing, feed health thresholds, order handling during outages, failover rules and escalation paths should be decided before production rather than during an incident.
Acceptance testing with real failure cases
Testing includes symbol mismatches, rejected orders, partial execution where applicable, stale or missing prices, session resets and endpoint loss. The handover documents what is monitored, who owns each component and which evidence is needed to diagnose an issue.
State integration exclusions and ownership
Confirm the selected bridge or gateway, available platform access and the commercial arrangements with each external endpoint. Connectivity work does not supply a counterparty agreement by default. The proposal should identify configuration, mapping, testing and operational management as distinct deliverables, with supplier-specific dependencies recorded before scheduling.
Collect a bridge assessment brief
Share platform family, instrument inventory, endpoint specifications and the intended routing policy. Include test credentials through the agreed secure process, never in an initial enquiry. Ask how incidents will be traced across platform, bridge and counterparty logs and which team owns recovery for each segment.