Eleven MVPs in, I can tell you what kills a fintech launch — and it’s almost never the code.
Three years ago, I was advising a Series A lender that had just finished a beautiful, Stripe-grade onboarding flow. Seven weeks of design. A feature roadmap a VC partner had called “immaculate.” We were four days from soft launch when the compliance officer dropped a single line into a Slack thread.
“Where does the money actually leave the customer’s account?”
No one could draw it. Not the PM. Not the CTO. Not the designer. We had a product, a deck, and a pricing page. We did not have a map. We delayed six weeks.
That was my last “ship first, regulate later” MVP. Since then, I’ve built eleven fintech products at banks, investment firms, and venture-stage startups — and the ones that shipped on schedule all started the same way. Not with a user journey. Not with a wireframe. With a money-flow diagram.
The insight most PMs get wrong
Here’s the PM orthodoxy for an MVP:
Define the user problem
2. Scope the minimum feature set
3. Build a prototype
4. Test with users
5. Iterate
That works perfectly for SaaS, productivity tools, and consumer apps. It does not work for fintech. When your product moves money — someone else’s money, regulated money, traceable money — every one of those five steps is gated by a question no one on the product team can answer alone: who owes whom, when, and under whose license?
Fintech PMs who learn this the hard way usually learn it on the same day the lawyers read the pitch deck and cross out three of the five features. Or worse, on the day a regulator asks for the chain-of-custody diagram three weeks post-launch and the team spends a quarter retrofitting it.
The fix is almost embarrassingly simple: put compliance into the scope phase, not the review phase. Stop treating compliance as a QA gate. Start treating it as a design input, exactly like latency or churn.
This sounds like extra work. In practice it’s the opposite. Compliance-first scoping typically cuts feature backlogs by 30–40% — because half the features you were planning to build are either illegal in your target geographies or are going to require licensing work you can’t finish in the MVP window anyway. Knowing that at week 1 is a gift. Finding it at week 9 is a disaster.
The framework: The Money Flow Map
Before any fintech MVP gets a product spec, I draw a Money Flow Map. One page. Five components:
The parties — every entity that touches the money or the data about the money. Customer. Your platform. Your banking-as-a-service provider. The destination. The card network. Any intermediary.
2. The events — every state transition money can make. Authorization. Capture. Settlement. Refund. Chargeback. Reversal.
3. The rails — which wires actually move the value. ACH. SEPA. Card. Wire. Stablecoin. Internal ledger.
4. The licenses — who is legally permitted to do what, at each edge of the diagram. Your license, your partner’s license, the recipient’s license.
5. The records — what gets written down, by whom, retained for how long.
Draw it on a napkin. Draw it in Excalidraw. It doesn’t matter. What matters is that every arrow in the diagram has a legal owner, and every box has a licensee behind it. If you can’t fill in a party, an event, a rail, a license, or a record — that’s not a gap in the diagram. That’s a gap in your product. Scope around it.
The Money Flow Map is the single most underrated artifact in fintech product. It is the first document I produce for every client engagement. It takes two hours. It saves a quarter.
How this plays in practice
Last year, a Series B treasury startup came to me with a 14-feature roadmap and a 90-day build window. Beautiful Figma files. The PM’s job was to get it shipped.
We spent the first session not looking at Figma. We drew the Money Flow Map.
Three things surfaced in those two hours.
First: their “instant payout” feature — prominent in the marketing site, headline in the deck — actually moved money through a partner whose license did not cover two of their target countries. “Instant payout — except in the two largest markets you’re pitching to VCs” is not a feature. It’s a rewrite of the positioning statement. We cut it from the MVP and rebranded the offer around same-day payout, which the license supported everywhere.
Second: their refund flow had a 72-hour window in the spec. The Map revealed that one of the rails involved had a 5-business-day settlement cycle. A 72-hour refund promise was literally impossible to honor without the platform eating the timing cost out of its own treasury. That’s not a bug caught in QA. That’s an unfunded liability caught in planning.
Third: their record-keeping was split between two systems with inconsistent customer identifiers. No regulator was going to be able to reconstruct a single customer’s transaction history without a spreadsheet and a prayer. We unified it in the MVP.
Feature count went from 14 to 9. Build window stayed at 90 days. They shipped on time. More important, they shipped something they could defend to an auditor without spending the next quarter documenting backwards.
That is the Money Flow Map’s real ROI. Not the features you add. The ones you stop building.
What to do Monday
Three things you can run this week, regardless of your stage:
Book two hours on your calendar and draw your Money Flow Map. If it’s longer than a single page, you’ve overscoped. If you can’t fill in a license column, that’s your first scope cut.
2. Forward the Map to your compliance advisor before your next product-review meeting. Ask one question: “Which of these arrows is going to take you longer than 90 days to approve?” Their answer is your MVP cut list.
3. Add the Map to your product spec as Section 1 — before the user stories. Every feature below it should cite which boxes or arrows it depends on. Features that can’t be traced back are suspect.
If you only have time for one, do #1.
If you’re scoping a compliance-sensitive MVP right now and you want another set of eyes on the Map, I do 60-minute strategy calls. I usually find the feature that shouldn’t ship within the first 20 minutes.
— Barak