Trading Bot Development: Where Custom Solutions Break
A custom trading bot usually passes tests confidently in a calm market and breaks in the first minutes of real volatility.
The reason is not the strategy but the engineering wrapper: it was written for the “happy path,” where an order is always filled in full, the exchange response arrives instantly, and the operator has time to react manually.
The most common failure is position desynchronization. The bot maintains its own view of the balance and open volumes but reconciles with the exchange rarely or not at all.
One partially filled order, a rejected order, or a connection drop at the moment of placement—and the local state diverges from reality. Then the bot calculates risk from an incorrect base and opens a volume that is not in the account.
The second bottleneck is race conditions with simultaneous orders. Signals come from several sources, handlers write to a shared state object without locks, and a repeated placement request is not recognized as a duplicate.
The result is doubled positions and stop orders that no one placed. There is often no limit control: the maximum position check lives in a separate place and is not applied to every execution path.
The third is manual intervention exactly when it is most dangerous. Without a decision log, response-latency metrics, and alerts, the operator learns about a problem from drawdown rather than from an event.
In industrial trading bot development, these points are closed in advance: periodic reconciliation with the exchange as the source of truth, idempotent keys for every order, limits inside a single handler, and automatic stop on divergence. We'll examine how this is arranged in our environment below.
What an Externally Managed Trading Bot Provides
Trading bot control is moved to an external environment: commands, parameters, and stop flags come from the server side, not from a terminal window.
Because of this, reaction to a market event fits into fractions of a second—manually, a trader has time neither to assess the order book nor to place an order. Reaction speed stops depending on who is watching the screen.
Risk control is built in before an order is sent, not after. The position size limit, daily loss, and number of trades per unit of time are checked on every signal, so an order that violates the rules does not go to market. This closes a whole class of failures: mixed-up volume, an extra order, a manually removed stop.
The resilience of trading logic rests on the fact that rules and parameters are moved into configuration and versioned. Changing a strategy is a separate version that can be rolled back, not an edit of production code on the server. After a failure, the bot starts up and restores state from the trade log and open positions.
Execution automation is visible in the share of situations the bot handles without a human: standard entries and exits, moving stops, time-based closing. The operator intervenes only where a decision is needed—for example, with a data anomaly or an exchange halt.
Recovery time is measured in minutes: state is not assembled manually but restored from the log, and orders are reconciled with actual positions. Next, we break down how such an environment is assembled and what remains under the team's control.
Deployment Options: Cloud, Dedicated Environment, Hybrid
The bot's placement determines not the speed of an individual order but how the environment survives a failure: a channel break to the exchange, a node crash, network latency at the moment the spread widens.
The choice comes down to three schemes, and they differ not in hardware power but in who is responsible for availability and key security.
Launch constraints are also set by regulations: where the trade log is stored, who has access to it, and how much time it is acceptable to be out of the market. Hence the mapping table—it is usually what resolves disputes within the team.
| Option | When it fits | Limitations |
|---|---|---|
| Public cloud | Strategy launch, a small set of instruments, trade history can be stored with the provider | Co-tenancy with other workloads, unstable network latency, provider-side limits |
| Dedicated environment | Operation under internal regulations: keys and the trade log remain in your own infrastructure | On-call duty, updates, and the backup communication channel are handled by the customer on their own |
| Hybrid scheme | The trading core requires minimal latency, while calculations and reporting require a managed environment | Two environments must be linked and synchronized; the gap between them itself becomes a failure point |
Fault tolerance of the environment is assembled according to one logic: a state replica, process auto-restart, and a backup channel to the exchange.
In a dedicated environment, an orchestrator such as Kubernetes brings a crashed process up in seconds; in the cloud, the provider does this; and in a hybrid, both parties do, so we describe the boundaries of responsibility in the regulations in advance.
How Implementation Proceeds: From Strategy Review to Handover
Before writing code, engineers describe the current trading logic: which signals, at what price orders are placed, and what happens during partial execution and a connection drop. Otherwise, the bot reproduces the errors of manual trading—only faster.
Procedure and Checkpoints
- Logic audit. We analyze entry and exit, leverage usage, averaging, and stop orders. We record which decisions remain with a human and what to do with an open position by the end of the session.
- Interaction scheme with exchanges. We determine which data comes as a quote stream and which comes via separate requests, and how access keys are stored. We separate permissions: withdrawal of funds is unavailable to the bot.
- Control and limits. A control environment via a software interface: start and stop, changing parameters on the fly, limits on position size, number of orders, and daily loss with auto-stop.
- Historical testing. A run on historical data accounting for commissions, slippage, and latency, then on the exchange's test environment. Divergence from manual trading is a reason to rebuild the logic, not to tweak parameters.
- Acceptance tests. Connection drop, repeated order submission, insufficient balance, sharp price movement. For each scenario—expected behavior and a log entry.
- Handover to operation. We version the logic and configuration in Git: rollback to the previous state takes minutes. We hand over the scheme, instructions, and access; after that—support and refinement when exchange rules change.
Configurations, Schemes, and Regulations You Receive
Trading bot development ends not with a running process but with a package by which it can be launched, maintained, and handed over to another team. Below is what you receive along with the code: configurations, schemes, policies, and regulations.
- Trading bot configuration files — strategy parameters, trading pairs, volume and risk limits, and a switch between test and production mode. Everything is moved out of the code: behavior changes by editing configuration, without a new build.
- Integration schemes — how the bot is connected to exchanges via the management REST API, where position and order state is stored, and what happens during a connection drop and repeated request submission.
- Access policies and roles — keys with reduced permissions, separation into read, trade, and administration, secret rotation procedure, and their storage location.
- State storage scheme — the structure of the trade and event log, retention period, and the procedure for restoring state after a process crash without duplicate orders.
- Operational regulations — what to do during position desynchronization, exchange unavailability, or a loss limit trigger: steps, responsible parties, and response times.
- Monitoring and notifications — a list of metrics, trigger thresholds, notification channels, and the verification procedure before going to production.
- Bot documentation — strategy description, configuration breakdown, launch from scratch, and rollback to the previous version.
Case Study: A Bot for an Arbitrage Strategy Across Three Exchanges
The task came from a team that was netting positions across three exchanges manually.
Discrepancies between what the bot considered its position and the actual account state accumulated by the end of the shift, and reaction to a price difference took tens of seconds—during that time, the arbitrage strategy window had time to close. Some discrepancies came from partial fills and rejected orders on exchanges such as Bybit.
| Metric | Before | After |
|---|---|---|
| Share of discrepancies between the position and the actual account state | 5–8% of trades per shift | less than 0.2% |
| Reaction time to a price discrepancy between exchanges | 40–90 seconds | 1–2 seconds |
| Manual interventions per shift | 25–30 | 0–2 |
| Recovery after a connection drop | manual restart and reconciliation | automatic state recovery |
We changed the accounting method: the position is built from confirmed executions, not from sent orders, and is reconciled with the account state after every event. Repeated submission goes with a unique key, so a duplicate does not open a second position.
We added stop conditions: if the price difference goes beyond the liquidity boundary or the exchange stops responding, the bot cancels orders and waits rather than adding to the position at an unfavorable price.
On operations: a log of every decision, notifications to the team channel, and a clear set of stop reasons. Control is moved to an external software interface, so connecting one more exchange is a configuration task, not a rewrite of the strategy core.
How Does a Management REST API Differ from Direct Exchange Integrations?
A direct integration with an exchange means the bot itself holds trading keys, polls the market of the required exchange, and sends orders. While there is only one exchange, this is justified: one node, one set of keys, minimal layers between signal and order.
The problem appears with the second exchange and with the first person on the team who needs access.
A management REST API places a unified interface between the strategy and exchanges. Commands go out in one format, state comes in one format, and exchange differences—currency pairs, order types, rounding—are hidden by connector modules.
Adding a new exchange stops being a bot rewrite: one connector is written, and the strategy logic is not touched.
Permission separation is the second thing that changes. With direct integrations, trading keys spread across all nodes, and any script in that chain can withdraw funds.
Through the management interface, only the necessary permissions are issued: to the strategy—place and cancel orders; to the risk module—force-close positions; to the operator—read state. Exchange keys live in one place and are not exposed externally.
Action audit appears as a side effect. The unified interface writes a log: who changed parameters and when, which command went to the exchange, and what response came back.
With disparate connections, this trail has to be assembled from each process's logs, matching time manually. Stopping the bot also turns into one command, not a bypass of all integrations.
A direct connection remains reasonable on one exchange with one strategy. As soon as there are more exchanges, roles on the team, and requirements to investigate incidents after the fact—the management layer pays off, and it is easier to add it at the beginning than after.
Technical Doubts Worth Resolving Before Launch
Before launching a bot, the same questions come up: what will happen to positions during a connection drop, who holds access keys, and how to test the logic before working with a real balance. Below are answers that resolve technical doubts before launch.
What happens if an exchange changes the rules or limits for operations?
Limits for operations, price step, and minimum order size change without warning. We put them in configuration, not code—editing takes minutes. The bot does not blindly repeat a rejected order: it records the reason and reduces activity until confirmation.
Can an already working strategy be migrated?
Yes, if the strategy has formalized entry and exit conditions. We describe it as a set of rules and run it in a test environment on historical data, comparing the result with the current implementation. Logic that relies on manual decisions will require formalization—we will say so in advance.
What happens during a connection drop?
Trade state is stored separately from the connection, so a drop does not lose positions. After recovery, the bot reconciles its data with the actual data on the exchange and continues from the confirmed state.
Critical actions during unavailability are blocked: missing an entry is safer than opening a position twice.
Who is responsible for access keys, and how can trades be tested before launch?
Keys are not stored in code and are not transmitted in plaintext. We issue limited permissions: withdrawal of funds is disabled, only the necessary set of operations is available, and the key can be revoked at any time.
Testing takes place in a test environment—the same code and the same checks, but without execution on a real balance.
Let's Discuss Your Task and Come Back with an Implementation Plan
To base the estimate on facts rather than guesses, we build the first conversation around your current trading environment.
It is enough to describe the task in words: which exchanges, what entry and exit logic, who manages positions now and how, and what you want to get from the bot.
- exchanges and instruments: underlying asset market or derivatives, test environment or live account;
- access: API keys, separation of read and trade permissions, exchange rate limits;
- strategy: signal sources, timeframes, entry and exit rules, handling of partial fills;
- risk limits: maximum position size, daily stop, behavior during a connection break and repeated attempts;
- management environment via REST API: which commands come from outside, how state is reported, the trade log and reporting;
- infrastructure: where we deploy, how we restart, how we reconcile positions and balance with the exchange.
After the conversation, we send an implementation plan: an environment diagram, scope of work, stages with verifiable results, acceptance procedure, and an estimate for each stage.
We do the pilot launch on a limited volume—the logic is tested on real data without affecting the main account.
Describe the task in free form: the exchange, strategy, and current workflow. We will come back with an estimate and implementation plan.