A Control Your Diligence Team Can Inspect: How We Separate Arithmetic from Assumptions

This is the third in a short series. The first piece described the self-checking AI loop we built; the second showed what that precision looks like in an advisor’s client meeting. This one is for the people who have to approve a vendor before any of that reaches a client: the risk, compliance, and diligence teams at a serious firm.

We built this to be inspected, not just trusted. Here is what there is to look at.

The question a diligence team actually asks

When a firm evaluates a tool that produces numbers clients make decisions on, the real question isn’t “does it have a nice interface.” It’s “what happens when it’s wrong, and how would we know?” A black box that emits confident figures with no way to verify them is a liability, no matter how good the demo looks.

So we designed the answer to that question into the product.

A clear line: arithmetic versus assumptions

The most important control is conceptual, and it governs everything else.

The outputs are pro forma projections. The future they model, income growth, inflation, a household’s choices over decades, is driven by assumptions the advisor sets, not predictions we make. What we hold exact is the arithmetic: given a set of assumptions, the federal repayment figures, IDR and RAP payments, plan comparisons, forgiveness amounts, are correct to the cent and current with the federal rules.

The advisor owns the assumptions. We own the arithmetic.

For a compliance team, that line is doing real work. It locates responsibility cleanly: the firm’s advisors are accountable for the assumptions they choose, and the vendor is accountable for the math being right under those assumptions. There’s no ambiguous middle where a bad outcome can’t be traced to a cause.

The control itself: an independent reference model

The arithmetic claim isn’t a promise; it’s a process you can examine.

We maintain a second, independent implementation of the federal repayment rulebook, RAP, the IDR formulas, PSLF, the forgiveness clocks, the filing-status logic, built separately from the production engine for one purpose: to disagree with it. Every federal calculation the engine produces is checked against this reference, to the cent. When the two agree, the result ships. When they don’t, it stops, and the discrepancy gets resolved before it can reach a client.

This is not a generic industry benchmark. It’s a private evaluation against the outcomes that actually matter, the federal figures an advisor puts in front of a household. And it improves with use: every disagreement resolved makes the check sharper and the encoded knowledge deeper. For a diligence review, the takeaway is concrete, there is a named, independent control whose entire job is catching errors in the math, and it runs on every calculation, not on a sample.

What doesn’t depend on a model release

One more thing risk teams reasonably worry about with any AI-driven vendor: model risk and durability. If the product is just a thin wrapper around whichever large model is best this quarter, what happens when that model changes underneath it?

Our domain knowledge, the encoded rulebook and the reference model, is our own IP. It does not live inside any single AI model we could lose or that could drift. The model underneath can be swapped; the encoded expertise and the independent check remain. The dependable part of the system is the part we own and can show you.

What we offer a firm

Finology Software is the dependable foundation for student-loan repayment planning at scale: federal math modeled precisely and kept current as the rules change, built on an architecture engineered for reliability from the ground up. It’s infrastructure your advisors can put in front of clients with full confidence, and that your firm can grow on.

We’d love to show you what it can do for your team. See the platform, explore our security and partnership posture, or start a conversation.