Introduction to Monitor

Explore API

Monitor detects if your customers are on government watchlists, using modern APIs that reduce false positives and increase efficiency. Monitor screens users against a number of sanction and PEP lists. Sanction lists are updated daily and can be used for daily automated re-scans. Any hits will be exposed via both a user-friendly dashboard UI and via API, for use with either manual or automated review workflows. Monitor also integrates directly with Identity Verification for an end-to-end verification and KYC solution.

Monitor can be used to screen end users in any country. To integrate with Monitor, your company must be based in the US (support for additional countries coming soon).

The first step to integrating is logging into the dashboard and accessing the 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.

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.

The number of programs you wish to maintain will vary based on the complexity of your organization. Many companies choose to split up programs such that each program aligns to the compliance ownership within their organization and each reviewer will only see programs they are responsible for. 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.

If your use case involves an ongoing relationship with your customers, Plaid recommends creating at least two programs -- one with rescan enabled for active customers, and one with rescan disabled, for former customers. For more details, see Monitor fee schedule.

Once your first program is created, you can start your integration.

This integration overview describes the process for using a Dashboard-based review workflow, which is the most common way to use Monitor. The review process can also be performed using the API; see the API reference for details.

1. If you are already using Identity Verification, you can use the Enable screening setting in the Identity Verification setup flow to automatically assign users to a Monitor program after they have completed verification. If not using Identity Verification, create your customer object using /watchlist_screening/individual/create or /watchlist_screening/entity/create ; while not required, it is recommended to specify a client_user_id, which should refer to an internal ID in your database, to help associate screening with your customer in the future.
2. Once a user or entity has been checked against the screening program, you will receive a webhook, SCREENING: STATUS_UPDATED.
3. Upon receiving the webhook, call /watchlist_screening/entity/get or /watchlist_screening/individual/get and check the status flag on the response.

• If it is cleared, your customer either did not appear on any of your target screening lists, or they received a hit but it has been dismissed by a reviewer as invalid.
• If it is pending_review, your customer received a hit and is pending review.
• If it is rejected, your customer received a hit that has been confirmed by a reviewer as a valid match.

This guide assumes that you will be using the dashboard for reviewing hits, but you can also re-create any aspect of the dashboard in your internal applications via the API.

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. If using an API-based review workflow, 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.

Monitor updates screening lists daily and 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 that a reviewer log in daily to check the review status on the dashboard. If you prefer to be alerted when a hit is found or to handle hits via automation, you can set up a daily automated job to check /watchlist_screening/individual/hit/list or /watchlist_screening/entity/hit/list once a day to poll any of the screenings that end up in this queue. Then use the associated client_user_id or id to tie the hit back to your internal database and determine if action is required.

Plaid will also fire webhooks to alert you when any new hits are found. Webhooks will contain the watchlist screening id, which you can use to go retrieve any watchlist screening hits that are pending review.

• 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, this can result in false negatives or false positives (for example, broad searches based on incomplete names).

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:

Note that the Sandbox environment sanction and watchlist dataset may be out of date. Make sure all real checks are carried out on the live Production environment.

To learn more about building with Monitor, see the Monitor API Reference.

If you're ready to launch to Production, see the Launch checklist.