The Fifteen Basis Points That Choose My Trades
Suneet Malhotra
Jul 16, 2026
There is a line in my crypto book guardrails that reads, in full: limit orders only, never market. Two lines below it, the slippage band: 0.15 percent through the bid or ask when no limit price is supplied. The entry recipe spells the same thing out arithmetically, a buy priced at the ask times 1.0015, resting good-til-canceled. I wrote those rules to control what a bad fill can cost me. That is not what they do. They are the rule that decides which trades I end up holding, and cost control is the smaller half of the job.
A limit order priced through the touch is a market order with a leash
Start with what ask times 1.0015 actually is. It is not a patient bid sitting below the market waiting for someone to come to me. It is a buy order priced above the best offer, which means it crosses the spread on arrival and takes whatever is resting there. Functionally it is a market order. The only thing the limit adds is a stopping rule: sweep the book, but stop at fifteen basis points through the touch and do not chase past it.
That distinction is the entire point of the guardrail, and it is a good one. A pure market order has no floor under how far it will walk. This one does. But calling it a limit order flatters it. It is marketable, it is aggressive, and on any ordinary fill it behaves exactly like the market order the guardrail forbids. What I bought with the limit type is not patience. It is a maximum.
The band is one number wearing two hats
Here is the part I did not think through when I wrote it. Fifteen basis points is simultaneously two settings, and they are welded together.
Hat one is the cost cap, the thing I intended. No single entry can pay more than fifteen basis points of slippage against the touch. Clean, bounded, easy to reason about.
Hat two is the fill probability, the thing I did not intend. Every order that would have needed sixteen basis points to fill does not fill. It rests. And a resting good-til-canceled buy in a market that has walked away from it is not a trade waiting to happen, it is an order waiting to be wrong.
I cannot tune one hat without moving the other. Tighten the band to five basis points and I have not reduced my execution cost, I have converted it into a different risk. I now pay less on the fills I get and I get a different, smaller, worse-selected set of fills. The cost did not go away. It moved somewhere my logs do not have a column for.
The fills I miss are not a random sample
This is the part that should bother anyone running a band like mine. If non-fills were randomly scattered across my signals, the band would be a pure cost control and tightening it would be free. But they are not random. They are selected, and selected against me.
Think about which orders need more than fifteen basis points to fill. They are the ones where the book emptied out between my decision and my order arriving, because the price was moving. Moving which way? Away from me. A buy that cannot fill inside the band is, disproportionately, a buy on something that is already running. And a signal that is already running is, on a momentum book, precisely the setup I most wanted to be in.
Now the other side. Which orders fill easily, instantly, well inside the band? The ones where there is plenty of size resting on the offer, patient and unhurried, happy to sell to me at the touch. That is a book that is not going anywhere, or is coming back toward me.
So the band does not sample my strategy uniformly and shave a little off the top. It runs a filter: it preferentially rejects the trades that were about to run and preferentially accepts the trades that were content to sit. My realized book is not my signal minus a cost. It is a biased subsample of my signal, and the bias points at the trades I wanted least. This is textbook adverse selection, the same mechanism Copeland and Galai and later Glosten and Milgrom described for market makers in the 1980s, arriving at my account from the other side of the table. A resting order is an option I wrote to the market for free, and the market exercises it exactly when doing so is good for the market.
My own stack takes both sides of this trade
Nine days ago I published a post arguing that a protective stop is correctly a market order, because a control whose entire purpose is guaranteeing the exit should buy certainty of exit and eat whatever price that costs. Stop limit, I wrote, caps the price and uncaps the fill, which is the wrong trade for that particular job.
Then I read my own crypto guardrails, where the execution invariant says never market, and the very next clause says a stop price upgrades the order type to stop limit. Four lines further down, exit protection is sacred, never cancel it.
So the control I named sacred is the one I built with uncapped fill risk, in the book where the rule forbids the order type I argued for. Those two posts cannot both be right about the same engine. They are not the same engine, the equity side and the crypto book make different choices for different reasons, and I am not going to pretend the tension resolves cleanly just because the repos are separate. It is a real disagreement sitting inside my own stack, in writing, in two files I wrote.
What I can and cannot claim here
Everything above is config and mechanism. I have read the guardrail lines and the entry arithmetic. I have not measured my own fill rate, my realized slippage, or how many entries died resting inside that band, because from where this routine runs I read committed rules, not an execution log. I am not going to invent those numbers, and the argument does not need them: the selection effect follows from the structure of a book, not from my particular tape.
The claim I will stand behind is that a slippage band is not a cost parameter. It is a selection parameter that presents as a cost parameter, and that disguise is what makes it dangerous. A cost you can see in a fill report. A trade you never got is invisible, uncounted, and shaped like exactly the trade you built the strategy to catch. Fifteen basis points is not what I pay. It is what I am willing to be chosen by.
Share this post
You Might Also Like
A Retry Is Not a Trading Decision
A rejected order is a decision. Retrying it without preserving the reason can turn a risk control into a duplicate trade.
Quantitative TradingThe Market Is Closed Is Not a Trading Rule
A backtest can know the exchange hours and still schedule a trade into a holiday, an early close, or a stale session. Calendar state is market data.
Agentic AIThe Log Is Part of the Agent's Interface
An agent that can act but cannot leave a useful decision record is not autonomous. It is an opaque process with write access.
Agentic AIThe Agent Did Not Need More Context
When an agent edits a shared checkout, the dangerous variable is not context length. It is the boundary around what the run is allowed to write.
Latest Blog Posts
A Retry Is Not a Trading Decision
A rejected order is a decision. Retrying it without preserving the reason can turn a risk control into a duplicate trade.
The Log Is Part of the Agent's Interface
An agent that can act but cannot leave a useful decision record is not autonomous. It is an opaque process with write access.
The Market Is Closed Is Not a Trading Rule
A backtest can know the exchange hours and still schedule a trade into a holiday, an early close, or a stale session. Calendar state is market data.
Related Tools & Demos
The QA Field Manual to Language Models
A free 24-chapter book. Start at βwhat is AI, really?β and finish with a small language model you built yourself β one that reads a failing Playwright test and proposes a fix you can run. Read it in your browser, or download the PDF or the Mac app.
View Source Code βMulti-Model LLM Harness
One interface to call any AI model β capability routing, fallback chains, budgets, circuit breakers, and a quality feedback loop. A practical architecture pattern write-up.
Automated Trading System
Multi-engine trading platform with real-time risk management, regime-based strategy selection, and automated order execution.
View Source Code β
Stay in the Loop
Get weekly insights on AI-driven QA, engineering leadership, and automation strategies.
No spam, ever. Unsubscribe anytime.