Creating a National Best Bid/Offer Engine
Today I started, then stopped. Then restarted work on a National Best Bid/Offer engine for my ticker plant system. Basically, the rules are pretty simple: you keep track of the ticks for an instrument by exchange - keeping the latest bid/ask data for each exchange. What you might end up with after a few ticks is something like this:
| Exchange | Bid Price | Bid Size | Ask Price | Ask Size |
| A | 12.50 | 25 | 14.00 | 20 |
| C | 12.25 | 20 | 14.00 | 25 |
| D | 12.50 | 20 | 13.75 | 20 |
The rules say that you look at all the bid prices - pick the largest one, and then sum all the bid sizes for those exchanges where the price is the "best bid". In this case, the best bid is 12.50 and the sizes are (25 + 20) = 45. For the best ask (offer), you look at the minimum asking price, and sum up the sizes that match that value. In this case, the price is 13.75 and the size is a simple 20.
So, there are a lot of ways to accomplish this. One is just to have a cache of all the ticks - organized by instrument, by exchange, and then when a new one comes in you toss out the old, recompute the new NBBO, and then if something has changed from the last time you calculated the NBBO, you send out a new message to the downstream clients. Pretty simple.
The problem with this is that while it's easy, it's a guaranteed two-pass system because you need to first find the best price (of either kind), and then sum all those sizes with that price. Not ideal. Also, there's the possibility that a Quote message from one of the exchange services will have a bid from one exchange and an offer from another. So it's not rally easy to keep the entire message - and I don't really need it. I only really need the data.
So what if I just kept the data?
struct ExchangeData { // bids and asks are separate and organized by exchange float bidPrice[26]; uint16_t bidSize[26]; float askPrice[26]; uint16_t askSize[26]; // ...and this is the NBBO that's generated from it float nbboBidPrice; uint16_t nbboBidSize; float nbboAskPrice; uint16_t nbboAskSize; // ...and a lock to make sure it's all changed atomically boost::detail::spinlock dataMutex; }; typedef struct ExchangeData exch_data_t;
If I have this structure - one for each instrument, in some simple data structure (like, say, a trie), then I can forego the message retention, and just retain the data from the message and update the data in the structure.
But wait, there's more.
If I'm careful about what I do, I can update the NBBO values without having to make a two-pass update. What I can realize is that there already exists, for each tick, an NBBO, and if I just update that by subtracting out the old data, and adding in the new, then the values will always stay up to date. No need to do the two-pass calculation.
The code for just the bid looks something like this:
if ((bidExch != '\0') && (bidPrice > 0.0) && (bidSize > 0)) { // get the exchange as an index into the arrays uint8_t idx = bidExch - 'A'; // see if we need to remove the old bid from the NBBO if ((myExchData->bidPrice[idx] == myExchData->nbboBidPrice) { myExchData->nbboBidSize -= myExchData->bidSize[idx]; newNBBO = (myExchData->bidSize[idx] > 0); } // see if we have a *new* NBBO bid, or maybe just an update if (bidPrice > myExchaData->nbboBidPrice) { myExchData->nbboBidPrice = bidPrice; myExchData->nbboBidSize = bidSize; newNBBO = true; } else if (bidPrice == myExchaData->nbboBidPrice) { myExchData->nbboBidSize += bidSize; newNBBO = true; } }
and with this code, I should be able to maintain a decent NBBO engine with very little latency through the system. I still need to write a few things and test it all out, but it's a really promising start, and I'm excited about the possibilities.
Sweet idea.
UPDATE: This logic isn't going to work. What if I fall out of the NBBO? This code will remove the contribution, but if I'm the only one, then we're left with a bad price and a zero size. I need to fix this. But I still think it's salvageable. The only case when we will have to scan is when there's only one exchange in the BBO, and that one is out. Then, we have to find the next best, and that's likely a scan.