TECHNICAL STANDARD — MODEL PORTFOLIO
Version 1.0 | Effective: [Effective Date of MSA] | Published at platform.alphaquark.in/model-portfolio
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 Model Portfolios behave on the Platform: how the Client constructs them, how End Users subscribe, how rebalances are computed and issued, and how the Platform handles broker authentication failures and rejections.
2. Lifecycle of a Model Portfolio
Creation. The Client creates a Model Portfolio in the admin dashboard by specifying a name, a benchmark, a holdings list with per-stock allocation, and one or more subscription plans with name, duration and price.
Subscription. End Users subscribe by purchasing a plan through the Platform's payment flow. An active subscription is the entitlement that triggers rebalance delivery.
Initial Allocation. On first subscription, the End User receives the current portfolio composition as a set of BUY recommendations, sized to the End User's chosen capital. Allocations are rounded to whole shares; the resulting cash drag is shown to the End User explicitly.
Rebalance. The Client issues a rebalance from the admin dashboard. The Platform fans this out to all subscribed End Users.
Closure. Plan expiry, Client-initiated closure or End-User cancellation ends the subscription. The Platform does not auto-liquidate End-User holdings on expiry.
3. Subscriber-Execution Model
3.1 Each End User executes their own trades through their own broker account. The Platform does not aggregate End-User orders, does not custody assets, and does not act as a Portfolio Manager. The Client does not have execution discretion over any End User's account — every order requires explicit End-User approval through the Platform.
3.2 The Client's published model-portfolio return is computed at the model-portfolio level. Individual End Users' realised P&L may differ materially due to (a) entry timing, (b) sizing rounding, (c) cash availability, (d) broker rejections, (e) trades the End User chooses not to act upon, and (f) partial fills.
4. Rebalance Semantics
Rebalance Issuance. Rebalances are issued by the Client at the Client's discretion. The Platform does not enforce any minimum or maximum rebalance frequency.
Composition Model. A rebalance replaces the target composition for the model portfolio. The Platform does not support partial composition updates as a separate mode.
Trade Generation. The Platform computes the per-End-User trade set by comparing the End User's Platform-recorded holdings against the new target composition, scaled to the End User's current allocation. Offsetting trades in the same scrip are netted before issuance.
Order Submission. When the End User accepts a rebalance, all calculated trades are submitted together as a single atomic batch. The End User cannot selectively accept some legs and reject others within the same rebalance; the choice is to accept the rebalance or to skip it.
Skipped Rebalances. If the End User does not accept a rebalance, the End User remains in their pre-rebalance state. The next rebalance is computed against the End User's actual holdings at that future point in time; the skipped rebalance is not retried automatically.
5. Broker Authentication and Rejections During Rebalance
Token Expired. The End User is shown a re-auth prompt; the rebalance is held in a pending state until the End User re-authenticates.
Broker Maintenance / Unavailability. If the broker reports an unavailability or maintenance state, the rebalance fails for that End User and the End User is shown a clear message. The End User may retry once the broker is available.
Order Rejection. Broker rejection responses are translated by the Platform into plain-English messages shown to the End User. The translation is maintained by the Company and is not Client-customisable.
Partial Fill. See Order Execution Standard §4.
6. Multi-Broker End Users
End Users with more than one connected broker account select the broker at order-placement time. The Platform does not split a single recommendation across multiple brokers, and does not aggregate holdings across brokers for the purposes of rebalance computation. Each broker account is treated as an independent portfolio.
7. Holdings Source of Truth
For the purposes of rebalance computation, the End User's holdings are taken from the Platform's record of executed orders, not from the broker's live holdings API. This is by design — broker holdings can drift from Platform records when the End User trades outside the Platform; the Platform does not reconcile such external trades, and rebalance computations will not account for them.
8. Performance-Monitoring Subscription
Every Model Portfolio carries an internal performance-monitoring subscription that the Platform uses for end-to-end notional P&L tracking. This subscription does not place real trades and does not appear in End-User-facing performance figures. The Client may not remove it.
9. What This Standard Does NOT Support
Client-initiated execution on an End-User's broker account without per-recommendation End-User approval.
Auto-rebalance on a Platform-enforced schedule (rebalances are always Client-initiated).
Cross-broker portfolio aggregation.
Synthetic back-tested model portfolios dated before they went live on the Platform.
Tax-loss harvesting, lot-selection or FIFO/LIFO optimisation at the broker level.
Currency-hedged or multi-currency portfolios.
10. Changes to This Standard
The Company may amend this Standard at any time in accordance with Clause 4 of the MSA. Material changes will be notified to the Client SPOC at least seven (7) days before they take effect.