.png?sv=2019-07-07&sig=2zFSID3I3ut3zb9oj4aeuIpTcRqB9rpg1sGTt8%2Bc3I8%3D&spr=https%2Chttp&st=2023-06-03T07%3A53%3A16Z&se=2023-06-03T08%3A03%3A16Z&srt=o&ss=b&sp=r){kind=logo}
Watchlist Match cases
- 26 Aug 2022
- Print
- Comment
- PDF
Watchlist Match cases
- Updated on 26 Aug 2022
- Print
- Comment
- PDF
Article Summary
Overview
The Watchlist Match case type provides a place to review any counterparties on transactions that are found to be on a watchlist when performing the transaction. These cases are automatically opened by the system when an Ad Hoc Watchlist check is run when a FinTech performs a transaction between a customer and an external counterparty. The case displays the two entities in the transaction (the FinTech customer and the external counterparty), along with the watchlist match information for the lists the external counterparty was found to be on, allowing for review and determining if the transaction should be allowed or not.
When to use the Watchlist Match case type
The Watchlist Match case type will be automatically created when an Ad Hoc Watchlist check is run by the FinTech when performing a transaction between a customer and an external counterparty if the external counterparty is found to be on any lists. This check can be run for outgoing ACH transfers, wire transfers, or other transactions where the name of the counterparty is known but they are not a customer of the FinTech.
While the watchlist checks will be run on the external counterparty, it will not count as full KYC on the counterparty, and the counterparty will continue to have a KYC status of UNVERIFIED.
These cases will be actionable by the FinTech for review and deciding whether it is a valid watchlist hit match and if the transaction should be allowed to continue through. All actions and decisions made on the case will be made by the FinTech and viewable by the Bank for oversight purposes.
To help decision Watchlist Match cases, case system users can review the information displayed in the UI and check the provided links to the customer info and watchlists themselves.
What's displayed for the Watchlist Match case type
Sender
The name of the sender on the transaction, with a link to their Customer Details page.
Receiver
The name of the receiver on the transaction, with a link to their Customer Details page.
Watchlist matches
The detailed information about the watchlists the Receiver was found on, the information of theirs that matched, the offense that got them added to the list, a link to the watchlist or watchlist website, and any other details available.
View details
This will display a JSON representation of the Watchlist hit information.
Match field options and their meanings
| Match field type | Description | Example |
|---|---|---|
| nameExact | Exact Name Match | Robert & Robert |
| nameFuzzy | Fuzzy Name Match | Jennifer & Jennifre |
| nameEquivalent | Name match based on the same name meaning | Husain (حسین) & Hussein (حسین) |
| Jacklyn & Jacqueline | ||
| James & Jimmy | ||
| Bank, Banque, & Banca | ||
| Automovil & Automobile | ||
| Vladimir Putin & Владимир Владимирович Путин | ||
| removedPersonalTitle | Partial name match due to the removal of an honorary title within the input name such as (Dr, Mr, Queen, etc.). | Dr Miles & Kevin Miles |
| nameInitialized | Name match based on initials | H.B. Hawala & Haji Basir Hawala |
| namePhonetic | Name match based on phonetic similarity | Renault & Reneaux |
| akaExact | Exact alias match | Joaquin Guzman & Chapo Loera |
| akaFuzzy | Fuzzy alias match | Joaquin Guzman & Charo Loeta |
| akaEquivalent | Alias match based on the same alias meaning | Peter Tobin & Pat McLaughlin |
| akaPhonetic | Alias name match based on phonetic similarity | Ibrahim Anis & Abraham Anees |
| dobExact | DOB matches year, month, and day. | 1988-02-23 & 1988-02-23 |
| dobFuzzy | DOB is within one year (+/-) from the entered DOB. | 1988-02-23 & 1987-02-24 |
| 1988-02-23 & 1987 | ||
| 1988-02-23 & 1988-06-14 | ||
| 1988-02-23 & 1989-02-22 | ||
| dobNotOnRecord | The source does not contain a DOB for the matched entity |
Reviewing and decisioning cases
There are actions available on the Sender, Receiver, and the case itself.
Sanction Sender
Take this action to change the Sender’s Customer Status to ‘Sanctioned’ and to change all of their accounts into ‘Restricted’ status, meaning they can no longer perform actions like opening a new account and also cannot transact with any of their accounts.
Sanction Receiver
Take this action to change the Receiver’s Customer Status to ‘Sanctioned’ and to change all of their accounts into ‘Restricted’ status, meaning they can no longer perform actions like opening a new account and also cannot transact with any of their accounts.
NoteIn most instances the Receiver will not have any accounts as they will be an external counterparty.
Mark as OFAC Match
Take this action to mark the match as valid, which will put the Receiver into a 'Sanctioned' status, meaning they cannot open new accounts or transact. This will also close the case.
Mark as False Positive
Take this action to mark the match as not valid, and close the case without changing the status of the Receiver.
Was this article helpful?