Risk Profiles: tolerance, capacity, and a suitability record with dates on it.

Dan Mueller11-min read

In most planning software the client's risk profile is a dropdown. Five rungs, conservative through aggressive, sitting on an assumptions page. Somebody picked one. There is no record of who, no record of when, no record of why, and no relationship at all between the rung and whether the household's plan can actually support it.

That dropdown was Foundry's answer too, until last week. clients.risk_tolerance was a single enum with no provenance and no date. It is now read-only, and it links to something considerably harder to argue with.

What actually gets asked

The uncomfortable part of a risk profile is rarely the rung. Ask any experienced advisor to eyeball a household and they will land within one notch of where the questionnaire lands. The uncomfortable part is everything around it: how you got there, when, what you were looking at, and what happened the last four times the answer moved.

The SEC's 2019 interpretation of the adviser standard of conduct puts a reasonable understanding of the client's objectives inside the duty of care, formed at the outset and updated when circumstances change. Regulation Best Interest and FINRA Rule 2111 both build on a customer investment profile that includes risk tolerance. None of these say "keep a dropdown." They describe a process with a shape: it has inputs, a date, a reason, and a history.

Most firms do that process. Almost none of them have software that keeps the record of it. The reconstruction happens later, from meeting notes, when someone asks.

This post describes how a tool works. It is not legal or compliance advice, and your firm's obligations depend on your registration and your own policies.

Three components, one scale

A Foundry risk profile is three numbers, and they are on one scale so they can be compared directly.

ComponentWhat it measuresRangeSource
ToleranceWillingness to accept loss0 to 100Questionnaire, or a hand-set rung with required reasoning
CapacityFinancial ability to absorb loss0 to 100Derived from the plan, refreshed when the plan changes
EnvironmentCircumstances right now-25 to +25Advisor, with required reasoning

They combine like this:

adjusted   = clamp(tolerance + environment, 0, 100)
composite  = min(adjusted, capacity)
level      = band(composite)

band() uses flat 20 point bands: 0 to 19 conservative, 20 to 39 moderately conservative, 40 to 59 moderate, 60 to 79 moderately aggressive, 80 to 100 aggressive.

Capacity is a ceiling, not half of an average

This is the one design decision that matters more than the rest of the tool combined.

Take a 63 year old who scores 90 on the questionnaire. Genuinely comfortable with volatility, held through 2008, wants growth. Now run their plan: seven years to retirement, a 5.2% withdrawal rate, Social Security covering a third of spending. Capacity comes back 25.

Average the two and you get 57. That reads as Moderate. It is a defensible looking number produced by arithmetic that quietly deleted the only fact that mattered, and nothing on the screen tells you it happened. If that household takes a moderate allocation into a bad first five years of retirement, the reconstruction afterward is not going to go well.

Under a ceiling the same household lands at 25, reads as Moderately Conservative, and the profile says in plain words that capacity is the binding constraint. The number and the reason arrive together.

Foundry stores that reason as a field. binding_constraint is capacity when the plan is what's holding the household down, and tolerance when their willingness is. The two are different jobs. Capacity-constrained households are the suitability exposure. Tolerance-constrained households are the coaching opportunity: they can afford more risk than they will stomach, which is a conversation, not a filing.

The environment adjustment moves tolerance and only tolerance. It can lower a profile freely, and it can never lift one through the ceiling. A tolerance of 90 with a +25 adjustment against a capacity of 25 is still 25. This enforces a rule worth teaching: if the off-plan assets are real, model them in the plan. An expected inheritance does not belong in a comment box where it silently loosens an allocation.

Where capacity comes from

Capacity is not a survey answer. It is five weighted factors read off the household's own projection.

FactorWeightScores nothing atFull marks at
Years to retirement0.500 years20+ years
Guaranteed income coverage0.480% of spending100% of spending
Length of retirement0.150 years25+ years
Withdrawal rate0.156% or more0%
Funding buffer0.150.801.50

Two things about that table are deliberate.

Time is two clocks, not one. Years to retirement is the sequence of returns window: how long before the portfolio has to start paying out. Length of retirement is how long the payout is spread across. A single lifetime horizon scores a 58 year old seven years from retiring the same as a 38 year old, because both have roughly 35 years to plan end. They are not the same household. Splitting the clock is what fixes that.

The weights sum to 1.43, and the score is capped at 100. That is not a bug in the arithmetic, it is headroom. There are two unrelated ways to have real capacity: you will not touch the money for two decades, or Social Security and pensions already cover the spending so a drawdown never forces a sale. The second one holds regardless of age. A fully floored 75 year old has capacity that no horizon term will ever credit them with. Either route alone carries an ordinary household to roughly 90. The three supporting factors maxed out, with no runway and no income floor, reach only 45. They are evidence, not engines.

The detail page shows all five contributions as bars, so when capacity comes back 41 you can see which factor did it, and what would move it.

Capacity recomputes off the plan through the existing compute cache, keyed on a hash of the effective scenario tree and the firm's capital market assumptions. It recomputes exactly when something upstream changed and serves cache otherwise. A nightly sweep keeps the profiles of households nobody has opened from going stale.

The questionnaire

RTQ v1 is five weighted questions, fixed and versioned in code so a score recorded today stays interpretable after v2 ships.

#QuestionWeight
1Your investments lose 20% over six months. What do you do?30%
2Which range of ten year outcomes would you rather live with?25%
3Which best describes your goal for this money?20%
4During past declines (2008, 2020, 2022), what did you actually do?15%
5How would you describe your investing experience?10%

Three notes on the design, since a questionnaire is only as good as the reasons behind its questions.

Question 3 asks about goal priority, not time horizon. Horizon is already half the capacity score. Asking it here would let one fact push both ceilings, which double counts it and makes the profile look more confident than the evidence supports.

Questions 1 and 4 both probe drawdown behavior on purpose. Question 1 is stated behavior, question 4 is revealed. When they disagree, that gap is worth reading before the meeting. Question 4 also offers "I was not invested at the time", which drops the question and redistributes its 15 points across the other four, so a 32 year old is not marked down for having no crisis history.

There are three ways in: email the client a tokened link, sit with them and fill it out together, or set the rung by hand. All three record their provenance. The manual path requires written reasoning before it will save, because a hand-set rung with no explanation is an unexplained change to a suitability record.

When a spouse takes it too, household tolerance is the lower of the two scores, and both are shown. The disagreement between them is exactly the thing an advisor needs on the screen.

The one number the software refuses to produce

The questionnaire closes with free text: are there circumstances in your life right now that make you want to take more or less risk than usual?

That prose is never converted into a numeric adjustment. It arrives on the profile page as an unreviewed note with a banner on it. An advisor reads it, decides what it is worth, and records the environment adjustment themselves with reasoning attached. A non-zero adjustment without reasoning is rejected twice, once by the API contract and once by a database constraint.

The plus or minus 25 points of discretion stay with a licensed human. That is the whole point of them.

The record

Every movement writes an append-only event: what kind of change, who made it, the reasoning, the before and after score and level, and a snapshot of all three components as they stood at that moment. The snapshot is what keeps a two year old entry readable after the scoring code has moved on.

One rule keeps that history usable. Capacity drifts continuously, a point or two at a time, as the plan gets edited. Logging every move makes the log unreadable inside a month, so a capacity recompute earns a row only when it moved the household to a different rung. Capacity sliding 61 to 63 writes nothing. Capacity carrying a household from Moderate to Moderately Aggressive writes a row. Every advisor-driven change always logs, because the reasoning is the entire value of the record.

A profile is flagged Review due 12 months after tolerance was last confirmed. Only tolerance ages. Capacity refreshes itself and carries its own computed-on date.

The view across the book

/risk lists every household you can see, with its composite level and score, the binding constraint, tolerance with its source and date, capacity, the environment adjustment, and when it last moved. Four chips call out the states that need action: Not established, Review due, Capacity-constrained, Goals over-reaching.

Not established deserves a note. A household with a computed capacity but no tolerance shows as Not established, not as a profile. Capacity is an ability to bear risk, not a decision to take it. Surfacing those households is the main reason the list exists.

The list runs through the same visibility rules as the clients list, so a per-advisor book silo holds here too. A compliance surface that quietly enumerates households an advisor cannot otherwise see is not a compliance surface.

Alignment is a prompt, never an action

The firm tags its model portfolios with risk levels in CMA. When a household's composite level and the portfolio their base scenario actually runs on disagree, the profile page names both, shows what the taxable and retirement buckets are each really using, and offers an explicit Apply button.

It never applies on its own, and that is a correctness requirement rather than a preference. Capacity depends on the projection, and the projection depends on the model portfolio. Auto-applying closes a loop, capacity to composite to portfolio to returns to funding score to capacity, that is not guaranteed to converge. It would also mean editing a client's grocery budget could silently change their allocation.

There is a fourth chip for the case where the arithmetic and the goals are in open conflict. Foundry solves for the real return that would exactly fund the plan's withdrawals and maps it onto a growth exposure axis between the firm's cash and equity assumptions. When the growth the goals demand exceeds what capacity supports, the household is flagged Goals over-reaching, and the flag points at the plan. Spending, timing, or savings has to move. It never raises the profile to meet the goal, which is the direction that failure usually runs in software that flags this at all.

What you can hand someone

One click exports the profile as a PDF on the firm's branding: the composite level and score, the three components, the five capacity contributions with the plan date they were computed from, the portfolio alignment readout, and the full dated change log with actors and reasoning. It saves to the client's document vault automatically and writes an audit entry on the way out.

That document is the thing that was missing. Not the rung, which was never really in doubt. The account of how the rung was arrived at, what it was checked against, and every time it moved since.

Frequently asked questions

What is a risk capacity score? The household's financial ability to absorb a loss, distinct from their willingness to accept one. Foundry derives it from the plan on a 0 to 100 scale from five weighted factors: years to retirement, guaranteed income coverage, length of retirement, withdrawal rate, and funding buffer.

Why cap at capacity instead of averaging? Averaging hides the binding constraint. Tolerance 90 with capacity 25 averages to 57 and reads Moderate, with nothing on screen saying the plan cannot support it. The ceiling lands at 25 and names capacity as the reason.

How long is a profile good for? Tolerance is flagged Review due 12 months after it was last confirmed. Capacity recomputes itself from the plan, so it does not age.

Does the portfolio change automatically? No. Mismatches surface with both portfolios named and an explicit Apply button. Applying is always an advisor action.


Risk Profiles are live for every Foundry Planning firm, included, with no separate module to buy. Existing risk tolerance rungs were migrated with their original level preserved exactly, so nobody's household moved on day one. The capability tour is here, and pricing is one number.

If your firm's compliance process needs something this does not yet keep a record of, tell us: support@foundryplanning.com.


Written by
Dan Mueller
More articles
Back to the index →