# XBT presents arbitrage opportunities for algorithmic traders

Currency arbitrage is a method of taking advantage of price discrepancies or disparities between different exchange rates of ﬁat currencies. Whilst my ﬁrst algorithm for automated trading could offer some results when running live data, the drawback was latency. The problem that I found when I came up with this algorithm was that it turned out that my idea had already been around for several years and was being used by investment banks with the resources to proﬁt from differences in pricing. I had no way to access the low fee, high-frequency trading platforms and more importantly, no substantial capital. It wasn’t a drawback being underage because it wouldn’t have been a problem to use a broker through a parent’s name. The issue I would have faced anyway would have been latency. Latency was too much of an issue since banks had access to instantaneous transactions and leverage. The chance to proﬁt from discrepancies in pricing in foreign exchange markets were short windows of opportunity that usually spanned no more than a few seconds. Another problem with latency had nothing to do with those constraints, it was to do with the algorithm that I devised. Assuming there are *n* number of currencies such that the number of nodes in the search tree was *n! *since each path meant that there were (*n *- 1) number of nodes in the following layer () which are all interconnected plus the starting point *x*(£) as a route back. My challenge was to create a search function that would iterate all of the combinations of currencies in a traversal tree such that the logarithmic product of the weights to each node, when cumulated, would be > the starting value *x*. To give you a better idea, here’s a scenario in which it may operate:

- I start off with £1000 (
*x*= 1000) - There are 3 nodes in the ﬁrst layer: $ (USD), € (EUR), ¥ (JPY)
- The ﬁrst search will start at parent node one: $
- The second layer contains 2 child nodes that haven’t been converted to: € and ¥
- The last layer (for simplicity) will just be £ (the start and end point)

*f*(*x*) is the function applied to *x *when the multiplication becomes a product sum of the route’s weights.

So I refer to the paths between the two nodes as weights because the value passed along the link is multiplied by the weight of the route. So for example, right now the exchange rate from GBP to USD is 1.46 and so in the ﬁrst iteration; my *x *value will be multiplied by the weight (W10) 1.46 and the new node value is $1460(£1000 => $1460).

The node has two possible routes like a binary search tree: € and ¥. Since it’s the ﬁrst iteration, it will go for the euro and so the exchange rate from US dollar to the euro (0.86) is retrieved and this weight(W20) is applied to the value moved to the penultimate node ($1460 => €1255,60).

The ﬁnal path is from the euro to the start/end point which is GBP and so the weight/exchange rate from EUR to GBP is pulled from the live rates table and applied (0.80) and so €1255,60 =>£1004.48

1004.48 (*f*(*x*)) > 1000 (*x*) a 0.45% increase can be executed immediately and repeated until the algorithm detects a convergence of the differentials as a rate of change in the disparities increases the cost as a %. Don’t worry too much about that, the basic program was meant to take current exchange rates and search the product functions. As latency reduction is fundamental to this market exploit, I considered adding a module which indexes low volume currencies and historical data (to rank similar frequencies as opposed to an elaborate AI which is far beyond my capability as a programmer) to ﬁnd discrepancies quicker.

So as you can see,

*f*(*x*) = ((*x* * W10) * W20) * W30

*f*(*x*) = *x* * {W10W20W30}

If we were to implement the node network model that I’ve shown you above, you’ll face N-hard O problems if you’re serious about using an algorithm like mine to trade. So, we can easily calculate the arbitrage opportunities by multiplying out the matrix of weights by the *x* value. However, this will only tell you if there is an opportunity and not the vector so you can come up with your own method that suits you. Personally though, I like the idea of working with a 2-dimensional array with string elements to identify the node. However, back to my opening title. The reason why I’ve been seriously considering the algorithm again comes down to illiquid cryptocurrency markets. XBT has more or less tracked the other ﬂoating rates but with more of a lag. It seems apparent that I may have found a golden opportunity to settle these discrepancies whilst proﬁting at the same time. Ever since I’ve looked into it, I’ve found myself more intrigued. Today I added XBT to my original program and not to my surprise I started to get results from only 2 layers (which is actually a lot better than elaborate routes which are too delayed and incur too many transaction fees). For instance, one of the opportunities was to convert British Sterling into Bitcoin then Euro and British Sterling. The result with £1000 was £1033 (rounded to nearest int.) and this wasn’t a short ﬂuctuation but rather a difference in exchanges. The trouble with BTC rates is the variance amongst different exchanges. There is not a consistent tracker for the price but they are roughly aligned for average trading. This is ideal for currency arbitrage and I wouldn’t be surprised if others were trying this out.