| ID | 19 |
| Pedigree | Added FIX.2.7, Updated FIX.4.2 |
The Allocation 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 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 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 message can be submitted as preliminary, calculated, calculated without preliminary, new, cancel or replace. The AllocTransType field indicates the purpose of the message. When submitting calculated, replace, or cancel AllocTransType messages the RefAllocID field is required. Replacement allocation messages must contain all data for the replacement allocation. Calculated allocations should have a unique AllocID and use RefAllocID to specify the AllocID from the preliminary. Calculated without preliminary are sent unsolicited from the sellside and do not require RefAllocID.
The allocation message contains repeating fields for each order, sub-account and individual execution. The repeating fields are shown below in typeface Bold-Italic and 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
Sharesvalue 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. - Multiple orders can be combined for allocation by identifying the number of orders in the
NoOrdersfield and each individual order in theOrderIDfields. 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 message specifying one or more
AllocAccountandAllocSharesvalues within the repeating group designated byNoAllocs. - Sellside sends Execution Report messages for the “New” and resulting fills.
- Post-Trade Allocation messaging takes place
Post-Trade Allocation can be computed via one of two methods:
- Using Average Price: Each
AllocAccounthas a singleAllocAvgPx - Using Executed Price: Combination of each
AllocAccountandAllocPrice(unique LastPx) (e.g. Japan)
Post-Trade Allocation supports three different message flows:
- Buyside initiated without
Misc Fees - Buyside-initiated with
Misc Feecomputation - Sellside-initiated
See Appendix K: Example Usage of Allocations for more examples and details.
Field | Name | Type | Req'd | Comments | Pedigree |
|---|---|---|---|---|---|
StandardHeader | Y | MsgType = J | Added FIX.2.7 | ||
70 | Y | Added FIX.2.7 | |||
71 | Y | Added FIX.2.7 | |||
72 | Required for AllocTransType = Calculated, Replace, or Cancel | Added FIX.2.7 Updated FIX.4.1 | |||
196 | Can be used to link two different Allocation messages (each with unique AllocID) together, i.e. for F/X “Netting” or “Swaps” | Added FIX.4.1 | |||
197 | Can be used to link two different Allocation messages and identifies the type of link. Required if AllocLinkID is specified. | Added FIX.4.1 | |||
OrdAllocGrp | Indicates number of orders to be combined for allocation. If order(s) were manually delivered set to 1 (one). | Added FIX.2.7 Updated FIX.4.1 | |||
ExecAllocGrp | Indicates number of individual execution repeating group entries to follow. Absence of this field indicates that no individual execution entries are included. Primarily used to support step-outs. | Added FIX.4.0 Updated FIX.4.2 | |||
54 | Y | Added FIX.2.7 | |||
55 | Y | Added FIX.2.7 | |||
65 | Added FIX.2.7 | ||||
48 | Added FIX.2.7 | ||||
22 | Added FIX.2.7 | ||||
167 | Must be specified if a Future or Option. If a Future: Symbol, SecurityType, and MaturityMonthYear are required. If an Option: Symbol, SecurityType, MaturityMonthYear, PutOrCall, and StrikePrice are required. | Added FIX.4.1 | |||
200 | For Options or Futures to specify the month and year of maturity. | Added FIX.4.1 | |||
205 | For Options or Futures and can be used in conjunction with MaturityMonthYear to specify a particular maturity date. | Added FIX.4.1 | |||
201 | For Options. | Added FIX.4.1 | |||
202 | For Options. | Added FIX.4.1 | |||
206 | For Options. | Added FIX.4.1 | |||
231 | For Fixed Income, Convertible Bonds, Derivatives, etc. Note: If used, quantities should be expressed in the "nominal" (e.g. contracts vs. shares) amount. | Added FIX.4.2 | |||
223 | For Fixed Income. | Added FIX.4.2 | |||
207 | Can be used to identify the security. | Added FIX.4.1 | |||
106 | Added FIX.3.0 | ||||
348 | Must be set if EncodedIssuer field is specified and must immediately precede it. | Added FIX.4.2 | |||
349 | Encoded (non-ASCII characters) representation of the Issuer field in the encoded format specified via the MessageEncoding field. | Added FIX.4.2 | |||
107 | Added FIX.3.0 | ||||
350 | Must be set if EncodedSecurityDesc field is specified and must immediately precede it. | Added FIX.4.2 | |||
351 | Encoded (non-ASCII characters) representation of the SecurityDesc field in the encoded format specified via the MessageEncoding field. | Added FIX.4.2 | |||
53 | Y | Total number of shares allocated to all accounts | Added FIX.2.7 Updated FIX.4.0 | ||
30 | Market of the executions. | Added FIX.4.1 | |||
336 | Added FIX.4.2 | ||||
6 | Y | For F/X orders, should be the “all-in” rate (spot rate adjusted for forward points). | Added FIX.2.7 Updated FIX.4.1 | ||
15 | Currency of AvgPx. Should be the currency of the local market or exchange where the trade was conducted. | Added FIX.4.0 Updated FIX.4.1-errata1 | |||
74 | Absence of this field indicates that default precision arranged by the broker/institution is to be used | Added FIX.2.7 Updated FIX.4.0 | |||
75 | Y | Added FIX.2.7 Updated FIX.4.0 | |||
60 | Date/time when allocation is generated | Added FIX.4.0 | |||
63 | Absence of this field is interpreted as Regular | Added FIX.2.7 Updated FIX.4.0 | |||
64 | “Settlement Date”. Required with SettlmntTyp other than regular | Added FIX.4.0 Updated FIX.4.2 | |||
381 | Expressed in same currency as AvgPx. Sum of (AllocShares * AllocAvgPx or AllocPrice). | Added FIX.4.2 | |||
118 | Expressed in same currency as AvgPx. Sum of AllocNetMoney. | Added FIX.4.0 Updated FIX.4.1 | |||
MiscFeesGrp | Required if any miscellaneous fees are reported. Indicates number of repeating entries | Added FIX.4.0 Deprecated FIX.4.1 | |||
119 | Added FIX.4.0 Deprecated FIX.4.1 | ||||
120 | Added FIX.4.0 Deprecated FIX.4.1 | ||||
77 | Added FIX.2.7 | ||||
58 | Added FIX.2.7 | ||||
354 | Must be set if EncodedText field is specified and must immediately precede it. | Added FIX.4.2 | |||
355 | Encoded (non-ASCII characters) representation of the Text field in the encoded format specified via the MessageEncoding field. | Added FIX.4.2 | |||
157 | Applicable for Convertible Bonds and fixed income | Added FIX.4.1 | |||
158 | Applicable for Convertible Bonds and fixed income | Added FIX.4.1 | |||
AllocGrp | Indicates number of allocation groups to follow. | Added FIX.2.7 Updated FIX.4.1 | |||
StandardTrailer | Y | Added FIX.2.7 |
Orchimate Copyright 2026 Atomic Wire Technology Limited
Orchestra Copyright 2026 FIX Protocol Ltd
Terms of Service|Privacy Policy