Playbook: Stress-Testing a Rebalancing Engine Without Real Client Data

Stage 1 — Drift-band correctness across the household graph

First, validate that the engine fires (or doesn't) correctly across the full distribution of drift states. The synthetic corpus should include households at every meaningful drift state: well within bands, just outside bands, well outside bands, oscillating across bands, and households where one account is in-band but household-aggregate is out-of-band.

Stage 2 — Cross-account coordination

Real households have multiple accounts. A naive rebalancer that operates per-account will issue trades in account A that get undone by trades in account B. Stage 2 validates the cross-account coordination logic.

For each multi-account household in the synthetic corpus, simulate the rebalancer running and compare the aggregate-trade-list against an oracle (a known-correct optimum computed from the household's full state). The engine must pass the oracle test on at least the held-out portion of the corpus.

Key scenarios: (1) tax-aware asset placement — bonds in tax-deferred, equities in taxable; (2) wash-sale avoidance — selling a security in account A while account B holds the same security and is buying; (3) tax-bracket-aware harvesting — accelerating losses in years where ordinary-income offset is most valuable.

// Cross-account coordination test sketch
for (const household of corpus.multi_account_households) {
  const tradeList = rebalancer.run(household);
  const oracle = optimalRebalance(household, {
    objective: 'minimize_drift_after_tax',
    constraints: ['no_wash_sales', 'asset_location_optimal']
  });
  // Allow some divergence — heuristics are not optimal —
  // but flag households where divergence exceeds tolerance
  if (after_tax_outcome(tradeList) <
      0.95 * after_tax_outcome(oracle)) {
    flagForReview(household, tradeList, oracle);
  }
}

Stage 3 — Tax-aware execution under realistic lot stacks

Stage 3 is where rebalancers that look fine in stages 1 and 2 fail. Real taxable accounts have lot stacks with mixed cost basis, mixed holding periods, and wash-sale exposure to other accounts. A rebalancer's tax-aware execution depends on its ability to navigate these structurally.

Use a corpus with calibrated lot-level structure. For each rebalance trade, evaluate: did the engine pick the right lot (highest cost basis for sells, longest-held for gains realization, shortest-held only when a holding-period transition is imminent)? Did it avoid the cross-account wash-sale conflict that ~6% of would-be-trades create in real-world households? Did it respect QSBS holding-period requirements for §1202-eligible positions?

This is also where holding-period transitions matter: if a lot is 11 months and 28 days from short-term to long-term, the engine should defer the sale by 4 days unless market urgency overrides. The corpus should include households where this trade-off is structurally present.

Stage 4 — Adversarial market regimes

Stages 1-3 use the synthetic corpus at its baseline calibration — roughly 'normal' market conditions. Stage 4 stress-tests the rebalancer under adversarial market regimes by parameterized re-pricing of the corpus.

The regimes we recommend testing: (1) 2008-style crisis — broad equity drop of 35-50% over 6 months with correlated drops in credit; (2) 2022-style stagflation — equity-bond co-drawdown of 15-20% with rising rates; (3) tech-concentration unwind — large-cap tech drop of 40%+ while rest of market is flat; (4) interest-rate spike — rapid 200bp move with bond duration-matched losses.

For each regime, run the rebalancer against the re-priced corpus and look for: (a) excessive turnover (regime-driven over-trading); (b) failure to harvest opportunities (locked-up by drift bands that don't recognize the regime change); (c) wash-sale violations under high-correlation conditions; (d) liquidity strain in illiquid positions.

// Stress regime application
const regimes = [
  '2008_crisis', '2022_stagflation',
  'tech_concentration_unwind', 'rate_spike_2bp'
];

for (const regime of regimes) {
  const stressedCorpus = applyStressRegime(corpus, regime);
  const stats = runRebalancer(stressedCorpus);

  // Watch for the canonical failure modes
  assertWithin(stats.turnover_pct, expected[regime].turnover);
  assertNoWashSales(stats.trades);
  assertHarvestRate(stats.harvest_pct,
    minimum_for_regime[regime]);
}

Reporting: the artifact a production-readiness review consumes

The output of the four-stage playbook is a single review artifact: a stage-by-stage pass/fail with the specific household-IDs that failed each stage. This artifact goes to the production-readiness review and to the algorithm change log.

Good stress-test results don't mean perfect. They mean: known bounded misbehavior in known scenarios, with a documented decision to either fix or accept each scenario. A rebalancer with five known-and-documented edge cases shipped is healthier than one that 'passes all tests' on a thin test corpus.

Key takeaways

• The four stages — drift correctness, cross-account, tax-aware execution, adversarial regimes — each catch a different class of failure. Skipping any of them is shipping with a known blind spot.
• Cross-account coordination is the most-skipped stage. Per-account rebalancers that look fine in single-account QA produce undoing-trades the moment they meet a multi-account household.
• Lot-level structure in the synthetic corpus is the prerequisite for tax-aware testing. Aggregated-cost-basis test data can't exercise the tax-aware paths at all.
• Adversarial regime testing prevents the production failure mode where the rebalancer is fine in normal markets and disastrous in crises. Parameterized re-pricing of a baseline corpus is the standard technique.

FAQ