Matchlists (Blocklists)

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

Matchlists: The Upgraded Blocklist

Matchlists are a sophisticated tool in FrankieOne’s suite, designed to enhance the Know Your Customer (KYC) processes by allowing entities to be screened against curated lists of attributes. Unlike traditional blocklists, Matchlists provide nuanced classification for more granular decision-making during onboarding workflows. In the current implementation, Blocklists are the first type of Matchlist available, providing advanced screening capabilities beyond simple blocklisting. While Matchlists can be used for blocking, their enhanced capabilities allow for more sophisticated risk management.

Key Features

Manage Matchlists

Easily retrieve and manage Matchlists, ensuring consistent and controlled screening during customer onboarding.

Attribute Matching

Match entities based on various attributes such as email, name, and address to identify potential risks with precision.

Entry Management

Perform CRUD operations on Matchlist entries, including adding, updating, and retrieving entries for effective risk management.

Screening and Risk Assessment

Integrate Matchlists into workflows for real-time risk assessment and automated decision-making.

Getting Started

Follow these steps to begin using Matchlists for enhanced KYC processes. Ensure the Matchlist Step is added to your workflow, especially if you are migrating from v1 to v2.

For now, you cannot create your own Matchlist or set screening parameters. These actions are handled by the FrankieOne implementation team. A Matchlist with the action type BLOCK and a risk score of 1 will be created and configured for you during the initial customer onboarding process. You can retrieve the details of the Matchlist created for you using the endpoint GET /v2/matchlists.

1

Create a Matchlist

Use the API endpoint to initiate a Matchlist, assigning a unique name and configuration. The first Matchlist created will be marked as the isDefault Matchlist. The isDefault Matchlist is automatically used in workflows unless specified otherwise.

2

Set Screening Parameters

Define the match rules and actions for when a match is found, such as the riskScore or action. The currently available actions include BLOCK, ALERT, ALLOW, REVIEW, and NONE.

ParameterDescription
BLOCKPrevents the entity from proceeding in the workflow.
ALERTFlags the entity for review but allows the workflow to continue.
ALLOWExplicitly allows the entity to proceed without restrictions.
REVIEWMarks the entity for manual review before proceeding.
NONENo action is taken; the entity proceeds without any flags or restrictions.
3

Retrieve Matchlists

Use the endpoint GET /v2/matchlists to retrieve a list of all Matchlists. This includes details such as matchlistId, name, description, isDefault, action, riskScore, and state.

Example Response

1{
2 "requestId": "01HN9XHZN6MGXM9JXG50K59Q85",
3 "matchlists": [
4 {
5 "matchlistId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
6 "name": "Blocklist",
7 "description": "Prevents the entity from proceeding in the workflow.",
8 "isDefault": true,
9 "action": "BLOCK",
10 "riskScore": 1,
11 "state": "ACTIVE",
12 "createdBy": "operator-12345", // Example operatorId
13 "createdAt": "2025-04-01T01:39:07.182Z",
14 "updatedBy": "operator-67890", // Example operatorId
15 "updatedAt": "2025-04-01T01:39:07.182Z"
16 }
17 ]
18}
4

Add Entries

Populate the Matchlist with entries using the endpoint POST /v2/matchlists/{matchlistName}/entries, each consisting of attributes such as name, email, or address.

Example Request
1// Add a batch of entries to the Matchlist
2{
3"batchName": "blocklist-1.csv", // Name of the batch for tracking purposes
4"entries": [
5{
6 "entityId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", // Unique identifier for the entity
7 "reference": "CERT-BAD-ACTOR-1234-5678", // Reference for the entry
8 "reasons": [
9 "FREQUENT_USE_EMAIL" // Reason for adding the entity
10 ],
11 "attributes": [
12 {
13 "type": "ENTITY_TYPE",
14 "value": "INDIVIDUAL"
15 },
16 {
17 "type": "IND_DISPLAY_NAME",
18 "value": "John Doe"
19 },
20 {
21 "type": "EMAIL_ADDRESS",
22 "value": "john.doe@example.com"
23 }
24 ]
25}
26],
27"comment": {
28"text": "Update after speaking to security over phone directly" // Additional context for the entry
29}
30}

Note: Refer to the Reason Codes section for a list of predefined reason codes.

Managing Entries

Learn how to retrieve, search, update, and manage entries within your Matchlists. This section covers the endpoints and methods available for handling Matchlist entries effectively.

Retrieve Entries

Get a list of entries using the endpoint GET /v2/matchlists/{matchlistName}/entries/{entityId}.

Search Entries

Use the endpoint GET /v2/matchlists/{matchlistName}/entries/search to search for entries based on matchlist attributes. Note that attribute comparisons are case-insensitive (e.g., “John” equals “john”).

Retrieve a Matchlist Entry

Retrieve a matchlist entry using the endpoint GET /v2/matchlists/{matchlistName}/entries/{entityId}.

Modify Entries

Use endpoint PATCH v2/matchlists/{matchlistName}/entries/{entityId} to update a matchlist entry’s non-attribute fields such as reference, state, reason.

Updating the attributes field of a Matchlist entry is not allowed. Instead, retrieve the entry details, then create a new entry with the original and updated values. The old entry should have its state changed to DELETED.

Add Individual to Matchlist

Add an individual to the Matchlist using the endpoint POST /v2/matchlists/{matchlistName}/entries/addEntity.

Remove Individual from Matchlist

Remove an individual from a Matchlist using the endpoint PATCH /v2/matchlists/{matchlistName}/entries/removeEntity. This automatically sets the state of the entry to DELETED.

Screening Workflow

Integrate Matchlists into your onboarding workflow to enhance risk assessment and decision-making. The following steps outline how to effectively utilize Matchlists in your KYC processes.

1

Configure Workflow

Ensure the Matchlist step is included in your onboarding workflow configuration. This step is crucial for screening entities against the Matchlist during the onboarding process.

2

Trigger Screening

Use the endpoint POST /v2/individuals/{entityId}/serviceprofiles/KYC/workflows/matchlist/execute to trigger the workflow and automate the assessment. This step will screen entities against the Matchlist and apply predefined actions based on the match results.

3

Review Results

Review the results of the screening process. The results will include details about any matches found, including the matchlist name, entryId, and a list of attributes that triggered the match.

4

Assess Matches

When a match is detected, classify it with a selection of manual statuses for further action.

Manual StatusDescription
TRUE_POSITIVEThe match is confirmed as accurate and indicates a valid risk.
FALSE_POSITIVEThe match is determined to be incorrect and does not indicate a valid risk.
TRUE_POSITIVE_ACCEPTThe match is accurate, but the entity is allowed to proceed.
TRUE_POSITIVE_REJECTThe match is accurate, and the entity is rejected from proceeding.
UNKNOWNThe match requires further investigation to determine its validity.
UNKNOWN_ACCEPTThe match is under investigation, but the entity is allowed to proceed.
UNKNOWN_REJECTThe match is under investigation, and the entity is rejected from proceeding.
5

Update Workflow

If necessary, update the workflow configuration to refine the screening process. This may include adjusting match rules, actions, or entry attributes.

6

Monitor and Maintain

Regularly monitor the Matchlist for new entries or updates. Note that the Matchlist Step will not rerun automatically. It needs to be triggered again to rerun the screening process. Ensure that the Matchlist remains current and relevant to your KYC processes.

Reason Codes

The following table outlines the predefined reason codes available for Blocklists. Customers can add their own reason codes if needed.

Reason CodeMatchlist TypeDescription
SYNTHETIC_IDBLOCKLISTUsed when the identity is suspected to be synthetic.
SUSPECTED_FRAUDBLOCKLISTUsed when fraud is suspected.
SUSPECTED_ID_THEFTBLOCKLISTUsed when identity theft is suspected.
SUSPICIOUS_DATABLOCKLISTUsed when the data provided is suspicious.
ID_USED_IN_KNOWN_FRAUDBLOCKLISTUsed when the ID has been used in known fraud incidents.
ID_THEFT_VICTIMBLOCKLISTUsed when the individual is known to be a victim of identity theft.
REQUESTED_BLOCKBLOCKLISTUsed when a block has been requested.
SUSPECTED_FRAUD_ADDRESSBLOCKLISTUsed when the address is suspected of being associated with fraud.
SUSPECTED_FRAUD_NAMEBLOCKLISTUsed when the name is suspected of being associated with fraud.
SUSPECTED_FRAUD_EMAILBLOCKLISTUsed when the email is suspected of being associated with fraud.
SUSPECTED_FRAUD_PHONEBLOCKLISTUsed when the phone number is suspected of being associated with fraud.
SUSPECTED_FRAUD_DEVICEBLOCKLISTUsed when the device is suspected of being associated with fraud.
FAKE_FACEBLOCKLISTUsed when a fake face is detected.
FAKE_IDBLOCKLISTUsed when a fake ID is detected.
FREQUENT_USE_ADDRESSBLOCKLISTUsed when the address is being used frequently.
FREQUENT_USE_NAMEBLOCKLISTUsed when the name is being used frequently.
FREQUENT_USE_EMAILBLOCKLISTUsed when the email is being used frequently.
FREQUENT_USE_PHONEBLOCKLISTUsed when the phone number is being used frequently.
FREQUENT_USE_DEVICEBLOCKLISTUsed when the device is being used frequently.
FREQUENT_USE_FACEBLOCKLISTUsed when the face is being used frequently.
SUSPECTED_MONEY_MULEBLOCKLISTUsed when the individual is suspected of being a money mule.
NON_PAYMENTBLOCKLISTUsed when non-payment is the reason for adding the entity to the matchlist.

A Note on Duplicate Entries

To ensure data integrity, the Matchlist system enforces strict rules to prevent duplicate entries. These rules apply to both entityId and specific attribute combinations, depending on the entity type.

Key Principles

  • Unique entityId: Each entry must have a unique entityId. Attempting to create an entry with an existing entityId will result in rejection.
  • Attribute Combinations: Duplication checks also apply to specific attribute combinations, which vary by entity type:
    • Individual Entity Type:
      • The combination of IND_GIVEN_NAME, IND_FAMILY_NAME, and IND_DATE_OF_BIRTH must be unique.
    • Organization Entity Type:
      • The combination of ORG_NAME and ORG_REGISTERED_COUNTRY must be unique.
    • The combination of DOC_PRIMARY_IDENTIFIER and DOC_TYPE must be unique.
    • At least two attributes from the following set must be unique: ADDR_STREET_NUMBER, ADDR_STREET_NAME, ADDR_POSTAL_CODE, and ADDR_COUNTRY.
  • Case Insensitivity: Attribute comparisons are case-insensitive (e.g., “John” equals “john”).

Important Considerations

  • Entries without an entityId can still be created, but the attribute uniqueness rules will apply.
  • If an entry violates the duplication rules, it will be rejected to maintain data integrity.
  • The system prioritizes preventing duplication based on the defined rules to ensure accurate and reliable screening results.

By adhering to these rules, the Matchlist system ensures that each entry is unique and avoids conflicts or redundancies in the screening process.

Integration Instructions

Prerequisites

  • Access to FrankieOne API.
  • Configured Matchlist with defined attributes and match rules.
  • Ensure your API keys are active and configured for access.

Troubleshooting

  • Issue: Unable to create a Matchlist entry.
    • Solution: Ensure all required attributes are provided and avoid duplicates.
  • Issue: No matches found during screening.
    • Solution: Verify that the correct Matchlist and attributes are being used.

Additional Resources