Finic
ContactTry the API
Recipes

Detect money mule accounts

Decide whether an account is a money mule, whether the holder is complicit or was deceived by a job or romance scam, and whether to restrict or close it.

Grayson decides whether an account is being used as a money mule, whether the holder is complicit or was deceived by a fake job or romance scam, and whether to keep monitoring, restrict the account and contact the customer, or close it and refer it for a suspicious activity report (SAR). It reads data your institution already holds, from the customer profile and transactions to devices, linked accounts and the customer's own messages, and costs about $0.08 per 1,000 decisions.

  • Decides: Whether an account is passing other people's money through, whether the holder knows, and what to do
  • Call it: When monitoring flags pass-through activity on an account
  • Questions: 1 yes/no, 2 choice, 1 score
  • Cost: $0.000083 per decision, $0.08 per 1,000, for this example's 2,349 input tokens
  • Latency: 208 ms for this example, the median of 5 calls through api.finic.ai from US-West

Example

A checking account dormant for 14 months has taken in $22,125 from seven people and two businesses in three weeks, with about 90% of each earlier payment leaving within two days; the customer has written that they "process payments" for an employer, and a sender's bank has reported one credit as rental-scam proceeds.

Open in PlaygroundEdit and run this request in the Finic portal.
QuestionGrayson's answer
is_muleYes, P(yes) 59%
holder_roleunwitting, 65%
fraud_proceedsLikely (60-90%), 41%
actionclose_and_refer, 77%

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.

  • is_mule: below a threshold chosen on your past alerts, close the alert as a false positive; above it, act on the role and action answers.
  • holder_role: give a close call between complicit and unwitting to an investigator who can call the customer, and send not_in_control to your takeover team.
  • action: send close_and_refer and restrict above their thresholds to your exit and restriction workflows, and everything below them to an analyst queue.

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.json

The problem

A mule account rarely breaks a rule with any single transaction. What gives it away is the shape over days: many unrelated senders, money that leaves within hours, a balance that keeps returning to near zero. Rules that flag that shape also flag roommates splitting rent and small side businesses, and they can't read a customer's message about their new job.

What to send

Send the account as an analyst would review it, with the alert that raised it:

  • Who sends money in. Many new, unrelated senders with memos like "deposit" or "rent" suggest scam proceeds.
  • How fast and where it leaves. A roughly fixed share left behind after each fast exit can be the mule's cut.
  • Account history against the stated profile. A dormant account suddenly taking in many times its expected volume is a common sign of recruitment.
  • Amounts against limits. Transfers just under a hold threshold, or cash under the $10,000 CTR threshold, show amounts being shaped.
  • Shared devices and accounts. Sharing with other customers points to an organized network, not an isolated, deceived customer.
  • What the customer has said, word for word. A remote job "processing payments" often separates an unwitting mule from a complicit one.

Add your own criteria

Some institutions exit every account that has passed on fraud proceeds, while others keep a deceived long-time customer, stop the money and explain the scam, so put your procedure in the context in your team's words. This one keeps deceived long-time customers after a first occurrence, restricting the account and calling the customer instead of closing it.

Your deceived-customer procedure adds this to the context:

{
  "institution_policy": "Money mule procedure, section 4 (revised 2026-06): For a customer of more than three years whose own messages show they believe the payments are legitimate work or help for someone they trust, and who shares no device, phone number or external account with other customers: restrict outbound transfers, return any reported funds still in the account to the sending institution, and call the customer to explain the scam. Do not close the account on a first occurrence, even when a sending institution has reported a credit as fraud. Close it and refer it to the BSA/AML team only if the activity continues after that call, or if the evidence shows the customer knew the money was stolen. Whether to file a SAR on the activity is decided by the BSA/AML team in every case."
}
QuestionWithoutWith your deceived-customer procedure
is_muleYes, P(yes) 59%Yes, P(yes) 80%
holder_roleunwitting, 65%unwitting, 90%
fraud_proceedsLikely (60-90%), 41%Likely (60-90%), 43%
actionclose_and_refer, 77%restrict, 95%

This customer has banked here since 2018, wrote that they process payments for an employer and shares no device or account with other customers, so the action should move from closing the account to restricting it and calling the customer, while their role stays the same.

Where to call it

  • On each monitoring alert, before it reaches an analyst, and again when another institution reports a credit.
  • Before money leaves an alerted account, in the payment path for P2P payments, external transfers and wires.
  • When the answer is uncertain, send it to an analyst; whoever contacts the customer must not say whether a SAR has been or will be filed.

Cost and latency

This example is 2,349 input tokens, so a decision costs $0.000083: $0.08 per 1,000 decisions, or $83.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 208 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/money-mule-detection/questions.json --label is_mule=<column> --label holder_role=<column> --label fraud_proceeds=<column> --label action=<column>

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

  • is_mule: true or false
  • holder_role: complicit, unwitting, not_in_control, no_mule_activity
  • fraud_proceeds: a level, such as "Very likely (over 90%)"
  • action: monitor, restrict, close_and_refer

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 complicit mule from one recruited through a job scam?

It can when the evidence is in the context. Long tenure, the customer's usual device, transfers to an account in their own name and a message about a new job point to an unwitting mule; a new account, devices shared with other customers, explanations that change and cash kept under reporting thresholds point to a complicit one. If your team also uses the FBI's middle category, witting (a customer who ignores obvious red flags), add it as an option with that definition.

Do we still file a SAR if the customer was deceived?

Often, yes. The obligation to file depends on what the institution knows or suspects about the transactions, not on whether the customer meant to launder money, so an unwitting mule's activity can still need a SAR. What usually differs is how you treat the customer, and the filing decision stays with your BSA officer.

What if we don't have device data or customer messages?

Send what you have: credits, debits, tenure and the stated profile are usually enough to answer is_mule. Without messages or device data, expect more of holder_role's probability to sit between complicit and unwitting, and route those cases to someone who can call the customer.

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.

Detect account opening fraud and synthetic identities

Approve, step up or decline a deposit account application at risk of stolen or synthetic identity fraud.

Recipes

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

Insider threats

Grayson triages insider risk alerts: whether an employee opened customer accounts without a business reason, why, and whether to close, refer or suspend.

Context

What to put in the context, the formats Grayson accepts, and how the context counts toward the token limit.

On this page

ExampleCall it from your codeThe problemWhat to sendAdd your own criteriaWhere to call itCost and latencyEvaluate on your own dataFAQCan Grayson tell a complicit mule from one recruited through a job scam?Do we still file a SAR if the customer was deceived?What if we don't have device data or customer messages?Related recipes