The model was not the difficult part
During my IBM internship, I worked with a credit-card dataset containing roughly 284,000 transactions and a fraud rate of only 0.17%. That imbalance makes the problem feel strange: a model can be “accurate” by doing almost nothing useful.
I began with two unsupervised approaches—Isolation Forest and a deep Autoencoder. Both produced an anomaly score, but neither score meant much to an analyst on its own. One was based on isolation path length; the other on reconstruction error. They lived on different scales and failed in different ways.
The interesting work started after the first notebook ran successfully.
A notebook proves that an idea can work. A prototype has to make its assumptions visible enough that somebody else can trust it.
The split comes before the cleverness
With rare-event data, leakage can quietly turn a good-looking experiment into fiction. I created stratified train and test boundaries first, then fitted scaling and resampling steps only on the training data. SMOTE belonged inside that boundary—not before it.
I also kept a Logistic Regression baseline. It was less exciting than an Autoencoder, which made it useful. If a complex system could not justify itself against a transparent baseline, the architecture was not the achievement I wanted it to be.
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, stratify=y, random_state=42
)
scaler.fit(X_train)
X_train_scaled = scaler.transform(X_train)
X_test_scaled = scaler.transform(X_test)
That ordering looks obvious when written down. It is also exactly the kind of detail that disappears when experimentation moves too quickly.
Two imperfect signals were better together
Isolation Forest and the Autoencoder noticed different kinds of unusual behavior. I normalized both outputs and combined them into a hybrid fraud-risk score from 0 to 100.
The combined system raised precision from 2.97% for the standalone Autoencoder to 14.64%, while retaining 83.7% recall. The F1 score moved from 0.057 to 0.249. Those numbers were not magic; they were the result of treating each model as one piece of evidence rather than a final verdict.
The 0–100 score also created a better interface. A threshold could change with operational needs, and an analyst could see how much each model contributed instead of receiving a mysterious binary answer.
Explainability became part of the output
I initially thought of explanation as a layer added after prediction. That view changed while building the analyst-facing breakdown. If the system cannot say why a transaction looks risky, it is harder to debug, tune, and use responsibly.
For each flagged transaction, the prototype exposed:
- the normalized Isolation Forest contribution;
- the Autoencoder reconstruction contribution;
- the combined risk score;
- the threshold that triggered the alert;
- and the features most responsible for the deviation.
This was not a perfect causal explanation, but it made the model inspectable. It gave a human somewhere to begin.
The unglamorous checklist that made it reliable
By the end of the internship, my checklist looked less like model research and more like software engineering:
- Fix the data boundary before fitting anything.
- Save preprocessing artifacts alongside model weights.
- Make evaluation reproducible from one command.
- Report precision and recall, not accuracy alone.
- Test missing values and out-of-range inputs.
- Keep a simple baseline alive.
- Explain every score in the language of the person using it.
The biggest lesson was not that hybrid models always win. It was that reliability comes from the entire path around the model: data, evaluation, interfaces, explanations, and the discipline to reproduce yesterday’s result.
The notebook was where the idea appeared. The prototype was where it became honest.
