The Sovereign Clearinghouse evaluates every cross-jurisdiction crypto-asset transfer against sanctions, jurisdiction, and operator policy as cryptographic invariants — before the routing decision is signed and committed to an append-only audit chain. Built for MiCA-licensed CASPs, regulated custodians, and sovereign operators that must prove structural compliance to an examiner, not just describe it.
The MiCA 1 July 2026 deadline, FATF Travel Rule expectations, OFAC sanctions enforcement, and GDPR Article 17 erasure rights converge on a single requirement: show that policy was bound to the decision, with cryptographic evidence, every time. Today’s stack does not produce that evidence.
Chainalysis-class screening flags transfers post-hoc; the actual routing logic that committed the transfer never had sanctions or jurisdiction as a hard precondition. Examiners are now asking for the inverse.
A regulator who wants to verify why a transfer cleared cannot reconstruct the exact policy state, sanctions feed, and decision path that existed at the moment of commit. In-house audit-trail engineering eats $50K–$500K a year and still does not produce a deterministic replay.
CSSF, FCA, FinCEN, and MAS each have a different view of what they are entitled to see. Today this is solved by maintaining redacted copies of the same record. Cryptographic per-observer redaction does not exist in mainstream tooling.
Append-only logs that include personal data on tokenised flows leave operators with two choices: refuse the erasure request or break the audit chain. Both are non-starters for a regulated custodian.
NIST FIPS 203–205 are finalised; CNSA 2.0 mandates Level V parameters. Reserve attestations, transfer records, and audit certificates produced today must remain verifiable through that migration.
Governments, defence prime contractors, and central banks need a clearing primitive they can run in their own enclave, under their own keys, with a structural answer to “who decided what, under which policy, against which sanctions list?”
The Sovereign Clearinghouse is an operator-controlled service for regulated settlement environments.
Customer applications submit a routing decision request; the service evaluates it against the
operator’s active sanctions feed, jurisdiction policy, and operational rules-of-engagement,
returns a decision with a cryptographically-anchored decision_id,
and appends an immutable audit record. No multi-tenant SaaS posture. No uncontrolled data movement.
The decision engine cannot return a route that crosses a denied jurisdiction pair, touches a sanctioned entity, or violates the operator’s rules of engagement. The constraint is structural — not an after-the-fact alert.
Every decision references the exact sanctions feed digest, jurisdiction policy version, and signer set. A future examiner can replay the audit chain and arrive at the same digest, byte-for-byte.
CSSF, FCA, FinCEN, and MAS each receive a view of the same underlying audit trail with non-overlapping personal data redacted. Each view carries a proof that the redaction is faithful to the source — no duplicate, no divergence.
Cryptographic primitives are referenced by version, not hard-coded. Migrating from a classical signing posture to a post-quantum posture is a governance event, not a code rewrite, and the migration itself is part of the audit chain.
Adding a new sanctioned counterparty, expanding the active jurisdiction set, or promoting a new restriction is gated by a threshold signature from the operator’s signer roster. Single-operator key compromise cannot move the policy surface.
The deployment model is scoped with the operator’s security team. Policy inputs, evidence retention, and monitoring boundaries are documented before pilot start so data sovereignty and operational accountability are clear from day one.
The clearinghouse is a deterministic decision pipeline. A routing request enters one side; a signed decision and an append-only audit record exit the other. Every stage in between is governed by policy preconditions the operator can review.
Each policy layer can reject a route with a citable rationale tied to the active sanctions feed, jurisdiction policy, and operator rules. When a request is under-specified, the clearinghouse is designed to abstain rather than fabricate a route. Operator overrides become reviewable evidence instead of being buried in operational logs.
Sovereign Clearinghouse is powered by the TrustDB substrate, but the product promise is simple: a settlement decision cannot be separated from the policy, evidence, and approvals that made it valid. The technology is designed for regulated operators that need structural assurance, not another alerting layer.
Sanctions, jurisdiction, counterparty, and operator restrictions are represented as decision preconditions. If a route does not satisfy them, the clearinghouse abstains or denies rather than passing the risk downstream.
The TrustDB substrate models routes, restrictions, observers, and evidence as connected structures rather than flat log entries. That makes it possible to preserve how a decision was reached, even when rules and disclosure scopes change.
A decision carries references to the input, policy state, sanctions feed version, signer set, and outcome. An examiner should be able to reconstruct why a transfer cleared, failed, or required operator review.
Operators can prepare different evidence views for regulators, auditors, and internal teams without maintaining divergent copies of the underlying record. Redaction is treated as a governed view of the same evidence, not a separate document trail.
Custody and clearing records may need to remain verifiable long after today’s signing standards change. The clearinghouse treats cryptographic posture as a versioned governance concern, including a path toward post-quantum assurance.
The product is designed around operator-controlled deployment boundaries, evidence retention, key governance, and policy ownership. That is the difference between outsourcing screening and operating a clearing primitive under your own accountability model.
The product surface is organized around the people who need to trust it: operators who run the workflow, compliance officers who approve risk, auditors who need replayable evidence, regulators who need entitled disclosure, and administrators who control access.
Needs a work queue, clear outcomes, exception handling, integration health, and confidence that the system will abstain when evidence is incomplete.
Needs policy versioning, escalations, sign-off trails, evidence replay, and a record that maps every disposition to the rule that produced it.
Needs read-only evidence packs, exportable logs, retention status, and enough lineage to reconstruct why a transfer cleared, failed, or required review.
Needs entitled disclosure, redaction boundaries, policy rationale, and accountable operator contacts without unnecessary operational data exposure.
Needs organization setup, user roles, jurisdiction settings, pilot contacts, security posture, and deployment-boundary configuration.
Users enter through work email, SSO, or a controlled pilot invite. The account path declares organization, jurisdiction, and intended role.
Access is granted into a named operator boundary. No user sees clearing data until tenant membership and permission level are approved.
The organization confirms deployment boundary, evidence retention, compliance owners, policy sources, and promotion criteria before evaluation.
Each role lands in the console view that matches its job: operations, compliance, audit, disclosure, governance, integrations, readiness, or admin.
One screen for status, work queue, and evidence posture.
Scope, ownership, and acceptance criteria become explicit before the pilot starts.
Rules are versioned, reviewable, and connected to every decision they affect.
| Policy set | Version | Owner | Status |
|---|---|---|---|
| Sanctions and restricted party | 2026.06.18 | Compliance | Active |
| Jurisdiction routing | 2026.06.14 | Legal | Active |
| Counterparty exposure | Draft 4 | Risk | Review |
Every route has a disposition path: clear, deny, abstain, or escalate.
| Case | Route | Reason | Disposition |
|---|---|---|---|
| SC-18429 | CADC to USDC | Policy match | Clear |
| SC-18430 | BTC custody move | Counterparty review | Escalate |
| SC-18431 | Stablecoin redemption | Missing evidence | Abstain |
Auditability depends on reconstructing why a decision was valid when made.
Different recipients receive lawful views of the same record.
Outcome, policy basis, retained evidence, and accountable operator contacts.
Replayable case history, approvals, version lineage, and exportable evidence.
Operational context, queue notes, reviewer assignment, and remediation history.
Policy changes, signer changes, and promotion gates require named accountability.
Operators need connection health without exposing sensitive operational details.
Show route status, versioned schemas, and non-sensitive diagnostics. Keep keys, endpoints, and internal timings out of the public site.
Promotion is a governed business decision backed by evidence.
Administrators manage users, roles, contacts, and pilot materials for one operator boundary.
The programme gives operators, compliance teams, and examiners a clear evidence trail before any expansion decision. It begins with readiness review and controlled configuration, then progresses through shadow evaluation, gate review, and steady-state monitoring. Advancement depends on agreed compliance, security, performance, and operational criteria.
Readiness review
Confirm jurisdiction scope, policy owners, governance roles, data protection requirements, and pilot success criteria before any operational use begins.
Controlled deployment
Deploy into the operator’s controlled environment with documented configuration, access controls, audit-retention expectations, and support boundaries.
Shadow evaluation
Run alongside the existing workflow so the operator can compare policy-bound decisions against current screening and compliance procedures.
Gate review
Assess agreed evidence across policy enforcement, audit replayability, exception handling, performance, and operator override patterns.
Measured rollout
If gates are met, usage expands under a jointly approved operating plan. If not, the pilot remains in evaluation while the observed gap is resolved.
Operating review
Maintain recurring evidence packs for compliance, security, and executive stakeholders so the pilot produces a defensible expansion decision.
The clearinghouse is presented with evidence appropriate for diligence, not a black-box promise. The public matrix below separates available capabilities from certification work and pilot-scoped validation. Detailed runbooks, test outputs, and implementation artifacts are shared under pilot review.
| Claim | Status | Evidence | Posture |
|---|---|---|---|
| Pilot deployment package | Available for controlled operator environments | Containerized service, documented installation path, access-control model, and support boundaries are provided during pilot onboarding. | Available |
| Engineering test evidence | Available for diligence review | Relevant test outputs, release notes, and reproducibility guidance are shared with pilot teams during technical review. | Available |
| Policy-bound routing decisions | Available for pilot evaluation | Sanctions, jurisdiction, and operator policy constraints are evaluated before a decision is committed. | Available |
| Replayable audit trail | Available for pilot evaluation | Each decision can be tied to policy version, input digest, signer set, and outcome so an examiner can reconstruct why a decision cleared or failed. | Available |
| Post-quantum signing posture | Planned and staged | Daily roll-up signing and post-quantum verification are part of the hardening roadmap; current pilots receive a documented transition path. | In progress |
| SOC 2 Type II | In progress | Control mapping and evidence collection are underway; current pilot agreements should treat this as not yet certified. | In progress |
| FIPS 140-3 CMVP certification | Not yet certified | Certification is a forward-looking requirement. Pilot diligence can include a gap posture and planned certification pathway. | Gap posture |
| MiCA CASP regulatory sandbox enrolment | Operator- and jurisdiction-dependent | Pilot scoping includes jurisdiction review and regulator-facing evidence where appropriate. | Pilot-scoped |
| Empirical performance and decision-quality anchors | Pilot-measured | Performance, false-positive/negative behaviour, and override patterns are measured in the operator’s environment before expansion. | Pilot-measured |
| High-availability production posture | Roadmap / deployment-dependent | Pilot architecture is scoped to agreed availability needs; multi-region or active-active production posture is part of deployment planning. | Roadmap |
Your team receives a guided pilot package with deployment instructions, policy-feed interfaces, audit-retention guidance, and example client calls. Details that belong in a security review are shared during onboarding, not exposed as public website implementation instructions.
Run inside an operator-controlled environment or approved hosted reference path, with documented access control and support boundaries.
Agree how decision evidence is retained, exported, and reviewed against the operator’s regulatory obligations.
Ingest sanctions, jurisdiction, KYC, and operator policy feeds through governed interfaces that the operator can review.
Translate restricted origins, destinations, counterparties, and route pairs into policy rules before decisions are committed.
Applications submit a routing decision request and receive a deterministic outcome with an audit reference.
Decision evidence can be exported to the operator’s evidence store and reviewed as part of compliance, security, and operating workflows.
Pilot setup review
1. Confirm deployment boundary and accountable owners.
2. Review access controls, support channels, and evidence retention.
3. Run the operator-approved validation pack before evaluation begins.
Policy feed review
1. Identify sanctions, KYC, jurisdiction, and operator policy sources.
2. Confirm update cadence, approval roles, and exception handling.
3. Preserve feed version references for audit replay.
Decision flow summary
request → policy preconditions → sanctions review → jurisdiction review
→ operator rules → signed outcome → replayable audit reference
A typical MiCA-licensed CASP currently spends $180K–$750K a year on screening, in-house audit trail, and audit prep — and still cannot demonstrate structural enforcement. The Sovereign Clearinghouse replaces that stack at materially lower total cost of ownership with stronger evidence. The model below maps to lifecycle and certification milestones.
Founding operator cohort
$48K per year · 3-year lock + CPI escalation
Regional CASP · MSB · custodian
$60K per year · single region · single tenant
Multi-region · 24×7 SLA
$300K+ per year · multi-region · custom SLA
Defence · central bank · sovereign
On request air-gapped · data-resident · custom diligence path
Forward-looking notice: tier pricing reflects the current commercial draft and is intended to evolve as SOC 2 Type II, FIPS 140-3 CMVP, and jurisdiction-specific sandbox pathways mature. Founding-customer pricing is locked for three years against the current certification posture.
The clearinghouse is designed to halt, abstain, or stay in evaluation when agreed evidence fails. Operators see the criteria up front, with escalation and remediation paths documented in the pilot pack.
Decision-quality gate
If decision quality falls outside agreed tolerance, expansion is halted and the finding is reviewed with compliance and engineering owners before further use.
Trust-state gate
If the decision record, policy state, and observed operator workflow diverge, the pilot stays in evaluation until the source of divergence is understood.
Workflow integrity
Persistent operator overrides on the same decision class are treated as evidence that policy, workflow, or configuration needs review rather than a condition to ignore.
Sanctions integrity
If a sanctioned route clears without a rationale, the pilot is designed to stop, replay the decision evidence, and document the root cause before expansion continues.
Time-bounded support window
Pilot deployments are time-bounded with renewal, support, and review expectations agreed in advance so an evaluation cannot become an unmanaged production dependency.
Threshold governance
Material policy changes require multi-party approval under the operator’s governance model. Single-key compromise cannot quietly move the policy surface.
A 30-minute briefing covers the problem you need to solve, the pilot fit, diligence materials, security review path, and jurisdiction-specific deployment considerations. Detailed runbooks and implementation artifacts are shared under pilot review.