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
-
How It Works
The complete reference: definition, field scope, pattern matching, 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.
-
Examples
Three production scenarios with sample data, anomaly messages, and the SQL equivalent of what the check evaluates.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.