Skip to content

Is Credit Card Check Examples

Three real-world scenarios that show how the Is Credit Card check is typically used in production: validating a dedicated card column, checking card-method transactions with a filter, and auditing a legacy column mid-cleanup. The first two run at 100% coverage and report Record Anomalies; the third lowers coverage and reports a Shape Anomaly instead.

The situation: The card_number column exists to hold nothing but the card number. Rows holding a token, a note, or a truncated value break the file the platform submits to the acquirer.

Check configuration

Field Value
Rule Is Credit Card
Field card_number
Filter (none)
Custom Anomaly Description Off
Coverage 100%
Owner (check creator)
Anomaly Assignee (Payments Engineering)
Description Card number column must hold valid card numbers.
Tags payments, format
Additional Metadata jira: DATA-9301
Status Active

Payload

{
    "description": "Card number column must hold valid card numbers.",
    "rule": "isCreditCard",
    "fields": ["card_number"],
    "container_id": 301,
    "coverage": 1,
    "filter": null,
    "properties": {},
    "tags": ["payments", "format"],
    "additional_metadata": {"jira": "DATA-9301"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 15
}

Sample Data

payment_id card_number method
P-001 4111 1111 1111 1111 card
P-002 tok_1H8sK2 card
P-003 5500-0000-0000-0004 card
P-004 (null) card

What gets flagged

Payment P-002 holds a vault token instead of a number. P-003 uses dashes between digit groups and passes. P-004 is NULL, which the assertion also rejects. Coverage is 100%, so each failing row is reported as its own Record Anomaly.

Record Anomalies

The field 'card_number' has value 'tok_1H8sK2', which does not match a valid credit card format

The field 'card_number' has value 'null', which does not match a valid credit card format

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read card_number"]
    B --> C{"Is value NULL?"}
    C -->|Yes| F["Flag row.<br/>Record Anomaly per failing row."]
    C -->|No| E{"Strip spaces and dashes:<br/>all digits and Luhn valid?"}
    E -->|Yes| D["Row passes"]
    E -->|No| F

Equivalent SQL

-- Rows the Is Credit Card check would flag.
SELECT p.*
FROM payments p
WHERE p.card_number IS NULL
   OR NOT luhn_valid(replace(replace(p.card_number, ' ', ''), '-', ''));

Exclude NULLs when they are legitimate

Set a Filter Clause of card_number IS NOT NULL to keep missing values out of the evaluation.

The situation: The transactions table mixes card payments with transfers and vouchers. Only rows whose method is card must carry a card number in instrument; other methods hold identifiers of a different shape.

Check configuration

Field Value
Rule Is Credit Card
Field instrument
Filter method = 'card'
Custom Anomaly Description Off
Coverage 100%
Owner (check creator)
Anomaly Assignee (Payments Engineering)
Description Card transactions must carry a valid card number.
Tags payments, format
Additional Metadata jira: DATA-9333
Status Active

Payload

{
    "description": "Card transactions must carry a valid card number.",
    "rule": "isCreditCard",
    "fields": ["instrument"],
    "container_id": 302,
    "coverage": 1,
    "filter": "method = 'card'",
    "properties": {},
    "tags": ["payments", "format"],
    "additional_metadata": {"jira": "DATA-9333"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 15
}

Sample Data (filtered to method = 'card')

txn_id method instrument
T-01 card 4012888888881881
T-02 card **** 1881
T-03 card 6011000000000004

Why the filter matters

The filter runs before the evaluation, so transfers and vouchers are never validated as cards. Only card transactions are evaluated.

What gets flagged

T-02 holds a masked value, which no longer contains a full number. Coverage is 100%, so the failure is reported as a Record Anomaly, and the message ends with the filter that scoped the evaluation.

Record Anomaly

The field 'instrument' has value '**** 1881', which does not match a valid credit card format [filter: method = 'card']

Flowchart

graph TD
    A["Apply filter: method = 'card'"] --> B["Read instrument"]
    B --> C{"Is the whole value<br/>a card number?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: method = 'card']"]

Equivalent SQL

-- Rows the check would flag on card transactions.
SELECT t.*
FROM transactions t
WHERE t.method = 'card'
  AND (t.instrument IS NULL
       OR NOT luhn_valid(replace(replace(t.instrument, ' ', ''), '-', '')));

The situation: A legacy wallet table mixes real numbers with free text in stored_card. A cleanup job is rewriting the bad rows, and a small fraction is expected to remain broken until it finishes, so the check tolerates up to 0.5% failures.

Check configuration

Field Value
Rule Is Credit Card
Field stored_card
Filter (none)
Custom Anomaly Description Off
Coverage 99.5%
Owner (check creator)
Anomaly Assignee (Legacy Migration team)
Description Stored card column must hold valid card numbers.
Tags legacy, payments
Additional Metadata jira: DATA-9388
Status Active

Payload

{
    "description": "Stored card column must hold valid card numbers.",
    "rule": "isCreditCard",
    "fields": ["stored_card"],
    "container_id": 303,
    "coverage": 0.995,
    "filter": null,
    "properties": {},
    "tags": ["legacy", "payments"],
    "additional_metadata": {"jira": "DATA-9388"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

wallet_id stored_card migrated
W-01 4111111111111111 true
W-02 see contract false
W-03 4111 1111 1111 1112 false
W-04 (null) false

What gets flagged

Wallet W-02 holds free text and W-03 holds a number whose Luhn checksum does not come out to zero. W-04 is NULL, which the assertion also rejects, and it counts in the scanned total. Only 25% of the rows pass, which is below the 99.5% coverage threshold, so the check reports a single Shape Anomaly for the dataset with a sample of the offending rows. Coverage below 100% does not produce Record Anomalies.

Shape Anomaly

For the field 'stored_card', 75.000% of 4 records (3) do not match a valid credit card format

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read stored_card"]
    B --> C{"Is value NULL?"}
    C -->|Yes| F["Flag row.<br/>Passing rate falls below the 99.5%<br/>coverage, so one Shape Anomaly is reported."]
    C -->|No| E{"Strip spaces and dashes:<br/>all digits and Luhn valid?"}
    E -->|Yes| D["Row passes"]
    E -->|No| F

Equivalent SQL

-- Rows the check would flag.
SELECT w.*
FROM wallets w
WHERE w.stored_card IS NULL
   OR NOT luhn_valid(replace(replace(w.stored_card, ' ', ''), '-', ''));

A short all-digit value would pass

A truncated value such as 0000 satisfies Luhn and is not reported. Pair the check with Min Length when truncation is the failure you are hunting.

See Also