Skip to content

Is Credit Card Troubleshooting

Common problems when creating and running an Is Credit Card check, their causes, and how to resolve them.

Validation Fails When Creating the Check

Clicking Validate returns an error instead of a success message.

Cause: The rule could not run against the selected data. The most common reasons are an invalid Filter Clause expression, a connection problem with the source, or a container that failed to load.

Resolution:

  1. Review the error message: it explains what needs attention.
  2. Check the Filter Clause for typos: it must be a valid SQL WHERE expression for the selected container.
  3. If the message says the container is marked as Unloadable, the container was skipped after repeated operation failures. Follow the steps in Unloadable Container Error.

Masked or Tokenized Values Are Flagged

A column holding **** **** **** 1111 or an opaque token is reported.

Cause: Those values no longer contain a full card number, so validation fails.

Resolution: Point the check at the column that holds the real number, or remove the check from tokenized columns: they are not meant to carry card data.

Values With Extra Text Are Flagged

A row holding a number plus a note is reported.

Cause: Is Credit Card expects the whole value to be the number.

Resolution: Use Contains Credit Card when surrounding text is legitimate, or normalize the column so it holds only the number.

Rows With NULL Values Are Flagged

Rows with no value in the field are reported, with null as the value in the anomaly message.

Cause: The assertion returns false for a NULL input, so absence is a violation like any other and counts in the evaluated total. An empty string fails for the same reason.

Resolution: If NULL is legitimate in this column, exclude those rows with a Filter Clause such as card_number IS NOT NULL. If it is not, the anomaly is correct and the producing system needs fixing.

A Short Numeric Value Is Not Flagged

A value far too short to be a card number, such as 0000, passes the check.

Cause: The rule enforces no card-number length and no issuer prefix. It only requires at least one digit after spaces and dashes are removed, plus a Luhn checksum of zero, which short all-digit values can satisfy by accident.

Resolution: Add Min Length or Matches Pattern on the same field when the length also has to hold.

An Array Field Is Not Validated Element by Element

An array column was selected, but the individual elements are clearly not being checked.

Cause: Is Credit Card has no array branch. It applies the scalar card-number assertion to the selected column whatever the field type.

Resolution: Use Contains Credit Card, which does branch on array fields and requires every element to carry a card number.

An Edited Check Keeps Behaving the Old Way

You changed the configuration but the anomaly list did not change.

Cause: Edits take effect on the next Scan. Saving the check does not re-evaluate the data, and anomalies raised under the previous configuration are not modified.

Resolution: Run a Scan on the container (or wait for the scheduled one). Old anomalies stay open until you triage them or a Full scan with Auto Resolve clears them. See What Happens to Existing Anomalies.

No Anomalies Although the Data Looks Wrong

A Scan ran, the data clearly breaks the rule, but nothing was reported.

Cause: One of these configurations is excluding the violations:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Filter Clause excludes those rows before the evaluation runs.
  • Coverage is below 100% and the failing fraction stayed within the tolerance, so the check passed.

Resolution: Confirm the check is Active and test the filter expression against the offending rows. Then review the coverage setting; see Coverage and Tolerance.

Expected One Anomaly per Row, Got a Single Rolled-Up One

Many rows failed, but the scan reported one Shape Anomaly instead of per-row Record Anomalies.

Cause: When the number of failing rows exceeds the scan's rollup threshold, the per-row findings are grouped into one rolled-up Shape Anomaly.

Resolution: This is expected behavior; the rolled-up anomaly carries sampled source records. To change the threshold, see Maximum Record Anomalies per Check.