1. Data Warehouse Structures
for AML Applications
JERZY KORCZAK, Wroclaw University of Economics
LSIIT, CNRS, Strasbourg, France
BŁAŻEJ OLESZKIEWICZ, Wroclaw, Poland

2. Money Laundering - Definition
Money laundering is 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
selected problems of AML systems

3. Outline Problem of AML – the state of the art
Fundamental aspects of AML system design
System for Analysis and Registration of Transactions
Architecture of data warehouse
Case study – examples of a few selected problems
Conclusion and future research

4. Process of money laundering
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.

6. Examples of stages of the process
Placement Stage
Layering Stage
Integration Stage
Cash paid into bank
(sometimes with staff complicity or mixed with proceeds of
legitimate business).
Wire transfers abroad (often using shell companies or funds disguised as
proceeds of legitimate business).
Resale of goods/assets.
Income from property or legitimate business assets appears "clean".
Monies are placed into retail economy or are smuggled out of the country
Complex web of transfers (both domestic and international) makes tracing original source of funds virtually impossible.
 Establishment of anonymous companies
Transformation into other asset forms: travellers cheques,postal orders,etc.
Cash exported. Cash deposited in overseas banking system.
Sending of false export-import invoices overvaluing goods

7. AML software – the state-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 

8. 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 Identity Management systems which check various negative
lists (such as OFAC) and represent an initial and ongoing part of Know
Your Customer (KYC) requirements
Transaction Monitoring Systems, 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.

9. 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

10. 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.

11. Outline Problem of AML – the state of the art
Fundamental aspects of AML system design
System for Analysis and Registration of Transactions
Architecture of data warehouse
Case study – examples of a few selected problems
Conclusion and future research

12. Typical solutions vs. Analytical SQL Server

13. Architecture of Analytical SQL Server
Warto tu zaznaczyć, że architektura ASQL zawiera w sobie wszystkie elementy klasycznego rozwiązania, nie ma problemu integracji danych.

14. SART internal architecture

15. Major modules of SART

16. Major modules of SART
Transaction Register (Rejestr Transakcji Bankowych) – repozytorium do składowania transakcji zrealizowanych przez bank. Transakcje składowane w tym repozytorium są wynikiem procesu scalania transakcji na podstawie dekretów Księgi Głównej.
Account Register (Rejestr Rachunków) – repozytorium Rejestr rachunków bankowych 16

17. Outline Problem of AML – the state of the art
Fundamental aspects of AML system design
System for Analysis and Registration of Transactions
Architecture of data warehouse
Case study – examples of a few selected problems
Conclusion and future research

18. Main issues Problem of scalability
Data structure Charts of Accounts of General Ledger
OLAP Data Warehouse based on General Ledger
Reporting
Transaction chains

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

20. Architecture of data warehouse Problem of scalability
Approximate size of OLAP cube of 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:
× × 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
5 liczba op po wn i ma, agregaty po wn i ma, liczba operacji po winien i ma 20

21. Heterogeneous data warehouse dimensions of General Ledger
Przykład pozycji konta analitycznego (kolumna KNT_CODE = „A”), na kontach analitycznych „A” mogą być dekretowane operacje księgowe, konta które nie mają wpisu w kolumnie KNT_CODE są kontami syntetycznymi, agregującymi dane z kont niesyntetycznych w nich zawartych.
Do tej pozycji będziemy się odwoływać w dalszej części prezentacji poprzez jej identyfikator kolumna KNT_ID = 460.

22. Homogenous dimensions of TIME
Widok raportu OLAP z perspektywą wymiaru czasu

23. Data Warehouse of General Ledger
Modeling and implementation of the Data Warehouse of General Ledger
Fact Table
Dimensions
Charakterystyka i podstawowe własności kostek ROLAP 23

24. Data Warehouse of General Ledger
Star Schema
Schemat gwiazdy, w wymiarze czasu mamy cztery kolumny dotyczące identyfikacji czasu: year, quarter, month, day.
Ziarnistość wymiaru (identyfikacja rekordów) jest na najniższym poziomie czyli day (identyfikator rekordu to kolumna „id”). Nie możemy w tym przypadku w sposób jednoznaczny identyfikować podwymiarów: year, quarter, month. 24 24

25. Data Warehouse of General Ledger
Normalized Time Dimension in a Snowflake Schema
Schemat płatka śniegu ze znormalizowanym wymiarem czasu.
Ziarnistość wymiaru (identyfikacja rekordów) jest na każdym poziomie czyli year, quarter, month, day (identyfikator rekordu to kolumna „id” w każdej z tabel). Możemy w tym przypadku w sposób jednoznaczny identyfikować wszystkie wymiary: year, quarter, month, day.
Problemy:
bardzo kosztowne od strony obliczeniowej operacje złączeń tabel (JOIN);
denormalizacja pokazana na przykładzie nie rozwiązuje problemu wymiarów niejednorodnych takich jak Plan Kont. 25 25

26. Data Warehouse of General Ledger
Hierarchical schema (always a la star schema)
Schemat z hierarchią wymiaru czasu – w tym przypadku schemat hurtowni danych zawsze odpowiada schematowi gwiazdy (nie wymaga kosztownych obliczeniowo join-ów pomiędzy tabelami tak jak to jest w przypadku schamtu „płatka śniegu”).
Ziarnistość wymiaru (identyfikacja rekordów) jest na każdym poziomie czyli year, quarter, month, day (identyfikator rekordu to kolumna „id”). Możemy w tym przypadku w sposób jednoznaczny identyfikować wszystkie wymiary: year, quarter, month, day.
Nie trzeba tu wykorzystywać kosztownych operacji JOIN tak jak w przypadku schematu płatka śniegu.
Możemy tej metody użyć również do wymiarów niejednorodnych. 26 26

27. Data Warehouse – Fact Table
Tabela faktów księgi głównej w której zawarte są dekrety Księgi Głównej banku (import z Dziennika Dokumentów).

28. Facts Table – operation
Tabela faktów księgi głównej w której zawarte są dekrety Księgi Głównej banku (import z Dziennika Dokumentów).
Zaznaczono operację – zestaw dekretów objętych tym samym wyróżnikiem dokumentów (kolumna TDD_IDWD), scalona operacja na dekretach będzie transakcją.
Zaznaczony przykład odpowiada temu w artykule. 28 28

29. Facts Table – operation
Tabela faktów księgi głównej w której zawarte są dekrety Księgi Głównej banku (import z Dziennika Dokumentów).
Zaznaczono operację – zestaw dekretów objętych tym samym wyróżnikiem dokumentów.
Na rysunku zaznaczono wyróżnik dokumentów:
Zaznaczony przykład odpowiada temu w artykule. 29 29

30. Facts Table – operation
Tabela faktów księgi głównej w której zawarte są dekrety Księgi Głównej banku (import z Dziennika Dokumentów).
Zaznaczono operację – zestaw dekretów objętych tym samym wyróżnikiem dokumentów.
Na rysunku zaznaczono identyfikatory kont dekretów z Planu Kont (przedstawione wcześniej).
Zaznaczony przykład odpowiada temu w artykule. 30 30

31. Facts Table – operation
Tabela faktów księgi głównej w której zawarte są dekrety Księgi Głównej banku (import z Dziennika Dokumentów).
Zaznaczono operację – zestaw dekretów objętych tym samym wyróżnikiem dokumentów.
Na rysunku zaznaczono kwoty operacji poszczególnych dekretów – należy zwrócić uwagę na sposób księgowania:
w kolumnie TDD_WN kwota operacji „WINIEN”;
w kolumnie TDD_MA kwota operacji „MA”.
Jest to standard księgowy (księgowy model danych). 31 31

32. Facts Table and Charts of Account
Tabela faktów księgi głównej w której zawarte są dekrety Księgi Głównej banku (import z Dziennika Dokumentów) oraz fragment wymiaru Planu Kont – pokazano jak za pomocą identyfikatora wskazuje się w dekrecie tabeli faktów wymiar Planu Kont (KNT_ID = 460). 32 32

33. Integration of accounting model and transaction mode
Scalenie dwóch dekretów z księgi głównej do jednej transakcji bankowej.
Górna ramka – dekrety Księgi Głównej:
TDD_ID – id dekretu.
TDD_WN – kwota w pozycji winien dekretu.
TDD_MA – kwota w pozycji ma dekretu
Dolna ramka – transakcje:
TTD_IDDS – id dekretu źródłowego transakcji
TTD_IDDD – id dekretu docelowego transakcji
TTD_AM – kwota transakcji

34. Summary of data structure
Technological characteristics:
non uniform hierarchy
number of nodes:
within number of synthetic accounts:
max depth: 10
Application characteristics:
decrees dictionary of General Ledger
dictionary of transaction accounts
dimensions of data warehouse
Liczba kont syntetycznych oznacza na ilu kontach w OLAP trzeba będzie agregować dane z poddrzew.
Tu należy zwrócić uwagę na następujące aspekty:
Niejednorodności hierarchii – generalnie hierarchie bardzo trudno przechowywać i wydajnie nimi zarządzać w SQL.
Mapowanie 1-1 struktury Planu Kont z Księgi Głównej – dzięki temu mogliśmy wykorzystać tą strukturę jako:
słownik w SART oraz słownik definicji transakcji (warstwa aplikacyjna SART);
wymiary w hurtowni i OLAP (warstwa analityczna SART).
Bardzo ważno – żadnego z powyższych punktów nie da się efektywnie zrealizować w żadnym obecnie istniejącym rozwiązaniu DBMS, HD i OLAP (MS SQL, ORACLE, DB2).

35. Outline Problem of AML – the state of the art
Fundamental aspects of AML system design
System for Analysis and Registration of Transactions
Architecture of data warehouse
Case study – examples of a few selected problems
Conclusion and future research

36. Case Study – some statistics
sample database
number of processed records (daily):
min: ~1,000 rec. (weekend)
max: ~300,000 rec. (end of month)
monthly (January 2008)
total: 2,497,280 rec./month
daily average : 80,557 rec.
DW dimensions: 197,046 rec.

37. Characteristics of DW (General Ledger)
13,299,773 rows in Facts Table
20,581,733 Cartesian products in OLAP Cube
970,987,198 number of OLAP operations executed during recomputing of OLAP cube
/ = 47,177 average number of OLAP operations over registered decree
13,299,773 rows in Facts Table – liczba dekretów w tabeli faktów.
20,581,733 Cartesian products in OLAP Cube – liczba produktów kartezjańskich w kostce OLAP, ziarnistość na każdym poziomie agregacji np. dla daty wyliczone agregaty dla każdego poziomu: 2008, 2008-Q1, 2008-Q1-02, 2008-Q
970,987,198 number of OLAP operations executed during recomputing of OLAP cube – liczba operacji przeliczeń OLAP (produkty kartezjańskie) jaka została wykonana do przeliczenia całej kostki.
/ = 47,177 average number of OLAP operations over registered decree – ta liczba 47,177 mówi, że aby przeliczyć jeden fakt z tabeli faktów trzeba dodać/uaktualnić 47,177 wierszy będących produktami kartezjańskimi kostki OLAP. 37

38. OLAP Data Warehouse of General Ledger
Implementation of the OLAP DW of General Ledger
Fact Table
Dimensions
OLAP Cube
Cube Pivot as changes viewing in OLAP cube
Charakterystyka i podstawowe własności kostek ROLAP 38

39. OLAP Data Warehouse – General Ledger
Tabela faktów Księgi Głównej.

40. OLAP Data Warehouse – General Ledger
Tabela faktów Księgi Głównej – zaznaczono dekrety na koncie „Depozyty 1 dniowe w PLN” identyfikator konta TDD_IDKT =
Chcielibyśmy zobaczyć zagregowaną wartość operacji na tym koncie (kolejny slajd). 40 40

41. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension
Do slajdu 20. Raport OLAP (dla wszystkich klientów i całego czasu) - zaznaczono pozycję na koncie „Current Account in PLZ” TDD_IDKT = 460.
Znaczenie poszczególnych kolumn:
KNT_NAME: Nazwa konta
KNT_ID: Id konta
DDO_WN: zagregowana (suma) pozycja „WINIEN” (miara kostki OLAP)
DDO_MA: zagregowana (suma) pozycja „MA” (miara kostki OLAP)
DDO_OCWN: liczba zagregowanych dekretów pozycji „WINIEN” (miara kostki OLAP)
DDO_OCMA: liczba zagregowanych dekretów pozycji „MA” (miara kostki OLAP)
DDO_OC: liczba zagregowanych dekretów pozycji „„WINIEN” i „MA” (miara kostki OLAP) 41 41

42. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension
Raport OLAP (dla wszystkich klientów i całego czasu) - zaznaczono pozycję na koncie „Deposits (1 day) in PLN” TDD_IDKT =
Znaczenie poszczególnych kolumn:
KNT_NAME: Nazwa konta
KNT_ID: Id konta
DDO_WN: zagregowana (suma) pozycja „WINIEN” (miara kostki OLAP)
DDO_MA: zagregowana (suma) pozycja „MA” (miara kostki OLAP)
DDO_OCWN: liczba zagregowanych dekretów pozycji „WINIEN” (miara kostki OLAP)
DDO_OCMA: liczba zagregowanych dekretów pozycji „MA” (miara kostki OLAP)
DDO_OC: liczba zagregowanych dekretów pozycji „„WINIEN” i „MA” (miara kostki OLAP) 42 42

43. Data Warehouse – Cube Pivot
Dimension
General Ledger
Dimen.
Time
Account N
OLAP operation
Cash in ZLP
Dimension
Client
Account 1
Dimension
Client
Account 1
Account N
Operacja Cube Pivot – zmiana widoku w kostce OLAP – z widoku wymiaru Planu Kont na widok wymiaru czasu.
Operacja ta umożliwia również uszczegółowianie podwymiarów (operacja SLICE - wycinania) – w obrocie jako parametr podamy interesujące nas konto i zobaczymy zagregowane wartości względem tego konta w wymiarze czasu.
Cash in ZLP
Dimension Time
Dimension General Ledger

44. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension
Operacja „Cube Pivot” na poprzednim slajdzie mieliśmy raport OLAP z widokiem Planu Kont i zaznaczonym kontem: „Depozyty 1 dniowe w PLN” ID=11581.
Zmienimy widok kostki z wymiaru Planu Kont na wymiar czasu i dodatkowo wykonamy operację OLAP Slice (wycinania) dotyczącą tylko powyższego konta.
W wyniku otrzymamy raport OLAP z widokiem na wymiar czasu zodcięciem tylko danych dotyczących konta: „Depozyty 1 dniowe w PLN” ID=11581.
Parametryzacja operacji Cube Pivot – wybieramy konto „Depozyty 1 dniowe w PLN” ID=11581. 44 44

45. OLAP Data Warehouse – OLAP Raport with view on the Charts of Account dimension
Wynik zapytania.
Znaczenie poszczególnych kolumn:
DT_DATE: DATA w formacie ROK-KWARTAŁ-MIESIĄC-DZIEŃ
DT_ID: Id daty w wymiarze czasu (identyfikowane są wszystkie elementy).
DDO_WN: zagregowana (suma) pozycja „WINIEN” (miara kostki OLAP)
DDO_MA: zagregowana (suma) pozycja „MA” (miara kostki OLAP)
DDO_OCWN: liczba zagregowanych dekretów pozycji „WINIEN” (miara kostki OLAP)
DDO_OCMA: liczba zagregowanych dekretów pozycji „MA” (miara kostki OLAP)
DDO_OC: liczba zagregowanych dekretów pozycji „„WINIEN” i „MA” (miara kostki OLAP) 45 45

46. OLAP Data Warehouse – General Ledger
Wynik zapytania – na rysunku pokazano odpowiednie pozycje miar w obu widokach (fragment z Planu Kont dotyczące wcześniej wybranego konta).
Znaczenie poszczególnych kolumn:
DT_DATE: DATA w formacie ROK-KWARTAŁ-MIESIĄC-DZIEŃ
DT_ID: Id daty w wymiarze czasu (identyfikowane są wszystkie elementy).
DDO_WN: zagregowana (suma) pozycja „WINIEN” (miara kostki OLAP)
DDO_MA: zagregowana (suma) pozycja „MA” (miara kostki OLAP)
DDO_OCWN: liczba zagregowanych dekretów pozycji „WINIEN” (miara kostki OLAP)
DDO_OCMA: liczba zagregowanych dekretów pozycji „MA” (miara kostki OLAP)
DDO_OC: liczba zagregowanych dekretów pozycji „„WINIEN” i „MA” (miara kostki OLAP) 46 46

47. 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 created Cartesian products OLAP: 991,675
average number of OLAP operations/sec: 21,103.1 op./sec. 47

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

49. 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

50. SART – Transaction merging
Transaction merging process in SART
Building a transaction model based on the General Ledger decrees
Integration of the transaction model with the General Ledger accounting model
Integration of the transaction model with a OLAP reporting 50

51. SART – Transaction merging
Formularz scalania transakcji – proces polegający na budowaniu transakcji z dekretów Księgi Głównej zawartych w hurtowni danych. 51

52. SART – Transaction merging
Formularz scalania transakcji – proces polegający na budowaniu transakcji z dekretów Księgi Głównej zawartych w hurtowni danych.
Proces scalania polega na zdefiniowaniu:
konta źródłowego (IDD_IDKT = 11581),
Konta docelowego (IDD_IDKT = 460),
objętych tym samym wyróżnikiem (zaznaczono na rysunku w kolumnie TDD_IDWD = 88258) 52

53. SART – Transaction merging
Formularz scalania transakcji – proces polegający na budowaniu transakcji z dekretów Księgi Głównej zawartych w hurtowni danych.
Proces scalania polega na zdefiniowaniu:
konta źródłowego (IDD_IDKT = 11581),
Konta docelowego (IDD_IDKT = 460),
objętych tym samym wyróżnikiem (zaznaczono na rysunku w kolumnie TDD_IDWD = 88258).
Dodatkowo pokazano fragment wymiaru Planu Kont z kontem „Rachunek bieżący w PLN” KNT_ID = 460, które odpowiada identyfikatorowi tabeli faktów i definicji transakcji. 53

54. SART - Cash Flow Chains Analysis
Cash Flow Chains Analysis (CFCA)
Cash Flow Chains
OLAP Data Warehouse of Cash Flow Chains
Cash Flow Chains Analysis – example of use

55. SART - Cash Flow Chains Analysis
Kółka: konta, strzałki: transakcje (z numerem kolejnej transakcji)
Interpretacja (kolejność transakcji jest istotna – numery przy strzałkach):
Na czerwono zaznaczono konta zasilające czerwone konta końcowe.
Na zielono zaznaczono konta zasilające zielone konta końcowe.
Na żółto zaznaczono konta zasilające konta czerwone i zielone. 55

56. Cash Flow Chains Analysis
Graf przedstawia tylko:
17*6 = 102 konta
19*6 = 114 transakcji
Gdzie są konta źródłowe, docelowe i pośrednie, jaka jest kolejność transakcji itd. 56

57. Transaction chains – trees view
Widok łańcuchów transakcji w formie drzewiastej z poprzedniego slajdu. 57

58. Transaction chains – trees view
Interpretacja widoku drzewiastego i diagramu. 58

59. Transaction chains (cash flow)
Kółka konta, strzałki transakcje.
Przykład łańcucha transakcji. 59

60. SART - Cash Flow Chains Analysis
Four major CFCA rates
Source Accounts/Transaction chains ratio
Destination Accounts/Transaction chains ratio
Inner Accounts/Transaction chains ratio
Number of account cycle chains 60

61. CASE STUDY SART - Cash Flow Chains Analysis
Sample database of OLAP Data Warehouse CFCA
Number of transactions : 46,459
Number of accounts in CFCA: 38,844
Number of chains: 5,021,459
Number of chains links: 29,567,581

62. CASE STUDY
Analysis of Transaction Chains
In the case study it will be analyzed transaction chain from the source account (id=22921) to the target account (id=14037). 62

63. CASE STUDY Report characteristics: # of generated chains 674;
Transaction Chain Analysis
Report characteristics:
# of generated chains 674;
# of transactions participating in chains 88;
# of source accounts of sub-chains 5;
# of target accounts of sub-chains 5;
Important risk of ML using „shell companies”. 63

64. Cash Flow Chains Analysis Wybrane konto źródłowe
Parametryzacja zapytania wybieramy identyfikatory konta źródłowego (id=22921) i docelowego (id=14037).
Szukamy łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037. 64

65. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 65

66. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
W ramce zaznaczono jeden z poszukiwanych łańcuchów.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 66

67. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
W ramce zaznaczono jeden z poszukiwanych łańcuchów, strzałka pokazuje przepływ pieniądza pomiędzy kontami.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 67

68. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
W ramce zaznaczono jeden z poszukiwanych łańcuchów, strzałka pokazuje ogniwo łańcucha – konto docelowe poprzedzającej transakcji w łańcuchu jest kontem źródłowym kolejnej transakcji w łańcuchu.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 68

69. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
W ramce zaznaczono jeden z poszukiwanych łańcuchów, strzałka pokazuje przepływ pieniądza pomiędzy kontami.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 69

70. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
W ramce zaznaczono jeden z poszukiwanych łańcuchów.
Ostatecznie cały łańcuch dotyczy przepływu pieniądza pomiędzy kontami a za pośrednictwem 6 transakcji i 10 kont dla zaznaczonego łańcucha.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 70

71. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
Zaznaczono trzy bloki, łącznie sześć łańcuchów odpowiadających kryteriom zapytania – w drzewie są one scalone w jedno poddrzewo aby wskazać rozwidlanie się łańcuchów – w tym przypadku z transakcji nadrzędnej.
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 71

72. Cash Flow Chains Analysis Wybrane konto źródłowe i docelowe (wynik zapytania)
Wynik zapytania dla łańcuchów w które zaczynają się od konta id=22921 i kończą się na koncie id=14037.
Zaznaczono trzy bloki, łącznie sześć łańcuchów odpowiadających kryteriom zapytania – w drzewie są one scalone w jedno poddrzewo aby wskazać rozwidlanie się łańcuchów – w tym przypadku z transakcji nadrzędnej.
Niebieską linią pokazano połączenie ogniwa łańcuchów – konto docelowe pierwszej transakcji w drzewie jest kontem źródłowym transakcji w poddrzewie (podkreślone na niebiesko).
TEX_ID – identyfikator łańcucha;
TEX_ID – identyfikator transakcji;
DT_SDATE – data transakcji;
TEX_IDNS – rachunek źródłowy;
TEX_IDND – rachunek docelowy;
TEX_AMNT – kwota transakcji;
TEX_IDWD – wyróżnik dokumentu (identyfikator po którym łączone były dekrety w procesie scalania transakcji);
TEX_RIMP – raport importu (blok importowanych danych). 72

73. Conclusions and future works
SART has been implemented
SART does not need any suppl. components
high system performance -> ~ real time
extensions: credit analysis, operational risk, …
Further research:
standardisation of the data warehouse model
development of BI and CI
mapping Object/Relation model in SART
study of data mining algorithms