Thanh toán tức thời & QR

Trong ba bài trước của series, chúng ta đã đi qua bức tranh tổng quan (Tổng quan) và các hệ thống thanh toán nội địa "cổ điển" là RTGS và ACH (RTGS/ACH). Cả hai đều có một điểm chung: chúng được thiết kế cho một thế giới có giờ làm việc. RTGS chạy theo giờ hành chính của ngân hàng trung ương; ACH gom giao dịch theo lô và quyết toán vài lần trong ngày. Người dùng cuối phải chờ — có khi vài giờ, có khi tới ngày làm việc kế tiếp.

Bài này nói về làn sóng đã đảo ngược kỳ vọng đó: thanh toán tức thời (instant payment) hoạt động 24/7/365, tiền tới nơi trong vài giây, và ngày càng gắn chặt với mã QR như một phương thức khởi tạo giao dịch. Ở Việt Nam, hai cái tên trung tâm là NAPAS 247 và VietQR.

1. Instant payment là gì và khác gì các hệ thống cũ

"Instant payment" (thanh toán tức thời, real-time payment) là một cơ chế chuyển tiền có bốn đặc điểm cốt lõi:

• Ghi có gần tức thời (giây): tiền vào tài khoản người nhận trong vòng vài giây kể từ khi người gửi bấm xác nhận. Không còn khái niệm "chờ đối chiếu cuối ngày".
• Always-on 24/7/365: dịch vụ không nghỉ đêm, không nghỉ cuối tuần, không nghỉ lễ. Đây là khác biệt lớn nhất so với RTGS (giờ hành chính) và ACH (theo lô, theo phiên).
• Xác nhận ngay cho cả hai phía: người gửi nhận được thông báo giao dịch thành công, người nhận nhận được thông báo tiền đã vào. Xác nhận này là một phần không thể thiếu của trải nghiệm — người bán ở quầy nhìn màn hình báo "đã nhận" mới giao hàng.
• Khó hoàn tác (irrevocable): một khi lệnh được thực hiện, về nguyên tắc nó là chung cuộc (final). Không có "cửa sổ" để hủy như một số quy trình theo lô.

Điểm cuối cùng có hệ quả rất lớn về rủi ro. Trong hệ thống theo lô, nếu phát hiện gian lận trước khi phiên quyết toán chạy, đôi khi vẫn còn cách chặn. Với instant payment, tiền đi là đi luôn. Vì vậy instant payment bắt buộc phải đi kèm chống gian lận real-time: chấm điểm rủi ro, phát hiện bất thường và ra quyết định chặn/cho qua ngay trong vài trăm mili-giây của luồng giao dịch — chứ không phải rà soát sau đó.

Đối chiếu nhanh ba mô hình:

2. Nghịch lý quyết toán: khách tức thời, ngân hàng thì chưa chắc

Một điểm dễ gây nhầm lẫn: khi nói "tức thời", chúng ta nói về trải nghiệm của khách hàng, không nhất thiết là về quyết toán liên ngân hàng.

Trong nhiều hệ thống instant, ngân hàng nhận ghi có ngay cho khách hàng của mình dựa trên thông điệp xác nhận từ hệ thống chuyển mạch — tức là ngân hàng nhận "tin tưởng" rằng khoản tiền liên ngân hàng sẽ được quyết toán. Nhưng bản thân việc chuyển tiền giữa các ngân hàng có thể được hoãn lại (deferred) và gom lại quyết toán theo net vào các thời điểm nhất định.

Để mô hình này an toàn, người ta dùng prefunded net settlement: các ngân hàng thành viên phải ký quỹ trước một lượng thanh khoản (prefunding) vào một tài khoản/quỹ do bên vận hành hệ thống quản lý. Vị thế net của mỗi ngân hàng bị giới hạn trong phạm vi số dư ký quỹ đó. Nhờ vậy, ngay cả khi quyết toán liên ngân hàng diễn ra sau, rủi ro tín dụng giữa các ngân hàng vẫn được khống chế bằng tài sản đã đặt cọc.

Hệ quả với đội vận hành: quản trị thanh khoản trở thành công việc always-on. Vì dịch vụ không nghỉ, số dư prefunding phải luôn đủ để cover dòng tiền ra kể cả 2 giờ sáng Chủ nhật. Đây là một thay đổi tư duy so với thời "quyết toán cuối ngày".

3. NAPAS 247 — trục chuyển mạch tức thời của Việt Nam

Ở Việt Nam, dịch vụ chuyển tiền nhanh liên ngân hàng 24/7 được vận hành trên hạ tầng của NAPAS (Công ty Cổ phần Thanh toán Quốc gia Việt Nam), với thương hiệu quen thuộc là NAPAS 247 (dịch vụ chuyển nhanh Napas247 / FastFund 247).

Vai trò của NAPAS ở đây là chuyển mạch (switching): nó không phải ngân hàng của bạn, mà là bên đứng giữa định tuyến lệnh giữa ngân hàng gửi và ngân hàng nhận, đối chiếu và điều phối quyết toán giữa các thành viên. NAPAS 247 cho phép:

• Chuyển theo số tài khoản tại ngân hàng khác;
• Chuyển theo số thẻ (số thẻ nội địa);
• Chuyển/thanh toán qua QR (nền tảng cho VietQR ở mục 4).

Dịch vụ hoạt động 24/7, kể cả ngoài giờ hành chính và ngày nghỉ, với người nhận nhận tiền gần như ngay lập tức. Phạm vi áp dụng cho các tổ chức thành viên (ngân hàng và một số tổ chức trung gian) có trụ sở tại Việt Nam và tham gia mạng lưới NAPAS.

Lưu ý: bài này cố ý không nêu con số cụ thể (hạn mức, số lượng giao dịch, phí) vì các tham số này thay đổi theo thời gian và theo từng ngân hàng/chính sách. Hãy tra cứu tại chính ngân hàng của bạn hoặc trang chính thức của NAPAS khi cần số chính xác.

4. QR chuẩn EMVCo và VietQR

4.1 Hai chiều "trình QR": ai giơ mã cho ai?

Chuẩn QR thanh toán quốc tế do EMVCo ban hành có hai chế độ:

• Merchant-Presented Mode (MPM) — merchant-presented QR: người bán trưng mã (dán ở quầy, hiện trên POS/màn hình), người mua dùng app ngân hàng/ví quét mã đó. Đây là mô hình phổ biến nhất bạn thấy ở quán cà phê, chợ, cửa hàng.
• Consumer-Presented Mode (CPM) — consumer-presented QR: người mua hiện mã QR trên điện thoại, người bán dùng máy quét/thiết bị đọc mã của khách. Thường gặp ở siêu thị, chuỗi bán lẻ có POS quét mã.

4.2 VietQR

VietQR là chuẩn/thương hiệu QR dựa trên EMVCo do NAPAS vận hành cho dịch vụ chuyển nhanh tại Việt Nam. Payload VietQR tuân theo cấu trúc TLV (Tag–Length–Value) của EMVCo: mỗi trường gồm ID (2 ký tự) – Độ dài (2 ký tự) – Giá trị.

Một số trường đáng nhớ trong payload:

• Payload Format Indicator (ID 00) — phiên bản định dạng, giá trị 01.
• Point of Initiation Method (ID 01) — cho biết QR tĩnh hay động:
  • 11 = tĩnh (static): một mã dùng lại nhiều lần, thường không nhúng số tiền — khách tự nhập số tiền.
  • 12 = động (dynamic): mã sinh riêng cho từng giao dịch, thường đã nhúng số tiền và tham chiếu đơn hàng.
• Merchant Account Information (ID 38) — khối thông tin tài khoản/định danh phía nhận cho dịch vụ VietQR qua NAPAS. Khối này chứa GUID A000000727 (định danh toàn cầu của VietQR/NAPAS), kèm mã ngân hàng (acquirer/BNB ID) và số tài khoản/định danh người nhận (consumer ID).
• Merchant Category Code (MCC) — mã ngành hàng của người bán (dùng 0000 nếu không áp dụng).
• Transaction Amount — số tiền (có ở QR động; QR tĩnh thường bỏ trống).
• CRC (ID 63) — mã kiểm tra tính toàn vẹn của toàn bộ payload, tính theo CRC-16 (ISO/IEC 13239) trên tất cả các trường (kể cả ID và Length của chính trường CRC), biểu diễn 4 ký tự hex. Nếu payload bị sửa dù một ký tự, CRC sẽ sai và app từ chối.

Ví dụ cấu trúc payload VietQR/EMVCo rút gọn:

(minh hoạ — không phải mã QR thật)

00 02 01                         Payload Format Indicator = "01"
01 02 12                         Point of Initiation = "12" (QR động)
38 54                            Merchant Account Information (khối con):
   00 10 A000000727             ├─ GUID = A000000727 (VietQR/NAPAS)
   01 27                        ├─ Beneficiary Organization (khối con):
      00 06 970xxx              │    ├─ Bank BIN = 970xxx (mã ngân hàng)
      01 11 0123456789          │    └─ Số tài khoản người nhận
   02 08 QRIBFTTA               └─ Service code (chuyển nhanh tới TK)
53 03 704                        Transaction Currency = "704" (VND)
54 05 50000                      Transaction Amount = 50,000
58 02 VN                         Country Code = "VN"
62 09                            Additional Data (khối con):
   08 05 HOADO                  └─ Nội dung/tham chiếu
63 04 A1B2                       CRC-16 (ISO/IEC 13239)

Các trường trên là cấu trúc tổng quát; giá trị cụ thể (BIN, service code, thứ tự trường) khác nhau tùy tài liệu chuẩn hiện hành của NAPAS.

5. Request to Pay (RtP) — "yêu cầu thanh toán"

Các mô hình ở trên đều là push: người trả chủ động đẩy tiền đi. Request to Pay (RtP) đảo chiều khởi tạo:

1. Người nhận (ví dụ người bán, đơn vị phát hành hóa đơn) gửi một yêu cầu thanh toán tới người trả, kèm số tiền và nội dung.
2. Người trả nhận được yêu cầu, xem và duyệt (hoặc từ chối) ngay trên app.
3. Khi được duyệt, một lệnh push instant được thực hiện — tiền chạy như một giao dịch tức thời bình thường.

RtP không phải là "ghi nợ tự động" (direct debit): người trả luôn phải chủ động chấp thuận. Nó phù hợp với hóa đơn, chia bill, hoặc thương mại điện tử — nơi người bán muốn khởi tạo nhưng vẫn để quyền kiểm soát cuối cùng ở người trả. QR động về bản chất là một dạng RtP đơn giản: mã QR chính là "yêu cầu" mang sẵn số tiền, còn cú quét-và-xác-nhận của khách là bước "duyệt".

6. Luồng một giao dịch QR/instant

Điểm mấu chốt trong sơ đồ: hai nhánh xác nhận chạy song song về hai phía (người gửi và người bán) trong vài giây, còn quyết toán liên ngân hàng (đường Note dưới cùng) diễn ra theo cơ chế net/prefunded ở phía sau — khách hoàn toàn không cảm nhận được.

7. Use case thực tế: quét VietQR trả 50k ở quán

Bạn uống cà phê hết 50.000đ. Người bán chỉ vào tấm QR dán ở quầy:

1. Mở app ngân hàng → chọn "Quét QR" → hướng camera vào mã.
2. App đọc payload, kiểm CRC để chắc mã không hỏng/không bị dán đè, rồi hiển thị tên người nhận và số tài khoản. Nếu là QR tĩnh (Point of Initiation 11), app để bạn tự nhập 50.000đ; nếu là QR động (12), số tiền đã hiện sẵn.
3. Bạn xác nhận → app xác thực (sinh trắc/PIN) → NH gửi chạy chống gian lận real-time rồi đẩy lệnh qua NAPAS 247 tới ngân hàng của quán.
4. Trong vài giây, màn hình bạn báo "thành công" và điện thoại người bán reo báo "đã nhận 50.000đ". Bạn cầm ly đi.

Lưu ý an toàn thực tế: hãy luôn đọc tên người nhận trước khi bấm xác nhận. Kẻ gian đôi khi dán đè QR của chúng lên QR thật — bước đối chiếu tên là tuyến phòng thủ đơn giản nhất (xem thêm Rủi ro & gian lận và Bảo mật thẻ).

8. Thách thức vận hành và rủi ro

• Chống gian lận không có "phanh tay". Vì giao dịch gần như không thể hoàn tác, mọi lá chắn phải nằm trước khi lệnh đi: chấm điểm rủi ro real-time, giới hạn hạn mức theo hành vi, xác thực mạnh (SCA/sinh trắc), cảnh báo tài khoản người nhận đáng ngờ.
• APP fraud (Authorised Push Payment fraud). Đây là loại gian lận khó nhất: nạn nhân tự tay duyệt lệnh chuyển tiền vì bị lừa (giả danh công an, giả người thân, đầu tư ảo, "duyệt" một yêu cầu RtP giả). Về mặt kỹ thuật giao dịch là "hợp lệ" — người dùng đã xác thực đúng — nên phòng chống dựa nhiều vào giáo dục người dùng, cảnh báo ngữ cảnh và mô hình phát hiện bất thường theo mối quan hệ người gửi–người nhận.
• Tra soát (dispute/recall). Vì tiền đã đi, quy trình đòi lại chủ yếu là thu hồi trên tinh thần hợp tác (recall request): ngân hàng gửi nhờ ngân hàng nhận liên hệ người thụ hưởng để hoàn trả, không bảo đảm thành công. Chuẩn hóa và tăng tốc luồng tra soát là bài toán liên tục.
• Tính sẵn sàng 24/7. Đây là thay đổi văn hóa vận hành lớn nhất. Trước đây, quy trình cuối ngày (COB — Close of Business) của core banking (như T24) có thể "đóng cửa" hệ thống một lúc để chạy tính lãi, phân bổ, quyết toán. Với instant, dịch vụ không được dừng. Ngân hàng phải thiết kế online COB / non-stop processing: chạy các tác vụ cuối ngày mà vẫn phục vụ giao dịch tức thời song song, hoặc dùng cửa sổ chuyển ngày cực ngắn. Bất kỳ downtime nào cũng lập tức lộ ra với khách.

9. Xu hướng

• ISO 20022 cho instant. Các hệ thống tức thời mới ngày càng dùng chuẩn thông điệp giàu dữ liệu ISO 20022 (thay cho các định dạng cũ nghèo trường), giúp mang theo nhiều thông tin đối chiếu, chống gian lận và tự động hóa hậu kiểm.
• Interoperability xuyên biên (cross-border). Đang có nhiều nỗ lực kết nối các hệ thống instant/QR giữa các quốc gia để chuyển tiền và quét QR xuyên biên giới hoạt động như trong nước. Đây là hướng phát triển đáng theo dõi, dù mức độ triển khai còn khác nhau theo từng hành lang.

Ghi nhớ

• Instant payment = ghi có trong giây, 24/7/365, xác nhận ngay hai phía, và gần như không hoàn tác → bắt buộc chống gian lận real-time.
• "Tức thời" là với khách; quyết toán liên ngân hàng thường theo net/prefunded (deferred) với thanh khoản ký quỹ trước.
• Ở Việt Nam: NAPAS 247 là trục chuyển mạch cho chuyển nhanh theo số tài khoản / số thẻ / QR.
• QR: EMVCo có merchant-presented (MPM) và consumer-presented (CPM); VietQR là chuẩn dựa trên EMVCo do NAPAS vận hành, payload TLV với ID 38 (GUID A000000727), 01 phân biệt tĩnh (11) / động (12), 63 là CRC-16 (ISO/IEC 13239).
• RtP: người nhận yêu cầu, người trả chủ động duyệt — khác direct debit.
• Rủi ro lớn: APP fraud (nạn nhân tự duyệt), tra soát khó (chỉ recall hợp tác), và yêu cầu 24/7 không dừng (nối T24/COB kiểu non-stop).

Bài liên quan: Tổng quan thanh toán · RTGS & ACH nội địa · Rủi ro & gian lận · Bảo mật & gian lận thẻ