What we actually do with your ID.

Four signals, all in-house

We do not outsource verification to a brand-name third party. We run a four-signal in-house pipeline and weight the signals into one score, with the full architecture documented on this page. Each signal is independent — borderline scores trigger human review rather than auto-approve.

• PDF417 barcode parse

  Client-side (your browser)

  We read the AAMVA barcode on the back of US driver licenses and state IDs in your browser, before anything is uploaded. Checksum, expiry, date of birth, document number, and address all parse client-side. Foreign documents skip this signal and lean on the other three.

• Face match

  Client + server

  We compare the selfie to the face on the ID using an open-source face-recognition model. A similarity score rolls into the composite. We don't enroll your face in any database — embeddings are computed once per verification and discarded.

• Liveness

  Client + server

  Lightweight liveness check on the selfie — the model looks for the kinds of artefacts a printed photo or a screen recording leaves behind. We also run a server-side glare detector that flags screens being held up to the camera. This is weaker than what a brand-name vendor with adversarially-trained models would give you. We are honest about that — see 'acknowledged risks' below.

• LLM vision sanity check

  Server → Anthropic API

  A subset of pixels from the ID front, ID back, and the holding-ID selfie is sent to Anthropic's Claude API with a structured prompt: does this look like a genuine government-issued ID, and is the person in the selfie the same person pictured on the document? Under Anthropic's standard API terms, inputs from paid customers are not used to train their models. The same-person check is the server-side compensating control for the in-browser face match, which a determined attacker could otherwise forge.

The data flow, in one diagram

  Browser                Our server                Third parties
  ───────                ───────────                ─────────────
  capture ID  ─────►    upload (TLS)        
  capture selfie ──►    encrypt + store           
  PDF417 parse  ──►    barcode signal       
  face match    ──►    face signal          
  liveness      ──►    liveness signal      
                       LLM signal       ──►   Anthropic Claude
                       composite score             (no training)
                            │
                            ▼
                       ≥0.75 auto-approve → signing
                       0.4–0.75 → human review queue
                       <0.4 → reject + retry
                            │
                            ▼
                       signed release PDF
                            │
           ┌────────────────┼────────────────┐
           ▼                ▼                ▼
     your ModelCollabs   (optional)      both parties
     account (encrypted) Drive/Dropbox    receive PDF

What we store, and for how long

What we don't store

• —Drafts of requests you started but never sent.
• —Partial captures (if you retake an ID photo, the discarded version is never persisted).
• —Raw video frames from the liveness check — only the final selfie still image.
• —Face embeddings beyond the single match. We do not maintain a face database.
• —IP addresses or device fingerprints beyond what is needed for the audit log.

Third parties involved

• Anthropic (Claude API)

  Receives a subset of pixels from the ID and the holding-ID selfie for the LLM sanity check (document authenticity + server-side same-person verification). Under Anthropic's standard API terms, inputs from paid customers are not used to train their models.

• Supabase

  Postgres database and object storage. Encrypted at rest; row-level security enforces that only the producer account that created a verification can read it.

• Vercel

  Hosting and edge network. TLS termination, no persistent storage of request bodies.

• Postmark / Resend

  Transactional email delivery (release-request invites, signed-PDF copies). They see email addresses, not ID images.

• Google Drive / Dropbox (optional)

  Auto-sync of signed packages, only if the producer enables it. Files land in the producer's own account, not a shared drive.

Acknowledged risks

We are an early-stage company. There are things a brand-name vendor would give you that we don't — yet. We list them here rather than hide them.

• No third-party errors-and-omissions insurance on verification decisions.

  Mitigation: Composite scoring across four independent signals reduces single-signal failure. A pending-review queue catches borderline cases for human review before any release is signed.

• Our liveness model is weaker than the adversarially-trained models a vendor like Veriff or Persona ships.

  Mitigation: Liveness is one of four signals, not the gate. The LLM vision check provides redundancy against the most common spoof — a printed photo of an ID held up to the camera.

• No SOC 2 yet.

  Mitigation: We are pursuing it, with a target of completion within 12 months of public launch. In the meantime our infrastructure providers (Supabase, Vercel) are SOC 2 Type II certified, and we follow their hardening guidance.

How to request deletion

Email dommy@modelcollabs.com from the address on your account, or use the in-app deletion request from your account settings (coming soon — until then, email is the path). We acknowledge within 24 hours and complete deletion within 30 days, except where retention is required by law (audit log entries are redacted, not removed). You can also request deletion as a recipient — even if you don't have a ModelCollabs account, the producer's release record will be redacted on request.

How we describe what we do

Our verification stack is closed-source — this page is the substitute for that. Every signal, every threshold, every place an image lives, and every third party we touch is described above. If we change how any of it works, this page updates within the same release. If anything on this page no longer matches reality, that is a bug we want to hear about.