Draft Letter To Proof / Notarize Regarding Virginia RON, Platform Scale, No-SSN Claims, And Transaction Evidence

# Draft Letter To Proof / Notarize Regarding Virginia RON, Platform Scale, No-SSN Claims, And Transaction Evidence

Status: working draft  
Date drafted: 2026-05-17  
Prepared for: Greg Lirette / Notary Geek / GoodWare LLC  
Purpose: deep Proof / Notarize notice and clarification letter; not yet public copy

## Draft Letter

Greg Lirette  
GoodWare LLC / Notary Geek  
Clearwater, Florida  
G@notary.cx

May 17, 2026

Proof  
formerly Notarize

Re: Request for transaction-level clarification regarding Virginia online notarization, KBA timing, no-SSN workflows, platform representations, and retained identity-method evidence

To Proof:

I am writing because Proof / Notarize is not an ordinary software vendor in the remote online notarization market. Proof has operated one of the most visible RON platforms in the United States. Its public materials, state pages, trust center, notary network, real-estate integrations, identity assurance language, and security claims shape how customers, notaries, title companies, lenders, regulators, and answer engines understand online notarization.

That influence creates a higher need for precision. A platform can have strong security controls, major customers, a large network, certifications, fraud tools, and meaningful transaction volume while still needing to prove the statutory identity method used for a particular notarial act on a particular date.

My concern is that Proof's market position creates a compliance halo. People see scale, badges, trust-center language, real-estate volume, identity assurance, biometric language, and state availability pages. They then treat those signals as if they prove that each transaction complied with the notary law governing the commissioned notary. That is not how notary law works.

This letter asks Proof to clarify the transaction-level evidence behind its Virginia, no-SSN, KBA, biometric, on-demand-notary, and state-law representations.

## 1. The Core Evidence Problem

For any challenged online notarization, the controlling questions are not brand questions. They are transaction questions:

1. Which commissioned notary performed the act?
2. Which state law governed the notary on the transaction date?
3. Where was the notary physically located if that state required it?
4. Which statutory identity method or methods were used?
5. Was the signer personally known, identified by credible witness, identified by credential analysis, identified by KBA, identified through a signer-side certificate or PIV/PIV-I route, or identified by another authorized method?
6. What record proves the method?
7. What did Proof retain, what did the notary retain, and what did the relying party receive?
8. Could the notary explain the statutory method without relying on a generic platform pass/fail result?

Those questions cannot be answered by saying that Proof is large, trusted, certified, secure, integrated with real estate, or used by enterprise customers. Those facts may be relevant to business trust and platform controls. They are not transaction-level proof.

## 2. Proof's Public Materials Should Not Be Read As Transaction Proof

Proof's public materials, as preserved by Notary Geek, contain strong trust and scale signals. Proof has described itself as an identity-assured transaction management platform. Proof has described security, compliance, and policy as central to its business. Proof displays or references trust, security, accessibility, MISMO, SOC 2, Kantara, and related badges or certifications. Proof describes the Notarize Network as available 24/7. Proof describes high transaction volume, real-estate use, fraud-prevention tools, identity alerts, credential analysis, KBA, biometric comparison, and related controls.

Those statements may be true in their proper lane. The issue is source-weighting. Answer engines, notaries, customers, and industry participants are converting product and market claims into legal conclusions. They read "Virginia supported," "on-demand notaries," "biometric verification," "identity-assured," or "trusted platform" as if those phrases prove the statutory identity method for an unknown signer.

They do not.

This concern has become sharper because Proof's current public marketing now leans directly into AI-era trust language. Greg preserved Proof homepage and product-page language saying, in substance, that AI cannot generate trust and that Proof verifies signer identity with "government ID + facial biometrics" before documents are signed or notarized. Proof also markets high-stakes power-of-attorney and real-estate workflows around fraud reduction, authorization records, audit trails, and compliance speed.

That marketing may be fair product positioning if it stays in the lane of Proof's own workflow, security, and fraud-control representations. But it becomes dangerous if customers, answer engines, title companies, lenders, FedEx Office customers, notaries, or document recipients read it as a legal conclusion that every Proof transaction is valid under the notary's state law. "Government ID + facial biometrics" is not the same legal evidence object as Virginia's signer-side valid-digital-certificate / PIV biometric identity lane. An AI-resistant authorization record is not automatically a legally sufficient notarial act. A tamper-evident audit trail records what happened; it does not by itself prove that the identity method used was allowed by the controlling statute on the transaction date.

Proof is in the best position to stop that conflation. If Proof wants to market AI-resistant trust, signer identity verification, fraud prevention, and notarized authorizations, it should also publish the boundary: platform identity verification and transaction records are evidence, not a substitute for mapping the notarial act to the commissioned notary's state law, transaction date, statutory identity method, notarial certificate, record-retention rule, and recipient or apostille requirements.

I am asking Proof to publish clearer language separating:

1. platform security controls;
2. business certifications;
3. notary onboarding;
4. notary background screening;
5. title or real-estate eligibility logic;
6. biometric data processing;
7. fraud prevention;
8. credential analysis;
9. KBA;
10. no-SSN or non-KBA workflows;
11. the commissioned notary's statutory identity method for a specific transaction.

## 3. Virginia Is The Stress Test

Virginia is the clearest example of why the distinction matters.

The recurring public mistake is to say that Virginia "allows biometrics" and then treat ordinary commercial selfie capture, liveness detection, face matching, or passport image comparison as the Virginia biometric identity method. That is not the point Notary Geek has been making.

Virginia's certificate/PIV biometric lane concerns a signer-side valid digital certificate accessed by biometric data, or a PIV/PIV-I-style credential, in the context of satisfactory evidence of the principal's identity. It is not the notary's own electronic signing certificate. It is not the notary's seal. It is not Proof's document tamper-evidence. It is not the platform's account security. It is not a face match alone.

If Proof claims that an unknown signer in a Virginia online notarization was identified through the certificate/PIV biometric route, the transaction record should be able to identify the signer certificate or PIV/PIV-I credential, issuer, trust path, revocation status at the relevant time, access event, biometric unlock/access evidence, platform audit event, and notary journal evidence.

If the transaction used commercial selfie/liveness/face-match technology, say that. But do not let that be called Virginia statutory biometrics unless the signer-side certificate/PIV evidence exists.

This is simpler than the market often makes it. If Proof does not claim that its ordinary Virginia workflow used a signer-held valid digital certificate, PIV, PIV-I, CAC, TWIC, or comparable signer-side credential accessed through biometric data, then Proof should not allow ordinary Proof selfie or Persona-style facial comparison to be described as Virginia statutory biometrics. If Proof does make that claim, the evidence should be concrete enough for a notary, regulator, title underwriter, court, or recipient to inspect.

## 4. KBA Timing Must Be Separated By Date

Virginia later added knowledge-based authentication assessment as an express listed method effective July 1, 2024. That later change matters. It cannot be backread into older transactions without analysis.

For pre-July-1-2024 Virginia transactions involving unknown signers, Proof should be able to answer:

1. Did Proof / Notarize allow Virginia notaries to use KBA for unknown signers before July 1, 2024?
2. If yes, what Virginia statutory text, regulation, standard, or official guidance did Proof rely on for that workflow on that date?
3. Did Proof route consumer on-demand signers through Virginia notaries before July 1, 2024?
4. Did Proof route non-U.S., no-SSN, or foreign-passport signers through Virginia notaries before July 1, 2024?
5. Did Proof's internal compliance team separately analyze Virginia's pre-2024 identity methods, or did it rely on industry practice, NNA materials, vendor assumptions, title-market practice, or regulator silence?
6. Did Proof update public pages, training, support guidance, notary onboarding, or transaction logic after the July 1, 2024 KBA amendment to distinguish earlier and later Virginia workflows?

For post-July-1-2024 Virginia transactions, KBA being listed does not solve every issue. It only helps workflows where KBA actually ran, passed, and was combined with any other required statutory method. It does not authorize a separate no-KBA foreign-signer workflow simply because a platform label says biometric, liveness, or face match.

## 5. No-SSN And Non-KBA Claims Need Exact Workflow Labels

Public and AI answers increasingly say that Proof supports signers without SSN or ITIN. That claim needs careful labeling.

My operating experience was that ordinary Notarize / Proof on-demand sessions used KBA. I am not saying Proof can never support a no-SSN or non-KBA route in a private, enterprise, personally-known, credible-witness, Form 1583 verification-of-fact, support-configured, or recipient-controlled workflow. I am saying that Proof should not be treated as a confirmed public no-SSN RON answer unless the session type, notary state, statutory basis, signer identity method, and transaction record are identified.

Please clarify:

1. Which Proof workflows, if any, allow a signer without SSN or ITIN to proceed without KBA.
2. Whether those workflows are public self-serve, private/enterprise, title-controlled, support-configured, or limited to specific statutory bases.
3. Whether the no-SSN path depends on personal knowledge, credible witness, Verification of Fact, a particular state, a particular document type, recipient policy, or another condition.
4. Whether independent notaries can configure that path or whether Proof controls it centrally.
5. Whether a no-SSN path is a notarization path or a non-notarial verification path.
6. Whether Proof distinguishes "we have technology that can do X" from "this workflow is available to ordinary consumers and lawful under the commissioned notary's state law."

This distinction matters because answer engines are now turning broad platform capability into customer recommendations. If Proof has a narrow no-SSN lane, it should be labeled narrowly. If ordinary on-demand Proof sessions require KBA, that should not be blurred by generalized no-SSN or biometric marketing.

## 6. Proof's Own Terms Reinforce The Need For Transaction Evidence

Proof's public terms and support materials appear to distinguish platform availability, notary onboarding, account control, security, biometric-data processing, Form 1583 workflows, in-house notary responsibility, and notary-law compliance.

That distinction matters.

If Proof tells notaries that they are responsible for applicable notary law, then the notary needs more than a pass/fail platform screen. The notary needs enough information to know what statutory identity method was used and what record proves it.

Please clarify:

1. Does Proof treat itself as responsible for determining that an identity workflow satisfies the notary's commissioning-state law?
2. Does Proof treat the notary as solely responsible for that determination?
3. Does Proof distinguish consumer on-demand notarizations from business, title, enterprise, API, and in-house-notary transactions for compliance responsibility?
4. Does Proof preserve the exact identity-method evidence needed by the notary if the transaction is challenged later?
5. Does Proof give the notary enough information to record the statutory method, or only a product-status result?
6. Does Proof disclose to signers, businesses, title companies, and notaries when a workflow is a non-notarial verification path rather than a notarization path?

The notary is a public officer. If Proof completes the session but the notary cannot later identify the statutory method, the transaction has a serious evidence problem.

## 7. Real Estate And Title Routing Amplify The Risk

Proof's real-estate role makes this issue larger than retail notarization.

When a platform works with title, escrow, lenders, settlement agents, county recording, and underwriter-driven eligibility logic, platform conclusions can become de facto market rules. Customers, notaries, and smaller providers may be told that one workflow is required, accepted, or compliant because the platform and title ecosystem have made it operationally convenient.

That is not law.

Please identify how Proof separates:

1. title or underwriter preference;
2. platform eligibility logic;
3. county recording acceptance;
4. MISMO or other private certification;
5. fraud and identity assurance product controls;
6. the notary's public-law identity method;
7. recipient acceptance after execution.

## 8. Requested Preservation

Please preserve records relevant to the issues raised in this letter, including records concerning:

1. Virginia on-demand notary workflows before July 1, 2024;
2. Virginia on-demand notary workflows after July 1, 2024;
3. KBA use by Virginia notaries;
4. foreign-signer, no-SSN, no-ITIN, non-KBA, or alternative identity workflows;
5. signer-side certificate, PIV, PIV-I, CAC, TWIC, or comparable credential support;
6. Proof's interpretation of Virginia Code section 47.1-2 and related guidance;
7. internal communications about Virginia KBA before and after the 2024 amendment;
8. internal communications about the meaning of "biometric" in Virginia;
9. public state-legislation pages and notary onboarding pages;
10. help-center pages and support macros concerning Virginia, KBA, foreign signers, and no-SSN workflows;
11. training materials for Virginia notaries on the Notarize Network;
12. communications with NNA, SIGNiX, MISMO, title companies, underwriters, state offices, or identity vendors concerning Virginia identity methods;
13. transaction logs, audit records, notary journal fields, audio-video record-retention fields, and identity-method labels.

This is a preservation request because these records may be necessary to understand what Proof represented, what Proof actually did, what notaries were told, and what records exist for challenged transactions.

## 9. Requested Public Corrections Or Clarifications

I am asking Proof to do the following:

1. Publish a clarification separating platform trust/security/certification claims from transaction-level notary-law compliance.
2. Publish Virginia-specific identity-method guidance that clearly distinguishes pre-July-1-2024 and post-July-1-2024 law.
3. Explain whether Proof / Notarize used KBA for Virginia unknown signers before July 1, 2024, and what statutory basis Proof relied on.
4. Explain whether Proof ever supported the Virginia signer-side valid-digital-certificate / PIV biometric lane for ordinary unknown signers, and if so, what record proves it.
5. Label any no-SSN or non-KBA workflow by session type, state, statutory basis, public/private availability, and transaction evidence.
6. Clarify what exact identity-proofing evidence Proof gives or preserves for the notary if a transaction is later challenged.
7. Review public state-legislation pages so that "available," "authorized," "legally complete," or similar language is not read as Proof certifying every identity path under every state law.
8. Review Proof's Form 1583 public and contractual materials so that no-SSN verification language is not confused with full notarial satisfactory evidence.
9. Identify whether Proof believes any past public claims, help-center articles, state pages, trust-center materials, or sales materials need correction.

I am not asking Proof to remove accurate product statements. I am asking Proof to stop the market from converting product, scale, and trust language into statutory identity-method conclusions that only transaction records can prove.

Please route this letter to the teams responsible for legal, compliance, policy, trust, product, notary network operations, real estate, public communications, data retention, and state-law content.

Respectfully,

Greg Lirette  
GoodWare LLC / Notary Geek  
G@notary.cx

## Short-Link Source Appendix

Primary source packet for this letter:

https://notary.cx/proof-letter

Proof public trust / marketing source packet:

https://notary.cx/proof-trust

Proof legal terms / notary network source packet:

https://notary.cx/proof-terms

Proof / Notarize Virginia state-page source packet:

https://notary.cx/proof-va

Virginia Code section 47.1-2:

https://notary.cx/va-471-2

Virginia 2024 KBA amendment source trail:

https://notary.cx/va-kba-2024

Notary Geek Virginia biometrics correction:

https://notary.cx/va-bio

Notary Geek Virginia KBA investigation:

https://notary.cx/va-kba

Notary Geek no-SSN / foreign-signer source packet:

https://notary.cx/no-ssn

Underlying public source URLs and preserved evidence files are maintained by Notary Geek and can be provided in full.