Key takeaways

• Real-time payments are moving from a nice-to-have to an expectation.
• FedNow and RTP are two separate instant-payment rails, and many institutions will use both.
• FedNow adoption has grown quickly since launch, but most credit unions are still deciding.
• The first decision is receive-only versus send-and-receive.

Real-time payments let money move between accounts in seconds, any time, and they are quickly becoming the baseline members expect. Two rails matter in the U.S. The Federal Reserve's FedNow Service launched in 2023 and has grown to roughly 1,600 participating financial institutions, with transaction volume up more than 460% year over year in early 2025 (Federal Reserve, FedNow). The Clearing House's RTP network now reaches more than 1,260 participating institutions and has cleared over $1.4 trillion since launching in 2017 (The Clearing House). Yet only about 38% of credit unions currently offer real-time payments (Cornerstone Advisors, 2025), which means most are still deciding how to move.

FedNow and RTP are not the same thing

It is easy to treat instant payments as one thing, but FedNow and RTP are separate networks. FedNow is operated by the Federal Reserve. RTP is operated by The Clearing House. They do not interoperate today, so reaching the most counterparties often means connecting to both over time. For most credit unions the practical question is not which one is better in the abstract, but which reaches the people your members actually pay and get paid by.

Receive first, then send

The most useful early decision is receive-only versus send-and-receive. Receiving instant payments is lower risk and lets members get money faster right away, from payroll, from another person, from a business. Sending introduces more to manage, including fraud controls and operational readiness, because an instant payment is final and cannot be clawed back the way some other payments can. Many credit unions start by receiving and add send once the controls are in place.

Why finality changes the risk picture

Speed and finality are the point of these rails, and they are also the risk. When a payment settles in seconds and cannot be reversed, fraud has to be stopped before the payment goes out, not after. That puts more weight on real-time monitoring, limits, and member verification. It is manageable, and thousands of institutions are doing it, but it is a real change from the slower rails credit unions are used to. See payments security basics.

What it takes to connect

Connecting to a real-time rail touches your core, your fraud tools, and your operations. The cleanest path is a core and payments platform that already supports the rails, so connecting is configuration rather than a custom project. The harder path is bolting real-time payments onto a system that was never designed for them. This is one more place where the underlying platform decides how hard the next step is. See what credit unions should know about cloud-native cores.

Have a use case, not just a connection

The mistake some institutions make is treating real-time payments as a box to check, turning on a rail without a clear idea of what members will do with it. The credit unions that get value start from a use case. Faster payroll access for members who live close to the edge. Instant transfers between a member's accounts. Quicker funds for a small business that cannot wait days to get paid. Real-time loan disbursements. Starting from a concrete member need keeps the project focused and makes it obvious how to talk about the new capability once it is live.

Build the fraud controls before you turn on send

Because a sent instant payment is final, the fraud controls have to be ready before you enable sending, not added after the first loss. That means real-time transaction monitoring, sensible sending limits that can tighten when something looks off, strong member verification, and clear confirmation steps for new payees. It also means preparing for scams where the member is tricked into sending money themselves, which is a growing share of real-time payment fraud. None of this should stop a credit union from offering instant payments. It should simply come first, so speed never outruns safety.

Sequence the rollout

A sensible rollout has a clear order. Start by receiving on the rail that reaches the most of your members' counterparties. Prove the operations and monitoring work. Add sending for a limited set of use cases with conservative limits, watch closely, then widen as confidence grows. Communicate each step to members so they know the capability exists. This phased path captures the member benefit early while keeping the riskier parts controlled, which is exactly the balance real-time payments require. It also spreads the operational load rather than turning everything on at once.

Tell members what changed

A new capability that members do not know about earns nothing. When instant payments go live, say so plainly, in the app and in the moments where speed matters. Members who learn that money can now arrive in seconds use the feature more, and they give the credit union credit for keeping up. Quietly enabling a rail and hoping people notice wastes the work. A little clear communication turns a back-office upgrade into something members actually feel, which is the point of doing it.

The cost of waiting

Members increasingly expect money to move now. As more people experience instant payments elsewhere, slow transfers start to feel like a flaw. Credit unions do not need to do everything at once, but they do need a plan. The institutions deciding now will be ready when members ask, while the ones waiting will be explaining why money still takes days.