Is Credit Card Best Practices¶
Guidelines for getting reliable signal from Is Credit Card checks while keeping the noise (and the maintenance) low.
Point the check at the column that really holds the number¶
A masked, truncated, or tokenized column will fail every row, which tells you nothing useful. Run the check on the column that stores the full number, and drop it entirely from columns that are designed not to.
Consider whether the column should hold card data at all¶
A column failing this check may be revealing that card numbers ended up somewhere they should not be, or that a column meant to be masked is not. Review the field's masking configuration alongside the anomaly rather than only fixing the values.
Use Contains Credit Card when surrounding text is legitimate¶
When the column carries a note or a formatted string that includes the number, Contains Credit Card is the right rule. Is Credit Card is for columns whose entire value is the number.
Pair with Not Null when the field is mandatory¶
NULL values pass. The rule asserts that present values are card numbers. It does not require the field to be populated. Add Not Null on the same field when presence is part of the rule.
Pair with a length rule when the length matters¶
The validator enforces no card-number length and no issuer prefix: any all-digit value whose Luhn checksum comes out to zero passes, including values far too short to be a card. Add Min Length or Matches Pattern on the same field when the length is part of the rule.
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 rows break the rule. 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 segment, one channel, one period), 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 failure usually points at the system that produced the value, not at the warehouse. 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, 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.
-
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.