Hello Everyone,
We unveiled or rather publicly spoke about DEXT (Dhan Exchange Trading System) a year before in May 2024 to explain what goes behind trading systems and how we, at Dhan, are approaching this differently.
But, before that… What is DEXT?
DEXT is Dhan’s own in-house trade processing system that is built on the latest technology stack, and this makes it among the very few Stock Trading platforms in the world (not just India) that owns and manages most of its technology infrastructure in-house including the core trading systems that are built from scratch. For Dhan - DEXT has been an absolute game-changer as it gives us flexibility to build, iterate and scale faster instead of relying on third-party systems.
When Dhan started its journey our end-to-end execution speeds were at an industry standard of usually 120-150 ms (speeds at a certain size and scale), and post moving to DEXT they were optimised to under 50 ms for 90% of the orders. We keep optimising our trading systems and we are glad to share that with DEXT, we are now able to process 90% of all our orders under 20 ms. This makes Dhan 6-8 times faster than the industry standards that we started with.
DEXT delivers ~40% of all orders under 10ms, and ~90% of all orders between 20 ms. These are end to end order validations, trade execution, position display and margin management numbers in terms of time-take. While some of these processes are fire and forget, to be on the same side it’s best to add 3-5 ms for any front-end systems.
Dhan is a technology led trading platform instead of just being a tech-enabled broker working as a system integrator who integrates multiple third party partner or vendor products. We also have built great innovations on top of Dhan with new order types like - Super, Scalper, etc, core integrations of Positions and Margin Management, and also more innovations that are work in progress at our end. We have also spoken from time to time of how we are building Dhan, the technology that goes behind the scene on Charts, Orders, DEXT, DhanHQ APIs and more.
It doesn’t end here; in fact it starts here with technology! Each day, we strive to make Dhan a better experience for all our users and contribute our share to the innovation in the Indian Trading ecosystem. This means building on the edge of technology, with ever evolving tech stack, reinventing age-old broking concepts with new approaches and building products by listening to our users first.
In this process, we achieved experience metrics which are now possibly the new industry benchmarks, whether that be sub-20 millisecond order response time or streaming entire market depth data on top of charts. And we keep on pushing these metrics each day to give the best possible experience to all our users.
Since we introduced DEXT, a lot of conversations have happened around how we built an entire order execution management system in just a few months wherein most of our peers in the industry rely on external vendors for the same. And not just in-house but with the reduced latency and enhanced reliability, handling large volumes of trades at scale.
How is the DEXT Designed?
Quick Background - Most trading platforms in India are over a decade old, built on an older technology stack and were built by third party vendors.
DEXT is built to solve two things - innovation in trading platforms and speed of execution. The third important pillar to this is reliability - which solves for managing order executions of any volume seamlessly.
To design the DEXT system, we split all the processes that an order goes through, redesigned layers which can handle multiple processes at once, defining the role of each layer differently than the other and stitched it together.
The DEXT system is a high-performance, multi-layered order processing framework designed for low-latency trading operations. It consists of four core components - Receiver, Order Management System (OMS), Risk Management System (RMS), Encoder and Order Constructor - through which orders flow non-sequentially. By leveraging parallel processing across layers and a sophisticated synchronization strategy, DEXT ensures rapid validation while adhering to exchange and broker regulations, at the same time managing risk for the user and for us as a platform. The architecture employs a combination of Barrier Synchronization and a Consensus Mechanism to coordinate parallel tasks and guarantee order integrity.
Receiver Layer (Layer 1)
- Role: Serves as the ingress gateway, interfacing with frontend platforms (Web, App, Charts, ScanX, DhanHQ APIs) to capture all incoming orders.
- Operations: Assigns a unique order ID, serializes the order into a structured format, and executes a preliminary set of lightweight checks (e.g., syntax, completeness).
- Parallel Dispatch: Upon successful initial validation, the Receiver initiates two concurrent workflows:
- Direct Stream: Forwards the raw order to the Internal Validator within the Encoder layer for baseline readiness assessment.
- Validation Stream: Routes the order to the OMS for comprehensive validation and risk checks, enabling parallel processing from the outset.
- Purpose: Minimizes sequential delays by splitting the order pipeline into independent, parallel paths.
- Initialise Constructor: The receiver layer on initial validation also informs the Encoder and Order Constructor (Layer 5) to expect an order in sometime, while the Constructor begins its function to make an order ready to send to exchanges, provided confirmation via Encoder.
Order Management System (OMS) Layer (Layer 2)
- Role: Conducts detailed order validation through 40-50 independent checks, executed concurrently across goroutines.
- Validation Categories:
- User KYC compliance verification
- Instrument eligibility and type validation
- Segment-specific rules
- Price reasonableness against market data
- Market operational status (open/closed)
- Connectivity health with exchange systems
- Freeze quantity limits (e.g., for Dhan Iceberg auto-slicing)
- Parallel Execution: Each check operates as a standalone task, updating the Internal Validator asynchronously upon completion. This parallelized approach eliminates sequential bottlenecks, significantly reducing latency compared to traditional stepwise validation.
- Output: Streams validation results to the Encoder layer for aggregation and informs the Order Constructor.
Risk Management System (RMS) Layer (Layer 3)
- Role: Performs an extensive set of 130-150 risk-related checks per order, also executed in parallel to maximize throughput.
- Risk Categories:
- Margin sufficiency and availability
- Open orderbook and position exposure analysis
- Liquidity thresholds
- Internal risk policy enforcement
- User-specific behavioral flags
- Exchange operational status alignment
- Price range compliance
- Parallel Execution: Like OMS, each check runs independently, with results transmitted to the Internal Validator in real-time. This layer handles the bulk of computational complexity, addressing both regulatory mandates and broker-specific risk controls.
- Optimization: Significant engineering effort was dedicated to parallelizing these checks, ensuring scalability and responsiveness under high order volumes.
- Output: Streams validation results to the Encoder layer for aggregation and informs the Order Constructor.
Encoder Layer (Layer 4) with Internal Validator
- Role: Acts as the final aggregation and decision-making layer, integrating inputs from Receiver, OMS, and RMS to finalize each order.
- Mechanism: The Internal Validator within this layer employs two key architectural patterns:
- Barrier Synchronization: The Validator functions as a synchronization barrier, similar to the coordinator in a Barrier Synchronization Architecture. It collects over 200 validation results—approximately 5 from Receiver, 40-50 from OMS, and 130-150 from RMS—represented as a set of state flags or bits. The order cannot proceed until all required parallel checks complete and report their status. This ensures that no partial or unvalidated order reaches the exchange, enforcing a strict “wait-for-all” condition akin to a barrier in parallel computing.
- Consensus Mechanism: Beyond mere synchronization, the Validator implements a lightweight consensus process. It requires unanimous “agreement” across all checks (i.e., all must pass) before marking the order as valid. This mirrors distributed consensus protocols, where multiple nodes (here, the parallel checks) must align on a single outcome. If any check fails, the order is rejected or flagged, ensuring compliance and risk mitigation.
- Execution: Once the barrier is cleared and consensus is achieved, the Encoder serializes the validated order and transmits it to the exchange.
- Uniqueness: The combination of barrier synchronization and consensus within the Encoder enables DEXT to process orders with exceptional speed and reliability, handling simultaneous updates from multiple layers without sacrificing accuracy.
- Output: Informs the Order Constructor to trigger order to Exchange as it inserts the Order Completion function in the Constructor.
Order Constructor Layer (Layer 5)
- Role: Receives inputs from both the Internal Validator and Encoder, constructing the final exchange-ready order payload.
- Operations:
- Merges the validated order from the Internal Validator (raw validated data) with the Encoder’s output (potentially enriched or formatted data).
- Formats the combined order into an exchange-specific structure (e.g., FIX protocol, JSON, or proprietary format).
- Adds exchange-required metadata and conducts a final lightweight integrity check.
- Execution: Transmits the fully constructed order to the Exchange.
- Purpose: Consolidates dual inputs from Layer 4, ensuring the order is both validated and properly formatted, enhancing reliability and adaptability.
Once ready, the Order Constructor will send the Order to the respective exchange, While this is posted, it will check the status of exchange (live, closed) and based on the same it will send the order to respective exchange for execution or collect the same for AMO.
Architectural Highlights of DEXT:
- Non-Sequential Workflow: Orders traverse layers dynamically, with Receiver initiating parallel streams and Encoder enforcing final synchronization.
- Parallel Processing: OMS and RMS operate as concurrent task clusters, feeding results to the Validator in real-time.
- Synchronization and Consensus: The Internal Validator’s dual role as a barrier and consensus arbiter ensures robust order validation, making DEXT both efficient and compliant.
- Dual Streams to Layer 5: The Internal Validator and Encoder both send data to the Order Constructor, introducing redundancy or parallel processing options.
Synchronization: The Barrier Synchronization and Consensus Mechanism remain intact within the Internal Validator, with the Order Constructor acting as the final integration point.
What we demonstrated above is the journey of a single order that you place on Dhan. All of the processes in each layer have to work in sync to ensure that no check is missed and your order reaches the exchange on time. To achieve these speeds - our systems start encoding and building the order constructor the moment we have it at the first stage of DEXT.
As we have always said that Stock Trading platforms are one of the most complicated financial and technology systems out there with tons of failure scenarios, internal and external that are beyond control.
Now, imagine thousands of orders flowing through this very system every minute, and millions throughout the day. This is where we have built each layer to be highly flexible in terms of scaling, making sure we have reserved bandwidth and our server utilisation at any given moment stays below 30%. The ability to spin off servers throughout the trading hours, as market volatility is unpredictable, requires us to be innovative in terms of our cloud management and devops.
Not just this, we know how bad any failure scenario can be for users. This is why we have an active-active system wherein DEXT can work out of multiple server locations at once. We talked about how we can keep the system active from two locations simultaneously earlier back in Dec 2023:
Now, we have extended this further and added more locations wherein DEXT processes orders and connects to the exchange. Not just this, it is optimised for speed - where the load is distributed according to the latency achieved across the server. This makes the EMS one of its kind, making it fault resistant and optimising for speed, both on the same layer.
While we have posted DEXT performance numbers time and again, we have decided to add a snapshot of our journey, achieving less than 25 millisecond latency for more than 95% of orders.
You can notice major inflection points in some of the months, and this is when we deployed major changes to DEXT for efficiency. In the phase between May 2024 to Dec 2024, we continued to achieve multi-region operating capacity, stabilising all order types on DEXT speeds and innovation on the layer, some of which is being released now.
And as we continue to optimise sub-25 millisecond latency on our systems, we have already started to work on the next benchmark for your order execution speed. Dhan is driven by innovation and enabled by technology that’s built in-house, and it is important for us to keep building better products every day.
Hope this clears a lot about what goes around whenever you place an order on Dhan and how we have achieved lower latency compared with the industry benchmarks. We believe this transparency helps with your trust with Dhan and also helps you understand trading systems better.
As always, Happy Trading!
Alok
Yes, we know 
