Interchange data between brokers trading platforms

Hi, I am looking for some advice from you guys or even an appointment to a convention that I am not aware.

Actually, I work with 2 different brokers (probably 3 in the future) and each one has its own trading platform. As Amibroker and AFL are becoming an essential tool for my trading strategies I want to focus my efforts in Amibroker to study, create strategies and process buy/sell signals and send it to the trading platform.

About this last part. What has been the most effective solution for you?

I already saw a topic about MT4, but this question goes far beyond. As suggested, I also thought to write a csv file and read from the brokers platform. Therefore, it seems to be a very fragile solution. Anyway. Is there any convention to do this? What does the developer suggest?

This topic can benefit anyone but to elucidate my particular matter, I trade only futures. The platforms are Metatrader 5 (Brazil and US) and TWS (US). I use IQFeed (very consistent and rich database by the way).

For data interchange, the participating applications should expose APIs (A very general but necessary term) by any way either through RAW code, DLLs or OLE as some examples.

Referring specifically to AB, the COM/OLE method is one of the easiest and can be found here for more details:
https://www.amibroker.com/guide/objects.html
More complex DLL via ADK is also possible.

There is also a DDE plugin that can be used in AB to interact with MT4.
MT5

More aggressive discussion can be found here, but also worth reading the whole thread.

IB/TWS
Nothing more to add then the explanation here
https://www.amibroker.com/guide/h_ib.html

There are probably hundreds of posts, you need to go through a majority of them.
Also cite the thread/post you visited and what you found unanswered so that specific point can be discussed further rather than generalizations.

1 Like

Thanks for your answer.

Actually, I got the quotations. I tried COM solution and have success at comparing IQFeed quotation to the broker's platform. The documentation is easy to understand and it is fast to implement. Therefore, my problem is that I can't find how to get the real time buy/sell signals from Amibroker. Is there any object that carries this information? Am I missing anything?

DDE can't solve my problem. Can DLL?

I had seen the MT4 post. In my point of view a poor solution (create a text file on communication), but maybe the only one I have.

Well. Thanks again.

Well, as I got no solution here. I payed a coder. For future reference are two very useful libraries called Redis and ZeroMQ. They make the implementation of a bridge very fast and easy. You can use in your DLL and share data to C++, Python and Mql (Metatrader 4 and 5) and other many languages supported. Who knows AFL in the future? Would be a simple way to communicate Amibroker with everything else. If anyone is interested. I am creating an order manager in Python that will receive the buy/sell signals from Amibroker (by a .csv I need to implement) and send it to TWS, Metatrader 5, and many others by socket (those libraries I quoted).

1 Like

Hi
i dont think you need to pay any coder to write a code for saving your signals to csv.
there are so many examples in this forum how to save a file.

Can you tell us the delay between the signal and the execution to your broker?

Actually, I payed to connect Python to Metatrader via socket (the libraries above). The point was "how to connect Amibroker to Metatrader, Saxo Bank, etc.". After all, my solution was Amibroker talks to Python app and Python app talks to the broker's platform. This Python app will provide connection consistency and gather the daily result. Python app will be a kind of "order, position and result manager".

The AFL code I agree with you I already got some formulas that I am editing. I am studying just how to implement it to be more consistent and trustful.

About its delay:

Sending orders manually from Python...

  1. Time to the Broker receive the order: 0.25 milliseconds to 3.51 milliseconds
  2. Get the order ID in Python (market order executed): 0.73 seconds to 2.23 seconds

Automated from Amibroker:

Well. As we know r/w files is not the fastest solution. And the type of storage you are using (HD or SSD) needs to be considered. I have chosen this option because my strategies don't demand timing.

Anyway. Setting the thread to wait 1 second it takes 3 to 7 seconds from the time of buy/sell signal written by Amibroker till Python gets the order's ID. I need to adjust the time units to provide a more precise result.

Well, works for me.

This test above was made for Metatrater 5.

For timming you really should code a DLL to do this. ZeroMQ and Redis will be very useful to Metatrader. For TWS you can use either ibcontroller in AFL or their C++ API (very intuitive) in DLL. It would allow you to do more things such as draw your daily results from many brokers.

Off course, this is just my opinion based on my searches until now.

2 Likes

Hello

The best idea is to avoid the thread to wait 1 second and NOT use it at all, in this part of the code.

To wait 1 second or more you can use staticvar Instead.

What? I don't know who wrote you those "python" parts, but anything that runs locally (not over the Internet) even when using ordinary files should be working well below 1 second (I mean less than blink of an eye).
The only thing that will take time is to having your broker to accept and fill the order. Actually if that is limit order it may not be filled at all for long time (limit not reached or lack of liquidity). And no you don't need DLLs for auto-trading. And you don't need waiting. If you are using any kind of Sleep() in the formula you are doing it wrong.

And to the original poster: I don't know exactly what problem you have. You can have data from IQFeed using official plugin and trade using Interactive Broker interface. Automated trading and quote feed are independent. Data are delivered by data plugins (DLLs). Automated trading is handled by OLE/COM (see IBController publicly released sources to see how it is done). It can also be done via REST APIs if your broker allows that.

1 Like

Hi Tomazs. Thanks again for your considerations.

These are the questions:

  1. The original problem is how to integrate Amibroker to any broker's accredited platform. Not all brokers provide REST APIs, specially in Brazil and other emerging countries that I am investing. Usually what happens is a brokers accredit an existing platform to work as a mediator (IE. Metatrader). My goal is to build a solution to talk to those mediators. Via baskets, sockets, etc.

So, the solution I propose is to have a forwarder (Python, C++ whatever) between Amibroker and those platforms which receives the Amibroker buy/sell signals and send it to the broker. The idea behind this forwarder is having an administrator to assure the connection quality and also get order status and display real time result charts. Think is a bad idea?

  1. The 1 second wait was just for a silly delay test. But, yes, there is a sleep() function inside a loop waiting for the file to be completely used for Amibroker. My concern is reading a file while Amibroker is still writting into it. Is it wrong?

  2. Finally and the most important. I got very curious about OLE/COM solution. Would be perfect. What object manages buy/sell signals? How can I get them?

I think you might have mixed up two things here. Atleast from what I read. Corrcet me if I'm wrong.

Firstly, COM/OLE model works in Server - Client way, so in very few words, one should be prudent in its application.
It is very simple to write your COM object, register it and call it from AB whenever a signal is generated.
This way there is no delay, your program will get signals and then you can pass them to the Trading Platform.
In this scenario, AB is the client and your Program acts as server.

The role of server and client can't be reversed, it will then pile up on flaws.

Incase you to interact with AB, say, you want to run all active explorations from your program,
at that time create an object of AB and invoke relevant methods.

AB = new ActiveXObject( "Broker.Application" ); // creates AmiBroker object
try 
{ 
    NewA = AB.AnalysisDocs.Open( "C:\\analysis1.apx" ); // opens previously saved analysis project file 
    if ( NewA ) 
    { 
         NewA.Run( 2 ); // start backtest asynchronously
         while ( NewA.IsBusy ) WScript.Sleep( 500 ); // check IsBusy every 0.5 second 
         NewA.Export( "test.html" ); // export result list to HTML file
         WScript.echo( "Completed" ); 
         NewA.Close(); // close new Analysis 
     } 
} 
catch ( err ) 
{ 
     WScript.echo( "Exception: " + err.message ); // display error that may occur
}

This makes sense having AB as the server and your program as the client.

Both can work together, that is each running application, instantiating the others object and invoking functions, provided the role for each object is well thought out.

I had tested this article for a Python COM object
http://timgolden.me.uk/pywin32-docs/html/com/win32com/HTML/QuickStartServerCom.html
and it worked very well.

3 Likes

It (OLE/COM) should be implemented the other way round. Trading interface is the OLE/COM server, AmiBroker is a client. Full C++ source codes of IBController that does just that are available:
http://www.amibroker.com/devlog/2013/06/03/ibcontroller-1-3-8-source-codes-released/

Once you write your trading interface you can interact with it using AFL:
http://www.amibroker.com/guide/afl/createobject.html
http://www.amibroker.com/guide/a_aflcom.html

5 Likes

At First. Thank you for taking your time in this topic. Things started to make sense.

You are right! I completely misunderstood it. Studying a little of the IBController code I got what you are talking about.

It is exactly what I need to do. I need no csv as I could do this way.

But one thing is not clear yet. If a have many other formulas working at the same time and same COM communication. How exactly it will be managed? Is there any risk to lose information from and buy/sell signals?

1 Like

Study IBController. It handles multiple orders. You should just use kind of "OrderID" so you can keep track of different orders from different formulas. COM/OLE is serialized so there is no re-entrancy risk (one call to COM/OLE would need to be completed before next one is handled)

4 Likes

Thank you Tomasz for this reply and for the last reply with the very useful links. Very helpful!