What Rexfin Keeps, What It Purges, and How Deletion Actually Works

“How long do you keep our data, and can you actually delete it when we leave?” is one of the first questions a security review asks, and it is a fair one. Most vendors answer with a policy document. Rexfin answers with a mechanism, because the honest version of “we delete it” has to survive contact with a system that also keeps a tamper-evident audit trail of every verified number it ever produced.

Not everything in the platform is the same kind of data

The first thing Rexfin does is stop treating all stored material as one blob. Every document, extracted figure, cached answer, and audit record carries a sensitivity classification, inherited from the deal it belongs to and refined per artifact where needed. That classification isn’t decorative: it gates which processing locations and which model providers are even eligible to touch the data, a link described in more detail in how Rexfin governs which LLM providers can see your data. An artifact with no resolvable classification defaults to the most restrictive tier, never the loosest, and downgrading a classification requires an explicit, audited action: you cannot quietly relabel something as less sensitive.

Classification also splits the data into two lifecycles that matter for retention: durable actuals (the extracted figures and source pages that are the evidence behind every number) and transient derived artifacts (cached answers, what-if scratch, retrieval indexes). The first category is what the product’s value rests on. The second is recomputable, and keeping it indefinitely is a liability with no upside.

Retention windows, and a legal-hold override

Transient artifacts get a retention window, set per artifact type and per classification: a restricted-tier cached answer can expire faster than a lower-sensitivity one. A scheduled job purges what has aged past its window, and it does this without touching the durable atoms it was derived from: if a cached answer disappears, Rexfin just recomputes it next time someone asks, rather than erroring. That’s the trade this design makes deliberately: you can minimize the sensitive footprint aggressively precisely because the underlying atoms and the verifier can always reproduce whatever gets purged.

A deal under legal hold is exempt from this entirely. Placing a hold is an audited, deliberate action, and once set, nothing in that deal is purged or deleted regardless of age, until the hold is released. This is the safety valve that keeps automated data minimization from destroying evidence a dispute or a regulator has frozen.

Deleting a deal, and proving you did it

When a customer offboards, or a data subject exercises a right to erasure, Rexfin runs a scoped deletion: every row and file keyed to that deal (documents, extracted atoms, model cells, exports, cached answers) is removed, and nothing belonging to a different deal is touched. The output is a signed manifest naming what was purged, by whom, under what basis: something a customer’s data protection officer can keep as evidence the deletion actually happened, rather than a support ticket that says “handled.”

The part that’s actually hard: deleting from an append-only ledger

Here’s the tension worth being honest about. Rexfin’s answer audit log is deliberately append-only and tamper-evident: that’s what makes a verified answer independently checkable months later. But an append-only ledger and a right-to-deletion request pull in opposite directions: you cannot both keep every verdict forever and honor an erasure request.

The resolution is crypto-erasure. Each audit record’s payload is encrypted under its own key. To delete it, Rexfin destroys that key (the ciphertext becomes permanently unreadable) while the record’s hash stays in the tamper-evident chain. The published root still verifies, and the absence of that record’s content is provable rather than a silent gap that would look like tampering. Deletion doesn’t rewrite history; it makes a specific payload permanently unrecoverable while leaving the proof that something existed there and was lawfully erased.

What this doesn’t claim

Rexfin isn’t claiming a certification here: the honest framing is that these controls are designed to meet the storage-limitation and erasure expectations that show up in GCC data protection frameworks and in enterprise offboarding clauses generally. Retention windows are config, not a promise in a slide deck, and the scoping is deliberately narrow: a purge only ever touches one tenant’s data, checked by tests that seed two deals and confirm deleting one leaves the other untouched byte for byte.

If you want to see how this fits into the platform’s broader approach to keeping the system itself defensible after an outage or a bad restore, that’s covered in reliability and disaster recovery. For the full picture of how Rexfin is built, start at the Inside the Rexfin platform hub.