Fraud and Scam Prevention Redirection Prompt

This prompt is designed for trust-and-safety engineers, platform operators, and support teams who need an AI system to safely handle user requests that involve phishing, impersonation scams, financial fraud, or social engineering. The prompt produces a firm, policy-compliant refusal that redirects the user to victim support resources, official reporting channels, and consumer protection guidance. Use this when a user asks how to create a phishing page, impersonate a brand, fabricate financial documents, or execute a scam. The primary job-to-be-done is to stop the model from facilitating harmful activity while preserving a path for the user to get legitimate help if they are a victim or a concerned bystander.

Do not use this prompt for general cybersecurity education requests, legitimate penetration testing inquiries, or academic fraud research where the intent is defensive and clearly stated. A security researcher asking 'show me a phishing email template so I can train my detection model' requires a different workflow—one that provides educational content without enabling misuse. Applying this refusal prompt to defensive research will cause over-refusal, frustrate legitimate users, and erode trust in the AI system. Before routing a request to this prompt, your classification layer must distinguish between 'how do I commit fraud' and 'how do I understand fraud to prevent it.' If the classification confidence is low, escalate to human review rather than defaulting to refusal.

This prompt assumes the upstream system has already detected a high-likelihood fraud or scam intent. It does not perform detection itself. Wire it behind a classification router that scores requests for fraud indicators such as impersonation language, financial manipulation patterns, or phishing infrastructure questions. The refusal response includes structured fields for fraud type, recommended reporting channels, and victim support resources. Validate that the output contains a valid fraud category, at least one actionable reporting URL, and no language that could be interpreted as ambiguous about the refusal. Log every refusal with the detected fraud type, the resources provided, and a session identifier for audit trails. If the model fails to produce a valid refusal structure after one retry, escalate to a human moderator.

This template is designed to be placed in your system instructions or a dedicated safety classifier that runs before the main model response. It detects requests related to phishing, impersonation, investment fraud, romance scams, business email compromise, and other financially motivated deception. Instead of a bare refusal, it produces a structured redirection that includes reporting paths, victim support resources, and consumer protection information. The prompt is calibrated to distinguish between legitimate security research, fraud awareness education, and actual fraud-facilitation requests—reducing false positives that frustrate security professionals while maintaining a hard boundary against harmful outputs.

codeCopy
SYSTEM INSTRUCTION:
You are a safety classifier for a platform that does not facilitate fraud, scams, impersonation, or financial exploitation. Your job is to detect requests that seek to enable, instruct, automate, or disguise fraudulent activity and redirect them to legitimate victim support and reporting resources.

CLASSIFICATION RULES:
1. Classify the user request into one of these categories:
   - "FRAUD_FACILITATION": The request seeks help creating, automating, improving, or concealing fraudulent schemes, scams, impersonation, phishing, or financial deception.
   - "LEGITIMATE_SECURITY_RESEARCH": The request discusses fraud techniques in an academic, defensive, detection, or educational context without requesting operational fraud assistance.
   - "FRAUD_AWARENESS_OR_VICTIM_SUPPORT": The user is asking for help recognizing scams, reporting fraud, recovering from victimization, or educating others about fraud prevention.
   - "UNRELATED": The request does not involve fraud, scams, or financial deception.

2. If classification is "FRAUD_FACILITATION", produce the refusal response below. Do not provide any substantive information about how to commit fraud, even in the refusal.

3. If classification is "LEGITIMATE_SECURITY_RESEARCH" or "FRAUD_AWARENESS_OR_VICTIM_SUPPORT", respond helpfully within safety boundaries. Do not provide operational fraud instructions, but you may discuss detection techniques, prevention strategies, reporting mechanisms, and victim support resources.

4. If classification is "UNRELATED", pass through to normal processing.

REFUSAL RESPONSE TEMPLATE (for FRAUD_FACILITATION only):
"I can't help with that request. If you're concerned about a potential scam or believe you've been targeted by fraud, here are resources that can help:

- **Report fraud** to the FTC at ReportFraud.ftc.gov or call 1-877-FTC-HELP (US)
- **Report phishing** to the Anti-Phishing Working Group at reportphishing@apwg.org
- **Report identity theft** at IdentityTheft.gov for a recovery plan
- **International fraud reporting**: Contact your national consumer protection agency or visit econsumer.gov for cross-border complaints
- **Financial institution fraud**: Contact your bank or credit card issuer immediately using the number on the back of your card

If you're a security researcher or educator working on fraud detection, please rephrase your request to clarify the defensive or educational context."

INPUT TO CLASSIFY:
[USER_INPUT]

CONSTRAINTS:
- Do not output anything other than the classification label and, if applicable, the refusal response.
- Do not explain your classification reasoning in the output.
- Do not provide examples of fraudulent techniques, even hypothetically.
- If uncertain between FRAUD_FACILITATION and LEGITIMATE_SECURITY_RESEARCH, default to FRAUD_FACILITATION and provide the refusal response.

[RISK_LEVEL]: HIGH
[ESCALATION_PATH]: If the request involves imminent financial harm, active impersonation of a specific individual, or child financial exploitation, escalate to human review immediately.

Adaptation guidance: Replace the resource URLs and phone numbers in the refusal template with jurisdiction-appropriate alternatives for your user base. The [USER_INPUT] placeholder should receive the raw user message before any other processing. If your platform operates in regulated financial services, add your compliance team's mandated reporting language. For high-volume production deployments, pair this prompt with a lightweight pre-filter that flags obvious fraud keywords before invoking the full classifier—this reduces latency and cost. The [RISK_LEVEL] and [ESCALATION_PATH] placeholders should be replaced with your platform's internal risk taxonomy and escalation procedures. Test this prompt against a golden dataset that includes both clear fraud-facilitation requests and edge cases like journalists asking about scam techniques for a story, to verify your false-positive rate is acceptable before deployment.

This prompt is designed to sit inside a trust-and-safety decision pipeline, not as a standalone chatbot. The typical integration point is after an upstream classifier has flagged a user request as potential fraud, scam, impersonation, or financial exploitation content. The harness receives the classified request, the fraud type label, and any relevant session context, then invokes the prompt to generate a refusal response that includes victim support resources, reporting guidance, and consumer protection information. The generated output is not returned directly to the user until it passes validation checks for resource accuracy, tone consistency, and policy alignment.

Implement the harness as a structured function with clear inputs: user_request (the original flagged text), fraud_type (one of phishing, impersonation, financial_scam, identity_theft, romance_scam, investment_fraud, or other), jurisdiction (ISO country code for region-specific resources), and session_risk_score (a float from the upstream classifier). The function should populate the prompt's [INPUT] with the user request, [FRAUD_TYPE] with the classified category, [JURISDICTION] with the country code, and [RESOURCE_DATABASE] with a pre-vetted mapping of fraud types and jurisdictions to official reporting agencies, helplines, and victim support organizations. Never let the model hallucinate resource URLs or phone numbers—inject them from a maintained database. After generation, validate the output against a schema that requires: a refusal statement, at least one actionable reporting path, at least one victim support resource, and a consumer protection information block. If validation fails, retry once with the validation errors injected into the prompt as [PREVIOUS_ERRORS]. If the retry also fails, escalate to a human reviewer and log the failure for prompt improvement analysis.

Model choice matters here. Use a model with strong instruction-following and low refusal-creep for safety content—GPT-4o or Claude 3.5 Sonnet are appropriate defaults. Set temperature low (0.0–0.2) to keep resource citations stable. Log every generation with the input fraud type, the output resources cited, the validation result, and whether the response was auto-approved or escalated. For high-risk jurisdictions or fraud types involving vulnerable populations, add a mandatory human-review gate before the response reaches the user. Do not store the user's original request in plaintext logs if it contains PII or financial details—redact before logging or use a secure audit store. The next step after deployment is to build an eval suite that tests the harness against known fraud scenarios and measures resource relevance, refusal clarity, and escalation accuracy.