Which AI Models Touch Your Financials, and Under What Terms

“Which model sees our filings, and what stops it from training on them?” is a question every serious buyer eventually asks, and the honest answer is more interesting than “we use one trusted vendor.” Rexfin uses several models for several different jobs, deliberately, and the reason that’s safe rather than reckless comes down to two design decisions: no single model is ever trusted to be right about a number, and no model gets to see anything until its data terms have been checked.

The number doesn’t depend on which model wrote it

Rexfin’s trust chain runs on agreement between independent extraction passes, reconciliation to the printed total, and a deterministic identity check, never on any one model’s confidence. That’s what why calculation is deterministic, not generative is really about, and it’s the reason Rexfin can afford to be unsentimental about which model does which job.

High-volume, low-stakes tasks (pulling figures off a page, classifying a line item, rewriting a retrieval query) run on cheaper models, because the extraction-agreement check catches a wrong guess regardless of which model made it. The two roles that actually matter for what a customer reads, the verifier reasoning about an identity failure, and the writer producing the final cited answer, are reserved for stronger models. If the strong tier is unavailable, Rexfin fails closed and returns a clear error rather than quietly downgrading a trust-critical answer to a cheaper model. A wrong answer from a cheap model dressed up as a considered one is worse than no answer.

No provider gets in without vetted terms

Every provider goes through an admission gate before it’s routable at all. A provider’s data terms are recorded as a structured fact: does it retain prompts, does it train on them, what region does it process in, what’s the DPA reference. Only a provider recorded as zero-retention and no-training is admitted; anything else is flagged or rejected and simply cannot be selected, regardless of how good the model is. If a provider’s terms lapse or expire, it’s automatically demoted and stops receiving traffic: no code change required, no human needing to remember to flip a switch.

This is deliberately not a “we don’t use providers from country X” policy. A provider is admitted or rejected purely on the terms it can prove, which is what keeps the governance story honest rather than performative, and it means no single vendor ever becomes something Rexfin can’t route around if its terms change.

Nothing rests outside the region it’s supposed to

Data at rest (the extracted figures, the audit records, the cached answers) stays pinned to a single declared region. An external model provider may see a prompt in transit, but only under a zero-retention term, and the disclosure of which providers see what is generated from the live routing configuration rather than hand-maintained as a document that quietly drifts out of date. For customers with stricter requirements, trust-critical roles can be pointed at a self-hosted, in-region model instead, which is one of the paths covered in GCC data residency options.

The highest-volume data flow in the system, computing embeddings for retrieval, runs locally rather than through an external API at all, which means the single biggest stream of data never leaves the region and, offline, never touches a vendor.

What actually crosses the boundary

Before any prompt goes to an out-of-region provider, it passes through a second gate: a pass that identifies sensitive spans (names, account numbers, identifiers) and masks them with stable placeholders before the request leaves. The model reasons over the masked version; the placeholders are swapped back for the real values locally, after the response comes back, and that mapping never leaves the process and is never logged. If the masking step can’t run for some reason, the call is blocked rather than sent unredacted: the failure mode is always “refuse to send,” never “send it anyway and hope.”

What this doesn’t promise

None of this is a certification claim: Rexfin doesn’t assert SOC or ISO status here. What it asserts is narrower and checkable: routing decisions are config, provider admission is enforced in code rather than promised in a DPA, and the disclosure of who sees what is generated from what’s actually wired up, not authored separately from it. That combination is what turns “we vet our AI vendors” from a sentence in a security questionnaire into something a buyer can actually verify. For how this connects to the platform’s broader security architecture and to how Rexfin resists adversarial input in prompts, see prompt injection defenses. For the full map of how the platform is built, visit the Inside the Rexfin platform hub.