Allocation (MsgType = J, FIXML = Allocation)

The Allocation (J) message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts. It can also be used as a confirmation message through which third parties can communicate execution and settlement details between trading partners. In addition, the Allocation (J) message can be sent by the broker to communicate fees and other details that can only be computed once the sub-account breakdowns are known.

Allocation (J) is typically communicated Post-Trade (after fills have been received and processed). It can, however, also be communicated Pre-Trade (at the time the order is being placed) to specify the account(s) and their respective order quantities which make up the order. This is a regulatory requirement in certain markets and for certain types of securities.

An Allocation (J) message can be submitted as preliminary, calculated, calculated without preliminary, new, cancel or replace. The AllocTransType (71) field indicates the purpose of the message. When submitting calculated, replace, or cancel AllocTransType (71) messages the RefAllocID (72) field is required. Note that AllocTransType (71) of Cancel, Reject, or Replace affects the entire Allocation (J) message thus each AllocAccount (79) (cannot cancel, reject, or replace a single AllocAccount instance without affecting the entire Allocation (J) messge). Replacement allocation messages must contain all data for the replacement allocation. Calculated allocations should have a unique AllocID (70) and use RefAllocID (72) to specify the AllocID (70) from the preliminary. Calculated without preliminary are sent unsolicited from the sellside and do not require RefAllocID (72) .

The Allocation (J) message contains repeating fields for each order, sub-account and individual execution. The repeating fields are indented with the => symbol. The field's relative position in the message is important. For example, each instance of allocation must be in the order shown below.

• The total shares allocated must equal the Shares (53) value which must equal the total executed quantity of the original order. If present, the total shares in the execution section must also be equal to this value.
• The number of sub-account instances is indicated in NoAllocs (78) .
• Multiple orders can be combined for allocation by identifying the number of orders in the NoOrders (73) field and each individual order in the OrderID (37) fields. Combined orders must have the same ticker, trade date, settlement date and side.

Pre-Trade Allocation consists of the following steps:

• Buyside sends a New Order request (D) message specifying one or more AllocAccount (79) and AllocShares (80) values within the repeating group designated by NoAllocs (78) .
• Sellside sends Execution Report (8) messages for the "New" and resulting fills.
• Post-Trade Allocation messaging takes place

Post-Trade Allocation can be computed via one of two methods:

1. Using Average Price: Each AllocAccount (79) has a single AllocAvgPx (153)
2. Using Executed Price: Combination of each AllocAccount (79) and AllocPrice (366) (unique LastPx (31) ) (e.g. Japan)

Post-Trade Allocation supports three different message flows:

1. Buyside initiated without Misc Fees
2. Buyside-initiated with Misc Fee computation
3. Sellside-initiated

See Appendix K: Example Usage of Allocations of FIX Specification for more examples and details.

© 2026. EPAM Systems. All Rights Reserved.

All material contained within the website is copyright of EPAM Systems, Inc. No material contained herein can be copied or otherwise used without the express permission of the copyright holder.