A timeout can create a duplicate trade
If an order request times out, blindly retrying can duplicate the position — the broker may have received the first request.
FIELD NOTES / FINTECH & CAPITAL MARKETS
One decision.
Many accounts, many brokers.
Algo Trade automates configurable intraday options strategies, monitors positions in real time, triggers rule-based adjustments, and executes across multiple broker accounts from a unified control interface.
FINTECH CASE STUDY
Algo Trade
Options execution.
Multi-account replication.
Algo Trade / Trading dashboardACTUAL PRODUCT INTERFACE
THE CONTROL SURFACEEvery account, one operator view.
Strategies, open positions, account and combined P&L, and available margin in a single interface.
Follow the workflow ↗ConfigureMonitorAdjustReplicateReconcile
DOMAIN
Algorithmic options trading
WHAT WE BUILT
Execution & multi-broker platform
OUR ROLE
Trading workflow design to execution engineering
01 / THE REAL ENGINEERING PROBLEM
Placing the order is easy.
Deciding to is not.
Options strategies such as straddles and strangles can require additional trades when individual positions reach predefined profit or loss thresholds. The challenge was never simply placing orders automatically.
The system continuously evaluates every active position to determine whether an adjustment threshold has been reached, which position should receive the counter trade, how large it should be, which strike to select, whether capital is available, and how the adjustment affects all connected accounts.
That logic has to run continuously against live market data — and a single trading decision may become multiple broker orders.
Each account is a different execution context
Accounts differ by broker, quantity multiplier, available capital, authentication session, API rate limit and execution state.
Margin pressure needs a rule, not a rejection
As adjustment positions accumulate, the next trade may need more capital than the account has — the platform decides that explicitly rather than letting broker rejection define strategy behaviour.
02 / INSIDE THE PRODUCT
Configure the strategy.
Watch it execute.
Five views of the delivered platform.
Each shows another part of the execution path.
One view of the whole operation.
Strategies, open positions, account-level and combined P&L, and available margin sit together, so the operator sees state rather than assembling it.
THE EXECUTION PATH
Market data→Evaluate→Adjust→Size→Replicate→Submit→Reconcile
03 / ORDER INTEGRITY & LATENCY
Automated trading fails
in infrastructure, not strategy.
Order lifecycle and reconciliation were treated as core architecture problems rather than simple API handling. If the application restarts with open positions, relying entirely on local database records can resume the engine from an incorrect state.
The platform was designed around a sub-150 ms tick-to-trade target under normal market conditions. Broker infrastructure and exchange processing contribute significantly to total latency, so the architecture focused on minimising the part it controls: the path between receiving market data and submitting an order.
Look under the hood ↘01
Evaluate against live data
Every active position is continuously assessed against its configured adjustment thresholds.
Recorded and replicated
The fill is recorded against the account and the position becomes part of the next evaluation cycle.
Resolve before retry
An uncertain broker response is resolved before any retry, because a blind retry can create a duplicate trade.
02
Resolve the decision per account
One decision becomes the correct order for each account's broker, multiplier and available capital.
03
Reconcile to broker truth
Order state is reconciled against the broker rather than assumed from local records, so a restart resumes from reality.
04 / THE TECHNOLOGY & THE REASON
A latency-conscious path
from tick to order.
The stack was chosen around the part of execution the platform can actually control — evaluating market data and submitting an order — with broker differences absorbed behind a common abstraction.
OPERATOR INTERFACE
React + TypeScript
The trading dashboard: strategies, positions, per-account and combined P&L, and available margin.
Why one interface?
An operator managing multiple accounts needs one place to see state and intervene, not one tab per broker.
PY
EXECUTION ENGINE
Python + FastAPI
Carries strategy evaluation, adjustment logic, sizing and the order submission path.
Why keep it in one engine?
Adjustment decisions depend on live position state; splitting the evaluation from the execution adds a hop the latency budget cannot afford.
RECORDS
PostgreSQL
Holds strategies, accounts, positions and the order lifecycle record that reconciliation depends on.
Why record the lifecycle?
After a restart, local state alone can be wrong — the record exists so it can be checked against the broker.
RD
HOT STATE
Redis
Holds fast-moving state on the path between market data and order submission.
Why a second store?
The tick-to-trade path cannot wait on durable writes for data that changes every tick.
API
BROKER INTEGRATION
Kite Connect + SmartConnect
Broker API abstraction layers over Zerodha Kite Connect and Dhan SmartConnect, each with its own session and rate limits.
Why abstract the broker?
Accounts differ by broker, and a strategy should express intent once rather than per-integration.
SCH
SCHEDULING
APScheduler
Drives the continuous evaluation cycles that keep adjustment logic running against live market data.
Why scheduled evaluation?
Adjustment thresholds are only meaningful if every active position is checked continuously, not on user action.
The architecture and product narrative reproduce the supplied project documentation. Interface values are product screen data and are not presented as investment results or evidence of future performance.
Explore the documented platform stack
- Frontend
- React 18 · TypeScript · trading dashboard
- Execution engine
- Python 3.11 · FastAPI · strategy, adjustment and sizing logic
- Data
- PostgreSQL · Redis
- Broker integration
- Zerodha Kite Connect · Dhan SmartConnect · broker API abstraction layers
- Scheduling & infrastructure
- APScheduler · AWS
Technology names identify the documented implementation, not partnerships or endorsements.
A CONVERSATION ABOUT YOUR TRADING WORKFLOW
What happens between
your signal and the fill?
Bring one execution, adjustment or reconciliation workflow. In 20 minutes, we will map where automation is safe, and where an operator still has to decide.
20 minutes · Your strategy, brokers and constraints