Basket Order Trigger - Not Based on Sequence

[PravinJ]

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.