Custom trading bot development with any strategy

Why a custom trading bot breaks on a live market

Errors almost never live in the strategy itself.

Failures concentrate in the layer between signal and confirmed trade: according to incident reviews in algorithmic trading, most account stops are due to execution and connectivity, not entry logic (Report on operational failures in algorithmic trading).

A self-written custom trading bot most often falls exactly here — where the math ends and the real order book begins.

Price slippage is the first source of divergence. The logic calculates entry at the last trade price, while actual execution goes through order book levels: on a sharp move, the difference between calculated and actual price eats the strategy's positive expected value entirely.

Next is partial order execution. The order fills part of the volume, the remainder sits in the order book, and the bot already considers the position complete and sends the next order.

The same scenario causes order duplication: the exchange response did not arrive, the module repeated the send without reconciling account state.

A separate class is connection loss with the exchange. The market data channel goes down, while orders and the position on the exchange continue to live.

Without reconciliation on reconnect, the bot either opens a second position or remains without protective stop orders, and risk grows without any signal.

None of these failures can be cured by tuning strategy parameters. A separate execution layer is needed: idempotent order sending, a local state journal, regular reconciliation with the exchange, limits on volume and number of retries. We explain how this is covered.

What custom order execution logic provides

We move order execution logic into a separate layer between the strategy and the venue's trading interface.

The strategy provides only intent — direction, volume, acceptable price deviation — and the layer decides how to implement it: split into parts, place a limit order, or cancel it when the market moves away.

The "decision — sending" gap produces effects visible in the execution journal, not in a "became more convenient" report.

Speed of reaction to a market event

The event handler maintains a persistent connection to the venue and reacts to order book changes without human involvement. The task queue and idempotent order keys prevent sending a duplicate when a message is redelivered.

The path from signal to order is reduced to a single pass through the handler, and the share of unexecuted orders falls — typically from tens of percent to single digits.

The journal of orders and positions is written to PostgreSQL, so divergence between internal state and the venue's response is investigated based on facts.

Risk and position management

Position limit, maximum drawdown per session, prohibition of opposing orders, and auto-stop on desync are checks inside the execution layer, not instructions for the operator on duty.

The failure class "exceeded the limit because I didn't have time to calculate" goes away: excess is blocked before sending.

Fault tolerance relies on reconnecting with state recovery from the journal and reducing the position on connection loss — manual operations remain only as many as the venue's regulations require.

Operating modes: from signal to fully autonomous

Operating mode is not about the degree of trust in the bot, but about the human's place in the trading cycle: signal generation, risk check, order placement, position management.

Which step confirmation occurs at determines both reaction latency and requirements for the execution environment.

Signal and semi-automatic modes

In signal mode, the robot provides a ready calculation: instrument, direction, entry price, volume, stop level.

The human confirms or rejects — and every rejection is written to the journal with a reason, otherwise it is impossible to understand exactly where the strategy loses results.

In semi-automatic mode, the boundary goes deeper: the human confirms entry, while position volume, stop transfer, and partial exits are managed by the robot itself.

The practical value of this pairing is the reverse: it collects statistics on manual decisions and shows which of them should be handed over to the robot.

Autonomous mode and its limitations

The autonomous environment is deployed separately: its own access keys, its own limits on the venue side, isolation from the rest of the infrastructure. If a node fails, open positions remain under control rather than hanging without management.

The limitations of automation do not go away: slippage on a thin order book, partial fills, connection loss during volatility.

Therefore, autonomous mode always comes with safeguards — maximum position size, daily stop, pause on abnormal movement — and before launch, a shadow mode is usually run, where the robot calculates but does not send orders.

How implementation proceeds: from strategy review to code handover

Implementing a trading bot begins not with code, but with formalizing rules: as long as the strategy lives as "you can see the entry by eye," it can neither be tested on history nor handed over to your team.

We break down the logic into unambiguous conditions — what counts as a signal, how position volume is calculated, when the position is force-closed.

Strategy review and venue limitations

1. Strategy review: entry and exit rules, handling partial volumes, bot behavior when there is no signal.
2. Venue limitations: request rate limits, allowed order types, price and volume step, commissions, trading session modes.
3. Scheme of interaction with the trading account: access keys only for trading, separation of production and test environments, storage of secrets outside code.
4. Assembly of logic and safeguards: volume calculation, risk limit per trade and per day, order count limiter, correct handling of connection drops.

Verification before a real account

• Historical data verification: run on quotes over a long period taking into account commissions and slippage, compare the number of trades with expectations.
• Work on a test account: the same rules in real time, adjustments based on venue failures and execution delays.
• Controlled rollout to a real account: small volume, daily reconciliation of bot reports with account history, scaling volumes after confirmation.

Code handover is a separate stage: a repository with change history, startup and shutdown instructions, a walkthrough with your engineers. The code remains with you; you build support yourself or continue with us.

What you receive: code, diagrams, regulations

Bot handover is not an archive with code, but a set of artifacts from which the system is raised from scratch without the author. We deliver by checklist: if an item cannot be verified on a separate test bench, it is not considered accepted.

Code and configurations

• Source code of the bot and strategy modules with revision history — the build is reproducible in a clean environment.
• Configurations for test and production environments: trading pairs, volume limits, timeouts, trigger thresholds.
• Component interaction diagram: signal path from market data to order placement and bottlenecks.
• Access and key storage policies: roles, where exchange access keys are stored, rotation procedure, journal composition.

Documentation and regulations

• Strategy documentation: entry and exit conditions, indicator calculation, deviation signs, and bot shutdown conditions.
• Operations regulations: startup procedure, pre-session checks, on-duty actions when limits trigger.
• Failure recovery instructions: how to reconcile position state with the trade journal and return to work.
• Change procedure: how to add a strategy or parameter and what checks a change undergoes before rollout.

Case study: migrating from an off-the-shelf solution to a custom bot

The client came with an off-the-shelf bot: the strategy worked, but lived inside someone else's logic. It was impossible to change the entry condition or understand why some orders went to manual confirmation. The strategy was migrated to a custom bot while preserving behavior on historical data.

Before

The off-the-shelf solution automatically executed about three quarters of orders, while the rest waited for operator confirmation — the operator sat at the screen during active market hours.

The actual position diverged from the calculated one several times a week: some trades were lost when the channel dropped, and this was discovered only through manual reconciliation.

Downtime on connection loss reached 40 minutes, and during all that time open positions remained unmanaged.

After

The share of automatically executed orders rose to 98%, manual operations remained under two percent — fund withdrawal and risk profile change.

Recovery after a connection drop takes up to 30 seconds: the bot reconnects, reconciles actual state with calculated state, and only then removes the pause.

The "position desync" failure class is closed: every order carries a retry key, and reconciliation runs on every reconnect.

We collect metrics via Grafana — the dashboard shows the share of executed orders, recovery time, and the number of manual interventions by day.

We attach the measurement protocol before and after to the acceptance report: it shows that the issue is in execution logic, not in a change in market load.

What to do if an off-the-shelf solution is already trading on the exchange

A working solution does not need to be turned off to begin migration.

Off-the-shelf bots are limited not so much by strategy logic as by its framework: entry and exit rules are hardcoded, risk management changes only within predefined fields, and test mode calculates on history without a real order queue. These limitations become the reason for migration.

Strategy migration begins with formalization: entry, exit, adds, and stops are described as a specification independent of the previous platform.

Then it is run on the same history and on a recorded order flow, and trades are reconciled with the current bot's log — divergence in price and trigger time shows where we read the market differently.

Compatibility with the current environment is checked before switching: the new bot connects to the account with limited rights — trading allowed, fund withdrawal disabled — and takes over management of already open trades using the same stops.

Then instruments are migrated in groups, the old system remains as a hot standby, and trading does not stop for a minute.

Technical concerns: latency, failures, improvements

Before launching a strategy on a real account, the client checks how the system behaves in non-standard situations: what happens on connection loss with the venue, where keys are stored, how logic is verified before the first trades. Below are the technical questions that most often come up during acceptance.

How is execution latency reduced?

The signal is calculated in the same process as order sending, and the connection to the market data stream is persistent. We log latency from signal to order — the bottleneck is visible in metrics, not discovered through drawdown.

Where are account access keys stored?

Trading-enabled keys are stored encrypted on the client side and do not enter code or logs. Withdrawal rights are not granted to them on the venue, and decryption is via a separate secret.

How is the strategy verified before a real account?

First a run on historical data, then the venue's test environment with a real order flow, then an account with minimum volume. The transition criterion is that behavior matches the calculation, and divergence in execution and slippage fits within the specified tolerance.

Who is responsible for improvements and support after handover?

Changes in venue rules are planned improvements: we modify the adapter and configuration; the strategy itself is not rewritten. After handover, we remain on support: we track changes, update dependencies, and analyze incidents using logs.

Let's discuss your strategy and come back with a plan

For the timeline estimate to be based on facts rather than assumptions, an input environment is needed: the more precisely you describe the rules and limitations, the fewer assumptions we will build into the plan. Send what you have — even a draft in a spreadsheet will do.

• Strategy rules: entry and exit signals, volume calculation, behavior on sharp movement and thin order book.
• Venues and instruments: where we trade, spot or futures market, which order types and limits exist on the venue side.
• Current environment: what already works — manual trades, spreadsheets, scripts, off-the-shelf builds. We will separately note what we migrate and what we rewrite.
• Risk limitations: acceptable drawdown, limit per trade and per day, what the bot does on connection loss and state desync.
• Reporting: which metrics are needed, in what form and where to export them, whether a trade journal with the ability to review disputed executions is needed.
• Data for reconciliation: trade history or test period — we will run the logic on it before rollout to a real account.
• Access environment: where we deploy, who owns the keys, at the first stage read-only rights are sufficient.

Then the order is as follows: we ask clarifying questions on disputed points, show the module interaction diagram, provide a timeline estimate and scope of work by stages — from strategy review and historical reconciliation to launch and support. Describe the task — we will come back with a work plan where each stage has a verifiable result.