FIX Configuration
This page documents the FIX-specific fields the adapter wizard presents when the selected connection type is FIX. The wizard itself, the save-and-enable flow, and everything else that is not FIX-specific are covered in Creating an Adapter.
Connection types
| Connection Type | Use this when |
|---|---|
| FIX Initiator | Your system connects outbound to a venue or counterparty. |
| FIX Acceptor | A venue or counterparty connects inbound to your system. |
FIX Initiator fields
| Field | Example | Description |
|---|---|---|
| Host | fix.venue.com | The venue's server address. |
| Port | 9876 | The venue's port number. |
| SenderCompID | MY_FIRM | Your FIX identifier. Supplied by the venue. |
| TargetCompID | VENUE_X | The venue's FIX identifier. |
| FIX Version | FIX.4.4 | The FIX protocol version the session will use. |
| Heartbeat | 30 | Keepalive interval in seconds. The standard value is 30. |
The counterparty's connectivity guide is the authoritative source for every value in this table.
Reconnect timing is not a wizard field. The adapter reconnects on a built-in default interval. If a venue requires a different cadence, ask Connamara to expose it as a field.
FIX Acceptor fields
| Field | Description |
|---|---|
| Port | The port the adapter listens on. Your network team must open this port for inbound traffic. |
| SenderCompID | Your firm's FIX identifier for this session. |
| TargetCompID | The counterparty's FIX identifier. |
| FIX Version | The FIX protocol version the counterparty will connect with. |
| Heartbeat | Keepalive interval in seconds. Must match what the counterparty expects. |
Share the listen address, port, SenderCompID, and TargetCompID with the counterparty so they can configure their side.
Encrypted connections
Either your infrastructure terminates TLS ahead of the adapter, or the session terminates it itself. The venue decides which; confirm before enabling the adapter.
To terminate at the session, set Use TLS in the TLS section under Advanced. Certificates are validated against the platform's default trust store. Enabled TLS Protocols and Cipher Suites pin those allowlists when a venue names them, for example TLSv1.2,TLSv1.3; blank accepts the defaults. Send SNI applies to initiators.
A private certificate authority or a client certificate is not configurable here. Ask Connamara before committing to a venue that needs one.
Custom data dictionaries
If the venue uses non-standard FIX fields, upload the venue's data dictionary (XML) to Artifacts and reference it by name in the FIX connector fields. The adapter loads the dictionary at session start and uses it to parse venue-specific message types.
Advanced settings
The FIX connector exposes additional session-protocol fields (sub-identity routing, reset-on-logout, reset-on-disconnect). Set them only if your counterparty's spec requires it; consult the venue's integration guide for the exact values.
Keep ResetOnLogon at N (the default). Setting it Y discards any messages sent during a disconnect window before the next logon. Use it only for development scratch sessions, or pair it explicitly with durabilityMode=NONE (see below) when no message recovery is wanted on reconnect.
The wizard exposes three sequence-reset controls, all defaulting to N: ResetOnLogon (reset on every logon), ResetOnLogout (reset on a normal logout), and ResetOnDisconnect (reset on a network disconnect). To force a fresh sequence space on the next logon, set ResetOnLogon=Y; that is what puts ResetSeqNumFlag (tag 141) on the outgoing Logon. There is no separate control for the tag.
Logon fields
Counterparties that authenticate on logon expect extra fields on the Logon message, usually tag 553 (Username) and 554 (Password), though venues do use other tags. Add as many as the venue's connectivity guide specifies under Logon Fields, as tag and value pairs; they are sent in the order listed.
Enter the values the venue gave you. There is no provisioning step.
If policy forbids credentials in an application's configuration store, enter ${env:VAR_NAME} as the value and mount VAR_NAME into the adapter from a Secret via adapter.extraEnvFromSecrets (Security). The adapter resolves it in memory at connect time, so the store, the exports, and the bundles hold only the reference. It does not hide the value from the session's message log, where the Logon is archived like every other message.
For runtime behavior under sustained load and pod sizing guidance, see FIX Operations and the Scaling and Helm reference pages.
Durability mode
Each FIX session declares how it persists message bytes through the durabilityMode field. The mode chosen at session create time defines whether the platform can reconstruct in-flight messages after a non-graceful pod termination. The mode is re-read from the session's configuration on every start, so it is not locked once set, but changing it after a session has produced traffic is strongly discouraged for the durability reasons described below.
| Mode | Message persistence | Recovery after non-graceful termination | Wire latency cost | When to use |
|---|---|---|---|---|
FULL (default) | Every outbound message is persisted to the platform store before the bytes leave the pod. Inbound messages run single-shot: the message is delivered into the processing pipeline first, and a single durable record is written when it is acknowledged (at or after apply), not before. Inbound zero-loss comes from the counterparty's resend on reconnect, applied-sequence recovery, and downstream idempotency. | The new pod resumes the session with the counterparty's recovery protocol (gap fill from the persisted record), provided the session is configured with ResetOnLogon=N. | Includes one platform-store group-commit window per outbound batch. | Regulated venues, drop-copy and reporting feeds, broker-of-record and order-routing sessions, and any session where loss of a single in-flight message is unacceptable. The right default for almost every production session. |
NONE | Messages are not persisted. Sequence numbers live only in the pod's memory for the duration of the session. | No recovery. The session must be configured with ResetSeqNumFlag=Y (or ResetOnLogon=Y) so each logon negotiates a fresh sequence space; otherwise the next logon after a pod loss will fail with a sequence mismatch and require manual reconciliation. | Removes the platform-store write from the outbound path. | Replayable market-data feeds where the upstream re-emits and no message-byte reconstruction is required. Tactical feeds with a published source-of-truth replay window. Never appropriate for order flow or trade reporting. |
The choice is per session. A single deployment can run FULL sessions and NONE sessions side by side; the platform applies each session's mode independently.
When to pick which
If you are not certain which to pick, use FULL. The cost is a group-commit window of latency per outbound batch, which is well below the protocol's heartbeat interval and the counterparty's clock tolerance. The recovery story for any other mode requires explicit pairing with session reset behavior and a runbook for the reset case; FULL requires neither.
Pick NONE only when both of the following are true:
- The data on the session is fully reconstructible from a source other than the platform (an upstream feed, a market replay service, a separately persisted copy at the venue).
- The session is configured with
ResetSeqNumFlag=Yon its logon, so the post-restart sequence negotiation is automatic. Without this pairing, every non-graceful restart will require a manual sequence reseed using the Portal session controls.
Changing the mode after a session has produced traffic
The platform does not lock the mode: it is re-read from the session's configuration on every start, so an operator can change it. Doing so after the session has produced traffic is strongly discouraged. The recovery path on the next restart cannot cleanly reason about which records were written under which policy, which undermines the durability guarantee the mode is meant to provide. The safe path is to create a new session under the new mode and retire the old one through the normal session-end process with the counterparty.
Recovery interaction
The recovery behavior described in Sequence number recovery applies to FULL sessions. For NONE sessions, the platform does not attempt sequence recovery on restart; the logon-time ResetSeqNumFlag=Y negotiation is the only recovery mechanism, and the Portal's Update Seq action is the only way to align sequences manually if that negotiation fails.
FIX-specific troubleshooting
Session does not reach logon
The adapter is running, but the FIX session never reaches a logged-on state. Common causes:
- Host, port, or session identifiers (
SenderCompID,TargetCompID) are wrong. - The network is blocking outbound traffic to the venue.
- The venue requires encryption and TLS termination is missing at the load balancer.
Verify the connector fields against what the venue provided, read the event log for the rejection reason, and coordinate with the venue's connectivity desk when the event log reports a counterparty-side rejection.
Sequence number mismatch
The venue rejects the logon because sequence numbers are out of sync. See Sequence number recovery in FIX Operations.
Next steps
- FIX Operations for runtime behavior, monitoring, sequence-number recovery, and operational troubleshooting.
- Use Cases for end-to-end integration patterns.