Currency String Sanitization and Conversion Prompt

This prompt is designed for fintech engineers, billing system integrators, and data pipeline operators who receive currency values in inconsistent string formats from large language models. The core job is to strip currency symbols, normalize decimal and thousand separators, handle negative amount formats, and convert the result into a predictable numeric type paired with a validated ISO 4217 currency code. Use this when a model's output contains amounts like '$1,234.56', '(€99,99)', or 'JPY 5000' that must become clean, machine-readable records before entering a ledger, payment gateway, or analytics database.

This prompt is appropriate when the currency string is semantically correct but structurally messy. It is not a currency exchange rate converter, an inflation adjuster, or a tool for interpreting ambiguous natural language like 'a few hundred dollars.' The workflow assumes you already have a string that represents a specific monetary amount and you need to coerce it into a { amount: number, currency: string } structure. The prompt includes explicit handling for accounting-style negatives (parentheses), European decimal commas, and currency codes that may be embedded in the string or provided separately as context. It also validates that the extracted currency code is a real ISO 4217 alpha-3 code, flagging unrecognized codes for human review rather than silently passing them through.

Do not use this prompt when the input is a natural-language description of value (e.g., 'around fifty bucks'), when you need real-time exchange rates, or when the currency string is part of a larger unstructured document that requires extraction before sanitization. In those cases, pair this prompt with an extraction or classification step upstream. For high-risk financial workflows, always log the original string, the sanitized output, and any normalization decisions for auditability. If the prompt cannot resolve a currency code with high confidence, escalate to a human reviewer rather than defaulting to a guess that could cause a transaction error.

This prompt template is designed to be copied directly into your AI harness, test suite, or orchestration layer. It accepts a raw currency string and a set of configuration parameters, then returns a structured JSON object containing the sanitized numeric value, the detected or confirmed ISO 4217 currency code, and a confidence score. The template uses square-bracket placeholders exclusively so you can safely perform string replacement in any programming language without conflicting with JSON braces or model-specific template syntax.

textCopy
You are a currency sanitization engine. Your job is to convert a raw currency string into a clean numeric value and a validated ISO 4217 currency code.

INPUT:
[INPUT]

CONSTRAINTS:
[CONSTRAINTS]

OUTPUT_SCHEMA:
{
  "original": "string (the raw input)",
  "amount": "number (the sanitized numeric value as a float)",
  "currency_code": "string (the 3-letter ISO 4217 code, uppercase)",
  "confidence": "number between 0.0 and 1.0",
  "warnings": ["string (any issues detected during conversion)"]
}

RULES:
1. Strip all currency symbols ($, €, £, ¥, etc.) and whitespace.
2. Normalize decimal separators: treat the last occurrence of ',' or '.' as the decimal separator when ambiguous, based on the detected locale or currency convention.
3. Handle negative amount formats: leading minus, parentheses, 'CR', 'DB', and trailing minus signs.
4. If a currency symbol or code is present, map it to the correct ISO 4217 code. If only a symbol is present and it is ambiguous (e.g., $ for USD/CAD/AUD), set confidence to 0.5 and include a warning.
5. If no currency indicator is present and [DEFAULT_CURRENCY] is provided, use that code and set confidence to 0.3.
6. If the input cannot be parsed, set amount to null, confidence to 0.0, and include a descriptive warning.
7. Do not perform any currency conversion. Return the amount as parsed.
8. Return ONLY the JSON object. No markdown fences, no explanatory text.

To adapt this template, replace [INPUT] with the raw currency string from your model output or user input. Replace [CONSTRAINTS] with any additional rules, such as a maximum allowed value, a list of acceptable currency codes, or locale hints. If you want a fallback currency when none is detected, add a [DEFAULT_CURRENCY] placeholder and wire it into your application logic before sending the prompt. For high-risk financial workflows, always validate the output against your own ISO 4217 registry and numeric range checks before ingestion. This prompt is a sanitization step, not a financial calculation engine—it should feed into, not replace, your existing validation pipeline.

This prompt is designed to be a post-generation repair step, not a standalone service. In a production fintech or billing pipeline, you will typically call this prompt after a primary model has generated a transaction description, invoice line item, or payment record that contains a currency string. The prompt expects a raw currency string as [INPUT] and an optional ISO 4217 currency code as [EXPECTED_CURRENCY]. It returns a structured JSON object with the sanitized numeric value, the detected or validated currency code, and a confidence score. Wire this into your application as a synchronous validation gate before any database insert or API call to a payment processor.

Validation and retry logic is critical here. After receiving the prompt's JSON response, your application code must validate that the confidence field exceeds your configured threshold (we recommend >= 0.95 for financial writes). If confidence is lower, or if the error field is populated, do not silently default the value. Instead, implement a retry loop with a maximum of 2 additional attempts, each time appending the previous error message to the [PREVIOUS_ERRORS] placeholder in the prompt context. If all retries fail, route the record to a human review queue with the original raw string, all repair attempts, and the final error payload. Never write a low-confidence numeric value to a ledger or trigger a payment without human approval.

Logging and audit requirements for financial systems demand that every sanitization call is recorded. Log the full prompt input (excluding any PII in surrounding fields), the raw model response, the parsed output, and the final decision (passed, repaired, or escalated). Use structured logging with a unique repair_id per record so that auditors can trace any currency conversion from raw input to final stored value. For model choice, prefer a fast, cost-effective model like gpt-4o-mini or claude-3-haiku for this task, as it is a narrow extraction and normalization problem that does not require deep reasoning. If you are processing high volumes, batch these calls asynchronously and implement a circuit breaker that halts processing if the error rate exceeds 5% in a rolling 5-minute window, preventing a prompt failure from corrupting your entire transaction pipeline.