How to use Claude to identify user fraud

A customer is earning reward points much faster than their card spend should allow. The fraud analyst can see it on one account. What they can't easily see is whether it's one person gaming a promotion or fifty, which merchant it runs through, and whether the company lost money on it. On fintech teams we work with, that question now goes to Claude, and the first answer comes back while the analyst is still on the account.

This is a playbook, built from how fraud, compliance and support people at a fintech use Claude through Contextflo every week. No customer names or numbers, just the setup that works.

The data Claude needs

Fraud questions cross tables nobody joins on a normal day. These are the sources that came up again and again:

Most of this lives in one warehouse. The vendor and compliance-tool fields often don't, and those are the joins where investigations used to stall.

The context that makes the answers right

Pointing Claude at those tables raw gets you plausible SQL and wrong answers. The schema doesn't say any of this, so it has to be written down once:

• How the tables join. The same customer ID can be stored as a UUID in one table and a string in another. Write down the canonical keys (business to transactions to KYC) and the cast, or every cross-table question fails or silently drops rows.
• What your detection rules mean. "Credits exceed declared annual income over a rolling 365 days" is a rule your compliance team named. Save its definition, so "show me R5 hits this quarter" means the same thing to everyone.
• Which fields are nested. Beneficial owners stored as a JSON array need to be unpacked before they can be matched. Say so in the column description.
• Which views are dead. Legacy views that are being replaced should be marked as such, or Claude will happily build on them.
• The heavy queries, saved. Multi-step AML queries are the ones that time out. Once one works, save it, and the next person reuses it instead of rebuilding it.

Contextflo generates a first pass of table and column descriptions from your schema, code and docs. The fraud-specific rules above are what your team adds, and the answers sharpen as people save corrections.

What an investigation looks like

Here is the shape of a rewards-abuse session, with illustrative prompts:

1. Start with one account. "Compare the points issued to this customer with their card spend, by merchant, for the last 90 days."
2. Test the obvious explanation. "Did people spend at this merchant before the points promotion existed?"
3. Follow the money. "Who receives the payments from these transactions, and did we earn any fee revenue on them?"
4. Go wide. "Do a top-down review of the top point earners this month. Were repeated welcome bonuses on the same card or on different cards?" Then the question that matters most: "Are there other cases like this?"
5. Write it up. "Give me a cautious draft of what we found and what's still unconfirmed." The analyst edits it, and pushes back when Claude misses something ("you didn't include total spend at the merchant across all customers").

Every number arrives with the query behind it, so the write-up can cite exactly what was run. Ask for totals and breakdowns, not raw award rows: a few thousand rows pasted into a chat is slow, expensive and harder to read than a ten-line summary.

Who focuses on what

The data team's work is front-loaded and small: the definitions and access groups above, then upkeep when a rule or table changes. After that, the operators who know what fraud looks like run their own investigations, and the data team stops being the queue every suspicion waits in.

Guardrails worth setting before anyone asks

• Read-only, always. The connection can't change a record, freeze an account or move money. Claude investigates; your systems act.
• Access by table and group. Support might see transactions and KYC status, while beneficial-owner and case tables stay with compliance. Access is set per table, so if analysts may only see their own region's customers, give each group a view.
• An audit log of every lookup. Every question and query is logged with the person who asked it. On customer data, "who looked at this account and why" is a question you will be asked.
• Decisions stay human. Claude finds the pattern and drafts the case. Filing a report or closing an account goes through your compliance process like it always has.

The analyst who spotted the odd points balance still makes the call. They just make it the same afternoon, with every similar account already on the page.

FAQ

Can Claude detect fraud in transaction data? Claude can investigate it. Connected to your transaction, KYC and rewards tables through a governed layer like Contextflo, it can trace one suspicious account, compare points earned against card spend, find other customers with the same pattern, and draft the write-up. The decision to freeze an account or file a report stays with your compliance team.

Is it safe to give Claude access to customer data for fraud investigations? Only through a layer that controls it. Contextflo connects read-only, limits which tables each person or group can query, and logs every question and query with the person who asked it, so you can see who looked up which customer.