Verify a hash
Paste a SHA-256 hash to confirm it is sealed in RegAlign's tamper-evident evidence chain or append-only audit trail. No account, no email — the endpoint either verifies the hash or it doesn't. Illustrated with Jersey / JFSC throughout; the chain itself is regime-agnostic.
Pilot-ready for Jersey trust company businesses. Crown Dependencies and UK on the roadmap — same methodology and hash-chained record, source ingestors for JFSC, GFSC, IoM FSA and FCA already shipping.
How this works, and what we do and don't return
Every piece of evidence ingested into RegAlign is hashed with SHA-256 at the point of capture and the hash is sealed into a chained, append-only audit trail. The chain is engineered so any later edit would invalidate every subsequent entry.
If you hold a document that RegAlign claims to have sealed, you can compute its SHA-256 hash locally (on macOS: shasum -a 256 file.pdf) and paste the result above. A "Verified" response is independent proof that the document existed in RegAlign in exactly its current form at the sealed timestamp shown.
The endpoint never returns:
- tenant names, slugs or organisational identity
- the document filename, source reference or content
- who collected the evidence
- folder, access-control or metadata details
It returns only: whether the hash matched, the sealed-at timestamp (UTC), the kind of artefact, an opaque tenant tag (so multiple receipts from the same tenant can be correlated by an auditor without revealing identity), and an opaque verification reference.
Rate-limited to 20 verifications per IP per hour. Malformed input, unknown hashes and soft-deleted records all return the same plain "no match" response to prevent probing.
See the Trust Centre for the developer API, sub-processor list and the rest of the integrity stack. Auditors who need a named seat on a seeded tenant can request one at /auditor-access.