Imported from previous forum
The latest drafts of the German High Frequency Trading Act include a clause about assigning identifiers to individual algorithms, and then disclosing those identifiers to exchanges.
Putting aside the discussion on “what do they mean by individual algorithms?”, I’m curious about the technical implications:
Buy-sides using algorithms would presumably have to send these identifiers to brokers in some manner. Does anyone have any thoughts on appropriate FIX tags for sending these identifiers?
With MiFID II looking like it might take a similar approach to algorithmic trading disclosure, I’m concerned that these identifiers will become a common requirement, causing significant fragmentation of broker interfaces if no standard tag exists.
The latest drafts of the German High Frequency Trading Act include a clause about assigning identifiers to individual algorithms, and then disclosing those identifiers to exchanges.
Putting aside the discussion on “what do they mean by individual algorithms?”, I’m curious about the technical implications:
Buy-sides using algorithms would presumably have to send these identifiers to brokers in some manner. Does anyone have any thoughts on appropriate FIX tags for sending these identifiers?
With MiFID II looking like it might take a similar approach to algorithmic trading disclosure, I’m concerned that these identifiers will become a common requirement, causing significant fragmentation of broker interfaces if no standard tag exists.
Note that when a buyside firm sends an algorithmic order to a broker (who executes the algorithm), they specify ‘which strategy’ (of the broker’s definition) to use, along with the relevant paremters. They also provide their ClOrdID.
The latest drafts of the German High Frequency Trading Act include a clause about assigning identifiers to individual algorithms, and then disclosing those identifiers to exchanges.
Putting aside the discussion on “what do they mean by individual algorithms?”, I’m curious about the technical implications:
Buy-sides using algorithms would presumably have to send these identifiers to brokers in some manner. Does anyone have any thoughts on appropriate FIX tags for sending these identifiers?
With MiFID II looking like it might take a similar approach to algorithmic trading disclosure, I’m concerned that these identifiers will become a common requirement, causing significant fragmentation of broker interfaces if no standard tag exists.
Note that when a buyside firm sends an algorithmic order to a broker (who executes the algorithm), they specify ‘which strategy’ (of the broker’s definition) to use, along with the relevant paremters. They also provide their ClOrdID.
A fair point. However, I’m considering algorithms being run at the buy-side before sending to a broker. I’m also considering flow between multiple brokers before sending to the exchange.
Perhaps a better example to illustrate my question would be:
- Broker “A” receives an large order.
- Broker “A” applies some VWAP algorithm, slicing up the order into child orders in the process.
- Broker “A” sends these child orders to Broker “B”.
- Broker “B” sends these orders directly to the exchange.
At around step 3, I would suspect that Broker “A” needs to send the algorithm ID to Broker “B” to comply with the regulation.
Perhaps a better example to illustrate my question would be:
- Broker “A” receives an large order.
- Broker “A” applies some VWAP algorithm, slicing up the order into child orders in the process.
- Broker “A” sends these child orders to Broker “B”.
- Broker “B” sends these orders directly to the exchange.
At around step 3, I would suspect that Broker “A” needs to send the algorithm ID to Broker “B” to comply with the regulation.
In addition to having a positive ID on the algo that is placing the order do you have to disclose the original entity placing it. For example in above, do you need to disclose from #1 the LEI of broker “A”'s customer?
As far as identifying the specific algo
Strategies element has two attributes
strategyIdentiferTag
versionIdentifierTag
The original idea behind those was to enable the executing broker to identify different versions of the same algo being requested (perhaps due to an older FIXatdl file remaining in use in the field.) If the executing broker received an order generated off a stale FIXatdl file they could use the above attributes to accommodate the prior version, or just reject it all together. They would then be alerted to go back an insure that client had the current FIXatdl file.
In your above example you could transfer the above attributes from “A” into each slice (single time slice orders) that are pumped out to “B”. “B” would then include those in its orders to the exchange. That gives a full audit trail.
In the above scenario there may be some conflict between confidentiality and regulation. Lets face it the very first slice of a potentially large series of subsequent slices carries some significant information. Especially when the specific algo is fully identified.
I’m not familiar with the new rules or what they are after. Do they just want to have a full audit track record that can pin down what happened, when, after the fact? If so perhaps strategyIdentiferTag & versionIdentifierTag (plus broker A’s identity, and broker A’s client identity) could all be encoded and carried all the way through.
Or, are the regulators trying to have some capability of throttling or circuit breaking selected algos from executing in real time (i.e. choking them in step 4 above). To allow that functionality and still keep it encrypted would take a fairly sophisticated regulator.
MIT (and Andrew Lo) have very good encryption techniques for many scenarios, however it would take a three way agreement (regulators, participants, independent standards organization like FIX) to make it all work well.
Regulators would also have to “step up” to the security needs commensurate with having in-house the ability to “see it all very clearly in real time”. Can they offer that level of security?
If regulators can manage their own (substantial!) security needs, the technology to keep it all encrypted outside of that seems pretty well established.
I’m not familiar with the new rules or what they are after. Do they just want to have a full audit track record that can pin down what happened, when, after the fact? If so perhaps strategyIdentiferTag & versionIdentifierTag (plus broker A’s identity, and broker A’s client identity) could all be encoded and carried all the way through.
Or, are the regulators trying to have some capability of throttling or circuit breaking selected algos from executing in real time (i.e. choking them in step 4 above). To allow that functionality and still keep it encrypted would take a fairly sophisticated regulator.
The regulation itself (in draft form) is available from the German Finance Ministry’s website here:
I’m not very fluent in German, but my own interpretation is that currently they want to monitor the amount of algorithms in use for trading (and how many orders they produce). To this end they specify an identifier that can be used to uniquely relate specific orders to a specific algorithm.
I believe the implication is that sell side institutions must be able to disclose information to a regulator about a given algorithm, but that information does not have to be encoded in the identifier. There is also some suggestion that exchanges will be able to request that algorithms using a particular identifier are “turned off”, so traders will need to be able to relate an identifier back to the algorithm on their system.
Note that although the term “algorithmic” is defined, there doesn’t seem to be a definition of what an “individual algorithm” is, and I wouldn’t like to speculate.
In the above scenario there may be some conflict between confidentiality and regulation. Lets face it the very first slice of a potentially large series of subsequent slices carries some significant information. Especially when the specific algo is fully identified.
I believe the regulators only want unique identifiers for algorithms, rather than a description in real time. The act allows them to use this identifier to seek a full description at a later date.
In addition to having a positive ID on the algo that is placing the order do you have to disclose the original entity placing it. For example in above, do you need to disclose from #1 the LEI of broker “A”'s customer?
I don’t believe this is covered specifically by the act. Only an ID for the algo is prescribed, though other pre-existing regulation or venue-specific rules might require that the broker’s client is named on the order.
As far as identifying the specific algo
Strategies element has two attributes
strategyIdentiferTag
versionIdentifierTagThe original idea behind those was to enable the executing broker to identify different versions of the same algo being requested (perhaps due to an older FIXatdl file remaining in use in the field.) If the executing broker received an order generated off a stale FIXatdl file they could use the above attributes to accommodate the prior version, or just reject it all together. They would then be alerted to go back an insure that client had the current FIXatdl file.
Perhaps I’ve posted in slightly the wrong forum. I was thinking more of “Algorithmic Trading” along the lines of vanilla FIX rather than FIXatdl; my concern relates more to identifying algorithms that created a given order rather than describing an algorithm to apply to a given order. Please advise me if there’s a more appropriate place to post this.
I guess I’m trying to ask if any suitable standard field in FIX already exists for this requirement, or whether there were any indications that a standard is currently being devised?
[regulators] specify an identifier that can be used to uniquely relate specific orders, to a specific algorithm. …Perhaps I’ve posted in slightly the wrong forum. I was thinking more of “Algorithmic Trading” along the lines of vanilla FIX rather than FIXatdl; my concern relates more to identifying algorithms that created a given order rather than describing an algorithm to apply to a given order. Please advise me if there’s a more appropriate place to post this.
I wish it was simpler, but this requirement will likely cut across a few forum/FIX areas.
You are correct that the Algorithmic Trading Working Group (developers and maintainers of the FIXatdl) does not work whatsoever directly on plain vanilla FIX tags, FIX allowed data types, etc. FIXatdl itself just “rides on top” of the standard FIX wire protocol and helps widely deploy algos.
The Algo Work Group would be the logical one to help create a globally unique algo identifier system, should one be required for regulators.
Thinking out loud and on a preliminary basis, perhaps using a DOI (Digital object identifier - Wikipedia), or similar structure to pin down the actual algo object code, and version, would be best. However the industry need for anonymity, while the order is live in the market, is clearly not part of the current DOI system.
The “responsibility” for an algo’s orders released into the market may involve multiple parties.
- The original coder/manufacturer/maintainer of the algo strategy source code
- A user or licensee who runs that algo’s object code on their own live, production level algo execution infrastructure
- A fund, or fund complex manager that’s an agent user of the algo’s trading strategy on behalf of themselves, or one or more client accounts
- A broker/market maker using their own or others algos for their own prop trading
- After the orders leave the algo execution engine, the exchange/marketplace that acts on those orders
- The ultimate owner of the trades emanating from the algo’s executions
When tracing through the question of “who is responsible for issuing these specific orders!!!” the answer may not be as simple as first imagined. Multiple participants in the chain may need to be referenced. Traditional FIX “Client Order ID” may be wholly insufficient for regulators here. LEIs of all parts of the chain may ultimately be required?
Additionally, a large order (a single unit) may set off more than one algo. For instance the large order is sliced by algo #1, operating internally at a fund, that breaks down that trade automatically and creates 10 related child orders heading out to 10 different executing brokers. Each of THOSE brokers may then deploy their own algos from that point forward, prior to end level orders being issued into the various execution destinations. Which algo ID is then responsible for each specific execution? Orders arriving at the execution venues may, at one level, appear to be independent (after all, that was the intention of the slicing to begin with) however they are all related to that top most, single, parent order. Do all the algos in the chain need to be identified at the point where orders actually are to be executed?
The Exchanges and Markets Committee would be the logical FIX unit to address any real time circuit breaking and/or choking requirements that are to be applied just prior to execution. The member brokers offering DMA might also share responsibilities supplying the real time algo controls. Ultimate trade execution reporting by the exchange/marketplace would also likely be impacted by a requirement to disclose. More disclosure might be required subsequent to the individual sliced executions being ALL complete. This implies posting execution data “to the tape” that is not real time (i.e. only posted to the tape after all the slices are complete or canceled). That delayed reporting may or may not be acceptable to regulators. Algos sometimes operate past one day, will that be an issue?
In terms of the base FIX protocol, coming up with a standardized tag, that should not pose any significant challenge, and that would be done thought the standardized FIX Tag=value agreement process and released in a service pack.
It would be ideal to look at the entire “algo ID” requirement (and likely similar expected requirements for other regulators) to get the entire structure outlined and roughed in vs. constantly issuing (and redefining and reissuing) individual FIX tags. Global regulators are now getting more “interconnected” themselves so a solid regulatory requirement in one area is likely to propagate quickly into others.
Would be really great to have an English translation of that German requirement and the timeframes those regulators expect implementation.
Would be really great to have an English translation of that German requirement and the timeframes those regulators expect implementation.
Most of the concerns you’re raising are concerns I share too, but for this last point I can at least help shed some light:
In terms of an English translation, although not the full text, BaFin provide an English summary of the act here:
http://www.bafin.de/SharedDocs/Veroeffentlichungen/EN/Fachartikel/fa_bj_2012_11_hochfrequenzhandel_en.html
Unfortunately it doesn’t give much detail, but it’s a reasonable starting point.
In terms of timeframes, my current understanding is that the act is scheduled to pass into law in July 2013, and become enforceable around October 2013. Please consider that this is only my understanding, and clearly these dates are subject to change.