What 506K real transactions taught me about how Latin Americans actually save

Joel Mendoza — Wed, 17 Jun 2026 16:24:12 +0000

For nine years I ran Coinch, a goal-based savings app used by 30,000+ people across Mexico, Colombia, Argentina, Peru and Chile. When it wound down in 2024, it left behind 506,311 records of real saving behavior: 305,808 transactions, 108,570 savings goals, 91,933 users.

Most of what I found contradicts how savings products are designed. Here are the patterns, with numbers.

1. Naming your dream makes you more likely to fail at it

This is the finding that still bothers me. We grouped goals by category and measured completion:

Goal type	Completion rate
Free saving (no specific target)	7.8%
Travel / vacation	~4.7%
Car / vehicle	~4.5%

Aspirational, labeled goals — the car, the trip to Cancún — failed more than unlabeled "just saving" goals. The standard product playbook says the opposite: make the user visualize the dream, attach a photo, name the goal. Our data says the dream-naming ritual correlates with worse outcomes, possibly because aspirational goals get set with unrealistic amounts and deadlines (median goal horizon was just 120 days), while "free saving" grows quietly without a deadline to fail against.

2. Saving apps are graveyards of good intentions — and that's the honest baseline

Across all 108,570 goals: 73.8% ended overdue, 19.2% in progress, only 7.0% achieved. Among users, 93.7% never completed a single goal.

If you're building or evaluating a savings product, that's the base rate you're fighting. Any pitch deck claiming 40% goal completion is either measuring something else or selecting heavily. The honest question for product design isn't "how do we get everyone to finish" — it's "what distinguishes the 6.3% who do."

3. The answer: discipline beats everything else, and it's measurable

We computed a savings discipline score (regularity and consistency of deposits) per user. Its correlation with goal completion: ρ = 0.89. Nothing else came close. Not goal size, not income proxies, not demographics.

The practical implication is uncomfortable for feature roadmaps: the predictive signal isn't in what people save for, it's in how regularly they show up. A user depositing $2 every Friday is a fundamentally different (and more promising) customer than one who deposited $200 once.

4. Saving together works — but almost nobody does it

Shared goals (saving with friends or family toward one pot) were only 2.1% of all goals. But they outperformed on every axis: 8.9% completion vs 7.0% for individual goals (+27% relative), median target of $10,000 vs $6,000, and a savings rate roughly 3× higher.

The feature with the best outcomes had the worst adoption. In our case, the social layer was under-built — the data shows the demand signal we didn't fully act on. If I were building a savings product today, shared goals wouldn't be a feature; they'd be the product.

5. January is real. December is brutal.

Monthly deposit seasonality across nine years: January peaks at 9.7% of annual volume (new year's resolutions show up in the data, every year, without fail), with a secondary lift in August–October. December bottoms out at 7.1% — holiday spending doesn't just compete with saving, it wins.

If you run a financial product in LatAm: your acquisition budget belongs in the first week of January, and your December churn isn't your fault.

6. People deposit round numbers — 69.5% of the time

Of all deposits, 69.5% landed on exactly round values: 50, 100, 500, 1,000. Money is psychological before it's numerical. (This one has a practical engineering consequence too — synthetic test data with amounts like $147.23 is instantly recognizable as fake. I wrote about the statistics of faking it properly in a separate post.)

Where this data lives now

The app is gone, but the behavioral patterns are now the calibration source for a synthetic data generator on Apify — it produces unlimited fake-but-statistically-faithful LatAm fintech data (users, goals, transactions) for testing, ML training and demos. 100% synthetic output, zero PII, the real dataset stays private.

If you're building fintech for Latin America and want to pressure-test your assumptions against measured behavior, that's exactly what it's for. And if there's a pattern here you'd like to see explored deeper, tell me in the comments — the data has more stories than one post can hold.

Why your synthetic fintech data fails code review (and how mixture models fix it)

Joel Mendoza — Fri, 12 Jun 2026 22:01:57 +0000

Every fintech developer has done this: you need test data, you reach for Faker, you generate ten thousand transactions, and your demo works. Then a data scientist on the buying side opens your dataset, runs one df.describe(), and the deal-killing question arrives: "Why are your transaction amounts uniformly distributed?"

Real financial data has a shape. Synthetic data that ignores that shape is instantly recognizable — and in testing, ML training, or sales demos, instantly discrediting. I spent nine years running a savings app in Latin America (30,000+ users, 2015–2024), and when it wound down I kept something most synthetic data generators never had: 506,311 real records to measure that shape against. This post is about the three statistical properties that separate believable synthetic financial data from Faker output, with the actual numbers.

Property 1: Amounts are multimodal, not lognormal

The standard "sophisticated" approach is to sample amounts from a lognormal distribution. It's better than uniform — and it still fails. When I fitted a single lognormal to 261,070 real deposits, the body of the distribution looked fine (7–10% deviation between p25 and p90), but the tail fell apart: 35–45% deviation at p95–p99.

The reason is that "deposit amount" isn't one population. It's at least three: micro-deposits (the $1–$20 spare-change crowd), typical deposits ($100–$800), and large transfers ($6,000+). Each has its own location and spread. A single lognormal averages across them and gets all of them wrong.

The fix is a mixture of lognormals. Fit GaussianMixture from scikit-learn on the log-amounts, select the number of components, sample from the mixture. One non-obvious lesson from doing this on real data: don't select K with BIC. Financial amounts have heavy atoms at round values (more on that below), and BIC reacts to those atoms by under-fitting the number of components. Selecting K by minimizing the Kolmogorov–Smirnov statistic against a held-out sample worked far better: a 6-component mixture brought deposits from KS=0.068 down to KS=0.032, and p99 deviation from ~45% to under 5%.


python

DEV Community: Joel Mendoza