Finic
ContactTry the API
Card fraud

Screen card authorizations for fraud in real time

Grayson screens card authorizations for card testing, fallback and card-not-present fraud from recent card activity, and picks approve, step up or decline.

Grayson screens a card authorization against the card's recent activity and the cardholder's usual spending, and returns how likely it is to be fraud, whether the card number was just run through card testing, and whether to approve, step up or decline. It can run in parallel with your existing rules and models as an extra signal, and costs about $0.44 to $0.62 per 1,000 decisions.

  • Decides: Score card authorizations for fraud and choose approve, step up or decline, next to your existing rules.
  • Call it: When a card authorization request arrives
  • Questions: 1 score, 1 yes/no, 1 choice
  • Cost: $0.00044 to $0.00062 per decision ($0.44 to $0.62 per 1,000) for these examples' 12,661 to 17,676 input tokens
  • Latency: 196 to 248 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three authorizations, each sent with 90 to 110 days of the card's earlier authorizations (about 160 to 270 of them, with declines, refunds, reversals and recurring charges), the cardholder's devices and 3-D Secure history, activity at the merchant across the issuer's cards, and the scores and rules that already ran. They are a card number tested at a charity's donation page and then typed into a $749.99 electronics order, a traveler's first in-store purchase in Lisbon, and a $684.97 sneaker resale order from a new computer on a card exposed in a merchant breach.

Open in Playground

Open in Playground

Open in Playground

A yes/no answer is Grayson's probability that it's true. A choice answer is the top option and Grayson's confidence: 0% when every option is equally likely, 100% when one option has all the probability. A score answer is the expected level, numbering the levels in its criteria from 0, with its confidence measured the same way and, when no level reaches 70%, each level's probability. A multiple-choice answer lists the options at 50% or more.

  • action is the recommendation. Start by combining it with your existing decision, for example stepping up when your rules approve but Grayson favors decline.
  • fraud_likelihood: threshold the sum of "Likely" and "Very likely", with separate cutoffs for card-present, card-not-present and cross-border authorizations.
  • card_tested is about the card: a number that passed a test is compromised even if this purchase is declined, so block and reissue it.

Call it from your code

Save an example as request.json, such as fraud.json, and send it with your API key in GRAYSON_API_KEY:

curl https://api.finic.ai/v1/decide \
  -H "Authorization: Bearer $GRAYSON_API_KEY" \
  -H "Content-Type: application/json" \
  --data @request.json

The problem

Rules check fixed conditions, so they miss a $749.99 purchase that follows a $1 test at a charity page when no single threshold is crossed, and they decline a traveling cardholder's first foreign purchase. The difference is in the context: what the card did in the last hour, activity at the same merchant across your cards, and how the cardholder usually pays.

What to send

Send the authorization with the card's history and what your systems already know about the card. The examples send 160 to 270 earlier authorizations each, in about 13,000 to 18,000 input tokens.

  • 60 to 120 days of authorizations, including declines, refunds and reversals. $0 or $1 tests minutes before a larger purchase are card testing; the rest shows how, where and when the cardholder pays.
  • Activity at the same merchant across your cards. A burst of declines on sequential numbers from one BIN is a BIN attack.
  • How the card was read. A fallback read on a chip card that has never needed one is a classic counterfeit signal.
  • Card-not-present checks and device data. 3-D Secure authentication, especially after a challenge, is strong evidence of the cardholder. A data-only request still gives you the device, IP address and ship-to.
  • Account changes, devices and compromise alerts. A card in a breach alert makes a matching security code and address worth much less.
  • Usual pattern and recent locations. These separate impossible travel from a cardholder who is simply traveling.
  • Your existing scores and rule results. Grayson weighs them with the rest of the state.

Add your own policy

Whether to decline or step up trades fraud losses against false declines, so put your strategy in the request and Grayson applies it. This one gives cardholders enrolled in two-way text alerts a confirmation text instead of a hard decline on card-not-present authorizations under $1,000.

Your step-up policy adds this to the state of the obvious example:

{
  "authorization_strategy": "Card-not-present authorization strategy (rev. 2026-08). 1) We never hard-decline a card-not-present authorization under $1,000 for suspected fraud when the cardholder is enrolled in two-way text alerts, whatever the fraud scores, rules or evidence. Step up instead: decline this attempt with a response that asks the cardholder to contact us, and text them at the phone on file. If they reply YES within 15 minutes, approve the merchant's retry. If they reply NO or don't reply, block the card and reissue it. 2) Hard-decline and block without a text only when the amount is $1,000 or more, the card is already blocked, or the cardholder has already reported the card lost or stolen."
}
QuestionWithoutWith your step-up policy
fraud_likelihood3.69 of 4, confidence 86%3.70 of 4, confidence 87%
card_tested98% true99% true
actiondecline, confidence 54%step_up, confidence 86%

In the obvious-fraud example, the cardholder is enrolled in two-way text alerts and the keyed $749.99 purchase is under $1,000, so the action moves from decline to step-up, while the fraud likelihood and card testing answers stay the same.

Where to call it

  • In parallel, with a timeout: run it alongside your rules and model, and fall back to your existing decision if the answer isn't back.
  • Where it adds the most: card-not-present, fallback, cross-border and first-time-merchant authorizations, or your rules' borderline cases.
  • At 3-D Secure authentication, if you control the risk decision there: a likely-fraud answer becomes a challenge.

Cost and latency

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious12,661$0.00044$0.44198 ms
Legitimate17,676$0.00062$0.62248 ms
Ambiguous12,871$0.00045$0.45196 ms

You pay only for input tokens, at $0.035 per million, and each request is rounded up to the next millionth of a dollar, so a request with a larger state costs proportionally more; every response reports its size in usage.input_tokens. Latency is the median of 5 calls each through api.finic.ai from US-West, and grows with the number of input tokens. Add your own network time to api.finic.ai.

Evaluate on your own data

Score Grayson on your own past cases before you use it: a CSV with one row per case and a column with the right answer to each question. Every other column is sent as the case.

pipx install https://docs.finic.ai/downloads/grayson_cli-0.4.0-py3-none-any.whl
grayson eval my-cases.csv --questions https://docs.finic.ai/recipes/card-authorization-fraud/questions.json --label fraud_likelihood=<column> --label card_tested=<column> --label action=<column>

Each --label names the column with that question's right answer:

  • fraud_likelihood: a level, such as "Very likely (over 90%)"
  • card_tested: true or false
  • action: approve, step_up, decline

Or run grayson on its own to set up your questions step by step. You get each question's accuracy and a CSV with Grayson's answer next to yours for every case.

Evaluate on your own data

How it works, what you get, and every option.

FAQ

Is Grayson fast enough for authorization?

Call Grayson in parallel with your existing checks so its time overlaps with theirs, set a timeout that fits your authorization budget, and use your existing decision when the answer doesn't arrive in time. If the budget is too tight to screen every authorization, call it where it adds the most, such as card-not-present and fallback authorizations, or at 3-D Secure authentication.

Can it detect card testing across many cards, not just one?

Grayson reads one state per request, so compute merchant-level counts in your stream processing (attempts, distinct card numbers, decline rate and reasons, numbers running in sequence on your BIN) and add them to each authorization's state, as in the examples. You can also send a merchant's recent authorizations on your cards as the state and ask directly whether the merchant is being used for card testing.

Do AVS and CVV2 matches mean the cardholder is making the purchase?

No. Card details stolen through phishing and checkout-page skimmers usually include the billing address and security code, so these checks tell you most when they fail. 3-D Secure authentication with a challenge to the cardholder's phone or banking app is much stronger evidence, which is why the step-up option uses it.

Classify card disputes and detect friendly fraud

Classify unauthorized-transaction claims and choose provisional credit, approval or denial.

Triage dark web credential and card alerts

Match a dark web alert to the customer, judge whether the exposure still works, and choose the response.

Recipes

Every use case, with its questions and cost per decision.

Card fraud

Decisions on card transactions and the claims that follow them: authorizations, disputes and fleet cards. Ready-to-run Grayson recipes with real responses, cost and latency.

Card disputes

Grayson classifies card disputes as friendly fraud, account takeover or stolen card from authentication, logins and past disputes, and recommends a resolution.

On this page

ExamplesCall it from your codeThe problemWhat to sendAdd your own policyWhere to call itCost and latencyEvaluate on your own dataFAQIs Grayson fast enough for authorization?Can it detect card testing across many cards, not just one?Do AVS and CVV2 matches mean the cardholder is making the purchase?Related recipes