Architected for compliance from day one.

Why traditional database logs are not enough

A Postgres audit table with write-only permissions is not tamper-evident. A database administrator with root access can modify any row, and the audit trail cannot prove it. Access controls are procedural. Regulators increasingly require mathematical evidence that a record has not been altered since it was written. This is the distinction codified in FDA 21 CFR Part 11, SEC Rule 17a-4 (post-2022 amendments), EU AMLD6, and the EU AI Act's post-market monitoring obligations.

How FinQub's hash chain works

Every audit event in FinQub is individually hashed using SHA-256 and includes the hash of the preceding event. The chain looks like this:

event_0: { id, timestamp, workflow_id, action, payload, prev_hash: null, hash: H(event_0_body) }
event_1: { id, timestamp, workflow_id, action, payload, prev_hash: H(event_0), hash: H(event_1_body + H(event_0)) }
event_2: { id, timestamp, workflow_id, action, payload, prev_hash: H(event_1), hash: H(event_2_body + H(event_1)) }
...

If any historical event is modified, the recomputed hash will not match what was stored, and the chain breaks at that point. Every subsequent event also fails verification. An auditor runs a single verification pass over the chain to prove integrity.

Per-framework tagging for examiner-ready exports

FinQub tags every audit event with the regulatory frameworks it is evidence for. A single KYB decision can simultaneously satisfy evidence requirements for AMLD6, SOC 2 CC7, and a sponsor bank's BSA program. The export format is structured for the auditor:

• Filter by framework (AMLD6, BSA/AML, SOC 2 Type II, PCI DSS, DORA, CFPB 1033, GDPR)
• Filter by time window and optionally by workflow, vendor, or decision outcome
• Export as signed JSON or signed PDF, both carrying the chain-verification metadata
• Chain-verification CLI auditors can run offline against the exported file to confirm integrity

What you hand to a regulator during an exam

When an examiner arrives and asks for evidence on a specific decision, the workflow is: filter by the decision, export the signed bundle, hand it over. The bundle contains the full event chain, the policy configuration active at the time (hashed into the chain so swapping policies retroactively breaks signatures), every vendor response, every operator action, and the verification CLI. No manual reconstruction. No ShareFile folder. No screenshots.

How this differs from trading-focused audit products

Cryptographic audit systems exist today in algorithmic trading (VeritasChain Protocol, MiFID II RTS 25) and healthcare (FDA 21 CFR Part 11 implementations). FinQub applies the same cryptographic primitives to the fintech compliance stack: KYC, KYB, AML, payments, and vendor decisioning. The framework tagging, jurisdiction routing, and vendor-call capture are what make the chain usable by a fintech compliance officer rather than a quant or a GMP auditor.