Investigation Walkthrough: Your First Fraud Investigation

A fraud investigation walkthrough traces a single case from initial alert to a documented decision: gather data, assess signals, decide an action, and write it up so the case file holds up for the next analyst. This article follows new analyst Ren Castillo through a 23-order velocity alert that turns out to be a card-testing run linked to a wider fraud ring.

Monday Morning, Week Three

Ren Castillo had been a fraud analyst at Lakeshore Commerce for exactly sixteen days when their queue loaded a case that would take the rest of the week.

Alert #4471-A. Priority: Medium. Reason: Velocity anomaly. A customer account had generated 23 orders in 90 minutes, all for electronics, all shipping to the same address in Glendale, Arizona.

Ren stared at it. In training, they'd reviewed sample cases with neat timelines and obvious signals. This was different. Twenty-three orders. Real money. A real customer (or a real stolen identity). And Ren's decision would determine whether those orders shipped or got blocked.

They reached for the investigation framework their trainer had given them on Day 1: gather, assess, decide, document. Four steps. Start with the data.

This story is fictional, but the patterns are real.

Step 1: Gather the Data

What the Alert Told Ren

The automated system had flagged the account based on velocity: 23 orders in 90 minutes was far outside normal behavior for this account (which had zero prior orders). The alert included the customer's account ID, the order IDs, and the device fingerprint.

Ren pulled up the full picture.

Account Details:

Order Pattern:

The pattern was clear even to a new analyst: the orders started small and got progressively more expensive. The first three were under $50. By the end, individual orders were topping $800.

Shipping Address: All 23 orders shipped to the same residential address in Glendale, AZ. The billing address on the payment method matched a different address in Scottsdale, AZ.

Device Data: Single device fingerprint across all orders. Browser: Chrome on Windows. IP address: a residential ISP in the Phoenix area.

Payment: A single Visa credit card. All 23 orders used the same card. AVS (address verification) returned a partial match: ZIP code correct, street address mismatch.

What Ren Did Right

Before looking at any of this, Ren took a screenshot of the alert dashboard and noted the timestamp. Evidence preservation starts before investigation, not after.

They also resisted the urge to immediately block all 23 orders. The velocity was suspicious, but Ren didn't have enough information yet to know whether this was fraud, a legitimate bulk purchase, or something in between.

What Ren Looked Up Next

Ren checked the credit card's BIN (historically the first six digits of the card number, which identify the issuing bank). ISO/IEC 7812-1 was revised in 2017 to define 8-digit IINs; Visa and Mastercard required network and acquirer support by April 2022, and the industry has been migrating to 8-digit IINs since. Many tools and APIs still use the term "BIN" for both lengths. The card was issued by a major national bank. Not a prepaid card, not a virtual card number. A real credit card tied to a real bank.

They searched the email address across the platform's database. No other accounts. The email domain was Gmail, which is too common to be a signal either way.

They searched the shipping address. No other accounts had shipped to that address before. A quick check showed it was a single-family home in a residential neighborhood.

They searched the device fingerprint. No other accounts had used this device. That was mildly reassuring (if the device had been associated with previous fraud, it would be a stronger signal) but also expected for a new account.

Step 2: Assess What You've Found

Ren organized the evidence into two columns:

Signals pointing toward fraud:

• Brand new account (created the night before the orders)
• Zero prior order history
• 23 orders in 90 minutes (extreme velocity)
• Progressive value escalation (small to large)
• Billing and shipping address mismatch
• Partial AVS match (ZIP yes, street no)

Signals pointing toward legitimate:

• Residential IP in the same metro area as both addresses
• Real credit card from a major issuer (not prepaid)
• Single device used consistently (not rotating)
• Items are consumer electronics (high resale value, but also things a real person would buy)
• Shipping to a residential home (not a freight forwarder or PO box)

Ren felt stuck. The evidence was mixed. This is where training cases and real cases diverge: training cases have a clear answer. Real cases often don't.

The Escalation Decision

Ren's trainer had told them: "When you're not sure, escalate. Not because you can't handle it, but because a second pair of eyes protects the customer and the company."

Ren flagged the case for their team lead, Maya, with a summary of findings and their initial assessment: "Leans fraud based on velocity and escalation pattern, but some signals are inconsistent with typical fraud. Requesting guidance before taking action."

Maya reviewed it in ten minutes and pointed out something Ren had missed.

"Check the card testing pattern," she said. "Look at the first three orders."

Ren looked again. The first three orders were all under $50. Small amounts. Different product categories. Placed within 13 minutes.

"That's card testing," Maya explained. "They're validating the card works before scaling up. A legitimate customer who wants $6,000 in electronics doesn't start with $29 earbuds."

She was right. The escalation pattern wasn't a customer gradually filling a cart. It was a criminal confirming the card was live, then increasing amounts to extract maximum value before the card got shut down.

Step 3: Decide and Act

Maya and Ren decided to:

1. Hold all 23 orders (prevent shipment pending review)
2. Not cancel them yet (in case the verification step clears them)
3. Attempt customer verification (call the phone number on file)

Ren called the phone number. It went to voicemail. The voicemail greeting was a generic carrier message, no name. They left a message asking "Robert" to call back to verify recent orders.

While waiting, Ren ran one more check. They looked up the phone number in the platform's internal records. The same phone number was associated with two other accounts that had been blocked for fraud three weeks ago. Different names, different emails, same phone.

That was the missing piece. The phone number linked this account to a known fraud ring. The "Robert Tanner" account was part of a pattern.

The Action

Ren, with Maya's approval:

• Blocked all 23 orders
• Suspended the account
• Flagged the phone number, device fingerprint, and shipping address in the fraud database
• Filed an internal incident report linking this account to the two previously blocked accounts
• Documented the entire investigation timeline

No money was lost. No merchandise shipped. The card issuer was notified and confirmed the card had been reported stolen two days earlier by the real Robert Tanner, who lived in Scottsdale (the billing address) and had no connection to the Glendale shipping address.

Step 4: Document Everything

Ren wrote up the case with the structure Maya had taught them:

Case Summary: 23 fraudulent orders placed using a stolen credit card on a newly created account. Orders held before shipment. No financial loss.

Evidence Trail:

1. Alert triggered by velocity anomaly (23 orders in 90 minutes)
2. Account created less than 12 hours before first order
3. Card testing pattern identified (small orders escalating to large)
4. Billing/shipping address mismatch with partial AVS
5. Phone number linked to two previously blocked fraud accounts
6. Card confirmed stolen by issuing bank

Decision Rationale: Combination of velocity, escalation pattern, and phone number link to known fraud accounts provided sufficient basis for blocking. Individual signals were ambiguous; the combination was not.

Linked Cases: Account IDs of the two previously blocked accounts, with cross-references for the shared phone number.

What Ren Learned

Lesson 1: Card Testing Is a Tell

The progressive escalation pattern (small, medium, large) is one of the strongest fraud signals in e-commerce. Legitimate customers don't validate their own credit cards with $29 purchases before buying $800 laptops. They just buy the laptop.

Card testing is the criminal equivalent of dipping your toe in the water. If the small charge goes through, the card is live. If it gets declined, move to the next card. The first few small orders are investments, not purchases.

Lesson 2: Link Analysis Breaks Cases

The phone number was the key that unlocked this case. Without it, Ren had a suspicious but ambiguous set of signals. With it, the case connected to a known pattern.

Fraud rings reuse infrastructure. They rotate names and email addresses easily, but phone numbers, device fingerprints, shipping addresses, and payment methods are harder to swap out completely. Searching for these shared identifiers across accounts is often how you connect isolated fraud cases into a larger pattern.

Lesson 3: Escalation Isn't Weakness

Ren's decision to bring Maya in wasn't a sign of inability. It was the right call. Maya spotted the card testing pattern that Ren had seen but not recognized. Two perspectives produced a faster, more accurate assessment.

The danger isn't escalating too much. The danger is making a high-confidence decision when you're actually uncertain, either blocking a legitimate customer or approving a fraudulent order because you felt pressure to decide quickly.

Lesson 4: The Four-Step Framework Works

Gather, assess, decide, document. It sounds obvious, but under the pressure of a real case with real money at stake, having a framework prevents shortcuts. Ren's instinct was to block the orders immediately. The framework forced them to gather data first, which revealed the phone number link and produced a much stronger case.

Lesson 5: Speed Matters, But Accuracy Matters More

None of the 23 orders had shipped when Ren caught the case. That's the ideal outcome. But if Ren had rushed to block without investigating, they wouldn't have identified the phone number link, the connected fraud accounts, or the pattern that helped future investigations.

The hold (preventing shipment without cancelling) was the right intermediate step. It preserved optionality: if verification had cleared the customer, the orders could have been released. Because it didn't, the block was applied with full documentation.

Key Takeaways

• Start with data, not decisions. Gather everything available before forming a conclusion. First impressions are often wrong, and the most important signal might be the last one you find.
• No single signal proves fraud. Velocity, address mismatch, new account, card testing pattern. Each is ambiguous alone. The combination tells the story.
• Link analysis connects the dots. Searching shared identifiers (phone numbers, devices, addresses) across accounts is one of the most powerful techniques in fraud investigation. Criminals reuse infrastructure.
• Escalate when uncertain. A second pair of eyes is not a crutch. It's a control. The best analysts know when they need input.
• Document for the future. Your investigation today might be evidence in a larger case tomorrow. Write it up as if someone else will need to understand your reasoning without being able to ask you questions.

What's next: Review Common Fraud Types for the full catalog of fraud patterns you'll encounter as you progress, and SQL Crash Course to build the querying skills that power investigations like this one.

Key Terms