Currency arbitrage is a method of taking advantage of price discrepancies or disparities between

different exchange rates of fiat currencies.

Whilst my first 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 profit 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 profit 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 first layer: $ (USD), (EUR), (JPY)
The first 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 first 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 first 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 final 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 function. 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 find discrepancies quicker.

10

12

W11

W21
W20

W30

W31

So as you can see,

f(x) = ((x W10) W20) W30
f(x) = x {W10W20W30}

(1)
(2)

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 floating rates but with more of a lag. It seems apparent that I may
have found a golden opportunity to settle these discrepancies whilst profiting 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 hidden 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
fluctuation 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.