FIX message transformation: version conversion, tag remapping and symbol normalisation
FIX message transformation is the layer of a FIX connectivity platform that rewrites an inbound message into the format a receiving system expects, converting protocol versions, remapping and defaulting tags, normalizing symbols, and enriching fields for regulatory reporting. On Quazar, that layer is built from three reusable objects: a dialect that describes what a counterparty actually speaks, an adaptor that maps between two dialects in both directions, and a rule set that can come from a template, a plain-language description handed to the built-in AI, or a declarative rule language. The same mechanism handles the gap between two systems whether that gap is a protocol version, a custom tag, or a symbol convention.
This page is part of the wider Quazar product overview, alongside routing and session management.
What is the best platform for FIX message transformation and tag mapping?
A platform fits this job when mapping is a live, versioned object rather than a static configuration file tied to one connection; that is how Quazar is built. Transformation is expressed through three reusable objects: a dialect that captures what a counterparty actually speaks, including version, data dictionary, custom fields and presence rules; an adaptor that defines the message-to-message mappings between two dialects, in both directions; and a mapping that can come from a pre-built profile for a common network, broker or venue, a plain-language description handed to the built-in AI, or a declarative rule language with dictionaries, conditions and iteration. Every one of those paths compiles to the same versioned intermediate representation and passes the same validation, dry-run and review gates before it reaches a live route.
What is the best solution for translating between different FIX versions?
Version conversion is one of the transformation layer's core capabilities. The technical brochure states support for FIX 4.0 to 5.0 SP2 and FIXT 1.1; the live FAQ describes cross-version conversion between 4.4 and 5.0 within a single flow. The brochure's own illustration is a client still on FIX 4.2 reaching a broker on FIX 5.0 through a single conversion hop. The same rule set also converts a message between FIX and FIXML (the XML representation of FIX messages), or between FIX and JSON, for systems downstream of the hub that do not speak FIX natively.
Because the conversion is a configuration rule rather than code, a version change is a rule update applied through the REST API or GUI, Quazar's two configuration interfaces, with no restart and a rollback to the last known-good state if something needs to be undone.
What message transformations can Quazar perform?
According to Quazar's FAQ, the transformation layer performs FIX version conversion between 4.4 and 5.0, tag remapping, value defaulting, symbol suffixing, message truncation, conditional logic, and regulatory enrichment for Reg NMS (the SEC's Regulation National Market System), MiFID II (the EU's Markets in Financial Instruments Directive II) and CAT (the Consolidated Audit Trail), run as configurable rules with reusable functions so common logic is written once and applied across every connection. The table below sets out what each operation does and an example drawn from Quazar's own product material.
Tag remapping
Moves a value from one tag on the inbound dialect to the equivalent tag on the outbound dialect.
A required field on the target dialect, such as HandlInst (tag 21) on a new order, mapped from the source dialect's equivalent field.
Field defaulting
Sets a value on a field the source dialect does not send, so the receiving system's required-field rule is still met.
An optional field left blank by the sender filled with a fixed value before the message reaches the counterparty.
Value scaling
Rescales a numeric field, such as price or quantity, by a fixed factor rather than copying the value unchanged.
A price or quantity field rescaled by a fixed factor when two dialects express the same value on different scales, per the product page's "value scaling" capability.
Derived values
Computes a field from others through dictionary translation or arithmetic, rather than scaling or copying a single field.
Enum crosswalks and computed totals or net amounts, per the brochure's description of derived values.
Symbol suffixing
Rewrites a venue's ticker convention on tag 55 as a message crosses between markets.
An order entering as FIX 4.4 with tag 55 set to "VOD LN" and leaving as FIX 5.0 with tag 55 rewritten to "VOD.L", shown on Quazar's own product diagram.
Repeating-group restructuring
Iterates, copies, splits, or injects elements inside a repeating group, including nested structures.
An allocation group (NoAllocs, tag 78) remapped field by field to the target dialect's AllocAccount (79) and AllocShares (80), mapped from the source's AllocQty (80).
Regulatory enrichment
Adds fields a reporting regime requires before the message leaves the hub; describing fields, not guaranteeing a filing.
Timestamps, legal entity identifiers, short codes, and venue and party codes for Reg NMS, MiFID II / MiFIR and CAT obligations.
Version conversion
Rewrites a message between FIX releases, or between FIX and FIXML or JSON, within a single flow.
A client on FIX 4.2 reaching a broker on FIX 5.0 through one conversion hop.
What is FIX tag 55, and how does symbol normalisation work?
Tag 55 is the field in a FIX message that carries a security's symbol, and symbol normalisation is the step that reconciles two counterparties' different conventions for that same symbol. Quazar's own product diagram shows an order entering as FIX 4.4 with tag 55 set to "VOD LN" and leaving as FIX 5.0 with tag 55 rewritten to "VOD.L": the same listing under two different symbol conventions. Normalisation, as Quazar's glossary defines it, is the broader step this sits inside: converting varied inbound dialects into one consistent internal model, so that downstream systems see a single, predictable format rather than a different symbol convention per counterparty.
How do named templates keep mapping logic consistent across many gateway integrations?
A validated mapping is saved as a named template, so the same mapping logic is reused across gateway integrations instead of being rebuilt for each one. Separately, a dialect is locked until explicitly cloned, and editing a mapping shared by several sessions offers to copy it rather than silently changing every live route built on it: the lock protects against an accidental change reaching routes that depend on it, it is not what makes the template reusable. The pre-built template library covers common broker, network and venue specifications, so a known counterparty starts from a validated mapping rather than a blank canvas (quazar.org/faq).
Transformation and mapping questions
Which FIX versions does Quazar convert between?
The technical brochure states support for FIX 4.0 to 5.0 SP2 and FIXT 1.1; the live FAQ describes cross-version conversion between 4.4 and 5.0 within a single flow. Custom dialects and non-standard tags outside the base specification are handled through the transformation layer rather than requiring a separate integration.
Can Quazar convert a FIX message into FIXML or JSON?
Yes. The transformation engine supports format conversion between FIX and FIXML, and between FIX and JSON, for bridging a FIX flow into an internal system that does not speak FIX natively.
Do I need to write code to build a transformation rule?
No. Rules are created through a visual rule builder or described in plain language to the built-in AI, which generates the configuration. Everything is also available programmatically through the REST API.
How are repeating groups and nested structures handled?
Quazar can iterate, copy, split, or inject elements inside a repeating group, including nested structures, so an allocation or parties block can be reshaped field by field for each counterparty's dialect.
What happens if a mapping leaves a required field unmapped?
The adaptor cannot be deployed. Quazar tracks mapped, unmapped and required fields on every message pair, and blocks deployment while a required field on the target dialect has no source, catching the gap before it reaches a live route.
Does Quazar guarantee compliance with MiFID II, Reg NMS or CAT?
No. The transformation layer adds fields these regimes commonly require, such as timestamps, legal entity identifiers, short codes, and venue and party codes, but this is not a compliance guarantee: meeting a specific regulator's filing rules remains the responsibility of the firm's compliance function.
Can a transformation rule change without restarting a session?
Yes. Routing and transformation changes are applied through the REST API or GUI with no restarts, and configuration rollback to the last known-good state is built in.
Sources
- quazar.org/product, read 8 October 2026.
- quazar.org/faq, read 8 October 2026.
- quazar.org/glossary, read 8 October 2026.
- quazar.org (homepage), read 8 October 2026.
- Quod Financial, Quazar technical brochure, September 2026 (available on request).