Specify PartyRole(452)=3(Client ID) twice in NoPartyIDs(453)

1

Specify PartyRole(452)= 3(Client ID) twice in NoPartyIDs(453)

In the Quote (S), it can specify bid side and ask side of the quote and it can also input the NoPartyIDs(453). We want the counterparty to specify two Client ID info associated with bid and ask sides respectively. That is, we want to specify a PartyRole(452)=3(Client ID) associated with the bid side; In addition, we also want to specify another PartyRole(452)=3(Client ID) associated with the sell side.

Question A
Can we specify two PartyRole(452)= 3(Client ID) in the NoPartyIDs(453) repeating group, e.g. 453=2^448=ID_123^447=D^452=3^448=ID_456^447=D^452=3^ or 453=3^448=LocationID^447=D^452=75^448=ID_123^447=D^452=3^448=ID_456^447=D^452=3^? Is it FIX compliant?

Question B
Assume Question A is valid. Can we use the two repeating items of NoPartyIDs(453) and take that the first repeating item of 452=3 is always for the bid side quote while the second one of 452=3 is always for sell side quote? For example, given 453=2^448=ID_123^447=D^452=3^448=ID_456^447=D^452=3^, since “448=ID_123” is the first one, we treat this is for the buy side; while the 448=ID_456 is always for sell side.

Will this violate FIX protocol? Don’t know if the FIX engine will have problem to maintain the ordering of the repeating item(i.e. 448=ID_123 is for buy side and FIX engine must place it first).

Question C
If the implementation in Question B is a concern, how about we specify, like 453=2^448=S:ID_333^447=D^452=3^448=B:ID_222^447=D^452=3^. Then, when we see 448=S:ID_333, we interpret the “S:ID_333” and based on the “S:” we know it is for sell side; while the “448=B:ID_222” is for bid side. Can we do this?

Any other suggestion?

Thanks a lot.

2

What is the context in which you are using the Quote(35=S) message, i.e. who is sending and who is receiving it? The quote issuer would normally be a single party that quotes single- or double-sided. If you want to broadcast the quote to multiple parties, the FIX market data messages may be more suitable. They have a repeating group that includes a Party component.

If it must be the Quote(35=S) message, then the fairly recent Extension Pack EP254 for SFTR probably solves the issue as well:

NoPartyIDs(453) = 2

 > PartyID(448)=[Client ID of bid side]
 > PartyIDSource(447)=D
 > PartyRole(452)= 3(Client ID)
 > NoPartySubIDs(802)=1
 >> PartySubID(523)="BID"
 >> PartySubIDType(802)=86 (Party side)

 > PartyID(448)=[Client ID of offer side]
 > PartyIDSource(447)=D
 > PartyRole(452)= 3(Client ID)
 > NoPartySubIDs(802)=1
 >> PartySubID(523)="OFFER"
 >> PartySubIDType(802)=86 (Party side)

Yes, you can have multiple entries with the same PartyRole(452). The values of PartySubID(523) are up to you. Requiring special parsing of PartyID(448) by using a prefix such as “S:” is not a good idea.

How to model FIX order messages to withdraw cash from a settlement account
3

Thanks hanno.klein for your valuable input.

4

Sorry for hijacking this thread. I have a related question originating from here: https://github.com/quickfix-j/quickfixj/discussions/341#discussioncomment-805176
Is there a place in the FIX spec somewhere that clarifies whether e.g. duplicate PartySubIDs are allowed? I didn’t find anything in the online tagvalue spec.
I think there might be situations where it is acceptable (e.g. multiple PartySubIDTypes of 8/EmailAddress) and some where it isn’t.

Thanks in advance and best regards,
Chris.

5

No, the spec allows to have multiple entries for PartyRole or PartySubIDType of the same type as long as the semantics are clear. If there are multiple emails and a primary email address does not need to be specified, then it makes sense to have multiple entries of PartySubIDType(803)=8. It probably makes less sense to have PartySubIDType(803)=1 (Firm) more than once.

FIX intentionally tries to be as generic as possible and leaves it up to the Rules of Engagement to add text for a given implementation. There it might say “Multiple entries of PartySubIDType(803)=8 are permitted and the first entry will be taken as primary email address.” Or it might say “Multiple entries of PartySubIDType(803)=8 are not permitted.”

The spec is explicit where we feel it is necessary to enable/disable specific usages. Otherwise it is up to the (bilateral) agreement between counterparts.

1 Like