Your Platform Holds Other People's Money. Here's What That Actually Means for ACH.

There's a version of the same realization I've watched play out dozens of times.

A company builds a platform that does something valuable — connects buyers and sellers, matches employers with workers, helps businesses manage invoices. At some point, money needs to move through the platform, not just around it. The company integrates with a bank. Payments start flowing. Everything works.

Then the questions start. Who owns the funds sitting in the account between arrival and payout? What happens when a payment fails? Who is responsible for compliance — the platform, the bank, or both?

These questions aren't academic. They determine how your business operates, what risks you carry, and what happens when something goes wrong.

The Third-Party Sender Problem

In the ACH network, there's a specific designation for companies that originate payments on behalf of other entities: third-party sender. If your platform submits ACH payments where the originator is your customer — not you — you may be operating as one, whether or not you've explicitly set up that way.

The obligations are real. Agreements with originating depository financial institutions. Risk assessments on originators. Authorization compliance. Return and dispute handling. Many platforms stumble into this role without the compliance architecture keeping pace with their payment volume.

I wrote earlier this year about what the BaaS failures revealed — that when high-profile payment programs collapsed, the root cause was almost never APIs or dashboards. It was structural: no clear ownership of compliance, no authoritative ledger, no single party accountable for money in motion. The same structural risks apply to any platform originating ACH on behalf of its users, regardless of whether they're using a BaaS model or not.

Compliance Assumptions Worth Understanding

Domestic ACH transactions have been granted specific treatment under OFAC sanctions screening. The relief was provided based on the premise that ACH is a batch system — that transactions are processed in groups and screening can happen at the batch level rather than requiring individual transaction-level matching.

That treatment was issued when ACH transactions were originated, submitted, and settled in batches. The mechanics matched the assumptions.

As APIs push origination toward single-entry patterns and platforms take on third-party sender roles, the gap between operational reality and those assumptions is worth understanding. If every ACH payment is effectively its own batch — which is increasingly how API-driven origination works — the distinction between batch and individual processing narrows.

I'm not predicting a policy change anytime soon. NACHA is rightfully focused elsewhere like first-party fraud, and most ODFIs don’t have the technology to do real-time processing or screening on a per-payment basis. But I am saying that if you're originating ACH on behalf of your users, understanding the compliance framework you operate within — including the assumptions it rests on — is part of the job.

FBO Architecture and Why Ledgering Is the Foundation

When a platform holds funds on behalf of users, those funds typically sit in a For Benefit Of (FBO) account at a bank. The bank holds the aggregate balance. The platform is responsible for the breakdown: how much belongs to each user, what's in transit, what's settled, what's been returned.

This is where ledgering becomes critical infrastructure.

Without a real-time, authoritative ledger tracking every sub-account balance and every payment in flight, the platform is operating on faith. Small discrepancies between the bank's aggregate view and the platform's user-level view compound over time. At scale, they compound quickly. There's a reason companies like Square invested heavily in ledgering early. Payments don't scale safely without it.

The right architecture gives every user a sub-account with its own ledger — balance, transaction history, a clear record of every movement. The sum of all sub-account balances ties back to the FBO balance at the bank continuously, not just at end of day. When a return arrives, the affected sub-account updates in real time. Every exception creates a cascade of ledger entries that need to be correct, traceable, and auditable — and the system handles that cascade automatically.

Exception Handling Is Where This Gets Tested

The ACH network has a low return rate overall. But for platforms processing thousands of payments on behalf of users, even a small percentage generates real volume — and real complexity.

Returns are manageable. What's harder is exception handling. A return that doesn't look right. A dishonor process your ODFI hasn't practiced frequently. A dispute about authorization that requires navigating timelines and formatting requirements most originators have never encountered.

We polled attendees at a recent webinar on what creates the most operational friction. Exception handling won decisively — not origination, not formatting, but the processes that kick in when something goes wrong.

For platforms holding third-party funds, every exception is compounded. A return isn't just your money — it's your user's money. The sub-account needs to be debited. The user needs to be notified. If the platform fronted funds, there's a receivable to track. Without infrastructure that handles this cascade systematically, your team is the infrastructure — manually updating records and chasing discrepancies.

How Modern Treasury Is Built for This

We designed the platform from the start for companies that move money on behalf of others.

Customers get sub-accounts with real-time ledgers. The platform tracks who owns every dollar, continuously, through a proprietary ledger that has processed more than $400 billion in payments. With our PSP, compliance runs within Modern Treasury's program — customers don't operate their own and don't need to negotiate direct bank sponsorship. This is the structural difference between a fully managed PSP and a BaaS model: centralized accountability versus distributed responsibility.

With stablecoin capability now native to the platform, the same sub-account infrastructure, ledgering, and compliance program extends across ACH, wire, RTP, FedNow, push-to-card, and stablecoins. One API. One ledger. One source of truth for who owns what.

The Question Worth Asking

If your platform moves money on behalf of its users: do you know the exact balance in every sub-account right now? Can you reconcile against the bank's FBO balance in real time? When a return arrives, does the affected sub-account update automatically? Is your compliance program structured for your current volume — not the volume you had at launch?

These are the questions that determine whether a platform scales safely or discovers structural problems under pressure. If you're building payments and want to understand how the infrastructure should work, we're always glad to compare notes.