A custom platform is being built for Akshit to run and evaluate trading strategies across live-capital, paper, forward-testing and historical backtesting workflows.
The platform connects market-price data, strategy rules, order handling, capital controls and lifecycle management in one technical system. Its purpose is to support controlled strategy development and validation—not to promise trading results.
Akshit
Capital MarketsAkshit needed a technical platform that could support different stages of algorithmic strategy work without treating every stage as the same.
The platform is being designed to:
The project separates real-capital execution from simulation and research workflows. This separation helps users understand which actions can reach a broker and which actions remain inside the platform.
It does not remove trading, model, data, execution, broker, connectivity or implementation risk.
Strategy development is not one activity. Historical analysis, simulated execution, live-forward observation and real order placement have different purposes and different risks.
The platform therefore separates four workflows:
A strategy may behave differently across these workflows. Historical or simulated behavior does not guarantee live execution quality or future financial results.
Mode 01
Live-capital mode can send real buy and sell orders to the connected Fyers account.
Market-price updates are evaluated against the active strategy rules. When an eligible condition is met and the configured controls allow it, the platform can submit an order through the Fyers API.
Boundary: This mode uses real capital and can create financial losses. Its existence does not prove that the platform is publicly operating, adopted, profitable or production-ready.
Mode 02
Paper mode simulates strategy orders without sending real-capital orders to the broker.
It supports checking application logic, order flow and recorded strategy behavior before choosing whether to use live-capital mode.
Boundary: Paper trading avoids real-capital exposure during that mode, but it does not reproduce every live-market condition. It does not prove future returns, fill quality, latency, slippage, liquidity or live performance.
Mode 03
Forward testing observes strategy behavior using live-forward conditions while keeping the validation purpose separate from any claim of proven financial performance.
It is intended to help review how strategy rules respond as new market data arrives.
Boundary: Forward-test observations are not proof of future or live performance. They may differ from real execution because of market, data, timing, broker, model and implementation factors.
Mode 04
The separate backtest engine applies strategy logic to historical data and stores simulated trades and strategy statistics for review.
It helps inspect how the logic would have behaved under the historical data and assumptions used by the engine.
Boundary: Backtest outputs are hypothetical. They may be affected by data quality, assumptions, costs, liquidity, look-ahead bias, overfitting and implementation differences. They do not guarantee future or live results.
Signal-to-Order Workflow
The Fyers WebSocket supplies live market-price updates.
The active grid strategy receives each relevant price update.
The strategy checks its configured percentage-based profit threshold.
The strategy checks its configured percentage-based drop threshold.
The platform checks the strategy’s total allocated fund limit.
The platform checks the linked user’s allocated fund limit.
If available allocation is insufficient, the platform blocks the new buy.
If the strategy condition is eligible and the controls allow it, the platform sends the required buy or sell order through the Fyers API.
The platform stores the order and links it to the relevant hedge-line trading record.
The linked position remains available for lifecycle and exit-condition checks.
When the configured exit condition is met, the platform can submit the square-off order.
The order, trade and strategy state are recorded for later review.
The current build includes the following controls.
Each strategy can have a configured total allocated fund limit.
The platform checks this limit before allowing an eligible new buy. This is an application-level allocation control. It does not guarantee that total financial loss will remain within the configured amount.
A linked user can have an allocated fund limit.
The platform checks the user allocation before an eligible new buy is submitted. This control helps restrict strategy allocation inside the application. It does not confirm broker-account margin, settlement status or every external obligation.
When the platform’s allocation check determines that the configured funds are insufficient, it blocks the new buy.
This block applies to the platform’s own allocation logic. It is not a complete broker-side margin or risk check.
The strategy can use a percentage-based profit threshold as a square-off trigger.
This is an exit condition, not a promised profit. Actual execution can differ because of price movement, liquidity, slippage, rejected orders, delayed data, connectivity or broker response.
The strategy can use a percentage-based drop threshold to block further buys.
This control limits additional buying under the configured rule. It does not close an existing position, cap a loss or act as a guaranteed stop-loss.
Orders can be associated with a linked hedge-line trading record.
The linkage supports order tracking and related exit handling. The linkage does not mean the position is fully protected or financially risk-free.
The supported strategy lifecycle is:
Created → Running → Paused → Stopped
A strategy may also enter:
Error
Invalid state changes are rejected by the application.
Pause stops further strategy processing until the strategy is resumed or otherwise changed.
Pause does not close open positions.
Stop marks the strategy as stopped and pauses linked users.
Stop is not an emergency panic close-all control. The Stop action does not guarantee that every open position closes immediately.
The error state records that the strategy cannot continue its normal workflow.
An error state does not confirm that every related order or position is safe, closed or reconciled.
The paper-trading workflow is designed to show simulated orders, strategy state and recorded activity without submitting real-capital orders.
Paper-trading activity is simulated and does not submit real-capital orders.
Paper trading can help check:
Paper trading does not validate future profitability or reproduce every live execution condition.
The platform combines real-time market data, API services, scheduled processes, background workers, broker connectivity and persistent storage.
Fyers API v3 supplies WebSocket price streams and REST broker communication. Only live-capital mode can submit real orders.
FastAPI and Uvicorn handle strategy operations and lifecycle changes. APScheduler and Celery worker and beat processes support scheduled and background work; production must prevent duplicate execution.
MySQL, SQLAlchemy 2.0 and Alembic manage records and schema changes. Redis supports queues and scheduling, but is not the only safeguard for live-order execution.
Docker and Docker Compose support consistent setup. File and database logging are available, but active monitoring integration remains incomplete and production readiness is not implied.
The platform is being built and is not production-hardened.
Current limitations include:
The platform is not production-ready. Security, monitoring, recovery, reconciliation, broker behavior and emergency operational controls require separate review and verification before production use.
The project is validating whether the platform behaves as designed across its separate workflows.
Validation checks technical behavior under defined test conditions. It does not approve a strategy’s financial performance and does not establish that the system is ready for unrestricted live-capital use.
No financial or performance results are reported in this case study.
The current build is designed to cover:
The platform’s implemented controls and test workflows describe engineering scope only. They do not prove profitability, safety, production readiness or future trading performance.
The platform’s implemented controls and test workflows describe engineering scope only. They do not prove profitability, safety, production readiness or future trading performance.
Separate workflows for live-capital trading, paper trading, forward testing and historical backtesting.
Live price updates from the Fyers WebSocket can be evaluated by active strategy logic.
The grid engine checks configured percentage thresholds on each relevant price update.
Forward testing supports live-forward observation without treating the output as proof of performance.
Live-capital mode can send eligible buy and sell requests through the Fyers REST API.
Strategy and user allocation limits are checked before an eligible new buy.
Related orders can be connected to the relevant hedge-line trading record.
Configured conditions can trigger a square-off request.
Paper mode records simulated activity without submitting real-capital orders.
A separate engine stores simulated historical trades and strategy statistics.
Created, Running, Paused, Stopped and Error states provide controlled lifecycle handling.
Scheduled jobs and worker processes support recurring and asynchronous operations.
Strategy, order, trade and statistical information can be stored for technical review.
File and database logs support investigation during development.
Subject to separate requirements, compliance review and production validation, the same engineering pattern may also fit:
This list describes possible technical fit only. It is not an offer of investment advice and does not establish suitability for any person, strategy, broker, asset or market.
The listed technologies do not by themselves guarantee security, uptime, low latency, order execution, compliance, scalability, high availability or production readiness. Monitoring integration remains incomplete.
Discuss the technical scope of a multi-mode platform for broker integration, paper trading, forward testing, backtesting, allocation controls and strategy lifecycle management.
Discuss Your Platform RequirementsSoftware development support does not include investment advice or a guarantee of trading results. Any live-capital deployment requires separate security, operational, broker, regulatory and production-readiness review.
A multi-mode algorithmic trading platform separates real order execution from simulation and research workflows. This project includes live-capital trading, paper trading, forward testing and historical backtesting. Each workflow has a different purpose and risk boundary.
Live-capital mode can send real buy and sell orders to a connected Fyers account. Paper trading, forward testing and backtesting must remain separate from real-capital order submission. The presence of live-capital capability does not prove public operation, adoption, profitability or production readiness.
Paper trading simulates order activity without real-capital execution. Forward testing observes strategy behavior as new market conditions occur. Backtesting applies strategy logic to historical data. None of these workflows proves future or live performance.
No. The profit threshold can trigger a square-off request, but it does not guarantee a profit or execution price. The drop threshold can block further buys under the configured rule, but it does not close existing positions or cap losses.
No. Pause does not close open positions. The stop action marks the strategy as stopped and pauses linked users, but it is not a standalone emergency panic control that immediately closes every position.
No. The project is still being built and is not production-hardened. Monitoring integration, security hardening, operational recovery, reconciliation and emergency-control work require further review and verification before production use.
