• An advisor or RIA asks about selecting or migrating to a portfolio management platform
• Questions arise about building, maintaining, or distributing model portfolios
• A firm wants to implement UMA or sleeve-based account management
• An operations team needs guidance on drift monitoring thresholds or rebalancing configuration
• A practice seeks to aggregate held-away assets for holistic financial planning views
• Questions involve daily reconciliation between a PMS and custodian records
• An advisor asks how trades flow from the PMS to the order management system or custodian
• Discussion involves PMS-based performance calculation (TWR, MWR) or composite construction
• A firm needs to configure fee schedules, billing runs, or billable-AUM calculations in the PMS
• Questions concern custodian data feeds, multi-custodian management, or feed troubleshooting
• Trigger phrases: "portfolio management system," "Orion," "Black Diamond," "Tamarac," "Addepar," "model portfolio," "UMA," "sleeve," "rebalancing engine," "drift monitoring," "held-away assets," "portfolio accounting," "reconciliation," "custodian feed," "PMS billing"

For detailed specifications, platform comparison tables, and architecture diagrams, see

references/platform-details.md

.

• Multi-custodian support (Schwab and Fidelity integration required).
• Rebalancing engine capable of handling 12+ models across 800+ households.
• Tax-aware rebalancing with wash sale tracking.
• Automated billing with tiered fee schedule support.
• Performance reporting with composite construction for marketing materials.
• Integration with the firm's existing CRM (Salesforce).
• Client portal for on-demand performance access.

• Export current positions and cost basis from both custodians.
• Reconstruct historical transactions from custodian records (typically 3-5 years for performance history, full history for cost basis).
• Map existing security positions to Orion's security master.
• Import client and account demographic data from CRM.
• Establish the 12 model portfolios in Orion with target allocations and security selections.

• Define each of the 12 models with target weights, drift bands, and rebalancing rules.
• Assign each client account to the appropriate model.
• Configure substitution rules for taxable vs. tax-deferred accounts.
• Set drift thresholds (the firm selects 5% absolute / 25% relative).
• Configure cash reserve rules (2% minimum cash per account).

• Establish Schwab data feeds: positions, transactions, cash balances, cost basis, corporate actions. Test file delivery and parsing.
• Establish Fidelity data feeds: same data categories. Test independently.
• Configure daily reconciliation jobs for both custodians.
• Validate initial reconciliation: resolve any breaks before go-live.

• Run parallel operations for 30 days (maintain spreadsheets alongside Orion).
• Compare rebalancing recommendations from both systems.
• Validate performance calculations against custodian-reported returns.
• Validate billing calculations against historical invoices.
• Train advisors and operations staff on the new workflows.
• Decommission spreadsheet processes after successful parallel period.

• Each client's Investment Policy Statement (IPS) dictates the overall allocation across sleeves based on their risk profile.
• Conservative clients: higher fixed income and lower alternatives allocation.
• Aggressive clients: higher equity and alternatives allocation.
• Sleeve-level models operate independently within their assigned allocation.
• The overlay manager (CIO) can make tactical adjustments within the overlay sleeve without affecting other sleeves.

• The PMS overlay engine monitors unrealized gains and losses across all sleeves.
• When rebalancing triggers a sell in one sleeve, the overlay engine checks whether a loss can be harvested in another sleeve to offset the gain.
• Wash sale rules are monitored across sleeves: if the fixed income sleeve sells a bond fund at a loss, the equity sleeve cannot purchase a substantially identical fund within 30 days.
• Year-end tax management: the overlay engine runs a cross-sleeve analysis to identify harvesting opportunities before December 31.

• Client-facing reports show total UMA performance alongside per-sleeve performance attribution, so clients understand how each strategy contributes.
• Internal reports track model-level performance (how well each model performed independent of client cash flows) and implementation efficiency (how closely client accounts track their assigned models).
• Billing reports calculate fees on total UMA AUM (not per-sleeve).
• Household reports aggregate across multiple UMAs and non-UMA accounts for clients with more than one account.

1. Corporate action breaks (18 accounts): The PMS operations team identifies that a widely-held equity (held in 18 accounts) underwent a 3:1 stock split on the prior Thursday. The custodian processed the split automatically, but the PMS corporate action module failed to pick it up from the data feed. The team manually applies the split in the PMS, adjusting share counts and cost basis for all 18 accounts.
2. Settlement timing breaks (12 accounts): These breaks are expected and will self-resolve when Monday's end-of-day reconciliation runs. The team marks them as "expected timing difference" and monitors for resolution.
3. Data feed failure (8 accounts): The Saturday batch file from Schwab contained a format change in the corporate action field that caused the PMS file parser to reject the entire file for 8 accounts. The team contacts the PMS vendor to update the parser, manually imports the affected data, and re-runs reconciliation for those accounts.
4. DRIP configuration (6 accounts): Six accounts are configured for dividend reinvestment at the custodian but the PMS does not reflect this setting. When dividends reinvest into fractional shares, the PMS records a cash dividend instead. The team updates the DRIP flag in the PMS for these accounts and adjusts positions to match the custodian.
5. Unauthorized trades (4 accounts): An advisor placed 4 trades directly through the custodian platform without going through the PMS. The team enters the trades into the PMS after the fact and counsels the advisor on the requirement to use the PMS for all trade activity.

• Automated corporate action processing: Configure the PMS to automatically apply mandatory corporate actions (splits, mergers) from the custodian data feed, with alerts for actions requiring manual review (tenders, elections).
• Feed monitoring: Implement automated alerts when custodian data files fail to arrive, arrive with unexpected format changes, or contain fewer records than expected.
• DRIP audit: Run a quarterly audit comparing DRIP settings in the PMS against custodian DRIP elections for all accounts.
• Trade workflow enforcement: Configure custodian access so that advisors cannot place trades directly; all trades must originate from the PMS.
• Daily break dashboard: Implement a dashboard showing break counts by category, age, and resolution status, with escalation rules for breaks older than 3 business days.

1. Treating the PMS as the official record. The custodian, not the PMS, maintains the legally authoritative record of client assets. When discrepancies exist, the custodian record governs. Firms that rely solely on PMS data without reconciliation risk reporting incorrect positions and performance.
2. Neglecting daily reconciliation. Firms that reconcile weekly or monthly allow breaks to compound, making root-cause diagnosis much harder. A corporate action missed on Monday may cause cascading errors in performance, billing, and rebalancing throughout the week.
3. Over-engineering drift thresholds. Setting drift bands too tight (e.g., 1% absolute) generates excessive trading, increasing costs and tax drag. Setting bands too loose (e.g., 10% absolute) allows portfolios to deviate significantly from the intended risk profile. Calibrate thresholds based on asset class volatility and client tax sensitivity.
4. Ignoring wash sale rules across accounts. Tax-loss harvesting in one account while purchasing substantially identical securities in another account with the same tax ID disallows the loss. The PMS must monitor wash sale windows across all accounts for a client or household.
5. Stale held-away data. Aggregated held-away data that has not refreshed in weeks or months can lead to materially incorrect total-household allocation views and flawed planning recommendations. Implement alerts for stale connections and establish a process for client re-authentication.
6. Inconsistent model governance. Allowing advisors to freely modify firm models without oversight creates style drift and compliance risk. Establish clear policies on which model elements advisors can customize and require documentation of deviations.
7. Cost basis discrepancies between PMS and custodian. The PMS and custodian may calculate cost basis differently, especially after corporate actions, transfers, or wash sale adjustments. If the firm relies on PMS cost basis for tax-loss harvesting decisions but the custodian reports different basis to the IRS (Form 1099-B), clients may face unexpected tax consequences.
8. Billing on stale or unreconciled data. Calculating fees on PMS positions that have not been reconciled against the custodian may result in over- or under-billing. Always reconcile before running billing.
9. Failing to test custodian feed changes. Custodians periodically update their data feed formats. Firms that do not monitor for format changes or test in a staging environment before production risk silent data-import failures.
10. Overlooking performance calculation methodology. Reporting MWR when TWR is appropriate (or vice versa) can mislead clients or violate GIPS standards. Understand when each methodology is appropriate and clearly label which method is used in client-facing reports.

• asset-allocation (Layer 4, wealth-management) — PMS implements the strategic and tactical asset allocation defined in the client's investment policy. Model portfolios in the PMS are the operational expression of asset allocation decisions.
• rebalancing (Layer 4, wealth-management) — The PMS rebalancing engine applies rebalancing theory (threshold-based, calendar-based, opportunistic) to live client portfolios. The rebalancing skill defines the theory; this skill covers the system implementation.
• tax-efficiency (Layer 5, wealth-management) — PMS tax-loss harvesting, wash sale monitoring, and tax-aware rebalancing apply the tax-efficiency principles defined in the tax-efficiency skill to operational workflows.
• performance-metrics (Layer 1a, wealth-management) — The PMS calculates the return metrics (TWR, MWR, alpha, Sharpe ratio) defined in the performance-metrics skill. That skill defines the math; this skill covers how the PMS implements the calculations.
• performance-reporting (Layer 8, wealth-management) — The PMS generates the underlying performance data that feeds client-facing performance reports. The reporting skill covers presentation and communication; this skill covers calculation and data infrastructure.
• gips-compliance (Layer 9, compliance) — PMS composite construction and performance calculation must satisfy GIPS requirements for firms that claim compliance. The GIPS skill defines the standards; this skill covers the PMS configuration needed to meet them.
• order-management-advisor (Layer 10, advisory-practice) — The OMS receives trade lists generated by the PMS. This skill covers trade list generation; the OMS skill covers order routing, execution, and allocation.
• financial-planning-integration (Layer 10, advisory-practice) — The PMS current portfolio (including held-away aggregation) feeds financial planning tools for projections and scenario analysis.
• fee-billing (Layer 10, advisory-practice) — The PMS fee engine handles billing calculations described here. The fee-billing skill covers the broader billing operations workflow including invoicing, collections, and revenue recognition.
• client-reporting-delivery (Layer 10, advisory-practice) — PMS performance data, portfolio holdings, and asset allocation feeds the client reporting and delivery workflow.