Mark Rooney
FIX is one of the most common communication protocols used within the finance industry. This blog outlines the use of a kdb+ API built on top of QuickFix (www.quickfixengine.org) and describes how simple Indication of Interest (IOI) messages can be sent between two FIX components.
We will demonstrate how to use the API to create some simple FIX messages and send them via kdb+. We will use the FIXimulator tool (http://fiximulator.org/) to emulate the sell-side part of the system. This tool will send IOIs to our kdb+ client so that we can place orders and get realistic execution reports back.
Once you have the FIXimulator tool up and running, it will be bound to a port on your machine (by default this is 9878). To connect to the tool we can then use the .fix.connect function and pass the host and port name as arguments. The FIXimulator tool supports FIX 4.2 by default, so we will also make sure that our FIX client uses the same version. The final detail that we need to take care of is the session id. FIXimulator creates an acceptor session with the id FIX.4.2:FIXIMULATOR->BANZAI. We need to change our sender comp id and our target comp id to match.
q) connkeys:`BeginString`SocketConnectHost`SocketConnectPort`SenderCompID`TargetCompID
q) connvalues:(`FIX.4.2;`192.168.1.70;9878;`BANZAI;`FIXIMULATOR)
q) .fix.connect[connkeys!connvalues]
If you have not changed the logging configuration, then by default the kdb+ client will write messages out to stdout. You can then start the IOI generation thread and the automated executor thread and watch the messages being recieved by the kdb+ client (the default behaviour is to just print incoming messages to the screen).
We can then use the .fix.onrecv function to capture these non-administrative messages and handle them. The only parameter to the function is a dictionary that has longs as its keys and strings as its values (these will be converted to kdb+ types automatically in later revisions of the library).
q) .fix.onrecv:{[d] ... }You can use the .fix.send function to send your own fix messages to the FIXimulator server. To do this, you just need to build up a kdb+ dictionary that maps integers to kdb+ types. The function will automatically deduce where to send the FIX message based on the BeginString, SenderCompID, TargetCompID and SessionQualifier. We provide some helpful constants in the .fix.tags dictionary that can be useful if you are building them by hand. The example below shows how you could send a response to FIXimulator such that it will accept the order and respond with an execution report.
q) .fix.onrecv:{[d]
/ For simplicity, we will just accept all of the IOI's
/ recieved and construct a new order with the minimum
/ number of required fields. We can create a dictionary
/ using just the integer tags:
message:(8 49 56 54)!(`FIX.4.2;`BANZAI;`FIXIMULATOR;1);
/ or we can use the .fix.tags dictionary to make it a little
/ more readable
message[.fix.tags.MsgType]: `D;
message[.fix.tags.Symbol]: d[.fix.tags.Symbol];
message[.fix.tags.HandlInst]: 2;
message[.fix.tags.TransactTime]: .z.p;
message[.fix.tags.OrdType]: 1;
.fix.send[message]; }
If the message makes it through to the FIXimulator server, then we should get a response that looks something like the example below. The library will validate all messages that are recieved, which means that you can assume that the message that is passed to .fix.onrecv has at least all the required fields and the correct types.
BeginString | "FIX.4.2"
BodyLength | "176"
MsgType | ,"8"
MsgSeqNum | "45"
SenderCompID| "FIXIMULATOR"
SendingTime | "20150508-12:13:30.275"
TargetCompID| "BANZAI"
AvgPx | ,"0"
CumQty | ,"0"
ExecID | "E1431087210278"
LastPx | ,"0"
LastShares | ,"0"
OrderID | "01431087210281"
OrdStatus | ,"0"
Side | ,"1"
With these simple examples, you should be able to get started with using the library to build simple FIX clients. The source code for this project can be found on the GitHub account referenced below. This implementation should be considered to be in an alpha state and should be thoroughly tested before use in any production setting. Bugs and feature requests should be made on the GitHub page.
This blog is the first in a series of posts which will demonstrate one approach on how to build a production quality data capture and analysis system using the torQ frame work.
The GitHub repository for this project is located at: https://github.com/AquaQAnalytics/kdb-fix-adaptor
Share this:
