Finic
ContactTry the API
Payments and scams

Detect business email compromise in vendor payments

Decide whether a change to a vendor's bank details is business email compromise, and whether to release, hold or block the payment, from AP, email and login records.

Grayson decides whether a change to a vendor's bank details is business email compromise (BEC), whether the new account has really been confirmed with the vendor, and whether the next payment should be released, held for a call-back or blocked. It reads the vendor's payment and email history, the change request with its headers, each verification step and the sessions of the users involved, and costs about $0.57 to $0.60 per 1,000 decisions.

  • Decides: Catch payments to a vendor's new bank account after a fake or compromised change request.
  • Call it: Before a payment goes to a vendor's recently changed bank details
  • Questions: 1 score, 1 yes/no, 1 choice
  • Cost: $0.00057 to $0.00060 per decision ($0.57 to $0.60 per 1,000) for these examples' 16,229 to 17,259 input tokens
  • Latency: 221 to 284 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three payments to vendor bank details changed in the last month, each sent with the vendor record, at least a year of invoices and payments, months of the vendor's email, the customer's other payables and six weeks of sign-ins: a lookalike domain that hijacks a veterinary supplier's invoice thread, a sheet-metal supplier's real move to a new local bank, and a produce distributor's request from its own mailbox that only email has confirmed.

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.

  • bec_likelihood: add the "Likely" and "Very likely" probabilities rather than reading the top level, since a mixed case splits between the two ends; above your threshold, the payment shouldn't go out on the customer's checklist alone.
  • verified_out_of_band: a low probability means the change isn't really confirmed, whatever the attestation says, so send the payment to a call-back queue.
  • action: when release isn't clearly the most likely option, hold rather than release; a held payment can still go out on the due date.

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

Vendors do change banks, the invoice is real, the new account passes validation and the micro-deposits confirm, so every step of a BEC payment can look normal. A rule that holds every bank change flags changes that are almost all legitimate, and one that trusts a completed checklist misses a call-back placed to the number in the fraudulent email.

What to send

Send the vendor record and its change log, the invoices, payments and email you hold for the vendor, the change request as it arrived (with its headers and attachments), each verification step, the account validation result, what other customers show for the same vendor, and the sessions of the users involved:

  • How the change was requested. A lookalike domain registered days earlier is close to conclusive; the vendor's real domain proves little.
  • Timing and urgency. A change shortly before a large invoice is due, with pressure to update, fits the pattern.
  • The new account. An owner name no-match is a strong signal; an account that is merely valid tells you little.
  • How it was verified. A call-back counts only to a number on file before the request.
  • The vendor's history. A first-ever bank change on a long relationship deserves more care.
  • The users' sessions. A new device, a new country or repeated MFA prompts point to a taken-over login, not a fooled clerk.

Add your own policy

Teams differ on what a failed check means: some call the vendor after a name mismatch, while others treat an emailed change with a mismatch as fraud and cancel the payment outright. This policy takes the stricter line and spells out what counts as verification.

Your vendor bank-change policy adds this to the state of the ambiguous example:

{
  "platform_policy": "AP-7, vendor bank-detail changes. A change counts as verified only after a call to a phone number that was on file before the request arrived; a number, name or link supplied in the request never counts, and neither do micro-deposits. If a change was requested by email and the account validation owner name check returns anything other than a full match, treat it as suspected business email compromise and do not hold the payment for a call-back: cancel the payment, restore the vendor's previous verified bank details, lock vendor edits for the customer, and phone the customer's administrator at the number on file. The customer must re-verify the vendor and submit a new payment."
}
QuestionWithoutWith your vendor bank-change policy
bec_likelihood1.50 of 4, confidence 33% (Very unlikely 46%, Unlikely 13%, Uncertain 7%, Likely 12%, Very likely 22%)2.48 of 4, confidence 40% (Very unlikely 28%, Unlikely 8%, Uncertain 5%, Likely 8%, Very likely 52%)
verified_out_of_band1% trueUnder 1% true
actionhold_and_verify, confidence 47%block_and_alert, confidence 83%

In the ambiguous example, the produce distributor asked for the change by email and the owner name check returned a partial match, so under this policy the payment should be cancelled and the old bank details restored rather than held for a call-back.

Where to call it

  • When a vendor's bank details change, before the change takes effect, to decide how much verification to require.
  • When a payment to recently changed details is approved, before it is sent.
  • When the answer is uncertain, hold the payment and call the vendor at the number on file.

Cost and latency

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious17,259$0.00060$0.60221 ms
Legitimate16,229$0.00057$0.57256 ms
Ambiguous16,988$0.00060$0.59284 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/business-email-compromise/questions.json --label bec_likelihood=<column> --label verified_out_of_band=<column> --label action=<column>

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

  • bec_likelihood: a level, such as "Very likely (over 90%)"
  • verified_out_of_band: true or false
  • action: release, hold_and_verify, block_and_alert

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

Do micro-deposits or an account-validation check prove the change is legitimate?

No. A confirmed micro-deposit proves only that whoever supplied the bank details can see the account, which a fraudster can do for an account they opened. An owner name check is stronger, but fraudsters open accounts under names close to the vendor's, so send these results as evidence together with how the vendor was actually contacted.

What if the request came from the vendor's real email address?

Then domain and email authentication checks pass, because a compromised vendor mailbox sends from the real domain, often inside a genuine invoice thread. The other signals carry the decision: the new bank, the owner name check, a phone number that appears only in the request, urgency before a large payment, and whether other customers of the vendor received the same change. Grayson weighs these together, so you don't need a separate rule for each.

Should I score the bank-detail change or the payment?

Both. At change time, ask whether the change is fraudulent and whether it has been verified, to decide what verification to require; at payment time, add the invoice, the amount and the approvers' sessions and ask the action question too, since money is about to move. Keep the wording of shared questions identical so thresholds carry over.

Detect fraudulent incoming ACH credits and transfers

Release, hold or return an incoming credit that may be proceeds of BEC, account takeover or payroll diversion.

Fraud typology classification

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

Recipes

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

Payments and scams

Money going out and coming in: scam payments, vendor bank-detail fraud, incoming credits and check deposits. Ready-to-run Grayson recipes with real responses, cost and latency.

Check deposits

Grayson decides whether a deposited check is counterfeit, altered, stolen or a duplicate, and whether to release funds, place an exception hold or reject it.

On this page

ExamplesCall it from your codeThe problemWhat to sendAdd your own policyWhere to call itCost and latencyEvaluate on your own dataFAQDo micro-deposits or an account-validation check prove the change is legitimate?What if the request came from the vendor's real email address?Should I score the bank-detail change or the payment?Related recipes