Match
As the world has gone more online, digital fraud has been on the rise. Bad actors are constantly looking for new ways to commit fraud using techniques such as forging synthetic identities, stealing identity and performing account takeovers. Companies are left having to balance a frictionless customer onboarding journey while trying to minimize fraud and protecting its platform.
FullContact brings harmony to these two equations leveraging the power of Verify Match and its broad, real-time Identity Graph.
The power of Verify Match spans both the digital and terrestrial ecosystems along with providing insight into how, and if, personal and professional identities are linked together.
Try out Verify Match Create a 30 Day Trial Account Today!
Download Here: Verify Match Data Dictionary
Verify Match API can accept a wide variety of inputs such as:
- Name & Address
- Phone
- Social handle, ID or URL
- Employer/Job Title
Nuances and limitations
- While the endpoint accepts Multi-Field, it will only accept one input per contact identifier type (i.e. only one clear text email)
- This endpoint does not accept Record IDs, Person IDs and/or Partner IDs as input
- If name/address combination is used as input, FullContact will attempt to see if that name/address combination matches to a current, prior or unknown place of residence.
Based upon provided contact information, you can understand how the information you have provided matches (or does not match) against the FullContact Identity Graph. In addition to the match characteristics there is an associated risk score, which is a proxy for friction that may need to be applied downstream.
Give Our New Enhancements a Go
FullContact is looking for Beta testers!
Do you have Date of Birth, IP Address, Employment Job Title or the Organization name of a person's place of employment in your datasets?
Do you want to see how those elements relate to and match against other pieces of PII (email, social, name/address, phone)?
Reach out to your dedicated Customer Success Manager or please contact us to get your beta test started.
All this combined, helps you identify risk on a form field, sign up, onboarding process or application.
The direct output of the provided information (at the contact element level) could potentially represent any of the following categories:
Match Type | Description |
---|---|
Tangled string | Matches an input belonging to a different individual (no relationship). This is typically an indication of increased fraud risk; further downstream friction may need to be applied specific to that identifier. |
Household string | Matches an input field belonging to someone else inside the same household (spouse, young adult, etc). This is typically not an indication of fraud risk, however some friction may need to be applied. |
Self string | Matches an input field directly belonging and pointing to the most likely person requested. All outputs with ‘self’ must share metadata within our graph as this is the anchor in which all other fields are classified. |
Unknown string | Not enough information to qualify as any of the above classifications. This may or may not be an indication of fraud risk; further downstream friction may need to be applied. |
Risk double | Indicates the level of risk associated with the given inputs. This current risk score is based upon deterministic email related activity such as, first/last seen timestamps, number of sources and observations along with whether or not an observed linkage to a first party cookie exists. If the risk score is closer to 1.0, then the individual and associated inputs are deemed to be more risky. |
Interpreting Requests in Match
The input provided should follow the multi-field format since it returns indicators on which submitted fields align and which do not.
For example, if an email, phone and name are provided, the response will indicate if the email, phone and name belong to the same person.
If they do not, the response will indicate as much and offer some insights into the mis-matched fields.
Only input fields will return.
curl -X POST \
https://api.full.id/v3/verify.match \
-H 'Authorization: Bearer {Your API Key}' \
-H "Content-Type: application/json" \
-d '{
"email": "[email protected]",
"phone": "+15552227799",
"location": {
"addressLine1": "123 Main Street",
"city": "Denver",
"region": "Colorado",
"postalCode": "80203"
},
"name": {
"given": "Sally",
"family": "Smith"
},
"organization": "FullContact",
"title": "CEO"
}'
"ipAddress": "74.125.20.113",
"profiles": [{
"service": "twitter",
"username": "bartlorang"
},
{
"service": "twitter",
"userid": "123456"
},
{
"service": "linkedin",
"url": "https://www.linkedin.com/in/sallysmi"
}
]
{
"addressLine1" : "self",
"city" : "self",
"region" : "self",
"country" : "self",
"postalCode" : "self",
"givenName" : "self",
"familyName": "self",
"phone" : "tangled",
"email" : "household",
"title": "unknown",
"organization": "unknown"
"risk" : 0.52
}
For social profiles, you can only submit one - the above code example has 3, but only to show you how to input either "userid", "url", or "username" as an input. Only choose one when you make your Verify.Match API call
Example Explanation
- Request
- The request uses Bob's email, but Sally for the Name
- Bob Smith and Sally Smith live in the same home and thus share the address
- The phone number is not associated to either of them and rather is connected to somebody different
- Response
- The address & name are Sally: self
- The email is Bob's but Bob and Sally live together: household
- The phone is not either of theirs: tangled
- The risk is hence at slightly higher value due to having a
tangled
phone
- Actions
- Friction may be desired on the
tangled
phone, forcing the phone number to be verified by the consumer, who we hope is actually Sally! - Since the email is
household
, the requestor may choose to accept it as good enough since. Maybe both Bob and Sally share it from time to time.
- Friction may be desired on the
Response Codes & Errors
Response Codes | Message |
---|---|
200 - OK | Your request was successful |
400 - Bad Request | Your request was invalid |
500 - Server Error | Something is broken on FullContact's side. If you encounter this, please contact us at [email protected] for assistance. |
503 - Service Unavailable | There is a transient downstream error condition. We include a 'Retry-After' header dictating when to attempt the call again. |
Updated 8 months ago