Show Table of Contents

FIX Router

Chronicle FIX Router delivers enhanced operational flexibility to the distributed trading stack. As part of the Chronicle FIX suite, the Router is highly configurable, utilizing a natural rule syntax to manage the flow of FIX messages. Chronicle FIX Router offers the following functionalities:

  • Routing: Forwards FIX messages to different destinations based on standard and custom tags, enabling distribution across a pool of FIX gateway servers.

  • Version Translation: Translates FIX messages between different versions.

  • Rule-Based Drop Copy: Selectively stores outbound messages in queues based on message tags.

A single instance of the FIX Router can implement multiple functionalities simultaneously; however, version translation and rule-based drop copy cannot be enabled at the same time. Figure 1 shows a typical scenario of using a router in which a router forwards received messages from three initiators to two acceptors based on defined routing rules, and routes back the received replies from the acceptors to the initiators.

Routing Pattern

Routing rules in a RouterCfg object have a pattern property which defines the conditions that must be met by tags of a FIX message for the message to be forwarded to the specified route. These conditions are defined in expressions consisting of the following elements.

  • operators: ==, !=, <, >, ⇐, >=, =~ (regex match), !~ (regex not match).

  • logical operations: "and", "or" and "not".

  • "has": which checks presence of a tag.

  • brackets: to disambiguate expressions and/or clarifying the order of operations.

  • "$": which should precede tag numbers.

  • "@": which should precede tag names defined in the dictionary block.

Each expression should be enclosed in single or double quotation marks.

Managing Message Flow with Router

Chronicle FIX Router provides a flexible and performant mechanism for routing FIX messages between multiple upstream and downstream sessions. It supports selective routing of application-level and session-level FIX messages, enabling complex topologies and ensuring the correct flow of messages in both directions.

This guide documents how message categories are handled by the router, how routing is determined, and how customers can configure the system to suit their needs including functionality for routing session-level messages upstream.

Message Categories

Messages handled by the router are grouped into the following categories:

Category

Message Types

ORDER

D (NewOrderSingle), F, G, 8, AB, BN, E

MARKET_DATA

V, W, X, Y

QUOTE

S, R, AG, AJ, b, i, Z

PERMITTED_SESSION_LEVEL

3 (Reject) – optional, see below

Each category has its own routing logic. The router inspects message types and directs them based on routing rules defined in the configuration.

Routing Logic

The router uses a MessageParser to inspect incoming messages and determine routing behavior. By default, only application-level messages (like orders and market data) are routed.

Custom logic can be plugged in using:

  • MessageMapper for message interception and transformation

  • MessageNotifier to observe routed messages

  • RoutingRule for conditional behavior

Message Mapping

The MessageMapper API lets you inspect and modify FIX messages as they flow through the router. Implementations should be lightweight and thread-safe, since mappers are invoked for every message in high-throughput environments.

The MessageMapper abstraction exposes an API for users to interact with FIX messages as they pass through the router. It supports functionality such as:

* Simple field read/write

* Adding fields

* Removing fields

* Mutating fields

* Handling repeating groups

Rule Based Drop Copy 

Chronicle FIX router can be configured to store its outbound messages (messages from router to external and internal sessions) selectively in queues. The criteria to select a message to store are specified based on patterns in the messages' tags.

A dropCopyRules block should be added to the router configuration file. This block includes a set of rules that specify which messages should be stored and where they should be stored. A configuration example is shown below and the components of the block are explained.