Thẻ 3 — Phát hành & Vòng đời thẻ (Card Issuing)

Giới thiệu

Phát hành thẻ (card issuing) là toàn bộ chuỗi hoạt động mà một tổ chức phát hành (issuer) — thường là ngân hàng — thực hiện để biến một yêu cầu của khách hàng thành một công cụ thanh toán hợp lệ trên mạng lưới thẻ (Visa, Mastercard, JCB, NAPAS...). Đây không chỉ là chuyện "in ra một tấm nhựa": nó bao gồm việc tạo một tài khoản thẻ trên hệ thống lõi, sinh ra số thẻ (PAN) tuân thủ chuẩn quốc tế, cá thể hoá dữ liệu vào chip, phân phối vật lý hoặc số hoá, và quản trị toàn bộ vòng đời cho tới khi thẻ bị đóng.

Bài này đi sâu vào quy trình phát hành, cấu trúc số thẻ, chip EMV, tokenization cho ví điện tử, và các trạng thái trong vòng đời thẻ. Trọng tâm là hiểu bản chất kỹ thuật ở mức khái niệm, đủ để một kỹ sư backend hoặc chuyên viên nghiệp vụ ngân hàng số nắm được cách hệ thống vận hành mà không cần đi vào tài liệu mật của các tổ chức thẻ.

Quy trình phát hành thẻ

Một quy trình phát hành điển hình đi qua các bước tuần tự, mỗi bước có ràng buộc rủi ro và tuân thủ riêng.

1. Đăng ký (Application)

Khách hàng nộp yêu cầu qua kênh quầy, internet banking, hoặc ứng dụng di động. Ở giai đoạn này, hệ thống thu thập thông tin định danh (eKYC/KYC), loại thẻ mong muốn (ghi nợ — debit, tín dụng — credit, trả trước — prepaid), và với thẻ tín dụng còn kèm dữ liệu để thẩm định hạn mức.

2. Phê duyệt (Approval / Underwriting)

• Với thẻ ghi nợ, phê duyệt thường đơn giản: chỉ cần tài khoản thanh toán hợp lệ và KYC đạt.
• Với thẻ tín dụng, cần thẩm định tín dụng (credit scoring), kiểm tra CIC, xác định hạn mức và lãi suất.
• Bước này gồm cả sàng lọc chống rửa tiền (AML) và danh sách trừng phạt (sanctions screening).

3. Tạo tài khoản thẻ (Card Account Creation)

Hệ thống quản lý thẻ (card management system — CMS) tạo một card account liên kết với tài khoản khách hàng. Đây là lúc sinh ra PAN (Primary Account Number), gán BIN phù hợp với sản phẩm/thương hiệu, sinh ngày hết hạn, CVV/CVC (mã kiểm tra), và các khoá mật mã (keys) phục vụ chip. Lưu ý: CMS chỉ tạo dữ liệu logic; dữ liệu nhạy cảm được bảo vệ trong HSM (Hardware Security Module).

4. Cá thể hoá (Personalization)

Cá thể hoá là bước ghi dữ liệu riêng của chủ thẻ lên phôi thẻ:

• Thẻ vật lý: in dập tên, số thẻ, in dải từ (magnetic stripe), và nạp dữ liệu vào chip EMV (perso). Việc này thực hiện tại nhà máy cá thể hoá (perso bureau) được PCI chứng nhận, dùng file cá thể hoá được mã hoá.
• Thẻ ảo (virtual card): không có phôi vật lý; dữ liệu thẻ được tạo và lưu logic, có thể hiển thị an toàn trong app hoặc đẩy trực tiếp vào ví điện tử.

5. Giao thẻ (Delivery)

Thẻ vật lý được gửi qua đường bưu điện/chuyển phát hoặc giao tại quầy. PIN thường được gửi tách kênh (PIN mailer hoặc PIN động qua app) để tránh lộ đồng thời cả thẻ và PIN. Thẻ ảo được "giao" ngay lập tức trong ứng dụng.

6. Kích hoạt (Activation)

Thẻ được phát ở trạng thái chưa hoạt động để giảm rủi ro chặn bắt trên đường vận chuyển. Khách hàng kích hoạt qua app, IVR, hoặc lần giao dịch đầu tiên có xác thực. Sau kích hoạt, thẻ chuyển sang trạng thái active và có thể giao dịch.

Cấu trúc số thẻ (PAN)

PAN là chuỗi số in trên mặt thẻ, thường 16 chữ số (có thể 13–19 tuỳ mạng). PAN được chuẩn hoá theo ISO/IEC 7812 và gồm ba phần.

BIN / IIN

Sáu tới tám chữ số đầu là IIN (Issuer Identification Number), trước đây quen gọi là BIN (Bank Identification Number). Đây là "tem" nhận diện tổ chức phát hành và thương hiệu. Chữ số đầu tiên (MII — Major Industry Identifier) cho biết ngành: 4 là Visa, 5 (hoặc 2221–2720) là Mastercard, 3 là travel/entertainment (Amex, JCB, Diners)... Hệ thống chuyển mạch dùng BIN để định tuyến giao dịch về đúng issuer.

Số tài khoản (Account Number)

Các chữ số ở giữa (giữa BIN và chữ số cuối) là individual account identifier — định danh tài khoản thẻ cụ thể trong dải mà issuer quản lý. Đây KHÔNG phải số tài khoản thanh toán của khách hàng; nó chỉ là mã nội bộ mapping tới card account.

Luhn check digit

Chữ số cuối cùng là check digit tính theo thuật toán Luhn (mod 10). Nó không mang thông tin, chỉ dùng để bắt lỗi gõ nhầm/nhập sai. Cách tính:

1. Từ phải sang trái (bỏ chữ số kiểm tra), nhân đôi mỗi chữ số ở vị trí chẵn.
2. Nếu tích ≥ 10, cộng hai chữ số của nó (hoặc trừ 9).
3. Cộng tất cả lại; check digit là số làm tổng chia hết cho 10.

Ví dụ (số minh hoạ, đã che): một PAN dạng 4* * * * * * * * * * * 1234. Sáu số đầu 4XXXXX là BIN của một issuer Visa, phần giữa là account identifier, và 4 cuối là Luhn check digit. Trong hệ thống thực tế, ta chỉ hiển thị dạng che (masked): 411111******1111 — giữ 6 số đầu và 4 số cuối, phần giữa thay bằng dấu sao. Đây là mức che phổ biến được PCI DSS cho phép hiển thị.

Thẻ vật lý vs thẻ ảo

Tiêu chí	Thẻ vật lý	Thẻ ảo
Phôi	Có (nhựa + chip)	Không
Thời gian phát	Ngày tới tuần	Tức thì
Chi phí sản xuất	Cao hơn	Gần như bằng 0
Dùng tại POS/ATM	Có (chip/contactless/từ)	Chỉ khi đẩy vào ví NFC
Thanh toán online	Có	Có
Rủi ro thất lạc vận chuyển	Có	Không
Kiểm soát/huỷ nhanh	Chậm hơn	Rất nhanh (tức thời trong app)

Ngân hàng số hiện đại thường phát thẻ ảo trước để khách dùng ngay, rồi gửi thẻ vật lý sau nếu khách cần.

Chip EMV — vì sao an toàn hơn dải từ

EMV (Europay, Mastercard, Visa) là chuẩn cho thẻ chip. Điểm khác biệt cốt lõi so với dải từ:

• Dải từ (magnetic stripe) lưu dữ liệu tĩnh. Ai đọc/sao chép được dải từ là có thể tạo thẻ giả (skimming/cloning) vì dữ liệu không đổi qua các lần giao dịch.
• Chip EMV sinh dữ liệu động (dynamic data) cho mỗi giao dịch. Chip chứa khoá bí mật (không rời khỏi chip) và tính một cryptogram (ARQC — Authorization Request Cryptogram) cho từng lần dùng, dựa trên khoá, số tiền, một bộ đếm giao dịch (ATC) và số ngẫu nhiên. Vì cryptogram khác nhau mỗi lần, dữ liệu chụp được ở lần này vô dụng cho lần sau.

Ở mức khái niệm: issuer (hoặc HSM của issuer) xác minh cryptogram để chắc chắn thẻ là thật và chưa bị replay. Đây là lý do EMV chống clone hiệu quả hơn dải từ rất nhiều.

Contactless / NFC

Contactless dùng NFC để giao tiếp không tiếp xúc. Về bảo mật, contactless dựa trên cùng nền tảng mật mã EMV (còn gọi là EMV Contactless / tap-to-pay), nên vẫn sinh cryptogram động cho mỗi lần chạm — an toàn tương đương chip tiếp xúc, chỉ khác giao diện vật lý. Giới hạn số tiền không cần PIN (contactless limit) là biện pháp kiểm soát rủi ro bổ sung.

Tokenization

Tokenization thay thế PAN thật bằng một token — một dãy số thay thế, thường vẫn có định dạng giống PAN (16 số, pass Luhn) nhưng không phải PAN thật và chỉ dùng được trong ngữ cảnh hạn chế.

Vì sao cần tokenization

Nếu PAN thật bị lộ (rò rỉ merchant, ví bị hack), kẻ xấu có thể dùng ở bất cứ đâu. Token thì bị giới hạn phạm vi (domain restriction): chỉ hợp lệ với một thiết bị, một merchant, hoặc một kênh cụ thể. Lộ token ít nguy hiểm hơn nhiều, và token có thể bị thu hồi độc lập mà không cần đổi thẻ vật lý.

Network token vs PSP token

• Network token do chính mạng thẻ phát hành thông qua dịch vụ như Visa Token Service (VTS) hoặc Mastercard Digital Enablement Service (MDES). Đây là loại token dùng cho Apple Pay / Google Pay / Samsung Pay và cho "card-on-file" tại merchant lớn. Khi khách thêm thẻ vào ví, mạng thẻ sinh một DPAN (Device PAN) gắn với thiết bị, kèm khoá để sinh cryptogram động — nên thanh toán ví về bản chất cũng là EMV token với dữ liệu động. Network token có thể tự cập nhật khi thẻ được tái phát hành (lifecycle management), nên khách không phải nhập lại thẻ.
• PSP token (còn gọi acquirer/gateway token, hay merchant vault token) do nhà cung cấp thanh toán (payment service provider như Stripe, Adyen, các cổng nội địa) sinh ra để lưu thẻ hộ merchant. Merchant lưu token thay vì PAN, giảm phạm vi tuân thủ PCI. Tuy nhiên PSP token thường chỉ có ý nghĩa trong hệ thống của PSP đó, không mang tính "liên mạng" và không tự sinh cryptogram động như network token.

Tóm lại: network token gắn với mạng thẻ, an toàn cao, dùng cho ví và card-on-file liên mạng; PSP token gắn với một PSP, chủ yếu để merchant khỏi phải chạm vào PAN thật.

Vòng đời thẻ & các trạng thái

Một thẻ trải qua nhiều trạng thái từ khi phát tới khi đóng. CMS quản lý các chuyển trạng thái này với quy tắc chặt chẽ.

Trạng thái	Ý nghĩa	Có giao dịch được?
issued	Đã phát nhưng chưa kích hoạt	Không
active	Đang hoạt động bình thường	Có
blocked (temp)	Khoá tạm thời (khách tự khoá / nghi ngờ)	Không (có thể mở lại)
hotlisted	Vào danh sách đen (mất cắp, gian lận)	Không (không mở lại)
expired	Hết hạn theo ngày trên thẻ	Không
reissued	Đã tái phát hành thẻ mới thay thế	Thẻ cũ: không
closed	Đóng vĩnh viễn	Không

Diễn giải các chuyển trạng thái

• Kích hoạt: issued → active.
• Khoá tạm / mở lại: active ⇄ blocked. Dùng khi khách để quên thẻ, đi du lịch, hoặc hệ thống phát hiện bất thường nhẹ. Có thể đảo ngược.
• Khoá vĩnh viễn / hotlist: active/blocked → hotlisted. Khi mất cắp hoặc xác nhận gian lận, thẻ bị đưa vào danh sách nóng — mọi giao dịch bị từ chối và không thể khôi phục. Đây là bước không thể đảo ngược.
• Hết hạn: active → expired khi qua ngày hết hạn. Thông thường issuer đã chủ động tái phát hành (reissue) một thẻ mới với PAN thường giữ nguyên nhưng đổi ngày hết hạn và CVV, gửi cho khách trước khi thẻ cũ hết hạn.
• Gia hạn / tái phát hành: khi hết hạn, hỏng chip, hoặc đổi thương hiệu. Nếu chỉ gia hạn (renew) thì giữ PAN; nếu thay thế do mất cắp thì thường đổi PAN mới để cắt đứt PAN cũ đã lộ.
• Thay thế khi mất/cắp: khách báo mất → thẻ cũ hotlisted → issuer phát thẻ mới (issued) với PAN mới → khách kích hoạt.
• Đóng: closed khi khách hủy sản phẩm hoặc ngân hàng đóng tài khoản. Vĩnh viễn.

Điểm quan trọng về tokenization trong vòng đời: khi thẻ bị hotlist/đổi PAN, các network token liên kết cũng phải bị thu hồi hoặc cập nhật, nếu không ví điện tử sẽ trỏ tới PAN đã chết. Đây là lý do lifecycle management của network token rất giá trị.

PIN & mã hoá

PIN không bao giờ được lưu ở dạng rõ. Khi khách nhập PIN tại ATM/POS, PIN được mã hoá ngay trong thiết bị (PIN pad) thành PIN block, truyền dưới dạng đã mã hoá, và chỉ được xác minh trong HSM. Toàn bộ khoá dùng để mã hoá PIN được quản lý theo mô hình khoá phân cấp và không lộ ra ứng dụng.

Với chip EMV, có cơ chế offline PIN (chip tự xác minh PIN) và online PIN (PIN block gửi về issuer xác minh). Cả hai đều không để PIN ở dạng thô trong hệ thống.

Dữ liệu nhạy cảm & PCI DSS

Chuẩn PCI DSS quy định cách xử lý dữ liệu chủ thẻ:

• PAN: phải được che khi hiển thị (chỉ được để tối đa 6 số đầu + 4 số cuối) và mã hoá / băm / tokenize khi lưu trữ. Không lưu PAN dạng rõ.
• CVV / CVC / CVV2: tuyệt đối không được lưu sau khi giao dịch được ủy quyền — kể cả đã mã hoá. Đây là dữ liệu xác thực nhạy cảm (SAD).
• Track data (dữ liệu dải từ đầy đủ) và PIN block: cũng không được lưu sau ủy quyền.

Nguyên tắc chung: giảm tối đa phạm vi hệ thống "chạm" vào PAN thật (giảm PCI scope), và đây chính là động lực để dùng tokenization ở cả phía issuer lẫn merchant.

Use case: ngân hàng số phát hành thẻ ảo tức thì

Một ngân hàng số (neobank) muốn khách "mở app — có thẻ dùng ngay". Luồng điển hình:

1. Khách hoàn tất eKYC trong app.
2. Backend gọi CMS tạo card account, sinh PAN + expiry + CVV, tất cả dữ liệu nhạy cảm nằm trong vùng bảo vệ (HSM / nhà cung cấp issuing-as-a-service tuân thủ PCI).
3. Thẻ ảo được tạo ở trạng thái active ngay (không cần vận chuyển).
4. App hiển thị thông tin thẻ qua giao diện an toàn (thường render qua iframe/SDK của nhà cung cấp để backend của bank không chạm PAN thật — giảm PCI scope).
5. Khách push thẻ vào Apple Pay/Google Pay: hệ thống gọi VTS/MDES sinh network token (DPAN), khách chạm điện thoại là thanh toán được — dùng cryptogram động, an toàn.
6. Nếu khách nghi ngờ lộ thẻ, có thể freeze tức thì (blocked) trong app, hoặc yêu cầu đổi số thẻ ảo mới chỉ trong vài giây — điều bất khả thi với thẻ vật lý.

Đây là minh hoạ rõ nét cho việc thẻ ảo + tokenization + issuing-as-a-service cho phép trải nghiệm tức thì mà vẫn đảm bảo an toàn và tuân thủ.

Tóm tắt

• Phát hành thẻ đi qua chuỗi: đăng ký → phê duyệt → tạo tài khoản thẻ (sinh PAN) → cá thể hoá → giao → kích hoạt.
• PAN gồm BIN/IIN (nhận diện issuer), account identifier (định danh nội bộ), và Luhn check digit (bắt lỗi nhập).
• Chip EMV an toàn hơn dải từ nhờ dữ liệu động và cryptogram sinh riêng mỗi giao dịch; contactless dùng cùng nền tảng.
• Tokenization thay PAN bằng token giới hạn phạm vi: network token (mạng thẻ, dùng cho ví & card-on-file) khác PSP token (nhà thanh toán, lưu thẻ hộ merchant).
• Vòng đời thẻ trải các trạng thái issued/active/blocked/hotlisted/expired/reissued/closed, với khoá tạm đảo ngược được còn hotlist thì không.
• PIN luôn mã hoá và xác minh trong HSM; PCI DSS cấm lưu CVV/track/PIN và bắt buộc che + mã hoá PAN.
• Ngân hàng số dùng thẻ ảo + tokenization để phát hành tức thì mà vẫn giảm PCI scope.

Tự kiểm tra

1. PAN gồm những thành phần nào và Luhn check digit dùng để làm gì?
2. Vì sao chip EMV chống clone tốt hơn dải từ? "Dữ liệu động" và "cryptogram" nghĩa là gì ở mức khái niệm?
3. Phân biệt network token và PSP token; cái nào dùng cho Apple/Google Pay và vì sao?
4. Khi khách báo mất thẻ, các trạng thái chuyển ra sao và điều gì xảy ra với network token đã liên kết?
5. Theo PCI DSS, dữ liệu nào tuyệt đối không được lưu sau khi ủy quyền, và PAN được phép hiển thị ở mức nào?
6. Vì sao ngân hàng số có thể phát thẻ ảo tức thì mà backend của họ vẫn không cần "chạm" vào PAN thật?

Đọc tiếp

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