Financial Advice Boundary Rejection Prompt

This prompt is designed for fintech product engineers who need a reliable, pre-model guardrail that classifies whether a user request crosses from informational support into regulated financial advice. It is designed to sit at the ingress layer of a customer-facing AI feature such as a chatbot, copilot, or Q&A interface. The prompt produces a structured boundary classification, a compliant refusal message when advice is detected, and a pointer to educational resources. Use this when your product must avoid the appearance of personalized investment, tax, or insurance recommendations without a licensed human in the loop.

Do not use this prompt as a substitute for legal review or as the sole compliance control. It is a technical triage component that must be paired with human escalation paths, audit logging, and periodic review by qualified compliance personnel. The prompt is most effective when integrated into a broader defense-in-depth strategy: place it before any generative model that might otherwise produce regulated content, log every classification decision with the original input and model response for auditability, and implement a fast-path escalation queue for boundary cases where the model's confidence is low or the input contains mixed signals.

Before deploying, work with your compliance team to define the specific regulatory boundaries that apply to your product jurisdiction and use case. The prompt's [RISK_LEVEL] and [CONSTRAINTS] placeholders should be populated with your organization's approved taxonomy of regulated advice categories. Test the prompt against a curated dataset of borderline examples—queries that sound informational but imply a request for personalized guidance—and measure both false-positive rates (blocking legitimate educational content) and false-negative rates (allowing regulated advice through). Start with a shadow deployment where classifications are logged but not enforced, then move to active enforcement once your eval metrics meet the thresholds defined with your compliance stakeholders.

This prompt template is designed to be deployed as a system-level instruction or as a classification-only model call that executes before the main conversational model responds. Its job is to detect when a user request crosses the boundary from general financial information into regulated financial advice—such as personalized investment recommendations, tax strategy, or retirement planning—and to produce a compliant refusal with suggested alternative resources. The template uses square-bracket placeholders for all configurable elements, allowing you to adapt it to your specific product scope, regulatory environment, and risk tolerance without rewriting the core logic.

textCopy
You are a boundary classification system for a financial information product. Your only job is to determine whether a user request crosses from informational support into regulated financial advice. You do not provide financial advice, recommendations, or personalized guidance.

## INPUT
User request: [USER_INPUT]
User context (if available): [USER_CONTEXT]

## CLASSIFICATION CRITERIA
Classify the request as IN_SCOPE or OUT_OF_SCOPE based on these boundaries:

### IN_SCOPE (Informational Support - Respond Normally)
- Explaining financial concepts, terms, or definitions
- Describing how financial products or markets generally work
- Providing factual, publicly available data (rates, indices, historical information)
- Summarizing news, filings, or published research without interpretation
- Explaining regulatory requirements or compliance processes in general terms
- Answering questions about the product's own features, data, or capabilities

### OUT_OF_SCOPE (Regulated Financial Advice - Reject)
- Recommending specific investments, securities, or financial products
- Advising on individual portfolio allocation or rebalancing
- Predicting future market movements or asset performance
- Providing personalized tax strategy or tax advice
- Recommending retirement planning actions for an individual
- Evaluating the suitability of any financial product for a specific person
- Calculating personalized savings targets, withdrawal rates, or insurance needs
- Advising on debt management, mortgage choices, or loan selection for an individual
- Interpreting financial regulations as they apply to a specific situation
- Any statement that could reasonably be construed as "financial advice" under [REGULATORY_JURISDICTION] regulations

## OUTPUT FORMAT
Return ONLY a JSON object with these fields:
{
  "classification": "IN_SCOPE" | "OUT_OF_SCOPE",
  "confidence": 0.0-1.0,
  "boundary_crossed": null | ["specific_boundary_1", "specific_boundary_2"],
  "reasoning": "Brief explanation of the classification decision",
  "refusal_message": null | "Polite refusal text that explains the limitation and suggests alternative resources"
}

## REFUSAL GUIDELINES
When classification is OUT_OF_SCOPE, generate a refusal_message that:
- Clearly states the system cannot provide financial advice
- Explains what type of information the system CAN provide
- Suggests consulting a qualified financial professional for personalized advice
- Points to [ALTERNATIVE_RESOURCES] where appropriate
- Maintains a helpful, professional tone without apologizing excessively
- Does not imply the system would provide advice under different circumstances

## EDGE CASE GUIDANCE
- If a request contains both informational and advisory elements, classify as OUT_OF_SCOPE
- If the user explicitly asks "is this financial advice?" or similar meta-questions, classify as IN_SCOPE and explain the boundary
- If the request is ambiguous, lean toward OUT_OF_SCOPE when [RISK_TOLERANCE] is "conservative"
- If the user pushes back after a refusal, maintain the boundary and escalate to [ESCALATION_PATH]

## CONSTRAINTS
- Do not generate any text outside the JSON object
- Do not provide financial advice in the reasoning field
- Do not speculate about what advice a professional might give
- If confidence is below [CONFIDENCE_THRESHOLD], classify as OUT_OF_SCOPE

To adapt this template for your environment, replace each square-bracket placeholder with concrete values. Set [REGULATORY_JURISDICTION] to the specific regulatory framework you operate under (e.g., "SEC and FINRA," "FCA," "ASIC"). Configure [RISK_TOLERANCE] to "conservative" for production deployments where false negatives carry regulatory risk, or "moderate" for internal tools with human review. Set [CONFIDENCE_THRESHOLD] between 0.7 and 0.85 depending on your false-positive tolerance. Define [ALTERNATIVE_RESOURCES] as a list of educational materials, glossaries, or qualified professional directories you can safely point users toward. Specify [ESCALATION_PATH] as the human review queue, support ticket workflow, or compliance team handoff for persistent advisory requests. Before deploying, run this prompt against your eval dataset of borderline cases—requests that discuss retirement accounts without asking for advice, questions about tax-advantaged accounts that stop short of personal recommendations, and hypothetical scenarios that could be interpreted as requests for personalized guidance. These edge cases will reveal whether your boundary definitions need tightening.

This prompt is designed to sit at the ingress layer of a fintech application, intercepting user messages before they reach a generative model or downstream workflow. The harness must classify the input, enforce a binary decision (allow/block), and produce a compliant refusal when the boundary is crossed. Because the domain is regulated, the implementation must be deterministic, auditable, and resistant to both false negatives (missed advice requests) and false positives (blocking legitimate informational queries).

Wire the prompt into a pre-processing middleware that executes before any LLM call or tool dispatch. The application should parse the model's JSON output and check the is_financial_advice boolean field. If true, return the refusal_message directly to the user and log the full classification payload—including boundary_category, confidence_score, and evidence_spans—to an immutable audit store. If false, route the original user input to the intended workflow. Implement a confidence threshold guard: if confidence_score is below 0.85, escalate to a human review queue rather than making an automated routing decision. This prevents ambiguous edge cases from silently slipping through. For model selection, use a fast, cost-efficient model (e.g., GPT-4o-mini, Claude Haiku) since this is a classification task with low latency requirements. Do not use a model that introduces unnecessary latency or cost at the ingress layer.

Add output validation before acting on the classification. The validator should confirm: (1) the response is valid JSON, (2) is_financial_advice is a boolean, (3) confidence_score is a float between 0.0 and 1.0, (4) boundary_category matches one of the expected enum values (investment_recommendation, portfolio_advice, tax_strategy, retirement_planning, insurance_recommendation, estate_planning, none), and (5) refusal_message is non-empty when is_financial_advice is true. If validation fails, retry once with the same input and a stronger instruction to produce valid JSON. If the retry also fails, escalate to human review and return a generic fallback message: 'We're unable to process your request right now. Please contact support.' Never pass unvalidated output downstream.

For observability, log every classification decision with the original user input hash, the model's raw response, the validated classification, the routing decision, and the latency. Emit metrics on boundary-hit rate, confidence distribution, human-escalation rate, and validation-failure rate. Set up alerts for sudden spikes in boundary hits (possible prompt injection campaign) or validation failures (possible model drift). For A/B testing or prompt iteration, run the new prompt in shadow mode alongside the production prompt and compare classification agreement rates before cutting over. This prompt touches a regulatory boundary—treat it with the same change management rigor as production code.