I have performed FIX testing for well over 100 different FIX connections covering equities (single stock, DMA, baskets and algorithms), futures, foreign exchange, fixed income and I've always thought of this as an area where technology has stood still. Conformance testing in 2014 is really no different to conformance testing in 2005 or even earlier.
There is some testing software out there (such as Greenline, LaSalleTech and others) but it really exists to automate a manual process without re-engineering. This proposal aims to offer a way forwards for the FIX Trading Community to allow a low value piece of work to be automated and removed from the day-to-day work needed.
FIX workflow testing or conformance testing is a long and often painful process. If we look at the world of hardware we see plug-and-play technology such as the Universal Serial Bus (USB) that allows different devices to be connected and get up and running quickly. We also see technology such as Bluetooth that allows data transfer and system command based upon trust – sending music from an iPhone to a stereo, allowing an in-car system to use an Android telephone for hands-free calling. This proposal looks to implement a similar model for FIX based trading.
Consider this analogy...
A piece of C++ code that exposes an interface using IDL. There is code that does work (calculate the yield on a bond) and an interface that is called by other code to access the worker code. The segregation of duties principle is at work here, the interface merely describes the way to address the worker code, the task of performing the calculations is delegated to the worker code.
For more on IDL have a look here
Overview
When establishing a new FIX connection there is an on-boarding process. This is typically email and telephone based to establish the parameters for the connection. Let’s take a simple example
Broker A, an equity broker, wants to receive electronic order flow from buy-side B.
Broker A publishes a rules of engagement document
Broker A and buy-side B (hereafter A and B) then engage in discussion around topics such as:
- Physical transport layer
- FIX version to use
- Instrument types to trade
- Workflows supported
- Implementation shortcomings
- Certification testing
Then there are specific items of work to perform:
- Place order for physical connectivity (leased lines)
- Firewall set-up
- Telnet testing
- Conformance testing
- Go-live testing
At every stage there is human intervention and therefore scope for error.
Imagine an alternative...
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.
How?
Think of a typical workflow test case that would be performed by a manual tester.
- Buy-side FIX engine issues logon to sell-side
- Sell-side FIX engine issues logon to buy-side
- Buy-side sends a heartbeat
- Sell-side sends a heartbeat
- Buy-side sends New Order Single
- Sell-side issues pending new
- Sell-side issues new
- Sell-side issues fill to partially fill order
- Sell-side issues fill to fully fill order
- End of test
This workflow can be depicted in many ways – a state diagram, in words as above and so on.
Imagine instead that this workflow is described in a machine readable format. So this FIX interface is described in FIDL – FIX Interface Definition Language. The URL supplied by A links to a FIDL file for B that is downloaded, parsed and then automatically tested by B.
What would FIDL need?
This is something that requires more consideration, but as a starting point I suggest the following:
Ordering of messages (in the same way that FIX is ordered)
Defaulting to a reference implementation
Automatic generation of FIDL from sell-side OMS system logic would be preferable
Reference where needed to an industry-wide utility database for instrument reference data
Versioning
Automatic update capability with options for manual intervention
Multiple version support (so a sell-side can offer multiple FIDL interfaces customised to different clients)
Represented in pseudo-code we would see test cases that look something like this...
FIDL pseudo-code
<FIDL vX.Y.Z>
<Test set 0001>
<Workflow Step 1>
<Send>
<Buy-side try>Logon</Buy-side try >
<Buy-side catch> if a logon cannot be issued</Buy-side catch>
<Buy-side finally > if a logon cannot be issued then raise an error back to the OMS</Buy-side catch>
</Send>
<receive>
<Buy-side try > select the type of message received
<case>reject then raise error and quit<case>
<case>pending new then raise information message and continue to workflow step 0004<case>
<case>else then raise error and quit<case>
</Buy-side try >
The beauty of this human readable format is that the ordered message expectations of FIX mean that the number of paths through a trading interaction cannot explode outwards - there are a pretty limited number of valid options to answer the question "what can legally happen next".
Given the limited number of paths we have a problem set that can be regarded as a closed set - and as such, once a sell-side has constructed the initial implementation of their FIIDL interface it becomes simple to keep this up-to-date.
Plug-and-play means that I can buy a new phone and connect it to my car stereo with no effort. The world of electronic trading should step up to the plate and make it simple for buy-sides to access sell-side expertise by supporting the FIIDL initiative.
Comments
Post a Comment