Trading Systems Built for Live Accounts
We develop trading systems and execution algorithms and audit existing bots. We automate not only the trading logic itself, but also order handling, liquidity management, position management, failure handling, state recovery, risk controls, and monitoring.
T-Invest • Interactive Brokers • MOEX • Crypto exchanges • MetaTrader 5 • Broker and exchange APIs
Where to Start
You can come to us with an existing strategy, a problem that still needs an algorithm, or an existing system that needs to be reviewed.
You Have a Strategy — You Need a Bot
We turn the trading strategy into formal rules, design the system, implement the broker or exchange integration, test it, and prepare it for launch.
- trading logic
- orders and fills
- position management
- risk limits
- logging and monitoring
- test and live modes
You Have a Problem — You Need an Algorithm
If the objective is clear but there is no existing algorithm yet, we can design the decision logic itself: define inputs, constraints, decision rules, and system behaviour in different market conditions.
- execution algorithms
- liquidity management
- volume allocation
- venue selection
- dynamic order-handling rules
- other trading and operational problems that can be formalised
You Already Have a Bot — You Need an Audit
We check whether the bot correctly implements the intended trading logic, why backtest results may differ from live trading, whether there are critical implementation or risk-management issues, whether the code contains unexpected or unsafe behaviour, and whether the system is technically ready to operate on a live account.
- trading logic and implementation
- backtest/live discrepancies
- risk and position management
- code safety and unexpected behaviour
- order execution
- reliability after failures, reconnects, and restarts
The Bot Works. But Is It Ready for a Live Account?
The audit answers practical questions for a bot owner: is the trading logic implemented correctly, can the backtest results be trusted, is the code safe, and is the system ready for sustained operation on a live account?
We review the bot across four areas — from whether the code matches the intended strategy to how the system behaves in failure scenarios that inevitably occur when working with live broker or exchange APIs.
Does the Bot Correctly Implement the Intended Strategy?
We check whether the source code actually matches the described trading logic rather than only appearing to match it.
- consistency between the code and the described logic
- entry and exit conditions
- position state and trade lifecycle
- stop-loss, take-profit, and trailing logic
- position sizing and volume calculations
- repeated and duplicate entries
- missed signals
- boundary conditions and edge cases
- incorrect state transitions
- other implementation errors that change system behaviour
The audit checks whether the strategy is implemented correctly, not whether the trading idea itself is profitable.
Can the Backtest Results Be Trusted?
We investigate why a bot may perform well in backtests but behave differently in live trading, and why results may vary across brokers and testing environments.
- spread and commissions
- slippage
- order-execution assumptions
- historical data and data quality
- modelling assumptions and current-bar handling
- possible look-ahead bias
- broker-specific behaviour
- optimisation-related issues
- discrepancies between backtest and live execution
The goal is to identify technical and methodological reasons why test results may not reflect real trading conditions — not to predict future returns.
Is the Source Code Safe to Run?
We answer a practical question: “Someone else developed this bot — can I safely connect it to a live trading account?” This is not a full information-security audit, but a practical review of the code’s behaviour.
- external network requests
- WebRequest usage
- external services and endpoints
- DLL dependencies
- file-system access
- handling of API keys and credentials
- unexpected data transmission
- unexpected trading operations
- hidden restrictions and licensing mechanisms in the code
- other behaviour not required by the stated logic
This type of review is only possible when source code and the necessary project materials are available.
Is the System Ready for Live Operation?
We assess engineering reliability — how the bot behaves during failures, restarts, and desynchronisation with the broker during extended operation.
- order lifecycle
- partial fills
- rejected and cancelled orders
- duplicate operations
- broker or exchange API behaviour
- reconnects and restarts
- internal state recovery
- reconciliation against broker positions and orders
- stale or missing market data
- risk controls and emergency stop
- logs and diagnostics
This is the engineering depth of the audit: how the system behaves in non-ideal scenarios, not only when everything goes right.
When an Audit Makes Sense
If any of these situations sounds familiar, an audit can help clarify what is actually happening inside the bot.
How the Audit Works
Understand the System
We identify the platform, architecture, current project state, deployment model, and tasks the bot is expected to perform.
Test Critical Scenarios
We review the trading logic, code, testing methodology, and system behaviour: signals and trades, orders and positions, risk, data, failures, and recovery.
Prepare a Technical Report
We document the issues found, their consequences, severity, and recommended fixes.
You Decide What Happens Next
You can fix the issues yourself, give the report to your developer, or ask Miriva to implement the required changes.
What You Receive
The audit result is not a verbal opinion about the code, but a structured technical report.
An issue that makes the system unsafe to run on a live account until it is fixed.
A material risk that should be resolved before normal long-term operation.
A technical issue that may not block launch, but can lead to errors or make the system harder to operate.
A finding related to reliability, maintainability, diagnostics, or implementation quality.
For every material finding, we specify:
- what was found
- where the issue is located
- the scenario in which it appears
- the possible consequences and risks
- what should be changed or investigated
The final summary separately identifies which issues must be fixed before live deployment, which should be improved, and which are non-blocking. You are not required to order further work from Miriva: you can fix the issues yourself, pass the report to your developer, or ask Miriva to handle the changes.
Technical Reliability ≠ Strategy Profitability
The audit determines whether the trading bot correctly implements the intended logic and is technically capable of operating on a live account. It is not a promise or assessment of the strategy's future profitability.
Even a technically flawless bot cannot make a weak trading idea profitable.
After the Audit
You receive the report and decide how to use the findings. The fixes can be implemented by your own team or developer. If needed, Miriva can separately assess and implement the required changes.
Discuss a Bot AuditTrading Bot for T-Invest API
We developed an autonomous trading bot for a client using the T-Invest API. The trading strategy and system parameters are confidential, so only the engineering side of the project is described here.
Challenge
Automate the client's trading strategy and prepare the system for long-running autonomous operation through the broker API — not merely sending trading signals, but correctly handling real orders, positions, and failures.
What mattered in the implementation
- order-state tracking
- partial-fill handling
- reconciliation of actual positions with the broker
- correct recovery after restart
- separation of bot operations from the client’s manual operations
- market-data freshness controls
- protection against duplicate actions
- risk limits
- logging and system-state monitoring
Result
Not a standalone trading-logic script, but an autonomous system designed to operate with a live brokerage account and recover from failures and other abnormal conditions.
We do not publish the client's trading strategy, parameters, or trading results.
How We Approach Trading-System Engineering
We cover the engineering and algorithmic side of trading in detail in technical publications.
Trading Bot: What It Takes to Operate Autonomously with Real Money
A real T-Invest API project covering order states, partial fills, positions, restart recovery, data controls, risk limits, and monitoring.
Read on HabrPattern-Based Trading from an Algorithmic Perspective
How to formalise similarity between segments of market data, find comparable sequences in historical data, and test a trading hypothesis using mathematical methods.
Read on HabrTrading-System and Algorithm Development
From a defined trading strategy or an initial problem to a formalised algorithm and a working system integrated with a broker or exchange.
Understand the Problem
We define the system objective, market, instruments, input data, constraints, and criteria the algorithm should use to make decisions. If trading logic already exists, we formalise it. If not, we design the required algorithm for the problem.
Design the Algorithm
We formalise decision rules, system states, constraints, and behavioural scenarios so the logic can be tested and implemented unambiguously.
Design the System
We define the architecture, broker or exchange API, order and data handling, state storage, error handling, and monitoring.
Build and Test
We implement the trading logic and test not only the normal path, but also edge cases, API errors, failures, and recovery.
Launch
We deploy the system locally, on a VPS, or on the client’s server, verify operation in the chosen mode, and continue post-launch support where needed.
After launch, we can support the project, adapt it to changes in APIs, strategy, or infrastructure, and continue developing future versions.
Execution and Liquidity-Management Algorithms
Not every trading algorithm needs to predict the market. Sometimes its job is simply to buy, sell, or allocate the required volume more efficiently than manual execution.
You Do Not Need to Come with a Ready Algorithm
Sometimes a business does not have a formalised strategy, only a concrete task: execute a large volume, maintain a required asset reserve, choose between multiple venues, or dynamically redistribute orders. In that case, we can first design the decision algorithm itself and then implement it in software.
Liquidity Accumulation
An algorithm can gradually build the required asset position using passive limit orders, adjusting price and order size based on the order book and the target reserve. This avoids sending the entire required volume as a single market order.
Example: maintaining a required stablecoin reserve for operational use.
Large-Volume Execution
A large order can be split into a sequence of smaller orders and executed gradually based on liquidity and market conditions. The goal is to control execution price, slippage, and the market impact of a large order.
Example: executing a large client conversion without sending the entire volume to market at once.
Multi-Venue Execution
If liquidity is distributed across several exchanges, the algorithm can consider available prices, order-book depth, balances, constraints, and other parameters, and route execution across venues.
Example: executing a single client’s volume across several liquidity sources.
Dynamic Allocation of Large Volume Across Crypto Exchanges
For an operational problem involving large cryptocurrency volumes, we developed logic that evaluated available venues across several parameters and determined how much volume to route to each one.
The decision incorporated liquidity and order-book state, spread, current orders, and actual execution quality. Each venue's weight could change, and volume was reallocated if actual execution differed from expectations.
The algorithm's job was not to predict price direction, but to manage execution of a large volume under changing market conditions.
Algorithm and Code Are Not the Same Thing
Development can start with the logic itself: define criteria, weights, constraints, and decision rules. Once the concept is validated, the algorithm can be implemented as a trading bot, a standalone service, or part of an existing financial system.
A Custom Algorithm Is Not Always Necessary
If the exchange's native tools fully solve the problem — for example, through a built-in algorithmic order type — there is no reason to build a custom system for its own sake. A custom solution is justified when you need proprietary execution rules, multiple venues, balance and risk management, integration with internal services, or other logic not available in standard tools.
Developing an algorithm for a specific trading or operational problem is not a promise to create a profitable trading strategy from scratch. If the objective concerns strategy returns, the underlying hypotheses must be tested separately on data.
Markets and Integrations
We work with broker and exchange APIs where the platform technically supports the required trading logic.
T-Invest and MOEX
T-Invest, BCS, Finam, Alor, and other broker APIs for the Russian market.
Interactive Brokers
Stocks, ETFs, options, futures, and other instruments through the Interactive Brokers API.
Crypto Exchanges
Binance, OKX, Bybit, and other crypto exchanges with a suitable API and the required access on the client’s side.
MetaTrader and Forex
Expert Advisors, indicators, and strategy automation for supported Forex platforms.
Terms of Engagement
Code, strategy, and responsibility should be separated just as clearly as trading logic and execution.
Confidentiality
The trading strategy, source code, and project details remain with the client. We do not publish or reuse client trading logic without permission. NDA arrangements are available where required.
Implementation Warranty
Bugs in our code that can be reproduced within the agreed project logic are fixed without an additional charge. New features, strategy changes, or requirement changes are treated as separate development work.
No Profitability Guarantees
We are responsible for software implementation and technical correctness, but we do not guarantee the profitability of a trading strategy. We do not sell a “magic profit button” or act as an investment adviser.
A weak trading strategy cannot be fixed with a polished interface or high-quality code — it can only be implemented correctly and tested properly.
Have a Strategy, an Execution Problem, or an Existing Bot?
For the first conversation, a brief description of the market, platform, and problem is enough. If the bot already exists, tell us what it is built with and what you want to review or improve.