Imported from previous forum
[ original email was from John Harris - john.harris@bondmart.com ]
Request for Comment
A useful complement of the new protocol would be a Central Instrument Registry to be maintained by FPL or another entity.
The Registry would assign to each instrument an identifier that would serve to identify objects of trade. This identifier would point to an instrument definition which could itself contain multiple, alternative identifiers. Appended to the definition could be legal documentation such as official statements, standard forms of agreement (e.g., for financing transactions and OTC derivatives), and the like. New protocol messages would reference only this identifier.
All or parts of the instrument definition could be encrypted in order to protect information that is sensitive from a unilateral or bilateral perspective. Thus, any number of firms could append, but mask, their proprietary or internal identifiers. Or, instruments represented by bilateral or multilateral contracts could be encrypted altogether.
Presumably, for the sake of processing efficiency, the Registry’s identifier would be an integer (though computer scientists may have a better idea in that regard).
This facility would relieve new protocol messages of the need to specify an identifier source or multiple identifiers and sources.
If necessary, either a flag or namespace could be used to denote encrypted definitions.
Presumably the instrument definitions (or templates) would themselves have unique identifiers to assist in their invocation for specific instruments.
A challenge would be to avoid duplication. At least in theory, market participants could register the same instrument multiple times. While aggravating, this would not obviate the utility of the central registry. So long as participants agree on the instrument they are trading, the duplication will not cause trade breaks. And, we already have duplication without a central registry, so instances of duplication in a central registry would be no more detrimental than the present arrangement.
Any market participant would be able to download machine-readable forms of each instrument, except for encrypted data or information flagged as view only.
In order for this scheme to be as effective as possible, it would be complemented by a Central Entity Registry. I will post a separate Request for Comment on such a facility at a later date.
I recognize the challenges of creating and administering a Central Instrument Registry and that some may deem such a scheme to be out of scope. I respectfully submit, however, that such a facility would foster the most efficient and error-free trade messaging and deserves consideration in conjunction with new-protocol-development efforts.
Registrants would pay fees to FPL (or other registrar) to defray the operating expense.
Comments appreciated.
We need to be aware of the fact that there are other “open” initiatives that try to solve the same problem, e.g. http://bsym.bloomberg.com/sym/. What is the incentive to support the service offered by FPL compared to other offerings?
If most of the FIX users were to also become FPL members, additional fees would not be needed to operate such a service. Otherwise, initial funding of such an initiative is likely to be a stumbling block. The problem of global security identifiers is not primarily about performance but about automated processing and manual effort. Hence I would not tackle it within the scope of the HFT Working Group.
[ original email was from John Harris - john.harris@bondmart.com ]
Thank you for your comment, Hanno.
I was pleased to learn of Bloomberg’s Open Symbology Initiative, but find it deficient for the purpose at hand in multiple respects. Out of respect for what is a commendable effort, I won’t enumerate here what I see as the defects but am happy to share them with you off-line.
I am not aware of any other such initiatives, but would applaud them. I proposed an initiative along these lines several years back in the journal FIXGlobal and addressed the economics of it:
http://fixglobal.com/back_issues/Q1/GLOBAL/Fundamental%20messages.pdf
The incentive to support the FPL service is that it would actually solve the problem of unique and comprehensive instrument identification and description - again, I am aware of no other solution - be open and free of charge to most users, and reside in a trusted, non-commercial, collaborative, standards body.
The registration fees would easily defray the operating cost. I do not believe it is realistic to expect any but a tiny fraction of users of such information to become FPL members (millions of people use HTML without joining W3C).
I respectfully disagree on performance. First, if we are truly building a protocol that is as useful as possible for so-called high-frequency trading, there are no spare bits or bytes. Second, we have to consider all of the inputs, which include specification complexity, rules of engagement negotiation, and code development, testing, and maintenance. Finally, that the existing protocol has a component block for alternate instrument identifiers suggests room for improvement.
All that said, and as noted in my original, I agree that this effort MAY be out of scope. Still, I hope it will be considered as being within scope.
We need to be aware of the fact that there are other “open” initiatives that try to solve the same problem, e.g. http://bsym.bloomberg.com/sym/. What is the incentive to support the service offered by FPL compared to other offerings?
If most of the FIX users were to also become FPL members, additional fees would not be needed to operate such a service. Otherwise, initial funding of such an initiative is likely to be a stumbling block. The problem of global security identifiers is not primarily about performance but about automated processing and manual effort. Hence I would not tackle it within the scope of the HFT Working Group.
I am in agreement with you that synthetic security IDs are good for performance. My statement was that the call for global IDs is made by people who have bigger problems than performance, i.e. the problem of uniquely identifying a tradable entity in the first place. Venues have moved to solve the performance problem by introducing their own synthetic IDs which are obviously only useful when trading on this one venue. A single synthetic ID is useful when trading on multiple venues and I agree again that an organization like FPL is well positioned in general to be an issuer of such a global ID. FPL has done so with IDs for marketplaces which have now become obsolete with ISO MIC values.
I am less optimistic about the chances for FPL to provide such a service on the instrument level as this involves a number of very non-technical issues, e.g. commercial and political issues.
There are also technical issues, e.g. in the derivative space where it is necessary that matching engines can issue such IDs on the fly in real time. Another problem is that you need to distinguish tradable entities from (fungible) clearable entities. This is about stocks that are traded on the same venue with different matching algorithms (FIFO, pro-rata) and have two IDs fro trading but just one for clearing. Class A and class B shares are another example. Granularity of identifiers will be chosen differently depending on where you are in the value chain from pre-trade to settlement. Alternate security IDs are not a bad thing if these fields are limited to reference data messages.
My personal view is that the natural excitement of “defining a new protocol” as part of this working group has led to far too many things people would like to fix about FIX :-). Each and every one of these problems is worth solving but we will not solve anything with a scope as broad as it currently is. As I said, this is my personal view and I would love to be proven wrong.
Regards,
Hanno.
Thank you for your comment, Hanno.
I was pleased to learn of Bloomberg’s Open Symbology Initiative, but find it deficient for the purpose at hand in multiple respects. Out of respect for what is a commendable effort, I won’t enumerate here what I see as the defects but am happy to share them with you off-line.
I am not aware of any other such initiatives, but would applaud them. I proposed an initiative along these lines several years back in the journal FIXGlobal and addressed the economics of it:
http://fixglobal.com/back_issues/Q1/GLOBAL/Fundamental%20messages.pdfThe incentive to support the FPL service is that it would actually solve the problem of unique and comprehensive instrument identification and description - again, I am aware of no other solution - be open and free of charge to most users, and reside in a trusted, non-commercial, collaborative, standards body.
The registration fees would easily defray the operating cost. I do not believe it is realistic to expect any but a tiny fraction of users of such information to become FPL members (millions of people use HTML without joining W3C).
I respectfully disagree on performance. First, if we are truly building a protocol that is as useful as possible for so-called high-frequency trading, there are no spare bits or bytes. Second, we have to consider all of the inputs, which include specification complexity, rules of engagement negotiation, and code development, testing, and maintenance. Finally, that the existing protocol has a component block for alternate instrument identifiers suggests room for improvement.
All that said, and as noted in my original, I agree that this effort MAY be out of scope. Still, I hope it will be considered as being within scope.
We need to be aware of the fact that there are other “open” initiatives that try to solve the same problem, e.g. http://bsym.bloomberg.com/sym/. What is the incentive to support the service offered by FPL compared to other offerings?
If most of the FIX users were to also become FPL members, additional fees would not be needed to operate such a service. Otherwise, initial funding of such an initiative is likely to be a stumbling block. The problem of global security identifiers is not primarily about performance but about automated processing and manual effort. Hence I would not tackle it within the scope of the HFT Working Group.
[ original email was from John Harris - john.harris@bondmart.com ]
Valid points, Hanno.
Rolf and Mark have provided good leadership in beginning this effort with a focus on scope. The shared perception of a problem seemingly affecting many people and firms (perhaps fairly stated as, “FIX as it exists today may be less than optimal for high-frequency trading; doing something about that may be worthwhile”) provides the motive force for the formation and efforts of the working group. Upon further reflection, it becomes obvious that market participants other than so-called “high-frequency traders,” e.g., electronic market makers, may also benefit from the effort; that much has changed since FIX as we know it was created, and that if we were to set out on the same mission that Fidelity and Solly began almost twenty years ago, we might attack the problem(s) differently. At the same time, members of the working group appear to share the view that their efforts are not about “fixing FIX” - a protocol that has served the market extremely well and will continue to do so for years to come - but seeing what good they can accomplish starting from a clean sheet, looking with fresh eyes at the problems that are amenable to an open, standard, trading protocol.
I am on record as stating that I hope multiple proposals will issue for market participants to consider and that everything should be on the table, including protocol features that effect the evolution of market design and structure. I am definitely of the view that the effort should be rigorous and disciplined, that the entire trade cycle (or better stated, portfolio- or position-management cycle) should be addressed, and that we proceed with a view of all the inputs and resource requirements implicit in the development and adoption of a standard. After all, to the extent we produce a specification some number of months or years from know, people have to read it, understand it, code to it, test their code, etc.
As noted in a prior post, let’s do something insanely useful. That likely means solving heretofore intractable problems - not all of them, undoubtedly, but at least some of them. Otherwise, we could just create a binary version of FIX and be done with it (and there would be nothing wrong with that).
We have thousands of years of relevant experience among us. Why can’t we create a protocol that uses energy, bandwidth, and compute resources far more efficiently? That is far more accessible, comprehensible, and useful to a much broader audience of market participants? Why can’t we have a financial messaging protocol that can become virtually ubiquitous and lead to a new class of devices and services that people purchase at Office Depot or from their ISPs?
That vision may be horribly out of scope. I won’t be offended if it is, but let’s at least make sure that in the scope-setting phase, we have a vigorous discussion of the problem domain, vision, philosophy, and so forth. We will cheat ourselves of a great opportunity if we don’t. I’d like to think that what we do is so stimulating that the kinds of kids that create products such Google, Firefox, Linux, Tor, BitTorrent and the like will become interested and make invaluable contributions in this sphere as well.
I am in agreement with you that synthetic security IDs are good for performance. My statement was that the call for global IDs is made by people who have bigger problems than performance, i.e. the problem of uniquely identifying a tradable entity in the first place. Venues have moved to solve the performance problem by introducing their own synthetic IDs which are obviously only useful when trading on this one venue. A single synthetic ID is useful when trading on multiple venues and I agree again that an organization like FPL is well positioned in general to be an issuer of such a global ID. FPL has done so with IDs for marketplaces which have now become obsolete with ISO MIC values.
I am less optimistic about the chances for FPL to provide such a service on the instrument level as this involves a number of very non-technical issues, e.g. commercial and political issues.
There are also technical issues, e.g. in the derivative space where it is necessary that matching engines can issue such IDs on the fly in real time. Another problem is that you need to distinguish tradable entities from (fungible) clearable entities. This is about stocks that are traded on the same venue with different matching algorithms (FIFO, pro-rata) and have two IDs fro trading but just one for clearing. Class A and class B shares are another example. Granularity of identifiers will be chosen differently depending on where you are in the value chain from pre-trade to settlement. Alternate security IDs are not a bad thing if these fields are limited to reference data messages.
My personal view is that the natural excitement of “defining a new protocol” as part of this working group has led to far too many things people would like to fix about FIX :-). Each and every one of these problems is worth solving but we will not solve anything with a scope as broad as it currently is. As I said, this is my personal view and I would love to be proven wrong.Regards,
Hanno.Thank you for your comment, Hanno.
I was pleased to learn of Bloomberg’s Open Symbology Initiative, but find it deficient for the purpose at hand in multiple respects. Out of respect for what is a commendable effort, I won’t enumerate here what I see as the defects but am happy to share them with you off-line.
I am not aware of any other such initiatives, but would applaud them. I proposed an initiative along these lines several years back in the journal FIXGlobal and addressed the economics of it:
http://fixglobal.com/back_issues/Q1/GLOBAL/Fundamental%20messages.pdfThe incentive to support the FPL service is that it would actually solve the problem of unique and comprehensive instrument identification and description - again, I am aware of no other solution - be open and free of charge to most users, and reside in a trusted, non-commercial, collaborative, standards body.
The registration fees would easily defray the operating cost. I do not believe it is realistic to expect any but a tiny fraction of users of such information to become FPL members (millions of people use HTML without joining W3C).
I respectfully disagree on performance. First, if we are truly building a protocol that is as useful as possible for so-called high-frequency trading, there are no spare bits or bytes. Second, we have to consider all of the inputs, which include specification complexity, rules of engagement negotiation, and code development, testing, and maintenance. Finally, that the existing protocol has a component block for alternate instrument identifiers suggests room for improvement.
All that said, and as noted in my original, I agree that this effort MAY be out of scope. Still, I hope it will be considered as being within scope.
We need to be aware of the fact that there are other “open” initiatives that try to solve the same problem, e.g. http://bsym.bloomberg.com/sym/. What is the incentive to support the service offered by FPL compared to other offerings?
If most of the FIX users were to also become FPL members, additional fees would not be needed to operate such a service. Otherwise, initial funding of such an initiative is likely to be a stumbling block. The problem of global security identifiers is not primarily about performance but about automated processing and manual effort. Hence I would not tackle it within the scope of the HFT Working Group.
The problem with missing a common symbol to identify instrument is real, and important.
We are trying to use ISIN for identify instrument.
Instruments are listed on one or many markets, a list market. We use MIC for this, such as XSTO for Nasdaq OMX Stockholm. CHIX for example competes with multiple exchanges, that sometimes have listed the same instrument.
We trade this instrument listed on XSTO, on CHI-X , in Swedish currency.
We now have:
INSTRUMENT ISIN, Listing market=XSTO, Execution Venue=CHIX, Currency=SEK.
If you think it is getting complicated, add multiple CCP:S and bilateral clearing. Trading via multiple systems, in several membership (different entities) and DMA via several brokers… (Why are we at all in this industry? 
)
Fine, how many of our back office (one more identifier) can handle these, now 5-8 identifiers for indentifying for example a trade, and it’s clearing place, counterparty etc? TCA anyone?
Some of our system providers hides all this for us- and deliver what we want, out of the box. We love them! What a service! Others, still can’t see any similarity or connections at all between ERIC B listed on CHIX or ERIC B on BURG.
Where did we end for identifying a trade?
ISIN, Currency,List market, Execution Venue, Membership, Back office, Clearing place, ClearingVenue (We may clear EMCF using a GCP), , Counterparty, System, User, Entity,…
I agree, a central administrated system for all such identifiers would be greate.
/ Jan
We need to be aware of the fact that there are other “open” initiatives that try to solve the same problem, e.g. http://bsym.bloomberg.com/sym/. What is the incentive to support the service offered by FPL compared to other offerings?
If most of the FIX users were to also become FPL members, additional fees would not be needed to operate such a service. Otherwise, initial funding of such an initiative is likely to be a stumbling block. The problem of global security identifiers is not primarily about performance but about automated processing and manual effort. Hence I would not tackle it within the scope of the HFT Working Group.
[ original email was from John Harris - john.harris@bondmart.com ]
With the exception of commodities, every financial instrument is uniquely defined by a legal instrument or set of legal instruments.
There is no valid reason why these instruments cannot have a unique identifier.
A harder problem is defining all of the instruments in a way that is database-friendly. Some of them are simply odd ducks and difficult to reduce to a template. But they still can be uniquely identified.
The problem with missing a common symbol to identify instrument is real, and important.
We are trying to use ISIN for identify instrument.
Instruments are listed on one or many markets, a list market. We use MIC for this, such as XSTO for Nasdaq OMX Stockholm. CHIX for example competes with multiple exchanges, that sometimes have listed the same instrument.
We trade this instrument listed on XSTO, on CHI-X , in Swedish currency.
We now have:
INSTRUMENT ISIN, Listing market=XSTO, Execution Venue=CHIX, Currency=SEK.
If you think it is getting complicated, add multiple CCP:S and bilateral clearing. Trading via multiple systems, in several membership (different entities) and DMA via several brokers… (Why are we at all in this industry?
Fine, how many of our back office (one more identifier) can handle these, now 5-8 identifiers for indentifying for example a trade, and it’s clearing place, counterparty etc? TCA anyone?
Some of our system providers hides all this for us- and deliver what we want, out of the box. We love them! What a service! Others, still can’t see any similarity or connections at all between ERIC B listed on CHIX or ERIC B on BURG.Where did we end for identifying a trade?
ISIN, Currency,List market, Execution Venue, Membership, Back office, Clearing place, ClearingVenue (We may clear EMCF using a GCP), , Counterparty, System, User, Entity,…
I agree, a central administrated system for all such identifiers would be greate.
/ JanWe need to be aware of the fact that there are other “open” initiatives that try to solve the same problem, e.g. http://bsym.bloomberg.com/sym/. What is the incentive to support the service offered by FPL compared to other offerings?
If most of the FIX users were to also become FPL members, additional fees would not be needed to operate such a service. Otherwise, initial funding of such an initiative is likely to be a stumbling block. The problem of global security identifiers is not primarily about performance but about automated processing and manual effort. Hence I would not tackle it within the scope of the HFT Working Group.