10/17/2025 The Real-Time Payments (RTP) network is pretty cool to work with if you’re a power user of other bank transfer rails in the US - ACH, wire, check - ie. you’re someone whose use case is not solved by eg. Venmo or Zelle. Instant, 24/7, and final[\*](https://www.bitsaboutmoney.com/archive/no-payments-are-final/) are novel when you’re making or receiving B2B payments, or managing corporate treasury—especially if you’re running financial machinery that sometimes needs ad-hoc intervention over a weekend or overnight. Really, in any instance where speed and flexibility are operational benefits. But there are asterisks and surprises once you start moving many millions of dollars through the network (eg. as a fintech) that you wouldn’t anticipate (at least as an engineer) until you stand up serious volumes. (I’ll get to both FedNow and USDC — newer rails with lower volumes — after walking through real constraints I’ve observed with RTP at scale) ## Weekends are (still) hard 24/7 is part of the “point” of an RTP rail, so the big surprise is finding out that RTP capacity at your or your counterparty’s bank can be “different” (read: lower) on the weekend, than on the weekday. Computers don’t need weekends off. Twitter is 24/7; Twitter on Saturday is as active (or more) as on Monday, and the day of the week has no mechanical bearing. Surely, the way you’re making 24/7 payments work is internal ledgers and computers all the way down. RTP is closer to “sure, we can squeeze some in on the weekends, but let’s talk.” This is a byproduct of what is *actually* happening under the hood. Your bank has a pre-funded position at The Clearing House (TCH). When you send an RTP: - Your bank debits your account - TCH debits your bank’s pre-funded position - TCH credits the receiving bank’s pre-funded position - The receiving bank credits your counterparty - **Crucially**: if and when your bank's pre-funded position falls below a threshold, it “tops up” its position at TCH **via Fedwire**, to maintain funding for subsequent RTPs But the bank can’t send Fedwire on the weekend, meaning it can’t do those top-ups, so it must pre-fund its position to cover the entire weekend’s activity. There’s a cost of capital and a need to project accurately. How this manifests for you as a “power user” of this rail ranges from handshake, contracts, and/or API guardrails to keep aggregate transaction volumes below a certain amount, and/or otherwise risk their failure or stalling — with different size limits than what you’d experience during the week. If you spend down the bank’s pre-funded position over the weekend, it can’t top it up—and therefore can’t fulfill further weekend volume. In the case of banks that *receive* more RTP than they send, you’d think this is “easier,” or not a problem; they shouldn’t run out of pre-funding over the weekend. And yet in practice, you’ll (I) find that banks also cap how much they’re willing to *receive* over the weekend. Why? I don’t have as direct a connection to any “net *receivers*” — but based on some digging & speculation — receiving money comes with its own burden that is also hard to manage on the weekend. (It is not speculative that they have weekend caps on inbound RTP - I’ve seen it firsthand — it’s speculative for *me* *why* they do). A simple reason might be that inbound funds still involve manual fraud, risk, or compliance work. There may be legal reasons to cooperate with the originator to move funds back (e.g., in fraud cases), which are time-sensitive, and you’re probably not staffed over the weekend to handle those at weekday capacity. Also, for the same reasons a net sender might have a pre-funding shortfall over the weekend - as a net receiver, you can’t rebalance *out* of your position flexibly over the weeknd *either*. This tactically matters because: - You’re still expected to credit to the receiver on your end - You can’t move into Fed funds / treasuries / etc until Monday - but you might still owe depositors weekend yield - “Liquidity Coverage Ratio”: - Funds in your TCH position aren’t “high-quality liquid assets”, but as customer deposits, they’re simultaneously considered “potential outflows” (your depositor could send them out, eg. via RTP, whenever) - The ratio between “liquid assets” / “potential outflows” (to simplify LCR) is something banks report on and have to “manage.” Weekend RTP inflows worsen it, by increasing the denominator without increasing the numerator. It’s an operational burden to unwind / prevent this going wrong. The bottom line is that since this isn’t pure internal ledgering and software, weekends don’t always work as well with scale and variability, and that RTP is a differently-abled rail on the weekend relative to weekdays. This was at least a surprise to me, as a developer who expected 24/7 to resemble the sorts of “24/7” products I’m used to in software. I’ve seen a surprising number of (external) incidents and gaps in capacity, across both small and large banks, for a rail that sounds so purely computer magic at first. ## Bursts The same mechanical constraints that make weekends harder also cause the network to creak under certain weekday behaviors. If the bank has $X in its pre-funded position at TCH, and you attempt to send RTPs totaling more than $X all at once—not all of that can go out in real time. Depending on the bank’s guardrails, some portion will stall or fail outright. You might be able to process 10X or 100X in the span of a single day, but it has to be spread out in a way that allows the bank to top-up in between. It also helps if the bank receives enough RTPs (credited by TCH) to offset what it’s sending. Again, maybe obvious to people who know money movement really well, but to an engineer looking at an “instant” rail, not so obvious that you’d need to pace yourself for any reason other than eg. API rate limits. ## FedNow The good news (at least as far as I’ve heard) is that FedNow, the Federal Reserve’s *own* real-time payment rail, has far fewer of these problems. The gist of why, is that your “position” with TCH for RTP is less liquid and less flexible relative to the rest of your stack — it’s sort of stranded (both in terms of your ability to move funds in and out). Your equivalent “position” with FedNow is just your Fed Master Account (where all your other balances are sitting). Tactically: - Your funds are more flexible, even on weekends. FedNow includes special “Liquidity Management Transfers” that let banks move reserves between master accounts **even when Fedwire is closed**. - Those balances are considered high-quality liquid assets. So funds aren’t stranded, and I’d expect fewer bank-imposed limits on either end. However, of note: - The FedNow limit is $1 million, while RTP’s is $10 million. - The Fed intends FedNow as a retail payments solution, not a replacement for wires (CHIPS/Fedwire). It’s not really meant for large-scale B2B or corporate treasury flows—RTP is more oriented that way. From what I’ve read and heard, it’s a public vs. private dynamic: the public option biases toward retail and inclusion. In theory, competition from a rail directly tied into Fed Master Accounts should smooth out these issues as real-time payments gain adoption—we’ll see. It seems to have worked in Brazil and India. ## USDC From one angle, USDC is closer to the *actual*, computerized 24/7 experience I made mention of earlier. If I send you USDC, you receive it instantly, and weekday vs. weekend actually does *not* matter, because it really is some bits flipping on computers. But of course - this isn’t a US dollar, a bank deposit - it’s a liability of Circle backed by dollars. It’s closer to an open-source Venmo than it is a real big-B “bank transfer” rail. Whether this is a durable advantage relative to domestic RTP rails, I wouldn't know (my sense from the banking community is “nope, not even in the same league” and “only cross-border, and only in transit”) — but the following still bring it into the conversation for me: - I see it being taken seriously as a matter of cross-border / global corporate treasury and B2B payments. I see this happening with serious banking people who don’t otherwise give a shit about crypto. - It’s pretty easy to integrate with. You can start moving fiat globally and use USDC as the “L2” on which the money crosses borders pretty easily relatively to the status quo before it. - This is both useful and increasingly accessible, today, as a global inter-company money movement solution. The cliche but real example people offer is SpaceX doing corporate treasury globally via USDC. - There is less going on under the hood than there is with RTP. Anecdotally (and maybe this is a function of volumes and time), RTP screws up far more frequently at both the sending or receiving end than I’ve seen USDC screw up. Lots of human and legacy system stuff constraining RTPs that doesn’t really constrain USDC, and USDC is a more “open” loop in some ways. I say all of that to say - I wonder if, as a (hypothetical) corporate treasurer, with both tools in my stack and real experience using them, do I still only use USDC for cross-border transit, or is there I chance I use it for domestic *too*, “just because I can, and it works”. I should also mention - Bridge (and others) now see the future as less USDC-centric, and more “everyone has a custom stablecoin but this is more of an implementation detail on the backend than a user-facing thing” (I’ve written about why here: [[Why you'd issue a branded stablecoin like McDonaldsCoin]]). If you ask enough questions in that world, you find that you’re actually constrained on weekends yet again, even when you think you’re fully on-chain, if you eg. want to convert your on-platform stable to a counterparty’s preferred stable (eg. USDC). Your stable needs to be burned, its reserves (backed in part by MMF) may or may not be instantly liquid in the size you care about, and it can only be converted to eg. USDC after that liquidation. Even stablecoins might take the weekend off on occasion!