Lists

Lists are sets of values you keep in the dashboard under Configure → Lists. Some decline a verification automatically. Others do nothing until one of your decision rules asks about them.

Lists are separate for each environment. A list you fill in Sandbox does not exist in Production.

Lists are managed in the dashboard. There is no public API for them yet.

Custom lists

A custom list is a list you name and fill yourself. It holds one type of entry, and your workflow rules can ask whether a verification is on it. Typical uses:

• A list of staff email addresses, so internal test sign-ups go to review instead of approval.
• A list of user references you want checked by a person every time.
• A list of countries you serve, so anything else is sent to review.
• A list of office IP addresses, so sign-ups from your own network are easy to tell apart.

A custom list never declines or approves anything on its own. Until a rule reads it, it has no effect.

Create a list

1. Open Configure → Lists and select Create list.
2. Give it a name and, if you like, a description.
3. Choose what it holds. This cannot be changed afterwards.

You need the identity:manage permission to create or change a list, and identity:read to see one.

You can keep up to 50 custom lists per environment, each with up to 10,000 entries.

Entry types

A few details worth knowing:

• Email addresses and phone numbers are stored so they can be matched but not read back. The list shows each one partly hidden. To find one, type it in full.
• Email and phone lists only match a contact the applicant proved with a code. A typed, unconfirmed address never matches. Your workflow needs the email or phone verification step for these lists to be useful.
• User references are compared exactly as you send them, including upper and lower case.
• ID numbers ignore spaces, hyphens, dots and case. The same number on a different ID type is a different document.
• IP addresses are single addresses. Ranges are not supported.
• Device fingerprints are the ones shown on a verification's Device Intelligence card.
• When your backend submits verifications with a secret key, pass the applicant's connection as described in Create a verification, or IP address and device lists will have nothing to compare.

Add entries

Open the list and select Add entries. Countries are picked from a list. Everything else is typed or pasted, one value per line or separated by commas, up to 500 at a time.

• A value already on the list is left as it is.
• A value that is not valid for the list's type is not added. It stays in the box so you can correct it, and the rest are added.
• For ID numbers, choose the ID type first. For businesses, choose the country of the register first.

Use a list in a rule

Every custom list has a key, made from its name when you create it: "VIP customers" becomes vip_customers. A rule reads the list through the field list.<key>. The list's page shows the field and lets you copy it.

In the workflow builder, open Decisioning, add a rule, and choose the list from the Lists group. The field has three possible values:

For example, to send anyone on a list called "Manual review" to review:

{ "field": "list.manual_review", "op": "eq", "value": true }

Because unknown never matches, a rule such as list.served_countries eq false only fires when a country is known and is not on the list. To also catch verifications with no known value, add a second condition using the exists operator.

Rename or delete a list

You can rename a list or change its description at any time. The key does not change, so rules that read the list keep working.

A list cannot be deleted while a workflow rule reads it. Remove the rule from the workflow first, including from its unpublished draft, then delete the list. Deleting a list deletes its entries for good.

Publishing a workflow is refused if one of its rules reads a list that does not exist in that environment. Create the list there, or change the rule.

High-risk countries

One custom list is built in: High-risk countries. It starts with the countries on the FATF call-for-action and increased-monitoring lists, and you can add or remove countries.

Rules read it through four fields:

A country that is not known gives an unknown value, which never matches.

Blocklists

Blocklists are built in, one for each entry type: face, ID number, IP address, user, phone number, email address, device and business. A verification that would otherwise pass and matches an entry is declined.

The applicant is told only that the verification could not be completed. The reason is never shown to them, because it would tell a fraudster what to change. Your webhook and the verification result carry a reasonCode naming the list that matched: face_blocklisted, document_blocklisted, ip_blocklisted, user_blocklisted, phone_blocklisted, email_blocklisted, device_blocklisted or business_blocklisted.

You can add an entry from Configure → Lists, or straight from a verification with Add to blocklist.