XmlData (FIX tag 213)

dataFIX 4.4FIX 4.2session envelope

XmlData (tag 213) is a data field defined in FIX 4.4 and FIX 4.2. It belongs to the session envelope: every FIX 4.4 message carries it, so it identifies the session rather than describing the business event. It is length-prefixed — tag 212 carries the byte count, so the value may contain the SOH separator without breaking the message.

At a glance

Tag
213
Name
XmlData
Datatype
data
Dialects
FIX 4.4 and FIX 4.2
Messages
93
Length field
tag 212

What the specification says

FIX 4.4

Actual XML data stream (e.g. FIXML). See approriate XML reference (e.g. FIXML). Note: may contain embedded SOH characters.

FIX 4.2

Actual XML data stream (e.g. FIXML). See appropriate XML reference (e.g. FIXML). Note: may contain embedded SOH characters.

Descriptions are quoted from the FIX Orchestra sources under the Apache 2.0 licence.

A real message using tag 213

NewOrderSingle · FIX 4.4
TagFieldWire valueMeaning
8BeginStringFIX.4.4
9BodyLength129
35MsgTypeDOrder – Single
49SenderCompIDBOARTEAM
56TargetCompIDCOUNTERPARTY
34MsgSeqNum2
52SendingTime20240101-12:00:00.000
212XmlDataLen7
213XmlDataEXAMPLE
11ClOrdIDORD-10042
54Side1Buy
60TransactTime20240101-12:00:00.000
40OrdType1Market
10CheckSum227
Edit and decode it yourself

Shown with | separators for readability. On the wire FIX uses SOH (0x01), an invisible control byte — and because BodyLength and CheckSum are computed over the actual bytes, the two forms have different checksums. Both are valid and both decode here.

Open in the full decoder →

Generated from the FIX 4.4 dictionary and verified at build time: it parses and validates with no issues. Open the decoder to try your own message.

Where tag 213 appears

Session envelope field
Tag 213 appears in every one of the 93 FIX 4.4 message types, because it is part of the standard header or trailer. Listing them all would say nothing useful — it is present on anything you will ever decode.

Wire format

Raw bytes, length-prefixed by a partner field. The value may legally contain the SOH separator, which is why the length matters. @boarteam/fix reads the partner length field first and takes exactly that many bytes, so an embedded separator does not truncate the value.

Read tag 213 in TypeScript

decode.tsts
import { createFixEngine } from "@boarteam/fix";import { dictionary } from "@boarteam/fix-dict-fix44";const fix = createFixEngine(dictionary);const { message, issues } = fix.parse(raw);// Length-prefixed: tag 212 carries the byte count, so the// value may contain the SOH separator without breaking the message.const length = message.fields[212]?.value;const xmlData = message.fields[213]?.raw;

Other data fields

Decode this in your own code

The same engine that produced the decoded example above is an Apache-2.0 npm package with zero runtime dependencies. It runs in Node and in the browser, and parse() returns problems as data instead of throwing.

npm i @boarteam/fix @boarteam/fix-dict-fix44