Fintra Platform
Evidence that’s sealed at the moment you decide
Decide-and-Seal Evidence
Example figures- CONTROLS MAPPED
- SOC 2 · ISO
- canonical
- CHAIN
- verify_chain() ✓
- recomputable
- BACKFILL NEEDED
- none
- emitted at decision
- Access grant · prod DB, then CC6.1, CC6.3
- evidence sealed
- Pay run approval, then CC7.2, change mgmt
- evidence sealed
- Vendor bank change, then CC6.7, review
- evidence sealed
- Each artifact hash-chained to prior
- tamper-evident
- Auditor re-runs verify_chain()
- independently checkable
Decide-and-seal, not screenshot-and-hope
The weakness of after-the-fact evidence is that it’s a snapshot of a control at one moment, disconnected from the actual decisions the control is supposed to govern. Fintra emits the evidence at the point of the decision itself. When a governed action is approved, challenged, or blocked, the platform writes an evidence artifact (the actor, the verdict, the factors) and maps it to the canonical controls it satisfies.
| Governed action | Auto-mapped controls |
|---|---|
| Production access grant | SOC 2 CC6.1 / CC6.3 (logical access) |
| Vendor bank-detail change + payment hold | SOC 2 CC6.7 (data in transit / change review) |
| Pay-run approval by named human | SOC 2 CC7.2 (change management, segregation) |
| Blocked off-hours admin action | ISO 27001 A.9 / A.12 (access, operations security) |
Why “recomputable” matters
Evidence you can’t re-derive is evidence you have to trust. Because every artifact is hash-chained, an auditor doesn’t have to take the export at face value: they can run verify_chain() and confirm the record hasn’t been altered since it was sealed. And because scoring is deterministic, the verdict on any given action can be re-computed from the same inputs and will match.
- Every evidence artifact carries a sha256 seal chained to the prior artifact
- verify_chain() lets an auditor independently confirm nothing was edited after sealing
- Deterministic scoring means a verdict re-computes to the same result and factor list
- Controls mapping is to canonical frameworks (SOC 2 CC-series, ISO 27001 Annex A)
What enforcement actually does
Questions people ask
What does “decide-and-seal” mean?
The moment a governed action is decided (approved, challenged, or blocked) the platform emits an evidence artifact (actor, verdict, factors), maps it to the canonical SOC 2 / ISO controls it satisfies, and seals it into a hash-chained ledger. The evidence is created at the decision, not reconstructed later.
How is this different from Vanta or Drata?
Those tools collect and monitor evidence about systems: often via screenshots, integrations, and periodic checks. Fintra seals the decision itself: proof of what a control actually decided, when, and by whom. As we put it, Vanta collects screenshots; Fintra Trust seals the decision. They’re complementary, not identical.
What makes the evidence “recomputable”?
Each artifact is hash-chained with a sha256 seal, so an auditor can run verify_chain() to confirm nothing was altered after sealing. And because scoring is deterministic, any verdict re-computes from the same inputs to the same result and factor list: you can re-derive it, not just trust it.
Which controls does it map to?
Governed actions map to canonical frameworks: the SOC 2 CC-series (e.g., CC6 logical access, CC7 change management) and ISO 27001 Annex A (e.g., A.9 access, A.12 operations). Coverage is the set of actions Fintra governs, mapped to the controls they satisfy.
Does this replace a SOC 2 audit?
No. It produces recomputable, control-mapped evidence for the actions Fintra governs and can gate them, but it’s not a substitute for an audit, and it covers the actions the platform sees, not your entire environment. Live actuation happens only at the opt-in MCP boundary.
Keep reading
Guides
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
Seal the decision, not a screenshot
See a governed action emit control-mapped evidence and hash-chain it, then verify the chain yourself.