Update: I told bbg (Karin?) and Trex interviewers that domain isn’t a big concern to me. Even a back office IT role can turn out to be better.

  1. quantDev
  2. algoTrading
  3. bigData

… are the 3 big directions for trySomethingNew. I’m cautious about each.

quantDev — low demand; poor market depth; unable to find another job; See also %% poor accu ] quantDev

algoTrading — perhaps I should try java and medium frequency?

bigData — no consolidation; questionable accumulation and value-creation


market-depth^elite domains esp.algoTrading

I used to dismiss “commodity” skills like market data, risk system, J2EE… I used to prefer high-end specializations like algo-trading, quant-dev, derivative pricers.

As I get older, it makes sense to prefer market depth rather than “elite”(high-end niche) domains. A job market with depth (eg market-data) offers a large number of positions. The typical salary of top 10% vs the median are not very different — small gaps. In contrast, the elite domains feature bigger gaps. As I grow older, I may need to reconsider the specialist vs generalist-manager choices.

Reminders about this preference (See also the spreadsheet):

  1. stagnation in my orgradient
  2. may or may not use my specialist skills in math, concurrency, algorithms, or SQL …
  3. robust demand
  4. low churn — a critical criteria whenever I mention “market depth”. I don’t like the market depth of javascript and web java.
  5. salary probabilities(distro): mgr^NBA#marketDepth etc

–case study: Algo trading domain

The skillset overlap between HFT vs other algo systems (sell-side, OTC, RFQ, automated pricing/execution..) is questionable. So is “accumulation” across the boundary.  There seems to be a formidable “dragon gate” — 鲤鱼跳龙门.

Within c++ based HFT, accumulation is conceivable. Job pool is so small that I worry about market depth. My friend Shanyou agreed that most of the technical requirement is latency. C/C++ latency techniques are different from java.

Outside HFT, the level of sophistication and latency-sensitivity varies. Given the vague definition, there are many (mostly java) jobs related to algo trading i.e. better market depth. Demand is more robust. Less elitist.

## algoTrading jobs I almost got #!!buy-side

  1. c++ BNP I got an offer in 2012 but walked away
  2. c++ ArtOfClick I got an offer in 2015 but walked away

So I think it’s not impossible. It’s just very hard. All the buy-side job interviews I have failed to impress.


algo trading engine from scratch: ez route

Start by identifying some high-quality, flexible, working code base that’s as close to our requirement as possible. Then slowly add X) business features + Y) optimizations (on throughput, latency etc.) I feel [Y] is harder than [X], thought [X] gives higher business value. Latency tuning is seldom high-value, but data volume could be a show-stopper.

Both X/Y enhancements could benefit from the trusty old SQL or an in-memory data store[1]. We can also introduce MOM. These are mature tools to help X+Y. [3]

As I told many peers, my priorities as architect are 1) instrumentation 2) transparent languages 3) product maturity

GTD Show-stopper: data rate overflow. Already addressed
GTD Show-stopper: frequent[4] crashes. Unlikely to happen if you start with a mature working code base. Roll back to last-working version and retest incrementally. Sometimes the crash is intermittent and hard to reproduce 😦 Good luck with those.

To blast through the stone walls, you need power tools like instrumentation, debuggers … I feel these are more important to GTD than optimization skills.

To optimize, you can also introduce memory manager such as the ring buffer and custom allocator in TP, or the custom malloc() in Facebook. If performance doesn’t improve, just roll back as in Rebus.

For backend, there are many high or low cost products, so they are effectively out of scope, including things like EOD PnL, position management, risk management, reporting. Ironically, many products in these domains advertise themselves as “trading platforms”. In contrast, what I consider in-scope would be algo executor, OMS[2], market data engine [2], real time PnL.

— The “easy route” above is probably an over-simplification, but architects must be cautiously optimistic to survive the inevitable onslaught of adversities and setbacks —

It’s possible that such a design gradually becomes outdated like GMDS or the Perl codebase in PWM-commissions, but that happens to many architects, often for no fault of their own. The better architects may start with a more future-proof design, but more likely, the stronger architects are better at adjusting both the legacy design + new requirements

Ultimately, you are benchmarked against your peers in terms of how fast you figure things out and GTD….

Socket tuning? Might be required to cope with data rate. Latency is seldom a hard requirement.

Threading? single-threaded model is probably best. Multiple processes rather than multiple threads.

Shared memory? Even though shared memory is the fastest way to move data between processes, the high-performance and high-throughput ticket plant uses TCP/Multicast instead.

MOM? for high-speed market data gateway, many banks use MOM because it’s simpler and flexible.

Inter-process data encoding? TP uses a single simplified FIX-like, monolithic format “CTF”. There are thousands of token types defined in a “master” data dictionary — semi-static data.

GUI for trader? I would think HTML+javascript is most popular and quick. For a barebones trading engine, the GUI is fairly simple.

Scheduled tasks? Are less common in high speed trading engines and seldom latency-sensitive. I would rely on database or java/c++ async timers. For the batch tasks, I would use scripts/cron.

Testing? I would use scripts as much as possible.

[1] eg: GMDS architect chose memory-mapped-file which was the wrong choice. [2] both require an exchange interface
[3] data store is a must; MOM is optional;
[4]If it crashes once a day we could still cope. Most trading engines can shut down when market closed.


%%algo trading experiences # !!HFT

Hi HK,

I’m considering algo trading developer positions. I have some relevant experiences:

  • [Citi] generating and updating limit orders in response to market data changes. Need to brush up on the basic principles since I was asked to elaborate, but a developer probably doesn’t need thorough understanding.
  • [Baml] low-speed, low volume (bond) order management using very few FIX messages with trading venues to manage order state. This is probably the most valuable algo-trading project I have worked on.
  • [NYSE] high volume, fault-tolerant market data processing
  • [NYSE] exchange order book replication. I also implemented smaller order books from scratch, twice in coding interviews.
  • [Barclays] converting raw market data into soft market data such as curves and surfaces, essential to algo trading in bonds, FX-forwards, equity options.
  • [Baml] real time ticking risk, useful to some traders if reliable
  • home-made FIX server/client
  • [Citi and Baml] real time trade blotter
  • [Citi] very limited experience supporting an ETF algo trading system
  • [OCBC] simple automated quote pricer in response to client RFQ
  • [UChicago] school project — pair trading

However I feel these experiences are seen by the hiring managers as insufficient. What are the gaps you see between my experience and the essential skills?

? very limited OMS experience
? latency optimization
? network optimization


execution algo^algo strategy

I think the “exec algo” type is lesser known.

  • VWAP is best known example
  • bulk orders
  • used by many big sell-sides (as well as buy-sides) to fill client orders
  • the machine acts as a robot rather than a strategist
  • goal is not to generate alpha, but efficient execution of a given bulk order



[15]essential GTD/zbs to build algo trading system


(See also post on HFT)

Just to share some observations and reflections. More than one Asia (and to a lesser extent US) recruiters have reached out to me as a potential lead-developer for a HFT engine, to be created from scratch. I believe there are not many old hands in Singapore. Even in the US, this is a relatively small circle. Not a commodity skill.

A small trading shop would have very different needs than a big bank, so their HFT engine will use off-the-shelf tools for most but the most critical, customized modules. (I had a brief blog post on it.) What are the 10 essential know-how i.e. Essential functionalities you must know how to create (prove)?

  • executing strategy for order origination, i.e. machine trading
    • market data processor, sockets
    • order book replicated from market data? perhaps at the center of the engine
    • OMS (Kenny) ? in some cases we leverage the exchange query API or 3rd-party solutions
  • [W] FIX or other order submission protocol
  • in-sample testing. I used Matlab for this. Can be much simpler than the production system.
  • [3] real time pnl, updated by market data
  • [3] barebones blotter, or perhaps command line interface?
  • [3] store historical data for analysis. Perhaps SQL or KDB.
  • [3N] reference data
  • [3] post-trade STP

Low-level tech knowledge
• [N] threading
• [NW] Boost
• debugger
• [N] memory leak detection
• [W] socket programming

[3 = 3rd party products could be good enough in Every component, but this one is more likely]
[N = Not needed in every shop, but often required by interviewer]
[W = my weakness, relatively speaking]


mean reversion, deviation detector, pattern recognition

Nothing, including real time mkt data analyzers, can predict the future. They can point out unusual deviations which often precede reversions to norm. In such a case timing is unpredictable though.

Case in point — When I saw historical highs in copper price, I thought it would drop (reversion) within hours, or at most couple of days, but it just kept rising and destroyed my position. (A necessary condition for my undoing is margin. No margin, no collapse.)

I guess China Aviation Oil might have something like this?

Such a reversion is one type of pattern. Some patterns have a strong rational, logical basis. Consider historical vol’s mean reversion pattern. Consider the widening spread on-the-run vs off-the-run.
Mean reversion is one type of deviation detector.

execution risk in a VWAP execution algo

Background: VWAP strategy is known to have minimal market impact but bad “execution risk”.

Suppose you are given a large (500,000 shares) Sell order. Suppose your goal is minimal market impact i.e. avoid pushing up the price. What execution strategy? I don't know about other strategies, but VWAP strategies generally participate according to market volume, so given a decent implementation the market impact is often … reduced.

I think the idea of the Exec risk is the _uncertainty_ of the final block price. If an implementation offers a very tight control and results in well-controlled final block price, then exec risk is small. explains with an example —

suppose MSFT trades 30 million shares on an average day. If a trader has three million MSFT shares to trade, a VWAP algorithm may be appropriate. However, if the trader

gets 30,000 shares of MSFT to trade, then the savings of market impact (by spreading the trade over the whole day) is not significant compared against the opportunity cost the trader could save by trading the stock within the next few minutes. Quick execution means the uncertainty (or std) in “final block price” is much reduced. With a small order you would achieve something close to the arrival price.


vwap execution chasing the wrong signal – my guess

A vwap algo starts with a “model profile”, which tells us each hour (or minute) of the trading day typically experiences how many percent of the total daily volume.

Then the algo tries to execute according to the model profile, executing 10% in the first hour. The actual market profile may show a spike in the second hour. Suppose 2nd hour usually gets below half of first hour according to the model profile, but we see it's going to more than double the first hour, because the past 5 minutes show a very high spike in volume.

Question is, should we increase our trade rate? I guess there's reason to do so. When the volume spikes, we should trade bigger chunks so as to let the spike “mask and absorb” our market impact. If we don't capture this spike, then 2nd hour might end up being 80% of daily volume, but we only put in 4% our quantity, so our remaining quantity would cause market impact.

However, it's also possible to chase the wrong signal. The spike might cause a large rise or (more likely in realistic panic-prone markets) drop in price, which could reverse soon. Suppose we are selling a big quantity and the spike causes a big drop. Our active participation would further deepen the drop. We might do better to patiently wait for a reversal.