FIX Acceptor

The role of a FIX Acceptor is to:

Listen to FIX session initiating (Buy-side) counterparties at a designated port
Validate and authenticate a Logon message
Accept session by sending counter-Logon
Reject connection if validation fails
Listen to inbound messages
Close connection if counterparty becomes inactive

QXFIX Engine allows building an Acceptor that can:

Handle multiple counterparties
Maintain multiple FIX sessions
Process messages efficiently

Components of Acceptor Application

Component Details	Role
Callback handler (FixAcceptorHandler)	Handles session events and messages
FIX configuration (FixConfig)	Represents XML configuration
Persistence layer (FixDBConfig)	Manages database persistence
Target configurations (AcceptorTargetConfig)	Defines allowed counterparties
Target list (AcceptorTargetConfigList)	Maintains list of counterparties

FAQs

How do I setup FIX Acceptor?
What is FixAcceptorHandler?
How does Acceptor identify counterparties?
Can I add new counterparty dynamically?
Which IP is used if not provided?
Does Start() start sessions?
How to detect new connection/session?
Can I block new connections?
How to track session states?
How to set different rules per counterparty?
How to logout specific counterparty?
Does Acceptor handle order matching?
How are credentials validated?
How to detect session state changes?
How to use SSL?

1. How do I Setup my FIX Acceptor application to accept FIX connections?

View Answer

Steps:

Initialize list of Initiators
Initialize database configuration
Implement FIX Acceptor Handler
Instantiate and initialize Acceptor

Step 1: Initialize Initiators

View Code

FixConfig fixConfig = new FixConfig("Initiator.Config");

AcceptorTargetConfig sampleInitiator =
new AcceptorTargetConfig(
    FixVersion.BEGINSTRING_Fix42,
    "SampleInitiator",
    fixConfig
);

AcceptorTargetConfigList acceptorTargetConfigList =
new AcceptorTargetConfigList();

acceptorTargetConfigList.Add(sampleInitiator);

Step 2: Database configuration

View Code

string dbServer ="(local)";
string dbName = "FFFix";

string dbConnString = string.Format(
    "Data Source={0};Initial Catalog={1};IntegratedSecurity=SSPI;Pooling=true;Min Pool Size=0;Max Pool Size=100;Connect Timeout=30",
    dbServer, dbName
);

FixPersistConfig persistConfig =
new FixDBConfig(
    com.QX.FIXEngine.Core.eDBProvider.SqlServer,
    dbConnString
);

Step 3: Implement handler

View Code

FixAcceptorHandler fixAcceptorHandler =
new ApplicationCallbackHandler();

Step 4: Initialize Acceptor

View Code

acceptor.Init(
    userName,
    "SampleAcceptor",
    acceptorTargetConfigList,
    persistConfig,
    fixAcceptorHandler,
    System.Net.IPAddress.Loopback.ToString(),
    9999
);

2. What is the significance of the FixAcceptorHandler callback interface?

View Answer

The Acceptor maintains multiple FixSession instances on multiple threads.

QXFIX Engine does not include business logic. Instead, it provides callback methods through FixAcceptorHandler.

You can override these methods to implement your own logic such as:

Order processing
Message handling
Session event handling

View Code

using System;
using com.QX.FIXEngine;
using com.QX.FIXEngine.Acceptor;
using com.QX.FIXEngine.Core.Message;

namespace AcceptorApplication
{
    internal sealed class AcceptorCallbackListner :
    com.QX.FIXEngine.Acceptor.FixAcceptorHandler
    {
        public AcceptorCallbackListner(MainForm mainForm)
        {
        }

        public override void OnSessionCreation(FixSession fixSession)
        {
        }

        public override void OnConnectionBreak(FixSession fixSession, string failReason)
        {
        }

        public override void OnLogonMessage(FixSession fixSession, FixMessage message)
        {
            string userName = message.GetFieldAsString(FixFieldTag.Username_553);
            string password = message.GetFieldAsString(FixFieldTag.Password_554);

            if (Validate(userName, password))
            {
                FixMessage fixLogonMessage = fixSession.GetSessionFixMessage("A");
                fixLogonMessage.SetField(FixFieldTag.HeartBtInt_108, "30");
                fixLogonMessage.SetField(FixFieldTag.EncryptMethod_98, "0");

                fixSession.SendMessage(fixLogonMessage);
            }
            else
            {
                FixMessage logoutFixMessage =
                fixSession.GetLogoutMessage("Invalid Password. Logout Forced");

                fixSession.SendMessage(logoutFixMessage);
                return;
            }
        }

        public override void OnLogoutMessage(FixSession fixSession, FixMessage message)
        {
        }

        public override void OnRejectMessage(FixSession fixSession, FixMessage message, int rejectedMessageSeqNum)
        {
        }

        public override void OnApplicationMessage(FixSession fixSession, FixMessage message)
        {
            _mainForm.OnSessionApplicationMessageReceived(fixSession, message);
        }

        public override void InBoundQueueSizeThresholdValueReached(FixSession fixSession)
        {
        }

        public override void OnSessionTransmissionFail(FixSession fixSession, DateTime lastMessageRecvAt)
        {
        }
    }
}

3. How does my FIX Acceptor application identify the counterparties that it can accept?

View Answer

The Acceptor identifies counterparties using AcceptorTargetConfigList.

Each AcceptorTargetConfig represents one allowed counterparty
This list is passed during Init()

During Logon:

Incoming message is validated
Compared with configured counterparties
If match → session accepted

Key Points

Only registered counterparties are allowed
Matching is based on FIX session parameters
Ensures secure connectivity

4. Is it possible to make my Acceptor application accept a connection request from a new counterparty, unknown to it during the Init() call?

View Answer

Yes, you can dynamically add a new counterparty using:

View Code

public void AddNewAcceptorTargetConfig(
    AcceptorTargetConfig acceptorTargetConfig
)

Key Points

Allows dynamic onboarding of counterparties
No need to restart application
Useful for scalable systems

5. If the Init() call on an Acceptor instance does not provide the server-IP address, which IP address does it use?

View Answer

If no IP is provided:

The Acceptor scans available network interfaces
Selects the first available IP
Uses it to listen for connections

Key Points

Default behavior is automatic
Recommended to explicitly define IP in production

6. Does a Start() call of the Acceptor also start all the sessions maintained by the Acceptor?

View Answer

No, sessions are not started automatically.

Process:

Initiator connects via socket
Sends Logon message
Acceptor waits for Logon within configured timeout
If not received → connection closed

Key Points

Sessions are initiated by counterparties
Controlled via Logon message
Timeout controlled by configuration

7. How do I come to know about the acceptance of a new Initiator connection and creation of a new FixSession by the Acceptor?

View Answer

The Acceptor provides events and callbacks:

NewClientSocketConnectEvent → triggered when a socket connection is accepted
NewFixSessionCreatedEvent → triggered after successful Logon validation
OnSessionCreation() → callback before Logon validation

Key Points

Socket connection ≠ session creation
Session is created only after successful Logon

8. Can I stop the configured counterparties from establishing connections with my Acceptor application?

View Answer

Yes, you can block new connections without affecting existing sessions.

View Code

_acceptor.AcceptNewConnection = false;

Key Points

Existing sessions remain active
Prevents new session creation
Useful during high load

9. How do I identify all FixSession instances and their current session states?

View Answer

You can use the following methods:

View Code

FixSessionInfo[] sessions =
_acceptor.GetFixSessionInfoCollection();

eSessionState state =
_acceptor.GetSessionState(targetCompID);

Key Points

Each session has FixSessionInfo
Use TargetCompID to identify session
Helps monitor session health

10. How do I set different messaging rules for different counterparties?

View Answer

Messaging rules are controlled using FixConfig.

Each counterparty can have:

Different Data Dictionary
Different validation rules
Different recovery rules

Approach:

Create separate FixConfig for each counterparty
Assign during AcceptorTargetConfig creation

Key Points

Enables flexible configuration
Supports multiple counterparties
Ensures isolation between sessions

11. How do I logout a particular counterparty without affecting the transactions it made?

View Answer

You can retrieve the FixSession for a specific counterparty and perform logout.

View Code

FixSession fixSession =
_acceptor.GetFixSession(targetCompID);

Using this object:

You can send Logout message
Perform session-specific actions

Key Points

Logout is session-specific
Does not affect other sessions
Safe for live systems

12. Does the Acceptor class provide help in order matching?

View Answer

No, the Acceptor does not perform order matching.

Responsibilities:

Manage FIX sessions
Deliver messages

Application responsibility:

Process business logic
Handle order matching

Key Points

Acceptor is infrastructure layer
Business logic must be implemented separately

13. How does my Acceptor application validate the credentials of a session initiating counterparty?

View Answer

Credential validation is handled in the OnLogonMessage callback.

View Code

string password = message.GetField(FixFieldTag.Password_554);

if (password != "FGH")
{
    FixMessage logoutFixMessage =
    fixSession.GetLogoutMessage("Invalid Password. Logout Forced");

    logoutFixMessage.SetField(789, "");

    fixSession.SendMessage(logoutFixMessage);
    return;
}

FixMessage fixLogonMessage =
fixSession.GetSessionFixMessage("A");

fixLogonMessage.SetField(FixFieldTag.HeartBtInt_108, "30");
fixLogonMessage.SetField(FixFieldTag.EncryptMethod_98, "0");

fixSession.SendMessage(fixLogonMessage);

Key Points

Validation logic is customizable
Based on username/password or other rules
Determines session acceptance

14. How can my Acceptor application know about the change of state of a FixSession maintained by it?

View Answer

The Acceptor notifies session state changes using callback methods.

OnSessionStateChanged(FixSession fixSession, eSessionState sessionState)

You can also register for alerts using FixSessionState.

View Code

FixSessionState fixSessionState =
_acceptor.GetFixSessionState(_acceptorTargetConfig.TargetCompID);

fixSessionState.GetAlertManager().RegisterAlertCallback(
    eAlertType.All,
    new AlertCallbackRoutine(OnFixSessionAlertMessage)
);

private void OnFixSessionAlertMessage(
    SessionInfo fixSessionInfo,
    eAlertType alertType,
    string alertMessage,
    string additionalMessage)
{
    switch (alertType)
    {
        case eAlertType.Error:
            break;

        case eAlertType.InboundMessage:
            break;

        case eAlertType.InboundMessageSeqNumber:
            break;

        case eAlertType.Info:
            break;

        case eAlertType.OutboundMessage:
            break;

        case eAlertType.OutboundMessageSeqNumber:
            break;

        case eAlertType.SessionStateChange:
            break;

        case eAlertType.Warning:
            break;
    }
}

Key Points

Callback notifies state changes
Alerts provide detailed session events
Useful for monitoring and logging

15. How do I use SSL?

View Answer

SSL can be enabled using SecurityOptions.

View Code

private Acceptor _acceptor = new Acceptor();

SecurityOptions securityOptions =
new SecurityOptions(
    eNetworkSecureProtocol.Ssl,
    eConnectionEnd.Server
);

securityOptions.CertificateFile = "...";

_acceptor.SecurityOptions = securityOptions;

Key Points

Enables secure FIX communication
Requires valid certificate
Recommended for production systems