When a regulatory examiner reviews a bank's AML monitoring, the process follows a familiar pattern. The bank presents its policies. It describes how the monitoring system works. It shows sample alerts, case dispositions, and SAR filings. The examiner reviews these materials and forms a judgment about whether the system is effective.
This entire process is built on trust. The examiner trusts that the bank's description of how the system works matches how it actually works. They trust that the sample cases are representative. They trust that the policies documented in the compliance manual are the same policies running in the software.
That trust is usually justified. Banks don't systematically lie to their regulators. But "usually justified" and "verifiable" are very different standards. And the gap between them is where problems hide.
Where Trust Falls Short
There are three specific areas where trust-based audit struggles.
The first is system behavior verification. A bank can present a detailed description of its monitoring rules, thresholds, and scenarios. But the examiner has no way to independently confirm that the production system actually runs those rules. The system could have bugs. The configuration could have drifted from the documented version. A rule change could have been deployed without updating the compliance documentation. These things happen. They're rarely intentional, but they're also rarely caught during a supervisory review.
The second is temporal accuracy. When an incident occurs and the examiner asks "what rules were in effect on this date?", the bank has to reconstruct the answer from change logs, deployment records, and version control. This reconstruction is time-consuming and often imprecise. Batch processing systems are especially problematic here because the relationship between when a rule was changed, when the batch ran, and which transactions were evaluated under which version of the rule can be genuinely ambiguous.
The third is completeness. How does the examiner know that the system actually evaluated every transaction? In a batch system, transactions can fall through gaps between batches, get excluded by filters that aren't documented, or fail to process due to system errors that weren't logged. The examiner has to take the bank's word that the system has complete coverage.
None of these are hypothetical concerns. Every experienced compliance officer has encountered at least one of them. And every experienced examiner knows they exist but lacks the tools to systematically detect them.
What Cryptographic Attestation Changes
Imagine a different model. Instead of the bank describing how the system works and the examiner trusting that description, the system produces a mathematical proof of what it did.
Each batch of compliance decisions generates a proof bundle. This bundle contains: a hash of the policy set that was in effect, a hash of the input data that was evaluated, the verdicts that were produced, a timestamp, and a cryptographic signature that binds all of these together. The bundle also includes a Merkle root over the individual verdict hashes, which means any individual verdict can be verified as part of the batch without revealing all the others.
The examiner receives this proof bundle and runs it through a standalone verification tool. The tool checks: does the signature verify? Does the policy hash match the registered policy set? Does the Merkle root correctly cover the claimed verdicts? Is the timestamp consistent with the claimed evaluation period?
If all checks pass, the examiner has mathematical certainty that these specific policies were applied to this specific data and produced these specific verdicts at this specific time. No trust required. No reconstruction needed. No ambiguity about what version of the rules was running.
What This Doesn't Replace
Cryptographic verification doesn't replace supervisory judgment. It doesn't tell the examiner whether the policies are good, whether the risk appetite is appropriate, or whether the bank's overall AML framework is adequate. Those are qualitative assessments that require expertise, context, and professional judgment.
What it does is eliminate the time spent verifying mechanical facts. Did the system run? Did it run these rules? Did it evaluate these transactions? Did it produce these results? Today, answering these questions consumes a significant portion of examination time and still produces uncertain answers. With cryptographic attestation, these questions have definitive, instantly verifiable answers.
This frees up examination resources for the questions that actually require human judgment. Is the policy set appropriate for this bank's risk profile? Are the thresholds calibrated correctly? Is the bank acting on the alerts the system generates? Is the overall framework effective?
These are the questions examiners should be spending their time on. Instead, much of their time goes to establishing baseline facts about system operation that cryptographic verification could answer in seconds.
The Standalone Verification Tool
One detail matters a lot for practical adoption: the verification tool must be independent of the vendor's software.
If the regulator has to install the vendor's platform to verify the proofs, the trust problem hasn't been solved. It's just been moved. The examiner would be trusting the vendor's verification software instead of trusting the bank's compliance reports.
True cryptographic verification requires a standalone tool that runs independently. It takes the proof bundle as input, applies standard cryptographic operations (hash verification, signature checking, Merkle proof validation), and produces a VALID or INVALID output. The tool should be simple enough to audit, open enough to inspect, and independent of any vendor's infrastructure.
This is the approach taken by blockchain systems, where anyone can verify a transaction proof without running a full node. The same principle applies here. The regulator should be able to verify compliance proofs without installing the compliance engine.
Implications for SupTech Strategy
For supervisory technology teams, cryptographic verification opens new possibilities.
Continuous supervision becomes feasible. Instead of periodic examinations where the examiner reviews a sample of the bank's activity, the regulator could receive proof bundles on an ongoing basis and verify them automatically. Anomalies (missing epochs, policy hash changes, signature failures) could trigger alerts for human review. This shifts supervision from periodic sampling to continuous monitoring, which is a meaningful improvement in supervisory effectiveness.
Cross-jurisdictional supervision also benefits. When a bank operates in multiple jurisdictions, each regulator currently conducts its own examination independently. With cryptographic proofs, a proof bundle from one jurisdiction can be verified by another jurisdiction's examiner without any data sharing or system access. The proof is self-contained. This could simplify supervisory cooperation under frameworks like the ECB's Single Supervisory Mechanism.
The technology for all of this exists now. The question for supervisory authorities is whether to incorporate cryptographic verification into their supervisory expectations, initially as best practice and eventually as a standard. Regulatory sandbox programmes provide the appropriate testing ground.