Moniguard

What it is

Moniguard scores each payment from 0 to 1000 for fraud risk and says why, so a person can approve, review or block it. It is my own open-source product. It is not a 3Consulting deliverable.

The problem

Fraud in Nigerian pay-on-delivery shops and mobile-money apps looks different from card-present fraud. Phone numbers get recycled, delivery addresses cluster, and an account is taken over on a new device just before a large order. A merchant needs a score for each transaction in real time, not a report a month later.

What I built

• A transaction generator that creates realistic Nigerian orders with six labelled fraud patterns.
• One shared feature module with 73 features (velocity, amount changes, shared devices, phones and IPs). Training and live scoring use the same code, so they cannot drift apart.
• An ensemble of a class-weighted XGBoost model and an Isolation Forest, calibrated so the score maps cleanly to risk bands.
• A FastAPI service that returns the score and reason codes, plus Airflow and MLflow for retraining and tracking.

How it’s checked

The data is split by time, never shuffled. The model trains on the earliest 70% of the 180-day period and is tested on the latest 30%. I report PR-AUC and recall at a fixed review budget, with bootstrap confidence intervals, because plain accuracy would look excellent even for a model that flags nothing.

What the results do and don’t tell you

On synthetic data made by this repo’s own generator (60,000 transactions, about 2.8% fraud), the held-out test gives:

• PR-AUC 0.959 (95% interval 0.942 to 0.972) and ROC-AUC 0.996 in batch evaluation
• Recall 0.339 when analysts review the top 1% of traffic (the most any model could reach at that budget is 0.345), and 0.994 at a 5% review budget
• PR-AUC 0.837 and recall 0.843 at a 5% budget when 3,000 test transactions are scored one at a time through the API, the way live scoring works. Live scoring sees only the transaction in front of it, not the customer’s history, so this is the number to expect in use today

An audit on 1 November 2026 changed these figures. The calibration step had been fitted on the model’s own training predictions, and one feature (a vendor risk score) was built from the labels. Both are fixed, and a test now checks that the features come out the same with or without labels. The earlier 0.875 is retired.

These numbers show the pipeline works end to end and that the method is sound. They do not show how it would perform on real transactions. The data was generated, and it was not tested on a public benchmark such as PaySim or IEEE-CIS. A real pilot would need real data and a fresh evaluation.

My role

I designed and built all of it. Moniguard’s generator, features, model code and API were written for this project. None of it is copied from my employer’s client-specific code or data.

Stack

Python, XGBoost, scikit-learn (Isolation Forest, calibration), FastAPI, MLflow, Airflow, Docker.