Hi @t7support
Well, thanks for the detailed discussion on this topic, I think thereâs a fundamental misunderstanding here around what parallel processing in DEXT actually does versus how margin availability works in real trading scenarios.
Let me clarify this technically.
1. Margin dependency between two different orders
In the situation you described, the second order depends on the margin benefit expected from the first (closing) order.
However, unless the first order has actually traded and is confirmed by the exchange, no trading system whether DEXT, OMS-RMS stacks at other brokers, or even legacy setups can extend that margin benefit to another pending order.
Thatâs because:
- The RMS (Risk Management System) only recalculates margin after receiving trade confirmation from the exchange.
- Before that point, the position is still considered open, and the margin is still blocked.
- Therefore, the system cannot assume that the order will execute and release funds doing so would expose the broker to credit and exposure risk if the trade fails or is partially filled.
- Weâve validated this behaviour across multiple trading systems â all exchanges and brokers follow the same rule.
So, if the first order doesnât trade, the second order will naturally be rejected for insufficient margin. We verified this across the other broker you mentioned, and it fails as well.
2. Why adding artificial delay does not solve it
You mentioned adding a delay to âensure both orders go through.â Unfortunately, that doesnât guarantee success - because execution timing is controlled by the exchange, not the brokerâs internal system.
Even if we delay the second order, whether the first one trades or not still depends on exchange matching and market liquidity. Until the exchange confirms the trade, margin cannot be released or reused.
So, no timing tweak or delay on the broker side can change this outcome.
3. Parallel processing has no role in this scenario
As explained in Alok Pandeyâs post on Decoding DEXT Technology, parallel processing in DEXT refers to intra-order validation â meaning multiple checks (instrument validation, KYC, margin validation, market status, etc.) for a single order happen concurrently.
Itâs important to note:
- This is within one order, not across two independent orders.
- Parallel processing does not change margin states, nor can it coordinate dependencies between separate orders.
This design is meant to minimize latency during single-order validation, not to synchronize margin reuse between sequential or dependent trades.
4. The Actual Technical Process at Exchange: Exchange-Level Trade Confirmation, Not DEXT Parallelism
The margin update delay youâre experiencing isnât related to DEXTâs internal parallel processing at all. Itâs a fundamental aspect of how exchange systems operate (NSE/BSE in this case), independent of the brokerâs tech stack.
Hereâs why:
Order Lifecycle in Exchange Ecosystems:
- Your order is validated and routed via DEXT (with parallel checks as above).
- It reaches the exchangeâs matching engine.
- The exchange matches it against counter-orders (this can take 1-100ms depending on market depth and latency, or even faster).
- Only upon match confirmation does the trade execute, triggering:
- Trade reporting back to the broker.
- Real-time margin recalculation at the exchange (SPAN or similar model).
Why the Delay in Margin Visibility?
- Until the exchange confirms the trade (i.e., the order has âhappenedâ), the margin isnât deducted/updated for that specific leg. Youâre seeing the pre-trade margin availability because the trade isnât yet a realized position.
- This is by design: Exchanges enforce post-trade margining to avoid over-allocation.
- If margins updated pre-match, it could lead to erroneous exposures during unmatched orders.
DEXTâs barrier sync optimizes the broker-side (pre-exchange) phase, but it canât influence the exchangeâs sovereign confirmation timeline. Expecting instant margin update for an unconfirmed trade is akin to checking your bank balance before the ATM dispenses cash the transaction isnât complete yet.
In SummaryâŚ
- DEXTâs parallel processing = concurrent internal validation for a single order.
- Margin reuse between two orders depends on exchange trade confirmation, not DEXT.
- No delay logic can guarantee execution sequence because exchange trade confirmation is asynchronous.
Hence, the observed behaviour is entirely expected and consistent with how all exchange-linked trading systems function.
We can get into a call along with @Hardik @Alok_Pandey and show you a demo of the same, and also show you rejection by orders on other broker as well.
