1 / 73

Data Warehouse Structures for AML Applications

Data Warehouse Structures for AML Applications. J ERZY K ORCZAK , Wroclaw University of Economics LSIIT, CNRS, Strasbourg , France B ŁAŻEJ O LESZKIEWICZ , Wroclaw , Poland. Money Laundering - Definition.

inocencia
Télécharger la présentation

Data Warehouse Structures for AML Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data WarehouseStructures for AML Applications JERZY KORCZAK,Wroclaw University ofEconomics LSIIT, CNRS, Strasbourg, France BŁAŻEJ OLESZKIEWICZ, Wroclaw, Poland

  2. Money Laundering - Definition Money launderingis the practice of engaging in financial transactions in order to conceal the identity, source, and/or destination of money, and is a main operation of the underground economy. In this paper: identification the methods and technology of the anti- money laundering(AML) process introduction of SART system structures of data warehouse selectedproblems of AML systems

  3. Outline Problem of AML – the state of theart Fundamentalaspects of AML system design System for Analysis and Registration of Transactions Architecture of data warehouse Casestudy – examples of a fewselectedproblems Conclusion and futureresearch

  4. Process of moneylaundering Stages: Placement: refers to the initial point of entry for funds derived from criminal activities. Layering: refers to the creation of complex networks of transactions which attempt to obscure the link between the initial entry point, and the end of the laundering cycle. Integration: refers to the return of funds to the legitimate economy for later extraction.

  5. Examples of stages of theprocess

  6. AML software – thestate-of-the-art packages include capabilities of name analysis, rules-based systems, statistical and profiling engines, neural networks, link analysis, peer group analysis, and time sequence matching KYC solutions that offer case-based account documentation acceptance and rectification, as well as automatic risk scoring of the customer (taking account of country, business, entity, product, transaction risks) other elements: portals to share knowledge and e-learning for training and awareness 

  7. Types of AML systems All financial institutions globally are required to monitor, investigate and report transactions of a suspicious nature to the financial intelligence unit of the central bank in the respective country. Types of software addressing AML business requirements: Currency Transaction Reporting (CTR) systems, which deal with large cash transaction reporting requirements (15,000 E) Customer IdentityManagementsystems which check various negative lists (such as OFAC) and represent an initial and ongoing part of Know Your Customer (KYC) requirements Transaction MonitoringSystems, which focus on identification of suspicious patterns of transactions which may result in the filing of Suspicious Activity Reports (SARs). Identification of suspicious (as opposed to normal) transactions is part of the KYC requirements.

  8. Modules of AML system Software applications effectively monitor bank customer transactions on a daily basis and, using customer historical information and account profile, provide a "whole picture" to the bank management. Each vendor's software works somewhat differently; some of the modules in an AML software are: Know Your Customer (KYC) Entity Resolution Transaction Monitoring Compliance Reporting Investigation Tools

  9. Transaction Monitoring Systems TMS focus on identification of suspicious patterns of transactions which may result in the filing of Suspicious Activity Reports (SARs). Identification of suspicious transactions is part of the KYC requirements. Financial institutions face penalties for failing to properly file CTR and SAR reports, including heavy fines and regulatory restrictions, even to the point of charter revocation.

  10. Outline Problem of AML – the state of theart Fundamentalaspects of AML system design System for Analysis and Registration of Transactions Architecture of data warehouse Casestudy – examples of a fewselectedproblems Conclusion and futureresearch

  11. Typicalsolutionsvs. Analytical SQL Server

  12. Architecture of Analytical SQL Server

  13. SART internalarchitecture

  14. Major modules of SART

  15. Major modules of SART 16

  16. Outline Problem of AML – the state of theart Fundamentalaspects of AML system design System for Analysis and Registration of Transactions Architecture of data warehouse Casestudy – examples of a fewselectedproblems Conclusion and futureresearch

  17. Main issues Problem of scalability Data structureCharts of Accounts of General Ledger OLAP Data Warehousebased on General Ledger Reporting Transactionchains

  18. Architecture of data warehouse Problem of scalability • Size of dimensions: • General Ledger Dimension 60 000 entries, • Bank customers Dimension 500 000 entries, • Time Dimension 3600 entries (the duration of operations 10 years), • Number of measures in OLAP cube is 5.

  19. Architecture of data warehouse Problem of scalability Approximate size of OLAP cube of 230.2 PB Approximate calculation of the indicated OLAP cube’s size shows that it is not feasible to store OLAP data without Compression. Approximate number of entries in OLAP cube was: 60 000 ×500 000 × 3600 × 5 = 0.54*1015 . Considering the minimum size of data stored in OLAP cube (4 bytes dimension identifier, 8 bytes measure’s value) this value should increase by 3×4×5×8 = 480 times that is 259.2*1015 bytes 20

  20. Heterogeneous data warehouse dimensions of General Ledger

  21. Homogenous dimensions of TIME

  22. Data Warehouse of General Ledger • Modeling and implementation of the Data Warehouse of General Ledger • Fact Table • Dimensions

  23. Data Warehouse of General Ledger Star Schema 24

  24. Data Warehouse of General Ledger Normalized Time Dimension in a Snowflake Schema 25

  25. Data Warehouse of General Ledger Hierarchicalschema (always a la star schema) 26

  26. Data Warehouse – FactTable

  27. Facts Table – operation 28

  28. Facts Table – operation 29

  29. Facts Table – operation 30

  30. Facts Table – operation 31

  31. Facts Table and Charts of Account 32

  32. Integration of accounting model and transaction mode

  33. Summary of data structure Technologicalcharacteristics: non uniform hierarchy number of nodes: 61 297 withinnumber of syntheticaccounts: 29 268 max depth: 10 Applicationcharacteristics: decreesdictionary of General Ledger dictionary of transactionaccounts dimensions of data warehouse

  34. Outline Problem of AML – the state of theart Fundamentalaspects of AML system design System for Analysis and Registration of Transactions Architecture of data warehouse Casestudy – examples of a fewselectedproblems Conclusion and futureresearch

  35. CaseStudy – somestatistics sampledatabase number of processedrecords (daily): min: ~1,000 rec. (weekend) max: ~300,000 rec. (end of month) monthly (January 2008) total: 2,497,280 rec./month dailyaverage : 80,557 rec. DW dimensions: 197,046 rec.

  36. Characteristicsof DW (General Ledger) 13,299,773 rowsinFactsTable 20,581,733 Cartesian products in OLAP Cube 970,987,198 number of OLAP operations executedduringrecomputing of OLAP cube 970.987.198 / 20.581.733 = 47,177 averagenumber of OLAP operations overregistereddecree 37

  37. OLAP Data Warehouse of General Ledger • Implementation of the OLAP DW of General Ledger • FactTable • Dimensions • OLAP Cube • CubePivot as changesviewingin OLAP cube

  38. OLAP Data Warehouse – General Ledger

  39. OLAP Data Warehouse – General Ledger 40

  40. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension 41

  41. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension 42

  42. Data Warehouse – CubePivot Dimension General Ledger Dimen. Time Account N OLAP operation Cash in ZLP Dimension Client Account 1 Dimension Client Account 1 Account N Cash in ZLP Dimension Time Dimension General Ledger

  43. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension 44

  44. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension 45

  45. OLAP Data Warehouse – General Ledger 46

  46. Performance of DW SART OLAP Data import: 57,952 decrees OLAP recalculation: OLAP calculation: 4 min. 10 sec (250 sec.) OLAP operations: 5,275,770 number of createdCartesian products OLAP: 991,675 averagenumber of OLAP operations/sec: 21,103.1 op./sec. 47

  47. Performance of DW SART OLAP OLAP reporting performance: Chart of Accountsdimension OLAP view: Maximum: ~2 sec. Average: ~0.6 sec. Time dimension OLAP view: Maximum: ~1.2 sec. Average: ~0.4 sec. 48

  48. Summary of DW architecture the SART OLAP Data Warehouse model based on non-uniform dimensions OLAP model based on non-uniform dimensions Cube Pivot operation with slice functionality 49

  49. SART – Transactionmerging Transaction merging processin SART Buildinga transaction model based on the General Ledger decrees Integration ofthetransaction model with theGeneral Ledger accounting model Integration of thetransaction model with a OLAP reporting 50

More Related