Your fintech product needs financial planning models and math. That doesn’t mean you have to build them yourself.
Retirement, mortgages, equity comp, insurance timing — the models every fintech, wealthtech, and insurtech product eventually needs, and none should have to hand-build. Every Worthune model is Concordance-tested and ships with its receipts: a published spec, open test cases, sourced constants, and a changelog that never moves silently. Spend your roadmap on the idea only you can build.
no API key · three models free · see pricing
✓ what every response looks like
| breakEvenMonths | 31 |
| monthlySavings | $214.60 |
| specVersion | 1.0.1behavior pinned |
| facts | IRS values used, citedwith sources |
| record.sha256 | 7891f5ea…storable proof |
Computation that shows its work — and why that’s the product.
The math becomes someone else’s job. The proof stays yours to show.
Every fintech roadmap has the same stalled line items: the retirement projector, the payoff planner, the what-if tool. They stall because the math is easy to write, expensive to get right, and worse to maintain. Here’s what happens when you stop owning that problem.
The feature ships this sprint, not next quarter
The engine exists, the edge cases are handled, and the charts come back in the response. Integration is one POST request — or one script tag if you want the whole calculator rendered on your page. What was a two-month build becomes an afternoon of wiring.
→ the 5-minute quickstart“Where does this number come from?” has a real answer
Every model publishes its spec — the formula, the assumptions, what it deliberately leaves out — and every response cites the IRS figures it used, with sources and the version that produced it. When a customer, a reviewer, or your own PM asks, you open a document. You don’t draft an explanation.
→ read the refinance specJanuary stops breaking your product
Contribution limits, brackets, and SSA factors move every year — and stale constants are exactly how calculators quietly go wrong. We maintain the registry against the primary sources and version every change publicly, so your integration doesn’t move when the numbers do.
→ the facts registry, liveYour assistant computes instead of guessing
Language models approximate arithmetic; your users assume it’s exact. Point any MCP-capable assistant at our server and it runs the real model — then cites the spec version in its answer, so the number in the chat is the same number in the spec.
→ MCP setup for Claude & ChatGPTThree steps, no keys, nothing to install
This is genuinely the whole integration.
Pick a model
Browse the catalog and read the spec — inputs, valid ranges, formulas, assumptions. You know exactly what you’re integrating before you write a line.
Call it — or drop it in
POST JSON from your backend, connect the MCP server to your assistant, or embed the finished calculator with a script tag. Same Concordance-tested engine underneath all three.
Show your work
The response carries outputs, plain-language notes on edge cases, the assumptions, the sourced IRS figures, and an audit hash you can store and re-verify later.
// or the no-backend version — a live verified calculator, on your page:
<div data-worthune-embed="social-security-timing"></div>
<script async src="https://worthune.com/embed.js"></script>Whatever you’re building, there’s a short path in
The engine is the same for everyone — the fastest way to it depends on what you’re building.
Fintech & wealthtech product teams
Planning features on the roadmap, no appetite to build and re-verify an engine every tax year.
start with the API →AI & agent platforms
Copilots that discuss money can't be trusted to improvise it. Ground them in real computation.
start with MCP →Banks, insurers & advisory firms
Client-facing calculators on your site this quarter — one script tag, no engineering project.
start with embeds →Teams testing financial AI
Input-and-expected-output pairs two independent implementations agree on — the answer key your eval harness is missing.
start with the evals →Proof is a set of artifacts, not an adjective
Every claim on this page resolves to something you can open and check — that’s the point of the whole system. This table is the map.
| The claim | What enforces it | Check it yourself |
|---|---|---|
| ✓You know what it computes | Every model's contract is public: inputs, units, valid ranges, sentinels. Full specs — exact formulas, assumptions, exclusions — are published for the three sample models, and come with your key for the rest. Out-of-range inputs are rejected with errors — never silently adjusted. | GET /models/{model} |
| ✓The math is independently reimplemented | Concordance testing: a second implementation, built from the published spec alone, must agree with the production engine on 250 cases per model, re-checked on every change. Any disagreement stops the release. | how Concordance testing works |
| ✓The constants are sourced and dated | IRS limits, brackets, and SSA factors live in a registry with the primary source, the tax year, and the date a human last checked each value. Models that consume these constants cite them in the response. | GET /api/v1/facts |
| ✓It won't change under you | Model behavior changes only with a version bump and a public changelog entry. Responses pin their spec version, so you can hold us to it in your CI. | /models/changelog |
| ✓You can prove where a number came from | Every response includes a SHA-256 record over the model, version, inputs, and outputs. Store it with anything you build on the numbers; recompute it any time to prove they're unaltered. | verify a record (SDK) |
| ✓Even our traction is checkable | We ask you to trust our numbers, so ours are public: aggregate API usage, updated daily, no vanity math. | GET /api/v1/telemetry |
The questions a careful buyer asks
What does it cost?
Three models are free to call — no signup, no key, no card — with a visible “Powered by Worthune” where end users see results. The full catalog is $199 a month, and it drops the attribution. Both plans are on the pricing page, in full.
What's the catch on “no API keys”?
The three free models answer without one, so nothing sits between a developer and a first call. Abuse is handled by a rate backstop (120 requests/minute per IP) that a real integration never touches. Pro accounts do get a key — that key is what opens the rest of the catalog.
How locked in are we?
You’re not. It’s plain JSON over HTTPS, the response schema is documented, the specs are published, and behavior is pinned by version. If you ever leave, the spec of everything you were computing goes with you — that’s what published contracts mean.
What happens when tax law changes?
We update the registry from the primary source, bump the affected model specs, note it in the changelog, and your integration keeps working — now with current numbers. That maintenance is the product as much as the math is.
Your first computation is five minutes away — receipts included
Paste this into a terminal. No account, no key, no sales call — the fastest way to evaluate us is to use us.
Open the docs →$ curl -s -X POST https://worthune.com/api/v1/models/fire \
-H 'content-type: application/json' \
-d '{"currentAge":34,"currentSavings":120000,
"annualIncome":110000,"annualExpenses":52000,
"savingsRate":0.35,"expectedReturn":0.07,
"withdrawalRate":0.04}'Want to see the models at work before you write any code? Every calculator is a live demo — retirement, rent vs. buy, refinance, and more. Try the model demos →