Most retail brokers in India operate with trade execution speeds between 100 to 150 milliseconds. That was considered standard — until Dhan introduced DEXT, its custom-built trading engine, and changed the equation completely.
Over the last year, Dhan has quietly transitioned its core trading infrastructure to DEXT. As a result, more than 95% of all orders are now executed in under 25 milliseconds, and a significant portion of those are under 10ms. This isn’t just a minor speed bump — it’s a complete architectural overhaul that puts Dhan in a different league when it comes to execution performance.
This post breaks down how DEXT is designed, the different layers an order travels through, and how engineering choices like parallel processing, synchronization, and real-time validation make sub-20ms order speeds possible.
What is DEXT?
DEXT stands for Dhan Exchange Trading System, a fully in-house order execution engine. Unlike most Indian brokers that rely on third-party OMS and RMS systems, Dhan has developed its own core trading infrastructure from scratch.
The motivation was three-fold:
- Speed – Achieve ultra-low latency execution.
- Innovation – Enable fast iteration and experimentation.
- Reliability – Reduce external dependencies and improve fault tolerance.
The results have been significant. Execution latency has dropped from 120–150ms (as seen in typical vendor-based setups) to under 25ms for the vast majority of trades.
A Look at the DEXT Architecture
DEXT is structured as a multi-layered order execution pipeline. Each layer is specialized for a specific task and operates independently in parallel wherever possible. The five main layers are:
- Receiver
- Order Management System (OMS)
- Risk Management System (RMS)
- Internal Validator + Encoder
- Order Constructor
These layers work together to validate, format, and dispatch orders to the exchange — all in under 20 milliseconds.
Layer 1: Receiver
This is the first point of contact for any order, whether it’s placed via the Dhan app, website, charting platform, ScanX, or APIs.
Key responsibilities:
- Assigns a unique Order ID
- Performs basic validations (e.g., data completeness, syntax checks)
- Dispatches the order into two parallel flows:
- A Direct Stream to the Internal Validator (for early readiness)
- A Validation Stream to the OMS and RMS
The receiver also alerts the final order constructor to begin prepping for a potential incoming order — reducing wait time downstream.
Layer 2: Order Management System (OMS)
The OMS performs 40 to 50 checks related to order structure and user/account configuration. All checks run in parallel.
Examples of checks:
- Whether the instrument is valid and tradable
- If the user’s KYC is compliant
- Market open/close status
- Segment-specific rules
- Price validation
- Connectivity status with the exchange
- Quantity limits (e.g., slicing rules for large orders)
Each check operates independently to avoid creating sequential delays. Once complete, the OMS streams its results to the Internal Validator.
Layer 3: Risk Management System (RMS)
RMS performs 130 to 150 parallel checks focused on user and platform-level risk exposure. It is the most complex and computationally heavy layer.
Risk checks include:
- Margin availability and sufficiency
- Exposure from existing positions or open orders
- Volatility thresholds
- Liquidity and slippage considerations
- Internal flags for high-risk behaviors
- Price band compliance for the selected instrument
Despite the number of checks, RMS maintains low latency through aggressive parallelization.
Layer 4: Internal Validator + Encoder
This is the decision-making brain of the system. The Internal Validator acts like a gatekeeper, waiting for every check from Receiver, OMS, and RMS to report their status.
Two main mechanisms are used here:
- Barrier Synchronization: The order only moves forward once all parallel checks complete.
- Consensus Mechanism: The system waits for a unanimous “pass” before allowing the order through. Even one failure leads to rejection or flagging.
Once validated, the Encoder formats the order for downstream systems, ensuring consistency and integrity.
Layer 5: Order Constructor
This is where the final order is assembled and dispatched to the exchange.
It performs the following:
- Combines outputs from the Internal Validator and Encoder
- Formats the order into exchange-ready protocols (e.g., FIX, JSON)
- Adds required metadata (e.g., client code, product type)
- Performs a lightweight final check
- Sends the order to the appropriate exchange or queues it for later (in case of AMO or market closure)
This layer ensures that validated orders are not just fast, but compliant and structured to meet exchange protocols.
Latency Improvements with DEXT
Based on Dhan’s public performance metrics, the latency improvement journey has been remarkable:
- April 2024: Around 40% of orders were executed in under 25ms
- May 2024 onwards: Performance jumped to 75–88% sub-25ms orders
- March 2025: Over 95% of orders now execute under 25ms, with most around the 10–20ms mark
These numbers represent end-to-end latency — from the time a user places an order to when it is fully validated and sent to the exchange.
Scaling Under Load
DEXT isn’t just optimized for speed — it’s built to scale.
- Parallelized by design: Most validation layers run tasks independently to avoid queues and bottlenecks.
- Cloud-optimized infrastructure: Servers are kept under 30% utilization to accommodate surges in order flow.
- Active-Active mode: DEXT runs in multiple locations (Mumbai, Bangalore, and others) simultaneously. Load is routed based on server latency and availability.
- Failover-ready: If one region experiences issues, another can take over seamlessly.
This kind of design ensures that even on high-volatility days, the system remains responsive and reliable.
Why This Matters to Traders
For active traders and scalpers, execution speed can make or break a trade. Slower systems often suffer from price slippage, rejections, or delayed position updates — all of which impact real P&L.
With DEXT:
- Traders receive instant feedback and fills
- Risk is managed without compromising speed
- The infrastructure remains resilient under pressure
More importantly, it signals a shift — from brokers being just integrators of third-party systems to builders of technology that genuinely improves trading outcomes.
Closing Thoughts
Most brokers in India still operate with off-the-shelf infrastructure and trade routing systems developed by external vendors over a decade ago. Dhan, by building DEXT in-house, has not only matched global standards but also introduced a new layer of innovation into Indian retail broking.
With sub-20ms execution speed, parallel validation, multi-region failover, and a unique consensus model — DEXT is more than just a fast engine. It’s an example of how modern infrastructure can transform the trading experience.
Reference
Decoding DEXT – Technology & Architecture behind our in-house Exchange Trading System
