Scalping algorithm: where results are lost on the real market
The scalping algorithm earns on dozens of short trades: position holding is measured in seconds, and profit per trade is fractions of a percent. In such an economy, the result is determined not by entry logic but by the quality of order execution.
A signal calculated at one price is executed at another — and a trade that was profitable in calculation closes at a loss.
Slippage shows up on fast moves: while an order reaches the order book, the price has already moved, and during market volatility the gap between expected and actual price grows multiple times.
The second problem is partial execution: the volume is closed only partially, the position size turns out smaller than calculated, and the algorithm either fills the remainder at a worse price or remains with unclosed risk.
Separately, there is the difference between the test and real picture. In history, a trade looks executed at the needed price because the calculation does not account for latency to the venue, the order queue, and rate limits.
In the real loop, rejections arrive precisely at peak moments: the venue limits the flow, and the price moves most actively in those seconds — meaning the algorithm loses execution where it is needed most.
The bottleneck is almost never in the strategy itself, but in the chain "signal — order — confirmation from venue": entry logic may be correct, but execution eats the result. We break down how this is closed at each segment.
What changes after implementation: response speed and risk control
After the logic is launched, the strategy itself does not change, but how it executes decisions does. The algorithm assesses liquidity depth before placing an order, so on sharp moves entry occurs at the calculated price rather than at the first available one. This removes the main loss item of scalping — the fee for entering at a moment of volatility spike.
Reducing slippage in volatile sections
The logic splits the volume into parts and selects the order type for current liquidity: where the order book is thin, a limit order with waiting is used; where it is dense, market is taken.
Response latency on the exchange side differs, and on Binance and other venues the logic adapts to actual latency, not the advertised one.
As a result, the average entry price is closer to the calculated one, and trades that previously went into minus already at entry are filtered out before position opening.
Risk limits and protection against a series of losing trades
Risk is limited at three levels: per trade, per series, and per day. Reaching the loss limit closes the position and puts the algorithm into pause until the next window, instead of adding volume in hope of a reversal.
A consecutive-loss counter reduces position size after a specified number in a row, so the series does not grow into a drawdown. Thresholds live in configuration and are changed without editing the core.
Strategy resilience rests on repeatability: identical conditions produce identical decisions. The trade journal and metrics show where actuals diverge from the intent — this is the basis for the next iteration of the logic.
Comparison of execution modes: limit, market, hybrid
Order execution mode determines how much the signal loses on the path from calculation to trade. On liquid pairs, the difference between schemes is fractions of a percent, but with dozens of entries per day it adds up to the main part of the result. Below are three schemes that we build into entry and exit logic, and where each breaks.
| Option | When suitable | Limitations |
|---|---|---|
| Limit order for entry and exit | Calm order book, narrow spread, high order book liquidity | Risk of not being filled and missing the move |
| Market order for entry and exit | Impulse, thin order book, the fact of the trade is important | Slippage on every trade |
| Hybrid: limit entry, market exit | Scalping on liquid pairs as the main mode | Requires separate entry and exit control logic |
Limit mode and working in the order book
A limit order joins the queue and earns on the spread, but execution is not guaranteed. The algorithm keeps it at a set depth from the best price, moves it when the order book shifts, and cancels it if the price moves beyond the threshold.
The limiters are order lifetime and maximum deviation from the calculated price: they prevent the logic from getting stuck waiting.
Hybrid logic: limit entry with market exit
Limit entry reduces the entry price, while market exit guarantees closing the position by stop rather than hanging in the order book. Slippage on exit is limited by order book depth and predictable, unlike waiting for a counter order.
We separately count the share of unfilled entries: if it is above the set value, the threshold is moved closer to the market.
How the work is built: from task analysis to working launch
Each stage begins only after the previous one has produced a reproducible result. This way, implementing a trading strategy does not turn into a series of experiments on a live account, where an error is visible only by drawdown.
Testing on historical data and on a live stream
- Task analysis: on what market behavior the strategy earns and what conditions disable it.
- Data preparation: order book and trades for the required exchanges — with gaps, different time zones, and periods of low liquidity.
- Testing on historical data: running separately on calm and volatile markets, with commissions and slippage. Some hypotheses are filtered out here — this is an expected result.
- Testing on a live stream: the algorithm receives real quotes and makes decisions, but orders are not placed — we compare its reaction with the calculated one.
Launch in observation mode and handover of control
- Test launch with minimum volume: real orders, tight risk limits, manual confirmation of position exit.
- Observation and tuning: compare actual trades with the model, adjust stop rules when behavior deviates from expected.
- Handover of control: logic and parameters in documentation, monitoring panel, stop in one command, training for your team.
Configurations, trade journals, and support regulations
The set of materials is designed for a team that continues work without us: any parameter of the scalping algorithm can be changed without rebuilding the logic, and system behavior in an emergency is described in advance.
Risk management rules and strategy boundaries
- Maximum position size and maximum number of simultaneous orders per instrument.
- Drawdown limit per trading session and the action when it is reached — pause or full stop.
- Restriction on operating during moments of low liquidity and widened spread.
- Automatic stop when the quote stream breaks or data diverges between venues.
- Reducing trade volume after a series of losing triggers until settings are revised.
- Boundaries of allowed values: what can be changed manually and what requires rebuilding the logic.
Documentation and procedure for making edits
Strategy documentation, parameter configuration, and support regulations are kept next to the code and versioned — you can see which setting produced which result on historical data.
The key access policy separates roles: the trading loop has no rights to withdraw funds, and changing limits requires a second signature.
- Procedure for edits: request, testing on historical data, run on the test loop, release.
- Trade journal with full context: parameters at entry, exit reason, execution latency.
- Support regulations: what we check daily, what weekly, whom we notify about deviations.
Case study: how slippage was removed on a thin order book
Initial situation and bottleneck
The scalping algorithm worked on five pairs on the Binance exchange, where two or three orders were held at the first order book levels.
The logic placed limit orders at the last trade price, without calculating available depth: on a calm market, trades went through smoothly, but on an impulse, slippage ate a noticeable part of the calculated profit.
Based on a sample of 1,200 trades, the actual entry price deviated from the target by an average of 0.18%, and every twenty-fifth trade — by more than 0.5%.
The second bottleneck was recovery.
Position state lived only in process memory, so a break in the trade stream or a node restart meant manual reconciliation with the exchange, removing the pair from trading for 40–90 minutes, and missed entries that the algorithm no longer caught up with.
What changed after implementation
Order placement was rewritten: volume is calculated from real liquidity by order book levels, not from the last price; a large order is split; the unfilled remainder is canceled after a set interval.
Reconciliation of actual execution with the model runs in real time — if the discrepancy exceeds the threshold, the pair switches to a gentle mode until the book normalizes.
Recovery was moved to a separate loop: position and open order state is written to disk and reconciled with the exchange at startup; conflicts are resolved according to exchange data. Recovery after a connection break takes 3–4 minutes instead of 40–90.
Metrics were measured on the same set of pairs and the same signal logic. Average slippage fell from 0.18% to 0.04%, the share of trades with slippage above 0.5% — from 4% to 0.3%, and the number of manual interventions per month dropped from dozens to isolated cases.
How does a scalping algorithm differ from an arbitrage bot?
An arbitrage bot earns on the price discrepancy of one instrument between venues: the signal is visible in the order books, and the trade closes when the discrepancy disappears.
A scalping algorithm earns on microstructure — it reads the order flow and micro-movements of price within one venue. Hence different horizons, speed requirements, and sensitivity to costs.
Position holding horizon sets everything else. In arbitrage, a position lives exactly as long as the discrepancy exists — from seconds to hours, if we are talking about funding rates.
In scalping, hundreds of trades per day with profit in fractions of a percent, and the algorithm must manage to open and close before the order flow reverses.
Speed requirements differ in nature, not only in magnitude. Arbitrage needs synchronization of quotes from multiple venues: whoever sees the discrepancy second loses.
For scalping, what matters more is event processing time for one instrument — order book recovery, placing and canceling orders, correct handling of partial execution.
Sensitivity to commission is an order of magnitude higher in scalping.
Profit per trade is comparable to the spread, so the tariff level and slippage turn working logic into a losing one with the same signal — on Binance and other large venues, rebates for limit orders directly affect the viability of the strategy.
Arbitrage has more costs by composition: two legs, deposits and withdrawals, funding; the narrow spread between venues can be thinner than the total round-trip costs.
Therefore, infrastructure is assembled for different tasks: for arbitrage — connectors to multiple venues and risk control for one leg; for scalping — a fast market data stream, a careful execution model, and honest cost accounting in tests.
Technical doubts: latency, liquidity, and venue rejections
The scalping algorithm lives on the boundary between venue speed and incoming data quality. Therefore, honest limitations of the approach are more important than promises: below are the doubts that most often come up during design, and how we close them in the architecture.
The signal arrives with delay — how do we know we are not trading against the market?
Signal delay consists of data receipt, decision calculation, and order sending. We measure each segment separately and set a freshness threshold: stale data does not allow an order to be placed.
We take the order book stream from several sources and compare them with each other — a discrepancy stops trading until the cause is determined.
What to do about venue restrictions — request limits and order volume limits?
Each venue has its own rules on request frequency and order size. The algorithm keeps its own quota counter and operates with headroom, not at the limit.
Some orders are sent deferred, some are canceled before placement — this way the logic does not hit the ceiling and does not receive rejections for no reason.
Connection failures: what happens to an already open position?
A channel break is a normal situation, not an exception.
The position may be open at that moment, so the algorithm has a recovery layer: it reconciles the actual account state with its model and either completes the exit according to the original logic or closes the position by a protective condition.
The market is thin — how does the algorithm behave in low liquidity?
In a thin market, the spread widens, and the volume in the order book does not cover the order — slippage eats the result faster than signal errors.
A liquidity filter by order book depth and turnover disables the instrument when conditions go beyond the set boundaries and returns it after normalization.
Let's discuss the task: what we need from you for assessment and a work plan
To come back with an assessment of the task and a work plan, rather than general wording, we need input data for calculation.
The scope of a scalping algorithm is determined by instrument liquidity, the mode of access to the exchange, and response speed requirements — architecture and labor costs depend on these three things.
What is enough to send or describe in the first message:
- Venues and instruments: which exchanges we trade on, which pairs or contracts are prioritized, where liquidity is concentrated.
- Access mode: trading account with programmatic trading rights, exchange test loop, rate limits.
- Strategy logic, if it has already been formulated manually: entry, averaging, and exit conditions, handling partial order execution.
- Risk profile: allowable drawdown, position size, number of simultaneous trades, stop rule on a losing day.
- Infrastructure: where execution is hosted, which channel to the exchange, resilience requirements during a connection break.
- Data for verification: quote and trade history for the period over which we will confirm the hypothesis.
- Success criteria in your metrics: share of profitable trades, average position holding time, algorithm behavior in volatile sections.
After that, we return with an execution scheme, decomposition of stages, acceptance criteria, and options for supporting the strategy after launch. If some data is missing, we will say directly what needs to be collected, and we will assess that work as a separate stage.