Business problem: How can we identify high-risk, fraudulent transaction patterns in a high-volume mobile money network without freezing legitimate merchant cash flows?

This project answers that question end to end: exploratory analysis in Python, a PostgreSQL layer that translates the same business questions into SQL, and a Power BI dashboard that turns the findings into something a Fraud Review Team could actually act on.

Where does fraud actually concentrate? — by transaction type, amount, and destination account type.

How good is the status quo? — what does the platform's existing flagging rule catch, and at what cost?

What behavioral fingerprint separates fraud from legitimate high-value activity? — beyond just the transaction amount.

What's the trade-off if we act on that fingerprint instead? — how much fraud is caught vs. how many legitimate transactions get flagged.

Fraud lives in exactly two transaction types — TRANSFER and CASH_OUT — and never targets a merchant account. Of 2.15M merchant-destined transactions, zero are fraudulent.

The existing flagging rule barely works. It catches 16 of 8,213 fraud cases (0.2% recall) — essentially dormant.

A naive fix (flag every transfer over 200,000) overcorrects badly. Recall jumps to 66.6%, but it flags 1,192,198 legitimate transactions in the process — about 218 false alarms for every fraud case caught.

A single behavioral signal — the sender's account being fully drained to zero — is a near-perfect predictor. 97.7% of fraud does this; zero legitimate transactions do.

Recommendation: flag any TRANSFER/CASH_OUT transaction that fully drains the sender's balance. It catches 97.7% of fraud with zero false positives — merchant or customer — beating both the status quo and the naive threshold outright, not as a compromise between them.

Full walkthrough, with every number verified against the live data, is in PaySim_ Analysis.ipynb.

Built in Power BI, connected live to the PostgreSQL database below.

Volume Overview — overall transaction volume by type, and where fraud concentrates within it.

Rule Comparison — the payoff: recall vs. false-positive cost across the existing rule, a naive threshold, and the proposed rule.

Flagged Accounts — a filterable, review-ready list for a Fraud Review Team, built on the proposed rule.

Download the PaySim dataset (Kaggle: "Synthetic Financial Datasets For Fraud Detection") and place it in the project root as paysim dataset.csv.

Run the notebook top to bottom.

Create a PostgreSQL database and run the sql/ scripts in numeric order (01 through 05).

In Power BI Desktop, connect to the paysim_fraud database (PostgreSQL connector) and load transactions_enriched, v_rule_comparison, and v_flagged_accounts.

Python (pandas, matplotlib) for analysis · PostgreSQL for the data warehouse layer · Power BI for the dashboard.