What marks a fraudulent transaction?
What are the characteristics of fraudulent transactions?
The answer
In this PaySim sample, fraud shows up only in two transaction types. All 240 fraudulent transactions are TRANSFER or CASH_OUT: 0.7% of transfers and 0.2% of cash-outs, against 0.0% for PAYMENT, CASH_IN and DEBIT.
What we found
Fraud occurs only in transfers and cash-outs; payments, cash-ins and debits carry none.
Show more
TRANSFER has a fraud rate of 0.7% (95% interval 0.6% to 0.9%, n=16,898) and CASH_OUT 0.2% (0.1% to 0.2%, n=70,084). PAYMENT (n=67,660), CASH_IN (n=43,991) and DEBIT (n=1,367) show 0.0%. Restricting to TRANSFER and CASH_OUT still keeps all 240 fraud cases (86,982 rows), which matches the brief's description of fraudsters depleting accounts through transfers and cash-outs.
Be careful:
- DEBIT is small, so its interval reaches 0.3%.
All the numbers behind it: F1 in details/1_analysis.pdf
Fraudulent transactions are typically much larger, and the fraud rate climbs steeply with amount.
Show more
The median fraud amount is 401,192 against 73,996 for legitimate transactions (standardised difference +0.74). The fraud rate is 0.0% below 10,000, 0.1% from 10,000 to 200,000 and 0.2% from 200,000 to 1,000,000. It then jumps to 1.8% for 1,000,000 to below 5,000,000 and 4.7% at 5,000,000 and over (interval 3.0% to 7.4%, n=360). Still, 155 of the 240 fraud cases are below 1,000,000, so most fraud is not in the high bands.
Be careful:
- Part of this gap reflects type mix: PAYMENT and CASH_IN are mostly small and carry no fraud.
All the numbers behind it: F2 in details/1_analysis.pdf
Large amounts mark fraud among cash-outs, but not among transfers.
Show more
Within CASH_OUT, fraud amounts have a median of 455,710 against 146,796 (standardised difference +0.76). Cash-outs of 1,000,000 and over are 77.8% fraudulent (interval 65.1% to 86.8%, n=54), against 0.2% or less below that amount. Within TRANSFER, fraudulent amounts are if anything smaller (median 371,771 against 485,695; standardised difference +0.23 on means). The TRANSFER fraud rate is 1.2% below 100,000, 0.4% from 200,000 to 1,000,000 and 1.0% at 1,000,000 and over.
Be careful:
- The CASH_OUT group at 1,000,000 and over is only 54 rows, so the exact share is imprecise. 9 rows in the larger CASH_OUT bands were too few to show.
All the numbers behind it: F3 in details/1_analysis.pdf
Among transfers and cash-outs, type, timing and amount each stay associated with fraud when the others are held fixed.
Show more
In a model limited to TRANSFER and CASH_OUT (86,982 rows, 240 fraud), TRANSFER goes with x3.67 the odds of fraud against CASH_OUT (2.82–4.77). Each 100 steps later goes with x1.68 (1.56–1.82), and each extra 1,000,000 with x1.12 (1.08–1.16), all p<0.001. The model clearly beats no model (p<0.001; AUC 0.76 on the same rows). In the full model over all types, the zero-fraud types got x0.00 with intervals reaching infinity.
Be careful:
- The full model (T8) warned: the model did not settle on stable estimates, often because a category has only one outcome, and effects with very wide intervals are unreliable. Only the restricted model (T11) is used for conclusions.
- Amount enters as a straight line. This understates the sharp jump among cash-outs of 1,000,000 and over and averages the opposite patterns in the two types.
- The step effect largely mirrors the late-month volume drop (F4).
- AUC is measured on the same rows the model was fitted on.
All the numbers behind it: F6 in details/1_analysis.pdf
2 more finding(s) in details/1_analysis.pdf.
What you could do
- Treat transfers and cash-outs as the only relevant population for any fraud description or model of this data; the other types carry no fraud here.
- Describe amount separately for each type. For cash-outs, 1,000,000 and over is a strong marker; for transfers, amount alone tells little.
- Do not use step as a fraud signal without first adjusting for transaction volume per step, since the rise in rate reflects the simulator's volume pattern.
How much can you trust this?
| Good | Data | 200,000 rows; every value is present. More |
| Check | Checks | The automatic check on analysis numbers raised a warning. More |
| Check | Decisions | 3 made, 3 by the AI; 1 with low confidence (J3): worth a check. More |
Show the decisions made for you
| Question | Decided | By | How sure | |
|---|---|---|---|---|
| J3 | Should isFlaggedFraud be used as a feature, or excluded as a rule-based flag closely tied to the target? | Keep isFlaggedFraud as a feature | the AI | low |
| J1 | Should the 2,799 far outliers in amount (beyond 3x IQR, max 38,056,471.01) be kept or clipped? | Keep all amounts as they are | the AI | medium |
| J2 | Should the four balance columns (oldbalanceOrg, newbalanceOrig, oldbalanceDest, newbalanceDest) be dropped from the table, or kept but excluded from analysis? | Keep the columns in the table, marked excluded | the AI | medium |
To change one, edit edit/decisions.yaml and run again.
Keep in mind
- J3 was decided by the AI with low confidence: 'Keep isFlaggedFraud as a feature'. Should isFlaggedFraud be used as a feature, or excluded as a rule-based flag closely tied to the target?
- The reviewer asked (isFlaggedFraud): Should isFlaggedFraud stay in the analysis as a feature? It is almost constant in this sample, so it adds little for describing fraud.
- The reviewer asked (isFraud): How should the very low fraud rate (0.12%) be handled in the analysis? The cleaning left it as is, which is correct, but any later comparison or model needs to account for it.
Show all 9 points
- J3 was decided by the AI with low confidence: 'Keep isFlaggedFraud as a feature'. Should isFlaggedFraud be used as a feature, or excluded as a rule-based flag closely tied to the target?
- The reviewer asked (isFlaggedFraud): Should isFlaggedFraud stay in the analysis as a feature? It is almost constant in this sample, so it adds little for describing fraud.
- The reviewer asked (isFraud): How should the very low fraud rate (0.12%) be handled in the analysis? The cleaning left it as is, which is correct, but any later comparison or model needs to account for it.
- Gate 4: T8 logistic_regression: The model did not settle on stable estimates, often because a category has only one outcome. Effects with very wide intervals are unreliable.
- F4: the late-month fraud rate is driven by a collapse in total volume, which looks like a feature of how the simulator spreads transactions. It should not be read as fraudsters preferring the end of the month.
- F3: the striking 77.8% fraud rate among large cash-outs rests on 54 rows. The jump also partly follows from legitimate cash-outs of that size being very rare in the simulation.
- F5: the 10,000,000 cap is probably a hard limit in the simulator. A check at one exact value with 92 rows is thin evidence.
- F6: treating amount as a straight-line effect hides that amount separates fraud strongly within CASH_OUT but hardly within TRANSFER, so the x1.12 per 1,000,000 averages two different patterns.
- F2: the overall amount gap is partly type mix, because the types with no fraud (PAYMENT, CASH_IN) are mostly small amounts.
Want more?
| details/0_technical_summary.pdf | The same run with the exact figures, for a technical reader |
| details/1_analysis.pdf | Every finding with all its charts and the numbers behind them |
| details/2_data_quality.pdf | The data as received, what was wrong, and what was changed |
| details/2_data_columns.xlsx | Every column of the data, in Excel |
| details/3_decisions.pdf | Every decision: the options, why, and how to change it |
| details/4_audit.pdf | Which AI models ran, what it cost, and every file |
To change a cleaning decision, edit edit/decisions.yaml; to change the questions, edit edit/analysis_plan.yaml. Then run again.