Screening Integration Guide

This guide will explain how to approach integrating Cognito Screening

Creating a program

The first step to integrating is logging into the Cognito dashboard. Navigate to the New Program page. Programs help you to define the settings and workflows for conducting screenings in your organization. For example, you can define match sensitivities, which lists are being screened, and the behavior of ongoing screening.

The number of programs you wish to maintain will vary based on the complexity of your organization. Some common ways of splitting up programs are by product vertical (“Cardholders”, “Personal Loans”, “FDIC Accounts”, etc), geography (“US Cardholders”, “European Cardholders”, etc), risk level (“High Risk Individuals”, “Medium Risk Individuals”), or a combination of the above. For ideas about how to split customers up by risk, OFAC has prepared a helpful risk matrix that can provide a baseline for setting initial risk level and then modifying the risk level based on ongoing user behavior.

Cognito Screening allows you to start a customer in one program and then move them to a different one. Customers cannot be in multiple programs at once. Once your first program is created, you can start your integration.

Basic integration overview

You can build a skeleton integration that just lets you see what hits are associated with a customer. To get the full value out of Cognito’s Screening system, you should extend your integration using the other sections of this guide, but this will serve as a strong first step.

1. Create your customer object using /screenings. To make this API call you’ll need to use the program_id of the program you created in an earlier step to associate with them. We recommend also setting a customer_reference which should refer to an internal ID in your database to help associate this with your customer in the future.
2. Check the status flag on the return. If it is cleared, your customer did not appear on any of your target screening lists. If the result is pending_review, continue.
3. Call /screenings/:id/hits to see what potential hits are associated with your customer

Test cases for screening

For the time being, our sandbox environment supports a full dataset. Searching for sanctioned individuals should show up as they would in the live mode for the purposes of testing. If you need example test cases, here is some input data that you can use:

Warning: The sandbox environment sanction and watchlist dataset may be out of date. Make sure all real checks are carried out on the live environment.

Building a reviewer workflow

By integrating a few more APIs, you can unlock additional benefits that make Cognito Screening extremely powerful for your business. These benefits include having a built-in compliance review workflow for potential hits, automated audit trails, and hits that improve in quality over time by integrating a feedback loop with our systems. This guide assumes that you will be using the Cognito dashboard for reviewing hits, but our APIs allow you to re-create any aspect of our dashboard in your internal applications.

Assigning hits to reviewers

Once your basic integration is complete, any customers who have potential hits will start showing up on your dashboard. You can assign any screenings that are pending review via API to different reviewers in your organization. You can get a full list of users and their associated user IDs by calling /users and then edit your screening assignee to point to the desired user/reviewer.

Automatically handling reviews

Some potential hits do not necessarily require manual review. As you identify cases that can be programmatically ruled out, you will be able to add a step that reduces the number of reviews that your organization needs to handle. These will vary based on your desired internal risk levels, but some organizations will programmatically review hits that have an associated country code or date of birth for a match and automatically submit a review ruling out the suspected false positives.

Note: not all watchlist entries provided by various governments and list issuers have the same level of data richness. Some will have names, dates of birth, passports, and addresses associated with them, and others will only have names. When you are building your matching logic, make sure to take into account that no_data is different from no_match. no_data means that the list issuer didn’t supply data against which to match. no_match means that data was provided by the list issuer and it did not match the information provided by your customer.

Based on your risk level, determine which hits are accurate and which are false positives using the analysis object attached to each hit. Create a Review for this customer by calling /screenings/:id/reviews and setting confirmed_hits and dismissed_hits using the IDs of the returned hits. At this point you can update the screening status to cleared or rejected if there are no remaining hits that require manual review.

Preparing for ongoing screening

Cognito Screening supports ongoing daily rescans of your entire customer base to alert you when new hits are discovered. This system is designed around the concept of a living pending_review queue that is updated whenever new hits are found. We recommend setting up a daily job to check this endpoint once a day to poll any of the screenings that end up in this queue and using the associated customer_reference or id to tie it back to your internal database to determine if action is required.

Additionally, we have added support for webhooks to alert you when changes occur. Webhooks will contain the Screening id, which you can use to go retrieve any ScreeningHits that are pending review.

Additional considerations

• Adding Cognito Screening is not the only part of a successful Anti-Money Laundering program. We highly recommend that you consult with an AML professional to help you build all of the policies and procedures required. AML regulations vary widely for different jurisdictions and industries.
• Cognito Screening does not blanket ban any countries on your behalf. Some sanction programs effectively prohibit working with certain jurisdictions and it is up to you to ensure that you are only working with individuals from countries that are appropriate for your desired risk levels. For instance, here is an article from OFAC about a “Country List”
• Cognito Screening is built to make it difficult to overconstrain a search and therefore have false negatives. That being said, if your data inputs are not quality controlled to at least a basic extent prior to sending them to us, this can result in false negatives or false positives (for example, broad searches based on incomplete names).
• We store a log of all hits, status changes, assignments, and search profile changes (editing names, dates of birth, etc) completed both on the dashboard and API. You can get a copy of past revisions at any time by calling /screenings/:id/revisions.