Validating AML/Sanctions Models – A Case Study

1

Validating AML/Sanctions Models:

A Case Study BY Chandrakant Maheshwari

The views and opinions expressed in this paper are of the author and do not represent any other organization(s) the author is associated with.

Validating AML/Sanctions Models – A Case Study

2

Contents

Introduction .................................................................................................................................................. 3

Why a TransactionMonitoring System Is a Model .................................................................................... 3

Analysis Based On BSA/AML Risk Assessment .............................................................................................. 5

Leveraging Risk Assessment In Validation of AML/Sanctions Models ...................................................... 5

Review of Customer Demographics .......................................................................................................... 5

Review of Transaction-Monitoring Rules ...................................................................................................... 6

Review of Transaction-Monitoring Rules Via Customer Behavior ............................................................ 6

Deposits are structured through multiple branches of the same bank ................................................ 7

Deposits are structured through groups of people who enter a single branch at the same time ....... 7

Customer repeatedly uses a branch location that is geographically distant from his home or office . 7

Review of the Transaction-Monitoring Rules Via Alerts ........................................................................... 7

Review of the Transaction-Monitoring Rules Via Notes ........................................................................... 9

Review of Sanctions Models ......................................................................................................................... 9

Customer Information Screening ............................................................................................................ 10

A Short Note On Jaccard's Distance .................................................................................................... 10

A Short Note On Levenshtein's Distance Method .............................................................................. 11

Transactions Screening ........................................................................................................................... 12

Leveraging FFIEC OFAC Sanctions Validation ...................................................................................... 12

Conclusion ................................................................................................................................................... 13

References .................................................................................................................................................. 14

Validating AML/Sanctions Models – A Case Study

3

Introduction

Banks and regulators are actively working together to ensure that the criminals do not use banking

platforms to convert their illegitimate earnings into legal money. Another responsibility of the banks,

especially U.S.-based banks, is that persons listed in Specially Designated Nationals (SDN) from the Office

of Assets Control (OFAC) do not use their banking platform.

Though regulators have not prescribed the banks on how they can ensure that their banking platforms

are not abused by the criminals to launder dirty money, strict regulations, such as NYDFS Part 504 (1),

have ensured that banks perform adequate due diligence on their customers and transaction activities.

To ensure efficient due diligence, banks are using various software systems to monitor their customers

and transactions. The specifications (such as number of monitoring rules, their category) and parameters

(thresholds or the monitoring rules) of these systems are based on the banks' risk assessment from the

money laundering perspective that depends on the given bank's customer base, product offerings,

demographics, etc. Often, these systems fall into the category of models and require periodic validation

and monitoring of their specifications and parameters. The ownership and maintenance of such systems

are the responsibility of the banks' compliance departments. The transaction-monitoring, customer risk

rating, and sanction-screening systems are collectively called "AML models" in this paper.

Many AML practitioners do not agree that the transaction-monitoring system is a model, so the first

segment of this paper is devoted to explaining why it is. In the later part of the paper, we discuss how risk

assessment can be leveraged to develop data analytics approaches to form hypotheses that can be used

by the validator to assess the function of the transaction-monitoring and customer risk rating model.

The other key parts of AML model validation are Above the Line (ATL) and Below the Line testing (BTL) of

the monitoring rules, data validation (accuracy, quality, completeness, etc.), model performance

monitoring, etc. These aspects are not discussed in this paper, because they are already discussed in detail

by the white paper titled, "AML Model Validation in Compliance with OCC 11-12," by Susan Devine (2).

Why a TransactionMonitoring System Is a Model

Often, it is a concern among many practitioners that because the transaction-monitoring models are often rules-based and do not involve any statistical process, that they are non-models. A model is defined by SR 11-7 guidelines (3). This is the guidance issued by the OCC on Model Risk Management framework.

As per SR 11-7 guidelines: …the term model refers to a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. A model consists of three components: an information input component, which delivers assumptions and data to the model; a processing component, which transforms inputs into estimates; and a reporting component, which translates the estimates into useful business information.

Validating AML/Sanctions Models – A Case Study

4

The following analogy explains how transaction-monitoring systems are models. Imagine a locker room

that contains a diamond at one end and a gate on the other end, and we want to protect the diamond

from intruders.

Figure 1

We decide to add thin laser beams that would raise an alarm in case any intruder tries to enter the room.

Assuming that the wall and the roof are indestructible, and the only way an intruder can enter the room

is through the gate, we would need to make the following decisions:

1. How many laser beams would be needed?

2. What would be the positions and angles of those laser beams?

3. Should the angle of the laser beams be static or changing?

We would make the above decisions after learning the following information:

1. The locker room's dimensions, i.e., height, length, and width

2. Possible size of the intruder; initially, we will assume that only an adult human being of a height

range of 5.5 to 6 feet can be our possible intruder

Based on the above information, suppose we decide that three laser beams would be adequate; hence,

we would have the following situation:

Figure 2

As the situation and perceived risk change, we have to redesign the laser beam layout. The following may

be the new situations and perceived risks we may observe:

1. There are human beings who are shorter than the previously assumed range.

2. There are news articles that mention that animals are being used to steal, and hence, they can be

used by criminals to steal the diamond.

3. Later, it may be found that with the advancement of technology, small robots and drones could

also be used to intrude and steal the diamond.

Validating AML/Sanctions Models – A Case Study

5

Now, replace: the above room with the products and services offered by the bank; the laser beams with

transaction-monitoring rules; intruders with the money launderers/financial criminals; the diamond with

the success in the money laundering activity; and new events with new product offerings, customers, and

their activities.

Based on the bank's risk assessment report, risk managers make decisions on the number and types of

transaction-monitoring rules required that would be adequate to protect their banking platform against

money laundering activities. The transaction-monitoring systems require:

1. Regular modification or addition of rules based on the latest risk assessment and new data that

comes from existing and new product lines, customer profiles, etc.

2. Periodic rule tuning1 and performance monitoring

Each assumption and subsequent decision requires analytical reasoning, which is based on data and needs

regular updates; hence, they are models.

Analysis Based On BSA/AML Risk Assessment

The purpose of a comprehensive risk assessment is to assess the enterprise-wide BSA/AML risk profile of the organization, including the bank and all subsidiaries. According to Davidek (4), at least since 2005, every depository financial institution has been required to perform and document its written BSA/AML risk assessment.

Leveraging Risk Assessment In Validation of AML/Sanctions Models

The risk assessment can serve as a valuable tool for the model validator in understanding the demographics of the bank's customers and their behavior; and thus, can help in independently identifying any pattern of suspicious activity. If any suspicious activity is identified, and the transaction-monitoring and customer risk rating models already have adequate rules to capture them, then this analysis would help in supporting the model's conceptual soundness, or else, based on the pattern's seriousness, the issue can be documented as a finding, and remediation from the compliance department can be requested.

The content provided herein is intended to offer guidance on forming a hypothesis by a validator that he/she could test against the existing model-based controls developed by the compliance department.

Review of Customer Demographics

Assuming that the bank has three categories of customers (namely: high-risk, medium-risk, and low-risk

customers), then, using the transactions and the customer database, the validator can review the

following aspects:

1. Distribution of customer transactions of various risk classes with respect to the bank's branches

1 Tuning is calibration Transaction Monitoring rule's threshold based on the bank's Risk Assessment.

Validating AML/Sanctions Models – A Case Study

6

a. This exercise would help the validator identify which of the bank's branches pose higher risk;

for example, it may be observed that some of the high-risk customers of the bank are using

some specific branches. The inference of the analysis should be triangulated with their locations

and High Intensity Drug Trafficking Area (6)/High Intensity Financial Crimes Area (7) data.

b. The validator should see if the existing AML model assumptions2 are considering these

observations via adequate alerts; thus, he/she could also review if the assumptions mitigate the

risk adequately.

2. Transactions' distribution of customers with respect to business types

a. Business type is one of the key parameters in risk rating a customer. A review of transaction

distribution with respect to customers' business types would help in analyzing the severity of

risk ratings to the customer businesses.

i. Often, the business risk ratings are based on FFIEFC guidelines (8). This analysis will help in

understanding the customer behavior and the associated AML risks.

3. Identification of various data limitations can severely hamper the model performance of both the

customer risk rating model, and, subsequently, the transaction-monitoring model. Even though in

the case of missing data, the highest risk rating may be assigned via default by the banks, missing

data limits analyzing customer behavior based on their characteristics. For example, if a customer's

business code is missing, then the bank cannot align his/her transaction behavior to his business

requirement or allocate the customer's behavior to a pattern. Typically, the severity of the following

missing data can be explored:

a. Missing business codes: as discussed above, if business codes are missing, one cannot identify

if the transactions conducted by the customer are within expected business processes.

b. Missing unique tax identification number: if a customer is having multiple customer IDs and

accounts with the bank, and his unique tax ID is missing, then the uniqueness of a customer

cannot be easily identified, and his transaction activity may remain below the radar of

transaction-monitoring rules.

The severity of the above limitations should be segregated within high-risk, medium-risk, and-low

risk customers. High-risk customers are already flagged by the bank, but it is possible that many

medium-risk and low-risk customers are not getting moved into high risk, because they have missing

data, and hence, their activity is below the radar of transaction-monitoring rules.

Review of Transaction-Monitoring Rules

Review of Transaction-Monitoring Rules Via Customer Behavior

Based on the FFIEC documents' red flags, various customer behavioral activities can be modelled.

As per the FFIEC, some of the suspicious activity from a customer can include:

Deposits structured through multiple branches of the same bank, or by groups of people who enter

a single branch at the same time

2 Rules of Transaction Monitoring and Customer Risk Rating models.

Validating AML/Sanctions Models – A Case Study

7

The customer repeatedly uses a bank or branch location that is geographically distant from the

customer's home or office without sufficient business purpose

Deposits are structured through multiple branches of the same bank

This behavior can be analyzed through the following steps:

a. For a given month, identify unique customer ID and branch ID combinations

b. It is advisable that this segmentation be performed by the customer's business codes, so that the

right comparison can be made

c. A histogram should be developed for the number of customers versus the number of different branch

visits, and the customers who are consistently outliers should be identified

Deposits are structured through groups of people who enter a single branch at the same time

This behavior can be analyzed through following steps:

a. For a given branch, for a given month, extract the transactions and respective customer IDs from the database. Ensure that the transactions are cash.

b. For each of the transaction dates, create a list of customers.

c. Assuming that there would be 21 working days in a month, we have to create a combination of

transaction dates. i. Assuming that we are interested in finding which customers came to the bank branch together

three days in the month, we will have to create all the combinations of three days from 21 days and call each combination a tuple.

d. For each tuple, find the common customers by taking the following steps:

i. For each transaction date in the tuple, identify the list created in Step B. ii. Once the list is identified, create another list of customers.

iii. Find the common customers.

Based on the bank's risk assessment, the above two cases could be combined to check which customers

came to the bank's multiple branches together.

Customer repeatedly uses a branch location that is geographically distant from his home or

office

This behavior can be recognized by identifying all the customers who reside in a city that is different

from the branch they are visiting.

Review of the Transaction-Monitoring Rules Via Alerts

Often, each transaction-monitoring rule is uniformly applied to all customers. There may be two levels of

segregation:

Validating AML/Sanctions Models – A Case Study

8

a. A business and individual, e.g., may have the same rules, just different thresholds for business and

individual customers

b. Risk class: may have the same rules, just different thresholds for high-risk, medium-risk, and low-risk

customers

The validator should analyze the transactions' distribution and validity of rules based on:

a. Business codes

b. Customer demographics

For example, let's assume there is a rule that monitors daily cash transactions of all the bank's business

customers, and this rule creates an alert if a customer conducts aggregate cash activity greater than

$5,000 and less than $10,000 (less than $10,000, because the bank would file a currency transaction

report for a customer who conducts cash transaction greater than $10,000).

Pseudo code for the above rule

The following example table was constructed when the rule was run on one-month transactions data:

Segmentation Count Number of Alerts Percentage

All Customers 25,000 2,500 10%

High-Risk Customers 2,500 600 24%

Medium-Risk Customers 7,500 1,200 16%

Low-Risk Customers 15,000 700 5%

High-Risk Business Codes 18,000 and 100 distinct codes 2025 11.25%

Medium-Risk Business Codes 5,000 and 70 distinct codes 400 8%

Low-Risk Business Codes 2,000 and 40 distinct codes 75 3.75%

Using the above table, the following activities can be performed as the part of rule validation that is in

line with the risk assessment of the bank:

1. The above analysis should be performed on multiple months' data to identify any possible pattern.

Some patterns that can be explored:

a. Is the percentage column in the above table consistent with other months' tables?

b. Are the customers flagged by the above rule being flagged by other transaction-monitoring

rules?

c. Are there customers (or a group of customers) that are flagged repeatedly?

2. From observing the above table, the following hypotheses can be created, which can be tested in

dataset belonging to other months:

select Customer_Unique_Id, SUM(Transaction_Amount) as Daily_Total into

#Daily_Amt

from(

select Transaction_Unique_Id, Customer_Unique_Id, Transaction_Amount

FROM Transaction_History a, Customer_Table b

where a. Customer_Unique_Id =b. Customer_Unique_Id and Customer is a Business

Entity and Transaction is Cash) a group by Customer_Id

Validating AML/Sanctions Models – A Case Study

9

a. There are 100 high-risk business codes that are creating maximum alerts. Identify which among

these 100 business codes generates maximum alerts. From other months' transactions data,

identify if it is customer-specific type or business-specific type.

b. Are there flagged customers using multiple branches and account types to do their transactions?

If there are multiple such cases, without any expected business reasons, a separate rule may be

required to identify such activity.

The knowledge and patterns identified using the above activities should be triangulated by the knowledge

acquired by reviewing other rules.

The validator should also document the limitations in his/her analysis. For example, the limitation of the

above analysis is that some customers may have been alerted multiple times, because they were within

the threshold for multiple days; hence, they have been counted multiple times.

Review of the Transaction-Monitoring Rules Via Notes

Often, tellers of banks include notes when they are entering the customers' transactions. These notes

contain the tellers' observations about the transaction and the customer doing it. As such, the tellers are

trained to report to the compliance department about any suspicious behavior they observe about the

customer, but it may happen that individually, a transaction or customer behavior may not appear

suspicious, but they may write some of their observations on the notes, which, when observed in many

transactions, may result in suspicious patterns.

With the advent of Artificial Intelligence, natural language processors may be developed in the future that

would identify such patterns, but such systems are not currently built.

In the validation exercise, the validator should attempt to build a straightforward natural language

processor to identify any suspicious patterns from the notes to create his hypothesis.

Review of Sanctions Models

Sanctions models also come under the compliance department. For completeness, we would describe

them briefly from U.S. compliance laws.

The purpose of these models is to identify and prevent any person (or country) listed in in the Office of

Foreign Assets Control (OFAC) list of Specially Designated Nationals (SDN) from using banking platforms

of banks that have U.S. connections.

The banks have to ensure that:

They do not provide their banking services to any customer listed in the SDN list by screening new

customers against the list.

Validating AML/Sanctions Models – A Case Study

10

It conducts OFAC searches of account parties other than accountholders, which may include

beneficiaries, guarantors, principals, beneficial owners, nominee shareholders, directors,

signatories, and powers of attorney (FFIEC BSA/AML Examiner's Manual, pp. 152–154) (8).

The existing customers are not doing any banking activity with any counterparty on the list.

They freeze the accounts of any existing customer that is added in the list; for that, they screen their

customers periodically against the list.

For additional details, the reader is referred to the OFAC website (9).

These models used a fuzzy logic-based approach to ensure that the listed SDNs are not successful in

abusing the banking platform by using a slight variation in the spelling of their names. The U.S. Department

of the Treasury also provides a tool that is available to public (10).

Customer Information Screening

Often, banks rely on external vendors to provide them these tools, because banks cannot individually

screen their customers through the treasury's website. Depending on the vendor, the methodology

implemented in these systems may be open, or a black box.

For validation of such models, the model validator should benchmark its performance with the treasury

tool. If the vendor methodology is black box, then benchmarking it with the treasury tool is not enough,

because as both are black boxes, it would end up being a comparative study without any additional clarity.

To have additional comfort about the implemented methodology in the sanctions system, the validator

should benchmark its performance with an in-house developed tool. Various methodologies like Jaccard

Index, Levenstein Distance, etc. can be used (11).

In addition to name screening, the OFAC screening also includes date of birth and address of the customer.

The validator should access the effectiveness of those screening.

A Short Note On Jaccard's Distance

Consider two sets: A = {C,H,A,R,L,E,S} and B = {C,H,A,R,L,I,E}. The Jaccard's distance is defined as:

𝐽𝐷(𝐴, 𝐵) = 1 − 𝐽𝑆(𝐴, 𝐵) = 1 −|𝐴⋂𝐵|

|𝐴⋃𝐵|= 1 −

|{𝐶, 𝐻, 𝐴, 𝑅, 𝐿, 𝐸}|

|{𝐶, 𝐻, 𝐴, 𝑅, 𝐿, 𝐼, 𝐸, 𝑆}|= 1 −

6

8= 0.25 − − − (1)

The score ranges from 0 to 1. If A is the same as B, then the Jaccard's distance will be 0. If A is much

different from B, then the Jaccard's distance will approach 1.

Explanation of Q-gram

Validating AML/Sanctions Models – A Case Study

11

By definition, Jaccard's approach considers each string as a bag of characters, and order is not taken into

consideration. Adding the "q-gram" feature adds some sequencing structure. Consecutive "q" characters

are grouped into a single object.

In our example, the "1-gram" case is demonstrated in eqn [1].

For the case "2-gram," we have:

𝐴 = |{𝐶𝐻,𝐻𝐴, 𝐴𝑅, 𝑅𝐿, 𝐿𝐸, 𝐸𝑆}| and 𝐵 = |{𝐶𝐻,𝐻𝐴, 𝐴𝑅, 𝑅𝐿, 𝐿𝐼, 𝐼𝐸}|

𝐽𝑆(𝐴, 𝐵) =|𝐴⋂𝐵|

|𝐴⋃𝐵|=

|{𝐶𝐻,𝐻𝐴, 𝐴𝑅, 𝑅𝐿}|

|{𝐶𝐻,𝐻𝐴, 𝐴𝑅, 𝑅𝐿, 𝐿𝐸, 𝐸𝑆, 𝐿𝐼}|=4

7= 0.57 − − − (2)

For the case "3-gram," we have:

𝐴 = |{𝐶𝐻𝐴,𝐻𝐴𝑅, 𝐴𝑅𝐿, 𝑅𝐿𝐸, 𝐿𝐸𝑆}| and 𝐵 = |{𝐶𝐻𝐴,𝐻𝐴𝑅, 𝐴𝑅𝐿, 𝑅𝐿𝐼, 𝐿𝐼𝐸}|

𝐽𝑆(𝐴, 𝐵) =|𝐴⋂𝐵|

|𝐴⋃𝐵|=

|{𝐶𝐻𝐴,𝐻𝐴𝑅,𝐴𝑅𝐿}|

|{𝐶𝐻𝐴,𝐻𝐴𝑅,𝐴𝑅𝐿,𝑅𝐿𝐸,𝐿𝐸𝑆,𝑅𝐿𝐼,𝐿𝐼𝐸}|=

3

7= 0.4285 − − − (3)

A Short Note On Levenshtein's Distance Method

Levenshtein distance is a measure of the similarity between two strings. Intuitively, Levenshtein's Distance

is the number of additions and deletions a given string "s" has to go through to be transformed into string

"t."

Mathematically, the Levenshtein distance between two strings "s" and "t" (of length |s| and |t|) is given

by levs,t(|s|,|t|).

𝑙𝑒𝑣𝑠,𝑡(𝑖, 𝑗) =

{

max

(𝑖, 𝑗) 𝑖𝑓 min(𝑖, 𝑗) = 0,

𝑚𝑖𝑛 {

𝑙𝑒𝑣𝑠,𝑡(𝑖 − 1, 𝑗) + 1

𝑙𝑒𝑣𝑠,𝑡(𝑖, 𝑗 − 1) + 1

𝑙𝑒𝑣𝑠,𝑡(𝑖 − 1, 𝑗 − 1) + 1(𝑠𝑖≠𝑡𝑗)

𝑂𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒

Where 1(𝑠𝑖≠𝑡𝑗) is the indicator function equal to 0, when si=tj and equal to 1 otherwise and 𝑙𝑒𝑣𝑠,𝑡(𝑖, 𝑗) is

the distance between first "i" characters of "s" and first "j" characters of "t."

We present here an example we will refer to as the source string (s) and the target string (t). The distance

is the number of deletions, insertions, or substitutions required to transform "s" into "t." For example,

If "s" is "test," and "t" is "test," then lev(s,t) = 0, because no transformations are needed. The strings

are already identical.

Validating AML/Sanctions Models – A Case Study

12

If "s" is "test," and "t" is "tent," then lev(s,t) = 1, because one substitution (change "s" to "n") is

sufficient to transform "s" into "t."

The greater the Levenshtein distance, the more different the strings.

Transactions Screening

OFAC screening not only pertains to the existing customer base, but also to the transactions that contain

the information about the counterparties. For example, for wire transfers (both incoming and outgoing),

it is required that the counterparty's name and address should be screened. The possible types of bank

transactions offered by the bank depends on the product offerings of the respective bank.

Based on the bank's risk assessment and the policy, validator should confirm that all the relevant fields in

wire transfers, SWIFT transfers (Society for Worldwide Interbank Financial Telecommunication), checks,

Automated Clearing House (ACH), International ACH Transactions (IAT), online transfers, etc., are

screened.

Leveraging FFIEC OFAC Sanctions Validation

The validator should also review the model-related processes and outputs based on the examination

procedure provided on page 152 to 154 of FFIEC BSA/AML Examiner's Manual (8). The ones that are

relevant from the model process perspective are listed below:

Pull a sample of false hits (potential matches) to check their handling; the resolution of a false hit

should take place outside of the business line.

Review a sample of blocked and rejected reports filed to OFAC and evaluate their completeness and

timeliness.

If the bank uses an automated system to conduct searches, assess the timing of when updates are

made to the system, and when the most recent OFAC changes were made to the system.

If the bank does not use an automated system, evaluate the process used to check the existing

customer base against the OFAC list and the frequency of such checks.

Review the timeliness of obtaining and updating OFAC lists and filtering criteria.

Review should consider the extent of, and method for, conducting OFAC searches of account parties

other than accountholders, which may include beneficiaries, guarantors, principals, beneficial owners,

nominee shareholders, directors, signatories, and powers of attorney.

Review should consider:

o The process used to block and reject transactions

o The process used to inform management of blocked or rejected transactions

o The adequacy and timeliness of filing to OFAC

o The process to manage blocked accounts (such accounts must be reported to OFAC and earn a

commercially reasonable rate of interest while the funds remain blocked)

Validating AML/Sanctions Models – A Case Study

13

Conclusion

This white paper provides the validator with approaches he can use to gain an in-depth understanding of

banks' customer demographics, product profiles, and customer behavior with respect to the products

they use. We discuss using data analytics, what steps the validator can take to ensure that the existing

rules and assumptions of the model are adequately capturing the risks described in the bank's risk

assessment document.

The validation of AML models involves assessment if the model is working as intended. This primarily

involves:

Validation of data sources, data quality, ensuring data's completeness, its timeliness, etc.

Validation of rules related to customer risk, transactions monitoring, sanctions screening based on

the respective bank's risk assessment. Conventionally, this is done by:

o Independently replicating the rules and ensuring that the alerts generated are same as those

from the existing model

o Above the Line (ATL) and Below the Line (BTL) testing of rules by varying the thresholds

parameters, thus challenging their conceptual soundness

Review and validation of ongoing performance-monitoring of the AML models

Using the approaches discussed in this paper, the validator can model and review customer behavior and

investigate whether the existing AML models are adequate in capturing any suspicious patterns. Based on

the respective bank's demographics and product offerings, the suggested approaches can be easily

enhanced or modified.

Validating AML/Sanctions Models – A Case Study

14

References

1. NYDFS Part 504 https://www.dfs.ny.gov/docs/legal/regulations/adoptions/dfsp504t.pdf

2. AML Model Validation in Compliance with OCC 11-12, Susan Devine

3. Supervisory Guidance on Model Risk Management,

https://www.federalreserve.gov/supervisionreg/srletters/sr1107a1.pdf

4. Auditing and Updating an AML Risk Assessment, Donna Davidek, CAMS-Audit,

https://www.acams.org/aml-white-paper-audit-update-risk/

5. How to Build an Audit Risk Assessment Tool to Combat Money Laundering and Terrorist Financing,

Jonathan Estreich, CAMS-Audit,

https://www.acams.org/aml-white-paper-audit-risk-assessment/

6. HIDTA: https://www.dea.gov/hidta

7. HIFCA: https://www.fincen.gov/hifca

8. FFIEC BSA/AML Examination Manual: https://bsaaml.ffiec.gov/manual

9. OFAC Website https://www.treasury.gov/about/organizational-structure/offices/pages/office-

of-foreign-assets-control.aspx

10. Treasury Tool https://sanctionssearch.ofac.treas.gov/

11. Possible approaches to benchmark Sanctions system:

a. Jaccard Index https://en.wikipedia.org/wiki/Jaccard_index

b. Levenshtein distance https://en.wikipedia.org/wiki/Levenshtein_distance