Fintech Fraud Analytics

Why I built it

Fraud is a rare-event problem, which makes it a good test of whether an analysis holds up when the interesting cases are a fraction of a percent of the rows.

Questions it answers

• Which transaction types carry the fraud, and at what rate?
• What patterns separate a fraudulent transfer from a normal one?
• How do you keep 6.3 million rows queryable in an interactive dashboard?

How I built it

1. Load and model. The PaySim dataset lands in PostgreSQL with the query patterns the dashboard needs designed in up front.
2. Analysis in Python. Transaction-type breakdowns and behavioural comparisons between flagged and clean records.
3. Streamlit front end. An interactive dashboard deployed publicly on Streamlit Community Cloud rather than left as a notebook.
4. Hosting migration. Moved the database from Supabase to Neon after hitting free-tier limits — a real constraint, handled rather than worked around.

How I know it works

• 6.3 million transactions queried interactively, not sampled down to fit.
• Deployed and publicly reachable, so the work can be clicked rather than described.