Is AllocID the block trade ID in post-trade AllocationInstruction?


#1

Hi, I am trying to understand what’s the meaning of AllocID field in AllocationInstruction message (FIX 4.4),
The use case I am working on is a straightforward post-trade allocation:

  • buy-side has an existing block trade which has been booked previously, and want to allocate it into several funds. For this, buy-side needs to tell sell-side the ID of the block trade

Is AllocID (tag 70) the right field to send the block trade ID? My concern is that the FIX 4.4 spec says AllocID is “Unique identifier for this Allocation Instruction message”. However I can imagine scenarios when buy-side would send several AllocationInstructions for the same block trade - in this case AllocID will not be unique! Is Alloc ID supposed to be the unique ID of this allocation message, or the unique ID of the exisitng block trade being allocated?

Cheers,
Sergey


#2

Hi Sergey,

looking at FIXimate http://fiximate.fixtrading.org/ I see that there is also a field RefAllocID
which is used reference to original AllocID in the case of AllocTransType=Replace or Cancel.

So my best guess is that the AllocID is solely for the purpose of replacing or cancelling previous AllocationInstruction messages.

I would also check the repeating groups OrdAllocGrp and especially ExecAllocGrp.

But I am sure some more knowledgeable will answer soon.

Cheers, Jörg


#3

Thanks Jörg, indeed ExecAllocGrp may offer a way to send the block trade ID.
I am however hoping there’s a simpler approach for the case when users will be always allocating a single block trade. Looking at the implementation offered by some 3rd parties, I see that AllocID is listed as “The publishing systems ticket number of the block transaction being allocated.” , which is in line with my scenario. So I wonder if this is indeed the common practice, even though it seems to contradict the FIX 4.4 spec.


#4

AllocID(70) is a message level identifier in the AllocationInstruction message. It is does not identify an entity, e.g. a block trade. OrdAllocGrp and ExecAllocGrp contain one or more entity level identifiers. In your case, I propose to use TradeID(1003) from inside the ExecAllocGrp and NoExecs(124)=1 for this purpose. You are right that there can be multiple messages and hence multiple AllocID values for the same block trade.

You can also use the TradeCaptureReport(MsgType=AE) to convey allocations of a trade. Use the TrdAllocGrp on the side level with IndividualAllocID(467) to identify the allocation of the trade (if needed). You must specifiy AllocAccount(79) within TrdAllocGrp.


#5

Thank you, Hanno. Indeed I will proceed with using ExecAllocGrp to receive the block trade ID, even though it will always be one single entry for me. Please note that TradeID (1003) which you suggest is not supported in FIX 4.4 (appeared in 5.0) so I’ll go with ExecID (17). I already send this in trade’s ExecutionReport, so using the same tag makes logical sense.


#6

Yes, this is the way to go: Use repeating groups of size 1 if you need the field just once.

And it is also perfectly OK and recommended practice to use fields from later FIX versions.
So I would suggest to stay with the TradeID(1003) as suggested by Hanno unless you have
very strict requirements to only and only use FIX 4.4 fields.


#7

And it is also perfectly OK and recommended practice to use fields from later FIX versions.

Oh ok, I will check with users but hopefully they are fine with this too. In the past we had to use our own custom tags to support bespoke fields, but that was way before FIX 5.0 appeared.

What’s the difference in meaning between ExecID and TradeID? As I mentioned, when the user executes the block trade over FIX, I send the block trade ID in ExecID field of ExecutionReport (8) message. There’s no TradeID <1003> field in ExecutionReport message definition. So I am inclined towards using ExecID in AllocationInstruction as well, but keen to find out the difference between the two.


#8

Over the past years the common practice changed. Now it is always better to use fields defined in later FIX versions than use or define custom fields. I think most of the more useful custom field have been standardized now.

If your ID is really an ExecID used in previous ExecutionReport messages I am inclined to use ExecID (17).

Maybe Hanno has some more thoughts on this… :slight_smile:


#9

I am now somewhat stuck with the similar question for the response I send to AllocationInstruction. I want to use the AllocationReport (AS) to confirm the allocation to buyside and provide details of the allocation trades.

My system books new trades per allocation leg and I need to communicate the new trade IDs back. I can’t find a suitable field in AllocationReport though to send back new trade IDs.

AllocationReport contains AllocGrp which includes IndividualAllocID <467> field. However this field is also present in AllocationInstruction message. So I want to keep IndividualAllocID to allow the buyside to send their own reference for each allocation leg, in order to be able to track back which new trade matches which AllocGrp entry in request.

Do you know what is the general practice for sending back a unique new ID in AllocationReport (AS) for new trades created by splitting the block trade?
I can use SecondaryIndividualAllocID <989> but have a feeling it’s not the intended use.


#10

ExecID vs TradeID: Initially (up to FIX 4.3) there was no TCR, just an ER. Many people still only confirm executions and do not send an additional TCR to confirm the related trade. ExecID is fine if you do not use TCR messages. If you do, you should refer to TradeID and can additionally reference back to the ExecID from the ER message.


#11

@kubyser: you should not use the AllocationReport (AR) to implicitly report new trades that the recipient has never seen before. Use the TradeCaptureReport(TCR) to report trade splits and then use ARs to convey how they are to be allocated. That is the cleaner approach. ARs should only reference orders/executions/trades but not “create” them.