I've had a number of interesting conversations further to my earlier post on FIDL...
The main purpose of FIDL is to reduce the setup costs of trading with a new firm.
I have been thinking that FIDL should more accurately be called FIIDL - FIX Interactive Interface Definition Language. The point here is that most FIX documentation only covers the static elements of what fields are valid for which message type, which elements of an enumeration are accepted and so on. Hence why a person has to manually test the interactive workflows - what happens when I send an order and send an order cancel after the order is filled and so on. The interactive element is missing from documentation.
If the FIIDL file can contain all valid permutations and combinations of workflow and message payload logic then we get to FIX as a plug-and-play protocol.
Since FIIDL sits atop the actual protocol it will be possible for FIIDL to support any actual message representation whether it's FIX, FIXML, FAST, ASN.1, Protocol Buffers and so on...
One can argue - quite easily that FIIDL can be implemented entirely without the knowledge of a FIX engine. Since a FIX engine is providing middleware services and the value is at the application layer, it's easy to imagine FIIDL being generated from the core EMS and/or OMS business logic layer.
The main purpose of FIDL is to reduce the setup costs of trading with a new firm.
FIDL does not change any of the other dynamics of the business - AML and KYC still have to be done. What it does do is move towards a more modern technical paradigm where rules of engagement documents do not act to transfer the flow of information about how to interact with a broker via FIX.
I have been thinking that FIDL should more accurately be called FIIDL - FIX Interactive Interface Definition Language. The point here is that most FIX documentation only covers the static elements of what fields are valid for which message type, which elements of an enumeration are accepted and so on. Hence why a person has to manually test the interactive workflows - what happens when I send an order and send an order cancel after the order is filled and so on. The interactive element is missing from documentation.
If the FIIDL file can contain all valid permutations and combinations of workflow and message payload logic then we get to FIX as a plug-and-play protocol.
Since FIIDL sits atop the actual protocol it will be possible for FIIDL to support any actual message representation whether it's FIX, FIXML, FAST, ASN.1, Protocol Buffers and so on...
One can argue - quite easily that FIIDL can be implemented entirely without the knowledge of a FIX engine. Since a FIX engine is providing middleware services and the value is at the application layer, it's easy to imagine FIIDL being generated from the core EMS and/or OMS business logic layer.
Comments
Post a Comment