Skip to content
Platform · Privacy

Policy-based access

Access review is one of the hardest recurring disciplines in banking, because entitlements accumulate faster than any team can re-examine them. Here, entitlements follow written policy: role, purpose, and sensitivity label decide who sees what. Grants carry an expiry and lapse on schedule, so standing access has to be re-earned rather than remembered.

What you get01 / 03
01

Entitlements are derived from policy against labels and purposes. They are derived, never set, so there is no separate access list to fall out of date.

02

Every grant is time-boxed and expires on schedule; renewal is a fresh decision with a named approver.

03

Exceptions go through one decision door under maker-checker, and each one is sealed on the ledger with its justification.

04

Recertification comes with context: reviewers see the policy, the purpose, and the lineage behind each entitlement, so every decision is made with the full picture.

05

The system fails closed: if a policy cannot be evaluated or an attribute is missing, access is denied rather than defaulted open.

06

The evidence pack for an access review assembles itself from the sealed ledger, covering every grant, expiry, exception, and denial.

How it works02 / 03
1

Write policy

Policies are expressed against labels and purposes rather than individual tables and schemas.

2

Derive

Entitlements are computed from policy plus the graph, so a label change reshapes access automatically.

3

Expire

Every grant carries a term; when it lapses, access ends unless someone decides otherwise.

4

Seal

Each grant, renewal, exception, and denial is sealed on the hash-chained ledger.

Questions it answers03 / 03

“Who can see customer account data right now, and under which policy?”

Entitlements are derived from written policy against labels and purposes, so the answer is computed from the graph in real time. For any dataset you can see exactly who holds access, the policy that grants it, and the purpose behind the grant.

“Why does this analyst still have access to a system they stopped using months ago?”

Under this model they would not. Every grant is time-boxed and lapses on schedule, so standing access ends unless a named approver makes a fresh renewal decision.

“Show me the approval trail for this exception.”

Every exception goes through one decision door under maker-checker and is sealed on the hash-chained ledger with its justification. The full trail, including the approver and the reasoning, is available on demand and flows into the self-assembling evidence pack.

The next step

Start with proof, not a promise.

There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.

01

A 60-minute working session

Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.

02

A two-week guided sandbox

Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.

03

A six-week proof on your systems

We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.