Fintech onboarding: contactability and risk signals

In fintech and lending onboarding, phone and e-mail checks confirm contactability: that the applicant's mobile is assigned and reachable and the mailbox exists. They also add risk signals such as line type, porting and, where enabled, spam reports. This is not identity verification and not KYC. It sits beside your regulated checks and helps stop fake applications early.

#What is contactability, and why does it matter?

A financial account depends on reaching the customer. You send one-time passcodes to their phone, statements and notices to their e-mail, and some messages are legally required. If the contact details given at onboarding don't work, problems appear later, when they're harder to fix:

• Passcodes that never arrive. An applicant on an unreachable or unassigned number can't finish sign-in or confirm a payment, and your support team takes the call.
• Notices that bounce. A mailbox that doesn't exist means account notices and statements go nowhere. You then have to find another way to meet your communication duties.
• Fake and synthetic applications. Applications built on made-up details often use numbers and addresses that don't hold up: an unassigned number, a mailbox that doesn't exist, a line type that doesn't fit the rest of the application.
• Account takeover later on. A number that was ported to another network since onboarding, when your records don't expect it, is a reason for an extra step before a sensitive change.

Checking contact details at onboarding gives you a clean starting record and early warning signals, without asking the applicant for anything more.

#What this is not: identity verification or KYC

These checks are not identity verification and are not KYC. They describe a phone number or an e-mail address. They don't tell you who holds the number, and they never return names, photos, addresses or profiles. A reachable number with a live mailbox can still belong to a fraudster, and a genuine applicant can have an unreachable phone on the day they apply.

Run your regulated customer due diligence (identity documents, sanctions and PEP screening, AML monitoring) with the providers and processes your regulator expects. Use contactability checks alongside them, not instead of them. Our acceptable use policy says the same: results are signals at a point in time, not proof of identity or ownership, and they can't replace KYC or AML checks.

#How does it work?

1. Normalize the number. Parse it to E.164 using the applicant's country. Unparseable input comes back as number_status: invalid_number, free, so the form can ask for a correction.
2. Check at submission. Call POST /v1/lookup with the number and e-mail and checks: ["carrier", "hlr", "email"]. Add spam if it's enabled for your account.
3. Score contactability. Is the mobile reachable, and does the mailbox exist? If not, ask the applicant to correct or confirm the detail before you continue.
4. Weigh risk signals. Combine line type, porting and spam reports with your own device, session and application data.
5. Step up, don't auto-decline. Doubtful combinations go to extra verification (confirm the e-mail, a call-back) or to manual review.
6. Store the baseline. Keep mcc_mnc, line_type and checked_at with the account. Later, compare a fresh MNP lookup with this baseline before a password reset, a new payee or a payout.
7. Keep results out of credit decisions. Don't feed them into creditworthiness, pricing or limit decisions.

#Which checks should you use?

The HLR lookup already includes the porting flag and current network, so you don't need mnp at onboarding if you run hlr. Use mnp for the cheaper re-checks later.

#What happens after onboarding?

Contact details don't stay right forever. Customers change numbers, and attackers who take over an account try to change where passcodes and notices go. Three moments deserve a fresh check:

• A new phone number or e-mail on the account. Check the new details the same way as at onboarding, and confirm the change through the old ones. See account security.
• Sensitive actions: a password reset to a new destination, a new payee, a payout to a new account. A cheap MNP lookup compared with the stored baseline shows whether the number moved to another network in the meantime.
• Failed contact. When passcodes stop arriving or notices bounce, re-check before assuming the customer is at fault.

Use max_age: 0 for these checks, so the answer isn't served from an older cache entry.

#Example request

With a test key, +447700900006 is a reachable mobile that was ported, and [email protected] has a mailbox. See test values.

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym" \
  -H "Content-Type: application/json" \
  -d '{"numbers":["+447700900006"],"emails":["[email protected]"],"checks":["carrier","hlr","email"]}'

// npm install mobilevalidate · Node.js 20+ · save as check.mjs and run: node check.mjs
import { MobileValidate } from "mobilevalidate";

// Omit apiKey to read MOBILEVALIDATE_API_KEY from the environment.
const mv = new MobileValidate({ apiKey: "mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym" });
const { data, error } = await mv.lookup({
  numbers: ["+447700900006"],
  emails: ["[email protected]"],
  checks: ["carrier", "hlr", "email"],
});
if (error) console.error(error.code, error.message);
else console.dir(data.results, { depth: null });

// Node.js 18+, Deno, Bun or the browser console (ES module: save as .mjs or use "type": "module").
const res = await fetch("https://api.mobilevalidate.com/v1/lookup", {
  method: "POST",
  headers: {
    Authorization: "Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    numbers: ["+447700900006"],
    emails: ["[email protected]"],
    checks: ["carrier", "hlr", "email"],
  }),
});
console.log(res.status, res.headers.get("x-request-id"));
console.dir(await res.json(), { depth: null });

# pip install mobilevalidate-sdk
from mobilevalidate import MobileValidate

# Omit api_key to read MOBILEVALIDATE_API_KEY from the environment.
mv = MobileValidate(api_key="mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym")
result = mv.lookup(
    numbers=["+447700900006"],
    emails=["[email protected]"],
    checks=["carrier", "hlr", "email"],
)
print(result)

<?php
$ch = curl_init('https://api.mobilevalidate.com/v1/lookup');
curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [
        'Authorization: Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym',
        'Content-Type: application/json',
    ],
    CURLOPT_POSTFIELDS => json_encode([
        'numbers' => ['+447700900006'],
        'emails' => ['[email protected]'],
        'checks' => ['carrier', 'hlr', 'email'],
    ]),
]);
$response = curl_exec($ch);
echo curl_getinfo($ch, CURLINFO_RESPONSE_CODE), PHP_EOL, $response, PHP_EOL;

package main

import (
	"fmt"
	"io"
	"net/http"
	"strings"
)

func main() {
	body := strings.NewReader(`{"numbers":["+447700900006"],"emails":["[email protected]"],"checks":["carrier","hlr","email"]}`)
	req, err := http.NewRequest("POST", "https://api.mobilevalidate.com/v1/lookup", body)
	if err != nil {
		panic(err)
	}
	req.Header.Set("Authorization", "Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym")
	req.Header.Set("Content-Type", "application/json")
	res, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	defer res.Body.Close()
	out, _ := io.ReadAll(res.Body)
	fmt.Println(res.Status, string(out))
}

require "net/http"
require "json"

uri = URI("https://api.mobilevalidate.com/v1/lookup")
req = Net::HTTP::Post.new(uri)
req["Authorization"] = "Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym"
req["Content-Type"] = "application/json"
req.body = JSON.generate({
  "numbers" => ["+447700900006"],
  "emails" => ["[email protected]"],
  "checks" => ["carrier", "hlr", "email"]
})

res = Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| http.request(req) }
puts res.code, res.body

Response (excerpt, test mode: the checks of the phone row, then of the e-mail row):

[
  {
    "network.carrier": {
      "service": "network.carrier", "status": "completed", "registered": true,
      "attributes": {"line_type": "mobile", "carrier": "Test Carrier", "country": "GB"},
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-28T22:40:26.967Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    },
    "number.hlr": {
      "service": "number.hlr", "status": "completed", "registered": true,
      "attributes": {"status": "reachable", "ported": true, "roaming": false, "network": "Test Mobile Two", "mcc_mnc": "23410", "country": "GB"},
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-28T22:40:26.967Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    }
  },
  {
    "email.valid": {
      "service": "email.valid", "status": "completed", "registered": true, "attributes": null,
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-28T22:40:26.967Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    }
  }
]

A reachable mobile and a live mailbox: the applicant is contactable. The number was ported at some point, which on its own is normal, since people switch operators all the time. Store mcc_mnc: 23410 as the baseline, so a later change stands out.

#What should you do with each result?

#How much does it cost?

The HLR lookup is $0.005 per number and the MNP lookup $0.001 per number. The carrier lookup, the mailbox check and spam reputation are priced per check; see pricing. You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate). Onboarding runs a few checks per applicant, and repeat checks of the same number inside the freshness window come from your account's cache for free.

#What about consent and compliance?

Tell applicants in your privacy notice that you verify contact details to prevent fraud and to be able to reach them. Check only details the applicant gave you. Results are signals at a point in time, so store checked_at with every decision.

Keep three boundaries. First, this is not KYC; run your regulated checks separately. Second, don't use results for eligibility decisions about credit or insurance, or as a consumer report; the acceptable use policy forbids it. Third, there are no reverse lookups: checks never tell you who holds a number. Numbers from sanctioned countries and regions are never checked. People can object through the opt-out form.

#What are common mistakes?

• Calling it identity verification. A reachable number is not a verified person. Keep your KYC separate.
• Auto-declining on one signal. VoIP numbers, ported numbers and unknowns are common among genuine applicants. Step up instead.
• Letting results leak into credit models. Keep them in fraud and contactability logic only.
• Checking once and never again. Store a baseline and re-check before sensitive account changes.
• Treating no_reports as safe. It means no reports are held, nothing more.
• Storing full responses. Keep the decision, the baseline fields and checked_at.