Thanh toán 6 — Đối soát & quyết toán

Một giao dịch chuyển tiền không "sống" trong một hệ thống duy nhất. Nó đi qua sổ cái nội bộ của ngân hàng gửi, hệ thống của ngân hàng đại lý (correspondent), mạng clearing (bù trừ), rồi hệ thống của ngân hàng nhận. Mỗi chặng, mỗi bên tự ghi một bản sổ riêng. Đối soát (reconciliation) là công việc bắt buộc để khẳng định: những gì ngân hàng tin là đã xảy ra trùng khớp với những gì các bên bên ngoài xác nhận đã xảy ra. Không đối soát nghĩa là bay mù — tiền có thể thiếu, thừa, trùng hoặc bị ghi sai mà không ai biết cho đến khi khách hàng khiếu nại hoặc kiểm toán phát hiện.

Bài này khép lại phần "back-office" của series thanh toán: sau khi đã hiểu luồng SWIFT/nostro (Thanh toán 3) và bản tin ISO 20022 (Thanh toán 2), giờ ta nhìn góc sau khi tiền đã chạy: làm sao khớp sổ, netting là gì, khi nào giao dịch trở thành không thể đảo ngược, và quy trình xử lý sai lệch (break) hằng ngày ra sao.

Vì sao phải đối soát

Bản chất của thanh toán là phân tán trạng thái. Khi ngân hàng A trả tiền cho khách của ngân hàng B, dòng tiền không nhảy thẳng từ A sang B mà đi qua tài khoản trung gian: A giữ một tài khoản nostro tại một correspondent, correspondent nối vào mạng clearing, và cuối chặng số dư của B thay đổi. Mỗi bên trong chuỗi giữ một quyển sổ. Các quyển sổ đó phải kể cùng một câu chuyện, nhưng thực tế lệch nhau vì:

• Độ trễ thời gian: ngân hàng ghi có/ghi nợ ngay khi khởi tạo lệnh (T), nhưng sao kê từ correspondent phản ánh khi tiền thực sự về (T+1, T+2). Trong khoảng đó hai sổ tất yếu khác nhau.
• Phí và tỷ giá: correspondent trừ phí, hoặc quy đổi ngoại tệ với tỷ giá khác dự kiến → số tiền về không bằng số tiền gửi.
• Lỗi vận hành: nhập trùng, gửi hai lần, sai tài khoản, sai reference.
• Giao dịch "mồ côi": một khoản ghi có xuất hiện trên sao kê mà nội bộ không có lệnh tương ứng (ai đó gửi tiền vào nhưng thông tin chưa khớp về được).

Đối soát chính là hoạt động phát hiện thiếu, thừa, trùng, sai một cách có hệ thống — không đợi đến khi có sự cố mới đi tìm.

Các loại đối soát

Trong một ngân hàng có nhiều "trục" đối soát khác nhau, mỗi trục so hai nguồn dữ liệu độc lập.

Nostro reconciliation

Đây là đối soát kinh điển của mảng thanh toán quốc tế. Ngân hàng giữ sổ nội bộ về tài khoản nostro (bản ghi của chính mình về những gì mình nghĩ đã đi qua tài khoản tại correspondent) và so với sao kê do correspondent gửi về — ngày nay chủ yếu ở dạng bản tin ISO 20022 camt.053 (Bank-to-Customer Statement) hoặc camt.052 (báo cáo trong ngày). Mỗi dòng ghi nợ/ghi có trên sao kê phải khớp với một mục nội bộ.

Nostro = tài khoản "của chúng tôi ở ngân hàng khác". Vostro = tài khoản "của quý vị ở ngân hàng chúng tôi" — cùng một tài khoản nhìn từ hai phía. Chi tiết ở Thanh toán 3 — SWIFT & xuyên biên giới.

Đối soát với scheme (thẻ / NAPAS)

Với thanh toán thẻ và chuyển khoản nội địa, ngân hàng đối soát với mạng chuyển mạch / scheme: file đối soát từ Visa/Mastercard, hoặc từ NAPAS cho giao dịch thẻ nội địa và chuyển nhanh 24/7 tại Việt Nam. Ngân hàng so nhật ký giao dịch của mình (những gì đã cấp phép và thanh toán) với file quyết toán của scheme (những gì scheme sẽ ghi nợ/ghi có ròng cho ngân hàng), bao gồm cả phí interchange và phí scheme.

Đối soát nội bộ (GL vs subledger)

Không phải mọi đối soát đều "ra bên ngoài". Đối soát GL (sổ cái tổng) vs subledger (sổ chi tiết) kiểm tra tính nhất quán ngay trong lòng ngân hàng: tổng số dư của module thanh toán/chi tiết giao dịch phải bằng số dư tài khoản tương ứng trên sổ cái tổng. Đây là ứng dụng trực tiếp của nguyên tắc bút toán kép và tính đối chiếu control account.

Đối soát với clearing house

Với các hệ thống bù trừ (clearing house) — ví dụ hệ thống thanh toán bù trừ điện tử của ngân hàng trung ương hoặc ACH — ngân hàng đối soát các lệnh mình đã gửi vào phiên bù trừ với báo cáo kết quả phiên và vị thế ròng (net position) mà mình phải nộp hoặc được nhận khi settle.

Netting: thanh toán ròng thay vì từng khoản

Nếu mỗi giao dịch đều được settle riêng lẻ (gross settlement), số lần chuyển tiền và nhu cầu thanh khoản sẽ khổng lồ. Netting gộp nhiều khoản phải trả/phải thu giữa các bên thành một số ròng để settle một lần.

• Bilateral netting (song phương): giữa đúng hai bên. Trong ngày A nợ B 100 và B nợ A 70 → chỉ A trả B 30. Số lần chuyển giảm, nhu cầu thanh khoản giảm.
• Multilateral netting (đa phương): qua một trung tâm bù trừ (CCP / clearing house) đứng giữa nhiều thành viên. Mỗi thành viên chỉ tính một vị thế ròng với trung tâm thay vì với từng đối tác. Đây là mô hình của hầu hết hệ thống bù trừ bán lẻ.

Đánh đổi cốt lõi: netting giảm mạnh nhu cầu thanh khoản (chỉ cần đủ tiền cho phần ròng) nhưng tích tụ rủi ro trong khoảng thời gian giữa các lần settle — nếu một thành viên vỡ nợ trước giờ quyết toán, các vị thế ròng có thể phải tính lại. Vì thế netting luôn đi kèm quản trị rủi ro chặt: ký quỹ, hạn mức, và quy tắc pháp lý bảo vệ tính hiệu lực của netting khi có thành viên phá sản.

Đối lập với net settlement là RTGS (Real-Time Gross Settlement) — settle từng khoản, tức thời, không netting, dùng cho giao dịch giá trị lớn nơi rủi ro tích tụ là không chấp nhận được.

Settlement finality: khi tiền hết đường lui

Settlement finality là thời điểm một khoản thanh toán trở thành không thể đảo ngược và không thể hủy về mặt pháp lý — người nhận chắc chắn giữ được tiền, kể cả khi ngân hàng gửi phá sản ngay sau đó.

Đây không chỉ là chi tiết kỹ thuật mà là nền tảng pháp lý của cả hệ thống thanh toán:

• Trước thời điểm finality, một lệnh có thể bị đảo (recall, return, hủy phiên bù trừ nếu thành viên thiếu tiền).
• Sau finality, tiền đã "định đoạt" — mọi tranh chấp về sau chỉ có thể giải quyết bằng một giao dịch mới ngược chiều, chứ không xóa được giao dịch cũ.

Ý nghĩa với đối soát: chỉ những khoản đã đạt finality mới được coi là chắc chắn khi khớp sổ. Một khoản đã "gửi đi" nhưng chưa final vẫn có thể quay lại, nên hạch toán phải phản ánh trạng thái treo (in-flight / pending) đúng cách để không ghi nhận doanh thu/tất toán quá sớm.

Position keeping & thanh khoản trong ngày

Để settle được, tài khoản nostro phải có đủ tiền đúng lúc. Position keeping là việc theo dõi liên tục số dư khả dụng trên từng tài khoản nostro trong suốt ngày (intraday), dựa trên báo cáo trong ngày (camt.052) cộng với các lệnh đã và sẽ đi/về.

Một ngân hàng có thể có hàng chục tài khoản nostro ở nhiều loại tiền tệ, nhiều correspondent. Bộ phận treasury/nostro phải đảm bảo mỗi tài khoản đủ số dư trả các nghĩa vụ đến hạn trong ngày, đồng thời không để tiền "chết" quá nhiều (giữ dư thừa là chi phí cơ hội). Vì thế position keeping gắn liền với dự báo dòng tiền: biết trước những khoản lớn sẽ ra/vào để bơm hoặc rút thanh khoản kịp thời (funding).

Quy trình đối soát: matching → break → xử lý

Đây là trái tim vận hành. Về bản chất, đối soát là bài toán join hai tập dữ liệu và tìm chênh lệch.

Matching (khớp)

Engine cố gắng ghép tự động mỗi dòng của sao kê ngoài với một mục nội bộ. Các khóa khớp phổ biến:

• Reference / UETR: UETR (Unique End-to-end Transaction Reference) là định danh duy nhất theo suốt vòng đời một khoản chuyển tiền trong SWIFT gpi — khóa khớp mạnh nhất khi có.
• Amount + Date: số tiền và ngày giá trị.
• Counterparty / account: đối tác và tài khoản.

Khớp có hai mức: exact match (mọi khóa trùng khít) và fuzzy match (khớp gần đúng — ví dụ chênh lệch nhỏ trong dung sai cho phép, hoặc gộp nhiều dòng nội bộ vào một dòng sao kê tổng). Fuzzy dùng khi dữ liệu không chuẩn (reference cắt xén, số tiền lệch phí).

Exceptions / break

Mọi dòng không khớp trở thành break (còn gọi là exception hoặc unmatched item). Break là tín hiệu có gì đó cần con người điều tra. Các dạng break điển hình:

• Có trên nội bộ, không có trên sao kê → tiền chưa về / chưa đi (có thể do độ trễ, hoặc thất lạc).
• Có trên sao kê, không có nội bộ → khoản "mồ côi" (thừa, hoặc lệnh bị mất bản ghi nội bộ).
• Khớp một phần: cùng khoản nhưng lệch số tiền (phí, tỷ giá) hoặc lệch ngày.
• Trùng: một mục nội bộ khớp hai dòng sao kê (nghi ngờ gửi hai lần).

Điều tra & hạch toán điều chỉnh

Với mỗi break, đội vận hành xác định nguyên nhân, rồi hoặc hạch toán điều chỉnh (ví dụ ghi nhận phí correspondent chưa lường, quy đổi tỷ giá), hoặc liên hệ correspondent/scheme để truy vết (trace) và yêu cầu chỉnh sửa/hoàn trả. Break chỉ được đóng khi hai sổ khớp trở lại và nguyên nhân được ghi lại.

Aging của break

Break không được để tồn đọng. Aging phân loại break theo số ngày chưa xử lý (0–1 ngày, 2–5 ngày, trên 5 ngày, quá hạn nghiêm trọng). Break càng cũ càng rủi ro: có thể là tiền thất lạc thật, hoặc dấu hiệu lỗi hệ thống lặp lại. Báo cáo aging là thước đo sức khỏe vận hành thanh toán và thường là chỉ tiêu bị kiểm toán soi.

Ví dụ minh hoạ quy tắc matching / break

Dưới đây là mô tả quy tắc dạng giả mã (không phải mã chạy được), minh hoạ cách một matching engine phân loại từng dòng sao kê.

QUY TAC MATCHING (uu tien tu tren xuong):

  R1  EXACT   : noibo.UETR == sk.UETR
                AND noibo.amount == sk.amount
                -> MATCHED (do tin cay cao nhat)

  R2  STRONG  : noibo.reference == sk.reference
                AND noibo.amount == sk.amount
                AND |noibo.value_date - sk.value_date| <= 1 ngay
                -> MATCHED

  R3  FUZZY   : noibo.reference == sk.reference
                AND |noibo.amount - sk.amount| <= tolerance(phi)
                -> MATCHED_WITH_DIFF  (tao but toan dieu chinh phi)

  R4  KHONG KHOP -> BREAK, gan loai:
        - noibo co, sk khong          -> BREAK_MISSING_CREDIT (cho tien ve)
        - sk co, noibo khong          -> BREAK_ORPHAN         (khoan mo coi)
        - 1 noibo <-> 2 sk cung tien  -> BREAK_DUPLICATE      (nghi gui 2 lan)
        - amount lech ngoai tolerance -> BREAK_AMOUNT_DIFF

VI DU DU LIEU:
  Noi bo  : UETR=abc-123  amount=10,000.00 USD  date=2026-06-29  ref=INV77
  Sao ke  : UETR=abc-123  amount= 9,985.00 USD  date=2026-06-30  ref=INV77
  -> R1 truot (amount khac) -> R3 khop fuzzy:
     chenh 15.00 USD nam trong tolerance phi correspondent
     => MATCHED_WITH_DIFF, sinh but toan: No "Phi ngan hang dai ly" 15.00

Tự động hoá & vai trò của ISO 20022

Đối soát thủ công không còn khả thi ở quy mô lớn. Ba trụ cột tự động hoá:

• Matching engine + tolerance rules: hệ thống chuyên dụng khớp hàng triệu dòng, áp quy tắc dung sai (chấp nhận lệch nhỏ do phí) để không tạo break giả.
• STP (Straight-Through Processing): mục tiêu là để khoản khớp tự động, ghi sổ tự động, không cần chạm tay — con người chỉ can thiệp vào phần break còn lại.
• Dữ liệu có cấu trúc (ISO 20022): đây là đòn bẩy lớn nhất. Bản tin cũ (MT) có reference dạng văn bản tự do dễ bị cắt xén; ISO 20022 (pain/pacs/camt) mang dữ liệu có cấu trúc — UETR, remittance information có trường riêng, số tiền và phí tách bạch. Cấu trúc rõ ràng làm tỷ lệ auto-match tăng và break giảm. Đó là lý do camt.053/camt.052 dần thay thế sao kê cũ trong nostro reconciliation (Thanh toán 2 — ISO 20022).

Góc dữ liệu: đối soát là bài toán join kinh điển

Với người làm dữ liệu, đối soát là ví dụ sách giáo khoa của một outer join giữa hai nguồn để tìm phần không khớp:

• INNER JOIN theo khóa khớp → tập MATCHED.
• Dòng nội bộ không có cặp (LEFT anti-join) → break thiếu.
• Dòng sao kê không có cặp (RIGHT anti-join) → break mồ côi.
• Cùng khóa nhưng lệch số tiền → break chênh lệch.

Mọi độ phức tạp của một matching engine thực chất là: chuẩn hóa khóa (dọn reference, chuẩn ngày, quy đổi tiền tệ), định nghĩa tolerance, và xử lý quan hệ nhiều-một (gộp dòng). Chính vì thế đội dữ liệu thường được kéo vào xây dựng và tối ưu logic đối soát. Chủ đề dữ liệu thanh toán được đào sâu ở Thanh toán 8 — Dữ liệu thanh toán.

Use case thực tế: một break nostro — ghi có thiếu một giao dịch

Bối cảnh. Sáng T+2, đội nostro chạy đối soát tài khoản USD tại correspondent. Sổ nội bộ ghi có một khoản 25.000 USD từ khách hàng nước ngoài chuyển về (ngày giá trị T), nhưng camt.053 hôm đó không có dòng ghi có tương ứng. Engine tạo BREAK_MISSING_CREDIT.

Điều tra.

1. Kiểm tra độ trễ trước tiên. Khoản có value date là T nhưng đây là chuyển tiền quốc tế qua một chặng trung gian — rất có thể chỉ là chậm một ngày. Đội đánh dấu break "chờ theo dõi", không vội kết luận thất lạc.
2. Đối chiếu camt.052 trong ngày T+2. Báo cáo trong ngày cho thấy một khoản ghi có 25.000 USD đã về nhưng thiếu reference nội bộ nên engine chưa auto-match được — nó rơi thành một dòng mồ côi tiềm năng, không phải mất tiền.
3. Khớp thủ công. Số tiền, đối tác và ngày trùng khớp; reference bị cắt xén do đi qua một correspondent trung gian dùng bản tin cũ. Đội xác nhận đây chính là khoản đang tìm.
4. Đóng break. Ghép thủ công dòng camt.052 với mục nội bộ, ghi nhận nguyên nhân "reference thất lạc tại chặng trung gian", và bổ sung quy tắc fuzzy (khớp theo amount + counterparty + date khi thiếu reference) để lần sau tự khớp.

Bài học. Đa số break "thiếu" không phải mất tiền mà là lệch thời gian hoặc thiếu dữ liệu để khớp. Quy trình đúng là: loại trừ độ trễ → tìm khoản mồ côi đối ứng → khớp → và nếu là lỗi lặp lại thì sửa luật, chứ không chỉ xử lý một lần. Nếu sau vài ngày vẫn không thấy khoản đối ứng, khi đó mới nâng cấp thành truy vết chính thức (trace) với correspondent qua SWIFT.

Ghi nhớ

• Đối soát = khớp sổ nội bộ với xác nhận bên ngoài để bắt thiếu/thừa/trùng/sai. Tiền đi qua nhiều bên nên các sổ tất yếu lệch nhau tạm thời.
• Bốn trục chính: nostro (vs camt.053 của correspondent), scheme (thẻ/NAPAS), nội bộ (GL vs subledger), và clearing house.
• Netting (bilateral/multilateral) giảm nhu cầu thanh khoản bằng cách settle số ròng, đổi lại phải quản trị rủi ro tích tụ; đối lập là RTGS gross.
• Settlement finality là thời điểm không thể đảo ngược — chỉ khoản đã final mới chắc chắn khi khớp sổ.
• Position keeping theo dõi số dư nostro trong ngày để đủ thanh khoản settle đúng lúc.
• Quy trình: matching (UETR/reference/amount/date, exact & fuzzy) → break → điều tra & hạch toán điều chỉnh → aging để không tồn đọng.
• Tự động hoá dựa vào matching engine + tolerance + STP, và ngày càng dựa vào ISO 20022 vì dữ liệu có cấu trúc làm auto-match tăng.
• Với đội dữ liệu, đối soát chính là join hai nguồn + tìm chênh lệch — một bài toán dữ liệu điển hình.

Bài liên quan: Thanh toán 1 — Tổng quan · Thanh toán 2 — ISO 20022 · Thanh toán 3 — SWIFT & xuyên biên giới · Thanh toán 8 — Dữ liệu thanh toán