Could you please help define the values and highlight the differences between these values from PartyRole (452): values 3 (Client ID) and 13 (Order Origination Firm)?
Please refer to second tab (Client IDs) in the spreadsheet at https://www.fixtrading.org/packages/mapping-tables-mifid-fields-to-fix-fields/. Hopefully this answers your question. FIX has chosen these roles by convention in the context of ESMA. They may be used differently in a different (regulatory) environment. The client ID role typically denotes a simple and direct client relationship. The order origination role can be the same or used in a chain to denote the initiator of an order in a business sense.
Thank you!
Unfortunately there is still confusion around which FIX tag to use for client LEI as we continue to receive conflicting requirements across brokers’ FIX specs, some indicating to use 452=13 (or 20013) while others have already coded to use 452=3 (or 20003). My assumption (following the revised guidelines FTC, also attached here) is that the standard buy-side workflow where they submit an order to a broker for execution would use 452=13 to indicate Client ID.
The 2nd use case (submitting an order to a broker on behalf of another firm - i.e. “client’s client”) which is less common apparently sends both 452 = 13 (their own LEI or “W” in the attached example) and 452 = 3 (client’s client LEI). However, the FIX specs I’ve seen only include either 13 or 3 for client LEI, but not both. Further, the “MiFID II/R Implementation Guidelines for Inter-Firm Data Communication for Transaction Reporting” only include 452 = 13 for client LEI which seems to imply that submitting a client’s client LEI is NOT a requirement (in which case, including it in the attached document may be contributing to the ongoing confusion around Client IDs). It would be helpful to clarify when a client’s client LEI should be communicated to brokers, as many OMS/EMS vendors have a subset of clients who receive and submit orders for execution on behalf of a buy-side firm.
Please check https://www.fixtrading.org/packages/mifid-iimifir-implementation-guidelines-for-inter-firm-data-communication-for-transaction-reporting/ which is currently version 1.3 dated June 22, 2017. Under the LEI section is says for Client’s LEI: “PartyRole(452) = 3 (Client ID) or 13 (Order origination firm)” and for user-defined fields “20003 PartyIDClientID or 20013 PartyIDOrderOriginationFirm”. The scenario diagram then shows the different use cases, one of which has both 3 and 13 (broker’s client to broker). That is the only place where both come together due to the need for the broker’s client to identify (towards the broker) himself as well as the client for whom he is sending the order. It is the convention chosen for this use case.
Would it be less confusing if it said “and/or” instead of only “or” in the table above the diagram? Or is it an issue with a prior version of the document above which apparently only had 13?
Thanks for the response here, much appreciated. From your explanation, the common workflow is to use 20003/452 = 3, not vice versa. This diagram seems overly complicated as the most common workflow (broker’s client to broker) shows “W” being sent using 20013 which the broker in turn uses for downstream reporting (vs. “C”). Perhaps if there were separate diagrams for the common workflow (broker client to broker) followed by the current diagram showing the less common “client’s client to broker’s client to broker” workflow, that may help to avoid confusion. Multiple brokers continue to use 20013/452=13 in their FIX specs for client LEI, and to be honest the revised diagram (following past guidelines where 20013 was recommended) have indeed confused me as well. Again, appreciate the feedback here as it is very helpful.
I am not sure whether there is a misunderstanding here and will try to paraphrase the flows. You talk about downstream reporting towards “C” which the diagram does not depict. It only shows the flow(s) towards the venue where the client’s client as well as the client both use 452=13 to identify themselves as the order orignating firm. The broker then does the same towards the venue using 452=1 in order to express the fact that he is executing an order on the venue.
The broker’s client (W) can identify his own client © in addition to himself towards the broker (J) by using 452=3. The broker (J) can identify his own client (W) in addition to himself towards the venue by using 452=3.
Long story short, use 452 = 13 to send LEI for the most common workflow (buy side firm to broker) as I originally thought.
The client’s client is sent via 452 = 3. I mentioned the broker sends “W” for downstream reporting (as opposed to “C”) so quite not sure where your comment is coming from but it seems we’re on the same page here.
Our spec is consistent with FTC guidelines, however I received 2 updated broker specs today; one indicating to use 452 = 13 and the other indicating to use 452 = 3, so unfortunately the confusion around client LEI FIX tag remains a problem for some sell-side firms. One spec also indicates using 452 = 3 but 20013 for the equivalent flat tag which doesn’t make sense, hopefully all firms will align with FTC guidelines before January!
Please point brokers to the guidelines as published by FIX. I do not blame them for not being able to keep up with the multitude of changes required for MiFID II. In this case, “FIX” refers to a group of volunteer FIX member firms who make up the regulatory subgroups for which they have to find time on top of their day jobs. This means that there were also changes/corrections over time that may not have been caught by every broker implementing MiFID II.
Thanks for pointing out the inconsistencies in the specs out there. This forum on the new FIX website hopefully helps to slowly reduce the confusion.