How to Use an LLM to Triage Payment Fraud Alerts

Before writing any prompt, write down the boundary. There are three plausible designs, and you should pick deliberately.

Most teams should start at copilot and only move to triage once they have measured data. The reason is that a false decline is not free: it destroys the relationship with a good customer, which is a cost the business feels long after the transaction (Signifyd). A model that is right about fraud but wrong about good customers will look excellent on a fraud metric and terrible on revenue.

There is also a governance argument. J.P. Morgan's guidance for payments staff recommends documented approval processes, dual authority on payments and consistent escalation procedures, precisely because a single unchecked decision point is the vulnerability (J.P. Morgan). Giving a model unilateral authority is a single unchecked decision point with extra steps. Keep two humans, or one human plus an auditable model, on every release of funds.

A model asked to judge an alert without context will produce confident nonsense. The prompt is only as good as the records you attach to it. Build three blocks.

Order block. Amount, currency, merchant category, shipping and billing addresses, whether the bill-to and ship-to match, whether this is the first order from this customer, and any line items that are themselves resellable (gift cards, electronics, digital codes). Card testing, the fraud pattern where a stolen card is validated with a small charge, is usually recognizable from order characteristics: tiny amounts, repeated attempts, digital goods (Stripe). J.P. Morgan's card testing guide points out that these test transactions are deliberately zero or low dollar so they do not trip fraud detection (J.P. Morgan). Give the model the amount and the product type and it can name this pattern.

Device and session block. Device fingerprint, IP country, whether the device has been seen on this account before, time from account creation to checkout, and the result of any 3D Secure authentication. This last one carries legal weight: when a card-not-present transaction is fully authenticated with 3DS and the correct ECI and authentication values are passed, liability for fraudulent disputes generally shifts to the issuing bank, though non-fraud disputes like goods not received are not covered (gpayments). If 3DS passed, the model should know it, because it changes the risk calculus and the potential loss.

Customer history block. Account age, lifetime order count, previous chargebacks against this customer, and velocity in the last 24 hours and 7 days. Do not send the raw history; send the aggregates plus a short list of the five most recent orders. Long context makes models slower, more expensive and more likely to latch onto an irrelevant detail.

A worked example of the shape, not the content, of what you send:

{
  "alert_id": "AL-10482",
  "trigger_rule": "velocity_country_mismatch",
  "order": {"amount": 12.00, "currency": "USD", "mcc": "digital_goods", "bill_to_country": "US", "ship_to_country": "US", "first_order": false},
  "device": {"seen_on_account": false, "ip_country": "RO", "account_age_days": 210, "minutes_since_signup": null, "three_ds_result": "not_attempted"},
  "history": {"lifetime_orders": 14, "chargebacks_lifetime": 0, "orders_24h": 5, "orders_7d": 6, "avg_order_value": 85.00},
  "recent_orders": [{"days_ago": 2, "amount": 90.00, "status": "delivered"}]
}

The human reviewer should see the same facts, in the same order, next to the model's verdict. That way the reviewer can disagree with the model's reasoning without having to redo the data pull.

Ask for free text and you get prose. Ask for a schema and you get something you can route, filter, count and validate. The MLflow guidance on structured outputs is blunt about this: schema-constrained generation guarantees syntactic validity and reduces parsing errors compared to prompted JSON, but it does not guarantee the values are correct, so you still need runtime validation (MLflow). Design for both.

A workable schema for a fraud verdict:

{
  "risk_score": 0,
  "top_reasons": ["", "", ""],
  "pattern": "card_testing | account_takeover | friendly_fraud | legitimate | unclear",
  "recommended_action": "approve | hold | block | request_verification",
  "confidence": "low | medium | high",
  "missing_information": [""]
}

Four design rules make this schema hold up in production.

Score in a fixed band, not a percentage. A 0 to 100 score invites false precision. A 0 to 3 band that matches how your reviewers already think (clear, watch, suspicious, block) produces more consistent output.

Cap the reasons at three. A model that lists twelve reasons has not prioritized, and a reviewer cannot read twelve reasons at 2 a.m. Three forces the model to rank.

Require a pattern label drawn from a fixed list. The Fed's work on fraud classification exists precisely because inconsistent terminology between analysts makes cases hard to compare (FedPayments Improvement). An enum in the schema gives you the same consistency for free.

Demand a missing-information field. The single most useful thing the model can say is "I cannot tell whether the shipping address has been used before, because you did not send it." That field tells you which context block to fix, and it stops the model from inventing an answer.

Validate every response against the schema before it enters the queue. If validation fails, do not pass the raw text to the reviewer; retry once with the validation error appended, then route to a human with the failure flagged. Silent malformed output is the failure mode that erodes trust fastest (MLflow).

The audit trail is not paperwork. It is the mechanism that lets you measure the model and defend it later.

Log four things for every alert: the exact prompt (including the context blocks), the raw model response, the validated structured verdict, and the human decision with the reviewer's identity and timestamp. Tie them to the alert ID. Chipper Cash, describing its fraud email triage pipeline, reports that its prior manual process took roughly thirty minutes per email, that its Google Sheet was the system of record but entries depended on who filled them in and when, and that the new pipeline posts a notification and writes an audit trail for every action (Chipper Cash). The lesson is not the speed. It is that the audit trail became the product.

With that log you can compute the numbers that justify giving the model more weight.

Set a gate before you ever let the model's verdict change what happens to money. A reasonable gate: the model's precision on high risk alerts must exceed your current rules' precision on the same population, measured over a sample large enough that the difference is not noise, and the override rate must be stable. Until then, the model's recommendation is displayed to reviewers but not enforced.

Run each model verdict against a holdout. In every batch of alerts the model scores, keep a slice where reviewers see the model's verdict only after they have made their own decision. That slice is the only honest measure of whether the model would have helped.

Three failure modes deserve a named owner.

Friendly fraud mistaken for stolen cards. A cardholder disputing a legitimate purchase looks, from a distance, like fraud. Friendly fraud is widely reported as a large share of disputes, and it is filed by the actual customer, often out of genuine confusion about a billing descriptor (Visa). Give the model the customer's dispute history and the merchant descriptor, and ask it to consider friendly fraud explicitly as a pattern label. A model that treats every dispute as a stolen card will get the wrong answer in a large fraction of cases.

Card testing drowned in noise. A card testing attack generates a burst of small authorizations, and automated attackers rotate IPs and vary timing to blend in (Chargeback Gurus). The model should be told the velocity of attempts per card and per device over a short window, and the reviewer should be able to see whether this alert is one of a cluster. A single low-value alert is unremarkable. Forty in an hour is a different case.

Prompt leaks and PII. The Fed's guidance is explicit that this analysis should happen inside a bank-approved generative AI environment designed to safeguard sensitive customer information, rather than in external, ungoverned systems (FedPayments Improvement). If your fraud queue contains names, addresses and account numbers, and it will, the model runs in an environment your security team has approved, with the same access controls as the rest of the queue.

Give the model a review horizon of four to six weeks before changing anything about who decides. During that time the model runs in shadow mode: it scores every alert, the human decides every alert, and you compute the table above weekly.

When you are ready to move from copilot to triage, do it by band, not by category. Start with the lowest-risk slice: small amounts, established accounts, no prior chargebacks, and specifically not anything routed through a liability shift. If the model's precision holds there, expand to the next band. Keep the top band (the alerts most likely to be genuine fraud) fully human for longer, because that is where a wrong approval costs the most.

The model is also a prompt-and-context consumer, so run it through one gateway rather than wiring each product separately. Quanta Inference (https://quantaintelligence.ai/inference) puts text, image and embedding models behind a single OpenAI-compatible key priced in dollars, which makes it easy to swap the model behind your verdict schema while the schema and the logging stay fixed. That separation, not the model choice, is what keeps the pipeline stable.