The Flow of Funds: Documenting Your Payment Architecture

Flow-of-funds documentation is the connective tissue between regulatory requirements and operational reality. I've examined hundreds of flow diagrams—some clear and useful, others so obscured in technical jargon that they obscure rather than illuminate. The purpose of flow-of-funds documentation is simple: explain, in detail, how money moves through your system from entry point to exit point. Regulators, your bank, your auditors, and your own compliance team need to understand this because controls are meaningless if you can't trace where funds are actually going.

Why flow-of-funds documentation matters is not abstract. When a regulator examines your business, one of the first things they do is request a detailed, written description of how you handle money. They're looking for:

1. Whether money is actually held in trust accounts (as required by MTL) or whether you're co-mingling funds.
2. Whether you're holding customer funds as deposits or creating unsecured liabilities to customers.
3. Whether you have adequate control over funds at each stage of the flow.
4. Whether you're using third parties to hold or transmit funds and, if so, whether those third parties are adequately supervised.
5. Whether there are gaps in the flow where funds could be diverted or where you lose control.

Your bank wants flow documentation for a different reason: they're assessing whether your business presents appropriate risk given their appetite. A bank that specializes in fintech will be comfortable with a cryptocurrency-to-cash flow involving multiple technology providers. A traditional bank will be uncomfortable with anything more complex than a simple domestic remittance flow. A bank that has been burned by a customer using their accounts for sanctions evasion will scrutinize your flows obsessively.

Your auditors want flow documentation because it allows them to sample transactions at each stage and confirm that actual flows match documented flows. If you document a flow and actual operations differ, that's an audit finding.

A simple domestic flow looks like this: Customer A walks into your retail location, hands you $500 in cash, and tells you to send it to Customer B at an address in a different state. You record the transaction in your system, capturing customer identification, transaction details, and beneficiary information. You run both customers through OFAC screening. You hold the $500 in a trust account at your bank. You instruct your bank to transfer $485 (minus your $15 fee) to a settlement bank where Customer B retrieves it. The settlement bank is another financial institution that you have a contract with, and they're responsible for getting the funds to Customer B.

The documentation for this flow would show:

Entry Point: In-person cash. Customer identity verified. Purpose captured in transaction notes.

Processing: OFAC screening, customer record creation, transaction authorization, fee calculation.

Holding: Funds held in segregated trust account at Bank A.

Transfer: Instruction to Bank A to move $485 to settlement agreement with Bank B.

Exit Point: Customer B retrieves funds at Bank B location or through Bank B ATM.

Documentation Trail: Receipt issued to Customer A, transaction record maintained, bank statements reconcile, audit trail available.

A cross-border flow is more complex. Let's say you're sending remittance from a customer in the US to a beneficiary in Mexico. The basic flow is similar, but now you have regulatory obligations in Mexico as well. Your documentation needs to show:

Entry Point: Customer identity verified in US (FCRA-compliant ID check, AML compliance, OFAC screening).

Compliance Checks: US OFAC screening, FATF recommendations compliance, Mexico's OFAC equivalent (ACUS list), Mexico's customer identification requirements.

Holding: Funds held in segregated account in US.

Correspondent Arrangement: You have a correspondent bank in Mexico or a relationship with another remittance provider that serves Mexico. You're relying on them to deliver funds to the beneficiary.

Beneficiary Documentation: You collect information about the Mexican beneficiary (name, ID type, ID number, address) meeting FATF standards for cross-border remittance. This is mandatory under SWIFT's standard for cross-border payments.

Exit Point: Mexican correspondent delivers funds to beneficiary, confirms receipt.

Reporting: Your correspondent provides you a completion report. You retain documentation of the complete chain.

The critical issue in cross-border flows is knowing who bears responsibility at each stage. If your Mexican correspondent fails to deliver funds, who is responsible to the customer? Typically, you are—you're the regulated entity in the US. Your correspondent is your agent, even if they're another financial institution. So your flow documentation needs to show:

1. Who your correspondent is and what their regulatory status is.
2. What agreements govern the correspondent relationship (what do they do, what are they responsible for, what happens if they fail).
3. How you monitor your correspondent to ensure they're compliant.
4. How you handle disputes and failed transactions.
5. How often you audit the correspondent relationship.

Multi-party flows involve even more complexity. I worked on a remittance platform that used this flow: customer in the US sends money through a mobile app, the app routes the transaction to a payment processor, the payment processor routes it to a settlement bank, the settlement bank routes it to a correspondent in the receiving country, and the correspondent uses its own agent network to deliver funds to the beneficiary. That's five separate entities touching the transaction. The flow documentation had to show the role of each party, the contractual obligations between parties, the points where you (the licensed operator) retain control and responsibility, and the audit trails that allow you to track a specific transaction through all five stages.

Technology-driven flows present particular challenges because they move at machine speed. An API-based flow might involve a thousand transactions daily, each routing through multiple servers, payment networks, and settlement systems. You can't document the individual flow of each transaction the way you would a manual remittance. Instead, you document the system flow: Here's how the API works. Here's where data is validated. Here's how we screen customers. Here's how we move funds. Here's our audit log. Here's how we verify settlement. Here's how we handle failures and reversals. The documentation is the same in concept but higher level in execution.

Real-time payment flows are becoming standard, and they create documentation challenges. When you use the Federal Reserve's RTP system or FedNow, funds settle in real time, sometimes in seconds. Your documentation needs to show how you handle the compressed timeline for compliance. If you can't run OFAC screening in real time, how do you manage that? Some operators pre-screen customers so that authorized users clear OFAC before they're allowed to transact. Others screen after the transaction settles and halt further transactions if a screen hits. Your flow documentation explains your approach.

Common mistakes in flow documentation I see repeatedly:

1. Vague third-party documentation. "We use payment processor X." That's not documentation. You need: the name of payment processor X, what they do, their regulatory status (if any), what contracts govern the relationship, how you monitor them, and how you handle failures.

2. Inconsistency between documented and actual flows. You document a flow, but when I audit your transactions, they follow a different path. This happens because flows change over time—you add a new bank, you add a new corridor, you implement new technology—but the documentation doesn't get updated. Every change in your flow requires an updated flow diagram.

3. Missing control points. You show money moving from A to B to C, but you don't explain how you ensure it's the right amount, that it's not co-mingled with other customers' funds, or that it's actually delivered to the intended recipient.

4. Unclear responsibility for compliance obligations. If you use an agent, do they perform OFAC screening or do you? If they do, how do you verify they did it correctly? If you do it, how do you do it for transactions the agent initiated before you had data?

5. Insufficient documentation of correspondent relationships. This is a perennial problem. You have a correspondent in a foreign country, but your documentation of that relationship consists of a two-page contract signed five years ago. You don't have recent compliance certifications, you haven't visited them, and you don't know their current AML procedures. This is dangerous.

Templates and frameworks for flow documentation:

Domestic Flow Template: - Entry point (channel: branch, ATM, online, mobile app, agent) - Customer identity verification method - Compliance screening (OFAC, AML) - Amount and fee - Holding mechanism (account number, bank, segregation confirmation) - Transmission method (ACH, wire, real-time payment, cash delivery) - Settlement timing (same-day, next-day, T+1, etc.) - Exit point and beneficiary identification - Confirmation and audit trail

Cross-Border Flow Template: - Entry point with comprehensive customer identification - Sending country compliance requirements (US: OFAC, AML, FCRA) - Receiving country compliance requirements (OFAC equivalent, beneficiary ID standards) - Correspondent or partner identification and regulatory status - Agreement terms with correspondent - Holding account structure - Transmission method - Beneficiary identification and verification (passport, national ID) - Purpose-of-transfer capture - Correspondent delivery confirmation - Your verification of delivery to customer - Dispute handling procedure - Documentation retention period

Agent Model Flow Template: - Agent recruitment and due diligence - Agent training and ongoing monitoring - Customer identification: performed by agent or by you - Compliance screening: performed by agent or by you - Funds handling: does agent collect cash and hold it, or does agent collect cash and transmit immediately - Settlement between you and agent (daily, weekly, monthly) - Agent's compliance obligations and your verification - Audit sampling procedure - Termination procedures

For a real-world scenario, I worked with a remittance startup based in California that was expanding from a single location to a network of thirty agents across the southwestern US. Their initial flow was simple: customer walks in, gives cash, provides beneficiary info, pays fee, transaction goes into a mobile app, headquarters processes it, and funds are delivered through an established remittance provider in Mexico.

As they added agents, everything became more complicated. Agents were independent contractors. Some agents wanted to hold customer funds overnight before transmitting them to headquarters. Others wanted to do same-day transmission. Some agents had their own customer databases. Others wanted to use the company's app. The compliance issue was fundamental: the company was licensed in California, and they bore ultimate responsibility for every transaction. But if agents in Arizona and New Mexico were operating differently, the company couldn't guarantee that OFAC screening was happening consistently, or that customer funds weren't being co-mingled, or that transaction records were accurate.

We rebuilt their flow documentation to be agent-centric. Here's how agents are recruited. Here's how we verify they're not on sanctions lists. Here's the required training. Here's the documented procedure each agent must follow. Here's how agents transmit funds to us—we specified that agents must transmit all customer funds electronically within 24 hours; we don't allow agents to hold cash overnight. Here's how we perform OFAC screening (we centralize it—agents collect customer information but we run all screenings at headquarters). Here's how we audit agents (monthly review of transaction records, quarterly in-person visits, annual comprehensive audit). Here's what happens if an agent doesn't comply (warning, retraining, then termination).

The company went from having agents operating in five different ways to having a single, documented, repeatable flow. Onboarding new agents became faster because there was a clear playbook. Compliance monitoring became easier because variation was eliminated. Their bank, which had been nervous about the expansion, became comfortable because they could see a coherent, documented system.

Practitioner's Bottom Line: Flow-of-funds documentation is not a compliance checkbox—it's your system's blueprint. Clear documentation allows you to identify gaps, allows regulators and banks to understand your controls, and allows your team to execute consistently. If you can't document how money flows through your system, you don't actually understand your system. Update flow documentation whenever your operation changes, not annually or when you remember. The best time to validate your flow is before you have a transaction that goes wrong.

---