Fintra Trust feature
An audit trail you can prove wasn’t edited
Fintra Trust, Audit Trail
Example figures- INTEGRITY
- verified
- chain intact
- ENTRIES
- sequenced
- per-org seq
- REPRODUCIBLE
- yes
- replay to confirm
- Payment authorized: $84,200
- recorded
- Access to PII record
- recorded
- Agent tool-call denied (scope)
- recorded
- Chain verification
- intact
- Attempted silent edit
- detected
Why most audit logs don’t hold up
A plain audit log records what happened, but it proves nothing about whether the record itself was altered afterward. Anyone with database or admin access can change a row, and the log has no way to show it. An auditor assessing a control has to take the log on faith. Fintra’s audit trail closes that gap by hash-chaining every entry so tampering becomes detectable rather than invisible.
How the trail stays tamper-evident
- Each entry’s hash includes the previous entry’s hash, forming a chain
- A per-org monotonic sequence means gaps or reorders are visible
- Hashes cover the decision content, so any field change is detectable
- verify_chain recomputes the whole chain and reports whether it is intact
| Property | Plain log | Fintra audit trail |
|---|---|---|
| Records the action | Yes | Yes |
| Detects a silent edit | No | Yes: breaks the chain |
| Independently verifiable | No | Yes: recompute the chain |
| Reproducible entry hash | No | Yes: same input, same hash |
What the trail captures
Every governed action becomes an entry: who acted, what they did, to what resource, the verdict, the risk and trust score, and the linked evidence. Because the same decision always hashes to the same value, the entry is a golden vector: replay the action and the hash must match, or the record was changed.
Audit-ready by construction
What an auditor gets
- A complete, sequenced record of governed actions
- A verification endpoint to confirm the chain is intact
- Reproducible hashes they can independently recompute
- Evidence links from each entry to the control it supports
Questions people ask
Does SOC 2 require an audit trail?
SOC 2’s Common Criteria expect logging and monitoring of system activity: CC7 in particular covers detecting and responding to events, and evidence that access and changes are recorded. A tamper-evident audit trail is strong evidence for those controls because it shows not only that activity was logged but that the log itself is trustworthy.
What makes an audit trail tamper-evident?
Tamper-evident means any change to a recorded entry is detectable. Fintra achieves this by hash-chaining: each entry’s hash incorporates the previous entry’s hash, so altering one entry breaks every link after it. Recomputing the chain reveals the break.
Can an auditor verify the trail independently?
Yes. Because entry hashes are reproducible and the verification recomputes the chain from stored fields, an auditor can confirm integrity without trusting the application. The verify endpoint reports whether the chain is intact.
Is this an immutable log?
It is tamper-evident rather than strictly immutable: entries can physically be changed, but any change is detectable because it breaks the hash chain. That gives you the audit property that matters, you can prove whether the record was altered, without the cost of an append-only distributed ledger.
Keep reading
Guides
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
Prove your audit trail wasn’t edited
Give auditors a hash-chained record they can verify for themselves.