[HN Gopher] The high-frequency trading arms race: frequent batch...
___________________________________________________________________
The high-frequency trading arms race: frequent batch auctions
(2015)
Author : philips4350
Score : 83 points
Date : 2021-10-17 14:20 UTC (8 hours ago)
(HTM) web link (academic.oup.com)
(TXT) w3m dump (academic.oup.com)
| twic wrote:
| If you're a market maker, you really, really want to be able to
| do low-latency trading in order to hedge fills before the market
| moves against you. If market makers can't do this, they will make
| worse markets - show less size and wider prices, or just get out
| of the game. How do you do this under continuous batch auctions?
|
| I have an underdeveloped idea that what we really need is limit
| order types with built-in hedging. "Bid to buy 100 gizmos at 30c
| each, and for every five gizmos bought, immediately offer to sell
| 1 widget at $1.20; cancel this order if the best offer for
| widgets moves below that price" sort of thing. Basically, you're
| moving the simple reasoning that has to be executed at low
| latency from the market maker's FPGA to the exchange's matching
| engine.
|
| Sometimes, you can do this by putting orders in spreads, but only
| where a spread exists (or can be defined) for the two legs you
| care about, in the right ratio.
|
| You might also want to do more complicated things, like pulling
| an order in one product if another product moves a lot, because
| you think that presages a move in the product you're quoting.
|
| The idea would be, firstly, to make it much easier to make
| markets without having to invest in low-latency infrastructure,
| broadening the base of participants who can do it, and secondly,
| to reduce the negative impact of speed-blunting interventions
| like continuous batch auctions or speed bumps.
| Nevermark wrote:
| So generalize simple market offers toward time-limited smart
| contracts?
|
| And everyone having the ability to do so at the same level.
|
| Seems like a good idea to me, assuming contract constraints
| that guarantee market resolution system will resolve quickly
| and behave predictably.
|
| And some nano-fees for contract execution to make DNS attacks
| unprofitable (for the attacker, profitable for the market).
| bob1029 wrote:
| There are severe technological consequences for pushing for
| synthetic discrete time. Exchanges that currently execute in a
| serialized fashion may no longer be able to support the trading
| volume if the underlying platform is unable to develop batch
| sizes that naturally align with hardware capabilities and
| timings.
|
| Put differently, I think what is going to happen is you will
| start stacking way more orders at each interval than you can
| process before the next because the wonderful CPU pipelining
| effects get wrecked each time you hit an arbitrary time slice
| boundary. I suppose you could intentionally spin the CPU instead
| of yielding back to the OS during these delays, but that means
| you are not able to process any orders that are _currently_
| arriving, so your tail ends up growing longer and longer.
| atq2119 wrote:
| I would be very worried if the machines actually executing
| orders today were anywhere close to 100% load on average,
| because of the well-known issue where tail latency explodes as
| you get closer to 100% load. So I doubt the relevance of
| everything you wrote there.
|
| Batched auctions require different algorithms, sure. They may
| even be more expensive to execute. I suppose you have to sort
| the batch once instead of sorting as you go. _Maybe_ that makes
| it O(n log n) instead of O(n)? Can you keep a traditional order
| book up-to-date in O(1) per transaction? Either way, seems like
| this should be a non-issue. Even if exchanges need to add more
| shards for order processing, that 's just not a big deal.
| zamadatix wrote:
| Why would a premade queue be worse for pipelining than a random
| queue which you also have to modify as you process on it? Seems
| like a single pause per batch rather than constantly checking
| if the work queue has something new put in it.
| andylynch wrote:
| This hasn't materialised as a problem (batch auctions are one
| on the MiFID II venue models) - some eu venues have run this
| model for around four years now, its definitely less widely
| used than other models but has a niche.
| twic wrote:
| It might not have materialised as a problem because those
| venues are not handling as much traffic as the busiest CLOBs
| are.
| akvadrako wrote:
| Is there any mathematical proof that it's harder to game batch
| auctions than what we have now?
|
| For example, while other markets and the real world moves on, you
| gain info. So the later in the batch you can submit a trade, the
| greater your advantage.
| aserafini wrote:
| That was my initial thought as well: this would just become an
| arms race to submit your trade last? But maybe if the trades
| were priority queued it would negate that.
| fighterpilot wrote:
| Correct. I believe you need to randomize the auction time.
| This massively reduces the speed advantage. Without that
| speed is as important as ever.
|
| How does a priority queue work?
| akvadrako wrote:
| That just leads to the same question: is there proof its
| harder to game random batches?
| harryh wrote:
| _But maybe if the trades were priority queued it would negate
| that._
|
| If the trades are priority queued, then you have just
| recreated the speed "arms race" that this idea hopes to
| eliminate.
| hcarlens wrote:
| The ones that are currently live tend to have features that try
| to negate this (randomised uncrossing times, price collars,
| order priority based on arrival time or size)
| dang wrote:
| One small past thread:
|
| _The High-Frequency Trading Arms Race: Frequent Batch Auctions
| as a Solution [pdf]_ -
| https://news.ycombinator.com/item?id=20003222 - May 2019 (4
| comments)
| carterschonwald wrote:
| While I was at jpmorgan I actually spent some time thinking about
| alternative auction structures (vs the order book model). The
| current trading model is ultimately a mechanization of the rules
| from trading happened in a literal trading floor room, and a lot
| of the structural issues stem from those rules treating time as
| infinite resolution and the speed of information
| propagation/light being instaneous.
|
| There's some interesting details about how large trades are done
| today that could perhaps be better reflected into some element of
| auction design.
| wolverine876 wrote:
| So if we started with a clean slate, no trading room floor
| history framing our perspectives, how could we do it?
| carterschonwald wrote:
| thats that billion/trillion dollar question :)
|
| so I think theres a huge design space, and I think it
| partially turns into a "mechanism design" challenge to
| articulate a landscape of transaction / market auction
| mechanisms that
|
| 1) incentivize maximizing market liquidity
|
| 2) recognize the speed of light is finite, and have that
| inform the minimal time scale matching can happen on.
|
| 3) obviate/remove the need to obscure large trades as a large
| number of smaller trades (which is half the value of so
| called algorithmic trading strategies to institutional
| investors). This could be via having one design constraint on
| auctions be that the market impact of the sum of the small
| trades should be equivalent to the single large trade.
| (ignoring the issue of the exogenous information of there was
| a large trade ).
|
| some interesting knock on consequences of these ideas are the
| following
|
| 1) the larger the time scale you're willing wait for the
| trade to be matched to "the other side", the cheaper it
| should be to trade! (creating liquidity is valuable!)
|
| 2) if you're willing to allow your trade to be "partially
| matched" instead of all or nothing, that too creates
| liquidity.
|
| the point being, you start with "what are all the
| complications of how people do large/complicated trades today
| that should just be trivial with the right auction" is sortah
| my perspective. thats glossing over a lot of complexity and
| other concerns, but those are some high notes.
|
| that said,this is just the tip of the iceberg, and these sort
| of market design questions are genuinely under studied in my
| mind, and i could easily spend hours talking about this in
| greater depth over coffee or such.
| elzbardico wrote:
| What is the benefit for society of allowing HFT? This is what we
| should be asking ourselves.
| H8crilA wrote:
| ETFs only exist thanks to HFT
|
| Have you ever wondered how is it possible that when you buy
| some shares of SPY someone out there is somehow able to collect
| 500 securities to fulfil your order? Even if it's not a literal
| action-reaction, that is what must be happening at the margin.
|
| Also, if you still don't believe me, then try to find out how
| to unpack X amount of shares of SPY (for some non-small amount
| of X) into individual securities. Can you do it yourself, for
| example? Whom to call, where's the button for that, who can do
| it?
| kortilla wrote:
| Better prices when you want to sell your stock
| [deleted]
| hcarlens wrote:
| This type of order book is actually quite common in Europe now!
| It provides an interesting alternative to central limit order
| books and dark pools.
|
| Around the introduction of MiFID II regulation in 2018, several
| exchange operators added these frequent auction books.
|
| Cboe's period auctions book is the biggest of these by volume:
| https://www.cboe.com/europe/equities/trading/periodic_auctio...
|
| In addition to Cboe, Turquoise, Goldman Sachs, UBS, Virtu and
| Aquis also run frequent batch auction venues:
| https://www.cboe.com/europe/equities/market_share/market/ven...
|
| I actually co-wrote a paper about this at the time, and it's very
| rare I get a chance to talk more about it! https://jot.pm-
| research.com/content/13/3/5 (sadly it's paywalled)
| kasey_junk wrote:
| Periodic auctions still need tie breakers. CBOE for instance
| falls back to size then time. This is the same tie breaker that
| some CME futures contracts have used in a continuous order
| book. Those contracts always had more gamesmanship than
| standard price/time contracts when I was trading.
|
| Has that become true in the auction space at well?
| hcarlens wrote:
| When they were first introduced, each of the fba books had
| slightly different mechanics (matching priority, timing,
| price determination), so each book needs a slightly different
| approach. I guess you could see it as gamesmanship, but in
| equity markets dealing with market mechanics properly is just
| part of the job.
| [deleted]
| [deleted]
| bob229 wrote:
| Imagine all of the great minds that are wasting their time in the
| financial services sector and understand why we are doomed as a
| species
| robocat wrote:
| I thought part of the problem is that exchanges charge more for
| faster access (e.g. physical collocation), so the exchanges
| profitability depends in part on creating a bidding war between
| HFT companies?
| harryh wrote:
| Probably worth appending 2015 to the title on HN.
| secondcoming wrote:
| The ad-tech world worked on a Vickery Auction for quite some
| time. I've often wondered what things would look like if the
| financial world worked that way instead.
|
| (Vickery Auctions are pretty much dead now because websites saw
| that bidders were bidding $X and automatically assumed that
| because they weren't getting $X, but rather $(X - Y), they were
| being ripped off)
| chaps wrote:
| Maybe someone can explain how it would work, but wouldn't this
| need a wide price spread to cover risk?
| kamaitachi wrote:
| I was working in HFT as a dev team lead around the time of this
| article (2105).
|
| I remember this was being seriously considered by one of our
| target exchanges (can't remember if it was Eurex or Globex).
|
| Our main HFT trader didn't seem worried - he said that the race
| would just change from a race to pick off an opportunity into a
| race to align with any auction timeframe.
|
| Back then, our strategies were implemented in FGPA so our
| response to events could be timed very accurately. Even randomly-
| timed rolling auctions wouldn't have posed any challenges.
|
| Probably explains why this idea never ended up being implemented
| by any of the major exchanges.
| hcarlens wrote:
| Actually, it got implemented by most major exchanges in Europe
| in 2017/2018 and cboe seems to be bringing this to the US now:
| https://www.cboe.com/us/equities/trading/offerings/periodic_...
| kamaitachi wrote:
| Wow - TIL. Thanks.
|
| I've been out of the HFT business for a while, so i guess
| things have moved on.
| hcarlens wrote:
| Haha yeah! Though times for these auctions are double-digit
| milliseconds, a lifetime for your fpga strategies! And it's
| still fairly niche, these are complementing CLOBs/dark
| pools rather than replacing them. Where did you move to
| from hft?
| kamaitachi wrote:
| Moved into a small company that does process control
| (SCADA) systems development. Took a fairly large drop in
| salary but the work/life balance improved and job
| satisfaction increased.
|
| I'd previously done a lot of work in embedded SCADA
| systems (hence the fit for working with with FPGAs in
| HFT).
|
| I left mainly because I genuinely felt that there was a
| certain futility with ultra low latency trading...it's
| less about trading and more an arms race between quants
| and techies of different companies, all with deep
| pockets.
|
| I guess embedded SCADA systems are my comfort blanket :-)
| anonymouse008 wrote:
| I'm merely an observer, but it feels, intuitively, that
| HFT was great when things were fairly predictable -- or
| more like the major indices and individual names moved a
| most 2% on any given day -- and now, in the post-covid
| era, starting with the DPZ spike, and you could argue the
| TSLA original call buying spree, everything is in
| shambles. A lot of HFTs I know of suffered serious
| losses...
|
| Could you explain, indirectly or without identifiers, why
| now is different than back then?
| ReggieCommaRose wrote:
| I'm not sure about delta one firms but almost all the
| options MM firms have been having record years in the
| COVID / meme stock era.
|
| In broad strokes, the things that hurt market makers the
| most are long winded price trends and accumulation of
| inventory. So generally MMs can and often will eat large
| initial losses (depending on how many wings they happened
| to have owned at the time) when huge volatility spikes
| happen but when the raised volatility stays at that level
| for some amount of time (you'll sometimes hear this
| referred as market "regimes") and the MM was able to not
| blow out from the initial spike they'll more than make up
| their losses from the good trading environment after the
| fact.
|
| Market makers as a whole were suffering during the mid
| 2010s when volatility was low year to year, correlation
| with SPY was high, and all the indices basically just
| went straight up every month.
| amelius wrote:
| If your strategies were implemented in FPGA, they were probably
| not very complicated (considering the things you can do on a
| regular CPU).
|
| Wouldn't markets function better if every participant had a
| reasonable amount of time to make decisions?
| [deleted]
| twic wrote:
| The part of the strategy that lives on the FPGA has to be
| fairly simple, but that doesn't have to be the only part of
| the strategy. You can do all sorts of deep and meaningful
| computation on a real computer, then export some settings for
| a simple event-driven model to the FPGA, updated many times a
| second.
| tedunangst wrote:
| As a retro computing enthusiast who does algo trading from my
| Commodore 64, I would very much like more time to compute my
| trades.
| hansor wrote:
| This is interesting. May I ask how do you do it from
| software poinr of view? As for CPU and memory for sure it
| is possible, but I'm more interested about how do you
| connect into exechange/broker?
|
| Contiki, SLIP, PPP, or maybe some ethernet expansion ?
| twic wrote:
| I'd love to read about you trying to persuade the exchange
| to let you put that C64 in the colo.
| tubby12345 wrote:
| >they were probably not very complicated
|
| They use linear models and soft cores. Plenty complicated for
| the kind of arb you could get executing 500ns tick to trade
| better than the next firm.
| Traster wrote:
| It's not always that straight forward. In the hft space
| you're essentially always responding to 1 event, a trade, an
| order, a cancellation etc. Events are generally spread far
| enough apart that you can consider them independently
| (obviously not always, but often) So it doesn't matter how
| complicated your model is, if you can pose the question "what
| would you do if X happened" to your model then you can
| prepare your fpga with "if X happens do Y". As long as your
| universe of possibilities is tractable (which it often is)
| then an arbitrary model can have all latency sensitive events
| offloaded to fpga.
| im3w1l wrote:
| The way I see it, HFT firms provide liquidity to the market,
| which is good. They do so in an automatic fasion which makes it
| cheaper than the past system of human traders. But they also do
| a speed competition which is mostly wasteful. There may be some
| benefit for the overall market of faster communications but it
| is pretty low.
|
| All systems have waste, some more and some less. This is
| unavoidable. So the discussion might be more productive if it
| was framed like this: Which system provides more benefits with
| _less_ waste? Would frequent batch auctions lead to less
| resources being spent on wasteful racing, and more resources
| performing useful services for other market particpants?
|
| Or if we zoom out even more, the two main purposes of the
| market is allocating capital efficiently to businesses, and
| redistributing money from the working population to retired
| people (401k, IRA). And we can ask which market structure will
| make it better at these tasks?
|
| Framed like this it becomes natural to look at the other side
| of equation. Instead of asking which structure would screw over
| HFT's the most, we can ask which structure would be most
| convinient for say index funds or other mutural funds. And
| which structure would be most convinient for the individual
| stock picker. We could even start to ask which structure would
| help HFT's provide more liquidity with less risk.
| HWR_14 wrote:
| How do HFTs add valuable liquidity to the market? Does the
| 500ns faster transaction time for a block of AMZN matter to
| literally anyone? Other than the two sides of the trade who
| lost some money to the HFT who MITM'd them.
| harryh wrote:
| When someone buys liquidity, they don't do so to close
| their order 500ns faster. They do it to ensure they can
| trade at the current market price because they don't want
| to take the risk that the market will move away from them
| while waiting for a counter-party to trade with.
|
| Those that are comfortable taking this risk can simply
| issue a LIMIT order instead of a MARKET order.
| Retric wrote:
| Swap to an auction batch model and they don't provide
| liquidity, they simply don't have significant stakes relative
| to the number of daily transactions. Essentially their an
| outgrowth of all trades needing to be instantaneous which
| lets them reuse the same capital thousands of times per day.
|
| Add to that the fact HFT are profitable and they must
| therefore provide negative economic value. Either the seller
| or the buyer is failing to capture value.
| twic wrote:
| The idea is that HFTs provide value by tightening spreads.
|
| The slower a market maker is, the more risk they take on
| when they quote, because they are more likely to be caught
| by market moves - less likely to cancel their quote when
| the market starts moving, less likely to be able to hedge
| if they get filled at the start of a move. To make up for
| that risk, they have to earn more per trade. The only way
| to do that is to quote a wider spread [1]. That means that
| real money participants end up paying more when they cross
| that spread.
|
| The value captured by HFTs has not come from real money
| participants, but from other, slower, market makers, and
| they have shared that value with real money participants.
|
| [1] Or to demand a bigger stipend, or steeper maker-taker
| pricing, from the exchange, either of which means bigger
| fees for other participants.
| fighterpilot wrote:
| Nonsense. Trade can be positive sum in utility to both
| parties. One party making profits doesn't imply anything
| about how utility is changing on the other side of the
| trade. If you buy an iPhone, Apple have gotten richer but
| you have also gained something (utility).
|
| Your understanding of HFT is wrong as well. It's not all
| low latency arbitrage. It's also execution finesse, risk
| management and ML-heavy. HFT firms will still be extremely
| active under this new market structure.
| Retric wrote:
| High turnover rates are part of the definition of high
| frequency trading. If your holding positions for 30
| minutes your not doing HFT. Ultimate buyers and sellers
| aren't gaining anything on the timescales we are talking
| about.
| fighterpilot wrote:
| I don't know why you're bringing this up because it's not
| relevant, and nor is it accurate. You can have high
| turnover rates in batch auction strategy as well as a
| continuous trading strategy, this market structure change
| won't change that. And you can have a HFT strat with low
| turnover, e.g in a large tick name that barely moves
| where you might get five latency sensitive trades per
| day.
| Retric wrote:
| Latency sensitivity and Alo trading isn't the same thing
| as HFT.
|
| "Very short time-frames for establishing and liquidating
| positions." strait from the SEC: https://www.sec.gov/mark
| etstructure/research/hft_lit_review_...
|
| Now it's true an individual stock may only see 5 trades
| per day from a HFT algo, but theirs more than just one
| stock. The larger pool of money sitting around waiting
| for those 5 trades the lower your ROI. So, the obvious
| strategy is to reuse the same pool of money to back
| multiple different strategies.
| fighterpilot wrote:
| A HFT that's trading bond futures may only have a handful
| of trades per day and hold for a long time because it's
| hard to liquidate effectively. Sometimes they just range
| all day.
|
| Anyway my point is that it's wrong to think that HFT are
| going out of business with this change because it's a
| fundamental misunderstanding of HFT. There's almost
| always an ML component and always an execution component
| and these two skills are going to be critical to
| profiting off the new market structure. Citadel, Jump,
| Tower, you name it. I promise you they will be all over
| this new structure.
| Retric wrote:
| > all over this new structure
|
| I completely agree, and they are going to use the same
| tools. The question is if this change is a net positive
| trade for the economy, and that I don't know but I have
| heard reasonable arguments in favor.
| joshu wrote:
| alternatively you could have one or more specific crossings once
| a day and be done with the whole problem.
___________________________________________________________________
(page generated 2021-10-17 23:00 UTC)