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 without access to your runtime. They can test the covered fields, while key identity, source facts, and coverage remain separate questions.
RegTech builder
Run the evidence layer beneath your own product so the decision streams integrated with it can produce externally verifiable records.
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. That declaration contributes to input_hash, which is covered by the signature; when the original input is available, later substitution changes the hash. Notary Cloud records the declaration — it does not verify it. The public demo records show two separate properties: declared versions displayed beside a signed input_hash, and a daily batch root timestamped by an independent RFC 3161 authority. The public artifact does not expose the input needed to recompute the version binding.
Credibility comes from restraint.
Notary Cloud is early and currently paused. The public record and in-browser verifier remain available.
- Built by Sviatoslav Zhuravlev, the person who filed the FinCEN AML/CFT and PPSI rulemaking comments.
- Project on hold. The live API and write demo are offline; published sample records remain verifiable.
- 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.
- The implementation and published examples are described below; live service is paused.
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 proof bundle is useful only when each field's trust boundary is explicit. Some values are signed; registration metadata and external anchors support separate claims. Each mapping below is evidentiary context, not a compliance badge.
Version declarations committed through input_hash. The public demo displays the declarations beside that hash but does not expose the input needed to recompute the binding. The declarations are recorded, not verified.
A commitment to the submitted input. It detects later change when that input is available; it does not prove what the model actually considered or scored.
The time asserted inside the signed proof. It is not independent time. A verified Merkle inclusion path plus RFC 3161 token shows that the record was in the batch by the token's genTime; it does not establish decision or application-registration time.
A valid signature shows that the signed fields have not changed. Attribution depends on who controls the key and how that key was registered.
A server-assigned order after admission. Gaps can trigger investigation; seq_no is not part of the signed proof and does not show that every source event was submitted.
These are evidentiary mappings, not compliance certifications. No field by itself proves source completeness, semantic truth, or actual execution.
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: receive a decision declaration outside the producing runtime, sign the covered fields with a configured key, and keep the resulting proof independently checkable. Key attribution, source truth, and population completeness remain separate. 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.
Leave a noteEmbed 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 exampleLeave a note about one decision class.
The project is on hold. Share an inquiry or use case here; replies may take time. Email remains available for attachments.
A published or allowlisted signed record can have a verifier URL.
Share an authorized record with an examiner, a counterparty, or your CCO. The page verifies the signature client-side and shows the proof fields, canonical string, and public-key URL. It does not prove semantic truth, source completeness, or actual execution.
- 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 describes the implemented code or published record. The live service is paused.
See signed proof- 01CRYPTOWHEN 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. Attribution is only as strong as key custody and registration.
Maps to: signed-field integrity and key-based attribution; NIST 800-53 AU-10 context
- 02INTEGRITYIMPLEMENTEDDatabase-enforced record controls
Records receive server-assigned sequence numbers. Database triggers block UPDATE and DELETE on protected record tables, while Postgres RLS separates tenant access. Privileged out-of-band storage access remains a trust boundary, and sequence gaps do not prove source completeness.
Maps to: post-admission alteration and sequence signals
- 03STORAGEWHEN 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)
- 04TIMESTAMPPUBLISHED RECORDMerkle + RFC 3161
A July 2026 record shows a Merkle inclusion path and timestamp token from an independent RFC 3161 authority. The token establishes that the root existed by its genTime. It does not establish the earlier application or decision timestamp. The live anchoring job is paused.
Maps to: independent latest-existence bound
- 05AVAILABILITYIMPLEMENTEDFail-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
- 06PRIVACYIMPLEMENTEDAES-256-GCM encryption at rest
Stored enforce payloads and evidence blobs are encrypted with AES-256-GCM before storage.
Maps to: payload confidentiality
- 07ISOLATIONIMPLEMENTEDTenant isolation
Row-level security and FORCE RLS separate tenant records from runtime roles.
Maps to: tenant boundary
- 08PRIVACYPARTLY IMPLEMENTEDPayload 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
- 09OWNERSHIPRECORD 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.
A signature still authenticates an attestation.
If the institution holds the key, a valid signature attributes the declaration to that institution and makes later changes to covered fields detectable within the key-custody model. It does not make the declaration independent or true.
Separate custody narrows one failure mode.
Keeping a signed record and optional write-once copy outside the producing runtime can reduce the chance that one system change removes every copy. Privileged access and source events that were never submitted remain outside that claim.
Third-party verification has a limited object.
A reviewer can verify the signature over covered fields and, when present, the record's Merkle inclusion and the root's RFC 3161 time bound. Key identity, source facts, coverage, custody, and actual execution still require separate evidence.
Past verification and future issuance are different.
A past proof can remain verifiable when the record, trusted public-key reference, and any anchor material are retained. Institution-held key custody preserves the institution's ability to issue future records after a vendor exit, but those records remain institutional attestations.
Teams can build these controls themselves. Notary Cloud packages the narrower signing, registration, anchoring, and custody properties. Whether that is preferable to an in-house implementation is a pilot and procurement question, not a cryptographic fact.
Answers to what compliance teams actually ask.
Regulation B requires adverse-action reasons to be specific and to accurately describe factors actually considered or scored. Notary Cloud does not write your notice and does not judge whether the decision was fair. It preserves the stated reason and supplied decision context in a signed record so a reviewer can later test whether those fields changed and compare them with the source system. It does not independently observe the model computation, prove that the reason was actually used, or prove that every decision was recorded. Open a verifiable appendix example.
No. You already have screeners, case managers, and monitoring systems. Notary Cloud records the decision declaration and scoped context those systems submit. It preserves covered fields for later verification and comparison; it does not establish source truth, execution, or population completeness. 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.
Runtime logs can support reconstruction, but they leave internal audit dependent on the system and operator under review. Notary Cloud adds a separately signed record that can be verified and compared with the platform's own evidence. It does not make the record complete or true by itself.
Different layer, different time scale. Runtime enforcement platforms decide whether an AI-initiated action may proceed. Notary Cloud decides nothing at runtime; it preserves a submitted decision declaration for later integrity checks. The layers can complement each other, but a Notary Cloud record does not prove that an action executed or that every action was recorded.
It is still an attestation by the key holder. A valid signature authenticates the signing key and makes later changes to signed fields detectable; it does not prove that the declaration was true. Additional assurance can come from an independent RFC 3161 timestamp over the batch, separately controlled retention, and reconciliation against another source. The public demo proves cryptographic verification and anchored inclusion, not source completeness or actual execution.
Your core makes decisions. Your SIEM collects logs. Notary Cloud records a separately signed decision declaration that a later reviewer can verify and compare with those systems. Changes to signed fields break verification. This does not establish source completeness or actual execution, and it does not replace either system.
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 record can preserve what an AI system declared it decided, the supplied inputs, and the declared model version for later examination. It does not prove source truth, actual execution, or completeness. Configurable signing, database record controls, and RFC 3161 batch anchoring do not depend on which regulator is asking.
OSFI E-23 expects financial institutions to maintain model-lifecycle documentation and evidence. Notary Cloud can preserve a declared model version, policy state, input hash, decision label, and timestamp in a signed event for later comparison. It does not independently reconstruct what the model did, verify that the declarations were true, or prove that every decision was recorded. Whether the record is sufficient remains a matter-specific judgment for the institution and reviewer.