Thách thức dữ liệu của ngành ngân hàng

Ngân hàng là một trong những ngành dữ liệu-trọng và bị quản lý chặt chẽ nhất. Mỗi giao dịch, mỗi khoản vay, mỗi hồ sơ khách hàng đều sinh ra dữ liệu — và dữ liệu đó đồng thời là tài sản kinh doanh, là cơ sở ra quyết định rủi ro, và là đối tượng giám sát của cơ quan quản lý. Nhưng phần lớn ngân hàng không được sinh ra với một nền dữ liệu sạch. Họ thừa kế core banking đã chạy hàng chục năm, bồi đắp thêm hàng loạt hệ thống vệ tinh qua từng đợt số hóa, và kết quả là một bức tranh dữ liệu phân mảnh mà không một báo cáo nào phản ánh được trọn vẹn. Trang này phân tích các thách thức dữ liệu đặc thù của ngân hàng — gốc rễ của những hệ quả mà lãnh đạo đã quá quen: báo cáo lệch số, đối soát thủ công triền miên, KYC chậm, và rủi ro bị xử phạt khi thanh tra.

Vì sao dữ liệu ngân hàng khó hơn các ngành khác

Nhiều ngành cũng có nhiều dữ liệu, nhưng ngân hàng chịu đồng thời ba sức ép mà ít ngành nào gánh cùng lúc:

Quy mô & độ phức tạp nghiệp vụ: một ngân hàng đa năng vận hành đồng thời tiền gửi, tín dụng, thẻ, ngoại hối, đầu tư, bảo hiểm liên kết — mỗi mảng có vòng đời dữ liệu, định nghĩa và chu kỳ riêng.
Giám sát quản lý chặt: dữ liệu không chỉ phục vụ nội bộ mà phải chứng minh được với cơ quan quản lý là đúng, đủ, kịp thời và truy được nguồn gốc.
Niềm tin là sản phẩm: sai sót dữ liệu trong ngân hàng không chỉ tốn tiền — nó bào mòn niềm tin, thứ tài sản cốt lõi mà ngành này bán.

Khác với một doanh nghiệp bán lẻ thông thường, ở ngân hàng một con số sai trong báo cáo rủi ro hoặc một hồ sơ KYC lỏng lẻo có thể trở thành vấn đề pháp lý, chứ không đơn thuần là phiền toái vận hành.

Thách thức 1 — Core banking legacy và rừng hệ thống vệ tinh

Trái tim của hầu hết ngân hàng là một hệ core banking ổn định nhưng cũ, được thiết kế cho thời mà sản phẩm số chưa tồn tại. Quanh nó mọc lên các hệ vệ tinh theo từng nhu cầu phát sinh:

Hệ thẻ (phát hành, thanh toán, đối soát với tổ chức thẻ quốc tế).
Hệ tín dụng / Loan Origination (khởi tạo, thẩm định, giải ngân khoản vay).
Kênh internet banking và mobile banking (mỗi kênh thường giữ một bản ghi khách hàng riêng).
Hệ CRM và các công cụ marketing.
Kho dữ liệu / Data Warehouse và các báo cáo phục vụ quản lý, tuân thủ.

Hệ quả: silo dữ liệu

Mỗi hệ thống là một hòn đảo, lưu khách hàng theo định dạng riêng, mã hóa riêng, quy ước riêng. Không có một “ngôn ngữ chung”, nên cùng một thực thể khách hàng tồn tại ở nhiều nơi với nhiều phiên bản. Khi lãnh đạo hỏi một câu tưởng chừng đơn giản — “Tổng dư nợ và tổng tiền gửi của khách hàng X là bao nhiêu?” — câu trả lời phải lắp ghép thủ công từ nhiều nguồn, và thường không khớp.

Hệ quả: khách hàng phân mảnh và trùng lặp

Một cá nhân mở tài khoản tại quầy, sau đó đăng ký mobile banking, rồi vay tiêu dùng — rất dễ trở thành ba bản ghi khác nhau ở ba hệ thống. Sai khác chính tả tên, định dạng số giấy tờ, địa chỉ viết tắt khác nhau khiến hệ thống không nhận ra đó là cùng một người. Hậu quả trực tiếp:

Không thể dựng góc nhìn 360 độ về khách hàng → bán chéo kém, định giá rủi ro thiếu cơ sở.
KYC và thẩm định bị chậm và trùng lặp vì mỗi mảng tự thu thập lại thông tin.
Báo cáo tổng hợp theo khách hàng / nhóm khách hàng liên quan sai lệch — đặc biệt nguy hiểm khi tính giới hạn cấp tín dụng cho người có liên quan.

Lời giải nền tảng cho nhóm vấn đề này là MDM — gộp nhiều bản ghi rời rạc thành một golden record (định danh khách hàng duy nhất xuyên hệ thống). Xem Bản ghi vàng (golden record) và Đối sánh & hợp nhất bản ghi (matching).

Thách thức 2 — Áp lực tuân thủ đa tầng

Không ngành nào ở Việt Nam chịu khung quy định nhiều tầng như ngân hàng. Dữ liệu phải đồng thời thỏa mãn:

Cơ quan quản lý trong nước (NHNN): chế độ báo cáo định kỳ, an toàn vốn, giới hạn cấp tín dụng, an toàn công nghệ thông tin.
Chuẩn mực quốc tế: các nguyên tắc kiểu Basel về vốn và quản trị rủi ro; nguyên tắc tổng hợp & báo cáo dữ liệu rủi ro (BCBS 239); chuẩn kế toán quốc tế ảnh hưởng tới trích lập dự phòng (IFRS 9).
Phòng chống rửa tiền & tài trợ khủng bố (AML/CFT): chuẩn FATF cùng các quy định trong nước về phòng, chống rửa tiền.
Bảo vệ dữ liệu cá nhân: Nghị định 13/2023/NĐ-CP đặt ra nghĩa vụ về sự đồng ý, mục đích xử lý, và quyền của chủ thể dữ liệu.

Mỗi tầng đòi hỏi dữ liệu phải đúng, đủ, có chủ sở hữu rõ ràng và truy được nguồn gốc. Khi cùng một dữ liệu phải phục vụ nhiều khung quy định mà nền tảng bên dưới lại phân mảnh, đội tuân thủ buộc phải đối soát thủ công cho từng báo cáo — tốn người, dễ sai, và khó chứng minh khi thanh tra hỏi “số này từ đâu ra”.

Phân tích chi tiết từng khung quy định và yêu cầu cụ thể với dữ liệu nằm ở trang Khung pháp lý & tuân thủ dữ liệu trong ngân hàng.

Thách thức 3 — Dữ liệu rủi ro tổng hợp từ nhiều nguồn

Quản trị rủi ro tín dụng, thị trường và vận hành đòi hỏi gom dữ liệu từ nhiều hệ thống chủ rồi tổng hợp thành các chỉ số rủi ro toàn hàng. Đây chính là tinh thần của BCBS 239: dữ liệu rủi ro phải chính xác, toàn vẹn, đầy đủ và kịp thời, đồng thời có quản trị và truy xuất nguồn gốc (lineage) rõ ràng.

Khi nền dữ liệu phân mảnh, ngân hàng vấp phải:

Định nghĩa không thống nhất: “dư nợ”, “khách hàng có liên quan”, “tài sản đảm bảo” được hiểu khác nhau giữa các phòng → tổng hợp ra số khác nhau.
Không truy được nguồn: khi thanh tra hỏi một con số rủi ro tới từ đâu, không ai chứng minh được đường đi của nó từ hệ thống gốc tới báo cáo.
Chậm khi cần gấp: trong tình huống căng thẳng thị trường, lãnh đạo cần số rủi ro ngay, nhưng quy trình tổng hợp thủ công không kịp.

Với IFRS 9, mô hình tổn thất tín dụng kỳ vọng (ECL) cần dữ liệu lịch sử sạch và đầy đủ về dư nợ, nhóm nợ, tài sản đảm bảo. Dữ liệu bẩn ở đây đi thẳng vào con số trích lập dự phòng và ảnh hưởng tới vốn — một sai sót dữ liệu trở thành sai sót tài chính thực sự.

Cách Ataccama hỗ trợ BCBS 239 (lineage truy nguồn số rủi ro, đo chất lượng dữ liệu, governance định nghĩa thống nhất) được trình bày ở Truy xuất nguồn gốc cho tuân thủ & kiểm toán.

Thách thức 4 — Dữ liệu cá nhân rải rác khắp nơi

Ngân hàng nắm giữ khối lượng lớn dữ liệu cá nhân nhạy cảm: thông tin định danh, tài chính, hành vi giao dịch. Theo Nghị định 13/2023/NĐ-CP, ngân hàng phải biết dữ liệu cá nhân đang nằm ở đâu, được xử lý cho mục đích gì, ai được truy cập, và phải đáp ứng được quyền của chủ thể dữ liệu (truy cập, chỉnh sửa, xóa).

Vấn đề: dữ liệu cá nhân rải rác qua hàng chục hệ thống và vô số bản sao báo cáo. Nếu không có cơ chế phân loại tự động để định vị dữ liệu cá nhân, ngân hàng không thể trả lời nổi câu hỏi cơ bản “khách hàng này có những dữ liệu gì trong hệ thống của chúng ta” — chứ chưa nói tới việc xử lý một yêu cầu xóa dữ liệu một cách trọn vẹn.

Năng lực phát hiện và phân loại PII tự động giúp giải bài toán này — xem Phân loại PII trong Data Catalog. Chi tiết tuân thủ Nghị định 13 sẽ ở trang Bảo vệ dữ liệu cá nhân.

Hậu quả khi dữ liệu kém — bằng ngôn ngữ của lãnh đạo

Các thách thức trên không phải vấn đề kỹ thuật trừu tượng. Chúng quy đổi thẳng thành rủi ro kinh doanh:

Báo cáo sai: số liệu gửi NHNN, hội đồng quản trị hay kiểm toán lệch nhau, mất uy tín và mất thời gian giải trình.
Rủi ro bị xử phạt: không đáp ứng yêu cầu tuân thủ về dữ liệu rủi ro, AML hoặc bảo vệ dữ liệu cá nhân → chế tài hành chính và tổn thất danh tiếng.
Quyết định rủi ro sai: dữ liệu tín dụng và tài sản đảm bảo bẩn dẫn tới định giá rủi ro sai, trích lập sai, cấp tín dụng sai đối tượng.
Trải nghiệm khách hàng kém: khách phải khai lại thông tin nhiều lần, được “nhận diện” như người lạ dù đã gắn bó nhiều năm.
KYC chậm: mở tài khoản và onboarding kéo dài vì thông tin phân mảnh, làm mất khách vào tay đối thủ số hóa nhanh hơn.

Một ví dụ generic minh họa: tại một ngân hàng bán lẻ, một khách hàng tồn tại dưới ba bản ghi không liên kết. Bộ phận tín dụng đánh giá khoản vay mà không nhìn thấy dư nợ thẻ và một khoản vay tiêu dùng đứng tên cùng người ở hệ thống khác — dẫn tới tổng mức rủi ro thực bị đánh giá thấp. Gốc rễ không nằm ở năng lực thẩm định, mà ở chất lượng và tính nhất quán của dữ liệu.

Gốc rễ chung: chất lượng và quản trị dữ liệu

Điểm chung của cả bốn thách thức là chúng đều bắt nguồn từ dữ liệu — và vì thế đều có thể được xử lý một cách hệ thống bằng nền tảng chất lượng dữ liệu cộng với data governance, thay vì vá víu từng báo cáo. Trước khi đi vào từng khung quy định và từng bài toán, nên hiểu nền móng: chất lượng dữ liệu là gì và đo bằng các chiều nào. Xem Chất lượng dữ liệu là gì và Các chiều chất lượng dữ liệu.

Đây chính là chỗ một nền tảng như Ataccama phát huy vai trò: đo và cải thiện chất lượng dữ liệu, hợp nhất khách hàng (MDM), lập danh mục và phân loại dữ liệu (Catalog + PII), truy xuất nguồn gốc (Lineage), và đặt vai trò CDO/CRO/CCO vào một khung quản trị nhất quán.

Khung pháp lý & tuân thủ dữ liệu trong ngân hàng — phân tích từng quy định và yêu cầu với dữ liệu.
Khách hàng 360 & KYC — dựng golden record và tăng tốc KYC.
Chất lượng dữ liệu là gì — nền móng cho mọi bài toán phía trên.