Báo cáo NHNN 3 — Báo cáo thống kê định kỳ

Trong năm nhóm báo cáo đã vẽ ở bài tổng quan, nhóm thống kê tiền tệ - tín dụng là nhóm mà data team chạm vào thường xuyên nhất. Không phải vì nó nguy hiểm pháp lý nhất — nhóm phòng chống rửa tiền mới nhất — mà vì nó nhiều biểu, tần suất dày, và gắn thẳng vào sổ cái. Một ngân hàng có thể phải nộp hàng chục đến hàng trăm biểu thống kê mỗi kỳ, và một số biểu chạy theo ngày. Với một pipeline dữ liệu, đây là loại tải "đều tay nhưng không được sai" — đặc trưng dễ mài mòn đội vận hành nếu không tự động hoá tốt.

Bài này đi sâu vào chế độ báo cáo thống kê định kỳ: nó phục vụ mục đích gì, hệ thống chỉ tiêu được tổ chức ra sao, những nhóm biểu mẫu điển hình là gì, dữ liệu chảy từ hệ nguồn đến biểu mẫu như thế nào, và ba thách thức dữ liệu lớn nhất — mapping, chuẩn hoá danh mục, và bút toán điều chỉnh.

Lưu ý về phạm vi. Bài trình bày ở mức nguyên tắc. Chế độ báo cáo thống kê, danh mục mã biểu, hệ thống chỉ tiêu và kỳ báo cáo được quy định trong các văn bản của NHNN và thay đổi theo thời gian. Vì vậy bài không gán số hiệu Thông tư, không bịa mã biểu cụ thể. Khi triển khai, luôn dùng bản đặc tả chỉ tiêu và mã biểu chính thức hiện hành do NHNN ban hành. Mọi mã biểu, con số trong bài đều là minh hoạ.

Báo cáo thống kê để làm gì

NHNN đội hai vai: vừa là cơ quan giám sát ngân hàng, vừa là ngân hàng trung ương điều hành chính sách tiền tệ. Báo cáo thống kê phục vụ trực tiếp vai thứ hai, và gián tiếp vai thứ nhất.

1. Nguyên liệu cho điều hành chính sách tiền tệ. Để quyết định lãi suất điều hành, tỷ lệ dự trữ bắt buộc, hạn mức tăng trưởng tín dụng (room), NHNN cần bức tranh tổng hợp toàn hệ thống theo thời gian thực nhất có thể: tổng huy động và tín dụng đang tăng/giảm ra sao, cơ cấu theo kỳ hạn và loại tiền thế nào, lãi suất bình quân thị trường đang ở đâu. Báo cáo của từng tổ chức tín dụng là các "tế bào" để NHNN cộng lại thành thống kê tiền tệ (monetary statistics) cấp quốc gia.

2. Giám sát diễn biến và phát hiện sớm bất thường. Chuỗi thống kê định kỳ cho phép cơ quan giám sát nhìn xu hướng: một ngân hàng huy động tăng vọt bất thường, dư nợ dồn vào một ngành nhạy cảm, hay chênh lệch kỳ hạn (mismatch) nới rộng — tất cả lộ ra qua dữ liệu chuỗi thời gian trước khi thành vấn đề.

3. Đóng góp cho thống kê quốc gia và cam kết quốc tế. Số liệu tiền tệ - tín dụng còn phục vụ thống kê kinh tế vĩ mô của quốc gia và các chuẩn báo cáo quốc tế (ví dụ khuôn khổ thống kê tiền tệ - tài chính chuẩn). Điều này giải thích vì sao định nghĩa chỉ tiêu rất chặt: một khoản phải được phân loại nhất quán để cộng dồn được xuyên ngân hàng và so sánh được quốc tế.

Hệ quả với data team: khác với báo cáo an toàn (thường là vài tỷ lệ tổng), thống kê là khối lượng lớn các con số phân rã theo nhiều chiều (loại tiền × kỳ hạn × đối tượng × ngành...). Sai một chiều phân loại không làm sai một con số, mà làm sai cả một ô trong ma trận — và các ô phải cộng khớp về tổng.

Hệ thống chỉ tiêu báo cáo thống kê

Chế độ báo cáo thống kê được tổ chức thành một hệ thống chỉ tiêu có cấu trúc, không phải các file rời rạc. Ba khái niệm cần phân biệt rõ:

• Mã biểu (mã báo cáo). Định danh của một biểu mẫu cụ thể — ví dụ minh hoạ "biểu cân đối tài khoản kế toán tháng". Mỗi mã biểu có một cấu trúc cột/dòng và một kỳ báo cáo cố định.
• Chỉ tiêu (mã chỉ tiêu). Từng ô số liệu trong biểu, có định nghĩa chuẩn: nội dung kinh tế của con số, phạm vi bao gồm/loại trừ, đơn vị, quy tắc dấu. Ví dụ minh hoạ: "số dư tiền gửi có kỳ hạn của khách hàng cá nhân bằng VND".
• Chiều phân tổ (dimension). Các trục cắt lát một chỉ tiêu: loại tiền, kỳ hạn, đối tượng khách hàng, ngành kinh tế, khu vực... Cùng một khái niệm "tiền gửi" có thể phải nộp cắt theo nhiều chiều ở nhiều biểu khác nhau.

Đặc tả chỉ tiêu chính thức thường đi kèm quy tắc kiểm tra chéo (validation / cross-check): tổng các dòng phải bằng dòng tổng, tổng theo loại tiền phải bằng tổng chung, số liệu tài sản phải bằng số liệu nguồn vốn (nguyên tắc cân đối kế toán). Đây chính là bộ "test" mà pipeline nên nội bộ hoá — nếu tự kiểm trước, ta không bao giờ để cổng nộp của NHNN là nơi phát hiện lỗi.

Một biểu mẫu điển hình có thể hình dung như một ma trận:

Các ô = và Σ là ràng buộc cộng dồn — nơi data quality phải kiểm.

Các nhóm biểu mẫu điển hình

Dưới đây là các nhóm biểu thống kê thường gặp. Tên gọi mang tính khái quát, không phải tên biểu chính thức.

1. Cân đối tài khoản kế toán / bảng cân đối

Đây là biểu nền tảng nhất, thường là số dư của toàn bộ tài khoản kế toán theo hệ thống tài khoản của ngân hàng, tổng hợp theo kỳ. Vì mọi nghiệp vụ cuối cùng đều hạch toán vào sổ cái (GL), biểu cân đối tài khoản là "nguồn sự thật" mà các biểu thống kê khác phải khớp về. Nếu tổng dư nợ trên biểu thống kê tín dụng không bằng tổng các tài khoản cho vay trên cân đối kế toán, chắc chắn có sai sót ở một trong hai.

2. Thống kê tiền tệ — huy động và tín dụng

Nhóm cốt lõi phục vụ chính sách tiền tệ, phân rã theo nhiều chiều:

• Theo loại tiền: VND và ngoại tệ (thường quy đổi về VND theo tỷ giá ngày báo cáo).
• Theo kỳ hạn: không kỳ hạn, ngắn hạn, trung hạn, dài hạn (ranh giới kỳ hạn theo định nghĩa quy định).
• Theo đối tượng: tổ chức kinh tế, cá nhân, tổ chức tín dụng khác, khu vực công...
• Theo ngành kinh tế: dư nợ tín dụng cắt theo ngành (nông nghiệp, công nghiệp, thương mại, bất động sản, tiêu dùng...).

3. Thống kê lãi suất huy động và cho vay

Lãi suất bình quân theo loại tiền và kỳ hạn, đôi khi kèm lãi suất phát sinh mới trong kỳ so với lãi suất số dư. Đặc trưng dữ liệu: lãi suất là bình quân gia quyền theo số dư, không phải bình quân số học — sai chỗ này là một lỗi kinh điển.

4. Hoạt động thanh toán

Số lượng và giá trị giao dịch qua các kênh (chuyển khoản, thẻ, ví, kênh điện tử...), số lượng tài khoản, thẻ đang hoạt động. Nhóm này thiên về đếm và cộng khối lượng lớn giao dịch thay vì lấy số dư cuối kỳ, nên kỹ thuật tổng hợp khác hẳn (aggregate trên bảng giao dịch dày).

5. Ngoại hối

Trạng thái ngoại tệ, doanh số mua bán ngoại tệ, số dư tài sản/nguồn vốn bằng ngoại tệ. Một số chỉ tiêu ngoại hối chạy theo ngày, tạo áp lực vận hành cao nhất trong nhóm thống kê.

Tần suất báo cáo

Cơ chế nộp điện tử

Báo cáo thống kê ngày nay nộp điện tử. Ở mức nguyên tắc (không nêu tên hệ thống cụ thể để tránh sai lệch theo thời gian), cơ chế thường gồm các đặc trưng sau:

• Ngân hàng kết tập số liệu đúng cấu trúc mã biểu và mã chỉ tiêu do NHNN quy định, thành file/gói theo định dạng chuẩn hoá (file có cấu trúc theo đặc tả), hoặc nhập/tải lên qua cổng báo cáo trực tuyến.
• Dữ liệu được ký số và gửi qua hệ thống báo cáo tập trung.
• Cổng nhận thực hiện kiểm tra cấu trúc và kiểm tra chéo tự động: sai mã chỉ tiêu, sai định dạng, các dòng không cộng khớp → từ chối (reject) ngay và trả về mã lỗi.
• Nộp lại (resubmission) đính chính đều để lại dấu vết lịch sử.

Hai hệ quả trực tiếp cho data engineering — giống như đã nêu ở bài tổng quan: cấu trúc là bắt buộc chứ không phải gợi ý, và nộp lại có dấu vết nên phải quản lý phiên bản số liệu. Điều này biến các quy tắc kiểm tra chéo của NHNN thành một bộ test contract mà pipeline nên chạy nội bộ trước khi nộp.

Luồng dữ liệu: nguồn → mapping → biểu mẫu → nộp

Đây là kiến trúc xử lý cốt lõi của một biểu thống kê. Điểm cần nhấn: mapping và chuẩn hoá là trái tim, còn tính toán và đóng gói chỉ là cơ khí.

Hai đường đứt nét là nơi tốn công thật: vòng lặp sửa khi số không khớp, và vòng lặp xử lý khi cổng nộp từ chối.

Thách thức dữ liệu

1. Mapping từ hệ nguồn sang biểu mẫu quy định

Đây là bài toán khó nhất và bền nhất. Sổ cái ngân hàng tổ chức theo hệ thống tài khoản kế toán; biểu thống kê tổ chức theo hệ thống chỉ tiêu của NHNN. Hai hệ này không trùng nhau một-một: một chỉ tiêu thống kê có thể gom từ nhiều tài khoản GL; một tài khoản GL có thể tách vào nhiều chỉ tiêu tuỳ điều kiện (loại khách hàng, kỳ hạn còn lại...).

Thực hành tốt là quản lý mapping như dữ liệu có phiên bản, không phải code cứng: một bảng ánh xạ (tài khoản/điều kiện → mã chỉ tiêu) do nghiệp vụ sở hữu, có hiệu lực theo ngày, review được, và khi NHNN đổi đặc tả thì chỉ đổi bảng mapping chứ không sửa pipeline. Ý tưởng cấu trúc bảng mapping (minh hoạ):

-- Minh hoạ (KHÔNG phải câu nộp thật): bảng ánh xạ tài khoản GL sang mã chỉ tiêu thống kê
SELECT
    gl_account,          -- tài khoản sổ cái
    indicator_code,      -- mã chỉ tiêu trên biểu
    currency_class,      -- VND / ngoại tệ
    term_bucket,         -- không kỳ hạn / ngắn / trung / dài
    sign_rule,           -- quy tắc dấu (+/-)
    valid_from, valid_to -- hiệu lực theo ngày
FROM regulatory_indicator_map   -- bảng của data mart nội bộ, không thuộc sandbox
WHERE valid_from <= DATE '2026-06-30'
  AND (valid_to IS NULL OR valid_to >= DATE '2026-06-30');

Nguyên tắc vàng: mọi con số trên biểu phải truy được ngược về (các) tài khoản/bản ghi nguồn qua đúng phiên bản mapping đã dùng. Không truy vết được = không giải trình được khi cơ quan giám sát hỏi.

2. Chuẩn hoá danh mục

Các chiều phân tổ chỉ cộng khớp khi danh mục được chuẩn hoá về đúng bộ mã quy định. Ba danh mục hay gây đau:

• Loại tiền. Ngoại tệ phải quy đổi về VND theo tỷ giá ngày báo cáo với quy tắc tỷ giá thống nhất. Dùng nhầm tỷ giá (mua/bán/bình quân, hay tỷ giá ngày khác) làm lệch toàn bộ ô ngoại tệ.
• Kỳ hạn. Phân biệt kỳ hạn gốc (theo hợp đồng) và kỳ hạn còn lại (đến đáo hạn) — nhiều chỉ tiêu yêu cầu cụ thể một trong hai. Nhét sai loại kỳ hạn là lỗi tinh vi, khó phát hiện vì tổng vẫn khớp.
• Ngành kinh tế. Mã ngành trong hệ nguồn (do cán bộ tín dụng gán khi cấp khoản vay) phải ánh xạ về bộ mã ngành dùng cho báo cáo. Dữ liệu thiếu/nhập tay ở đây rất phổ biến → cần quy tắc mặc định và cảnh báo phần "chưa phân loại".

Bản chất data engineering ở đây là quản trị reference data / master data có phiên bản — cùng gốc với chủ đề chất lượng dữ liệu. Nếu danh mục nguồn "trôi" (drift) mà mapping không cập nhật, số sẽ sai âm thầm.

3. Xử lý bút toán điều chỉnh

Số liệu tại thời điểm khoá sổ chưa chắc là số cuối cùng. Kế toán có thể có bút toán điều chỉnh (adjustment / post-closing entries) sau ngày báo cáo: sửa phân loại, hạch toán bổ sung, đảo bút toán sai. Điều này tạo ra ba vấn đề dữ liệu:

1. Chốt thời điểm (as-of / cut-off). Số nộp phải phản ánh trạng thái tại ngày báo cáo, sau khi đã áp các điều chỉnh thuộc về kỳ đó — không phải trạng thái lúc pipeline tình cờ chạy. Cần khái niệm snapshot "as-of date" tách khỏi "run date".
2. Số đầu kỳ vs. cuối kỳ. Sau điều chỉnh, số cuối kỳ tháng trước (đã nộp) có thể lệch với số đầu kỳ tháng này. Cần quy tắc rõ: đính chính kỳ cũ hay phản ánh vào kỳ mới.
3. Nộp lại. Khi điều chỉnh đến sau khi đã nộp, phải sinh bản đính chính và giữ cả bản gốc lẫn bản sửa — quản lý phiên bản số liệu là bắt buộc.

Cách xử lý bền vững: pipeline chạy trên dữ liệu có timestamp và as-of date, tái lập được (reproducible) — chạy lại cho một ngày báo cáo trong quá khứ phải ra đúng con số đã nộp cho ngày đó, trừ khi có điều chỉnh chính thức. Đây là lý do thiết kế bất biến (append-only, versioned) được ưa chuộng trong regulatory data mart.

Kiểm tra chéo trước khi nộp

Trước khi đóng gói, pipeline nên tự chạy đúng bộ ràng buộc mà cổng NHNN sẽ kiểm — để bắt lỗi ở nhà, không phải ở cổng nộp:

• Cộng dồn: tổng các dòng chi tiết = dòng tổng; tổng theo loại tiền = tổng chung.
• Cân đối: với biểu cân đối, tổng tài sản = tổng nguồn vốn.
• Đối chiếu GL: tổng chỉ tiêu = tổng tài khoản GL tương ứng (khớp về nguồn sự thật).
• So sánh kỳ trước: biến động vượt ngưỡng bất thường → cảnh báo để soi trước khi nộp.
• Đầy đủ danh mục: không có bản ghi rơi vào nhóm "chưa phân loại" vượt ngưỡng.

Chi tiết về đối soát và kiểm soát chất lượng nằm ở bài Data quality & recon; việc tự động hoá và chốt kiểm soát khi tần suất cao ở bài Automation & governance.

Use case thực tế

Bối cảnh. Ngân hàng nộp biểu thống kê huy động - tín dụng tháng, phân rã theo loại tiền và kỳ hạn. Pipeline đã tự động, kỳ nộp theo tháng.

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

• Pipeline chạy xong, biểu vượt qua kiểm tra cộng dồn nội bộ — mọi dòng cộng khớp về tổng. Nhìn qua thì "sạch".
• Nhưng bước so sánh kỳ trước bật cảnh báo: tổng tiền gửi ngoại tệ quy đổi tăng +9% so tháng trước, trong khi số dư ngoại tệ nguyên tệ chỉ tăng khoảng +1%.
• Data team khoan xuống: chênh lệch không đến từ nghiệp vụ mà từ tỷ giá quy đổi. Bảng tỷ giá dùng để quy đổi bị lấy nhầm sang tỷ giá bán thay vì tỷ giá quy đổi thống nhất theo quy định, do một job cập nhật reference data đổi nguồn.
• Sửa nguồn tỷ giá, chạy lại: tổng ngoại tệ quy đổi tăng +1,2%, khớp với biến động nguyên tệ.

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

1. Kiểm tra cộng dồn không đủ — biểu sai vẫn cộng khớp hoàn hảo vì lỗi nằm ở tham số chuẩn hoá (tỷ giá), không ở logic tổng hợp.
2. Chốt cứu tình huống là so sánh chéo hai đại lượng lẽ ra phải đồng biến (nguyên tệ vs. quy đổi) và so sánh xu hướng kỳ trước — không phải ràng buộc trong nội bộ một biểu.
3. Nguyên nhân gốc là quản trị reference data (tỷ giá) — một vấn đề chuẩn hoá danh mục thuần tuý. Nếu tỷ giá được quản lý có phiên bản và kiểm soát nguồn, lỗi đã không xảy ra.

Ghi nhớ

• Báo cáo thống kê phục vụ điều hành chính sách tiền tệ, giám sát diễn biến/xu hướng, và thống kê quốc gia — nên định nghĩa chỉ tiêu rất chặt để cộng dồn xuyên ngân hàng và so sánh được.
• Hệ thống chỉ tiêu gồm ba tầng: mã biểu (biểu + kỳ báo cáo), mã chỉ tiêu (từng ô, có định nghĩa chuẩn), và chiều phân tổ (loại tiền, kỳ hạn, đối tượng, ngành...). Đặc tả kèm quy tắc kiểm tra chéo — hãy nội bộ hoá thành test.
• Các nhóm biểu điển hình: cân đối tài khoản kế toán (nguồn sự thật), thống kê tiền tệ (huy động/tín dụng theo loại tiền/kỳ hạn/đối tượng/ngành), lãi suất (bình quân gia quyền theo số dư), thanh toán (đếm khối lượng giao dịch), ngoại hối (một số chỉ tiêu chạy theo ngày).
• Tần suất đa dạng: ngày / tháng / quý / năm / đột xuất. Chỉ tiêu ngày bắt buộc tự động hoá.
• Nộp điện tử: kết tập theo mã biểu/chỉ tiêu, ký số, gửi qua hệ thống tập trung; cổng kiểm tra cấu trúc & chéo tự động, reject nếu sai; nộp lại có dấu vết.
• Ba thách thức dữ liệu cốt lõi: mapping GL → chỉ tiêu (quản lý như dữ liệu có phiên bản, truy vết được); chuẩn hoá danh mục (loại tiền/tỷ giá, kỳ hạn gốc vs. còn lại, ngành kinh tế); bút toán điều chỉnh (chốt as-of date, số đầu/cuối kỳ, nộp lại có phiên bản).
• Pipeline nên tái lập được: chạy lại cho một ngày báo cáo quá khứ phải ra đúng số đã nộp, trừ khi có điều chỉnh chính thức.
• Bài chỉ nêu nguyên tắc; mã biểu, mã chỉ tiêu, kỳ báo cáo và số hiệu Thông tư cụ thể phải tra cứu văn bản NHNN hiện hành.