Risk AssessmentHigh riskComparison recommended

AI Playbook for Synthetic Identity Fraud in Personal Loans

A fintech lender has experienced $1.8M in charge-offs in 6 months from personal loans to borrowers who appear to have no prior credit history, then built thin files rapidly before applying. The average time from first credit inquiry to loan application is 4.2 months—unusually short.

When to use this playbook

  • Use this playbook when the decision looks like the situation above: A fintech lender has experienced $1.8M in charge-offs in 6 months from personal loans to borrowers who appear to have no prior credit history, then built thin files rapidly before applying.
  • It is a fit when you have source files in hand and need a structured, reviewable analysis — not a generic chat answer about "Synthetic Identity Fraud in Personal Loans".
  • Do not use it as a substitute for licensed, legal, clinical, or authorized official judgment in the domain.

What you'll need

  • Loan application file (all originations, past 12 months)
  • Credit bureau pull data at origination
  • Payment history through charge-off
  • Device and IP data at application
  • Social Security Administration validation flags (if any)

Attachments: Documents (Documents)

The Prompt

You are a fraud analyst investigating synthetic identity fraud in a fintech personal loan portfolio. I am attaching:

Work only from the attached source files. If a conclusion is not supported, say so.

Produce:
1. Identify borrowers where the SSN was issued after the reported date of birth or where the SSN has fewer than 3 years of credit history despite the stated age.
2. Flag applications where the same device, IP address, or phone number was used for multiple distinct borrower identities.
3. Analyze the credit-building pattern for charged-off loans: rapid authorized user additions, thin file, single inquiry, large first loan—this is the synthetic identity playbook.
4. Calculate the average loss per synthetic identity vs. true first-party default, and estimate total synthetic exposure in the portfolio.
5. Tell me what origination controls would have caught 80% of these and what I need to change in the underwriting decision engine.

Call out where independent models are likely to disagree, and list follow-up documents a reviewer should request.

What to expect

  • Synthetic identity probability scores by application
  • Device/IP clustering analysis
  • Credit-building pattern flags
  • Loss comparison: synthetic vs. organic default
  • Origination control recommendations with estimated catch rate

Review before you act

  • Validate this output against source files before relying on it: Identify borrowers where the SSN was issued after the reported date of birth or where the SSN has fewer than 3 years of credit history despite the stated age.
  • Validate this output against source files before relying on it: Flag applications where the same device, IP address, or phone number was used for multiple distinct borrower identities.
  • Validate this output against source files before relying on it: Analyze the credit-building pattern for charged-off loans: rapid authorized user additions, thin file, single inquiry, large first loan—this is the synthetic identity playbook.
  • Validate this output against source files before relying on it: Calculate the average loss per synthetic identity vs. true first-party default, and estimate total synthetic exposure in the portfolio.
  • Confirm every cited figure, date, counterparty, or requirement against the attached originals — models compress and can drop a qualifier.
  • Treat disagreement between models as a review item, especially on classification, materiality, and recommended next action.
  • Do not authorize an operational, clinical, legal, credit, or enforcement action solely because the models agree.

Why compare models on this

For Synthetic Identity Fraud in Personal Loans, running the same attachments across independent models is useful because the hard part is classification and completeness, not fluency. The workflow is already designed to surface synthetic identity probability scores by application; device/ip clustering analysis; credit-building pattern flags; loss comparison: synthetic vs. organic default. Those are comparison artifacts — they only exist if more than one model runs. Typology labels (bust-out vs. first-party vs. third-party) and ring membership often diverge across models when data is incomplete. Divergence is a reason to hold and verify, not to auto-file a SAR.

Fraud DetectionCredit and Identity FraudRisk AssessmentHighDocuments

See governed multi-model AI on your own prompt

Compare GPT-5, Claude, and Gemini side by side, with human review and a decision record built in.