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
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
-
How It Works
The complete reference: definition, field scope, validation semantics, NULL handling, arrays, filter behavior, and coverage.
-
Anomaly Reporting
The anomaly messages the check produces, what the numbers mean, Source Records highlighting, and Custom Anomaly Description.
-
Best Practices
Guidelines for choosing the right column, handling masked values, pairing rules, and keeping the signal clean.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.