Skip to content

FIX engine integration

13 messages · Paul Kent, Jeff Ryan, Ulrich Staudinger +5 more

#
This isn't a a question per se. The simplest fastest way is to hire someone. 

The next best "question" is to carefully construct a request as to what you have done, what research you've done and what parts you are missing. 

Best
Jeff

Jeffrey Ryan    |    Founder    |    jeffrey.ryan at lemnica.com

www.lemnica.com
On Feb 17, 2013, at 11:30 AM, Paul Kent <paulkent7 at aol.com> wrote:

            
#
But has anybody attempted it already ? also FIX engines have
surprisingly not been implemented too much in C. will that be a
hindrance ? I can collaborate in this project if somebody wants to
make it. I already am making an algo trading platform in C. this would
just be an add on to it.
On 2/17/13, Ulrich Staudinger <ustaudinger at activequant.com> wrote:
#
Well ..... There is AQ-R, which you can use to plug into an ActiveQuant 
Master Server. AQ-R has real time messaging based on STOMP in it.
That means, you can react to messages and send new messages to channels ...

I'll leave it to the educated reader how to put these puzzle pieces 
together.
On 02/17/2013 07:32 PM, sidharth mallik wrote:

  
    
#
In addition to my former mail, you don't need plain C, it is very 
convenient to use RCPP.

Sincerely,
Ulrich
On 02/17/2013 07:32 PM, sidharth mallik wrote:

  
    
#
I mean there are several trading firms in Chicago that do this. They have
full time staffs on hand to keep everything going. FIX is not just as easy
as sending in buy me 1 e-mini at a price. Everything in the FIX message has
to be correct to get an ACK, if not you get a NAK. An ACK message is
detailed here:

http://www.fixprotocol.org/specifications/fix4.4fiximate/TradeCaptureReportA
ck.html

I was on a team interviewing for a FIX person. The best person wanted
$200,000 plus incentives. That was more than $100,000 over our salary range.
She eventually got what she was asking from a trading shop in Boston. So the
help for this is not cheap.

Wouldn't you rather use a brokerage firm that can take an order off a simple
order entry system and let them process it into FIX format and send it on to
the exchange?

GL

Frank 

-----Original Message-----
From: r-sig-finance-bounces at r-project.org
[mailto:r-sig-finance-bounces at r-project.org] On Behalf Of Paul Kent
Sent: Sunday, February 17, 2013 11:30 AM
To: r-sig-finance at r-project.org
Subject: [R-SIG-Finance] FIX engine integration


Hi All,

We are considering porting some automated trading strategies to R. 

Please can you advise me on FIX integration for trading:

The simplest and quickest way to do this

The most common/popular way of during this

The best (fastest/most robust) way of doing this.

Thanks

Paul


_______________________________________________
R-SIG-Finance at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- Subscriber-posting only. If you want to post, subscribe first.
-- Also note that this is not the r-help list where general R questions
should go.
#
@Ulrich : Aren't the specifications you mentioned somewhat obvious ?

Since he wants to use R, high frequency is ruled out. it is most
probably medium frequency.
then again, in absence of specs, we must assume that R will be used
here as a calculation engine for whatever kind of calculations
required which should by default include any calculations for reacting
to order events. I mean not reacting to order events is just a subset
of the whole thing and is just an architectural issue when actually
making the platform.

the actual issues he needs to answer are :

1. is this for a server level platform or a client level platform
2. what is the actual volume of trading
3. does he already have a front end or will that need to be integrated as well
4. what kind of risk management needs to be involved

and other such stuff.

but in any case, i think he is already using some platform and he has
strategies already prepared for that platform, so the actual
requirement is that a platform is being used, can he lay hands on R
code that can perform the same stuff or not.
On 2/18/13, Ulrich Staudinger <ustaudinger at activequant.com> wrote:
#
my two cents:

1. keep FIX (engine) outside of R (instances).

2. use rzmq/zeromq as middleware between the FIX engine and R (multi-instances):
http://www.zeromq.org/
https://github.com/armstrtw/rzmq

3. use filtering per topic (symbol subscribe):
http://www.zeromq.org/whitepapers:message-matching

4. You can use QuickFIX but a better option may be a fix8:
http://fix8.org/

Best regards,
Daniel
#
On Sun, Feb 17, 2013 at 12:30:20PM -0500, Paul Kent wrote:

            
I haven't done it, but have thought about doing so, and got some
feedback from folks who have built and used FIX in the past.  From
them, my understanding is that despite being a "standard", in actual
practice every broker uses FIX differently, with their own non-trivial
conventions and quirks.  So you will need to add custom support for
each broker you trade with.

You will probably also want to build a simulation of each of your
brokers FIX behavior, so you can hook that that up to your FIX-enabled
trading engine for testing.

If building your own, the C version of QuickFix is the obvious open
source codebase to start from.  Perhaps some commerical option would
be better, but I'm not familiar with them.