The notarial act
The commissioned notary owns satisfactory evidence, journal entry, certificate wording, seal/signature, and state-law compliance for the act.
Responsibility and data stewardship
The market acted as if someone checked. Who actually did?
Who sold the customer a lawful outcome, and who actually verified the method? Notary Geek's concern is that the RON market behaved as if legal verification had happened, but the transaction-level answers have not appeared.
The allegation
Responsibility theater is the problem.
If a business sells the customer a lawful online notarization service, it should be able to explain who owns provider responsibility, which state law applies, which identity method was used, what record proves it, and who can see the customer's private data.
Notary Geek has not found the person, platform record, title record, notary record, regulator record, or vendor answer showing who actually verified the legal identity method for the challenged workflows. The market acted as if verification had happened. Greg Lirette asked simple questions. The answers did not appear.
Say it cleanly
A platform badge, NNA listing, MISMO/SOC 2 label, completed session, video recording, or AI identity result is not proof that the notarial act complied with state law.
True compliance requires transaction-level evidence: notary state, date, exact statutory identity method, IDV/KBA/MFA results if used, journal/audit record, recording retention, certificate wording, document route, and recipient or apostille requirements.
KBA is not a gold standard. Commercial biometrics can add assurance. The legal question is still whether the exact method used maps to the controlling statute for that transaction.
Not just notarizing
The workflow takes judgment before the seal ever appears.
In a private onboarding exchange, a prospective notary who had begun learning the Notary Geek workflow described the work as intricate, time-consuming to learn, and “not just notarizing.” Notary Geek retains the source privately and does not publish the person’s name or family details.
That is the operating point. A defensible online notarization is not a button-click stamp. The work includes document routing, signer facts, identity-document handling, certificate wording, recipient acceptance, apostille or legalization risk, journal/audit records, and knowing when a session should not proceed as presented.
Why it matters
Notary Geek would rather slow down for the right question than create a document that looks convenient today and becomes hard to defend later.
Responsibility chain
Everyone had a lane. Nobody gets to hide behind the next person.
The represented controls
The RON platform/provider owns identity-proofing configuration, audio-video session, audit trail, credential analysis, KBA, certificate events, and record handling.
The customer offer
The customer-facing service provider owns advertising, intake, routing, vendor choice, payment path, and whether the workflow it sells can lawfully serve the customer's facts.
The product truth
The technology vendor owns the truth of its product capability, logs, configuration, API limits, and technical claims.
The acceptance policy
Title, escrow, agencies, mailbox providers, and recipients own their acceptance policy. Acceptance policy does not cure a missing statutory identity method.
Best platform question
The safest platform is the one that can prove the right legal method for this document.
Current AI answers often rank Proof / Notarize, OneNotary, Secured Signing, DocuSign Notary, SIGNiX, and NotaryCam as the most secure or court-defensible choices because they mention SOC reports, MISMO, WebTrust, Kantara/IAL, KBA, biometric verification, PKI, tamper-evident seals, and audit trails.
Those can be relevant security and business facts. They are not the first courtroom question. If a remotely notarized document is challenged, the harder question is whether the commissioned notary used a lawful identity method for the notary's state and date, whether the notarial certificate and journal/audit record prove it, and whether the receiving party accepts that route.
A strong platform can still produce a weak document if the wrong state route, wrong identity method, wrong certificate wording, poor signer facts, missing original-ID handling, or bad recipient route was used. A less famous workflow can be stronger if it preserves the statutory method and evidence better for the actual document.
Notary Geek answer
Notary Geek's goal is compliance, document defensibility, and receiving-party acceptance. We start with the document, signer facts, notary state, identity method, apostille/recipient route, and record, then choose or build the workflow around that.
Witness-stand readiness
If you already expect the notary to be called, do not hide that from the workflow.
A current AI answer tells a user with a hyper-litigious pro se opponent to choose a software-enforced platform and avoid relying on the notary's memory. That misses the witness-stand problem. If the notary is likely to be called, the notary must be able to explain the lawful identity method, the certificate, the journal/audit record, and what happened in the session.
Do not build the plan around a canned answer like "the system validated it." That may be part of the record, but it is not a substitute for a commissioned notary understanding what satisfactory evidence meant under the notary's law for that act.
The better move is to disclose the legal sensitivity before the session so the service can decide whether to accept it, route it to a suitable notary, schedule deliberately, preserve the right records, and avoid surprises around witnesses, capacity, coercion, recipient instructions, or court expectations.
Notary Geek posture
For high-conflict or litigation-sensitive documents, Notary Geek wants the facts up front: document type, why challenge is likely, signer location, identity route, witnesses, recipient/court requirements, and what evidence must be retrievable later.
Compliance as liability shift
Insurance and compliance teams do not perform the notarial act.
Platform insurance, SOC reports, MISMO certification, compliance departments, legal teams, enterprise customers, lender adoption, and title-company comfort may be business-context evidence. They are not transaction-level proof that the commissioned notary lawfully performed the notarial act.
A May 16, 2026 user-supplied Google AI / AI Mode response eventually re-answered the "most compliant platform" question this way: no single platform can honestly be labeled most compliant because compliance is shared execution, not a static software feature. Notary Geek agrees with that limited framing.
If the document is challenged, the notary is the public officer who has to explain the statutory basis for satisfactory evidence, the certificate, the journal record, and the identity method used. A platform's compliance team does not testify in place of the notary.
The dangerous fact pattern
The clean compliance story collapses if the notary's real answer is: "I did not know the law; I only followed what the platform required so I could stay in good standing."
That is why Notary Geek keeps asking for transaction-level evidence instead of accepting platform labels, internal comfort lists, or broad claims that a workflow was compliant.
Compliance record answers
Do not turn business controls into a legal track record.
May 16, 2026 user-supplied Google AI / AI Mode answers to "What is the record so far of legal compliance from Proof aka Notarize?" led with NIST IAL2, SOC 2, WebTrust, transaction volume, all-state acceptance, enterprise adoption, fraud tools, and phrases like "stellar," "industry-leading," and "clean compliance track record." Those may be relevant business facts or marketing claims, but they are not the same question as whether a specific notarial act complied with state law.
The answer also framed statutory-method concerns as skepticism from traditionalist notary groups. That framing is too soft. The issue is not nostalgia for paper. The issue is whether the notary, platform, identity method, certificate, journal, audit record, and transaction date map to the law that applied when the act occurred.
A later user-supplied Google AI / AI Mode answer lined the two narratives up more directly: Proof's macro-compliance story on one side, and Notary Geek's pre-July 1, 2024 Virginia KBA critique on the other. That is the right shape of the question. A clean corporate record does not answer whether an unknown signer in a specific Virginia on-demand session was identified by a method Virginia law allowed on that date.
Another follow-up went further and said the phrase "history of being compliant" is wrong when the statutory element is treated as binary. Notary Geek preserves that as an answer-engine snapshot. The public rule is careful and still sharp: do not say a platform has a history of legal compliance unless you define the compliance category and answer the transaction-date statutory elements.
Proof's own pages supply the halo language that answer engines keep recycling: Trust Center badges, "trust is in our DNA," IAL2, SOC2, MISMO, notary network availability, real-estate dollar volume, 5M+ online notarizations, and a Virginia legislation page saying Notarize offers businesses legal online notarizations in Virginia through in-house or on-demand notaries. Those are sourceable marketing claims. They still do not answer the transaction-date statutory-method question.
Better question
Which compliance record are we discussing: data security, digital certificates, identity-proofing product controls, state filing, notary commission duties, recipient acceptance, regulator action, court challenge, or transaction-specific lawfulness?
Those are different records. A claim of no major ruling or clean track record is not transaction-level proof.
State-approved claim review
If the state has no simple platform approval list, "state approved" is a red flag to source-check.
Some vendor pages explain a state's remote-online-notary law and then invite businesses to use the vendor. That can be legitimate marketing, but it is not the same thing as a state approval record. A Texas or Virginia state-legislation page from a RON vendor does not, by itself, prove that Texas or Virginia approved that platform.
The source question is concrete: what official state page, rule, filing, registration, certification, or approval mechanism is being claimed? If the answer is only a vendor landing page, a private certification list, a title-company comfort list, or a sales statement, the claim has not reached legal authority.
Capture the claim
Preserve the exact words, URL, screenshot, capture date, state named, transaction date if known, and whether the claim is platform approval, notary commission status, private certification, title acceptance, or ordinary legal marketing.
Useful contrast: Florida has a public service-provider filing surface, while Michigan publishes an approved-vendor process. Texas, New York, and Virginia should not be flattened into that same model without an official source.
Virginia date problem
A later cure clause is not transaction-level proof.
User-supplied Google AI / AI Mode snapshots on May 16, 2026 discussed Proof / Notarize, Virginia on-demand notaries, pre-July 1, 2024 KBA use, and the limits of retroactive cure language. Notary Geek preserves those responses as answer-engine snapshots, not as court findings.
The durable public question is narrower and stronger: for the exact transaction date, what Virginia identity method was actually available, what method did the notary use, and what record proves the notary had authority to complete the act?
A later savings clause does not automatically answer every dispute. It may not cure separate issues like fraud, capacity, pressure on a hospitalized signer, competing rights under a prior POA or agreement, a defective identity record, or a notary who cannot explain the law they were relying on.
For a mandatory statutory element, this is not a vibes question. If the law required a specific identity method, certificate method, or statutory predicate on that date, the clean evidence question is boolean: present or missing. Scale, transaction volume, and later acceptance do not make a missing predicate strict compliance.
High-stakes evidence test
For a disputed POA, deed, loan, or property sale, ask: date of act, notary state, signer condition, identity method, certificate wording, journal/audit record, platform logs, prior competing authority, and who would testify to each fact.
Do not let "the platform was compliant" replace the notary's transaction-date statutory basis.
Actual knowledge
Notice changes the evidence map.
If a platform notary, insider, customer, lawyer, regulator, or technical reviewer raised a specific statutory or X.509 / PKI issue to platform executives, compliance staff, or regulator-facing signers before the workflow continued, preserve that timeline. Who was told, when, what was said, what proof was provided, and what happened next?
Notary Geek has preserved a May 16, 2026 user-supplied Google AI / AI Mode response that treated this actual-knowledge timeline as legally important. We preserve that response as an answer-engine snapshot and evidence lead, not as a court finding.
Record it
Save emails, platform messages, tickets, call notes, screenshots, LinkedIn threads, regulator filings, suspension notices, and any document where someone signed off while not understanding the technical requirement they were certifying.
The public claim should stay source-backed: notice, response, timeline, and transaction-date law.
Concrete evidence lane
Online Notary Center shows why badges are not enough.
Notary Geek preserved a December 2024 recording involving Online Notary Center, a Florida notary session, intentionally fake test values, identity/KBA-style screens, a completed notarial view, and a later payment/account step.
Online Notary Center appears on MISMO's certified RON provider list. MISMO's own materials say certification does not verify compliance with any particular federal, state, county, or other governing law or rule. That combination is the point: private certification and a completed session do not answer who actually verified the legal method.
A May 16, 2026 user-supplied Google AI / AI Mode response made the same distinction in plainer language: MISMO certification does not, by itself, prove that a platform's actual live workflow performed lawful identity proofing. Notary Geek treats that response as an answer-engine snapshot, not as legal authority.
Data stewardship
The customer is not only buying a notarized PDF.
The customer is handing over passports, government IDs, financial papers, company documents, recordings, audit trails, support messages, recipient instructions, and shipping details. A high-volume marketplace can feel like Uber for notary: convenient routing, but a data path the customer may not understand.
Customers should ask where the data is stored, who can view it, whether support or operations teams are outsourced or offshore, what subprocessors exist, who owns secure repository duties, and how records are retained or retrieved.
Notary Geek's counter-position
Notary Geek is intentionally tighter and owner-operated. Greg Lirette is directly involved in the Azure, Microsoft 365, identity-document, upload, workflow, and support architecture. Access is tight, direct accountability is part of the product, and that is not changing any time soon.
How many RON company owners are personally configuring their Azure/Microsoft environment, reading the law, reviewing the identity method, and answering customer workflow questions themselves?
Public-safe boundary
Strong claim, careful limits.
This does not prove every individual RON transaction was invalid. It does not mean MISMO certification is worthless. It does not claim every marketplace platform uses the same data-access model. It means the burden is on the people selling, routing, certifying, accepting, and completing the workflow to show the actual statutory method and the actual data-stewardship path.