That progression matters as transaction volumes rise. FedNow® processed almost five million settled payments in Q2 2026, an 83.2% increase from the previous quarter, while the RTP® network set a single-day record of 2.27 million transactions on May 1, 2026. For banks, the next question is increasingly how to network access into a send-side confidence, broader customer use cases, and a scalable instant payments proposition.
Key takeaways
- Receive-only can be an effective starting point, while send capability opens a broader range of consumer and commercial instant payment use cases.
- Moving to send requires banks to address real-time validation, fraud controls, liquidity, and operational readiness before a payment is released.
- Supporting both FedNow and RTP can increase reach and give institutions more flexibility to orchestrate and route payments according to defined business requirements. ISO 20022-native processing, APIs, and orchestration can help banks integrate instant payments with existing infrastructure while modernizing progressively rather than creating another payments silo.
- Request for payment and richer messaging create opportunities to build services around the payment itself.
- The value of send capability depends on the use cases behind it, so banks should prioritize the customer and commercial needs that justify 24/7 origination.
Why do banks often enable receive before send on FedNow and RTP?
Receive-only offers a practical entry point into instant payments. The Federal Reserve’s FedNow operating procedures distinguish between “Credit Transfer Receive Only” and “Credit Transfer Send and Receive” participation. The Clearing House similarly notes that financial institutions can join RTP as receive-only, allowing them to accept incoming payments without originating outgoing transactions.
This can give operations teams time to become familiar with always-on processing, reporting, reconciliation, customer servicing, and exception management while building the controls, funding strategies, and operational confidence needed to originate payments at scale. ABNB Federal Credit Union, for example, initially joined RTP as receive-only in May 2024 before expanding to send. Randolph-Brooks Federal Credit Union has also described dividing its implementation into receive-only and send phases to help manage risk and build its business case.
The case for progressing further is becoming more relevant as usage grows. FedNow processed almost five million settled payments in Q2 2026, up 83.2% quarter over quarter. The RTP network, meanwhile, processed a record 2.27 million transactions on May 1, 2026.
For institutions evaluating that next step, Volante’s US Instant Payments, FedNow & RTP resource outlines how modern instant payment infrastructure can support 24x7x365 operations while integrating with existing banking systems.
Receive-only vs. send-enabled: What changes?
The fundamental distinction is straightforward, but it has important implications for the services a bank can offer.
| Capability | Receive-only | Send and receive |
| Receiving incoming credit transfers | Yes | Yes |
| Originate outgoing credit transfers | No | Yes |
| Support outbound instant payment use cases | No | Yes |
| Originate supported payment messages | No | Yes, subject to network and participation type |
Source: Federal Reserve FedNow Service Operating Procedures and The Clearing House RTP network information.
The difference extends well beyond adding an outbound payment option. Send enablement changes the risk, liquidity, decisioning, and operational requirements surrounding the transaction. Instant payments operate continuously, and settlement can be final within seconds. On the RTP network, for example, settlement is final and irrevocable once a payment has been submitted, although the network provides messaging to request the return of funds.
For a sending institution, payment initiation therefore needs to be orchestrated with the processes that determine whether, when and how a transaction should proceed, including customer authentication, recipient validation, fraud and sanctions screening, transaction limits, and liquidity checks.
What can banks unlock by enabling send?
Receiving instant payments gives customers faster access to incoming funds. Sending allows banks to move beyond basic connectivity and build a broader range of commercial services around real-time money movement.
The Clearing House identifies use cases ranging from consumer payments to cash concentration, portfolio rebalancing, and large supplier or vendor payments. Request for Payment can add another layer, allowing a biller or other party to send a structured request that can lead to an instant account-to-account payment.
For banks serving businesses, send capabilities can support real-time liquidity management, faster invoice settlement, payroll, supplier payments, and treasury movements. These use cases can help corporate customers manage cash positions more dynamically, while giving banks opportunities to expand the services they provide around the payment itself. For consumers, instant account-to-account payments can provide greater control over when money leaves one account and reaches another.
Supporting more than one instant payment network can also create additional flexibility, but the greater value comes from orchestrating those networks as part of a broader, multi-rail payments strategy. Volante’s Real-time payments revolution article explores how institutions can connect to both RTP and FedNow, using APIs and low-code integration to support dual-network connectivity and smarter routing.
That makes the strategic question broader than whether a bank can send. Institutions also need to consider which rail should carry a transaction, which business rules and conditions inform that decision, and how they can deliver a consistent customer experience across payment systems.
Why does sending require stronger real-time controls?
An institution receiving a payment has a different risk profile from one authorizing and originating it. Once a bank enables send, risk, routing, liquidity, and operational decisions must happen or as the payment moves, at instant-payment speed.
Authentication, recipient validation, fraud monitoring, sanctions screening, transaction limits, and liquidity checks need to happen quickly enough to preserve the speed of the payment while applying the institution’s controls. An always-on service also requires visibility into available liquidity outside traditional banking hours.
This is where the surrounding payments architecture becomes particularly important. Volante’s AI-powered Payments Platform combines multi-rail orchestration and ISO 20022-native processing with embedded validation, liquidity-aware routing, and fraud and sanctions integration to support send enablement. Its Payments as a Service model provides managed payment processing designed for always-on environments, including real-time payment systems.
AI can also support parts of the operating environment. Volante’s Vol360i agentic AI framework applies confidence-based automation to areas including exception handling, routing, and SLA monitoring, with human oversight, policy controls, and traceability. These capabilities can support operational decision-making around payments, while fraud, compliance, authentication, and other controls remain part of the institution’s wider risk framework.
Why does send-side capability depend on modern payment infrastructure?
Instant payments place pressure on systems built around cut-off times, overnight processing, and manual intervention. When transactions can arrive or leave at any time, the surrounding infrastructure needs to support continuous processing as well.
Orchestration can provide a common decisioning and processing layer across that environment. Rather than building separate workflows around every network, institutions can apply common business rules and connect payment initiation with the appropriate processing path. This becomes particularly useful when a bank supports FedNow and RTP alongside ACH, wire, and other payment types.
APIs can also help connect instant payment services with existing core systems, allowing institutions to introduce new capabilities progressively without requiring immediate replacement of the existing payments environment. Volante’s Embedded Preprocessing solution, for example, is designed to sit between existing systems and newer payment capabilities, supporting functions such as validation, enrichment, intelligent routing, and compliance before transactions reach the core.
For institutions with limited internal payments engineering resources, the infrastructure question can be particularly important. Cloud-based, scalable platforms can provide a route to expanding real-time payment capabilities while managing the cost and complexity of modernization. Flexible infrastructure can also allow institutions to introduce new services progressively as customer demand develops.
The objective is a unified payments environment that can make decisions continuously while maintaining consistent controls across instant, ACH, wire, and other payment types. Volante’s FedNow vs. RTP discussion explores the considerations around supporting the two US instant payment networks, including use cases, fraud prevention, and interoperability.
This approach can support phased modernization. Lakeside Bank, for example, selected Volante’s Payments as a Service to implement end-to-end real-time payments across RTP and FedNow while enhancing its SWIFT processing. The example shows how instant payments can form part of a broader payments modernization program while existing infrastructure evolves over time.
Are you using FedNow and RTP to their full potential?
For banks that already receive instant payments, the next stage starts with assessing whether there is a strong use case for origination, and whether the operating model is ready to support it.
A useful self-assessment includes:
- Can customers originate instant payments as well as receive them?
- Can fraud, sanctions, authentication, and recipient validation operate in real time?
- Can liquidity be monitored and managed outside traditional banking hours?
- Can payments be intelligently orchestrated and routed across FedNow, RTP, and other appropriate rails according to defined business rules?
- Can posting, reconciliation, customer servicing, and exception handling continuously?
- Are there clearly defined customer or commercial use cases that justify send enablement?
A “no” does not necessarily mean an institution should delay its instant payments strategy. Instead, the answers can help identify where controls, integration, infrastructure, or operating-model changes are needed before expanding send capabilities.
An API-driven or Payments as a Service model can allow new capabilities to connect with existing cores, while orchestration can provide consistent rules across multiple payment systems. The experiences of institutions such as ABNB and Randolph-Brooks also demonstrate how receive-only can form part of a phased strategy, allowing banks to build operational experience before expanding their proposition.
Frequently asked questions
Is sending an instant payment riskier than receiving one?
Sending introduces additional responsibilities because the institution must decide whether to authorize and release the payment before it is settled. On the RTP network, submitted payments are final and irrevocable, although a return request message is available. Banks therefore need layered authentication, validation, fraud, compliance, and transaction controls that can operate at real-time speed.
Does a bank have to enable send to participate in instant payments?
No. Both FedNow and RTP support forms of receive-only participation. This can provide a practical starting point for institutions that want to build experience with instant payments before originating transactions.
Do banks need both FedNow and RTP?
There is no single model for every institution. The decision depends on customer needs, reach, use cases, existing connectivity, and the bank’s wider payment strategy. Supporting both can provide additional flexibility, particularly when infrastructure can determine the appropriate network according to defined business rules.
What does send-side capability require technically?
Banks need more than network connectivity. Send-side capability requires an always-on payments environment than can coordinate payment initiation, validation, fraud and sanctions controls, liquidity management, routing, posting, reconciliation, reporting, and exception handling at real-time speed. APIs and orchestration can help integrate these functions with existing banking systems.
What is Request for Payment?
Request for Payment is a messaging capability that allows a party to request payment from another party. It can support use cases such as bill payment and invoicing by linking a structured request with an instant payment flow. Availability and requirements vary according to the network and participation type.
Can legacy systems support instant payments?
They can remain part of the architecture, provided the institution can integrate them with the continuous processing, messaging, validation, routing and controls required for instant payments. Modernization can therefore take place in phases rather than requiring immediate replacement of the core environment.
Rail-agnostic launch is not a promise about future roadmap capability. It reflects what the estate does today when the underlying architecture supports it. Weeks-to-launch is a measurable outcome, not slideware describing eventual capability. The payment orchestration layer benefits stack when the estate operates at Level 4.
From instant payment access to instant payment utilization
Receive-only participation can provide financial institutions with a manageable route into the US instant payments market. But connectivity is only the starting point. The greater opportunity lies in activating connectivity through send capabilities, intelligent orchestration, and real customer and commercial use cases. As FedNow and RTP usage grows, the opportunity increasingly lies in how banks build on that connectivity.
Send capability can broaden customer use cases, enable richer payment experiences, and give institutions more flexibility across instant payment networks. Realizing those benefits depends on the infrastructure around the transaction, including real-time controls, liquidity visibility, orchestration, resilient processing, and an operating model designed for continuous availability.
For institutions already connected to FedNow or RTP, the next question is practical: which send-side use cases matter to their customers, and do they have orchestration, controls, liquidity visibility, and operating model to support them at scale?
