Identity Resolution: When Name and Address Aren’t Enough
By Robert Barker, Infoglide Senior Vice President & Chief Marketing Officer
Not long ago, Knowledge Integrity president, David Loshin, suggested that you have to spend considerable effort to standardize attributes of entities in order to exploit identity resolution effectively. He went on to explain multiple types of name standardizations to demonstrate just how complex the process can be.
Staying with the well understood example he used, let’s consider the complexity associated with names. Standardizing names is often more problematic than say, U.S. street addresses, since there’s no authoritative reference like the USPS database of deliverable addresses to check against. As David points out, name structures are inconsistent and undependable. Here are more examples:
- Standardizing doesn’t account for nicknames, e.g. is Jack = John or Jackson?
- Standardizing doesn’t account for typos: Is ‘Jak’ = Jack or Jake?
- Standardizing doesn’t help in a full text context. Try scanning for a guy named “Ira Roth” in a database of financial transactions.
- A naming trend in the 90s was to create non-traditional spellings of traditional names, e.g. “Erica” became “Aarika”.
While standardizing certain attributes helps, a full implementation of identity resolution overcomes the remaining inconsistencies. Definitely required are multiple analytics to handle David’s name examples as well as the additional ones outlined above, but analytics for a multitude of other attribute types present in the data are also needed (e.g. a license plate algorithm that scores a “B” as similar to the number “13”).
By harnessing the power of comprehensive identity resolution software, you can leverage multiple identity attributes, beyond just names and addresses. Then, basing decisions on algorithmically generated confidence scores of similarity and equality, the seemingly impossible complexity and variations in identity data can be exploited to increase the accuracy and value of your key applications.
Subscribe to this blog
July 11th, 2008 at 5:10 am
But how then do you cope with systems and requirements where at times only names are available for checking as other attributes are just not available, or if they are available for the most part some transactions are devoid of anything but name? Moreover, if these systems must *never* miss a name only match what options do you have? There are situations where name alone has to be enough and is mandated by the end customer.
July 11th, 2008 at 12:36 pm
Ant is correct. Occasionally name is the only attribute available, and in that case, identity resolution technology must include very effective inexact name matching, preferably providing a confidence score for each match. On the other hand, most systems capture and store additional attributes, and a simultaneous analysis of multiple attributes including names can give much higher confidence levels.