For wealthtech & fintech builders
Ship planning features without
building the calculation engine
Worthune gives fintech and wealthtech teams financial planning infrastructure to call instead of build: unified household management, whole-household planning with coordinated strategies, and tested calculator models, all over one API. Every model publishes the rules it follows, keeps its behavior fixed to a version you can pin, and returns the government figures it used with their sources.
Retirement projections, rent-vs-buy, equity comp, debt strategy: your roadmap needs them and your users expect them. Building each one correctly is slow work, and re-checking it every January is slower. Worthune is that engine, with a record attached to every answer. Start with one model this sprint, add whole-household planning next quarter, and manage client households under your brand after that, all on one integration. When a reviewer or your regression suite asks whether a number is right, there is an endpoint for that too.
Ship it asunified household management, planning software, or calculators & models. One API under all three.
Last reviewed
Rules your compliance team can read
Every model publishes what it computes: inputs, units, valid ranges, formulas, assumptions, and exclusions. Responses carry the version they ran on, and changes go through a public changelog. Nothing shifts under your feature.
QA you're not staffing
A second implementation, written from the published rules alone, has to reproduce every model exactly, across 250 cases each, re-run on every change. When we find a bug, the rules are corrected first and the fix ships as a new version. How every model is tested before release is written up at worthune.com/methodology.
Grade the engine you already built
Keep your engine and grade it against ours: post your inputs and your answers, and get a pass or fail per case at the tolerances our own CI runs. Agreement gives you a regression suite. Disagreement is a bug worth finding before a customer does.
Tax-year upkeep included
IRS limits, brackets, and SSA factors are sourced, dated, and cited in the response. When Washington moves a number we update it, version the change, and your integration carries on unchanged.
A diligence pack per model
Vendor review tends to stall on a request for documentation nobody has. Each model renders its own: published rules, test-case summary, changelog, constant sources, and a sample record, print-ready.
A record in every response
Store the record with whatever you build on the numbers. Years later you can recompute it and show they are unaltered, with no key needed and nothing of yours stored on our side.
“My client is in the 22% bracket. What does a $20,000 Roth conversion actually cost?” A single filer with $34,000 of Social Security and $62,000 of other income, on Medicare:
| federal tax on the conversion | $4,504.00 |
| IRMAA surcharge triggered | $1,148.40 |
| total cost of the conversion | $5,652.40 |
| trueMarginalRate | 28.26% |
| dollarsToNextIrmaaTier | $26,100 |
The 22% bracket was really 28.3%. The difference is a Medicare surcharge two years out, set by a threshold the client crossed by accident. Three rule sets interact here: Social Security taxation under §86, the CMS Medicare tiers, and for clients under 65 the ACA subsidy. Two of them use different definitions of the same word, MAGI. A spreadsheet cannot hold a model like this for long, so the rules were written down before the code. It stays planning-grade and federal, and the exclusions are published with the model, not discovered later.
One POST per computation
Stateless JSON, and the same inputs always return the same outputs. The three sample models answer without a key, and so does the household engine: POST a household to /api/v1/project and nothing is stored, so nothing needs an account. A paid key opens the rest of the catalog, including this one, and the stored households that unified household management is built on. If you want guarantees on both sides of the wire, pin the machine-readable contract in your CI.
// e.g. inside your planning feature
const res = await fetch(
"https://worthune.com/api/v1/models/roth-vs-traditional",
{ method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify(userInputs) },
);
const { ok, outputs, specVersion, facts } = await res.json();
// outputs.breakEvenTaxRate, outputs.yearlyGrowth[...]
// facts: IRS constants used, with sources — show them to usersQuestions
Common questions
- Should we build our own financial calculators or license them?
- Building one calculator takes a week. Keeping thirty of them right is the real job. IRS limits move every January, brackets shift, and a quiet error in a projection is the kind of bug users find before your tests do. Licensing makes sense when you want the math to be someone else's maintenance contract and your team's time to go into the product around it. Building makes sense when the math is your differentiator.
- How do I add accurate retirement projections to my app?
- Call the model over REST with JSON inputs that match its published contract, or connect the MCP server if an assistant is doing the asking. The response carries the outputs, the model version, the assumptions, the government figures used with their primary sources, and a record you can store. Three models answer with no signup or key, so you can try it before deciding.
- How do we regression-test a financial planning engine we already built?
- Download the eval datasets and run your engine against them. Each is a set of input and expected-output pairs at the same tolerances our own test harness holds. If your engine disagrees with a case, one of the two is wrong, and the model's published rules say which behavior was intended. Teams use this to catch January constant changes before their users do.
- What happens when tax constants change in January?
- Constants live in a registry with their primary source and the date each was last checked. A change ships as a version bump with a public changelog entry. You can pin a version so your outputs never move underneath you, and read the changelog to decide when to adopt the new one.
- Can we grow from calculators into full planning features?
- Yes, without re-integrating. The same API that runs single models also runs the household engine: one versioned record per client, a year-by-year projection, and a longevity-aware Monte Carlo. Coordination strategies cover withdrawal sequencing, Roth ladders, Social Security claiming, and pension elections, and each returns ranked alternatives with dollar deltas. Unified household management runs on the same record, kept current from the feeds you already use and monitored for drift, with white-label delivery on the Growth tier. Every paid plan includes the household engine, with an active-household allowance per tier.
- Can we see how a number was calculated after the fact?
- Every response includes a record covering the model, its version, the inputs, and the outputs. Store it with the result. Months later you can recompute it and show that the number came from that model, at that version, on those inputs. That is usually the question a reviewer is actually asking.
Talk to us