Verit Global logo
Verit Global

Deterministic Settlement: Mathematical certainty for money movement

Every settlement is bit-for-bit reproducible and cryptographically verifiable. Funds move only when the math and the evidence agree.

Quick DemoTalk to an Engineer
Deterministic settlement architecture

The invariant (gate before money moves)

Two conditions, or no disbursement

  1. replay_digest == transcript_digest — mathematical proof the computation is correct.
  2. acceptance_bundle.validate(freshness, quorum) — cryptographic proof of approvals (ACK/CT/SPV).

If either fails, the decision is HOLD with a reason code.

Acceptance matrix (pseudo)

const ok =
  (replayDigest === transcriptDigest) &&
  requiredDomains.every(d => verify(proofs[d]) && fresh(proofs[d], F) && quorum(proofs[d], Q));
return ok ? 'ALLOW' : ['HOLD', reasonCode];

Interfaces: 8 ways to integrate

One-call Authorization Gate
1
Best default: minimal change
PSP plugin + SPV receipts
2
Airtight reconciliation
Batch flat-file (Tier-0)
3
Fastest start
Event streaming (Kafka/Pub/Sub)
4
For tight SLAs/scale
ERP-native adaptor
5
Finance-led control
SDK-first (Stripe-style)
6
Great DX for dev teams
Ops copilot (agent)
7
Support layer
On-/cross-chain SPV
8
Only if you touch on-chain

Decision tree

Need value in weeks?          → 1 + 2 (add 6 later)
Tight SLA or heavy scale?     → 1 + 4 (+2/6)
Finance-led & ERP-centric?     → 5 + 1 (+2/6)
Product/dev-led?               → 6 + 1 (+2)
Crypto/on-ledger touchpoints?  → add 8 to acceptance

Anti-patterns to avoid

  • Becoming payer of record (replace rails)
  • Per-payment synchronous gating (gate per window)
  • Re-implementing compute in ERP
  • Skipping evidence (no ACK/CT/SPV)
  • Non-determinism: FP math, wall-clock reads, unordered iteration

Architecture: 12 core + 4 context

[C1] Policy Compiler & Manifest

Compile declarative policy → IR; fix window cadence, shard function, rounding scale S, acceptance F/Q; sign & version.

Gets → Sends

Gets: Governance (C9), Security (C2) → Sends: params to C4/C5/C7

Data (authoritative)

Git + Manifest table (OLTP); artifacts in object store

[C2] Security & Keys

mTLS everywhere; sign transcript roots & manifests; rotate keys; audit usage.

Gets → Sends

Gets: Governance (C9) → Sends: signatures to C6 & C1

Data (authoritative)

KMS/HSM; key metadata (OLTP)

[C3] Ingestion & Normalizer

Validate schema; idempotency; assign partition_id; canonical timestamps.

Gets → Sends

Gets: External (CTX-1), mappings (C12) → Sends: canonical events to C4

Data (authoritative)

Object store (raw/normalized), Topics; Idempotency index (OLTP)

[C4] Partitioned Logs & Window Manager

Single-writer per partition; lexicographic fold; monotone watermark to close window.

Gets → Sends

Gets: C3, rules (C1) → Sends: close + ordered stream to C5

Data (authoritative)

Compacted topics (open), Window state (OLTP), Archived logs

[C5] Deterministic Execution Engine

i128 accumulation; late quantization; deterministic carry; no FP/wall‑clock/unordered iteration.

Gets → Sends

Gets: C4, C1 → Sends: allocation records to C6

Data (authoritative)

Worker KV + checkpoints (object store)

[C6] Transcripts & Digests (tiered)

Content‑addressed segments (inputs/checkpoints/outputs); output_digest; signed transcript_root.

Gets → Sends

Gets: C5, signatures (C2) → Sends: root/digest to C7/C8/CTX-2/C11

Data (authoritative)

Object store tree + Transcript index (OLTP)

[C7] Verifiers (+ Acceptance Matrix)

Intake ACK/CT/SPV proofs; enforce freshness F & quorum Q; reason-coded outcomes; bind to digest.

Gets → Sends

Gets: C6, proofs (CTX‑1/3) → Sends: acceptance to CTX‑2; snapshot to C10

Data (authoritative)

Acceptance (OLTP); proof artifacts (object store); cache

[C8] Replay & Equivalence

Reproduce solely from transcripts; block on mismatch; store diffs for audit.

Gets → Sends

Gets: C6 → Sends: equality to CTX‑2/C9/C10

Data (authoritative)

Replay job log (OLTP); replay logs (object store)

[C9] Governance & Safe‑Change

Deterministic canary → N clean windows → promotion; rollback; dual‑write for re‑shard.

Gets → Sends

Gets: C7/C8 → Sends: activation to C1; rules to C4/C6; notif to C10

Data (authoritative)

Append‑only governance ledger (OLTP); snapshots

[C10] Observability & KPIs

Metrics, logs, traces; KPIs: time‑to‑release, replay‑equality, proof freshness, watermark lag.

Gets → Sends

Gets: C4–C8, CTX‑3 → Sends: alerts; feeds C9

Data (authoritative)

Prometheus/ELK/Jaeger; Warehouse

[C11] Reconciliation & Provider Adapters

Normalize provider reports; map provider_batch_id ↔ window_id/output_digest; feed SPV.

Gets → Sends

Gets: CTX‑3 → Sends: SPV to C7; GL maps to C12; metrics to C10

Data (authoritative)

Raw drop‑zone (object); normalized receipts (OLTP)

[C12] Connector Layer (ERP/GL/PSP)

Stamp window_id/output_digest/transcript_url/provider_batch_id; filter ALLOW for pay‑runs.

Gets → Sends

Gets: CTX‑2 decisions, C11 recon → Sends: ERP/GL/PSP in CTX‑1; echoes to C3

Data (authoritative)

Connector state (OLTP); payload archives

Context boxes (4)

  • [CTX-1] External Systems — files/streams, ERP/GL, PSP/bank, KYC/Tax
  • [CTX-2] Authorization Gate — returns ALLOW/HOLD with reasons
  • [CTX-3] Disbursement via PSP/Bank — tagged with window_id/output_digest
  • [CTX-4] Acceptance Matrix — ops view derived from verifiers

ASCII snapshot

[CTX-1] → [C3] → [C4] → [C5] → [C6]
       ↘ [C12]           ↘ [C8]
          [C7] → [CTX-2] → [CTX-3]
                   ↘ [C11] → [C10]
[C1] affects C4/C5/C7; [C2] signs C1/C6; [C9] governs rollout

Data contracts & repositories

Cross-cutting IDs

window_id · tenant_id · partition_id · policy_version · output_digest · provider_batch_id · transcript_root

Authoritative stores

  • Object store — transcripts (C6), receipts (C11), immutable/WORM
  • Postgres HA — manifests (C1), acceptance (C7), governance (C9), auth/recon logs
  • Kafka/PubSub — open-window logs (C4) + ingest (C3)
  • KMS/HSM — signing keys (C2)
  • Observability stack — metrics, logs, traces; warehouse for BI

Key contracts (TS sketch)

interface EventRecord { tenant_id: string; window_id: string; event_id: string; ts_logical: number; bucket_id: number; principal_id: string; amount_minor: string; payload_digest: string; provider_id: string; }
interface AllocationRecord { window_id: string; policy_version: number; principal_id: string; bucket_id: number; amount_native: string; carry_delta: number; }
interface AcceptanceRecord { window_id: string; kind: 'ACK'|'CT'|'SPV'; subject_id: string; status: 'VALID'|'EXPIRED'|'INVALID'; quorum: number; expires_at: string; reason_code?: string; signature: string; }

Reason codes (starter)

DIGEST_MISMATCH · STALE_PROOF · INSUFFICIENT_QUORUM · MISSING_ACK · MISSING_CT · MISSING_SPV · PROVIDER_TOTALS_MISMATCH · WATERMARK_STALL · POLICY_VERSION_CONFLICT

Run & scale (Kubernetes reference)

K8s layout

  • Namespaces per env (dev/stage/prod)
  • HPA on C3/C4/C5/C7; NetworkPolicies + mTLS
  • Secrets via KMS; short‑lived tokens

Scale units & autoscaling

  • Partitions/window (target 2–5M events/partition)
  • One engine worker per (partition, window)
  • Autoscale: queue depth • watermark lag • proof backlog

Multi‑region & SLOs

  • Phase 1: single region multi‑AZ → Phase 3: active‑active
  • Window close p95 ≤ 15m; transcript seal ≤ 10m
  • Replay equality: 100% on canary; any mismatch pages

Security & compliance

Crypto & keys

  • ed25519 signatures on manifests & transcript roots
  • KMS/HSM key rotation & audit
  • Signed gate responses; mTLS everywhere

Data handling

  • No PII in transcripts; CT/KYC in separate encrypted bucket
  • Object Lock / WORM; cross‑region replication
  • RBAC + RLS; per‑tenant isolation

Compliance posture

  • SOC2/ISO roadmap; PCI alignment
  • GDPR/CCPA ready; data residency options
  • Immutable audit (transcripts + acceptance)

Docs & API (core surface)

Endpoints

POST /ingest/events
POST /window/{id}/authorize
GET  /audit/transcript/{window}
GET  /audit/output-digest/{window}
POST /acceptance/proof
GET  /acceptance/{window}
POST /replay/{window}
POST /policy/propose|activate|rollback

Example: authorize window

{
  "window_id": "W-2025-09-12-1",
  "output_digest": "hex...",
  "decisions": [
    {"principal_id": "P123", "decision": "ALLOW"},
    {"principal_id": "P124", "decision": "HOLD", "reason_code": "STALE_PROOF"}
  ]
}

Implementation roadmap

0
Foundation
1
MVP
2
Pilot
3
GA
4
Scale

Phase 0 — Foundation (Week 0)

Platform

  • Bootstrap repos, envs (dev/stage/prod), CI/CD
  • Secrets via KMS/HSM; mTLS between services
  • Core schemas: EventRecord, AllocationRecord

Compliance & Data

  • WORM bucket for transcripts; cross‑region replication
  • Data classification (no PII in transcripts)
  • RBAC/RLS baseline, audit logging on write paths
Repos readySchemas v1KMS wired

Phase 1 — MVP (Weeks 1–4)

Pipeline (C3→C6)

  • Ingest/normalize with idempotency (C3)
  • Partitioned windowing + watermark close (C4)
  • Deterministic engine: i128, carry ledger (C5)
  • Transcripts + output digest (C6)

Acceptance & Gate

  • ACK/CT verifiers with freshness & quorum (C7)
  • Authorization Gate returning ALLOW/HOLD (CTX‑2)

Interfaces

  • #1 Authorization Gate API
  • #2 Batch flat‑file drop (CSV/Parquet)
  • PSP plugin stub for SPV receipts
Determinism tests passTranscript URLGate reasons

Phase 2 — Pilot (Weeks 5–8)

Replay & Recon

  • Replay equality checks with diffs (C8)
  • Provider adapters; map provider_batch_id↔window_id (C11)
  • SPV loop wired to verifiers (C7)

Observability & SLOs

  • Dashboards: watermark lag, proof freshness, TTR (C10)
  • Alerts: DIGEST_MISMATCH, STALE_PROOF, WATERMARK_STALL

Governance

  • Deterministic canary cohorts (C9)
  • N‑window promotion criteria + rollback path
Pilot tenant liveSPV receiptsSLO alerts

Phase 3 — GA (Weeks 9–12)

Interfaces @ scale

  • #4 Event streaming (Kafka/PubSub)
  • #5 ERP native adaptors
  • #6 SDKs (TS/Go/Java/Python)

Resilience

  • Multi‑AZ; active‑passive DR (RPO≤5m/RTO≤30m)
  • Backpressure & quotas; graceful window holds

Security & Compliance

  • Key rotations; audit exports
  • Policy change logs (append‑only)
Streaming liveDR testedSDKs shipped

Phase 4 — Scale & Hardening (Ongoing)

Throughput

  • Increase K partitions; shard rebalancing playbooks
  • Window close p95 ≤ 15m at target volume

Coverage

  • Additional verifiers (market‑specific)
  • Catalog of reason codes & automated remediations

Multi‑region

  • Active‑active via tenant pinning
  • Chaos drills + audit replay SLAs
≥120M events/dayReason‑code playbooksActive‑active