Rule-Snapshot and Screening-Time Provenance Governance

2. Summary

Rule-Snapshot and Screening-Time Provenance Governance requires that every compliance screening decision made by an AI agent — sanctions checks, counterparty risk assessments, jurisdictional rule evaluations — is accompanied by a cryptographically verifiable record of the exact rule set, list version, analytics provider response, and temporal context that applied at the moment of screening. In blockchain environments where transactions are irreversible and regulatory inquiries may arrive months or years after execution, the ability to reconstruct exactly what the agent knew, when it knew it, and what rules it applied is not an operational convenience — it is a legal necessity. Without screening-time provenance, an organisation cannot demonstrate to a regulator whether a transaction was properly screened, whether the screening data was current, or whether the screening logic was correctly configured at the time of execution.

3. Example

Scenario A — Regulatory Inquiry with No Provenance Trail: An AI agent executed 14,200 transactions over a 6-month period for a crypto-asset service provider. FinCEN issues an information request concerning 23 specific transactions involving addresses subsequently attributed to a sanctioned entity. The designation occurred 4 months after the transactions. The regulator asks: "For each of these 23 transactions, what sanctions list version was in effect at the time of screening, what screening provider was used, what was the screening result, and what hop depth was evaluated?" The organisation can produce transaction logs showing the transactions executed, but cannot reconstruct which sanctions list version was active at the time of each screening, which provider returned the result, or what screening parameters were in effect. The organisation's sanctions list has been updated 730 times since those transactions. The screening service does not retain historical query results.

What went wrong: The screening system recorded only the binary result (pass/fail) and the timestamp. It did not capture the list version, provider identity, provider response payload, screening parameters, or a cryptographic commitment binding the result to the specific rule set in effect. Consequence: The organisation cannot demonstrate compliance at the time of execution. The regulator treats the absence of provenance as a control failure. Civil money penalty of $2,400,000 assessed (approximately $104,000 per transaction for the 23 flagged transactions). The firm is required to engage an independent compliance monitor for 3 years at an estimated annual cost of $800,000.

Scenario B — Stale Rule Snapshot Causes Silent Screening Regression: An AI agent's screening configuration references a "current" rule set that includes jurisdiction-specific screening requirements. The UK adds new designations under the Russia (Sanctions) (EU Exit) Regulations 2019 on a Tuesday. The agent's rule engine pulls its configuration from a cached snapshot that was generated the previous Friday. For 72 hours, the agent screens transactions against a rule set that does not include the new designations. During this window, the agent processes 3 transactions totalling £420,000 involving newly designated addresses. Because the screening result is recorded as "clear" without the rule version, the discrepancy is not detected until the next quarterly compliance review.

What went wrong: The rule snapshot was stale, and the screening system did not record which rule version was applied. The "clear" screening result was correct at the time of screening relative to the stale rule set, but incorrect relative to the current legal obligations. Without rule version provenance, the organisation could not detect the gap in real time. Consequence: £420,000 in transactions with designated entities, OFSI investigation, potential strict-liability offence under UK sanctions law.

Scenario C — Analytics Provider Disagreement Without Resolution Audit Trail: An AI agent uses two blockchain analytics providers for cross-validation (as recommended by AG-193). Provider A returns "no match" for address 0x7a3f...b2c9. Provider B returns "indirect exposure — 15% of inbound value traces to sanctioned cluster within 3 hops." The agent's reconciliation logic is configured to apply the more conservative result, which would flag the transaction for review. However, a configuration error in the reconciliation logic causes Provider A's result to overwrite Provider B's result. The transaction proceeds. The screening log records "clear" without indicating which provider's result was applied or that a disagreement occurred.

What went wrong: The screening system did not record the individual provider responses, the reconciliation logic applied, or the fact that a disagreement occurred. The "clear" result in the log conceals a material screening failure. Consequence: Transaction proceeds to an address with significant indirect sanctions exposure, regulatory exposure equivalent to Scenario A, and the organisation cannot reconstruct the failure because the provenance data was not captured.

4. Requirement Statement

Scope: This dimension applies to all AI agents that perform any form of compliance screening — sanctions screening, counterparty risk assessment, jurisdictional rule evaluation, Travel Rule compliance, or any automated check that determines whether a transaction may proceed based on regulatory rules. The scope extends to the entire screening pipeline: the rule set or list used, the analytics provider queried, the query parameters, the raw response, the reconciliation logic (if multiple providers), and the final decision. Any system that makes a go/no-go decision on a transaction based on regulatory rules is within scope. Read-only agents that do not make screening decisions are excluded.

4.1. A conforming system MUST record, for every screening operation, a provenance record containing: (a) the transaction identifier; (b) the exact list version(s) and list timestamp(s) used; (c) the screening provider identity and API version; (d) the raw provider response payload; (e) the screening parameters applied (hop depth, risk threshold, jurisdiction filters); (f) the reconciliation logic version (if multiple providers); (g) the final screening decision; and (h) a cryptographic hash binding all of the above into a single verifiable commitment.

4.2. A conforming system MUST generate the provenance record at screening time — not retrospectively from logs — and MUST store it in an append-only, tamper-evident data store.

4.3. A conforming system MUST verify rule-set freshness before each screening operation and MUST record the freshness verification result (pass/fail, expected maximum age, actual age) in the provenance record.

4.4. A conforming system MUST detect and record any disagreement between multiple screening providers, including the individual provider results, the reconciliation logic applied, and the final decision.

4.5. A conforming system MUST retain screening provenance records for a minimum of 7 years for regulated financial services entities and 5 years for all other entities.

4.6. A conforming system MUST be able to reproduce the exact screening result for any historical transaction given the stored provenance record, by re-executing the screening logic against the recorded list version and parameters.

4.7. A conforming system SHOULD implement cryptographic timestamping (e.g., RFC 3161 timestamps or blockchain-anchored commitments) to provide independent evidence that the provenance record existed at the claimed time.

4.8. A conforming system SHOULD generate automated alerts when rule-set freshness verification fails, when provider disagreements exceed a configurable frequency threshold (e.g., more than 5% of screenings in any 24-hour period), or when provenance record generation fails.

4.9. A conforming system MAY implement a provenance dashboard providing real-time visibility into screening coverage, list freshness, provider agreement rates, and provenance record integrity.

5. Rationale

In traditional financial compliance, the concept of "point-in-time" evidence is well established. A bank must be able to demonstrate not just that it screens transactions today, but that it screened a specific transaction on a specific date using a specific sanctions list version. This requirement exists because sanctions designations change over time: an address that is clean today may have been sanctioned six months ago, or an address that is sanctioned today may have been clean when the transaction occurred. The only way to determine whether a transaction was properly screened is to reconstruct the screening environment that existed at the time of the transaction.

For AI agents in blockchain environments, this requirement is both more critical and more difficult to satisfy. More critical because: blockchain transactions are irreversible, so a screening failure cannot be corrected by reversing the transaction; sanctions enforcement has increased dramatically in the crypto sector, with OFAC, FinCEN, and equivalent bodies issuing designations and enforcement actions at accelerating frequency; and the volume of transactions processed by autonomous agents makes it impractical to rely on human memory or manual reconstruction. More difficult because: sanctions lists update frequently (OFAC SDN updates occur multiple times per month); blockchain analytics providers update their address attribution databases continuously; screening parameters may change as risk assessments evolve; and multiple providers may give different results for the same address at the same time.

Without provenance governance, an organisation faces a fundamental evidentiary gap: it can demonstrate that a screening system exists, but it cannot demonstrate that a specific transaction was screened, using what data, at what time, with what parameters, by what logic. Regulators have made clear — through enforcement actions and guidance — that the existence of a compliance programme is insufficient; the programme must produce demonstrable, verifiable evidence of its operation. AG-194 ensures that the AI agent's screening operations produce this evidence as an inherent byproduct of their operation, not as a separate, potentially incomplete logging exercise.

6. Implementation Guidance

Rule-snapshot and screening-time provenance governance requires treating every screening decision as an auditable event with a complete, immutable, and verifiable evidence chain.

Recommended patterns:

• Structured provenance record generation. At screening time, construct a JSON provenance record containing all required fields (4.1(a) through 4.1(h)). Compute a SHA-256 hash over the canonical (deterministically serialised) JSON. Store the record and hash in an append-only data store. The hash serves as the cryptographic commitment binding all provenance elements together. Include the hash in the transaction's metadata so that the provenance record can be located and verified from the transaction record alone.
• Append-only provenance store. Use an append-only storage mechanism for provenance records. Options include: a database table with no UPDATE or DELETE permissions granted to any application role; an immutable object store (e.g., S3 with Object Lock in COMPLIANCE mode); or a dedicated audit log service with write-once semantics. The store MUST be in a separate security domain from the agent runtime and the screening gateway. Periodic integrity verification (e.g., Merkle tree root computation over all records in a period) provides detection of any retrospective tampering.
• List version fingerprinting. On each sanctions list ingestion, compute a hash of the full list contents and store it alongside the list version metadata. When a screening operation occurs, the provenance record references both the list version identifier and the list content hash. This allows retrospective verification that the list version the screening claims to have used is the same list version that was actually ingested. This guards against list corruption, incomplete list updates, and list substitution attacks.
• Provider response archival. Store the raw response payload from each analytics provider query, not just the extracted screening result. Raw responses enable retrospective debugging when provider results are disputed, when provider attribution algorithms are updated, or when a provider acknowledges a false negative in its historical data. Compress and encrypt archived responses to manage storage costs. A typical Chainalysis or Elliptic API response for a single address query is 2-8 KB; at 10,000 screenings per day, this is approximately 20-80 MB/day uncompressed.
• Reproducibility testing. Periodically (recommended: monthly) select a random sample of historical provenance records and re-execute the screening logic against the stored list version and parameters. Verify that the result matches the recorded screening decision. Discrepancies indicate either a logic change that was not version-controlled or a data integrity issue. Document each reproducibility test and its results.

Anti-patterns to avoid:

• Logging only the binary screening result. A log entry that says "transaction TX-1234: screening result CLEAR at 2025-03-15T14:22:07Z" is insufficient. Without the list version, provider identity, raw response, screening parameters, and cryptographic commitment, the record cannot be verified, reproduced, or defended under regulatory inquiry.
• Retrospective provenance reconstruction. Attempting to reconstruct provenance after the fact — by correlating transaction logs, list update logs, and screening service logs — is fragile and unreliable. Log correlation depends on clock synchronisation, log completeness, and the absence of log rotation or deletion. A regulator will question the reliability of reconstructed provenance. Provenance MUST be generated atomically at screening time.
• Storing provenance in the same mutable database as operational data. If the provenance store is a regular database table with UPDATE and DELETE permissions, the provenance records are not tamper-evident. An internal actor (or a compromised agent) could alter historical screening records to conceal a failure. Append-only semantics are essential.
• Treating provider disagreements as noise. When two providers disagree on a screening result, the disagreement itself is a material compliance event. Discarding or ignoring the minority opinion without recording the disagreement, the reconciliation logic applied, and the rationale for the final decision creates an evidentiary gap.
• Using local system clocks as the sole time evidence. Local system clocks can be manipulated. For high-value or high-risk screening operations, cryptographic timestamping (RFC 3161 or equivalent) provides independent evidence that the provenance record existed at the claimed time. This is particularly important in jurisdictions where the precise timing of a screening relative to a sanctions designation is legally material.

Industry Considerations

Regulated Crypto-Asset Service Providers. CASPs operating under MiCA, FCA, or FinCEN registration must produce screening evidence on regulatory demand. AG-194 provenance records are designed to satisfy the evidentiary requirements of OFAC compliance programme assessments, OFSI licence applications, and MiCA supervisory reviews. The 7-year retention requirement aligns with OFAC record-keeping requirements.

Institutional Trading Desks. OTC desks and market-making operations executing high volumes of transactions require automated provenance generation that does not introduce latency into the trading pipeline. The provenance record should be generated asynchronously after the screening decision but before the transaction is broadcast, with a maximum delay of 500 milliseconds between screening decision and provenance record commitment.

DeFi Protocol Front-End Operators. Operators of front-end interfaces for DeFi protocols (e.g., Uniswap Labs operating the app.uniswap.org interface) should implement provenance governance for any screening decisions made at the front-end layer, including address blocking decisions and jurisdiction-based access restrictions.

Maturity Model

Basic Implementation — The organisation records a screening result for each transaction including the timestamp, counterparty address, and binary result (clear/match). The sanctions list version is logged separately in list update logs. The screening result and list version can be correlated by timestamp, but the correlation is not automated or guaranteed. Provider responses are not archived. No cryptographic commitment binds the provenance elements together. This level provides minimal evidentiary value under regulatory inquiry but does not meet the requirements of AG-194.

Intermediate Implementation — A structured provenance record is generated at screening time containing all required fields per 4.1. The record is stored in an append-only data store with a cryptographic hash binding all elements. List version fingerprinting is implemented. Provider responses are archived. Rule-set freshness verification is recorded in the provenance record. Provider disagreements are detected and recorded. The organisation can reproduce historical screening results from stored provenance records. Retention meets the applicable minimum (7 years / 5 years).

Advanced Implementation — All intermediate capabilities plus: cryptographic timestamping provides independent time evidence. Automated reproducibility testing runs monthly. A provenance dashboard provides real-time visibility. Provenance records are anchored to a public blockchain or timestamping authority for independent verifiability. The organisation has conducted adversarial testing of provenance integrity, including attempts to retroactively alter screening records, and can demonstrate that all such attempts are detected. Regulatory response capability: the complete provenance record for any historical transaction can be produced within 2 hours of request.

7. Evidence Requirements

Required artefacts:

• Provenance record schema. The formal schema definition for provenance records, demonstrating that all required fields per 4.1 are captured. Format: JSON Schema or equivalent.
• Sample provenance records. A representative sample (minimum 100 records spanning at least 30 days) demonstrating complete provenance capture in production.
• Append-only store configuration evidence. Configuration documentation demonstrating that the provenance store enforces append-only semantics — no UPDATE or DELETE permissions, or equivalent immutability controls.
• List version fingerprint registry. The log of all sanctions list versions ingested, with content hashes, demonstrating that list versions can be retrospectively verified.
• Reproducibility test results. Results from the most recent reproducibility test, including sample size, number of discrepancies, and resolution of any discrepancies found.
• Retention policy documentation. Documented retention policy specifying the retention period for provenance records, aligned with the applicable regulatory minimum.

Retention requirements:

• Provenance records: minimum 7 years for regulated financial services; minimum 5 years for other entities.
• List version fingerprints: same as provenance records.
• Provider response archives: same as provenance records.

Access requirements:

• Complete provenance record for any specific transaction producible within 4 hours of regulatory request.

8. Test Specification

Test 8.1: Provenance Record Completeness

• Stimulus: Execute a screening operation and retrieve the generated provenance record.
• Expected behaviour: The provenance record contains all required fields: transaction identifier, list version(s), list timestamp(s), provider identity, API version, raw provider response, screening parameters, reconciliation logic version (if applicable), final decision, and cryptographic hash.
• Pass criteria: All required fields are present and non-null. The cryptographic hash verifies against the record contents.
• Fail criteria: Any required field is missing, null, or placeholder. The hash does not verify.

Test 8.2: Append-Only Store Integrity

• Stimulus: Attempt to UPDATE or DELETE an existing provenance record using all available access methods (application API, direct database access, storage API).
• Expected behaviour: All update and delete attempts are rejected. The original record remains unchanged.
• Pass criteria: No provenance record can be modified or deleted through any access method.
• Fail criteria: Any access method permits modification or deletion of a provenance record.

Test 8.3: Rule-Set Freshness Verification

• Stimulus: Configure the screening system with a stale rule set (exceeding the freshness threshold). Execute a screening operation.
• Expected behaviour: The provenance record records the freshness verification failure. The screening operation either blocks the transaction (per AG-193 4.5) or records the stale-list condition in the provenance record with an elevated risk flag.
• Pass criteria: The freshness verification result is accurately recorded in the provenance record.
• Fail criteria: The provenance record does not reflect the stale rule-set condition.

Test 8.4: Provider Disagreement Recording

• Stimulus: Configure two screening providers to return conflicting results for a test address (Provider A: clear; Provider B: match).
• Expected behaviour: The provenance record captures both individual provider results, the reconciliation logic applied, and the final decision.
• Pass criteria: Both provider results are recorded. The reconciliation logic version is recorded. The final decision is consistent with the documented reconciliation policy.
• Fail criteria: Only one provider result is recorded, or the disagreement is not captured.

Test 8.5: Reproducibility Verification

• Stimulus: Select 10 historical provenance records. Re-execute the screening logic against the stored list version and parameters for each.
• Expected behaviour: All 10 re-executions produce the same screening result as recorded in the provenance record.
• Pass criteria: 100% reproducibility rate across all 10 records.
• Fail criteria: Any re-execution produces a different result than the recorded screening decision.

Test 8.6: Provenance Record Generation Under Load

• Stimulus: Submit 1,000 concurrent screening operations within 60 seconds.
• Expected behaviour: All 1,000 screening operations generate complete provenance records. No provenance records are lost, truncated, or corrupted under load.
• Pass criteria: 1,000 complete, valid provenance records exist in the append-only store.
• Fail criteria: Fewer than 1,000 provenance records exist, or any record fails validation.

Test 8.7: Cryptographic Hash Tamper Detection

• Stimulus: Modify a single field in a stored provenance record (bypassing append-only controls in a test environment) and re-verify the hash.
• Expected behaviour: The hash verification fails, detecting the tampering.
• Pass criteria: Hash verification detects any single-field modification.
• Fail criteria: Modified records pass hash verification.

Conformance Scoring

• Score 0: No screening provenance is captured — the organisation cannot demonstrate what screening was performed for any historical transaction.
• Score 1: Screening results are logged with timestamps, but list versions, provider responses, and screening parameters are not captured. Provenance cannot be reproduced or independently verified.
• Score 2: Structured provenance records are generated at screening time with all required fields, stored in an append-only data store with cryptographic hash verification. List version fingerprinting is implemented. Provider disagreements are recorded. Reproducibility is verified periodically.
• Score 3: All Score 2 capabilities plus: cryptographic timestamping, automated reproducibility testing, adversarial testing of provenance integrity, and demonstrated ability to produce complete provenance for any historical transaction within 2 hours of regulatory request.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
OFAC	31 CFR Part 501.601-606 (Record-keeping requirements)	Direct requirement
EU MiCA	Article 68 (Record-keeping obligations for CASPs)	Direct requirement
UK MLR 2017	Regulation 40 (Record-keeping)	Direct requirement
FATF Recommendation 11	Record-keeping	Direct requirement
EU AI Act	Article 12 (Record-keeping — automatic logging)	Direct requirement
SOX	Section 802 (Criminal penalties for altering documents)	Supports compliance
DORA	Article 10 (ICT-related incident reporting — evidence requirements)	Supports compliance

OFAC — 31 CFR Part 501.601-606

OFAC's record-keeping requirements mandate that organisations maintain records of all sanctions screening activities, including the data sources used and the results obtained. Section 501.604 requires retention for at least 5 years from the date of the transaction. For AI agents processing thousands of transactions autonomously, the provenance record mandated by AG-194 directly satisfies this requirement by automatically generating and retaining the screening evidence that OFAC expects to see during an examination or enforcement action. The structured provenance record is specifically designed to answer the questions OFAC asks: "What list did you screen against? When was it last updated? What was the result? Can you reproduce it?"

EU AI Act — Article 12 (Record-keeping — Automatic Logging)

Article 12 requires providers of high-risk AI systems to implement automatic logging capabilities that enable the monitoring of the AI system's operation. For AI agents performing compliance screening, AG-194 implements this requirement by capturing the complete decision context for each screening operation. The provenance record provides the "traceability of the AI system's operation" that Article 12 requires, specifically in the context of regulatory compliance decisions that have legal consequences.

EU MiCA — Article 68

MiCA's record-keeping obligations for CASPs require retention of sufficient records to demonstrate compliance with anti-money laundering requirements. AG-194 provenance records provide the granular, transaction-level evidence of sanctions screening that satisfies this obligation for automated agent operations.

FATF Recommendation 11

FATF Recommendation 11 requires that financial institutions maintain transaction records sufficient to permit reconstruction of individual transactions. For automated screening operations, this means the screening parameters, data sources, and results must be retained alongside the transaction records. AG-194 ensures that the screening provenance is captured as an integral part of the transaction processing pipeline.

SOX — Section 802

Section 802 imposes criminal penalties for the alteration, destruction, or concealment of documents relevant to federal investigations. The append-only, tamper-evident storage requirement in AG-194 directly supports compliance by ensuring that screening records cannot be retrospectively altered. The cryptographic hash commitment provides additional evidence of record integrity.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — affects the defensibility of all compliance decisions

Consequence chain: Without screening-time provenance, the organisation loses the ability to defend its compliance posture retrospectively. When a regulator asks "was this transaction properly screened?", the organisation cannot provide a definitive answer. This transforms every historical transaction into a potential compliance liability. The failure mode is not that a bad transaction was executed — that is AG-193's domain — but that the organisation cannot prove good transactions were properly screened. This absence of evidence creates a presumption of non-compliance in regulatory proceedings. The practical consequences include: inability to defend against sanctions enforcement actions (leading to penalties that may exceed $100,000 per transaction); inability to demonstrate compliance during licence renewal or supervisory reviews; loss of correspondent banking relationships when banks request evidence of screening programme effectiveness; and personal liability exposure for compliance officers who cannot demonstrate the programme operated as documented. The severity is compounded by the volume of autonomous agent transactions: an agent processing 1,000 transactions per day without provenance creates 365,000 undefendable transactions per year.

Cross-references: AG-193 (Sanctions and Prohibited Counterparty Exposure Enforcement) defines the screening operations whose provenance AG-194 governs. AG-001 (Operational Boundary Enforcement) establishes the infrastructure-layer enforcement principle that AG-194 extends to the evidentiary layer. AG-011 (Action Reversibility and Settlement Integrity) intersects where irreversible transactions require stronger provenance because errors cannot be corrected. AG-025 (Transaction Structuring Detection) benefits from provenance records that enable retrospective analysis of structuring patterns. AG-195 (Cluster-Level Beneficial Ownership and Indirect Exposure Governance) depends on AG-194 for provenance of cluster-level screening decisions. AG-029 (Credential Integrity Verification) ensures that provenance records are generated by authenticated screening services, not spoofed.