Blockchain 6 — Ứng dụng thực tế trong ngân hàng

Năm bài trước dựng nền: từ tổng quan, mật mã & đồng thuận, Bitcoin/Ethereum, smart contract & DeFi, tới blockchain doanh nghiệp & CBDC. Bài này là bài trọng tâm nghiệp vụ: gạt hype sang một bên, xem blockchain thực sự làm được gì trong ngân hàng, và quan trọng hơn — cái gì đã chết, cái gì đang sống.

Nguyên tắc xuyên suốt: với mỗi use case ta hỏi ba câu — (1) vấn đề hiện tại là gì, (2) blockchain giải quyết thế nào, (3) trạng thái thực tế (đã triển khai / mới thí điểm / còn là hype). Ngành ngân hàng đã đốt rất nhiều tiền vào blockchain từ 2016–2020; nhiều consortium đình đám đã đóng cửa. Hiểu vì sao thất bại quan trọng ngang hiểu nó hứa hẹn gì.

1. Thanh toán & chuyển tiền xuyên biên

Vấn đề hiện tại

Chuyển tiền quốc tế chủ yếu chạy qua correspondent banking — mạng ngân hàng đại lý nối nhau bằng SWIFT (xem SWIFT & thanh toán xuyên biên và thanh toán & chuyển tiền). Ba nỗi đau: chậm (qua 2–4 trung gian, khác cut-off/múi giờ → T+1…T+3); đắt (mỗi trung gian ăn phí, phí ẩn trong tỷ giá — chi phí kiều hối TB toàn cầu vẫn ~6%); thiếu minh bạch (không biết tiền ở đâu, phí cuối, khi nào tới).

Gốc rễ: mỗi ngân hàng giữ sổ cái riêng, phải đối soát qua tin nhắn, cộng thêm pre-funding — nạp tiền sẵn vào tài khoản nostro ở nước ngoài (vốn chết).

Blockchain giải quyết thế nào

Ý tưởng: thay chuỗi tin nhắn + nhiều sổ cái bằng một sổ cái chung hoặc tài sản số chuyển thẳng.

• RippleNet / ODL: messaging chuẩn hoá; bản On-Demand Liquidity dùng tài sản trung gian (XRP) để khỏi pre-funding — đổi tiền A→tài sản→tiền B trong vài giây.
• Stablecoin bridge: hai ngân hàng cùng chấp nhận một stablecoin (ví dụ USDC) làm phương tiện chuyển giá trị, settlement gần realtime, 24/7.
• CBDC bắc cầu — mBridge: CBDC bán buôn đa phương (BIS + NHTW Trung Quốc, Hong Kong, Thái Lan, UAE...) cho phép thanh toán xuyên biên trực tiếp giữa các CBDC, bỏ bớt trung gian.

Kết quả kỳ vọng: T+2 → gần realtime, giảm phí, minh bạch trạng thái.

So sánh với hướng "không blockchain"

Điểm tỉnh táo: SWIFT gpi đã cải thiện phần lớn nỗi đau minh bạch/tốc độ mà không cần blockchain — tracking end-to-end, phần lớn lệnh tới trong 24h. Nên giá trị thuần của blockchain bị thu hẹp: thắng rõ nhất ở hành lang thiếu thanh khoản và bỏ pre-funding, còn hành lang lớn thì gpi + thanh toán tức thời nội địa đã đủ tốt.

Trạng thái thực tế: RippleNet có khách thật nhưng quy mô nhỏ so với SWIFT; mBridge đã qua giai đoạn thử nghiệm MVP thật (giao dịch giá trị thật) nhưng chưa vận hành đại trà; stablecoin bridge phổ biến trong crypto/fintech, ngân hàng truyền thống còn thận trọng vì pháp lý. Kết luận: có giá trị thật ở phân khúc hẹp, chưa thay thế SWIFT.

2. Tài trợ thương mại & thư tín dụng (L/C)

Đây là use case blockchain "được yêu thích nhất" — và cũng là nghĩa địa consortium lớn nhất. Nền tảng nghiệp vụ ở tài trợ thương mại.

Vấn đề hiện tại

Tài trợ thương mại vẫn ngập giấy tờ: thư tín dụng (Letter of Credit), vận đơn (Bill of Lading), hoá đơn, chứng nhận xuất xứ... di chuyển vật lý giữa nhà xuất khẩu, nhập khẩu, và hai ngân hàng ở hai nước. Hệ quả:

• Chu kỳ 5–10 ngày chỉ để luân chuyển và kiểm tra bộ chứng từ.
• Gian lận chứng từ trùng (double financing): cùng một lô hàng đem đi vay ở nhiều ngân hàng vì không ai thấy được nhau.
• Kiểm tra chứng từ thủ công, dễ sai lệch (discrepancy) → tranh chấp.

Blockchain giải quyết thế nào

• Số hoá bộ chứng từ: L/C, vận đơn, hoá đơn thành bản ghi số dùng chung; các bên thấy cùng một sự thật.
• Smart contract tự giải ngân: khi điều kiện đạt (ví dụ vận đơn được xác nhận đã bốc hàng), hợp đồng thông minh tự kích hoạt thanh toán/giải ngân, giảm bước thủ công.
• Chống double financing: hàng và chứng từ có "dấu vân tay" trên sổ chung → ngân hàng khác thấy lô hàng đã được tài trợ.

Bài học từ các consortium (rất quan trọng)

Bài học chung — vì sao thất bại:

1. Mạng lưới (network effect): L/C chỉ có giá trị khi cả hai đầu và hãng vận tải cùng lên mạng. Một ngân hàng lên là vô nghĩa nếu đối tác không lên → vòng luẩn quẩn: chưa đủ người dùng → ít giá trị → không ai vào.
2. Thiếu chuẩn hoá: nhiều consortium cạnh tranh, không interoperate → chia nhỏ thị trường.
3. Chi phí vận hành vượt doanh thu: hạ tầng đắt, khối lượng giao dịch thật quá thấp.
4. Sổ off-chain vẫn là gốc: hàng vật lý, hải quan, luật nằm ngoài chuỗi → không loại bỏ được kiểm tra ngoài đời (oracle problem).

Trạng thái thực tế: phần lớn hype 2018–2021 đã xẹp. Cái sống sót nghiêng về số hoá chứng từ có luật đỡ lưng — như khung MLETR (Model Law on Electronic Transferable Records) và các nền tảng eBL (electronic Bill of Lading) được cho phép pháp lý — chứ không nhất thiết phải là blockchain "thuần". Bài học: công nghệ không thua vì kém; thua vì thiếu mạng lưới và chuẩn.

3. KYC / định danh chia sẻ

Vấn đề hiện tại

Mỗi ngân hàng tự làm KYC (Know Your Customer) từ đầu cho mỗi khách. Một khách mở tài khoản ở 5 ngân hàng → nộp giấy tờ 5 lần, mỗi ngân hàng tốn công thẩm định lặp lại. Chi phí KYC/AML toàn ngành khổng lồ (xem tổng quan AML).

Blockchain giải quyết thế nào

• KYC dùng chung: kết quả thẩm định của một ngân hàng được chia sẻ (có sự đồng ý của khách) qua sổ chung → ngân hàng khác tái sử dụng, giảm lặp.
• SSI / DID (Self-Sovereign Identity / Decentralized Identifier): khách tự nắm danh tính số và các "chứng nhận có thể kiểm chứng" (verifiable credential), chủ động cấp/thu hồi quyền xem cho từng ngân hàng — thay vì để dữ liệu nằm rải rác.

Trên chuỗi thường không lưu dữ liệu KYC gốc (vi phạm quyền riêng tư/GDPR), mà chỉ lưu hash/bằng chứng đã thẩm định; dữ liệu thật nằm off-chain.

Trạng thái thực tế: nhiều thí điểm (Singapore, khu vực Nordic...) nhưng vướng trách nhiệm pháp lý (ngân hàng B có dám tin KYC của ngân hàng A và chịu phạt nếu sai không?) và chuẩn danh tính. SSI/DID đang lên nhưng chậm. Chủ yếu vẫn là thí điểm.

4. Đối soát & thanh toán bù trừ liên ngân hàng

Vấn đề hiện tại

Vì mỗi ngân hàng giữ sổ riêng, cuối ngày phải đối soát (reconciliation) khối lượng lớn: khớp từng giao dịch, xử lý lệch (break), điều tra chênh. Cả một đội vận hành sống bằng việc này (liên quan đối soát thanh toán ở chặng xuyên biên).

Blockchain giải quyết thế nào

Nếu các bên cùng ghi lên một sổ cái chung (shared ledger) thì "sự thật" chỉ có một bản — về lý thuyết reconciliation gần như biến mất vì không còn hai bản sổ để so. Đây là lời hứa hấp dẫn nhất về mặt vận hành nội bộ.

Trạng thái thực tế: hợp lý nhất trong mạng nhỏ, có kiểm soát — ví dụ bù trừ trong một tập đoàn, hoặc thanh toán bán buôn giữa nhóm ngân hàng đã định danh (permissioned DLT). Ở quy mô toàn hệ thống, việc thay hạ tầng RTGS/ACH hiện có là cực khó và rủi ro cao → phần lớn dừng ở PoC. Giá trị thật nhưng khu trú.

5. Chứng khoán hoá & tokenization tài sản

Đây là mảng đang nóng thật năm 2024–2025, khác với hype rỗng trước đó.

Vấn đề hiện tại

Thanh toán chứng khoán truyền thống T+1/T+2 (settlement chậm), nhiều trung gian (CSD, custodian, clearing), vốn bị "kẹt" trong thời gian chờ, và nhiều lớp đối soát.

Blockchain giải quyết thế nào

• Trái phiếu on-chain: phát hành token hoá → giảm trung gian, tự động hoá coupon.
• Quỹ token hoá: tiêu biểu là BlackRock BUIDL (quỹ thị trường tiền tệ token hoá trên Ethereum, ra mắt 2024) — chia lãi hằng ngày, chuyển nhượng 24/7, quy mô hàng tỷ USD → nhu cầu thật từ tổ chức.
• DvP T+0: Delivery versus Payment — giao chứng khoán đồng thời với trả tiền trên cùng sổ (atomic settlement), loại rủi ro đối tác trong khoảng chờ, rút settlement về T+0.

Trạng thái thực tế: use case có động lực thật — tổ chức lớn (BlackRock, JPMorgan Onyx, các CSD) triển khai có doanh thu. Vẫn vướng pháp lý "token có giá trị như chứng khoán truyền thống không" ở nhiều nước. Ít hype nhất, thực chất nhất hiện nay.

6. Bảo lãnh ngân hàng số (bank guarantee)

Vấn đề: bảo lãnh (guarantee) truyền thống là văn bản giấy, xác thực chậm, dễ làm giả; bên thụ hưởng khó kiểm chứng thư bảo lãnh có thật không.

Blockchain giải quyết: phát hành bảo lãnh dưới dạng bản ghi số trên sổ chung — bên thụ hưởng kiểm chứng tức thì tính xác thực và trạng thái, giảm gian lận thư giả.

Trạng thái thực tế: đã có triển khai thành công cấp quốc gia hẹp — ví dụ mạng bảo lãnh ngân hàng số ở Úc (Lygon) từng vận hành thật với nhóm ngân hàng lớn. Nhỏ về phạm vi nhưng chứng minh mô hình chạy được khi mạng lưới đủ chặt. Có thật, quy mô hẹp.

Sơ đồ: luồng L/C trên blockchain

7. Góc dữ liệu: data team làm gì?

Blockchain trong ngân hàng sinh ra loại dữ liệu mới cần team dữ liệu xử lý (đào sâu ở phân tích dữ liệu on-chain):

• Tích hợp node/API: kết nối tới node của mạng permissioned (Fabric/Corda) hoặc API của mạng (RippleNet, mBridge) để kéo sự kiện giao dịch vào kho dữ liệu, giống như tích hợp một core mới.
• Đối soát on-chain vs core: dữ liệu on-chain phải khớp với core banking / GL nội bộ. Data team dựng pipeline so sổ chung với sổ nội bộ, phát hiện lệch — mỉa mai là blockchain hứa "hết reconciliation" nhưng lại tạo ra một tầng đối soát mới giữa on-chain và off-chain.
• Phân tích & giám sát: theo dõi thời gian settlement, tỷ lệ giao dịch tự động hoá, phát hiện bất thường; cấp dữ liệu cho AML/giám sát giao dịch.

Về nguyên tắc dữ liệu, kho on-chain thường được ETL vào PostgreSQL / warehouse để phân tích quen thuộc. Ví dụ minh hoạ (dữ liệu mô phỏng đã ETL về bảng nội bộ) — đo tỷ trọng giao dịch xuyên biên theo tiền tệ để chọn hành lang nên thí điểm DLT:

-- ▶ Chạy được
SELECT a.currency,
       COUNT(*)                        AS so_giao_dich,
       ROUND(SUM(t.amount)::numeric, 2) AS tong_gia_tri,
       ROUND(AVG(t.amount)::numeric, 2) AS gia_tri_tb
FROM transactions t
JOIN accounts a ON a.id = t.account_id
WHERE t.kind = 'transfer'
GROUP BY a.currency
ORDER BY tong_gia_tri DESC;

Câu này chạy trên sandbox PostgreSQL để minh hoạ tư duy phân tích trước khi chọn mạng DLT — không phải truy vấn trực tiếp lên blockchain (blockchain không nói SQL; luồng thực là node → ETL → warehouse).

8. Đánh giá tỉnh táo: giá trị thật vs hype

Xếp các use case theo mức độ thực chất (đánh giá của tác giả, giữa 2025):

Vì sao nhiều consortium thất bại — gói thành nguyên tắc:

1. Cần mạng lưới đủ lớn: blockchain là công nghệ nhiều bên, một mình vô dụng. Không đủ người → không có giá trị → không ai tham gia.
2. Cần chuẩn hoá & interoperability: nhiều consortium cạnh tranh, không nói chuyện được → chia nhỏ thị trường.
3. Phải giải bài toán ngoài chuỗi: hàng vật lý, hải quan, luật, danh tính pháp lý (oracle problem).
4. Đối thủ "boring" mạnh hơn: gpi, RTGS tức thời, API chuẩn hoá thường giải nỗi đau rẻ và ít rủi ro hơn.

Nguyên tắc chọn: blockchain thắng khi có nhiều bên không tin nhau, cần một sự thật chung, và không có bên trung tâm đáng tin sẵn. Nếu đã có bên trung tâm đáng tin (CSD, NHTW, một hệ RTGS), một database chung thường rẻ và tốt hơn.

Bối cảnh NCB

Với ngân hàng cỡ vừa như NCB, khuyến nghị thực dụng:

• Không đầu tư hạ tầng DLT lõi từ đầu — rủi ro/chi phí cao, mạng lưới chưa chín. Theo dõi và tham gia mạng có sẵn nếu NHNN hoặc consortium khu vực dẫn dắt (nhất là CBDC bán buôn/thanh toán).
• Ưu tiên use case đã thực chất: nếu tham gia, chọn thanh toán xuyên biên qua mạng có sẵn hoặc tokenization khi pháp lý Việt Nam rõ hơn — thay vì tự dựng consortium trade finance (rủi ro chết như we.trade).
• Chuẩn bị năng lực dữ liệu trước: tập dượt tích hợp node/API và đối soát on-chain ↔ core trên môi trường thử, để khi phải tham gia (ví dụ CBDC) thì đã sẵn sàng.
• Quản trị rủi ro/tuân thủ song hành: mọi thí điểm gắn với AML, bảo mật khoá, riêng tư dữ liệu (xem bài rủi ro & pháp lý — bc-08 trong series).

Use case thực tế

Bối cảnh: NCB nhận đề nghị tham gia thí điểm thanh toán xuyên biên qua DLT cho hành lang Việt Nam–một nước ASEAN, do một mạng khu vực dẫn dắt. Team dữ liệu đánh giá có nên tham gia và chuẩn bị gì.

Các bước:

1. Định lượng nỗi đau hiện tại: kéo dữ liệu chuyển tiền xuyên biên 12 tháng — khối lượng theo hành lang/tiền tệ (kiểu truy vấn ở mục 7), settlement TB (từ log gpi), phí. Giả sử: hành lang mục tiêu ~4.200 lệnh/năm, settlement TB ~1,8 ngày, phí ~5,5%.
2. Ước lượng lợi ích DLT: nếu settlement về ~vài phút và bỏ pre-funding nostro (~2 triệu USD vốn chết) → tiết kiệm chi phí vốn + phí. Cân với chi phí tích hợp node + vận hành.
3. PoC dữ liệu: pipeline đối soát on-chain vs core trên sandbox — mục tiêu khớp ≥ 99,9%, phát hiện lệch trong ngày.
4. Đánh giá network effect: bao nhiêu đối tác thật ở đầu bên kia đã lên mạng. Nếu dưới ngưỡng khối lượng → khuyến nghị chờ.
5. Quyết định: tham gia mức "quan sát + PoC dữ liệu", chưa cam kết hạ tầng — tránh vết xe đổ của consortium chết vì thiếu mạng lưới.

Kết quả: NCB có số liệu để quyết định dựa trên giá trị thật, team dữ liệu sẵn năng lực đối soát on-chain khi mở rộng.

Ghi nhớ

• Với mỗi use case luôn hỏi: vấn đề hiện tại → blockchain giải thế nào → trạng thái thực (triển khai/thí điểm/hype).
• Xuyên biên: DLT/stablecoin/mBridge giảm T+2 → gần realtime và bỏ pre-funding, nhưng SWIFT gpi đã lấy mất phần lớn giá trị "minh bạch/tốc độ" mà không cần blockchain.
• Trade finance/L/C: use case được kỳ vọng nhất nhưng là nghĩa địa consortium — we.trade, Marco Polo, TradeLens đã đóng cửa (~2022–2023). Thua vì network effect và thiếu chuẩn, không phải vì công nghệ kém.
• KYC chia sẻ & đối soát liên ngân hàng: hợp lý về lý thuyết, nhưng vướng trách nhiệm pháp lý và khó ở quy mô lớn → chủ yếu thí điểm/PoC.
• Tokenization (BlackRock BUIDL, trái phiếu on-chain, DvP T+0) là mảng thực chất nhất hiện nay — có tổ chức lớn triển khai có doanh thu.
• Bảo lãnh số đã có vận hành thật quy mô hẹp (Lygon) — chứng minh mô hình chạy khi mạng lưới đủ chặt.
• Góc dữ liệu: tích hợp node/API, đối soát on-chain ↔ core (blockchain tạo tầng reconciliation mới), phân tích settlement/bất thường; thường ETL on-chain → warehouse để phân tích.
• Nguyên tắc chọn: blockchain chỉ thắng khi nhiều bên không tin nhau + cần một sự thật chung + không có bên trung tâm đáng tin sẵn. Có bên trung tâm đáng tin → database chung thường rẻ/tốt hơn.
• Bối cảnh NCB: không tự dựng hạ tầng lõi; theo dõi, tham gia mạng có sẵn (nhất là CBDC/thanh toán), ưu tiên use case đã thực chất, và chuẩn bị năng lực dữ liệu trước.