From source to surveillance: the hidden risk in AML monitoring system optimization September 2010

Transcription

1 From source to surveiance: the hidden risk in AML monitoring system optimization September 2010

2 Contents The heart of the matter 1 Activey managing AML monitoring data can reduce costs, save time, avoid reguatory remediation, and improve assurance An in-depth discussion 2 Institutions may occasionay address the effectiveness of their AML monitoring systems, but are they ooking at the right things? Diagnosing your transaction data probem 3 The right approach transaction reference data management 4 paired with a reconciiation utiity How data quaity affects AML transaction monitoring 6 Estabishing a transaction reference data management system 7 Deveoping an effective reconciiation utiity 8 Laying the groundwork for an effective soution 9 What this means for your business 10 Institutions reap compiance, financia rewards from soution that combines transaction reference data management with a transaction reconciiation utiity Case study 12 Contacts 13

3 The heart of the matter Activey managing AML monitoring data can reduce costs, save time, avoid reguatory remediation, and improve assurance As the financia crisis eves off, reguators are now refocusing their efforts on antimoney aundering (AML) and terrorist financing enforcement. This increase in reguatory scrutiny is compeing many financia institutions to take a coser ook at their AML operations as they seek innovative ways to meet reguator expectations and reduce costs in an uncooperative economic environment. Considering the reguatory compexity and high costs associated with AML transaction monitoring, institutions often start with improving the effectiveness and efficiency of their automated AML transaction monitoring aert engines. When propery configured, these systems can hep institutions detect patterns of activity that may indicate moneyaundering or terrorist-financing activities. Poory defined aert engine parameters and threshods, however, may raise fags unnecessariy or even miss significant money aundering activity. PricewaterhouseCoopers (PwC) anaysis indicates that 90 percent to 95 percent of a aerts generated by AML aert engines are fase positives. These high fasepositive rates ead to significant monitoring costs but more disconcerting are the fase negatives, or the cases of money aundering that are not detected. Unike fase positives, these are hidden, are harder to quantify, and can have significant negative impact. Both of these issues can be addressed if institutions refine their rue set threshods. But tuning without first tacking AML data quaity can ead to skewed and misrepresented threshods. By the time the data is discovered to be inaccurate or incompete, a threshod change may have aready been impemented, eading to costy rework and the potentia for a reguatormandated transaction ookback. Many institutions are caught in a cyce of tuning, rework, ookback, tuning, rework, ookback, etc., because data quaity issues are addressed haphazardy instead of systematicay. The quaity of data ceary affects the quaity of the aerts generated by a transaction monitoring system. Active management of monitoring data is paramount to improving data quaity. When AML transaction monitoring systems were initiay impemented, the accuracy of the transaction code data and rues that determined what quaified as an exception may have been estabished and vetted. Since the origina impementation, however, many institutions have not reassessed and verified whether the transaction codes and data that feed their AML monitoring systems remain at initia quaity eves. Despite this, many institutions have sti spent time and money tuning monitoring rues using outdated, inaccurate, and incompete transaction reference data. This reiance on a one-time assessment of data ignores an institution s dynamic fisca andscape as it introduces new products, consoidates financia entities, and its IT infrastructure evoves. To estabish compete and accurate AML monitoring data, institutions shoud consider a soution that combines transaction code reference data management with a transaction reconciiation utiity. Data management is the forma transaction code AML cassification process that incudes compiance concusions reached for each transaction code (i.e., whether or not the transaction code shoud be excuded or incuded in AML monitoring and why) and the preservation of the nature and extent of the compiance review procedures performed. The transaction reconciiation utiity provides recent transaction reconciiation and exception reports between source and surveiance systems to evidence effective system transaction fow. By addressing the quaity and consistency of transaction code data, institutions can save time and money, avoid substantia fines and costy remediation programs, and increase assurance that their AML transaction monitoring systems are operating effectivey. September 2010 From source to surveiance 1

4 An in-depth discussion Institutions may occasionay address the effectiveness of their AML monitoring systems, but are they ooking at the right things? Many institutions have overooked the need to periodicay review AML monitoring data that is essentia for a fuy functioning and efficient AML monitoring system. Despite the dramatic increase in transaction voume, mass consoidation of institutions post-financia crisis, ever-expanding product ines, and a continuousy shifting reguatory and business andscape, many institutions sti base their AML decisions on source data cassifications and mappings estabished by their initia assessments, which may have been performed eight to 10 years ago. This reiance on an initia data assessment can have an adverse impact on the effectiveness of an institution s AML compiance program. Consider an institution that, prior to the financia crisis, was a typica deposit and oan regiona bank. When its AML monitoring system was impemented, the appropriate compiance and technoogy personne worked with each business ine to identify a of the bank s products and transaction types that required AML monitoring. Every system and data source was evauated, and the reevant underying data was mapped to the AML monitoring system s transaction codes so that the monitoring rues coud hep identify potentiay suspicious transaction patterns. Fast forward to today: Since its initia AML monitoring system impementation, this bank not ony acquired and integrated two institutions, but it aso transformed its commercia ending function by impementing a new servicing system, expanding its product offerings and revamping its onine banking function. With each of these institutiona changes, a compete reassessment of the AML transaction monitoring system s reference data and transaction code mappings shoud have been performed in conjunction with the business ines, compiance, and IT. This reassessment did not occur, however. Instead, the institution spent time and money performing a compete AML transaction monitoring rues optimization project with the intention of generating more productive aerts with ess fase positives. Because there was no reassessment of the reference and transaction data, the institution used inaccurate and incompete data as part of its rues optimization process. Unfortunatey, during a reguatory examination focused on the optimization changes to the rues engine, the reguators uncovered severa data issues and required the institution to perform a transaction ookback. Why transaction codes matter Institutions utiize transaction codes to identify and differentiate financia transactions. These codes are significant to a number of operationa processes within institutions, such as the monitoring of transactions for antimoney aundering purposes. Transaction code cassification and mappings are used across various AML systems to effectivey determine which transactions are in scope for AML transaction monitoring. Additionay, the mappings are used to categorize each transaction into appropriate AML transaction groups, such as cash, wire, monetary instruments, account transfers, etc., which makes monitoring more consistent across business ines and geographies. Effective transaction monitoring and vaidation have become extremey difficut due to increasing transaction voumes, expanding business ines and geographies, and perpetua changes to the business andscape. 2 From source to surveiance September 2010

5 As we see from this exampe, severa risks emerge when an institution overooks the need to periodicay reassess its transaction monitoring reference data, especiay when institutions are transforming as rapidy as they are today and need to continuousy monitor the reference data for changes. These risks incude arge monetary remediation penaties from reguators, excess costs in terms of staff hours (time to run exception reports, dea with fase positives, etc.), and reduced assurance that the AML program is working effectivey. The key to reduce these risks is to focus on upstream data sources and how that data is managed as opposed to anayzing the downstream data eements that comprise an AML monitoring system s aert engines. A soution that pairs transaction reference data management with a reconciiation utiity is crucia to maintaining acceptabe eves of data quaity in monitoring systems. It can enabe institutions to stay ahead of quaity issues and reduce institutiona risk. Diagnosing your transaction data probem Managing mutipe source systems and the massive voume of transaction data these systems can generate is chaenging. Determining which codes shoud be incuded or excuded, documenting the AML data fow or modification ogic, and estabishing a consistent, enterprise-wide data integrity standard are a few of the obstaces institutions must successfuy hurde to manage transaction data effectivey. Contros issues Your institution may be experiencing transaction data contro issues if: A arge number of inactive transaction codes exist. Transaction codes in other jurisdictions are not in the anguage required by home country reguators. Incorrect transaction-to-transaction code assignments exist. Inconsistencies in transaction code mapping exist. A arge number of transaction codes are excuded when they shoud be incuded. A arge number of transaction codes are incuded when they shoud be excuded. Misceaneous and ambiguous transaction codes represent a arge number of transactions. Transaction codes are managed differenty across business sectors and countries. Tracking and documentation issues Your institution may be experiencing transaction data tracking and documentation issues if: Litte or no documentation exists on transaction code incusion or excusion and mapping determinations. Litte or no documentation of AML data fow and modification ogic exists as data traves from source systems to data warehouses to the monitoring system. There is no way to prove that transaction voumes in source and monitoring systems reconcie. Transactions from a source system are ost and not oaded into the monitoring system. There is no centra organization utimatey responsibe for resoving AML data integrity issues and performing active reconciiation reviews, root-cause anaysis and correction, and competeness testing. Data integrity issues Your institution may be experiencing data integrity issues if: Data definitions are inconsistent between functions and typicay there is no current enterprise-wide data integrity standard for transaction codes. How institutions resove data integrity issues among their various functions (front office, IT, operations, compiance), business sectors, and geographies is uncear. Managing data integrity and reconciiation between the systems and countries is highy compex because of the inconsistencies in how data is handed. Often, data competeness and accuracy issues are manifested downstream when the AML monitoring system produces a high number of ineffective aerts, which drives significant costs for itte vaue. Data integrity issues are generay discovered when a compiance faiure occurs, eading to costy remediation efforts. Initiatives address transaction code data for specific purposes, but there is no overarching governance of transaction code integrity. September 2010 From source to surveiance 3

6 The right approach transaction reference data management paired with a reconciiation utiity Data is coected and stored in various systems within the business ines. For exampe, commercia ending functions typicay have an origination system and a servicing system. In some cases, the same information (e.g., customer and account data) is stored in each system and other data points (e.g., customer credit information) is ony stored in the origination system. Data about a customer may reside in mutipe systems across different business ines. This data is typicay manipuated, aggregated, and stored in databases and warehouses between the source systems and the AML surveiance system. This data manipuation is often compex and undocumented, which presents chaenges to AML transaction monitoring. Data is typicay manipuated using various types of programming ogic in one or more ways as it is prepared to be passed to AML monitoring. It is at this point where faiures can occur and go undetected for ong periods of time. Types of data manipuation ogic incude: Transaction code incusion/ excusion ogic Matching ogic (e.g., match to vaue in ookup tabes for routing information) Text parsing ogic Currency conversion ogic Aggregation ogic (e.g., aggregating sma doar transactions into one aggregated transaction) Reassignment ogic (e.g., reassignment of a group of transactions to another transaction code) Transaction fiter ogic (e.g., excusion of reversas) Data enrichment ogic (e.g., augmenting with party detais) Fied excusion ogic (e.g., fied not carried through from source to monitoring system) Mutipe transaction egs handing (e.g., transaction description fied exceeds maximum text fied capacity so additiona transaction egs are created to hande text overfow) Issues that can arise from errors in the data manipuation process incude: Defect in data manipuation process resuts in $0 currency conversion issue that goes unde-tected because $0 is ignored by monitoring system rue. Certain aert rue required fieds (e.g., beneficiary name) are not popuated and 99% of input transactions are subsequenty ignored by monitoring system rue. New funds transfer transaction code is created and not cassified as either incuded or excuded in monitoring. Process does not know how to hande so defauts to excuded. A reated transactions never reach monitoring system. Process enriches nu address fied with defaut vaue. This resuts in a high number of fase positives generated for certain aert rues because address is used as a point of aggregation. Process treats certain eectronic funds transfers as SWIFT wires and parses identifier fied as if it were a BIC code which erroneousy pus two digit characters and treats them as country codes. This eads to the generation of a high number of aerts to highrisk countries. Process treats each eg on a transaction as a transaction resuting in a arge number of dupicate entries. 4 From source to surveiance September 2010

7 As AML requisite data moves through the data process fow from source to surveiance, it is manipuated, treated, and transformed one or more times. What exacty is occurring to the data and how does this impact the abiity to effectivey monitor that data? Figure 1 Exampe source systems Data management processes AML surveiance Commercia ending Origination systems Servicing systems Credit info repository Cash management Servicing systems Unusua activity and abnorma behavior rues Residentia mortgage Origination systems Servicing systems Credit info repository Customer Transaction Account Funds transfer? Deposits Onboarding systems Core banking systems Aerts Aerts Marketing & saes Reationship database Saes force system A controed system ensures that transaction codes in scope for monitoring are propery managed, that a compiance review was performed and that IT impemented the change correcty. The transaction reconciiation utiity provides exception reports to evidence effective system transaction fow. By addressing the quaity and consistency of transaction code data, institutions can save time and money, avoid substantia fines and costy remediation programs, and increase assurance that their AML transaction monitoring systems are operating effectivey. Figure 2 Figure 2 Exampe source systems Data management processes AML surveiance Commercia ending Origination systems Servicing systems Credit info repository Cash management Servicing systems Transaction code reference data management Ceary defined, documented and controed manipuation rues Unusua activity and abnorma behavior rues Residentia mortgage Origination systems Servicing systems Credit info repository Customer Transaction Account Funds transfer Deposits Onboarding systems Core banking systems Aerts Marketing & saes Reationship database Saes force system Periodic exception reporting process Reconciiation utiity September 2010 From source to surveiance 5

8 How data quaity affects AML transaction monitoring The accuracy and competeness of data can have a significant effect on the quaity of the aerts generated by a transaction monitoring system. Often, streams of data are manuay and eectronicay transformed mutipe times from source systems on their way to becoming imported into an AML surveiance system. These transformations can generate conversion errors that may ead to incorrect aerts or even resut in highrisk information faiing to trigger an aert. Further scrutiny of how transaction data fows through an AML system demonstrates why institutions shoud go beyond anayzing their downstream data eements. In this hypothetica exampe, suppose 1 miion wire transactions are fed into an AML aert engine and 1,000 aerts are generated (for simpicity s sake, assume one aert contains ony one transaction). Of these 1,000 aerts, 50 require a suspicious activity report (SAR) fiing. One might concude that this aert rue is we-tuned given its 1-to-1,000 aert-to-transactions rate and 5 percent SAR fiing rate. However, coser inspection of the 1 miion wire transactions reveas that the amount fied for 900,000 of the transactions is $0. Why woud 90 percent of the transactions have a $0 amount? A root-cause anaysis identifies an issue with the transformation of wire transactions from source system to AML aert engine. Non-US currency transactions that need to be set to US currency are erroneousy set to $0 because there is an error in the spot-rate conversion ogic. How does this affect optimization resuts? Since the aert rue ignores a amount vaues of $0 or ess, the effect is substantia. Essentiay, the aert engine bypassed 90 percent of the transaction data. Because of this inordinate number of unevauated transactions, a timeconsuming, expensive ookback is required. The critica takeaway from this exampe is that simpy ooking at transaction counts of rue inputs and outputs for threshod anaysis, without first vaidating that the underying data is aigned with the data requirements of the rue, can ead to incorrect concusions and costy consequences. 6 From source to surveiance September 2010

9 Estabishing a transaction reference data management system Assessing the accuracy and competeness of a financia institution s data at the root of its source systems is far from a simpe task. The compexity and sheer number of variabes that affect institutions attempts to enhance their transaction data and systems make it essentia to consider a more far-reaching soution than simpy tweaking their aert engine monitoring rues. This soution begins with the impementation of a system of comprehensive transaction reference data management, and it suppements the system with a reconciiation utiity that provides reports that evidence effective system transaction fow. There are four main components to estabishing a transaction reference data management system: Estabish a baseine Poicies and procedures Cassification and assessment Monitoring and vaidation Estabish a baseine Estabishing an enterprise-wide transaction code treatment process within the AML compiance organization is a critica first step in the impementation process. For many institutions, itte or no documentation exists that detais how mapping is determined or when transaction codes shoud be incuded or excuded from consideration in an AML transaction monitoring system. By documenting the rationae and process for incuding or excuding transaction data as it fows from the source systems to monitoring systems, a quaity baseine is created for existing transaction codes. Poicies and procedures Whie the baseine step heps expain why transaction codes may fa within AML monitoring parameters, creating the poicies and procedures for how transactions codes are created, modified, and managed ays the groundwork for an institution to estabish a uniform, enterprise-wide process for handing transaction code data. This step is where buy-in from a functiona stakehoders is a must. It can hep institutions avoid probems such as front-office personne not propery impementing changes suggested by back-office compiance teams, or the business approving a code strategy before compiance has a chance to review and assess it. Making compiance a stakehoder in the transaction code management process offers back-office teams insights on strategic business decisions and aows them to participate in the process of creating or amending the transaction codes that support these decisions. The front office aso pays an integra roe in the transaction code compiance process. Proper training on the importance of standardized transaction codes and transparent communication from management on why these poicies and procedures must be foowed, as we as how business objectives wi be achieved as a resut, wi hep the front office ensure that changes are impemented as panned. Cassification and assessment With a transaction code treatment process and the poicies and procedures surrounding how to create, modify, or deete transaction codes in pace, an institution needs to deveop a process for cassifying and assessing new or modified transaction codes and determining if these codes shoud be incuded or excuded from the AML surveiance system. This process wi hep an institution overcome probems reated to time when the business needs immediate execution for a new product, for exampe and the decentraized and manua management of transaction code ists, which can be more costy and prone to errors than a centraized, automated cassification system. To address timing considerations, an institution can estabish a banket documentation process and use preapproved compiance assessments to meet its business needs. On the cost front, there are many ways an institution can everage a centraized transaction code administration process. When differences are not warranted, it can imit the number of unique transaction codes managed by the institution through standardization of transaction codes. A centraized system can aso automate notifications of new or amended transaction codes to compiance, produce and manage a centraized ist of a transaction codes across an institution, and deveop a systematic approach to reporting a new transaction codes and their corresponding compiance and business assessments. Another way to hep mitigate costs when changes to transaction codes need to be impemented is to design the transaction code assessment process as a middeoffice hub. This function woud incude the periodic reconciiation of the transaction codes within each source system to a standardized master ist of transaction codes. The design wi hep imit the costs and risks associated with the impementation of contros within each product processor. Monitoring and vaidation The fina component to an effective transaction reference data management system is to vaidate that transaction codes are monitored competey and accuratey, incuding activity within inactive codes. Once this stage is reached, the automated system and the compiance officers who oversee it wi periodicay assess whether new or modified transaction codes status shoud be recassified as in scope or out of scope. September 2010 From source to surveiance 7

10 Deveoping an effective reconciiation utiity Once the transaction reference data management system is in pace, a dedicated reconciiation utiity wi hep ensure that an institution s AML transaction monitoring system is operating effectivey. Estabishing and impementing this reconciiation utiity typicay invoves four steps: Configuration Sourcing and standardization Monitoring and event identification Exception reporting and response Configuration Estabish a centraized AML data integrity and reconciiation utiity. Ideay, the utiity shoud be housed within a current reconciiation utiity aready existing within the institution. Most institutions have a shared service function in pace to perform reconciiations for financia reporting processes. Institutions can more rapidy and cost-efficienty operationaize the utiity by everaging the function for AML reporting processes. Sourcing and standardization At this stage, the objective is to source and standardize the input and output of transactions from source systems to data warehouses to AML monitoring patforms. An institution shoud create a standard data mode based on the data requirements found within each monitoring system. In other words, the mode shoud be created based on the data that each monitoring rue requires to run efficienty. Monitoring and event identification After sourcing and standardization are compete, an institution shoud monitor and reconcie the inputs and outputs of its transactions as they fow through its systems to ascertain breaks in data integrity. This is not as simpe as reconciing counts by transaction code given that transaction data is manipuated and potentiay changed through its journey to monitoring system. This step wi be exponentiay more difficut based on the number of transaction processing systems, data warehouses, and AML monitoring systems that an institution operates. Typicay, many of the data process rues are embedded within programming code in mainframes and data sourcing toos. Programming code anaysis can derive what is happening to required data as it treated by the code. Using the data mode created during the sourcing and standardization step, each data point shoud be traced backward from monitoring system to source system to determine how it is treated. Common treatment incudes matching ogic (e.g., match to vaue in ookup tabes for routing information), text parsing ogic, currency conversion og, and aggregation ogic. Given the compexity invoved in this step, it shoud be impemented iterativey so that each proposed reease can be proven successfu prior to reeasing to additiona areas. Exception reporting and response Once the data treatment process is ceary documented, this information can be buit in the reconciiation utiity. This wi aow exceptions to be generated by the utiity rather than by manua review on reconciiation reports. When breaks in data integrity are identified, the utiity wi work with appropriate stakehoders to remediate the root cause and test to ensure the correction was done propery and is functioning appropriatey. Many factors affect the deveopment of an effective transaction reconciiation utiity. Some eading practices that broady appy across a types and sizes of financia institutions incude: Leverage existing operations and technoogy when possibe. Use a risk-based approach to determine appropriate eve of monitoring (i.e., at a data process gates or just at source and endpoint). Assign ownership of transaction codes so, if exceptions occur, there is accountabiity of resoution. Estabish service eve agreements to set expectations of unit. Use phased impementation that incudes piots with both an easy, quick win and a compex area. Report usabiity is a key factor to ongterm success of reconciiation utiities. Reports shoud highight red fags and be distributed ony to imited numbers of recipients prior to exception confirmation. There must be a common set of metrics, but deviation threshods need to be taiored to risk toerance of the institution, region, and ine of business. Contro totas and counts are important, but data quaity is equay important and must be monitored as we. One technoogy and operations mode does not fit a processes from simpe to compex. Vendor seection is vita. Pick a vendor that offers soutions that are fexibe enough to meet your institution s needs. Often premium appications are too compex for simpe needs, and simpe appications cannot hande compex needs. 8 From source to surveiance September 2010

11 Laying the groundwork for an effective soution Once an institution commits to impementing a transaction reference data management and transaction reconciiation utiity soution, there are severa steps that wi ay the groundwork for a more successfu impementation process. Foowing these steps wi hep estabish buy-in from management and a functiona stakehoders. Prior to initiating this type of project, PwC recommends financia institutions: 1. Assembe stakehoders to review current state of AML data contro and the effort associated with estabishing a common transaction code nomencature and reconciiation utiity and the vaue to be derived. 2. Deveop transaction code reference data and reconciiation utiity target operating modes (TOMs) (e.g., oversight/standard setting vs. execution of the operationa processes). 3. Deveop business cases that wi contain the investment needed to reach the TOMs and the recommended yeary funding for the effort. 4. Deveop a roadmap that prioritizes the effort of the impementation of the TOMs. 5. Estabish a steering committee and governance to ratify the initiation of the review, ensure the review is prioritized correcty, and endorse the strategy and business case. September 2010 From source to surveiance 9

12 What this means for your business Institutions reap compiance, financia rewards from soution that combines transaction reference data management with a transaction reconciiation utiity When the most reiabe component to the AML compiance equation is change, institutions need to impement a soution that not ony periodicay vaidates the quaity of its transaction data, but heps institute a framework by which the everyday process becomes an ingrained part of the way the institution conducts its business. By foowing PwC s approach of managing transaction reference data and impementing a transaction reconciiation utiity, institutions can more effectivey and efficienty begin reaizing the benefits of an enhanced AML monitoring system. The primary benefits to impementing a transaction reference data management and reconciiation utiity soution incude: Avoiding reguatory remediation (e.g., AML transaction ookbacks) Trimming costs by reducing the time and cost per aert of fase positives Gaining a greater eve of assurance that AML systems are accuratey capturing the right surveiance data Before impementation, however, input and buy-in from stakehoders shoud be secured. The stakehoder groups compiance, interna audit, IT and operations, front-office business ines often have different or even competing viewpoints, goas, and motivations for why they woud want to manage transaction code data more effectivey. From the compiance team s perspective, impementing this type of soution enhances the team s abiity to meet its transparency and competeness monitoring objectives. It aso heps compiance quicky and concisey demonstrate the effectiveness of the transaction monitoring processes and systems to reguators and interna audit. The reconciiation utiity can significanty enhance the interna audit process. Instead of interna audit spending the buk of its time tracing the numbers and verifying the data, the utiity can do that work and save time and money by streamining interna audit s efforts For the IT and operations group, the soution aows team members to enhance the quaity of information and refocus on using automation and anaytics to sove business probems. It reduces the number of distinct transaction codes, reduces the number of manua processes, improves the content and integrity of data, and enhances an institution s abiity to impement enterprise-wide changes. The ast thing front-office personne want is for compiance to hinder their abiity to do business. Effective transaction reference data management and the reconciiation utiity provide severa top-ine benefits. They hep improve customer service standards, enhance the abiity to everage data assets to improve existing businesses or enter new markets, and aow the institution to better compete by providing comparative information across customer segments and markets. Some top-tier institutions have impemented or are in the process of impementing a soution that effectivey manages transaction reference data and uses a transaction reconciiation utiity. They have significanty impacted their AML monitoring performance as a resut of this focus on assessing the upstream data processes. Rather than serving as a stricty back-office compiance function, AML transaction monitoring, when done correcty with accurate and compete data continuousy tracked at the source systems, can benefit a areas of an enterprise. The hard and soft benefits matrix (see Figures 3 and 4) heps quicky show the benefits reaized by the compiance, IT and operations, and business and front-office teams. 10 From source to surveiance September 2010

13 Figure 3: Hard benefits matrix Benefit Compiance IT / Ops Business / Front Office Reduced costs reated to the reduction in AML reguatory remediations Reduced interna costs in deaing with business noncompiance Reduced IT and business costs associated with maintaining a arge number of heterogeneous transaction codes Improved breath of revenue channes by broady reeasing region-specific strategies Increased revenue from more precise and consistent transaction pricing New revenue channes by monetizing as an asset the aggregate benchmark information of customer activity across the bank Enhanced abiity to cross-se with transaction code usage as an additiona data point in customer segmentation Figure 4: Soft benefits matrix Benefit Compiance IT / Ops Improved AML oversight within institution by optimizing AML systems Better aignment of a compiance-reated activities that require transaction codes Enhanced view from reguators Improved anayst productivity and depth and breadth of anaysis Improved consistency in reporting across regions and ines of business Improved timeiness of the impementation of crossregion/business unit strategies that require ike transaction codes Reduced risk from incrementa, staged impementation of new AML and other technoogies that rey on transaction codes and transactions from product processors Improved attractiveness of institutions to customers by making it easier for them to transact across regions and business units by standardizing transaction services and pricing Business / Front Office September 2010 From source to surveiance 11

14 Case study Chaenge A bank had been making annua adjustments to threshod eves of its aert engines in its antimoney aundering (AML) monitoring system, but data issues had been triggering reguatormandated ookbacks in recent years. To hep resove these issues, the bank was in the process of aunching an initiative to improve its data contros for AML compiance across a businesses and regions gobay. By proactivey monitoring compiance data contro risks, the cient anticipated improving its abiity to detect and address issues before they become reguatory concerns, whie possiby increasing its operationa efficiency through fewer fase positives. The first step in the improvement process was to assess transaction code reference data for consistency and accuracy prior to its usage in the AML monitoring systems. PwC s roe and objectives PwC undertook an effort to review a transaction codes for monitoring incusion or excusion cassification and AML system mapping. PwC identified more than 100,000 transaction codes from 125 core banking systems that required review. PwC appied a mixed approach that incuded an automated, knowedge-based code description cassification; a targeted transaction samping technique; a transaction existence and fow review; and a controed manua review using PwC proprietary software. Vaue to the cient PwC s approach ensured that the review effort appied risk concepts consistenty across the various geographies and businesses whie aowing for the inherent differences that exist within each. It aso acceerated the review process in a controed manner whie ensuring accuracy and competeness with minima impact to IT, operations, and compiance. The bank was abe to eiminate a arge amount of unnecessary data that was impacting the aert generation process as a resut of PwC s recommendations. The bank aso reduced its risk exposure by proactivey identifying a sma number of transaction codes that shoud have been incuded in monitoring. This initiative improved the effectiveness and efficiency of the bank s AML monitoring system and aid the groundwork for creating and impementing a sustainabe function for managing transaction code reference data and an AML data reconciiation utiity. 12 From source to surveiance September 2010

15 Contacts To have a deeper conversation about how this subject may affect your business, pease contact: Jeff Lavine Partner jeff.avine@us.pwc.com Patrick Giacomini Partner patrick.a.giacomini@us.pwc.com Thomas Messina thomas.messina@us.pwc.com Nathan Thomas nathan.thomas@us.pwc.com Marco Iacono marco.p.iacono@us.pwc.com September 2010 From source to surveiance 13

16 PricewaterhouseCoopers LLP. A rights reserved. PricewaterhouseCoopers refers to PricewaterhouseCoopers LLP, a Deaware imited iabiity partnership, or, as the context requires, the PricewaterhouseCoopers goba network or other member firms of the network, each of which is a separate and independent ega entity. This document is for genera information purposes ony, and shoud not be used as a substitute for consutation with professiona advisors.