Why a Credit Card Number Was Not Detected

Data type: Payment card data (PAN, CVV/CVC/CID, card images) Article type: Known behavior / troubleshooting

Issue

A payment card number was present in scanned content but produced no finding, or scored lower than expected. Most often reported during PCI validation testing, or after a card table screenshot fails to trigger.

Environment

All content integrations and endpoint scan paths. Applies to the native credit card detector. The causes below describe model and pipeline behavior and do not apply to custom regex detectors, which match purely on pattern.

Before troubleshooting: test the sample in the Nightfall Playground

The Playground returns the model's confidence score for any text you paste, independent of your policies and detection rules. It is the fastest way to separate a detection question from a configuration question.

→ playground.nightfall.ai

Sanity-check your test card first

Before concluding anything is a miss, confirm the number is actually a valid card. Paste it into Claude or ChatGPT and ask:

"Is this a valid credit card number? Check the Luhn checksum, and tell me which network the prefix belongs to and whether the digit count matches that network's real card length."

You can also test your credit card number here: 

https://www.bincodes.com/bin-checker/

An invalid or wrong-length test number is the most common cause of a reported miss, and this check takes seconds.

Cause and resolution

Work these in order. Causes 1 through 3 account for most reported misses during validation testing.

1. The number fails a validation stage

Three validation gates run before any scoring. Failing any one drops the candidate entirely — no confidence score is produced, and lowering your policy threshold will not change the result.

a. Luhn checksum. If the number does not satisfy Luhn, it is not a card number and nothing should fire. Note: 10% of all 16 digit numbers pass the Luhn checksum so other checks are necessary.

b. Card number prefix and exact length must agree. The number must match a known network prefix and one of that network's valid lengths. A prefix with the wrong digit count is dropped.

c. The issuer prefix must exist in our BIN/IIN reference data. The leading 6 to 9 digits are checked against a Bank Identification Number dataset. A number that passes Luhn and has a plausible network prefix will still be dropped if its issuer range is not a real, issued one.

Internal note. Gate (c) is the usual reason a hand-generated or synthetic "Luhn-valid" test card produces nothing. Luhn generators produce checksum-valid numbers with arbitrary issuer prefixes, which then fail the BIN lookup. Explain this as "the number must belong to a real issuer range," not as a published blocklist — there is no test-card blocklist in the pipeline.

Resolution: Test with a number that is Luhn-valid, matches a real network prefix at that network's correct length, and carries a genuine issuer prefix. Ask your payments team for a de-provisioned real BIN rather than generating a number.

You can also test your credit card number here: 

https://www.bincodes.com/bin-checker/

2. The card was repeated, so it was treated as ordinary grouped numbers

A card number embedded in a longer run of same-length, same-delimiter digit groups is filtered out. The assumption is that a long uniform sequence of digit groups is tabular or machine-generated data, not a card.

This is the single most common self-inflicted miss in validation testing, because the instinct when testing is to paste the number repeatedly:

4242 4242 4242 4242 4242 4242        → filtered, reads as one long grouped sequence

1111 2222 4242 4242 4242 4242        → filtered, the card sits inside a longer run

Credit card: 4242 4242 4242 4242     → evaluated normally

Note that this filter only applies to candidates with uniform group lengths. Numbers with no delimiter at all, or with irregular grouping such as American Express (4-6-5), are not affected.

Resolution: Test one card per line with surrounding text. Do not paste the same number several times in a row, and do not place test cards in a column of other same-width numbers.

3. Delimiters were inconsistent

Delimiters within a single number must be consistent. Supported separators are the space, the hyphen, eight Unicode dash variants, and no delimiter at all — but they cannot be mixed within one number.

4242-4242-4242-4242     → evaluated

4242 4242 4242 4242     → evaluated

4242424242424242        → evaluated

4242-4242 4242-4242     → filtered, mixed delimiters

Resolution: Use one delimiter consistently. If real customer data legitimately mixes delimiters, capture a sample — that is a detector enhancement request.

4. No contextual clue near the value

Card detection starts from a base score and adds evidence. Context is by far the largest single contributor, which is why a bare card number frequently lands below Very Likely while the same number with a label clears it.

Recognized context includes the network and card-related keywords — credit, visa, mastercard, amex, discover, jcb, diners, maestro, instapayment, card, cc, ccn, american express, withdrawal, purchase, cvv, cvc, csc, exp, expiration — and also a standalone expiration date in MM/YY form, where the year falls within a window around the current year.

Two limitations worth knowing:

• A date in full MM/DD/YYYY or MM/DD/YY form does not count as expiration context. This is deliberate, so that ordinary calendar dates near a number do not inflate confidence.

Resolution: Add a contextual clue to your test sample. Where bare card numbers must be caught in production, set the rule to Likely. If your environment uses non-English card terminology, share samples — context vocabulary can be extended.

5. The number appeared in a field labeled as an ID

If the surrounding field label looks like an identifier field — id, id#, idno, idnumber — the candidate is filtered out. This exists because internal record IDs are a large false positive source, but it means a genuine card number stored under an ID-like column or key will be suppressed.

card_number: 4242 4242 4242 4242    → evaluated

id: 4242 4242 4242 4242             → filtered

Resolution: This is a known tradeoff. If a customer legitimately stores card data in an ID-named field, capture the sample and route it to Detection — do not attempt to tune around it with a threshold change, which will not help.

6. A negation preceded the context keyword

If a negating word such as "not" or "no" precedes the card keyword, the candidate is dropped rather than merely downweighted.

This is not a credit card: 4242 4242 4242 4242    → filtered

This matters mainly for test content and documentation, where explanatory prose often negates. It is rarely the cause in production data.

7. The number was inside a URL, path, email address, or larger number

Candidates are removed when they fall inside a URL, a URL parameter, a file path, an email address local part, or a longer floating-point number. Test data assembled as a query string or a path fragment will not produce findings.

8. The credit card number was in a table and the column header was lost

When a card number sits in a table, the column header — CCN, Card Number, CC# — is usually the only context the detector has. Whether that header survives depends on the file type.

Header preserved: CSV, Excel, and other structured data files. Each value stays tied to its column, so the detector effectively reads:

email:          jwhite@domain.com
cc_type:        m
CCN:            5270-4267-6450-5516
cc_cvc:         123
cc_expiredate:  2010/06/25

CCN sits right next to the number. Scores Very Likely.

Header lost: images of tables and HTML tables. Screenshots, photos, PDFs, and HTML flatten into a single run of text:

jwhite@domain.com m 5270-4267-6450-5516 123 2010/06/25

The header row appears once, at the top. Every row after it is pushed further away:

Name  Email  Phone  CCN  CVC  Expires     ← the only place "CCN" appears
Row 1 …  …  …  5270-4267-6450-5516  …     ← header is ~40 characters back
Row 2 …  …  …  4532-1234-5678-9010  …     ← ~120 characters back
Row 40 …  …  …  6011-0009-9013-9424 …     ← thousands of characters back

The detector looks for context within a short window around the value. Once the header falls outside that window, the card number is just a 16-digit number with nothing around it — and a card that scores Very Likely as a structured file scores Possible, or produces no finding at all.

This is why partial detection down a long column is such a common report. The first rows are close enough to the header; the rest are not.

9. There is no native CVV/CVC/security code detector

Expected behavior, not a gap. CVV values are 3–4 digits and indistinguishable from dates, quantities, internal IDs, and ordinary numbers, so a standalone CVV detector would generate very high false positive volume. Tightening context requirements to suppress that noise raises the miss rate instead, because CVVs are frequently shared without consistent labels.

Recommended approach: Rely on the card number and card image detectors, which are far stronger PCI signals. Note that cvv, cvc, and csc already function as context that boosts card number confidence — so a card and its CVV appearing together helps detect the card.

10. A clipboard image will not trigger the card image detector

Images in the copy buffer are processed for text extraction only. The card-image classifier does not run on clipboard content — it applies when the image is its own file or is embedded in a document. If extraction is clean, the card number detector can still fire on the extracted text.

Related: mixed clipboard content is not supported. Text is preferred over image, except where the text portion is only a URL, in which case the image is processed.

Resolution: Expect the card number detector, not the card image detector, on clipboard paste events. Test image classifiers using file uploads or embedded images.

11. Coverage gap — the detector was never deployed there

Common pattern: card detection deployed on the primary file store and chat tool but absent from the support ticketing system or wiki, which is often exactly where customers submit payment details. Verify the detector is present on the integration in question before treating this as a detection problem.

12. Results differ between tenants

If a sample fails in one tenant and succeeds in another, the cause is detection rule configuration — minimum confidence, minimum findings, or scope — not model behavior. Cheap early triage step.

Ruled out as a cause

Card numbers at end-of-line or end-of-file. Suspected during regression testing and confirmed to behave as expected. Do not spend time on this hypothesis.

A test-card blocklist. There is none. Well-known test PANs are not suppressed by name or range. When a test card fails, the reason is Luhn, prefix/length, BIN lookup, or the repeated-groups filter — not an exclusion list.

What not to do

Do not lower confidence to Possible as a general fix. It will surface large volumes of ordinary numeric data. Reserve it for narrow, time-boxed cases such as a one-time historical scan where the volume is explicitly accepted. Validate any threshold change in the Playground or an isolated test policy first.

Reporting a missed detection to Nightfall Support

Non-findings are not retained. A missed detection cannot be investigated retroactively — there is no stored artifact, unlike a false positive where the content is available in the event finding.

Contact Nightfall Support and include these three items at minimum:

Also helpful, in rough order of value:

1. Confirmation the number is Luhn-valid, at a correct length for its network prefix, and carries a real issuer prefix

2. Your Playground result — the confidence score, or "no finding"

3. Whether the number appeared more than once, or alongside other same-width numbers

4. The field label or column header the value sat under

5. Detection rule configuration: scope, minimum confidence, minimum findings, context rules

6. For images, the original image file — not a re-screenshot

7. Whether the same sample behaves differently in another tenant or integration

Triage sequence

1. Validate the number first — Luhn, prefix/length agreement, real issuer range. This resolves most reports. 

2. Check whether the number was repeated or sat among other same-width grouped numbers (cause 2), and whether its delimiters were consistent (cause 3).

3. Paste the sample into the Playground and record the result.

4. No finding at all → validation or a pipeline filter; work causes 1, 2, 3, 5, 6, 7.

5. Scored but below threshold → context; work cause 4, or cause 8 if the source was an image or table.

6. Scored in the Playground but the policy did not fire → configuration; work causes 11 and 12.

7. If the source was an image or a table, identify the ingestion path before anything else.

8. Still unexplained → contact Nightfall Support with a sanitized sample, the time of the test, and the environment.