Open Banking 4 — Account Aggregation & AISP

AIS: ứng dụng phổ biến nhất của Open Banking

Trong tổng quan Open Banking ta chia dịch vụ thành hai nhóm lớn: AIS (Account Information Service — dịch vụ thông tin tài khoản, chỉ đọc dữ liệu) và PIS (Payment Initiation Service — khởi tạo thanh toán, xem bài 5). Trên thực tế, AIS là mảng "nổ" trước và rộng nhất: hầu hết ứng dụng fintech mà người dùng chạm tay đầu tiên — app quản lý chi tiêu, app so sánh sản phẩm, app cho vay nhanh — đều bắt đầu bằng việc đọc dữ liệu tài khoản của khách. Lý do đơn giản: đọc dữ liệu rủi ro thấp hơn nhiều so với chuyển tiền, nên cả ngân hàng lẫn cơ quan quản lý dễ chấp nhận, và giá trị mang lại cho khách hàng thấy được ngay.

Nhân vật trung tâm của AIS là AISP — Account Information Service Provider (nhà cung cấp dịch vụ thông tin tài khoản). Đây là một loại TPP (Third Party Provider — bên thứ ba) được cấp phép, chuyên tổng hợp thông tin tài khoản và giao dịch của một khách hàng từ nhiều ngân hàng vào một chỗ duy nhất. Khách hàng có tài khoản ở NCB, một ngân hàng quốc doanh, một ví điện tử và một công ty tài chính — thay vì mở bốn app, họ nhìn thấy toàn bộ bức tranh tài chính trong một màn hình. Đó chính là account aggregation (tổng hợp tài khoản).

Điều kiện tiên quyết, không có ngoại lệ: consent (sự đồng ý) của khách hàng. AISP chỉ được truy cập dữ liệu sau khi khách xác thực trực tiếp với từng ngân hàng và cấp quyền theo đúng phạm vi, đúng thời hạn. Toàn bộ cơ chế consent, xác thực mạnh (SCA), token và thu hồi đã trình bày kỹ trong Consent & bảo mật; bài này tập trung vào dữ liệu và ứng dụng.

Dữ liệu được chia sẻ qua AIS

Khi khách hàng đã cấp consent, ngân hàng (đóng vai ASPSP — Account Servicing Payment Service Provider, tức bên giữ tài khoản) mở cho AISP một tập dữ liệu chuẩn qua API AIS. Thường gồm bốn nhóm:

• Danh sách tài khoản (accounts): các tài khoản khách sở hữu trong phạm vi consent — số tài khoản (thường ẩn/che một phần), loại tài khoản (thanh toán, tiết kiệm, thẻ tín dụng), loại tiền tệ, chủ tài khoản. Endpoint điển hình: GET /accounts.
• Số dư (balances): số dư hiện tại, số dư khả dụng, hạn mức. GET /accounts/{id}/balances.
• Lịch sử giao dịch (transactions): từng dòng giao dịch — số tiền, chiều (ghi nợ/ghi có), ngày ghi sổ, ngày giá trị, mô tả/diễn giải, đối tác nếu có, mã tham chiếu. GET /accounts/{id}/transactions. Đây là nhóm dữ liệu giá trị nhất nhưng cũng khó xử lý nhất.
• Thông tin sản phẩm (product): đặc điểm sản phẩm gắn với tài khoản — lãi suất, phí, điều khoản. Hỗ trợ so sánh sản phẩm.

Điểm mấu chốt của người làm dữ liệu: cùng một khái niệm "giao dịch" nhưng mỗi ngân hàng trả về cấu trúc, tên trường, quy ước dấu và định dạng khác nhau, kể cả khi cùng tuân theo một chuẩn (OBIE, Berlin Group, hay chuẩn nội địa). Một ngân hàng để amount luôn dương và tách trường creditDebitIndicator; ngân hàng khác dùng số âm cho ghi nợ. Ngày có nơi theo UTC, có nơi theo giờ địa phương. Đây chính là gốc rễ của bài toán data engineering mà ta sẽ bàn ở phần sau.

Kiến trúc tổng hợp AISP

Về mặt luồng, một AISP đứng giữa nhiều ngân hàng nguồn và app hướng người dùng. Sơ đồ dưới minh hoạ kiến trúc điển hình:

Khách hàng cấp consent tại từng ngân hàng (mũi tên xác thực SCA), AISP lưu token; Fetch Engine gọi API AIS định kỳ, đẩy dữ liệu thô qua tầng chuẩn hoá + enrichment trước khi lưu vào kho tổng hợp để app PFM hiển thị. Toàn bộ giá trị của AISP nằm ở tầng chuẩn hoá này — không có nó, aggregator chỉ là một cái ống dẫn dữ liệu lộn xộn.

Ứng dụng của account aggregation

Dữ liệu tổng hợp mở ra một loạt sản phẩm:

• PFM — Personal Financial Management (quản lý tài chính cá nhân): ứng dụng "flagship" của AIS. App gộp mọi tài khoản, tính tổng tài sản/nợ, hiển thị dòng tiền vào–ra, cảnh báo sắp hết tiền, nhắc hoá đơn định kỳ.
• Phân loại chi tiêu (categorization): gắn nhãn từng giao dịch vào nhóm (ăn uống, di chuyển, hoá đơn, giải trí, đầu tư…) để vẽ biểu đồ "tiền đi đâu". Đây là tính năng người dùng thấy rõ nhất — và phụ thuộc hoàn toàn vào chất lượng enrichment.
• Gộp bức tranh tài chính (net worth view): một màn hình duy nhất cho toàn bộ tài sản và nghĩa vụ nợ đa ngân hàng.
• Chấm điểm tín dụng thay thế (alternative credit scoring): thay vì chỉ dựa vào lịch sử tín dụng truyền thống (CIC), bên cho vay dùng dòng tiền thực từ dữ liệu AIS — thu nhập đều đặn, tỷ lệ chi/thu, số dư trung bình, tần suất thấu chi — để đánh giá khả năng trả nợ. Cách tiếp cận này đặc biệt giá trị với nhóm "thin-file" (ít lịch sử tín dụng). Kỹ thuật scorecard xem Chấm điểm tín dụng.
• Onboarding nhanh & xác minh thu nhập (income verification): khi mở tài khoản hay vay, khách cho phép app đọc lịch sử lương thay vì nộp sao kê giấy — rút ngắn quy trình từ nhiều ngày xuống vài phút, và dữ liệu đáng tin hơn ảnh chụp sao kê.

Thách thức dữ liệu: đây là bài toán data engineering thực sự

Điểm cốt lõi của bài này: giá trị của một AISP nằm ở lớp xử lý dữ liệu, không phải ở việc gọi được API. Gọi API chỉ là bước lấy nguyên liệu thô; biến nó thành thông tin sạch, thống nhất, có ý nghĩa mới là phần khó. Một pipeline enrichment điển hình gồm các chặng:

1. Chuẩn hoá (normalization)

Ánh xạ lược đồ (schema) khác nhau của từng ngân hàng về một mô hình dữ liệu chung (canonical model). Thống nhất: đơn vị tiền tệ, quy ước dấu (ghi nợ âm / ghi có dương), múi giờ về UTC, định dạng ngày, encoding tiếng Việt trong diễn giải. Không có bước này, mọi phép tính tổng hợp đều sai.

2. Phân loại & enrichment (categorization / enrichment)

Từ chuỗi diễn giải thô (thường viết tắt, dính mã máy) suy ra: danh mục (category), merchant (đơn vị thụ hưởng thực), tính chất định kỳ (recurring — lương, tiền nhà, gói thuê bao). Kỹ thuật thường kết hợp: bộ luật (regex/từ khoá) cho các mẫu ổn định, mô hình ML phân loại cho phần còn lại, và bảng tra merchant. Chất lượng ở đây quyết định trải nghiệm PFM.

3. Khử trùng lặp (deduplication)

Cùng một giao dịch có thể xuất hiện nhiều lần: do refresh chồng lấn cửa sổ thời gian, do giao dịch nội bộ giữa hai tài khoản của chính khách (chuyển từ tài khoản A sang B hiện ra hai dòng), hoặc do giao dịch "pending" rồi "posted" là hai bản ghi. Cần khoá định danh ổn định (fingerprint) để nhận ra và gộp.

4. Chất lượng dữ liệu (data quality)

Kiểm tra tính đầy đủ, hợp lệ, nhất quán: có khoảng trống thời gian không (ngân hàng downtime), số dư có khớp với tổng giao dịch không, có giá trị bất thường không. Đây là vòng kiểm soát bắt buộc — xem Chất lượng dữ liệu. Dữ liệu tài chính sai một dòng có thể dẫn tới quyết định cho vay sai.

Cấu trúc dữ liệu chuẩn hoá (minh hoạ)

Dưới đây là mô hình dữ liệu tổng hợp minh hoạ (không phải chuẩn chính thức của bất kỳ ngân hàng nào) — mục đích để thấy sản phẩm sau chuẩn hoá trông thế nào:

// account (đã chuẩn hoá) — MINH HOẠ
{
  "account_id": "ncb::acc_8842",
  "source_bank": "NCB",
  "type": "current",
  "currency": "VND",
  "balance_available": 12450000,
  "consent_id": "cst_7f3a",
  "last_refreshed_at": "2026-07-13T02:00:00Z"
}

// transaction (đã chuẩn hoá + enrich) — MINH HOẠ
{
  "txn_id": "ncb::acc_8842::t_10293",
  "account_id": "ncb::acc_8842",
  "posted_at": "2026-07-12T09:14:00Z",
  "amount": -185000,          // âm = ghi nợ
  "currency": "VND",
  "raw_desc": "POS 970418 HIGHLANDS COFFEE HN",
  "merchant": "Highlands Coffee",
  "category": "food_beverage",
  "is_recurring": false,
  "fingerprint": "a91f...c2"
}

Trường fingerprint (băm từ tài khoản + thời gian + số tiền + diễn giải chuẩn hoá) là chìa khoá khử trùng lặp; category và merchant là kết quả enrichment.

Ví dụ SQL: tổng hợp chi tiêu theo nhóm

Trong sandbox học tập của chúng ta có schema đơn giản accounts(id, customer_id, balance, currency) và transactions(id, account_id, amount, kind, created_at). Không có cột category, nên ta mô phỏng việc gộp giao dịch ra theo tài khoản/loại tiền để hình dung logic tổng hợp mà một pipeline PFM sẽ làm với dữ liệu đã enrich. Lưu ý ép ::numeric trước ROUND khi dùng AVG:

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

Trong hệ thống PFM thật, GROUP BY sẽ theo cột category (kết quả enrichment) thay vì kind, và có thêm chiều thời gian (theo tháng) để vẽ xu hướng chi tiêu. Truy vấn trên chỉ minh hoạ hình dạng phép tổng hợp trên schema sandbox.

Trải nghiệm & consent theo thời gian

Khác PIS (một lệnh thanh toán rồi kết thúc), AIS thường là consent dài hạn: khách cho phép app đọc dữ liệu định kỳ trong một khoảng thời gian (ví dụ 90 ngày, tuỳ khung pháp lý), để bức tranh tài chính luôn cập nhật. Điều này đặt ra vài yêu cầu:

• Refresh định kỳ: aggregator gọi lại API theo lịch (ví dụ mỗi đêm) để lấy giao dịch mới. Cần thiết kế cửa sổ lấy dữ liệu chồng lấn có kiểm soát để không sót nhưng cũng phải khử trùng lặp phần chồng.
• Giới hạn tần suất (rate limit): khung Open Banking thường phân biệt truy cập do khách chủ động mở app (được ưu tiên) và truy cập nền tự động (bị giới hạn số lần/ngày, ví dụ 4 lần/ngày khi khách offline). Pipeline phải tôn trọng hạn mức này để không bị chặn.
• Thu hồi (revocation): khách có thể rút consent bất cứ lúc nào. Khi đó AISP phải dừng truy cập ngay và, tuỳ chính sách, xoá hoặc ngừng dùng dữ liệu đã tổng hợp.
• Hết hạn & gia hạn: consent hết hạn thì luồng dữ liệu dừng cho tới khi khách xác thực lại. App tốt sẽ nhắc khách gia hạn trước khi ngắt.

Rủi ro & tuân thủ

Aggregation gom dữ liệu tài chính của một người vào một chỗ — chính điều làm nó hữu ích cũng làm nó nhạy cảm. Ba nguyên tắc bắt buộc:

• Quyền riêng tư & mục đích (purpose limitation): chỉ được dùng dữ liệu đúng mục đích khách đã đồng ý. Consent để "quản lý chi tiêu" không cho phép đem dữ liệu bán cho bên quảng cáo. Xem Quyền riêng tư & tuân thủ và chia sẻ dữ liệu & quyền riêng tư.
• Bảo mật dữ liệu tổng hợp: kho dữ liệu aggregator là "mỏ vàng" cho kẻ tấn công. Cần mã hoá khi lưu và khi truyền, kiểm soát truy cập chặt, tối thiểu hoá dữ liệu (chỉ giữ trường thực sự cần). Nền tảng kỹ thuật xem Kiểm soát truy cập & mật mã.
• Trách nhiệm giải trình: ghi log ai truy cập dữ liệu gì, khi nào, để phục vụ khách hàng khiếu nại và cơ quan quản lý thanh tra.

Góc nhìn ngân hàng: NCB đứng ở đâu?

Một điểm dễ nhầm: ngân hàng không chỉ đóng một vai. Với NCB, Open Banking mở ra hai vị thế đồng thời:

1. NCB là nguồn dữ liệu (ASPSP): NCB phải mở API AIS cho các AISP được cấp phép truy cập dữ liệu khách hàng NCB (sau consent). Đây là nghĩa vụ/cơ hội tuân thủ — chất lượng API AIS của NCB ảnh hưởng trực tiếp tới trải nghiệm khách trên mọi app fintech.
2. NCB là AISP: NCB hoàn toàn có thể tự xây một app PFM tổng hợp tài khoản đa ngân hàng cho chính khách của mình. Khách có tài khoản ở NCB và ngân hàng khác vẫn coi app NCB là "trung tâm tài chính" — giữ khách ở lại hệ sinh thái NCB, đồng thời NCB thu được tín hiệu dòng tiền quý giá để cross-sell và chấm điểm vay.

Vị thế kép này biến năng lực data engineering tổng hợp giao dịch thành lợi thế cạnh tranh cốt lõi, chứ không chỉ là chi phí tuân thủ.

Use case thực tế

Bối cảnh (số liệu ước lượng, minh hoạ): NCB ra mắt "NCB Money" — app PFM tổng hợp tài khoản đa ngân hàng. Mục tiêu năm đầu: 200.000 khách kết nối, mỗi khách trung bình liên kết 2,3 tài khoản từ 1,8 ngân hàng.

Bước triển khai:

1. Kết nối & consent: khách bật liên kết ngân hàng khác, xác thực SCA tại từng ngân hàng, cấp consent 90 ngày. NCB lưu token, lên lịch refresh mỗi đêm 02:00.
2. Pipeline enrichment: mỗi đêm kéo ~4 triệu giao dịch mới, chạy chuẩn hoá → khử trùng lặp (loại ~6% bản ghi trùng do chuyển nội bộ và chồng lấn) → enrichment. Bộ luật phủ ~70% giao dịch (mẫu quen như HIGHLANDS, GRAB, tiền điện EVN), mô hình ML xử lý phần còn lại, đạt độ chính xác phân loại ~88% (ước lượng).
3. Sản phẩm PFM: khách thấy tổng tài sản, biểu đồ chi tiêu theo nhóm, cảnh báo "tháng này ăn uống vượt 20% so với trung bình".
4. Chấm điểm vay từ dòng tiền: với khách đồng ý, NCB tính chỉ số dòng tiền (thu nhập đều đặn, tỷ lệ chi/thu, số dư tối thiểu 90 ngày) làm biến bổ sung cho scorecard tín dụng. Kết quả (ước lượng): duyệt được thêm ~12% hồ sơ "thin-file" từng bị từ chối do thiếu lịch sử CIC, với tỷ lệ nợ xấu tương đương nhóm chuẩn.

Bài học: phần khó không phải gọi API — mà là tầng chuẩn hoá/khử trùng/enrichment và kiểm soát chất lượng. Một lỗi phân loại lương thành "thu nhập bất thường" sẽ kéo điểm tín dụng sai và làm khách mất niềm tin vào biểu đồ chi tiêu. Đầu tư vào data quality ở đây có ROI trực tiếp.

Ghi nhớ

• AIS (chỉ đọc dữ liệu) là mảng phổ biến nhất của Open Banking; AISP là bên thứ ba tổng hợp tài khoản/giao dịch từ nhiều ngân hàng vào một chỗ, luôn cần consent (bài 3).
• Dữ liệu chia sẻ qua API AIS: danh sách tài khoản, số dư, lịch sử giao dịch, thông tin sản phẩm.
• Ứng dụng chính: PFM, phân loại chi tiêu, gộp bức tranh tài chính, chấm điểm tín dụng thay thế từ dòng tiền, onboarding nhanh, xác minh thu nhập.
• Giá trị thật của AISP nằm ở pipeline dữ liệu: chuẩn hoá schema/dấu/tiền tệ → khử trùng lặp (fingerprint) → enrichment (category/merchant/recurring) → data quality. Đây là bài toán data engineering, không phải chỉ gọi API.
• Consent AIS thường dài hạn: refresh định kỳ, tôn trọng rate limit truy cập nền, xử lý thu hồi và hết hạn.
• Tuân thủ cốt lõi: purpose limitation (chỉ dùng đúng mục đích consent), bảo mật kho dữ liệu tổng hợp, log truy cập.
• NCB có vai kép: vừa là nguồn dữ liệu (ASPSP) vừa có thể là AISP cung cấp app PFM — biến năng lực tổng hợp giao dịch thành lợi thế cạnh tranh.
• Liên quan: Open Banking tổng quan và Khởi tạo thanh toán (PIS).

Nguồn tham khảo

• Open Banking Limited (OBIE) — Read/Write API Specifications, đặc biệt phần Account and Transaction API (Accounts, Balances, Transactions endpoints).
• The Berlin Group — NextGenPSD2 XS2A Framework (Implementation Guidelines cho Account Information Service).
• Directive (EU) 2015/2366 (PSD2) — khung pháp lý định nghĩa vai trò AISP, TPP và yêu cầu Strong Customer Authentication (SCA).
• ISO 20022 — Universal financial industry message scheme (mô hình dữ liệu và từ vựng cho thông điệp tài chính).
• Financial Data Exchange (FDX) — FDX API Specification (chuẩn chia sẻ dữ liệu tài chính, phổ biến tại Mỹ/Canada).