CME STP FIX - Allocation Message Flows

CME STP FIX - Allocation Message Flows

This section describes the sequence and flow of information (showing key FIXML fields) between the client system and the CME STP FIX during allocation.

Contents

 

Allocation

CME STP supports allocations, which means one firm "gives-up" trades to another firm. The firm that executed a trade (i.e. Executing firm) may want to "allocate" or "give-up" a trade to a different firm (i.e. Claiming firm). 

The Executing firm will receive an Offset message to indicate that the trade is being removed and the Claiming Firm will receive an Onset message to indicate the trade is now on their books. This flow shows the original trade followed by the modified trade, and the offset and onset messages that the API sends for an allocation.

This diagram shows only responses, and not requests.

In the case of a reversal or release of an allocation, CME STP will report both the offset and onset trades as cancelled. (tag 487-TradeReportTransType= 1) Parameters on the cancel will mirror those of the original offset or onset, e.g. the side of the cancel message will match the side of the respective offset or onset message.

Sub-allocation (e.g. the claiming firm marks a claimed allocation for give-up) will not result in the "Trade marked for Allocation" message above, however, when the new claiming firm claims the allocation, CME STP FIX will send offset and onset trades.

Allocation of Spreads

CME STP allocates spreads at the leg level only, therefore the API does not mark spread level messages for allocation. For users requesting tag 442-MLegRptTyp=2 (individual leg of a multi-leg security), allocation of spread legs is no different than allocation of outright trades, except that tag 442-MLegRptTyp=2 instead of 1.

For firms requesting spread level messages, (for example,  tag 442-MLegRptTyp=3), allocation behaves differently. When a clearing firm marks a leg of a spread for allocation, the API sends a message showing that individual leg as an tag 442-MLegRptTyp=2 to the executing firm, even though the user only requested @MLegRptTyp=3. The field tag 1851-StrategyLinkID can be used to link the allocated leg to the multi-leg spread message. The offset and onset trades after the claiming firm claims the allocation are no different than before. Should a clearing firm un-mark a trade for allocation (not illustrated), the API will send a message with tag 442-MLegRptTyp=2 showing the leg as un-marked.

When requesting tag 442-MLegRptTyp=3, be advised that any tag 442-MLegRptTyp=2 messages received only indicate allocation status. These tag 442-MLegRptTyp=2 messages must not be booked as new trades, considering that they duplicate one or more legs of the tag 442-MLegRptTyp=3 messages already received. Client systems should not double count the trades.

 

This diagram shows only responses, and not requests.

 

 

Allocation States

Allocation Scenarios

  • APS - Average Price

  • GUS - Give-up

Allocation Type

Scenario / Transition

Transition End State

CME STP TCR Received?

Summary

Allocation Type

Scenario / Transition

Transition End State

CME STP TCR Received?

Summary

GUS

GUS

Mark for Allocation (individual trade)

 

Y

When The Buy Side of Trade is Marked for Allocation

Then the Buy Side Receives TCR which is a Replace (tag 487-TradeReportTransType=2) with tag 826-AllocationIndicator=1 and tag 793-SecondaryAllocationGroupID

GUS 

Allocate Trade to Claiming Firm

Allocation Pending

N

 

GUS 

Allocation Claimed by Receiving Firm

Claimed

Y

When firm "<GiveUp>" accepts the allocation from firm "<Buyer>"

Then firm "<GiveUp>" receives new OFFSET TCR with  (tag 487-TradeReportTransType=0, tag 10021-OffsetInstruction=0 and tag 793=SecondaryAllocationGroupID=”abc”, no SideTrdRegTS block       

Then firm "<Claiming>" receives new ONSET TCR with  (tag 487-TradeReportTransType=0, tag 10021-OffsetInstruction=1 and tag 793=SecondaryAllocationGroupID=”abc”, no SideTrdRegTS block

GUS 

Trade is Unmarked

Start

Y

Given Trade entered in CPC

When The Buy Side of Trade is Marked for Allocation

Then the Buy Side Receives TCR, which is a Replace tag 487-TradeReportTransType=2 with tag 10021-OffsetInstruction=1 and tag 793=SecondaryAllocationGroupID

When the Buy Side of Trade has Allocation Unmarked in FECPLus

Then the Buy Side Receives TCR, which is a Replace tag 487-TradeReportTransType=2 AND NO tag 10021-OffsetInstructionand NO tag 793=SecondaryAllocationGroupID

GUS 

Claimed Allocation: Reverse Requested and Accepted

Reversed

Y

Given Allocation has been claimed

When the Claiming firm allocation is reversed the following day, then NO TCR is reported

When the Buy Side of Trade accepts the reversal

Then the Buy Side Receives TCR which is updated OFFSET with tag 487-TradeReportTransType= 1 (cancel)

Then the Claimed Side Receives TCR which is updated ONSET with tag 487-TradeReportTransType= 1 (cancel)
 

GUS 

Claimed Allocation: Reversal Requested but is Rejected or Cancelled

Claimed

N

 

APS

 APS

Create APS Group (marking for APS allocation)

Incomplete Group

Y

Given Trade entered in CPC

When The Buy Side marks trades for APS and Assigns group

Then The Buy Side Receives TCR which is a Replace ( tag 487-TradeReportTransType=2) with tag 826-AllocationIndicator=1, tag 793=SecondaryAllocationGroupID and tag 1853-AveragePricingIndicator=1

APS

Complete Average Price Group

Complete Group

N

 

APS 

Allocate Trade to Claiming Firm

Allocation Pending

N

 

APS 

Claim Allocation APS Group

Claimed

Y

Given Trades allocated to APS Group then TCR tag 793=SecondaryAllocationGroupID=”abc”, tag 1853-AveragePricingIndicator=1, tag 826-AllocationIndicator=1

Given Allocation performed on APS group to Carry Firm then No TCR When Claiming Firm Claims Allocation

Then the Buy Side Receives TCR with tag 10021-OffsetInstructionand=0, tag 793=SecondaryAllocationGroupID=”abc”, tag 6-AveragePrice, tag 11-ClientOrderID="Group Name"

Then the Claiming firm Receives TCR with tag 10021-OffsetInstructionand=1, tag 793=SecondaryAllocationGroupID=”abc”, tag 6-AveragePrice, tag 11-ClientOrderID="Group Name"

APS - Full Lifecycle

APS

 

 

 

 

 

Full Cycle APS

 

 

Given Trades allocated to APS Group, then TCR tag 793=SecondaryAllocationGroupID=”abc”, tag 1853-AveragePricingIndicator=1, tag 826-AllocationIndicator=1

Given Allocation performed on APS group to Carry Firm, then No TCR When Claiming Firm Claims Allocation

Then the Buy Side Receives TCR with tag 10021-OffsetInstructionand=0, tag 793=SecondaryAllocationGroupID=”abc”, tag 6-AveragePrice, tag 11-ClientOrderID="Group Name"

Then the Claiming firm Receives TCR with tag 10021-OffsetInstructionand=1, tag 793=SecondaryAllocationGroupID=”abc”, tag 6-AveragePrice, tag 11-ClientOrderID="Group Name"

Create Group

 

Y

Given Trades allocated to APS Group, then TCR tag 793=SecondaryAllocationGroupID=”abc”, tag 1853-AveragePricingIndicator=1, tag 826-AllocationIndicator=1

Complete Group

 

N

No TCR sent to STP

Allocate Trade to claiming Firm

 

N

No TCR sent to STP

Claim Allocation

 

Y

Buy Side Receives TCR with tag 10021-OffsetInstructionand=0, tag 793=SecondaryAllocationGroupID=”abc”, tag 6-AveragePrice, ClOrdID="Group Name"

Claiming firm Receives TCR with tag 10021-OffsetInstructionand=1, tag 793=SecondaryAllocationGroupID=”abc”, tag 6-AveragePrice, tag 11-ClientOrderID="Group Name"

Reverse Allocation

 

N

No TCR sent to STP

Accept Reversal 

 

Y

Then the Buy and Claiming side receive a Cancel message

Sub-Allocation

 

Creating a Sub-Allocation

Claimed

Y

When the Claiming side Marks for SubAllocation
Then no TCR is sent
When The Buy Side is allocated to firm Claiming and Trade Claimed
Then The Claiming Side Receives an Offset Message
Then The Re-allocated Side Receives an Onset Message




How was your Client Systems Wiki Experience? Submit Feedback

Copyright © 2024 CME Group Inc. All rights reserved.