PROJECT PAUSED · Live API offline. Published samples remain verifiable. Inquiries stay open.
About

Built by the person who filed the NPRM comments.

Notary Cloud is built by Sviatoslav Zhuravlev. Filed public comments under FINCEN-2026-0034 and FINCEN-2026-0100 on the deployer-evidence gap that surfaces when AI participates in compliance decisions and an examiner later asks for the record.

The product exists because the structural problem under both US and EU regimes is the same. Vendor logs can be part of the evidence, but they leave an institution dependent on the system and operator under review. Notary Cloud adds a separately signed record that can survive the producing runtime and be checked later. That check is limited to the fields the proof covers; it does not establish that the source was truthful or complete.

Operating from Spain. Direct, partner, and regulator-side conversation all welcome.

LinkedInEmail

Where Notary Cloud sits in the emerging stack

The market is starting to map the stack around AI governance into distinct layers. Some companies are building intelligence generation, some orchestration, some policy definition, some runtime authority that decides at the moment of execution whether an action is allowed to become real. The picture is broadly correct as a category map.

Where I disagree is on what one of those layers actually does. The attestation, witness, continuity slot is often described as informational. As a layer that records what happened so other layers can decide.

That description undersells the operational consequence. When an examiner asks six months later whether a control held on a given date, a reviewer needs evidence it can test rather than a story reconstructed only by the system under review. Runtime enforcement matters when an action is attempted. A witness record matters later, when the reviewer assesses what can be verified and what still depends on source evidence.

For that later review, the signed record should be checkable without asking the producing runtime to recreate it. A valid signature makes later changes to covered fields detectable. A verified Merkle inclusion path can link the record to a daily root, and an RFC 3161 token can show that the root existed by its genTime. Those properties do not establish that the declaration was true, that the recorded action executed, or that every required event was submitted. Key identity and custody remain separate evidence questions.

There is a second question underneath that slot: who holds the signing key. A vendor-held key can authenticate vendor-issued records. Past records can remain verifiable after a vendor exit if the record, a trustworthy public-key reference, and any anchor material were retained; the dependency concerns future issuance and custody operations, not a past signature expiring. An institution-held key preserves the institution's ability to issue its own records, but it remains an attestation by that institution. The signature supplies attribution and signed-field integrity, not independent truth. Additional assurance must come from capture controls, retention, reconciliation, and evidence that the observation path could not be bypassed.

EU AI Act Article 12 addresses automatic event-logging capabilities in high-risk systems, while Article 26(6) requires deployers to keep automatically generated logs to the extent those logs are under their control. Those duties support keeping usable evidence under deployer control; they do not turn an institution's own signed declaration into independent proof.

That bounded record-integrity and custody slot is where Notary Cloud sits.

Public record

Regulatory comments

Notary Cloud has filed public comments in U.S. rulemaking on AML/CFT and stablecoin evidence standards.

Status, plainly

  • Pre-revenue. No paying customers, no completed pilots yet.
  • No legal entity yet. Incorporation path is Stripe Atlas Delaware C-corp or explicit deferral, depending on first paid pilot timing.
  • Engineering is solo. Backend code supports the cryptographic evidence pipeline when configured: ECDSA P-256 signing, RFC 3161 timestamping, and daily Merkle anchoring through a configured TSA endpoint. A browser-verifiable external-origin key demo is published at /r/prf_fe22c21f8edaed3d.
  • Public technical comments are posted on regulations.gov under FINCEN-2026-0034 and FINCEN-2026-0100.