Track sector weight drift between stock rebalances
A portfolio that satisfies a sector cap immediately after rebalancing can exceed it later without making another trade. Relative price changes alter weights, and a compliant final snapshot can hide several intervening breaches. Revalue the entire holding interval, record first and sustained exceptions and distinguish monitoring from a policy that actually enforces limits through trading.
This guide follows a fixed synthetic stock account over five observations. It is an external monitoring method, not verified automatic enforcement or live connectivity in CoTrading. Use one currency and market. The caps below are invented research rules, not legal investment limits or recommendations.
Define the monitored account and rules
Record actual share quantities, cash, valuation timestamps and the interval after a known rebalance. Specify whether each cap applies at rebalancing only, at every inspected valuation or continuously. Those are different commitments; a target optimizer’s one-time constraint does not automatically govern later market drift.
Our account holds four A shares, four B and one C, plus cash 100. Every initial price is 100, so NAV is 1000. A is Tech, B Health and C Utilities. The declared Tech cap is 0.45, and the maximum individual stock weight is 0.49.
All classifications are known for the main example. At the initial mark, stock weights are 0.4, 0.4 and 0.1, with cash 0.1, so the stated caps pass. Preserve that initial evidence rather than assuming the rebalance was compliant solely because an optimizer returned successfully.
Obtain complete valuation coverage
For every expected observation, retain prices, price age, quantities, cash and point-in-time classification. Missing quotes cannot be silently replaced by zero weight. The Python finite-number documentation supports the explicit numeric admission checks used here.
Require positive usable prices and positive finite NAV before computing percentages. The sample rejects missing prices, invalid cash and zero NAV, and it supports an all-cash positive-value account. An empty stock list is not the same as an empty or valueless account.
The fixture has exactly five declared consecutive sessions; it is not a production calendar adapter. A real monitor must compare received keys with the expected holding interval. If a day is unknown, do not close an ongoing exception as though the portfolio had been observed back inside the limit.
Revalue shares rather than target weights
Compute each security value from actual quantity times current mark, add cash to obtain NAV, then divide by that total. Aggregate current security weights by the classification effective for that observation. Do not hold yesterday’s target weights constant in a chart when the quantities and prices imply drift.
value[s] = shares[s] * price[s]
nav = cash + sum(value.values())
weight[s] = value[s] / nav
sector_weight[group] = sum(weight[s] for s in members[group])The script checks stock weights plus cash weight sum to one within an absolute tolerance. Cash remains an explicit component; normalizing only securities would inflate sector exposures and describe a different denominator. Also preserve changes from real trades or corporate actions instead of assuming all quantity changes are market returns.
The FINRA concentration-risk discussion notes that asset performance can create concentration. It does not prescribe our caps or certify this monitor. The method below measures an invented example and creates no orders.
Work through a hidden mid-interval breach
A’s prices are [100,140,150,110,100]; B and C stay at 100. Quantities and cash never change. Portfolio NAVs are therefore 1000, 1160, 1200, 1040 and 1000. The same initial and final value does not imply the path remained compliant.
| Session | Tech weight | Tech above 0.45? | Any stock above 0.49? |
|---|---|---|---|
| 0 | 0.400000 | no | no |
| 1 | 0.482759 | yes | no |
| 2 | 0.500000 | yes | yes |
| 3 | 0.423077 | no | no |
| 4 | 0.400000 | no | no |
Tech first breaches at session one and remains above its cap for two inspected sessions. The individual limit first breaches at session two and lasts one. Equality is permitted by these caps; the code uses strictly greater comparisons rather than a threshold chosen after inspecting the path.
At session four, both caps pass again without a trade. Reporting only that final snapshot would erase the period the monitor was meant to detect. Preserve the full interval and exception episodes, not merely the latest status.
Measure first occurrence and duration
Group consecutive observed breach keys into episodes. Store start, end, observed length, peak exposure and the evidence used to close the episode. The sample derives Tech episode [1,2] and individual episode [2] from the actual flags.
Observed-session duration is not automatically elapsed clock time. A gap or uninspected weekend needs the policy’s own interpretation. Do not call two checks two continuous days unless coverage and timing justify that language. Our fixture uses consecutive synthetic sessions for clarity.
Separate a confirmed recovery from missing data. The missing-price counterexample removes B’s third-session mark and blocks the calculation rather than treating the day as compliant. That prevents a data outage from artificially shortening the measured breach.
Preserve unknown classification as uncertainty
The alternative classification test removes C’s sector. Its first-session weight 0.1 goes into Unknown; it is not dropped. Known Tech remains 0.4, but the possible Tech total could be as high as 0.5 if the unknown holding belonged there.
The conclusion is therefore classification_incomplete, not full sector compliance. Later, when known Tech alone exceeds 0.45, a breach can be confirmed even before unknown exposure is resolved. Keep known lower and possible upper exposure distinct instead of inventing a classification to make the table complete.
Real classification changes require effective dates and source versions. Applying today’s label to the full historical interval can alter earlier sector totals. Preserve the original unknown state when corrected data arrives, and create a revised analysis rather than silently rewriting the monitoring history.
The final recovery statement belongs to the fully classified main path. In the alternative with C still unknown, returning prices to their initial levels does not resolve classification uncertainty: known Tech is again 0.4, but its possible upper value remains 0.5. Do not reuse the main path’s compliant label for that alternative. Likewise an episode still open at the last observation needs an ongoing label, not a fabricated recovery date beyond the available interval.
Specify what happens after detection
Our frozen action policy is monitor-only. Shares remain unchanged and orders are zero, even when a breach occurs. A warning is evidence of observation, not proof that an optimizer continuously constrained the portfolio or that a broker automatically reduced exposure.
A real policy might wait until the next scheduled rebalance, request review or initiate a separately authorized action. Document that policy and its execution outcomes independently of the monitor. Trading restrictions, costs and account access can prevent nominal remediation from happening.
If using a read-only holding connector, verify that it is enabled and its snapshots are current. The existence of a portfolio screen does not prove live synchronization. This example consumes supplied synthetic quantities and makes no connection or real-account claim.
Execute and accept the interval report
Download the complete example. Use Python 3.12 or later and run python R636.py. Standard-library assertions verify the weight path, first and consecutive breaches, final recovery, unknown-weight uncertainty, missing-price rejection, all-cash handling and zero-NAV rejection.
Archive account snapshots, expected session coverage, prices, classifications, cap versions, episode records and the action policy. Confirm that no later compliant endpoint replaces earlier exceptions. If the interval is incomplete, qualify the result rather than reporting continuous compliance.
Recompute when holdings, cash, quotes, classifications or limits change, preserving earlier versions. The result verifies synthetic concentration monitoring, not real historical compliance, product-wide constraints or automatic trading capability.
FAQ
Does a compliant rebalance guarantee the whole holding interval?
No. Price changes can create breaches before the next rebalance.
Can unknown sectors be omitted from the denominator?
No. Preserve their weight and the uncertainty they create for sector conclusions.