Xây dựng mơ hình đưa rabáo cáo cácgiao dịch đáng ngờ

Một phần của tài liệu Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các NHTM việt nam khoá luận tốt nghiệp 325 (Trang 74 - 86)

3. Kết cấu của đề tài

3.2. Xây dựng mơ hình đưa rabáo cáo cácgiao dịch đáng ngờ

Để đưa ra được báo cáo các giao dịch đáng ngờ cần phải trải qua 4 bước thực hiện (Hình 3.2): Thu thập (Extract), Chuẩn hóa (Transform), Nạp dữ liệu (Loading) lên data warehouse, Khai thác dữ liệu từ data warehouse.

Hình 3.2 Xây dựng mơ hình đưa ra báo cáo các giao dịch đáng ngờ

Bước 1: Thu thập (Extract)

Gom dữ liệu từ nhiều nguồn khác nhau về. Cụ thể trong mơ hình này, nguồn ta lấy từ mơ hình dữ liệu Oracle Financial Services Data Model (FSDM) gồm các thông tin về khách hàng, tài khoản, giao dịch... Lấy các trường thông tin, các bảng nằm trong nhóm dữ liệu:

+ Account Data + Customer Data + Enterprise Data

Lê Thị Thu Phương - Lớp K17HTTTB 57

Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại Việt Nam

Khố luận tốt nghiệp

+ Transaction Data

Ngồi ra, các nguồn này có thể là database hệ thống nghiệp vụ (MS SQL, MySQL, Oracle...), cũng có thể là file ở các định dạng khác nhau (CSV, excel, XML...), có thể là dữ liệu nội bộ ngân hàng hoặc từ bên ngồi.

Bước 2: Chuẩn hóa (Transform)

Biến đổi dữ liệu từ định dạng nguồn sang định dạng data warehouse bao gồm các bước nhỏ:

Bước 2.1: Từ yêu cầu nghiệp vụ mong muốn lấy các trường thông tin sau và lưu trữ trên data ware để thuận lợi cho việc khi thác và xuất báo cáo. Xác định rõ các trường thông tin cần lưu trong data ware house. Trong bảng 3.9 đang mơ tả ví dụ về một yêu cầu: nghiệp vụ muốn hiển thị các trường thông tin trên báo cáo:

STT Trường thông tin Kiểu dữ liệu Mô tả

ĩ CUST_SEQ_ID NUMBER(22) ID của khách hàng

2 CUST_TYPE_CD CHAR(ĩ0) Loại khách hàng: cá nhân/tổ chức

3 BIRTH_DT DATE Ngày sinh của khách hàng

4 FULL_NM CHAR(ĩ50) Họ tên khách hàng

5 CUST_ADD_DT DATE Ngày khách hàng được thêm vào hệ

thống

6 CUST_STAT_CD CHAR(ĩ) Trạng thái hiện tại của khách hàng

A: Hoạt động P: Đang chờ xử lý I: Không hoạt động N: Không phải là khách hàng

STT Trường thông tin Kiểu dữ liệu Mô tả

ĩ CUST_ID_DOC_

SEQ_ID

NUMBER(22) Mã CUST ID DOC

2 DOC_TYPE_CD CHAR(50) Loại tài loại nhận được từ khách

hàng: chứng minh thư...

3 DOC_TYPE_CD CHAR(50) Số chứng minh thư/hộ chiếu

4 DOC_NM CHAR(200) Tên tài liệu nhận

5 DOC_REF_NUM CHAR(20) Số nhận dạng tài liệu

STT Trường thông tin Kiểu dữ liệu Mô tả

ĩ ACCT_SEQ_ID NUMBER(22) Mã ID tài khoản

2 ACCT_INTRL_ID CHAR(50) Số tài khoản khách hàng

3 ACCT_OPEN_DT DATE Ngày mở tài khoản

3 ACCT_STAT_CD CHAR(ĩ) Tình trạng thài khoản

4 ACCT_CLOSE_DT DATE Ngày đóng tài khoản

5 ACCT_TYPE_CD CHAR(20) Loại tài khoản

Bảng 3.9: Bảng thông tin các trường cần lấy lên báo cáo Bước 2.2: Đổ dữ liệu 1:1 từ nguồn lên Staging

Staging là vùng chứa dữ liệu chuẩn bị cho việc biến đổi dữ liệu thu được từ nguồn trước khi chuyển qua các vùng chứa dữ liệu khác trong kho dữ liệu. Xác định được các trường thơng tin muốn lấy ra được nó lấy nguồn từ những bảng thơng tin nào. Từ đó, đổ dữ liệu 1:1 lên tầng Staging. Hệ thống Oracle Financial Services

Lê Thị Thu Phương - Lớp K17HTTTB 58

Khoá luận Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực tốt nghiệp nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại

Việt Nam

Data Model (FSDM) có khoảng 30 bảng dữ liệu. Tuy nhiên để lấy dữ liệu cho data warehouse được thiết kế ở trên ta chỉ sử dụng các bảng và các trường sau:

+ Bảng lưu trên Staging về CUST: STG_CUST

Bảng 3.10: Bảng lưu trên Staging về CUST

+ Bảng lưu trên Staging về CUST_ID_DOC: STG_CUST_ID_DOC

Bảng 3.11: Bảng lưu trên Staging về CUST_ID_DOC + Bảng lưu trên Staging về ACCT: STG_ACCT

STT Trường thông tin Kiểu dữ liệu Mô tả

ĩ ACCT_PHON_SEQ_ID NUMBER(22) Mã ID ACCT PHON

2 PHON_NB CHAR(20) Sô điện thoại khách hàng

STT Trường thông tin Kiểu dữ liệu Mô tả

ĩ FO_TRXN_SEQ_ID NUMBER(22) Mã ID giao dịch

2 TRXN_LOC_ADDR_SEQ_I

D

CHAR(50) Vị trí giao dịch

3 ACCT_INTRL_ID CHAR(50) Mã ID của tài khoản giao dịch

4 BANK_CARD_ID_NB NUMBER(20) Mã ID của ngân hàng giao

dịch

5 CNDTR_ACTVY_RISK_NB NUMBER(3) Mức độ rủi ro liên quan đến

hoạt động của giao dịch 2: Đáng tin cậy cho một mức

độ loại trừ từ giám sát 1: Đáng tin cậy cho một mức

giám sát

0: Không đáng tin cậy hoặc mạo hiểm

ĩ-10: Tăng mức độ rủi ro

6 CNDTR_NM CHAR(350) Tên cá nhân/tổ chức giao dịch

7 TRXN_ACTVY_CRNCY_C

D

CHAR(3) Đơn vị tiền tệ được xác định

trong giao dịch

8 DBT_CDT_CD CHAR(20) Sô tiền được chuyển vào ghi

có (CDT) hoặc đi ra ghi nợ (DBT) từ tải khoản giao dịch

9 TRXN_EXCTN_DT DATE Ngày thực hiện giao dịch

ĩõ- TRXN_EXCTN_TM CHAR(9) Thời gian thực hiện giao dịch

ĩĩ TRXN_LOC_NM CHAR(350) Tên địa điểm giao dịch được

thực hiện

Bảng 3.12: Bảng lưu trên Staging về ACCT

Lê Thị Thu Phương - Lớp K17HTTTB 59

Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại Việt Nam

Khoá luận tốt nghiệp

+ Bảng lưu trên Staging về ACCT_PHON: STG_ACCT_PHON

Bảng 3.13: Bảng lưu trên Staging về ACCT_PHON

STT Mapping Source table Source column Iype

1 Họ và tên STG_CUST FULL_NM CHAR(150)

2 Ngày tháng năm

sinh

STG_CUST BIRTH_DT DATE

3 Nghề nghiệp STG_CUST OCPTN_NM CHAR(30)

4 Quốc tịch STG_CUST CNTRY_OF_BIRTH CHAR(3)

5 Số chứng minh

thư/Hộ chiếu

STG_CUST_ID_DOC DOC_TYPE_CD CHAR(50)

6 Số điện thoại STG_CUST_PHON PHON_NB CHAR(20)

7 Số tài khoản STG_ACCT ACCT_INTRL_ID CHAR(50)

8 Ngày mở tài

khoản

STG_ACCT ACCT_OPEN_DT DATE

9 Tình trạng tài

khoản

STG_ACCT ACCT_STAT_CD CHAR(1)

10 Loại khách hàng STG_CUST CUST_TYPE_CD CHAR(10)

11 Vị trí giao dịch STG_Cash_Transaction TRXN_LOC_ADDR_SE

Q_ID

CHAR(50)

12 Số tiền giao dịch STG_Cash_Transaction DBT_CDT_CD CHAR(20)

Bảng 3.14: Bảng lưu trên Staging về Cash Transaction

Bước 2.3: Sau khi xác định các trường thơng tin đó, ta đi Mapping nguồn lấy của các trường thông tin lấy từ bảng nào, trường nào trong mơ hình dữ liệu Oracle

Lê Thị Thu Phương - Lớp K17HTTTB 60

Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại Việt Nam

Khoá luận tốt nghiệp

Financial Services Data Model (FSDM). Giả sử như trường thông tin “Họ và tên” được lấy từ bảng STG_CUST tương ứng với trường FULL_NM.

S TT

Source table Source column Target table Target column type

ĩ STG_CUS T FULL_NM TBL_INF_CU ST FULL_NM CHAR (ĩ50) 2 STG_CUS T BIRTH_DT TBL_INF_CU ST BIRTH_DT DATE 3 STG_CUS T OCPTN_N M TBL_INF_CU ST OCPTN_NM CHAR(3 0) 4 STG_CUS T CNTRY_OF_ BIRTH TBL_INF_CU ST CNTRY_OF_ BIRTH CHAR(3 ) 5 STG_CUST_ ID_DOC DOC_TYPE_ CD TBL_INF_CU ST DOC_TYPE_ CD CHAR(5 0) 6 STG_CUST_ PHON PHON_NB TBL_INF_CU ST PHON_NB CHAR(2 0) 7 STG_ACC T ACCT_INTR L_ID TBL_INF_CU ST ACCT_INTRL _ID CHAR(5 0) 8 STG_ACC T ACCT_OPEN _DT TBL_INF_CU ST ACCT_OPEN _DT DATE 9 STG_ACC

T ACCT_STAT UTBL_INF_C ACCT_STAT_ CHAR(ĩ

Bảng 3.15: Thông tin mapping các trường, các bảng từ nguồn

Bước 3: Nạp dữ liệu (Loading) lên data warehouse

Ghi dữ liệu đã được chuẩn hóa từ data warehouse (lưu trữ dữ liệu chi tiết). Bước này bao gồm cả quá trình cập nhật thay đổi từ hệ thống nghiệp vụ vào data warehouse, đảm bảo số lượng báo cáo luôn được cập nhật. Data warehouse thường bao gồm một hoặc nhiều data mart, với data mart chính là data warehouse thu nhỏ tập trung vào một nghiệp vụ nhất định nào đó của doanh nghiệp, ngân hàng (ví dụ data mart về sale, bảo hiểm của khách hàng vay thế chấp, thẻ tín dụng...).

Để lưu trữ được bảng thông tin trên data warehouse ta cần xác định bảng thông tin TBL_TRANS_CUST sẽ lưu với cơ chế gì. Thơng thường bảng thông tin lưu trên data warehouse sẽ lưu theo 2 cơ chế là: cơ chế SCD (Slowly Changing Dimension) và cơ chế incremental. Đối với các thông tin thay đổi liên tục sẽ lưu theo cơ chế incremental, như là đối với một CUST ID khách sẽ có nhiều bản ghi lưu

Lê Thị Thu Phương - Lớp K17HTTTB 61

Khoá luận Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực tốt nghiệp nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại

Việt Nam

thơng tin giao dịch của khách hàng đó. Cịn đối với các thơng tin ít thay đổi sẽ lưu theo SCD, cơ chế SCD có 3 loại:

- SCD loại 1 (ghi đè): đây là loại chiều không cần lưu lại lịch sử thay đổi. Chỉ việc ghi đè lên bản ghi cũ.

- SCD loại 2(dữ liệu lịch sử hết hiệu lực): đây là loại chiều cần lưu lạilịch sử. Thay vì ghi đè lên chiều cũ, người ta tạo ra một dịng mới với cùng khố tự nhiên nhưng khác khoá đại diện.

- SCD loại 3(dữ liệu lịch sử còn hiệu lực):đây là trường hợp các giá trịlịch sử vẫn còn hiệu lực sử dụng đồng thời với các giá trị mới. Thay vì tạo thêm một dịng mới trong bảng, người ta tạo thêm các cột mới để lưu vết.

Vì bảng thơng tin này có lưu các giao dịch của khách hàng nên ta sẽ lưu trữ các trường thông tin thành một bảng mới trên data warehouse theo cơ chế incremental:

_CD ST CD ) 10 STG_CUST CUST_TYPE_ CD TBL_INF_CU ST CUST_TYPE_ CD CHAR(1 0) 11 STG_Cash_T ransaction TRXN_LOC_ ADDR_SEQ_I D TBL_INF_CU ST TRXN_LOC_ ADDR_SEQ_I D CHAR(5 0) 12 STG_Cash_T ransaction DBT_CDT_C D TBL_INF_CU ST DBT_CDT_C D CHAR(2 0)

Lê Thị Thu Phương - Lớp K17HTTTB 62

Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại Việt Nam

Khố luận tốt nghiệp

Tên tham số Mơ tả Giá trị mẫu (Min, Max)

Bảng 3.16: Bảng TBL_INF_CUST lưu trữ trên data warehouse Bước 4: Khai thác dữ liệu từ data warehouse

Để khai thác dữ liệu trong data warehouse thường áp dụng một số cơng cụ chính sau:

- Báo cáo OLAP (OLAP tool): là báo cáo cho phép người dùng sử dụng các tính năng của OLAP để tạo báo cáo. Báo cáo OLAP được sử dụng khi người dùng muốn thông tin cắt lớp, chuyên sâu hoặc toàn cảnh trước khi ra quyết định.

- Báo cáo tĩnh (reporting tool): là các báo cáo có cấu trúc, format, sử dụng truy vấn được định nghĩa trước đó, đơi khi bao gồm cả biểu đồ. Báo cáo tĩnh được sử dụng khi người dùng muốn xem các thông tin đánh giá, điều hành.

- Bộ công cụ khai phá dữ liệu (data mining): cho phép người dùng phân tích dữ liệu để tìm ra các thơng tin cịn bị ẩn dấu, ví dụ như các xu hướng, các mẫu chung.

Cụ thể trong phần khai thác dữ liệu từ data warehouse em sẽ nghiên cứu công cụ reporting tool để đưa ra báo cáo. Để có thể đưa các các báo cáo theo nghiệp vụ mong muốn, ta cần truyền các tham số đầu vào. Ví dụ trong kịch bản chuyển tiền giữa người khởi tạo định kỳ và người thụ hưởng:

Bước 4.1: Truyền các tham số đầu vào, sẽ có các ngưỡng quy định đối với từng nhóm tài khoản, khách hàng. Trong bảng tham số phía dưới có hiển thị một vài ví dụ mẫu của các ngưỡng được quy định.

Lê Thị Thu Phương - Lớp K17HTTTB 63

Khoá luận Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực tốt nghiệp nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại

Actvty Risk Cutoff Lvl Mức độ rủi ro hoạt động được quy ước cho các ngưỡng có điều kiện để quyết định tập hợp các giá trị ngưỡng nào được áp dụng

trong cảnh báo. 5

(0,10)

Frequency Period Số ngày theo lịch được chỉ định cho khoảng

thời gian tần suất.

14 days (7,30) HR Max Augment

Trans Ct

Số lượng giao dịch tối đa được hiển thị trong giao diện người dùng.

500 (50,1000)

HR Min Trans Amt Tổng số tiền giao dịch cho 1 cảnh báo. 500

(100,100M)

HR Min Trans Ct Tổng số giao dịch cho 1 cảnh báo. 6

(1,500) HR Receive

Percentage

Ngưỡng phần trăm của tổng số tiền giao dịch giữa các cặp thực thể trên tổng số tiền tổng giao dịch đến của thực thể nhận.

50% (1,100)

HR Send Percentage Ngưỡng phần trăm của tổng số tiền giao

dịch giữa các cặp thực thể trên tổng số tiền giao dịch gửi đi của thực thể gửi.

50% (1,100) MR Max Augment

Trans Ct

Số lượng giao dịch tối đa được hiển thị trong giao diện người dùng.

500 (50,1000)

MR Min Trans Amt Tổng số tiền giao dịch cho 1 cảnh báo. 500

(100,100M)

MR Min Trans Ct Tổng số giao dịch cho 1 cảnh báo. 6

(1,500) MR Receive

Percentage

Ngưỡng phần trăm của tổng số tiền giao dịch giữa các cặp thực thể trên tổng số tiền tổng giao dịch đến của thực thể nhận.

50% (1,100)

MR Send Percentage

Ngưỡng phần trăm của tổng số tiền giao dịch giữa các cặp thực thể trên tổng số tiền giao dịch gửi đi của thực thể gửi.

50% (1,100)

RR Max Augment Trans Ct

Số lượng giao dịch tối đa được hiển thị trong giao diện người dùng.

500 (50,1000)

RR Min Trans Amt Tổng số tiền giao dịch cho 1 cảnh báo. 500

(100,100M)

RR Min Trans Ct Tổng số giao dịch cho 1 cảnh báo. 6

(1,500) RR Receive

Percentage

Ngưỡng phần trăm của tổng số tiền giao dịch giữa các cặp thực thể trên tổng số tiền tổng giao dịch đến của thực thể nhận.

50% (1,100)

RR Send Percentage Ngưỡng phần trăm của tổng số tiền giao

dịch giữa các cặp thực thể trên tổng số tiền giao dịch gửi đi của thực thể gửi.

50% (1,100)

Lê Thị Thu Phương - Lớp K17HTTTB 64

Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại Việt Nam

Khoá luận tốt nghiệp

Bảng 3.17: Bảng tham số đầu vào của kịch bản rủi ro về chuyển tiền giữa người khởi tạo định kỳ và người thụ hưởng

Bước 4.2: Từ các thông tin đã lưu trong bảng TBL_INF_CUST trên data warehouse so sánh với các tham số đầu vào:

+ Tổng số tiền giao dịch (DBT_CDT_CD) của một khách hàng lớn hơn ngưỡng 500 triệu.

+ Mức độ rúi ro hoạt động (CNDTR_ACTVY_RISK_NB) của một khách hàng lớn hơn ngưỡng 5.

+ Tổng số tiền giao dịch giữa 1 cặp người khởi tạo và người thụ hưởng: tổng số tiền giao dịch ghi có vào tài khoản giữa 1 cặp trên tổng số tiền ghi có vào tài khoản của một khách hàng lớn hơn ngưỡng 50%.

Ket quả: Khi mà tất cá các điều kiện này điều xảy ra thì giao dịch của khách hàng bị nghi là giao dịch đáng ngờ và sẽ hiển thi trong báo cáo các giao dịch đáng ngờ. Trong báo cáo hiển thị sẽ có báo cáo chi tiết và báo cáo tổng hợp. Báo báo chi

Khoá luận Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực tốt nghiệp nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại

Việt Nam

tiết sẽ hiển thị bản ghi chứa các giao dịch đáng ngờ như: tên khách hàng, loại khách hàng, số tài khoản, số tiền giao dịch, vị trí giao dịch. Cịn đối với báo cáo tổng hợp sẽ thống kê có bao nhiêu tài khoản nằm trong giao dịch đáng nghi ngờ, tổng số lượng tiền đáng nghi ngờ đó.

Khố luận Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực tốt nghiệp nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại

Việt Nam

KẾT LUẬN CHƯƠNG 3

Ở chương này, em nghiên cứu các tham số dữ liệu đầu vào, đầu ra của từng kịch bản phát hiện hành vi rửa tiền đã nêu ở chương 2. Để mọi người có cái nhìn tổng quan hơn em cũng xây dựng từng bước của mơ hình đưa ra báo cáo các giao dịch đáng ngờ dữ từ mơ hình dữ liệu Oracle Financial Services Data Model (FSDM) và từ đó áp dụng các cơng cụ phân tích để khai thác, sử dụng dữ liệu trên data warehouse đưa ra báo cáo hiển thị theo mong muốn ban đầu của từng nghiệp vụ.

Khoá luận Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực tốt nghiệp nghiệm trên hệ thống dữ liệu tại các ngân hàng thương mại

Việt Nam

KẾT LUẬN

Một phần của tài liệu Nghiên cứu kịch bản nhận diện các giao dịch rửa tiền và thực nghiệm trên hệ thống dữ liệu tại các NHTM việt nam khoá luận tốt nghiệp 325 (Trang 74 - 86)

Tải bản đầy đủ (DOCX)

(91 trang)
w