Identity validation

Every persona that goes near a target gets validated first. The validation pipeline runs three independent checks; all three must pass before the profile is launchable.

1. Email reachability

We do an MX + SMTP-handshake probe. The mailbox must exist and the domain must accept mail. We don't actually send mail — the probe disconnects before DATA — but a target's signup flow needs to be able to deliver a confirmation link.

Common reasons for fail:

  • Disposable-mail domains (mailinator.com,tempmail.io, etc.) — we maintain a denylist shipped with the app.
  • Catch-all domains that respond 200 OK to every local-part. Common with self-hosted mail or some hosting providers. We treat catch-all as a yellow warning and let the launch proceed, but a serious abuse pipeline will recognise the domain.
  • Greylisted MX (initial 451 response). We retry after a 60-second delay; if still 451, we surface a warning.

2. Phone line type

We send the number to Twilio Lookup with type=carrier. The pipeline accepts:

  • mobile — landlines and VOIP fail.
  • NL country code unless the persona is explicitly cross-border.

Twilio Lookup occasionally misclassifies low-tier MVNO numbers as VOIP. If you're sure the number is a real mobile line on a real carrier (and your KvK-registered SIM bundle confirms this), override via the validation panel's Force-pass phone toggle. The override is logged in audit_events.

3. Payment-instrument plausibility

For payment instruments we run a BIN check — first six digits of the card map to an issuing bank, card-network, and country of issue. Validation passes if:

  • BIN exists in our table.
  • Country of issue matches the persona's stated country (or is a neighbouring SEPA country, with a yellow warning).
  • Card-network is one of: Visa, Mastercard, Maestro, Amex.

We do not hit the card network with a zero-dollar auth — that triggers fraud-model signals on the issuing side and looks bad. BIN-only is sufficient plausibility.

What the validation pipeline doesn't do

  • It doesn't probe the target's signup flow. The launch is the thing that does that. Validation is a pre-flight sanity check on the persona itself.
  • It doesn't check social-graph plausibility (does this persona "look real" online). That's the warmup orchestrator's job — see Quickstart §7.
  • It doesn't cache results. Re-validation hits the same probes again because phone-line classification can change (number ports, carrier swaps).

AUP click-through

The first time you click Validate identity on any profile after a new AUP version is published, you'll get an interstitial. Click through, the attestation is recorded against your user-id + AUP version, and you proceed. Subsequent validations under the same AUP version don't re-prompt.

Refusing the AUP click-through blocks identity upload. Read the AUP for the why.