This prompt is for fintech and payment engineers who need to sanitize text before it enters an AI model or after it leaves one. The core job-to-be-done is producing a redacted version of input text where credit card numbers, CVVs, bank account details, and other financial identifiers are masked according to PCI DSS truncation standards. Use this when you need a downstream model to process the intent of a message—such as a customer complaint or a transaction note—without ever seeing the raw financial data. The ideal user is an engineer building a defense-in-depth pipeline who understands that a prompt is a probabilistic layer, not a cryptographic control.

This prompt is not a standalone compliance solution. Do not use it as your sole mechanism for PCI DSS compliance. It must be paired with deterministic pre-processing, such as regex-based detection and Luhn algorithm validation, to catch what the model might miss. The prompt is most effective when the input text is natural language with embedded financial data, such as a customer support ticket or an internal operations note. It is less reliable for structured data dumps, log files, or non-standard card formats where the model's pattern recognition may fail silently. Always assume the model will miss edge cases and design your pipeline to catch them before and after this prompt runs.

Before implementing this prompt, confirm that your architecture already includes deterministic redaction as the primary control. This prompt should be positioned as a secondary, context-aware scrubber that handles cases regex patterns cannot, such as financial data split across multiple lines or described in conversational language. The next step is to review the prompt template and adapt the [CONSTRAINTS] and [OUTPUT_SCHEMA] placeholders to match your specific compliance requirements and downstream application contract.

This prompt template is designed to be placed as a system-level instruction or pre-processing step in your AI pipeline. It instructs the model to detect and redact primary account numbers (PANs), card verification values (CVVs), bank account numbers, and routing numbers from input text. The template uses square-bracket placeholders for variables you must supply: the input text to scan, the desired output format, any domain-specific constraints, and the risk level of the deployment context. Copy the template below and adapt the placeholders to your application's data handling requirements.

codeCopy
You are a financial data redaction engine operating under PCI DSS compliance requirements. Your sole task is to scan the provided text and return a redacted version with all credit card numbers, CVVs, bank account numbers, and routing numbers replaced by safe placeholder tokens.

## INPUT TEXT
[INPUT]

## REDACTION RULES
1. **Primary Account Numbers (PANs):** Detect all 13-19 digit sequences that pass the Luhn algorithm check. Replace with `[REDACTED_CARD_NUMBER]`. If the input contains a truncated PAN (first 6 and/or last 4 digits), replace the visible digits while preserving the truncation format: `[REDACTED_CARD_NUMBER: first6=XXXXXX, last4=YYYY]`.
2. **Card Verification Values (CVVs):** Detect 3-4 digit sequences immediately following a PAN or explicitly labeled as CVV/CVC/CID. Replace with `[REDACTED_CVV]`.
3. **Bank Account Numbers:** Detect sequences of 8-17 digits that do not pass the Luhn check but appear in contexts mentioning account, routing, ACH, wire, or direct deposit. Replace with `[REDACTED_ACCOUNT_NUMBER]`.
4. **Routing Numbers:** Detect 9-digit sequences that start with 01-12, 21-32, or 61-72 (valid ABA routing number prefixes). Replace with `[REDACTED_ROUTING_NUMBER]`.
5. **Expiration Dates:** Detect MM/YY or MM/YYYY patterns adjacent to card data. Replace with `[REDACTED_EXPIRY]`.
6. **Non-Financial Numbers:** Do NOT redact phone numbers, social security numbers, order IDs, invoice numbers, dates unrelated to cards, or monetary amounts. These are handled by separate PII redaction systems.

## OUTPUT FORMAT
Return a JSON object with the following structure:
```json
{
  "redacted_text": "The full input text with all financial data replaced by placeholder tokens",
  "redactions": [
    {
      "original_token": "[REDACTED]",
      "redaction_type": "card_number | cvv | account_number | routing_number | expiry",
      "placeholder": "[REDACTED_CARD_NUMBER]",
      "position": {"start": 0, "end": 0},
      "luhn_valid": true | false | null
    }
  ],
  "redaction_count": 0,
  "luhn_checks_performed": 0,
  "confidence": "high | medium | low"
}

CONSTRAINTS

[CONSTRAINTS]

RISK LEVEL

[RISK_LEVEL]

IMPORTANT

• Never output the original financial data in any field, including error messages or explanations.
• If you are uncertain whether a number is financial data, set confidence to "low" and include a needs_review flag in the redaction object.
• For [RISK_LEVEL] = "high", any confidence below "high" must trigger a human review recommendation.
• Do not redact example card numbers used for testing (e.g., 4111 1111 1111 1111) unless [CONSTRAINTS] explicitly requires test data redaction.
• Preserve all non-financial text exactly, including whitespace and punctuation.

Adaptation guidance: Replace [INPUT] with the text your application needs to scan—this could be user messages, support tickets, log entries, or document extracts. Set [CONSTRAINTS] to any additional rules specific to your environment, such as "do not redact test PANs in staging environments" or "flag but do not redact when input is from an authenticated admin user." Set [RISK_LEVEL] to low, medium, or high to control the strictness of redaction and whether uncertain detections trigger human review. For production payment systems, always use high and implement the human review recommendation in your application harness.

What to do next: After pasting this template into your system prompt, build a validation layer in your application that checks the output JSON against the original input. Verify that every character position in redacted_text matches the input except at the documented redaction offsets. Run this prompt against a golden test set containing known PANs, CVVs, and edge cases like hyphenated card numbers, numbers embedded in URLs, and Luhn-valid non-card numbers. If your application processes real payment data, ensure the model output is never logged or stored without an additional server-side redaction pass as a defense-in-depth measure.

This prompt is designed to sit inside a pre-processing or post-processing pipeline stage, not as a standalone chatbot. The typical integration pattern is: raw text enters your application, passes through this redaction prompt, and the sanitized output proceeds to downstream models, logs, or storage. You should never send unredacted text containing potential cardholder data to an external model endpoint. The redaction step must complete before any other AI processing occurs, and the redacted output should be the only version that leaves your trust boundary.

Validation is mandatory. After the model returns a redacted output, run a Luhn algorithm check on any remaining digit sequences of 13–19 characters to confirm no valid PANs survived. Also scan for 3–4 digit sequences adjacent to redacted card numbers that could be CVVs, and for patterns matching bank routing numbers or IBANs. If validation fails, do not retry with the same model—log the failure, flag the input for human review, and return a safe fallback message. For PCI DSS compliance, ensure your logging layer never captures the pre-redaction text. Log only the redacted output, the validation result, and a hash of the original input for deduplication.

Model choice matters. Use a model with strong instruction-following and low hallucination rates for structured extraction tasks—Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro are appropriate. Avoid smaller or older models that may miss partial card numbers or hallucinate redaction markers. Set temperature=0 to maximize deterministic behavior. If you are processing high volumes, batch inputs where the provider supports it, but never mix inputs from different users or sessions in the same batch to prevent cross-contamination.

Retry logic should be conservative. If the model returns malformed output (missing the required redacted text field, invalid JSON structure), retry once with a simplified version of the prompt that strips optional instructions and focuses only on card number detection. If the second attempt fails, escalate to a human review queue. Never retry more than twice—each retry is another opportunity for the model to leak data. Implement a circuit breaker that stops processing if the failure rate exceeds 5% in a rolling window.

Audit trail requirements. Every redaction operation should produce a structured log entry containing: a unique request ID, timestamp, model used, validation pass/fail status, count of redacted entities by type (PAN, CVV, routing number, IBAN), and the hash of the original input. This audit trail supports PCI DSS Requirement 10 (logging) and gives your security team the evidence they need during incident response. Store these logs in a separate, access-controlled system from your application logs.

What to avoid. Do not use this prompt as a regex replacement—the model adds semantic understanding that catches non-standard formats, but it is not a substitute for deterministic scanning. Always run regex and Luhn validation as a second layer. Do not send the original text to a logging or observability platform. Do not assume the model will catch every instance; design your pipeline so that a single missed PAN triggers an alert, not a compliance violation. Finally, test this prompt against your own production-like data before deployment—generic test sets will not capture your specific card format variants or edge cases.