Configuring FIX Connections
This page covers the FIX-specific settings you'll encounter when creating an adapter that connects to a FIX venue or counterparty.
For the general adapter creation workflow, see Creating an Adapter.
Connection Types
| Connection Type | Use this when... |
|---|---|
| FIX Initiator | Your system connects outbound to a venue |
| FIX Acceptor | A venue or counterparty connects inbound to you |
FIX Initiator Settings
When you select FIX Initiator as the connection type, the form asks for these settings:
| 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 (provided by the venue) |
| TargetCompID | VENUE_X | The venue's FIX identifier |
| FIX Version | FIX.4.4 | The version of the FIX protocol (provided by the venue) |
| Heartbeat | 30 | How often (in seconds) to send a keepalive; 30 is standard |
Your counterparty or venue's connectivity guide will have all of these values.
FIX Acceptor Settings
When you select FIX Acceptor, Conncentric listens for an inbound FIX connection from a counterparty.
| Field | Description |
|---|---|
| Port | The port to listen on (your IT team will need to open this in the firewall) |
| SenderCompID | Your firm's FIX identifier for this session |
| TargetCompID | The counterparty's FIX identifier |
| FIX Version | The version the counterparty will connect with |
Give the counterparty your address, port, SenderCompID, and TargetCompID so they can configure their side.
Encrypted Connections
If the venue requires encrypted connections, your infrastructure team configures TLS termination at the load balancer or network layer before the adapter is created. Coordinate with your infrastructure team to confirm this is in place before enabling the adapter.
Custom Data Dictionaries
If the venue uses non-standard FIX fields, upload a custom data dictionary (XML file) to Artifacts and select it in the connector settings. This allows the platform to parse and validate venue-specific message types.
Advanced Settings
These settings are found under the Advanced section of the FIX connector configuration.
Reset On Logon
Controls whether the platform resets sequence numbers each time the FIX session connects.
| Setting | Behavior | When to use |
|---|---|---|
| N (recommended) | Sequence numbers are preserved across reconnects. If the session drops, both sides pick up where they left off and replay any missed messages automatically. | Production environments where message continuity matters. |
| Y | Sequence numbers reset to 1 on every logon. Any messages from the prior session that were not yet delivered are permanently lost with no warning. | Development and testing only. |
If ResetOnLogon is set to Y and the adapter restarts mid-session (for example, during a pod restart), all messages sent by the counterparty while the adapter was offline will be lost. The platform cannot request a replay because both sides have agreed to start fresh. Set this to N for any production or pre-production environment.
Pipeline Backpressure Limit
Controls what happens when inbound FIX messages arrive faster than the pipeline can process them (for example, a target Kafka cluster is temporarily slow).
| Setting | Behavior |
|---|---|
| 0 (default) | Disabled. Messages queue in memory until the pipeline catches up. Suitable when the pipeline can sustain the expected message rate. |
| Any positive number | When the internal queue reaches this depth, the platform gracefully disconnects the FIX session so the pipeline can drain. Once drained, the session reconnects and the counterparty automatically replays any messages that were sent during the disconnect. |
How to choose a value: Set the limit low enough that the container is never killed due to memory pressure while messages are still queued. Messages that have been received but not yet processed live only in memory. If the container is killed before the queue drains, those messages are lost and cannot be recovered via replay. The backpressure disconnect prevents this by disconnecting the session before memory pressure becomes critical.
As a guideline, estimate how much memory headroom the container has beyond normal operation. If that headroom is 512 MB and each FIX message averages roughly 1 KB, a limit of 200000 provides a safe ceiling with margin.
When this limit is triggered, you will see a warning event in the Portal: Backpressure disconnect triggered.
Troubleshooting FIX Connections
Session not connecting
The adapter is running but the FIX session never reaches a logged-on state.
Common causes:
- Wrong host, port, or session settings (SenderCompID, TargetCompID)
- Network is blocking the outbound connection to the venue
- Network-level encryption misconfiguration (if the venue requires encrypted connections)
What to do:
- Double-check the connector settings in the Portal
- Check the event log for the specific rejection message from the venue
- Contact the venue's connectivity support to verify your session details
Sequence number mismatch
The venue rejects the logon because sequence numbers are out of sync.
See Sequence Numbers for how to diagnose and resolve this.
Next Steps
- Sequence Numbers: understand FIX sequence tracking and how to reset when needed
- Common Use Cases: patterns for FIX-to-Kafka, inbound acceptor, bridging, and market data fan-out