Here at Ekata, we’re constantly iterating our products in an effort to deliver concise, actionable data to our customers. We recently released version 3.2 of the Identity Check API, which includes some exciting new data elements. Before getting into the changes, I’ll start by explaining what Identity Check is and how our customers use it.
With a single Identity Check API query, you can input two sets of phone numbers, addresses, and names (primary and secondary) in addition to one email address and one IP address. We return match statuses that tell you if the phone(s), address(es), and email are associated with the name(s) you provided in the query. We also return raw data about each input including the email’s age, a prepaid phone flag, address deliverability information, and much more.
Identity Check is used by eCommerce merchants, financial services institutions, and technology companies in the risk space. In the eCommerce space, we’re integrated with Accertify and a number of other platforms. Merchants leverage Ekata global identity data in their existing rulesets and our sales engineering team can recommend specific rules and weights that make sense for your business. Outside of eCommerce, financial services institutions and technology companies build our response into their risk models.
In Identity Check 3.2, we’ve added the following data elements:
- is_subscriber_deceased and is_resident_deceased – These data elements tell you if the person associated with the phone and address is alive or not. As you can probably guess, deceased people are not good customers and this flag is predictive of fraudulent activity. If you see this flag, we highly recommend pushing that order or application into manual review.
- distance_from_phone – This calculates the distance between the IP geolocation and the address that we have on record for the phone. We find that the address associated with the phone is often different than the primary or secondary address provided on the order or application. Lower numbers here are better. If the distance is greater than 500 miles, it’s a significant risk indicator.
We recommend looking at both distance_from_address and distance_from_phone. If one of them is within 25 miles of the IP address, then it’s a sign that the order or application is likely good.
- connection_type – This flag tells you what kind of IP address you received on the order or application. Possible responses are ‘Cable/dsl’, ‘Corporate’, ‘Cellular’, and ‘Dialup’. We find that this data element is actionable in two ways:
- First, if it’s a ‘Cellular’ connection, then you should place less weight behind our distance_from_address and distance_from_phone. When we calculate distances, we look at the IP geolocation and if it’s a ‘Cellular’ IP, then it could be hundreds of miles away from the actual location of the phone.
- Second, some of our customers are finding that ‘Corporate’ IP addresses are a positive signal. People ordering products or submitting applications from work are typically not fraudsters.
We’ve also changed the names of the inputs. We used to require ‘billing’ and ‘shipping’ inputs. To accommodate our customers outside of the eCommerce space, we’ve changed the syntax to ‘primary’ and ‘secondary’.
Finally, and what we’re most excited about, is the fact that Identity Check 3.2 returns rich, complete, and accurate data for all markets globally. We have been working very hard at launching a global product and we’re excited to be able to offer this global identity data in the same API endpoint that our customers currently use for the United States and Canada. The international identity data is live now and we’ll be releasing updated documentation and blog posts about the international data specifically over the next month or two. If you need information now, please reach out to us.
Interested in learning more about our APIs? Check out our Developer Center.