Financial Transaction Approval Prompt for Agents

This prompt is the critical safety gate for any autonomous agent operating in a regulated fintech environment. Its primary job is not to execute a payment, but to force a structured, auditable pause between an agent's intent to move funds and the actual invocation of a payment tool. The ideal user is a platform engineer or compliance officer embedding an AI agent into a payment processing pipeline, where the cost of an erroneous or unapproved transaction is high. You need this prompt when your agent handles multi-currency transfers, interacts with banking APIs, or must produce a decision record that satisfies internal audit and external regulatory requirements. It is designed for workflows where the agent has already gathered the necessary transaction details and is now seeking a definitive 'approved' or 'rejected' signal before proceeding.

The prompt's core mechanism is to surface a complete, structured approval request containing the transaction amount, counterparty, currency, purpose code, and a set of computed risk flags. It encodes threshold-based routing logic directly into the instructions, creating two distinct paths: a streamlined auto-approval path for low-risk, low-value transactions that fall within pre-defined parameters, and a mandatory escalation path for high-risk transactions that require explicit human review. This design prevents the agent from bypassing the approval gate through prompt injection or ambiguous reasoning. For example, a transaction under $500 with a standard purpose code and a known counterparty might be routed for automatic logging, while a five-figure wire to a new beneficiary in a high-risk jurisdiction would be blocked until a compliance officer provides a documented sign-off. The prompt's output is a structured object that serves as both a control signal for your application logic and an immutable record for your audit trail.

Do not use this prompt as a standalone payment execution instruction or as a replacement for robust backend authorization logic. It is a decision-support and gating mechanism, not a security control. The application layer must enforce the approval decision; the prompt's role is to make that decision explicit, consistent, and auditable. Before deploying, ensure your system can provide the required input context—specifically, the transaction payload and a computed risk profile—and that your downstream tools are wired to respect the approval outcome. The next step is to integrate this prompt into your agent's tool-calling loop, configure your risk scoring service, and establish the human review queue for escalated transactions.

This template is designed to be pasted directly into your agent's system instructions or the description of a dedicated request_transaction_approval tool. It forces the agent to halt execution and produce a structured payload that your application layer can route to a human review queue. The prompt does not assume a specific model; it uses explicit constraints, a required output schema, and conditional logic to ensure consistent behavior across frontier models. Replace every square-bracket placeholder with values from your own risk policy, currency allowlists, and routing rules before deployment.

markdownCopy
You are a financial controls agent. Your sole responsibility is to evaluate a requested transaction and produce a structured approval request. You do not execute transactions. You do not make risk decisions. You only produce the approval payload.

## Required Inputs
Before generating the approval request, you must have the following fields from the calling system or user context. If any field is missing, respond with a structured error asking for the specific missing field.
- [TRANSACTION_AMOUNT]
- [CURRENCY_CODE]
- [COUNTERPARTY_IDENTIFIER]
- [COUNTERPARTY_NAME]
- [PAYMENT_RAIL]
- [PURPOSE_CODE]
- [INITIATOR_ROLE]
- [SOURCE_ACCOUNT_ID]
- [DESTINATION_ACCOUNT_ID]

## Output Schema
Produce a single JSON object conforming to this structure. Do not include any text outside the JSON object.
{
  "approval_request_id": "string, UUID v4 generated by you",
  "timestamp": "string, ISO 8601 UTC",
  "transaction_summary": {
    "amount": "string, formatted with currency symbol",
    "counterparty": "string, name and identifier",
    "payment_rail": "string",
    "purpose_code": "string",
    "initiator": "string, role and department"
  },
  "risk_flags": [
    {
      "flag_type": "string, one of: AMOUNT_THRESHOLD | COUNTERPARTY_RISK | JURISDICTION_RISK | RAIL_RISK | PURPOSE_ANOMALY | FREQUENCY_ANOMALY | SANCTIONS_HIT | UNVERIFIED_ACCOUNT",
      "severity": "string, one of: LOW | MEDIUM | HIGH | CRITICAL",
      "description": "string, specific and evidence-based, not speculative",
      "triggered_rule": "string, reference to the specific policy rule ID that fired"
    }
  ],
  "routing": {
    "approval_threshold": "string, one of: AUTO_APPROVE | LEVEL_1 | LEVEL_2 | LEVEL_3 | EXECUTIVE | BLOCKED",
    "required_reviewers": ["string, role identifiers"],
    "escalation_timeout_minutes": "integer",
    "queue_name": "string"
  },
  "audit_trail": {
    "policy_version": "string, the version of the risk policy applied",
    "rules_evaluated": "integer, count of rules checked",
    "rules_triggered": "integer, count of rules that fired",
    "evidence_sources": ["string, systems or datasets consulted"]
  },
  "source_account_risk_score": "integer, 0-100",
  "destination_account_risk_score": "integer, 0-100",
  "overall_risk_score": "integer, 0-100"
}

## Threshold-Based Routing Logic
Apply these rules in order to determine the `routing.approval_threshold` field:
1. If `overall_risk_score` is 0-20 AND no risk flag has severity HIGH or above: `AUTO_APPROVE`
2. If `overall_risk_score` is 21-50 OR any single HIGH severity flag: `LEVEL_1`
3. If `overall_risk_score` is 51-75 OR any CRITICAL flag OR `transaction_summary.amount` exceeds [LEVEL_2_AMOUNT_THRESHOLD]: `LEVEL_2`
4. If `overall_risk_score` is 76-90 OR multiple CRITICAL flags: `LEVEL_3`
5. If `overall_risk_score` is 91-100: `EXECUTIVE`
6. If any SANCTIONS_HIT flag is present: `BLOCKED` (override all other rules)

## Constraints
- Never execute a transaction. This prompt is for approval generation only.
- Never downgrade a risk flag severity to make a transaction appear safer.
- If the counterparty appears on [SANCTIONS_LIST_NAME], you MUST include a SANCTIONS_HIT flag with CRITICAL severity.
- If the transaction amount exceeds [MANDATORY_REVIEW_THRESHOLD], routing must be at least LEVEL_2 regardless of risk score.
- If the purpose code does not match expected patterns for this counterparty, include a PURPOSE_ANOMALY flag.
- If the payment rail is [HIGH_RISK_RAIL_LIST], include a RAIL_RISK flag with at least MEDIUM severity.
- All descriptions in risk flags must reference specific evidence, not vague concerns.
- Generate a new UUID for `approval_request_id` on every invocation.
- If you cannot determine any required field, respond with: {"error": "MISSING_FIELD", "missing_field": "[field_name]", "message": "Cannot generate approval request without [field_name]."}

## Examples
[FEW_SHOT_EXAMPLE_1]
[FEW_SHOT_EXAMPLE_2]
[COUNTEREXAMPLE_INSUFFICIENT_ESCALATION]

After pasting this template, replace the placeholders with your organization's specific values. [LEVEL_2_AMOUNT_THRESHOLD] should be a numeric value in your base currency. [SANCTIONS_LIST_NAME] should reference the exact name of the sanctions dataset your compliance system queries. [HIGH_RISK_RAIL_LIST] should enumerate payment rails that require additional scrutiny, such as cross-border wires or cryptocurrency rails. The [FEW_SHOT_EXAMPLE_*] placeholders should be replaced with 2-3 real examples drawn from your historical approvals, including at least one that was correctly escalated and one that was correctly auto-approved. The [COUNTEREXAMPLE_INSUFFICIENT_ESCALATION] should show a case where the risk score was miscalculated and the routing was too permissive, teaching the model what failure looks like. Test the prompt with at least 20 historical transactions where you know the correct routing outcome before deploying to production.

The financial transaction approval prompt is not a standalone artifact—it is a decision gate inside a larger agent harness. In production, the prompt sits between the agent's intent to execute a payment and the actual API call to the payment rail. The harness is responsible for: (1) assembling the prompt with live transaction context, (2) enforcing that the model cannot bypass the approval gate, (3) validating the structured output before routing to a human reviewer, and (4) logging every approval decision for audit. Without this harness, the prompt is advisory text, not a control.

Start by defining a strict tool contract. The agent must call a request_transaction_approval function—not generate free text—when it intends to move money. This function's schema should map directly to the prompt's placeholders: [TRANSACTION_AMOUNT], [CURRENCY], [COUNTERPARTY], [COUNTERPARTY_COUNTRY], [PURPOSE_CODE], [SOURCE_ACCOUNT], [DESTINATION_ACCOUNT], and [RISK_FLAGS]. The harness validates that all required fields are present and that the amount, currency code, and purpose code match allowed enumerations before the prompt is even assembled. If validation fails, the harness rejects the tool call and returns a structured error to the agent—do not let a malformed request reach the model or a human reviewer. For model choice, prefer a model with strong structured output support (e.g., GPT-4o with response_format set to json_schema or Claude with tool-use mode). The output schema must include: approval_decision (enum: APPROVE, ESCALATE, REJECT), risk_score (integer 0-100), required_reviewer_role (string), escalation_reason (string if escalated), and audit_summary (string for the audit trail).

Retry logic must be bounded and observable. If the model returns malformed JSON, missing required fields, or a risk score outside the 0-100 range, the harness retries once with the same prompt plus the validation error message appended as a [REPAIR_INSTRUCTION]. If the second attempt also fails, the harness escalates to a human operator with a MANUAL_REVIEW_REQUIRED status and the raw model output attached. Never retry more than twice—silent loops here create compliance risk. For logging, emit a structured audit event on every approval decision that includes: transaction_id, timestamp, model_id, prompt_version, input_context_hash, output_decision, risk_score, reviewer_identity (if human-reviewed), and final_disposition. This log must be append-only and immutable in your audit store. If the decision is APPROVE and the risk score is below the configured auto-approval threshold (e.g., 30), the harness may proceed to execute the payment. If the decision is ESCALATE or the risk score exceeds the threshold, the harness routes the approval request to a human review queue with the full prompt context and model output. The human reviewer sees the model's recommendation but makes the final decision—the harness must record the reviewer's identity, decision, and timestamp separately from the model's output.

Human review integration requires careful state management. When a transaction is queued for review, the harness must set a timeout (e.g., 15 minutes for high-velocity payments, 4 hours for batch). If the timeout expires without a human decision, the harness must apply a configurable default policy—typically REJECT for outbound payments and ESCALATE to a secondary reviewer for internal transfers. The review interface should surface: the transaction details, the model's risk assessment, a link to the counterparty's sanction screening result, and the last 5 transactions from the same source account for pattern detection. Do not let the reviewer see only the model's summary—they need the raw inputs. After the human decides, the harness writes the final disposition back to the agent's context so it can proceed or halt. If the agent attempts to call the payment execution tool without a valid approval record, the harness must reject the call with a MISSING_APPROVAL error. This is the hard enforcement point—no approval record, no payment.

Finally, test this harness against known failure modes before any real money flows. Simulate: a model that returns APPROVE on a transaction above the auto-approval threshold (harness must still escalate), a model that hallucinates a risk score of 150 (validation must catch it), a human reviewer who times out (default policy must fire), and an agent that attempts to call the payment tool directly without requesting approval (tool gateway must block it). Run these tests in a sandbox environment with mock payment endpoints and a test review queue. The prompt is only as reliable as the harness that enforces its output.