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!

Verify Match API can accept a wide variety of inputs such as:

  • Name & Address
  • Phone
  • Email
  • 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.

Response Codes & Errors

Response CodesMessage
200 - OKYour request was successful
400 - Bad RequestYour request was invalid
500 - Server ErrorSomething is broken on FullContact's side. If you encounter this, please contact us at [email protected] for assistance.
503 - Service UnavailableThere is a transient downstream error condition. We include a 'Retry-After' header dictating when to attempt the call again.