Transcription
Garbage In, Garbage Out?Don’t Let That Be Your AML SolutionStephen R. King, JD, AMLPCBA Regulatory Compliance ConferenceOctober 7, 2015MEMBER OF PKF NORTH AMERICA, AN ASSOCIATION OF LEGALLY INDEPENDENT FIRMS 2010 Wolf & Company, P.C.
Today’s Agenda Model Risk Management BSA Risk Assessment BSA/AML Software Utilization and Validation BSA System Optimization FinCEN Advisory Enforcement Actions2
What is a Model?A quantitative method, system, or approach that appliesstatistical, economic, financial, or mathematicaltheories, techniques and assumptions. These features are used to process input data intoquantitative estimatesModels consist of three components: Information input Processing Reporting3
Model RiskThe use of models presents “Model Risk” Inaccurate data outputs Incorrect or misuse of model outputs and reports Potential for adverse consequences– Regulatory Risk– Reputation risk– Financial loss4
Model Risk ManagementModel Risk must be managed to eliminate downfalls: Develop the model accordingly Implementation and control Establish limits on model use Monitor performance Adjust or revise parameters over time Supplement model results with other analysis orinformation5
Model Development & Implementation Purpose/Use/Data Flow of the Model Limitations Testing– Incorporate actual data– Incorporate low, moderate, and high areas of risk Document and summarize the results6
Model Validation & IndependenceSet of processes and activities intended to verify thatmodels are: Performing as expected Limitations have been identified & potential impact isknown Model aligns with objectives and business useModel data input, processing, and reporting should besubject to validation.Actual validation must be performed by an independentparty.7
BSA Risk Assessment8
BSA Risk AssessmentThe FFIEC BSA Examination Manual requiresinstitutions to create a Bank Secrecy Act/Anti-MoneyLaundering/OFAC risk assessment covering theinstitution’s: Products and Services Customers and Entities Geographic Locations9
BSA Risk AssessmentStructure:1. Analysis of the Institution’s products/services,customers/entities and geographic locations.2. Identification of risks and the mitigating controls.3. Statistical analysis culminating in risk ratingsThe risk assessment should include appropriatedocumentation supporting the risk-based reasoningbehind any dollar thresholds utilizes. Institutions shouldmaintain back up documentation supporting theirconclusions.10
BSA Risk AssessmentBest Practices: The risk assessment should contain an overall ratingfor the BSA/AML and OFAC programs. Overallratings for products/services, customers/entities andgeography is also a good practice. The Risk Assessment should be presented to theBoard for approval.Areas where the Institution accepts the risk of nothaving certain controls in place should be included inthe risk assessment so as to receive approval ofaccepting such risk from the Board.11
BSA Risk AssessmentThis risk assessment should be amended on at least anannual basis, or as major changes occur such as: New products and servicesMergers or acquisitionsNew geographic areasNew service providersNew softwareSignificant examination or audit findings12
AML Software13
Model ValidationSet of processes and activities intended to verify thatmodels are performing as expected, in line with theirdesign objectives and business uses.Helps ensure models are soundIdentifies potential limitations and assumptionsAssesses possible impact14
Model ValidationIs model working efficiently?User feedback andinsightManagers questionmethods andassumptionsModel functions well andreflects realitiesJustifies assumptions anddesign15
Model ValidationValidation requires degree of independence:– Incentives aligned with goals of validationKnowledgeSkillsExpertiseAuthority Staff must have:16
System Validation - ResponsibilitiesInitial Independent ValidationOngoing Change MonitoringPeriodic Independent Validation17
System Validation - ResponsibilitiesWhere does the System Validation piece come from?18
AML Software - IntroductionMany institutions have moved towards BSA AutomatedSoftware to assist in meeting their day to dayBSA/AML/OFAC regulatory requirements.There are various risks, expectations, controls and bestpractices that institutions should consider whenimplementing such software.As with any other software or outsourcing utilized, theinstitution is still ultimately responsible for compliance.19
AML Software - IntroductionAreas the Automated Software could impact include, butare not limited to: Suspicious Activity Monitoring Suspicious Activity Reports (“SARs”) Enhanced Due Diligence Currency Transaction Reporting (“CTRs”) CTR Exemptions 314(a) Request Lists OFAC Wire Transfers20
AML Software - StructureAutomated Software often reviews customer activity byvarious means and identifies possible occurrences ofsuspicious activity, frequently referred to as “alerts”.Similar to any suspicious activity that was manuallyidentified, the institution has an obligation to review theactivity to determine if a SAR filing is necessary.How the Automated Software identifies these “alerts” is akey part of the software structure which should beunderstood by the institution.21
AML Software - StructureAutomated Software is typically structured in one or bothof these fashions:Rules Based – Alerts are based on specific, often logicor activity based rules. When the criteria for that rule ismet then an alert is generated.Behavior Based – Alerts are based on specific customerbehavior. Defined parameters exist for expectedbehavior (either overall or for specific customers) andalerts are generated when activity is outside suchexpected behavior.22
AML Software - StructureRules Based System example: Customer is in business account type; and Customer is from HIDTA zip code (coded list insoftware); and More than 3 transactions between 8,000 - 10,000take place in one month periodAlert is generated if all criteria are met23
AML Software - StructureBehavior Based System example: Expected activity for customer of specified type is 25,000 in currency per month; 50,000 is consideredhigh Customer has 45,000 in activity during month,representing risk code of 95 Bank’s parameters are set to generate an alert foranything with a risk code of 50 or aboveAlert is generated due to activity outside of expectedbehavior24
AML Software - StructureBased on the Automated Software, there may be timeswhere the institution has to manually code risk ratings orfigures that impact the risk rating. If this isn’t done, therisk rating process can be adversely affected.Examples: NAICS Codes Status as SAR suspect, 314(a) match, OFAC match (ifthere isn’t integration between such reporting and theAutomated Software)25
AML Software - StructureMany Automated Software solutions also provide for theestablishment of risk ratings for customers and accounts.Oftentimes this involves the calculation of a rating basedon various factors such as products used, geographiclocation, business type, activity and other factors.The risk rating may be used as part of the rules based orbehavior based alert generation process, or may result inseparate alerts or reporting on its own.26
AML Software - BenefitsBenefits: Identify more suspicious activity Streamline risk rating and customer due diligenceprocesses Facilitates electronic filing requirements Stronger integration27
AML Software - BenefitsBenefits: Reduces reliance on manual processes Provides more detailed records and documentation Eliminates duplicative or contradicting informationwhile avoiding version control28
AML Software - PitfallsPitfalls: Cost (direct and indirect) Examiners impose higher standard Increase time needed for monitoring suspiciousactivity if not properly managed Potential for superfluous false positives29
AML Software - PitfallsPitfalls: Quality Issues from data integrity Increased supporting documentation Increased vendor management oversight30
AML System Validation - Challenges Limited regulatory guidance on scope and frequency ofvalidation testing Identifying how the AML system operates and alerts Identifying data integrity issues Increased expectations to reviewmore information31
AML System Validation - Opportunities Assurance that the software is producing reliable resultsthat support your AML program and records detailed trailof events Identifies opportunities to improve the quality of theoutput & usefulness of alerts Identifies any data integrity issueswithin the system32
AML Software – ParametersIn establishing the parameters followed, it is critical thatthe institution utilize its risk assessment.Parameters should be established based on internal,unique factors at the institution such as: Customer base Products and services offered Geographic location Volume of higher risk customers and regulatory reports Other historical information33
AML Software – ParametersExamples: Institution’s customer base consists of many cashintensive businesses. Expected activity for cash is set ata higher level than initially recommended by vendor. Institution operates in rural area where internationalwires are occasional at best. Institution sets parametersfor international wires to be more sensitive than thoseinitially recommended by vendor. Customer usage of a particular product type is extremelyrare (used 5 times in a year). Institution sets parameterssuch that any usage of such product is flagged.34
AML Software – ParametersAll applicable transaction types should be consideredwhen the software evaluates activity. This includes, but isnot limited to: Cash Wire Transfers Monetary & Negotiable Instruments ATM/Debit Cards ACH Other Electronic Transfers Lending Transactions35
AML Software – ParametersStructuring Software settings have been done at a dollar thresholdtoo high to capture activity appropriately (ex. 50,000minimum) Date range for capturing activity is too brief, or too wide Parameters are not properly structured to apply tocorrect types of customersEnd Result: Instances of activity are not properlyidentified, activity is never reviewed, and the institutionfails to file SARs as required.36
AML Software – ParametersWire Activity Institution has set dollar value of transactions at too lowa level given typical customer activity Institution applies consumer dollar and transactionvolume standards to both consumer and businesscustomers Institution has failed to take into account that a largesegment of its customer base are students receivingfunds from abroad via parentsEnd Result: The software produces too many alerts,most of which are not relevant and the institution spendstoo much time reviewing non-suspicious activity.37
AML Software – ParametersRisk Ratings System has established that time deposit accountsearn higher numerical score than transaction accounts No specific business types in system have beenidentified as a high risk business type Institution fails to record in Automated Software whatcustomers have had SARs filed on them Minimum score for a high risk account is set at a veryhigh level such that only customers performing alltypes of high risk activities could possibly have such ascore.End Result: The software fails to appropriately identifyhigh risk customers.38
AML Software - GovernanceInitial Set up/Periodic MaintenanceThe individual at the institution primarily responsible forinitial setup should have the sufficient knowledge ofBSA/AML rules, as well as internal practices and risks atthe institution.Facts and reasoning utilized in establishing initialparameters should be documented and retained.Appropriate input may be necessary from multiple areas(BSA/compliance, IT, Retail, etc ).39
AML Software - GovernanceInitial Set up/Periodic MaintenanceAny key decisions made to change parameters orfunctionality should be clearly documented.Especially important in those instances where theinstitution is taking on more risk, such as by increasingthresholds to trigger alerts or reducing the frequency ofreview.Appropriate dual control should be in place for changes.40
AML Software - GovernanceTimeliness of ReviewThe institution will want to ensure that alerts or reportsproduced by the software are reviewed in a timelymanner so as to comply with regulatory requirementsand also ensure volume does not become overwhelming.Frequency of alerts may vary based on vendor andstructure of reporting (daily, weekly, monthly, quarterly).Dual controls should be established to allow for periodicsecondary review of alerts or reports closed out as notsuspicious.41
AML Software - GovernanceBoard & Senior Management Establishment of policies & procedures designed toensure compliance Clearly delineate roles and responsibilities as theyrelate to model risk management and controls Oversight of AML software development,implementation and validation Review internal audit findings and validation results Ensure prompt corrective action of deficiencies42
AML Software - GovernancePolicies and ProceduresWritten policies and procedures concerning the usage ofthe software should be established.Specifying internal practices in addition to simply relyingon manuals provided by the vendor are recommended.Also, any changes that have been made based on whatis documented in any manuals should be documented asnecessary.43
AML Software - GovernanceTrainingTraining concerning the software is critical. Examinerswill criticize the institution if they believe employees donot have a proper understanding of the product.Depth of training should be based on level ofinvolvement. BSA Officer and staff should receive detailed training Other staff may only require training as warranted (ex.ensuring information is entered into correct fields toavoid subsequent data or timing issues).44
AML Software - GovernanceResourcesThe institution should ensure that appropriate resourcesare in place concerning the usage of the software.There should be sufficient staffing to cover alerts andother reports or obligations created via the software.There should also be sufficient staffing in place to ensurereview mechanisms and dual controls.Institutions should not adjust parameters to reduce thenumber of alerts solely due to resource issues. It shouldbe risk-based in nature such that the institution iscomfortable that alerts being excluded are not important.45
AML Software - GovernanceReportingSufficient reporting to senior management should bedone on the usage and effectiveness of the AutomatedSoftware, particularly at smaller institutions where costscan be a concern.Major changes in the usage of the software should becommunicated to the appropriate levels of management.There are no specific guidelines for how such reportingshould be done.46
Fraud SoftwareSome Automated Software provide fraud alert reportingor are specifically establish to identify fraudulentbehavior.While this may assist in BSA monitoring efforts, this isnot considered all encompassing. Fraud is not allinclusive of all suspicious activity, and the softwareshould be structured to identify all types of suspiciousactivity.47
ReportingAutomated software frequently assists with CTR and SARreporting.Oftentimes fields will directly flow from either core systemor Automated Software into the applicable form fields.The institution will want to ensure that such fields arebeing filled in properly and that manual edits are madewhen necessary.48
Watch ListsAutomated Software can also provide means to review“Watch” lists such as OFAC and 314(a).The institution will want to ensure that all applicable listsare being utilized and are properly flowing into thesoftware (particularly when updates are made to lists orsoftware).Sensitivity of the software should be appropriate set so asto not leave out potential matches that can be of concern.49
System Validation – Getting StartedWhat is the system doing in regards to your data? Identifying Evaluating Reporting50
System Validation – Getting StartedPotential Breakdown Points:1. Management shouldestablish a clear anddefined escalationprocess from the point ofinitial detection todisposition of theinvestigation.2. Not having a system thatcaptures the suspiciousactivity.51
System Validation – Getting StartedItems Required for Testing: Core Reports showing all transactional data for the timeperiod Wire activity reports BSA/AML system reports for rules and/or configurations Exception lists User Access List Employee Roster Change Management Policies and Proceduressurrounding your BSA/AML system52
System Validations – Data FlowWhere do we start? Identify the Data flow:Nightly coreprocessingactivity export1CoreBankingWireDatabaseOutsourcedWire FunctionNetworkAML / BSAApplicationAML / BSAExceptionReportsOutsourcedCore BankingSiteAML Monitoring Application1This is where the Core data is imported intothe AML / BSA Monitoring ationInstitution – Local Network2AML/BSAMonitoringTriggersThis is where the AML / BSA MonitoringSystem’s rules identify activity to bereviewed53
System Validations - TestingTesting the system involves validation of the followingitems: Import of information from the core (integrity /completeness) Results of the AML / BSA Monitoring system(integrity / accuracy)54
System Validations - TestingCore Data Integrity and Completeness Check: Capture and Aggregate activity reports fromthe Core Banking System and Wire System Select random samples from the core data andverify they are present in the BSA/AML system Data integrity check by ensuring data isappearing the same as it is within the core55
System Validations - TestingBSA/AML System results Integrity and AccuracyCheck : Utilize rules configured within the AML / BSASystem against the aggregated data Select samples that would be expected to “hit”rule criteria Compare the results of this testing against theAML / BSA exception reports56
System Validations - TestingGeneral System Security Controls, including: User Accounts and Access Levels – Abilities toconfigure monitoring rules / abilities toconfigure report structures System security monitoring controls Change management policies and proceduresalong with periodic independent monitoring57
System Validations - Known Issues Bad data inappropriately mapped tothe BSA/AML system Entire Modules not flowing over tothe BSA/AML system Random transactions not flowing over to the BSA/AMLsystem Transactions not being appropriately risk rated in theBSA/AML system58
AML Software – Exam ExpectationsExaminers expect the Automated Software to be coveredby independent testing as part of the BSA audit function.The audit must be performed by an independent partythat was not involved in the set up of the software and isnot involved in the regular maintenance or usage of thesoftware.This can be done through an Internal Audit Department,third party auditors or other individuals in the institutionas long as they are independent and have appropriateexpertise.59
AML Software – Exam ExpectationsThe audit coverage should ensure that therules/parameters being utilized by the software arereasonable and appropriate. IT validation should coverany data entry/analysis concerns.The audit should also cover the usage of the software,including: Ensuring that there is appropriate understanding bypersonnel; Timely addressing of alerts and reports Proper documentation for cases not resulting in SARfilings.60
AML Software – Exam Expectations Has the institution performed an appropriate analysiswhen the product was implemented and not simplyused "out of the box" parameters/rules? Does the institution periodically review its parametersto ensure that they are appropriate? Has the institution ensured that its parameters areappropriate in accordance with its risk assessment,policies and practices?61
AML Software – Exam Expectations Is the institution performing its analysis of alerts in atimely manner? Is the institution reviewing alerts in a consistent manner,and properly documenting the results of its analysis? Do the appropriate individuals review these alerts, andis key information reported to the appropriate membersof management? Is the usage of the software impacting BSA complianceor reporting in any negative fashion?62
AML Software – Exam Expectations Controls to establish and changes parameters Appropriate user authorities and controls Testing of system changes Periodic validation of entire system63
AML Software OptimizationAssess the adequacy of your Institutions AML softwareparameters. Whether your institution is using defaultparameters or customized parameters, consider thefollowing: Are the parameters sufficient to identify areas thatpose significant risk to your institution? Are the parameters adequate given your institutionsrisk model and risk assessment? Is the software generating quality alerts and arethese alerts manageable?64
Objectives of OptimizationContinued analysis and even adjustment of theparameters are crucial components of softwarevalidation.Any changes made as a result of the analysis andadjustments must be documented and include andescription of the changes, benefits, pitfalls/limitations,and anticipated results. Use of new data, new risks New model approaches New or improved reports65
FinCEN AdvisoryThe strength of an Institution’s compliance culturedepends on: Support and understanding by leadership ofcompliance efforts; Efforts to manage and mitigate deficiencies/risks arenot compromised by revenue interests Pertinent information from the business lines iscommunicated to the Bank Secrecy Act/Anti-MoneyLaundering Department Appropriate allocation or resources Effective compliance program – 4 pillars Understanding of the need for compliance andpenalties for non compliance66
Where do the shortcomings lead to?67
Enforcement ActionsApril 2012: Citibank, N.A. OCC Cease & DesistWeak documentation of the validation and optimizationprocess applied to automated transaction monitoringsystems– the independent BSA/AML audit function failed toidentify systematic deficiencies68
Enforcement ActionsSeptember 2013: TD Bank 52.5 millionSEC and OCC fined Bank for its actions and nonactions regarding potential 1 billion ponzi scheme.OCC Failure to identify suspicious activities Failure to file SARs despite system alerts69
Enforcement ActionsSeptember 2013: Saddle River Valley Bank 8.2 millionFinCEN fined the Bank for failure to maintain aneffective anti-money laundering program. Inadequate EDD over casas de cambio Failure to detect and report CDC suspicious activities ‘Insufficient experience” and inadequate training70
Enforcement ActionsJanuary 2014: JPMorgan Chase Bank, N.A. 350 Million Less than satisfactory Risk Assessment processes Systematic deficiencies in the Bank’s transactionmonitoring systems, due diligence processes, riskmanagement, and quality assurance programs SAR decision-making deficiencies71
Enforcement ActionsJanuary 2014: Old National Bank 500kOCC fine for BSA program failures Failure to conduct adequate Risk Assessment Inadequate suspicious activity monitoring program Lack of qualified BSA Officer and resources72
Enforcement ActionsJune 2014: Associated Bank 500kOCC fine for BSA program deficiencies Failure to conduct adequate Risk Assessment Insufficient Customer Due Diligence Improper high-risk customer identification Inadequate suspicious activity monitoring program73
Enforcement ActionsNov 2014: North Dade FCU 300k 4 Pillars violation Failure to establish adequate AML Program Failure to establish adequate CIP Failure to Identify/Report CTRs and SARs Failure to review §314(a) Request Lists74
Enforcement ActionsFinCEN Dec. 2014: Thomas Haider 1 Million Willfully violated the requirement to implement andmaintain an effective Anti-Money LaunderingProgram Willfully violated the requirement to report suspiciousactivity and file timely SARs Failure to termination known high risk agents Failure to conduct adequate due diligence of agents75
Enforcement ActionsJan. 2015: Oppenheimer & Co. Inc. 20 MillionSEC fine for BSA/AML program deficiencies: Failure to implement an adequate Anti-MoneyLaundering program Pattern of suspicious activity was identified based onthe same two significant red flags Failure to implement an adequate due diligenceprogram for a foreign correspondent account Failure to report a customers suspicious activityoccurring through Oppenheimer accounts76
Enforcement ActionsFeb 2015: First Natl Community Bank 1.5m CMP 1m FinCEN fine and 500k OCC Failure to detect or report SARs timely Failure to comply with internal policies77
Enforcement ActionsApril 2015: Lone Star National Bank 1 Million CMPOCC fine for BSA program deficiencies: Unsatisfactory EDD and CDD for high risk accounts Independent Audit Inadequate Suspicious activity monitoring & reporting Foreign Correspondent Relationship/Banking78
Enforcement ActionsJune 2015: Bank of Mango 5.7m (CMP/forfeiture) Failure to establish adequate AML Program Failure to establish adequate CIP Failure to Identify/Report CTRs and SARs79
BSA ResourcesFFIEC BSA Exam Manual – BSA/AML Risk Assessmenthttp://www.ffiec.gov/bsa aml infobase/pages manual/olm 005.htmFRB Supervisory Guidance on Model Risk g/srletters/sr1107a1.pdfFinCEN Advisory to U.S. Financial Institutions on Promoting aCulture of Compliancehttp://www.fincen.gov/statutes regs/guidance/pdf/FIN-2014A007.pdfFinCEN Enforcement Actionshttp://www.fincen.gov/news room/ea/80
Final Thought“The level of thinking necessary toaddress today’s problems must begreater then that which got us here.”Albert Einstein81
Thank youStephen R. King, JD, AMLPDirector, Regulatory Compliance Services617-428-5448sking@wolfandco.com82
AML Software - Introduction Areas the Automated Software could impact include, but are not limited to: Suspicious Activity Monitoring Suspicious Activity Reports ("SARs") Enhanced Due Diligence Currency Transaction Reporting ("CTRs") CTR Exemptions 314(a) Request Lists OFAC Wire Transfers 20
