Standard for Post Trade Confirmations

We receive trade confirmations from various brokers via emails in csv/xls/pdf attachment and in all sorts of formats. Its time we had a standard is’nt it ?

FIX already supports Post Trade Confirmations in Confirmation (AK) format. It was introduced in FIX version 4.4. Please find below the current definition:

“The Confirmation messages are used to provide individual trade level confirmations from the sell side to the buy side. In versions of FIX prior to version 4.4, this role was performed by the allocation message. Unlike the allocation message, the confirmation message operates at an allocation account (trade) level rather than block level, allowing for the affirmation or rejection of individual confirmations.”

Thanks, Ram. I am not aware of a lot of buy side firms using FIX for receiving trade confirmations. I feel there is a need for a non FIX standard for trading confirmations…

Let me look at the AK msg type and see how easy is it to transpose a manual confirmation into it.

Hi Srini, we have lot of clients accepting trade confirmations in FIX, using AK messages. This is becoming trend lately.

1 Like

A non FIX standard for trade confirmations is always a welcome step but probably the FIX community wouldn’t be able to help much for a non FIX standard.

1 Like

Yes that’s a good idea. As per my experience, the FIX standard AK message has a decent coverage of the necessary fields required on a trade confirmation.

1 Like

Thanks, Sunil. Trust all is well.

Thanks Ram.

Isn’t this proposing yet another standard?

Hello Richard, I am not. There are a lot of smaller brokers who don’t use FIX post-trade, hence my question. Does anyone know which EMS/OMS systems support FIX Trade Confirmations ?

in my experience Drop copies (post-trade confirmation) usually comes as execution reports (35=8) or Trade Capture reports (35=AE). they can come build-in in the trade session, or in a completely separate FIX session which is more common. fluent Trade Technologies supports all this just right from the box from many venues.

Using FIX for post trade matching/confirmations is becoming much more common and replacing other mechanisms of doing post trade matching and confirmations, i.e. email, file based, proprietary protocols, etc. Sometimes this is done directly by the OMS used by the buy side or sell side. Other times its handled by a “middle office” system that integrates with the OMS. I work for Itiviti NYFIX, we offer a service NYFIX MATCHING which integrates with your OMS via FIX or a file and does the post trade confirmation process with your counter party via FIX. There is one version of the service for buy sides and another for sell sides.

1 Like

@rcomotto , this is not proposing a new standard. The Confirmation(35=AK) message type have existed in FIX since FIX 4.4 (published in 2003). This confirmation message serves the purpose of a pre-settlement confirmation at the allocated account level. This message is typically used between buy-side and sell-side as the step after the buy-side sends the block trade allocation instructions (i.e. using the AllocationInstruction(35=J)) to the sell-side.

@srinivas.padmasol as @briandriscoll stated there are a lot of trading platforms and vendors supporting this already.

@drroffe TradeCaptureReport has slightly different use case and can be used to confirm a trade as well, but usually between sell-sides and clearing houses, but sometimes used to confirm/affirm voice trades whether allocated or not.

1 Like

thanks for sharing this knowledge
regards

Helpful

As someone had mentioned earlier, there are plenty of non-FIX solutions out there. However (for friends in the US), one thing to add is that with the decommissioning of OASYS, many firms started to look into these solutions last year. I’ve noticed that interest into post-trade confirmations / allocations via FIX has increased a lot. I do believe many firms are still handling them manually, but will likely look to have a more automated / electronic solution in the near future.

TradeCaptureReport (35=AE or TradeNotification in EUREX ETI or MT512 in SWIFT) is the [only] legally binding report about of a trade for settlement in GER for instance. Allocation matching has some tradition in DTCC CTM. From 4.4 onwards the Alloc.Report was assigned its own message type 35=AS which substantially helped in establishing the message flow on allocationn processing - both order-bound pre and seperate instruction (35=J) bound post trade.