AI Playbook for Identity Takeover — Account Opening Fraud
A credit union's digital banking team has seen 180 new accounts opened in 30 days via its mobile app, with 60 of those accounts showing immediate large withdrawals followed by zero activity. The accounts used real SSNs that passed identity verification but the behavioral pattern suggests stolen identity use.
When to use this playbook
- Use this playbook when the decision looks like the situation above: A credit union's digital banking team has seen 180 new accounts opened in 30 days via its mobile app, with 60 of those accounts showing immediate large withdrawals followed by zero activity.
- It is a fit when you have source files in hand and need a structured, reviewable analysis — not a generic chat answer about "Identity Takeover — Account Opening Fraud".
- Do not use it as a substitute for licensed, legal, clinical, or authorized official judgment in the domain.
What you'll need
- New account origination file (180 accounts, 30 days)
- Device fingerprint and IP data at application
- Transaction history for all 180 accounts
- Identity verification results (KYC pass/fail by check)
- Bureau inquiry data at origination
Attachments: Documents (Documents)
The Prompt
You are a fraud analyst investigating identity takeover in new account opening at a credit union. I am attaching: Work only from the attached source files. If a conclusion is not supported, say so. Produce: 1. Identify the 60 accounts with the immediate-withdrawal-then-dormant pattern and cluster them by shared device, IP, or phone number. 2. For each cluster, assess whether the SSNs used belong to real individuals who are unlikely to have opened the accounts (elderly, minors, deceased). 3. Determine whether the identity verification failures were systematic—did a specific KYC check (document scan, liveness, bureau) fail to catch these? 4. Calculate total losses and estimate the exposure from remaining unflagged accounts that may follow the same pattern. 5. Tell me what changes to the onboarding flow would prevent this attack and what I need to file with the NCUA. Call out where independent models are likely to disagree, and list follow-up documents a reviewer should request.
What to expect
- Identity takeover cluster map
- Victim profile analysis
- KYC failure point identification
- Total and projected loss estimate
- Onboarding control recommendations and NCUA filing guidance
Review before you act
- Validate this output against source files before relying on it: Identify the 60 accounts with the immediate-withdrawal-then-dormant pattern and cluster them by shared device, IP, or phone number.
- Validate this output against source files before relying on it: For each cluster, assess whether the SSNs used belong to real individuals who are unlikely to have opened the accounts (elderly, minors, deceased).
- Validate this output against source files before relying on it: Determine whether the identity verification failures were systematic—did a specific KYC check (document scan, liveness, bureau) fail to catch these?.
- Validate this output against source files before relying on it: Calculate total losses and estimate the exposure from remaining unflagged accounts that may follow the same pattern.
- 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 Identity Takeover — Account Opening Fraud, 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 identity takeover cluster map; victim profile analysis; kyc failure point identification; total and projected loss estimate. 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.
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.

