For a member firm, every calculator is a communication with the public and every projection is a supervised claim. The verified-model pattern does not lighten those obligations — it makes them administrable.
Retail brokerages and wealth apps run planning tools at consumer scale under broker-dealer communications rules, which is the hardest version of the calculator problem this series covers: enormous audiences, principal review obligations, and projections that must stay fair, balanced, and substantiated. The compliance pillar's fair-and-balanced piece (/writing/finra-2210-calculators) develops the regulatory frame in depth; this playbook is the product team's side — which models, which surface, and the workflow that keeps review effort proportional to releases rather than usage.
The models and their fit
The self-directed audience's recurring questions map to the retirement and tax families — FIRE projections, Roth-versus-traditional, capital-gains and quarterly-estimates around realization events, RMD for the distribution cohort — plus emergency-fund and debt models for the financial-wellness surfaces wealth apps increasingly carry. Two boundary notes matter more here than anywhere. The catalog computes planning comparisons on user-supplied assumptions; it does not forecast markets, model specific securities, or produce anything resembling a performance projection for a product — the absences that keep a planning tool from drifting into performance-advertising territory. And the sentinel design is a communications asset: the honest extremes arrive as annotated answers, never as invented numbers, which is precisely the behavior a communications reviewer needs the tool to have at scale.
The surface: API, with the review workflow attached
Brokerages should own the tool loop through their backend — the wealth app needs product context, entitlement logic, and trace storage no third-party frame can carry. The distinguishing mechanics for this vertical are in the review workflow around the integration. The reviewable unit is the model version: the principal approves the spec, the presentation, the assumptions surface, and the sentinel phrasings once per version; CI's drift fixture turns any version bump into a red build and a review the moment it ships — firms that need the served version held until review completes should pair it with spec-version pinning, a Pro guarantee — and a changelog bump routes back through review with the entry as the change memo. Envelope storage runs under communications retention, which turns the eventual "what did the tool show this customer in March" into the replay procedure (/writing/audit-replay) instead of a project.
| Obligation surface | Integration response | The deep dive |
|---|---|---|
| Retail communications review | Version-level principal approval, CI-pinned | Fair-and-balanced piece |
| Substantiation | Assumptions and spec link rendered at the number | Fair-and-balanced piece |
| Recordkeeping | Envelopes under communications retention | Books-and-records piece |
| Supervision of change | Changelog-driven re-review, fixture-enforced | Change-control piece |
| Honest extremes | Sentinel phrasings in the approved copy | The refusal and sentinel guides |
Scale mechanics
Consumer scale makes the operational guides load-bearing rather than optional. Debounce interactive controls so sliders cannot become request streams; cache identical runs keyed on model, version, and inputs; watch the five envelope-derived metrics, with the sentinel-trigger rate doubling as a product signal about what your customers' scenarios actually look like (/writing/observability-embedded-math). Write envelopes at trust boundaries, not per keystroke — a slider session is exploration, and the record belongs to the answer the customer lands on. At brokerage volumes the fair-use guideline is a conversation to have early: consistently high volume is the design-partner discussion the pricing page invites, and the terms are written down before it starts.
Migration and the archive problem
Established brokerages carry the industry's oldest calculator estates — tools that predate current teams, embedded constants that predate current tax years. The migration pattern is the standard one (shadow, diff, cut over), with one vertical-specific accelerant: the diff log's stale-constant findings are themselves communications findings, since a tool citing a superseded limit has been making an unsubstantiated claim at scale. Treat the migration as the remediation it quietly is, sequence the highest-traffic tools first, and let the registry-fed models end the annual constants-update project that created the staleness in the first place.
- Review at the model-version level; pin the approved version in CI.
- Keep sentinel phrasings inside the approved copy set.
- Store envelopes under communications retention from day one.
- Debounce, cache, and monitor per the operational guides — scale is the point.
- Route recommendation functionality through the firm's own obligations — planning tools stay planning tools.
- Attribution: visible Powered by Worthune where results reach customers, per the pricing page.
Sources
- [1] Worthune writing: Fair and Balanced, Computed: Calculators as Retail Communications. https://worthune.com/writing/finra-2210-calculators
- [2] Worthune writing: Answering "Why Did It Say That?": The Replay Procedure. https://worthune.com/writing/audit-replay
- [3] Worthune writing: Observability for Embedded Math: What to Log and What to Alert On. https://worthune.com/writing/observability-embedded-math