I introduced the Money Flow Map in Issue #1. Most of you replied. Half the replies said the same thing:
"Cool. How do I actually draw one?"
This issue is the canonical "how to draw it" reference. Print it, pin it next to your monitor, run through it the next time you scope a fintech feature. It's deliberately mechanical. The point is to remove the temptation to skip steps.
When to draw a Money Flow Map
Three triggers:
Before any new fintech product or major feature gets scoped. Day zero. Before wireframes.
When a regulator or auditor asks a question you don't immediately know the answer to. That gap is the gap the diagram would close.
When you hire a new PM, designer, or engineer onto a fintech team. It's the fastest onboarding doc you can give them — replaces three weeks of "wait, who actually holds the money?"
Don't draw it at week 4. By then, the architecture is committed and the map becomes an after-the-fact justification, not a design tool.
The five components — full definitions
1. Parties
Definition: Every legal entity that touches the money or makes a decision about the money in your flow.
Common parties to enumerate:
The end customer (consumer or business)
Your company
Each banking partner you depend on
Each broker-dealer, custodian, or money-services-business in the chain
Each card network (if cards are involved)
Each card processor (Marqeta, Galileo, etc.)
The KYC/AML vendor
The regulator (yes — list them as a party. They have a role in the flow even if they don't move money.)
Diagram convention: rectangles, one per party. Color-code by jurisdiction (US, EU, IL) so cross-border flows are visible at a glance.
2. Events
Definition: Every moment money or value moves, or a decision about money is committed.
Common events to enumerate:
Authorization (the moment the customer commits to a transaction)
Submission (the moment the transaction is submitted to a rail)
Settlement (the moment the rail confirms the transaction is final)
Reversal (the moment a transaction is undone)
Refund (the moment money flows back to the customer)
Failure (the moment a rail or counterparty rejects the transaction)
Disclosure (the moment a regulator-mandated message is shown to the customer)
Diagram convention: arrows between parties, labeled with the event name. Each arrow has a timestamp source — e.g., "Submission: card network ISO-8583 message timestamp." If you can't say where the timestamp comes from, the event isn't fully specified.
3. Rails
Definition: Every payment or value-movement network that carries money in your flow.
Common rails:
ACH (Same-Day, Standard)
RTP / FedNow
Wire (FedWire / SWIFT)
Card networks (Visa, Mastercard, Amex, regional)
Pull/push card transactions (different rails, different cycles)
Crypto rails (Ethereum, Solana, stablecoin issuance and burn)
Internal book transfers (within the same partner bank)
Why this matters: every rail has its own cycle (intraday / next-day / T+2), its own cutoff time, its own failure mode, and its own cost. A "same-day transfer" promise sits on top of a rail. If the rail's cutoff is 3pm ET and your customer initiates at 4pm ET, your promise is broken — and you should know this before you make the promise.
Diagram convention: every arrow is labeled with the rail it uses. If an arrow can use multiple rails (smart routing), draw it as a fan-out and label each rail with its conditions.
4. Licenses
Definition: Which entity holds which license, and what that license actually permits.
Common license categories:
State money transmitter licenses (US, ~50 jurisdictions)
Federal banking license (national bank, federal savings, etc.)
Trust company license
Broker-dealer license (FINRA + SEC)
Investment Advisor (RIA, SEC- or state-registered)
E-money license (EU, UK)
Payment Institution license (EU, UK)
Banking Sponsor license (the bank you partner with)
Why this matters: every event-rail combination requires that a licensed entity sit on at least one side of the flow. If you're sending USD to a customer's external bank account, somebody licensed must be initiating the transfer. That somebody is either you (if you hold the license), your partner bank, or a money transmitter you've contracted with.
The pattern that breaks fintech products: the team assumes "the partner has the license" without checking what the license actually permits. Many bank partners hold a license that allows them to initiate ACH for their own customers — not for your customer-of-customers. That distinction is invisible until a regulator looks.
Diagram convention: every party gets a license-holdings annotation. "Mercury Advisory LLC: SEC-registered RIA. Permitted activities: investment advice." If you can't write that one-line annotation for every party in your map, you don't yet know whether your product is legal.
5. Records
Definition: What gets logged, where it's logged, with what timestamp, and who can audit it.
Common record types:
Transaction records (your database)
Customer disclosures shown (timestamp, content, customer ID)
Decision records (KYC outcomes, underwriting outcomes)
Reconciliation records (your records vs. the rail's records)
Audit logs (every state change, who/what initiated)
Why this matters: in fintech, the audit is the structural event, not the launch. A regulator visiting your office in 2027 will not ask you to demo the app. They will ask: "Show me, for transaction X on date Y, every record that touched this customer's funds, with timestamps and authorizing actors."
If your records are scattered across three databases, two vendor APIs, and one Slack channel, you can't answer that question. Most fintech products that fail an audit don't fail because they did the wrong thing; they fail because they couldn't prove they did the right thing.
Diagram convention: every event arrow has a record annotation. "Submission event: logged to transactions table; timestamp from card network; correlation ID exposed to user via UI." Every event needs all three: source, timestamp, exposure.
The drawing process — 90 minutes
Block 90 uninterrupted minutes. Whiteboard or Excalidraw (no slide tools — too tempting to skip steps).
Minute 0–15: Parties only. Draw rectangles. Don't connect them yet. Aim for 4–7 parties. If you have fewer than 4, you've forgotten one. If you have more than 8, you're probably listing departments instead of legal entities.
Minute 15–35: Events. Draw arrows. Each arrow named with an event. Each arrow has a timestamp source written next to it. If you can't name the timestamp source, the event isn't fully specified — leave a "?" and come back.
Minute 35–50: Rails. Annotate each arrow with the rail. If the same arrow can carry multiple rails, fan out.
Minute 50–70: Licenses. Annotate each party with its license holdings (one line each). If a license is missing for a flow that depends on it, mark it with a red exclamation point. These are your scope-killers.
Minute 70–85: Records. Annotate each event with its record source, timestamp, and customer-visible exposure.
Minute 85–90: Review. Read the diagram out loud to a colleague who didn't help draw it. The questions they ask are the questions a regulator will ask.
What to do with the map
Three things, every time:
Pin it. Print A3, hang it where the team works. Update it when scope changes.
Ship it with every spec. Engineers should never receive a feature spec without the map attached. The map is the contract.
Bring it to compliance review week zero. Don't ask compliance for input on a feature description; ask compliance for input on the map. The conversation that results is 5× shorter and 10× sharper.
What this isn't
The Money Flow Map is not:
A user-flow diagram (those describe the UX; this describes the capital and license flow)
An ER diagram (those describe data; this describes legal entities and rail transitions)
A sequence diagram (those describe timing within one transaction; this describes the structural shape of the flow at large)
A pitch slide (don't waste the map by putting it in front of investors. It's a working artifact.)
If you find yourself making it pretty, you're using it wrong. It's a working document. Crossings-out and arrows redrawn are signs the map is doing its job.
What to do this week
Pick one fintech product or feature you're working on right now. It can be live, in-scoping, or pre-scoping.
Block 90 minutes on your calendar this week. Not in the next product review. Solo, with a whiteboard or Excalidraw.
Draw the map using the five-block process above. When you find a "?" — license you can't name, timestamp source you can't identify — write it down separately. That list is your week's scoping work.
Send the map to the engineer and the compliance advisor on the project. Ask one question: "Is anything wrong here?" Their answers will be more useful than any roadmap meeting you'll have this quarter.
If you only do one: #3.
If you'd like a worked-example map for a real fintech product (treasury, lending, payments, or AI-in-finance) — that's exactly what comes out of my 2-week MVP scoping sprints. Book a strategy call: cal.com/barakazuga/strategy-call.
— Barak
The Regulated MVP is a weekly tactical brief for fintech and AI-in-finance product leaders. Every Tuesday.