Email and Physical Address risk
Overview
Fraudulent accounts can cost brands money. Account onboarding is your first line of defense against fraudsters using false information to create accounts for nefarious purposes.
Strivacity’s email and physical address risk step allows brands to evaluate the information submitted during onboarding for risk signals. Higher-risk accounts can either then be blocked or further vetted to ensure authenticity.
Email and physical address risk evaluation is currently only available in the US and Canada.
Approach
Strivacity sends account data you collect and selects via claims mapping to our data partner, which returns various values that you can write risk rules against. See full list of evaluation rules and return values.
Configured rules can then be assigned a risk impact, which determines the outcome of that rule. When a rule is triggered, you can either pass the step, fail the step, add to a failure threshold, or subtract from a failure threshold. Rules are evaluated in order and can be re-ordered as needed. If no “Pass step” or “Fail step” rules are triggered, then the failure threshold count is evaluated. If no rules are triggered and the failure threshold is not met, the step will end in a success action.
![Email and physical address risk rule configuration](https://files.readme.io/c4a052b-image.png)
Email and physical address risk rule configuration
Capabilities
Risk rules
The following evaluation rules and return values are available to configure your brand's risk tolerance.
Evaluation rules | Description | Possible return values |
---|---|---|
Email address validation | Validates whether the email address is a valid email address. | - Invalid domain (DNS check) - Invalid syntax (email syntax incorrect) - Invalid account (unlikely to be delivered) - Valid domain and syntax but unknown account (limited info on deliverability) - Active account (high likelihood of email being delivered) |
Email address found in 3rd-party data | Determines if the email address was found in a 3rd-party database. A return value of "Yes" is a dependency for returning activity and attribute match data. | - Yes - No |
Email address first active | Indicates when an email address was first seen in data. | - None seen or first activity is unknown - 0-6 months ago - 7-12 months ago - Over 12 months ago |
Email address last active | Indicates when an email address was last seen in data. | - None seen or last activity is unknown - 0-6 months ago - 7-12 months ago - Over 12 months ago |
Email address active for | Indicates how long an email address has been continuously used. | - None seen or active streak unknown - Less than 12 consecutive months - 12 consecutive months - 13-24 consecutive months - More than 24 consecutive months |
Physical address - business vs. residence | Returns if an address is a business or residence, based on USPS RDI service. | - Residential - Both - Business - Unclassified |
Physical address is vacant | Returns if an address is reported vacant by the USPS. | - Yes - No - Unknown |
Physical address is a commercial mail-receiving agency | Returns if an address is, or has on its premises, a commercial mail receiving agency as reported by USPS. | - No - Yes - Buiding where tenant is CMRA - Both CMRA and building where tenant is CMRA |
Physical address is a prison | Returns if an address is a prison, as reported by USPS. | - Yes - No |
Physical address is a small office or home office | Returns if an address is a small office or home office, as reported by USPS | - No - Likely - Very likely - Potential small office - Small business. - Unknown address status |
Physical address component validation | Returns if all or just primary address components are valid. | - All address components validated - Only primary components validated - Address cannot be validated |
USPS physical address type | Returns USPS NCOA address type for the given address | - Street address - Firm or business - Rural route - High rise - P.O. Box - General delivery |
Attribute association
The following attribute associations and return values are available to write rules against. These associations are sourced from a third-party provider of marketing data.
Evaluation rules | Description | Possible return values |
---|---|---|
Phone number to full name | Returns any data linkage between a phone number and a full name | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
Phone number to first name | Returns any data linkage between a phone number and a first name. | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
Physical address to phone number | Returns any data linkage between a physical address and a phone number | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
Email address to phone number | Returns any data linkage between an email address and a phone number | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
Physical address to full name | Returns any data linkage between a physical address and a phone number | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
Email address to full name | Returns any data linkage between an email address and a name | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
Email address to physical address | Returns any data linkage between an email address and a physical address | - Invalid or missing input - No link - No data in repository - unknown - Low accuracy linkage - High accuracy linkage |
How to set up
To configure an email and physical address risk:
- set up an identity verification policy (Policies > Identity verification > Create identity verification policy)
- add an email and physical address risk policy
- review existing default rules and adjust as needed
- add new rules that support your business use cases
- make sure the claim mapping tab configuration is pulling the user’s data from the proper native claims
Configuration for common use cases
Use case: physical address fraud
Using a false physical address can allow fraudsters to create accounts that can then be used for crimes such as student loan fraud or other financial fraud. You can configure email and physical address fraud to reduce that risk. For example, the following policy would allow you to check that a physical address is real, is not a business, and that the email address used for account opening has been associated with that address.
Risk rules
- Email validation: Invalid domain: Fail validation
- Email validation: invalid account: Fail validation
- Address - business vs. residence: Business: Fail validation
- Address is commercial mail receiving agency: Yes: Fail validation
- Address is a prison: Yes: Fail validation
Attribute match rules
Email to physical address: High accuracy linkage: Pass validation
Risk score: set to zero
Updated 4 days ago