AI First-Party Credit Fraud Bust-Out Detection Playbook
A regional bank's credit card portfolio has 14,200 active accounts. The fraud team suspects a bust-out ring is operating across approximately 60 accounts: accounts that were opened cleanly, built credit, then maxed out in a compressed window before going delinquent. Net exposure is estimated at $2.1M.
When to use this playbook
- Use this playbook when the decision looks like the situation above: A regional bank's credit card portfolio has 14,200 active accounts.
- It is a fit when you have source files in hand and need a structured, reviewable analysis — not a generic chat answer about "First-Party Credit Fraud Bust-Out Detection".
- Do not use it as a substitute for licensed, legal, clinical, or authorized official judgment in the domain.
What you'll need
- Account-level transaction history (14,200 accounts, 18 months)
- Credit limit and utilization history by account
- Account origination data (address, phone, SSN last 4, IP at application)
- Delinquency and charge-off records
Attachments: Documents (Documents)
The Prompt
You are a fraud analyst investigating a suspected bust-out fraud ring in a regional bank's credit card portfolio. I am attaching: Work only from the attached source files. If a conclusion is not supported, say so. Produce: 1. Identify accounts that follow the bust-out pattern: 12+ months of low utilization, then utilization spike to 90%+ within a 45-day window, followed by missed payments. 2. Cluster accounts by shared origination attributes: same IP address, same device fingerprint, same address, overlapping phone numbers, or shared authorized users. 3. Identify the merchants and categories where the utilization spike occurred—bust-out rings often liquidate through gift cards, electronics, or wire services. 4. Calculate the total exposure across the suspected ring accounts and the timing of first missed payment relative to utilization spike. 5. Tell me which accounts I can still intercept (not yet charged off) and what intervention actions are available. Call out where independent models are likely to disagree, and list follow-up documents a reviewer should request.
What to expect
- Ring network map by shared attribute
- Merchant/category liquidation analysis
- Total confirmed and at-risk exposure
- Interceptable account list with recommended actions
Review before you act
- Validate this output against source files before relying on it: Identify accounts that follow the bust-out pattern: 12+ months of low utilization, then utilization spike to 90%+ within a 45-day window, followed by missed payments.
- Validate this output against source files before relying on it: Cluster accounts by shared origination attributes: same IP address, same device fingerprint, same address, overlapping phone numbers, or shared authorized users.
- Validate this output against source files before relying on it: Identify the merchants and categories where the utilization spike occurred—bust-out rings often liquidate through gift cards, electronics, or wire services.
- Validate this output against source files before relying on it: Calculate the total exposure across the suspected ring accounts and the timing of first missed payment relative to utilization spike.
- 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 First-Party Credit Fraud Bust-Out Detection, 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 ring network map by shared attribute; merchant/category liquidation analysis; total confirmed and at-risk exposure; interceptable account list with recommended actions. 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.

