Trading Technology
Building My Own Market Scanner
Off-the-shelf scanners show you what everyone else sees. I wanted mine to see what I define — so I built it.
Every retail scanner is a fixed menu of somebody else's ideas. I wanted to define the setups myself and have them fire in real time. So this is the architecture I'm building — and the parts that are genuinely hard.
The pipeline
How it works
- MARKET DATA FEED
- INGEST / NORMALIZE
- INDICATOR ENGINE
- RULE MATCHER
- ALERTS + UI
The scanner is really four services pretending to be one app. Each stage has a different failure mode, and pretending otherwise is how retail tools stay fragile.
The unglamorous hard part: data
raw ticks -> dedupe -> align to bars -> handle gaps/halts -> indicators
Nobody warns you that 80% of the work is making the data trustworthy. Late ticks, halts, splits, and vendor quirks will happily produce "signals" that are pure artifacts.
A signal on bad data is worse than no signal
The scanner that fires on a data glitch trains you to trust noise. Correctness of the feed comes before cleverness of the strategy — every time.
Making it real-time
Batch scanning on a cron is easy and mostly useless intraday. Streaming — a WebSocket feed into an indicator engine that updates incrementally — is where it gets interesting, and expensive.
Where's the opportunity?
Most traders can't build this. A configurable, correctness-first scanner is a product people pay monthly for.
Streaming data engineering — backpressure, incremental indicators, exactly-once semantics — is a rare and well-paid skill.
Market-data licensing costs are real and can dwarf your infra bill; read the vendor terms before you scale.
Key takeaway
A great scanner is a data-engineering project with a trading skin. Get the feed correct first; the indicators are the easy 20%.
I'm building this in the open — follow it at Real-Time Market Scanner.