TECHNICAL STANDARD — ORDER EXECUTION
Version 1.0 | Effective: [Effective Date of MSA] | Published at platform.alphaquark.in/order-execution
NOTICE: This document is a Technical Standard incorporated by reference into the AlphaQuark Master Services Agreement (MSA). It is NOT separately signed. The Company may amend this Standard unilaterally at any time in accordance with Clause 4 of the MSA. Subscribers are bound to the most-recent published version with effect from seven (7) days after publication. This Standard describes how the Platform operates and is provided for the Client's information. Where the Client's expected or preferred behaviour conflicts with this Standard, this Standard prevails.
1. Purpose and Scope
This Standard describes how orders generated from recommendations and rebalances are routed and executed against End Users' broker accounts. It applies to equity cash, equity F&O and derivative basket orders.
2. Order Submission
2.1 No order is placed on an End User's broker account without explicit End-User approval through the Platform.
2.2 Approved orders are routed to the End User's connected broker through that broker's official integration. The Platform does not interact with broker terminals or screen-scrape broker user interfaces.
2.3 Order placement is asynchronous. The Platform returns an order acknowledgement and subsequently tracks the order's status. Final fill confirmation may take from a few seconds to several minutes depending on the broker, market conditions and order size.
3. MARKET-to-LIMIT Conversion
3.1 To protect End Users from runaway slippage during volatile market conditions, and to align with several brokers' restrictions on MARKET orders outside the regular session, MARKET orders submitted through the Platform are converted to LIMIT orders before being sent to the broker. The conversion is performed uniformly across all supported brokers from a single point in the Platform; the Client may not opt out.
3.2 The conversion adds a price buffer to the last traded price (LTP) — upward for buy orders, downward for sell orders. The buffer width is tiered by instrument type and LTP band, and is calibrated to be wide enough to fill on a normally-functioning market without exposing the End User to extreme slippage. The Company calibrates and updates the buffer-width parameters from time to time based on market conditions. The current parameters are part of the Platform's operational configuration and are not Client-customisable.
3.3 The converted LIMIT price is rounded to the relevant instrument's tick size before submission.
4. Order Outcomes (Fills, Partial Fills, Rejections)
Full fill. The order is recorded as executed, and the End User's Platform-recorded holdings are updated.
Partial fill. Where the broker reports a non-zero filled quantity less than the requested quantity, the order is recorded as a partial fill. The filled portion is reflected in the End User's Platform-recorded holdings; the Platform does not automatically retry the unfilled remainder. Any retry is at the discretion of the End User or, where applicable, the Client.
Rejection. Broker rejection responses are translated by the Platform into plain-English messages shown to the End User. The translation table is maintained by the Company and is not Client-customisable. The original broker response is retained internally for audit purposes.
5. Retries and Cancellations
Cancel-Before-Retry. Before any retry of a pending or partially-filled order, the Platform first cancels the prior order with the broker. This is to avoid the risk of a double-fill on brokers whose order-state is eventually consistent.
Retry Sizing. Where the Platform retries an order on behalf of the End User, the retry is sized to the remaining unfilled quantity, not the original requested quantity.
Trading-Session Boundary. Retries operate within the current trading session only. Orders that have not filled by the end of the trading session are not carried into the next session.
6. GTT, Stop-Loss, Profit-Target
GTT (Good Till Triggered), Stop-Loss and Profit-Target orders are submitted as native broker orders, and are supported only on brokers and instrument types that natively support them. The Platform does not provide a synthetic substitute on brokers that lack support.
Where supported, the End User configures these orders at the time of placement, subject to the broker's own validation rules.
7. Derivatives Baskets
Baskets are submitted leg-by-leg, sequentially, in the order specified by the Client.
A leg failure does not automatically cancel previously-filled legs. The Platform surfaces the resulting partial-basket state to the End User and the Client.
Both basket-level and leg-level cancellation are supported. Cancel requests are acknowledged immediately and processed asynchronously by the Platform; the final cancelled state is available shortly thereafter.
Expired contracts (past their expiry date) are filtered out at symbol-search time using both the broker's contract master and the embedded expiry in the contract symbol; expired contracts cannot be placed through the Platform.
8. Order-Type Support by Broker
Not every order type is supported by every broker. The Platform reflects each broker's supported order types in the End User's order-placement screen and disables controls that the broker does not support.
9. Audit
Every order placement, fill, partial fill, rejection, cancel and retry is logged internally with a timestamp, broker reference and outcome, and is available to the Client through the admin dashboard.
10. Changes to This Standard
The Company may amend this Standard at any time. Buffer parameters, tick rules and broker order-type support are expected to change from time to time as brokers update their integrations.