Compliance Monitoring

Enable institutions to screen private transactions for regulatory compliance (AML, sanctions, fraud) without exposing transaction details to unauthorized parties. Balance privacy preservation with auditability through selective screening approaches and tiered disclosure, so settlement can proceed under compliance controls while counterparty identities and amounts remain shielded from public view.

This is an orchestration pattern that composes primitives (viewing keys, zero-knowledge proofs, threshold KMS, attestations) into a compliance workflow. The unique contribution is the rule engine, alert pipeline, and audit trail that hold the workflow together; the underlying disclosure primitives are linked via related_patterns.

• Compliance oracle or screening service evaluates transactions against sanctions lists, AML rules, and internal policies. Can be centralized, federated, or threshold-operated.
• Rule engine stores jurisdiction-specific rules with versioning. Rule updates are logged and auditable.
• Threshold key management issues and rotates viewing keys distributed to authorized parties, so no single operator can unilaterally decrypt transaction contents.
• zero-knowledge proof verifiers (optional) validate compliance attestations such as "amount below reporting threshold" or "counterparty not on sanctions list" without revealing the underlying values.
• Alert and case management system handles flagged transactions through severity tiers with defined response times.
• Audit log records every screening decision with timestamp, rule version, and decision hash. Typically anchored on-chain via attestations for tamper evidence.

Guarantees:

• Transaction details are visible only to the compliance function and authorized parties.
• All transactions are screened against current sanctions lists and jurisdiction rules before settlement.
• Screening decisions produce an immutable, timestamped audit trail suitable for regulator review.
• Counterparty identities are protected from public view; disclosure is scoped to authorized auditors via viewing keys.

Threat model:

• Soundness of any zero-knowledge proofs used for screening attestations.
• Non-colluding oracle operators. A single compromised or coerced operator in a centralized deployment can leak transaction metadata or unilaterally block transactions.
• Rule engine integrity. A tampered rule set can allow prohibited transactions or block legitimate ones.
• Key management for viewing keys. Compromised keys enable unauthorized decryption of historical transactions.
• Network-layer metadata (IP, timing, submission patterns) is out of scope and must be covered separately.

• Real-time screening adds 100 to 500 ms per transaction. Batch screening for low-risk flows mitigates this.
• False positives from overly strict rules block legitimate transactions. Tiered thresholds and human review for edge cases are standard mitigations.
• Oracle trust is a concentration point. Threshold operation with multiple providers or TEE-based screening reduces this risk.
• Per-transaction screening fees can be significant at volume; internal screening for high-frequency flows is common.
• Centralized oracles retain unilateral censorship power even when privacy is otherwise strong; threshold governance and transparent appeals are necessary counterweights.

• An institution initiates a large bond purchase on a privacy L2.
• The sender's compliance node pre-screens the counterparty against the sanctions list (clear).
• The transaction is submitted with an encrypted amount and a zero-knowledge proof that the amount is within the reporting threshold.
• The oracle verifies the proof, checks the counterparty risk score (medium), and clears the transaction.
• Settlement executes. The audit log records timestamp, screening version, result, and proof hash.
• A monthly report aggregates cleared transactions for the regulatory filing.