What is a digital footprint check in KYC?

A check of whether the email address, phone number or username an applicant supplied is registered with accounts on public platforms, and for how long it has demonstrably existed. It complements document and liveness checks, which prove a document is genuine but say nothing about whether the contact details have any history.

Does a digital footprint check count as identity verification under AML rules?

No. It is a corroborating signal, not identity proofing, and our terms say so explicitly. Use it to decide how much additional verification an applicant needs and to document the basis for that decision, not as the sole evidence that someone is who they claim to be.

Is checking an applicant’s email against social platforms GDPR-compliant?

It can be, and many regulated firms do it under the legal-obligation or legitimate-interest bases, but the lawful basis, any required assessment and the duty to inform applicants are yours. The API returns only whether an account exists, never its contents, which keeps the processing narrow.

Can I keep the result as part of the audit trail?

Yes. Every result carries the method and the exact time it was established, the response has a lookupId, and past lookups are listable from the API scoped to your account. That is enough to show a reviewer what was known at the moment the onboarding decision was taken.

Digital footprint checks for KYC and AML onboarding

Updated 2026-08-30

A document check proves a document. A digital footprint KYC check adds a different fact: whether the email address the applicant typed has existed, and been used, anywhere before today. This AML identity verification API reports which accounts are registered to the identifier, its breach history and public mentions, each with the method and timestamp a reviewer will ask for.

Why a digital footprint belongs in KYC onboarding

Synthetic identities pass document checks. A fabricated name attached to a real-looking ID and a freshly created email address will clear most onboarding flows, because nothing in those flows asks whether the contact details have a past. A digital footprint check asks exactly that. An address that has been registered with a professional network, a developer platform and a music service, and that appears in a breach dated 2012, has existed for at least fourteen years. A synthetic applicant’s address exists nowhere. Neither fact settles the case on its own; both change how much further verification is proportionate.

The check runs on the identifier the applicant gave you, which matters for data protection: you are corroborating something they supplied, not discovering something they did not. The response never contains profile contents, only existence, method and time.

What the AML identity verification API returns

One request, one response. For each of the 887+ platforms that answered confidently, registered says whether an account exists for the input, method says how that was established and checkedAt says when. The example below is a well-established footprint of the kind a genuine applicant usually has.

POST /v1/lookup?wait=true

curl -X POST "https://api.digifootprint.dev/v1/lookup?wait=true" \
  -H "Authorization: Bearer dfp_your_key" \
  -H "Content-Type: application/json" \
  -d '{"query": "a.okafor@example.com"}'

Response (abridged) - an established footprint

{
  "lookupId": "c41d7f2b-...",
  "query": "a.okafor@example.com",
  "platformsChecked": 887,
  "matches": 6,
  "socialMatches": 5,
  "servedFromCache": false,
  "results": [
    { "platform": "google",   "registered": true, "method": "domain_derived", "checkedAt": "2026-08-30T10:02:41.310Z", "mailboxProvider": true },
    { "platform": "linkedin", "registered": true, "method": "public_api",     "checkedAt": "2026-08-30T10:02:41.512Z" },
    { "platform": "github",   "registered": true, "method": "public_api",     "checkedAt": "2026-08-30T10:02:41.640Z" },
    { "platform": "spotify",  "registered": true, "method": "public_api",     "checkedAt": "2026-08-30T10:02:41.688Z" },
    { "platform": "strava",   "registered": true, "method": "public_api",     "checkedAt": "2026-08-30T10:02:41.902Z" }
  ],
  "breaches": [
    { "name": "Canva", "date": "2019-05-24" },
    { "name": "Dropbox", "date": "2012-07-01" }
  ],
  "webMentions": [],
  "phoneDetails": null
}

Note the Google result: it carries mailboxProvider: true and method: domain_derived because the account came with the mailbox rather than being signed up for, so it is counted in matches but not in socialMatches. Platforms that could not be confirmed are omitted rather than listed as unregistered. The full field reference is in running a lookup.

Reading the signals: age, breadth and corroboration

Age. The oldest date in breaches is a lower bound on how long the address has existed, established by a third party with no stake in the outcome. It is the single most useful KYC fact in the response, and it comes from breach data rather than from anything the applicant can fabricate on the day.

Breadth. socialMatches counts accounts the person chose to create. A professional profile on LinkedIn, a developer account on GitHub and a fitness app do not co-occur on a burner address. Breadth across unrelated categories is a stronger signal than several accounts in one category, so weight distinct platform categories rather than raw counts.

Corroboration. If the applicant also gave a username, run it as a second lookup. A handle that exists on the same platforms as the email is consistent; a handle with a rich footprint attached to an email with none is worth a question. webMentions marked confirmed show the identifier appearing verbatim on public pages, and unconfirmed ones should be ignored for compliance purposes.

An audit trail a reviewer can follow

Compliance reviewers ask two questions of any signal: what did you know, and when did you know it. Every result answers both with method and checkedAt, and servedFromCache tells you whether the fact was freshly established or reused from a recent check of the same input. Store the lookupId against the case; past lookups remain listable from the API, scoped to your account, so the record can be retrieved later without re-running the check. For a review queue that shows analysts results as they land, streaming delivers the first platforms in well under a second.

Boundaries: what a digital footprint KYC check is not

It is not identity proofing, and our terms prohibit relying on it as proof that a person is who they claim to be. It is not a consumer report. It does not return names, photos, addresses or any profile content, and it never reports a platform as unregistered unless that platform confirmed it. Phone-number lookups are in beta with limited platform coverage and should be treated as supplementary. What it is: one verified, timestamped input to a risk-based onboarding decision, with free lookups to start and pricing on the pricing section. Teams scoring signups outside a regulated context should read the fraud prevention page instead.

Frequently asked questions

What is a digital footprint check in KYC?: A check of whether the email address, phone number or username an applicant supplied is registered with accounts on public platforms, and for how long it has demonstrably existed. It complements document and liveness checks, which prove a document is genuine but say nothing about whether the contact details have any history.
Does a digital footprint check count as identity verification under AML rules?: No. It is a corroborating signal, not identity proofing, and our terms say so explicitly. Use it to decide how much additional verification an applicant needs and to document the basis for that decision, not as the sole evidence that someone is who they claim to be.
Is checking an applicant’s email against social platforms GDPR-compliant?: It can be, and many regulated firms do it under the legal-obligation or legitimate-interest bases, but the lawful basis, any required assessment and the duty to inform applicants are yours. The API returns only whether an account exists, never its contents, which keeps the processing narrow.
Can I keep the result as part of the audit trail?: Yes. Every result carries the method and the exact time it was established, the response has a lookupId, and past lookups are listable from the API scoped to your account. That is enough to show a reviewer what was known at the moment the onboarding decision was taken.

Start free Try a lookup