Financial Transaction Summary and Approval Prompt

This prompt is designed for fintech and billing engineering teams that need a reliable, human-readable checkpoint before a financial transaction executes. It is not a general-purpose summarizer; its sole job is to take raw, structured transaction details and produce a standardized summary that captures the amount, currency, involved parties, ledger impact, and any regulatory flags. The ideal user is a system orchestrating a human-in-the-loop (HITL) approval workflow where no payment, transfer, or ledger mutation proceeds without explicit confirmation. The prompt should be invoked after all business logic checks have passed but before the transaction is committed to the ledger or sent to a payment gateway.

Use this prompt when the cost of an incorrect autonomous action is high—such as a six-figure wire transfer, a batch payment run, or a transaction that triggers a regulatory reporting obligation—and when auditors require a clear, auditable record of what was approved and why. It is appropriate for workflows where the approving human is a finance operator, a compliance officer, or an engineering lead who needs a concise, structured view of the transaction without reading raw API payloads. The prompt assumes that the input data is already validated and complete; it does not perform fraud detection, balance checks, or sanctions screening. Those checks must happen upstream in the application harness before this prompt is called.

Do not use this prompt for real-time, low-value transactions where human approval would introduce unacceptable latency, such as a consumer tapping a contactless card. It is also not a substitute for a formal regulatory filing or a legal contract. If the transaction involves multiple complex legs, derivatives, or non-standard settlement instructions, the prompt template should be extended with additional fields rather than relying on the model to infer missing structure. Before deploying, ensure that the approval routing logic, audit trail generation, and timeout-based escalation paths are implemented in the application harness, not in the prompt itself. The next section provides the copy-ready template you can adapt to your transaction schema.

This prompt template is designed to be injected into your application's approval workflow. Its job is to take raw transaction data from your system and produce a structured, human-readable summary that a reviewer can quickly assess. The summary must clearly state what will happen, the financial impact, the parties involved, and any regulatory or risk flags that require attention. The output is not the final action; it is a checkpoint that gates execution.

textCopy
Generate a pre-transaction summary for human approval. Use the provided transaction data to create a clear, concise brief. Do not execute any transaction. Your only output should be the summary.

[TRANSACTION_DETAILS]

Generate a summary that includes the following sections. If any information is missing, state 'NOT PROVIDED' for that field.

1.  **Transaction Overview:** A one-sentence description of the action (e.g., 'This is a request to execute a wire transfer.').
2.  **Parties Involved:**
    *   Source: [SOURCE_ACCOUNT_NAME] ([SOURCE_ACCOUNT_MASKED_ID])
    *   Destination: [DESTINATION_ACCOUNT_NAME] ([DESTINATION_ACCOUNT_MASKED_ID])
3.  **Financial Details:**
    *   Amount: [CURRENCY_SYMBOL] [AMOUNT]
    *   Currency: [CURRENCY_CODE]
    *   Estimated Settlement Date: [SETTLEMENT_DATE]
4.  **Ledger Impact Preview:**
    *   Source Account Post-Transaction Balance: [ESTIMATED_SOURCE_BALANCE]
    *   Destination Account Post-Transaction Balance: [ESTIMATED_DESTINATION_BALANCE]
5.  **Regulatory & Risk Flags:**
    *   [List any triggered flags, such as 'Exceeds single-transaction limit', 'New payee', 'Sanctions screening required', or 'None'. If a flag is present, provide a one-line explanation.]
6.  **Required Approvals:**
    *   Based on the amount and risk flags, this transaction requires approval from: [DERIVED_APPROVAL_ROLE] (e.g., 'Manager', 'Compliance Officer').

[CONSTRAINTS]
*   Do not include any conversational filler, greetings, or sign-offs.
*   Format the output using Markdown for readability, with clear headings for each section.
*   If a regulatory flag is present, prefix the summary with a bolded warning: **⚠️ ACTION REQUIRES REVIEW: Regulatory flags are present.**

To adapt this template, replace every square-bracket placeholder with data from your transaction system before sending it to the model. The [DERIVED_APPROVAL_ROLE] should be computed by your application logic based on the amount and risk flags, not by the model. The model's sole responsibility is to format this pre-populated data into the specified summary structure. After the model returns the summary, your harness must present it to the designated human reviewer and log their explicit approval or rejection before any transaction API is called. This prompt is not a substitute for your application's core validation, sanctions screening, or balance checks; it is the final human-readable gate.

This prompt is a pre-execution gate, not a post-hoc log. The harness must call the model, parse its structured output, and then block the transaction until a human approves it. The prompt generates the summary and flags; the harness enforces the approval routing, records the decision, and then—and only then—releases the transaction to the payment or ledger system. Treat the model's output as an input to a deterministic state machine, not as the final authority.

Integration flow: 1) The application assembles the prompt with live transaction data, including [TRANSACTION_DETAILS], [LEDGER_IMPACT], and [REGULATORY_CONTEXT]. 2) The model returns a JSON object with summary, risk_flags, required_approvers, and approval_routing. 3) The harness validates the JSON against a strict schema. If validation fails, retry once with a repair prompt; if it fails again, escalate to an on-call engineer and block the transaction. 4) On valid output, the harness creates an audit record with a unique approval_id, stores the full prompt and response, and routes the summary to the designated human approvers via the existing notification system (e.g., Slack, email, internal tool). 5) The harness polls for approval. If the approval window expires, the transaction is automatically rejected and logged. 6) On approval, the harness executes the transaction and stores the approval decision, timestamp, and approver identity in the audit trail.

Model choice and performance: Use a model with strong JSON mode and low latency for this synchronous gate. GPT-4o or Claude 3.5 Sonnet are suitable. Avoid models prone to hallucinating financial details. Set temperature=0 to maximize determinism. The harness must enforce a strict timeout (e.g., 5 seconds) on the model call; if the model does not respond in time, fail closed and escalate. For high-throughput systems, consider a dedicated, fine-tuned model to reduce token costs and latency, but only after validating it against a golden dataset of edge cases.

Validation and evals: Before deploying, build an eval suite that tests the prompt against: normal transactions, high-value transactions, cross-border payments, transactions with missing regulatory context, and transactions that should trigger specific risk flags (e.g., sanctions list matches, unusual amounts). Measure schema_conformance, risk_flag_recall, and summary_completeness. A human reviewer should grade a sample of outputs for clarity and actionability. In production, monitor the approval rate, time-to-approval, and the rate of schema validation failures. A sudden drop in approval rate may indicate the model is generating confusing summaries; a spike in validation failures may indicate a prompt drift or model version change.

What to avoid: Do not allow the model to execute the transaction directly via function calling. The model's role is strictly advisory. Do not skip the human approval step for transactions above a materiality threshold defined by your finance team. Do not log the full prompt if it contains unmasked sensitive PII; use a redaction proxy before the prompt is assembled and logged. Finally, never use the model's output to auto-determine the approval routing without a secondary, deterministic rules engine that maps risk flags and amounts to your organization's actual delegation of authority policy.