Financial Data Leakage Repair Prompt Template

This prompt is a post-generation safety net for fintech and banking engineering teams. Use it when a model output might contain credit card numbers, bank account numbers, routing numbers, or financial credentials that must be redacted before the output enters downstream systems. This prompt is designed for PCI DSS and SOX compliance boundaries where format-specific masking rules matter and where a regex-only approach misses contextual financial identifiers. It assumes the model output already exists and needs repair, not that the model should be prevented from generating sensitive data in the first place.

The ideal user is a platform engineer, security engineer, or compliance-focused developer who has already generated a model response—such as a transaction summary, customer service reply, or audit note—and needs to sanitize it before logging, storing, or displaying it. The prompt expects you to provide the raw model output as [RAW_OUTPUT] and a set of [REDACTION_RULES] that specify which financial data categories to detect (e.g., PANs, account numbers, routing numbers) and how to mask each one (full redaction, last-four display, tokenization placeholder). You should also supply a [COMPLIANCE_STANDARD] parameter (e.g., 'PCI_DSS', 'SOX', 'GLBA') to activate the correct masking format and audit trail requirements. The output is a sanitized version of the text with an accompanying [REDACTION_LOG] that records what was changed and why.

Do not use this prompt as your primary prevention mechanism. It is a repair tool, not a substitute for input sanitization, strict schema design, or prompt instructions that forbid generating sensitive data. If your model is consistently leaking financial data, fix the upstream prompt or retrieval pipeline first. Also avoid this prompt for real-time streaming scenarios where per-token latency is critical; a regex-based guard with a model fallback for ambiguous matches is more appropriate there. Finally, never use this prompt to redact data that will be needed downstream—if a downstream system requires the full account number, redact at the display layer instead of destroying the data in transit.

This prompt template is designed to be dropped into a post-generation repair loop where model outputs must be sanitized before they enter logs, databases, or user-facing surfaces. It targets financial data leakage—credit card numbers, bank account numbers, routing numbers, and financial credentials—that the model may have inadvertently included. The template uses square-bracket placeholders for all variable inputs so you can wire it into an application harness without manual editing. Every placeholder maps to a concrete input your application must supply at runtime.

textCopy
You are a financial data leakage repair system. Your job is to scan the provided model output for financial data and redact it according to the rules below. Do not modify anything other than the financial data you find. Preserve all original formatting, structure, and non-financial content exactly as provided.

## INPUT TO SCAN
[OUTPUT_TO_SCAN]

## FINANCIAL DATA DETECTION RULES
1. Credit card numbers: Match 13-19 digit sequences that pass Luhn check or match known card issuer prefixes (4xxx, 5[1-5]xx, 3[47]xx, 6011xx, 65xxx). Redact to [CREDIT_CARD_REDACTED].
2. Bank account numbers: Match 8-17 digit sequences appearing near keywords (account, acct, routing, ABA, bank, checking, savings). Redact to [ACCOUNT_NUMBER_REDACTED].
3. Routing numbers: Match 9-digit sequences that pass ABA routing number checksum validation. Redact to [ROUTING_NUMBER_REDACTED].
4. Financial credentials: Match patterns resembling API keys, tokens, or passwords near financial context (plaid, stripe, fintech, payment, transaction). Redact to [FINANCIAL_CREDENTIAL_REDACTED].
5. Partial matches: If a sequence matches a financial pattern but appears in a clearly non-financial context (e.g., test data, documentation examples, sample code), flag it as [FLAGGED_FOR_REVIEW] instead of redacting.

## REDACTION RULES
- Replace detected financial data with the exact redaction tokens specified above.
- Preserve the length and position of redacted content where possible, or use the standard token if length preservation would break formatting.
- Do not redact non-financial numbers (order IDs, invoice numbers, timestamps, quantities, prices).
- If the input contains PCI DSS or SOX compliance boundary markers, treat those sections with highest sensitivity.

## OUTPUT FORMAT
Return a JSON object with these fields:
{
  "sanitized_output": "<the full output with financial data redacted>",
  "redactions": [
    {
      "original_value_preview": "<first 4 and last 4 characters of detected value>",
      "redaction_type": "<CREDIT_CARD | ACCOUNT_NUMBER | ROUTING_NUMBER | FINANCIAL_CREDENTIAL>",
      "position": { "start": <char index>, "end": <char index> },
      "confidence": <0.0 to 1.0>,
      "requires_review": <true | false>
    }
  ],
  "flagged_for_review": [
    {
      "value_preview": "<first 4 and last 4 characters>",
      "reason": "<why it was flagged instead of redacted>",
      "position": { "start": <char index>, "end": <char index> }
    }
  ],
  "summary": {
    "total_redactions": <count>,
    "total_flagged": <count>,
    "compliance_boundary_breaches": <count>
  }
}

## CONSTRAINTS
- Do not invent redactions. Only redact what you detect.
- If no financial data is found, return an empty redactions array and the original output unchanged.
- If the input is empty or unreadable, return an error object: { "error": "<reason>" }.
- [ADDITIONAL_CONSTRAINTS]

## EXAMPLES
[FEW_SHOT_EXAMPLES]

To adapt this template, replace each square-bracket placeholder with values your application controls at runtime. [OUTPUT_TO_SCAN] receives the raw model output that needs sanitization. [ADDITIONAL_CONSTRAINTS] lets you inject organization-specific rules—for example, additional financial patterns, internal account number formats, or compliance boundary markers specific to your PCI DSS scope. [FEW_SHOT_EXAMPLES] should contain 2-4 examples showing correct redaction behavior, including at least one borderline case where a number matches a financial pattern but should be flagged for review rather than redacted. If your application already performs regex-based detection before calling this prompt, pass those pre-detected spans as context to reduce false positives.

Before deploying this prompt to production, test it against a golden dataset of outputs containing known financial data. Measure recall (did it catch all instances?), precision (did it redact non-financial numbers?), and the false-positive-to-review ratio. For PCI DSS and SOX environments, every redaction decision must be logged with the audit trail this prompt produces. If the confidence score for any redaction falls below your threshold, route that output to human review before it enters downstream systems. This prompt is a repair layer, not a replacement for input-side data minimization or token-level streaming guards.

This prompt is designed as a post-generation safety net, sitting between the model's raw output and any downstream system of record, log aggregator, or user-facing surface. The implementation harness must treat the prompt as a deterministic gate: every model response that could contain financial data passes through this repair step before it is considered safe. The harness is responsible for providing the structured [INPUT_TEXT] and the [REDACTION_RULES] configuration, then validating that the returned [REDACTED_OUTPUT] and [REDACTION_LOG] meet the required schema before releasing the data.

Wire the prompt into an asynchronous processing queue or a synchronous API middleware layer depending on your latency budget. For synchronous use, call the model with a low max_tokens and a fast model (e.g., a small Claude Haiku or GPT-4o-mini variant) to keep redaction under 500ms. The application must construct the [REDACTION_RULES] object from a secure configuration store, never from user input, specifying which PCI DSS and SOX patterns to scan for: credit_card_number, bank_account_number, routing_number, financial_credentials, and tax_identifier. The harness must enforce a strict JSON output contract. If the model's response fails to parse as valid JSON, or if the redaction_log array is missing required fields (original, redacted, type, confidence), the harness must retry once with a stronger constraint instruction appended to the prompt. After a second failure, the harness must route the original output to a human review quarantine queue and raise an alert—never pass unrepaired text downstream.

Logging is the most dangerous part of this workflow. The harness must write the redaction_log to an append-only audit table for compliance, but it must never log the original field from the log entries to standard application logs. Strip the original values or replace them with a hash before sending to observability tools. For high-throughput fintech pipelines, batch the input by grouping multiple model responses into a single prompt call with a clear delimiter, but keep batches small (3–5 items) to avoid confusing the model and to keep the redaction_log correctly aligned to each input. Before deploying, build an eval harness that tests the prompt against a golden dataset of 50 known financial data leakage examples—including edge cases like masked PANs, test account numbers, and credentials in JSON escape sequences—and measure both precision (don't redact legitimate financial terms) and recall (catch every real leak).