AllocationInstruction (MsgType J)

applicationFIX 4.4FIX 4.2

AllocationInstruction is the FIX message with MsgType J, defined in FIX 4.4 and FIX 4.2. It is an application-level message: it carries a business event rather than managing the session. Its body has 65 top-level members once the standard header and trailer are counted. Earlier dialects call it Allocation; the MsgType value is unchanged.

MsgType is case-sensitive
J is AllocationInstruction, but j is a different message entirely — BusinessMessageReject. Twenty-three FIX message types differ from another only by letter case.
Also known as Allocation
FIX 4.2 calls MsgType J Allocation. Same value on the wire, different name in the spec.

A real AllocationInstruction

AllocationInstruction · FIX 4.4
TagFieldWire valueMeaning
8BeginStringFIX.4.4
9BodyLength129
35MsgTypeJAllocation Instruction
49SenderCompIDBOARTEAM
56TargetCompIDCOUNTERPARTY
34MsgSeqNum2
52SendingTime20240101-12:00:00.000
70AllocIDEXAMPLE
71AllocTransType0New
626AllocType1Calculated (includes MiscFees and NetMoney)
857AllocNoOrdersType0Not specified
54Side1Buy
53Quantity1000000
6AvgPx1.09215
75TradeDate20240101
10CheckSum120
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.

Message body — FIX 4.4

Components are listed by name and link to their own page rather than being expanded inline; repeating groups are expanded, including where they nest.

Message body — FIX 4.2

Components are listed by name and link to their own page rather than being expanded inline; repeating groups are expanded, including where they nest.

What changed between the dialects

Present in FIX 4.4 only (39)

tag 626, tag 793, tag 796, tag 808, tag 466, tag 857, OrdAllocGrp, ExecAllocGrp, tag 570, tag 700, tag 574, Instrument, InstrumentExtension, FinancingDetails, UndInstrmtGrp, InstrmtLegGrp, tag 854, tag 229, tag 625, tag 423, tag 860, SpreadOrBenchmarkCurveData, Parties, tag 775, tag 238, tag 237, tag 754, tag 159, tag 540, tag 738, tag 920, tag 921, tag 922, tag 650, Stipulations, YieldData, tag 892, tag 893, AllocGrp

Present in FIX 4.2 only (22)

group 73, group 124, tag 55, tag 65, tag 48, tag 22, tag 167, tag 200, tag 205, tag 201, tag 202, tag 206, tag 231, tag 223, tag 207, tag 106, tag 348, tag 349, tag 107, tag 350, tag 351, group 78

Handle AllocationInstruction 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);if (message.msgType === "J") {  message.name;            // "AllocationInstruction"  // fields are keyed by tag; repeating groups live on message.groups}// Problems come back as data, never as exceptions:issues;                    // FixIssue[]fix.validate(message);     // dictionary-level problems

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