Use of tag 2405 as an indicator for SI liquidity source

general-qa

#1

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


#2

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


#3

@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.


#4

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


#5

@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.


#6

Thanks for your help. This makes a lot of sense.