Credit card number: format, validation and detection

What it is

Card numbers are in the Global pack under payment cards. The PCI DSS compliance profile requires the credit_card rule to show at most the last four digits, and the other five profiles include the Global pack.

In Maskflare this is the detector credit_card, labelled "Credit card number", category payment card number, in the Global pack.

Format and layout

• 13 to 19 digits; spaces or hyphens in groups of four are common.
• The first digit is 3, 4, 5 or 6, or the first four digits fall in 2221 to 2720.
• All digits cannot be the same.

How the check works

Luhn: from the right, double every second digit, subtract 9 from results over 9, add everything, and require a multiple of 10.

Worked example

1. Doubling every second digit from the right and reducing results over 9 gives a total of 30.
2. 30 is a multiple of 10, so the number passes.

Valid and invalid examples

In running text the valid example reads, for instance, card 4111 1111 1111 1111. The invalid one is left alone: a value that fails the validator is treated as an ordinary string.

Regex and validation caveats

• Luhn alone passes one in ten random numbers; the issuer-range rule removes order numbers and timestamps that happen to pass.
• 13-digit runs are mostly product barcodes, so a bare 13-digit run needs a keyword (card, card no, amex and similar) before it. Bare 17 and 18-digit runs get the same treatment.
• Test card numbers like the one above pass the check, so they are masked too.
• Runs of 13, 17 and 18 digits with no separators are masked only when one of the detector's keywords is nearby, because those lengths are mostly barcodes and order numbers.

Words that confirm it

The formatted shape is masked without a keyword. For a run with no separators, these words count as the detector's own keywords when a word like order, invoice or phone is also close: amex, card, card no, card number, carta, carte, carte bancaire, cc, credit card, debit card, kaart, karte, kartennummer, kreditkarte, maestro, mastercard, pan, tarjeta, visa. The nearer word wins.

How to detect it in LLM traffic

Card numbers reach an LLM in support chats where a customer typed the number, in order exports pasted for analysis, and in test fixtures pasted into debugging prompts. A prompt is outside most companies' card-data environment, so the number should not be in it at all.

Maskflare replaces card numbers with tokens before the request leaves. The PCI DSS compliance profile raises the rule to at least the partial action, which leaves only the last four digits visible, and also requires the card security code rule.

If you build the detection yourself

1. Strip spaces, dots and hyphens before running any arithmetic, but remember where they were so the original text can be replaced exactly.
2. Match the shape with a pattern anchored on word boundaries, so that a long digit string is not read as several shorter Credit card number candidates.
3. Apply the layout rules from the section above. This identifier has no check digit to recompute, so expect more look-alikes than with a checksum-based format.
4. Treat a run with no separators more carefully than a formatted one: reject it when a word such as order, invoice, phone or reference is nearer to it than one of the identifier's own keywords.
5. Replace the value before the text is sent anywhere, and keep a mapping if the answer has to be restored afterwards.

How Maskflare handles it

• Protect now, Healthcare and Developer: mask (a reversible token).
• Finance - Protect now: partial (last four characters readable).
• Monitor first: alert (counted, forwarded unchanged).

The available actions are mask (reversible token), redact, partial, hash, format-preserving encryption, generalize, alert and block. Masked values are kept encrypted for 30 days so that answers can be restored, then they expire; prompts and responses are not logged. The full list of detectors is in the detector reference.

Compliance profiles that include it

All 6 compliance profiles include the Global pack, and applying them turns this detector on: HIPAA Safe Harbor, GDPR - EU/EEA, UK GDPR, PCI DSS, US personal data and Switzerland - nDSG health data. A profile is a floor: it never turns anything off or weakens a rule that is already stricter.