Perform address comparison
When input and watchlist entity (WLE) addresses either do not match exactly or some parts of the addresses (such as road, city, house number, and so on) are missing, a scoring mechanism is used to provide probabilistic or fuzzy matching. The addressMatch JSON object contains a score parameter. This excerpt delineates the heuristic behind calculating this score.
Use external address verification service
The addressMatch object contains comparisonOutput when the external address verification service is configured to verify and match addresses, as shown in the example below:
"addressMatch": {
"matcherSource": "AVSERVICE",
"comparisonOutput": {
"house_number_match": false,
"city_match": true,
"state_match": true,
"country_match": true,
"postal_code_match": false,
"road_match": false
},
"score": 0.7,
"match": false,
...
By default, if the house number, city, country, and road match, the match variable is set to true. However, in many situations, one or more of these required fields either do not match (set to false) or are unavailable (set to null). In such cases, a score is provided based on the weigthed average of the data points available in comparisonOutput.
More specifically, the following heuristic is used to calculate the score:
score = location_weight * (house_match_score + road_match_score + postal_match_score) + region_weight * (city_match_score + state_match_score + country_match_score)
If any of the matching factors are missing (or set to null), the corresponding values are discounted and the weights are adjusted to obtain a score that reflects the available data for making a decision. Below is a sample of the score table with the factors set to be either true, false, or null.
| house | road | postal | city | country | state | score |
|---|---|---|---|---|---|---|
true | true | true | true | null | true | 0.91 |
true | true | true | null | null | null | 0.9 |
FALSE | true | null | true | true | true | 0.88 |
null | true | null | true | true | true | 0.88 |
true | true | true | null | true | true | 0.88 |
true | true | true | true | null | null | 0.88 |
true | true | true | null | null | true | 0.86 |
true | true | true | null | true | null | 0.86 |
true | true | null | true | null | true | 0.85 |
FALSE | true | true | true | true | true | 0.82 |
null | true | true | true | true | true | 0.82 |
true | true | null | null | true | true | 0.8 |
true | true | null | true | null | null | 0.76 |
true | true | null | null | null | true | 0.72 |
true | true | null | null | true | null | 0.72 |
See the full score table in the addressMatchingScores_final.xlsx file.
You can either utilize these scores along with a threshold value to write a rule in the Drools file for adjudicating an address match. Alternatively, use the comparisonOutput object directly to create a customized rule to escalate or de-escalate a hit based on address matching.
rule "example_address_match_rule_using_threshold_0.7"
activation-group "default"
salience 1687
when
TypeMatch (inputType in (EntityType.INDIVIDUAL, EntityType.ORGANIZATION, EntityType.LOCATION))
eval (addressMatch.match == true || addressMatch.score >= 0.7)
then
RulesUtils.escalate("Address of the screened entity matching address of the sanctioned entity", rulesDecision,addressMatch.score);
end
Another example using the comparisonOutput object is as follows:
rule "example_address_match_rule_using_comparison_factors"
activation-group "default"
salience 1687
when
TypeMatch (inputType in (EntityType.INDIVIDUAL, EntityType.ORGANIZATION, EntityType.LOCATION))
eval (addressMatch.comparisonOutput.road_match && addressMatch.comparisonOutput.city_match )
then
RulesUtils.escalate("Address of the screened entity matching address of the sanctioned entity", rulesDecision,addressMatch.score);
end
Use approximate string matching
When no external address verification services are available, an approximate string matching heuristic is used to obtain a similarity score. This method largely relies on calculating the ratio of tokens between the two addresses that match, including detection of abbreviations or common prefixes. In the example below, all tokens are accounted for, resulting in a complete match.
- Screened input:
'6820 South Harl Avenue, Tempe, Arizona 85283, United States' - Sanctioned input:
'6820 S. Harl Ave., Tempe, Ariz., 85283, U.S.' - String matching score:
1.0000000
See another example:
- Screened input:
'510 McDonald Ave, Brooklyn NY' - Sanctioned input:
'510 McDonald Ave ISTANBUL TURKEY' - String matching score =
0.500000
Here, only half the tokens match (excluding Ave, which is a common address token ignored in calculations).
Currently, the score matching heuristic is not applied when Google Geocoder is used for address verification or matching, since the geocoder result maps an address to a unique identifier. This produces a match with a score of 1.0 if the identifier matches, and 0.0 otherwise.