Interpretation of MobileMatch
Interpreting the results of a standard MobileMatch verification.
Overview
Verification via MobileMatch is represented at the top level by a policy decision (true for all transactions on the AXN). You can confidently engage business logic based on only the policy decision, but understanding the underlying outcomes at the assertion and component levels will enable you to engage in more nuanced business logic and help users troubleshoot.
Recommended Reading
You'll need to understand policy decisions and the process for finding and reviewing an individual transaction before attempting to analyze an individual transaction, which is what's covered here.
Assertions/Components
For standard MobileMatch, the verification process is two steps: PII verification followed by OTP verification. Since there are multiple paths through which a user can pass through PII verification and since users can be Denied at either step, it's helpful to understand each underlying component independently.
Standard PII verification uses two policy components (level 1): the "PII" component is based on four sub-components (level 2) with their own sub-components (level 3) and assertions. The "Risk Checks" component is based on four assertions. Standard OTP verification uses one policy component (level 1), the "Phone access indicator (OTP)" component which is based on one assertion.
MobileMatch PII
TEMPLATE: MobileMatch - Risk Checks
All of these assertions must pass for this level 1 component to pass.
Description | Assertion Name | Component Name (Level 1) |
---|---|---|
Was the last time the SIM on this phone was ported more than 14 days ago? | test.lastPortGT14days | TEMPLATE: MobileMatch - Risk Checks |
Was the last time the SIM on this phone was ported more than 30 days ago? | test.lastPortGT30days | TEMPLATE: MobileMatch - Risk Checks |
Is this phone a personal phone number? | test.phone_landline_mobile_personal | TEMPLATE: MobileMatch - Risk Checks |
Is this phone number active? | test.phoneActive | TEMPLATE: MobileMatch - Risk Checks |
MobileMatch PII
TEMPLATE: MobileMatch - PII
One of these level 2 components must pass for this level 1 component to pass.
Description | Component Name (Level 2) | Component Name (Level 1) |
---|---|---|
Is this full name associated with this phone number? | Full name associated with phone | TEMPLATE: MobileMatch - PII |
Is this last name associated with this address and is that same address associated with this phone number? | Last name associated with address and address associated with phone | TEMPLATE: MobileMatch - PII |
Is this last name associated with this phone number and is that same phone number associated with this address? | Last name associated with phone and phone associated with address | TEMPLATE: MobileMatch - PII |
Is this last name associated with this phone number and address and is that same phone number associated with that address' ZIP code? | Last name associated with phone and address and phone associated with ZIP code | TEMPLATE: MobileMatch - PII |
MobileMatch PII
Full name associated with phone
All of these assertions must pass for this level 2 component to pass.
Description | Assertion Name | Component Name (Level 2) | Component Name (Level 1) |
---|---|---|---|
Is this full name associated with this phone number? | link.fullName_phone | Full name associated with phone | TEMPLATE: MobileMatch - PII |
MobileMatch PII
Last name associated with address and address associated with phone
All of these assertions must pass for this level 2 component to pass.
Description | Assertion Name | Component Name (Level 3) | Component Name (Level 2) | Component Name (Level 1) |
---|---|---|---|---|
Is this last name associated with this address? | link.lastName_address | Last name associated with address | Last name associated with address and address associated with phone | TEMPLATE: MobileMatch - PII |
Is this phone number associated with this address? | link.phone_address | Phone associated with address | Last name associated with address and address associated with phone | TEMPLATE: MobileMatch - PII |
MobileMatch PII
Last name associated with phone and phone associated with address
All of these assertions must pass for this level 2 component to pass.
Description | Assertion Name | Component Name (Level 3) | Component Name (Level 2) | Component Name (Level 1) |
---|---|---|---|---|
Is this last name associated with this phone number? | link.lastName_phone | Last name associated with phone | Last name associated with phone and phone associated with address | TEMPLATE: MobileMatch - PII |
Is this phone number associated with this address? | link.phone_address | Phone associated with address | Last name associated with phone and phone associated with address | TEMPLATE: MobileMatch - PII |
MobileMatch PII
Last name associated with phone and address and phone associated with ZIP code
All of these assertions must pass for this level 2 component to pass.
Description | Assertion Name | Component Name (Level 3) | Component Name (Level 2) | Component Name (Level 1) |
---|---|---|---|---|
Is this last name associated with this address? | link.lastName_address | Last name associated with address | Last name associated with phone and address and phone associated with ZIP code | TEMPLATE: MobileMatch - PII |
Is this last name associated with this phone number? | link.lastName_phone | Last name associated with phone | Last name associated with phone and address and phone associated with ZIP code | TEMPLATE: MobileMatch - PII |
Is this phone number associated with this ZIP code? | link.phone_zip | Phone associated with ZIP code | Last name associated with phone and address and phone associated with ZIP code | TEMPLATE: MobileMatch - PII |
MobileMatch OTP
Phone access indicator (OTP)
All of these assertions must pass for this level 1 component to pass.
Description | Assertion Name | Component Name (Level 1) |
---|---|---|
Did the user submit the correct six-digit OTP? | test.device | Phone access indicator (OTP) |
Interpretation & Example Outcomes
Result | Explanation | Solution |
---|---|---|
Notes
A) MobileMatch is unique in that it can and does attempt to connect a full name to a phone number any way possible, as direct as name-to-phone or more indirectly such as name-to-address-to-phone. This increases the number of potential assertion payloads.
B) What may seem like undue complexity in the MobileMatch policy is actually there to accommodate the multiple vendors capable of returning an individual assertion within the AXN; what is presented as one assertion here (e.g. link.lastName_phone) actually represents x3 assertions, hence why these assertions are organized into one component so one policy can accommodate multiple vendors.
Updated almost 2 years ago