Fair and Balanced, Computed: Calculators as Retail Communications

A projection a retail investor can see is a communication, and the communications rulebook applies to it exactly as it applies to prose. The difference is that a well-built calculator can substantiate itself.

FINRA Rule 2210 governs broker-dealer communications with the public: retail communications must be fair and balanced, must provide a sound basis for evaluating the facts, and must not be misleading, exaggerated, or unwarranted — and projections get specific, cautious treatment. When a member firm puts a calculator in front of retail investors, the outputs generally live under the communications rulebook the way a brochure does — which rule provisions attach to a given tool is the firm's compliance call. This piece is about the substantiation problem calculators create, and the artifact set that answers it. It is a collaboration guide for the engineering and compliance functions of member firms, written from the engineering side; the rule's application to any given communication is the firm's principal-review call, not ours.

The substantiation problem, stated as an engineer hears it

When compliance reviews a static brochure, the claims sit on the page and the review is of what is written. A calculator is a claim generator: it will produce numbers nobody reviewed individually, for input combinations nobody enumerated. The review question becomes structural — under what assumptions does this tool compute, are they disclosed where the investor can see them, is the presentation balanced across favorable and unfavorable cases, and can the firm show the basis for any number the tool has ever produced. Those are engineering properties. A tool either has an inspectable assumptions surface or it does not; it either records its outputs or it does not.

What the envelope contributes, element by element

The sentinel row rewards attention because it is where calculators most often drift into unwarranted territory. A refinance tool that quietly extrapolates a break-even for a loan that never breaks even, or a retirement tool that projects an age no table supports, is manufacturing the exaggerated claim the rule prohibits — mechanically, at scale. The platform's sentinel design returns those cases as explicit annotated outcomes instead, which means the extreme arrives pre-phrased for the fair-and-balanced test: the tool says "this scenario never breaks even" rather than inventing a number that implies it does.

A principal-review workflow that scales

The reviewable unit for a calculator is not each output; it is the model version. A workable cycle: at adoption, the reviewing principal reads the spec and the model card (/writing/model-card-worksheet), approves the calculator's presentation with its assumptions surface and disclaimers, and records the approved spec version. In production, the CI fixture pins that version, so any behavior change fails a build instead of silently reaching investors; a version bump routes back through review with the changelog entry as the change memo. The stored envelopes then guarantee that any number the firm is ever asked about traces to an approved version with its assumptions attached. Review effort scales with releases, not with usage — which is the only way calculator review scales at all.

• ✓Review at the model-version level; record the approved specVersion.
• ✓Render the assumptions surface and disclaimer where the investor sees the number.
• ✓Keep sentinel phrasings in the approved copy — the honest extremes are part of balance.
• ✓Pin the approved version in CI so changes cannot skip review.
• ✓Store envelopes under the firm's communications retention.
• ✓Route the final judgment through the firm's principal review — this guide is input to it, not a substitute.

The larger point for both functions

Rule 2210 predates computed communications, but its logic transfers cleanly: claims need basis, assumptions need daylight, extremes need honesty. What changes with a verified-model stack is feasibility. Substantiation stops being a binder assembled after the fact and becomes a property of the response format — every number arrives carrying its version, assumptions, sources, and cautionary language, and leaves a hash-verifiable record behind. Compliance gets a reviewable object; engineering gets a review process that does not veto interactivity. The rule did not get easier; the evidence got better. And to say it plainly one more time: this piece is an engineering description of that evidence, not legal advice — the rule's application belongs to the member firm's compliance function.