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 an externally verifiable 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
Signing key held outside the producing runtime, public key retained separately; the record stays verifiable even if the runtime is gone. Deployer-held key custody is the pilot target mode; the public demo shows a deployer-labelled record verifying against a key served from a separate origin. The deployer can also declare the model and policy version inside the decision input; the declaration is hash-bound into the signed record, so it cannot be swapped after the fact. Notary Cloud records the declaration — it does not verify it. Both properties are live on the public demo records: declared versions visible on an anchored record, and a batch root countersigned by an independent RFC 3161 timestamp authority.
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, an exported record and the retained public key can still be verified without re-running the runtime. Deployer-held key custody is the pilot target mode; today the pilot key is held by Notary Cloud, and the deployer-labelled demo record shows external-origin key verification.
- 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 externally verifiable record.
What each field in the record is for.
A signed record is only useful if each field answers a question an examiner actually asks. Each field below maps to a specific evidentiary requirement, not to a compliance badge.
Versions the deployer declared at decision time, hash-bound into the signed record so they cannot be swapped afterward. Visible on the public demo record. The declaration is recorded, not verified.
That the stated reason for the decision matches what the model actually scored.
When the record was created, provable by a third party.
That the record has not changed since creation and comes from the deployer's key.
That the record cannot be quietly rewritten or deleted after the fact.
These are evidentiary mappings, not compliance certifications. The record supports each requirement; it does not by itself satisfy it.
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
The pipeline is running. Verify it yourself.
A hosted Notary Cloud backend produced the pilot record below through the full live pipeline: enforce, ECDSA P-256 signing, a daily Merkle root, and an RFC 3161 timestamp from an independent authority. Every artifact is public — check each one without trusting us.
WebCrypto recomputes the ECDSA P-256 check locally against the public key; flip one byte and verification fails. The record carries the declared model and policy version (hash-bound via input_hash) and the countersigned batch root.
Open record prf_29dcc501b0a7821a →The signing key's public half is served by the backend's well-known endpoint — the same URL the record page uses for verification.
render_demo_proof_1.pem →The daily Merkle root covering the record, with its RFC 3161 token, is public — no account, no key. The anchor proves the record existed no later than registration time.
/v1/transparency/2026-07-04 →The pilot record is synthetic and signed by a Notary Cloud pilot key — it demonstrates the live pipeline mechanics. Deployer-held key custody is a separate property, demonstrated by the Demo Bank-labelled record, whose key is served from an origin outside the backend. Two records, two properties.
Watch the pipeline sign a record, live in the console.
Pick one of the synthetic cases and hit run. The sandbox checks it against the finance pack, decides ALLOW or DENY, and signs the record with ECDSA P-256, one line at a time in the console. Then verify that signature yourself, or change one byte and watch it break.
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; NIST 800-53 AU-10 (non-repudiation)
- 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
- 03STORAGELIVE WHEN CONFIGUREDCustomer-held WORM retention
When the customer's Object-Lock bucket is configured, signed records replicate into it (write-once retention), so the bytes sit under the institution's retention control, not ours. Deleting or rewriting a record inside the retention window is blocked by the customer's storage layer itself.
Maps to: record retention; record-alteration detection (storage layer)
- 04TIMESTAMPLIVE — ON THE DEMO RECORDMerkle + RFC 3161
Daily batches are hashed into a Merkle root and countersigned by an independent RFC 3161 timestamp authority. The public demo record carries the token; it verifies offline with openssl. The anchor proves the record existed no later than registration time. Fallback endpoints are configurable; none ships as a built-in default.
Maps to: time-of-record evidence
- 05AVAILABILITYLIVEFail-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
- 06PRIVACYLIVEAES-256-GCM encryption at rest
Stored enforce payloads and evidence blobs are encrypted with AES-256-GCM before storage.
Maps to: payload confidentiality
- 07ISOLATIONLIVETenant isolation
Row-level security and FORCE RLS separate tenant records from runtime roles.
Maps to: tenant boundary
- 08PRIVACYPARTLY 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
- 09OWNERSHIPLIVE 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
- 10OPERATIONSPLANNEDTransparency 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.
Vendor-held key vs institution-held key.
A vendor can also sign the record for you and hold the key. That answers tampering, but it leaves two things with the vendor: the record stays verifiable only while the vendor keeps signing, and new evidence can only be produced while you keep that vendor. Independence of the signer is bought at the cost of dependence for production. Holding the key inside the institution keeps both the production of new records and their verification on your side, while anyone can still check a record against the published key. The independent check is the verifier, not the vendor.
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 enforcement platforms decide at the moment of execution whether an AI-initiated action is allowed to proceed. 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 enforcement is decisional at execution time. The externally verifiable record is decisional at examination time, because what a regulator or court will accept depends on whether the record survives the system that wrote it. These are complementary slots, not competing ones.
No, and the reason is specific. The assurance does not come from who holds the signing key. It comes from two things a reviewer can check without taking anyone's word: the record is tamper-evident and append-only, and its signature verifies against a public key served from a separate origin, not from inside the system that made the decision. Anyone can fetch that key and verify the record independently. Holding the key inside the institution is also what keeps the evidence under the institution's own control, the control Article 12 of the EU AI Act asks for, instead of depending on a vendor to keep producing new records. Where the timing of the record itself has to be provable by a third party, batch roots are countersigned by an independent RFC 3161 timestamp authority — shown countersigned on the public demo record, verifiable offline.
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 declared 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, RFC 3161 batch 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: declared model version, policy state, input hash, decision label, and timestamp. Notary Cloud records those as a signed event — the versions are what the institution declared at decision time, hash-bound so they cannot be rewritten later — that 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.