# How can we reverse engineer a market-making algorithm (HFT)?

Consider a market participant $A$ who is mechanically following an automated liquidity providing algorithm (HFT) in a number of large cap stocks on a specific exchange.

Assume furthermore that we are able to observe all orders placed by $A$ and that we know that the algorithm used by $A$ takes only public market data as input. $A$ starts and ends all trading days with zero inventory.

We want to reverse engineer the algorithm used by $A$. Let's call this algorithm $f(...)$.

The first step in reverse engineering the algorithm $f(...)$ would be to collect potential input variables to the algorithm that can later be used to infer the exact form of $f(...)$.

The first problem we face is which input variables we should collect in order to be able to reverse engineer $f(...)$.

To have a starting point we can consider the input variables used in Avellaneda & Stoikov (2008). In Avellaneda & Stoikov (2008) the authors derive how a rational market maker (non-specialist) should set his bid and ask quotes in a limit order book market. The results are obviously contingent on the assumptions and model choices made in the paper.

The optimal bid (or ask) in Avellaneda & Stoikov (2008) is a function of the following inputs:

• The trader's reservation price, which is a function of the security price ($S$), the market maker's current inventory ($q$) and time left until terminal holding time ($T-t$)
• The relative risk aversion of the trader ($\gamma$) (obviously hard to observe!)
• The frequency of new bid and ask quotes ($\lambda_{bid}$ and $\lambda_{ask}$)
• The latest change in frequency of new bid and ask quotes ($\delta\lambda_{bid}$ and $\delta\lambda_{ask}$)

What potential input variables should we collect in order to be able to reverse engineer $f(...)$?

I'll take a stab at it, but this is a really broad question.

A direct answer: Bayesian models often use "probability that the counter-party is informed."

Indirect answers: I think your assumption is that the algorithm operates on each stock individually, and has no knowledge of what it's doing in any other stock. But, it is likely that the algorithm is doing some hedging that you don't see yet. You should look at similar products (or build synthetic baskets) and see if your algorithm is changing it's quote sizes/prices when other products' quote sizes/prices change. (It is also possible that the algorithm is aware of all orders/positions it has in all stocks and it leaning more heavily on some bid/offers than others as it tries to flatten out delta (beta) of the entire portfolio.)

If you're certain that the algorithm is working on an individual name with only that stock's orderbook as input, then I would study the active orders to see when and why it gets out. (maybe the only active orders are at the end-of-day flattening, in which case, I would study the canceled orders.) It's easy to make a little money working bids and offers most of the time, but at some point you will get run-over unless you know when to get out of the way (and/or hedge). I'd also look for times when the algo pauses. Are there times when it doesn't have both a bid and an offer in the book? If so, these are times that it is unsure, or it is at it's position limit (should be pretty easy to distinguish which is which). It might be helpful to see what it going on when it is 'unsure' that wasn't going on when it was 'sure.' This will help you eliminate possible parameters.

Long, long, ago, we used a micro-pricer to come up with an estimate of where the real price was using things like qty traded on the ask vs. qty traded on the bid, and sums of bid and ask sizes. Initially, the micro-pricer worked as a stand-alone high-frequency liquidity-taker. Then it became a piece in a market-making algo that was just a way to know when to cancel orders.

I'm assuming that the algorithm is a black box. [You can't see any or all of the inner workings].

You would reverse engineer it like you would anything else:

1. Collect evidence of events [Signals to buy/sell, quantities], and the environment that it operates in.
2. Make theories, and then model them.
3. For each of the theories: Make a convincing argument for the events, or a case to disprove the model.
4. The strongest model that you have is your "best believe". If you completely disprove a model, then eliminate it, and write up something on why. [This is so if you come back to the same question you can re verify the beliefs]

Remember market data, and systems will always be noisy [as will human traders]. You can develop hyptohesis, but rarely ever can you prove something.

There is a research paper that attempts to do just that: http://www.cs.ucr.edu/~cshelton/papers/docs/orderflow_emm.pdf

no personal experience implementing anything like that.