Further to earlier posts here and here I've been asked to clarify how exactly this proposed model would allow FIX sessions to bootstrap from a session layer to the application layer. The original text I wrote had this description:
BT Radianz IP 111.222.333.444 port 2536
"Broker A sends buy-side B an email with a unique URL. B opens the URL through their OMS. The OMS at B (once able to physically connect to A) then auto-discovers the capabilities of A. A set of test cases are created based on the systematically described capabilities of A. These test cases are then automatically executed by systems at A and B. A report is generated with human readable results of the testing and these results are archived to disk as part of an audit trail"
While that's viable, I'd like to extend and enhance the original proposal. A much more elegant solution is this:
"Broker A sends buy-side B an email details of the methods of connectivity supported, such as:
BT Radianz IP 111.222.333.444 port 2536
TNS IP 223.785.222.601 port 8036
Autex Target Compid EUBrokerA
Fidessa Target Compid EUBrkrA
B the configure their FIX engine to open a session with Broker A. The OMS at B (once able to physically connect to A) then auto-discovers the capabilities of A. Essentially the FIIDL data is transmitted as a FIX message. The simplest analogy here is if you think of an equity exchange publishing a start of day market data download of tradable instruments (LSE Stock Exchange Daily Official List = SEDOL). A set of test cases are created based on the systematically described capabilities of A. These test cases are then automatically executed by systems at A and B. A report is generated with human readable results of the testing and these results are archived to disk as part of an audit trail.
Every day at session start up an increment request/reply mechanism will be executed to ensure that the buy-side receives and updates. So imagine that a European broker decides to expand to a new market in Asia. The FIIDL file will now include a new set of capabilities that the sell-side offers to the buy-side. The beauty of this model is that the entire mechanism is contained within an enhanced FIX session."
Note that it's entirely possible for the FIIDL description to be transmitted over a different session layer model compared to the actual trading session. So FIIDL may be sent in a FIX 5.0 Service Pack XX session and the actual trading could happen using GPB, FAST, ASN.1 or perhaps even OUCH.
So, in effect, the FIX session now bootstraps the trading technology relationship between the sell-side and the buy-side. No need to keep on testing manually each time a new exchange goes live or a new option series is created.
Echoing the earlier post here one potential consequence of a move to a FIIDL based trading world is that the onion layer model breaks down, as discovery becomes inherent to the trading landscape. One can imagine that savvy buy-sides set their spiders to find liquidity and then use a sell-side to simply book a riskless principal cross to the exchange. As such, the series of connections in the market place now starts to resemble a grid or mesh rather that a spider web.
A tech savvy exchange would have a competitive advantage if it was able to connect to a FIIDL based mesh trading world.
Comments
Post a Comment