For a decade, compliance in crypto-asset settlement meant screening after the fact. A transfer was routed, a vendor flagged it, an analyst reviewed the flag, and an audit log recorded that all of this happened. Supervisors accepted it because there was nothing better. That has ended. MiCA is in force, FATF Travel Rule expectations are explicit, OFAC enforcement is active, and examiners in several jurisdictions now ask the inverse question: show me that the sanctions and jurisdiction checks were preconditions on the routing decision, and let me reconstruct the exact policy state, sanctions feed and decision path that existed at the moment it committed.
An audit log cannot answer that. A log is a summary the system wrote about itself. What the examiner wants is replay: the same inputs, the same policy version, the same feed digest, the same decision, and a digest that matches. This article is for compliance officers and heads of crypto-asset operations at regulated exchanges, custodians and payment operators, and for the examiners who review them. It describes what replayable compliance requires, and how Sovereign Clearinghouse, which 8Braid builds and operates on 8DB under our Digital Fabric brand, does it.
Policy as a precondition, not an alert
In Sovereign Clearinghouse a routing request does not proceed to a decision that is then screened. Sanctions, jurisdiction policy and the operator's rules of engagement are evaluated as preconditions, and a route that crosses a denied jurisdiction pair, touches a sanctioned entity or violates the operator's rules is not returned. When a request is under-specified, the service abstains rather than guessing. Every rejection carries a citable rationale tied to the active sanctions feed version, the jurisdiction policy version and the rule that fired. Compliance moves from an alert someone might act on to a gate the transfer had to pass.
Every decision is replayable
Each decision references the exact sanctions feed digest, the jurisdiction policy version and the signer set that were in force, and is appended to an audit chain. A supervisor who wants to know why a transfer cleared does not read a summary. They replay the decision against the recorded inputs and arrive at the same digest, byte for byte. This is what 8DB's provenance model is for: content-addressed inputs, a decision recorded with its governance state, and an integrity structure that authenticates the chain, so that "why" is a query with a verifiable answer rather than a narrative.
One record, every supervisor's lawful view
A custodian operating across jurisdictions may answer to several supervisors, each entitled to a different view of the same audit trail and none entitled to the personal data the others need. The usual solution is redacted copies, which drift. In Sovereign Clearinghouse each observer receives a view of the same underlying record with non-overlapping personal data redacted, and each view carries a proof that the redaction is faithful to the source. Because governance state is part of the record in 8DB rather than a filter in front of it, the views are projections of one chain rather than four documents that have to be kept consistent.
Erasure inside an immutable chain
The same substrate resolves the other paradox regulated operators face: GDPR Article 17 erasure against an append-only audit trail. Erasure is a structural operation that emits a certificate verifiable without the erased content,1 and the public verifier is live on the Sovereign Clearinghouse site. The boundary and the reasoning are set out in Erasure and Immutability Are Not Enemies.
Evidence notes
Sovereign Clearinghouse is in a structured pilot programme for MiCA-licensed providers, regulated custodians and sovereign operators: readiness review, controlled deployment in the operator's environment, shadow evaluation alongside existing screening, gate review and measured rollout. Its claims-and-evidence matrix separates what is available for pilot evaluation from what is in progress.2 We would rather an examiner read that matrix than a brochure.
What to bring us
- One transfer you had to explain. The reconstruction you produced for a supervisor and how long it took. We will show the same decision as a replay.
- Your supervisors' views. Which authorities you answer to and what each is entitled to see. That becomes the disclosure configuration.
- Your screening vendor's output. Run it alongside the clearinghouse in shadow mode and compare dispositions before anyone changes production.
Write to pilot@digital-fabric.com with the subject "Sovereign Clearinghouse pilot: replayable compliance". You will hear back from an engineer.
Sources and further reading
- Sovereign Clearinghouse
- Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA)
- FATF Recommendations, including Recommendation 16
- 8DB: Show Your Work: Provenance as a Query
Footnotes
-
Certificates are issued for records nothing later depends on; where a later record derives from the erased one, the engine tombstones with the dependency preserved rather than certifying a clean removal. ↩
-
Available for pilot evaluation: policy-bound routing, the replayable audit trail and the deployment package. Staged on the hardening roadmap: daily roll-up signing and post-quantum verification. SOC 2 Type II is in progress. ↩
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work