TECHNICAL STANDARD — BROKER CONNECTIVITY & DATA
Version 1.0 | Effective: [Effective Date of MSA] | Published at platform.alphaquark.in/broker-data
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 which brokers the Platform integrates with, how those integrations are authenticated, how market data is delivered to the End-User, and the operational constraints that apply.
2. Supported Brokers
The Platform currently integrates with the following brokers. Each broker is integrated through its officially-published interface. Broker additions, modifications and removals are at the Company's sole discretion and may occur in response to broker-side changes, regulatory action, commercial considerations or quality concerns.
Zerodha
Angel One
Upstox
ICICI Direct
Kotak
Dhan
Fyers
AliceBlue
Motilal Oswal
HDFC Securities
Groww
IIFL Securities
Axis Securities
A separate "manual" mode is available where the End User executes outside the Platform and records the trade on the Platform; this is provided for End Users who have not connected a supported broker and is not itself a broker integration.
3. Authentication Lifecycle
3.1 Two broker connection patterns are supported, depending on what the broker offers:
(a) Hosted OAuth: the End User is redirected to the broker's hosted login and returns with a code or token that the Platform exchanges for a session.
(b) Credential entry: the End User supplies the broker-issued API key, secret and any other required identifiers through the Platform.
3.2 Credential Storage. Broker credentials at rest are encrypted using strong industry-standard cryptography under per-Client encryption keys. Plaintext credentials are not written to application logs.
3.3 Token Lifetime. Most broker session tokens expire on a daily cycle as set by the broker. The Platform prompts the End User to re-authenticate as required. The broker's session-management rules apply; the Platform does not extend or override them.
3.4 EDIS / DDPI / TPIN. Sell operations require the End User to have authorised their broker for delivery debits using the broker's prescribed mechanism (EDIS, DDPI or TPIN, depending on the broker). The Platform checks for these authorisations before submitting a sell order and shows the End User the broker-prescribed instructional flow when an authorisation is absent. The Client cannot bypass these checks.
4. Symbol Resolution
4.1 The Platform maintains a canonical symbol table and, for each broker, a mapping from that canonical table to the broker's own symbology. Where the same security is listed under more than one suffix (for example after a SEBI-mandated series change), the Platform applies a fallback chain so that orders continue to route to the correct contract.
4.2 New suffix transitions are added to the fallback chain as and when the Company becomes aware of them. The Company makes no commitment as to the precise time within which any specific suffix change is incorporated.
4.3 If symbol resolution fails at order-placement time, the order is rejected with a clear plain-English explanation to the End User. The Client cannot bypass this check.
5. Market Data
Live last-traded price (LTP) is delivered to the End-User app through the Platform's market-data infrastructure, which draws on exchange feeds. End-User screens subscribe to specific symbols on demand.
Previous-day closing prices for indices and stocks are pre-computed after market close on the prior trading day and made available to the End-User app via the Platform.
Daily open-high-low-close is derived from exchange end-of-day data. Intraday history, where shown, is best-effort.
The Platform does not commit to any specific market-data latency.
6. Per-Customer Egress
Certain broker portals enforce per-customer-IP allowlists. For such brokers, each End User is assigned a stable source IP address by the Platform that is registered with the broker as required. The assignment and registration are maintained automatically by the Platform.
7. Operational Reality
The Platform aims for high availability but does not commit to a specific uptime percentage in this Standard. Scheduled maintenance windows, where required, are notified to the Client SPOC reasonably in advance.
Broker-side maintenance windows and outages are outside the Platform's control. Where the broker is unavailable, the End User receives a clear message and may retry once the broker is back.
Operational monitoring and watchdog mechanisms are in place internally; their specifics are not externally documented.
8. Data Retention
End-User personal data, order records and audit logs are retained for periods consistent with Applicable Law (including SEBI record-keeping requirements and the DPDP Act 2023). Operational telemetry and diagnostic logs are retained for periods determined by the Platform's operational needs. The Client may request a Client-specific data export on termination per Clause 6.6 of the MSA.
9. What This Standard Does NOT Support
Brokers not listed in §2.
Foreign brokers or non-INR settlement.
End Users sharing a single broker login across multiple End-User accounts on the Platform.
Client-specific or End-User-specific market-data sources outside the Platform's standard data infrastructure.
10. Changes to This Standard
The Company may amend this Standard at any time. Broker additions and removals, authentication-flow changes, and market-data infrastructure changes are expected from time to time as the upstream broker and exchange landscape evolves.