A fraud detector trained on past cases can miss new tactics. An autoencoder offers a complementary way to look for them: it learns to reconstruct legitimate transactions, then treats unusually poor reconstructions as potential anomalies. It does not establish that a transaction is fraudulent; it identifies candidates for further review. section 8.4 section 8.4.1
Figure 8.9 Autoencoder architecture for unsupervised fraud detection. The encoder compresses the input transaction X into a low-dimensional representation h, and the decoder reconstructs it as X-hat. Anomalous (potentially fraudulent) transactions are identified when the reconstruction error |X – X-hat|2 is significantly high, indicating patterns the model didn’t learn during training on normal data.
The encoder compresses transaction features into a smaller representation; the decoder reconstructs the original features. A large difference between input and reconstruction signals a pattern the model did not learn well. section 8.4.1
A practical credit-card workflow separates learning normality from testing whether the score is useful:
- Start with scaled training and test features. Filter the training features to legitimate transactions (`X_train[y_train == 0]`); labels select normal examples but are not reconstruction targets. section 8.4.2
- Build a symmetric Keras autoencoder with Dense layers, BatchNormalization, LeakyReLU, and a lower-dimensional bottleneck. Use a linear output because standardized features can be negative or positive; check the compression and expansion with `model.summary()`. section 8.4.3
- Train on legitimate transactions as both inputs and targets. Validate on a separate legitimate subset; inspect training and validation loss, and use early stopping to restore the best weights. section 8.4.3
- Reconstruct the full test set and compare errors for legitimate and fraudulent transactions. Mean squared error or mean absolute error can serve as the anomaly score. section 8.4.1 section 8.4.2
Turning scores into alerts requires an operational threshold, not just a model fit. Examine normal-error statistics and class separation where test labels exist, then account for analyst review capacity and customer friction. Shadow-mode testing with analyst feedback can inform the threshold before live decisions; real-time use also requires serving, feature retrieval, logging, and monitoring. section 8.5











