Skip to main content

Grid iList matching scenarios

The iList matching process uses configurable, rule-based logic to screen entities by applying restricted, unrestricted, and country-specific lists and determine whether to alert, or approve of individuals, organizations, or countries.

Example 1: Alertable/restricted iList: Country iList

In this example, Grid screens inquiries against the iList Match Content Rule (IMC Rule) COUNTRY_NO_MATCH. The filter for this iList rule profile is set to !(COUNTRY_NO_MATCH), meaning the system checks if the inquiry's address matches any country on the restricted iList. Based on this check, the system determines whether to issue an iList alert along with the entity matches or to send only the entity matches, if necessary.

Matching Process on a Restricted Country iList

Examples:

  • When Grid receives an address from "Country A" and finds "Country A" on the alertable/restricted iList, it generates an iList alert, and the entity matches, if necessary.

  • When Grid receives an address from "Country B" and does not find "Country B" on the restricted iList, it sends the entity matches, if necessary.

Example 2: Alertable/restricted iList: Date of Birth (DOB)

In this example, Grid screens inquiries against the iList Match Content Rule (IMC Rule) DOB. The filter for this iList rule profile is set to DOB < 2, meaning the system checks if the inquiry's DOB falls within a two-year range of the DOB on the iList entry. Based on this check, the system determines whether to issue an iList alert along with the entity matches or to send only the entity matches, if necessary.

Matching Process on a Restricted iList

Examples:

  • When Grid receives an inquiry with a DOB of January 1, 1980, and finds an iList entry with a DOB within two years (e.g., January 1, 1978, to December 31, 1981), it generates both an iList alert and the entity matches, if necessary.

  • When Grid receives an inquiry with a DOB of January 1, 1980, and does not find an iList entry with a DOB within two years, it sends only the entity matches, if necessary.

Example 3: Not alertable/unrestricted iList: name score and fraud event

In this example,Grid screens inquiries against the iList Match Content Rule (IMC Rule) MATCH_SCORE. The filter for this iList rule profile is set to MATCH_SCORE > 85, meaning Grid checks if the inquiry match score against the iList entry exceeds 85. If the score is above 85, Grid then evaluates the inquiry using the Grid Match Content Rule (GMC Rule) EVENT. For this iList rule profile, the filter is configured as EVENT: Fraud (FRD), meaning Grid checks its own entities for fraud event. Based on these checks, Grid decides whether to suppress the inquiry matches or trigger an Entity Match Alert.

Matching Process on a unresticted iList with IMC and GMC rules

Examples:

  • When Grid receives an inquiry, it first compares the inquiry to the iList entry to see if the match score exceeds 85. If the match score is greater than 85, Grid then to checks its own entities for fraud (FRD) events. If an FRD event is detected, Grid suppresses those Grid entities. If no FRD event is found, Grid generates the entity matches, if necessary.

  • When Grid receives an inquiry, it first compares the inquiry to the iList to see if the match score exceeds 85. If the match score is 85 or lower, or if the Grid entity does not have a Fraud (FRD) event, Grid doesn't suppress the inquiry. In this case, Grid generates the entity matches, if necessary.

Additional Information