Quản trị rủi ro trong ngân hàng trước các sự kiện “Thiên nga đen”

Sự xuất hiện của “thiên nga đen” cho thấy giới hạn của mô hình truyền thống và thực tế là không phải mọi rủi ro đều có thể đo lường. Thiên nga đen có thể xuất hiện trong mọi loại rủi ro – tín dụng, thị trường, hoạt động – nhưng trong thực tế quản trị thì nó liên quan nhiều nhất tới rủi ro hoạt động.

1. Khó khăn của Quản trị rủi ro hoạt động truyền thống

Hầu hết các khung quản trị rủi ro hiện nay (như Basel II giai đoạn đầu) được xây dựng dựa trên lý thuyết xác suất và phân phối chuẩn (Bell Curve). Điều này dẫn đến 3 "điểm mù" lớn:

• Bẫy dữ liệu lịch sử: Các mô hình dự báo thường dựa vào dữ liệu quá khứ. Tuy nhiên, Thiên nga đen là những sự kiện chưa từng xảy ra hoặc có tần suất thấp đến mức dữ liệu không đủ để phản ánh tính nghiêm trọng.
• Sự phức tạp của các mối liên kết (Correlation): Trong điều kiện bình thường, các rủi ro dường như độc lập. Nhưng trong khủng hoảng, các mối liên kết ngầm (như giữa lỗi hệ thống CNTT và thanh khoản ngân hàng) bùng phát cùng lúc, tạo ra hiệu ứng domino mà không mô hình nào tính toán hết được.
• Tâm lý lạc quan và "Sự im lặng của dữ liệu": Các sự kiện "suýt xảy ra" (near-miss) thường bị bỏ qua hoặc báo cáo chưa đầy đủ, khiến tổ chức lầm tưởng về độ an toàn của hệ thống.

Trong quản lý rủi ro hoạt động, Thiên nga đen là những sự cố vượt ngoài mọi giả định, ví dụ:

• Khủng hoảng tài chính toàn cầu năm 2008.
• Đại dịch COVID-19 làm gián đoạn chuỗi cung ứng toàn cầu.
• Một vụ tấn công mạng quy mô lớn khiến hàng triệu tài khoản ngân hàng bị lộ.

Điểm nguy hiểm là các mô hình truyền thống thường bỏ qua hoặc đánh giá thấp xác suất xảy ra của những sự kiện này. Trong ngành ngân hàng, các sự kiện rủi ro hoạt động như vụ hack SWIFT ở Bangladesh Bank (2016), sự cố CNTT khi nâng cấp hệ thống lõi của TSB Bank (2018), sự cố thanh toán Visa châu Âu (2018) hay các sự kiện rủi ro khác cũng có liên quan tới rủi ro hoạt động như Lehman Brothers (2008-2009), khủng hoảng nợ châu Âu (2010-2012), COVID-19 (2020), Credit Suisse (2023), SVB (2023) cho thấy thiên nga đen đang xuất hiện nhiều hơn, với tác động hệ thống và tốc độ lan truyền nhanh. Điều này củng cố quan điểm thực tiễn rằng các ngân hàng cần chuẩn bị cho một thế giới nơi thiên nga đen không còn là hiếm hoi.

Thay vì cố gắng dự báo Thiên nga đen, các tổ chức cần xây dựng văn hóa nhận thức rủi ro (culture of risk awareness) để phát hiện sớm các dấu hiệu rủi ro và xây dựng một hệ thống "Càng hỗn loạn càng mạnh mẽ" (Antifragile) – nơi mà các sai sót nhỏ được phát hiện sớm và hệ thống có đủ độ linh hoạt – để có thể tự điều chỉnh trước khi rủi ro lớn ập đến.

2. Thử nghiệm ứng suất ngược (Reverse Stress Testing - RST)

Để vượt qua giới hạn của phương pháp truyền thống, tư duy quản trị cần chuyển dịch từ "Dự báo" sang "Giả định thảm họa". Đây chính là nền tảng của Stress test ngược.

Quy trình thực hiện:

Thay vì bắt đầu bằng nguyên nhân (Ví dụ: "Nếu hệ thống lỗi..."), RST bắt đầu bằng kết quả cuối cùng (Điểm gãy - Breaking point). Hãy xét thử kịch bản giả định sau: "Sự sụp đổ của tính toàn vẹn dữ liệu giao dịch".

• Xác định trạng thái "Thất bại hoàn toàn": Trong vòng 48 giờ, hệ thống thanh toán báo "Giao dịch thành công" cho khách hàng và đối tác (Merchant), nhưng tiền không thực sự được hạch toán vào hệ thống lõi (Core Banking), hoặc bị hạch toán sai lệch hoàn toàn. Hậu quả có thể xảy ra là ngân hàng thất thoát hàng trăm hay thâm chí hàng ngàn tỷ đồng không thể thu hồi; đối tác đồng loạt ngắt kết nối; Ngân hàng Nhà nước đình chỉ giấy phép thanh toán trực tuyến để thanh tra.

• Truy vết ngược (Working Backwards): Tìm kiếm tất cả các kịch bản, dù là vô lý nhất, có thể dẫn đến kết cục đó. Điều này thường dẫn đến việc phát hiện ra các lỗi cấu hình tham số, sự phụ thuộc quá mức vào một nhà cung cấp, hoặc lỗ hổng trong quy trình vận hành. Để đạt đến thảm họa này, không chỉ một lỗi đơn lẻ mà thường là sự kết hợp của một "Cơn bão hoàn hảo":

• o Nhân tố A (Lỗi tham số hóa): Một bản cập nhật cấu hình API mở mới nhằm tăng tốc độ xử lý giao dịch đã vô tình ghi đè lên tham số kiểm tra số dư (Validation Logic).

• o Nhân tố B (Rủi ro bên thứ ba): Đơn vị cung cấp dịch vụ Cloud/HSM gặp sự cố chập chờn, khiến các gói tin xác thực bị trễ (timeout). Hệ thống tự động chuyển sang chế độ "Fail-open" (cho phép đi qua để tránh nghẽn) thay vì "Fail-close".

• o Nhân tố C (Lỗ hổng giám sát): Hệ thống Dashboard KRI đang hiển thị "Xanh" vì nó chỉ đo lường số lượng giao dịch thành công, chứ không đối chiếu (reconciliation) theo thời gian thực giữa Gateway và Core Banking.

• o Nhân tố D (Phản ứng chậm): Đội ngũ vận hành coi các cảnh báo lỗi ban đầu là "nhiễu" do đang có chương trình khuyến mãi lớn gây tải cao.

Sau khi chạy giả lập này, Ban quản trị rủi ro sẽ nhận ra các lỗ hổng mà RCSA thông thường có thể bỏ qua:

• o Điểm mù 1: Quy trình phê duyệt thay đổi tham số (Change Management) cho API quá lỏng lẻo.

• o Điểm mù 2: Chế độ "Fail-open" là một rủi ro cực lớn nhưng chưa bao giờ được đưa vào danh mục kiểm soát.

• o Điểm mù 3: Thiếu KRI về "Tỷ lệ khớp dữ liệu thời gian thực" (Real-time reconciliation rate).

• Đánh giá khả năng chống chịu: Kiểm tra xem với kịch bản thảm họa đó, các chốt kiểm soát hiện tại có phát huy tác dụng hay không.

3. Các phương pháp đối phó với Thiên nga đen

Khi đối mặt với những ẩn số không thể xác định xác suất, chiến lược hiệu quả nhất không phải là "ngăn chặn" mà là xây dựng Năng lực phục hồi (Resilience) và Tính phản mong manh (Antifragility).

a. Thiết lập "Cầu dao rủi ro" (Circuit Breakers)

Trong các hệ thống API mở và tích hợp phức tạp, cần có các cơ chế ngắt tự động. Ví dụ: Nếu tỷ lệ giao dịch lỗi vượt quá một ngưỡng nhất định hoặc có dấu hiệu sai lệch dữ liệu số dư, hệ thống sẽ tự động cô lập phân đoạn đó thay vì để rủi ro lan rộng ra toàn bộ ngân hàng.

b. Red Teaming và Diễn tập sa bàn (Tabletop Exercises)

Không chỉ dừng lại ở việc quét lỗ hổng kỹ thuật, tổ chức cần các đội chuyên gia đóng vai "kẻ tấn công" để thử nghiệm các kịch bản phi truyền thống. Các buổi diễn tập sa bàn với sự tham gia của cả lãnh đạo cấp cao giúp chuẩn hóa quy trình ra quyết định trong trạng thái khủng hoảng – thời điểm mà các quy định vận hành thông thường thường bị tê liệt.

c. Chiến lược linh hoạt (Agility & Flexibility)

• Tham số hóa hệ thống: Thay vì cài đặt cứng (hard-code) các quy tắc nghiệp vụ, việc tham số hóa giúp ngân hàng điều chỉnh nhanh chóng trước các biến động chính sách hoặc thị trường mà không cần can thiệp vào mã nguồn.
• Đa dạng hóa hạ tầng: Tránh rủi ro tập trung vào một nhà cung cấp duy nhất (Single Point of Failure). Luôn có sẵn "Kế hoạch thoát hiểm" (Exit Strategy) để chuyển đổi dịch vụ khi nhà cung cấp gặp sự cố thiên nga đen.

d. Tập trung vào "Khả năng chịu đựng tác động" (Impact Tolerance)

Thay vì cố gắng dự báo khi nào thảm họa xảy ra, hãy xác định: "Chúng ta có thể chịu đựng việc gián đoạn dịch vụ này trong bao lâu trước khi gây ra thiệt hại không thể phục hồi?". Việc thiết lập ngưỡng chịu đựng giúp định hướng ưu tiên nguồn lực đầu tư cho các hệ thống trọng yếu.

4. Kết luận

Quản trị rủi ro Thiên nga đen không phải là một bài toán xác suất, mà là một bài toán về năng lực thích nghi. Việc tích hợp Stress test ngược vào quy trình RCSA định kỳ không chỉ giúp tổ chức tuân thủ các chuẩn mực quốc tế như Basel III mà quan trọng hơn, nó tạo ra một "hệ thống miễn dịch" giúp ngân hàng không chỉ sống sót mà còn phát triển mạnh mẽ hơn sau mỗi biến cố.

Tài liệu tham khảo:

https://www.federalreserve.gov/econres/feds/files/2025043pap.pdf

https://ascelibrary.org/doi/pdf/10.1061/%28ASCE%29LM.1943-5630.0000036

https://www.pwc.co.uk/assets/pdf/risk-practices-black-swans-turn-grey-the-transformation-of-the-risk-landscape.pdf