Open Banking & Open Finance: ngân hàng mở, vì sao là xu hướng

Trong hơn một thập kỷ, dữ liệu tài khoản ngân hàng bị "nhốt" trong hệ thống lõi của từng nhà băng. Muốn tổng hợp chi tiêu trên 3 ngân hàng, khách phải tự xuất sao kê PDF; muốn một app fintech đọc số dư, cách duy nhất là đưa username/password cho app đó "đăng nhập hộ" (screen scraping) — cực kỳ rủi ro. Open Banking ra đời để thay thế mô hình đó bằng một cơ chế chuẩn hóa, an toàn và có kiểm soát.

Open Banking là gì

Open Banking là mô hình trong đó ngân hàng mở dữ liệu và dịch vụ của mình ra bên ngoài thông qua API an toàn, và chỉ mở khi có sự đồng ý (consent) rõ ràng của khách hàng, để bên thứ ba — thường gọi là TPP (Third-Party Provider), phần lớn là fintech — xây dựng dịch vụ trên đó.

Ba đặc trưng không thể thiếu:

• API thay cho scraping: bên thứ ba gọi API chuẩn (REST/JSON, OAuth2) thay vì "đăng nhập hộ" bằng mật khẩu của khách. Khách không bao giờ phải giao mật khẩu ngân hàng cho fintech.
• Consent là trung tâm: khách chủ động cấp quyền, phạm vi hẹp (chỉ đọc số dư? chỉ 90 ngày giao dịch?), có thời hạn, và thu hồi được bất cứ lúc nào.
• Khách sở hữu dữ liệu của mình: triết lý nền tảng là dữ liệu tài chính thuộc về khách hàng, ngân hàng chỉ là nơi giữ hộ; khách có quyền yêu cầu chia sẻ nó cho bên mình tin tưởng.

Điểm mấu chốt để phân biệt với "ngân hàng số" thông thường: Open Banking không phải là ngân hàng làm app đẹp hơn, mà là ngân hàng cho phép người khác xây dịch vụ trên dữ liệu/dịch vụ của mình.

Phổ mở rộng: Open Banking → Open Finance → Open Data

Open Banking chỉ là bước đầu. Phạm vi "mở" ngày càng rộng theo một phổ:

• Open Banking: giới hạn ở tài khoản thanh toán (payment account) — số dư, lịch sử giao dịch, và khả năng khởi tạo lệnh thanh toán.
• Open Finance: mở rộng ra toàn bộ sản phẩm tài chính — tài khoản tiết kiệm, khoản vay và lịch sử trả nợ, thẻ tín dụng, danh mục đầu tư, hợp đồng bảo hiểm, quỹ hưu trí. Nhờ đó fintech có thể tư vấn tài chính cá nhân toàn diện chứ không chỉ nhìn dòng tiền.
• Open Data: mở ra cả ngoài ngành tài chính — dữ liệu viễn thông, hóa đơn điện nước, y tế, dịch vụ công. Đây là tầm nhìn dài hạn của "nền kinh tế dữ liệu".

Series này tập trung chủ yếu ở tầng Open Banking và Open Finance, vì đó là nơi ngân hàng như NCB đang và sẽ phải hành động.

Vì sao Open Banking là xu hướng

Ba động lực chính:

1. Cạnh tranh và đổi mới: cơ quan quản lý muốn phá thế độc quyền dữ liệu của các ngân hàng lớn, tạo sân chơi cho fintech nhỏ đổi mới. Đây là lý do PSD2 ở EU ra đời — mang tính bắt buộc, không phải tự nguyện.
2. Trao quyền cho khách hàng: khách được kiểm soát dữ liệu của mình, dễ dàng so sánh, chuyển đổi nhà cung cấp, dùng dịch vụ tổng hợp đa ngân hàng.
3. Chuyển từ "ngân hàng đóng" sang nền tảng/hệ sinh thái: mô hình kinh doanh chuyển dịch. Thay vì là một ống dẫn khép kín (pipe), ngân hàng trở thành nền tảng (platform) để bên khác cắm dịch vụ vào — mở đường cho BaaS (Banking-as-a-Service) và embedded finance (nhúng dịch vụ tài chính vào app phi ngân hàng, ví dụ mua trả góp ngay trong app thương mại điện tử).

Sự dịch chuyển này liên quan trực tiếp tới hạ tầng thanh toán mà bạn đã thấy ở Thanh toán & Chuyển tiền: Open Banking chuẩn hóa cách bên thứ ba khởi tạo các lệnh chuyển tiền đó qua API.

Bối cảnh quốc tế

Open Banking không có một chuẩn toàn cầu duy nhất; mỗi thị trường có khung riêng. Nắm được bức tranh này giúp tránh nhầm lẫn khi làm việc với đối tác quốc tế.

Lưu ý quan trọng về mặt chính xác: các khung trên khác nhau về chi tiết điều khoản, phạm vi và lộ trình. Bài này nêu ở mức khung/xu hướng; khi triển khai thực tế cần đọc trực tiếp văn bản gốc phiên bản mới nhất, tránh trích dẫn điều khoản theo trí nhớ.

Việt Nam

Tại Việt Nam, hướng đi mang tính xu hướng và khung định hướng hơn là một luật Open Banking bắt buộc kiểu PSD2:

• Ngân hàng Nhà nước (NHNN) thúc đẩy chuẩn Open API cho ngành ngân hàng, khuyến khích kết nối - chia sẻ dữ liệu có kiểm soát giữa ngân hàng và fintech.
• Hạ tầng thanh toán quốc gia do NAPAS vận hành đóng vai trò xương sống cho kết nối liên ngân hàng và các dịch vụ như chuyển nhanh 24/7, QR chuẩn.
• Xu hướng chung là chia sẻ dữ liệu có kiểm soát, gắn với khung pháp lý về bảo vệ dữ liệu cá nhân — xem thêm Quyền riêng tư & tuân thủ.

Nói ngắn gọn: Việt Nam đang ở giai đoạn hình thành khung và hạ tầng; ngân hàng nào chủ động chuẩn hóa Open API sớm sẽ có lợi thế đối tác. Tránh khẳng định các điều khoản/nghĩa vụ pháp lý cụ thể chưa được ban hành chính thức.

Các vai trò trong hệ sinh thái

Đây là bộ thuật ngữ cốt lõi (theo cách gọi của PSD2, đã trở thành ngôn ngữ chung toàn ngành):

• ASPSP (Account Servicing Payment Service Provider) — ngân hàng giữ tài khoản của khách, bên "mở" API. NCB đóng vai trò này.
• TPP (Third-Party Provider) — bên thứ ba được cấp phép tiêu thụ API. Chia hai loại chính:
  • AISP (Account Information Service Provider) — dịch vụ tổng hợp thông tin tài khoản: đọc số dư, giao dịch để phân tích chi tiêu, chấm điểm, tư vấn. Đào sâu ở Account Aggregation.
  • PISP (Payment Initiation Service Provider) — dịch vụ khởi tạo thanh toán thay khách (ví dụ thanh toán trực tiếp từ tài khoản, không qua thẻ). Đào sâu ở Payment Initiation.

Một fintech có thể vừa là AISP vừa là PISP. Điểm chung: cả hai đều chỉ hành động trong phạm vi consent khách đã cấp.

Điểm cần khắc: mật khẩu ngân hàng của khách không bao giờ chạm tới fintech. Xác thực diễn ra tại ngân hàng, fintech chỉ nhận token giới hạn quyền.

Bốn trụ cột — định hướng series

Cả series được tổ chức quanh bốn trụ cột, mỗi trụ cột là một bài chuyên sâu:

• API & chuẩn — REST, OAuth2/OIDC, các chuẩn dữ liệu, sandbox, versioning: APIs & Standards.
• Consent & bảo mật — vòng đời consent, SCA, mTLS, chống lạm dụng token: Consent & Security. Liên quan trực tiếp tới kiểm soát truy cập và mã hóa trong Access & Crypto.
• Chia sẻ dữ liệu & quyền riêng tư — data minimization, mục đích sử dụng, tuân thủ bảo vệ dữ liệu cá nhân: Data Sharing & Privacy.
• Hệ sinh thái & BaaS — mô hình kinh doanh nền tảng, marketplace, embedded finance: Ecosystem & Fintech.

Và bài phân tích dữ liệu ứng dụng trong ngân hàng mở: Data & Analytics, kết nối tới các chỉ số vận hành ở Metrics & KPI.

Cơ hội và rủi ro cho ngân hàng

Open Banking là con dao hai lưỡi. Ngân hàng cần nhìn thẳng cả hai phía:

Chiến lược khôn ngoan: không chống lại xu hướng, mà biến API thành sản phẩm — chủ động là ASPSP có chất lượng dịch vụ tốt, đồng thời khai thác vai trò AISP để không bị mù dữ liệu. Rủi ro gian lận ở đây gắn với các chủ đề AML và chấm điểm rủi ro Scorecard.

Ví dụ luồng dữ liệu (minh họa)

Hình dung một app quản lý chi tiêu cá nhân xin đọc giao dịch của khách qua API ngân hàng. Sau khi khách đã cấp consent và app có token, app gọi endpoint dạng:

GET /open-banking/v1/accounts/{accountId}/transactions?fromDate=2026-04-01&toDate=2026-06-30
Authorization: Bearer <access_token_giới_hạn_phạm_vi>

Ngân hàng chỉ trả về đúng phạm vi mà consent cho phép (ví dụ 90 ngày giao dịch, chỉ-đọc). Đây là ví dụ minh họa endpoint chung theo phong cách OBIE, không phải API thật của một ngân hàng cụ thể.

Về phía nội bộ ngân hàng, phía sau API là dữ liệu tài khoản/giao dịch. Một truy vấn thống kê nội bộ đơn giản để hình dung bức tranh giao dịch theo loại tiền tệ trên nền dữ liệu sandbox:

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

Truy vấn trên chỉ minh họa cách dữ liệu giao dịch được tổng hợp; API Open Banking chỉ là "cửa" có kiểm soát consent đứng trước lớp dữ liệu này.

Use case thực tế

Bối cảnh. NCB muốn mở Open API cho một đối tác fintech vận hành app quản lý chi tiêu ("MoneyView" — tên minh họa) để khách NCB có thể tổng hợp và phân loại chi tiêu tự động. NCB đóng vai ASPSP; MoneyView là AISP.

Mục tiêu. Giữ khách trong hệ sinh thái NCB, tạo dữ liệu hành vi hữu ích cho tư vấn sản phẩm, và mở nguồn thu phí API — thay vì để fintech scraping mật khẩu (rủi ro và không kiểm soát được).

Các bước triển khai đề xuất:

1. Cổng API & sandbox. Dựng API Gateway đặt trước core banking, phát hành sandbox có dữ liệu giả để MoneyView tích hợp thử trước khi lên production (chi tiết ở APIs & Standards).
2. Cấp phép & onboarding TPP. Ký hợp đồng, cấp client_id/client_secret, thiết lập mTLS và whitelist. Đối tác phải đạt yêu cầu bảo mật tối thiểu.
3. Consent flow. Khách NCB được chuyển hướng về app/web NCB để đăng nhập, xác thực mạnh (OTP/sinh trắc), rồi chọn phạm vi (đọc giao dịch 90 ngày, chỉ-đọc) và thời hạn (ví dụ 90 ngày, tự hết hạn). Chi tiết ở Consent & Security.
4. Data minimization. API chỉ trả trường cần thiết cho phân loại chi tiêu; không lộ dữ liệu định danh dư thừa. Gắn với Data Sharing & Privacy.
5. Giám sát & thu hồi. Ghi log mọi lượt gọi, giới hạn tần suất (rate limit), cho khách xem và thu hồi consent trong app NCB bất cứ lúc nào.

Số liệu ước lượng (minh họa, không phải cam kết):

• Nếu 3% trong ~2 triệu khách cá nhân bật kết nối → khoảng 60.000 consent hoạt động năm đầu.
• Với rate limit ví dụ 4 lần đồng bộ/khách/ngày → khoảng 240.000 lượt gọi API/ngày; hạ tầng cần thiết kế cho đỉnh gấp 3–4 lần.
• Chỉ số theo dõi: tỷ lệ consent thành công (mục tiêu > 85%), độ trễ API p95 (< 800 ms), tỷ lệ lỗi (< 0,5%), số consent bị thu hồi/tháng.

Giá trị thu về. NCB "nhìn" được hành vi chi tiêu tổng hợp (khách đồng ý) để gợi ý sản phẩm đúng thời điểm, giảm rủi ro scraping, và đặt nền móng chuyển sang vai trò AISP trong tương lai — đọc dữ liệu từ ngân hàng khác để phục vụ chính khách của mình.

Ghi nhớ

• Open Banking = ngân hàng mở dữ liệu/dịch vụ qua API an toàn, có consent của khách, cho bên thứ ba (TPP) — thay thế screen scraping bằng token, mật khẩu khách không bao giờ tới fintech.
• Phổ mở rộng: Open Banking (tài khoản thanh toán) → Open Finance (tiết kiệm, vay, đầu tư, bảo hiểm) → Open Data (ngoài tài chính).
• Ba động lực: cạnh tranh/đổi mới, khách kiểm soát dữ liệu, chuyển từ "ngân hàng đóng" sang nền tảng/hệ sinh thái (BaaS, embedded finance).
• Vai trò: ASPSP (ngân hàng giữ tài khoản) và TPP = AISP (tổng hợp thông tin) + PISP (khởi tạo thanh toán).
• Bối cảnh: PSD2/PSD3 (EU), UK OBIE, Úc CDR — mỗi thị trường một khung; Việt Nam ở mức Open API do NHNN thúc đẩy + hạ tầng NAPAS, chia sẻ dữ liệu có kiểm soát. Tránh trích điều khoản chưa chắc chắn.
• Với ngân hàng: cơ hội (doanh thu API, dữ liệu, đổi mới) đi kèm rủi ro (mất kênh trực tiếp, bề mặt tấn công, gánh nặng tuân thủ) — chiến lược là chủ động biến API thành sản phẩm.
• Bốn trụ cột của series: API & chuẩn, consent & bảo mật, chia sẻ dữ liệu & quyền riêng tư, hệ sinh thái/BaaS.

Nguồn tham khảo

• Directive (EU) 2015/2366 (PSD2) — Payment Services Directive 2, văn bản gốc trên EUR-Lex (eur-lex.europa.eu)
• UK Open Banking — Open Banking Standard (Open Banking Implementation Entity / OBIE) (openbanking.org.uk)
• Berlin Group — NextGenPSD2 XS2A Framework (chuẩn API PSD2 phổ biến tại châu Âu) (berlin-group.org)
• Consumer Data Right (CDR) — Australian Government, khung quyền dữ liệu người tiêu dùng (cdr.gov.au)
• EBA — Regulatory Technical Standards on Strong Customer Authentication and secure communication (SCA-RTS) under PSD2, European Banking Authority
• Ngân hàng Nhà nước Việt Nam (NHNN) — định hướng chuẩn Open API cho ngành ngân hàng (sbv.gov.vn)