Is Credit Card Check FAQ

Answers to common questions about how the Is Credit Card check validates a value, how masking and NULLs behave, and how anomalies are reported, grouped by topic.

Behavior

Does the check verify that the card is real?

No. It strips spaces and dashes, requires the rest to be digits, and applies the Luhn checksum. It cannot tell whether the card exists, is active, or belongs to the customer on the row.

How is this different from Contains Credit Card?

Is Credit Card expects the whole value to be the number. Contains Credit Card passes as soon as a number appears anywhere inside the value, so it tolerates surrounding text.

Are spaces and dashes accepted?

Yes, when they separate the digit groups of the number itself. What fails is content that is not part of the number, such as a label or a note.

Does the check enforce a card-number length?

No. The only length requirement is that at least one digit remains after spaces and dashes are removed. There is no issuer-prefix test either, so a short all-digit value whose Luhn checksum happens to come out to zero (0, 18, 0000) passes. Add Min Length or Matches Pattern when the column must also have a plausible card length.

How are NULL values treated?

NULLs fail. The assertion returns false for a NULL input, so the row is reported and counts in the evaluated total; its Record Anomaly renders the value as null. An empty string fails too. Absence is already covered, so there is no need to pair the check with Not Null; if NULL is legitimate in the column, exclude it with a filter clause such as card_number IS NOT NULL.

What happens on an array field?

An array field can be selected, but the rule has no element-level evaluation: it applies the scalar card-number assertion to the column whatever the field type, so elements are never validated one by one. Use Contains Credit Card to validate the elements of an array of text values.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: <field> has the value <value>, which is not a valid credit card number

Shape Anomaly: <field> values are not a valid credit card number, affecting N of M asserted records

When a filter is set, the message names it at the end of its first sentence, as (applied to records where <expression>). Record and Shape Anomaly messages both carry it.

Does Is Credit Card produce Record Anomalies, Shape Anomalies, or both?

At 100% coverage (the default), violating rows are reported as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset.

Scan settings can group a large number of Record Anomalies into one rolled-up Shape Anomaly, which carries the Shape Anomaly message. This behavior applies across rule types and is documented under Maximum Record Anomalies per Check.

Does Custom Anomaly Description work for Is Credit Card?

Yes. Is Credit Card emits Record Anomalies, so the anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) applies.

When the option points at another column on the same row, the Record Anomaly message becomes that column's value for the violating row, shown as written. When the column is null, missing, or empty, the message falls back to the rule's standard wording, and when the column is masked the message reads <masked>. Shape Anomaly messages are unaffected.

Configuration

Can I lower the coverage on an Is Credit Card check?

Yes. Coverage at 1.0 (100%) means every row must pass. Lowering coverage to 0.995 allows up to 0.5% of rows to fail without raising an anomaly; once the failing fraction goes past that, the check reports a Shape Anomaly. Use lower coverage with care: a real regression that happens to fall just under the threshold will not raise an alert at all.

Can I point the check at a different field later?

Yes. In the UI, open the check, change the Field, and click Update; see Edit a Check for the full steps. Through the API, a PUT to /api/quality-checks/{id} updates fields. The rule type, the target container, and the associated Check Template stay immutable; see the API page for the editable/immutable matrix.

What permission do I need to create or edit an Is Credit Card check?

The Drafter team permission on the datastore covers Draft work (creating a check as Draft or editing it while it stays Draft). Anything that puts the check into evaluation, such as creating or editing an Active check, archiving, or deleting, requires the Author team permission (or above). Viewing only requires Reporter. See Permissions for the full matrix.