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 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 history, the change request, each verification step and the sessions of the users involved, and costs about $0.05 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.000047 per decision, $0.05 per 1,000, for this example's 1,319 input tokens
- Latency: 184 ms for this example, the median of 5 calls through api.finic.ai from US-West
Example
A veterinary group changed a long-standing supplier's bank details after an email from the supplier's real address, confirmed them by calling the number given in that email, and has just approved a $46,850 payment to the new account.
| Question | Grayson's answer |
|---|---|
bec_likelihood | Likely (60-90%), 25% |
verified_out_of_band | No, P(yes) under 1% |
action | hold_and_verify, 81% |
Each percentage is Grayson's probability for the answer shown; for a yes/no question it's the probability of yes. A multiple-choice answer lists the options at 50% or more.
{
"model": "grayson-1",
"context": {
"review": {
"as_of": "2026-10-08T13:06:00Z",
"trigger": "Payment approved to vendor bank details changed in the last 30 days"
},
"customer": {
"name": "Alderwick Veterinary Partners",
"business": "Three veterinary clinics",
"customer_since": "2023-02-14",
"payment_controls": "Dual approval over $10,000. A user who changes a vendor's bank details must attest that they called the vendor to confirm.",
"users": [
{
"name": "Ben Carter",
"role": "AP specialist; edits vendors and creates payments",
"usual_access": "Windows laptop on the Denver, CO office network"
},
{
"name": "Rachel Moss",
"role": "Controller; approves payments over $10,000",
"usual_access": "MacBook on the Denver, CO office or home network"
}
]
},
"vendor": {
"name": "Bellhaven Veterinary Supply Co.",
"vendor_since": "2023-03-01",
"payments_to_date": 31,
"typical_payments": "Monthly orders of $9,800 to $22,400; larger quarterly stock orders",
"largest_prior_payment_usd": 41200,
"contact_on_file": {
"email": "billing@bellhavenvetsupply.example.com",
"phone": "+1-303-555-0147",
"on_file_since": "2023-03-01"
},
"bank_before_change": {
"bank": "First Wolden Bank",
"account": "Business checking x4410",
"verified": "2023-03-02, by call-back to the phone on file",
"payments_received": 31
},
"earlier_bank_changes": 0,
"other_platform_customers_paying_vendor": "6; all still pay First Wolden Bank x4410 and none has submitted a bank change for this vendor"
},
"invoice": {
"number": "INV-20931",
"received": "2026-09-30T15:05:00Z",
"from": "billing@bellhavenvetsupply.example.com",
"description": "Quarterly stock order",
"amount_usd": 46850,
"due": "2026-10-09"
},
"bank_change_request": {
"received": "2026-10-02T16:48:00Z",
"channel": "Email to the customer's AP inbox, in the INV-20931 thread; uploaded to the platform by Ben Carter",
"from": "billing@bellhavenvetsupply.example.com",
"reply_to": "billing@bellhavenvetsupply.example.com",
"email_authentication": "SPF and DKIM pass for bellhavenvetsupply.example.com",
"text": "Hi Ben, due to an internal audit we have moved our banking. Please update our remittance details using the attached letter before you pay INV-20931. Our First Wolden account closes October 9, so payments sent there after that will be returned. For questions call our accounts team directly at +1-720-555-0189. Thank you, Bellhaven Billing",
"attachment": "PDF letter on Bellhaven letterhead, unsigned",
"new_bank": {
"bank": "Quarrystone Commerce Bank",
"account": "Checking x7731"
}
},
"verification_and_changes": [
{
"ts": "2026-10-02T17:20:00Z",
"type": "phone_call",
"by": "Ben Carter",
"number_called": "+1-720-555-0189",
"note": "Spoke with Karen in accounts, who confirmed the new account details"
},
{
"ts": "2026-10-03T15:12:00Z",
"type": "vendor_bank_details_changed",
"by": "Ben Carter",
"access": "Usual Windows laptop, Denver office network",
"attestation": "Called the vendor to confirm"
},
{
"ts": "2026-10-03T15:13:00Z",
"type": "account_validation",
"result": "Account open and able to receive ACH credits. Owner name check: no match for Bellhaven Veterinary Supply Co."
},
{
"ts": "2026-10-05T14:30:00Z",
"type": "micro_deposits",
"result": "Two micro-deposits to x7731 confirmed through a link emailed to billing@bellhavenvetsupply.example.com"
}
],
"payment_under_review": {
"invoice": "INV-20931",
"amount_usd": 46850,
"rail": "Same-day ACH",
"destination": "Quarrystone Commerce Bank checking x7731",
"created": {
"ts": "2026-10-07T21:40:00Z",
"by": "Ben Carter",
"access": "Usual Windows laptop, Denver office network"
},
"approved": {
"ts": "2026-10-08T13:05:00Z",
"by": "Rachel Moss",
"access": "Usual MacBook, hotel network in Chicago, IL (first seen)"
}
}
},
"questions": {
"bec_likelihood": {
"type": "score",
"instructions": "How likely is it that the change to the vendor's bank details is fraudulent, that is, requested by someone impersonating the vendor or made through a compromised email account or login, rather than requested by the vendor?",
"levels": [
"Very unlikely (under 10%)",
"Unlikely (10-40%)",
"Uncertain (40-60%)",
"Likely (60-90%)",
"Very likely (over 90%)"
]
},
"verified_out_of_band": {
"type": "noul",
"instructions": "Has the vendor confirmed the new bank details through a channel the requester could not control, such as a call to a phone number that was on file before the change was requested?"
},
"action": {
"type": "choice",
"instructions": "What should happen to the vendor payment under review?",
"options": {
"release": "Release the payment to the new bank account",
"hold_and_verify": "Hold the payment until the vendor confirms the new bank details on a call to a phone number that was on file before the change",
"block_and_alert": "Cancel the payment, restore the vendor's previous verified bank details and alert the customer to suspected business email compromise"
}
}
}
}Probabilities are shortened to four decimals here; responses carry full precision.
{
"id": "dec_bed3658c2ec24bb59e6275ba5c187b39",
"model": "grayson-1",
"answers": {
"bec_likelihood": {
"type": "score",
"value": 2.08,
"level": "Likely (60-90%)",
"probabilities": [
0.2249,
0.1751,
0.1204,
0.2548,
0.2249
]
},
"verified_out_of_band": {
"type": "noul",
"value": false,
"probability": 0.0022
},
"action": {
"type": "choice",
"value": "hold_and_verify",
"probabilities": {
"release": 0.008,
"hold_and_verify": 0.8111,
"block_and_alert": 0.181
}
}
},
"usage": {
"input_tokens": 1319
}
}bec_likelihood: add the "Likely" and "Very likely" probabilities; 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: whenreleaseisn'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 request.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.jsonThe 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, the change request as it arrived, each verification step 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 criteria
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 context:
{
"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."
}| Question | Without | With your vendor bank-change policy |
|---|---|---|
bec_likelihood | Likely (60-90%), 25% | Very likely (over 90%), 85% |
verified_out_of_band | No, P(yes) under 1% | No, P(yes) 1% |
action | hold_and_verify, 81% | block_and_alert, 99% |
The change was requested by email and the owner name check returned no 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
This example is 1,319 input tokens, so a decision costs $0.000047: $0.05 per 1,000 decisions, or $47.00 per million. You pay only for input tokens, at $0.035 per million, and each request is rounded up to the next millionth of a dollar. A larger context costs proportionally more; every response reports its size in usage.input_tokens.
Grayson answered this example in 184 ms, the median of 5 calls through api.finic.ai from US-West. Latency 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.2.2-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:trueorfalseaction: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.
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.
Related recipes
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.
Account opening fraud
Grayson approves, steps up or declines a deposit account application, weighing identity-vendor results, credit file, contact, device and velocity data.
Card authorizations
Grayson screens card authorizations for card testing, fallback and card-not-present fraud from recent card activity, and picks approve, step up or decline.