Detecting Impersonation with Identity Data Enrichment

A suspicious caller does not always sound suspicious.

They may know your name. They may know the company you work with. They may even know an account number, address, supplier name, or another detail that appears difficult for a stranger to know.

But knowing information about someone is very different from being that person.

This is where identity data enrichment can become useful.

Instead of asking only, “Does this caller know something about us?”, a better question is:

Do the identity signals behind this person actually connect to each other?

Impersonation is becoming a data problem

Consider a simple situation.

Someone calls a small business and says:

“My name is Daniel Ortiz. I’m calling from your equipment service company. We need to update the payment details for your next invoice.”

The caller provides:

• a full name
• a phone number
• an email address
• a company name
• some information about the existing business relationship

Individually, every piece looks reasonable.

The problem appears when those signals are checked together.

For example:

• the phone number may be associated with another person
• the email may have no visible connection to the claimed company
• the name may appear with a different geographic history
• digital profiles connected with the contact information may contradict the story
• several independent data sources may point toward a different identity

One mismatch does not automatically mean fraud.

Several unrelated mismatches, however, can justify additional verification before money, access or sensitive information changes hands.

Think in terms of an identity profile

A useful enrichment workflow does not ask one database:

“Is Daniel Ortiz legitimate?”

Instead, it collects multiple signals and builds a profile.

A simplified result could look like this:

Input
  name: Daniel Ortiz
  phone: +1 xxx xxx xxxx
  email: daniel@example.com

Enrichment
  phone_name:
    Daniel M. Ortega
    confidence: medium

  email_name:
    Daniel Ortiz
    confidence: medium

  email_domain:
    public email provider

  location:
    Nevada

  claimed_location:
    Arizona

  company_connection:
    not confirmed

  digital_identity:
    partial match

Result
  identity_consistency: low
  conflicts: 3
  recommended_action: verify through independent channel

The important part is not any single field.

It is the relationship between the fields.

This is one of the central ideas behind multi-source data enrichment.

Phone numbers and emails are identifiers, not proof

Phone numbers and email addresses are extremely useful starting points.

They can help discover connections between:

phone → person → email → social identity → location → other digital signals

But they should not automatically be treated as verified identity.

Numbers get reassigned.

People use multiple email addresses.

Business employees use personal phones.

Public data can be incomplete.

Some sources become outdated.

That means enrichment systems should preserve uncertainty rather than forcing every result into a simple “match” or “no match.”

A stronger model might return:

NAME
Daniel Ortiz
Sources: 3
Confidence: 82%

PHONE CONNECTION
Possible match
Sources: 2
Confidence: 61%

EMAIL CONNECTION
Strong match
Sources: 4
Confidence: 88%

COMPANY CONNECTION
Not confirmed

LOCATION
Conflict detected

Now the person reviewing the interaction can understand why additional verification may be necessary.

Cross-source agreement is more useful than one strong-looking result

Imagine three different enrichment sources independently connect the same phone number and email address to the same person.

That agreement has meaning.

Now imagine another situation:

• Source A connects the phone to Daniel Ortiz.
• Source B connects it to Michael Reed.
• Source C has no name.
• The email points toward Daniel Ortiz.
• The claimed company cannot be connected to either identity.

A good system should not hide this conflict.

It should expose it.

This is important because one of the biggest mistakes in identity enrichment is silently selecting the first result that looks correct.

The application should instead keep the evidence and allow the decision layer to consider:

• source agreement
• conflicts
• timestamps
• match strength
• identifier quality
• missing information

What should happen after a conflict?

Enrichment should normally influence a decision, not make the entire decision by itself.

For example:

Strong cross-source match
→ continue normal process

Minor identity conflict
→ request additional verification

Multiple independent conflicts
→ manual review

Payment or account change + identity conflict
→ verify using previously known contact channel

The last point is particularly important.

If someone unexpectedly asks to change a bank account, obtain a one-time code, receive remote access, collect equipment or gain physical access, identity enrichment should complement an independent verification process.

Do not use the new phone number or email supplied by the person as the only way of verifying them.

What can go wrong with automated enrichment?

Identity intelligence is useful precisely because data is imperfect.

That also means the system must be designed for imperfect results.

Treating a common name as a strong identifier

A name such as Daniel Ortiz may match many unrelated people.

Name + city is still often insufficient for confidently linking records.

Ignoring stale data

A phone number association from several years ago should not necessarily receive the same weight as a recent observation.

Overwriting conflicts

If two sources return different names, storing only one removes important evidence.

Keep both results and their sources.

Turning “no data” into “bad identity”

Lack of information does not mean the person is fraudulent.

It means the system has insufficient evidence.

Making enrichment the final authority

The purpose of enrichment is to provide additional intelligence for a decision.

It should not replace independent verification when the requested action carries significant risk.

A simple verification checklist

When building an identity consistency workflow around an unexpected interaction, check:

• Does the phone number connect with the claimed identity?
• Does the email connect with the same person?
• Does the email domain make sense for the claimed organization?
• Do multiple independent sources agree?
• Are there conflicting names or locations?
• How recent is the supporting data?
• Is the company relationship supported by other signals?
• Is the person asking for money, credentials, access or changed instructions?
• Can the request be verified using a previously known contact channel?

The objective is not to find one magical data source.

It is to see whether multiple independent pieces of information tell the same story.

From identity enrichment to practical background profiling

For a practical small-business example, TellData recently published a guide explaining how to detect impersonation in service calls.

It covers scenarios such as callers pretending to be suppliers, technicians, account representatives or service companies, and explains why independently checking the story is more reliable than trusting caller ID or information the caller already knows.

Read the TellData article: How to Detect Impersonation in Service Calls

For cases where a U.S. small business needs a broader background profile of an individual, TellData also provides a web portal that brings identity and contact consistency information together with other available background information. The underlying report should still be treated as an intelligence signal rather than absolute proof; the TellData article itself notes that public records may be incomplete, old, or connected to people with similar names.

TellData and its background profiling web portal are currently available only in the United States.

Register for the TellData background profiling portal — USA only

The bigger lesson

Impersonation detection is not really about finding one suspicious phone number.

It is an identity-resolution problem.

A person presents a name, phone, email, company, location or digital identity. The verification layer collects independent signals behind those identifiers and asks whether they belong together.

When they agree, confidence increases.

When they conflict, the system should show the conflict.

And when the requested action is sensitive, the safest next step is often very simple:

pause the transaction, verify through an independent channel, and then act.

That combination of multi-source enrichment and sensible decision logic is much stronger than trusting any single piece of identity data.