Account Closure Approval Prompt for FinServ Agents

This prompt is designed for financial services operations teams that are automating account lifecycle management. Its primary job is to generate a structured, evidence-backed approval request before an account closure is initiated. The ideal user is a back-office agent, a customer service representative, or an automated workflow system that needs to package a complete summary—including balance disposition, regulatory holds, outstanding obligations, and a customer communication plan—for a human manager or compliance officer to review and approve. The prompt forces the AI to act as a meticulous preparer, not a decision-maker, ensuring that no closure proceeds without explicit human sign-off.

Use this prompt when the cost of an incorrect closure is high, such as closing an account with a non-zero balance that hasn't been properly disposed of, ignoring an active regulatory or legal hold, or failing to settle pending transactions. It is appropriate for integrating into a case management system where a human agent triggers the 'Request Closure Approval' action. The prompt requires several critical inputs to function safely: the full account profile, a list of active holds, a transaction history for a specified lookback period, and the firm's standard operating procedure for closures. Without these, the generated approval request will be incomplete and should be programmatically blocked from reaching a reviewer.

Do not use this prompt for low-risk, self-service account deactivations where a customer can close a zero-balance account without manual review. It is also unsuitable for scenarios where the AI is expected to make the final decision; the output is always a request for approval, never an execution command. The downstream system must be designed to parse the structured output, present it in a review queue, and only execute the closure after a human provides an approved status. The primary failure mode is a false sense of security—a well-written summary that masks a missing regulatory check. Therefore, the implementation must include hard validation rules that reject any approval request missing a required section, such as the regulatory hold check or the balance disposition plan.

This prompt template is designed to be embedded in a financial services agent workflow that handles account lifecycle management. It takes structured account data and produces a human-readable approval request that a compliance officer or operations manager can review before the account is terminated. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into an application that fetches account records, flags, and pending transactions before calling the model.

textCopy
You are an account closure review assistant for a regulated financial institution. Your job is to produce a structured closure approval request that a human reviewer can act on. You do not approve or deny closures yourself.

## INPUT DATA
Account Details:
[ACCOUNT_DETAILS_JSON]

Regulatory Hold Flags:
[REGULATORY_HOLDS_JSON]

Pending Transactions:
[PENDING_TRANSACTIONS_JSON]

Outstanding Obligations:
[OUTSTANDING_OBLIGATIONS_JSON]

Customer Communication History:
[COMMUNICATION_HISTORY_JSON]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
{
  "request_id": "string, unique identifier for this approval request",
  "account_summary": {
    "account_id": "string",
    "account_type": "string",
    "customer_name": "string",
    "account_age_days": "number",
    "current_balance": "string, formatted as currency",
    "closure_reason": "string, customer-stated or system-detected reason"
  },
  "balance_disposition": {
    "method": "string, one of: transfer, check, wire, hold",
    "destination_account": "string or null",
    "estimated_amount": "string, formatted as currency",
    "fees_applicable": "boolean",
    "fee_breakdown": "string or null"
  },
  "regulatory_hold_check": {
    "holds_active": "boolean",
    "hold_details": ["string, description of each active hold"],
    "requires_legal_review": "boolean",
    "legal_review_rationale": "string or null"
  },
  "outstanding_obligations": {
    "has_obligations": "boolean",
    "obligation_list": [
      {
        "type": "string, e.g., loan, credit_card, safe_deposit_box",
        "status": "string, e.g., active, past_due, in_collections",
        "resolution_required": "boolean",
        "resolution_notes": "string"
      }
    ]
  },
  "pending_transactions": {
    "has_pending": "boolean",
    "transaction_count": "number",
    "total_pending_amount": "string, formatted as currency",
    "oldest_pending_days": "number",
    "requires_settlement_wait": "boolean"
  },
  "customer_communication_plan": {
    "required_notifications": ["string, list of required communications"],
    "cooling_off_period_days": "number",
    "retention_offer_eligible": "boolean",
    "retention_offer_details": "string or null"
  },
  "risk_assessment": {
    "overall_risk_level": "string, one of: low, medium, high, critical",
    "risk_factors": ["string, specific risk factors identified"],
    "recommended_action": "string, one of: proceed, hold_for_review, escalate_to_compliance, escalate_to_legal",
    "recommendation_rationale": "string"
  },
  "approval_required": {
    "approver_role": "string, e.g., branch_manager, compliance_officer, operations_lead",
    "approval_deadline_iso": "string, ISO 8601 datetime",
    "additional_approvers": ["string, additional roles required"]
  }
}

## CONSTRAINTS
- If any regulatory hold is active, set recommended_action to "escalate_to_compliance" and requires_legal_review to true.
- If pending transactions exist and the oldest is less than [SETTLEMENT_WINDOW_DAYS] days old, set requires_settlement_wait to true.
- If outstanding obligations exist with status "past_due" or "in_collections", set recommended_action to "hold_for_review".
- If overall_risk_level is "critical", require at least two approvers.
- Never recommend "proceed" if holds_active is true, has_pending is true with unsettled transactions, or has_obligations is true with unresolved items.
- Format all currency fields as "$X,XXX.XX".
- If any required field cannot be determined from the input data, set it to null and include the reason in recommendation_rationale.

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each bracketed placeholder with data from your account management system. The [ACCOUNT_DETAILS_JSON] should include at minimum the account ID, type, customer name, age, balance, and closure reason. The [REGULATORY_HOLDS_JSON] array should list any active legal, fraud, or compliance holds with descriptions. The [SETTLEMENT_WINDOW_DAYS] value should match your institution's transaction settlement policy, typically 3–7 business days. The [RISK_LEVEL] placeholder accepts a value like "high" to adjust the scrutiny applied. The [EXAMPLES] placeholder should contain one or two few-shot examples of correctly formatted approval requests for common scenarios, such as a straightforward closure with no holds and a complex closure with multiple risk factors.

Before deploying this prompt, validate that your application layer enriches the input data completely. Missing regulatory hold information or stale transaction data will cause the model to produce an incomplete risk assessment. Always log the full prompt and response for audit purposes, and ensure the human reviewer sees the original account data alongside the generated approval request. Do not use this prompt to auto-approve closures; the output is a recommendation package for human decision-making only.

This prompt is designed to sit at a critical decision boundary in an account lifecycle automation system. It should be invoked after the AI agent has gathered all required account data—balance, transactions, regulatory flags, obligations—but before any termination API call is made. The prompt's job is to produce a structured approval request that a human reviewer can evaluate quickly. The application layer must enforce that no closure action proceeds until the approval response is explicitly confirmed and logged.

Wire the prompt into a state machine or workflow orchestrator (e.g., Temporal, AWS Step Functions, or a custom queue-based pipeline). The flow should be: (1) Agent collects account context and populates the [ACCOUNT_SUMMARY], [BALANCE_DISPOSITION], [REGULATORY_HOLDS], [OUTSTANDING_OBLIGATIONS], and [COMMUNICATION_PLAN] placeholders from internal systems. (2) The assembled prompt is sent to a capable model (GPT-4o or Claude 3.5 Sonnet recommended for structured compliance reasoning). (3) The model's JSON output is validated against a strict schema: required fields include closure_ready (boolean), blocking_conditions (array of strings), risk_level (enum: LOW/MEDIUM/HIGH/CRITICAL), and approval_items (array of objects with item, status, evidence). (4) If validation fails, retry once with the validation errors injected into the prompt as [PREVIOUS_ERRORS]. If it fails again, escalate to a human operator with the raw output and error log.

The approval request must be surfaced in a review UI, not just logged. Present the structured output in a human-readable card showing each approval item with its status (CLEARED/NEEDS_REVIEW/BLOCKED), the evidence snippet, and the overall risk level. The reviewer must explicitly click 'Approve Closure' or 'Reject Closure.' On approval, the system records the reviewer's identity, timestamp, and the full prompt + response payload as an immutable audit record before calling the account termination API. On rejection, the system records the rejection reason and routes the case to an exceptions queue. Never allow the model's closure_ready boolean to auto-approve the action—it is an advisory signal for the reviewer, not a decision.

For testing, build a harness that feeds known account profiles (clean closure, account with pending transactions, account with active regulatory hold, account with unresolved disputes) and asserts that the output correctly flags blocking conditions. Eval criteria should include: (a) closure_ready must be false when any blocking condition exists, (b) risk_level must be CRITICAL when regulatory holds are present, (c) every approval_item must include non-empty evidence, and (d) the output must never suggest skipping a required check. Run these evals in CI before deploying prompt changes. In production, monitor the rate of CRITICAL vs. LOW risk closures and alert if the ratio shifts unexpectedly, which may indicate prompt drift or data quality issues upstream.