Fraud and Scam Content Classification Prompt

This prompt is a classification gateway for fintech and e-commerce trust and safety teams who need to analyze unstructured text for fraud and scam indicators before the content reaches a user, agent, or downstream processing system. It is designed to detect romance scams, investment fraud, impersonation, payment fraud, and other deceptive patterns in user-generated messages, support tickets, transaction notes, or marketplace communications. The primary job-to-be-done is triage: reducing the volume of content that requires manual review by automatically scoring risk and routing suspicious items to the correct investigation queue. The ideal user is a security engineer, fraud analyst, or platform developer embedding this prompt into an AI pipeline as a pre-processing layer.

To use this prompt effectively, you must supply the unstructured text to be classified and define the output schema your downstream system expects. The prompt outputs a structured fraud type taxonomy with confidence scores and a recommended investigation queue, making it suitable for direct integration with case management systems, alerting platforms, or automated moderation workflows. However, this prompt is not a replacement for a rules engine, a transaction monitoring system, or a full fraud case management platform. It does not access account history, payment networks, or device fingerprints. It operates purely on the text provided, which means it can detect linguistic patterns of fraud but cannot verify whether a transaction actually occurred or whether an account is compromised.

Do not use this prompt as the sole decision-maker for blocking users, freezing accounts, or filing regulatory reports. Its output should be treated as a signal that feeds into a broader risk scoring pipeline. In high-stakes scenarios—such as suspected money laundering, imminent harm, or large-value fraud—always route the output for human review. Before deploying, build a validation layer that checks the structural integrity of the JSON output, retries on malformed responses, and logs every classification for auditability. Pair this prompt with a set of golden test cases that include known fraud examples, borderline legitimate content, and adversarial inputs designed to evade detection. Monitor false-positive and false-negative rates in production, and establish a feedback loop where analyst overrides are used to refine the prompt or its surrounding eval criteria over time.

The prompt below is designed to be dropped into a classification harness. It expects raw user-generated content as input and returns a structured fraud assessment with a taxonomy label, confidence score, and a routing decision. Every placeholder in square brackets must be replaced by your application before the prompt is sent to the model. Do not ship this prompt with unresolved placeholders in production.

textCopy
You are a fraud and scam content classifier for a trust and safety operations team. Your job is to analyze user-submitted content and determine whether it contains indicators of fraud, scams, or deceptive financial schemes.

## INPUT
[CONTENT]

## TAXONOMY
Classify the content into exactly one of the following fraud types. If no fraud indicators are present, use "none_detected".

- romance_scam: Building fake romantic relationships to request money or financial information.
- investment_fraud: Fake investment opportunities, Ponzi schemes, or guaranteed-return scams.
- impersonation: Pretending to be a trusted entity (bank, government, tech support, executive).
- payment_fraud: Fake invoices, overpayment scams, advance-fee fraud, or payment redirection.
- phishing: Attempts to steal credentials, account details, or personal information via deceptive links or forms.
- business_email_compromise: Targeted impersonation of executives or vendors to authorize fraudulent transfers.
- marketplace_scam: Fake listings, non-delivery, bait-and-switch on e-commerce or classified platforms.
- job_scam: Fake job offers, work-from-home schemes, or requests for upfront fees for employment.
- lottery_prize_scam: Fake lottery winnings, prize claims, or inheritance notifications requiring upfront payment.
- none_detected: No fraud or scam indicators present in the content.

## OUTPUT SCHEMA
Return a valid JSON object with no additional text, markdown fences, or commentary. Use this exact structure:

{
  "fraud_type": "<taxonomy_label>",
  "confidence": <0.0_to_1.0>,
  "indicators": ["<specific_phrase_or_pattern>"],
  "routing_queue": "<queue_name>",
  "requires_human_review": <true_or_false>,
  "explanation": "<brief_reasoning>"
}

## ROUTING RULES
- If confidence is below 0.7, set requires_human_review to true and routing_queue to "manual_review".
- If fraud_type is "none_detected", set routing_queue to "low_priority" and requires_human_review to false.
- For romance_scam, investment_fraud, or business_email_compromise with confidence >= 0.8, set routing_queue to "high_priority_investigation" and requires_human_review to false.
- For all other fraud types with confidence >= 0.8, set routing_queue to "automated_action" and requires_human_review to false.
- If the content contains explicit threats of imminent harm, override all routing and set routing_queue to "urgent_escalation" with requires_human_review true.

## CONSTRAINTS
- Do not invent fraud indicators that are not present in the content.
- If the content is ambiguous, reflect that in a lower confidence score rather than guessing.
- Do not output personally identifiable information in the explanation field. Use generic descriptions instead.
- If the content is in a language you cannot reliably analyze, set fraud_type to "none_detected", confidence to 0.0, and routing_queue to "language_unsupported".

## EXAMPLES

Input: "Hi dear, I am a US soldier stationed overseas. I need $5,000 to get home and I will pay you back double. Please send via Western Union."
Output: {"fraud_type": "romance_scam", "confidence": 0.95, "indicators": ["US soldier stationed overseas", "send via Western Union", "pay you back double"], "routing_queue": "high_priority_investigation", "requires_human_review": false, "explanation": "Classic military romance scam pattern with urgency, emotional appeal, and untraceable payment method request."}

Input: "Your account has been compromised. Click here to verify your identity: bit.ly/3xK9mP2"
Output: {"fraud_type": "phishing", "confidence": 0.92, "indicators": ["account has been compromised", "click here to verify", "shortened URL"], "routing_queue": "automated_action", "requires_human_review": false, "explanation": "Phishing pattern with urgency, credential harvesting language, and obfuscated link."}

Input: "Can you send me the Q4 report by EOD?"
Output: {"fraud_type": "none_detected", "confidence": 0.98, "indicators": [], "routing_queue": "low_priority", "requires_human_review": false, "explanation": "Routine business communication with no fraud indicators."}

To adapt this template, replace [CONTENT] with the raw text your system ingests. If your fraud taxonomy differs, modify the enum list and update the routing rules to match your internal queues. The examples are critical for few-shot behavior; replace them with real cases from your own labeled dataset. If you are operating in a regulated jurisdiction, add a [JURISDICTION] placeholder and adjust the taxonomy to include region-specific fraud types such as GST scams or BEC variants common in your market. Always validate the model's JSON output against the schema before routing, and log every classification decision with the raw input, model version, and confidence score for auditability.

This prompt is designed to operate as a classification gateway before any downstream processing of user-generated content. It should be deployed as a synchronous API call within your content ingestion pipeline, returning a structured fraud taxonomy and confidence score that determines the next processing step. The prompt expects raw text input and outputs a JSON object with fraud_type, confidence_score, indicators, and recommended_queue fields. Because misclassification can route genuine fraud to low-priority queues or flag legitimate content for investigation, the implementation must include deterministic post-processing, not just raw model output.

Wire the prompt into your application with a validation and retry layer. After receiving the model's JSON response, validate that fraud_type matches one of your defined taxonomy values (e.g., romance_scam, investment_fraud, impersonation, payment_fraud, none), that confidence_score is a float between 0.0 and 1.0, and that recommended_queue maps to an actual queue in your investigation system. If validation fails, retry once with the same input and a stronger format instruction appended. If the second attempt also fails, route the content to a manual review queue with a classification_failure tag. Log every classification attempt—including the raw input, model response, validation result, and final routing decision—for audit and model evaluation purposes.

For high-confidence fraud detections (confidence > 0.85), route directly to the fraud investigation queue with the extracted indicators attached as evidence. For medium-confidence detections (0.60–0.85), route to a triage queue where human analysts review the content before investigation. For low-confidence or none classifications, allow the content to proceed to normal processing but log the classification for trend analysis. Implement a feedback loop: when human reviewers override a classification, store the corrected label and use it to build evaluation datasets for prompt regression testing. Never use this prompt to automatically block users or freeze accounts without human confirmation—the cost of a false positive in fraud classification can include reputational damage and customer churn.

Choose a model with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all perform well on this classification task, but you should run your own evaluation against a labeled dataset of known fraud and legitimate content before selecting a production model. If latency is critical, consider using a smaller fine-tuned model for initial screening and only calling a larger model for ambiguous cases. For regulated environments, ensure that all model calls happen within your compliance boundary and that no raw user content is logged to external observability platforms without redaction. The next step after implementing this harness is to build a regression test suite using your historical fraud cases and known false positives to catch prompt drift before it reaches production.