Financial Transaction Approval Prompt Template

This prompt is designed for payment and fintech agent builders who need a reliable pre-transaction approval gate. Use it when your AI system must generate a structured confirmation payload before executing any financial transaction, including payments, refunds, transfers, or disbursements. The prompt produces a human-readable approval card with amount, recipient, currency, fee breakdown, risk flags, and threshold compliance checks. It is not a transaction execution prompt. It stops before execution and requires explicit human authorization. Use this when the cost of an autonomous mistake is financial loss, regulatory exposure, or irreversible fund movement.

The ideal user is an engineering lead or product manager integrating an AI agent into a financial operations workflow. The required context includes the raw transaction payload, a customer profile, a risk score, and a set of business rules like amount thresholds or velocity limits. The prompt is most effective when wired into a state machine where the AI's output is parsed into a JSON schema and rendered as a confirmation card in a human review queue. Do not use this prompt for low-risk, non-financial actions, or for transactions where the AI is authorized to execute autonomously. It is also unsuitable for real-time, high-frequency trading systems where latency constraints preclude human review.

Before deploying this prompt, ensure you have defined the exact approval schema your downstream system expects. The prompt's value is in standardizing the approval language and surfacing hidden risks like duplicate transactions or threshold breaches. The next step after generating the approval card is to route it to a human reviewer with the authority to approve or reject. Avoid the temptation to use the model's output as a direct execution signal; always maintain a hard separation between the approval generation step and the execution step in your application logic.

This prompt template is designed to be placed directly into your system instructions or sent as a user message before a financial action is executed. Its job is to force the AI to stop, package all critical transaction details into a structured confirmation payload, and explicitly request human authorization. It does not execute the transaction. Instead, it produces a review-ready artifact that a human operator or an upstream orchestration layer can inspect, approve, or reject. Use this template whenever your agent is about to initiate a payment, refund, transfer, or any other irreversible movement of funds.

textCopy
You are a financial transaction gatekeeper. Your only job is to produce a structured pre-transaction confirmation payload. You must never execute, simulate, or authorize a transaction.

Before generating the payload, validate the following:
- [AMOUNT] is a positive number and does not exceed the single-transaction threshold defined in [THRESHOLD_RULES].
- [RECIPIENT] is not on the [BLOCKED_ENTITIES_LIST].
- This transaction is not a duplicate of any transaction in [RECENT_TRANSACTION_LOG] within the last [DUPLICATE_WINDOW_MINUTES] minutes.
- The [CURRENCY] matches the expected currency for the [SOURCE_ACCOUNT].

If any validation fails, stop and output a `blocked_transaction` object with the failure reason. Do not proceed to the confirmation payload.

If all validations pass, generate a `confirmation_payload` JSON object using exactly the schema below:

{
  "transaction_id": "string, a unique ID generated for this request",
  "status": "pending_approval",
  "summary": "A one-sentence, human-readable summary of the transaction.",
  "details": {
    "amount": "number, the transaction amount",
    "currency": "string, ISO 4217 code",
    "recipient": {
      "name": "string",
      "identifier": "string, account or routing identifier"
    },
    "source_account": "string",
    "fee_breakdown": {
      "transaction_fee": "number",
      "processing_fee": "number",
      "total_fee": "number"
    },
    "reference": "string, invoice or payment reference"
  },
  "risk_flags": [
    {
      "flag": "string, e.g., 'high_value', 'new_recipient', 'unusual_location'",
      "severity": "low | medium | high",
      "description": "A brief explanation of the flag."
    }
  ],
  "required_approvals": ["string, role or individual required to approve"],
  "expires_at": "ISO 8601 timestamp, after which this approval request is void"
}

Now, process the following transaction request and output only the JSON object, with no additional text or markdown fences.

Transaction Request:
- Amount: [AMOUNT]
- Currency: [CURRENCY]
- Recipient: [RECIPIENT]
- Source Account: [SOURCE_ACCOUNT]
- Reference: [REFERENCE]

After pasting this template, replace every square-bracket placeholder with live data from your application context. The [THRESHOLD_RULES] and [BLOCKED_ENTITIES_LIST] placeholders should be populated from your policy engine or a trusted data store, not hardcoded. The [RECENT_TRANSACTION_LOG] should be a time-windowed query against your ledger to catch duplicates. The output is a single JSON object that your application must parse and route to a human review queue. Do not allow the model to proceed past this step. The next action in your workflow must be a human decision, not another model call.

This prompt is designed to be the final checkpoint in a payment agent's execution loop. It should be called after the agent has collected all transaction details but before any API call to a payment processor (Stripe, Adyen, internal ledger). The application layer is responsible for assembling the [TRANSACTION_DETAILS] object from user input, session context, and system lookups. The model's output is a structured confirmation payload, not an executed transaction. The application must parse this payload and present it to a human for explicit authorization.

Integration flow: 1) The application constructs the prompt with the required placeholders, including [TRANSACTION_DETAILS] (amount, currency, recipient, method), [ACCOUNT_CONTEXT] (available balance, daily limits), and [RISK_POLICIES] (threshold rules, velocity checks). 2) The LLM generates a JSON confirmation payload containing approval_card (human-readable summary), risk_flags (duplicate, threshold breach), and requires_approval (boolean). 3) The application validates the JSON schema strictly. If requires_approval is true or validation fails, the transaction is blocked and the approval_card is pushed to a human review queue (e.g., a Slack channel, internal tool, or mobile push). 4) The human's decision (approve/reject) is logged immutably alongside the generated payload and the final transaction ID for audit.

Validation and retries: Implement a JSON schema validator in your application code. If the model output fails to parse, retry once with a repair prompt that includes the raw output and the schema. If the second attempt fails, escalate to a human operator with the raw context. Never execute a transaction on a failed parse. For high-value transactions (configurable threshold), add a mandatory multi-stakeholder approval step by routing the approval_card to a secondary reviewer. Log every step—prompt version, raw model output, validation result, and human decision—to an append-only audit store. This trace is critical for compliance and debugging false-positive risk flags.