Autoencoders for Financial Anomaly Detection: A Review of Architectures, Evaluation Practice and Deployment Gaps
Financial institutions must decide, within the milliseconds of a payment authorisation window and on evidence that is almost entirely unlabelled, whether a transaction is fraudulent: positives account for less than 0.2% of records, confirmatory labels arrive months later as chargebacks, and the gene...
Guardado en:
| Autores principales: | , , , , , , |
|---|---|
| Formato: | Reference entry |
| Lenguaje: | inglés |
| Publicado: |
2026
|
| Materias: | |
| Acceso en línea: | Enlace permanente (DOI o Handle) |
| Etiquetas: |
Sin Etiquetas, Sea el primero en etiquetar este registro!
|
| Sumario: | Financial institutions must decide, within the milliseconds of a payment authorisation window and on evidence that is almost entirely unlabelled, whether a transaction is fraudulent: positives account for less than 0.2% of records, confirmatory labels arrive months later as chargebacks, and the generating process adapts to whatever boundary a detector exposes. Supervised classification is poorly posed under these conditions. An autoencoder is a neural network trained to reconstruct its own input through a low-dimensional bottleneck; fitted to legitimate transactions alone, it converts an intractable labelling problem into a tractable one-class fitting problem, and the reconstruction error of a new record becomes a continuous score of atypicality. This review synthesises 85 Scopus-indexed records published between 2018 and 2026. It describes eleven architectural families and their hybridisation with resampling schemes, tree ensembles, one-class classifiers, and generative models across card payments, transaction monitoring, accounting and audit records, insurance claims, anti-money laundering screening, and on-chain value transfers. It then examines how these detectors are evaluated and finds the design space broad in architecture and narrow in evaluation: threshold selection, temporally held-out validation, drift analysis, and latency reporting are absent from almost every record examined. Closing those gaps, rather than adding architectural variants, is the priority the literature indicates. |
|---|