The documents, selfies, IP address and recordings a verification collects, what Didit keeps by default and how to limit it per feature, for your GDPR review.
By default Didit keeps everything the steps of your workflow produce: the document images and the fields read from them, the selfie and liveness capture, face match images, and the IP address and device signals when the workflow runs Device & IP analysis. You limit it per feature in the workflow's Returned data tab, and you decide how long it stays with retention. Separately, the hosted verification page sends error reports and product analytics to the monitoring tools Didit runs it with; those are part of the service, are the same for every organization, and Returned data does not change them.
#What each step produces
A verification only collects what its workflow asks for: a workflow without a liveness step never captures a selfie. For the steps it does run:
| Step | Personal data it produces |
|---|---|
| ID verification | Front and back images of the document, the portrait cropped from it, and the fields read from it (names, dates, document number, nationality, address, MRZ, chip data when NFC is used) |
| Liveness | The selfie image and the frames of the liveness capture |
| Face match | The two faces compared and the similarity score |
| Proof of address | The uploaded document and the address read from it |
| Device & IP analysis | The IP address, the location derived from it, VPN and proxy signals, and the device and browser |
| Phone and email | The number or address the user verified |
| AML screening | The name and details screened, and any matches |
Everything a step produces is stored with the session and returned in the decision and the webhook, unless you switch it off.
#Limiting what Didit keeps
- Returned data, per feature. Open the feature in the workflow and go to its Returned data tab: every field, image and score has a switch, and what you turn off is neither stored nor returned for new sessions. See choosing which data a verification returns.
- Leave out the steps you don't need. A step that is not in the workflow collects nothing.
- Retention. Set how long sessions are kept, from one month to ten years, or delete a session at any time from the console or the API. See deleting sessions and personal data.
- Model training. Stop Didit using your organization's verification data to improve its models. See opting out of model training.
#Recordings
Two different things get called a "recording", and they are not the same data:
- Full session video. A video of the whole verification from the user's camera. It is off by default and is not a console setting: Didit turns it on for an organization. If your session records show a full session video, it is on for your organization, and support can turn it off. It is never assembled for a user who declined the biometric consent.
- Session replay. A recording of how the verification page was used: the layout of each screen, taps and scrolls. Every text and form field is masked and every image, video and canvas is blocked, so a recording never shows what is on the page: not the camera, the document, the selfie or the data read from it.
#Error monitoring and analytics on the verification page
The hosted verification page runs two monitoring tools, the same for every organization:
| Tool | What it receives |
|---|---|
| Error monitoring | Error reports from the page: the error, the browser and device type, the page address with the verification link removed, and the session ID. No IP address is stored, and no request or response content is sent |
| Product analytics | Events for the steps of the flow (a step started, finished or failed, the document type and country chosen), tied to the session ID rather than to a named person, and the masked session replay described above. Nothing stored on the user's device, and no IP address stored |
No event carries the camera images, the document images, the selfie or the personal fields Didit reads from a document. Both tools receive their events through the verification page's own address, never straight from the user's browser. Neither can be switched off for one organization, and the Returned data tab does not affect them: it governs what Didit keeps on the session and returns to you, not the page's own monitoring.
Both tools are sub-processors of Didit. The binding sub-processor list, with the features each one supports and where it processes data, is the one the Data Processing Addendum references, and it is public at didit.me/terms/sub-processors.
#Related
- Choosing which data a verification returns
- Deleting sessions and personal data
- DPAs, data residency and subprocessors
Still stuck? Talk to a human.
Include your organization ID and the session ID you are asking about.