Introduction to Monitor
Sanction, PEP, and watchlist screening for anti-money laundering compliance
Explore API
API Reference
View Monitor requests, responses, and example code
View Monitor APIQuickstart
Learn about Plaid's key concepts and run starter code
Get startedOverview
Monitor detects if your customers are on government watchlists, using modern APIs that reduce false positives and increase efficiency.
To check your human customer against various sanction and PEP lists, create a Watchlist Screening
. You can update previously created screenings for use with ongoing screening, see past versions of a screening profile, view any hits associated with the screening, and create and view reviews regarding past hits.
Creating a program
The first step to integrating is logging into the Plaid dashboard. Navigate to the Monitor New Program page. Programs help you to define the settings and workflows for conducting watchlist 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.
Monitor 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
As a first step, 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 Monitor, extend your integration using the other sections of this guide.
- Create your customer object using
/watchlist_screening/individual/create
. To make this API call you’ll need to use thewatchlist_program_id
of the program you created above. While not required, it is recommended to specify aclient_user_id
, which should refer to an internal ID in your database, to help associate screening with your customer in the future. - Check the
status
flag on the response. If it iscleared
, your customer did not appear on any of your target screening lists. If the result ispending_review
, continue. - Call
/watchlist_screening/individual/hit/list
to see what potential hits are associated with your customer.
Test cases for screening
Sandbox supports a real-world dataset, meaning that sanctioned individuals should show up just as they would in Production. Some example sanctioned individuals and entities you can use for testing purposes include:
Individual Name | Date of Birth | Location | Document |
---|---|---|---|
Joseph Kony | 1964-09-18 | CF | |
Jianshu Zhou | 1971-07-15 | CN | E09598913 |
Ermias Ghermay | Any day in 1980 | LY |
Entity Name | Location | Document |
---|---|---|
Iran Mobin Electronic Development Company | IR | 10103492170 |
МИНСКИЙ ОТРЯД МИЛИЦИИ ОСОБОГО НАЗНАЧЕНИЯ | BY | |
Islamic Radio And Television Union | AF |
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 more endpoints, you can unlock additional functionality, such as built-in compliance review workflow for potential hits, automated audit trails, and hits that improve in quality over time by integrating a feedback loop. This guide assumes that you will be using the Plaid dashboard for reviewing hits, but you can also re-create any aspect of the dashboard in your internal applications via the API.
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 to different reviewers in your organization. You can get a full list of users and their associated user IDs by calling /dashboard_user/list
and setting your screening assignee
to the desired 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.
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 /watchlist_screening/entity/review/create
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
Monitor 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 client_user_id
or id
to tie it back to your internal database to determine if action is required.
Plaid will also fire webhooks to alert you when changes occur. Webhooks will contain the watchlist screening id, which you can use to go retrieve any watchlist screening hits that are pending review.
Additional considerations
- Adding Monitor 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.
- Monitor 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"
- Monitor 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).
Testing Monitor
Monitor is currently accessible only to customers in the Early Access program. This access limitation applies across all environments (including Sandbox). If you are interested in trying Monitor when it becomes available to you, contact your Plaid Account Manager.
Next steps
To learn more about building with Monitor, see the Monitor API Reference.
Feedback
If you have feedback to provide, please let us know in our Developer Feedback repo on GitHub (beta).