A single blended risk tolerance number is a poor tool for a client who is actually funding several different goals with several different time horizons and several different consequences for shortfall. Goals-based planning replaces one portfolio with a mental structure of funding buckets, grouping money by the goal it serves rather than by asset class alone. A near-term, must-not-fail goal such as next year's tuition payment is funded conservatively. A decades-out, can-flex goal such as a comfortable retirement or a discretionary legacy can carry real risk, inside the same overall relationship. The common three-tier grouping runs from essential needs that must be funded with near-certainty, through lifestyle goals that should be funded with high confidence, to aspirational or legacy goals that can tolerate real variance. Each tier gets its own horizon, its own risk level and its own way of being graded. The question stops being "did the whole portfolio beat a benchmark" and becomes "is this specific goal on track."
Advertisement
What is a funding ratio?
"On track" is a computable number: the funding ratio, the present or future value of assets currently earmarked for a goal divided by the goal's target, given a stated return assumption. A funding ratio below 100% is not a crisis. It is an input, telling you how much additional saving is required to close the gap, or, less comfortably, how much the goal itself needs to shrink or move later. A Python-verified version of the calculation appears in the practice set and in the core content. Where a funding ratio comes up meaningfully short, the honest next step is a required-contribution calculation: solve for the periodic saving that closes the future-value gap by the goal's date. The alternative, an unexamined instruction to "just take more risk", raises the expected ending value and also raises the chance of an even worse shortfall. A goals-based plan exists to make that trade-off visible and chosen rather than silent and accidental.
This is precisely the point at which this module deliberately stops and hands off. Turning a set of goal-buckets into an actual optimized portfolio (deciding the covariance-aware allocation across buckets, applying a liability-relative optimization, or blending views into an equilibrium-return starting point) is AA1.02's machinery, not this module's; this module produces AA1.02's inputs (the goals, the horizons, the funding ratios, the risk each bucket can tolerate) and stops there, exactly the way QM1.03 hands its Monte Carlo construction to the quant-code region rather than building it twice.
Modern Data Analysis: automating the funding-ratio and goals dashboard
The by-hand funding-ratio arithmetic above is the right way to learn the mechanic, you need to be able to compute it cold, with a calculator, because a client-facing number you cannot sanity-check by hand is a number you cannot defend. But a real practice with dozens of clients and hundreds of goals does not recompute each one by hand every quarter. The production version is a small pandas job: one dataframe of goals (client_id, goal_name, target_amount, target_date, amount_earmarked, expected_return), one column computing months-to-goal from today's date, one column computing the future value of the earmarked amount at the goal's expected return, and one column dividing that into the target to produce a funding ratio per row, then a groupby("client_id") to roll every client's goals into a single dashboard, flagging any row below, say, 90% funded for a review conversation. This is exactly the kind of repetitive, well-specified, numerically verifiable task the quant-code region (the DA branch) teaches you to build and validate properly, the point of naming it here is not to re-teach pandas, it is to make explicit that the arithmetic you just did by hand is the unit the code scales, and that scaling it does not remove the obligation to spot-check a sample of the dashboard's output against a hand calculation before you trust it for a real client review.