Financial Scam and Fraud Detection Prompt

This prompt is designed for fintech and marketplace trust engineers who need to classify user-generated content, messages, or transaction descriptions for financial scam indicators. It detects investment scams, advance-fee fraud, phishing for financial credentials, payment redirection attempts, and romance-investment hybrid scams. Use this prompt at the ingress layer before user content reaches downstream models, payment systems, or messaging infrastructure. The prompt outputs a structured classification with scam category, confidence score, and extracted indicators including URLs, payment addresses, and pressure tactics. This is a classification and triage prompt, not a response-generation prompt. It belongs in a guardrail pipeline where flagged content triggers quarantine, human review, or automated blocking before any financial action occurs.

Do not use this prompt as a standalone consumer safety tool, for generating user-facing warnings, or for making final account action decisions without human review. It is not a replacement for transaction monitoring systems, KYC/AML checks, or regulatory filing workflows. The prompt is optimized for text-based content and may miss scams conveyed purely through images, audio, or video without accompanying text. For multimodal content, pair this prompt with a vision-capable model or pre-extract text descriptions before classification. The confidence scores are model-estimated probabilities, not calibrated risk scores—always calibrate thresholds against your own labeled evaluation set and business risk tolerance before setting automated action triggers.

Deploy this prompt where the cost of a missed scam (false negative) is higher than the cost of a false positive review. Typical integration points include: peer-to-peer marketplace messaging, payment description fields, investment community posts, customer support intake forms, and social features within fintech products. Before production use, run the prompt against a golden evaluation set that includes your platform's specific scam patterns, legitimate financial discussions that should not be flagged, and edge cases like financial education content or sarcastic commentary. Start with a human-in-the-loop quarantine workflow and only automate blocking actions after measuring precision and recall across at least two weeks of production traffic.

This prompt template is designed to be pasted directly into your system prompt or user message template. It instructs the model to act as a financial fraud classifier, analyzing the provided input for known scam patterns. The template uses square-bracket placeholders like [INPUT] and [SCAM_TAXONOMY] so you can wire it into your application's variable substitution logic without manual editing. The output is a structured JSON object, making it suitable for direct ingestion by a downstream routing or quarantine service.

textCopy
You are a financial scam and fraud detection classifier. Your task is to analyze the provided user input and determine if it contains indicators of a financial scam or fraudulent activity.

### INPUT
[INPUT]

### SCAM TAXONOMY
Use the following categories to classify the input. If the input is not a scam, use the category "none".
[SCAM_TAXONOMY]

### OUTPUT SCHEMA
You must respond with a single, valid JSON object conforming to this schema. Do not include any other text.
{
  "is_scam": boolean, // true if any scam indicators are detected
  "category": string, // the most specific category from the taxonomy that matches, or "none"
  "confidence": number, // a score from 0.0 to 1.0
  "indicators": [
    {
      "type": string, // e.g., "url", "payment_address", "pressure_tactic", "credential_phishing", "advance_fee", "impersonation"
      "value": string, // the extracted suspicious string or tactic description
      "context": string // the surrounding sentence or phrase where the indicator was found
    }
  ],
  "reasoning": string // a brief, factual explanation of the classification, referencing the indicators found
}

### CONSTRAINTS
- Do not hallucinate indicators. Only extract strings that are literally present in the input.
- If the input is a normal financial discussion, customer support query, or legitimate transaction, classify it as "none" with a low confidence score.
- Pay special attention to urgency, threats of loss, and requests for secrecy, which are strong pressure tactics.
- Identify cryptocurrency wallet addresses, payment links, and routing numbers that are presented in a suspicious context.

To adapt this template, replace the [SCAM_TAXONOMY] placeholder with your organization's specific list of scam categories, such as "investment_scam", "romance_scam", "advance_fee_fraud", or "payment_redirection". The [INPUT] placeholder should be populated with the raw user text at runtime. For high-risk production environments, you should pair this prompt with a validation layer that checks the output JSON against the schema before acting on the classification. A common failure mode is the model returning a category not present in your taxonomy; implement a retry or repair step to handle this.

Integrating this prompt into a production system requires treating it as a classification microservice with strict input validation, output schema enforcement, and a clear escalation path. The prompt is designed to sit behind an API endpoint or message queue consumer that receives user-submitted text—such as marketplace messages, payment notes, or support tickets—and returns a structured scam assessment. Because false negatives can lead to financial loss and false positives can block legitimate transactions, the harness must balance automated action with human oversight. The implementation should never allow raw model output to trigger irreversible actions like account freezes or payment blocks without passing through a configurable risk threshold and, above that threshold, a human review queue.

Start by wrapping the prompt in a function that accepts a single [INPUT] string and a [RISK_LEVEL] parameter (low, medium, high) that controls the sensitivity of the detection. The function should enforce a maximum input length (e.g., 4000 characters) to prevent prompt stuffing and reject empty inputs. Before calling the model, sanitize the input by stripping null bytes and normalizing Unicode to prevent encoding-based evasion. The model call itself should use a low-temperature setting (0.0–0.1) to maximize deterministic classification, and you should request a structured JSON output matching the schema: { scam_detected: boolean, scam_category: string | null, confidence: float, indicators: { urls: string[], payment_addresses: string[], pressure_tactics: string[] }, explanation: string }. Implement a retry loop with exponential backoff (max 3 attempts) that only retries on model unavailability or malformed JSON—not on low-confidence results. After receiving a valid response, run a post-processing validator that checks: (1) confidence is between 0.0 and 1.0, (2) scam_category is non-null when scam_detected is true, and (3) extracted URLs are syntactically valid. If validation fails, log the raw output and route to a manual review queue rather than retrying indefinitely.

For observability, log every classification decision with a unique trace_id, the input hash (not the raw input, to avoid logging sensitive user content), the model version, confidence score, and the final routing decision. This audit trail is critical for tuning thresholds, investigating false positives, and demonstrating compliance to regulators or payment partners. Wire the classification result into a decision engine: if scam_detected is false or confidence is below a configurable threshold (e.g., 0.7), allow the transaction or message to proceed. If scam_detected is true and confidence exceeds a high threshold (e.g., 0.9), you may automate a soft block—such as flagging the account for review or delaying the payment—but never hard-delete content or permanently ban users without human confirmation. All cases in the middle confidence band (0.7–0.9) should create a ticket in your trust and safety review queue with the full model output, extracted indicators, and a link to the source input. This human-in-the-loop step is non-negotiable for financial workflows where the cost of a mistake is high. Finally, schedule a weekly review of false positive and false negative cases to update your few-shot examples and threshold configuration.