Companion repository for the Nerdearla Chile 2026 talk Fraud prevention, machine learning, and design patterns: keep your analysts in the loop, by José P. Barrantes.
I put this material together to expand on the architecture, operational trade-offs, and research behind the talk.
| Format | Link |
|---|---|
| Technical article, web | jospablo777.github.io/fraud_ml_design_pattern |
| Technical article, PDF | communication/LaTeX/technical_article.pdf |
| Slides, PDF | Nerdearla-fraud_prevention_ML_and_architecture.pdf |
| Talk recording | Nerdflix |
Fraud prevention requires coordinated decisions across rules, machine learning, operational policy, and analyst review. A model estimates risk; the surrounding system determines how to act, which cases need investigation, and how review outcomes inform future decisions. This repository describes a design pattern for that system: ML-enabled human-in-the-loop triage.
Fig. 1. Rules encode explicit knowledge and controls. Machine learning scores and ranks cases. Analysts investigate ambiguity, identify unfamiliar behavior, and provide feedback.
This material is for fraud, risk, and trust-and-safety teams deploying ML, data scientists integrating models into production, and software architects responsible for those systems. The pattern also applies to workflows with automated decisions and limited review capacity, including security alert triage, content moderation, credit adjudication, and claims review.
Four properties of fraud affect the architecture.
Attackers adapt. Fraudsters change their behavior as detection methods become known. Models and rules need monitoring and revision as those tactics change.
Labels are delayed and incomplete. Confirmation may arrive weeks later through a customer dispute or a completed investigation. Unreported fraud can remain labeled as legitimate in training data. Different forms of abuse, such as account takeover, friendly fraud, and mule activity, also have distinct indicators that a single fraud label can obscure.
Errors have different costs. Missed fraud causes financial loss. Blocking a legitimate transaction creates customer friction, support work, and potential churn. Policy thresholds need to reflect those costs and the organization's risk tolerance.
Decisions have deadlines. Some interventions must happen within milliseconds. The available time determines which checks can run automatically and which cases can wait for review.
The model produces a risk estimate. A separate policy layer combines that estimate with operational constraints to select an action.
Fig. 2. The scoring, policy, and action stages have separate responsibilities.
Policy may account for analyst capacity, regional restrictions, campaign traffic, service-level agreements (SLAs), and legal requirements. Keeping this logic explicit makes it possible to inspect, version, audit, and change decision behavior without retraining the model.
Fig. 3. Rules handle cases covered by explicit controls. Machine learning scores the remaining cases. Policy routes them to automatic approval, analyst review, or mitigation.
Each component has strengths and limitations. Rules are precise and auditable but require maintenance as behavior changes. Models combine weak signals and generalize across cases, though their outputs can be difficult to explain. Analysts interpret context and investigate unfamiliar behavior, within the limits of available time and expertise. Routing policy determines how these capabilities are used.
Analyst review needs defined inputs, decision authority, escalation paths, and structured outputs. These requirements affect queue design, interfaces, and the data captured during investigation.
Fig. 4. Review outcomes support changes to rules, thresholds, labels, and routing logic. The yellow arrows show retrospective review of automatically handled cases, which helps detect false positives and false negatives.
The model prioritizes cases for investigation. Analysts adjudicate them, escalate when necessary, and record outcomes that can be reused for maintenance and training. Sampling automatically approved and mitigated cases also helps identify errors that the review queue would otherwise miss.
Fig. 5. The analyst interface presents case priority, contributing signals, deadlines, and action controls. Structured fields capture the outcome, reason code, confidence, and suggested action; free-text notes provide additional context.
The operational objective is to reduce fraud loss while controlling customer friction and analyst workload. Evaluation needs to cover the conditions under which decisions are made.
Fig. 6. Four evaluation areas: data and input quality, model and decision quality, queue and analyst operations, and runtime and platform health. Policy behavior is evaluated across these areas.
Useful measures include precision among the cases analysts can review, recall on confirmed fraud, calibration, backlog, review latency, and service availability. Approval, review, and block rates describe policy behavior and should be tracked alongside model metrics.
These measures expose operational trade-offs: faster decisions allow less time for investigation; broader detection can increase customer friction; more review coverage requires more analyst capacity; frequent changes increase the work needed for traceability and audit.
Coupling scoring and policy. Business actions depend directly on model outputs, making decision logic difficult to inspect and revise. Define and version the policy separately.
Unstructured review outcomes. Free-text notes alone make analyst feedback difficult to reuse. Capture outcomes, reason codes, confidence, and suggested actions in structured fields.
Incomplete operational design. Queue behavior, escalation logic, and the analyst interface receive too little attention during development. Review demand can then exceed capacity, causing backlog and analyst fatigue.
Insufficient monitoring. Queue overload, analyst disagreement, and calibration drift can develop while the service remains available. Define monitoring for these conditions before deployment.
Unmanaged integration complexity. Feature joins, rule engines, scoring services, queues, and alerting tools accumulate under delivery pressure. Shared interfaces, traceability, and versioning help keep these dependencies maintainable.
This architecture requires queue monitoring, versioned decision logic, an audit trail, and governed feedback data. Software engineers, data scientists, risk operators, and analysts need to coordinate changes to shared system behavior. These costs should be assessed against the expected reduction in fraud loss, customer friction, and review workload.
The article documents the context, competing requirements, solution, and consequences of ML-enabled human-in-the-loop triage so teams can assess where it applies.
Fig. 7. The pattern applies where review demand exceeds analyst capacity, some decisions require immediate action, attackers adapt, and errors have different costs. Its design balances response time, customer friction, detection coverage, human oversight, and available expertise.
The proposal builds on established human-in-the-loop approaches. Its contribution is to document the combination of rules, scoring, policy, analyst review, and feedback as a reusable architecture for fraud operations.
The article includes five additional figures covering system anatomy, planning, analyst–model collaboration, operational learning, and the MLOps lifecycle, along with open research questions and the full bibliography.
communication/
Quarto/ Web article source (.qmd, references.bib, CSL styles)
LaTeX/ LaTeX article source and PDF
docs/ Rendered site for GitHub Pages
img/ PNG figures and editable GIMP sources in img/GIMP/
Nerdearla-fraud_prevention_ML_and_architecture.pdf Slide deck
The Quarto and LaTeX articles contain the same text, figure captions, definitions, and references. Their layout and citation formatting differ. Keep both sources aligned when editing the article, and rebuild the HTML and PDF outputs.
The .xcf files let you edit the figures for your own material.
The README gives an overview of the architecture. The slides follow the conference talk. The technical article develops the design, operational details, and research context.
The article contains the full bibliography. These references cover the main topics:
- Sculley, D., et al. (2015). Hidden technical debt in machine learning systems. NeurIPS 28. Maintenance costs in the software and infrastructure surrounding ML models.
- Lewis, G. A., Ozkaya, I., & Xu, X. (2021). Software architecture challenges for ML systems. ICSME. https://doi.org/10.1109/ICSME52107.2021.00071 Co-architecting, co-versioning, and monitorability.
- Kästner, C. (2025). Machine learning in production: From models to products. MIT Press. ML integration into products and operational systems.
- Andersen, J., & Maalej, W. (2024). Design patterns for machine learning-based systems with humans in the loop. IEEE Software, 41(4), 151–159. https://doi.org/10.1109/MS.2023.3340256 Reusable patterns for human participation in ML systems.
- Alves, J. V., et al. (2025). A benchmarking framework and dataset for learning to defer in human-AI decision-making. Scientific Data, 12, 506. https://doi.org/10.1038/s41597-025-04664-y Routing decisions between models and experts.
- Jalalvand, F., et al. (2024). Alert prioritisation in security operations centres. ACM Computing Surveys, 57(2). https://doi.org/10.1145/3695462 Alert prioritization, workload, and analyst fatigue.
- Amershi, S., et al. (2019). Guidelines for human-AI interaction. CHI 2019. https://doi.org/10.1145/3290605.3300233 Interface design for oversight and intervention.
- Chen, C., et al. (2022). Reliable machine learning: Applying SRE principles to ML in production. O'Reilly. Monitoring and reliability practices.
You're welcome to adapt the figures, diagrams, and text for your own presentations, documentation, and systems. I'd appreciate a citation if you find them useful:
Barrantes, J. P. (2026). Designing fraud-prevention systems that keep analysts in the loop. Nerdearla Chile 2026. https://github.com/jospablo777/fraud_ml_design_pattern
I'd be glad to hear your questions, disagreements, or experiences with fraud review systems.
- LinkedIn: José Pablo Barrantes
- BlueSky: doggofan77.bsky.social
Released under the MIT License.