Development of a management system for multiple trading bots

Bot management system: where manual maintenance breaks down

While there are only two or three trading bots, they live in separate terminal windows: the operator starts each one manually, monitors positions, and decides what to do with a rejected order.

Once there are ten bots, manual maintenance of strategies becomes a continuous stream of switching, and attention is no longer a reliable component.

The first typical failure point is state desynchronization. The bot stores the position in its memory, the exchange stores it in its register; after a process restart, some trades become invisible, and the next order is calculated from the wrong volume.

The second is a failure in order execution: partial fill, cancellation by price limit, re-sending due to lack of confirmation. The most dangerous thing is that these events arrive simultaneously, and they have to be sorted out from scattered logs of different windows.

Then scale comes into play. One operator physically cannot keep track of a dozen bots: while they are dealing with an accident on one, the others run unattended, and the overall flow of requests to the exchange hits rate limits. Response time is measured in minutes, whereas the window to cancel or hedge a position is seconds.

The bottom line: losses arise not because of the strategy, but because of its maintenance. Next, we will break down how this is closed by a bot management system — with a unified event log, position reconciliation with the exchange, and automatic rules for failures.

What a unified strategy control loop provides

A unified control loop is a layer between strategies and exchange interfaces: it holds the state of each strategy, limits, order queue, and event log in one place.

When each strategy is launched as a separate process with its own settings, the connection between them is maintained manually — hence discrepancies in positions and duplicate orders.

Downtime is reduced by the supervisor: it checks the liveness of each process, terminates hung sessions, and restarts only the failed segment, not the entire loop.

Open positions are brought to a safe state according to defined rules, rather than being dumped at market — restart takes seconds instead of manually sorting out a night incident.

Risk control for the portfolio of strategies is calculated at a common level: aggregate exposure, limit per instrument, overlapping directions.

This eliminates a class of failures where two strategies independently opened opposing positions and the total risk turned out to be twice the specified amount.

Recovery after a failure relies on an intent log and idempotent sending: when reconnecting to Binance, the loop reconciles the local state with actual positions and balance, completes unfinished orders, and only then resumes trading. Duplicate orders and lost positions cease to be a separate class of failures.

Architecture options: single node or distributed loop

The bot control loop comes down to three decisions: where strategy state is stored, how their failures are isolated, and how capacity is added as the number of bots grows.

A single node provides simple launch and a single observation point, but an error in the common process stops all strategies at once, and the load hits the resource limit of one machine.

Distributed bot execution spreads the runners across several nodes, so the failure of one does not affect the others.

The price for this is a control layer with order arbitration and a common state log: without it, strategies will start duplicating orders and diverging in positions.

Load limits are calculated in advance: the number of simultaneous connections, the frequency of requests to the venue, and the peak market data flow determine how many bots a node can hold.

We build in a margin and design so that a strategy can be moved to a separate node without rewriting the logic.

Implementation stages: from strategy audit to handover

The implementation stages are structured so that an error in a strategy or configuration is detected before going into real trading. Each step ends with an artifact — a registry, a diagram, or a run report — and without it we do not move to the next one.

1. Inventory and strategy audit. We compile a list of bots: what they run on, what they trade, which parameters are set manually, where limits and positions overlap. The result is a registry with the owner, status, and criticality of each strategy.
2. Service interaction diagram. We record who communicates with whom: control module, parameter storage, broker adapters, metrics and log collection, notifications. The diagram immediately shows single points of failure and duplicate loops.
3. Setting up loops and access. The test loop mirrors the production one in terms of services; we issue keys only for trading, without withdrawal, with limits on volume and number of orders.
4. Backtest on historical data. We run each strategy on archived quotes and compare with the owner's calculations. We investigate discrepancies down to the cause: commissions, slippage, incomplete data.
5. Pre-live check. Launch on limited capital: we compare actual trades with expected ones — response time, execution prices, handling of broker rejections.
6. Handover and maintenance. We provide configuration documentation, service diagram, duty regulations, and rollback procedure to the previous version, and train the team. We run the first period together, then hand over control.

What the client receives after implementation

The tangible result of implementation is not only a working loop, but also a complete set of artifacts that allow the system to be operated and developed without us. Below is what is handed over to the client's team: configurations, diagrams, policies, logs, and regulations.

• Loop configurations — description of nodes, connection parameters to exchanges and networks, limits for each bot. Deployment is reproduced from the repository, not restored from memory.
• Access and role diagrams — which employees can start and stop a bot, change a strategy, manage fund withdrawals. Rights are granted on a least-privilege basis, critical actions require confirmation.
• Event logs — structured records for each bot: orders, rejections, protection triggers, exchange responses. With a defined retention period and export for incident analysis.
• Monitoring and alerts — a set of metrics, thresholds, and notification routes. The duty operator learns about a bot failure before the discrepancy is noticed in reporting.
• Maintenance regulations — procedure for updating strategies and dependencies, maintenance windows, rollback procedure to the previous stable version.
• Response regulations — step-by-step scenarios for typical failures: loss of connection to the exchange, stuck order, balance discrepancy. With indication of the responsible person and response time.
• Loop documentation — architecture, data flow diagram, working with keys and secrets, instructions for the duty operator. Designed for an engineer who sees the system for the first time.

The handover is completed by a series of walkthroughs with your team: we show how to add a new bot, change limits, and analyze the log after an incident.

Case study: twelve strategies in one loop without manual control

Before implementation, twelve strategies lived as independent processes: each had its own server, its own keys, its own log.

Positions were reconciled manually once every few hours, so the discrepancy between the strategy's calculation and the actual account state surfaced only after a series of trades — and was closed manually, under duty.

What was changed

We assembled Kontur — a unified control layer: process supervisor, common position log, and automatic reconciliation with the trading venue's reports after each cycle.

Risk limits were moved to the loop level rather than an individual strategy: when a threshold is exceeded, the strategy stops and goes into safe mode, while the others continue working.

What it gave

Desynchronization ceased to be an incident and became a routine operation: reconciliation goes through each cycle, and the discrepancy is closed from the log, without manual order matching.

The failure of one strategy no longer drags down the others — process isolation and common monitoring show exactly what failed, and bring it up from the last agreed point.

How a unified loop differs from a set of separate scripts

The difference is visible already at the second or third strategy. Separate scripts keep logic, access, and restart within themselves: any edit is a synchronous change of several files, and position state lives in different places.

A unified loop moves this to the control level — strategies become modules, the core stores common state, maintains a trade log, and applies unified risk limits.

The observability of trading strategies in a set of scripts depends on who wrote the logs and how.

In the loop, metrics are collected according to a common scheme: profitability, drawdown, share of rejected orders, execution latency, frequency of integration failures with the exchange.

We aggregate them in Grafana, and on one screen you can see which strategy went negative and which limit triggered.

Moving strategies into the loop does not require rewriting from scratch.

The logic is formalized as a module with declared parameters and a fixed version: launch goes through a common mechanism, the previous version remains for rollback with one command, and historical data testing takes place in the same environment as the production run.

Maintenance cost is measured in connections, not lines of code. Several strategies and several exchanges in a fragmented form require pairwise integrations, each with its own response format and its own errors; the loop reduces them to a single access layer.

Adding a strategy takes hours instead of weeks, and stopping all strategies is done with one action.

Technical doubts before project start

Engineering objections before the start concern not the logic of strategies, but the boundaries within which the system can operate: what the venue allows, what happens in case of a connection loss, who gets access to accounts.

We address these doubts before the first line of code, so that they do not surface when going into real trading.

Some questions are resolved during design: we fix the load profile, failure points, and recovery requirements, and test them on the venue's test loop. Below are four doubts that most often slow down the launch of a bot management system.

What happens to open positions on restart?

State does not live only in process memory. Trades, strategy parameters, and order statuses are written to the log; on startup, the system reconciles records with actual positions on the venue and restores discrepancies.

Duplicate orders are filtered by identifiers, so a connection loss or planned restart does not lead to double trades.

What access rights does the system need?

Keys are created with trading permission but without withdrawal, separate for each bot, with IP address range restrictions and scheduled rotation. Management is divided by roles: the operator can see and stop bots, but does not change keys or configure infrastructure. Any human intervention is logged with an indication of who changed what.

Will it be possible to use the existing code?

Working strategies are connected as separate modules through adapters: the logic can be preserved by replacing the execution, accounting, and reporting layer.

If the code is written for another platform, we wrap it and run it in parallel, migrating one module at a time and checking calculations on historical data.

Let's discuss the task: what to prepare for the conversation

To come back with an estimate and work plan, rather than a new round of clarifying questions, we need sufficient inputs on the project.

The scope of a bot management system is determined by three things: how many strategies are in operation, where they are executed, and how strictly risks need to be controlled.

Below is what to prepare for the task discussion; this is enough to outline the stages and the order of start.

• Venues and access: which exchanges, whether keys are separate for trading and withdrawal, whether there are rate limits — this determines the key storage scheme and separation of rights.
• Bot composition: how many strategies, how they differ, and whether there is common logic — determines what is moved to the control core and what remains a module.
• Control commands: start, pause, stop, restart, on-the-fly parameter editing, redistribution of limits between bots.
• Risk rules: overall limit of open positions, auto-stop on a series of losses, limit per instrument — this is the core of the system, not an add-on.
• Accounting and reporting: how to consolidate trades and positions across all bots at once, which slices are needed and with what delay they should update.
• Behavior during failures: venue crash, connection loss, order duplication — an explicit recovery and manual intervention procedure is needed.
• Infrastructure and roles: where we deploy, who has access to the panel, and how the rights of operator, analyst, and administrator are separated.

With such a set, we come back with an architecture, stages, and timelines, rather than an estimated range. The start order is simple: we fix the loop, assemble control on two bots as a verifiable minimum, then scale to the rest. Describe the task — we will come back with an estimate and work plan.