AML PEER GROUPING

Anandhi R
Insurance (INS 2.1) No. 1/G1, SIPCOT IT Park, Siruseri, Chennai 603 103. Mob: +91-9940742343 anandhi.ramasamy@tcs.com

Parthiban M
Insurance (INS 2.1) No. 1/G1, SIPCOT IT Park, Siruseri, Chennai 603 103. Mob: +91-9789070400 parthiban.murugesan@tcs.com

Bhuvaneshwari M
Insurance (INS 2.1) No. 1/G1, SIPCOT IT Park, Siruseri, Chennai 603 103. Mob: +91-9486088432 bhuvaneshwari.muthukottiappan@tc s.com

ABSTRACT
Financial institutions worldwide face the challenge of accurately detecting money laundering as well as prioritizing the transaction for investigation in a timely manner, so that their analysts can concentrate on these transactions. Transactions that are false positives take toll on their precious time and effort, affecting their efficiency. On the other hand false negative transactions impact the organizations bottom. Monitoring of account activity and transactions flowing through a financial institution is one means of ensuring that it allows for identification of unusual patterns of activity or transactions. These unusual transactions or activity are usually filtered based on certain parameters like verage !aily "ash "redit, verage #eekly #ithdrawals, verage ccount $alance, etc. %n &eer 'rouping, the process provides higher degree of accuracy of monitoring fraudulent activities. This paper deals with the method to identify suspicious transactions based on deviations from peer groups.

TACTiCS TCS Technical Architects Conference07

1.1

Peer Group Analysis

%t is one of the techni-ues used as a measure for anti( money laundering. %t provides end(to(end coverage to identify and report suspicious transactions related to money laundering and terrorist financing, ensuring firms can meet current regulations and -uickly adapt to the evolving regulatory environment. Peerin! is the comparison of an individual customer or entity to a group of others that are in the same group. %n nti(Money )aundering terms, it is defined as comparing the transactions of a customer with that of a group. / &rovides a method to gauge if a customers activity is appropriate. / &rovides a mechanism to view segments of the institutions customer base and their associated volume of transactions. %t also enables the organization to0

1.

INTRODUCTION
Money laundering is a well(known problem in the insurance industry. %t is the process of concealing the source of large amounts of money that have been gained through illegitimate means. The %nternational Monetary Fund estimated that two to five percent of the worldwide global economy involved laundered money. The Financial ction Task Force on Money )aundering *F TF+, an intergovernmental body set up to combat money laundering, stated that, ,Overall, it is absolutely impossible to produce a reliable estimate of the amount of money laundered and therefore the F TF does not publish any figures in this regard.,

%mprove efficiency through a configurable, robust workflow and alerts management system 1ffectively meet regulatory re-uirements 2treamline compliance operations and reduce ongoing M) program costs !eliver better detection by combining behavioral profiling and rules management

".

E#ISTING APPROAC$
There are a large number of tools available in the market for suspicious transaction detection and management. 2ome of these tools have insurance specific frameworks and functionality for the detection. )et us consider the reputed 3.2 based insurance firm, they are

&ermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice. To copy otherwise, or republish, to post on servers or to redistribute to lists, re-uires prior specific permission and.or a fee.

using "ustomer M) 4isk 2core model for the detection of suspicious transaction.

".1

Ris% S&orin! Mo'el

M) 4isk ssessment considers the

The "ustomer following0 5.

'eography / including the F%2 6urisdiction, branches, the geographic regions of the customer base, and the 6urisdiction of counter parties "ustomers / defining customer types, with particular concern for the identification of customer.entity types conventionally associated with a heightened risk for money laundering.terrorist financing e8posure, such as cash intensive businesses, import.e8port companies &roducts and services offered by the institution / certain products and services pose a greater risk of money laundering and terrorist financing, such as private banking, international wire transfers, and trade finance.

Type of activity should be factored into the calculation of customer risk by applying a risk factor such as an evaluation of the products or services utilized or customer.account activity volume. For example, international wire transfers receive a higher risk than check deposits. In another example, payable upon proper ID (PUPID wires would carry a higher risk than automatic bi!weekly "#$ payroll deposits.

2.2.4

ther !actors
%ype of business &ccupation (for individuals 'ength of relationship (elationship history, #ash activity volume )ire activity volume %otal volume #ountry of residency #ountry of incorporation

7.

9.

"."

Ris% (a&)or Ca)e!ories

".+

Cus)o*er Pro,iles -s. Toleran&e

The following factors should be considered while building customer risk models0

2.2.1

Customer Type

The building of customer risk models is highly dependent upon decisions made when defining customer types. 2ome organizations may simply define and distinguish customer types as individual and business. Other organizations may re-uire more specific definitions. For e8ample, international individual, domestic individual, broker dealer, partnership, international corporation, domestic corporation, trust, correspondent bank, foreign banking institution, money service business, cash(intensive business, etc. The first step in building the customer risk models involves listing customer types at the lowest level possible, defining the "%& acceptance criteria and the customer risk factors for each type. %t is important to note that customer types that you define should also be defined in the source system that will supply the customer file. Cus)o*er Ris% Assess*en) :

&nce a customer has been assigned a risk class, a tolerance is applied to the expected incoming and outgoing volumes for profile! monitoring purposes. %he tolerance is inversely related to the risk class* thus, the higher the risk, the lower the tolerance. +ote the following example, 'ow (isk - ./0 tolerance 1edium (isk - 2/0 tolerance $igh (isk - 3/0 tolerance %hus, if customer "4# Importers, a medium risk customer, has an expected monthly dollar volume of 52/,/// incoming and 56/,/// outgoing, then profile!based monitoring would result in a flag only if the following thresholds were exceeded, Incoming tolerance &utgoing tolerance 7 8xpected incoming of 52/,/// 9 2/0 7 52/,/// 9 532,/// 7 5:2,/// 7 8xpected outgoing of 56/,/// 9 2/0 7 56/,/// 9 53/,///7 5;/,///

2.2.2

Account Type

ccount types should be factored into the calculation of customer risk by applying a risk factor such as an evaluation of the type of account*s+ and account activity volume. For e8ample, a corporate !! compared to a certificate of deposit for a domestic individual would result in differing risk result scores. 2imilarly, an %4 for a professional service provider would carry a different risk result score from a transaction account, such as a business checking account. private banking account carries a significantly different result score from a corporate "!.

%he same would be applied if the numbers of incoming and outgoing transactions are considered.

+.

TRANSACTION PRO(ILING

2.2.3

Activity Type

The transactions which happened daily in the financial institution are profiled account(wise and rolled up for the monitoring period where these profiled data were very much useful in finding the suspicious transactions. %t improved the ability for Financial "rimes nalytics Team to monitor the suspicious transactional behavior based on transactional profiles. %t also helps in the design for peer groups.

+.1

Pro&e'ure

2td. !eviation Total *2um+

First, create an analytical repository of aggregated high risk transactions to be used for building a transactional behavioral profile of every customer. This will be useful to validate peer( groups and to build adaptive transactional models for detecting suspicious financial activity.

These statistical data would be stored in the Monthly &rofiling table which will be useful for fi8ing the bucket size for the peer grouping. %t also provides the basis for the monitoring.

+."

Pro&ess (lo.

+.+
5.

Bene,i)s
?uick analysis of money laundering can be done using profiled data. =elps in reducing the losses incurred due to the money laundering. nalytics team can easily identify the suspicious financial activity.

!aily .Monthly

7.
2tatistical !ata "alculation

2taging
4ollup

9.

/.
3.2.1 Sta"in"

PEER GROUP PRO(ILING

"apability to define peer groups across the organization on the basis of total transaction amount. %dentification of corporate and individual accounts based on similarity of behavior. bility to set monitoring criteria on each such identified peer group. bility to constantly monitor accounts for deviations from set criteria. Flagging of accounts.customers e8hibiting abnormal deviations from peer group.

The first phase of this scenario is staging, in which the transaction details from various sources are collected, processed and stored in the database with all the necessary column values. There may be a chance of getting an invalid transactional entry because the input details were unprocessed one. 2o, we maintained the data integrity and make sure that the data stored in the repository was in a good state, which in turn going to be useful for profiling.

3.2.2

#aily $oll%up

fter staging, the transactional data was rolled up daily based on a certain key columns like ""O3;T<;4, "= ;;1), T4 ;2 "T%O;<T>&1, etc. !uring this phase, we have calculated the total transaction amount and the total count of transactions occurred with the same profiling key columns. These two columns TOT )< MT and TOT )<"O3;T have their significant importance in transaction based peer grouping. %t will be also useful for the nalytics team to write the better business rules. The daily rolled up data was then undergone monthly roll( up so that the monthly total transaction amount and count values were calculated.

3.2.3

Statistical #ata Calculation

$ucket size should be fi8ed based on the desired grouping of customers. ll customers must be put into an appropriate bucket. For e8ample, in this case we fi8ed the bucket size based on the TOT )< MT, @A to @7B,AAA per month @7B,AA5 to @BA,AAA per month @BA,AA5 to @5,AA,AAA per month 1tc

The rolled up data was stored in the intermediate database having monthly partitions. The transactional data that was happened in any particular month undergone some statistical calculations based on that key columns. The following are the ma6or statistics we have calculated from the two columns TOT )< MT and TOT )<"O3;T in the daily profiling table, Min Ma8 Mean * verage+ Mode * long with Multi mode "ount+ Median

2tatistical !ata like M%;< MT, M C< MT, M1!% ;, D14 '1 and 2T!<!1D are calculated for each group based on a monitoring period. 'roups need to have a significant number of customers *minimum 9A is desirable+ for the statistics to be valid. %f the median and average values are e-ual, then there may not be enough customers in the group.

&.1.1

#eterminin" Suspicious Activity

/.1

Toleran&e
Tolerance is the acceptable deviation from the groups normal average. %t was represented in 2tandard !eviations from the verage *2T!<!1D+. The 2tandard !eviation is the representation of how much each customer differs. The smaller the number for 2T!<!1D, the more each customer is alike. The larger the number, the bigger the difference between each customer.

The statistics for the group is should be calculated based on the average volume of transactions per month for the past transactions, take last 57 months for e8ample. #e calculated the verage, Median, Ma8, Min and 2tandard !eviation for each group separately. 1ach group should have a threshold value, $ucket0 90:;::1 )o 91::;::: Min Ma8 Median verage 2tandard !eviation M of 2tandard !eviation Threshold 5 Threshold E 'roup verage F Tolerance Ta1le + De)er*inin! )3res3ol' ,or ea&3 !roup 5T3res3ol'E @GH,GBA F *9 I @J,5AA+ E @5, A5,ABA Then, determine the total volume of transactions for the current period for one customer. "ompare the customers current volume to the group normal one. "ustomers total volume that e8ceed the group threshold are to be reviewed *marked as Bol' in the Table :+. @B7,9BA @LJ,H:L @G7,9BA @GH,GBA @J,5AA 9 91;:1;:0:

The tolerance is the number of standard deviations from the average that encompasses the ma6ority of the population. "oncept is to find those customers that e8ceed the norm for the group. ctivity in e8cess of the tolerance is deemed suspicious.

0. 0.1

ILLUSTRATION Mo'el ,or Ban% Transa&)ions

%n the Table 5, the customers are categorized into groups based on the average volume of transactions per month for the past one year. Ta1le 1 Si2e o, ea&3 1u&%e) 1ase' on 4olu*e o, )ransa&)ions 4olu*e o, Transa&)ions per Nu*1er o, Cus)o*ers *on)3 7Bu&%e)8 @A to 7B,AAA @7B,AA5 to BA,AAA @BA,AA5 to 5AA,AAA @5AA,AAAF :B LA :A 5A

Cus)o*er Na*e Michael Madhan 2heela 4ohan braham <o3n Arun

To)al A*oun) @BH,9JA @BJ,H:L @G7,:5A @JH,GBA @LG,9AA 91:";+:: 91:=;10:

Then, 2tatistical !ata like M%;< MT, M C< MT, M1!% ;, D14 '1 and 2T!<!1D are calculated for each group based on a monitoring period. The statistical data calculated for one sample bucket was shown in the Table 7. Ta1le " S)a)is)i&al Da)a &al&ula)e' ,or ea&3 !roup $ucket0 90:;::1 )o 91::;::: Min Ma8 Median verage 2tandard !eviation @B7,9BA @LJ,H:L @G7,9BA @GH,GBA @G,LAA

Li)a 9110;>:: Ta1le / Cus)o*er6s )o)al -olu*e ,or )3e &urren) *on)3 2o the customers Kohn, run and )ita may be involved in the suspicious transactional activity. #e should investigate their transactions for the current month and identify whether any suspicious transactions happened or not. $y this way, we can improve the accuracy of detecting the illegal transactions.

current period

?.

SUMMAR@
'roup customers by one or more attributes, always include the Dolume of Transactions. 2ize the buckets based on the desired grouping. Find the Median, verage, Min, Ma8 and 2tandard !eviation for each bucket. Find the best number of 2tandard !eviation which should cover most of the population. "ompare past activity of the group to the customers

=.
N5O N7O N9O N:O

RE(ERENCES
http0..www.financialcrimerisk.fiserv.com http0..www.ifsalearning.org http0..www.niceactimize.com.inde8.asp8 http0..www.primeassociates.com