Indexes

Message Layouts
Session
PreTrade
Trade
PostTrade
Infrastructure

  • Documentation

  • Message

    Allocation (J)

    ID19
    PedigreeAdded 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 Shares 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.
    • Multiple orders can be combined for allocation by identifying the number of orders in the NoOrders field and each individual order in the OrderID 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 message specifying one or more AllocAccount and AllocShares values within the repeating group designated by NoAllocs.
    • 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:

    1. Using Average Price: Each AllocAccount has a single AllocAvgPx
    2. Using Executed Price: Combination of each AllocAccount and AllocPrice (unique LastPx) (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 for more examples and details.

    Field
    Name
    Type
    Req'd
    Comments
    Pedigree
    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
    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
    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
    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
    Indicates number of allocation groups to follow.
    Added FIX.2.7
    Updated FIX.4.1
    Y
    Added FIX.2.7

    Orchimate Copyright 2026 Atomic Wire Technology Limited
    Orchestra Copyright 2026 FIX Protocol Ltd
    Terms of Service|Privacy Policy