Finic
ContactTry the API
Onboarding

Screen loan applications for fraud before the credit decision

Grayson screens personal loan, credit card and small-business loan applications for stolen identities, inflated income, edited pay stubs and other people's bank accounts, and picks proceed, verify income, verify identity or decline.

Grayson screens a loan application for fraud and misrepresentation before your credit decision, and returns how likely it is to be fraudulent, which problems the evidence shows (an inflated income, an employer nobody can confirm, an edited pay stub, a stolen or synthetic identity, loan stacking, a bank account that isn't the applicant's), whether the connected bank account supports the stated income, and whether to proceed, verify income, verify identity or decline. This is the fraud screen only: whether the applicant can repay a loan made on true facts is still your credit decision. It costs about $0.45 to $0.59 per 1,000 decisions.

  • Decides: Screen a loan application for fraud and misrepresentation, and choose proceed, verify income, verify identity or decline.
  • Call it: When a loan or card application is complete, before the credit decision
  • Questions: 1 score, 1 multiple choice, 1 yes/no, 1 choice
  • Cost: $0.00045 to $0.00059 per decision ($0.45 to $0.59 per 1,000) for these examples' 12,962 to 16,952 input tokens
  • Latency: 236 to 302 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three online personal loan applications, each sent with everything our checks return before the credit decision: the identity match, a credit file with 24 months of history, the employment database and employer checks, the analysis of each uploaded pay stub, 90 days of the connected checking account (about 110 to 190 transactions), device and session data, and velocity at our bank and in a lending consortium. They are a homeowner's stolen identity paid into a stranger's account, a nurse whose second job the employment database can't see, and a laid-off technician's new job at a small company that pays him by Zelle.

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.

  • action routes the application: send decline above a high bar to your fraud decline flow, verify_income and verify_identity to those queues, and everything else to the credit decision. When no option is clearly ahead, verify rather than decline.
  • problems tells the reviewer what to check and gives you the reason to record: an edited pay stub or a mismatched bank account calls for different follow-up than an employer nobody has confirmed yet.
  • 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 legitimate.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

Each rule on its own fires on good applicants all the time: a stated income above the employment database, a new phone, a recent move, a cluster of inquiries. The applications that are really fraudulent tend to pass the identity match, because the name, SSN and address are real. What gives them away is how the pieces fit: whether the deposits come from the stated employer, whose name is on the bank account, when and how the pay stubs were made.

What to send

Send the application with everything your checks return before the credit decision. The examples send about 13,000 to 17,000 input tokens each.

  • The application as submitted. Stated income by source, employer and employer phone, loan amount, purpose and where the funds go.
  • The identity match, and whether the phone and email belong to the identity. A stolen identity passes the name, SSN and address match but brings new contact details.
  • The credit file and its alerts. Under the Fair Credit Reporting Act, a fraud alert on the file means you must take reasonable steps to verify identity before extending credit, at the consumer's phone number if the alert gives one. Recent inquiries and new accounts show loan stacking.
  • Employment database and employer checks. What the database shows for each employer, and whether the employer phone on the application is the employer's listed number.
  • Document analysis. Edits after production, which tool produced each stub, and whether taxes and year-to-date figures agree with the stated pay.
  • The connected bank account. The owner's name and contact details, detected income, and 90 days of transactions: deposits from the stated employer, and loan money arriving and leaving.
  • Device and velocity. The same device, phone, email or bank account on other applications under other names.

Add your own policy

Many lenders require independent proof of income above certain loan amounts or income gaps, whatever the fraud evidence shows. Put that standard in the request and Grayson applies it alongside its own judgment.

Your income verification standard adds this to the state of the legitimate example:

{
  "income_verification_standard": "Personal loan income verification standard (rev. 2026-07): For any loan of $15,000 or more, when the stated total income is more than 20% above the employment database's annualized base pay for the primary employer, hold the application for income verification before the credit decision. Deposits in a connected bank account and pay stubs uploaded by the applicant don't satisfy this standard, however consistent they are. It is satisfied only by the employment database for each employer, IRS tax transcripts through Form 4506-C, or a call to each additional employer at a number we find ourselves. Apply this whatever the fraud evidence shows; it is a documentation requirement, not a fraud finding."
}
QuestionWithoutWith your income verification standard
fraud_likelihood0.03 of 4, confidence 98%0.04 of 4, confidence 97%
problemsNone at 50% or moreNone at 50% or more
income_supported98% true98% true
actionproceed, confidence 98%verify_income, confidence 68%

In the likely-legitimate example, the nurse asks for $18,500 and her stated $104,000 is 27% above the database's base pay for her main job. Her deposits and stubs show the second job, but under this standard they don't count, so the action moves from proceed to verify income, while the fraud likelihood stays very low and the deposits still support her income.

Where to call it

  • After the credit pull, document analysis and account link return, and before the credit decision or any offer.
  • Again after a hold, with the verification result added to the state, so the same screen makes the final call.
  • Before the funds go out, if the bank account for the funds changes after approval.

Cost and latency

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious15,392$0.00054$0.54236 ms
Legitimate16,952$0.00059$0.59302 ms
Ambiguous12,962$0.00045$0.45285 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/loan-application-fraud/questions.json --label fraud_likelihood=<column> --label problems=<column> --label income_supported=<column> --label action=<column>

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

  • fraud_likelihood: a level, such as "Very likely (over 90%)"
  • problems: option keys separated by | (income_overstated, employer_unverifiable, document_altered, stolen_identity, synthetic_identity, loan_stacking, bank_account_not_applicants)
  • income_supported: true or false
  • action: proceed, verify_income, verify_identity, 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

Does it work for credit cards and small-business loans?

Yes. The questions don't depend on the product, so send what your application and checks hold for it. For a credit card there is often no connected bank account, so income_supported relies on what you do have; for a small-business loan, add the business's registration, its bank statements and the owners' identity checks, as in the business onboarding recipe.

Can it catch loan stacking when the other new loans aren't on the credit report yet?

Only from what you send. New loans take weeks to appear on a credit report, so send what shows sooner: inquiries, lending consortium applications with the same SSN, and loan money arriving in the connected account. Grayson weighs these against the applicant's answer about recent loans.

What do we tell an applicant we decline?

A declined credit applicant is still owed an adverse action notice under the Equal Credit Opportunity Act and Regulation B, with the specific principal reasons. Regulation B's sample notice includes reasons such as "unable to verify income" and "unable to verify employment", and problems helps you choose the accurate one. Your compliance team decides the wording.

Detect account opening fraud and synthetic identities

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

Review business onboarding (KYB) applications

Approve, approve with limits, request documents or decline a business applying for card processing or another business product.

Recipes

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

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.

AML and sanctions

Transaction monitoring alerts, money mule accounts and sanctions and watchlist screening. Ready-to-run Grayson recipes with real responses, cost and latency.

On this page

ExamplesCall it from your codeThe problemWhat to sendAdd your own policyWhere to call itCost and latencyEvaluate on your own dataFAQDoes it work for credit cards and small-business loans?Can it catch loan stacking when the other new loans aren't on the credit report yet?What do we tell an applicant we decline?Related recipes