2.3 Matching

Oracle Financial Services Customer Screening uses different approaches to matching for different use cases. For Sanctions screening, a zero-tolerance approach to matching is assumed, where secondary data such as dates and years of birth, and nationalities cannot necessarily be assumed to be correct. In this case, it may be important to present matches where there is a level of name match even if other data would indicate that a match is unlikely. When screening against lists of Politically Exposed Persons (PEPs) or other individuals on watch lists (Enhanced Due Diligence matching), where the occasional 'false negative' may be tolerable from a business perspective, match rules are generally 'tighter' and demand at least one item of secondary data (such as a nationality, year of birth or date of birth) matches as well as a name of match. However, the screening rules for each screening process can, and should, be tailored according to the business appetite to risk. Oracle Financial Services Customer Screening also provides separate processes for Batch and Real-Time screening, as these may be subject to different matching strategies.

The following general notes describe the approach to matching:
  • Matches are ranked according to how well the name matches. An exact name match rates as a match at the highest level, with the lowest level being represented by two loosely possible name matches with a different name structure. Further ranking is imposed by how well additional information (such as city or country information, and date of birth information) matches between the records.
  • Oracle Financial Services Customer Screening allows for various levels of name match, including, but not limited to:
    • Name variation recognition. This is carried out by name standardization. For example, all variations of Mohammed (Muhamad, Mohammad, Mohamed and so on) are substituted with ‘Mohammed’ when matching. This is particularly used for given names, though also applied when matching whole names. For example, more than 20 variations of the name ‘Mohammed’ are recognized and considered to be the same name.
    • Allowances for name abbreviation and initials. For example, ‘Pete’ is a possible match to ‘Peter’, and ‘J’ is a possible match to ‘John’.
    • Allowances for typographical errors and transliteration differences. For example, ‘Abdool’ is a possible match to ‘Abdul’, even if the variants are not standardized.
    • Allowances for names being out of order or structured differently. For example, ‘Mohammed Abbas Al-Tikriti’ can be matched with ‘Mohammed Al-Tikriti Abbas’.
    • Allowance for additional names. For example, ‘Juan Carlos Ferreira’ can be matched with ‘Juan Ferreira’.
    • Allowance for names being split differently. For example, ‘Xiao Jian’ is a match to ‘Xiaojian’.
  • Oracle Financial Services Customer Screening attempts to prevent false positives by various means, including, but not limited to, the following methods:
    • Backing up typo tolerance with Metaphone matching. For example, ‘Mary’ and ‘Mark’ are not considered a match, although they are only one character different.
    • Backing up typo tolerance with consideration of the percentage of characters that are different. For example, the initials ‘A’ and ‘E’ are not considered a match, even though they are only one character different.
    • Considering the different significance and commonality of name tokens. For example, if name qualifiers such as ‘Al’ are shared between two Arabic names, this is not as significant as if an uncommon name such as ‘Abbas’ is shared.
  • It is advisable to configure the set of match rules that are activated. In particular, you may wish to activate or deactivate some of the lower match rules in the list, which lead to the weakest name matches. Factors affecting the usefulness of these rules include:
    • The policies of the organization;
    • The quality of the customer data;
    • The provenance of the customer data.

For example, Asian and Arabic names may be subject to more typographical and name ordering issues than other names. Where the data contains many of these names, the lower strength rules may identify more possible matches. The organization may want to review some or all of these as a matter of policy, or it may consider the matches too weak to review.

The required rules are easily activated or deactivated as needed in Oracle Financial Services Customer Screening.

Match Rules

The following match rules are involved in Individual Screening:
  • The elimination rules. These are used in various positions in the rule templates to eliminate any records that have conflicting supporting data. The elimination rules may be moved up and down in order to change when they are applied during the matching process.
  • The name matching rules. These are organized by the level of name match, with the strongest name matching rules placed at the top of the decision table.

    Note:

    • Match rules are not ordered by strength across all identifiers. For example, a weaker name match that is strengthened by matches on date of birth, city, and country is likely to be a stronger overall match than a strong name with strongly contradictory data in the other fields.
    • Oracle Financial Services Customer Screening includes many match rules for each level of name match, reflecting the match strength of any additional information, particularly date of birth and location data. The last rule in each set is a 'conflict' rule, and in many cases will be disabled by default. These rules allow records that fulfill the specified level of name match but have conflicting supporting data fields indicating that a true match is unlikely.
  • The loose name matching rules. These are also based around name matching, but identify looser matches and are not enabled by default. These rules are likely to result in a large number of false-positive matches and are most likely to be of use when screening against sanctions lists, where it is important that no true matches are missed.
For the sake of clarity, match rules are divided into groups, as shown below:

Figure 2-1 Match Rules


Description of Figure 2-1 follows
Description of "Figure 2-1 Match Rules"

As each group is selected, the match rules it contains are displayed in the window below.

The priority of the groups can be changed using the arrows below the Match Rules Group list. When a group is highlighted, you can:
  • Click Up Arrow to move it up one place on the list.
  • Click Down Arrow to move it down one place on the list.
  • Click Top Arrow to move it to the top of the list.
  • Click Bottom Arrow to move it to the bottom of the list.

The remainder of this section describes the matching rules that are present in Oracle Financial Services Customer Screening in greater detail.

Prohibition Rules

The Prohibition rules check for country information in an individual's record against the list of prohibited countries and nationalities maintained in List Management.

Table 2-13 Prohibition Rules

Group Code Matching Rule Summary of Rule Logic
I000A Country prohibition - Residency The country of residence given matches a prohibited country.
I000B Country prohibition - Nationality The nationality given matches a prohibited nationality.

Elimination Rules

Table 2-14 Elimination Rules

Elimination Rule Summary of Rule Logic Enabled by default?

ELIMINATE WHERE NO YOB

INCOMMON

 This rule will eliminate pairs of records if both YOB fields are populated and there is no value in common. Yes

ELIMINATEWHERE DOB IS

DIFFERENT

 This rule will eliminate pairs of records if both DOB fields are populated and there is no value in common. No
ELIMINATE WHERE DOB TOODIFFERENT This rule will eliminate pairs of records if the date of birth differs too greatly between the two records. Pairs are eliminated if there are 6 or more years difference between DoBs, and one typographical error, and one typographical error in a month. No

ELIMINATE WHERE GENDER

IS DIFFERENT AND BOTH DERIVED OR BOTH STATED

 This rule will eliminate pairs of records if the genders are different, and EITHER both records had the gender specified as part of the input record, OR both records have a gender value which was derived from other fields. Yes
ELIMINATE WHERE NO COUNTRYSHARED AND ALL SAFE

This rule will eliminate pairs of records if there are no countries in common in the Country fields, AND if all countries listed are on the Safe list.

The Safe list is maintained in the Match - Individual Safe Countries ISO Codes Reference Data.

 Yes
ELIMINATE WHERE NO NATIONALITIES IN COMMON This rule will eliminate pairs of records if the Nationality fields contain no common entries. Yes
ELIMINATE WHERE LIST OCCUPATION IS SAFE

This rule will eliminate pairs of records if the List Occupation field contains only values in the Match - Safe Occupations Reference Data.

 Yes
ELIMINATE WHERE CUSTOMERRISK SCORE BELOWTHRESHOLD This rule will eliminate pairs of records if the Customer Risk Score is below a threshold specified in the corresponding screening process. No
ELIMINATE WHERE LIST RISK SCORE BELOW THRESHOLD

This rule will eliminate pairs of records if the List Risk Score is below a threshold specified in the corresponding screening process.

 No
ELIMINATE WHERE LIST PEP RISKSCORE BELOW THRESHOLD This rule will eliminate pairs of records if the List PEP Risk Score is below a threshold specified in the corresponding screening process. No

Note:

No elimination rules are enabled by default for Sanction records.