Matchlists (Blocklists)

Learn how to manage and utilize Matchlists to enhance your KYC processes efficiently.

What are Matchlists?

Matchlists are a sophisticated tool in the FrankieOne platform designed to screen entities against curated lists of attributes during your KYC process. They are an evolution of traditional blocklists, offering more nuanced classification and control over your risk-based decisioning.

While the primary use case is often for “blocklisting,” the Matchlist framework is designed to be flexible, allowing for different actions based on your compliance policies. In the current implementation, Blocklists are the first type of Matchlist available.

How Matchlists Work

The process is integrated directly into the workflow engine, allowing for automated, real-time screening at onboarding.

1

1. Configure a Matchlist

The FrankieOne team will work with you to set up your initial Matchlists. For now, a default “Blocklist” will be created with an action of BLOCK and a risk score.

2

2. Add Entries to the Matchlist

You populate your Matchlist with entries via the API. Each entry consists of one or more attributes (e.g., a name, email address, or document number) that you want to screen against.

3

3. Execute a Workflow with a Matchlist Step

When you execute an onboarding workflow, the dedicated Matchlist Step will screen the entity’s data against the entries in your Matchlist.

4

4. Review and Classify Hits

If a match is found, the workflow will return a HIT. Your compliance team can then review the match and classify it (e.g., as a TRUE_POSITIVE_REJECT or FALSE_POSITIVE) via the API.


Managing Your Matchlist and Its Entries

While you cannot create your own Matchlists yet, you have full control over managing the entries within the lists configured for you by the FrankieOne team.

Retrieve Your Matchlist Details

Use the GET /v2/matchlists endpoint to retrieve the details of the Matchlists created for you. This is how you find the matchlistName needed for managing entries.

1GET /v2/matchlists

Adding Entries to a Matchlist

You can add entries one by one or in bulk using the POST /v2/matchlists/{matchlistName}/entries endpoint. Each entry must contain an array of attributes.

Example: Adding a Batch of Entries
1{
2 "batchName": "known-fraud-list-q3",
3 "entries": [
4 {
5 "entityId": "ent_01J...",
6 "reference": "CASE-12345",
7 "reasons": [ "SUSPECTED_FRAUD_EMAIL" ],
8 "attributes": [
9 { "type": "IND_DISPLAY_NAME", "value": "John Smith" },
10 { "type": "EMAIL_ADDRESS", "value": "john.smith.fraud@example.com" }
11 ]
12 }
13 ],
14 "comment": { "text": "Added based on fraud report from Tier 2 team." }
15}

Preventing Duplicate Entries

To maintain data integrity, the system enforces uniqueness rules. An entry will be rejected if it is a duplicate.

  • By entityId: An entry with the same entityId as an existing entry will be rejected.
  • By Attribute Combination: The system also checks for uniqueness based on specific combinations of attributes, even if no entityId is provided.
    • For Individuals:
      • IND_GIVEN_NAME + IND_FAMILY_NAME + IND_DATE_OF_BIRTH
      • DOC_PRIMARY_IDENTIFIER + DOC_TYPE
    • For Organizations:
      • ORG_NAME + ORG_REGISTERED_COUNTRY

Screening and Classifying Results

The Matchlist Workflow Step

For screening to occur, your workflow must contain a Matchlist Step. When this step executes:

  • If no match is found, the step result is CLEAR.
  • If a match is found, the step result is HIT, and a BLOCKLISTED issue with BLOCK severity is generated.

Classifying a Match

When a match is found, a compliance officer must review it and classify it using the PATCH /v2/individuals/{entityId}/results/matchlist endpoint.

Manual StatusDescription
FALSE_POSITIVEThe match is incorrect and does not indicate a valid risk.
TRUE_POSITIVE_REJECTThe match is accurate, and the entity should be rejected.

After classifying all hits for an entity, you should re-run the workflow. This will re-evaluate the Matchlist step. If all hits have been resolved as FALSE_POSITIVE, the step result will change to CLEARED, and the BLOCKLISTED issue will be removed.


Managing Individual Entries via API

You can perform full CRUD (Create, Read, Update, Delete) operations on the entries within your Matchlists.

ActionEndpoint
Retrieve EntriesGET /v2/matchlists/{matchlistName}/entries
Search EntriesPOST /v2/search/matchlists
Modify an EntryPATCH /v2/matchlists/{matchlistName}/entries/{entryId}
Updating Entry Attributes

You cannot directly update the attributes of an existing Matchlist entry. To change an attribute, you must first mark the old entry’s state as DELETED and then create a new entry with the updated attributes.

Adding and Removing an Entire Entity

You can also manage entries based on an entityId.

  • Add Entity: POST /v2/matchlists/{matchlistName}/entries/addEntity
  • Remove Entity: PATCH /v2/matchlists/{matchlistName}/entries/removeEntity (This sets the entry state to DELETED).

Reference: Reason Codes

When adding an entry to a blocklist, you can provide one or more reason codes to add context for auditing and review.

Reason CodeDescription
SYNTHETIC_IDThe identity is suspected to be synthetic.
SUSPECTED_FRAUDFraud is suspected.
SUSPECTED_ID_THEFTIdentity theft is suspected.
ID_USED_IN_KNOWN_FRAUDThe identity has been used in known fraud incidents.
ID_THEFT_VICTIMThe individual is a known victim of identity theft.
REQUESTED_BLOCKA block has been requested for this entity.
SUSPECTED_FRAUD_ADDRESSThe address is suspected of being associated with fraud.
SUSPECTED_FRAUD_EMAILThe email is suspected of being associated with fraud.
SUSPECTED_FRAUD_PHONEThe phone number is suspected of being associated with fraud.
FREQUENT_USE_ADDRESSThe address is being used with unusual frequency.
FREQUENT_USE_EMAILThe email is being used with unusual frequency.
FREQUENT_USE_PHONEThe phone number is being used with unusual frequency.
SUSPECTED_MONEY_MULEThe individual is suspected of being a money mule.
NON_PAYMENTNon-payment is the reason for adding the entity.

Configurable Attributes for Matchlist Checks

You can use any of the following attributes to create rules for matchlist checking:

Entry Attribute TypeNotes
ENTITY_TYPEMaps to entity profile
EMAIL_ADDRESSDirect mapping to email object
EMAIL_DOMAINPart of email object
PHONE_NUMBERIncluding country and format validation
ADDR_STREET_NUMBERPart of address schema
ADDR_STREET_NAMEPart of address schema
ADDR_STREET_TYPEPart of address schema
ADDR_NEIGHBORHOODPart of address components
ADDR_LOCALITYPart of address components
ADDR_DISTRICTPart of address components
ADDR_SUBDIVISIONPart of address schema
ADDR_COUNTRYISO-3166-1 format
ADDR_POSTAL_CODEPart of address schema
ADDR_UNSTRUCTURED_LONG_FORMFlexible address format
DOC_CLASSDocument classification
DOC_TYPEDocument type specification
DOC_SUBTYPEFurther document categorization
DOC_PRIMARY_IDENTIFIERMain document identifier
DOC_SECONDARY_IDENTIFIERAdditional document identifier
IND_DISPLAY_NAMEDisplay name for individuals
IND_GIVEN_NAMEFirst name
IND_FAMILY_NAMELast name
IND_MIDDLE_NAMEMiddle name
IND_DATE_OF_BIRTHIndividual’s birth date
IND_NATIONALITYCountry of nationality