FIX APIs

Has anyone already experience with Zorro and FIX APIs? If I remember right this was even on the agenda 'planned for future Zoro versions' some time ago but I'm not sure at all.

I am in the midst of writing a DTC plugin. DTC is a similar protocol to FIX. It would not be difficult for me to use my DTC plugin experience to write a FIX plugin - I'd even re-use at least half the code.

Why do you ask? Is there a particular broker you were hoping to use it with?

Yes and I'd be simply curious to have a try, it should offer a very direct access.

FIX is theoretically standardized but often implementation-specific. Can you name the broker? Perhaps I can use it as a starting point.

Darwinex seems interesting. Ciao

https://blog.darwinex.com/fix-api-trading/

I'm not sure why they need $500 USD for access to a server that's probably up and running.

A complete free of setup fees and accessible for everyone FIX API implementation is e.g. offered by fxpig.com. I don't know how reliable they are but this shouldn't matter if they provide a FIX API playground ... demo account I mean.

Wow, you're right. I can't open live accounts with them but they let me open a FIX demo anyways. How nice.

So they do FIX 4.4, which is relatively common. I am uncertain of how much tinkering is required to make the messages compatible with an individual broker - hopefully this is minimal.

What I might have to do is make a FIX 4.4 plugin and require a certain BrokerCommand or username "flag" to enforce message compatibility (i.e. BrokerCommand(SET_BROKER,BROKER_FXPIG)).

To be honest, this is low priority on my own list, but maybe I can get to it within a year.

By the way, FIX is Orders Only (no "trades"), so you would have to run Zorro scripts in NFA mode, just like with IB.

If FIX was intended as a standardized API it should really not vary so much between brokers except regarding different version numbers. BTW brokers that offer cTrader access should also be reachable through FIX API directly.


No problem, I'm not in a hurry.

I am simply relaying what I have read from experienced FIX programmers who, having put up with these problems, invented the DTC protocol in the first place.

On a side note, I wrote the Ally Plugin, which used a small number of FIX messages in a special XML format called FIXML, jumbled with their own proprietary REST stuff. And none of the FIXML messages were actually compliant with the official FIXML schema! Ally ignored me when I asked about it.

But that was a mixed interface. Hopefully I won’t have such hiccups working with pure FIX. None!

Andrew, FIX messages are asynchronous, correct? so you manage somehow concurrency when callbacks from FIX gain access to the same shared resources?

Thanks

Asynchronous network programming would be the preferred approach, yes, but technically it can be programmed synchronously as well, and optionally multithreaded (not necessarily the same thing as asynchronous). A server can send several kinds of messages at any time, so a plugin will need to receive and handle them. Let your programmer decide the best approach.

thanks Andrew, so you would suggest as a possible solution the plugin 'receiver' to collect callbacks, queue them and send for processing sequentially one by one. correct?

thanks

Messages should always be sent and received on a FIFO basis, yes.