Thẻ 4 — Bảo mật thẻ & Chống gian lận

Bảo mật thẻ là một "cuộc chạy đua vũ trang" liên tục giữa các tổ chức phát hành/thanh toán và kẻ gian lận. Mỗi lớp phòng thủ — xác thực chủ thẻ, bảo vệ dữ liệu thẻ, chống làm giả phôi thẻ, phát hiện bất thường theo thời gian thực — giải quyết một loại tấn công khác nhau. Bài này đi sâu vào từng lớp, các loại gian lận phổ biến, cách hệ thống phát hiện gian lận hoạt động, và vòng đời khiếu nại (chargeback/dispute) khi mọi thứ đã xảy ra.

Bài trước trong series đã trình bày kiến trúc mạng lưới thẻ (four-party model: cardholder, issuer, acquirer, merchant) và luồng authorization/clearing/settlement. Bài này giả định người đọc đã nắm các vai trò đó.

3-D Secure: xác thực giao dịch online

Khi giao dịch không có thẻ vật lý hiện diện (card-not-present — CNP, ví dụ thanh toán trên website/app), merchant không thể kiểm tra chip hay chữ ký. 3-D Secure (3DS) là giao thức bổ sung một bước xác thực chủ thẻ giữa merchant và issuer. Ba "domain" trong tên gọi là: acquirer domain (merchant/acquirer), issuer domain (ngân hàng phát hành), và interoperability domain (hạ tầng của scheme kết nối hai bên).

3DS 1.0 và vì sao nó bị thay thế

Phiên bản đầu (thương hiệu như "Verified by Visa", "Mastercard SecureCode") luôn chuyển hướng người dùng sang một trang OTP/mật khẩu tĩnh cho hầu hết giao dịch. Trải nghiệm gãy khúc (redirect, popup), tỷ lệ bỏ giỏ hàng cao, không hỗ trợ tốt cho app di động, và mật khẩu tĩnh dễ bị phishing. Nó cũng gần như không truyền dữ liệu ngữ cảnh để issuer đánh giá rủi ro.

3DS 2.x: risk-based, frictionless vs challenge

3DS 2.x (EMV 3-D Secure) thiết kế lại theo hướng risk-based authentication. Merchant/acquirer gửi cho issuer một khối dữ liệu ngữ cảnh phong phú (hàng chục đến hơn trăm trường): thông tin thiết bị, địa chỉ IP, lịch sử tài khoản, giá trị đơn hàng, địa chỉ giao hàng... Cấu phần ACS (Access Control Server) phía issuer chấm điểm rủi ro và quyết định:

• Frictionless flow: rủi ro thấp → issuer xác thực ngầm dựa trên dữ liệu, không làm phiền chủ thẻ. Giao dịch được xác thực mà người dùng không phải nhập gì.
• Challenge flow: rủi ro cao hoặc quy định bắt buộc → yêu cầu một bước xác thực chủ động: OTP qua SMS/app, xác thực sinh trắc trong app ngân hàng (out-of-band), v.v.

3DS 2.x cũng hỗ trợ native app SDK (không cần redirect trình duyệt), và các luồng non-payment (ví dụ xác thực khi thêm thẻ vào ví). Ở một số khu vực (đặc biệt EU với PSD2/SCA — Strong Customer Authentication), challenge với hai yếu tố là yêu cầu pháp lý, kèm các trường hợp miễn trừ (giao dịch giá trị nhỏ, TRA — transaction risk analysis, v.v.).

Liability shift

Điểm kinh tế then chốt: khi giao dịch được xác thực thành công qua 3DS, trách nhiệm tài chính đối với gian lận CNP thường chuyển từ merchant sang issuer (liability shift). Nếu merchant không dùng 3DS, merchant thường phải gánh khoản chargeback gian lận. Đây là động lực khiến merchant triển khai 3DS dù nó có thể làm tăng ma sát.

PCI DSS: bảo vệ dữ liệu thẻ

PCI DSS (Payment Card Industry Data Security Standard) là bộ chuẩn bảo mật do PCI SSC ban hành, áp dụng cho mọi tổ chức lưu trữ, xử lý hoặc truyền dữ liệu chủ thẻ (cardholder data). Mục tiêu: giảm rò rỉ dữ liệu thẻ và gian lận phát sinh từ đó.

Phân loại dữ liệu và nguyên tắc lưu trữ

• PAN (Primary Account Number): số thẻ. Có thể lưu nhưng phải được làm cho không đọc được khi lưu trữ — mã hoá mạnh, hoặc truncation (chỉ hiển thị một phần, ví dụ 6 số đầu + 4 số cuối), hoặc hashing/tokenization.
• Sensitive Authentication Data (SAD): dữ liệu xác thực nhạy cảm — CVV/CVC (mã 3-4 số), full track data (dữ liệu dải từ), PIN. Nguyên tắc bất di bất dịch: KHÔNG được lưu trữ SAD sau khi authorization hoàn tất, kể cả ở dạng mã hoá.

Các kỹ thuật cốt lõi

• Mã hoá PAN: mã hoá khi lưu (at rest) và khi truyền (in transit), quản lý khoá nghiêm ngặt (key management, rotation).
• Tokenization: thay PAN bằng một "token" không có giá trị nếu bị lộ ra ngoài kho token. Merchant lưu token thay vì PAN thật; PAN thật chỉ nằm trong một vault được bảo vệ chặt. Đây cũng là nền tảng của network tokenization (token do scheme phát hành cho ví điện tử — như thẻ trong điện thoại).
• Scope reduction (giảm phạm vi): nguyên tắc quan trọng nhất về chi phí tuân thủ. Càng ít hệ thống "chạm" vào dữ liệu thẻ thô, phạm vi kiểm toán PCI càng nhỏ. Do đó nhiều merchant dùng hosted payment page hoặc trường nhập thẻ được iframe hoá từ payment gateway, để PAN không bao giờ đi qua server của merchant.

Ngoài ra PCI DSS còn bao trùm phân vùng mạng, kiểm soát truy cập theo need-to-know, ghi log và giám sát, quét lỗ hổng và penetration testing, chính sách bảo mật. Mức độ yêu cầu tuân thủ (SAQ hay full audit) phụ thuộc số lượng giao dịch (merchant levels).

EMV: chống làm giả thẻ (counterfeit)

EMV (Europay, Mastercard, Visa) là chuẩn thẻ chip. Trước EMV, thẻ chỉ có dải từ (magnetic stripe) chứa dữ liệu tĩnh — ai đọc được dải từ (skimming) đều có thể sao chép ra một thẻ giả dùng được (counterfeit).

EMV chống điều này bằng mật mã động. Chip là một vi xử lý an toàn chứa khoá bí mật không thể trích xuất. Với mỗi giao dịch, chip tạo ra một cryptogram động (ARQC — Authorization Request Cryptogram) dựa trên khoá bí mật, dữ liệu giao dịch và một bộ đếm giao dịch (ATC — Application Transaction Counter). Issuer xác minh cryptogram này.

Vì cryptogram thay đổi theo từng giao dịch và không thể tính ngược ra khoá, kẻ gian không thể sao chép chip từ dữ liệu quan sát được. ATC tăng dần cũng giúp phát hiện replay (một cryptogram cũ dùng lại sẽ có ATC không hợp lệ).

Kết quả thực tế: EMV làm sụp đổ mô hình gian lận counterfeit tại điểm bán (POS). Nhưng nó không giải quyết CNP — chip không tham gia vào giao dịch online. Đây chính là lý do khi các thị trường chuyển sang EMV, gian lận thường "dịch chuyển" (fraud migration) sang kênh CNP, làm tăng tầm quan trọng của 3DS và tokenization.

Contactless và giới hạn

Thanh toán không tiếp xúc (contactless, NFC) dùng cùng nền tảng mật mã EMV nhưng qua sóng vô tuyến tầm gần. Vì tiện lợi và nhanh, contactless thường có ngưỡng giao dịch không cần xác thực (CVM limit): dưới ngưỡng, chạm là xong (không cần PIN/chữ ký); trên ngưỡng, yêu cầu PIN hoặc xác thực trên thiết bị.

Rủi ro tiềm ẩn (chạm trộm, đọc lén) được kiểm soát bằng: tầm hoạt động rất ngắn (vài cm), vẫn dùng cryptogram động EMV (không sao chép được), giới hạn số tiền mỗi lần và giới hạn số lần liên tiếp trước khi buộc phải xác thực. Với thẻ trong điện thoại (device token + xác thực sinh trắc mở khoá), ngưỡng thường cao hơn hoặc không áp dụng vì mỗi giao dịch đã được xác thực bằng thiết bị.

Các loại gian lận thẻ

Ba nhóm cần lưu ý về bản chất:

• Account takeover nguy hiểm vì kẻ gian hành động "như chính chủ" — vượt qua nhiều lớp xác thực bằng chính thông tin/OTP của nạn nhân. Phòng thủ nghiêng về giám sát thay đổi tài khoản, không chỉ giám sát giao dịch.
• BIN attack không nhắm một nạn nhân cụ thể mà "quét" hàng loạt tổ hợp số thẻ; chống bằng velocity checks và rate limiting ở tầng authorization/gateway.
• Friendly fraud không phải tấn công kỹ thuật mà là lạm dụng cơ chế chargeback; chống bằng chứng cứ giao dịch (bằng chứng giao hàng, log 3DS, lịch sử tài khoản) để representment.

Phát hiện gian lận

Hệ thống phát hiện gian lận hiện đại thường lai ghép hai lớp bổ trợ nhau.

Rule-based (luật)

Các luật tường minh, dễ giải thích, chạy nhanh, dùng cho những mẫu đã biết:

• Velocity checks: đếm số giao dịch/tổng số tiền trên một thẻ hoặc thiết bị trong cửa sổ thời gian (ví dụ > N giao dịch trong 1 phút → chặn/thử thách).
• Ngưỡng số tiền bất thường so với hành vi lịch sử.
• Geo/velocity địa lý: hai giao dịch ở hai nơi cách nhau không thể di chuyển kịp ("impossible travel").
• Danh sách đen/trắng (thiết bị, merchant, quốc gia rủi ro).

Ưu điểm: minh bạch, dễ tuân thủ và audit. Nhược điểm: cứng nhắc, kẻ gian dễ dò và né ngưỡng, và tạo nhiều false positive nếu đặt chặt.

Machine learning

Mô hình học từ dữ liệu lịch sử để chấm điểm rủi ro (risk score) cho từng giao dịch theo thời gian thực. Các nhóm đặc trưng (feature) tiêu biểu:

• Tần suất/velocity: số giao dịch gần đây, khoảng cách thời gian giữa các giao dịch.
• Địa điểm bất thường: lệch so với vùng địa lý/merchant quen thuộc của chủ thẻ.
• Số tiền: so với phân phối chi tiêu lịch sử của tài khoản.
• Đặc trưng thiết bị/kênh: fingerprint thiết bị, IP, kênh (POS/CNP/ATM).
• Đặc trưng đồ thị: liên kết giữa thẻ — merchant — thiết bị (phát hiện vòng gian lận có tổ chức).

Thực tế thường kết hợp: luật xử lý các trường hợp rõ ràng và tuân thủ; ML bắt các mẫu tinh vi và mới nổi. Điểm rủi ro được đưa vào một cơ chế quyết định (approve / step-up challenge qua 3DS / decline / gửi review thủ công), có xét đến sự đánh đổi giữa tỷ lệ bắt gian lận và ma sát/false positive với khách hàng thật.

Liên hệ danh mục AI: bài toán fraud detection là ví dụ kinh điển của phân loại mất cân bằng lớp (gian lận là thiểu số), cần chú trọng precision/recall và chi phí sai lệch, feature engineering theo cửa sổ thời gian, và giám sát drift theo thời gian thực. Xem thêm các bài trong danh mục AI/ML về mô hình phân loại và giám sát mô hình.

Vòng đời chargeback / dispute

Khi chủ thẻ cho rằng một giao dịch là sai/gian lận, cơ chế chargeback cho phép đảo ngược khoản tiền qua các bên. Quy trình do scheme (Visa/Mastercard...) quy định chặt về thời hạn, bằng chứng và reason code (mã lý do). Các reason code cụ thể tùy theo quy định của từng scheme — bài này không liệt kê mã cụ thể để tránh sai lệch; chỉ mô tả các nhóm lý do phổ biến: gian lận (giao dịch không được ủy quyền), lỗi xử lý (trùng, sai số tiền), hàng/dịch vụ không nhận được hoặc không đúng mô tả, và tranh chấp authorization.

Các bước điển hình:

1. Cardholder khiếu nại với issuer về giao dịch.
2. Issuer khởi tạo chargeback với một reason code, ghi nợ tạm thời cho acquirer/merchant.
3. Representment: acquirer chuyển yêu cầu về merchant; nếu merchant có bằng chứng giao dịch hợp lệ (bằng chứng giao hàng, log 3DS/liability shift, chữ ký, lịch sử...), họ nộp bằng chứng để phản bác và đòi lại tiền.
4. Pre-arbitration / arbitration: nếu hai bên vẫn không thống nhất, tranh chấp leo thang lên scheme; scheme (arbitration) ra phán quyết cuối cùng dựa trên quy tắc và bằng chứng. Bên thua thường chịu phí.

Friendly fraud là kịch bản khó xử nhất trong vòng đời này: chủ thẻ thật khiếu nại một giao dịch họ thực sự đã thực hiện. Vũ khí của merchant là bằng chứng representment; vũ khí phòng ngừa là 3DS (liability shift) và lưu vết giao dịch đầy đủ.

Use case ngân hàng: hệ thống fraud realtime dựa trên luồng giao dịch

Kiến trúc phát hiện gian lận thời gian thực điển hình dựng trên nền tảng streaming:

• CDC (Change Data Capture) hoặc feed trực tiếp từ hệ thống authorization bơm mỗi giao dịch vào một topic Kafka.
• Một lớp xử lý dòng (stream processing) tính đặc trưng theo cửa sổ thời gian (velocity, tổng số tiền trong 1 phút/1 giờ, số quốc gia trong ngày) và tra cứu trạng thái (profile khách hàng, danh sách rủi ro).
• Mô hình chấm điểm (rule engine + ML model serving) trả về điểm rủi ro trong độ trễ mili-giây, đủ để tác động ngược vào quyết định authorization (approve / step-up 3DS / decline).
• Các giao dịch điểm cao được đẩy vào hàng đợi review thủ công và vòng phản hồi (feedback loop) để gán nhãn, tái huấn luyện mô hình.

Đây là điểm bắc cầu tự nhiên sang các bài về Kafka/CDC (streaming, exactly-once, stateful processing) và AI/ML (feature store, model serving realtime, giám sát drift) trong knowledge base.

Để minh hoạ một luật velocity đơn giản (loại phát hiện "một tài khoản có nhiều giao dịch/tổng lớn trong khoảng thời gian ngắn") mà bạn có thể thử ngay:

▶ Chạy được trong SQL Builder

SELECT
    t.account_id,
    c.full_name,
    COUNT(*)          AS txn_count,
    SUM(t.amount)     AS total_amount,
    MIN(t.created_at) AS first_txn,
    MAX(t.created_at) AS last_txn
FROM transactions t
JOIN accounts  a ON a.id = t.account_id
JOIN customers c ON c.id = a.customer_id
GROUP BY t.account_id, c.full_name
HAVING COUNT(*) >= 5
    OR SUM(t.amount) >= 50000000
ORDER BY total_amount DESC;

Truy vấn trên gom giao dịch theo tài khoản, và gắn cờ những tài khoản có từ 5 giao dịch trở lên hoặc tổng số tiền lớn — một xấp xỉ thô của velocity check. Trong hệ thống thật, logic này chạy trên luồng streaming với độ trễ thấp, có ràng buộc cửa sổ thời gian (ví dụ WHERE t.created_at >= NOW() - INTERVAL '1 hour') và nhiều đặc trưng hơn, nhưng ý tưởng cốt lõi giống nhau: đo mật độ và bất thường của hành vi trong một cửa sổ thời gian.

Tóm tắt

• 3DS 2.x xác thực chủ thẻ trong giao dịch CNP theo hướng risk-based: rủi ro thấp đi frictionless, rủi ro cao đi challenge (OTP/sinh trắc); xác thực thành công thường kéo theo liability shift sang issuer.
• PCI DSS bảo vệ dữ liệu thẻ: không bao giờ lưu CVV/SAD sau authorization, mã hoá/tokenize PAN, và giảm scope để hạ chi phí và rủi ro tuân thủ.
• EMV dùng cryptogram động của chip để chống làm giả thẻ (counterfeit) tại POS, nhưng không bảo vệ kênh online — nên gian lận có xu hướng dịch chuyển sang CNP.
• Các loại gian lận trải rộng từ kỹ thuật (counterfeit, BIN attack) đến social engineering (phishing, ATO) và lạm dụng quy trình (friendly fraud); mỗi loại có dấu hiệu và cách phòng thủ riêng.
• Phát hiện gian lận kết hợp rule-based (velocity, ngưỡng, danh sách) với machine learning (điểm rủi ro theo đặc trưng thời gian/địa điểm/số tiền), cân bằng giữa bắt gian lận và ma sát khách hàng.
• Vòng đời chargeback: khiếu nại → issuer khởi tạo với reason code → representment của merchant/acquirer → arbitration của scheme; reason code cụ thể theo quy định từng scheme.

Tự kiểm tra

1. Phân biệt frictionless flow và challenge flow trong 3DS 2.x; điều gì quyết định giao dịch đi theo luồng nào?
2. Vì sao PCI DSS cấm lưu CVV nhưng cho phép lưu PAN (dưới điều kiện nào)? Tokenization giúp giảm scope ra sao?
3. Cryptogram động của EMV chống được kiểu gian lận nào và không chống được kiểu nào? Giải thích khái niệm fraud migration.
4. Cho một tài khoản phát sinh 40 lần authorization thất bại giá trị nhỏ trong 2 phút — nhiều khả năng đây là loại gian lận nào, và velocity check chặn nó thế nào?
5. Mô tả các bước của một chargeback từ khi chủ thẻ khiếu nại đến arbitration; representment là gì và merchant dùng bằng chứng nào?
6. Friendly fraud khác các loại gian lận khác ở điểm cốt lõi nào, và liability shift của 3DS giúp merchant ra sao?

Đọc tiếp

Thẻ 5 — Nghiệp vụ thẻ tín dụng