Contains Credit Card

Use the containsCreditCard rule when a sensitive payment field is expected to contain a recognizable credit card number pattern.

What is Contains Credit Card?

Think of Contains Credit Card as a sanity check for payment data.

This rule evaluates whether a selected field contains a recognizable credit card number rather than an empty value, placeholder, or value that does not match its criteria.

In simple terms: It checks whether values match the rule's credit card recognition criteria. It does not confirm that a card account exists, is active, or was used for payment.

Add Contains Credit Card Check

Use the Contains Credit Card check to evaluate payment-related fields and surface records where the expected credit card pattern is missing or not recognized.

What Does Contains Credit Card Do?

It helps you answer questions like:

• “Do the completed orders in this Scan contain a recognizable credit card pattern?”
• “Are payment records missing sensitive fields?”
• “Did upstream systems send incomplete payment data?”

In short: It flags records in the Scan scope where an expected credit card pattern is missing or not recognized.

How Does Contains Credit Card Work?

Step 1: Select the Field

Choose a single field that should contain a credit card number (e.g., CARD_NUMBER).

Step 2: Pattern Validation

Qualytics evaluates each value against the credit card recognition criteria used by the rule.

Step 3: Anomaly Detection

If a record does not meet the configured criteria, it can produce an anomaly, subject to the check's filter and coverage settings.

Step 4: Review Results

You can review exactly which records failed and why.

Real-Life Example: E-commerce Orders

The Situation

An e-commerce company stores order data in the ECOMMERCE_ORDERS table.

Each successful order is expected to include a credit card number in the CARD_NUMBER field.

This data is critical for:

• Payment reconciliation
• Fraud investigation
• Compliance audits

The Problem

Before this check was configured, the data team had to manually review order records to verify whether credit card numbers were present.

This manual process:

• Took significant time during each review
• Did not scale as order volume increased
• Still risked missing incomplete or invalid payment records

The Solution

The team implemented the Contains Credit Card check on the CARD_NUMBER field.

During each Scan, Qualytics evaluates the records in scope and flags orders where the credit card number is missing or does not match the check criteria. Data stewards review those findings and any accepted exceptions before deciding how to resolve them.

What the Check Detected

During the Scan, Qualytics identified 26 anomalous records where the CARD_NUMBER field did not match the rule's credit card criteria, even though the orders were marked as completed.

Output

Violation Message Example: In CARD_NUMBER, 26.00% of filtered records (26) do not contain credit card numbers.

Why This Matters

Missing or unrecognized payment values can make it harder to:

• Audit payment records
• Investigate potential fraud
• Review evidence required by payment-data policies
• Operate downstream billing systems

The Outcome

After reviewing the Contains Credit Card anomalies:

• The team identified faulty upstream ingestion logic
• Missing card numbers were traced to a failed payment gateway response
• The team routed confirmed ingestion issues to the responsible owner
• The check became a repeatable quality signal for later Scans

When Should You Use Contains Credit Card?

Use this rule when you:

• Validate payment or transaction tables
• Support review under PCI or financial data policies
• Monitor upstream payment integrations
• Surface incomplete payment records for investigation

Key Takeaway

Contains Credit Card provides a repeatable signal about payment-data structure. Teams still confirm the business meaning of each finding and use other controls to establish payment status or compliance.

Field Scope

Single: The rule evaluates a single specified field.

Accepted Types

General Properties

The filter allows you to define a subset of data upon which the rule will operate.

It requires a valid Spark SQL expression that determines the criteria rows in the DataFrame should meet. This means the expression specifies which rows the DataFrame should include based on those criteria. Since it's applied directly to the Spark DataFrame, traditional SQL constructs like WHERE clauses are not supported.

O_TOTALPRICE > 1000

C_MKTSEGMENT = 'BUILDING'

WHERE O_TOTALPRICE > 1000

WHERE C_MKTSEGMENT = 'BUILDING'

O_ORDERPRIORITY = '1-URGENT' AND O_ORDERSTATUS = 'O'

(L_SHIPDATE = '1998-09-02' OR L_RECEIPTDATE = '1998-09-01') AND L_RETURNFLAG = 'R'

WHERE O_ORDERPRIORITY = '1-URGENT' AND O_ORDERSTATUS = 'O'

O_TOTALPRICE > 1000, O_ORDERSTATUS = 'O'

RIGHT(
    O_ORDERPRIORITY,
    LENGTH(O_ORDERPRIORITY) - INSTR('-', O_ORDERPRIORITY)
) = 'URGENT'

LEVENSHTEIN(C_NAME, 'Supplier#000000001') < 7

RIGHT(
    O_ORDERPRIORITY,
    LENGTH(O_ORDERPRIORITY) - CHARINDEX('-', O_ORDERPRIORITY)
) = 'URGENT'

EDITDISTANCE(C_NAME, 'Supplier#000000001') < 7

O_ORDERSTATUS IN (
    SELECT DISTINCT O_ORDERSTATUS
    FROM {{_qualytics_self}}
    WHERE O_TOTALPRICE > 1000
)

O_ORDERSTATUS IN (
    SELECT DISTINCT O_ORDERSTATUS
    FROM ORDERS
    WHERE O_TOTALPRICE > 1000
)

Anomaly Types

Example

Objective: Check whether O_PAYMENT_DETAILS contains a recognizable credit card pattern for records in the Scan scope.

Sample Data

{
    "description": "Check that O_PAYMENT_DETAILS contains a recognizable credit card pattern",
    "coverage": 1,
    "properties": {},
    "tags": [],
    "fields": ["C_CCN_JSON"],
    "additional_metadata": {"key 1": "value 1", "key 2": "value 2"},
    "rule": "containsCreditCard",
    "container_id": {container_id},
    "template_id": {template_id},
    "filter": "1=1"
}

Anomaly Explanation

In the sample data above, the entry with O_ORDERKEY 2 violates the rule because O_PAYMENT_DETAILS does not match a recognized credit card pattern.

graph TD
A[Start] --> B[Retrieve O_PAYMENT_DETAILS]
B --> C{Contains Credit Card Number?}
C -->|Yes| D[Move to Next Record/End]
C -->|No| E[Mark as Anomalous]
E --> D

-- An illustrative SQL query to identify order records that don't contain a credit card number in the payment details.
select
    o_orderkey,
    o_payment_details
from orders
where
    not (regexp_like(o_payment_details, '[0-9]{16}'))
    or not (regexp_like(o_payment_details, '\d{4}-\d{4}-\d{4}-\d{4}'))

Potential Violation Messages