Seven Years and $400 Billion: What Payments Look Like at Scale

Modern Treasury has been moving money since 2018. In that time, we've processed over $400 billion in payments across ACH, wire, RTP, FedNow, and other rails — for hundreds of customers and dozens of bank partners.

ACH accounts for the largest share of that volume for most of our customers. It's the rail where patterns emerge first, edge cases accumulate fastest, and operational maturity gets tested most consistently. I've been involved in most of the hard moments: debugging raw NACHA file output at 11 PM, tracing reconciliation mismatches across an entire bank connection, encountering return codes I'd never seen before, and digging through the operating rules to figure out if they were even valid. This is a collection of what we've learned. The patterns that only become visible at volume.

Banks Change Things Without Telling You

This is probably the single biggest operational lesson from seven years of doing this. Banks change behavior — file formatting, cutoff times, statement reporting, return code handling — and they often don't tell you in advance. Sometimes they don't tell you at all.

We've had banks change the structure of their BAI2 files without notice. Fields that were populated start coming back empty. Timestamps shift formats. The file is still technically valid, but our parsing logic was built around the previous structure. At our scale, a BAI2 parsing issue doesn't affect one customer; it affects every customer on that bank connection. We've had banks change their ACH cutoff times with a few days' notice buried in an operations bulletin nobody was monitoring.

The lesson: if you're building on top of banks, your system has to be defensive by default. You can't assume stability. You have to monitor, detect, and adapt — ideally before your customers notice.

Reconciliation Is the Whole Game

When people evaluate payments infrastructure, they focus on origination. Can I send an ACH credit? How fast does the API respond? Those matter. But the thing that actually determines whether a payment operation works at scale is reconciliation — can you, at any point in time, account for every dollar?

This sounds simple until you're doing it across multiple bank partners, each with their own reporting formats, timing, and quirks. One bank settles and reports same-day. Another reports the next morning. A third aggregates by batch. Our system matches every statement line item back to the originated payment, flags discrepancies, and surfaces exceptions — flexible enough to handle a bank that reports a 50-payment batch as one line item and another that reports the same batch as 50 individual entries.

Reconciliation isn't a feature you add after launch. It's the system of record. If you get origination right but reconciliation wrong, you'll be able to send money, but you won't know where it went.

The Return Code You've Never Seen Will Find You

Most origination platforms handle the common return codes competently — R01 for insufficient funds, R02 for account closed. Then you get an R17 or an R31, which was introduced relatively recently for the return of a dishonored return. At scale, they show up. And when they do, the question is whether your system handles them gracefully or creates manual work.

We polled attendees at a recent webinar on what creates the most operational friction. Exception handling won decisively — returns, dishonors, contested transactions. Not origination, not formatting. The stuff that takes the most time and exposes the most risk. My advice: read the full return code table before you need it, not after.

Same-Day ACH Changed Behavior in Ways Nobody Predicted

Same-day ACH now handles 1.4 billion payments a year worth $3.9 trillion, growing over 21% annually. What's most interesting isn't the volume — it's how it changed origination behavior.

Before same-day, there was a natural cadence. Payments settled the next morning, and processing was spread out. Same-day introduced the ability to time payments to specific windows, and what followed was a concentration effect. Rather than spreading payments throughout the day, companies started targeting the latest possible window. Processing load that used to be distributed started compressing into tight windows — leaving almost no buffer if something goes wrong.

We help customers understand the trade-offs. Sometimes the second-to-last window is better because it provides a safety margin. The right infrastructure gives you the ability to choose rather than defaulting to whatever window your bank exposes.

Payments Is a Burden You Don't Have to Carry

The companies that run the best payments operations assume things will break and build accordingly. They check balances before originating, monitor for returns proactively, and have runbooks for edge cases.

That burden exists because banks aren't static. File formats shift. Return codes get interpreted differently. Undocumented limits get enforced. If you've built your own payments infrastructure, you own all of that drift — and most teams underestimate it until something breaks.

The companies that get into trouble treat payments as a solved problem. They integrate, it works, they move on. Then six months later, a bank changes behavior or a reconciliation discrepancy emerges — and they don't have the operational muscle to respond.

Modern Treasury exists because of this asymmetry. We absorb the burden so our customers don't have to. Integrate once, and never worry about this again.

What the Next Seven Years Look Like

The ACH network processed 35.2 billion transactions for $93 trillion last year. Real-time rails like RTP and FedNow are adding volume. Stablecoins are introducing new settlement patterns. The surface area of what "payments infrastructure" means is expanding in every direction.

The fundamentals haven't changed — files, batches, settlement, returns. But the operational demands have increased, and the infrastructure that managed $1 billion in annual volume might not manage $10 billion without significant investment.

That's the bet we've been making for seven years: that the gap between "I can send a payment" and "I can operate payments at scale" is wide, persistent, and worth building for. Four hundred billion dollars later, I'm more convinced of that than when we started.