Khách hàng 360 và KYC/CDD trong ngân hàng

Hãy thử đặt một câu hỏi tưởng như đơn giản với bất kỳ ngân hàng nào: “Khách hàng Nguyễn Văn A đang có quan hệ gì với chúng ta?”. Trong nhiều ngân hàng, câu trả lời không nằm ở một chỗ. Tài khoản thanh toán nằm ở core banking, thẻ tín dụng ở hệ thống thẻ, khoản vay ở hệ thống tín dụng, lịch sử tương tác ở CRM — và ở mỗi nơi, cùng một con người lại là một bản ghi khác nhau, tên viết khác nhau, số định danh nhập khác nhau, địa chỉ mỗi nơi một kiểu. Ngân hàng không thiếu dữ liệu về khách hàng; ngân hàng thiếu một cái nhìn duy nhất, đáng tin về khách hàng đó. Đây vừa là rào cản kinh doanh — không bán chéo được, không đánh giá rủi ro toàn diện được — vừa là rủi ro tuân thủ: KYC/CDD đòi hỏi định danh khách hàng chính xác, mà định danh thì lại tản mác. Bài viết này phân tích bài toán “khách hàng 360” và cách MDM (Master Data Management) trong Ataccama giải nó từ gốc.

Bài toán nghiệp vụ: vì sao ngân hàng không nhìn thấy khách hàng

Một ngân hàng thương mại trung bình ở Việt Nam vận hành trên core banking cùng hàng chục hệ thống vệ tinh ra đời ở các thời điểm khác nhau, do các đội khác nhau quản lý: hệ thống thẻ, hệ thống cho vay, internet/mobile banking, CRM bán hàng, kho dữ liệu báo cáo. Mỗi hệ thống tự sinh và lưu hồ sơ khách hàng theo cách riêng của nó. Hệ quả là một khách hàng có thể tồn tại dưới năm, bảy bản ghi rời rạc, không hệ thống nào biết về các bản ghi còn lại.

Vấn đề trầm trọng thêm vì dữ liệu khách hàng bẩn theo những kiểu rất đời thường:

Tên không chuẩn: “Nguyễn Văn A”, “NGUYEN VAN A”, “Nguyễn V. A”, “Nguyen Van A” — máy coi là bốn người khác nhau.
Số định danh lệch: số CCCD nhập thiếu số, nhập nhầm, hoặc một người vừa có CMND cũ vừa có CCCD mới mà hệ thống không nối lại.
Địa chỉ mỗi nơi một kiểu: “P. Bến Nghé, Q.1” và “Phường Bến Nghé, Quận 1, TP.HCM” là cùng một chỗ nhưng viết khác.
Thiếu hoặc lỗi thời: số điện thoại cũ, hồ sơ thiếu trường bắt buộc cho thẩm định.

Khi định danh khách hàng đã không nhất quán ngay từ trong nhà, mọi việc dựa trên nó đều lung lay. Bộ phận tuân thủ không chắc đã gom đủ quan hệ của một khách để thẩm định. Bộ phận kinh doanh không thấy được tổng thể để bán chéo. Bộ phận rủi ro tính sai mức độ tập trung tín dụng vì không biết ba khoản vay ở ba hệ thống thực ra là của cùng một người.

Vì sao dữ liệu là gốc rễ

Có một cám dỗ thường gặp: nghĩ rằng cứ mua một phần mềm CRM mới, hay một giải pháp eKYC mới, là sẽ có “khách hàng 360”. Nhưng phần mềm mới chỉ là thêm một hệ thống nữa chứa một bản ghi nữa về cùng khách hàng. Cái nhìn duy nhất về khách hàng không phải là một màn hình đẹp — nó là một vấn đề dữ liệu chủ (master data): phải có một nơi quyết định được rằng các bản ghi rải rác này đều trỏ về cùng một con người, và bản thông tin đáng tin nhất về người đó là gì.

Rủi ro nằm ở cả hai phía của bài toán đối sánh:

Bỏ sót (under-matching): không nhận ra hai bản ghi là cùng một người. Khách hàng bị xé thành nhiều mảnh, ngân hàng đánh giá rủi ro thiếu, có thể vô tình cho vay vượt khẩu vị vì không thấy hết dư nợ.
Gộp nhầm (over-matching): gộp hai người khác nhau thành một. Đây là lỗi nguy hiểm trong ngân hàng — thông tin tài chính của người này lẫn sang người kia, vi phạm bảo mật và làm sai thẩm định.

Vì thế, “khách hàng 360” phải được giải ở tầng dữ liệu, bằng một kỷ luật chuyên trị dữ liệu chủ, chứ không phải bằng một ứng dụng nghiệp vụ đơn lẻ.

Ataccama giải thế nào: MDM tạo định danh khách hàng duy nhất

Đây chính là phạm vi của MDM trong Ataccama. MDM gom các bản ghi khách hàng từ mọi hệ thống nguồn, làm sạch, đối sánh (matching) để nhận ra các bản ghi thuộc cùng một thực thể, rồi gộp (merging) chúng thành một bản ghi vàng (golden record) — phiên bản đáng tin duy nhất đại diện cho khách hàng đó. Bản ghi vàng này trở thành định danh khách hàng duy nhất, xuyên suốt mọi hệ thống.

Thu thập và chuẩn hóa (cleansing). Dữ liệu khách hàng từ core, thẻ, tín dụng, CRM được đưa về MDM. Trước khi so khớp, hệ thống chuẩn hóa từng trường: viết hoa/thường thống nhất, tách họ – tên đệm – tên, chuẩn hóa số CCCD về đúng định dạng, đưa địa chỉ về cấu trúc thống nhất. Bước này quyết định chất lượng của mọi bước sau — dữ liệu càng sạch, đối sánh càng chính xác.
Đối sánh (matching). MDM dùng các quy tắc và thuật toán so khớp để phát hiện những bản ghi có thể là cùng một người dù viết khác nhau. So khớp không chỉ dựa trên một trường: nó cân nhắc tổ hợp tên, số định danh, ngày sinh, địa chỉ, số điện thoại, và xử lý được cả lỗi gõ, viết tắt, dấu tiếng Việt. Kết quả là các bản ghi được nhóm lại theo thực thể.
Gộp và chọn lọc giá trị tốt nhất (survivorship). Với mỗi nhóm, MDM gộp thành một golden record và áp luật survivorship để chọn giá trị đáng tin nhất cho từng trường — ví dụ ưu tiên số CCCD từ hồ sơ đã thẩm định, lấy địa chỉ mới nhất, giữ số điện thoại được xác nhận gần đây. Golden record không phải bản sao của một nguồn nào, mà là tổng hợp những gì tốt nhất từ tất cả nguồn.
Quản lý ngoại lệ (stewardship). Những cặp “ngờ ngợ” mà máy không đủ chắc để tự gộp sẽ được đẩy cho chuyên viên quản trị dữ liệu (data steward) xem và quyết định. Đây là van an toàn chống gộp nhầm — đặc biệt quan trọng trong ngân hàng.
Phân phối định danh duy nhất. Golden record (cùng một mã định danh khách hàng thống nhất) được trả ngược về các hệ thống tiêu dùng: CRM, hệ thống thẩm định KYC, công cụ chấm điểm rủi ro, báo cáo. Từ đây, mọi nơi nhìn về cùng một khách hàng.

Trên nền golden record, ba nhóm nghiệp vụ được phục vụ trực tiếp:

KYC/CDD/eKYC chính xác hơn. Khi định danh khách hàng đã được hợp nhất và làm sạch, quy trình thẩm định dựa trên một hồ sơ đầy đủ và nhất quán thay vì các mảnh rời. eKYC khi mở tài khoản có thể đối chiếu với golden record để phát hiện khách đã tồn tại, tránh tạo trùng ngay từ đầu. Việc khử trùng khách (deduplication) giảm rủi ro một người giả mạo tạo nhiều hồ sơ, hoặc một hồ sơ giả lọt qua vì hệ thống không nối được với dữ liệu đã có.
Bán chéo trên cái nhìn toàn diện. Single customer view cho thấy đầy đủ sản phẩm khách đang dùng và hành vi của họ, để đề xuất đúng sản phẩm tiếp theo thay vì chào mời thứ họ đã có.
Đánh giá rủi ro toàn diện. Khi mọi quan hệ của một khách được quy về một định danh, rủi ro được tính trên tổng thể — đúng dư nợ thực, đúng mức độ tập trung — chứ không bị xé lẻ theo từng hệ thống.

Giá trị mang lại

Khi ngân hàng có được định danh khách hàng duy nhất, giá trị trải đều trên ba trục:

Tuân thủ vững hơn. KYC/CDD dựa trên hồ sơ khách hợp nhất, đầy đủ, truy được — đáp ứng yêu cầu định danh và thẩm định khách hàng một cách có thể chứng minh, thay vì chắp vá. Khử trùng và phát hiện khách giả mạo trở thành năng lực sẵn có chứ không phải nỗ lực thủ công.
Kinh doanh hiệu quả hơn. Cái nhìn 360 mở đường cho bán chéo đúng nhu cầu, chăm sóc khách hàng nhất quán giữa các kênh, và trải nghiệm số liền mạch — khách không phải khai lại thông tin đã có ở nơi khác.
Rủi ro được kiểm soát đúng. Đo lường rủi ro tín dụng và mức độ tập trung dựa trên thực thể khách hàng thật, giảm nguy cơ cho vay vượt khẩu vị vì “nhìn không ra” tổng dư nợ.

Để hiểu sâu hai cơ chế cốt lõi tạo nên golden record, xem Bản ghi vàng (golden record) và Đối sánh bản ghi (matching). Golden record khách hàng cũng là nền tảng cho giám sát giao dịch chính xác hơn trong Phòng chống rửa tiền (AML) và gian lận.

Ví dụ minh họa

Một ngân hàng bán lẻ chuẩn bị triển khai chiến dịch bán chéo và đồng thời siết lại quy trình KYC theo yêu cầu thẩm định khách hàng. Khi rà soát dữ liệu, họ phát hiện một thực tế quen thuộc: một khách hàng thân thiết mở tài khoản từ thời còn dùng CMND, sau đó mở thẻ tín dụng bằng CCCD mới, rồi vay mua nhà qua một chi nhánh khác nhập tên có dấu khác cách. Ba hệ thống coi đó là ba khách hàng.

Sau khi đưa dữ liệu vào MDM, đối sánh nhận ra ba bản ghi cùng trỏ về một người nhờ tổ hợp ngày sinh, số điện thoại và mối liên hệ CMND–CCCD; golden record gộp lại, ưu tiên số CCCD đã thẩm định và địa chỉ mới nhất. Từ đó: quy trình KYC thấy được hồ sơ đầy đủ của khách để thẩm định đúng; đội kinh doanh thấy khách đã có thẻ và khoản vay nên đề xuất đúng sản phẩm còn thiếu; đội rủi ro cộng đúng tổng dư nợ thay vì tính lẻ. Cùng lúc, hệ thống chặn được một hồ sơ mở tài khoản mới mà thông tin trùng khớp đáng ngờ với một khách đã có — một tín hiệu để soát kỹ trước khi phê duyệt.

Lưu ý khi triển khai

Chất lượng dữ liệu đi trước đối sánh. Đối sánh tốt đến đâu cũng phụ thuộc dữ liệu đầu vào. Cần đầu tư bước chuẩn hóa tên/CCCD/địa chỉ ngay từ đầu; bỏ qua bước này thì golden record sẽ “rác vào, rác ra”.
Cẩn trọng với gộp nhầm hơn cả bỏ sót. Trong ngân hàng, gộp nhầm hai người làm lẫn thông tin tài chính là lỗi nghiêm trọng. Nên đặt ngưỡng so khớp thận trọng và để chuyên viên quản trị dữ liệu xét tay các trường hợp ngờ vực, thay vì để máy tự gộp hết.
Định danh khách hàng là dự án có chủ sở hữu, không phải dự án IT thuần. Cần xác định rõ ai sở hữu định nghĩa “khách hàng”, luật survivorship nào được ưu tiên, ai duyệt ngoại lệ — đây là việc của quản trị dữ liệu, có sự tham gia của nghiệp vụ và tuân thủ.
Tích hợp hai chiều với hệ thống nguồn. Golden record chỉ phát huy giá trị khi được trả về các hệ thống tiêu dùng và có cơ chế cập nhật khi dữ liệu nguồn thay đổi. Cần lên kế hoạch tích hợp ngay từ thiết kế.
Tôn trọng quy định bảo vệ dữ liệu cá nhân. Hợp nhất dữ liệu khách hàng đồng nghĩa với tập trung dữ liệu cá nhân — phải đi kèm phân quyền truy cập, mục đích sử dụng rõ ràng và khả năng theo dấu dữ liệu, đúng tinh thần các quy định bảo vệ dữ liệu cá nhân hiện hành.