Rebalancing workflow in iRebal

This lesson walks through the operational workflow for quarterly rebalancing using Eclipse iRebal. By the end, you'll understand each stage and your role in it.

Stage 1: Sync accounts

Before any rebalancing run, Orion and iRebal must have current, reconciled data.

Operations team responsibilities:

• Confirm all accounts are reconciled in Orion (no pending transactions, corporate actions resolved)
• Verify cash balances include any pending deposits or distributions
• Flag accounts that should NOT be rebalanced this cycle:
  • Accounts with pending rollovers or transfers
  • Accounts where the client has requested a hold (e.g., pending large withdrawal)
  • Accounts in the process of transitioning to a new model
  • New accounts that haven't been fully funded yet

The "Do Not Trade" (DNT) flag in iRebal excludes flagged accounts from the rebalancing run. Forgetting to flag an account is a trade error waiting to happen.

Stage 2: Run analysis

With clean data, iRebal analyzes every non-flagged account against its assigned model.

What iRebal evaluates:

• Current allocation vs. target allocation
• Which asset classes have drifted beyond the ±5% rebalancing band
• Cash position: is the account over or under the target cash reserve?
• Tax-lot information for taxable accounts
• Wash-sale rule lookback (30-day purchase history)

iRebal produces a proposed trade list for every account that needs rebalancing. Most accounts in any given quarter will be within tolerance and require no trades.

Stage 3: Review proposals

The advisor reviews every proposed trade before approval. This is not a rubber stamp — it's a substantive review.

Advisor review checklist:

• [ ] Are the proposed trades consistent with the client's current situation?
• [ ] Have any client-specific tax events occurred that iRebal wouldn't know about? (large capital gain from stock sale, expected income change)
• [ ] Is the client approaching an RMD deadline? (ensure sufficient cash or liquidation is planned)
• [ ] Are there wash-sale concerns from recent tax-loss harvesting?
• [ ] Is the trade size proportionate? (very small trades may not be worth the transaction cost)
• [ ] For new clients: has the transition plan been followed? (gradual transition from legacy holdings, not a one-day liquidation)

Advisors mark each household as "approved," "modified" (with documented changes), or "deferred" (with a reason and follow-up date).

Stage 4: Approve and submit

Once advisors have approved their books:

1. Operations compiles the approved trade list
2. A second team member reviews the compiled list against advisor approvals (double-check protocol)
3. Trades are batched by custodian and submitted
4. ETF trades: market orders for liquid ETFs, limit orders for less liquid positions
5. Mutual fund trades: submitted before the NAV cutoff time

Timing matters. All equity trades should be submitted between 10:00 AM and 3:30 PM ET. Mutual fund orders must be received by the custodian before 4:00 PM ET to receive same-day NAV.

Stage 5: Reconcile

Within 24 hours of execution:

• Operations matches each executed trade confirmation against the approved proposal
• Any discrepancies (wrong quantity, wrong fund, partial fill) are flagged immediately
• The post-trade allocation for every rebalanced account is verified against target bands
• The trade blotter is updated with execution details (price, time, confirmation number)
• Any accounts that were deferred in Stage 3 are added to the follow-up tracker

The quarterly rebalancing cycle is not complete until every rebalanced account has been verified as within tolerance bands.

Household-level rebalancing

Minerva rebalances at the household level, not the individual account level. This means we consider all of a client's accounts — 401(k), IRA, Roth, brokerage — as one portfolio.

Why this matters:

• The household may be perfectly balanced even though individual accounts are "off" (e.g., the IRA holds 80% bonds and the brokerage holds 80% stocks — the aggregate is 50/50 as intended)
• Rebalancing trades are placed in the most tax-efficient account (sell stocks in the IRA, not the taxable brokerage, to avoid capital gains)
• Cash raises for distributions come from the account type that minimizes tax impact

iRebal is configured to optimize across all household accounts. But advisors must verify the household-level view makes sense given each account's tax character.

Key takeaways

1. The quarterly rebalancing workflow has five stages: sync, analyze, review, submit, and reconcile.
2. The "Do Not Trade" flag must be set on accounts with pending activity before any rebalancing run.
3. Advisor review is substantive, not a rubber stamp — client-specific tax and life events must be considered.
4. Household-level rebalancing optimizes across all accounts for tax efficiency.
5. The cycle isn't complete until every rebalanced account is verified within target tolerance bands.

Glossary

• Do Not Trade (DNT) flag — A setting in iRebal that excludes an account from the current rebalancing run due to pending activity or client request.
• Household-level rebalancing — Treating all accounts belonging to a client or couple as a single portfolio for rebalancing purposes, optimizing trades across accounts for tax efficiency.
• Tolerance band — The acceptable range of drift around a target allocation (typically ±5 percentage points) before rebalancing is triggered.
• NAV cutoff — The daily deadline (typically 4:00 PM ET) by which mutual fund orders must be received to execute at that day's net asset value.
• Trade blotter — The record of all executed trades, updated with execution details during the reconciliation stage.
• Deferred account — An account whose rebalancing has been postponed by the advisor, with a documented reason and follow-up date.