Financial Planning Integration

Financial Planning Integration

Core Concepts

Financial Planning System Architecture

The financial planning engine is the analytical hub of the advisor technology stack. It ingests client data from multiple systems, models the client's financial future, and produces outputs that drive portfolio construction, cash management, and ongoing advisory recommendations. (For the planning methodology those engines implement, see financial-planning-workflow.)

Relationship to other systems in the advisor technology stack:

• CRM (client relationship management): Source of client demographic data, household composition, employment status, life events, and planning review triggers. The CRM is the system of record for client facts; the planning tool consumes these facts as inputs.
• PMS (portfolio management system): Source of current portfolio holdings, asset allocation, and account types. The plan produces a required return target and risk capacity that feed back to the PMS as constraints for portfolio construction.
• Custodian: Source of account balances, positions, and transaction history. Custodial data feeds ensure the plan reflects actual account values rather than stale estimates.
• Aggregation platform: Source of held-away assets — accounts at other custodians, employer retirement plans, bank accounts, real estate equity estimates, stock options. Aggregation fills the gap between what the advisor custodies and what the client actually owns, which is essential for a complete financial picture.

Common financial planning platforms (as of 2026; verify current vendor lineups): eMoney Advisor, MoneyGuidePro (Envestnet), RightCapital, Naviplan (InvestCloud), and planning modules embedded within all-in-one platforms (e.g., Orion Planning, Advyzon). Platform selection depends on firm size, integration requirements, planning complexity, and client-facing presentation needs. Some platforms emphasize interactive client portals (eMoney, RightCapital); others emphasize advisor-facing analytical depth (MoneyGuidePro, Naviplan).

Goal Data Model and Status Tracking

Goals are the structured records that flow between the planning tool, CRM, and client portal. Each goal carries a defined set of attributes that downstream systems consume:

• Target amount: The dollar amount needed, in today's or future dollars
• Target date: When the funds are needed (single date or range for ongoing goals like retirement income)
• Priority: Essential, important, or aspirational
• Funding source: Which accounts and income streams fund the goal — this account linkage is what connects the plan to the PMS
• Inflation assumption: The category-specific inflation rate applied (general CPI, education, healthcare)

Each goal carries a status derived from its current probability of success, and status updates flow out to the CRM and client portal:

• On track: Probability at or above the target threshold (commonly 80-90%)
• Needs attention: 60-80%, where modest adjustments could restore on-track status
• At risk: 40-60%, requiring significant plan changes
• Unlikely: Below 40%, where the goal may need restructuring or deprioritization

These status indicators must update dynamically as portfolio feeds refresh plan inputs. How to set goals, prioritize among them, and model trade-offs is methodology — see financial-planning-workflow.

Capital Market Assumptions as Governed Inputs

The expected return, volatility, and correlation assumptions behind plan projections are the most consequential — and most frequently desynchronized — data elements in the planning stack.

• Small changes are high-leverage: reducing an expected equity return from 8% to 7% can shift a plan's probability of success by 10-15 percentage points. A single probability number presented without assumption context creates false precision.
• The firm should maintain a single authoritative capital market assumptions (CMA) document — owned by the investment committee, reviewed on a defined cadence (quarterly or annually) — that every system (planning tool, PMS, proposal engine) references. Assumptions set independently in each system will drift apart.
• When CMAs change, all systems must update simultaneously and all client plans should be re-run, with material probability changes flagged for advisor review.
• Distribution choices (normal vs. log-normal, historical bootstrapping, regime-switching) are also assumptions that should be documented in the CMA governance record, since different planning tools default to different methods.

Monte Carlo mechanics and how to interpret probability-of-success results are covered in financial-planning-workflow.

Tax Reference Parameters as Governed Inputs

Planning-tool tax projections depend on annually updated reference data: federal and state bracket thresholds, standard deduction amounts, IRMAA (Medicare income-related monthly adjustment amount) thresholds, contribution limits, and RMD ages. These parameters are data-governance concerns, not just planning inputs:

• Most planning vendors push annual tax-table updates, but firms must verify the update landed before running year-end conversion or withdrawal analyses. A plan computed on last year's brackets silently misstates bracket-fill room and IRMAA exposure.
• Anchor every figure to a tax year in client-facing output. For reference, 2026 values: standard deduction $32,200 (married filing jointly); 22% bracket tops out at $211,400 of MFJ taxable income; first IRMAA threshold $218,000 MFJ (based on MAGI from two years prior). Always verify current-year values — these adjust annually.
• Custom overrides (e.g., a state tax assumption entered manually) should be inventoried and re-validated each year, since they do not refresh with vendor updates.

Plan-to-Portfolio Linkage

The financial plan and the investment portfolio are two sides of the same coin. The plan determines what the portfolio must deliver (required return, risk budget, withdrawal schedule), and the portfolio must be constructed to meet those requirements. When the plan and portfolio are disconnected, the client receives inconsistent advice.

From plan to portfolio — the forward link:

• The plan produces a required rate of return: the return the portfolio must achieve for the plan to succeed at the target probability.
• The plan identifies the client's risk capacity: the maximum tolerable drawdown or volatility before the plan fails. Risk capacity is derived from the plan — a client with a well-funded plan and flexible spending has high risk capacity; a client on the edge of plan failure has low risk capacity.
• These outputs feed the Investment Policy Statement (IPS), which translates planning assumptions into portfolio constraints: target allocation, allowable ranges, rebalancing triggers, withdrawal rules.

The IPS as the bridge document:

• The IPS connects the financial plan to the portfolio. It specifies the return objective (from the plan), the risk tolerance (ability from the plan, willingness from client assessment), and the constraints (liquidity needs from the plan's withdrawal schedule, time horizon from the plan's goal dates, tax considerations from the plan's tax projection).
• When the plan changes, the IPS should be reviewed and updated. When the IPS changes, the portfolio should be adjusted accordingly.

From portfolio to plan — the feedback loop:

• Portfolio performance (actual returns, contributions, withdrawals) feeds back to update the plan. If the portfolio outperforms, the plan's probability of success improves. If the portfolio underperforms, the plan may need adjustment.
• Account-level activity (Roth conversions executed, RMDs taken, tax-loss harvesting realized) affects the plan's tax projection and should be reflected in the next plan update.