Table of Contents
A phone number feels stable.
It looks personal.
It looks unique.
It looks tied to one individual.
But in reality, phone numbers are recycled all the time.
For background screening platforms, this creates a silent risk:
You may enrich the right number — but connect it to the wrong person.
This is not a data quality issue.
It’s a workflow design issue.
Let’s break it down.
Why Phone Numbers Get Recycled
Telecom providers reassign inactive numbers.
Common scenarios:
A user stops paying and the number returns to the carrier
A prepaid SIM is abandoned
A number is inactive for 30–90 days
A corporate number is reassigned internally
The new owner inherits the number — but not the history.
Enrichment APIs may still surface digital traces associated with the previous owner.
If your screening logic treats phone enrichment as strong identity proof, you create risk.
How Recycled Numbers Create False Flags
In screening workflows, phone enrichment is often used to:
Add digital footprint context
Support identity confidence
Detect inconsistencies
Route cases for review
The issue happens when:
Phone lookup returns historical exposure
That exposure belongs to a previous owner
Your system escalates the case automatically
Now you’ve created a false positive — not because the data was wrong, but because the identifier changed hands.
This is common in:
Tenant screening
Gig platform onboarding
Marketplace seller checks
Vendor onboarding
Especially when users rely on prepaid or temporary numbers.
Phone Numbers Are Volatile Identifiers
In enrichment design, identifiers have different stability levels.
Phone numbers are:
Reassignable
Region-dependent
Often short lifecycle
Frequently used in fraud attempts
Compared to:
Long-term email addresses
Verified government IDs
Internal customer history
Treating them equally creates over-escalation.
How to Design Around This Risk
You don’t need to stop enriching phones.
You need guardrails.
1️⃣ Don’t Escalate Based on Phone Alone
Phone lookup should be one data point.
Escalation should require:
Consistency with email
Alignment with name
Matching geography
Recent activity signals
If phone is the only weak signal — route to Yellow, not Red.
2️⃣ Add Freshness Weighting
Old exposure tied to a phone number should not trigger hard review.
Consider:
Timestamp of activity
Recency of linked data
Whether signals are ongoing or historical
Stale signals should lower confidence.
3️⃣ Use Async Enrichment Correctly
If your enrichment pipeline is asynchronous:
POST lookup → receive numeric id with status “progress”
Poll via GET /api/request-monitor/api-usage/{id}?key=…
Normalize before decision
Avoid making routing decisions before enrichment completes.
Also note:
Calling lookups too frequently (within ~30 seconds) may trigger “Insufficient enrichment timeout.”
Design polling with backoff.
4️⃣ Cache With TTL
Phone lookups are expensive and volatile.
Use a cache key like:
tenant_id + phone_normalized
Suggested TTL:
7–30 days depending on workflow risk.
If cached and recent → reuse.
If stale → re-enrich.
Check credits regularly via:
GET /api/request-monitor/credit-stat?key=…
This protects margin and stability.
5️⃣ Log the Right Things for Audit
If a case is escalated due to phone enrichment, store:
lookupId used
request ID
timestamp
enrichment summary
reason code (e.g., “phone exposure – historical”)
When a client asks “why was this flagged?” you need clarity.
Audit trail is part of screening quality.
Mistakes to Avoid
Mistake: Treat phone as identity proof
Fix: Treat phone as context
Mistake: Escalate from single identifier
Fix: Require cross-identifier consistency
Mistake: Ignore timestamp
Fix: Weight by freshness
Mistake: Run lookups too fast
Fix: Respect timeout windows and polling intervals
Simple Checklist
Treat phone numbers as volatile identifiers
Require consistency with at least one other identifier
Weight signals by freshness
Implement async lookup + polling correctly
Cache with TTL
Store lookup IDs + reason codes
Question
Have you seen cases where phone-based enrichment created unnecessary review load?
Resources
Quickstart (15 minutes):
https://espysys.com/irbis-api-quickstart-15-min/
Async Enrichment Tutorial:
https://espysys.com/api-tutorial/
API Documentation:
https://api-docs.espysys.com/