The Concordance Manifesto
For decades, financial software has been graded on whether the number looks right. We think users — and regulators — now deserve to see why it's right.
Resources
Whether you’re comparing vendors, planning an integration, or making the case to your compliance team, there’s something here written for you. And we hold our writing to the same standard as our product: real sources, no invented statistics, and every claim about a model you can check against its published spec.
Start here
New here? These four are the best places to get your bearings.
For decades, financial software has been graded on whether the number looks right. We think users — and regulators — now deserve to see why it's right.
One POST, one JSON response — and a plain-English explanation of every field that comes back, including the ones worth storing.
Every procurement process asks roughly the same ten questions. Here are our actual answers, each backed by something you can check — including the ones where the honest answer is “not yet.”
The industry has been building a category without naming it. This essay names it: what the checkable-computation layer is, what belongs in it, and where it ends.
Foundations
Why we believe financial numbers should be computed, cited, and checkable — and what that actually looks like.
For decades, financial software has been graded on whether the number looks right. We think users — and regulators — now deserve to see why it's right.
Calculator, model, engine, spec — the industry uses these four words interchangeably. We don't, and the differences turn out to matter.
If someone questions a number in your product, can you show them where it came from? Here are the six answers a financial UI should always have ready.
Is that calculator your competitive edge, or just plumbing? Eight honest questions to help you decide what deserves your team's time.
The formula fits on a napkin. The edge cases, the annual updates, and the years of maintenance? Not so much.
Language models predict; your users assume the number is exact. Here's why that gap matters, and what to do about it.
A black box asks users to take the answer on faith. A glass box lets them follow every claim back to its source. We think the choice is easy.
What do users, regulators, and reviewers actually check before they trust a number? Twelve signals, ranked by how much weight they really carry.
A worksheet for putting real dollars on the build-vs-buy question — including the maintenance costs that rarely make it into the estimate.
Every generation of financial software has rebuilt the same calculators from scratch. Here's how the pattern took hold, and why it's finally breaking.
Model catalog
A closer look at the models we ship: what each one computes, what it assumes, and what it deliberately leaves alone.
Seven inputs, one practical question: will the lower rate pay for its closing costs before you move? A walk through the model, straight from the spec.
What does financial independence actually mean once you have to write it in code? A withdrawal rate, a target multiple, and a spec that's honest about its limits.
Claim at 62, at full retirement age, or at 70? The model compares all three honestly — formulas published, assumptions stated, exclusions named.
Rent versus buy isn't a monthly-payment comparison — it's a net-worth race. This model runs it in the open, one year at a time.
Eight loan models, one verification standard — and the story of a rounding bug our own review caught before any user ever saw it.
RSUs, ESPP, and the mega-backdoor Roth: three equity-comp models that tell you their boundaries before they show you the math.
Roth or traditional is really a question about marginal tax rates, not philosophy. The model treats it that way.
This model doesn't price a policy. It compares the quote in your hand against carrying the risk yourself — which is the decision people actually face.
Given what you can realistically save each month, when will your buffer actually exist? That's a question people act on — unlike a guilt-inducing target number.
The HSA contribution limits are in our registry today; the projection model is still on the roadmap. Here's exactly where that line sits, so nobody confuses the two.
Engineering & integration
From your first API call to production — versioning, error handling, and knowing when something's off.
One POST, one JSON response — and a plain-English explanation of every field that comes back, including the ones worth storing.
A div, a script tag, and you have a calculator whose math you can cite. What the embed does, what it deliberately doesn't, and where the attribution goes.
Pin a test fixture to a spec version and a hash, and “the vendor changed something” becomes a red build instead of a production incident.
Five database columns turn every answer your product shows into evidence you can produce later. The schema, plus the retention logic to go with it.
The API rejects out-of-range inputs rather than quietly adjusting them. Your UI's job is to turn that rejection into helpful guidance, not a wall.
Replacing math nobody fully remembers writing? Shadow mode, a diff harness, and a cutover you can defend to anyone who asks.
One enforced backstop, no run quota at all, and a meter that counts stored households rather than calls. What to build against, and what not to bother building.
Five metrics tell you whether your embedded calculation layer is healthy — and the response envelope already carries all five, if your logging keeps the right fields.
Thirty-three checks across six areas — everything our integration guides recommend, condensed into one runnable list. If every box checks, your integration is boring. That's the goal.
The shadow-diff-cutover pattern, applied to the messiest case we know: a retirement tool with years of history and units nobody wrote down.
MCP & AI assistants
How to give an AI assistant real math to lean on, and how to prove it actually used it.
One endpoint, six tools that need no key, and a whole household projection an assistant can run without an account. Here's how to connect any MCP-capable client, tool by tool.
What happens when an assistant answers from memory instead of using a tool? We lined up real tool output against two years of constant drift so you can see for yourself.
The prompt patterns, response templates, and refusal behaviors that make an assistant's numeric answers reproducible instead of merely plausible.
A conversation is testimony; a trace is evidence. How to store your assistant's tool calls so that every number it ever gave can be traced back to a computation.
Our catalog offers dozens of models — your assistant probably shouldn't offer all of them. How to choose, describe, and stage the tools it can reach.
Twenty-five adversarial prompts every deployed financial assistant should be able to pass. Deliberately generic, so the list outlives any single vendor.
Same engine, same response, two ways in. The real question is who owns the tool loop — the assistant client or your backend — and what each one can promise.
When an assistant doesn't know a contribution limit, a good refusal beats a confident guess. The craft is making that refusal specific enough to be useful.
“What's the 401(k) limit this year?” isn't a computation — it's a lookup, and it deserves the same care. Two grounded ways to answer the questions models most often get wrong.
250 test cases per model, agreed by two implementations written independently from the published spec. What's in the datasets, which ones are public, and how to turn them into a benchmark for your assistant.
Compliance & auditability
For regulated teams: the records, the review workflows, and the audit trail behind every number.
The 2011 model-risk guidance predates every calculator API, but its vocabulary maps surprisingly well onto published specs and Concordance testing. Here's the mapping — and where your obligations remain your own.
Broker-dealers keep records under Rule 17a-4; advisers under Rule 204-2. The response envelope works as a record under both — as long as your storage layer holds up its half.
FINRA Rule 2210 asks whether a communication is fair, balanced, and not misleading. A calculator can answer with its stated assumptions — if your integration keeps them visible.
A calculator that quietly adjusts your inputs is answering a question about someone else's situation. Consumer-protection law has words for that — and there's an engineering pattern that never does it.
A user disputes a number. A reviewer samples one. An examiner asks about one. The same five-step replay procedure answers all three.
One afternoon a year per model family, a short memo at the end, and every input an artifact you can open. The routine that keeps “reviewed” from meaning “reviewed once.”
Every procurement process asks roughly the same ten questions. Here are our actual answers, each backed by something you can check — including the ones where the honest answer is “not yet.”
Change management usually lives in tickets nobody outside the vendor ever sees. A public, versioned changelog turns it into governance evidence — and a recent release shows the whole thing working.
State insurance law is strict about what an “illustration” may show. Our insurance-adjacent models stay firmly on the planning side of that line — here's where it sits, and who owns what.
Every artifact a reviewer will ask about, the URL where it lives, and the obligation it usually serves. Worth bookmarking if compliance is your job.
Comparisons
Build it, buy it, or blend the two? The honest trade-offs, one decision at a time.
The comparison isn't really about the arithmetic — it's about everything that has to stay true around the arithmetic. Six dimensions to weigh.
Embed widget, backend API, or MCP? Three ways to put Concordance-tested math on a product surface, and how to pick the one that fits yours.
There are two ways to produce a number: arithmetic and prediction. The best products know exactly when to use which.
A number on a page is either bound to a source that updates, or it's quietly drifting. And the gap widens every revision cycle.
Open-source libraries and maintained registries are both valid choices. The real question is who owns the maintenance calendar.
An all-in-one suite hands you a finished UI; composable models hand you a catalog. Both are legitimate — it comes down to who should own the top layer.
A visible “powered by” badge is a real cost to some brands and a real benefit to others. It depends on who your end user is and what they should see.
Two ways to defend a number in front of a customer: compliance-approved copy, or an answer that cites its model. Which artifact should carry the weight?
Regulatory surfaces, constant registries, and data quality vary enormously across countries. Starting US-only is a scope decision, not a shortcoming.
“Free” means very different things across fintech APIs. What matters is how durably each vendor commits to what free means — and how you'd tell.
Vertical playbooks
How this works in your corner of the industry — advisor platforms, banks, credit unions, and more.
Advisors own the recommendation; the platform should own the arithmetic underneath it. The integration pattern for advisor software, from model selection to the record in the client file.
Retail brokerages ship calculators into the most rule-dense communications environment in consumer finance. Here's how to make those tools genuinely reviewable — not just reviewable in theory.
Banks run some of the most-used calculators on the web, and keeping them current is a constant struggle. The integration pattern for digital banking teams, with the UDAAP discipline built in.
Personal-finance apps are great at showing people their money, and weaker at answering “so what should I do?” Here's how to turn insights into real computations — no quant team required.
Every fall, every limit moves, and every enrollment page has to be right on day one. The integration that finally makes that calendar boring.
Advisory work runs on scenario arithmetic. The integration pattern for CPA practices and the platforms that serve them — with the tax-prep boundary kept clean.
Lenders need borrower education that builds trust without turning into a quote. Here's how to keep the calculator layer and the rate sheet strictly apart.
Big-bank member expectations, community-institution budgets. How a credit union can ship a full Concordance-tested calculator suite with two lines of markup per page — free, with attribution.
For editorial teams, the numbers age faster than the articles do. Here's what an evergreen tool strategy looks like when the numbers stop aging.
Coaching products run on assessments and behavioral framing. Concordance-tested models are what make the arithmetic inside those assessments real.
Toolkits
Checklists and worksheets your team can put to work this week.
Thirty-nine items across product, engineering, compliance, marketing, and support — what a shipped calculator looks like when nothing got skipped.
The checklist every editor should walk each October and November — before a page quietly serves last year's numbers all year long.
One page, twelve fields, per calculator. Enough for a reviewer to understand in five minutes what the tool actually does.
Fifteen heuristics for scoring your current calculator. Score it honestly, then fix from the top.
Six questions that point you to the calculator most worth adding to your product first.
Where the badge needs to appear, and in what form. An hour of auditing that prevents most attribution failures.
Ten questions to ask any model vendor before you sign. Good answers look alike — what varies is whether the vendor can produce them at all.
The edge cases a serious retirement planner has to handle. Check your current tool against the list, then fix the gaps that matter for your audience.
Every feature a real mortgage tool might need. The gap between this list and your tool is where users give up and leave.
Constant, source URL, revision date, spec version — ten minutes per article before publish, hours saved every time it ages.
Facts & reference
The constants behind the math, and exactly where every one of them comes from.
Nine fields turn a tax constant from a number in code into a claim you can check. This is the registry our models actually read — published from the same file the engine imports.
Three IRS documents set almost every 2026 number a financial calculator needs — and they arrive on two different calendars. Here's the map, with the registry values alongside.
Two reference factors, the reduction formulas behind them, and a deliberately short list — plus the repealed rules a registry has to remember without ever applying.
Credit pricing, insurance underwriting, market forecasts — a catalog of things we deliberately don't model, each with its reason. Scope you can read is scope you can trust.
Fifty state tax codes, one exact jurisdiction field. Why the registry stops at state lines, and what to do on the other side of them.
Forty-eight divisors from IRS Publication 590-B drive every RMD computation. How the table lives in the registry — and why the last row reads “120 and over.”
One URL shows our own traffic: daily hits per surface, thirty days deep, aggregates only. What the fields mean, and what the endpoint deliberately can't tell you.
Every behavior change lands as a versioned, dated entry generated straight from the specs. A reading guide, with a real entry unpacked.
Every model ships with 250 Concordance cases — the same ones our CI runs, with the sample models' datasets fully public. How to get a set, what the tolerance means, and what reproducing it proves.
Constants are claims, and claims age. Why every registry row carries the date a human last checked it — and what an honest public correction looks like.
Buyer & leadership
The executive view: what this costs, what it saves, and why it holds up over time.
For engineering leaders: the work that simply stops happening when the math is embedded — and what that freed capacity is actually worth.
For CFOs and COOs: what it really costs to maintain calculator constants in-house, framed the way you'd frame any other maintenance risk.
For product leaders: how to sequence adoption across a product line, starting with the calculators whose failure would hurt the most.
For procurement and legal: what you keep if you ever leave, the portability commitments behind that, and what offboarding really looks like.
For procurement: the questions that separate a durable free-tier commitment from a marketing one.
For content leaders at banks, insurers, and RIAs: the discipline that turns a calculator page from a maintenance burden into something you can defend.
For CCOs and heads of compliance: the governance case for moving calculator math to Concordance-tested external models — and what it changes about your review workflow.
For VPs of Engineering: what the reclaimed quarters actually look like, and how to spend them well.
The industry has been building a category without naming it. This essay names it: what the checkable-computation layer is, what belongs in it, and where it ends.