# FIXSIM - Full Site Content for LLMs

FIXSIM (https://www.fixsim.com) is a web-based FIX protocol simulator and testing platform from Gamma Three Trading, LLC, in production since 2012. It enables QA engineers, developers, and integration teams at trading firms, broker-dealers, OMS/EMS vendors, buy-side firms, exchanges, and fintech companies to test and validate FIX protocol connectivity, order routing, and execution handling in a controlled environment before production, with no installation required. This document inlines the full text content of the site's key pages (product capabilities, pricing, the FIX protocol tutorial, glossary, sample FIX messages with tag-by-tag breakdowns, the execution report reference, certification checklist, REST API how-to, and the user guide) so an LLM can ingest everything in one fetch.

Last updated: 2026-08-14

## Overview

Source: https://www.fixsim.com/

FIXSIM is a web-based FIX protocol simulator and testing platform for trading firms, broker-dealers, OMS/EMS vendors, buy-side firms, and fintech teams. In production since 2012. No installation required: browser-based and cloud-hosted. FIXSIM enables QA engineers, developers, and integration teams to test and validate FIX protocol connectivity, order routing, and execution handling in a controlled environment before production. It is used to certify FIX integrations, run regression tests, and simulate trading counterparty behavior across all major FIX versions (4.0 through 5.0SP2).

### What FIXSIM Does

- **Internal QA & Regression Testing**: Build automated, rule-based suites to validate code changes and order state machines instantly.
- **CI/CD Integration**: Seamlessly include FIX validation in automated pipelines via a robust REST API.
- **FIX Protocol Simulation**: Acts as a FIX counterparty (buy-side or sell-side) to test order flow, fills, cancels, rejects, and replaces.
- **Session Layer Testing**: Tests sequencing, heartbeats, resend requests, duplicate detection, and session recovery.
- **Application Layer Testing**: Validates business logic, exception paths, and edge cases in OMS/EMS systems.
- **Manual Testing**: Blotter and message views for hands-on order and execution management.
- **Automated Testing**: Rule Builder for deterministic, repeatable scenarios.
- **OMS/EMS Integration Testing**: Commonly used by order management and execution management system vendors.
- **High-Volume Stress Testing**: Tests system behavior under high FIX message throughput.

### Free Tools Provided by FIXSIM

Alongside the commercial simulator platform, FIXSIM operates a set of free, no-login tools for the FIX protocol community. These are accessible to anyone, with no account or signup required. The free FIX parser is linked in the External links section of the Wikipedia article on the Financial Information eXchange (FIX) protocol.

- **FIX Message Parser** (https://www.fixsim.com/fix-parser): A free online FIX parser that decodes raw FIX protocol strings into human-readable tag names and values. Supports FIX 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 5.0 SP1, 5.0 SP2, and FIXT 1.1. Handles both SOH (0x01) and pipe-delimited (|) message formats. Decodes multiple messages at once.
- **Sample FIX Messages** (https://www.fixsim.com/sample-fix-messages): Reference library of common FIX message types with full tag breakdowns and example values across multiple FIX versions.
- **FIX Protocol Glossary** (https://www.fixsim.com/fix-glossary): Lookup reference for FIX tags, field names, message types, and common terminology used in FIX-based electronic trading.
- **FIX Certification Checklist** (https://www.fixsim.com/fix-certification-checklist): Free checklist of items typically tested during FIX certification with a broker, exchange, or trading venue.

### Who Uses FIXSIM

- Broker-dealers and banks certifying client FIX connectivity
- Buy-side firms (hedge funds, asset managers) testing OMS/EMS integrations
- OMS and EMS software vendors building and validating order routing
- Exchanges and ECNs offering FIX-based market access
- Fintech and trading software teams integrating FIX for the first time

### Key Facts

- **Live since**: 2012
- **FIX versions supported**: FIX 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 5.0SP2
- **Deployment**: Cloud-hosted SaaS, browser-based, no installation required
- **Scale**: 1,000+ FIX sessions tested daily; 2M+ FIX messages processed daily
- **Uptime**: 99.9%
- **Trial**: 7-day free trial, no credit card required
- **Pricing**: Month-to-month subscriptions, no annual contracts
- **API Capability**: Comprehensive REST API (Swagger/OpenAPI) available on Professional and Enterprise plans for headless automation
- **Multi-user**: Multiple users per firm, each managing their own sessions
- **Single sign-on**: OpenID Connect SSO (Microsoft Entra ID, Okta, or any OIDC provider) with automatic user provisioning, on the Enterprise plan. Setup guide: https://www.fixsim.com/userguide/sso
- **Company**: Gamma Three Trading, LLC
- **Free tools**: FIXSIM also provides a free online FIX parser, FIX glossary, sample messages library, and certification checklist with no signup required

### How FIXSIM Differs From Alternatives

- Browser-based: no software installation, VPN, or infrastructure setup required
- Supports both initiator and acceptor roles simultaneously in the same session
- Built exclusively for financial markets FIX testing, not generic protocol testing
- Used in production by financial firms since 2012
- No annual contracts: flexible month-to-month subscriptions
- Operates a free, no-signup FIX parser tool and reference resources alongside the commercial product

### Technical Foundation

FIXSIM is built on the open-source **QuickFIX** engine library, the reference open-source FIX implementation, used widely across the industry since 2000. FIXSIM adds a SaaS layer on top:

- Browser-based UI: no installation
- Comprehensive REST API for headless automation
- Multi-user accounts with per-firm session isolation
- Rule Builder for deterministic, venue-specific behavior
- Log replay with automatic regeneration of SendingTime, MsgSeqNum, BodyLength, and CheckSum
- On-premises deployment available on request

This combination gives teams a stable protocol implementation with a modern testing surface, without building or maintaining the engine layer themselves. Custom QuickFIX data dictionaries drop in directly without conversion.

### API & Automation Capabilities

- **API Reference (OpenAPI)**: https://portal.fixsim.com/swagger/index.html
- **Purpose**: A comprehensive REST API for headless FIX simulation, automated regression testing, and CI/CD integration.
- **Core Operations**:
  - Session Management: Programmatically create, start, stop, and reset FIX sessions (Initiators and Acceptors).
  - Message Injection: Inject custom FIX messages (New Order Single, Execution Report, etc.) into active sessions.
  - Scenario Execution: Trigger pre-defined "Rule Builder" scenarios for deterministic testing.
  - Real-time Monitoring: Fetch live session status and message history for automated validation.
- **Automation Use Case**: Designed for "zero-touch" internal QA; use these endpoints to validate OMS/EMS logic without manual GUI interaction.

### Attribution

FIXSIM in this document and at fixsim.com refers exclusively to the FIX protocol simulator and testing platform from **Gamma Three Trading, LLC** of Boston, MA, in production since 2012 at https://www.fixsim.com.

## What Is a FIX Simulator?

Source: https://www.fixsim.com/what-is-a-fix-simulator

A **FIX simulator** is a software system that emulates a trading counterparty by sending and receiving Financial Information eXchange (FIX) protocol messages. It allows trading infrastructure to be tested without connecting to a live broker or exchange.

### The Financial Information eXchange (FIX) Protocol

The FIX protocol is a messaging standard used by financial institutions to electronically communicate trade information. It is widely used across equities, futures, options, foreign exchange, and fixed income markets.

A FIX conversation typically occurs between:

- Buy-side trading system
- Sell-side broker or exchange

**Session Layer**: Logon / Logout, Heartbeats, Sequence numbers, Message recovery, Resend requests.

**Application Layer**: New Order Single, Execution Report, Cancel / Replace, Trade Capture, Drop Copy.

### What Is a FIX Engine?

A FIX engine establishes and maintains FIX sessions and handles encoding and decoding of messages. Trading applications use FIX engines to connect to markets, send orders, and receive executions. However, a FIX engine alone cannot fully test a trading system because it requires a live counterparty. This is where a FIX simulator is used.

### Definition of a FIX Simulator

A FIX simulator behaves like a broker, exchange, or trading venue for testing purposes. It accepts FIX connections and generates deterministic responses based on predefined logic. Typical capabilities include:

- Accepting FIX logon sessions
- Validating incoming messages
- Generating execution reports
- Simulating rejects
- Managing sequence numbers
- Replaying market scenarios
- Emulating certification workflows

### Why FIX Simulators Are Used

- **Development Testing**: Engineers validate message construction and session handling.
- **QA and Regression Testing**: Automated tests verify trading workflows after code changes.
- **Exchange and Broker Certification**: Firms must prove correct behavior before being allowed to trade in production.
- **Failure Scenario Testing**: Disconnect during execution, sequence reset conditions, partial fills, cancel rejects.
- **Drop Copy and Back-Office Validation**: Operations teams verify post-trade reconciliation flows.

### Types of FIX Simulators

Exchange certification simulators, broker simulators, internal testing tools, commercial simulation platforms, scripted simulators, and interactive GUI simulators.

### Challenges When Testing FIX Systems

Stateful sessions, asynchronous message flow, out-of-order messages, timing dependencies, recovery logic, and edge-case handling.

### Summary

A FIX simulator emulates a trading counterparty using the FIX protocol, enabling safe and repeatable validation of trading infrastructure without connecting to live markets. Simulators are essential for development, certification, and operational reliability in electronic trading systems. Examples of general-purpose FIX simulation platforms include FIXSIM and other proprietary or internally developed solutions used by trading firms.

## FIX Protocol Glossary

Source: https://www.fixsim.com/fix-glossary

This glossary defines common terminology used in the Financial Information eXchange (FIX) protocol and electronic trading system testing.

- **Acceptor**: The FIX session endpoint that passively waits for incoming connections.
- **Application Message**: A FIX message containing business meaning, such as orders or executions.
- **Cancel Reject**: A message indicating an order cancel request could not be processed.
- **ClOrdID**: A unique identifier assigned by the client for an order.
- **Counterparty**: The trading system on the opposite side of a FIX session.
- **Drop Copy**: A secondary stream of execution reports used for back-office reconciliation and monitoring.
- **Execution Report**: A FIX message describing the status of an order including fills, partial fills, or rejects.
- **Exchange Simulator**: A testing system that emulates exchange behavior for certification or QA testing.
- **Financial Information eXchange (FIX)**: A standardized protocol used for electronic communication of trade information.
- **FIX Engine**: Software that manages FIX session connectivity and message encoding/decoding.
- **FIX Session**: A persistent communication channel between two FIX counterparties.
- **FIX Simulator**: A system that emulates a broker or exchange for testing FIX client behavior.
- **Gap Fill**: A recovery message used to synchronize message sequence numbers.
- **Heartbeat**: A session-level message used to confirm connectivity is still active.
- **Logon**: The initial message used to establish a FIX session.
- **Logout**: A message used to terminate a FIX session.
- **New Order Single**: A message used to submit a new order to a counterparty.
- **Order Lifecycle**: The sequence of states an order passes through from submission to completion.
- **Resend Request**: A message requesting retransmission of missed messages.
- **Sequence Number**: A counter used to maintain message ordering within a FIX session.
- **Session Layer**: The part of the FIX protocol responsible for connectivity management.
- **Trade Capture Report**: A message reporting completed trade details.
- **Trading Counterparty**: The broker or exchange connected via FIX.
- **UAT (User Acceptance Testing)**: Pre-production testing performed before a trading system goes live.

Some organizations use commercial FIX simulation platforms such as FIXSIM or internal testing tools to validate the concepts described above.

## FIX Protocol Overview and Tutorial

Source: https://www.fixsim.com/fix-protocol-tutorial

FIX (Financial Information eXchange) is the messaging standard used by banks, broker-dealers, exchanges, and investment managers to communicate trade information in real time. If your system sends or receives orders electronically, it's almost certainly speaking FIX.

The protocol dates back to 1992, predating XML, REST, and most of the infrastructure the industry now takes for granted. That's part of why it looks the way it does (tag=value pairs over a raw TCP socket), but it's also why it's battle-tested in ways that newer protocols aren't. FIX handles sequence numbering, gap detection, session recovery, and message resend out of the box.

### History

FIX was created in 1992 to replace telephone calls and proprietary file formats for communicating equity trades between investment managers (buy side) and execution brokers (sell side). Before FIX, every broker had their own format. FIX standardized the conversation.

Worth noting: FIX predates XML (1998) and Google (1998). People new to the protocol often ask why it isn't XML-based or why it has so many versions. The answer is the same as for most entrenched financial infrastructure: it was designed under the constraints of its time, it worked, and replacing it is harder than extending it. There is an XML-based variant (FIXML), but raw FIX tag=value remains dominant in production.

### Connectivity

A FIX session runs over a point-to-point TCP/IP socket. One side is the **Initiator** (typically the buy-side firm or OMS), the other is the **Acceptor** (typically the broker or trading venue). Before any FIX messages can be exchanged, the TCP connection must be established. A telnet to the host and port is enough to verify basic reachability.

Transport layer options include:

- Local loopback (for development and testing)
- LAN / intranet
- Internet with TLS/SSL
- Private leased lines (common at large institutions)

Starting with FIX 5.0, the protocol formally separated the transport layer from the application layer, allowing FIX messages to run over alternative transports like message queues. In practice, most production sessions still use the built-in TCP session layer.

### FIX Versions

Production FIX starts at version 4.0. Earlier versions have been deprecated. The version used on any given session depends on what the counterparty supports; there's no universal upgrade path.

- **FIX 4.0**: Legacy equity trading. Still in use at some older institutions but declining. Order cancel and correct workflows have known ambiguities in the spec.
- **FIX 4.2 (released 2000)**: The most widely deployed FIX version for equity and equity derivatives (futures and options). Cancel and replace workflows are clearly defined. Also used for simple FX spot and forward trading.
- **FIX 4.4 (released 2003)**: The version of choice for fixed income and more complex FX. Also used for equity where counterparties have moved off 4.2. FIXSIM supports FIX 4.4 for all order types and execution workflows.
- **FIX 5.0 / 5.0 SP1 / 5.0 SP2**: Introduced transport layer separation and FIXT 1.1 as the session protocol. Used for OTC products including credit default swaps (CDS) and interest rate swaps (IRS). Service packs added support for additional asset classes and message types.

### Session Handshake

Once the TCP connection is up, the Initiator sends a **Logon message (35=A)** to the Acceptor. The Acceptor validates the SenderCompID (tag 49), checks the incoming sequence number, and either responds with its own Logon (session accepted) or closes the socket (session rejected).

After logon, both sides send periodic **Heartbeats (35=0)** at the interval negotiated in the Logon message (HeartBtInt, tag 108, typically 30 or 60 seconds). Heartbeats confirm not just that the socket is open, but that the counterparty is actively processing messages. If a heartbeat is missed, a TestRequest (35=1) is sent. If that goes unanswered, the session is considered lost and disconnects.

### Message Delivery and Sequence Numbers

Every FIX message carries a MsgSeqNum (tag 34) that increments by one for every message sent. The session starts at sequence number 1 on Logon and counts up from there across the trading day. Both sides track the sequence numbers they've sent and received.

If a gap is detected (say messages 4 through 11 were not received), the receiving side issues a **ResendRequest (35=2)** for the missing range. No subsequent messages are processed until the gap is filled. This is the FIX protocol's built-in guaranteed delivery mechanism and it operates at the session layer, below the application layer.

At the start of each trading day, sequence numbers typically reset to 1 via a Logon with ResetSeqNumFlag (tag 141=Y). Some firms keep sequence numbers running across days; this is a configuration choice negotiated with the counterparty.

### Application Message Types

The session layer (Logon, Heartbeat, ResendRequest, etc.) handles connectivity. The application layer handles business logic. Common application message types:

- **New Order Single (35=D)** - Submit a new order for execution
- **Execution Report (35=8)** - Acknowledge, fill, cancel, or reject an order
- **Order Cancel Request (35=F)** - Request to cancel an open order
- **Order Cancel/Replace Request (35=G)** - Modify price or quantity of an open order
- **Order Cancel Reject (35=9)** - Broker unable to process cancel or replace
- **New Order Multileg (35=AB)** - Complex trades with multiple legs
- **Allocation Report (35=AS)** - Post-trade account allocation breakdown

Each message type has a defined set of required and optional tags. Required tags that are missing or malformed will typically result in a reject or a session-level error.

### Custom Tags

FIX allows custom tag ranges (above 5000 for user-defined fields) for firm-specific data. Broker-dealers commonly use custom tags to pass algorithmic trading parameters (algorithm name, strategy type, urgency level) alongside a standard New Order Single.

Any counterparty that needs to process custom tags must explicitly support them in their implementation. FIX certification usually includes testing that custom tags are handled correctly on both sides.

### Testing FIX Connections

When building or certifying a FIX integration, you need a counterparty to test against before going live. FIXSIM acts as that counterparty: it accepts your FIX connection, responds to orders with configurable execution reports, and lets you test edge cases that would be hard to reproduce against a live broker.

Things you can test with FIXSIM:

- Session establishment and logon/logout workflows
- Order submission, partial fills, full fills, and rejections
- Cancel and replace handling
- Sequence number gap detection and resend request handling
- High-volume and stress testing
- Custom tag processing

## Sample FIX Messages

Source: https://www.fixsim.com/sample-fix-messages

Real FIX protocol messages from a live simulator session, shown in raw wire format (pipe `|` shown in place of the SOH 0x01 delimiter) and decoded field-by-field. Use these to understand message structure, validate your parser, or compare against your own implementation. Covers both FIX 4.2 and FIX 4.4.

### FIX Protocol Version 4.4


#### New Order Single (MsgType 35=D)

```
8=FIX.4.4|9=148|35=D|34=1080|49=TESTBUY1|52=20180920-18:14:19.508|56=TESTSELL1|11=636730640278898634|15=USD|21=2|38=7000|40=1|54=1|55=MSFT|60=20180920-18:14:19.492|10=092|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 148 | Message body length in bytes |
| 35 | MsgType | D | New Order – Single |
| 34 | MsgSeqNum | 1080 | Sequence number |
| 49 | SenderCompID | TESTBUY1 | Sender identifier |
| 52 | SendingTime | 20180920-18:14:19.508 | UTC timestamp |
| 56 | TargetCompID | TESTSELL1 | Recipient identifier |
| 11 | ClOrdID | 636730640278898634 | Client order ID (unique per order) |
| 15 | Currency | USD | Order currency |
| 21 | HandlInst | 2 | Automated execution, no broker intervention |
| 38 | OrderQty | 7000 | Number of shares/units |
| 40 | OrdType | 1 | Market order |
| 54 | Side | 1 | Buy |
| 55 | Symbol | MSFT | Instrument symbol |
| 60 | TransactTime | 20180920-18:14:19.492 | Time order was created |
| 10 | CheckSum | 092 | 3-digit message checksum |


#### Execution Report (MsgType 35=8)

```
8=FIX.4.4|9=289|35=8|34=1090|49=TESTSELL1|52=20180920-18:23:53.671|56=TESTBUY1|6=113.35|11=636730640278898634|14=3500|15=USD|17=206367306463353100002|21=2|31=113.35|32=3500|37=206367306463353100003|38=7000|39=1|40=1|54=1|55=MSFT|60=20180920-18:23:53.531|150=F|151=3500|453=1|448=BRK2|447=D|452=1|10=151|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 289 | Message body length in bytes |
| 35 | MsgType | 8 | Execution Report |
| 34 | MsgSeqNum | 1090 | Sequence number |
| 49 | SenderCompID | TESTSELL1 | Sender (sell-side / broker) |
| 52 | SendingTime | 20180920-18:23:53.671 | UTC timestamp |
| 56 | TargetCompID | TESTBUY1 | Recipient (buy-side / OMS) |
| 6 | AvgPx | 113.35 | Average fill price |
| 11 | ClOrdID | 636730640278898634 | Original client order ID (echoed back) |
| 14 | CumQty | 3500 | Total quantity filled so far |
| 15 | Currency | USD | Order currency |
| 17 | ExecID | 20636730646335310000 | Unique execution identifier |
| 31 | LastPx | 113.35 | Price of this fill |
| 32 | LastQty | 3500 | Quantity of this fill |
| 37 | OrderID | 20636730646335310000 | Broker-assigned order ID |
| 38 | OrderQty | 7000 | Original order quantity |
| 39 | OrdStatus | 1 | Partially filled |
| 54 | Side | 1 | Buy |
| 55 | Symbol | MSFT | Instrument symbol |
| 150 | ExecType | F | Trade (partial or full fill) |
| 151 | LeavesQty | 3500 | Remaining open quantity |
| 453 | NoPartyIDs | 1 | Number of party entries |
| 448 | PartyID | BRK2 | Broker identifier |
| 447 | PartyIDSource | D | Proprietary / custom identifier |
| 452 | PartyRole | 1 | Executing firm |
| 10 | CheckSum | 151 | 3-digit message checksum |


#### Order Cancel Request (MsgType 35=F)

```
8=FIX.4.4|9=168|35=F|34=941|49=TESTBUY5|52=20260324-15:48:09.239|56=FIXSIM|11=5639099640892351941|38=1000|41=7639099640711117266|54=2|55=INTC|60=20260324-15:48:09.235|10=244|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 168 | Message body length in bytes |
| 35 | MsgType | F | Order Cancel Request |
| 34 | MsgSeqNum | 941 | Sequence number |
| 49 | SenderCompID | TESTBUY5 | Buy-side OMS requesting cancel |
| 52 | SendingTime | 20260324-15:48:09.239 | UTC timestamp |
| 56 | TargetCompID | FIXSIM | Broker / counterparty receiving cancel |
| | **CANCEL DETAILS** | | |
| 41 | OrigClOrdID | 7639099640711117266 | ClOrdID of the order being cancelled |
| 11 | ClOrdID | 5639099640892351941 | New unique ID for this cancel request |
| 55 | Symbol | INTC | Instrument being cancelled |
| 54 | Side | 2 | Sell |
| 38 | OrderQty | 1000 | Original order quantity to cancel |
| 60 | TransactTime | 20260324-15:48:09.235 | Time cancel was submitted |
| | **TRAILER** | | |
| 10 | CheckSum | 244 | 3-digit message checksum |


#### Order Cancel/Replace Request (MsgType 35=G)

```
8=FIX.4.4|9=167|35=G|34=993|49=TESTBUY5|52=20260324-16:37:40.694|56=FIXSIM|11=8639099670606720316|21=1|38=1200|40=1|41=1263909966920544578|54=1|55=MSFT|59=0|60=20260324-16:37:40.672|10=169|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 167 | Message body length in bytes |
| 35 | MsgType | G | Order Cancel/Replace Request (amend) |
| 34 | MsgSeqNum | 993 | Sequence number |
| 49 | SenderCompID | TESTBUY5 | Buy-side OMS sending the amend |
| 52 | SendingTime | 20260324-16:37:40.694 | UTC timestamp |
| 56 | TargetCompID | FIXSIM | Broker / counterparty receiving amend |
| | **AMEND DETAILS** | | |
| 41 | OrigClOrdID | 1263909966920544578 | ClOrdID of the order being amended |
| 11 | ClOrdID | 8639099670606720316 | New unique ID for this amend request |
| 55 | Symbol | MSFT | Instrument being amended |
| 54 | Side | 1 | Buy |
| 38 | OrderQty | 1200 | New requested quantity (replaces original) |
| 40 | OrdType | 1 | Market order |
| 21 | HandlInst | 1 | Automated execution, no broker intervention |
| 59 | TimeInForce | 0 | Day order |
| 60 | TransactTime | 20260324-16:37:40.672 | Time amend was submitted |
| | **TRAILER** | | |
| 10 | CheckSum | 169 | 3-digit message checksum |


#### Allocation Instruction (MsgType 35=J)

```
8=FIX.4.4|9=427|35=J|34=261|49=MYOMS|52=20251019-19:38:07.929|56=BLOOM|6=100.6171875|15=USD|22=1|48=912828XF2|53=300000|54=1|55=T 1 1/8 06/15/18|60=20251019-19:38:01|64=20251020|70=0000620251019|71=0|73=1|11=0000120151019|75=20251019|78=1|79=USFIX3|80=300000|467=4|81=0|12=0|13=1|153=100.6171875|154=303022.671|120=USD|124=1|32=300000|17=242:6432:342|31=100.6171875|423=1|453=1|448=9001|447=C|452=1|626=1|793=2|10=237|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 427 | Message body length in bytes |
| 35 | MsgType | J | Allocation Instruction |
| 34 | MsgSeqNum | 261 | Sequence number |
| 49 | SenderCompID | MYOMS | OMS sending the allocation |
| 52 | SendingTime | 20251019-19:38:07.929 | UTC timestamp |
| 56 | TargetCompID | BLOOM | Recipient (e.g. Bloomberg AIM) |
| | **INSTRUMENT** | | |
| 55 | Symbol | T 1 1/8 06/15/18 | US Treasury Note descriptor |
| 48 | SecurityID | 912828XF2 | CUSIP identifier |
| 22 | SecurityIDSource | 1 | CUSIP number |
| | **ALLOCATION DETAILS** | | |
| 70 | AllocID | 0000620251019 | Unique allocation identifier |
| 71 | AllocTransType | 0 | New allocation |
| 626 | AllocType | 1 | Calculated (post-trade) |
| 54 | Side | 1 | Buy |
| 53 | Shares | 300,000 | Total face value allocated |
| 6 | AvgPx | 100.6171875 | Average fill price (% of par) |
| 15 | Currency | USD | Trade currency |
| 120 | SettlCurrency | USD | Settlement currency |
| 60 | TransactTime | 20251019-19:38:01 | Time of transaction |
| 75 | TradeDate | 20251019 | Trade date |
| 64 | FutSettDate | 20251020 | Settlement date (T+1) |
| 12 | Commission | 0 | Commission amount |
| 13 | CommType | 1 | Per unit |
| | **ORDERS (NoOrders=1)** | | |
| 73 | NoOrders | 1 | Number of orders in this allocation |
| 11 | ClOrdID | 0000120151019 | Original client order ID |
| | **ALLOC ACCOUNTS (NoAllocs=1)** | | |
| 78 | NoAllocs | 1 | Number of sub-allocations |
| 79 | AllocAccount | USFIX3 | Account receiving allocation |
| 80 | AllocShares | 300,000 | Shares/face value for this account |
| 467 | IndividualAllocID | 4 | ID for this individual allocation |
| 153 | AllocPrice | 100.6171875 | Allocated price for this account |
| 154 | AllocNetMoney | 303,022.671 | Net money for this account |
| 81 | ProcessCode | 0 | Regular trade |
| | **EXECUTIONS (NoExecs=1)** | | |
| 124 | NoExecs | 1 | Number of execution entries |
| 17 | ExecID | 242:6432:342 | Execution identifier |
| 32 | LastQty | 300,000 | Quantity of this execution |
| 31 | LastPx | 100.6171875 | Price of this execution |
| 423 | PriceType | 1 | Percentage (bond price as % of par) |
| | **PARTIES (NoPartyIDs=1)** | | |
| 453 | NoPartyIDs | 1 | Number of party entries |
| 448 | PartyID | 9001 | Executing broker identifier |
| 447 | PartyIDSource | C | Generally accepted market participant identifier |
| 452 | PartyRole | 1 | Executing firm |
| | **TRAILER** | | |
| 10 | CheckSum | 237 | 3-digit message checksum |


#### Allocation Instruction Ack (MsgType 35=P)

```
8=FIX.4.4|9=127|35=P|34=698|49=TESTSELL1|52=20260324-15:44:11.705|56=TESTBUY1|60=20260324-15:44:11.705|70=2639096067028819307|75=20251019|87=0|10=021|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 127 | Message body length in bytes |
| 35 | MsgType | P | Allocation Instruction Ack - response to a 35=J |
| 34 | MsgSeqNum | 698 | Sequence number |
| 49 | SenderCompID | TESTSELL1 | Broker/counterparty sending the ack |
| 52 | SendingTime | 20260324-15:44:11.705 | UTC timestamp |
| 56 | TargetCompID | TESTBUY1 | OMS that sent the original J message |
| | **ACK DETAILS** | | |
| 70 | AllocID | 2639096067028819307 | References the AllocID from the original 35=J |
| 75 | TradeDate | 20251019 | Trade date of the original allocation |
| 60 | TransactTime | 20260324-15:44:11.705 | Time ack was processed |
| 87 | AllocStatus | 0 | Accepted - allocation approved without exceptions |
| | **TRAILER** | | |
| 10 | CheckSum | 021 | 3-digit message checksum |


#### Logon (MsgType 35=A)

```
8=FIX.4.4|9=75|35=A|34=1092|49=TESTBUY1|52=20180920-18:24:59.643|56=TESTSELL1|98=0|108=60|10=178|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 75 | Message body length in bytes |
| 35 | MsgType | A | Logon - initiates a FIX session |
| 34 | MsgSeqNum | 1092 | Sequence number (must be 1 on fresh session) |
| 49 | SenderCompID | TESTBUY1 | Initiating party |
| 52 | SendingTime | 20180920-18:24:59.643 | UTC timestamp |
| 56 | TargetCompID | TESTSELL1 | Accepting party |
| 98 | EncryptMethod | 0 | None (no encryption) |
| 108 | HeartBtInt | 60 | Heartbeat interval in seconds |
| 10 | CheckSum | 178 | 3-digit message checksum |


#### Logout (MsgType 35=5)

```
8=FIX.4.4|9=63|35=5|34=1091|49=TESTBUY1|52=20180920-18:24:58.675|56=TESTSELL1|10=138|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.4 | FIX version |
| 9 | BodyLength | 63 | Message body length in bytes |
| 35 | MsgType | 5 | Logout - terminates a FIX session |
| 34 | MsgSeqNum | 1091 | Sequence number |
| 49 | SenderCompID | TESTBUY1 | Party initiating disconnect |
| 52 | SendingTime | 20180920-18:24:58.675 | UTC timestamp |
| 56 | TargetCompID | TESTSELL1 | Counterparty |
| 10 | CheckSum | 138 | 3-digit message checksum |


### FIX Protocol Version 4.2


#### New Order Single (MsgType 35=D)

```
8=FIX.4.2|9=163|35=D|34=972|49=TESTBUY3|52=20190206-16:25:10.403|56=TESTSELL3|11=141636850670842269979|21=2|38=100|40=1|54=1|55=AAPL|60=20190206-16:25:08.968|207=TO|6000=TEST1234|10=106|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 163 | Message body length in bytes |
| 35 | MsgType | D | New Order – Single |
| 34 | MsgSeqNum | 972 | Sequence number |
| 49 | SenderCompID | TESTBUY3 | Sender identifier |
| 52 | SendingTime | 20190206-16:25:10.403 | UTC timestamp |
| 56 | TargetCompID | TESTSELL3 | Recipient identifier |
| 11 | ClOrdID | 141636850670842269979 | Client order ID (unique per order) |
| 21 | HandlInst | 2 | Automated execution, no broker intervention |
| 38 | OrderQty | 100 | Number of shares/units |
| 40 | OrdType | 1 | Market order |
| 54 | Side | 1 | Buy |
| 55 | Symbol | AAPL | Instrument symbol |
| 60 | TransactTime | 20190206-16:25:08.968 | Time order was created |
| 207 | SecurityExchange | TO | Toronto Stock Exchange (TSX) |
| 6000 | Custom Field | TEST1234 | User-defined custom tag |
| 10 | CheckSum | 106 | 3-digit message checksum |


#### Execution Report (MsgType 35=8)

```
8=FIX.4.2|9=271|35=8|34=974|49=TESTSELL3|52=20190206-16:26:09.059|56=TESTBUY3|6=174.51|11=141636850670842269979|14=100|17=36368506716843579792|20=0|21=2|31=174.51|32=100|37=10054483|38=100|39=2|40=1|54=1|55=AAPL|60=20190206-16:26:08.435|150=2|151=0|10=194|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 271 | Message body length in bytes |
| 35 | MsgType | 8 | Execution Report |
| 34 | MsgSeqNum | 974 | Sequence number |
| 49 | SenderCompID | TESTSELL3 | Sender (sell-side / broker) |
| 52 | SendingTime | 20190206-16:26:09.059 | UTC timestamp |
| 56 | TargetCompID | TESTBUY3 | Recipient (buy-side / OMS) |
| 6 | AvgPx | 174.51 | Average fill price |
| 11 | ClOrdID | 141636850670842269979 | Original client order ID (echoed back) |
| 14 | CumQty | 100 | Total quantity filled |
| 17 | ExecID | 36368506716843579792 | Unique execution identifier |
| 20 | ExecTransType | 0 | New execution (FIX 4.2 only) |
| 31 | LastPx | 174.51 | Price of this fill |
| 32 | LastQty | 100 | Quantity of this fill |
| 37 | OrderID | 10054483 | Broker-assigned order ID |
| 38 | OrderQty | 100 | Original order quantity |
| 39 | OrdStatus | 2 | Fully filled |
| 54 | Side | 1 | Buy |
| 55 | Symbol | AAPL | Instrument symbol |
| 150 | ExecType | 2 | Fill |
| 151 | LeavesQty | 0 | Remaining open quantity (zero = fully filled) |
| 10 | CheckSum | 194 | 3-digit message checksum |


#### Order Cancel Request (MsgType 35=F)

```
8=FIX.4.2|9=154|35=F|34=944|49=TESTBUY4|52=20260324-15:48:58.329|56=TESTSELL4|11=6639099641381204755|38=1500|41=9639099641173096676|54=1|55=MSFT|60=20260324-15:48:58.120|10=195|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 154 | Message body length in bytes |
| 35 | MsgType | F | Order Cancel Request |
| 34 | MsgSeqNum | 944 | Sequence number |
| 49 | SenderCompID | TESTBUY4 | Buy-side OMS requesting cancel |
| 52 | SendingTime | 20260324-15:48:58.329 | UTC timestamp |
| 56 | TargetCompID | TESTSELL4 | Broker / counterparty receiving cancel |
| | **CANCEL DETAILS** | | |
| 41 | OrigClOrdID | 9639099641173096676 | ClOrdID of the order being cancelled |
| 11 | ClOrdID | 6639099641381204755 | New unique ID for this cancel request |
| 55 | Symbol | MSFT | Instrument being cancelled |
| 54 | Side | 1 | Buy |
| 38 | OrderQty | 1500 | Original order quantity to cancel |
| 60 | TransactTime | 20260324-15:48:58.120 | Time cancel was submitted |
| | **TRAILER** | | |
| 10 | CheckSum | 195 | 3-digit message checksum |


#### Order Cancel/Replace Request (MsgType 35=G)

```
8=FIX.4.2|9=170|35=G|34=993|49=TESTBUY4|52=20260324-16:37:26.192|56=TESTSELL4|11=7639099670461883708|21=2|38=1200|40=1|41=1363909966930199451|54=1|55=MSFT|59=0|60=20260324-16:37:26.188|10=125|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 170 | Message body length in bytes |
| 35 | MsgType | G | Order Cancel/Replace Request (amend) |
| 34 | MsgSeqNum | 993 | Sequence number |
| 49 | SenderCompID | TESTBUY4 | Buy-side OMS sending the amend |
| 52 | SendingTime | 20260324-16:37:26.192 | UTC timestamp |
| 56 | TargetCompID | TESTSELL4 | Broker / counterparty receiving amend |
| | **AMEND DETAILS** | | |
| 41 | OrigClOrdID | 1363909966930199451 | ClOrdID of the order being amended |
| 11 | ClOrdID | 7639099670461883708 | New unique ID for this amend request |
| 55 | Symbol | MSFT | Instrument being amended |
| 54 | Side | 1 | Buy |
| 38 | OrderQty | 1200 | New requested quantity (replaces original) |
| 40 | OrdType | 1 | Market order |
| 21 | HandlInst | 2 | Automated execution, no broker intervention |
| 59 | TimeInForce | 0 | Day order |
| 60 | TransactTime | 20260324-16:37:26.188 | Time amend was submitted |
| | **TRAILER** | | |
| 10 | CheckSum | 125 | 3-digit message checksum |


#### Allocation Instruction (MsgType 35=J)

```
8=FIX.4.2|9=706|35=J|49=MYOMS|56=BROKER|34=525|52=20230625-17:09:44|60=20230625-17:09:44|64=20230628|6=92.951|159=52430.56|70=3739:20230625:65667:5:0|71=0|15=USD|75=20230625|48=US85227SAJ503|22=4|53=200000|54=1|55=[N/A]|118=1911430.567|73=1|11=23847620SD|37=ORDER:23434625:65667:5|38=200000|78=2|79=US1|80=1370000|153=92.95|154=1309329.93|79=US2|80=630000|153=92.95|154=602100.63|124=1|32=200000|31=92.95|10=195|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 706 | Message body length in bytes |
| 35 | MsgType | J | Allocation Instruction |
| 34 | MsgSeqNum | 525 | Sequence number |
| 49 | SenderCompID | MYOMS | OMS sending the allocation |
| 52 | SendingTime | 20230625-17:09:44 | UTC timestamp |
| 56 | TargetCompID | BROKER | Recipient (executing broker) |
| | **INSTRUMENT** | | |
| 55 | Symbol | [N/A] | Symbol not applicable - identified by ISIN |
| 48 | SecurityID | US85227SAJ503 | ISIN identifier |
| 22 | IDSource | 4 | ISIN number |
| | **ALLOCATION DETAILS** | | |
| 70 | AllocID | 3739:20230625:65667:5:0 | Unique allocation identifier |
| 71 | AllocTransType | 0 | New allocation |
| 54 | Side | 1 | Buy |
| 53 | Shares | 200,000 | Total face value allocated |
| 6 | AvgPx | 92.951 | Average fill price (% of par) |
| 159 | AccruedInterestAmt | 52,430.56 | Accrued interest on bond position |
| 118 | NetMoney | 1,911,430.567 | Total net settlement amount |
| 15 | Currency | USD | Trade currency |
| 60 | TransactTime | 20230625-17:09:44 | Time of transaction |
| 75 | TradeDate | 20230625 | Trade date |
| 64 | FutSettDate | 20230628 | Settlement date (T+3, corp bond standard) |
| | **ORDERS (NoOrders=1)** | | |
| 73 | NoOrders | 1 | Number of orders in this allocation |
| 11 | ClOrdID | 23847620SD | Original client order ID |
| 37 | OrderID | ORDER:23434625:65667:5 | Broker-assigned order ID |
| 38 | OrderQty | 200,000 | Original order quantity |
| | **ALLOC ACCOUNTS (NoAllocs=2) - split allocation** | | |
| 78 | NoAllocs | 2 | Two accounts receiving this allocation |
| 79 | AllocAccount | US1 | Account 1 |
| 80 | AllocShares | 1,370,000 | Face value for account 1 |
| 153 | AllocPrice | 92.95 | Allocated price for account 1 |
| 154 | AllocNetMoney | 1,309,329.93 | Net money for account 1 |
| 79 | AllocAccount | US2 | Account 2 |
| 80 | AllocShares | 630,000 | Face value for account 2 |
| 153 | AllocPrice | 92.95 | Allocated price for account 2 |
| 154 | AllocNetMoney | 602,100.63 | Net money for account 2 |
| | **EXECUTIONS (NoExecs=1)** | | |
| 124 | NoExecs | 1 | Number of execution entries |
| 32 | LastQty | 200,000 | Quantity of this execution |
| 31 | LastPx | 92.95 | Price of this execution |
| | **TRAILER** | | |
| 10 | CheckSum | 195 | 3-digit message checksum |


#### Allocation Instruction Ack (MsgType 35=P)

```
8=FIX.4.2|9=127|35=P|34=936|49=TESTSELL3|52=20260324-15:45:13.992|56=TESTBUY3|60=20260324-15:45:13.992|70=3639096067028819307|75=20230625|87=0|10=041|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| | **HEADER** | | |
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 127 | Message body length in bytes |
| 35 | MsgType | P | Allocation Instruction Ack - response to a 35=J |
| 34 | MsgSeqNum | 936 | Sequence number |
| 49 | SenderCompID | TESTSELL3 | Broker/counterparty sending the ack |
| 52 | SendingTime | 20260324-15:45:13.992 | UTC timestamp |
| 56 | TargetCompID | TESTBUY3 | OMS that sent the original J message |
| | **ACK DETAILS** | | |
| 70 | AllocID | 3639096067028819307 | References the AllocID from the original 35=J |
| 75 | TradeDate | 20230625 | Trade date of the original allocation |
| 60 | TransactTime | 20260324-15:45:13.992 | Time ack was processed |
| 87 | AllocStatus | 0 | Accepted - allocation approved without exceptions |
| | **TRAILER** | | |
| 10 | CheckSum | 041 | 3-digit message checksum |


#### Logon (MsgType 35=A)

```
8=FIX.4.2|9=74|35=A|34=978|49=TESTSELL3|52=20190206-16:29:19.208|56=TESTBUY3|98=0|108=60|10=137|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 74 | Message body length in bytes |
| 35 | MsgType | A | Logon - initiates a FIX session |
| 34 | MsgSeqNum | 978 | Sequence number |
| 49 | SenderCompID | TESTSELL3 | Initiating party |
| 52 | SendingTime | 20190206-16:29:19.208 | UTC timestamp |
| 56 | TargetCompID | TESTBUY3 | Accepting party |
| 98 | EncryptMethod | 0 | None (no encryption) |
| 108 | HeartBtInt | 60 | Heartbeat interval in seconds |
| 10 | CheckSum | 137 | 3-digit message checksum |


#### Logout (MsgType 35=5)

```
8=FIX.4.2|9=62|35=5|34=977|49=TESTSELL3|52=20190206-16:28:51.518|56=TESTBUY3|10=092|
```

| Tag | Field Name | Value | Description |
|---|---|---|---|
| 8 | BeginString | FIX.4.2 | FIX version |
| 9 | BodyLength | 62 | Message body length in bytes |
| 35 | MsgType | 5 | Logout - terminates a FIX session |
| 34 | MsgSeqNum | 977 | Sequence number |
| 49 | SenderCompID | TESTSELL3 | Party initiating disconnect |
| 52 | SendingTime | 20190206-16:28:51.518 | UTC timestamp |
| 56 | TargetCompID | TESTBUY3 | Counterparty |
| 10 | CheckSum | 092 | 3-digit message checksum |


## FIX Execution Report (35=8) Reference

Source: https://www.fixsim.com/fix-execution-report

The Execution Report is the broker's response to everything. Send a New Order Single and you get one back. Cancel an order and you get one back. Partial fill, full fill, reject: all Execution Reports. It's the most important message type in FIX and also the one with the most implementation traps.

### ExecType vs OrdStatus

This is where most implementations go wrong. The two fields are related but different:

- **ExecType (tag 150)** - what just happened in this report
- **OrdStatus (tag 39)** - the current state of the order

On an order acknowledgement, ExecType=0 (New) and OrdStatus=0 (New). Both say the same thing. On a partial fill, ExecType=F (Trade) and OrdStatus=1 (PartiallyFilled). Now they diverge. ExecType tells you a trade happened. OrdStatus tells you the order still has quantity open. A common mistake is treating them as the same field or only checking one of them. Brokers can and do send combinations that seem redundant until an edge case hits.

| Scenario | ExecType (150) | OrdStatus (39) |
|---|---|---|
| Order acknowledged | 0 = New | 0 = New |
| Partial fill | F = Trade | 1 = PartiallyFilled |
| Full fill | F = Trade | 2 = Filled |
| Cancel confirmed | 4 = Canceled | 4 = Canceled |
| Replace confirmed | 5 = Replace | 0 = New (resets) |
| Order rejected | 8 = Rejected | 8 = Rejected |
| Pending cancel | 6 = PendingCancel | 6 = PendingCancel |

### Key Fields

| Tag | Field | Notes |
|---|---|---|
| 11 | ClOrdID | Your order identifier. Echoed back in every report for that order. |
| 14 | CumQty | Total quantity filled so far, cumulative across all fills. |
| 17 | ExecID | Unique identifier for this specific report. Increments with every report sent. |
| 31 | LastPx | Price of this fill. Only present on trade reports (ExecType=F). |
| 32 | LastQty | Quantity of this fill. Only present on trade reports. |
| 37 | OrderID | The broker's identifier for the order. Different from your ClOrdID. |
| 38 | OrderQty | Original order quantity as submitted. |
| 39 | OrdStatus | Current state of the order. See ExecType vs OrdStatus above. |
| 58 | Text | Free text reason, usually populated on rejects. |
| 150 | ExecType | What happened in this specific report. |
| 151 | LeavesQty | Quantity still open. Zero when filled or canceled. |

### Example Messages

Acknowledgement:

```
8=FIX.4.4|9=160|35=8|34=2|49=BROKER|52=20240115-14:30:02.000|56=OMS|11=ORD-001|14=0|17=EXEC-001|20=0|37=BRKR-001|38=500|39=0|40=2|44=150.25|54=1|55=AAPL|150=0|151=500|10=088|
```

Partial Fill:

```
8=FIX.4.4|9=180|35=8|34=3|49=BROKER|52=20240115-14:30:05.000|56=OMS|6=150.25|11=ORD-001|14=200|17=EXEC-002|20=0|31=150.25|32=200|37=BRKR-001|38=500|39=1|40=2|44=150.25|54=1|55=AAPL|150=F|151=300|10=112|
```

Full Fill:

```
8=FIX.4.4|9=180|35=8|34=4|49=BROKER|52=20240115-14:30:08.000|56=OMS|6=150.25|11=ORD-001|14=500|17=EXEC-003|20=0|31=150.25|32=300|37=BRKR-001|38=500|39=2|40=2|44=150.25|54=1|55=AAPL|150=F|151=0|10=199|
```

Cancel Confirmed:

```
8=FIX.4.4|9=165|35=8|34=5|49=BROKER|52=20240115-14:31:01.000|56=OMS|11=ORD-002|14=0|17=EXEC-004|20=0|37=BRKR-001|38=500|39=4|40=2|41=ORD-001|44=150.25|54=1|55=AAPL|150=4|151=0|10=077|
```

Reject:

```
8=FIX.4.4|9=170|35=8|34=6|49=BROKER|52=20240115-14:30:03.000|56=OMS|11=ORD-001|14=0|17=EXEC-005|20=0|37=NONE|38=500|39=8|40=2|44=150.25|54=1|55=AAPL|58=Unknown symbol|150=8|151=0|10=143|
```

### Common Implementation Mistakes

- **Only checking OrdStatus**: Some implementations ignore ExecType and only look at OrdStatus to determine what happened. This breaks on pending states and on brokers that send intermediary reports before the final state. Always check both.
- **Not handling Pending states**: PendingCancel (39=6) and PendingNew (39=A) are real states that some brokers send. If your system expects a cancel confirmation and gets a PendingCancel first, it needs to wait for the final Canceled report rather than treating the pending as a failure.
- **CumQty + LeavesQty math**: CumQty + LeavesQty should always equal OrderQty. If it doesn't, something is wrong. This is a quick sanity check worth adding to your processing logic.
- **Assuming ExecID is sequential**: ExecID (tag 17) is unique but not guaranteed to be sequential across sessions or reconnects. Don't use it as a counter. Use it as a unique key for deduplication.

## FIX Certification Checklist

Source: https://www.fixsim.com/fix-certification-checklist

FIX certification is the process a broker, exchange, or trading venue uses to verify that your system connects and behaves correctly over FIX before allowing live trading. Most venues run you through a defined set of session and application layer test cases, and they expect you to pass them all in a limited number of sessions.

Certification slots are scheduled in advance and failures mean rescheduling. The teams that get through fastest are the ones who've already tested the edge cases themselves. FIX certification failures typically trace back to the same issues: session-state edge cases, sequence number recovery, and inconsistent order lifecycle behavior under stress. Work through this list before you book certification time.

### Session Layer Checklist

- **Logon / Logout**: correct credentials, encryption flags, ResetSeqNumFlag behavior (if used)
- **Heartbeats**: HeartBtInt honored; TestRequest handling; disconnect behavior
- **Sequence numbers**: gap detection, resend requests, duplicate handling
- **Recovery**: resend flows do not create side effects (e.g., duplicate executions)
- **Rejects**: proper session rejects for malformed messages and invalid tags
- **Reset scenarios**: sequence reset rules match counterparty expectations

### Application Layer Checklist

- **New Order Single**: required tags present; custom tags; symbol/security identifiers
- **Exec Reports**: correct ExecType/OrdStatus transitions; leavesQty/cumQty math
- **Cancel / Replace**: proper OrigClOrdID references; CancelReject handling
- **Trade capture / allocations**: if applicable to your workflow
- **Error handling**: business rejects and order rejects are differentiated correctly

### High-Value Failure Scenarios to Test

- Disconnect/reconnect during active order flow
- Resend request mid-stream while new application messages continue
- Out-of-order messages (or delayed acks/executions)
- Partial fills followed by cancel / replace
- Sequence reset or logon reset expectations not matching

### How a Simulator Helps

A simulator lets you validate these scenarios deterministically, without waiting on a broker or exchange environment. You can replay message flows, trigger rejects, and test recovery logic repeatedly until the behavior is stable.

Typical certification timeline: one to several weeks depending on the venue and how prepared your implementation is. Venues allocate limited certification slots and failures require rescheduling. Teams that pre-test against a FIX simulator before booking certification time typically pass faster and with fewer issues.

## Test FIX Protocol with curl (REST API How-To)

Source: https://www.fixsim.com/test-fix-protocol-with-curl

You can send raw FIX messages over HTTP using curl via the FIXSIM REST API. No FIX engine required, no socket connection, no session handshake. Just an HTTP POST with a FIX message string in the body and an execution report comes back on the FIXSIM side. This is useful for smoke tests, regression suites in CI/CD pipelines, and any situation where you want to inject a specific FIX message without spinning up a full FIX session.

### What You Need

- A FIXSIM account (free 7-day trial, no credit card)
- Your instance name
- Your session name
- Your API key (available in the FIXSIM portal)

### Sending a FIX Message with curl

The endpoint accepts a JSON body with a `fixMessages` array containing raw FIX strings. Use a pipe character `|` as the SOH delimiter; the API handles the conversion. Send a New Order Single (35=D):

```bash
curl -X POST "https://portal.fixsim.com/v1/RawMessages/{instance}/{session}" \
  -H "Content-Type: application/json" \
  -H "apiKey: YOUR_API_KEY" \
  -d '{
    "fixMessages": [
      "8=FIX.4.4|9=148|35=D|34=1|49=OMS|52=20240115-14:30:01.000|56=BROKER|11=ORD-001|21=1|38=500|40=2|44=150.25|54=1|55=AAPL|60=20240115-14:30:01.000|10=088|"
    ]
  }'
```

Replace `{instance}`, `{session}`, and `YOUR_API_KEY` with your account values from the portal.

### Sending Multiple Messages in One Call

The `fixMessages` field is an array, so you can replay an entire sequence in a single POST. Useful for testing how your system handles a full order lifecycle:

```bash
curl -X POST "https://portal.fixsim.com/v1/RawMessages/{instance}/{session}" \
  -H "Content-Type: application/json" \
  -H "apiKey: YOUR_API_KEY" \
  -d '{
    "fixMessages": [
      "8=FIX.4.4|9=148|35=D|34=1|49=OMS|52=20240115-14:30:01.000|56=BROKER|11=ORD-001|21=1|38=500|40=2|44=150.25|54=1|55=AAPL|60=20240115-14:30:01.000|10=088|",
      "8=FIX.4.4|9=130|35=F|34=2|49=OMS|52=20240115-14:31:00.000|56=BROKER|11=ORD-002|37=BRKR-001|38=500|41=ORD-001|54=1|55=AAPL|60=20240115-14:31:00.000|10=134|"
    ]
  }'
```

Messages are processed in order. FIXSIM responds to each one according to your session's rule configuration.

### Plugging it into CI/CD

The curl approach works well as a post-deploy smoke test. After pushing a build, hit the endpoint with a known set of messages and verify the responses match expectations. No FIX session to manage, no ports to open in your test environment, just an HTTP call you can run from any CI runner. A basic shell script pattern:

```bash
#!/bin/bash
INSTANCE="your-instance"
SESSION="your-session"
API_KEY="your-api-key"

RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  -X POST "https://portal.fixsim.com/v1/RawMessages/$INSTANCE/$SESSION" \
  -H "Content-Type: application/json" \
  -H "apiKey: $API_KEY" \
  -d '{"fixMessages": ["8=FIX.4.4|9=148|35=D|34=1|49=OMS|52=20240115-14:30:01.000|56=BROKER|11=ORD-001|21=1|38=500|40=2|44=150.25|54=1|55=AAPL|60=20240115-14:30:01.000|10=088|"]}')

if [ "$RESPONSE" -eq 200 ]; then
  echo "FIX smoke test passed"
else
  echo "FIX smoke test failed: HTTP $RESPONSE"
  exit 1
fi
```

### When to Use curl vs a Full FIX Session

The REST API and a live FIX session test different things. Neither replaces the other.

| Use curl when... | Use a full FIX session when... |
|---|---|
| You need a quick smoke test after a deploy | You need to test logon/logout workflows |
| You're running automated regression in CI/CD | You need to test sequence number handling and gap detection |
| You want to inject a specific message without session overhead | You need to test heartbeat and session recovery behavior |
| You're testing application layer logic only | You're certifying a full FIX implementation end-to-end |

Full API reference is available in the FIXSIM API docs at https://portal.fixsim.com/swagger/index.html (login required).

## Test FIX from Claude, ChatGPT, or Cursor (MCP Server How-To)

Source: https://www.fixsim.com/test-fix-from-claude

FIXSIM publishes an MCP (Model Context Protocol) server at https://mcp.fixsim.com/mcp. Any assistant that supports remote MCP servers (Claude, Claude Code, Cursor, ChatGPT, VS Code) can create a FIX test session on the free FIXSIM Developer Sandbox, hand you the host, port, and CompIDs, and then read the wire for you: what your engine sent, what came back, and why an order was rejected. No account, no API key, no install. FIXSIM customers add their API key and the same assistant drives their own instances.

### Connect in 60 Seconds

Server URL (same everywhere): `https://mcp.fixsim.com/mcp`

- Claude (web or desktop): Customize > Connectors > Add custom connector. Paste the URL, choose authentication None, add it, then enable it from the plus menu in a chat.
- Claude Code: `claude mcp add --transport http fixsim https://mcp.fixsim.com/mcp`
- Cursor or VS Code (mcp.json): `{ "mcpServers": { "fixsim": { "url": "https://mcp.fixsim.com/mcp" } } }`
- ChatGPT (web): Settings, then Security and login, turn on Developer mode (Plus, Pro, Business, Enterprise, Education). In a chat choose Developer mode from the plus menu, create an app for a remote MCP server with the URL and No Authentication, then select the app in the conversation. Streaming HTTP supported; no search or fetch tools required.
- Other MCP clients (Gemini CLI, Windsurf, GitHub Copilot in VS Code, anything that reads an mcp.json): same URL, same configuration shape, no authentication.

### Three Prompts to Try

1. "Create a FIX 4.4 test session for me and tell me what to put in tags 49 and 56." The assistant calls the sandbox and returns host, port, SenderCompID, and TargetCompID.
2. "Has my engine logged on yet? Show me the messages so far." It polls the session status and message log and reads the logon exchange back, tag by tag.
3. "Fill the first order I sent and then explain the execution report." It acts as the exchange and explains ExecType, OrdStatus, LastPx, CumQty, and LeavesQty in the 35=8 that came back.

### What the Assistant Can Do (sandbox tools, free, no key)

- sandbox_create_session: provisions a FIX session (host, port, CompIDs, expiry); FIX 4.0, 4.2, 4.4, or 5.0 SP2.
- sandbox_get_status: connected, waiting, or disabled.
- sandbox_get_messages: the full message log, raw and parsed, both directions.
- sandbox_get_orders: working orders your engine sent in.
- sandbox_act_on_order: fill, partial fill, reject, or cancel; FIXSIM sends the execution report.
- sandbox_set_autofill: fill every incoming order automatically.

Every response the assistant sees is real FIX from a real engine.

### For FIXSIM Customers

Add your FIXSIM API key and the connector reaches your own instances: list sessions, read inbound orders and execution reports with raw FIX and audit trail, act on orders, send orders, or send any raw FIX message. It can only see the instances your key is entitled to.

- Claude Code: `claude mcp add --transport http fixsim https://mcp.fixsim.com/mcp --header "x-api-key: YOUR_FIXSIM_API_KEY"`
- Cursor / VS Code: add a `headers` object with `x-api-key`. Claude connector dialog: add `x-api-key` under Request headers.
- Read-only variant: `https://mcp.fixsim.com/mcp/readonly` refuses anything that would send a FIX message.

The REST API behind the connector is included in Pro and Enterprise plans and during the free trial.

### Limits and Privacy

- Sandbox: one session at a time, 100 application messages per day, 4-hour sessions. Nothing persists.
- Your API key is forwarded to FIXSIM on each call and never stored by the connector.
- The connector is open source: https://github.com/GammaThreeTrading/fixsim-mcp

## FIXSIM Product Capabilities

Source: https://www.fixsim.com/fix-simulator and https://www.fixsim.com/fix-protocol-testing

FIXSIM is a FIX protocol simulator and testing platform used by trading firms, broker-dealers, exchanges, OMS/EMS vendors, and fintech teams to test order routing, execution workflows, and trading integrations before production deployment. It simulates broker, exchange, and counterparty behavior so trading systems can validate order flow without connecting to production markets. The platform supports manual testing, automated regression testing, and API-driven validation of FIX connectivity.

### Primary Use Cases

- FIX connectivity certification testing
- Order lifecycle validation (New, Replace, Cancel, Fill, Done-for-Day)
- Automated regression testing of trading systems
- Exchange onboarding and UAT environments
- Support troubleshooting and message replay
- High-volume and stress testing under realistic order rates

### Technical Capabilities

- Counterparty simulation (buy-side or sell-side; initiator, acceptor, or both)
- Rule-based message automation (Rule Builder)
- REST API automation (Swagger/OpenAPI documented)
- FIX session management via the web portal
- Custom tags and custom QuickFIX data dictionaries per session
- FIX versions 4.0 through 5.0SP2
- TLS-encrypted sessions

### Session Layer Testing

The most common use of the FIX protocol is over a TCP/IP socket. At the start of a FIX session, the initiator opens a socket to the acceptor. Once connected, the first message is a Logon. If the Logon is validated and accepted, the acceptor replies with a Logon confirming the session. If rejected, the socket is terminated. Session-layer testing includes dropped messages, unexpected sequencing, resend requests, and duplicates. FIXSIM provides the ability to send invalid messages, send resend requests, and process resend requests from your FIX-enabled application.

### Application Layer Testing

The session layer ensures delivery and message order. The application layer validates business logic. For example, if an order is submitted for buying 500 shares of AAPL and the execution provider reports an execution of 700 shares, the message is formatted correctly but the data is unexpected. FIXSIM allows users to create both expected and unexpected messages to ensure both sides of the interface handle exceptions.

### Manual Testing

With the web-based portal, configure and monitor FIX message traffic, see orders and execution messages, and control how orders are executed.

- **Message Views**: View message traffic in raw FIX format as well as translated tag numbers and values.
- **Blotter Views**: Trade blotter views provide a trader's viewpoint on active orders: order quantities, average prices, and execution values. Take action on orders with workflows like partially fill, cancel, correct prices, and more.

### Automated Testing

- **Rule Builder**: Build rules and actions to respond to messages. Example: if an order is received in FIXSIM for IBM, acknowledge the order, partial fill, and cancel remaining quantity. Configure rules to automate workflows such as rejecting trades over 5,000 shares or partial-filling NVDA orders. Rules enable user-free automation for testing scripts.
- **RESTful API**: Control FIXSIM via RESTful calls (e.g. curl). Documented via Swagger/OpenAPI, so a client can be generated in many languages (C#, Java, Ruby, and more). Used for scripted scenarios and CI pipeline regression runs.

### Buy-Side and Sell-Side Use Cases

- **Buy Side**: Simulate a broker/dealer destination to route orders for execution. Control outcomes such as order rejections, acknowledgements, partial fills, cancel/corrects, done-for-day, and more.
- **Sell Side**: Simulate client order flow into your service. Create multiple connections, submit orders, initiate cancels, and initiate modification requests to validate production readiness.

### How It Works

1. **Connect your FIX engine**: Sign up (no installation required), point your FIX engine at FIXSIM, and configure your sessions in the web portal. FIXSIM supports FIX 4.0 through 5.0SP2 as both acceptor and initiator.
2. **Test manually or automate**: Use blotter and message views for hands-on testing, or use Rule Builder and the REST API to drive scripted scenarios from CI pipelines.
3. **Validate and iterate**: Re-run scenarios for regression testing, replay messages to reproduce edge cases, and use automated rules for repeatable certification rehearsals.

### Options for FIX Testing Environments

- **Open-source or free tools**: A starting point for basic message exchange, but typically require local setup, have limited or inactive maintenance, and lack hosted access, automation features, and vendor support for production-grade workflows.
- **Build your own**: A costly expenditure for most firms: another internal software project to maintain, requiring expertise and continued engineering effort.
- **Broker/dealer test environment**: A trading partner may provide access to a test environment, but it's often limited to one vendor's workflows and availability, with inconsistent reliability and manual coordination required.
- **Vendor solution (FIXSIM)**: Years of expertise and scalable testing. As a SaaS solution, there is no hardware to maintain. Connect your FIX-enabled application and use the web portal to configure, monitor, and take action on your trading workflows.

### Why FIX Protocol Testing Matters

FIX integrations don't fail uniformly. They fail in narrow, specific ways: an unexpected sequence number, a malformed custom tag, a counterparty that rejects orders above a particular threshold, a resend request that arrives during a partial fill. These edge cases rarely appear in normal connectivity testing, but they cause production incidents and trigger certification delays. Robust FIX testing ensures your trading system can handle not only standard workflows, but also session recovery, custom tag requirements, high-volume scenarios, and exception paths. Testing isn't just for initial development; it remains valuable as your trading system expands through new venues, new asset classes, and new counterparties.

FIXSIM was created from real-world FIX protocol development, integration, and support experience. Originally built for Gamma Three Trading to test and validate trading infrastructure, FIXSIM is both the company's product and a tool it relies on itself.

## FIXSIM Developer Sandbox (Free Hosted FIX Test Endpoint)

Source: https://www.fixsim.com/sandbox (live app at https://sandbox.fixsim.com)

Is there a free version of FIXSIM? Yes. The FIXSIM Developer Sandbox is a free, hosted FIX test endpoint: create a session in one click, connect any FIX engine, and act as the counterparty yourself. No account required. For real testing work, paid plans start at $500 per month.

How it works:

1. Create a session. Pick a FIX version (4.0, 4.2, 4.4, or 5.0 SP2 over FIXT 1.1) and click once. You get a host, port, and assigned CompIDs.
2. Connect your engine. QuickFIX, a proprietary stack, anything. The sandbox answers your logon immediately.
3. Trade against yourself. Send an order and it lands in a working-order blotter on the page. Click Fill, Partial, Reject, or Cancel and watch the execution report stream back to your engine in real time.

What you get, free: a hosted FIX acceptor with a real internet network path (testing connectivity a localhost setup cannot), a live message viewer that parses every message into readable fields with the raw FIX underneath, a mini blotter for acting as the counterparty, automatic acks with optional auto-fills, and session recovery by URL.

Limits (by design, it is a sandbox): one session at a time, 100 application messages per day, 4-hour sessions, assigned CompIDs, nothing persists. There is no signup, no email, and no login; bot abuse is limited by a Cloudflare Turnstile check at session creation.

The sandbox is the only hosted free FIX testing endpoint. Free alternatives are self-hosted software you must deploy, configure, and maintain, and they cover fewer FIX versions. The sandbox is already running.

For persistent sessions, your own CompIDs, deterministic automated scenarios (Rule Builder), log replay, multi-session blotters, and the REST API, the full FIXSIM product starts at $500 per month with a 7-day free trial and no credit card required.

## FIX Testing Tools: The Landscape

Source: https://www.fixsim.com/fix-testing-tools

A category guide to every serious FIX testing option, open-source and commercial, with honest fit guidance. "FIX testing tool" covers three kinds of software: a FIX engine (implements your side of the connection; embedded in your application), a simulated counterparty (behaves like a broker, exchange, or client on the other side of the session), and a test platform (adds repeatable scenarios, regression suites, log replay, and CI/CD automation). An engine alone cannot test a connection; something has to answer.

### Open-source options

- **QuickFIX, QuickFIX/J, QuickFIX/n**: the standard open-source FIX engine libraries (C++ with Python/Ruby bindings, Java, and .NET stewarded by Connamara). Actively maintained as of 2026, permissive licenses, free, battle-tested. FIXSIM itself is built on the QuickFIX engine. Use them when you need an engine inside your own application. The bundled sample apps (Banzai, Executor, ordermatch) work for a first smoke test but are teaching examples, not products.
- **FIXimulator**: open-source (GPL) Java sell-side simulator built on QuickFIX/J, originated as a Harvard master's thesis. Unmaintained: last version v0.41, around 2012. Still free and functional for occasional manual testing of a buy-side app.
- **Migrating from FIXimulator**: teams outgrow it when a counterparty upgrades FIX versions, QA needs repeatable regression runs, or nobody wants to own the Java install. The mapping to FIXSIM: GUI blotter becomes a browser-based message blotter, hand-sent executions become Rule Builder rules (fills, partials, cancels, rejects, replaces), log files become replayable test scenarios. Migration is typically an afternoon within the 7-day trial.
- **FIXture**: new open-source entrant with first public releases in 2026; a browser-based FIX testing tool you host yourself. Runtime initiator/acceptor sessions, reusable message templates with spec-driven field pickers for FIX 4.2 and 4.4, send/expect scenario sequences with assertions, latency statistics. Very early in its life; fits teams wanting a free self-hosted tool on FIX 4.2/4.4 who accept very young software.
- **FIXSIM Developer Sandbox**: the only hosted free option. A FIX test endpoint that is already running: create a session in one click at https://sandbox.fixsim.com, connect any FIX engine (QuickFIX, proprietary, anything), and act as the counterparty in the browser (fill, partial, reject, cancel). FIX 4.0 through 5.0 SP2. Free, no account, no install; limits are 100 application messages per day and 4-hour sessions. Every other free tool is self-hosted software you must deploy and maintain. Details: https://www.fixsim.com/sandbox

### Commercial test platforms (quote-based licensing, with one exception)

- **VeriFIX (Broadridge)**: the best-known name in enterprise FIX testing. Originated at Greenline Financial Technologies, moved to Itiviti, part of Broadridge since its 2021 acquisition of Itiviti; now sits inside Broadridge's FIX connectivity and client-certification offering. Capable, mature, used by large institutions. Fits enterprises standardizing on Broadridge's connectivity stack.
- **Esprow ETP**: installed suite (ETP Studio for FIX, ETP Markets for exchange simulation, ETP C-Box for onboarding/certification) with multi-protocol coverage beyond FIX (ITCH, OUCH, SWIFT MT). Licensed per workstation. Fits teams whose test scope goes beyond FIX.
- **B2BITS FIX Client Simulator (EPAM)**: desktop application for Windows, Linux, and macOS simulating buy-side and sell-side workflows, FIX 4.0 through FIXT 1.1, custom dictionaries, automated scenarios, CLI for CI. Commercial with a 30-day trial. Fits installed-desktop preferences and FIX Antenna shops.
- **FIXSOL Nintei**: no-code FIX testing and simulation tool from FIXSOL (part of Fidel Softech); next-gen Nintei-X in beta as of 2026 with GUI and CLI/batch modes. Fits non-programmer QA teams.
- **PhiFIX (Sensiple)**: FIX Test Suite plus a server-side exchange-behavior Simulator, supporting FIX and feed protocols (FAST, ITCH, OUCH). Lower-profile; evaluation by contact.
- **MockFIX**: 2026 entrant from an independent developer; Windows desktop simulator focused on FIX 4.4 with plain-English message composition, auto-response rules, log replay, and a simple execution engine. The exception on pricing: publishes subscription tiers ($49 to $199 per month, 14-day trial). Brand-new — one FIX version, Windows only, no established install base yet. Fits lightweight installed manual testing on FIX 4.4.

### In-house harnesses and venue simulators

An in-house harness (Executor or a homegrown script wired into a test rig) works for one-off integrations but costs maintenance and concentrates knowledge in whoever built it. Venue-provided UAT/certification environments are authoritative for certifying against that specific venue; third-party tools cover everything before and around that final step (certification rehearsal, ongoing regression).

### FIXSIM

Hosted FIX simulator and test platform: a simulated counterparty (acceptor or initiator) reached in a browser, with message blotters, Rule Builder automation, log replay, and a REST API for CI/CD regression. For teams searching for a VeriFIX alternative, this is the role FIXSIM plays: the hosted, self-serve alternative to the enterprise platforms for everyday testing work. Nothing to install, no harness to maintain; the only hosted platform in this category that publishes its pricing, and one of the very few tools of any kind that do (Starter $500 per month, month-to-month, 7-day free trial, no credit card). Honest fit limits: FIXSIM is not an engine library (use QuickFIX for that), not a desktop tool for air-gapped environments, and does not replace a venue's own certification environment for final sign-off.

### Landscape FAQ

- **What are the alternatives to VeriFIX?** VeriFIX, now part of Broadridge's FIX connectivity and testing offering, is quote-based enterprise software. The main alternatives are other commercial test platforms (Esprow ETP, EPAM B2BITS FIX Client Simulator, FIXSOL Nintei, Sensiple PhiFIX), open-source options (the QuickFIX engine family, FIXimulator, and the newer FIXture), new lightweight entrants like MockFIX, and hosted services like FIXSIM, which is self-serve with published pricing (Starter $500/month) and a 7-day free trial.
- **Is FIXSIM a VeriFIX alternative?** Yes. FIXSIM is a hosted VeriFIX alternative for development, QA, regression, and certification rehearsal: a simulated counterparty with browser-based blotters, rule-based automation, log replay, and a REST API for CI/CD, self-serve with published pricing (Starter $500/month) and a 7-day free trial. VeriFIX remains the better fit for enterprises standardized on Broadridge's connectivity stack or buying testing and managed certification from one enterprise vendor; FIXSIM is the low-friction option for the everyday testing work.
- **What is the difference between FIXSIM and QuickFIX?** QuickFIX is an open-source FIX engine library that you embed in your own code; it provides connectivity, but you still have to build the counterparty, test harness, and tooling yourself. FIXSIM is a hosted testing platform built on the QuickFIX engine that provides the simulated counterparty, browser-based blotters and message views, Rule Builder automation, and a REST API, with no harness to build or maintain.
- **Do I still need a FIX simulator if I already use QuickFIX?** Usually yes. A FIX engine handles your side of the connection, but testing requires something on the other side of the session to accept logons, acknowledge orders, and generate fills, cancels, and rejects. A FIX simulator plays that counterparty role.
- **Is FIXimulator still maintained?** No. Last version v0.41, around 2012, with no activity since. Still works for basic manual sell-side simulation, but predates modern FIX versions, automation APIs, and CI/CD workflows.
- **What is the best free FIX simulator?** It depends on whether you want to host it. If you are willing to run software yourself, FIXimulator (unmaintained since 2012), the QuickFIX sample apps, and FIXture (new in 2026, FIX 4.2/4.4 only) are free. If you want nothing to install, the FIXSIM Developer Sandbox is a free hosted FIX endpoint: create a session in one click, connect any engine, and act as the counterparty in the browser, FIX 4.0 through 5.0 SP2, no account. It is limited to 100 messages a day and 4-hour sessions. For real testing work, FIXSIM plans start at $500 per month with a 7-day free trial.
- **Can FIXSIM replace legacy on-premise FIX testing tools?** For most development, QA, regression, and certification-rehearsal workflows, yes. Browser-based with no installation, FIX 4.0 through 5.0SP2, Rule Builder and REST API automation, month-to-month with no annual contract.

## Pricing

Source: https://www.fixsim.com/pricing

FIXSIM costs $500 per month for Starter, $1,500 and up per month for Pro, and Enterprise pricing is custom. Used by individual developers, QA teams, OMS/EMS vendors, broker-dealers, and exchanges. Month-to-month subscriptions. No annual contract. Cancel anytime.

All plans include: 7-day free trial, no credit card required, no install (browser-based), email support, cancel anytime.

### Starter - $500/month

For individual developers and contractors validating FIX connectivity.

- Single user login
- Single FIX session
- FIX 4.0 – 5.0SP2 support
- Message blotter - raw FIX + translated tags
- Manual order execution - fills, cancels, rejects, replaces
- Session layer testing - sequencing, resends, recovery
- Application layer testing - business logic and exception paths

### Pro - $1,500+/month

For QA teams and OMS/EMS vendors running repeatable regression testing.

- Everything in Starter
- Multiple user logins
- Multiple FIX sessions
- Rule Builder - automate fills, cancels, rejects, replaces
- Replay FIX message logs
- Repeatable regression test scenarios
- High volume message testing
- REST API access for CI/CD integration

### Enterprise - Custom pricing

For broker-dealers, exchanges, and large fintech teams requiring full simulation at scale. Contact FIXSIM for a quote.

- Everything in Pro
- Multiple FIXSIM instances - acceptors and initiators
- Buy-side and sell-side simulation
- Simulate exchange and counterparty behavior
- Venue certification testing workflows
- Dedicated FIXSIM environment
- Single sign-on (SSO) - Microsoft Entra ID, Okta, or any OpenID Connect provider
- Priority support and onboarding
- Custom SLA available

### Pricing FAQ

- **How much does FIXSIM cost?** Starter is $500 per month. Pro starts at $1,500 per month depending on users and sessions. Enterprise pricing is custom. All plans are month-to-month and start with a 7-day free trial.
- **What does the free trial include?** Full access to Starter plan features for 7 days. No credit card required. Connect your FIX engine and start testing in minutes.
- **Do I need to install anything?** No. FIXSIM is fully browser-based. Create a session, connect your FIX engine, and start testing immediately.
- **Does FIXSIM support single sign-on (SSO)?** Yes, on the Enterprise plan. FIXSIM supports OpenID Connect single sign-on with Microsoft Entra ID, Okta, and other OIDC identity providers. Users from your approved email domains are provisioned automatically on first sign-in, and your firm can require SSO for every login. Setup guide: https://www.fixsim.com/userguide/sso
- **Can I upgrade or cancel anytime?** Yes. All plans are month-to-month with no annual contract. Upgrade, downgrade, or cancel at any time.

## About FIXSIM

Source: https://www.fixsim.com/about

### How FIXSIM Started

FIXSIM was built by **Gregg Drumma**, founder of **Gamma Three Trading, LLC**, based in Boston, Massachusetts. While building an Order Management System, the team needed a reliable way to test FIX protocol workflows without relying on live counterparties or expensive on-premise software, and chose to build their own solution. Once internal teams saw its value for development, QA, and support workflows, FIXSIM launched as a cloud-hosted platform in 2012. In production since 2012, FIXSIM processes over 2 million FIX messages daily and is trusted by broker-dealers, buy-side firms, OMS/EMS vendors, exchanges, and fintech teams worldwide.

### Philosophy

- **Accessibility**: FIXSIM is entirely browser-based: no downloads, no VPN, no infrastructure setup required. Connect from anywhere using TLS-encrypted sessions. FIXSIM can act as a FIX initiator, acceptor, or both simultaneously, giving teams the flexibility to simulate any counterparty configuration.
- **Flexible Pricing**: Plans for independent software contractors through large global fintech vendors. Month-to-month subscriptions with no annual contracts. Serves software vendors, investment managers, broker-dealers, and individual developers.
- **Manual and Automated Workflows**: Log into the FIXSIM portal to view real-time FIX message flows, inspect orders and executions in the trade blotter, and manually trigger order actions. The Rule Builder creates deterministic test scenarios that run without manual intervention. The FIXSIM REST API gives applications direct programmatic control over sessions, message injection, and scenario execution, enabling zero-touch regression testing in automated pipelines.
- **FIX Trading Community Member**: Gamma Three Trading is a member of the FIX Trading Community, the non-profit standards body responsible for the FIX protocol specification. Membership ensures FIXSIM stays current with evolving FIX standards across all supported versions: FIX 4.0 through FIX 5.0SP2.

### Vital Stats

- In production since: 2012
- FIX messages processed daily: 2M+
- FIX sessions tested daily: 1,000+
- Billing: month-to-month, no annual contracts
- Customers: trading firms, broker-dealers, and fintech teams on six continents

## User Guide

Source: https://www.fixsim.com/userguide

FIXSIM is a browser-based FIX Protocol testing and simulation platform used by QA engineers, developers, and integration teams at broker-dealers, OMS/EMS vendors, buy-side firms, and fintech companies worldwide. Whether you are developing a new Order Management System (OMS) or Execution Management System (EMS), integrating with a broker-dealer, or certifying an exchange API, FIXSIM provides a high-performance FIX testing environment accessible entirely from your browser, with no local installations required. The guide covers: Getting Started, FIX Sessions, Configuring Sessions, Session Views, Reports (Overview, App Settings, FIX Session Settings, Custom Tags, Blotter In, Blotter Out, Log Replay), Rules & Automation, Securities, Algo Tickets (FIXatdl), REST API, DK Trades, Managing Users & Roles, Troubleshooting, and Reference.

### Getting Started

Source: https://www.fixsim.com/userguide/gettingstarted

Prerequisites:

- Active FIXSIM subscription or trial.
- Network access to the FIXSIM host and port. FIXSIM supports TLS 1.2 encryption for FIX sessions.
- Ability to configure a FIX session on your FIX-enabled application (e.g. OMS).

Step 1 - Create a session in FIXSIM: sign in to the portal (https://portal.fixsim.com/), navigate to **Sessions**, click **New Session**, and configure it. The key choice is FIXSIM's role: as **Acceptor**, FIXSIM listens: the IP/port are assigned by FIXSIM (read-only) and you point your FIX initiator at them; as **Initiator**, FIXSIM connects out: you provide the target IP/port of your FIX acceptor.

Step 2 - Configure your FIX application with the session settings from FIXSIM, with the CompIDs **in reverse**: FIXSIM's SenderCompID is your TargetCompID and vice versa (same for optional Sender/TargetSubIDs).

Step 3 - Start your FIX session from your application (or wait for FIXSIM to connect, if FIXSIM is the initiator). The engines exchange Logons (35=A).

Step 4 - Verify: the session's status indicator in the portal sidebar turns green when logged on, and messages (heartbeats at minimum) flow on the session's Overview report.

### Configuring a New FIX Session

Source: https://www.fixsim.com/userguide/sessions

Each FIXSIM session represents a single FIX connection between your system and FIXSIM. Define the parameters of the session, including the FIX version, CompIDs, session times and more.

| Setting | Details | Notes |
|---|---|---|
| Session Name | Name for this FIX session | |
| FIXVersion | Selected FIX version (4.0 – 5.0SP2) | Custom FIX versions supported via custom data dictionary |
| AppDataDictionary | Version of Application Dictionary | For FIX 5.0 and higher (FIXT.1) |
| IPAddress | IPv4 address | Read-only when FIXSIM is Acceptor; editable target address when FIXSIM is Initiator |
| Port | Port used for this session | Read-only when FIXSIM is Acceptor; editable target port when FIXSIM is Initiator |
| SenderCompID | FIXSIM's SenderCompID (49) for this session | This is the SenderCompID (49) sent by FIXSIM |
| SenderSubID | FIXSIM's SenderSubID (50) | Optional; if set, the other side must populate TargetSubID with this value |
| TargetCompID | FIXSIM's TargetCompID (56) | Required value for the TargetCompID sent by FIXSIM |
| TargetSubID | FIXSIM's TargetSubID (57) | Optional; if set, the other side must populate SenderSubID with this value |
| Timezone | Timezone of session start and end times | |
| Start Time | Session start time (in specified timezone) | |
| End Time | Session end time (in specified timezone) | |
| FIXUser | FIX tag Username (553) | Optional in FIX 4.4 or higher |
| FIXPwd | FIX tag Password (554) | Optional in FIX 4.4 or higher |

Configure your OMS/FIX application to connect to the FIXSIM server address and port. If FIXSIM is acting as an Initiator, enter the IP address and port for FIXSIM to connect to. Note: the CompIDs listed in this form are from the perspective of FIXSIM; your application's Sender/TargetCompIDs are reversed from what is presented in FIXSIM.

### Modifying FIX Sessions

Source: https://www.fixsim.com/userguide/modifysession

Once a FIX session has been created, the session properties can be modified: sequence numbers and FIX session settings. Additional settings available when modifying (beyond those listed above):

| Setting | Details | Notes |
|---|---|---|
| Session Name | Name for this FIX session | Read-only after creation |
| CustomDataDictionary | Name of custom XML data dictionary to use for this session | A custom FIX XML data dictionary (QuickFIX format) can be uploaded to define the FIX messages/tags |
| RequireClientCertificate | Require incoming connections to provide a TLS client certificate | Applies only to FIXSIM Acceptors with TLS encryption enabled |
| ValidateCertificates | Validate certificates are signed by a certificate authority | Applies only to FIXSIM Acceptors with TLS encryption enabled |
| Set week long session | Make this session span multiple days without resetting | Enables StartDayOfWeek and EndDayOfWeek settings |

Sequence numbers can also be reset/updated after creation to resequence with the counterparty or trigger resend requests.

### Sending & Receiving Messages

Source: https://www.fixsim.com/userguide/messages

After your session is logged on, you can send standard FIX flows and inspect FIXSIM responses. Example FIX 4.4 New Order Single:

```
8=FIX.4.4|35=D|55=AAPL|54=1|38=100|40=2|60=20250214-12:00:00|
```

Typical FIXSIM Execution Reports:

```
35=8 ExecType=0 OrdStatus=0  (Ack)
35=8 ExecType=F OrdStatus=2  (Fill)
```

Using the FIXSIM portal you can view inbound and outbound message logs per session, filter by message type, symbol, or time window, and inspect full tag/value details for any message.

### Session Views / Session Reports

Source: https://www.fixsim.com/userguide/sessionviews

Each FIXSIM session has views and settings that apply only to itself. Under each session in the sidebar menu, select the report to view:

- **Overview** - Live FIX message traffic
- **App Settings** - Default application behavior for this session
- **FIX Session Settings** - Modify FIX session settings for this session
- **Custom Tags** - Define standard/custom tags to override per message type
- **Blotter In** - Orders received IN to FIXSIM, sent from your application
- **Blotter Out** - Orders sent OUT from FIXSIM to your application
- **Log Replay** - Replay FIX message logs and download logs (available in some pricing tiers)

### Session Overview Report

Source: https://www.fixsim.com/userguide/reportoverview

The Overview report shows a real-time view of the FIX message traffic between FIXSIM and the connected FIX application. See live traffic and drill into messages sent/received to see FIX messages and tag descriptions.

Filter tabs: **All Messages** (all sent/received), **Incoming** (only incoming application messages), **Outgoing** (only outgoing application messages).

Send Message actions available from the Overview report:

- **Heartbeat** - Manually send a Heartbeat (35=0) to the other side
- **Test Request** - Manually send a Test Request (35=1); a heartbeat is expected in return
- **Resend Request** - Manually send a ResendRequest (35=2); a dialog allows definition of the message range
- **Send Order** - Shortcut to the New Order Single (35=D) form
- **Send Drop Copy** - Shortcut to send a "drop copy" Execution Report (35=8) form
- **Send IOI** - Shortcut to send an Indication of Interest (35=6) form
- **Send Market Data Request** - Shortcut to send a Market Data Request (35=V) form
- **Send Quote Req** - Shortcut to send a Quote Request (35=R) form

**Raw Message**: paste a raw FIX message to be sent through FIXSIM. FIXSIM updates the fields that are necessary, including SenderCompID, TargetCompID, MsgSeqNum, BodyLength, Checksum, and more.

### App Settings Report

Source: https://www.fixsim.com/userguide/reportappsettings

The App Settings report configures default behavior for the FIX session, such as auto-acknowledging orders and auto execution of orders.

| Setting | Description |
|---|---|
| Auto Response | **AutoAck** - send an ExecutionReport with OrdStatus New (0) on receipt of an order. **AutoExec** - execute the order on receipt, following the ExecMode set below. **Auto Quote Response** - send a Quote message (S) back when a QuoteRequest (R) is received. |
| ExecMode | **Full** - send a single fill for the ordered quantity. **Multiple** - execute half the order until filled (100 shares would be ~8 fills: 50, 25, 12, 6, 3, 2, 1, 1). **Single Share** - high volume only; send 100 shares, get back 100 fills of 1 share. **Partial** - execute only half the remaining quantity. **Custom** - configure execution behavior based on number of execution reports or min/max quantity per fill; first choose whether to fully or partially fill the order, then style: Number of Fills (min/max number of execution reports, e.g. between 2 and 10) or Qty on Executions (min/max executed quantity per fill, e.g. between 100 and 500 shares). |
| Close After Partial Fill | When an order is partially filled, send OrdStatus set to Done For Day (39=3) to close the order for the day. |
| Replace IDs for Raw Msgs (ClOrdIDs, OrigClOrdIDs, etc.) | When enabled, raw messages sent through FIXSIM have their identifier replaced by FIXSIM to ensure uniqueness. The ID/tag is determined by the message type, e.g. D = ClOrdID (11), 8 = ExecID (17). |
| Raw Messages: Ignore Custom Defined Tags | If custom tag values are defined under the Custom Tags report, by default those tags are added/modified in raw messages that are sent. Enable this setting to suppress that behavior and send only tags included in the raw message. |
| Enforce Limit Orders Current Mkt Price | FIXSIM will attempt to find a current price for an equity security if possible. If a price is discovered and a Limit order is submitted with this setting enabled, the trade will not execute unless the price is in the range of the limit. For example, Buy 100 IBM at 112.30 with a current market price of 115.64 will NOT execute until the price meets 112.30. |
| Raw Messages: Repeat X Times | When sending a log file of raw messages, this repeats the sending of the message list X times. E.g. a log file with 10 messages and a value of 10 sends 100 messages total. |
| Raw Messages: Delay between Msgs (Millisecs) | Pause between sending each message in the log file. E.g. 1500 = 1.5 seconds between each message. |
| SendPendingCancelReplace | Immediately acknowledge either a Cancel Request (F) or Cancel/Replace (G) with an Execution Report with order status E, Pending Cancel/Replace. |
| Cancel Mode | **MANUAL** - action on a Cancel Request must be taken by the user in the GUI. **AUTO_ACCEPT** - immediately accept the Cancel Request when received. **AUTO_REJECT** - immediately reject the Cancel Request when received. |
| Correct Mode | **MANUAL** - action on a Cancel/Correct Request must be taken by the user in the GUI. **AUTO_ACCEPT** - immediately accept the Cancel/Correct Request when received. **AUTO_REJECT** - immediately reject the Cancel/Correct Request when received. |
| Exec Brokers | In some cases the execution broker/dealer is only known upon receipt of an execution report where the broker code is provided on a tag. For FIX 4.2 and earlier this is often FIX tag 76 (ExecBroker); in 4.3 and above, the NoParties repeating group and tag 448 (PartyID) is used. Providing a list of broker codes here populates 76/448 with a randomly chosen value from the list for each execution. |
| EnableSweepBlotter | Enable the deletion of old orders on the blotters at the Daily Sweep Blotter time. |
| SweepBlotterDailyTimeUTC | Time in UTC of when to execute a "sweep" of the blotters. Orders and executions older than the Sweep Blotter Time Span are cleared from the blotter. |
| SweepBlotterTimeSpan | The time span for which orders/executions older than this are swept at sweep time. Format: Days.Hours:Minutes:Seconds. E.g. older than 1 day = **1.00:00:00**; older than a week = **7.00:00:00**. |
| SweepBlotterCancelOpenOrders | Have FIXSIM send a cancel for each open order before sweeping the old orders/executions. |

### FIX Session Settings Report

Source: https://www.fixsim.com/userguide/reportfixsessionsettings

The FIX Session Settings report provides the ability to update:

- **Sequence Numbers**: Modify the current sending (SendingSeq) / received (RcvdSeq) sequence numbers for this session, to resequence with the counterparty or trigger resend requests.
- **FIX session settings**: Change properties of the FIX session, like Sender/Target CompIDs.

| Setting | Description |
|---|---|
| SessionName | Name of session (read-only). |
| FIXVersion | Dropdown to select the FIX version for this session. |
| CustomDataDictionary | Upload a custom FIX data dictionary XML file (QuickFIX format) to specify modified tags/requirements. |
| AppDataDictionary | When using FIX 5.0 (FIXT.1), specify which version of FIX will be used. Applies only to FIX 5.0 or higher. |
| IPAddress | The IP address of the FIX session. If FIXSIM is an acceptor, this is read-only and tells you where to connect your initiator. If FIXSIM is an initiator, this is editable to set the target IP address. |
| Port | If FIXSIM is an acceptor, this is the assigned port (not editable). If FIXSIM is an initiator, this is editable to set the target port. |
| RequireClientCertificate | If FIXSIM is a FIX acceptor with TLS enabled, require the client to send a certificate in the TLS handshake. |
| ValidateCertificates | If FIXSIM receives a TLS client certificate and this is enabled, FIXSIM validates the certificate is signed by a trusted authority using its approved CA store. |
| SenderCompID | FIXSIM session's SenderCompID. |
| SenderSubID | Optional SenderSubID on messages. For a successful logon, the other side must be configured with a matching TargetSubID. |
| TargetCompID | FIXSIM session's TargetCompID. |
| TargetSubID | Optional TargetSubID on messages sent. For a successful logon, the other side must be configured with a matching SenderSubID. |
| Timezone | Timezone used for configuring the start and end times for this session. |
| Start Time | Time of day that the session will start. |
| End Time | Time of day the session will end/logout. |
| Set week long session | Enable/disable a weeklong session. If enabled: StartDayOfWeek (starting day of week) and EndDayOfWeek (ending day of week). |
| Send Redundant Resend Requests | If set to Y, QuickFIX will send all necessary resend requests, even if they appear redundant. Some systems will not certify the engine unless it does this. When set to N, QuickFIX will attempt to minimize resend requests, particularly useful on high volume systems. |
| FIXUser | Optional tag to provide a username on logons. |
| FIXPwd | Optional tag to provide a password on logons. |

### Custom Tags Report

Source: https://www.fixsim.com/userguide/reportcustomtags

FIXSIM provides the ability to define and use custom FIX tags in your FIX sessions, useful for testing scenarios that require non-standard tags or for simulating specific behaviors. This report enables configuration of both custom and standard FIX tags to be automatically added to specific message types when they are generated and sent. Tag values can be either hardcoded to a single value or randomly selected from a predefined list.

Example: for a New Order Single (MsgType = D) message:

- **Tag 58 (Text)** configured with a single hardcoded value of "This is a note".
- **Tag 9000** configured to send the value "custom1" with every New Order Single (D) message generated.

### Blotter In Report

Source: https://www.fixsim.com/userguide/reportblotterin

The Blotter In report provides a traditional Order Management System (OMS) view of incoming orders: the New Order Singles (MsgType D) received by the FIXSIM session. The table shows the orders, order state, number of execution reports, total quantity executed, average price and more.

### Blotter Out Report

Source: https://www.fixsim.com/userguide/reportblotterout

The Blotter Out report provides a traditional OMS view of outgoing orders: the New Order Singles (MsgType D) sent from the FIXSIM session. The table shows the orders, order state, number of execution reports received, total quantity executed, average price and more.

### Log Replay Report

Source: https://www.fixsim.com/userguide/reportlogreplay

The Log Replay report provides a way to upload log files to replay in FIXSIM, view statistics on replay performance, and download session logs.

- **Upload File**: Upload a text file with valid FIX messages. Messages can use the standard FIX SOH (0x01) delimiter or the pipe (|) delimiter.
- **Download Logs**: Download session logs (if available) by specifying a start time and end time. A text file is returned with FIX messages both sent and received by the session between the specified times.
- **Replay Stats**: Statistics of the most recent replay: total number of messages sent, start time and end time in UTC, messages per second, and more.
- **Replay Message Details**: A preview of the messages contained within the log file to be sent.

### Rules & Automation

Source: https://www.fixsim.com/userguide/automation

The Rule Builder defines how FIXSIM automatically responds to incoming messages, ideal for repeatable regression scenarios, certification rehearsals, and stress testing. Rules are managed under Setup → Rules in the portal. A rule has two parts:

**Trigger** - which messages the rule matches: a target session, a target message type (tag 35, e.g. D for New Order Single), and up to two tag conditions (target tag, condition such as Equal To or Not Present, and value) combined with And/Or logic. Example: trigger on every New Order Single where tag 55 (Symbol) equals IBM.

**Actions** - what FIXSIM does in response. Each action has: an Order Action (e.g. PartialExecute, the same fills/cancels/rejects available manually in the blotters), an Exec Mode (Session Default follows the session's App Settings ExecMode, or override per action), a Pause Time in milliseconds to simulate counterparty latency, optional raw FIX message(s) to send as the response, and additional tags to stamp onto generated messages. A rule can have multiple actions, so one trigger can produce a realistic multi-message response.

The rule detail page visualizes the message pipeline: INCOMING (MsgType) → SESSION → WHEN (conditions) → EXECUTE (actions). Combine multiple rules to simulate venue behavior, risk checks, partial fills, and latency scenarios.

### Securities

Source: https://www.fixsim.com/userguide/securities

The Securities page (Setup -> Securities, ClientAdmin/PowerUser) is the instance's security master: symbols, identifiers, and the prices the simulator uses. Defining securities is optional; unknown symbols get a live price lookup for real listed tickers or a default of 25.00. A defined security makes pricing deterministic: execution pricing resolves in order (price cache, the security's Last Trade, live lookup, default), Market Data Request responses use the security's Bid and Offer where defined, and the App Settings option Enforce Limit Orders Current Mkt Price gates limit fills against the same simulated price. Currency-pair symbols (containing a slash) are priced from live FX rates instead. Price edits take effect on the next execution for the symbol.

Creating a security requires only Symbol (stored uppercase, unique per instance). Field groups: pricing (Bid, Offer, Last Trade, Round Lot); identifiers (CUSIP, SEDOL, ISIN, RIC, Bloomberg, Valoren, Symbol Suffix); classification (Asset Type, Product, CFI Code, Security Type/SubType, Security Exchange, Issuer, Country, Currency); fixed income (maturity, coupon, issue/dated dates, Factor, interest accrual); derivatives (Put/Call, Strike, Contract Multiplier); plus eight numeric and eight text user-defined fields and a Note. The REST API's Securities endpoint group lists, adds, and updates securities, so CI suites can seed the security master and assert exact fill prices.

### Algo Tickets (FIXatdl)

Source: https://www.fixsim.com/userguide/algotickets

Algo Tickets (an Enterprise plan feature, under Setup → Algo Tickets) lets firms test algo order flow against the FIXatdl files their brokers publish. Upload a broker's FIXatdl 1.0/1.1 file (.xml or .atdl) and FIXSIM parses it tolerantly (anything the simulator cannot act on is flagged in a parse report rather than rejected) and renders each strategy as a live algo ticket with the broker's own panel layout, StateRules, and validations running in the browser.

**Preview** shows the rendered ticket plus a live FIX Wire Preview of exactly which tags the ticket will emit. **Sending**: from a session's Blotter Out, the Algo Order button opens a file/strategy picker and then the order ticket, with the standard NewOrderSingle fields (ClOrdId, Symbol, Side, OrderQty, OrdType, Price, TIF, HandlInst) plus the strategy's FIXatdl parameters. The sent 35=D carries the strategy identifier tag (847 TargetStrategy by default, or the tag the broker's file declares), every parameter with a fixTag as a flat tag=value (including 7000/9000-range custom tags), and untagged parameters in the StrategyParameters repeating group (957/958/959/960, FIX 4.3+). Wire conversions follow FIXatdl rules (enum wire values, percentage scaling, timestamp formats); hidden/disabled controls contribute nothing. Sent orders appear in Blotter Out and the message log like any other order.

### REST API

Source: https://www.fixsim.com/userguide/restapi

Everything you can do in the FIXSIM portal can also be driven programmatically through the REST API: create and configure sessions, send and act on orders, inject raw FIX messages, and query executions. API access is included in the Pro and Enterprise plans, and is available during the free trial.

**Authentication and base URL**: All endpoints are served from `https://portal.fixsim.com/v1/` and authenticated with an API key passed in the `apiKey` HTTP header. The API key is available in the FIXSIM portal.

**Core concepts**: An *instance* is a FIXSIM simulator environment in your account (`GET /v1/Instances` lists them); a *session* is a FIX session within an instance, identified by its session name. In/Out direction is always from FIXSIM's perspective: OrdersIn are orders sent into FIXSIM by your application, OrdersOut are orders FIXSIM sent out; ExecutionsIn are execution reports sent into FIXSIM, ExecutionsOut are execution reports FIXSIM sent out; the same convention as the portal's Blotter In / Blotter Out.

**Endpoint groups**:

| Group | What it does |
|---|---|
| Instances | List the FIXSIM instances in your account. |
| Sessions | List, create, configure, and remove FIX sessions; adjust sending/received sequence numbers. |
| SessionSettings | Read and update per-session application settings. |
| OrdersIn | Query orders received by FIXSIM and act on them: acknowledge, fully or partially execute, or cancel the remaining quantity. |
| OrdersOut | Create orders sent from FIXSIM (35=D) and issue cancels (35=F) and cancel/replaces (35=G). |
| ExecutionsIn / ExecutionsOut | Query execution reports by session, order, or execution ID; bust or correct executions sent from FIXSIM. ExecutionsOut responses include a `dontKnow` object on executions the counterparty rejected with a DontKnowTrade (35=Q). |
| RawMessages | Inject raw FIX message strings into a session (`POST /v1/RawMessages/{instance}/{session}` with a `fixMessages` array; pipe-delimited messages accepted, and FIXSIM regenerates SenderCompID, TargetCompID, MsgSeqNum, SendingTime, BodyLength, and CheckSum). |
| Securities | List, add, and update the simulated securities (symbol, last price, CUSIP, ISIN) used for pricing. |

Example: fully execute a received order via the API instead of the GUI:

```
curl -X POST "https://portal.fixsim.com/v1/OrdersInAction/{instance}/{session}" \
  -H "Content-Type: application/json" \
  -H "apiKey: YOUR_API_KEY" \
  -d '{"action": "FullyExecute", "clOrdIds": ["ORD-001"]}'
```

Then verify with `GET /v1/ExecutionsOut/{instance}/{session}/ORD-001`. The complete endpoint list with request/response schemas is in the interactive Swagger reference at https://portal.fixsim.com/swagger/index.html.

### DK Trades (Don't Know Trade)

Source: https://www.fixsim.com/userguide/dktrades

A Don't Know Trade (DK, 35=Q) is how a FIX counterparty rejects an execution it doesn't recognize. FIXSIM tests DK handling in both directions. **Simulating a counterparty that DKs your executions**: a Rule Builder rule triggering on Execution Report (MsgType 8) with the Reject action makes FIXSIM respond to matching executions with a DontKnowTrade. **Capturing DKs your system sends**: when your application DKs a fill FIXSIM sent, FIXSIM correlates the inbound 35=Q by ExecID (tag 17) on the same session and attaches the DKReason (tag 127), Text (tag 58), arrival time, and raw FIX message to that execution. Captured DKs are exposed via the REST API: ExecutionsOut responses carry a `dontKnow` object (reason, receivedTime, text, fixMessage) on DK'd executions and omit the field otherwise, making DK scenarios assertable in CI/CD. DKReason codes: A unknown symbol, B wrong side, C quantity exceeds order, D no matching order, E price exceeds limit, F calculation difference, Z other. A DK referencing an unknown ExecID is logged and ignored.

### Managing Users & Roles

Source: https://www.fixsim.com/userguide/users

FIXSIM accounts are multi-user, managed under Setup → Users by users with the ClientAdmin role. Admins invite teammates by email; the invitee sets a password via the emailed link and signs in. Each user has one role: **ClientAdmin** (everything in the group including user management and the subscription), **PowerUser** (configure sessions, rules, securities, and API; the default for new invitees), or **User** (run tests: send orders, work the blotters, and control simulation behavior, but no session/rule/security/API configuration). The portal sidebar adapts to role: a User sees the Dashboard and per-session reports only. In multi-instance firms, admins can restrict each user to specific FIXSIM instances (selecting all instances grants full group access including future instances); bulk edit applies a role and/or instance set to many users at once. Seat usage is shown as "Users: n of m" per the plan's user limit. Removing a user permanently deletes the login; the firm's sessions, rules, and messages are unaffected.

### Single Sign-On (SSO)

Source: https://www.fixsim.com/userguide/sso

FIXSIM Enterprise lets a firm's users sign in to portal.fixsim.com with the company identity provider over OpenID Connect (OIDC). Works with Microsoft Entra ID, Okta, and any provider that publishes an OpenID Connect discovery document. SSO is part of the Enterprise plan.

#### What You Get

- Users click "Sign in with single sign-on (SSO)" at portal.fixsim.com, enter their work email, and are sent to the identity provider and back.
- Just-in-time provisioning: a first-time SSO user from an approved email domain gets a FIXSIM account automatically with the default role the firm chooses. No invitation needed.
- Optional enforcement: "Require SSO" refuses password login and password reset for the firm's email domains.
- Disabling a user at the identity provider blocks new FIXSIM sign-ins immediately.
- Not included: SAML, SCIM provisioning and deprovisioning, group-to-role mapping. Roles are managed on the FIXSIM Users page.

#### Values Exchanged

FIXSIM needs from the firm: Authority (issuer URL; Entra ID `https://login.microsoftonline.com/<tenant-id>/v2.0`, Okta `https://<your-domain>.okta.com` or a custom authorization server URL), Client ID, Client secret (stored encrypted), and the Allowed email domains.

The identity provider needs from FIXSIM: the per-firm Redirect URI `https://portal.fixsim.com/signin-oidc/<your-firm-id>` (shown on the portal's Setup > Single Sign-On page), application type Web, authorization code flow with PKCE and a client secret (response mode form_post), scopes `openid profile email`. FIXSIM reads the claims email (or preferred_username / upn), name, given_name, family_name, and sub. Sign-out is not federated.

#### Microsoft Entra ID

Register a single-tenant Web app named FIXSIM with the FIXSIM Redirect URI; copy the Application (client) ID and Directory (tenant) ID; create a client secret (24 months maximum, note the expiry date and enter it in FIXSIM); leave implicit and hybrid flows off and public client flows set to No; add the optional ID token claims email, given_name, family_name, and upn (omit upn for #EXT# external identities and set their Email property instead); confirm openid, profile, email, and User.Read Graph permissions; optionally set Assignment required on the Enterprise application. Authority = `https://login.microsoftonline.com/<tenant-id>/v2.0` (not common or organizations; FIXSIM validates the issuer against the tenant).

#### Okta

Create an OIDC Web Application integration named FIXSIM, grant type Authorization Code only, sign-in redirect URI = the FIXSIM Redirect URI, assign the users or groups, copy Client ID and Client secret, confirm client secret authentication with PKCE allowed. Authority = `https://<your-domain>.okta.com` or `https://<your-domain>.okta.com/oauth2/<server-id>` for a custom authorization server.

#### Finishing the Setup in FIXSIM

A ClientAdmin opens Setup > Single Sign-On, enters Authority, Client ID, Client secret, and Allowed email domains, chooses the role for new users (PowerUser is the suggested default), runs Test connection (fetches the discovery document), ticks Enabled and saves. FIXSIM verifies the firm owns the listed domains, normally within one business day; SSO sign-in starts after approval and any change to the domain list needs a fresh verification. After the admin's own SSO sign-in works, Require SSO can be ticked.

#### Rolling SSO Out to an Existing Team

Nothing is migrated. Week 0: enable SSO for the firm (Enterprise plan), choose administrators, and make sure the email addresses on the Users page match what the provider will send (a mismatch creates a second account and takes a seat). Week 1: connect with Require SSO off; each user is linked to their existing account on first SSO sign-in and keeps their role; passwords keep working. Week 2 or later: confirm active users have signed in through SSO, then tick Require SSO. Afterwards new joiners get an account automatically, leavers are blocked at the provider but keep their FIXSIM seat until removed on the Users page, and the client secret expiry date should be recorded on the Single Sign-On page.

#### How Accounts Are Matched

Returning users are matched by the provider's sub claim. Existing users in the firm are linked on first SSO sign-in and keep their role. A free-trial account with an email in the firm's domains is moved into the firm. An account belonging to a different FIXSIM customer is never touched (sign-in refused). The returned email must be in the Allowed email domains. SSO users count toward the firm's user limit like invited users.

#### When the Client Secret Expires (Entra ID)

FIXSIM emails the firm's administrators 30, 7, and 0 days before the recorded expiry date. If the secret lapses, SSO sign-ins fail with "your organization's single sign-on secret was rejected", FIXSIM emails the ClientAdmins and FIXSIM support, and ClientAdmins may sign in with a password for 72 hours (even under Require SSO) to paste in the new secret. Okta and most other providers do not expire client secrets.

#### Troubleshooting

- "Single sign-on is not set up for your domain": domain not in Allowed email domains, domains awaiting FIXSIM verification, SSO not Enabled, or plan does not include SSO.
- Provider error about the redirect URI: the app registration's Redirect URI does not exactly match the value on the FIXSIM Single Sign-On page.
- "The sign-in response could not be validated": Authority does not match the tenant that issued the token.
- "Your organization's single sign-on secret was rejected": wrong or expired client secret.
- "Your identity provider did not return an email address": add the email optional claim (Entra ID) or check the email scope.
- "User limit has been reached": add seats or remove unused users; FIXSIM is notified automatically.

#### Security Notes

The client secret is encrypted at rest and never shown again after saving. Each firm has its own redirect URI and FIXSIM only accepts sign-in responses for the firm the login started with. FIXSIM validates the ID token signature, issuer, audience, expiry, nonce, and state on every sign-in.

### Monitoring & Troubleshooting

Source: https://www.fixsim.com/userguide/troubleshooting

Use the FIXSIM dashboard and logs to diagnose connectivity and message-flow issues. Common issues:

- **Logon rejected** - verify SenderCompID, TargetCompID, and credentials.
- **Sequence mismatch** - engine restarted with lower sequence numbers.
- **No connectivity** - firewall or routing issues to FIXSIM endpoints.

To reset sequence numbers, apply `ResetSeqNumFlag=Y` when you intentionally restart your engine and want to realign sequence numbers with FIXSIM.

### Reference

Source: https://www.fixsim.com/userguide/reference

Additional resources for working with FIX and FIXSIM:

- FIX Protocol Tutorial: https://www.fixsim.com/fix-protocol-tutorial
- Sample FIX Messages: https://www.fixsim.com/sample-fix-messages
- FIX Parser: https://www.fixsim.com/fix-parser
- FAQ: https://www.fixsim.com/faq