A FedNow Request for Payment is not a debit and it does not move money by itself. It is a structured request that reaches the payer’s financial institution before any instant payment is sent.

That distinction matters to product teams, billers and customers. A polished request screen can look like a payment is already under way, but the value transfer begins only after the payer accepts and the financial institution sends a separate customer credit transfer.

The short version

FedNow uses the ISO 20022 pain.013 message for a Request for Payment, usually shortened to RFP. A participant can send one for itself or for an end customer, such as a biller asking a customer to pay an invoice.

The receiving financial institution needs the FedNow participation type and product capability required to receive the request and present it to its customer. If the customer accepts, the payer’s institution then originates a separate pacs.008 Customer Credit Transfer.

The request and the payment are therefore related, but they are not the same message or the same action.

What happens before the transfer

A typical flow has five practical stages.

  1. A biller or other requester creates a payment request through its financial institution or service provider.
  2. The sender’s institution packages the request as a pain.013 message and sends it through FedNow.
  3. The receiver’s institution validates the message and presents the request in its own app, portal or other customer channel.
  4. The customer reviews the payee, amount, due date and reference, then accepts or rejects the request.
  5. On acceptance, the payer’s institution creates and sends a separate pacs.008 credit transfer.

The last step is the one that moves value. An RFP can be delivered, presented or accepted without being a completed payment. Systems that report status should keep those states separate so a biller does not mark an invoice paid too early.

This is also why the message model matters. Our guide to ISO 20022 payment messages explains how a message name identifies its business role, not merely its file format.

Acceptance is not automatic withdrawal

The Federal Reserve’s operating procedures say that, if an RFP is accepted, the participant must initiate a Customer Credit Transfer. The word “initiate” is important. Acceptance authorises the next action; it is not a standing permission for the requester to pull funds from the account.

That makes RFP different from a card-on-file charge or a direct-debit mandate. The payer’s financial institution remains the party that sends the credit transfer after the customer makes a decision in its channel.

A product should make that sequence visible. Good screens show who is asking, how much is requested, what the request relates to and what will happen after approval. A vague “confirm” button creates unnecessary uncertainty when the next step is an instant, generally irrevocable payment.

For comparison, a card authorisation hold is another case where an early payment state can be mistaken for final movement. The rails and rules differ, but the product lesson is similar: label the current state precisely.

The messages around an RFP

The core request uses pain.013. A pain.014 response can communicate the request’s status, including acceptance or rejection. The later payment uses pacs.008.

Those identifiers are useful in logs and reconciliation, but they should not leak into customer copy. A customer needs plain labels such as “request received”, “waiting for your approval”, “declined” and “payment sent”. Operations teams, meanwhile, need the original identifiers and business references so they can match a request with the transfer that followed it.

A request can also be cancelled. Cancellation does not substitute for a payment return and it does not reverse money that has already moved. Once the credit transfer has been sent, the payment has its own lifecycle and exception processes.

What zero-dollar requests are for

FedNow also describes a zero-dollar RFP market practice. It lets a biller check whether a customer is ready to receive and act on requests before sending a real one.

The Federal Reserve recommends this as an onboarding aid, but does not require it. A zero-dollar request follows a simplified version of the RFP flow and has only accepted or rejected response codes. It is a capability check, not a tiny payment and not proof that a later request will be approved.

For implementers, that means zero-dollar events should be stored as tests. They should not appear in revenue, receivables or payment-volume reports.

Who can send and receive

All FedNow participants enabled for credit transfers can send an RFP. Receiving one requires the appropriate participation setup and the ability to present it to an end customer.

A bank can therefore participate in FedNow without offering every RFP experience to every customer. Coverage depends on the receiving institution’s participation type, product rollout and customer channel. Billers should not assume that a routing number alone guarantees that a request will appear in a customer’s app.

The Federal Reserve publishes a list of FedNow participants and service providers, but the list does not replace a live capability check inside a payment product.

What FedNow charges in 2026

The FedNow 2026 fee schedule lists a $0.01 fee for originating a pain.013 Request for Payment. An on-us RFP is listed at $0.00.

The separate pacs.008 Customer Credit Transfer has a listed origination fee of $0.045, or $0.00 when on-us. The general $25 monthly participation fee is discounted to $0.00 in 2026, and a 2026 discount covers up to 2,500 qualifying credit-transfer originations per month.

These are service fees charged within the FedNow participation model. They are not a promise about what a bank, fintech or biller will charge its own customer. Retail pricing, account fees and service-provider charges can be different.

Fraud and interface checks

An RFP can make a legitimate bill easier to pay, but a request is still a prompt to send money. The presence of a request inside a bank channel does not make every underlying invoice correct.

Before approval, the payer should be able to verify:

  • the requester name;
  • the amount and requested date;
  • an invoice or account reference;
  • whether the request was expected;
  • the destination and any warning supplied by the bank.

Product teams should avoid urgency tricks and should not hide the requester behind a generic notification. They also need controls for duplicate requests, mismatched references and requests that arrive after an invoice was already paid elsewhere.

Because the payment that follows can settle within seconds at any hour, review belongs before the approval action. A warning shown after the pacs.008 has been sent is too late to prevent the transfer.

Reconciliation needs both sides of the flow

For a biller, the most useful implementation keeps the request record and the payment record linked but distinct.

The request record should retain its RFP identifier, amount, requester reference, delivery state and response. The payment record should retain the credit-transfer identifier, settlement state and the reference used to match it back to the request.

That separation supports several common outcomes: a request may be rejected, expire, be cancelled, remain unanswered or be accepted without a transfer completing as expected. A single “paid” flag cannot explain all of them.

It also helps customer support. An agent can tell whether the problem is that the request never reached the payer, the payer declined it or the later transfer encountered an exception.

Reporting and sources

This explainer is based on the Federal Reserve Banks’ FedNow Service Operating Procedures, February 2026, version 3.5, particularly the Request for Payment section, plus the FedNow Service 2026 fee schedule and the current participant overview.

Source and fee details checked on 23 October 2026. Product availability and customer pricing still depend on the participating institution.