Kaggle PaySim - Synthetic Mobile Money Transactions (1M+ Rows)

Kaggle PaySim - Synthetic Mobile Money Transactions is the Transaction & Payment Processing Services catalog's cleanest rehearsal stage for payment-risk work: roughly one million simulated mobile money transactions, each carrying five transaction-type values, sender and receiver account identifiers, pre- and post-transaction balances on both sides, and two independent fraud flags.

The simulator behind it was calibrated on an aggregated, anonymized sample of real mobile money platform logs, which is why the mechanics feel lived-in rather than random: money moves in CASH-IN, CASH-OUT, DEBIT, PAYMENT and TRANSFER shapes, balances reconcile arithmetically, and fraud arrives as a behavior - accounts drained by a TRANSFER followed by a CASH_OUT - instead of a random coin flip. Time runs as 744 hourly steps across 30 simulated days, so sequence matters. The full simulated run holds about 6.36 million transactions (~493 MB as a single CSV); the widely used working extract is the million-row cut this page describes.

Every field below carries a verified definition and example - the dictionary scores 8 on our field-documentation rubric against a catalog average of 7.81 across 1,744 datasets. Get a sample of this dataset and read real rows before anything ships. It sits in our transaction payment processing services data hub beside the rest of the industry's catalog.

One simulated transaction per row, eleven columns, exactly as delivered:

step           : 1
type           : PAYMENT
amount         : 9839.64
nameOrig       : C1231006815
oldbalanceOrg  : 170136.0
newbalanceOrig : 160296.36
nameDest       : M1979787155
oldbalanceDest : 0.0
newbalanceDest : 0.0
isFraud        : 0
isFlaggedFraud : 0

step           : 1
type           : TRANSFER
amount         : 181.0
nameOrig       : C1305486145
oldbalanceOrg  : 181.0
newbalanceOrig : 0.0
nameDest       : C553264065
oldbalanceDest : 0.0
newbalanceDest : 0.0
isFraud        : 1
isFlaggedFraud : 0

step           : 1
type           : CASH_OUT
amount         : 181.0
nameOrig       : C840083671
oldbalanceOrg  : 181.0
newbalanceOrig : 0.0
nameDest       : C38997010
oldbalanceDest : 21182.0
newbalanceDest : 0.0
isFraud        : 1
isFlaggedFraud : 0

Read the anatomy rather than the digits - all three rows above are documented examples of the delivered shape. First, the arithmetic always closes: in the PAYMENT row, oldbalanceOrg minus amount equals newbalanceOrig to the cent, so balance-consistency features can be engineered and trusted instead of guessed. Second, the fraud pattern is visible with the naked eye - in the TRANSFER and CASH_OUT rows, the originator's balance before the move exactly equals the amount and drops to zero afterward: an account emptied, twice, in the same hour, by two different customer IDs. Third, the rule-based control stays silent (isFlaggedFraud = 0) on both fraudulent rows while the ground-truth isFraud fires - the gap between what a threshold rule catches and what actually happened is built into the data, not bolted on. Fourth, merchant destinations carry an M prefix and hold zero balances on both sides, because the simulation tracks merchant ledgers differently from customer ones. Live rows cut to your types, steps and flags arrive with your sample.

All eleven cataloged fields carry verified definitions - every name, type, definition and example below was checked against the simulator's own documentation rather than inferred from column headers.

Three groups do the work. The movement group (step, type, amount) places each transaction on an hourly clock and gives it a shape and a size. The ledger group - nameOrig, oldbalanceOrg, newbalanceOrig, nameDest, oldbalanceDest, newbalanceDest - is the part most transaction extracts leave out: both parties' balances before and after, which turns every row into its own reconciliation test and makes liquidity and account-drain analysis possible without joining anything. The label pair (isFraud, isFlaggedFraud) separates observed fraud from control-flagged fraud, so you can measure a detection rule against ground truth instead of against itself.

Additional fields on request. Derived conveniences used in published walkthroughs - balance-delta error columns, per-account transaction counts, the TRANSFER-to-CASH_OUT linkage that stitches fraud chains together - ship with the sample rather than being promised blind. Ask for the sample and they arrive with it.

• Geographic: none stated, deliberately. The simulator was calibrated on an aggregated sample of real mobile money logs, so amounts behave like real ones but attach to no country, carrier or currency. Treat findings as mechanism-level - how drains unfold, how balances reconcile - not as any single market's rates.
• Temporal: 30 simulated days expressed as 744 hourly step values. Hour-of-day and day-of-month patterns are recoverable; calendar dates and seasonality are not, so trend claims stop at the month boundary.
• Granularity: one row per simulated transaction with both parties' pre/post balances - about a million rows in the standard extract, deep enough to stratify by type and still leave every fraud chain multiple examples.

That ladder is the point: a fully labeled, arithmetic-consistent transaction history where every idea about detection can be tested against complete ledgers on both sides of the money.

API, files, or your warehouse. Daily, weekly, or hourly.

You choose the slice and the shape: the full million-row extract, fraud-labeled rows only, a single transaction type, or a band of hourly steps - as flat files for analysts, a feed for running pipelines, or landed tables next to the rest of your warehouse. Every delivery ships the complete field dictionary above, the sample rows and the coverage profile mapped to whatever slice you named, so the version your models trained on is the version that keeps arriving. Get a sample of this dataset scoped to your slice before anything else happens.

• Fraud-model benchmarking without exposing a single real customer - supervised labels on both flags let you train, tune and compare classifiers end to end, then publish results without a privacy review; see data scientists use cases.
• AML drain-chain study - the TRANSFER-then-CASH_OUT behavior survives as connected rows sharing amounts and timing, so laundering patterns can be traced across accounts rather than scored one row at a time; see synthetic-data for why that works.
• Agent and account liquidity monitoring drills - dual-side balances make inflow/outflow timing per-account measurable, the base mechanic behind float and top-up forecasting for payment operations; see e-commerce operators use cases.
• Control-effectiveness reviews - compare what the threshold rule flagged against what actually happened, a quantified argument for where detection spend goes next; see competitive intel product teams use cases.
• Pipeline and schema testing - a stable eleven-column schema with heavy rows and rare positives is a realistic stress test for ingestion, feature stores and monitoring jobs; see developers builders use cases.

Data scientists and ML engineers get the rare fraud corpus where class labels, class rarity and feature raw material all coexist legitimately - the fastest honest dry run before pointing a model at production money movement. Payments and risk analysts get a drain chain they can follow end to end, which real logs almost never allow for compliance reasons. Product and strategy teams get a control-versus-ground-truth comparison that turns "our rules catch fraud" into a number. Developers and builders get a fixed eleven-column schema that loads fast and never changes shape mid-project. Educators get the demonstration set where precision-recall trade-offs, threshold effects and class imbalance all show up in one afternoon, with every column documented.

• Synthetic cuts both ways - no privacy constraints, but also no geography and no real counterparties: mechanism findings transfer, market-specific rates do not. Anyone quoting PaySim fraud percentages as industry benchmarks is overstating what the simulation claims.
• isFlaggedFraud is a control, not a second truth - it fires only on transfers above a fixed threshold, so treat it as the rule you are evaluating and isFraud as the answer key. Conflating them quietly ruins an evaluation.
• Fraud is rare by design - positive rows are a small minority spread across a million, which is exactly why the dataset rewards stratified sampling and precision-recall thinking over accuracy.
• Card rails are a different animal - pair it with Credit Card Fraud Detection (ULB) for real European card authorizations and IEEE-CIS Fraud Detection for device and identity enrichment this simulator does not attempt; the closest head-to-head lives at ULB vs PaySim.
• Macro context comes from elsewhere - for how national payment systems actually behave, pair with RBI Payment System Indicators, the monthly volume complement in the same catalog.

Two glossary notes sharpen the vocabulary before you commit: what a fraud label actually asserts about a row, and how synthetic data earns trust despite having no real customers in it. Pages that pair well: the transaction payment processing services data hub for the pooled industry view, the best transaction-payment-processing datasets ranking for where this sits, and how data scientists put simulation-calibrated ledgers like this to work.