PII Validation

Overview

This step cross-checks provided PII (name, address, phone number) against authoritative mobile carrier records and identity databases, and layers that with an assessment of phone line risk. A match establishes that the provided identity is real and that the phone number belongs to that person.

Level of Assurance

Medium — carrier-corroborated PII. Increases to Medium-High when paired with SMS Link possession check.

User Friction Level

Low — PII form only. Most users complete in seconds.

End User Requirements

Mobile phone line registered in the user's name; current name, address, and phone number.

Speed

Real-time (seconds)

Supported Countries

Standard: US, UK, CA. Extended coverage available — see International MobileMatch for full country list.

Use Cases & Fraud Prevention

• Account onboarding where phone possession is a strong identity signal.
• CIP compliance — carrier-corroborated PII meets identity proofing requirements.
• Step-up when session risk triggers additional scrutiny.
• Mitigates: synthetic identity fraud (phone-to-PII mismatch flags fabricated identities), account takeover (carrier-level data is not easily spoofed), stolen identity (PII must correlate across multiple authoritative sources).

How It Works

The user submits their name, address, and phone number. The system cross-references this PII simultaneously against mobile carrier records and an authoritative identity database. A correlation must be established between the provided identity and the phone number. Phone line risk checks run in parallel — flagging inactive lines, landlines, or lines with a recent SIM port.

All risk assertions must pass, and at least one PII correlation pathway must succeed for the step to proceed.

Configuration Options

Template Variations

• PII Validation → SMS Link possession check (default — recommended)
• PII Validation only (approve on PII match alone, lower assurance)
• PII Validation + SSN collection (optional field, improves match rate for thin-record users)

Optional Add-ons

• SIM Swap checker — flags recent SIM port on this step's API key before PII is processed
• Recycled Number / Number Deactivation — flags recently recycled or inactive numbers
• Email Risk on the preceding Session Risk step — early filter before PII is collected

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. PII fields are rendered in the hosted UI — no field-level integration required.

Step-by-step Setup

• Navigate to the Workflow page in the Admin Console and deploy a workflow that includes PII Validation.
• Optional: enable Login Hint to prefill PII fields from your existing directory.
• Optional: add scope=openid+country.US to the /authorize request to pre-set dial code and address format.

Integration: ID Dataweb API

PII Validation is the second /slverify call in a typical flow — preceded by Session Risk (which returns the forwardApiKey used as the PII Validation step key). On success, PII Validation returns another forwardApiKey for the next step (typically SMS Link).

API Prerequisites

sequenceDiagram
    participant App as Your Application
    participant IDW as ID Dataweb API

    Note over App,IDW: Session Risk step runs first → returns forwardApiKey = PII Validation key

    App->>IDW: POST /slverify (PII Validation key + name, address, phone)
    IDW-->>App: policyDecision + forwardApiKey (SMS Link key) or deny

    Note over IDW,App: policyDecision = obligation → proceed to SMS Link
    Note over IDW,App: policyDecision = deny → PII mismatch or phone risk

API Reference

The following shows the full request and response structure for the PII Validation /slverify call.

var axios = require('axios')
var token = 'YOUR_BEARER_TOKEN' // -- obtained from step 1 --

var data = {
  "apikey": "string",
  "credential": "string",
  "appID": "string",
  "asi": "string",
  "userAttributes": [{
          "attributeType": "FullName",
          "values": {
              "fname": "John",
              "mname": "",
              "lname": "Smith"
          }
      },
      {
          "attributeType": "InternationalAddress",
          "values": {
              "country": "US",
              "administrative_area_level_1": "VA",
              "locality": "Vienna",
              "postal_code": "23225",
              "route": "Liberty St",
              "street_number": "123"
          }
      },
      {
          "attributeType": "InternationalTelephone",
          "values": {
              "dialCode": "1",
              "telephone": "1234567890"
          }
      }
  ]
}

var request = async () => {
  var response = await axios({
      url: 'https://api.preprod.iddataweb.com/v1/slverify',
      method: 'post',
      data: data,
      headers: {
          'Content-Type': 'application/json',
          'Cache-Control': 'no-cache',
          Authorization: 'Bearer ' + token
      }
  })
  console.log(response.data)
}
request();

{
  "errorCode": "string",
  "errorDescription": "string",
  "transaction_id": "string",
  "userAttributes": [],
  "acquiredAttributes": [],
  "userAssertionList": [],
  "policyDecision": "approve | deny"
}

Step-by-step Setup

• Obtain an access_token — see API Authentication.
• Use the forwardApiKey returned by the Session Risk step as the apikey for this call.
• Submit all required PII fields using the correct attributeType names: FullName (with fname, mname, lname), InternationalAddress (with country, administrative_area_level_1, locality, postal_code, route, street_number), and InternationalTelephone (with dialCode and telephone).
• On policyDecision = obligation, use the returned forwardApiKey as the key for the next step (SMS Link or the step defined in your workflow).
• On policyDecision = deny, the PII could not be corroborated or a phone risk assertion failed — do not retry with the same data.

📘

MobileMatch Postman Collection (preproduction): https://documenter.getpostman.com/view/24165880/2s8YekQaNj

Configuration Options — API-specific

Policy Components & Assertions

All risk assertions must pass. At least one link.* assertion pathway must pass for the step to proceed.

Error Handling & Troubleshooting

• PII mismatch: Verify name, address, and phone are current and match carrier records. Nicknames or maiden names will fail.
• Family plan / corporate phone: Carrier data may not resolve to the individual user — allow the user to retry with a personal phone line.
• test.phoneActive = Fail: Phone is inactive — the user must use an active personal line.
• test.lastPortGT14days = Fail: Recent number port detected — indicates risk.

Testing in Preproduction

Testing Options

• Gateway (Try Now): Admin Console with US + Andrew Roshell test data.
• API: Contact your ID Dataweb team for the MobileMatch Postman Collection with the preproduction endpoint configured.

Test Credentials and Values

Step-by-step How to Test

• Approve: Submit Andrew Roshell data with the carrier test phone number → expect obligation + forwardApiKey.
• Deny (PII): Change the name to "John Smith" — expect deny at PII step.
• Deny (phone): Use a non-carrier number (Google Voice, VOIP) — expect deny or step-up.

Interpreting Results

policyDecision = obligation — PII corroborated, forwardApiKey available for the next step.
policyDecision = deny — at least one risk assertion failed, or no PII correlation pathway passed. Check acquiredAttributes for which assertion failed.

Related Resources

→ Identity Verification | → SMS Link | → Session Risk | → Phone Registration + Risk Checker | → Authoritative Database Checker | → Gateway (OIDC) Integration