For connecting the Zorro platform to a particular broker API, a DLL must be dropped in its Plugin folder. The DLL is then automatically recognized and appears in Zorro’s Broker selection box. For trading with the broker, the DLL exports functions for getting prices and sending orders. These functions are standardized and described in the Zorro manual. They are the same for all brokers. The following 4 functions are the most important:

BrokerOpen – identify the DLL.
BrokerLogin – initialize and store login credentials.
BrokerAsset – retrieve price and other parameters of an asset.
BrokerBuy2 – send a buy or sell order.

These four are sufficient for running most trading strategies. The DLL can export additional functions that are useful, but not mandatory, since Zorro works around them when they are not implemented:

BrokerAccount -get the account state.
BrokerTrade – get the trade or order state.
BrokerHistory2 -get price history.
BrokerCommand – set special modes, get order book, etc.

Zorro users have written DLLs for several broker APIs, but the code is often redundant and invents the wheel many times again. I’ll give here an example of a relatively lean broker DLL that can be used as template for individual REST API implementations. Bittrex is a US based digital currency exchange that supports several hundred crypto currencies and provides free API access. We’re first going to implement the 4 mandatory functions, following the API description on the Bittrex website:

https://bittrex.github.io/api/v3

We will use the free Visual C++ Community Edition from Microsoft. Aside from the exported functions, we need some internal functions to print messages, send HTTP requests, parse a JSON response, and generate a digital signature. For all this there’s ready code available on the Internet, but there are also ready functions in Zorro’s library. To make life easier, we simply import the Zorro function library to the DLL. The VC++ setup for generating such a DLL is described here:

https://zorro-project.com/manual/en/dlls.htm

The setup is for a C++ trading strategy, but works as well for a broker API DLL. First we’re going to implement the adminstrative stuff, the BrokerOpen and BrokerLogin functions:

#define PLUGIN_TYPE 2
#define PLUGIN_NAME "Bittrex V3"
#define DLLFUNC extern "C" __declspec(dllexport)

int (__cdecl *BrokerMessage)(const char *Text);
int (__cdecl *BrokerProgress)(const int Progress);
...

DLLFUNC int BrokerOpen(char* Name,FARPROC fpMessage,FARPROC fpProgress)
{
  strcpy_s(Name,32,PLUGIN_NAME);
  (FARPROC&)BrokerMessage = fpMessage;
  (FARPROC&)BrokerProgress = fpProgress;
  return PLUGIN_TYPE;
}

The BrokerOpen function is Zorro specific. It sets up two function pointers for printing message and sending heartbeats to Zorro. It’s needed for recognizing the DLL in the Plugin folder and letting the plugin name, “Bittrex V3”, appear in the broker scrollbox. 

Next we need the login function that’s called at the begin and the end of any algo trading session

struct GLOBAL {
  int PriceType,VolType,OrderType;
  double Unit; // smallest trade unit
  char Path[256]; // send path buffer
  char Key[256],Secret[256]; // credentials
  char Symbol[64],Uuid[256]; // last trade symbol and UUID
  char AccountId[16]; // account currency
} G; // parameter singleton
...

DLLFUNC int BrokerLogin(char* User,char* Pwd,char* Type,char* Accounts)
{
  if(User) { // login
    memset(&G,0,sizeof(G));
    strcpy_s(G.Key,User);
    strcpy_s(G.Secret,Pwd);
    return 1;
  } else  // logout
    return 0;
}

This function only sets up the G struct, a singleton that holds all global variables of the DLL. The User and Pwd arguments contain the Bittrex key and secret. They are taken from the Zorro login fields or from the account list. Type is the account type, ignored here because Bittrex has no demo accounts.  Account is the account identifier and also ignored since we’re not using sub-accounts.

Next comes the function to retrieve prices and other parameters of a particular cryptocurrency. It’s a bit more complex and requires a HTTP request to the API. Some requests require authentication, some not. For all this we first implement a send() function in the DLL that uses Zorro’s functions for sending http requests and generating a HMAC signature. The authentication method by the Bittrex REST API V3 is a bit complex:

To properly sign an authenticated request for the Bittrex v3 API, the following headers must be included: Api-Key, Api-Timestamp, Api-Content-Hash, Api-Signature. Api-Timestamp is the current time as a UNIX timestamp in epoch-millisecond format. Api-Content-Hash is a SHA512 hash of the request body, Hex-encoded (with no request body, a SHA512 hash of an empty string). For creating the Api-Signature, first generate a string by concatenating the following items: Contents of the Api-Timestamp header; the full URI used to make the request, including query string; the HTTP method of the request, in all caps (GET, POST, DELETE, etc.); Contents of the Api-Content-Hash header. Sign this string via HmacSHA512, using the API secret as the signing secret. Hex-encode the result and populate the Api-Signature header with it.

This is the implementation:

#define RHEADER "https://api.bittrex.com/v3/"
...

int sleep(int ms)
{
  Sleep(ms); 
  return BrokerProgress(0);
}

char* send(const char* Url,
  int Mode = 0,
  const char* Method = NULL,
  const char* Body = NULL)
{
  static char Url[1024], Header[2048], Signature[1024],
    Buffer1[1024*1024], Buffer2[2048];
  *Signature = *Header = 0;
  sprintf_s(Url,"%s%s",RHEADER,Url);
  if (Mode & 1) { // Authentication required
    strcpy_s(Header, "Content-Type:application/json");
    strcat_s(Header, "\nAccept:application/json");
    strcat_s(Header, "\nApi-Key: ");
    strcat_s(Header,G.Key);
    strcat_s(Header, "\nApi-Timestamp: ");
    __time64_t Time; _time64(&Time);
    static __time64_t Offset = 0;
    char* TimeStamp = i64toa(Time*1000 + Offset++); 
    strcat_s(Header, TimeStamp);
    strcat_s(Header, "\nApi-Content-Hash: ");
    char* Hash = hmac(Body, 0, 0, 512);
    strcat_s(Header,Hash);
    strcpy_s(Signature, TimeStamp);
    strcat_s(Signature, Url);
    if(Method && *Method)
      strcat_s(Signature, Method);
    else if(!Body)
      strcat_s(Signature,"GET");
    else
      strcat_s(Signature,"POST");
    strcat_s(Signature, Hash);
    strcat_s(Header, "\nApi-Signature: ");
    strcat_s(Header, hmac(Signature, 0, G.Secret, 512));
  }

  char* Response = Mode & 2? Buffer2 : Buffer1;
  int MaxSize = Mode & 2? sizeof(Buffer2) : sizeof(Buffer1);
  int Id = http_request(Url,Body,Header,Method);
  if(!Id) goto send_error;
// wait 30 seconds for the server to reply
  int Size = 0, Wait = 3000;  
  while (!(Size = http_status(Id)) && --Wait > 0)
    if(!sleep(10)) goto send_error;
  if (!Size) goto send_error;
  if(!http_result(Id,Response,MaxSize)) goto send_error;
  Response[MaxSize-1] = 0; // prevent buffer overrun
  http_free(Id);
  return Response;

// transfer unsuccessful?
send_error:
  if(Id) http_free(Id);
  return NULL;
}

The above code adds an authentication header with signature when Mode == 1. Mode == 2 selects a second, smaller response buffer and thus allows to evaluate two API responses at the same time. The sleep function generates a delay with a heartbeat to keep the Zorro window responsive during long requests. If it returns 0, someone has hit Zorro’s [Stop] key and all operations should be aborted. The Windows _time64 function has only 1-second resolution, so we add an incremented Offset for generating unique timestamps.

We’re now prepared to implement the BrokerAsset function:

double fixAmount(double Value)
{
  int Exp = log10(Value);
  if (Exp >= 0) Exp++;
  return pow(10,Exp);
}

DLLFUNC int BrokerAsset(char* Symbol,double* pPrice,double* pSpread,
double *pVolume, double *pPip, double *pPipCost, double *pMinAmount,
double *pMargin, double *pRollLong, double *pRollShort, double *pCommission)
{
  sprintf_s(G.Url,"markets/%s/ticker",fixSymbol(Symbol));
  char* Response = send(G.Url,2);
  if(!Response) return 0;
  double Bid = strvar(Response, "bidRate", 0.),
    Ask = strvar(Response,"askRate",0.);
  if (Ask > 0. Bid > 0. && pSpread) 
    *pSpread = Ask - Bid;
  double Last = strvar(Response, "lastTradeRate", 0.);
  if(Ask == 0. || G.PriceType == 2) 
    Ask = Last;
  if (Ask == 0.) return 0; // symbol does not exist
  if(pPrice) *pPrice = Ask;
  if(pVolume) {
    sprintf_s(G.Url,"markets/%s/summary",fixSymbol(Symbol));
    Response = send(G.Url,2);
    if (Response) {
      if (G.VolType == 4)
        *pVolume = strvar(Response, "volume", 0);
    else
        *pVolume = strvar(Response, "quoteVolume", 0);
    }
  }
  if (pMinAmount) { // get lot amount
    sprintf_s(G.Url,"markets/%s",fixSymbol(Symbol));
    Response = send(G.Url,2);
    if (Response) {
      *pMinAmount = fixAmount(strvar(Response,"minTradeSize",0.000001));
      if (pPip) {
        int Exp = strvar(Response,"precision",8);
        *pPip = pow(10,-Exp); 
        while (*pPip * *pMinAmount < 0.000000001)
         *pPip *= 10; // avoid too small pip cost
        if (pPipCost)
          *pPipCost = *pPip * *pMinAmount;
      }
    }
  }
  if (pMargin) 
    *pMargin = -100; // no leverage
  return 1;
} 

This function is supposed to return current price, current ask-bid spread, and current volume. It can also optionally request other asset specific parameters when available from the API. Otherwise Zorro will replace them with parameter values from the asset list. Broker APIs rarely provide all requested parameters. Make sure to only calculate and fill a parameter when its pointer passed to the function is nonzero. Most of the pointers are NULL most of the time.

The send function uses the second buffer because we’ll need price requests internally for calculating the account state. For getting lot amount, pip size, and pip cost, two more API requests are needed. The values from the response string are parsed with Zorro’s strvar function. The fixAmount function converts a value to its next-higher power of 10 – for instance, 7 is converted to 10 and 0.07 to 0.1. We’re doing this because we don’t want a strange number for the lot amount. The pip size is calculated from the precision, but we prevent it from going too small. Bittrex has no leverage, so the margin cost is always 100%.    

The next and final function sends an order to the API:

DLLFUNC int BrokerBuy2(char* Symbol,int Volume,double StopDist,double Limit,double *pPrice,int *pFill)
{
  if(!isConnected() || !Volume) return 0;

// compose the body
  char Body[256] = "{\n";
  strcat_s(Body,"\"marketsymbol\": \"");
  strcat_s(Body,fixSymbol(Symbol));
  strcat_s(Body,"\",\n\"direction\": \"");
  strcat_s(Body,Volume > 0? "BUY" : "SELL");
  strcat_s(Body,"\",\n\"type\": \"");
  strcat_s(Body,Limit > 0. ? "LIMIT" : "MARKET");
  strcat_s(Body,"\",\n\"quantity\": \"");
  double Size = labs(Volume);
  if(G.Amount < 1.) Size *= G.Amount;
  strcat_s(Body,ftoa(Size));
  if (Limit > 0.) {
    strcat_s(Body,"\",\n\"limit\": \"");
    strcat_s(Body,ftoa(Limit));
  }
  strcat_s(Body,"\",\n\"timeInForce\": \"");
  if ((G.OrderType&2) && Limit > 0.) 
    strcat_s(Body,"GOOD_TIL_CANCELLED"); // limit orders only
  else if (G.OrderType&1) 
    strcat_s(Body,"FILL_OR_KILL"); // fill all or nothing
  else 
    strcat_s(Body,"IMMEDIATE_OR_CANCEL");
  strcat_s(Body,"\"\n}");

  char* Response = send("orders",1,0,Body);
  if(!Response) return 0;

  char* Uuid = strtext(Response,"id","");
  if(!*Uuid) return 0; // failed
  strcpy(G.Uuid,Uuid);
  double Filled = strvar(Response,"fillQuantity",0);
  if(Filled == 0. && !(G.OrderType&2))
    return 0; // unfilled FOK/IOC order
  double Price = strvar(Response,"proceeds",0);
  if (Filled > 0. && Price > 0. && pPrice)
    *pPrice = Price/Filled;
  if (*pFill) *pFill = Filled/min(1.,G.Unit);
  return -1; 
}

The function first composes a message body in this JSON format (example):

{
  "marketSymbol": "ETH/BTC",
  "direction": "BUY",
  "type": "LIMIT",
  "quantity": "0.1",
  "limit": "0.008",
  "timeInForce": "IMMEDIATE_OR_CANCEL"
}

If the order is accepted, the response has this JSON format:

{
  "id": "12345-6789-007-4711",
  "marketSymbol": "ETH/BTC",
  "direction": "BUY",
  "type": "LIMIT",
  "quantity": "0.1",
  "limit": "0.008",
  "timeInForce": "IMMEDIATE_OR_CANCEL",
  "fillQuantity": "0.05",
  "commission": "0.000002",
  "proceeds": "0.00001",
  "status": "CLOSED"
}

The relevant fields, especially the id, the fill amount, and the fill price, are parsed from the response and returned. The return value -1 indicates to Zorro that the order generated no identifer number, but an UUID. It was stored and can be retrieved with a subsequent command. G.Unit is the lot amount that was generated with the previous BrokerAsset call. 

The remaining functions not described here – BrokerTrade, BrokerAccount, BrokerHistory2, and BrokerCommand –  are implemented in a similar way. You can find them in the full source code in the Source folder of the latest Zorro version. 

Update, November 2023: Bittrex recently announced that they will terminate their operation. So the Bittrex API plugin described herein lost its purpose, but you can still use the code as a template for connecting Zorro to any other broker or crypto exchange APIs – at least as long as they remain operational.  

Binary options, in their most common form, are very different to real options. They are a bet that the price of an asset will rise or fall within a given time frame. If you win the bet, the broker pays your stake multiplied with a win payout factor in the 75%..95% range. If you lose, you pay the stake minus a possible loss payout. You’re trading not against the market, but against the broker. The broker needs you to lose, otherwise they would not make any profit. Even if they really pay out your wins, and even if they do not manipulate the price curve, they can still control your profit with their payout factors. So it seems that even if you had a winning system, the broker would just reduce the payout for making sure that you lose in the long run.

However this conclusion is a fallacy. It can in fact be of advantage for the broker to offer a payout that allows you to win, as long as most other traders still lose. A broker has not the freedom of arbitrarily reducing the payout. He’s competing with other brokers. But why would you want to trade binary options anyway, when you also can trade serious instruments instead? If you wanted a binary outcome, you can also achieve this by opening a Put or Call Spread with real options – and this with a serious broker, much higher payout factors (even > 100% in some cases) and the possibility to sell the options prematurely.

But aside from tax advantages in some countries, there is one single compelling reason that might make a binary options trading experiment worthwhile. Profit and trading cost of a binary option are independent of the time frame. So you can trade on very short time frames, which would be difficult, if not impossible with real options or other financial instruments. You can find a discussion of this problem in the Scalping article.

Binary scalping math

The required minimum win rate for binary trading can be calculated from the broker’s win and loss payout:

[pmath size=16]W~=~ {1-Pl}/{1+Pw-Pl}[/pmath]

W = required win rate for break even
Pl = Loss payout
Pw = Win payout

With 85% win payout and no loss payout, you need a win rate of

[pmath size=16]W ~=~ 1/{1.85} ~=~ 54%[/pmath]

54% win rate seem to be manageable on short time frames. The transaction costs of a non-binary, conventional broker would require a much higher win rate, as in the following graph from the Scalping article:

You had to win almost 80% of five-minutes trades – impossible for a trading system under normal conditions unless you enforce that win rate with some tricks, which however won’t help getting in the profit zone.

So, smaller trading costs on low time frames are the obvious benefit of trading binary options. With all the side benefits of low time frames, such as more data for backtests, and shorter drawdown periods in live trading. But how can we take advantage of that? There are three problems to solve.

Three steps to potential binary profit

1. Find a strategy with a win rate that is better than the W determined with the above payout formula. But be aware that prices on small time frames are strongly feed dependent. Normally you won’t know your binary broker’s price source (if he has any at all). For being on the safe side, test with different historical price data from different serious brokers (f.i. Oanda or FXCM) and stay some percent points above the minimum W.
    
2. Find a way to trade automated. Binary brokers often do not want you to do that. Consequently most do not offer a platform or API for automated trading. But they all have a web interface. So you need either a software tool (such as Zorro) that can send key strokes and mouse clicks to a website, or some other means to get your trades to the broker.
     
3. Find a broker that’s halfway honest. At least one that allows you to really collect your gains. All binary brokers make it easy to deposit, but some follow the philosophy: “If you gave it to me, it’s mine.” Make test withdrawals before you deposit large amounts. Keep the account balance small. Check the broker’s opportunity to manipulate the price curve: the more customers they have and the more bets they handle, the more difficult is it to manipulate without attracting unwanted attention. Retrieve as many information as possible about your broker: Where are they really located? For some reason, fraudsters seem to be concentrated in Tel Aviv. Check what customers say about that broker – but be aware: positive statements on trader forums are often planted by the broker himself.

All those issues make trading binary options sort of “messy”. However it’s the messy methods that sometimes offer the best opportunities. Ed Thorp made his first millions not with ‘serious trading’, but with a Blackjack strategy and with a method to estimate the value of warrants, both also considered messy and hard to calculate at that time.

Step 1: The system

A price curve is no random walk. At least not all of the time. Long time frames are often dominated by trend, short time frames by mean reversion. When transaction costs do not matter, it’s not very hard to find a system with > 54% win rate on 5-minutes bars. Here’s a simple example that exploits the mean reversion tendency of short time frames (script for Zorro):

var objective()
{
	return ((var)(NumWinLong+NumWinShort))/(NumLossLong+NumLossShort);
}


function run()
{
	BarPeriod = 5;
	LookBack = 100;
	NumWFOCycles = 20;
	NumCores = -1;
	
	set(BINARY);
	WinPayout = 85;
	LossPayout = 0;

	set(PARAMETERS);
	int TimePeriod = optimize(20,10,100);
	var Threshold = 0.01*(HH(TimePeriod)-LL(TimePeriod));

	if(NumOpenLong+NumOpenShort == 0) 
	{
		LifeTime = 1;
		if(HH(TimePeriod) - priceClose() < Threshold)
			enterShort();
		else if(priceClose() - LL(TimePeriod) < Threshold)
			enterLong();
	}
}

In the C code above we defined an individual objective() function that optimizes the system for binary trading. It measures the system performance as the number of winning trades divided by the number of losing trades. Otherwise the optimizer would hunt for the most robust profit factor, which makes no sense for binary trading.

The setup establishes a 5 minutes bar period, which is the time frame of our bets. We use 20 WFO cycles and let the optimizer use all CPU cores but one. This way the training run takes about 5-10 minutes for 5 years data. The BINARY flag activates binary trades, and we’re simulating a broker with 85% win payout and no loss payout.

We have a mean reverting system that trades whenever the current price is closer than a threshold – here, 1% of recent volatility – to its previous High or Low. The time period for determining the High and Low is the only system parameter that we optimize. You could improve the system in many ways, for instance by optimizing also the threshold, by modifying the objective() function so that it prefers systems with more trades, and by applying a filter that prevents trading in non mean-reverting market regimes. Since we bet on the price in 5 minutes, we’ve set the LifeTime of a trade to one bar. Here’s the equity curve from a 5 years walk forward test with EUR/USD:

The system has about 56% win rate and a notable, although not spectacular positive return. Which is not achieved by the crude mean reversion mechanism, but mostly by amplifying the small entry-exit price differences through binary trading, even though the payout is only 85%. You won’t get a similar result with conventional trades. The same system not trading binary options, but leveraged forex positions produces a very different equity curve (for testing, comment out the BINARY flag and the Payout settings in the code):

With the same trades we have now only 40% win rate and an overall loss, since all the trade profit is eaten up by spread and commission. 

Step 2: Automatizing

How do you let your script automatically enter a bet at the right moment? This is a technical issue unrelated to trading, but it comes up whenever you have a broker with a web based platform and no proper connection for automatizing. Here’s a code snippet for detecting the positions of [Buy] and [Sell] buttons on a website, and automated clicking them:

void main()
{
	int BuyX,BuyY,SellX,SellY; // button coordinates

// open the browser	
	printf("\nOpening the broker's website...");
	exec("http://financial-hacker.com/shark.htm",0,1);

// get the position of the Buy button
	printf("\nRight click on [Buy]!");
	while(wait(50)) {
		int button = mouse(&BuyX,&BuyY,window(""));
		if(button & 2) break;
	}
// wait until right mouse key released	
	while(wait(50)) {
		int x,y,button = mouse(&x,&y,0);
		if(!(button & 2)) break;	
	}

// get the position of the Sell button	
	printf("\nRight click on [Sell]!");
	while(wait(50)) {
		int button = mouse(&SellX,&SellY,window(""));
		if(button & 2) break;
	}
// wait until right mouse key released	
	while(wait(50)) {
		int x,y,button = mouse(&x,&y,0);
		if(!(button & 2)) break;	
	}

// send mouse clicks to Buy and Sell	
	printf("\nI will now click on [Buy]!");
	keys("[click %d,%d]",BuyX,BuyY);
	printf("\nI will now click on [Sell]!");
	keys("[click %d,%d]",SellX,SellY);
	printf("\nDone!");
}

Start the script, and wait until the broker’s website pops up in your browser. Then follow the instructions in Zorro’s message window. Manoever the mouse onto the “Buy” button and hit the right mouse key. Then do the same with the “Sell” button. The script will store the button positions and then use the keys function to send test clicks to both positions of the active window. For testing purposes I’ve imitated a typical binary broker’s trading platform.

You now only need to glue together your trading script with the button clicking script, and adapt the latter to the website of your broker. This is left as an exercise to the reader. And better use improved versions – the scripts here are kept simple for demonstration purposes. As long as the script trades, make sure that the browser window stays in the foreground, or else it can not click on the buttons. For the position size, either enter a fixed size for all positions, or let your script click into the size field and send key strokes to set individual sizes.

Step 3: The broker

Of course I don’t want to recommend a particular binary options broker. In the end, they’re all crooks – but some are crookier than others. Finding a suited broker is, also, left as an exercise to the reader. Binary broker comparison websites are often – surprise, surprise – installed and paid by binary brokers. US citizens are normally not allowed to trade binary options with brokers that are not regulated in the US. Some brokers will accept your deposit nevertheless, but use that as pretext to refuse payout. If you’re a citizen of Israel, you might not be accepted by many binary brokers since they’re not allowed to fraud compatriots. 

Conclusion

It’s often the “messy” and despised trade instruments that can still provide opportunities when they are correctly understood. I’ve uploaded the two scripts to the 2016 repository. You’ll need Zorro 1.52 or above for running them. When you now make huge profits with binary options, don’t forget where the money comes from: Not from the broker, but from his less fortunate customers that maybe just haven’t read the right blog.

Addendum: From all articles on this blog, this one attracted by far the most spam comments. From them it appears that a new lucrative business has established in the orbit of binary brokers: recovery fraud. As soon as you’ve lost your money, you’ll receive offers by “hackers” or “law firms” to recover it, for a fee of course. Where did they get your email from? Naturally from the very broker that bagged your money…

A broker API allows software to trade, receive price quotes, and download price history. Those three functions are essential for an automated system. Good-to-have additional features are retrieving trade status, account status, and asset parameters. That’s six functions, or seven when you count login/logout. A broker API has often more than 100 functions. So you should assume that at least the 6 essential are more than covered. But sadly, it is not so. The debacle begins already with installing and starting up the API. 

API startup

Installing and starting a broker API can be so simple. The ideal case is a broker that provides no software at all, but just a protocol and a URL for a TCP/IP or UDP connection. You can then use well-established libraries such as curl or enet for connecting to the broker. In the second-best case you get an API DLL that you can redistribute to your clients. Your software then just calls the login function of that DLL, submits the authentification data and the connection is established. But for some unknown reason, many brokers feel obliged to provide connections to their APIs in much more complex and creative ways.

Broker A required any user to run an API installation package. After an installation dialogue with several Windows incompatibility warnings, the installer produced a bunch of DLLs. Then you can go through a lengthy procedure with many steps of building up all the internal tables and data structures that you need for connecting to your account. In a previous version, the installer also modified the Registry, so you could not step around it and distribute the DLLs directly to your clients together with your software. They had to go through the installation procedure themselves. This is fortunately not required anymore with the current version.

Broker B offers no direct connection at all. You have the choice of connecting either to their bloated Java trade platform, or to a small “Gateway” program. When you connect to the Java platform, your software must once per day log out, restart the platform, and log in again since the platform automatically shuts down every 24 hours. When you connect through the “Gateway”, you can not open their platform at the same time (not even from a different PC). So you can’t even check your positions. If you do, the Gateway connection breaks down and must be manually re-established. This is not a bug as you might think. It is intentionally implemented this way (according to the broker) as a service to their users.

Both broker A and broker B are major, world-wide operating Forex and stock brokers.  

Getting price quotes

Broker A keeps its asset prices in a “Quote Table” on his server. For getting a price quote you must first subscribe to that asset. For this you do not just call a function, you build up a “Request Factory” and generate a “Subscription Request”. Now you can enter the procedure of receiving a response on your request, which involves the creation of a “Response Listener”. Subscribing to an asset this way takes about 30 primary lines of C++ code – and this does not include the secondary code for sending the requests, generating listeners, and all the supplementary stuff. My clients can consider themselves fortunate that I don’t charge by code line. Getting the price itself then only requires looking up the asset in the server’s quote table.

Broker B makes it easy: You can not subscribe market quotes by API at all. You must do that manually on their website, and it is not free (except for Forex). For getting the price, a simple API call is sufficient. Or would be, if you knew the primary exchange, secondary exchange, asset type and sub-type, and other asset parameters. If any of them is not right, you get no price. And don’t think that these exchange and other parameters are documented somewhere. You’re supposed to find them out by trial and error, or to ask fellow programmers on the Internet.

Getting price history

Although any algorithm trades in real time, it still needs price history on startup for calculating initial values of its indicators and price-analyzing functions. With no access to price history, you had to wait a couple days before the first trade can be placed. Since this is not really practical, price history is an essential API function.

Broker A provides price history with no major problem. I can almost not believe it. Ok, you must again fire up the “Request Factory”, generate requests and listeners, but about 50 code lines enable you to download historical prices. The broker charges no fee for those prices (you can even download them with a demo account), and at least the recent data, from 2010 and above, is in acceptable quality. Eight out of ten points for the price history from broker A.

Broker B again got creative and enterprising. Their price history from demo accounts is worthless – you must indeed open a real account and deposit $10,000 when you want historical data. This sum, of course, is also required from a poor coder who only wants to implement a function for getting price history. Not that you get it then easily. Technically it’s simple – a few lines of code are enough – but you only have 60 requests. After that, the price history server is shut down for 10 minutes. 60 requests are enough for a single-asset system, but not for starting a portfolio system, and certainly not for backtests. Why this bizarre limit? Maybe broker B can’t afford a fast Internet connection for their price history server. Maybe they are using the CEO’s old PC, located in his living room, and the bandwidth goes down anytime when his kids play Tetris on it. Whatever the reason, that’s only one out of ten points for the price history from broker B.

Is there a broker with even zero points for the price history? Yes, there is: Broker C has no API function for retrieving historical prices at all. Apparently they had not expected that someone would really use their API. I had no choice but to advise my client to choose another broker for his algorithmic system.

Handling trades

We programmers tend to think binary. When we send a fill-or-kill order to the broker API, we assume that the position will be either opened (“yes”), or it will not (“no”). But from time to time, broker APIs produce a third result, like “maybe” or “I won’t tell”. A position that is maybe opened or maybe not can result in an orphaned trade. This is a trade opened by the broker, but not reported back to the trading software, and consequently not under automated control. This trade won’t be closed by a reversal or stop and can thus accumulate a large loss. It can blow the account. Orphaned trades are not a good thing.

Theoretically, they would be so easy to prevent. The API just needs to provide a simple order function with an identifier and a validity limit, like this:

openAtMarket(string Asset, int Amount, int ID, int SecondsValid);

ID = dear broker, please store this identifier together with the trade and use it for retrieving the trade status in case of doubt.
SecondsValid = dear broker, please disregard the order when after the given number of seconds your API still doesn’t know if it can fill it or not, or is unable to confirm it for whatever reason. 

That’s the ideal, but how’s the reality?

Broker A accepts a ton of parameters in his order functions, but no user-supplied trade ID and no SecondsValid limit. After sending an order and going through the usual “Request Factory” and “Response Listener” rigmarole, you’ll receive a confirmation and can retrieve the trade identifier for managing or closing it later. Or you’ll get notified that the order failed. Or neither of both. It happens that the API does not react at all on your order, maybe due to a server hickup, an Internet outage, or because it became confused by too many Factories and Listeners. Then you can only guess if your order made it to the server or not. If it did, you have an orphaned trade. But at least you can relatively easily identify and close it manually.

Broker B provides a simple order function, even with a user-supplied ID. And you get confirmation by a simple callback function that the order was filled or not. Usually not, since broker B needs again lots of information about the asset and the order routing, and won’t execute the order if something is missing or not fitting together. But at least you know the ID. This makes you think that you can later check the trade status. Think again: Broker B won’t reveal any information about your trades. At least not to you. In fact they do not store your trades at all. They only store net positions. So there is no way to identify orphans. Not even manually, since you can’t open the trade platform as long as an automated system is running.

Account parameters and trading costs 

Broker A provides a function where you can request leverage, pip size, pip cost, rollover, and any other parameters of the selected asset. Enough information to calculate margin and trading costs in advance, what is a good thing for an automated system – if there weren’t an important parameter missing. The API does not allow to retrieve the commission. You must enter it manually and store it per asset. Why this important parameter is not provided by the API remains broker A’s secret.

Broker B does not have this problem, as its API provides no asset and trading cost information at all – not even the leverage. For compensation, it supports a sort of “virtual order” that can be used to calculate profit, similar to Zorro’s “phantom trades”. Theoretically you could use that to calculate some of the asset parameters in a complex way from a series of virtual orders with different lot sizes. My clients didn’t pay me for that. For simulating a broker B account in a backtest, you must therefore enter all required asset parameters and trading costs manually in a spreadsheet – which is no easy task due to the complicated fee and margin structure of that broker.

There are APIs for almost all imaginable software tasks. And most are well structured nowadays and relatively easy to use. Why is it not so with most broker APIs? Dear brokers: If you think about providing API access to your customers, please look first into other broker’s solutions for learning how NOT to do it. And if really necessary, please add detailed documentation about which of the market or order parameters are really required and in which combination.

And if you then still are not sure how to implement your new API, just hire me. I had the dubious pleasure to implement dozens of APIs so far, and can show you how an API for algo trading should look like. And even though you’ll then have to hand over some shekels to my employer, you’ll make up for this by winning an excellent reputation. At least among the poor coders and hackers who have to implement your API.

Addendum (January 2017): For the sake of fairness it should be mentioned that broker B has meanwhile removed the bizarre 60 requests limit for historical data. One year of data is now available. Maybe they have read this blog. Or their CEO got a new PC for Christmas. Whatever the reason, it’s still not sufficient for backtests, but at least for live trading even large portfolio strategies.