FIX Trading API Certification Test Cases
The certification test confirms that a client FIX engine can connect, recover, submit orders, parse execution reports, and handle controlled exception cases before production credentials are issued.
FxTrusts runs the test against a supervised demo environment. Scenarios use predictable order states so the integration team can verify protocol behavior, downstream booking, and operational controls without relying on live market conditions.
Prerequisites
| Area | Requirement |
|---|---|
| Connectivity | Approved VPN, cross-connect, or private network handoff is established. |
| Credentials | Demo FIX session credentials, sender IDs, and target IDs are issued by FxTrusts. |
| Symbols | Symbol dictionary and venue mapping are loaded in the client environment. |
| Operations | A technical contact is available during testing for sequence resets and replay checks. |
Session level message flow
Session testing covers authentication, heartbeat behavior, reconnect handling, controlled logoff, and sequence recovery.
Automatic Reconnect
The client FIX engine should reconnect automatically after an unexpected disconnect and restore the assigned session without manual intervention.
Tag 141
When a session is out of sync, the client may request a sequence reset on logon using ResetSeqNumFlag. FxTrusts validates that retry behavior is controlled and does not loop indefinitely.
Reset of Sequence Numbers
The client should demonstrate clean logoff before a maintenance window, reset the expected sequence numbers, and log on successfully when the new session begins.
Keep Session Alive
The client should maintain the session through heartbeat and test request handling for the agreed certification window without avoidable communication gaps.
Application level message flow
Application testing confirms that order lifecycle events are submitted and consumed consistently across the client platform, risk layer, and back-office process. The client should be ready to test the scenarios below before requesting production access.
Scenario references use predefined order quantities so FxTrusts can return deterministic responses. The client should verify that each execution report is handled correctly in the trading platform, allocation logic, and downstream reporting.
- Scenarios without Allocation
- Scenarios with Basic Embedded Allocation
- Scenarios with External Allocations via Allocation
Scenarios without Allocation
Single-account order scenarios validate the base order lifecycle before allocation-specific handling is introduced.
| Scenario | Order Qty | Place | Change | Cancel | Scenario Playback |
|---|---|---|---|---|---|
| 1 | 5 | Accept | Accept | Accept | New -> Fill |
| 2 | 10 | Accept, partial fill | Accept | N/A | New -> Partial |
| 3 | 20 | Accept, full fill | N/A | N/A | New -> Fill |
| 4 | 30 | Accept | Reject | Accept | New -> Cancel |
| 5 | 40 | Reject | N/A | N/A | Reject |
| 6 | 50 | Accept | Accept | Reject | New -> Replace |
| 7 | 60 | Accept, done for day | N/A | N/A | Done for day |
| 8 | 70 | Accept, unsolicited cancel | N/A | Reject | Cancel report |
Scenarios with Basic Embedded Allocation
Embedded allocation scenarios confirm that account splits, partial fills, rejects, and cancel events are processed without breaking the original order chain.
| Scenario | Order Qty | Allocation | Place | Change | Cancel |
|---|---|---|---|---|---|
| 101 | 1000 | Single account | Accept | Accept | Accept |
| 102 | 1010 | Two accounts | Accept, partial fill | Reject | N/A |
| 103 | 1020 | Two accounts | Accept, full fill | N/A | N/A |
| 104 | 1030 | Two accounts | Accept | Accept | Reject |
| 105 | 1040 | Two accounts | Reject | N/A | N/A |
| 106 | 1050 | Two accounts | Accept, done for day | Reject | Accept |
| 107 | 1060 | Two accounts | Accept, unsolicited cancel | N/A | Reject |
| 108 | 1070 | Two accounts | Accept, replace then fill | Accept | Accept |
Scenarios with External Allocations via Allocation
External allocation scenarios validate matching between the order and the allocation instruction supplied after execution.
| Scenario | Allocation Type | Instruction | Place | Change | Cancel |
|---|---|---|---|---|---|
| 10001 | Separate allocation | All accounts | Accept | Accept | Accept |
| 10002 | Separate allocation | Missing account | Reject | N/A | N/A |
| 10003 | Separate allocation | Partial allocation | Accept, partial fill | Reject | N/A |
| 10004 | Separate allocation | Full allocation | Accept, full fill | N/A | N/A |
| 10005 | Separate allocation | Cancel after allocation | Accept | Reject | Accept |
| 10006 | Separate allocation | Replace after allocation | Accept | Accept | Reject |
| 10007 | Separate allocation | Unmatched allocation | Reject | N/A | N/A |
| 10008 | Separate allocation | Late allocation update | Accept, review required | Reject | Reject |
Controlled test scenarios
| Scenario | Expected result |
|---|---|
| Market order | Order accepted, routed, filled, and reported with correct average price and quantity. |
| Limit order | Working state, partial fill, full fill, expiration, and cancellation are validated. |
| Stop order | Trigger behavior and rejection handling are confirmed against the test script. |
| Recovery | Disconnect, reconnect, duplicate message, and reject-message handling are reviewed. |
Final scenario coverage depends on product scope, order types, liquidity setup, and commercial agreement.
Production approval
- Complete the agreed session-level and application-level scenarios.
- Share client-side logs, timestamps, and order references with FxTrusts technical onboarding.
- Resolve any parsing, sequencing, or booking issues found during the test window.
- Receive written FxTrusts sign-off before production credentials are released.