PUBLIC COMMENT PERIOD - Parties Reference Data

, ,
1

Imported from previous forum

2

The Global Technical Committee has reviewed and preliminary approved the Parties Reference Data Proposal. The document now enters a 15 day public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.

Please post feedback, comments, and questions as replies to this discussion thread.

A link to the proposal can be found at
http://www.fixprotocol.org/documents/4320/FIX%20Gap%20Analysis%20Parties%20Ref%20Data%20Rev%200.11.doc

The public comment period ends on February 6, 2009.

3

Two questions on naming conventions:

Message PartyDetailsListReport provides a list of parties with detailed information for each party and its relationships . Fragmentation is supported by a field called TotNoPartyList. The number of parties described in is defined by the field NoPartyList.

I find the usage of the term “List” confusing as the message does not provide a number of party lists but simply a number of parties.

First question is if we can omit the term “List” as follows:
TotNoPartyList --> TotNoParties
-->
NoPartyList --> NoParties

Second question is related to the message name which are quite long. Similar messages for securities do not have the term “Detail” in their name, i.e. SecurityListRequest and SecurityList (does not even have “Report”). I find it obvious that a message contains details about the entity it describes. On the other hand, the term “List” is important here as it can be more than a single party per message.

Second question is if we can omit the term “Detail” as follows:
PartyDetailsListRequest --> PartyListRequest
PartyDetailsListReport --> PartyListReport

Regards,
Hanno.

4

[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
Thanks for the comments.

I don’t have all that much of an opinion on the first question.

Regarding the second, though:

Second question is related to the message name which are quite long.
Similar messages for securities do not have the term “Detail” in their
name, i.e. SecurityListRequest and SecurityList (does not even have
“Report”). I find it obvious that a message contains details about the
entity it describes. On the other hand, the term “List” is important
here as it can be more than a single party per message.

Second question is if we can omit the term “Detail” as follows:
PartyDetailsListRequest → PartyListRequest PartyDetailsListReport →
PartyListReport

We already have a “Parties” component, which is a list of parties. That is just a bare-bones list. No context IDs, alt IDs, or other info like risk limits. We created a PartyDetail block that provides such detailed information about the party. Since what we’re exchanging is this detailed information, and not merely a simple list of parties, we chose the names PartyDetailsListRequest and PartyDetailsListReport.

5

[ original email was from Zoltan Feledy - zoltan_feledy@ssga.com ]
There is a need for a standard way to convey counterparty restrictions to a third party over FIX and the PartyID block seems like the solution. There are 4 types of restrictions: restricted/directed execution, and restricted/directed settlement.

The first 2 of the above can be accomodated using…
452=56 -> Acceptable Counterparty
452=57 -> Unacceptable Counterparty

A gap however exists for the settlement restrictions.
Examples:
I can execute with BrokerA but it has to be given up for settlement. (restricted)
I can execute with anyone but it has to be settled through BrokerA. (directed)

  • Example to restrict 4 destinations would look like this:
    …453=4|452=56|447=D|448=Broker1|452=56|447=D|448=Broker2|452=56|447=D|448=Broker3|452=56|447=D|448=Broker4…
  • Example to direct to 4 destinations would look like this:
    …453=4|452=57|447=D|448=Broker1|452=57|447=D|448=Broker2|452=57|447=D|448=Broker3|452=57|447=D|448=Broker4…
    -Not having this block on an order would indicate that there are no restrictions.

Replacing the PartyRole (452) values would allow us to convey restricted and directed settlement in a similar fashion thereby providing a complete solution to the stated problem. This would require the addition of the following 2 enumerations to PartyRole (452):
452= -> Unacceptable Settling Party
452= -> Acceptable Settling Party

Since we are expanding the enumerations as part of this expansion I thought that this would be a worthy addition.

Cheers,
Zoltan

6

[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
> There is a need for a standard way to convey counterparty restrictions

to a third party over FIX and the PartyID block seems like the solution.

Thanks for your input.

I envision the Parties Reference Data message suite as being the building blocks upon which one can construct a lot of things, including a very robust entitlement system. This is the ideal case, though; we don’t have time to model a full entitlement system for inclusion in FIX 5.0 SP2. I hope that building such an entitlement framework can be taken up by one or more Committees or Working Groups in the near future.

In the mean time, the two example PartyRole values you mention do allow for some rudimentary access control. While I don’t think continuing to expand PartyRole is the best long-term solution, I do recognize your immediate business need to define acceptable and unacceptable settling parties, and I do support your proposed enhancement.

7

I believe this can also be modeled with the existing Parties block until entitlements are available within the parties reference data. Acceptable and unacceptable counterparty roles are the basis which can be further qualified with the component which allows user defined values above 4000.

I do not think that one of the standard values captures what you need but you could define PartySubIDType = 4000 = “Transaction” with PartySubID = “Settlement”. This would express an (un)acceptable counterparty for a settlement transaction.

I would prefer that to an extension of the party roles which are already numerous (>80). I am sure there are more use cases out there where someone would want to express “(un)acceptable X counterparty” with X being IOI, quoting, trading, clearing, settlement et.al. It would also represent only a temporary solution until entitlements are modeled.

Regards,
Hanno.

There is a need for a standard way to convey counterparty restrictions
to a third party over FIX and the PartyID block seems like the solution.
There are 4 types of restrictions: restricted/directed execution, and
restricted/directed settlement.

The first 2 of the above can be accomodated using… 452=56 →
Acceptable Counterparty 452=57 → Unacceptable Counterparty

A gap however exists for the settlement restrictions. Examples: I can
execute with BrokerA but it has to be given up for settlement.
(restricted) I can execute with anyone but it has to be settled through
BrokerA. (directed)

  • Example to restrict 4 destinations would look like this: …453=4|452-
    =56|447=D|448=Broker1|452=56|447=D|448=Broker2|452=56|447=D|448=Broke-
    r3|452=56|447=D|448=Broker4…
  • Example to direct to 4 destinations would look like this: …453=4|45-
    2=57|447=D|448=Broker1|452=57|447=D|448=Broker2|452=57|447=D|448=Brok-
    er3|452=57|447=D|448=Broker4… -Not having this block on an order
    would indicate that there are no restrictions.

Replacing the PartyRole (452) values would allow us to convey restricted
and directed settlement in a similar fashion thereby providing a
complete solution to the stated problem. This would require the addition
of the following 2 enumerations to PartyRole (452): 452= →
Unacceptable Settling Party 452= → Acceptable Settling Party

Since we are expanding the enumerations as part of this expansion I
thought that this would be a worthy addition.

Cheers, Zoltan