How to design a flow of funds

Last week I mapped out the people you’ll need before you write a line of code. Here’s something I didn’t mention: almost every one of them will ask you for the same document and it’s not your pitch deck!Sponsors, banks and compliance teams have seen a thousand decks.

It’s your flow of funds.

Think of this document as a map showing who owns the money, where it sits, and what legally allows it to move; typically taking the form of a one-page picture of every account your product touches and how money moves between them. It's usually the first thing an EMI's risk team asks for and the quality of it tells them, within a few minutes, whether they're talking to someone who understands regulated payments or someone who's learning as they go.

I've seen this document completely change the tone of a meeting. When it's done well, the conversation quickly moves from "How does this work?" to "How do we launch it?

Here’s how to draw one properly.

Every arrow should answer four questions

A flow of funds is not an architecture diagram. It's not a user journey either.

It's simpler than both. Money moves from account to account through your product, and every time it moves, your diagram needs to answer four questions.

How does money enter the system? Which rails, what the customer references when they pay in, and where the money lands when it arrives. If customers pay into a vIBAN issued in their own name, say so. If funds arrive against a payment reference into a pooled account, say that instead. Entry is the easiest part to draw and the worst part to hand-wave.

What can customers do once money is in the system? This is the one founders underestimate. Can they hold a balance? Spend on a card? Send it to someone else? Redeem it? Buy crypto, or stocks and shares? And mechanically, how? Does money move from their vIBAN to the crypto exchange one-to-one, or do you pool customer funds and send them to the exchange in bulk, one-to-many? Those are different flows with different risks, and your sponsor will treat them very differently.

How do you prevent co-mingling? Client money and your money must never blur. So where do your fees get swept to, and how often? A fee that sits in the client money account for a week is a finding waiting to be written up. Show the sweep, name the frequency.

How does money leave? Withdrawals and payouts, and the checks that run on the way out. Do you verify the beneficiary, CoP in the UK, VoP in SEPA? What happens when the name doesn’t match?

Answer those four and you’re ahead of most applications a sponsor sees. Miss them and no amount of visual polish will save you.

What the risk team is actually scoring

Beyond the mechanics, the reviewer is silently checking three things.

Does money only move when the diagram says it can? Your sponsor expects client funds to stay at the bank where the vIBANs are issued. You don’t get general permission to move money around. You get specific permissions for specific movements, each one drawn in the flow of funds. A customer redeeming e-money to fund a crypto exchange is a use case. “We move funds to another account for operational reasons” is not. This is why the diagram carries so much weight: it isn’t a description of your product, it’s effectively the list of movements your sponsor is authorising. If it’s not on the diagram, it doesn’t happen. One nuance worth knowing for that conversation: at the bank, under a virtual account model safeguarded funds sit as one pooled total, and the per-customer breakdown lives on the platform ledger, with reconciliation running total-to-total between the two.

What happens when a payment fails? And they do, constantly. Wrong reference, failed screening, closed destination account, rail outage. For every arrow, the reviewer wants to know where the money waits when it can’t move forward, and how it gets back. A diagram with no failure paths tells me you've only drawn the journey you hope happens, not the one you'll actually have to operate.

And they’ll read your co-mingling answer twice. The fee sweep is where weak diagrams fall apart. Somewhere in the flow, money stops being the customer’s and becomes yours, and that moment has to be explicit: which account it leaves, which it lands in, what triggers it, how often. If revenue just ambiently appears in your company account, expect the diagram back with questions.

How founders usually draw it

Take a simple cross-border payment product. Customer pays in, recipient gets paid out. The founder version:

Technically true. Completely useless.

Here’s the version the risk team wants:

Notice there’s one client account, not a separate collections account and payout account. The vIBAN your customer pays into is the account their payout leaves from. What changes along the way is the currency it holds and the permission each movement happens under, and that’s exactly what the diagram is there to show.

Every box is a real account with a named holder. The line between client money and company money is explicit. Every failure has a home.

That’s the whole trick.

Card programmes run on two clocks

Card products confuse people because there are actually two completely different timelines. One happens in seconds, the other happens days later.

Treat them as the same thing and your flow of funds will be wrong.

If your card diagram shows money moving at the moment of the tap, redraw it. The gap between those two clocks is where real programmes make real mistakes, and it gets its own article later in this series.

Four things that make a risk team stop reading

Confusing messages with money. An API call is not a transfer. Draw where value moves, not where instructions move.

No failure paths. The reviewer’s first question. Every time.

Revenue mixed with client funds. If your fee sits in the safeguarding account a moment longer than it needs to, expect hard questions.

Claiming custody you don’t have. “We hold customer funds.” No. Your sponsor holds them, at a bank, and that difference is precisely what the whole regulatory structure exists to police.

That last one matters double when you’re presenting. Say “funds are held by our sponsoring EMI in safeguarded accounts, and we maintain the per-customer ledger” and the room relaxes. Say “we hold the money” and the meeting becomes a correction session.

Steal this template

Label every account with three things: what it’s called, who holds it, and whose money is in it (client safeguarded or company).

Label every movement with five: what triggers it, which rail it uses, whose permission it happens under, how long it takes, and where the money goes if it fails.

Then a footer answering the four questions. How money enters. What customers can do with it, and whether flows out to third parties run one-to-one or pooled one-to-many. Where and how often fees sweep. How money leaves and what checks (CoP/VoP) run on the way out.

One page. If it doesn’t fit, your product has more than one flow. Draw several, don’t compress.

A founder who walks into a sponsor meeting with this has answered the risk team’s first twenty questions before anyone asks them. That’s what competence looks like from the other side of the table.

If you’ve drawn yours and want someone who reads these for a living to poke holes in it before your sponsor does, drop me a message.