We’ve recently starting getting requests from clients to use tag 2405 to indicate which internal desk of ours executed flow under our SI MIC code. Since going live with MIFID II many brokers have a single MIC to indicate their SI but the SI liquidity could come from multiple internal desks that are filling the order as an SI.
Tag 2405 was added to the FIX protocol as part of MIFID II and is defined as ExecMethod with the values 0 – Undefined, 1 – Manual, 2 – Automated, and 3 – Voice brokered.
Clients are indicating that brokers are using the 2405 values 0,1,2,and 3 to represent internal SI liquidity sources so that whilst 2405=2 might be defined as ExecMethod=Automated it’s being used instead to communicate that it was an SI risk unwind fill. I spoke to some vendors about this and whilst they hadn’t had client requests to enable 2405 as an SI liquidity indicator they did support the parameter being MIFID II related and so were storing the value which could be used to indicate SI liquidity if that’s how the buyside was interpreting it.
Has the FIX Protocol had any discussions on how to represent different SI liquidity sources which share the same MIC code?
The concern of using 2405 is that it’s pre-assigned to ExecMethod so some buysides might be using the field to indicate ExecMethod and would then incorrectly interpret it if it was also used to show SI Liquidity sources. Also 2405 only has 4 possible values and its possible there could be more sources of SI liquidity within a broker.
Has there been any discussion on this topic?
Thanks,
James
Hello James,
why you do not use the MIC/Operating MIC coding to provide to your clients this information?
Look at what have done EXANE DERIVATIVES for example.
They have opened an Operating MIC (EXSY) and several specific MIC, each representing a specific Desk.
Alessandro
EXSB EXSY S EXANE DERIVATIVES - SYSTEMATIC INTERNALISER CORPORATE BONDS
EXSD EXSY S EXANE DERIVATIVES - SYSTEMATIC INTERNALISER OTC DERIVATIVES
EXSE EXSE O EXANE BNP PARIBAS - SYSTEMATIC INTERNALISER
EXSF EXSY S EXANE DERIVATIVES - SYSTEMATIC INTERNALISER OTHER BONDS
EXSH EXSY S EXANE DERIVATIVES - SYSTEMATIC INTERNALISER SHARES
EXSP EXSY S EXANE DERIVATIVES - SYSTEMATIC INTERNALISER STRUCTURED PRODUCTS
EXSY EXSY O EXANE DERIVATIVES - SYSTEMATIC INTERNALISER
EXYY EXSY S EXANE DERIVATIVES - SYSTEMATIC INTERNALISER CONVERTIBLES
@jamespurnell44 ExecMethod(2405) is certainly not the right choice to identify a desk responsible for execution. It covers a method of execution regardless of the actor behind it. The Parties component is used to identify actors within a transaction. There is even an explicit PartyRole(452)=76 (DeskID) to identify a specific desk.
Executions can be flagged as SI-executions with MatchType(574)=9 (SI). On the entry side, an order can be flagged as an order from an SI with OrderAttributeType(2594)=5 (SI order).
A MIC is only a MIC, i.e. it does not convey the fact that an SI is behind an execution, even if you register a MIC per SI asset class as described by @alessandro.caffarr.
Thanks. This makes sense.
So would you be setting either (repeating group):
Party Role 452=76 (Desk ID)
Party ID Source 447=C (General Identifier) - I chose C as couldn't see anything else in the list that made sense
Party ID 448 = <The Actual Desk ID>
Or for clients on FIX 4.2 that need a flat tag:
20076=<The Actual Desk ID>
Where the desk ID is just the name you as a firm calls that desk entity. E.g. RiskUnwind
Thanks,
James
@jamespurnell44 almost, PartyIDSource(447)=C stands for “Generally accepted market participant identifier”. You only mentioned the symbol for the valid value which does not reflect the true semantics. The term “accepted” is key here, i.e. it is not about names chosen by an individual firm. The names must be in general use across independent entities, e.g. mnemonics issued by NASD for market makers. It is not as an ISO standard, e.g. G stands for MIC which is ISO10383, but it is a de facto standard established in the industry (does not have to be global).
The right value for you is D=Proprietary/custom code (Custom ID schema used between counterparties, trading platforms and repositories). This means that the IDs are issued and maintained by the (trading/clearing) firm.
Tag 20076 works and is from the range of user-defined tags (20,000-39,999). This convention came up during MiFID II for FIX 4.2 users who are unable to support repeating groups, i.e. Parties. The Rules of Engagament (your interface specification) should state the domain (PartyIDSource) used for 20076, e.g. “D” as it is not part of the wire format. The standard approach to use the Parties component is recommended.
Note that there is no guarantee that one your counterparties has used this tag number for something else. There are a few tags that FIX has officially issued in a regulatory context for such users (see 8,000-8,499 range on https://www.fixtrading.org/standards/user-defined-fields/). These are safe to use if they apply.
Thanks for your help. This makes a lot of sense.
Hi Hanno,
Over the past few months we’ve consistently got more and more requests from clients for an SI Liquidity Indicator. I’d tried to get a discussion going with the FIX protocol on the subject but unfortunately we didn’t get much traction.
We had for a couple of clients implemented the 2405 tag mentioned in this thread but given it could cause problems with the vast majority of clients and vendors given it’s used as ExecMethod we are going to implement a method in the same approach you mention above.
I’m going to run this method by the vendor community and just wanted to confirm with you my logic is sound. As it uses the same concept you mention of defining custom codes in the 452/447/448 repeating group I believe the method should already be FIX compliant as we are in essence just defining another Party ID on executions. I picked 452=35 as this represents Liquidity Provider which is what we are defining it being an SI Liquidity Provider. The SI MIC will be in tag 30 on all executions:
FIX 4.4:
452=35 (Liquidity Provider)
447=D (Proprietary Code)
448=
FIX 4.2:
20035=
20035 being picked as it’s the 20,000 range tag that matches 452.
The above tags would then go out on any executions where our SI filled the order. In tag 448 or 20035 we would have 7 character codes that represent our different SI Liquidity sources. We plan to have 5 categories but given the setup this could easily expand to any number of categories - We just need to ensure clients/vendors know the codes.
Thanks for your help,
James
Hi James,
I am afraid that this is not FIX compliant. The Parties component only identifies a party or an account with tag 448, it does not provide further detail about the party. With PartyRole(452)=35 you would simply convey the fact that the ID contained in PartyID(448) represents a liquidity provide. Additional information about the party (not about an execution of that party) can be provided with the PtysSubGrp component. Also, PartyIDSource(447)=D does not mean you are free to put anything in PartyID(448). Semantically, it must still be an identifier of the party or account.
The FIX compliant approach to convey the source of liquidity of an execution carried out by an SI is as follows:
- Identify the execution as being from an SI, either with OrderAttributeType(2594) = 5 (SI order) or with MatchType(574) = 9 (SI)
- You could alternatively add a party with PartyRole(452) = 63 (SI) and define in your rules of engagement that presence of this party role identifies an execution from an SI
- Once you have established that the execution is from an SI, the fields ExecMethod(2405) and LastLiquidityIndicator(851) apply to the SI. As ExecMethod is not about a source of liquidity, it is LastLiquidityIndicator which should contain your additional values.
LastLiquidityIndicator(851) does not permit user defined values. Can you post the seven different SI liquidity sources here to better understand the business semantics? It would require a FIX Gap Analysis through one of the FIX working groups to get them added to the standard. They should also be generic enough to be used by others, i.e. the working group could collect sources from others as well.
Maybe I should have asked first whether you use LastLiquidityIndicator(851) at all when an SI fills the order and what the semantics are. It is a key field and relevant for regulatory reporting, hence the current FIX GTC view that it should not be open to user-defined values.
Regards,
Hanno.
Hi Hanno,
Thanks for the quick response.
An example FIX message would be as follows:
|35=8|49=SENDER|56=TARGET|34=536|37=ORDERID|11=115957792|17=TRANID|20=0|150=1|39=1|63=0|55=WPP|65=LN|48=B8KF9B4|22=2|54=1|38=88|40=2|44=10.4286|15=GBP|59=0|47=A|32=41|31=9.96|30=GSSI|29=4|151=47|14=41|6=9|120=GBP|21=1|851=2|574=9|2524=6| 453=3 |447=N|448=|452=1|447=G|448=GSSI|452=73|447=D|448=GSMKTM|452=35|
Where we are saying:
The fill came from our SI - Tag 30
The last liquidity indicator is 2 (took liquidity) - As we are providing liquidity
We set 574=9 to say it was an SI fill
Then in the repeating groups which we are sending 3 (453=3)
We define our Broker LEI first with 447=N, 448=The LEI, and 452=1 - The executing firm
We then define our Transaction Reporting information where 452=73 (exeutiing venue), stating it’s a MIC code (447=G).
The above is all as per our FIX rules of engagement
Then the new bit - which I’d set up in the same way you originally suggested (You just used Desk ID), which was to specify a Proprietary custom code (447=D) and as we want to specify what we call an SI Liquidity Provider we are using 452=35 (liquidity provider). We then put our custom code in 448. This particular one being GSMKTM which would be our Market Making SI.
Generally banks have various flavours of SI liquidity, Market Making, Deriv Hedging etc. Clients want to know when they receive an SI fill what type of liquidity it is - hence the use of Liquidity Provider and a custom code - because these are our codes (other banks may have something different). We’d add these codes to our rules of engagement - Given they are custom we would need to certify them with clients/vendors.
Hi James,
thanks to your example think I understand it better now and remember the DeskID from the beginning of the thread. The value “GSMMKTM” certainly sounds like a party (desk or liquidity provider). It sounds more like a terminology issue where FIX uses liquidity indicator only in the sense of tag 851. In your case it is rather a source of liquidity and the values are understandably custom to your company. It is not how the liquidity was created but where it came from.
That said, I no longer see an issue with what you are proposing. If you will party role 35 (liquidity provider) is the most generic role with more specific roles also being available, e.g. 63 (SI), 66 (Market Maker), or 115 (Hedging party).
A comment on your statement “The fill came from our SI - Tag 30”. LastMkt(30) requires a MIC value (ISO 10383) but the value would require a lookup to find out it is an SI. Your usage of MatchType(574)=9 avoids the lookup.
A question on your statement “The last liquidity indicator is 2 (took liquidity) - As we are providing liquidity”. Who is “we” in this case? Providing liquidity would be 851=1 (add liquidity). What am I missing here?
Hi Hanno,
Thanks for the reply. Yes what we are defining is a source of liquidity. The codes for that source being custom codes for each source. They are all SI liquidity but are different categories (sources) of SI liquidity that our clients want us to mark on SI fills.
I support party role 63 would also work with it being SI - We chose 35 as we are being a liquidity provider and our clients asked us to provide them an SI Liquidity provider FIX tag. So 35 makes sense. We would provide the mappings to our clients as part of our FIX rules of engagement.
Regarding 851, we are providing the liquidity so when the clients sends the order they took the liquidity from us. So this would be 851=2. The client isn’t adding liquidity to our market making desk, they are taking the liquidity we are providing. Does that make sense?
It sounds like our methodology makes sense. We are providing custom codes to say what type of liquidity we are providing - it all just happens to be liquidity from our SI which we need to categorise.
I wanted to avoid using 2405 as we don’t want to use a FIX tag for something it was never purposed for as this could cause issues with clients using it as an ExecMethod.
I’ll reach out to clients/vendors regarding our usage or the repeating group (452=35 Liquidity Provider,
447=D Proprietary Code,448=customcodes) or 20035 and confirm they can support it.
Thanks for your help.
James
1 Like
Thanks, @jamespurnell44. Makes sense, incoming order from client is aggressive, i.e. does not rest on your book and hence takes liquidity.
Thanks for your help. Greatly appreciated.
James
1 Like