Three routes onto the record.
Same evidence layer underneath. Pick the path that matches how you would start. Each one ends in a signed, independently verifiable decision record.
Compliance owner
Scope one decision stream you already examine, such as an adverse action or an AML disposition, and put it under signed record first.
Independent reviewer
Hand a client a live evidence example they can verify themselves, with no access to your runtime and no trust required.
RegTech builder
Run the evidence layer beneath your own product so every decision your platform makes ships with a defensible record.
Where this argument is already dated.
Filed comments are not regulator endorsement. They are dated evidence of the category argument, anchored to rulemaking the whole market is tracking.
Regulatory comments
Three public comments filed in the FinCEN AML/CFT and PPSI rulemaking dockets.
Signed sample
ECDSA P-256 proof generated through the local enforce lifecycle, verified in-browser against a separately served public key.
Architecture
Deployer-held record with the public key retained separately, verifiable even if the runtime is gone.
Credibility comes from restraint.
Notary Cloud is early. The public record, the live verifier, and the status labels are the trust surface.
- Built by Sviatoslav Zhuravlev, the person who filed the FinCEN AML/CFT and PPSI rulemaking comments.
- Pre-revenue. No paying customers and no completed pilots yet.
- If Notary Cloud stops operating, a deployer-held record and retained public key can still be verified without re-running the runtime.
- The pre-revenue status is labelled plainly because this is evidence you may have to defend to your own examiner.
- We label what is live and what is not, because an examiner will.
A concrete next step for a CCO or BSA officer.
Start with one decision class where the institution already carries examination risk: an automated adverse action such as a denial, an AML alert disposition, or a model-risk-relevant compliance call.
Scope
One consequential decision stream, one evidence schema, one verifier path.
Walk-away
A set of signed sample records, review notes, and a go/no-go production outline.
Terms
90-day pilot shape. No annual lock-in. OEM pricing remains on the partner pricing page.
Four moves from decision to defensible record.
The system on file is rarely the system that produced the record.
Per-decision evidence is not enough if the institution cannot later show which system, model, policy, vendor, and custody state existed when the decision was made.
You switched vendors last year. Can you still produce the evidence for a decision the old vendor's system made?
Preservation duties and lifecycle logging duties can collide with data-minimization and erasure duties. Lifecycle logging says little about who controls the logs after the system changes hands.
Adoption is a representation.
A procurement memo, model inventory entry, or vendor statement says what was adopted. It does not guarantee the evidence environment will still exist when the decision is examined.
The system changes.
Models retrain, policies revise, retention changes, vendors switch, and custody moves. The system on file is rarely the system that produced the record.
The evidence splits.
When the model, the policy, or the vendor changes, the evidence does not move cleanly with it. It splits across parties, systems, and retention duties.
Notary Cloud's public posture is narrower: record the decision event outside the producing runtime, use an independent signing key held outside that runtime, and keep the resulting record externally verifiable. This section states the institutional evidence gap, not a solution design.
The cost appears when the examiner asks for the record.
A sober version of the downside: not a breach, not a headline, just an institution unable to prove the state of a consequential AI decision.
The institution produces a vendor export from the current system. The decision was made by the old system.
The reviewer can see a row, but cannot independently test whether the row is complete, whether the policy state matches the date, or whether the export changed after the vendor migration. Mutable logs can still be useful. They are weaker evidence when the institution carries the burden of reconstruction.
Find the right surface fast.
Different buyers need different proof. The site routes to existing detail instead of duplicating it.
Scope one direct decision stream.
Scope a pilotEmbed the evidence layer under your AI compliance agent.
Partner pathReview the lifecycle API and verifier route.
Integration notesShow a client an evidence example without backing a tool you cannot inspect.
Evidence exampleScope a pilot around one decision class.
Use the form when email is too much friction. Mail remains available for security review threads and attachments.
Each signed record gets a verifier URL your examiner can open.
Share a record with an examiner, a counterparty, or your CCO. The public page verifies the signature client-side. It shows proof fields, the canonical string, and the public key URL. It does not prove semantic truth of the underlying decision.
- Signed proof ID in the URL
- Signature validated in the reader's browser
- Canonical string visible
- Payload PII excluded through allowlist
One chain per decision stream.
Each stream of consequential AI decisions gets its own chain. The engine is universal - chains define the shape of a valid record and the events that belong in that stream.
Records SAR-relevant decisions - dismissed, escalated, filed - with the rationale and inputs a BSA examiner would expect.
Records OFAC list-match reviews and the rationale for each dismissal or freeze.
Records threshold-triggered alerts and how they were resolved across the case lifecycle.
Built for the question an examiner asks in month six.
Each row names a structural control. Some are live in code today. The honest ones say what is not.
See signed proof- 01CRYPTOLIVE WHEN CONFIGUREDConfigurable signing
Records are signed by the configured proof key. ECDSA P-256 is implemented when key directories are configured; HMAC remains the default dev and legacy path.
Maps to: agent output provenance
- 02INTEGRITYLIVEAppend-only record storage
Records get monotonic sequence numbers and database-level append-only enforcement. UPDATE and DELETE are blocked on the signed-record tables under row-level security. Do not confuse this with a per-record blockchain.
Maps to: record alteration detection
- 03TIMESTAMPLIVE WHEN CONFIGUREDMerkle + RFC 3161
Daily batches can be hashed into a Merkle root and timestamped through one configured RFC 3161 TSA endpoint. No built-in DigiCert fallback yet.
Maps to: time-of-record evidence
- 04AVAILABILITYLIVEFail-closed validation
Records with unknown chains, missing required fields, or malformed rationale are rejected before storage. The upstream decision remains yours.
Maps to: invalid action rejection
- 05PRIVACYLIVEAES-256-GCM encryption at rest
Stored enforce payloads and evidence blobs are encrypted with AES-256-GCM before storage.
Maps to: payload confidentiality
- 06ISOLATIONLIVETenant isolation
Row-level security and FORCE RLS separate tenant records from runtime roles.
Maps to: tenant boundary
- 07PRIVACYPARTLY LIVEPayload minimization
The public sample exposes only fields needed for verification. Customer schemas still need explicit allowlists before any real customer record is public.
Maps to: data minimization
- 08OWNERSHIPLIVE IN RECORD DESIGNDeployer-controlled record
The record sits in the deployer's evidence layer, not the vendor's runtime. Exportable, reconcilable, contract-independent of vendor terms.
Maps to: vendor runtime boundary
- 09OPERATIONSPLANNEDTransparency surfaces
Public status, incident history, and key rotation log are not live today. They should ship before any production pilot claim.
Maps to: security transparency
Why not just log it yourself?
This objection is valid. The gap is structural, not about whether your team can write logs.
Self-attested vs independently provable.
An in-house log is signed, if at all, by the same party being audited. Notary Cloud's record is signed with a key held outside the system that produced the decision and is verifiable by a third party without taking the deployer's word for it.
Lives inside the system under audit.
In-house logs sit in the same runtime or database that produced the decision, so they can be changed, rotated, or lost by whoever controls that system. The Notary Cloud record survives independently of that runtime.
Verifiable without trusting your infrastructure.
An examiner or counterparty can confirm a Notary Cloud record is authentic and unaltered without trusting your logging stack, your retention policy, or your word. A homegrown log requires them to trust all three.
Building the pipeline is easy. Producing evidence that holds up when the system that made the decision is the thing under question is the part teams cannot build by adding more logging.
Answers to what compliance teams actually ask.
Rules already in force require specific, accurate reasons for an adverse action even when a complex or opaque model produced it, and a creditor's failure to understand its own model is not a defense (CFPB Circular 2022-03). Notary Cloud does not write your adverse-action notice and does not judge whether the decision was fair. It records, outside the system that decided, what was decided, on which inputs, and under which model and policy state, so you can later show the reason you gave matches what the model actually scored. That is the part an in-house log cannot prove on its own, because it is signed by the same system under question. Open a verifiable appendix example.
No. You already have screeners, case managers, and monitoring systems. Notary Cloud records what those systems decided, in a form your examiner can reconstruct. We are the evidence layer underneath your existing stack, not a replacement for it.
The April 2026 NPRM credits institutions whose AI tools help demonstrate AML/CFT program effectiveness. Adoption alone gets no credit. Verifiable evidence of effectiveness is the kind of demonstration an effectiveness-based approach calls for.
Signing is synchronous. Anchoring is asynchronous and should not block the upstream decision. I will publish latency numbers only with a dated benchmark artifact, because made-up p50/p99 claims are worse than no numbers.
Your decision still happens. What is at risk is the record. A pilot design should decide whether to queue records locally and replay them later, or fail-closed on recording for high-risk decisions. That is a customer risk decision, not ours to hide.
Not today. Customer co-signing and BYOK are roadmap items. HSM/KMS-backed signing is not live in the current product.
Most of this site speaks to compliance officers at US banks and fintechs. If you build AI compliance agents that those institutions buy, the partner pages explain how Notary Cloud sits under your product as an evidence layer. Direct, co-brand, and white-label options are scoped during the pilot.
Internal audit cannot reconstruct AI decisions when the audit trail is produced by the same runtime that made the decisions. Notary Cloud records the decision event outside that runtime, in a form internal audit can read, verify, and reconcile against the platform's own surface. This is the artifact independent assurance needs when AI sits in the decision path.
Different layer, different time scale. Runtime authority platforms decide at the moment of execution whether an AI-initiated action is allowed to bind consequence. Notary Cloud decides nothing at runtime. It produces a record of what was decided that an examiner can verify months later without trusting the runtime that produced it. Both are decisional. Runtime authority is decisional at execution time. The externally verifiable record is decisional at examination time, because admissibility in court or before a regulator depends on whether the record survives the system that wrote it. These are complementary slots, not competing ones.
Your core makes decisions. Your SIEM collects logs. We sit between them for decisions a regulator could later question - recording the decision, the rationale, and the inputs in a form the SIEM and the core cannot quietly rewrite. We complement both, not replace either.
The structural problem is the same. Canadian federally regulated financial institutions operate under OSFI E-23 for model risk management and under PCMLTFA recordkeeping requirements that FINTRAC can request on examination. A signed, externally verifiable record of what an AI system decided, on what inputs, under which model version, holds up under those exam postures the same way it holds up under FinCEN or EU AI Act scrutiny. Independent signing key, append-only record storage, optional RFC 3161 anchoring. The architecture does not depend on which regulator is asking.
OSFI E-23 requires federally regulated financial institutions to demonstrate model risk management across the model lifecycle, including documentation that an examiner can use to reconstruct what a model did and why. Where AI sits in a decision path, the same record fields matter: model version, policy state, input hash, decision label, and timestamp. Notary Cloud records those as a signed event the institution can produce on examination without depending on whichever vendor runtime made the call. This is the same artifact that supports SR 11-7 reconstruction in the US.