DEV Community: Mustabin Neha

Credit Card Fraud Detection

Mustabin Neha — Sat, 12 Sep 2026 19:42:22 +0000

What 284,807 Credit Card Transactions Taught Me About Fraud (And About Trusting My Own Charts)

I've been building a data analytics portfolio that combines my finance and accounting background with hands on Python. My first project looked at ROE across the top 200 US companies. For this one, I wanted something with a bit more edge, so I picked a dataset that's practically a rite of passage in data science: the Kaggle Credit Card Fraud Detection dataset. Nearly 285,000 real, anonymized European transactions from September 2013, with fraud making up a tiny fraction of the total.

I wasn't trying to build a model. I just wanted to understand the shape of fraud in the data, the way an auditor might poke at a ledger looking for anomalies. What I found along the way was a lesson that applies well beyond fraud detection: a chart can be technically correct and still lead you to the wrong conclusion if you don't check what's behind it.

How rare is fraud, really?

Out of 284,807 transactions, only 492 were fraudulent. That's 0.173 percent. Put another way, if you picked transactions at random, you'd need to look at almost 600 of them before expecting to see a single fraud case. This is the classic "needle in a haystack" problem that makes fraud detection genuinely hard: any method that just predicts "not fraud" every time would already be right 99.8 percent of the time, which tells you accuracy alone is a useless metric here.

Fraud hides in small amounts

I split the data into fraud and normal transactions and compared their amount distributions. Normal transactions span a huge range, some go past $25,000. Fraudulent transactions cluster tightly at the low end and basically disappear once you get into the thousands. In this dataset, fraud isn't going for the big score. It's staying small and easy to overlook, which is exactly the kind of behavior that slips past a distracted reviewer or a threshold-based alert set too high.

The chart that lied to me (a little)

Here's where it got interesting. I broke the data down by hour of day and counted how many fraud cases showed up in each hour. Hour 2 and hour 11 stood out with the highest raw counts, around 57 and 53 cases respectively. My first instinct was to write that up as "fraud spikes at 2am and 11am."

Then I paused. A raw count doesn't tell you if an hour is actually risky or if it just processes more transactions overall. An hour with 50,000 total transactions and 53 fraud cases is a very different story from an hour with 5,000 total transactions and the same 53 fraud cases. So I recalculated using the fraud rate per hour instead: fraud count divided by total transactions in that hour.

The corrected picture was sharper and more honest. Hour 2 held up as a genuine hotspot, with a fraud rate of 1.71 percent, about 10 times the overall average. Hour 4 also stood out at 1.04 percent, roughly 6 times average. But hour 11, which looked like the second biggest spike in the raw count chart, dropped to a much quieter 0.31 percent once normalized. It was still slightly above average, but nowhere near as dramatic as the count chart made it look. Some of that raw spike was volume, not risk.

This is the same trap I ran into on my last project with ROE. A ratio, a rate, or a count can look meaningful on its own, but it only means something once you check what's underneath it. In accounting terms, it's the equivalent of not trusting a margin number until you've looked at both the numerator and the denominator.

What actually predicts fraud in this data

The dataset's 28 numeric features are anonymized (they've been through a PCA transformation, so we don't know what they represent in plain business terms), but a few of them clearly carry signal. Looking at correlation with the fraud label, three features stood out with the strongest negative correlation: low values on these features were the clearest indicator of fraud in the dataset. A smaller set of features showed a positive relationship, though weaker. Even without knowing what these features represent in the real world, this is a useful reminder that a handful of variables often carry most of the predictive weight, a pattern worth knowing before building anything more complex on top of a dataset like this.

The takeaway

Rare event data is a genuinely different animal from the balanced spreadsheets many of us are used to in finance. It punishes lazy metrics and rewards checking your assumptions twice. My biggest takeaway from this project wasn't really about credit cards. It was a reminder that the first chart you make is a hypothesis, not a conclusion, and it's worth the extra five minutes to check whether what you're seeing is a real pattern or just a byproduct of the data's shape.

The full notebook and code are on GitHub if you want to dig into the analysis yourself, or replicate it with a different rare-event dataset.

This is part of an ongoing series applying Python and data analysis to finance and accounting questions.

What ROE Doesn't Tell You

Mustabin Neha — Sat, 12 Sep 2026 17:49:46 +0000

What ROE Doesn't Tell You: A Beginner's Look at 200 US Companies' Financial Health

My first Python data project, and what it taught me about reading ratios like an analyst, not a spreadsheet.

Why I Started Here

I have a formal background in finance and accounting, but I'm brand new to Python. So instead of learning Python through generic tutorials, I decided to learn it by doing the kind of analysis I actually understand: financial statement ratios. I used a Kaggle dataset covering pre-calculated ratios ROE, current ratio, debt-to-equity, and more for the top 200 US companies, and worked through it in Google Colab.

Step One: Just Look at the Data

Before doing anything clever, I loaded the CSV with pandas and checked the basics: what columns existed, how many rows, what data types, and quick summary statistics (mean, min, max) across all the ratios. This is a habit worth keeping regardless of the tool you don't analyze what you haven't looked at first.

Ranking by ROE and a Reality Check

Return on Equity (ROE) is one of the most commonly cited profitability metrics: it tells you how efficiently a company turns shareholder equity into profit. So naturally, my first move was to sort all 200 companies by ROE and see who came out on top.

The answer: McKesson Corporation, by a wide margin.

If you don't know McKesson's story, this looks like a slam-dunk a company squeezing enormous returns out of shareholder capital. But here's where the accounting background matters more than the code: McKesson has spent years aggressively buying back its own stock, which shrinks shareholder equity sometimes down to very small or even negative levels. Since ROE is calculated as Net Income divided by Equity, a shrunken denominator can inflate the ratio dramatically, even when the underlying business performance hasn't changed all that much.

In other words: a high ROE isn't automatically a sign of a great business it can just as easily be a sign of financial engineering.

Widening the Lens: Liquidity and Leverage

To avoid over-indexing on one ratio, I pulled two more views:

Current Ratio (short-term liquidity can a company cover its near-term obligations?)
Debt-to-Equity (leverage how much debt is the company carrying relative to equity?)

Sorting by Current Ratio surfaced a completely different leaderboard from ROE NVIDIA, Activision Blizzard, Texas Instruments, Intuitive Surgical, Arista Networks, TransDigm Group, DexCom, Monster Beverage, Vertex Pharmaceuticals, and Zoetis topped the list, all with current ratios well above 3 (NVIDIA highest at over 7). None of these were anywhere near the ROE top 10. That alone is worth sitting with: the "best" company depends entirely on which question you're asking. A company can be a poor ROE performer and still be extremely safe on liquidity, or vice versa profitability and short-term financial safety are simply answering different questions.

Looking at these alongside ROE gives a much more honest picture than any single number in isolation. A company with a sky-high ROE but also very high debt-to-equity is telling a very different story than one with high ROE and conservative leverage even if the ROE figure looks identical on paper.

Testing the McKesson Theory Across All 200 Companies

The McKesson observation raised a question: is this a one-off, or a pattern? To check, I plotted every company's ROE against its Debt-to-Equity ratio in a single scatter chart, rather than just looking at the top 10.

The result: most of the 200 companies cluster tightly in the bottom-left corner of the chart low debt-to-equity, low-to-moderate ROE, no visible relationship between the two. But a handful of companies break sharply away from that cluster, sitting far to the right with debt-to-equity ratios in the thousands. The most extreme point on the entire chart debt-to-equity near 4,300 and ROE above 12 is almost certainly McKesson.

So it's not a broad, systemic trend across all 200 companies most businesses don't show any strong link between leverage and ROE. But the few genuine outliers on the chart are exactly the companies worth double-checking before taking their ROE at face value, since extreme ROE and extreme leverage do show up together for them. McKesson isn't unique in kind, just the most extreme example of a small group.

Either way, this is the more rigorous version of the same instinct: don't trust one ratio, and don't trust one company's story as proof of a pattern until you've checked it across the full dataset.

The Takeaway

The biggest lesson from this project wasn't a Python lesson it was a reminder that ratios are shorthand, not truth. ROE, on its own, answers "how much profit relative to equity?" but says nothing about why the equity is the size it is. The moment you pull in debt levels, buyback history, or industry context, the story can change completely.

For anyone with a finance background moving into data work: this is exactly the kind of judgment that a model or a script can't replicate on its own knowing which number to be suspicious of, and why, is domain knowledge, not code.

What's Next

This was project one of an ongoing series where I'm using Python to explore different corners of finance next up: either rounding out this dataset further, or moving into a completely different area like credit risk, budgeting trends, or market data.

Built with Python (pandas, matplotlib) in Google Colab. Dataset: "Financial Statement Data for Top 200 US Companies" via Kaggle.