Arjun Kalra - Senior Manager - Crowe Horwath Risk Consulting Practice Chuck Taylor BSA Officer City National Bank

Transcription

1 Arjun Kalra - Senior Manager - Crowe Horwath Risk Consulting Practice Chuck Taylor BSA Officer City National Bank

2 Discuss the following Regarding Anti-Money Laundering (AML) Systems AML System Implementations Recommendations & Lessons Learned AML System Tuning Best Practice AML System Model Validation What does it mean? 2

3

4 AML Monitoring Fraud Monitoring Case Management Sanctions Screening Real time interdiction vs. post transaction Customer Due Diligence Customer Risk Ranking Ad-Hoc query engine Reporting

5 Align business and technical tasks

6 What out of the box rules/models to implement? Coverage of current system & what s lacking Risk Assessment Regulatory recommendation Custom rules? Timeframe/phases

7 Data you need will depend on rules & models chosen plus what you may like to mine. Teller activity (Checks, cash, monetary instruments, credit card advance & payment, loan payment) Electronic (Wire, ACH, online, mobile, RDC, ATM/Debit, credit & prepaid card) Loan, Wealth management, broker/dealer, trade finance & FX Changes in Client data (can you provide delta?) Real time transaction activity? 7

8 Who needs to be involved? Vendor on-site? What data do you need? How do we get what we need? Daily full extracts from the core system What other systems? Incremental delivery of files (for real time fraud monitoring) Debit and POS transactions Real time interdiction data mapping OFAC ACH/IATs Wires 8

9 Data Types Fixed width, delimited (CSV), or XML Data Uniqueness Account numbers may not be unique across host systems May require prefix identifiers LN = Loan SV = Savings TR = Trust 9

10 Vendor will provide mapping document but may not provide much explanation ASK questions Maybe most important implementation factor Improper mapping = invalid system What is the best source for? Client information? Transaction Information? Teller data All items Statements 10

11 Configurable Client and/or vendor is able to change functionality of system without coding Little or no cost May be feasible to do yourself Customizable Vendor must change coding to meet the requested change Most likely a fee involved Unlikely that it can be done without vendor assistance

12 Costs Configuration costs are a must Must set up solution to meet your basic needs Customization costs are a preference Is additional customization needed or can you survive with the basics Time Implications Can some rules/thresholds be configured by the vendor Will customization cause more problems down the road Upgrades

13 Don t get hung up on status quo & trying to make system fit current processes Be flexible and try to use out of the box functionality and configurability with little or no customization Use opportunity to review current processes and cut out waste Go paperless Consolidate many systems Move away from manual work and SPREADSHEETS

14 During initial request for funds include customization costs & pad it YOU WILL NEED IT When more customization is needed Get key parties involved early Document the reasons for customization Emphasize cost savings (and/or loss if not customized) Try to go back for more only once 14

15 Who needs access to what? How will alerts be handled? Triage? Business Unit Hierarchy Roles & Groups 15

16 Moving alerts across groups Who handles what alerts? AML Fraud SAR Debit/check fraud OFAC/Sanctions High Risk Clients EDD Is audit trail maintained Turning alerts into cases Who handles review/assignment Is audit trail maintained Turning cases into SARs Who handles review/assignment Is audit trail maintained 16

17 Setting up Roles Administrator Who? IT, Business? BSA Officer Case Management SARs High Risk Customers Due Diligence Analysts SAR Filers CDD/EDD Fraud/Loss Prevention Sanctions Audit/Examiners View Only Teller Monetary Instrument Logs OFAC Verifications CTRs Personal Bankers OFAC Verifications Wire Transfer/ACH Personnel OFAC Verifications Deposit Operations Debit Card Fraud Alerts Account Fraud Alerts Check Fraud Alerts 17

18 Desired reporting may be tied to workflow Extra steps in workflow can improve data and user issues Step for return to analyst (issues found in alert disposition) Supervisor Review step SAR filed No SAR filed Pending information 18

19 Is data missing? Was it mapped correctly? Is it logic or display data? Transactions for Customer Date Range All Transactions Listed End to End testing 19

20 Customer Information First Name Middle Name Last Name Business Name Occupation/Industry Address Country Phone Customer Since SSN/EIN Date of Birth ID number Country of origin Employment Number of Accounts Account Status Account Open Date Account Closed date Number of Cards Card Status Online Limits Associations/Joint Information Transaction Date Range All Transactions Listed 20

21 Filtering criteria Thresholds used Any rules not being utilized Why? How the above is appropriate for the bank s risk (tied back to risk assessment) Important to document this to use as a defense during an examination 21

22 Test before you go live Work prior system and new system concurrently Start with a small set of scenarios Go-live should be an evolution, not an event Keep detailed documentation for auditors/examiners Background of system User guide/training materials 22

23 Keep spreadsheet of questions/outstanding items between you and Vendor Most likely won t be able to respond at time of question Quality of vendor team is very important Experience Willingness to help Availability & responsiveness Push back if you need to 23

24 Data mapping between the core banking and transaction monitoring systems undertaken by IT staff alone BSA personnel should be involved As well as wire room, ACH, Mobile Banking, etc. Having unrealistic goal dates If it can t be completed in time, accept it 24

25 Define what expertise you have in house and what s missing: Requirements definition Process design Data mapping & acquisition Data validation & testing Model tuning If team is lacking it may be very beneficial to add consulting You don t know what you don t know Consultants have experience from other clients

26

27 OCC & FRB Supervisory Guidance on Model Risk Management (April 2011) Regulators have been treating AML Systems as models and subjecting them to Risk Analysis Division (RAD) scrutiny similar to credit risk models PHD level statisticians In depth review of data quality and output AML models include Transaction monitoring, Customer risk rating, Watchlist filtering, and more 27

28

29 Establish a repeatable process Optimize scenario & eliminate false positives Identify scenarios for retirement Identify monitoring gaps 29

30 Map risk factors to monitoring to identify gaps or any redundancies 30

31 Tuning phases Baseline tuning Pre-production tuning Production tuning Quantitative Approach Tunable vs. static parameters Focus on alert quality On-Going Process Change control procedures Input monitoring Output monitoring Risk profile updates 31

32 Vendor default values Before using, do they make sense? Out of the box parameters are rarely adequate Regulators will criticize unless properly supported Consider statistical analysis Average values Percentiles 32

33 Assessment of alert quality to define parameter values for Production Parameters should be tailored to the bank s activity and risk profile Sampling approach to reduce effort, while maintaining confidence in results 33

34 Approach should be consistent with Preproduction tuning process Benefit of actual production results How many alerts were generated Distribution of alerts that lead to investigations/cases Distribution of investigations/cases that lead to SARs Above-the-Line vs. Bel0w-the-Line 34

35 Customer Segmentation Exemptions and filtering Customers Transaction codes Alert consolidation 35

36 Helps address examiner/audit expectations Have to show execution Prescriptive methodology won t hold up without documentation Track changes over a long model lifetime Changing roles and responsibilities Employee turnover 36

37

38 Conceptual Design System Validation Data Validation Process Validation 38

39 Critically evaluate the logic and design of the model/system Assess if documentation supports model design and implementation Identify if model is aligned to the specific risks of your institution 39

40 Assess system functionality for any logic/methodology flaws Identify any system limitations (data, logic, etc.) Evaluate the inventory of data feeds, data elements, evaluation against conceptual design Assess the approach towards tuning and optimizing the model 40

41 Risk based testing of accuracy and integrity of source systems Comparison of data records from source to supporting documentation Assess completeness of data and identify any data limitations Testing of interface with external systems Transaction monitoring with case management Back testing Match alerts to source data Match source data to alerts 41

42 Validate the effectiveness of managing system/model output System controls System balancing Access rights Alert/exception management Feedback and model enhancement processes Management reporting 42

43

44 Arjun Kalra (415) Chuck Taylor (213)

45 45