Table of Contents
Modern platforms make decisions every day with incomplete information.
A user signs up with a phone number you’ve never seen. An email looks valid, but you don’t know whether it’s newly created, widely reused, or linked to suspicious activity. A name appears in a payout request, but you can’t quickly connect it to any public footprint.
That gap is where identity enrichment helps: you start with one identifier (like a phone number, email, or name) and retrieve additional signals that provide context for trust, risk, and investigation workflows.
IRBIS is built for this as a cloud-native SaaS platform that supports both:
a web portal for interactive investigation and reporting, and
a developer API for automation and higher-volume usage, using modular lookup engines.
What “identity enrichment” means in practice
Identity enrichment isn’t one magic answer. It’s a set of signals that help you decide what to do next.
Depending on the lookup type and plan, results may include:
Identity signals: names/aliases, linked identifiers, profile references
Digital footprint signals: associated platforms and public presence hints
Risk/trust context: suspicious patterns, exposure indicators, and where applicable, watchlist/PEP screening hits
Structured report sections suitable for compliance or investigation workflows
A key principle: results vary by identifier and region, and not every lookup returns the same depth.
The three most common enrichment entry points
1) Phone lookup
A phone number is often the strongest “starting key” because it’s used for onboarding, MFA, support, and payouts.
A phone-based enrichment flow typically aims to answer:
Is this phone linked to other identifiers (names/emails/usernames) where available?
Does it have public footprint hints that match the user story?
Are there exposure/breach indicators associated with it (where available)?
IRBIS may include Phone Lookup / Reverse Phone Lookup as part of its catalog.
2) Email lookup and validation
Emails are universal but easy to create in bulk, so context matters.
An email enrichment flow typically helps you:
validate the email (where available), and
connect it to additional signals (plan-dependent).
IRBIS may include Email Lookup and Email validation.
3) Name search (Name WebScan)
Names are messy: transliterations, aliases, duplicate people, and partial matches are common.
Name-based enrichment is usually used for:
compliance and investigation support,
manual review workflows, and
joining “weak” identifiers to public footprint hints.
IRBIS may include Name Search / Name WebScan.
How to think about “modules” (and why it matters)
In IRBIS, a lookup is a query against a specific enrichment module (phone, email, name, social discovery, etc.). Each module is designed to start from a particular identifier type and return the most relevant signals it can.
The catalog evolves, but public-facing references commonly include:
Phone Lookup / Reverse Phone Lookup
Email Lookup / Email validation
BreachScan / exposed information checks
Name Search / Name WebScan
Social profile discovery
Face WebScan / face recognition
KYC & watchlists screening
Court / criminal records
IP geolocation and validators
Web scraper / leads search
AI sentiment analysis
Psychological Portrait (AI-based behavioral summary using public signals where available)
When you build a product integration, this modular structure is useful because you can start small (one module), measure impact, and expand.
A practical enrichment workflow for product teams
Here’s a clean way to plug enrichment into a real platform without overcomplicating it.
Step 1: Pick one “decision moment”
Good starting points:
Signup / account creation
First purchase
Payout / withdrawal
High-risk events (password reset, device change, sudden location change, support escalations)
Start with one event and one identifier type.
Step 2: Define outcomes, not just data
Before integrating any API, decide what you’ll do with results:
Auto-approve (low risk)
Step-up verification (ask for more proof)
Manual review
Block / restrict (high risk)
This keeps the integration measurable.
Step 3: Run a lookup and store “signals” safely
Typical implementation pattern:
send a phone/email/name to the lookup module
receive structured enrichment signals (plan-dependent)
store only what you need for your decisioning and audit trail
Step 4: Iterate
Once you can answer “did this reduce fraud or speed up reviews?”, you can add:
another identifier type (phone + email), or
another module (exposure checks, watchlists where applicable)
Portal vs API: when to use which
IRBIS is designed to support both interactive and automated workflows:
Use the portal when analysts need to investigate, compare results, and export reports.
Use the API when you want enrichment inside your product flow (onboarding, payments, trust & safety automation, higher-volume checks).
A common path is:
test manually in the portal,
confirm the signals are useful,
generate an API key in the portal,
integrate the lookup into production.
Credits and usage (what teams should plan for)
IRBIS plans use a credit/quota model.
On monthly plans, credits follow the subscription cycle; unused credits may expire per package rules.
On prepaid (Pay As You Go), credits can be valid for a fixed time window (per pricing rules in the portal/pricing page).
When you implement enrichment in a product flow, design for:
monitoring consumption per event type (signup vs payout, etc.)
graceful fallbacks (if a lookup returns limited data or is unavailable)
Responsible use
Identity enrichment is most effective when you use it to reduce risk and improve user safety, not to overreach.
Good practices:
collect and enrich only what you’re allowed to use
treat enrichment as signals, not absolute truth
keep decisions explainable (especially for compliance workflows)
Next steps
If you want to implement an enrichment layer with IRBIS, start small:
choose one decision moment (e.g., payout),
start with one identifier (phone),
evaluate whether the signals reduce review time or catch suspicious patterns,
then expand to email and name-based checks as needed (plan-dependent).
