Finic
ContactTry the API
Merchant and platform risk

Review merchant risk alerts on your payments platform

Grayson reviews a flagged merchant's processing, payouts and onboarding record, separates real growth from bust-out fraud, transaction laundering and stolen-card attacks, and picks the action, from clearing the alert to holding payouts or closing the account.

When your monitoring flags one of your merchants, Grayson reads the merchant's onboarding record, processing history, payouts and dashboard activity, and returns what best explains the activity (real business, a business in trouble, stolen cards at its checkout, a bust-out, transaction laundering or an account takeover), whether it still matches the business the merchant declared, how likely you are to be left with the losses, and what to do: clear the alert, ask for documents, hold back payouts, suspend or terminate. It costs about $0.55 to $0.61 per 1,000 decisions.

  • Decides: Whether a flagged merchant's activity is real business or fraud, how likely a loss is, and whether to hold payouts
  • Call it: When monitoring flags one of your merchants
  • Questions: 2 choice, 1 yes/no, 1 score
  • Cost: $0.00055 to $0.00061 per decision ($0.55 to $0.61 per 1,000) for these examples' 15,693 to 17,559 input tokens
  • Latency: 215 to 300 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three alerts at a payment facilitator, each sent with the merchant's onboarding record, 12 months of monthly and 60 days of daily processing, every sale of $250 or more and refund of $100 or more in the last 30 days, disputes and issuer fraud reports, payouts, dashboard logins and what the merchant has told the risk team. They are an HVAC contractor keying out-of-state cards at night after changing its payout account, a pumpkin farm's October peak with new online tickets, and a phone repair shop selling refurbished phones to distant buyers by payment link.

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. Send terminate and suspend above their thresholds straight to holding funds, and reserve_or_delay_payouts to the analyst who sets the reserve; when the top two options are close, take the more cautious one until an analyst has looked.
  • loss_likelihood: threshold the sum of "Likely" and "Very likely" to decide which alerts get a payout hold before an analyst reviews them, and weight it by the money still to be paid out.
  • risk_type routes the case: stolen_cards_at_checkout and account_takeover mean the merchant is a victim, so help it lock down its checkout or dashboard instead of treating it as the suspect; transaction_laundering and bust_out go to your financial crimes team.

Call it from your code

Save an example as request.json, such as legitimate.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

Monitoring rules fire on volume spikes, new sales channels, refund rates and payout account changes, and in a seasonal or growing business all of those are normal, so most alerts are cleared by hand. The few that matter look like the rest until you read the whole record: who keyed which cards and when, whether the payout account change came from the owner's usual device, whether the business had the same peak last year, and what the merchant's explanation leaves out. By the time chargebacks arrive, the payouts are gone.

What to send

Send the merchant as your risk analyst would review it, with the alert that raised it. The examples are about 15,700 to 17,600 input tokens each.

  • The onboarding record: declared business and category code, expected volume and ticket size, how customers pay, and the owners' identity checks. The question is always whether today's activity fits what was declared.
  • Processing history and card mix: monthly totals for a year (to show seasonality) and daily totals for two months, with entry mode, card types and issuing countries.
  • The sales themselves: larger sales and refunds with entry mode, address and security code results, billing ZIP, ship-to and the customer's IP location. Cards keyed late at night from many states tell a different story from invoices paid by local schools.
  • Disputes and issuer fraud reports, with reason codes. Fraud reports arrive days before chargebacks and are the earliest outside evidence.
  • Payout account changes and dashboard activity: who made the change, from which device, and how the new account was verified.
  • Links to other merchants: devices, bank accounts, cards and ship-to addresses shared with merchants you have terminated or are reviewing.
  • Website checks, earlier reviews and what the merchant said, word for word where you can.

Add your own policy

Some platforms only hold funds when they suspect fraud, while others always cover exposure they can measure, such as tickets sold for dates that haven't happened yet, so put your policy in the state and Grayson applies it.

Your future-delivery reserve policy adds this to the state of the legitimate example:

{
  "risk_policy": "Merchant risk policy, section 6: future delivery (rev. 2026-07). If a merchant closes or cancels, every sale it took for a date that hasn't happened yet can come back to us as a chargeback. We never clear an alert on a merchant whose undelivered sales for future dates are over $25,000 without a reserve, however legitimate the merchant is. Keep processing, hold back a reserve from its payouts equal to those undelivered sales, release it as the dates pass, and tell the merchant it is our standard future-delivery reserve, not a suspicion of fraud."
}
QuestionWithoutWith your future-delivery reserve policy
risk_typelegitimate_business, confidence 97%legitimate_business, confidence 85%
matches_declared_business99% true95% true
loss_likelihood0.05 of 4, confidence 95%0.44 of 4, confidence 67%
actionno_action, confidence 97%reserve_or_delay_payouts, confidence 94%

Applied to the likely-legitimate example: the farm holds about $46,000 of online tickets and invoiced group visits for dates after today, over the policy's $25,000 trigger, so the action moves from clearing the alert to holding a reserve, while the farm is still judged a legitimate business whose sales match what it declared.

Where to call it

  • On every merchant monitoring alert, before it reaches an analyst, so the riskiest are at the top of the queue and the clear seasonal ones are closed.
  • Before a payout leaves, for merchants with an open alert or a payout account changed in the last 30 days.
  • When outside evidence arrives: a new issuer fraud report, a chargeback, or a website change found by your monitoring vendor.

Cost and latency

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious17,559$0.00061$0.61300 ms
Legitimate15,693$0.00055$0.55286 ms
Ambiguous16,161$0.00057$0.57215 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/merchant-risk-review/questions.json --label risk_type=<column> --label matches_declared_business=<column> --label loss_likelihood=<column> --label action=<column>

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

  • risk_type: legitimate_business, business_trouble, stolen_cards_at_checkout, bust_out, transaction_laundering, account_takeover
  • matches_declared_business: true or false
  • loss_likelihood: a level, such as "Very likely (over 90%)"
  • action: no_action, request_documents, reserve_or_delay_payouts, suspend, terminate

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

Can Grayson tell a bust-out from a merchant whose customers are using stolen cards?

It can when the state carries the evidence that separates them. Sales the merchant keys in itself, a payout account changed just before the spike, instant payouts and links to terminated merchants point to the merchant; buyers who pay through the merchant's own checkout or links from VPNs and ship to forwarding addresses, at a merchant with a long clean history, point to a victim. Send who entered each sale and from which device, not just the totals.

Does it detect transaction laundering?

It reads what your systems give it: sales that don't fit the declared business (ticket sizes, card countries, hours, descriptors), referring websites, and your website monitoring results. If you run test purchases or crawl for undisclosed websites, add those results to the state; they are often the deciding evidence.

Should Grayson's action hold payouts automatically?

Start by using it to order your queue and to hold payouts only above a high threshold, with an analyst confirming within hours. Check your merchant agreement and your sponsor bank's rules for when you can hold funds and what notice you owe the merchant, and compare Grayson's answers with your analysts' decisions on past alerts before you automate more.

Review business onboarding (KYB) applications

Approve, approve with limits, request documents or decline a business applying for card processing or another business product.

Screen card authorizations for fraud in real time

Score card authorizations for fraud and choose approve, step up or decline, next to your existing rules.

Detect money mule accounts

Whether an account is passing other people's money through, whether the holder knows, and what to do

Recipes

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

Merchant and platform risk

The merchants on your payments platform, and abuse of your rewards and promotions. Ready-to-run Grayson recipes with real responses, cost and latency.

Promotion abuse

Grayson decides whether a sign-up bonus or referral reward is being claimed through multiple accounts, a referral ring or staged deposits, and whether to pay it, hold it, deny it or close the account.

On this page

ExamplesCall it from your codeThe problemWhat to sendAdd your own policyWhere to call itCost and latencyEvaluate on your own dataFAQCan Grayson tell a bust-out from a merchant whose customers are using stolen cards?Does it detect transaction laundering?Should Grayson's action hold payouts automatically?Related recipes