Open Banking 6 — Chia sẻ dữ liệu & Quyền riêng tư

Chia sẻ dữ liệu: cơ hội và nghĩa vụ đi cùng nhau

Trong tổng quan Open Banking ta đã thấy toàn bộ mô hình đứng trên một nền tảng: dữ liệu tài khoản của khách hàng — vốn nằm khoá kín trong ngân hàng — nay được chia sẻ có kiểm soát cho bên thứ ba để tạo dịch vụ mới. Đây vừa là động lực đổi mới, vừa là nguồn rủi ro lớn nhất. Bài Account Aggregation mô tả cái gì được chia sẻ; bài Consent & bảo mật mô tả cơ chế consent và xác thực. Bài này ghép hai mảnh đó lại dưới góc nhìn dữ liệu và quyền riêng tư: chia sẻ thế nào cho đúng luật, đúng phạm vi, và giữ được niềm tin của khách hàng — thứ tài sản khó xây, dễ mất.

Nguyên tắc nền tảng cần khắc cốt: khách hàng sở hữu và kiểm soát dữ liệu của mình. Ngân hàng chỉ là bên giữ hộ và xử lý. Open Banking hợp thức hoá quyền này bằng khái niệm data portability (khả năng mang dữ liệu đi) — khách có quyền yêu cầu ngân hàng chia sẻ dữ liệu của họ sang một nhà cung cấp khác. Nhưng "quyền mang đi" không phải "chia sẻ vô tội vạ": mọi luồng dữ liệu phải bị ràng buộc bởi năm cột trụ dưới đây.

Năm nguyên tắc chia sẻ dữ liệu có kiểm soát

Purpose limitation (giới hạn mục đích) dễ bị vi phạm mà lại khó phát hiện. Khách đồng ý chia sẻ lịch sử giao dịch để app quản lý chi tiêu phân loại khoản chi — đó là mục đích. Nếu app đem chính dữ liệu ấy đi chấm điểm tín dụng rồi bán cho công ty tài chính, đó là dùng sai mục đích, kể cả khi khách "đã đồng ý chia sẻ dữ liệu". Đồng ý cho việc A không phải đồng ý cho việc B.

Data minimization (tối thiểu hoá dữ liệu) là hàng rào phòng thủ rẻ và hiệu quả nhất. App cho vay cần biết thu nhập có ổn định không — không cần biết khách mua gì ở đâu từng đồng. Nếu bên chia sẻ chỉ trả về tổng thu nhập tháng và độ đều đặn dòng tiền vào thay vì toàn bộ transaction line, thì kể cả khi TPP bị hack, thiệt hại nhỏ hơn nhiều: ít dữ liệu ra ngoài = ít bề mặt tấn công.

Quyền riêng tư và khung pháp lý

Chia sẻ dữ liệu cá nhân không phải chuyện kỹ thuật thuần tuý — nó bị chi phối bởi pháp luật bảo vệ dữ liệu cá nhân. Người làm dữ liệu ngân hàng cần nắm khung, không cần thuộc lòng điều khoản.

Việt Nam: Nghị định 13/2023/NĐ-CP

Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân là văn bản pháp lý nền tảng hiện hành ở Việt Nam về chủ đề này. Ở mức khung, Nghị định đặt ra một số nhóm yêu cầu mà bất kỳ hoạt động chia sẻ dữ liệu nào cũng phải soi chiếu:

• Yêu cầu về sự đồng ý (consent): việc xử lý dữ liệu cá nhân về nguyên tắc cần có sự đồng ý của chủ thể dữ liệu, và sự đồng ý phải thể hiện rõ ràng, cụ thể về mục đích.
• Quyền của chủ thể dữ liệu: chủ thể dữ liệu có các quyền như được biết, được truy cập, rút lại đồng ý, xoá, hạn chế xử lý, phản đối xử lý dữ liệu của mình.
• Trách nhiệm của bên xử lý: các bên tham gia (bên kiểm soát, bên xử lý dữ liệu cá nhân) có nghĩa vụ bảo vệ dữ liệu, áp dụng biện pháp kỹ thuật và tổ chức phù hợp, và trách nhiệm liên quan đến các thủ tục như đánh giá tác động xử lý dữ liệu cá nhân.

Lưu ý: phần trên chỉ nêu tinh thần khung của Nghị định. Các mốc thời gian, ngưỡng, mẫu hồ sơ và điều khoản chi tiết phải tra cứu trực tiếp văn bản gốc và hỏi pháp chế — bài viết này không trích dẫn số điều/khoản cụ thể để tránh dẫn sai. Chi tiết tuân thủ xem Privacy & Compliance.

Quốc tế: GDPR để tham chiếu

GDPR (General Data Protection Regulation — Quy định bảo vệ dữ liệu chung của EU) là chuẩn tham chiếu phổ biến nhất thế giới; nhiều khái niệm của Nghị định 13 có tinh thần tương đồng: cơ sở pháp lý để xử lý (lawful basis), giới hạn mục đích, tối thiểu hoá, quyền được xoá (right to erasure), quyền mang dữ liệu đi. Với ngân hàng có yếu tố xuyên biên giới, GDPR là nghĩa vụ trực tiếp. Điểm cần nhớ: hãy thiết kế theo chuẩn cao hơn — vừa dễ mở rộng ra quốc tế, vừa an toàn pháp lý trong nước.

Kỹ thuật bảo vệ dữ liệu khi chia sẻ

Nguyên tắc pháp lý phải được cài đặt bằng biện pháp kỹ thuật cụ thể, nếu không chỉ là khẩu hiệu. Năm lớp bảo vệ:

1. Tối thiểu hoá tại nguồn (minimization at source). Endpoint chia sẻ phải lọc theo scope trước khi dữ liệu rời khỏi ngân hàng. Đừng trả cả object rồi để TPP "tự bỏ trường thừa" — trường đã ra ngoài là đã rủi ro. Thiết kế response theo scope: scope balance chỉ trả số dư, scope transactions:90d chỉ trả 90 ngày gần nhất.

2. Ẩn danh hoá và giả danh hoá. Khi mục đích cho phép, thay dữ liệu định danh trực tiếp bằng dạng ít nhận diện hơn:

• Anonymization (ẩn danh hoá): loại bỏ khả năng truy ngược về cá nhân một cách không thể đảo ngược — dùng cho phân tích tổng hợp, báo cáo. Dữ liệu đã ẩn danh thực sự thường nằm ngoài phạm vi "dữ liệu cá nhân".
• Pseudonymization (giả danh hoá): thay định danh thật bằng bí danh (token) qua bảng ánh xạ giữ riêng — vẫn truy ngược được nếu có khoá, nên vẫn là dữ liệu cá nhân, nhưng giảm rủi ro nếu rò rỉ.

Ẩn danh/giả danh hoá và tối thiểu dữ liệu là kỹ thuật nền khi chia sẻ — xem thêm Quyền riêng tư & tuân thủ.

3. Mã hoá khi truyền và khi lưu. TLS cho dữ liệu on-transit là bắt buộc; nhiều chuẩn yêu cầu thêm mTLS và ký message ở tầng ứng dụng. Dữ liệu at-rest (token store, consent store, log) phải mã hoá. Quản lý khoá, xoay khoá, HSM — xem Access & Cryptography.

4. Kiểm soát truy cập theo scope. Mỗi access token gắn với đúng scope của consent. Ở mọi endpoint, kiểm tra: token còn hiệu lực? scope có bao gồm tài nguyên đang xin? consent còn hiệu lực chưa bị thu hồi? Không có "quyền mặc định".

5. Không lưu quá mức ở TPP. Điểm yếu ngoài tầm kiểm soát trực tiếp của ngân hàng, nhưng ràng buộc được bằng hợp đồng và giám sát: TPP không được lưu quá thời hạn/mục đích, phải xoá khi consent hết hạn, phải chịu kiểm toán. Nên giả định TPP sẽ có ngày bị tấn công và thiết kế sao cho thiệt hại bị chặn (minimization là bạn thân ở đây).

Quản trị consent như một loại dữ liệu

Điểm mấu chốt mà nhiều team bỏ sót: consent bản thân nó là một loại dữ liệu quan trọng cần quản trị, không phải một cờ boolean cho/không. Mỗi consent cần được lưu như một bản ghi đầy đủ chiều thông tin — thường gọi là consent ledger (sổ cái consent) hoặc consent store:

• Ai — chủ thể dữ liệu (khách hàng) nào, TPP nào.
• Cái gì — scope: những loại dữ liệu và tài khoản nào được phép.
• Khi nào — thời điểm cấp, thời điểm hết hạn, thời điểm thu hồi.
• Mục đích — purpose khai báo khi xin consent (để kiểm tra purpose limitation).
• Trạng thái — active / expired / revoked, kèm lịch sử thay đổi.

Consent ledger phải append-only (chỉ ghi thêm, không sửa/xoá bản ghi cũ) để giữ lịch sử phục vụ audit. Khi khách thu hồi, ta ghi thêm sự kiện revoke chứ không xoá bản ghi cấp trước — vì sau này cần chứng minh "tại thời điểm T, TPP X có quyền truy cập dữ liệu Y theo mục đích Z". Mọi lần TPP truy cập cũng để lại audit log: request nào, consent nào, trả về gì — yêu cầu cả về tuân thủ lẫn điều tra sự cố.

Dưới đây là bản ghi consent minh hoạ (không phải schema sandbox, chỉ mô tả các trường cần có):

// MINH HOẠ — bản ghi trong consent ledger
{
  "consent_id": "CNS-2026-0007321",
  "customer_id": "CUST-88213",
  "tpp_id": "TPP-PFM-VN-014",
  "scopes": ["accounts:read", "balances:read", "transactions:90d"],
  "purpose": "personal_finance_management",
  "status": "active",
  "granted_at": "2026-05-01T09:12:00+07:00",
  "expires_at": "2026-11-01T09:12:00+07:00",
  "revoked_at": null,
  "sca_ref": "AUTH-2026-33125"
}

Chính sách scope/purpose đi kèm — ánh xạ mỗi purpose tới tập scope tối đa được phép — cũng là "dữ liệu": nó cần versioning và duyệt. Ví dụ chính sách minh hoạ: purpose personal_finance_management được cấp tối đa accounts:read, balances:read, transactions:90d; không được cấp transactions:full_history hay bất kỳ scope nào cho phép khởi tạo thanh toán.

Cuối cùng, dữ liệu chia sẻ phải có chất lượng và lineage. Nếu ngân hàng chia sẻ số dư sai hay giao dịch thiếu, TPP ra quyết định sai (từ chối khoản vay, cảnh báo chi tiêu nhầm) và uy tín ngân hàng chịu. Truy vết nguồn gốc mỗi trường dữ liệu chia sẻ (lineage) giúp điều tra khi có tranh chấp — xem Data Quality.

Vòng đời consent và luồng dữ liệu có kiểm soát

Sơ đồ tóm tắt trọn vòng đời: cấp (bước 1–5) → chia sẻ theo scope (6–8) → audit (song song, mọi bước) → thu hồi (9–10). Điểm cần nhấn: khối "Kiểm soát truy cập" tra cứu consent ledger ở mọi request, nên khi khách thu hồi, lần gọi tiếp theo của TPP bị chặn ngay — không có độ trễ, không cần TPP "tự giác".

Rủi ro và phân định trách nhiệm

Rủi ro tương quan dữ liệu đáng chú ý vì hay bị đánh giá thấp: dữ liệu tưởng đã "ẩn danh" (bỏ tên, bỏ số tài khoản) vẫn có thể lộ danh tính khi ghép với dữ liệu khác. Một chuỗi giao dịch với vài giao dịch đặc thù (lương từ một công ty cụ thể, một khoản chi định kỳ hiếm) có thể trỏ đúng một người. Vì vậy ẩn danh hoá phải làm đúng kỹ thuật, không chỉ "xoá cột tên".

Về phân định trách nhiệm khi có sự cố: mô hình Open Banking chuẩn tách vai rõ — ngân hàng (ASPSP) chịu trách nhiệm về tính đúng đắn của dữ liệu chia sẻ và về cơ chế xác thực/consent phía mình; TPP chịu trách nhiệm về việc sử dụng dữ liệu đúng mục đích và bảo vệ dữ liệu sau khi nhận. Chính vì ranh giới này, audit log và consent ledger là bằng chứng gốc để phân định lỗi — không có chúng, mọi tranh chấp thành lời khai một chiều.

Cân bằng đổi mới và bảo vệ khách hàng

Có một sức căng thường trực: chia sẻ càng nhiều thì càng tạo được nhiều giá trị, nhưng rủi ro riêng tư cũng càng lớn. Sai ở cả hai cực: khoá chặt quá thì bỏ lỡ đổi mới; mở toang quá thì đánh mất niềm tin — và niềm tin là tài sản không có trên bảng cân đối nhưng mất là mất khách. Điểm cân bằng đúng đến từ thiết kế: chia sẻ đúng thứ cần (minimization), đúng mục đích (purpose limitation), khách kiểm soát được (revoke, dashboard), mọi thứ để lại dấu vết (audit). Khi bốn điều này chắc, ngân hàng có thể mạnh dạn mở rộng chia sẻ mà không đánh cược uy tín.

Use case thực tế

Bối cảnh. NCB xây khung chia sẻ dữ liệu với TPP để phục vụ nhóm AISP quản lý chi tiêu và một đối tác chấm điểm tín dụng thay thế, đặt yêu cầu tuân thủ Nghị định 13/2023 làm ràng buộc thiết kế.

Các cấu phần triển khai:

1. Consent ledger tập trung. Mọi consent lưu tại một service append-only, giữ đủ chiều: customer_id, tpp_id, scopes, purpose, granted_at, expires_at, revoked_at, sca_ref. Mục tiêu: mọi truy cập của TPP phải trỏ về đúng một consent còn hiệu lực; không có consent hợp lệ thì gateway trả 403.

2. Tối thiểu dữ liệu theo scope. NCB định nghĩa 6 scope chuẩn (accounts:read, balances:read, transactions:90d, transactions:12m, product:read, và scope tổng hợp income:summary chỉ trả tóm tắt thu nhập thay vì raw transactions). Đối tác chấm điểm tín dụng chỉ được cấp income:summary — nhận về chỉ báo tổng hợp, không bao giờ thấy từng dòng giao dịch. Nhờ vậy nếu đối tác bị tấn công, dữ liệu lộ ra là số tổng hợp, không phải hành vi chi tiết.

3. Audit và thu hồi. Mỗi request qua API gateway ghi một audit record (thời điểm, TPP, consent, scope, số bản ghi trả về). Khách thu hồi qua app NCB; gateway đọc trạng thái consent theo thời gian thực nên request kế tiếp của TPP bị chặn ngay.

Số liệu minh hoạ (giả định để hình dung quy mô): ~180.000 consent active; ~92% consent dùng scope transactions:90d trở xuống (minh chứng minimization phát huy tác dụng — đa số không cần lịch sử dài); thời gian trung bình từ lúc khách bấm "thu hồi" tới lúc token bị chặn < 1 giây; 100% request TPP có audit record. Định kỳ, đội quản trị dữ liệu đối soát: mỗi consent revoked có đúng bản ghi trong ledger, mỗi truy cập có đúng consent hợp lệ tại thời điểm truy cập.

Truy vấn giám sát dưới đây minh hoạ tinh thần đối soát trên schema nội bộ NCB (bảng ob_consents, ob_access_logs là ví dụ, không thuộc sandbox nên không đánh dấu chạy được):

-- MINH HOẠ (schema nội bộ, không phải sandbox)
-- Tìm truy cập của TPP tới dữ liệu mà consent đã hết hiệu lực tại thời điểm truy cập
SELECT l.tpp_id, l.consent_id, l.accessed_at, c.revoked_at, c.expires_at
FROM ob_access_logs l
JOIN ob_consents c ON c.consent_id = l.consent_id
WHERE (c.revoked_at IS NOT NULL AND l.accessed_at >= c.revoked_at)
   OR (l.accessed_at >= c.expires_at);

Kết quả kỳ vọng: rỗng. Bất kỳ dòng nào xuất hiện là một sự cố kiểm soát truy cập cần điều tra ngay. Đây chính là cách biến nguyên tắc pháp lý (đồng ý, thời hạn, thu hồi) thành phép kiểm tra dữ liệu chạy được.

Ghi nhớ

• Khách sở hữu dữ liệu; ngân hàng chỉ giữ hộ và xử lý. Data portability cho khách quyền mang dữ liệu đi, nhưng luôn ràng buộc bởi consent.
• Năm nguyên tắc: consent-based, purpose limitation, data minimization, storage limitation, portability & control. Purpose limitation và minimization là hai hàng rào quan trọng và dễ bị bỏ nhất.
• Nghị định 13/2023/NĐ-CP là khung pháp lý nền về bảo vệ dữ liệu cá nhân ở Việt Nam: yêu cầu đồng ý, quyền chủ thể dữ liệu, trách nhiệm bên xử lý. Nắm khung, tra văn bản gốc + pháp chế cho chi tiết; GDPR để tham chiếu chuẩn cao.
• Kỹ thuật bảo vệ: tối thiểu hoá tại nguồn, ẩn danh/giả danh hoá đúng cách, mã hoá on-transit và at-rest, kiểm soát truy cập theo scope, không lưu quá mức ở TPP.
• Consent là dữ liệu, không phải cờ boolean. Lưu ai/cái gì/khi nào/mục đích trong consent ledger append-only; mọi truy cập để lại audit log; thu hồi phải có hiệu lực tức thời.
• Rủi ro chính: rò rỉ, dùng sai mục đích, TPP kém an toàn, tái định danh do tương quan dữ liệu. Consent ledger + audit log là bằng chứng gốc để phân định trách nhiệm.
• Niềm tin là tài sản. Cân bằng đổi mới và bảo vệ đến từ thiết kế đúng — chia sẻ đúng thứ, đúng mục đích, khách kiểm soát được, mọi thứ có dấu vết.

Nguồn tham khảo

• Chính phủ Việt Nam — Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (văn bản gốc trên Cổng thông tin điện tử Chính phủ / Cơ sở dữ liệu quốc gia về văn bản pháp luật vbpl.vn)
• Regulation (EU) 2016/679 (GDPR) — General Data Protection Regulation, EUR-Lex
• Directive (EU) 2015/2366 (PSD2) — Payment Services Directive, EUR-Lex
• ISO/IEC 27701:2019 — Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management (PIMS)
• ISO/IEC 29100:2011 — Information technology — Security techniques — Privacy framework </content>