Skip to content

Contains Credit Card Best Practices

Guidelines for getting reliable signal from Contains Credit Card checks while keeping the noise (and the maintenance) low.

Point the check at a field that should always carry the value

The rule asserts that credit card numbers are present in every row, so it belongs on a column dedicated to that data. Pointing it at a free-text column where a credit card number is merely common turns every ordinary row into an anomaly.

Use containment deliberately

The value passes as soon as a credit card number appears anywhere inside it, so "contact: {value}" passes just like a bare value. When the field must hold nothing but the value, pair the check with Matches Pattern anchored to the whole string.

Pair with Not Null when the field is mandatory

NULL values pass. Contains Credit Card asserts that present values contain a credit card number; it does not require the field to be populated. When the field must also exist, add a Not Null check on the same field.

Treat the check as a format guard, not a validity guard

A value can look like a card number and still be unusable: the check does not verify the issuer, the expiry, or whether the number passes the issuer's own validation. Pair it with the application-side validation that runs at capture time.

Mind masked and tokenized columns

Columns that store a masked reference (**** **** **** 1111) or an opaque token will fail, because they no longer contain a full number. Point the check at the column that really holds the number, or drop the check on tokenized columns entirely.

Keep coverage at 100% unless a known backlog exists

At 100% coverage every failing row is reported as a Record Anomaly, which tells you exactly which values are wrong. Below 100% the check reports a single Shape Anomaly only when the failing fraction crosses the tolerance, and no per-row detail is produced. Lower coverage only while a known set of legacy rows is being cleaned up.

Scope with a filter instead of loosening coverage

When the rule only applies to part of the table (one channel, one country, rows created after a migration), express that with a filter clause rather than by lowering coverage. The filter removes the out-of-scope rows from evaluation entirely, and the expression is echoed in every anomaly message.

Route the anomalies to the right people

A missing or malformed value usually comes from a collection form or an integration. Set an Anomaly Assignee from the team that owns that producer, and tag the check so related checks are easy to find.

See Also