What is a money mule account?

A money mule account is a bank or payment account used to receive and forward the proceeds of crime, opened either by a recruited individual or in a stolen or synthetic identity. Recruited mules are the harder case: the person is real, the documents are genuine, and the account passes identity verification cleanly, so detection has to rest on something other than whether the identity checks out.

How does digital footprint data help detect mule accounts?

Mule recruitment is fast and disposable, and the contact details reflect that: an address created for the application, used for nothing else, registered on no platform and absent from every breach corpus. A single lookup checks that address against 888 platforms and returns what is registered. A genuine long-term customer almost always has a history somewhere; a freshly minted identifier has none.

Is a thin digital footprint proof of a mule account?

No, and treating it as proof would be a serious error. Thin footprints are common among people who are young, recently arrived in a country, privacy-conscious, or simply using a separate address for financial services. The signal belongs in a risk score or a routing rule that sends the case to enhanced due diligence - never in an automatic rejection.

Can this detect mule networks rather than individual accounts?

Not directly. This API answers questions about one identifier at a time and holds no cross-customer graph, so it cannot tell you that two applicants are linked. What it contributes to network detection is a per-applicant feature - registration breadth and earliest breach date - that your own graph or monitoring can cluster on alongside device, IP and transaction signals.

When in onboarding should the check run?

At application, before the account is funded, because the value is in the decision about how much verification to require. Every result carries the method and timestamp that established it and the response carries a lookup id, so the check also becomes part of the audit trail showing what was known when the account was approved.

Money mule account detection at onboarding

A money mule account is opened by a real person with genuine documents, which is exactly why document and liveness checks pass it. What mule accounts share is disposable contact details: an email address or phone number created for the recruitment and used nowhere else. A digital footprint check surfaces that in one request, before the account is funded.

Why document checks do not catch recruited mules

A recruited mule is a real person presenting their own genuine passport. Every control aimed at proving that an identity exists and matches the applicant passes, because the identity does exist and does match. The fraud is not in who they are - it is in what the account will be used for, and identity verification is structurally unable to see that.

What does differ is the periphery. Mule recruitment happens over days through messaging apps and job adverts, and the contact details supplied are created for it: a new address, sometimes a new number, used for this account and nothing else. That is observable at application time, and it is observable cheaply.

What the check returns

Send the address the applicant supplied. One request checks every platform that accepts an email address and returns the ones that answered, plus breach history and public web mentions.

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": "recruit.4471@example.com"}'

200 OK - a footprint with nothing in it

{
  "query": "recruit.4471@example.com",
  "matches": 0,
  "socialMatches": 0,
  "platformsChecked": 888,
  "results": [],
  "breaches": [],
  "webMentions": []
}

// Nothing registered, no breach history, no public mentions.
// Not proof of anything - but a real applicant rarely looks like this.

Read the empties carefully, because they mean different things. results: [] means every platform that answered said no. breaches: [] means the breach source was queried and found nothing - whereas null would mean no breach source is configured and the question was never asked. Platforms that blocked the check or timed out are omitted from results entirely rather than counted as negatives, so an empty array is a genuine set of confirmed absences and not a tally of failures.

Turning it into a decision

Two features carry most of the value. Registration breadth is the count of platforms the identifier is confirmed on - expensive to fabricate at scale, because a mule network running a hundred identities would need to build a hundred histories. Earliest breach date is a demonstrable lower bound on how long the address has existed, which is difficult to fake because it is a dated record rather than an assertion. See the email age guide for how to derive it.

Feed both into the risk score you already run, then route rather than reject: a thin result should raise the applicant into enhanced due diligence, not decline them. That is a deliberate constraint, not a hedge - the innocent explanations for a thin footprint fall disproportionately on younger and recently arrived customers, and a rule that declines on thinness alone will systematically exclude them. Reading a thin footprint covers where the line sits.

Limits worth stating plainly

This is one signal among several, and it does not see the ones that catch mules after the fact. There is no device intelligence, no IP reputation, no transaction monitoring and no cross-customer graph here - a mule network sharing devices or funding patterns is visible to your monitoring stack, not to a registration sweep. What this adds is a pre-funding feature the rest of that stack does not have, from the only data a fraudster cannot create retroactively.

It is also not identity verification and does not discharge any customer due diligence obligation - see AML compliance and KYC for where it does and does not sit in a compliance programme.

Pricing

15 free lookups to start, no card required, then $0.06 per lookup pay as you go or Growth at $39 a month for 1,000 lookups. Full detail on the pricing page.

Frequently asked questions

What is a money mule account?: A money mule account is a bank or payment account used to receive and forward the proceeds of crime, opened either by a recruited individual or in a stolen or synthetic identity. Recruited mules are the harder case: the person is real, the documents are genuine, and the account passes identity verification cleanly, so detection has to rest on something other than whether the identity checks out.
How does digital footprint data help detect mule accounts?: Mule recruitment is fast and disposable, and the contact details reflect that: an address created for the application, used for nothing else, registered on no platform and absent from every breach corpus. A single lookup checks that address against 888 platforms and returns what is registered. A genuine long-term customer almost always has a history somewhere; a freshly minted identifier has none.
Is a thin digital footprint proof of a mule account?: No, and treating it as proof would be a serious error. Thin footprints are common among people who are young, recently arrived in a country, privacy-conscious, or simply using a separate address for financial services. The signal belongs in a risk score or a routing rule that sends the case to enhanced due diligence - never in an automatic rejection.
Can this detect mule networks rather than individual accounts?: Not directly. This API answers questions about one identifier at a time and holds no cross-customer graph, so it cannot tell you that two applicants are linked. What it contributes to network detection is a per-applicant feature - registration breadth and earliest breach date - that your own graph or monitoring can cluster on alongside device, IP and transaction signals.
When in onboarding should the check run?: At application, before the account is funded, because the value is in the decision about how much verification to require. Every result carries the method and timestamp that established it and the response carries a lookup id, so the check also becomes part of the audit trail showing what was known when the account was approved.

Start free with 15 lookups Try a lookup