Finic
ContactTry the API
Onboarding

Detect account opening fraud and synthetic identities

Grayson approves, steps up or declines a deposit account application, weighing identity-vendor results, the credit file, consortium, device and session data, and the funding account's history.

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, consortium, email, phone, device and funding checks already return, and costs about $0.39 to $0.41 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.00039 to $0.00041 per decision ($0.39 to $0.41 per 1,000) for these examples' 11,044 to 11,657 input tokens
  • Latency: 194 to 203 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three online checking applications, each with everything our checks return at submission: the identity bureau's match, a credit file with 24 months of balances, consortium and device results, the form session log and 90 days of the linked funding account. One is an aged synthetic identity in the middle of a bust-out, one a homeowner whose rule hits all have explanations, and one a five-year-old identity that could be a real person who got an SSN as an adult or a carefully aged synthetic one.

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.

  • decision routes the application: decline only when decline clears a high bar, and step up when step_up and decline together are high, or when application_type gives a fraud type a real share, as in the ambiguous example.
  • 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 an example as request.json, such as fraud.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 everything your checks return at submission, with dates. The examples send about 11,000 tokens each:

  • 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; monthly balances show a bust-out starting.
  • Consortium results. Applications with the same SSN, phone, email or address at other institutions, with their outcomes and any confirmed fraud reports.
  • Email, phone and address. Contact details created this week fit a stolen identity; a private mailbox can serve many identities.
  • Device, session and velocity. Whether the device, phone, email or address appears on other recent applications under other names, and whether the applicant typed their own details or pasted them from another window.
  • Deposit account history. Prior closures for cause and unpaid overdrafts, the main application-time sign of first-party fraud.
  • The funding account. The owner-name match and its recent transactions: a real person's account shows pay, rent and groceries, and a synthetic identity's shows money passing through.

Add your own policy

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 declines at submission only when the identity elements don't match one another or the device, phone or email has been used under another name, and sends every other application with fraud indicators to document and selfie verification.

Your step-up standard adds this to the state of the obvious example:

{
  "institution_policy": "Our account opening procedure, section 4 (identity decisions): We decline at submission only when the identity elements don't match one another (the identity bureau can't place the name, SSN and date of birth together), or when the device, phone number or email has been used on an application under a different name or SSN in the last 90 days. We don't decline at submission on credit-file, SSN-issuance, address, funding or session-behavior indicators, however strong, because document verification with a selfie match and an SSA eCBSV check settle most of these cases, and the same indicators describe many real applicants. We don't approve an application with those indicators at submission either: it goes to document and selfie verification, and we decide after it."
}
QuestionWithoutWith your step-up standard
identity_not_own89% true88% true
fraud_likelihood3.79 of 4, confidence 86%3.77 of 4, confidence 83%
application_typesynthetic_identity, confidence 77%synthetic_identity, confidence 78%
decisiondecline, confidence 94%step_up, confidence 85%

In the obvious-fraud example the identity elements match one another, and what ties it to other applicants is its mailbox address, not its device, phone or email. So the decision moves from decline to document and selfie verification, while application_type stays synthetic_identity 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

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious11,044$0.00039$0.39203 ms
Legitimate11,657$0.00041$0.41194 ms
Ambiguous11,449$0.00040$0.40198 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/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.

Onboarding

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

Business onboarding

Grayson reviews a small business's application for card processing, checks that the business is real and sells what it says, scores shell, impersonation and bust-out risk, and picks approve, approve with limits, request documents or decline.

On this page

ExamplesCall it from your codeThe problemWhat to sendAdd your own policyWhere 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