Security Architecture Overview: How Rexfin Protects Your Financial Data

Security pages tend to be a list of adjectives: “enterprise-grade,” “bank-level.” That’s not useful to a finance team deciding whether to route real filings through a tool. What’s useful is the actual architecture: what’s encrypted, who can see what, what happens when someone gets it wrong, and what proof exists afterward. This is that, at the level a security reviewer would actually ask about.

Encryption and isolation, stated plainly

Data is encrypted in transit with TLS and at rest with AES-256. Credentials for any connected system live in an isolated secrets store, not application config. Each organization’s data and model are logically isolated from every other organization’s, and nothing about your data is used to train shared or third-party models: your filings and your model stay inside your organization’s boundary, not folded into a general-purpose training set anywhere.

Access control that fails shut, not open

The design principle underneath permissions is simple to state and easy to get wrong in practice: every read of a document, a figure, or a source citation passes through one access decision, and that decision defaults to denying access rather than granting it. If a user hasn’t been explicitly given access to something, the answer is no, not “not shown in the UI but still reachable underneath.” An explicit deny always beats an explicit allow, so access granted through one path, like group membership, can still be blocked by a more specific rule naming that person directly.

This matters because of a failure mode that’s easy to miss: a document can be hidden in the interface while an AI assistant still has it in working context and can reason over or cite it. Hiding something from a screen while leaving it reachable underneath is a leak with a friendly face. Rexfin enforces access control at the same layer that decides what an AI assistant can retrieve from and cite: if a person can’t open a document, the assistant answering their question can’t see it either.

Roles layer on top of that base decision: who can only view figures, who can edit a model within sections they have access to, and who can manage access and export on the organization’s behalf. None override the underlying access check: a person with broad editing rights still can’t touch or export a section they were never granted access to.

Every connection to the data layer is authenticated and scoped

Internally, the service holding extracted figures and running verification is never reachable directly: every request carries a specific, scoped credential and travels only over a private network, never the public internet. A request without a valid credential is rejected outright; there’s no fallback to an open, unauthenticated read. And if a deployment somehow started up with a placeholder credential still in place, the application refuses to start at all, rather than running with safety controls that exist on paper but aren’t switched on.

An audit trail that can prove it wasn’t tampered with

Logging “who did what” is table stakes; the harder problem is proving that log hasn’t been quietly edited afterward. Rexfin’s access and action log is hash-chained: every entry incorporates a cryptographic hash of the entry before it, so altering, deleting, or inserting a record breaks the chain at that exact point, and a verification check can walk the whole chain and report precisely where the break happened. That turns “we keep logs” into something checkable: integrity you can verify, not a promise to take on faith. See how this discipline extends to every generated answer in the answer audit log. Denied access attempts are logged too, not just successful actions, so probing for something you shouldn’t reach is itself visible in the trail.

Where this connects to the rest of the platform

Security architecture isn’t bolted onto the product: it’s the same fail-closed instinct that shows up in how verification works, where an unresolved check is reported honestly instead of guessed at, and in how ingestion works, where an unclassifiable filing gets quarantined instead of force-processed. Refuse rather than assume runs through access control, verification, and ingestion alike, because a platform built on defensible numbers has to apply that standard to who can see them, not only whether they’re correct.

On certification: our information security program is designed against ISO/IEC 27001-style controls (the standard GCC and government-adjacent buyers actually ask for), and we say plainly that formal third-party certification hasn’t started, rather than imply an audit is already underway. See the trust center for the full, current state of that program. If your GCC data-residency requirements are specific, data residency options covers what’s available today.

Who this is for

Anyone whose procurement review asks harder questions than a marketing page answers: a controller who needs a permission change to be reconstructable after the fact, a CFO who needs to know an AI assistant can’t see what its user can’t see, an IT lead who wants to know what happens on a bad deploy. Book a demo and we’ll go through data handling, access controls, and deployment in the detail your review needs, or read the broader picture at the pillar overview.