How to Build a Flow-of-Funds Diagram for a New Product Risk Assessment

TL;DR

• A flow-of-funds diagram is the artifact that maps every entity, account, rail, ledger entry, and control point before your product launches—not after something breaks
• Regulators don’t prescribe the format, but OCC, FFIEC, and FDIC guidance requires that you’ve documented custody, settlement timing, and failure paths for any product that moves customer money
• The diagram earns its keep when a risk committee member asks “what happens if the sponsor bank restricts volume?” and someone can answer from a document, not from memory
• Most launch-failure forensics (Synapse, Voyager, Bilt) trace to gaps the flow-of-funds diagram would have flagged—custody ambiguity, undocumented failure paths, unlicensed intermediaries

The new product risk assessment has a standard set of components: a questionnaire covering twelve risk categories, a scoring matrix, a pre-launch checklist, sign-off rows for the first and second line. Most teams fill those out and treat the risk review as done.

What most teams don’t build is the artifact that makes those inputs defensible: a flow-of-funds diagram.

Not a slide with arrows and boxes drawn in ten minutes. A documented map of every entity, every account, every ledger entry, every payment rail, every custody step, and every reconciliation point—with owners assigned at each stage. The diagram a bank partner’s risk team will actually read. The artifact an OCC examiner will pull when something breaks.

If your new product risk assessment doesn’t include one, you’ve assessed the risks of a product you haven’t fully described yet.

What a Flow-of-Funds Diagram Actually Maps

A funds flow diagram is not a marketing slide showing a customer sending money to a merchant. It’s a working document that answers:

• Where is the money at each moment? Which legal entity’s account holds it? Under what title?
• What rail is it moving on? ACH, wire, RTP, Visa/Mastercard network, internal ledger transfer, or something else? What settlement timing applies to each?
• Who reconciles each ledger leg? Every fund transfer creates at least two ledger entries—a debit and a credit. Who is responsible for squaring them, and how often?
• Where is custody ambiguous? Is there a moment when customer funds are in an account owned by a middleware provider, not a bank? Does FDIC pass-through coverage actually attach there?
• What are the failure paths? What happens to in-flight transactions if the middleware files Chapter 11? If the sponsor bank restricts volume? If the payment processor has an outage?
• What licenses does this require? Does any step in the fund transfer require a money transmitter license that your entity or a partner needs to hold?

Synctera, which provisions embedded banking infrastructure, publishes its own funds flow documentation as a starting point for fintech partners. The ChartEngine funds flow guide is a useful practitioner-facing walkthrough of the architecture elements. These exist because banks and their fintech partners routinely underestimate how many distinct stages a transaction touches.

The Eight Elements Every Diagram Must Capture

1. Entities and Their Legal Status

List every legal entity that touches customer money: the customer, your company, any intermediary (BaaS middleware, payment processor, money transmitter), the sponsor bank or issuing bank, the acquiring bank if applicable, and the ultimate counterparty. For each entity, document: legal name, jurisdiction, regulatory status (bank, money transmitter, broker-dealer, exempt?), and whether it holds funds in its own name or in trust for customers.

2. Accounts and Account Ownership

For each fund-holding point, document: the account name and number structure, the bank where the account is held, the account owner of record, the account structure (FBO, omnibus, individual accounts, custodial), and whether FDIC pass-through insurance attaches. This is where most diagrams fail—they show the money moving but not who legally holds it at each step.

3. Payment Rails and Settlement Timing

Document the specific rail for each fund transfer: ACH (next-day, same-day), wire (Fedwire, CHIPS), real-time payments (RTP, FedNow), card network (Visa/MC with specific settlement timing), internal ledger transfer, or DDA to DDA. Settlement timing matters because it determines when your risk window is open—the period between when a customer’s account is debited and when the counterparty’s account is credited.

4. Ledger Entries and Reconciliation Owners

Every movement creates a ledger entry somewhere. Document who runs the ledger at each step—your company’s general ledger, the middleware provider’s ledger, the sponsor bank’s core system—and who reconciles it, with what frequency, using what source data. The reconciliation dead zones are where operational losses live.

5. Custody Determinations and FDIC Treatment

Document whether customer funds are FDIC-insured at each step, under what structure, with what disclosure requirements. The FDIC’s 2025 custodial deposit recordkeeping NPR introduced specific requirements for FBO accounts; the Synapse bankruptcy made clear what happens when middleware ledgers can’t map customer funds to bank accounts at the account level.

6. Control Points and Control Owners

At each stage where a risk could materialize—a transaction fails, a ledger doesn’t reconcile, a counterparty defaults—document the control in place and the owner. “We’ll monitor this” is not a control. A specific person, a specific process, a specific threshold, and a specific escalation path is a control.

7. Licensing and Regulatory Touchpoints

Does any step in the money movement trigger a regulatory obligation? Money transmitter license requirements vary by state and depend on custody; some payment flows require a specific federal charter. Flag every step where legal needs to confirm whether an exemption applies or a license is required. This is not something to reconstruct after the product is live.

8. Failure Paths and Wind-Down Scenarios

For every intermediary in the diagram, document the answer to: “What happens to in-flight and at-rest customer funds if this entity fails, restricts service, or gets an enforcement action?” The Synapse bankruptcy is the canonical failure case—the middleware’s ledger couldn’t reconcile which customer was owed which dollars when it filed Chapter 11. The diagram should force the question before launch, not in front of a federal trustee.

Building the Diagram: A Step-by-Step Process

Step 1: Walk the Transaction Lifecycle, Not the Org Chart

Start from the customer action—a purchase, a deposit, a transfer initiation—and trace the money through every step until it reaches the counterparty and settles. Do not start from your org chart or your vendor contract list. The transaction is the unit of analysis.

For products with multiple transaction types (deposit, withdrawal, peer-to-peer transfer, refund), build a separate lane for each. They often share infrastructure but have different failure paths.

Step 2: Interview Engineering and Finance Together

Engineering knows the technical architecture. Finance knows the accounting entries. Risk knows neither completely. Run the diagram-building session with all three in the room. Ask engineering to walk through the API calls and the system that creates each ledger entry. Ask finance to confirm that each accounting entry is actually recorded and by whom. The gaps emerge in that conversation.

Step 3: Document Every Entity Regardless of How Small

Fintechs routinely omit middleware providers from their flow-of-funds diagrams because “it’s just infrastructure.” The Synapse bankruptcy established that middleware handling customer funds is a regulated financial intermediary with custody implications—not infrastructure. If a vendor touches customer money at any point, it goes on the diagram.

Step 4: Assign an Owner to Every Reconciliation Step

For each ledger reconciliation point, name the person responsible. If the owner is “TBD” or “the vendor,” that is a finding. Either your team reconciles it, with specific frequency and escalation procedures, or the vendor reconciles it on a contractually defined basis with audit rights in your agreement.

This maps directly to the TPRM lifecycle documentation that bank partners and examiners expect for critical third parties.

Step 5: Stress-Test the Failure Paths

For each node in the diagram, ask: “What happens to customer money if this entity is unavailable for 72 hours? For 30 days? If it files bankruptcy?” Document the answer—not the desired answer, but the honest answer based on your current contractual and operational setup. If the honest answer is “we don’t know,” that’s a critical finding the risk committee needs to see before approving the launch.

Step 6: Legal Sign-Off on Licensing and Disclosure

Have legal review the completed diagram for: money transmitter licensing requirements at each step, FDIC pass-through eligibility and disclosure adequacy, Reg E applicability (if customer-initiated electronic fund transfers are in scope), and customer disclosure accuracy (does what marketing says match the diagram?).

The Voyager Digital case is the cautionary tale—marketing said FDIC-insured, the funds flow said crypto assets held by a bankrupt estate. That gap was the FTC action, the $1.65B judgment, and a personal settlement for the CEO.

What Examiners and Bank Partners Look For

When a bank partner reviews a new product’s flow-of-funds diagram, they’re asking specific questions:

OCC Bulletin 2023-17 (the interagency third-party risk management guidance) explicitly requires banks to understand the funds flow for products delivered through third parties. For BaaS-adjacent products, the bank’s examiners will pull your flow-of-funds documentation as part of reviewing the bank’s own third-party risk management.

A clear funds flow diagram protects you in two directions: it’s evidence that your new product risk assessment was substantive, and it’s the document your bank partner uses to satisfy their own OCC obligations.

The Most Common Gaps

The middleware custody gap. Funds sit in a middleware provider’s pooled account during settlement. The diagram shows the customer’s account on one side and the destination on the other, but doesn’t document who legally holds the funds in between and whether FDIC coverage applies. This was the Synapse gap.

The reconciliation dead zone. A step in the diagram creates ledger entries on two systems—the core banking system and the middleware ledger—but no one owns the daily reconciliation between them. Discrepancies accumulate until they’re material enough to investigate.

The unlicensed step. A fund transfer step that requires a money transmitter license in seven states where the product will launch. Legal wasn’t brought in until after the diagram was “done.”

The disclosure mismatch. The diagram shows that customer funds are held in a pooled FBO account with pass-through FDIC coverage, but the customer-facing disclosure says “FDIC insured” without the pass-through qualification. Legally different. Regulators notice.

The missing failure path. The diagram documents the happy path. No one modeled what happens to in-flight transactions if the payment processor goes down for four hours, or what the customer experience is when the sponsor bank’s API is unavailable.

So What?

If you’re building a new product risk assessment without a flow-of-funds diagram, you’re assessing risks you haven’t fully described. The questionnaire, the scoring matrix, and the pre-launch checklist all assume that the operational architecture is clear enough to evaluate. The diagram is what makes it clear.

For a payments fintech, the diagram is also the artifact that your bank partner’s risk team will review before approving the program. Showing up to that review with “we’ll send you documentation later” delays launch. Showing up with a clear, owner-assigned diagram that answers the custody, licensing, and failure-path questions accelerates it—because you’ve already done the analysis the bank partner’s risk committee is going to require.

For the business impact analysis and the RCSA, the flow-of-funds diagram is the foundation. Without it, both exercises are assessing hypothetical architecture.

The diagram should exist before launch, be owned by someone, be updated when the product changes, and survive the question: “What happens to customer money if [key intermediary] is unavailable tomorrow?”

If it can’t survive that question, the product isn’t ready to launch.

The New Product Risk Assessment template includes a money/data flow mapping tab designed to capture entities, accounts, rails, settlement timing, and control ownership before launch—alongside a 58-item pre-launch checklist and four worked examples for BNPL, embedded finance, instant payments, and stablecoins.