In quantitative trading, private funds, and multi-account asset-management operations, data is naturally fragmented. Balances live in exchange or broker systems, strategy status lives in research and execution systems, order details live elsewhere, and profit, loss, and fees often require separate reporting. As the number of accounts and strategies grows, spreadsheet-based consolidation becomes slow, inconsistent, and prone to missing risks.
This project is a management platform for quantitative asset-management operations. Built with a React frontend and a Django REST Framework backend, it brings accounts, assets, strategies, orders, risk controls, and performance analysis into one system. Users can drill down from a portfolio overview to individual subaccounts, monitor asset changes, follow signals through order execution, and understand operations through PnL, fees, positions, and net-asset-value charts.
Background
I contributed to the development and maintenance of this live-monitoring system while working on a quantitative team in 2022. The firm already had quantitative strategies, but no complete and unified way to monitor their live operation. Funds, strategy signals, order execution, real-time assets, PnL movements, and risk information were scattered across separate processes.
The system was not designed to generate strategies. Its purpose was to provide traders, operations teams, and managers with a single, observable, and manageable view of live strategy execution: how many signals were generated, whether they became orders, whether those orders were filled, how assets changed after execution, and whether an account showed abnormal movement.
1. Problems the Platform Solves
A live quantitative workflow includes strategies, accounts, risk checks, orders, executions, and returns. A failure at any stage can affect the final result. A valid trading signal may still fail to trade because of insufficient funds, risk limits, exchange connectivity, or market liquidity.
The platform addresses several recurring problems:
- managing multiple account levels and real trading accounts in one model;
- presenting initial assets, current assets, and asset movements consistently;
- tracing the path from a strategy signal to an actual trade;
- comparing submitted orders with executed orders;
- detecting and handling dispersed risk events;
- aggregating PnL, fees, positions, and liquidity indicators; and
- helping management assess whether a strategy is operating as expected.
2. Architecture
The project uses a frontend-backend separation. React handles interaction, tables, and visualization. Django REST Framework provides business logic, data access, permissions, and standardized APIs. MySQL stores business data, while Redis supports caching and selected real-time scenarios.
This boundary is deliberate: the frontend consumes consistent API responses rather than querying data directly, while the backend focuses on rules, calculations, data permissions, and traceability rather than page layout. Both sides can therefore evolve independently.
3. Core Modules
Account and Asset Management
The account model supports parent accounts, subaccounts, trader-related accounts, and underlying exchange accounts. Managers can move from total capital to a particular real trading account; traders can focus on the accounts and orders relevant to them. The platform also separates initial assets, current assets, and historical variation. A normal current NAV alone is not enough: drawdowns, rapid capital movements, and abnormal volatility require a time-series view and supporting transaction records.
Strategy Library and Signals
The strategy library maintains strategy identity, account assignment, operational status, configuration, and risk parameters. Signal pages show the outputs of a live strategy. A signal is an intermediate event rather than a trading result: it must pass risk controls and enter the execution pipeline. Keeping strategy configuration, signals, orders, and reports separate makes it easier to answer whether the issue lies in strategy generation, risk interception, market execution, or the final business result.
Orders and Executions
Entrusted orders and executed orders are separate concepts. A submitted instruction can be pending, partially filled, fully filled, cancelled, or rejected. Treating a submitted order as a completed trade would hide important execution risk. The separation lets a team locate the exact break in the chain—from missing signals to failed submission, poor fill quality, or unexpected asset impact.
Risk Controls and Notifications
Risk checks can cover capital allocation, position limits, order size, cumulative loss, strategy state, trading frequency, and instrument restrictions. Risk inputs represent the data and rule parameters to be checked; risk outputs represent the result, severity, and recommended action. A notification and risk-report page brings events out of backend logs and into an operational workflow: detect, confirm, limit a strategy or cancel an order, adjust parameters, and retain an audit record.
PnL, Fees, and Visual Reports
The reporting layer turns raw balances and order records into operational understanding. Tables support precise inspection, filters, and exports; line charts reveal trends in NAV and returns; pie charts show allocation; bar charts compare accounts, strategies, and periods; metric cards surface total assets, cumulative PnL, fees, and risk state. A useful report design combines all three: key metrics at the top, charts for trend and structure, and drillable detail below.
4. Engineering Implementation
The frontend was built with React, React Router, Redux, Ant Design, Axios, ECharts, Chart.js, and Sass. Pages were organized by business domain—accounts, strategies, orders, reports, and risk—rather than by database tables. This makes ownership clear and keeps change scope small. Route-level dynamic imports reduced initial bundle size for chart-heavy administrative pages, while API paths were centralized and the base URL was provided through environment variables.
The backend was organized into Django applications such as account, current, charts, funds, relation, and strategy. A typical request follows the path: frontend request → Django URL routing → view or viewset → business logic → ORM → MySQL and Redis → JSON response. Gunicorn can serve the WSGI application in production, typically behind Nginx for reverse proxying and static files.
5. Design Lessons and Next Steps
The main challenge was not the number of screens but the data relationships: account hierarchy, strategy-to-account bindings, signal-to-order references, order-state transitions, how executions update assets and positions, where risk checks apply, and how reports define and refresh every metric. These relationships had to be clarified before building pages.
Future improvements include upgrading the frontend stack from Create React App to a modern toolchain such as Vite; adding automated tests for account relations, order transitions, risk rules, permissions, and reporting definitions; publishing a unified data dictionary; strengthening role-based access control and operation audits; and using message queues, WebSocket connections, or scheduled jobs to improve real-time delivery and alerting.
Conclusion
This platform connects accounts and assets with strategy signals and order execution, then closes the loop with risk notifications and performance reporting. Its lasting value is not a single page or API. It is the ability to make live quantitative operations queryable, traceable, analyzable, and manageable—so strategies can run in a real environment with greater stability, transparency, and control.