Finic
ContactTry the API
Payments and scams

Stop scam payments before they're sent

Grayson screens a customer's outgoing Faster Payment for authorised push payment scams, names the likely scam type and picks release, warn, hold and call, or block, before the money leaves.

Grayson decides whether a customer is being deceived into sending a payment, which type of scam it looks like, whether a scammer is directing the customer as it happens, and whether to release the payment, show a warning written for that scam, hold it while a fraud specialist calls the customer, or block it. It reads what your payment screening already gathers when the customer presses Send, from months of account activity and saved payees to the session's behaviour signals, Confirmation of Payee and payee intelligence, and costs about $0.45 to $0.62 per 1,000 decisions.

  • Decides: Catch authorised push payment scams in the payment flow, and choose release, warn, hold and call, or block.
  • Call it: When a customer presses Send on a payment to a new or risky payee
  • Questions: 2 yes/no, 2 choice
  • Cost: $0.00045 to $0.00062 per decision ($0.45 to $0.62 per 1,000) for these examples' 12,843 to 17,606 input tokens
  • Latency: 210 to 255 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three Faster Payments from a UK bank's mobile app, each sent with 12 months of monthly totals, about 90 days of posted transactions (120 to 210 of them), saved payees, 30 days of app logins, the current session's events and behaviour signals, and the payment with its purpose, the customer's answers and payee intelligence. They are a widowed retiree moving her savings to a "safe account" during a phone call, a first-time buyer paying her house deposit to her solicitor, and a crypto buyer funding a newer, unregistered platform through an account in his own name.

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 block and hold_and_call above their thresholds to your fraud team's queue with the scam type attached. Set a separate threshold on deceived too: in the crypto example action favors release, but a one-in-four chance that a £6,000 payment is a scam is worth a call for many teams.
  • scam_type chooses the warning to show and the script for the call. When deceived is low, ignore it.
  • coached tells you whether a warning can work at all: when it's high, a customer on the phone with a scammer will click through, so prefer a hold over a warning even when the scam type is unclear.

Call it from your code

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

Scam payments pass every authentication check, because the real customer makes them on their own phone. Rules that fire on a new payee, a large amount or savings moved in also fire on house deposits and car purchases, and customers learn to click through the warnings. What separates the two is the combination: a phone call during the session, a "safe account" in someone else's name, a payee account a few days old, against a mortgage offer naming the payee or a payee your own completions team already pays.

What to send

Send what your screening holds when the customer presses Send. The examples send 120 to 210 transactions each, in about 12,800 to 17,600 input tokens.

  • The session, event by event. Savings moved in, a limit raised, a no-match warning overridden and long pauses all within minutes is the shape of a coached payment.
  • Behaviour signals. An incoming call that lasts the whole session, remote access, and payee details typed a few digits at a time point to someone reading them out.
  • Confirmation of Payee and payee intelligence. A no match on an "own account", a payee account opened days ago, or money that leaves it within minutes points to a mule account.
  • Purpose and answers. Answers that contradict the record, such as "my own account" for a name that doesn't match, matter more than the answers themselves.
  • Months of account history and payees. These show what is normal for the customer: their largest payment, how often they add payees, and earlier payments to crypto or investment platforms.
  • What else you hold about the customer. A mortgage application, support needs, a recent contact-detail change or a card decline they didn't make can explain or condemn a payment.

Add your own policy

Banks draw different lines on crypto, large first payments and own-account transfers, so put your policy in the request in your team's words and Grayson applies it. This one refuses any payment it can trace to a crypto platform that isn't on the FCA cryptoasset register, including payments to the customer's own account.

Your crypto platform policy adds this to the state of the ambiguous example:

{
  "crypto_payments_policy": "Payments to cryptoasset platforms (rev. 2026-07). 1) We do not send any payment, including to an account in the customer's own name at an e-money firm or exchange, when we can identify that the money is for a cryptoasset platform that is not on the FCA cryptoasset register. Block the payment and its payee, and tell the customer in the app that we don't send payments to unregistered crypto platforms. This applies whatever the customer's answers or history. 2) Payments to platforms on the FCA cryptoasset register go through normal scam screening. 3) A customer who disagrees can ask a branch to review the decision; the branch can't override rule 1."
}
QuestionWithoutWith your crypto platform policy
deceived25% true20% true
scam_typenone, confidence 41%none, confidence 44%
coached1% trueUnder 1% true
actionrelease, confidence 47%block, confidence 93%

Applied to the ambiguous example: the £6,000 is for Corvane Markets, which isn't on the FCA cryptoasset register, so the action moves from a narrow release to block, while whether he is being deceived and the scam type stay as uncertain as before.

Where to call it

  • After the customer presses Send and before you submit the payment, with a timeout, falling back to your rules if the answer isn't back.
  • Where it adds the most: payments to new payees, payees added in the last few weeks, own-account transfers to other firms, and anything your rules would warn on or hold.
  • Again when you know more, for example after the customer answers a fraud specialist's questions, with the call notes added to the state.

Cost and latency

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious12,843$0.00045$0.45255 ms
Legitimate17,606$0.00062$0.62210 ms
Ambiguous14,123$0.00049$0.49213 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/scam-payment-prevention/questions.json --label deceived=<column> --label scam_type=<column> --label coached=<column> --label action=<column>

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

  • deceived: true or false
  • scam_type: purchase, investment, romance, advance_fee, invoice_mandate, impersonation_police_bank, impersonation_other, none
  • coached: true or false
  • action: release, warn, hold_and_call, block

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

How is this different from fraud typology classification?

This recipe decides while the money is still with you, from what your screening holds when the customer presses Send. Fraud typology classification classifies a claim after the loss, from the customer's statement and the records of what happened, and decides reimbursement.

Does a warning the customer clicked through mean we don't have to repay them?

Rarely. Under the UK's APP scam reimbursement rules, in force since October 2024, a payment firm can refuse to reimburse when the customer was grossly negligent, which is a high bar, and not when the customer was vulnerable and that affected their ability to protect themselves. A customer being coached by a caller will usually click through a generic warning, which is why the coached answer exists and why stopping the payment is usually cheaper than repaying it.

Is it fast enough for the payment flow?

Customers expect a Faster Payment to go in seconds, so call Grayson in parallel with your other checks once the customer presses Send, and use your rules' decision if the answer doesn't arrive in time. Holding a payment while you talk to the customer is a different budget: UK rules let you delay an outgoing payment until the end of the fourth business day after the instruction when you have reasonable grounds to suspect fraud, as long as you tell the customer.

Fraud typology classification

Label a fraud claim with a FraudClassifier class, scam type and contributing factors; decide reimbursement.

Detect money mule accounts

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

Detect business email compromise in vendor payments

Catch payments to a vendor's new bank account after a fake or compromised change request.

Recipes

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

Incoming payments

Decide whether an incoming ACH credit is the proceeds of fraud at the sender, and whether to release, hold or return it, from the account's history, the ACH entry and what happened after it posted.

Onboarding

Applications for deposit accounts, business services and loans. Ready-to-run Grayson recipes with real responses, cost and latency.

On this page

ExamplesCall it from your codeThe problemWhat to sendAdd your own policyWhere to call itCost and latencyEvaluate on your own dataFAQHow is this different from fraud typology classification?Does a warning the customer clicked through mean we don't have to repay them?Is it fast enough for the payment flow?Related recipes