Multiple IOI modifications

Imported from previous forum

[ original email was from Olivier Morel - ]
What IOIRefID should be used in case of multiple IOI
modification ?
eg:
1st message(MsgSeqNum = 1)
IOIid = 1

2nd message(MsgSeqNum = 2) 1st modification
IOIid = 2
IOIRefID = 1

3rd message(MsgSeqNum = 3) 2nd modification
IOIid = 3
should IOIRefID be 1 or 2 ?

Thank you for any help.

 Olivier.

[ original email was from Toby - wxyz4321@hotmail.com ]
Because modification of an IOI is either Cancel or Replace (field 28), any modifications to a subsequent IOI replace should contain the IOIRefID of the 1st replacement, not the original, (ie IOIRefID=2 in the case below)

Toby

> What IOIRefID should be used in case of multiple IOI
> modification ?
> eg:
> 1st message(MsgSeqNum = 1)
> IOIid = 1
> …
>
> 2nd message(MsgSeqNum = 2) 1st modification
> IOIid = 2
> IOIRefID = 1
> …
>
> 3rd message(MsgSeqNum = 3) 2nd modification
> IOIid = 3
> should IOIRefID be 1 or 2 ?
>
> Thank you for any help.
>
> Olivier.
>
>
>

Do you think it is acceptable to accept IOIRefIDs <26> for updating that were previously rejected by your system?

21 years since the last post on this subject…

On one hand, it seems misleading. If you send a reject (say a 35=3 because the message is bad for example) and then they send a IOI with a ref of the IOI you couldn’t handle then it seems reasonable you won’t be able to handle the replace IOI. I’m not sure whether a 35=3 or 35=Q would be the right response in that scenario

On the other hand, IOIs are in practice sent a bit like market data (indeed if the price is market-based it might be sent at the same rate).

If the replace IOI replaces all the fields (or at least provides all the fields) you need to show the IOI then it’s sort of irrelevant what the old one had in it.

I think both approaches are acceptable and you’d want to engage both your upstream brokers and your client as to whether not showing an entire IOI chain because of missing the a single IOI (be it the first new or one in the middle) is the correct behavior.

@rmazour Not sure I fully understand the scenario. An IOIRefID(26) refers to an IOIID(23) of a previous IOI message. If the initial IOI message was rejected then the IOIID(23) in that message was never established at the receiving end and you cannot send another message that refers to the rejected identifier. The recipient simply does not know it, i.e. he will not respond with “previously rejected” but with “unknown ID”.

On what basis do you want to accept the update? I am assuming that IOITransType(28) = R is sent.

The recipient simply does not know it, i.e. he will not respond with “previously rejected” but with “unknown ID”.

How would you do this - 35=AJ seems like the way the spec implies you respond to IOIs but 694 doesn’t have anything relevant for “Don’t Know IOI”. A direct equivalent of 35=Q for IOIs doesn’t seem to exist.

The QuoteResponse(35=AJ) message only applies as response to a valid IOI. QuoteRespType(694) has no value such as “rejected” or “invalid”. The use case from @rmazour is the rejection of an IOI(35=6) followed by another IOI(35=6) message. The field usage description for IOIRefID(26) in the IOI(35=6) message says “Required for Cancel and Replace IOITransType messages”.

You do not need IOIRefID(26) if you only send IOIs with IOITransType(28)=N (New) with an implicit semantic that a new IOI for a given instrument and side simply overrides the previous one. If you send IOITransType(28)=R (Replace) then you must also send IOIRefID(26). However, if your first (new) IOI was rejected, you cannot send in a replacement and should simply send IOITransType(28)=N (New).