Finic
ContactTry the API
Recipes

Detect account opening fraud and synthetic identities

Grayson approves, steps up or declines a deposit account application, weighing identity-vendor results, credit file, contact, device and velocity data.

Grayson decides whether a deposit account application comes from a legitimate applicant, a stolen identity, a synthetic identity or someone planning first-party fraud, and whether to approve it, require document and selfie verification, or decline it. It reads the results your identity, credit, email, phone and device checks already return, and costs about $0.05 per 1,000 decisions.

  • Decides: Approve, step up or decline a deposit account application at risk of stolen or synthetic identity fraud.
  • Call it: When an online deposit account application is submitted
  • Questions: 1 yes/no, 1 score, 2 choice
  • Cost: $0.000047 per decision, $0.05 per 1,000, for this example's 1,337 input tokens
  • Latency: 183 ms for this example, the median of 5 calls through api.finic.ai from US-West

Example

An online checking application whose name, SSN and date of birth match, but whose two-and-a-half-year-old credit file is built only from authorized-user tradelines on strangers' cards, with an SSN issued long after the stated date of birth and a private mailbox as the home address.

Open in PlaygroundEdit and run this request in the Finic portal.
QuestionGrayson's answer
identity_not_ownYes, P(yes) 91%
fraud_likelihoodVery likely (over 90%), 53%
application_typesynthetic_identity, 90%
decisiondecline, 58%

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.

  • decision routes the application: decline only when decline clears a high bar, and step up when step_up and decline together are high.
  • application_type picks the follow-up: verification for a likely stolen identity, manual review for a likely synthetic one, account limits for likely first-party fraud.
  • fraud_likelihood orders your review queue: add the "Likely" and "Very likely" probabilities and sort on the sum.

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

Most signals of account opening fraud are common among good applicants too: VoIP numbers, private mailboxes, pasted SSNs, authorized-user tradelines. A rule that declines on any one turns away good customers, and one that waits for all of them misses a carefully aged synthetic identity. Each kind of fraud also needs a different response.

What to send

Send the results your vendors already return at application time, with dates:

  • Identity-vendor match results. Whether the name, SSN and date of birth appear together in credit-header records, and since when.
  • SSN issuance. A number issued years after the stated date of birth adds weight to other synthetic signals.
  • How the credit file was built. Authorized-user spots on strangers' cards, not a parent's, are how a synthetic identity buys a score.
  • Email, phone and address. Contact details created this week fit a stolen identity; a private mailbox can serve many identities.
  • Device and velocity. Whether the device, phone, email or address appears on other recent applications under other names.
  • Deposit account history. Prior closures for cause and unpaid overdrafts, the main application-time sign of first-party fraud.

Add your own criteria

Most fraud teams have a written procedure that says which signals justify a decline and which only justify more verification; put it in the request and Grayson applies it. This one doesn't decline on credit-file indicators alone when the identity elements match one another and nothing links the device, phone or email to other applications.

Your step-up standard adds this to the context:

{
  "institution_policy": "Marlow Creek Bank account opening procedure, section 4 (identity decisions): We don't decline an application at submission on credit-file or SSN-issuance indicators alone, because they also describe many real applicants who are new to credit. When the identity bureau matches the name, SSN and date of birth to one another, and the device, phone number and email aren't linked to any other application, send the applicant to document and selfie verification and decide after it. Decline at submission only when the identity elements don't match one another, or when the device, phone number or email is linked to other applications in the last 90 days."
}
QuestionWithoutWith your step-up standard
identity_not_ownYes, P(yes) 91%Yes, P(yes) 75%
fraud_likelihoodVery likely (over 90%), 53%Very likely (over 90%), 41%
application_typesynthetic_identity, 90%synthetic_identity, 80%
decisiondecline, 58%step_up, 90%

Both conditions hold here, so the decision should move from decline to document and selfie verification, while application_type stays the same because the credit file still looks synthetic.

Where to call it

  • After the identity, credit, email, phone and device checks return, and before the account number is issued or the account is funded.
  • When no option is clearly ahead, step up rather than decline, then call again with the verification result added.
  • Again at the first large check deposit or outbound transfer, when first-party intent starts to show.

Cost and latency

This example is 1,337 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 183 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/account-opening-fraud/questions.json --label identity_not_own=<column> --label fraud_likelihood=<column> --label application_type=<column> --label decision=<column>

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

  • identity_not_own: true or false
  • fraud_likelihood: a level, such as "Very likely (over 90%)"
  • application_type: legitimate, stolen_identity, synthetic_identity, first_party
  • decision: approve, step_up, decline

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 synthetic identity from a real applicant who is new to credit?

Usually, if you send the details that separate them. A real applicant's authorized-user tradelines usually come from a family member who shares their surname or address, and their email and phone predate the credit file; a synthetic identity's come from strangers, and its contact details tend to appear at the same time as the file. Starter case account-opening-fraud-2 is that benign twin.

Does document and selfie verification stop synthetic identities?

Less well than it stops stolen identities. A selfie check confirms that the person holding the phone matches the photo on the document, which a fraudster using a stolen identity can't do, but a synthetic identity's license is fabricated with the fraudster's own photo. Checks against authoritative records do more: SSA's eCBSV for the SSN and, where available, verification of the license against the issuing state's records.

Can it catch first-party fraud at application time?

Only partly. A first-party fraudster applies with their own identity, so the application-time signals are mostly deposit account history and a burst of recent inquiries at other institutions. Most first-party fraud shows after opening, so call Grayson again at the first large check deposit or outbound transfer and ask about the activity itself.

Detect money mule accounts

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

Detect insider threats in employee account access

Decide whether an employee's account access is work, snooping or insider fraud, and close, refer or suspend.

Recipes

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

Recipes

Ready-to-run Grayson requests for fraud, payments, disputes, onboarding and AML decisions, with real responses and the cost and latency of each decision.

Business email compromise

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.

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 synthetic identity from a real applicant who is new to credit?Does document and selfie verification stop synthetic identities?Can it catch first-party fraud at application time?Related recipes