pairMatch Web Service Examples

  • Web Services
  • API Documentation
  • Auto-Steward

The following examples describe sample PairMatchRequests with their associated PairMatchResponse, with downloadable sample XML files.

Refer to PairMatchRequest  for a complete description of the strings contained within the request and response XML files.

Example 1 — Same person determined with referential match

Sample Request Description

Sample File (XML)

In this example,  Verato’s Auto-Steward service determines that two suspected duplicates (the identities input into the web service) are the same person because both input identities matched to the same reference identity.

For this example, the two input identities have the same DOB and SSN, similar names, but different addresses. If the MPI/MDM system could not quite match those definitively, they would be queued up as a data stewardship work item and passed to Verato’s AUTO-STEWARD service.

For example #1, the web service request XML is shown in the outlined box below. Red font is used to highlight the identity attribute values for the first input identity, and blue font is used to highlight the identity attribute values for the second input identity.

description pairmatch_request_example_1

Sample Response Description

The response indicates that the two input identities were deemed to be same person based on a common reference identity match. That indication is found in the MatchResult element of the XML response. Green font is used to highlight the web service response data that indicates the overall AUTO-STEWARD result. Red font is used to highlight the identity attribute values for the Verato reference identity which matched input identity #1. Blue font is used to highlight the identity attribute values for the Verato reference identity which matched input identity #2.

The Identity1AttributeMatchTable element in the response XML shows the degree of similarity between the 1st input identity and its matching Verato reference identity. The match codes indicate that there was a perfect match (code=MATCH) on the first name, last name, DOB, SSN, gender, and the address components.

The Identity2AttributeMatchTable element in the response XML shows the degree of similarity between the 2nd input identity and its matching Verato reference identity, which was the same identity (same AraxidID) that also matched the 1st input identity. The match codes indicate that there was a perfect match (code=MATCH) on the first name, last name, DOB, SSN, gender, and the address components.

Because this example did not rely on a head-to-head comparison between the 1st and 2nd input identities, the PairAttributeMatchTable element in the response XML was not a factor in the final SameIdentity decision, and it can be disregarded.

description pairmatch_response_example_1

Example 2 — Same person determined with head-to-head match

Sample Request Description

Sample File (XML)

The second example is a case where the two suspected duplicates (the two input identities to the web service) are deemed by Verato’s AUTO-STEWARD service to be the same person because both input identities match each other based on a head-to-head comparison of the input identities. One or both of the input identities did not match to a Verato reference identity, so the AUTO-STEWARD service compared the input identities against each other head-to-head.

In this example, the two input identities have the same name and DOB, similar SSNs, and only one input identity has an address. If the MPI/MDM system could not quite match those definitively, they would be queued up as a data stewardship work item and passed to Verato’s AUTO-STEWARD service. In this example, neither input identity was matched to a known identity in Verato’s Reference Database. But the input identities were compared head-to-head against each other and deemed to be the same person based on the matching first name, matching last name, matching DOB, matching gender, and very similar SSNs (which differ only by a transposition error).

For example #2, the web service request XML is shown in the outlined box below. Red font is used to highlight the identity attribute values for the first input identity, and blue font is used to highlight the identity attribute values for the second input identity.

 

description pairmatch_request_example_2

Sample Response Description

The web service response XML is shown in the outlined box below. The response indicates that the two input identities were deemed to be same person based on a head-to-head comparison. That indication is found in the MatchResult element of the XML response. Green font is used to highlight the web service response data that indicates the overall AUTO-STEWARD result.

Because neither input identity matched to a Verato reference identity, the Identity1CommercialMatches and Identity2CommercialMatches elements are empty. Also, the Identity1AttributeMatchTable and Identity2AttributeMatchTable elements are empty as well (for the same reason).

Since the final AUTO-STEWARD result was based on the head-to-head comparison between the two input identities, the PairAttributeMatchTable element is noteworthy – this element shows the degree of similarity between the two input records through the match codes for each attribute. The match codes indicate that the first name, middle name, last name, DOB, and gender attributes were all perfect matches (code=MATCH). The match codes also indicate that the SSN attributes were a partial match (code= ADJACENT_TRANSPOSED_CHARACTERS_MATCH). And the match codes indicate that the address was treated as missing since only one of the input identities had an address (code=TARGET_DATA_UNAVAILABLE).

description pairmatch_response_example_2

Example 3 — Not-Same-Person Determined With Referential Match

Sample Request Description

Sample File (XML)

The third example is a case where the two suspected duplicates (the two input identities to the web service) are deemed by Verato’s AUTO-STEWARD service to be NOT the same person because each input identity matched to a DIFFERENT reference identity.

In this example, the two input identities have some similarity in their names and SSNs, different DOBS, and only one input identity has an address. If the MPI/MDM system could not quite match those definitively, they would be queued up as a data stewardship work item and passed to Verato’s AUTO-STEWARD service.

For example #3, the web service request XML is shown in the outlined box below. Red font is used to highlight the identity attribute values for the first input identity, and blue font is used to highlight the identity attribute values for the second input identity.

description pairmatch_request_example_3

Sample Response Description

The web service response XML is shown in the outlined box below. The response indicates that the two input identities were deemed to be different people (SameIdentity=N) based on different reference identity matches. That indication is found in the MatchResult element of the XML response. Green font is used to highlight the web service response data that indicates the overall AUTO-STEWARD result. Red font is used to highlight the identity attribute values for the Verato reference identity which matched input identity #1. Blue font is used to highlight the identity attribute values for the Verato reference identity which matched input identity #2.

The Identity1AttributeMatchTable element in the response XML shows the degree of similarity between the 1st input identity and its matching Verato reference identity. The match codes indicate that there was a perfect match (code=MATCH) on the first name, last name, DOB, SSN, gender, while the address components were treated as missing (code=TARGET_DATA_UNAVAILABLE) since the input identity did not have an address.

The Identity2AttributeMatchTable element in the response XML shows the degree of similarity between the 2nd input identity and its matching Verato reference identity, which was a different identity (different AraxidID number) than the reference identity to which the 1st input identity matched. The match codes indicate that there was a perfect match (code=MATCH) on the last name, DOB, SSN, and gender, while the first name was a partial match (code=NAME_VARIANT_MATCH).

Because this example did not rely on a head-to-head comparison between the 1st and 2nd input identities, the PairAttributeMatchTable element in the response XML was not a factor in the final SameIdentity decision, and it can be disregarded.

description pairmatch_response_example_3