Báo cáo NHNN 1 — Tổng quan báo cáo & giám sát

Một ngân hàng không chỉ vận hành cho cổ đông và khách hàng của mình. Nó là một mắt xích trong hệ thống tài chính quốc gia, và sự đổ vỡ của một ngân hàng có thể lan sang cả nền kinh tế. Vì lẽ đó, ngân hàng chịu một nghĩa vụ mà rất ít ngành khác phải chịu ở mức độ tương đương: báo cáo thường xuyên, chi tiết và có kiểm soát cho cơ quan quản lý — ở Việt Nam là Ngân hàng Nhà nước (NHNN).

Với một team dữ liệu ngân hàng như của chúng ta, báo cáo NHNN không phải là "việc của phòng tài chính". Nó là một trong những nguồn tiêu thụ dữ liệu khó nhất, khắt khe nhất về chất lượng, và có hậu quả pháp lý trực tiếp nếu sai. Một con số lệch trên bảng cân đối gửi lên cơ quan giám sát không chỉ là bug — nó có thể dẫn tới giải trình, xử phạt hành chính, thậm chí ảnh hưởng xếp hạng giám sát của cả ngân hàng.

Đây là bài mở đầu của series Báo cáo & Giám sát tuân thủ NHNN. Bài này vẽ bức tranh tổng thể: vì sao phải báo cáo, cơ quan quản lý giám sát theo những triết lý nào, các nhóm báo cáo chính là gì, dữ liệu đi qua những chặng nào, và data team đứng ở đâu trong toàn bộ dây chuyền đó. Các bài sau sẽ đào sâu từng mảng.

Lưu ý về phạm vi: Bài này trình bày ở mức nguyên tắc và khái quát. Khung pháp lý cụ thể được quy định trong các Thông tư, văn bản của NHNN về từng lĩnh vực (an toàn hoạt động, chế độ báo cáo thống kê, phòng chống rửa tiền, thông tin tín dụng...) và các văn bản này thay đổi theo thời gian. Vì vậy bài không gán số hiệu Thông tư/Điều khoản cụ thể — khi triển khai thực tế, luôn tra cứu văn bản hiện hành và bản mapping chỉ tiêu chính thức do NHNN ban hành.

Vì sao ngân hàng phải báo cáo NHNN

Có ba lý do nền tảng, và chúng không loại trừ nhau.

1. Giám sát an toàn hệ thống (prudential / systemic). Cơ quan quản lý cần biết mỗi ngân hàng có đủ vốn, đủ thanh khoản, không cho vay tập trung quá mức vào một khách hàng hay một ngành hay không. Đây là lý do tồn tại của các tỷ lệ bảo đảm an toàn (capital adequacy ratio, tỷ lệ khả năng chi tr*, giới hạn cấp tín dụng...). Nếu một ngân hàng âm thầm xói mòn vốn, cơ quan giám sát phải nhìn thấy điều đó trước khi nó thành khủng hoảng.

2. Ổn định tài chính & điều hành chính sách tiền tệ. NHNN vừa là cơ quan giám sát, vừa là ngân hàng trung ương điều hành chính sách tiền tệ. Để quyết định lãi suất, room tín dụng, dự trữ bắt buộc, NHNN cần thống kê tiền tệ - tín dụng tổng hợp từ toàn hệ thống: tổng dư nợ theo ngành, huy động theo kỳ hạn, cơ cấu tiền gửi... Báo cáo của từng ngân hàng là nguyên liệu thô cho các quyết định vĩ mô này.

3. Minh bạch & bảo vệ người gửi tiền / phòng chống tội phạm. Báo cáo tài chính, báo cáo phòng chống rửa tiền, thông tin tín dụng phục vụ minh bạch thị trường, bảo vệ người gửi tiền và phòng chống rửa tiền, tài trợ khủng bố.

Tóm lại: ngân hàng dùng tiền của công chúng và được hưởng một số đặc quyền (huy động tiền gửi, tiếp cận thanh khoản từ ngân hàng trung ương). Đổi lại, nó phải chịu soi. Báo cáo là hình thức chịu soi đó.

Hai triết lý giám sát: tuân thủ vs. trên cơ sở rủi ro

Đây là phần dễ bị bỏ qua nhưng cực kỳ quan trọng để hiểu vì sao báo cáo lại được thiết kế như hiện tại.

Giám sát tuân thủ (compliance-based supervision) là cách tiếp cận truyền thống: cơ quan quản lý đặt ra các quy tắc, ngưỡng, tỷ lệ cụ thể; ngân hàng phải chứng minh mình tuân thủ đúng luật. Câu hỏi trung tâm là: "Anh có vi phạm quy định nào không?". Báo cáo ở đây mang tính kiểm tra hộp đánh dấu (tick-the-box): tỷ lệ an toàn vốn có ≥ ngưỡng không, có cho vay vượt giới hạn một khách hàng không, có nộp báo cáo đúng hạn không.

Giám sát trên cơ sở rủi ro (risk-based supervision — RBS) là hướng tiếp cận hiện đại mà các cơ quan giám sát trên thế giới, bao gồm NHNN, đang dịch chuyển tới. Thay vì kiểm tra máy móc từng quy tắc, cơ quan giám sát phân bổ nguồn lực theo mức độ rủi ro: ngân hàng nào rủi ro cao hơn (mô hình kinh doanh, chất lượng tài sản, quản trị yếu) thì bị giám sát dày hơn, sâu hơn. Câu hỏi trung tâm chuyển thành: "Hồ sơ rủi ro của anh thế nào, và anh có quản trị được nó không?".

Với data team, sự dịch chuyển này có hệ quả rất cụ thể: RBS đòi hỏi dữ liệu chi tiết hơn, tần suất cao hơn, và có khả năng phân tích sâu — không chỉ nộp một con số tổng, mà phải giải trình được con số đó cấu thành từ đâu, có thể khoan xuống (drill-down) từng khoản vay, từng khách hàng khi cơ quan giám sát yêu cầu. Nói cách khác, RBS đẩy nhu cầu về một kho dữ liệu báo cáo (regulatory data mart) chuẩn, chi tiết, truy vết được — chủ đề của bài Regulatory data mart.

Bản đồ 5 nhóm báo cáo chính

Có hàng trăm biểu mẫu báo cáo, nhưng chúng gom về năm nhóm lớn theo mục đích. Nắm được năm nhóm này là nắm được xương sống của toàn series.

Nhóm 1 — An toàn hoạt động (prudential ratios). Các tỷ lệ bảo đảm an toàn trong hoạt động ngân hàng: tỷ lệ an toàn vốn (CAR), tỷ lệ khả năng chi trả / thanh khoản, tỷ lệ dư nợ trên vốn huy động (LDR), tỷ lệ vốn ngắn hạn cho vay trung dài hạn, giới hạn cấp tín dụng cho một khách hàng và người có liên quan. Đây là nhóm gần nhất với triết lý an toàn hệ thống. Chi tiết ở bài Prudential ratios; nền tảng vốn theo Basel đã đề cập ở bài Rủi ro & Basel.

Nhóm 2 — Thống kê tiền tệ - tín dụng. Phục vụ điều hành chính sách tiền tệ và thống kê hệ thống: dư nợ tín dụng theo ngành kinh tế / theo kỳ hạn / theo loại tiền, số dư huy động, lãi suất bình quân, tình hình sử dụng room tín dụng... Đặc trưng của nhóm này là tần suất cao (nhiều báo cáo theo tuần/tháng) và tính thống kê tổng hợp. Xem bài Statistical reporting.

Nhóm 3 — Báo cáo tài chính / cân đối kế toán. Bảng cân đối kế toán, kết quả kinh doanh, và đặc biệt là phân loại nợ và trích lập dự phòng rủi ro theo quy định. Nhóm này gắn chặt với hệ thống sổ cái (GL) và kế toán ngân hàng — nền tảng đã trình bày ở bài Ngân hàng vận hành thế nào.

Nhóm 4 — Phòng chống rửa tiền (PCRT / AML). Báo cáo giao dịch có giá trị lớn, giao dịch đáng ngờ (STR), giao dịch chuyển tiền điện tử vượt ngưỡng... nộp cho cơ quan chuyên trách về phòng chống rửa tiền. Đây là nhóm có tính pháp lý hình sự cao nhất và ràng buộc thời hạn ngặt nghèo nhất. Quy trình lập STR đã được mô tả ở bài STR/SAR; phần dữ liệu chuyên sâu ở bài AML reporting.

Nhóm 5 — Thông tin tín dụng (CIC). Ngân hàng định kỳ báo cáo dư nợ, nhóm nợ, thông tin khoản vay của từng khách hàng cho Trung tâm Thông tin tín dụng Quốc gia Việt Nam (CIC) — cơ quan tổng hợp lịch sử tín dụng toàn hệ thống, phục vụ tra cứu ngược lại khi thẩm định. Đây là báo cáo "hai chiều": ngân hàng vừa nộp, vừa là người dùng. Chi tiết ở bài Credit reporting CIC.

Chu kỳ báo cáo và cơ chế nộp

Báo cáo NHNN không có một tần suất duy nhất — mỗi loại có chu kỳ riêng, tùy tính cấp thiết của thông tin.

Về cơ chế nộp, xu hướng đã chuyển gần như hoàn toàn sang nộp điện tử: ngân hàng kết tập dữ liệu theo đúng cấu trúc biểu mẫu do NHNN quy định (thường là các định dạng chuẩn hoá — file có cấu trúc, XML/text theo đặc tả, hoặc nhập/tải lên qua cổng báo cáo trực tuyến), ký số và gửi qua hệ thống báo cáo tập trung. Cơ chế điện tử này có hai hệ quả với data team:

1. Cấu trúc là bắt buộc, không phải gợi ý. Sai một mã chỉ tiêu, sai định dạng ngày, thiếu một trường bắt buộc → hệ thống nhận báo cáo từ chối (reject) ngay, không cần con người đọc. Điều này biến kiểm soát định dạng thành một tầng kiểm thử tự động — đúng "gu" của data engineering.
2. Nộp lại (resubmission) có dấu vết. Khi phát hiện sai sau khi đã nộp, ngân hàng phải nộp lại bản đính chính. Mọi lần nộp và đính chính đều để lại lịch sử, nên truy vết (lineage) và quản lý phiên bản số liệu là năng lực bắt buộc, không phải "nice to have".

Hệ sinh thái bên nhận báo cáo

Data team dễ mắc lỗi coi "NHNN" là một điểm nhận duy nhất. Thực tế là một hệ sinh thái nhiều đầu mối, mỗi đầu mối có định dạng, kênh và kỳ vọng riêng.

• NHNN (Ngân hàng Nhà nước) — cơ quan quản lý nhà nước tổng thể; nhận phần lớn báo cáo thống kê, an toàn, tài chính qua hệ thống báo cáo tập trung.
• Cơ quan Thanh tra, giám sát ngân hàng — bộ phận thực hiện chức năng thanh tra, giám sát; là "khách hàng" chính của giám sát trên cơ sở rủi ro, hay yêu cầu số liệu chi tiết và giải trình.
• CIC (Trung tâm Thông tin tín dụng Quốc gia Việt Nam) — nhận báo cáo thông tin tín dụng từng khách hàng, tổng hợp và cung cấp lại cho toàn hệ thống.
• Cục Phòng chống rửa tiền / cơ quan tình báo tài chính — đầu mối nhận báo cáo giao dịch giá trị lớn, giao dịch đáng ngờ.

Điểm mấu chốt: các đường đứt nét đi ngược lại trong sơ đồ — phản hồi, chất vấn, yêu cầu giải trình — mới là phần tốn công nhất và là nơi data team dễ đuối nhất nếu không chuẩn bị năng lực truy vết.

Vai trò của data team trong toàn trình

Đây là phần cốt lõi của cả series. Báo cáo NHNN đi qua sáu chặng, và data team hiện diện ở cả sáu.

1. Gom dữ liệu (ingestion). Kéo dữ liệu từ nhiều hệ nguồn: core banking (T24), hệ thống tín dụng, thẻ, treasury, AML, nhân sự. Thách thức thực tế: mỗi hệ có lịch khoá sổ, múi thời gian, và định nghĩa "cuối ngày" khác nhau. Nếu lấy dữ liệu core lúc 22h nhưng hệ thẻ chốt lúc 24h, con số sẽ lệch.

2. Chuẩn hoá (standardization). Đưa dữ liệu rời rạc về một mô hình chung: thống nhất mã tiền tệ, mã ngành kinh tế, phân loại kỳ hạn, quy đổi tỷ giá về ngày báo cáo. Đây là nơi một regulatory data mart phát huy giá trị.

3. Tính chỉ tiêu (calculation). Ánh xạ từ dữ liệu chuẩn hoá sang chỉ tiêu báo cáo theo đúng mapping do NHNN quy định. Ví dụ minh hoạ ý tưởng gom dư nợ theo nhóm nợ (không phải SQL nộp thật, chỉ minh hoạ logic tổng hợp):

-- Minh hoạ (KHÔNG phải câu nộp thật): gom dư nợ theo nhóm nợ để tính chỉ tiêu chất lượng tín dụng
SELECT
    loan_group,                    -- nhóm 1..5 theo phân loại nợ
    currency,
    SUM(outstanding_balance) AS total_outstanding,
    SUM(provision_amount)    AS total_provision
FROM regulatory_loan_book         -- bảng của data mart nội bộ, không thuộc sandbox
WHERE reporting_date = DATE '2026-06-30'
GROUP BY loan_group, currency;

4. Kiểm soát chất lượng (data quality & reconciliation). Trước khi nộp, phải khớp số: tổng báo cáo có bằng sổ cái không? Chỉ tiêu tháng này có "nhảy" bất thường so với tháng trước không? Có giá trị âm ở nơi không được phép âm không? Đây là chủ đề của bài Data quality & recon, và liên hệ trực tiếp với đối soát kế toán ở nghiệp vụ ngân hàng.

5. Nộp (submission). Đóng gói đúng định dạng, ký số, gửi qua cổng, và ghi nhận biên nhận. Chặng này ngày càng được tự động hoá (xem bài Automation & governance), nhưng tự động không có nghĩa là không kiểm soát — ngược lại, càng tự động càng cần chốt kiểm soát chặt.

6. Giải trình (explanation / drill-down). Khi cơ quan giám sát hỏi "vì sao dư nợ ngành bất động sản tăng 12% trong tháng?", data team phải khoan ngược từ con số tổng xuống từng khoản vay để trả lời. Không truy vết được = không giải trình được = rủi ro tuân thủ.

Nguyên tắc bao trùm cả sáu chặng: mọi con số phải truy được về nguồn, và mọi lần nộp phải tái lập được. Đây là lý do quản trị dữ liệu (data governance) không tách rời báo cáo — như đã bàn ở bài Governance tổng quan.

Use case thực tế

Bối cảnh. Ngân hàng chuẩn bị nộp báo cáo tỷ lệ an toàn vốn (CAR) tháng. Quy trình đã chạy tự động qua data mart. Lịch nộp: ngày làm việc thứ 10 của tháng sau.

Diễn biến (số liệu minh hoạ).

• Ngày làm việc thứ 8, pipeline chạy xong, ra CAR = 10,8% — trên ngưỡng tối thiểu, nhìn qua thì "ổn".
• Bước kiểm soát chất lượng bật cảnh báo: CAR tháng trước là 11,6%, sụt 0,8 điểm phần trăm trong một tháng là bất thường (ngưỡng cảnh báo nội bộ đặt ở 0,3 điểm).
• Data team khoan xuống: tài sản có rủi ro (RWA) tăng đột biến ở một danh mục. Truy tiếp: một khoản vay doanh nghiệp lớn bị phân loại sai hệ số rủi ro do thiếu cập nhật thông tin tài sản bảo đảm từ hệ nguồn — hệ tín dụng chốt sổ sau hệ core, nên bản snapshot lấy lúc 22h chưa có dữ liệu tài sản bảo đảm mới nhất.
• Điều chỉnh nguồn, chạy lại: CAR = 11,4%, khớp với xu hướng.

Kết quả & bài học.

1. Nếu không có chốt kiểm soát so sánh kỳ trước, ngân hàng đã nộp một con số sai, tự khai xấu đi năng lực vốn của mình — dẫn tới giải trình không đáng có với cơ quan giám sát.
2. Nguyên nhân gốc là lệch thời điểm chốt số giữa các hệ nguồn — một vấn đề data engineering thuần tuý, không phải lỗi nghiệp vụ.
3. Ba năng lực đã cứu tình huống: (a) kiểm soát chất lượng dạng so sánh xu hướng, (b) khả năng drill-down xuống từng khoản, (c) truy vết tới hệ nguồn và thời điểm chốt số. Cả ba đều là chủ đề của các bài tiếp theo trong series.

Ghi nhớ

• Ngân hàng phải báo cáo NHNN vì ba lý do nền tảng: giám sát an toàn hệ thống, ổn định tài chính & điều hành chính sách tiền tệ, và minh bạch / phòng chống tội phạm.
• Có hai triết lý giám sát: tuân thủ (kiểm tra vi phạm quy tắc, tick-the-box) và trên cơ sở rủi ro (RBS — phân bổ nguồn lực theo mức rủi ro). Xu hướng chuyển sang RBS đòi hỏi dữ liệu chi tiết hơn, kịp thời hơn, drill-down được.
• Năm nhóm báo cáo chính: (1) an toàn hoạt động, (2) thống kê tiền tệ - tín dụng, (3) báo cáo tài chính / cân đối, (4) phòng chống rửa tiền, (5) thông tin tín dụng (CIC).
• Chu kỳ báo cáo đa dạng: ngày / tuần / tháng / quý / năm / đột xuất. Nộp gần như hoàn toàn điện tử — sai cấu trúc là bị từ chối tự động; nộp lại có dấu vết nên cần quản lý phiên bản và truy vết.
• Bên nhận là một hệ sinh thái: NHNN, Cơ quan Thanh tra giám sát, CIC, Cục PCRT — mỗi bên có định dạng và kỳ vọng riêng; luồng phản hồi/giải trình ngược lại là phần tốn công nhất.
• Data team hiện diện ở cả sáu chặng: gom → chuẩn hoá → tính chỉ tiêu → kiểm soát chất lượng → nộp → giải trình. Nguyên tắc bao trùm: mọi con số truy được về nguồn, mọi lần nộp tái lập được.
• Bài này chỉ nêu nguyên tắc; số hiệu Thông tư/Điều khoản cụ thể phải tra cứu văn bản NHNN hiện hành khi triển khai.