Báo cáo NHNN 8 — Tự động hoá & quản trị báo cáo

Bảy bài trước đã đi qua từng mảnh của bức tranh báo cáo tuân thủ: tổng quan giám sát, tỷ lệ an toàn, thống kê tiền tệ - tín dụng, thông tin tín dụng CIC, báo cáo phòng chống rửa tiền, regulatory data mart và chất lượng dữ liệu & đối soát. Mỗi bài trả lời "báo cáo cái gì và tính thế nào". Bài cuối này trả lời câu hỏi quyết định ngân hàng có sống nổi với gánh nặng báo cáo hay không: làm sao để toàn bộ dây chuyền đó chạy đều, đúng hạn, ít lỗi, giải trình được — mà không đốt cháy đội ngũ mỗi kỳ khoá sổ.

Đó là bài toán của tự động hoá và quản trị báo cáo — không phải một tính năng, mà là cách tổ chức cả nhà máy sản xuất báo cáo. Bài này gom các bài kỹ thuật của series (data mart, chất lượng dữ liệu) và các bài nền tảng về điều phối Airflow, biến đổi dữ liệu dbt và quản trị dữ liệu thành một kiến trúc vận hành hoàn chỉnh.

Lưu ý về phạm vi. Bài trình bày ở mức nguyên tắc kiến trúc và vận hành. Số hiệu Thông tư, cấu trúc biểu mẫu, định dạng file nộp và cơ chế ký số cụ thể do NHNN và các đầu mối nhận báo cáo quy định và thay đổi theo thời gian — khi triển khai luôn tra cứu văn bản hiện hành và đặc tả kỹ thuật chính thức.

Vì sao phải bỏ Excel thủ công

Ở nhiều ngân hàng, quy trình báo cáo khởi đầu như một chuỗi file Excel: một người kéo số từ core banking, dán vào sheet, người khác chỉnh công thức, VLOOKUP nối bảng, rồi copy sang biểu mẫu nộp. Nó chạy được — cho đến khi không. Vấn đề của quy trình thủ công không phải "chậm", mà là bốn điểm chết người trong bối cảnh tuân thủ:

1. Lỗi âm thầm và không lặp lại. Một ô công thức kéo lệch một hàng, một cell hardcode số tháng trước còn sót, một vùng SUM quên một dòng mới thêm. Excel không báo lỗi — nó cứ ra một con số, và con số đó sai. Tệ hơn: chạy lại cùng dữ liệu có thể ra kết quả khác vì thao tác tay khác.

2. Không kịp hạn khi khối lượng tăng. Báo cáo daily (trạng thái ngoại tệ, giao dịch PCRT phát sinh) không thể chờ một người mở file lúc 8h sáng. Khi số biểu mẫu và tần suất tăng theo giám sát trên cơ sở rủi ro, sức người không co giãn kịp.

3. Không audit được. Thanh tra hỏi "con số này từ đâu ra?" — với Excel, câu trả lời là "để em mở lại file... à file bị ghi đè tháng sau rồi". Không vết, không phiên bản, không giải trình.

4. Rủi ro tập trung vào con người. Cả quy trình nằm trong đầu một, hai người "biết chỗ số nằm ở đâu". Họ nghỉ, quy trình đứng.

Tự động hoá giải đúng bốn điểm này: mã hoá logic thành code có kiểm thử (loại lỗi âm thầm), điều phối theo lịch (kịp hạn), ghi vết mọi lần chạy (audit), tách tri thức khỏi cá nhân (giảm rủi ro tập trung). Ngắn gọn: biến báo cáo từ tác vụ thủ công thành một sản phẩm dữ liệu có SLA.

Kiến trúc tự động hoá đầu-cuối

Một dây chuyền báo cáo tự động chuẩn có sáu chặng, mỗi chặng là một tầng kỹ thuật riêng, được điều phối bởi một orchestrator (thường là Airflow).

Chặng 1 — ELT (Extract-Load-Transform). Kéo dữ liệu thô về vùng landing/raw trước, biến đổi sau. Khác ETL cổ điển (biến đổi trước khi nạp), ELT giữ bản thô nguyên vẹn — bắt buộc trong tuân thủ vì phải chứng minh được con số cuối bắt nguồn từ đúng dữ liệu nào, thời điểm nào. Airflow điều phối chặng này: một DAG với các task phụ thuộc, có retry, có sensor chờ hệ nguồn khoá sổ. Nền tảng ở bài Airflow và bài pipeline dữ liệu.

Chặng 2 — Tính chỉ tiêu (dbt / SQL có kiểm thử). Trái tim logic nghiệp vụ: ánh xạ dữ liệu chuẩn hoá sang từng chỉ tiêu theo mapping NHNN (phân loại nợ, quy đổi tỷ giá, gom theo ngành/kỳ hạn...). dbt mang lại ba thứ then chốt: (a) mỗi chỉ tiêu là một model SQL có tên, có version, review qua Git; (b) dbt test kiểm thử ngay trên logic (not_null, unique, accepted_values, custom test kiểu "tổng chi tiết = tổng gộp"); (c) dbt docs sinh lineage tự động giữa các model. Logic báo cáo thành code có kiểm thử, không phải công thức Excel.

Chặng 3 — Sinh biểu mẫu (report generation). Từ các chỉ tiêu đã tính, đóng gói theo đúng cấu trúc biểu mẫu và định dạng file nộp mà đầu mối nhận yêu cầu (file có cấu trúc, XML/text theo đặc tả, hoặc payload cho cổng trực tuyến). Chặng này thuần kỹ thuật nhưng khắt khe: sai một mã chỉ tiêu, sai định dạng ngày, thiếu trường bắt buộc là bị từ chối tự động ở đầu nhận.

Chặng 4 — Kiểm soát chất lượng (DQ gate). Trước khi cho nộp, chạy bộ kiểm tra tự động: đối soát sổ cái, so sánh xu hướng kỳ trước, kiểm tra ràng buộc (không âm nơi không được âm, tỷ lệ trong khoảng hợp lệ). Mấu chốt: đây là cổng chặn (gate), không phải cảnh báo suông — không đạt thì pipeline dừng và không nộp, không có chuyện "cứ nộp rồi sửa sau". Chi tiết ở bài chất lượng & đối soát.

Chặng 5 — Phê duyệt & ký số (maker-checker). Tự động hoá không bỏ con người. Số liệu qua gate phải được người có thẩm quyền xem lại, phê duyệt và ký số trước khi nộp — chốt kiểm soát nội bộ bắt buộc, bàn kỹ ở mục dưới.

Chặng 6 — Nộp & thu biên nhận. Gửi qua cổng/kênh chính thức, ghi biên nhận và mã tham chiếu, đối chiếu phản hồi (chấp nhận / từ chối / yêu cầu đính chính) và ghi tất cả vào audit trail.

Nguyên tắc bao trùm: con người quyết định và chịu trách nhiệm; máy làm phần lặp lại, ghi vết và chặn lỗi. Càng tự động, chốt kiểm soát càng phải chặt, không phải càng lỏng.

Lineage đầu-cuối: xương sống của giải trình

Trong báo cáo tuân thủ, năng lực đắt giá nhất không phải tính đúng con số — mà là giải trình được con số đó khi thanh tra hỏi ngược. Câu hỏi kinh điển: "Ô CAR 11,4% trên biểu mẫu này cấu thành từ đâu?". Trả lời được câu này trong vài phút thay vì vài ngày là ranh giới giữa một nhà máy báo cáo trưởng thành và một mớ Excel.

Lineage (truy vết dòng dữ liệu) là bản đồ cho phép đi từ một ô trên biểu mẫu nộp, ngược qua model tính chỉ tiêu, qua bảng chuẩn hoá, về tận bản ghi thô ở hệ nguồn tại đúng thời điểm chốt số. Trong kiến trúc trên, lineage được ghép từ nhiều lớp:

Lớp	Cung cấp gì cho lineage
Airflow	Chạy nào (run_id), lúc nào, task nào thành công/thất bại, dữ liệu vào từ đâu
dbt	Model nào phụ thuộc model nào, chỉ tiêu tính bằng SQL gì, version nào
Data mart	Ô báo cáo ↔ dòng chi tiết (khoản vay, tài khoản, giao dịch) khớp về
Audit trail nộp	Bản nào đã nộp, lúc nào, ai ký, biên nhận số bao nhiêu

Ghép bốn lớp lại, ta được đường truy vết đầu-cuối: ô báo cáo → model dbt → bảng chuẩn hoá → snapshot thô → hệ nguồn + thời điểm chốt số. Khi thanh tra yêu cầu drill-down, đây là thứ trả lời thay cho con người. Đây cũng là lý do ELT (giữ raw) và dbt (lineage tự sinh) không phải lựa chọn phong cách mà là yêu cầu kiến trúc. Liên hệ nguyên tắc chung ở bài governance.

Quản trị thay đổi khi quy định biến động

Quy định báo cáo không đứng yên: NHNN sửa Thông tư, thêm chỉ tiêu, đổi mapping, đổi ngưỡng. Một nhà máy báo cáo tự động mà không quản trị được thay đổi sẽ vỡ đúng vào lúc quy định đổi — thời điểm áp lực cao nhất. Ba trụ cột:

1. Versioning logic báo cáo. Toàn bộ logic tính chỉ tiêu nằm trong Git (model dbt, mapping, ngưỡng DQ). Mỗi thay đổi là một commit/PR có người review, có lịch sử. Điều này cho phép trả lời "kỳ tháng 3 tính theo logic nào, kỳ tháng 6 theo logic nào" — vì bạn có đúng version tương ứng từng kỳ. Khi quy định có ngày hiệu lực, logic phải có điều kiện theo ngày hiệu lực (logic cũ áp cho kỳ trước, logic mới áp cho kỳ sau), không phải sửa đè.

2. Kiểm thử hồi quy (regression testing). Trước khi đưa logic mới lên production, chạy lại trên dữ liệu các kỳ đã nộp và so sánh: những chỉ tiêu không thuộc phạm vi thay đổi phải ra y hệt con số đã nộp; những chỉ tiêu thuộc phạm vi thay đổi phải khớp kỳ vọng của quy định mới. Điều này bắt được "thay đổi ngoài ý muốn" — sửa một model làm lệch một chỉ tiêu tưởng không liên quan.

3. Phê duyệt thay đổi (change approval). Thay đổi logic báo cáo là thay đổi có hệ quả pháp lý, nên phải qua quy trình phê duyệt: nghiệp vụ xác nhận đúng quy định mới, kỹ thuật xác nhận đã kiểm thử, người có thẩm quyền duyệt triển khai. Đây là nơi vòng đời phát triển phần mềm (CI/CD, PR review) gặp kiểm soát nội bộ ngân hàng.

Maker-checker, kiểm soát nội bộ và vết kiểm toán

Tách vai trò (segregation of duties) là nguyên tắc kiểm soát nội bộ cổ điển: người tạo ra một thứ không được là người duyệt chính thứ đó. Trong báo cáo, mô hình maker-checker nghĩa là:

• Maker — người (hoặc pipeline dưới sự vận hành của một người) tạo bản báo cáo: chạy tính toán, xử lý ngoại lệ.
• Checker — người độc lập rà soát và phê duyệt trước khi nộp: xác nhận số liệu hợp lý, gate DQ đã xanh, cảnh báo đã được giải thích.

Nguyên tắc: không ai vừa làm vừa tự duyệt cho báo cáo của mình đi nộp — chặn cả sai sót vô ý lẫn hành vi cố ý bóp méo số liệu.

Kèm theo là vết kiểm toán (audit trail) không thể chối bỏ: ai chạy pipeline (run_id, thời điểm), gate DQ ra sao, ai phê duyệt, ai ký số, bản nào nộp lúc nào, biên nhận thế nào. Mỗi lần nộp lại (resubmission) đính chính cũng để lại vết riêng gắn lý do. Audit trail biến câu "chúng tôi có kiểm soát" thành bằng chứng kiểm tra được — cho cả kiểm toán nội bộ lẫn thanh tra.

RegTech và xu hướng báo cáo hiện đại

RegTech (regulatory technology) là ứng dụng công nghệ để thực hiện nghĩa vụ tuân thủ hiệu quả hơn: tự động hoá lập báo cáo, giám sát tuân thủ theo thời gian thực, quản lý thay đổi quy định. Với data team, RegTech không phải mua sản phẩm — nó là cách xây năng lực nội bộ đúng như kiến trúc bài này mô tả. Ba xu hướng đáng theo dõi:

Báo cáo theo chuẩn dữ liệu (standardized reporting). Thay vì mỗi biểu mẫu một định dạng riêng, xu hướng chuẩn hoá cả mô hình dữ liệu lẫn định nghĩa chỉ tiêu (data dictionary chung, mã chuẩn cho ngành/kỳ hạn/loại tiền), giảm chi phí ánh xạ và tăng tính so sánh giữa các định chế.

Báo cáo chi tiết (granular reporting). Thay vì nộp số tổng đã gộp, cơ quan giám sát ngày càng muốn nhận dữ liệu chi tiết ở mức giao dịch/khoản vay/khách hàng rồi tự tổng hợp. Điều này đẩy gánh nặng từ "tính đúng con số tổng" sang "cung cấp dữ liệu chi tiết sạch, nhất quán" — đúng thế mạnh của một regulatory data mart tốt.

Pull-based reporting (báo cáo theo cơ chế kéo). Ở mô hình truyền thống, ngân hàng đẩy (push) báo cáo theo lịch. Xu hướng tương lai là cơ quan giám sát kéo (pull) dữ liệu chi tiết trực tiếp từ một lớp dữ liệu chuẩn ngân hàng duy trì, giảm độ trễ và bớt bước đóng gói biểu mẫu. Mô hình này đòi hỏi dữ liệu luôn sẵn sàng, luôn đúng — nâng yêu cầu chất lượng và governance lên rất cao.

Điểm chung cả ba: dịch trọng tâm từ "sản xuất biểu mẫu" sang "duy trì một nền dữ liệu chi tiết, chuẩn hoá, chất lượng cao, truy vết được" — chính là thứ cả series này xây dựng.

Bộ chỉ số vận hành nhà máy báo cáo

Bạn không quản trị được thứ bạn không đo. Một nhà máy báo cáo trưởng thành theo dõi bộ chỉ số vận hành (operational metrics) để biết mình đang khoẻ hay ốm:

Chỉ số	Đo cái gì	Ngưỡng mục tiêu (minh hoạ)
Tỷ lệ đúng hạn (on-time rate)	% báo cáo nộp trước hạn	≥ 99%
Số lỗi bị đầu nhận từ chối	Số lần reject/đính chính mỗi kỳ	Giảm dần về ~0
Số cảnh báo DQ mở	Cảnh báo chất lượng chưa xử lý trước nộp	0 tại thời điểm nộp
Thời gian lập (cycle time)	Từ khoá sổ nguồn đến sẵn sàng nộp	Giảm dần, đủ đệm trước hạn
Tỷ lệ tự động	% chặng chạy tự động, không can thiệp tay	Tăng dần
Thời gian trả lời drill-down	Từ lúc thanh tra hỏi đến khi trả lời được	Giờ, không phải ngày

Bộ chỉ số này biến báo cáo thành một dịch vụ có SLA đo được, giúp phát hiện suy thoái sớm (cycle time bò lên, số reject nhích lên) trước khi nó thành sự cố lỡ hạn.

Use case thực tế

Bối cảnh. Ngân hàng đã tự động hoá báo cáo thống kê tín dụng theo tháng: DAG Airflow chạy ELT → dbt tính chỉ tiêu → sinh file → DQ gate → maker-checker → nộp. Hạn nộp: ngày làm việc thứ 12 hằng tháng. Giữa kỳ, NHNN ban hành thay đổi mapping một chỉ tiêu dư nợ theo ngành, hiệu lực từ kỳ tháng 6.

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

• Ngày làm việc thứ 5, nghiệp vụ chuyển yêu cầu đổi mapping. Kỹ thuật sửa model dbt, gắn điều kiện theo ngày hiệu lực: kỳ < tháng 6 giữ logic cũ, kỳ ≥ tháng 6 dùng logic mới.
• Mở PR. CI chạy dbt test và kiểm thử hồi quy trên 6 kỳ đã nộp: 47/48 chỉ tiêu ra y hệt số đã nộp (đúng kỳ vọng — ngoài phạm vi), riêng chỉ tiêu bị sửa khớp kỳ vọng mới. Một chỉ tiêu tưởng không liên quan bỗng lệch → phát hiện dùng chung một macro, sửa lại đúng phạm vi.
• Trình duyệt kèm bằng chứng kiểm thử. Duyệt, triển khai.
• Kỳ tháng 6: DQ gate so sánh xu hướng — chỉ tiêu đổi mapping "nhảy" đúng dự kiến, maker chú thích lý do, checker xác nhận và duyệt. Nộp đúng hạn, biên nhận ghi vào audit trail.
• Hai tuần sau, thanh tra hỏi vì sao dư nợ một ngành đổi cách phân loại. Data team drill-down qua lineage trong dưới 30 phút: chỉ ra version model, ngày hiệu lực, mapping mới và bằng chứng kiểm thử hồi quy.

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

1. Versioning + ngày hiệu lực cho phép vừa áp logic mới cho kỳ mới, vừa tái lập được các kỳ cũ — không "sửa đè quá khứ".
2. Kiểm thử hồi quy bắt được tác động ngoài ý muốn (macro dùng chung) mà mắt người khó thấy.
3. Maker-checker + audit trail biến một thay đổi rủi ro thành một sự kiện có kiểm soát, giải trình được.
4. Lineage đầu-cuối biến câu hỏi hóc búa của thanh tra từ khủng hoảng vài ngày thành việc vài chục phút.

Ghi nhớ

• Tự động hoá báo cáo giải bốn điểm chết của Excel thủ công: lỗi âm thầm không tái lập, không kịp hạn, không audit được, rủi ro tập trung vào con người. Mục tiêu: biến báo cáo thành sản phẩm dữ liệu có SLA.
• Kiến trúc đầu-cuối sáu chặng, điều phối bởi Airflow: ELT → tính chỉ tiêu (dbt/SQL có kiểm thử) → sinh biểu mẫu → DQ gate → phê duyệt & ký số → nộp. DQ là cổng chặn, không đạt thì không nộp.
• Lineage đầu-cuối (ghép Airflow + dbt + data mart + audit trail nộp) là xương sống giải trình: truy từ ô báo cáo về snapshot thô và hệ nguồn. ELT giữ raw và dbt sinh lineage là yêu cầu kiến trúc, không phải phong cách.
• Quản trị thay đổi khi quy định biến động dựa trên ba trụ: versioning logic (Git, ngày hiệu lực), kiểm thử hồi quy (kỳ cũ ra y hệt, kỳ mới khớp kỳ vọng), và phê duyệt thay đổi.
• Maker-checker (tách vai trò tạo và duyệt) cùng audit trail không thể chối bỏ là chốt kiểm soát nội bộ bắt buộc; nộp lại/đính chính cũng để lại vết.
• RegTech đẩy ba xu hướng: báo cáo theo chuẩn dữ liệu, granular reporting (nộp dữ liệu chi tiết), và pull-based reporting — tất cả dịch trọng tâm sang duy trì nền dữ liệu chi tiết, chuẩn hoá, chất lượng cao.
• Đo để quản trị: tỷ lệ đúng hạn, số lỗi/reject, cảnh báo DQ mở, cycle time, tỷ lệ tự động, thời gian trả lời drill-down.
• Bài chỉ nêu nguyên tắc; cấu trúc biểu mẫu, định dạng nộp, cơ chế ký số và số hiệu Thông tư phải tra cứu văn bản NHNN hiện hành khi triển khai.