Email & phone verification

Introduction

Every applicant hands over an email address and a phone number before anything else. Until now, those two values went straight into an identity check without ever being examined. An applicant using a throwaway mailbox, a number that is not live, or contact details already seen on other sign-ups looked exactly like a legitimate one until the paid identity sources came back.

Email & Phone Verification screens those contact details first: deliverability and validity, how long the address and its domain have existed, how often they have been searched recently and by how many organisations, the network behind the number, and two aggregate risk scores built on how the same details recur across applications and institutions.

The results appear as dedicated sections on the eKYC check, above the identity sources. There is no separate check to launch.

How it works

Email & Phone Verification is part of the eKYC check and runs in the same single request to the verification provider. Like eKYC itself, it is an internal check: no end-user interaction, and the result comes back instantly.

Screened before the paid sources: The contact details are examined first. When your verification profile is configured for it, a failure on the email address or the phone number stops the identity sources from running at all. They are never queried and never billed.
Four sections on the check page: The signals are grouped into Email validation, Email verification signals, Mobile validation and Fraud risk.
Every row is evidenced: Each row names the provider result codes behind it, and a page-level Result codes list collects them all, so an analyst can justify a decision line by line.
The page adapts to what came back: A section appears only when the provider returned it. There is no empty state and no placeholder.
Signals, not values: The check shows signals about the email address and the phone number. It never stores or displays the values themselves.
Covered by the interpretation: The plain-language Interpretation card at the top of the check summarises the contact-detail signals alongside the identity result.

What gets verified

Email validation

Row	What it tells you
Address valid	Whether the address is a valid, deliverable email address.
Bounce risk	How likely a message to this address is to bounce back, for example `low`.

Email verification signals

Row	What it tells you
Fraud risk	A risk level and the score band behind it, for example `Review` in the 601-799 band.
Mailbox existence	Reported only when the domain exists but the mailbox does not. The provider never confirms that a mailbox is real, so this row either reads `Does not exist` or is absent.
Email first seen	The date the address was first observed, for example February 27, 2015. A recently created address on an applicant claiming a long history is worth a look.
Domain first seen	The date the domain behind the address was first observed.
Domain country	The country the email domain belongs to.
Recent usage	How often the address has been searched recently and by how many organisations, for example searched 1 time in the last 7 days, by 1 organisation. This row carries no value of its own: it reports what the provider returned.

Mobile validation

Row	What it tells you
Number valid	Whether the number is valid and reachable.
Line type	The kind of line behind the number, for example `Mobile`.
Current network	The operator and country currently carrying the number, for example `SFR` in `FRA`.
Original network	The operator and country the number was originally issued on. A difference between the two is a sign the number has been ported.

Fraud risk

Row	What it tells you
Trust score	The band of the trust score, for example `Low Risk`. It is built on how these contact details recur across applications and institutions.
Fraud score	The band of the aggregate fraud score.
Rules triggered	A count of the rules that fired, by family: velocity, combination, anomaly, and Trust Network match. When none fire, the row reads `No rules triggered`.
Score contributors	The labels that fed the fraud score, for example `Email - Valid, Mobile - Number is Valid`.

Velocity rules fire on how fast a detail reappears, combination rules on the same pairing seen across several applications (the same mobile number and email address together, for instance), anomaly rules on something unusual about the detail itself, and network match rules on a hit in the shared Trust Network.

Reading the results

Each row carries a status indicator, the value, and the provider result codes that produced it. A section header takes the status of its most severe row, and sections that carry a warning or an error are expanded by default, so what needs attention is what you see first.

Each of the four sections is in one of three states:

State	What you see
Returned	The section renders with its rows, its indicators, and the result codes behind each one.
Not carried out	The provider received the item but could not run it because mandatory information was missing. The section names the missing fields and offers Complete information and Relaunch check.
Absent	The section does not appear at all. Nothing was returned for it, so nothing is shown.

The email address and the phone number themselves are never displayed on the check, and the check does not store them. What you see are signals about them.

Working with the eKYC identity check

The contact-detail signals do not change the status of the check by themselves. The eKYC status still comes from the provider's profile-level decision, mapped to Approved, Need Review or Rejected exactly as described on the eKYC page. What changes is that the decision now accounts for the contact details as well, and that your identity sources can be spared entirely when the contact details fail.

Your review workflow is unchanged: the identity sources, the field-level match statuses and the approve and reject actions all work as they did, with the contact-detail sections sitting above them.

Launching email & phone verification

You launch it by launching an eKYC check, from any individual profile page. There is nothing extra to select and no additional configuration at launch time.

Fill in the individual's email address and phone number before launching. The eKYC check requires first name, last name, date of birth and address; it runs without contact details, but the email and mobile sections can only report on values you provide.

Using templates

Templates launch eKYC checks automatically on the individuals that require them, for example beneficial owners and legal representatives. The contact-detail sections come back on those checks exactly as on a manual one.

API

Email & Phone Verification uses the same endpoints as the eKYC check: create a check, retrieve it, and review it. The signals are returned on the check data, grouped the same way as on the page: trust, fraud score, email verification, email validation and mobile validation. Every field is optional, so a field absent from the response is a field the provider did not return. The existing check webhook events cover it, with no new event to subscribe to. You can learn more in our API documentation.

Provider

GBG

Email & Phone Verification is delivered by GBG, through the same ID3 Global platform that already powers the eKYC check. There is nothing new to integrate on your side, and the check carries Powered by GBG in the console.

The email and mobile signals come from GBG's international validation products, and the trust signals from a consortium network shared across GBG's member organisations, which is what makes a contact detail reused across institutions visible at all.

Coverage

Email and mobile validation are international products and are not restricted to the countries where identity verification is available. Which of them run on a given check is decided by the verification profile used for that country, so effective coverage depends on how your profiles are configured.