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.

How does a digital footprint check fit an AML compliance programme?

A digital footprint check sits in the risk-assessment step of an AML compliance programme, not the identification step. It answers how much online history an applicant’s contact details actually have, which is what separates a real customer from a synthetic identity or a money mule opening an account with a freshly created address. The output is a set of timestamped facts with the method that established each one, so a compliance officer can show a reviewer what was known and when.

What is an identity check based on digital footprint data?

An identity check based on digital footprint data asks whether the identifiers a person gave you have a plausible history: which platforms the email address or phone number is registered on, whether it appears in breach records that predate the application, and whether it is mentioned anywhere on the public web. It corroborates identity rather than proving it, so it runs alongside document and liveness checks rather than replacing them.

Can a digital footprint check be used for email compliance screening?

Email compliance screening usually means establishing that an address is real, reachable and not disposable before it enters a regulated onboarding flow. A digital footprint check answers a stronger version of that question - not merely whether the address is syntactically valid, but whether anything is actually registered to it anywhere - while returning no message content and no profile data, which keeps the processing narrow enough for regulated use.

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 AML compliance and KYC 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 886+ 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 /v2/lookup?wait=true

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

Response (abridged) - an established footprint

{
  "lookupId": "c41d7f2b-...",
  "input": { "email": "a.okafor@example.com", "phone": null, "username": null, "ip": null },
  "risk": { "score": 0 },
  "footprint": {
    "platformsChecked": 887,
    "matches": 5,
    "socialMatches": 4,
    "derivedMatches": 0,
    "hits": ["google", "linkedin", "github", "spotify", "strava"],
    "servedFromCache": false,
    "results": [
      {
        "platform": "google",
        "registered": true,
        "method": "domain_derived",
        "icon": "https://.../google.svg",
        "checkedAt": "2026-10-03T10:02:41.310Z",
        "mailboxProvider": true,
        "identity": "email"
      },
      { "platform": "linkedin", "registered": true, "method": "public_api", "icon": "https://.../linkedin.svg", "checkedAt": "2026-10-03T10:02:41.512Z", "identity": "email" },
      { "platform": "github", "registered": true, "method": "public_api", "icon": "https://.../github.svg", "checkedAt": "2026-10-03T10:02:41.640Z", "identity": "email" },
      { "platform": "spotify", "registered": true, "method": "public_api", "icon": "https://.../spotify.svg", "checkedAt": "2026-10-03T10:02:41.688Z", "identity": "email" },
      { "platform": "strava", "registered": true, "method": "public_api", "icon": "https://.../strava.svg", "checkedAt": "2026-10-03T10:02:41.902Z", "identity": "email" }
    ],
    "breaches": [{ "name": "Canva", "date": "2019-05-24" }, { "name": "Dropbox", "date": "2012-07-01" }],
    "webMentions": [],
    "phoneReserved": null
  },
  "email": {
    "address": "a.okafor@example.com",
    "deliverable": true,
    "disposable": false,
    "freeProvider": true,
    "age": { "firstSeenAt": "2012-07-01", "ageDays": 5207, "source": "breach_records", "estimate": true },
    "risk": { "score": 0 }
  },
  "phone": null,
  "ip": null,
  "meta": { "tier": "standard", "modules": ["footprint:email", "email"], "instant": false, "footprintComplete": true, "deadlineMs": null, "platformsPending": 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 footprint.matches but not in footprint.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 footprint.breaches, summarised as email.age, 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. footprint.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. footprint.webMentions marked confirmed show the identifier appearing verbatim on public pages, and unconfirmed ones should be ignored for compliance purposes.

Where this sits in an AML compliance programme

A digital footprint check is a risk-assessment input, not a customer identification measure. It does not discharge any CIP or CDD obligation, and nothing here should be read as a claim that it does. What it does is tell a compliance team where to spend the expensive checks: an applicant whose email has been registered on a dozen platforms for years is a different risk from one whose address has no presence anywhere, even when both present a perfectly genuine document.

That distinction is the whole reason thin-footprint identities matter to AML teams. A synthetic identity and a mule account share a property that a document check cannot see: the contact details are new. See thin digital footprints for how to read that signal without over-reading it, and fraud prevention for the same data used at signup rather than at onboarding.

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 footprint.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. A phone number reaches the messaging apps that register by number and adds carrier, line type and a phone risk score. 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.
How does a digital footprint check fit an AML compliance programme?: A digital footprint check sits in the risk-assessment step of an AML compliance programme, not the identification step. It answers how much online history an applicant’s contact details actually have, which is what separates a real customer from a synthetic identity or a money mule opening an account with a freshly created address. The output is a set of timestamped facts with the method that established each one, so a compliance officer can show a reviewer what was known and when.
What is an identity check based on digital footprint data?: An identity check based on digital footprint data asks whether the identifiers a person gave you have a plausible history: which platforms the email address or phone number is registered on, whether it appears in breach records that predate the application, and whether it is mentioned anywhere on the public web. It corroborates identity rather than proving it, so it runs alongside document and liveness checks rather than replacing them.
Can a digital footprint check be used for email compliance screening?: Email compliance screening usually means establishing that an address is real, reachable and not disposable before it enters a regulated onboarding flow. A digital footprint check answers a stronger version of that question - not merely whether the address is syntactically valid, but whether anything is actually registered to it anywhere - while returning no message content and no profile data, which keeps the processing narrow enough for regulated use.
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