3.4. Screening Program Design and Pre-Implementation Testing
The process of screening information collected and maintained by an LFI on the parties it does business with and their related parties is referred to as “name screening”. The concept encompasses any data set within the LFI’s operations, separate from its transaction records, that may present a relevant sanctions risk indicator or be conducive to detection through screening on a periodic basis and prior to entering into a customer relationship. The process of screening a movement of value—including funds, goods, or assets— out of, into, or through the LFI between parties or accounts is referred to as “transaction screening”.
Where automated systems are employed, LFIs should perform pre-implementation testing of sanctions screening systems, using historical transaction data as appropriate. Such testing should include system integration testing to ensure compatibility of the sanctions screening system with source systems and other sanctions compliance infrastructure and user acceptance testing to ensure that the system performs as anticipated in the operating environment. Material data mapping, transaction coding, and other data quality issues, as well as irregularities in sanctions screening model performance and outputs, identified through pre-implementation testing should be prioritized for remediation and subject to re-testing prior to the deployment of a sanctions screening system.
The following sections provide additional detail about system design and pre-implementation testing as these relate specifically to name screening and transaction screening processes respectively.
3.4.1. Name Screening
As per the Executive Office’s Guidance on TFS for Financial Institutions and Designated Non-financial Business and Professions,5 name screening (whether automated or manual) must be performed prior to the onboarding of a customer and/or the facilitation of an occasional transaction and on an ongoing basis (at least daily) thereafter. As indicated above, name screening encompasses any data set within the LFI’s operations, separate from its transaction records, that may present a relevant sanctions risk indicator or be conducive to detection through screening on a periodic basis and prior to entering into a customer relationship.
Data relevant for name screening may include:
• Customer data, including the names and addresses of existing or prospective customers, their beneficial owners, and other related or connected parties whose information is collected pursuant to risk-based due diligence procedures;
• Employee data, including employee names and addresses;
• Third-party service provider data, including the names, addresses, and beneficial owners of an LFI’s vendors, landlords, and tenants, as applicable;
• International Securities Identification Numbers (“ISINs”) and other sanctions-relevant identifying features of assets held in custody by the LFI; and
• Recipients of the LFI’s corporate donations or sponsorship.
Not all data elements within an LFI’s records are relevant for sanctions screening. When determining what reference data should be screened, an LFI should identify the data within its operations and records that is relevant to sanctions risk, determine how it is relevant, ensure it is conducive to effective screening, and differentiate it from data that is not relevant or suitable to screening. For example, the names of individuals and entities with whom the LFI has a relationship are relevant for screening against name-based sanctions lists but not for geographic (region- or country-based) sanctions programs. Likewise, while the data contained in the addresses of such individuals and entities may not be directly relevant for screening against name-based sanctions lists, this data may assist in differentiating a true name match from a false name match when reviewing apparent name screening hits.
An LFI should also define other data elements (such as date of birth, nationality, and place of birth) that may be relevant for sanctions screening in some situations but not others. Date of birth, for example, is relevant as a distinguishing factor to assess a potential or a true match from a false match on an individual and might be used for screening in combination with another attribute, such as a name. In each case, LFIs should weigh up the relative incremental value of screening the data element against the reliability of the data and whether an alert against the data will meaningfully assist in detecting or preventing a sanctions risk that would not be reasonably detected through other controls, or by screening different data attributes. The screening criteria used by LFIs to identify name variations and misspellings should be based on the level of sanctions risk associated with the particular product or type of transaction. For example, in a higher-risk area with a high volume of transactions, the LFI’s interdiction software should be able to identify close name derivations for review.
An LFI’s reference data is typically maintained in electronic files and is most effective when screened through an automated process and repeated at defined intervals. The use of manual screening can be considered when the risk is sufficiently low and where the reference data cannot be sourced reliably, either electronically or in a format necessary for automated screening. For example, if an LFI has identified only a small population of names requiring screening, it may choose to forego investing in an automated screening system and instead manually input these names into an online screening filter.
5 Available at: https://www.uaeiec.gov.ae/en-us/un-page#.
3.4.2. Transaction Screening
LFIs should screen all payments prior to completing the transaction (also referred to as “real-time” screening), utilizing all transaction records necessary to the movement of value between parties and at a point in the transaction where detection of a sanctions risk is actionable to prevent a violation. The LFI should then identify which attributes within those records are relevant for sanctions screening and the context in which they become relevant. As with name screening, names of parties involved in a transaction are relevant for list-based sanctions programs, whereas addresses are more relevant to screening against geographic sanctions programs but can be used as identifying information to help distinguish a potential or true match from a false match under a list-based program. Other data elements, such as bank identification codes, may be relevant for both list-based and geographic sanctions programs.
Some data elements are more relevant for sanctions screening purposes when found in combination with other attributes or references. For example, detection of sectoral sanctions risk typically requires detection of multiple factors, such as those where both the targeted parties and the prohibited activities are involved. Where automated controls alone may not be capable of detecting both factors simultaneously, manual review of the associated activity may be required alongside review to confirm a true match to applicable sanctions lists. In addition, certain data elements offer little or no risk mitigation through screening, for example, amounts, dates, and transaction reference numbers have no relevance from a screening perspective, although they may be relevant for TM or other risk management purposes.
Data relevant for transaction screening may include:
• The parties involved in a transaction, including the originator and beneficiary;
• Agents, intermediaries, and financial institutions involved in a transaction;
• Bank names, Bank Identifier Codes (“BICs”), and other routing codes;
• Free text fields, such as payment reference information or the stated purpose of the payment in Field 70 of a SWIFT message;
• ISINs or other risk-relevant product identifiers, including those that relate to sectoral sanctions identifications within securities-related transactions, as applicable;
• Trade finance documentation, including any:
o Importers and exporters, manufacturers, drawees, drawers, notify parties, and signatories;
o Shipping companies, vessel names and International Maritime Organization (IMO) numbers, names of parties associated with the vessel (including ship owners, charterers, and captains), and freight forwarders;
o Facilitators, such as insurance companies, agents, and brokers; and
o Financial institutions, including issuing, advising, confirming, negotiating, claiming, collecting, reimbursing, and guarantor banks.
• Geographic details, including:
o Addresses, countries, cities, towns, regions, ports, and airports (e.g., as contained within SWIFT Fields 50 and 59 or acquired through vessel tracking inquiries);
o Phone or fax numbers and web addresses, insofar as these contain geographic or other relevant details;
o Place of taking in charge, receipt, dispatch, delivery, or final destination;
o Country of origin, destination, and transshipment of goods or services; and
o Airport of departure or destination.
Transaction screening should be performed at a point in time where a transaction can be stopped and before a potential violation occurs. This typically occurs at a number of points in the lifecycle of a transaction, but certainly prior to executing any commitment to move funds. Particular attention should be directed to any points within the transactional process where relevant information could be changed, modified, or removed in order to undermine screening controls.
Transactional records are typically found in large volumes and within business processes predicated on speed of execution. These transaction types are generally in electronic form and conducive to systemic, automated screening. Some transaction types, however, still rely on documentation in various formats and varying methods of presentation. LFIs may employ text analytics tools such as optical character recognition (“OCR”) that automatically convert paper documentation into electronic data that can then be screened against applicable sanctions lists, but some paper-based transactions, such as documentary trade finance transactions, may require manual screening processes, where relevant information is physically added into a system for screening. OCR requires quality assurance validation to ensure the information has been captured fully and accurately. Certain paper-based transactions, such as paper cheque clearing, where the volumes can be high and the manual screening process creates high rates of errors, may rely on controls other than screening, such as CDD/KYC processes, where the sanctions risks for the product are assessed as being low.