Open Banking 5 — Payment Initiation & Instant Payment

13 thg 7, 2026 3 lượt xem
#banking
#napas
#instant-payment
#open-banking
#pisp

PIS: chuyển tiền thẳng từ tài khoản, không qua thẻ

Trong tổng quan Open Banking ta chia dịch vụ thành hai nhóm: AIS — đọc thông tin tài khoản (bài 4), và PIS — Payment Initiation Service (dịch vụ khởi tạo thanh toán). PIS là mảng "nặng ký" hơn: thay vì chỉ đọc dữ liệu, nó thực hiện chuyển tiền thật từ tài khoản khách. Rủi ro cao hơn nên khung pháp lý và bảo mật cũng chặt hơn, nhưng giá trị kinh doanh mà nó mở ra là rất lớn.

Nhân vật trung tâm là PISP — Payment Initiation Service Provider (nhà cung cấp dịch vụ khởi tạo thanh toán). Đây là một loại TPP (Third Party Provider — bên thứ ba) được cấp phép, đứng ra khởi tạo một lệnh chuyển tiền trực tiếp từ tài khoản thanh toán của khách đến tài khoản người thụ hưởng (thường là thương nhân/merchant), sau khi khách đã đồng ý (consent) và xác thực trực tiếp với ngân hàng của mình. Điểm mấu chốt: PISP không bao giờ giữ tiền và cũng không cần biết mật khẩu ngân hàng của khách — nó chỉ khởi tạo lệnh; việc ghi nợ tài khoản và chuyển tiền do chính ngân hàng giữ tài khoản (ASPSP) thực hiện.

So với thanh toán thẻ truyền thống, đây là mô hình A2A — Account-to-Account (tài khoản tới tài khoản): tiền đi thẳng từ tài khoản người mua sang tài khoản người bán, không qua mạng thẻ (Visa/Mastercard), không qua acquirer, không có bước "authorization → clearing → settlement" kéo dài. Xem thêm Payments & Transfers.

Vì sao thương nhân thích A2A

  • Phí thấp hơn nhiều. Thanh toán thẻ gánh interchange fee, scheme fee, phí acquirer — tổng thường 1.5–3% giá trị giao dịch. Thanh toán A2A qua hạ tầng chuyển nhanh nội địa chỉ tốn phí giao dịch cố định rất nhỏ (vài trăm tới vài nghìn đồng/lệnh), tỷ lệ giảm mạnh khi giá trị lớn.
  • Tiền về ngay (good funds). Với hạ tầng instant payment, tiền vào tài khoản merchant trong vài giây, 24/7, thay vì chờ chu kỳ settlement T+1/T+2 của thẻ. Dòng tiền và đối soát đơn giản hơn.
  • Ít chargeback. Giao dịch A2A là "push payment" do người trả chủ động đẩy đi, không có cơ chế chargeback như thẻ — giảm rủi ro gian lận hoàn tiền, nhưng cũng đặt ra bài toán bảo vệ người tiêu dùng (xem phần rủi ro).
  • Không lưu dữ liệu thẻ. Merchant không chạm vào PAN (số thẻ) nên gánh nặng tuân thủ PCI-DSS nhẹ đi.

Luồng khởi tạo thanh toán

Về bản chất, PISP đứng giữa merchant và ngân hàng của khách. Luồng chuẩn (theo mô hình OBIE của Anh và Berlin Group của EU) gồm các bước: khách chọn "trả bằng tài khoản" → PISP tạo payment consent và gửi lệnh tới ngân hàng → khách được chuyển hướng (redirect) về app/web ngân hàng để xác thực mạnh (SCA) → ngân hàng thực hiện ghi nợ và chuyển tiền → trả về trạng thái cho PISP và merchant.

Toàn bộ cơ chế consent, redirect, xác thực mạnh SCA (Strong Customer Authentication — xác thực đa nhân tố), token OAuth và thu hồi quyền được trình bày kỹ trong Consent & bảo mật. Ở đây cần nhớ hai đặc thù của PIS so với AIS:

  • SCA gần như luôn bắt buộc cho mỗi lệnh (trừ một số ngoại lệ hạn mức thấp, giao dịch định kỳ đã ủy quyền trước). Ngược lại, AIS có thể tái sử dụng consent để đọc dữ liệu nhiều lần trong thời hạn mà không cần SCA mỗi lần.
  • Consent gắn với một lệnh cụ thể (số tiền, người thụ hưởng, tham chiếu) — khách phê duyệt đúng chi tiết lệnh đó, chống việc PISP sửa số tiền sau khi được đồng ý.

Idempotency và đối soát

Vì là chuyển tiền thật, hai kỹ thuật sống còn:

  • Idempotency (bất biến trùng lặp). Mỗi request khởi tạo mang một x-idempotency-key duy nhất. Nếu mạng lỗi và PISP retry, ngân hàng nhận ra key đã xử lý và không tạo lệnh chi tiền lần hai. Thiếu điều này, một cú timeout có thể khiến khách bị trừ tiền hai lần.
  • Đối soát (reconciliation). Trạng thái trả về ngay có thể là "đang xử lý"; PISP và merchant phải poll trạng thái hoặc nhận webhook để xác nhận kết quả cuối, rồi đối chiếu với báo cáo settlement cuối ngày từ ngân hàng/NAPAS. Xem sâu về đối soát ở Payments & Transfers.

Instant Payment: hạ tầng nền cho A2A

PIS chỉ thực sự hấp dẫn khi tiền về ngay. Cái làm nên "ngay" đó là hạ tầng instant payment (thanh toán tức thời) — hệ thống chuyển tiền liên ngân hàng real-time, 24/7/365, xử lý và ghi có trong vài giây kể cả ngoài giờ hành chính, cuối tuần, ngày lễ. Đây là mảnh ghép hạ tầng, tách biệt với lớp API Open Banking, nhưng PIS thường "cưỡi" lên nó để giao tiền.

Một số hạ tầng instant payment tiêu biểu (nêu ở mức khung, chi tiết vận hành khác nhau theo từng thị trường):

Thị trườngHạ tầng instant paymentĐặc điểm
Việt NamNAPAS 24/7 (chuyển nhanh liên ngân hàng), VietQRChuyển khoản nhanh giữa các NH trong nước, gần như tức thời, 24/7; VietQR chuẩn hóa mã QR để quét-chuyển
EU (khu vực euro)SCT Inst (SEPA Instant Credit Transfer)Ghi có trong ~10 giây, trần giá trị theo quy định
AnhFaster PaymentsHạ tầng chuyển nhanh, nền cho phần lớn thanh toán Open Banking tại UK
Ấn ĐộUPILớp thanh toán tức thời gắn địa chỉ ảo, khối lượng cực lớn

Tại Việt Nam, NAPAS 24/7 và VietQR là nền tảng thực tế cho thanh toán A2A: người dùng đã quen quét QR để chuyển khoản tức thời liên ngân hàng. Khi khung pháp lý Open Banking hoàn thiện, PIS sẽ đứng trên chính hạ tầng chuyển nhanh này — "đường ray" tiền đã có sẵn, cái còn thiếu chủ yếu là lớp API chuẩn hóa + consent + cấp phép TPP. Đây là lợi thế lớn của VN so với nơi phải xây instant payment từ đầu. Đối chiếu chuyển tiền quốc tế xem SWIFT xuyên biên giới.

Các loại lệnh thanh toán

PIS không chỉ là "trả một đơn hàng". Các biến thể chính:

  • Chuyển đơn (single/domestic payment): một lệnh, một số tiền, một người thụ hưởng — phổ biến nhất khi thanh toán tại quầy hay checkout online.
  • Chuyển hàng loạt (bulk/batch payment): một file/lệnh chứa nhiều khoản chi — dùng cho trả lương, chi hộ nhà cung cấp. Doanh nghiệp khởi tạo qua PISP thay vì upload file thủ công qua internet banking.
  • Định kỳ (standing order / recurring): lệnh lặp lại theo lịch cố định (cùng số tiền, cùng ngày) — trả tiền thuê nhà, phí hằng tháng.
  • VRP — Variable Recurring Payments (thanh toán định kỳ giá trị thay đổi): xu hướng mới nhất và đáng chú ý nhất. Khách cấp một consent dài hạn cho phép PISP tự động khởi tạo nhiều lệnh trong giới hạn đã thỏa thuận (trần mỗi lệnh, trần theo tháng, khoảng thời gian), không cần SCA cho từng lệnh. VRP được kỳ vọng là "đối thủ" thực sự của thanh toán thẻ định kỳ và ví — vừa tự động như thẻ, vừa rẻ như A2A, vừa minh bạch giới hạn cho khách. Đây là hướng nhiều thị trường (UK dẫn đầu với "sweeping VRP") đang mở rộng.
  • Hoàn tiền (refund): lệnh ngược từ merchant về khách khi trả hàng/hủy dịch vụ — cần quy trình và dữ liệu tham chiếu để nối đúng giao dịch gốc.

Dữ liệu, trạng thái và rủi ro

Vòng đời trạng thái giao dịch

Người làm dữ liệu cần nắm state machine của một lệnh, vì mọi báo cáo, đối soát, cảnh báo đều bám vào đó. Các trạng thái điển hình (theo quy ước OBIE):

Ranh giới quan trọng: một lệnh Authorised (đã xác thực) chưa chắc đã Completed (tiền đã về). Merchant tuyệt đối không giao hàng khi mới thấy "Authorised" — phải chờ trạng thái cuối, hoặc chờ webhook xác nhận settlement.

Các nhóm rủi ro và cách kiểm soát

  • Chống gian lận realtime. Vì tiền đi ngay và không có chargeback, phát hiện gian lận phải xảy ra trước khi ghi nợ — trong vài trăm mili-giây của bước SCA. Ngân hàng chạy scoring realtime (thiết bị lạ, người thụ hưởng mới, số tiền bất thường, tốc độ giao dịch) và có thể chặn/step-up xác thực. Rủi ro nổi cộm của push payment là APP fraud (Authorised Push Payment fraud — lừa nạn nhân tự nguyện chuyển tiền cho kẻ gian): hợp lệ về kỹ thuật nhưng nạn nhân bị lừa. Mô hình giám sát xem AML.
  • Giới hạn/hạn mức. Ngân hàng áp trần mỗi lệnh, trần ngày, trần tháng theo hồ sơ khách và loại kênh; VRP còn có trần do chính khách đặt trong consent. Vượt hạn mức → lệnh bị Rejected, cần thông điệp lỗi rõ ràng.
  • Xử lý lỗi và hoàn tiền. Các nguyên nhân thất bại (số dư không đủ, tài khoản đóng, sai người thụ hưởng, timeout) phải được map thành mã lỗi chuẩn để merchant xử lý đúng. Tiền đã đi nhầm cần quy trình recall/refund — khó hơn thẻ vì không có chargeback tập trung.
  • Đối soát ba bên. Số liệu của PISP, của ngân hàng, và của NAPAS phải khớp cuối ngày. Lệch là dấu hiệu lệnh treo (pending mãi), ghi có trùng, hoặc thất lạc webhook.

Ví dụ payload lệnh thanh toán (minh hoạ)

Đây là ví dụ minh hoạ thân request khởi tạo domestic payment theo phong cách OBIE — cấu trúc thật tùy chuẩn từng thị trường:

{
  "Data": {
    "Initiation": {
      "InstructionIdentification": "NCB-2026-0713-001",
      "EndToEndIdentification": "ORDER-88213",
      "InstructedAmount": { "Amount": "1250000.00", "Currency": "VND" },
      "CreditorAccount": {
        "SchemeName": "VN.NAPAS.AccountNumber",
        "Identification": "0021000****",
        "Name": "CONG TY TNHH ABC"
      },
      "RemittanceInformation": { "Reference": "Thanh toan don ORDER-88213" }
    }
  },
  "Risk": { "PaymentContextCode": "EcommerceGoods" }
}

So sánh: A2A (PIS) vs Thẻ vs Ví

Tiêu chíA2A / PISThẻVí điện tử
Đường tiềnTài khoản → tài khoản, qua chuyển nhanhQua mạng thẻ (issuer–acquirer)Số dư ví / liên kết NH-thẻ
Phí cho merchantRất thấp (phí cố định nhỏ)Cao (interchange + scheme)Trung bình, tùy ví
Thời gian tiền vềVài giây (instant)T+1/T+2 (settlement)Gần tức thời trong ví, rút ra chậm hơn
ChargebackKhông (push payment)Có (bảo vệ người mua)Tùy chính sách ví
Dữ liệu nhạy cảm merchant giữKhông giữ PANCó (PCI-DSS)Không
Trải nghiệmRedirect + SCA ngân hàngNhập thẻ / token1 chạm trong ví

Ba mô hình không loại trừ nhau. Thẻ mạnh ở bảo vệ người mua và chấp nhận toàn cầu; ví mạnh ở trải nghiệm một chạm và hệ sinh thái khép kín; A2A/PIS thắng ở chi phí và tốc độ dòng tiền cho merchant, đặc biệt với giao dịch giá trị lớn hoặc B2B.

Cơ hội cho ngân hàng

A2A payment không chỉ là "mất phí thẻ". Với ngân hàng, đây là cơ hội:

  • Giữ giao dịch trong hệ thống tài khoản thay vì để mạng thẻ hưởng interchange.
  • Trở thành ASPSP hiệu quả: cung cấp API PIS ổn định, độ trễ thấp, tỷ lệ thành công cao — đây thành lợi thế cạnh tranh khi hệ sinh thái mở.
  • Bán dịch vụ giá trị gia tăng: VRP cho subscription, chi lương hàng loạt, thu hộ — kèm dữ liệu đối soát và analytics (Metrics & KPI).

Use case thực tế

Bối cảnh. NCB triển khai thanh toán A2A cho một chuỗi merchant vừa (siêu thị mini, chuỗi F&B) đang chịu phí thẻ cao. Khách thanh toán bằng cách quét QR / chọn tài khoản NCB tại quầy hoặc trên web, tiền đi thẳng từ tài khoản khách sang tài khoản merchant qua NAPAS 24/7, về tức thời, phí thấp.

Luồng rút gọn. Khách quét VietQR động (mã gắn số tiền + mã đơn) → app NCB mở đúng màn hình xác nhận → khách xác thực SCA (vân tay/PIN) → NCB ghi nợ và đẩy lệnh chuyển nhanh → merchant nhận webhook "Completed" và in hóa đơn. Toàn trình mục tiêu dưới 10 giây.

Số liệu ước lượng (minh hoạ, không phải cam kết). Giả định chuỗi merchant xử lý 200.000 giao dịch/tháng, giá trị trung bình 250.000đ:

Chỉ tiêuQua thẻ (~1.8%)Qua A2A/NAPAS
Doanh số/tháng50 tỷ đồng50 tỷ đồng
Phí chấp nhận~900 triệu đồng~ vài chục triệu đồng (phí cố định/lệnh)
Thời gian tiền vềT+1Tức thời
ChargebackCó, cần dự phòngKhông

Nếu chỉ 30% giao dịch dịch chuyển sang A2A, merchant tiết kiệm hàng trăm triệu đồng phí mỗi tháng, còn NCB giữ được dòng giao dịch trong hệ thống tài khoản và bán kèm dịch vụ đối soát.

Góc dữ liệu. Bảng trạng thái lệnh (state machine ở trên) là nguồn cho ba loại báo cáo: (1) tỷ lệ thành công theo bước (khởi tạo → SCA → completed) để tìm điểm rơi rớt; (2) đối soát ba bên PISP–NCB–NAPAS cuối ngày; (3) tín hiệu gian lận realtime feed vào mô hình giám sát (AML). Một câu tổng hợp giao dịch theo loại tiền và số lượng trên schema sandbox demo:

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

Ghi nhớ

  • PIS/PISP khởi tạo lệnh chuyển tiền trực tiếp từ tài khoản khách sau consent — mô hình A2A, không qua mạng thẻ; PISP không giữ tiền, không cần mật khẩu ngân hàng.
  • Thương nhân thích A2A vì phí thấp, tiền về ngay, ít chargeback, không giữ dữ liệu thẻ.
  • Luồng chuẩn: chọn trả bằng tài khoản → PISP tạo payment consent → redirect + SCA tại ngân hàng → ngân hàng thực hiện → trả trạng thái. Bắt buộc idempotencyđối soát.
  • Instant payment (NAPAS 24/7 & VietQR ở VN; SCT Inst ở EU; Faster Payments ở UK) là hạ tầng nền để tiền về tức thời 24/7 — "đường ray" A2A đã có sẵn ở VN.
  • Các loại lệnh: đơn, hàng loạt, định kỳ, VRP (định kỳ giá trị thay đổi — xu hướng mới), hoàn tiền.
  • Trạng thái then chốt: Authorised ≠ Completed — chờ trạng thái cuối mới giao hàng.
  • Rủi ro: gian lận realtime & APP fraud (không có chargeback), hạn mức, xử lý lỗi và recall/refund khó hơn thẻ.
  • Với NCB, A2A là cơ hội giữ giao dịch trong hệ thống tài khoản, giảm phí cho merchant và bán dịch vụ VRP/chi hộ/đối soát.

Nguồn tham khảo

  • Open Banking Limited (UK) — Open Banking Standard, Payment Initiation API Specification (standards.openbanking.org.uk) — mô hình PISP, domestic-payment-consents, trạng thái lệnh (AwaitingAuthorisation/Authorised/AcceptedSettlementCompleted), VRP.
  • PSD2 — Directive (EU) 2015/2366 on payment services in the internal market (khung pháp lý cho PIS/AIS, TPP, Strong Customer Authentication).
  • The Berlin Group — NextGenPSD2 XS2A Framework (chuẩn API PIS/AIS tại châu Âu lục địa).
  • ISO 20022 — Universal financial industry message scheme (iso20022.org) — chuẩn bản tin thanh toán liên ngân hàng.
  • NAPAS — Công ty Cổ phần Thanh toán Quốc gia Việt Nam (napas.com.vn) — hệ thống chuyển tiền nhanh liên ngân hàng 24/7 và tiêu chuẩn VietQR.
  • European Payments Council — SEPA Instant Credit Transfer (SCT Inst) Scheme Rulebook.
  • Pay.UK — Faster Payment System (hạ tầng chuyển nhanh nền cho thanh toán Open Banking tại UK).

Bài viết liên quan

T24 (nay là Temenos Transact) là gì, vị trí trong bức tranh core banking, mô hình Model Bank, chu kỳ release R-series, và các lựa chọn triển khai (on-prem, Temenos Banking Cloud).

13 thg 7, 2026 10

Hành trình dữ liệu ngân hàng đi từ Core Banking qua EOD extract, ODS, Data Warehouse (mô hình Kimball) tới Data Mart/BI và báo cáo tuân thủ NHNN. Bài giải thích các thực thể cốt lõi (CIF, Account, Transaction, Loan, GL), khái niệm dimension/fact, snapshot số dư cuối ngày, đối soát chất lượng dữ liệu, kèm bộ ví dụ SQL chạy được ngay trên SQL Builder.

13 thg 7, 2026 9

Nguyên lý hạch toán kép (Nợ/Có) và Sổ cái tổng hợp (GL): vì sao mỗi giao dịch luôn ghi ít nhất hai vế với Tổng Nợ = Tổng Có. Bài giải thích quy ước tăng/giảm theo loại tài khoản, vì sao tiền gửi khách là nợ phải trả của ngân hàng, Chart of Accounts, GL so với sổ phụ và đối chiếu cuối ngày (EOD).

13 thg 7, 2026 8

Hiểu bản chất kinh doanh của ngân hàng từ con số 0: vai trò trung gian tài chính, vì sao tiền gửi là nợ còn khoản vay là tài sản, cách đọc bảng cân đối và đòn bẩy cao, công thức NIM cùng thu nhập ngoài lãi, ba rủi ro cốt lõi (tín dụng, thanh khoản, lãi suất) và vì sao dữ liệu là xương sống của ngân hàng.

13 thg 7, 2026 8

Cảm nhận của bạn

Bình luận

Bạn cần để viết bình luận.

Chưa có bình luận. Hãy là người đầu tiên chia sẻ!