Investment Recommendation Refusal Prompt Template

This prompt is designed for a single, high-stakes job: refusing to provide personalized investment recommendations, portfolio allocation advice, or market timing suggestions in a retail investing or brokerage AI interface. The ideal user is a product engineer or compliance architect embedding an AI copilot into a consumer-facing fintech application. The prompt must be used when the system is subject to regulatory oversight (e.g., SEC, FINRA) and where an unqualified recommendation creates real legal liability, not just brand risk. The required context includes the user's raw query, the system's registered capacity (e.g., educational, execution-only), and any relevant disclaimers already shown in the session.

Do not use this prompt when the user is asking for purely factual security descriptions, historical performance data, or educational content about financial concepts. The prompt is not a general financial disclaimer; it is a targeted refusal for recommendation-like requests. If you apply it to benign requests for definitions or public filings, you will create over-refusal and degrade the user experience. The prompt also assumes the model has no access to the user's personal financial situation, goals, or risk tolerance. If your application does have that data, you must add explicit guardrails that prevent the model from synthesizing a recommendation even when it has the inputs.

Before deploying this prompt, you must define what constitutes a recommendation in your jurisdiction and product context. Work with product counsel to create a concrete taxonomy of prohibited output types: buy/sell/hold statements, portfolio percentage allocations, market timing suggestions, and suitability implications. The prompt template includes placeholder variables for these definitions so you can adapt it to your specific policy. After deployment, monitor for two common failure modes: the model providing an implied recommendation through framing (e.g., 'many investors are buying this right now') and the model refusing a clearly educational request because it contains a ticker symbol. Both require eval checks and likely prompt tuning.

This template is designed to refuse personalized buy/sell/hold recommendations, portfolio allocation advice, and market timing suggestions while still permitting factual security descriptions and educational content. It uses square-bracket placeholders so you can inject your own policy language, risk level, and output schema without rewriting the core refusal logic. The template is structured to be used as a system prompt or as a policy instruction block within a larger system prompt architecture.

textCopy
You are an AI assistant in a retail investing context. Your role is to provide factual information and educational content about securities, markets, and financial concepts. You must refuse any request that asks for personalized investment recommendations, portfolio allocation advice, or market timing suggestions.

When you receive a user request, classify it against the following policy:

- [POLICY_DEFINITION]: A clear statement of what constitutes a disallowed recommendation. For example: "Any statement that suggests a specific action (buy, sell, hold) for a specific security based on the user's personal circumstances, goals, or risk tolerance is disallowed."
- [PERMITTED_CONTENT]: A description of what you may provide. For example: "You may provide factual descriptions of securities, historical performance data, general education about investment concepts, and explanations of regulatory filings."

If the request falls under [POLICY_DEFINITION], respond with the following refusal structure:

1. A clear, direct statement that you cannot provide personalized investment recommendations.
2. A brief explanation of why (reference [POLICY_DEFINITION] without quoting it verbatim).
3. If applicable, offer a [SAFE_ALTERNATIVE] such as factual information about the security or educational content about the relevant concept.
4. If the request involves [HIGH_RISK_DOMAIN] such as options trading, margin, or cryptocurrency, include a [RISK_DISCLAIMER] and recommend consulting a qualified financial professional.

User request: [USER_INPUT]

Respond in the following JSON format:
[OUTPUT_SCHEMA]

To adapt this template, replace each square-bracket placeholder with your organization's specific policy language, risk definitions, and output format requirements. The [POLICY_DEFINITION] should be drafted in collaboration with your compliance team to ensure it accurately reflects regulatory obligations under SEC and FINRA rules. The [SAFE_ALTERNATIVE] placeholder should be populated with a list of permitted response types that your product team has validated as useful without crossing into recommendation territory. If your application requires structured logging for audit purposes, ensure the [OUTPUT_SCHEMA] includes fields for refusal reason codes, policy citations, and timestamps. Before deploying, run this template through your regression test suite using the eval criteria described in the Testing and Evaluation section of this playbook.

This prompt is a policy enforcement gate, not a conversational nicety. It should sit behind your application's orchestration layer, triggered whenever a user input or agent-generated plan touches investment recommendation territory. The prompt expects a structured input containing the user's request, any retrieved context, and a risk classification from an upstream triage step. Do not rely on this prompt alone to detect whether a request is an investment recommendation—pair it with a dedicated classification prompt or a keyword-based pre-filter that flags terms like 'should I buy,' 'best stock,' 'portfolio allocation,' or 'market timing.' The refusal prompt's job is to produce a compliant, consistent refusal when the system already knows the request falls in a regulated category.

Integration pattern: Wire this prompt into a decision node in your workflow. The upstream classifier outputs a risk_level enum (LOW, MEDIUM, HIGH, CRITICAL). For LOW, route to your normal response pipeline. For MEDIUM and above, invoke this refusal prompt with the original user query, the classifier's reasoning, and any relevant policy citations. The prompt returns a structured refusal object containing a refusal_text string, a safe_alternatives array, and a policy_citation field. Your application should validate that the output contains no buy/sell/hold language, no performance predictions, and no suitability implications before surfacing it to the user. Use a secondary LLM judge or a regex-based validator to check for leakage of recommendation language. If the validator flags the output, log the incident, increment a counter metric, and fall back to a static refusal message while alerting the safety engineering channel.

Model selection and latency: This is a safety-critical path, so prefer a capable model with strong instruction-following (GPT-4o, Claude 3.5 Sonnet, or equivalent). Latency is acceptable here—users waiting for a refusal is better than users receiving a bad recommendation. Set a timeout of 10 seconds. If the model call fails or times out, return a hardcoded refusal string from your application layer. Never fall through to an unguarded response. Logging and audit trail: Log every refusal invocation with the request_id, user_id, risk_level, policy_citation, the full prompt sent, the raw model output, and the validator result. These logs are your audit evidence if a regulator or internal compliance team questions why a particular response was surfaced. Store them in an append-only log system with retention aligned to your organization's compliance requirements (typically 3-7 years for financial services).

Human escalation trigger: If the risk_level is CRITICAL or if the user pushes back after a refusal (detected via a follow-up intent classifier), route the conversation to a human review queue. Do not let the model re-engage on the same topic. The escalation payload should include the full conversation history, the refusal that was shown, and the user's follow-up message. Testing before deployment: Run this prompt through a regression suite containing at least 50 test cases: direct recommendation requests ('What stock should I buy?'), implied requests ('I have $10k, where should I put it?'), performance predictions ('Will AAPL go up next quarter?'), suitability-adjacent language ('Is this ETF right for someone like me?'), and benign educational requests ('What's the difference between a stock and a bond?'). Measure refusal rate, false positive rate on educational content, and refusal consistency across rephrasings. Gate deployment on passing all safety-critical test cases and maintaining a false positive rate below 5% on educational content.