GDPR and data protection

This page makes no compliance claim

Veridia does not claim to be GDPR-compliant, and this page is not a legal assessment. It describes what the system does with personal data so that you and your counsel can perform your own.

Several things a GDPR programme normally depends on do not exist here yet. They are listed rather than left for you to find out later.

Note that GDPR is not usually the operative regime for the LatAm market Veridia primarily serves — Brazil's LGPD, Argentina's Ley 25.326, and Paraguayan law each have their own requirements. The mechanics below are the same regardless of which regime applies to you; the obligations are not. Which one binds you is a question for counsel.

What personal data is processed

Category	Fields	Source
Face images	Selfie; liveness challenge frames	Camera capture
Document images	Front, and back where required	Camera or gallery
Identity fields	Full name, document number, date of birth, nationality, document type	OCR of the document
Assessment	Verdict, confidence, per-check scores, flags	The verification pipeline
Linkage	Your userRef, if you send one	You
Request context	IP address, user agent, timings	The request

Face images processed in order to match a person against a document are generally treated as biometric data, with heightened requirements attached. Confirm the characterisation and its consequences with counsel — it is not a determination this page can make for you.

Where the data goes

1. The browser or mobile app captures images and uploads them to the Veridia API — not directly to object storage. See Security.
2. The API writes the images to object storage and enqueues the verification.
3. A backend pipeline performs OCR, face matching, liveness assessment, and sanctions screening, writing results to a MySQL database.
4. If you have configured a webhook, the outcome — including identity fields — is delivered to your endpoint.
5. Images are deleted on the retention schedule. The database row is retained. See Data retention.

Your endpoint becomes a store of personal data

The webhook payload includes fieldsExtracted: full name, document number, date of birth, nationality, document type.

That has consequences most integrators only notice later. If your handler logs raw request bodies, or forwards errors to a third-party error-tracking service, or writes payloads to a queue with its own retention, then identity PII has been copied into each of those systems. Include them in your own processing inventory and retention plan.

Data residency

There is no documented data-residency guarantee, and no formal sub-processor list published today. Processing spans Cloudflare's edge infrastructure and a backend host running the ML pipeline and database. If your assessment depends on knowing the processing locations and the sub-processors involved, ask before integrating rather than inferring it from this page.

Data-subject rights: what exists

This is the section to read carefully, because the honest answer for most rights is "no mechanism".

Right	Status
Access	Partial. GET /v1/verify/{id} with a secret key returns the verification's status, verdict, scores, and flags. It is not a complete export of everything held about a person, and it is keyed by verification, not by person.
Erasure	No mechanism. No endpoint, no dashboard control. A request means a manual database and storage operation by an operator.
Portability	No mechanism. No structured export format is produced.
Rectification	No mechanism. Extracted fields cannot be corrected through the API.
Restriction / objection	No mechanism.
Automated decision-making	See below.

There is no self-service path for any of these, and no committed turnaround time for a manual one. If your obligations include responding to requests within a fixed window, that constraint is on you to manage, and you should raise it before you depend on it.

Erasure conflicts with retention

Worth flagging because it surprises people: an erasure request and an AML retention obligation can point in opposite directions. Deleting a record you are legally required to retain creates a different problem from keeping it. Which obligation prevails is a legal question — the system will not resolve it for you, and deliberately does not delete database rows on the retention schedule for this reason.

Automated decision-making

A verification produces one of three verdicts: approved, review, or rejected. Two of those can be reached without a human.

Two things constrain that:

• A hard failure never auto-approves, regardless of how high the confidence score is.
• A strong sanctions match never auto-rejects. It forces the verification to review so that a person decides. See SEPRELAD.

The review verdict routes to a human queue in the dashboard, and the decision is recorded with the reviewer's identity, timestamp, and note.

Whether your use of these verdicts constitutes automated decision-making with legal or similarly significant effect — and what you therefore owe the data subject by way of information, human intervention, or contest — depends on what you do with the verdict, not on what Veridia does. If you gate account access on it, assume the question applies to you and take advice.

Consent

The widget does not capture consent

There is no consent screen, no checkbox, no recorded acceptance, and no timestamp of any agreement anywhere in the widget or the API. The capture flow begins when the user starts it.

If your lawful basis requires consent — and for biometric processing it commonly does — you must obtain and record it yourself, before mounting the widget. Veridia holds no evidence that consent was given, and cannot produce any if you are asked for it.

Likewise, no privacy notice is presented to the end user by the widget. Whatever the person needs to be told about who is processing their face and document, and why, has to be told by your interface.

Processing agreement

No data-processing agreement is offered today. There is no DPA template, no standard contractual clauses package, and no signed processor terms.

If your programme requires a written agreement with a processor before personal data can be shared — which is the normal position — that gap is between you and production. Raise it commercially rather than assuming a document exists.

Breach notification

There is no documented incident-response or breach-notification procedure, and no contractual notification window. If you require one, it needs to be agreed rather than assumed.

Summary of gaps

For assessment checklists:

• No DPA or processor terms
• No consent capture or privacy notice in the widget
• No erasure, portability, or rectification mechanism
• No documented data residency or published sub-processor list
• No documented breach-notification procedure or timeline
• No application-level encryption of identity columns (Security)
• IP address and user agent retained indefinitely with no purge mechanism (Data retention)
• No external audit or certification of any kind