Request for Payment on RTP and FedNow: An Operator Reference

A biller's Request for Payment (RfP) message looks, from the outside, like the US finally got something close to SEPA's request-to-pay or India's UPI Collect. It isn't quite either, and treating RTP's and FedNow's versions as interchangeable is the fastest way to build the wrong onboarding and dispute pipeline. Both rails let a biller's bank ask a payer's bank to trigger an instant credit transfer — a request, not a debit — and both rulebooks spend real text policing what that request may legitimately be for. Where they diverge is in how prescriptive that policing is, and what happens when a payer's bank disputes it. This is an operator reference to both, read from the actual rulebooks: FedNow's Operating Circular 8 and Service Operating Procedures, and RTP's Operating Rules, its Additional Requirements schedule for RfP, and TCH's Permissible Uses interpretation.

RfP is a message, not a debit — on either rail

Start with the mechanic both networks share. RTP's Operating Rules state it plainly: an RfP "shall not constitute the initiation of a debit or impose any obligation on the Message Receiver to pay any amount to the Message Sender." FedNow's architecture works the same way structurally — a Request for Payment (pain.013) is a nonvalue message that generates no accounting entry; only if the payer's bank sends back an acceptance does a real value message, a Customer Credit Transfer (pacs.008), move any money. In both cases the payer's action is what produces the payment. There is no pull leg anywhere in either rulebook — nothing resembling a direct debit mandate that lets a biller trigger future charges without asking again. Each RfP is its own ask, answered or not, every time.

That single design choice is why RfP reads as a nudge, not an authority — the same framing PaymentBrief has already used for SEPA's request-to-pay, a messaging-only mechanic rather than a payment instrument in its own right. RTP and FedNow's RfP sits in the same category, on US rails, with its own set of obligations layered on top.

What a biller may legitimately ask for

Both rulebooks require the request itself to be for a "legitimate purpose," and both split the test the same way: differently for business senders than for consumer senders.

FedNow's test (Operating Circular 8, s.9.8.5, detailed in the Operating Procedures s.12): if the Sender FI's customer is a business, the RFP is not for a legitimate purpose unless it seeks payment for a current sale or transaction, or an amount due, owed, or previously agreed to be paid. If the customer is an individual, the test flips to the recipient's side: the RFP breaches the warranty if it is "not reasonable for the Receiver FI's customer to have expected to receive" it. Any use that violates applicable law — including the FTC Act's and Dodd-Frank Title X's prohibitions on unfair, deceptive, or abusive practices — is automatically not legitimate.

RTP's test (Rule VII.B.3) runs the identical two-track structure — current sale/amount owed for non-consumer senders, known-and-expected for consumer senders — but RTP does not stop there. Rule VII.B.1 also requires every RFP to be for a "permissible use," and TCH has published a standalone interpretation naming exactly what those are, effective 15 April 2025:

• Business to Business — a business purpose on both sides, meaning not related to any personal, family, or household matter for either the sender or the receiver.
• Account to Account — the sender and receiver are the same person, or the sender holds an asset account for the receiver and is acting at the receiver's direction; either way, the payment must move funds between accounts verified as owned by the same person.
• Consumer Bill Pay — a recurring consumer service or financial obligation billed at least quarterly and expected to continue at least a year, or a non-recurring service performed and paid for at the consumer's home (lawn care, cleaning, repairs). TCH's interpretation is explicit that a single "just in time" RFP for a recurring obligation still counts, and that individual, as-needed purchases like groceries or haircuts do not.
• Consumer Down Payment, Security Deposit, or Final Payment — a one-time payment opening a deposit account or settling the outstanding balance on a multi-payment obligation like rent or a mortgage.
• Government Payments — tolls, taxes, licensing fees, fines owed to a federal, state, or local government.
• Healthcare Payments — medical, dental, or vision services, or a health insurance premium; the interpretation separately bars including Protected Health Information in the message itself.
• Trusted Party — a non-consumer sender with an existing employment or service-provider relationship expected to last at least 90 days, collecting on a prior obligation rather than a current sale — an employer recovering an ineligible purchase-card charge, a law firm billing a client, a school collecting fees.

The RTP taxonomy carries its own compliance step FedNow's retrieved materials do not: a Message Sending Participant must notify TCH of every Message Sender that will send RFPs, which permissible use category applies, and any change to that category before it takes effect. That is a per-biller registration duty layered on top of the underlying legitimate-purpose test — something to build into onboarding, not bolt on afterward.

The dispute is about the request, not the goods

Because RfP settles as an ordinary irrevocable credit-push instant payment once accepted, it inherits the same finality PaymentBrief has covered for FedNow and RTP generally and the same absence of a card-style chargeback that shapes authorized push payment fraud on real-time rails everywhere. But both networks do provide a narrower mechanism specific to RfP: a warranty claims process testing whether the request itself broke the rules, not whether the underlying purchase was satisfactory.

Both rulebooks say this almost identically. RTP: "A complaint regarding the quality or delivery of goods or services does not by itself constitute the allegation of facts sufficient to support a claim of breach of the RFP Warranty under sections VII.C.5." FedNow: dissatisfaction with quality or delivery "should not give rise to a breach of the RFP Warranty unless additional circumstances indicate the RFP was not sent for a legitimate purpose." What does qualify: no legitimate purpose, part of a fraudulent scheme to induce payment, harassing language or repeated requests, or otherwise unlawful use.

The two windows that matter operationally line up exactly. On both rails, a claim must be initiated within 95 calendar days of the date the responding payment settled, and the sending side must respond within 20 business days. That symmetry is worth noting precisely because so little else about the two dispute processes matches. RTP adds a third deadline with no FedNow counterpart: an arbitration request form "must be submitted to TCH within 45 calendar days of the negative response or conclusion of the response period and good faith efforts to resolve the claim, as applicable."

Where the rails genuinely diverge

Escalation, and who ultimately decides. This is the structural difference operators should engineer around first. On RTP, if a negative response doesn't resolve the claim, the Message Receiving Participant can initiate a formal Arbitration Proceeding: TCH investigates, decides based on the exchanged evidence and arbitration precedent, and issues a decision "final and binding on the Participants" with no appeal to the courts. The burden of proof isn't the same for every claim: for a claim involving a Request for Payment to collect payment for the Message Receiver's purchase of goods or services in the ordinary course of business, as determined by TCH, the Message Receiving Participant has the burden of establishing the facts necessary to support the claim; for every other claim, the Message Sending Participant has the burden of establishing the facts necessary to rebut it.

What the decision actually does is the part operators need to plan around, not just the fact that it's binding. "If TCH determines that a breach has occurred, the Message Sending Participant is required to return the amount of the Responding Payment(s) at issue in the dispute." Concretely: "If under the process described in section VII.C.7, the Message Sending Participant is determined to have breached the RFP Warranty, the Message Sending Participant must return funds to the Message Receiving Participant within five (5) business days through a Payment in the amount of the Responding Payment(s)." The Message Receiving Participant then "must credit the Message Receiver in the amount of the returned funds if it has not already done so", by the end of the business day immediately following the calendar day the funds are returned. TCH also maintains an RFP Fine Schedule and can fine a Participant found to have violated the rules during arbitration, independent of the arbitration outcome itself, and recovers the cost of running arbitration through a fee assessed on the unsuccessful party.

That's the real divergence — not just that RTP's decision is labeled "binding," but that RTP provides an in-network route by which the money actually comes back, decided by TCH. FedNow has no equivalent network-level adjudicator, and no equivalent in-network remedy. If the Sender FI's accept (IPAY) or reject (RJCR) response via camt.029 doesn't resolve things, the Operating Procedures are explicit: "the matter must be addressed outside the FedNow Service." The very next sentence adds that "Reserve Banks will not make any determination regarding the sufficiency of a claim that an RFP Warranty was breached, or otherwise evaluate claims." An unresolved FedNow claim doesn't disappear — it leaves the network for whatever bilateral or legal process the two institutions use next — but there is no in-network mechanism ordering the money back. An operator building a dispute-escalation path needs two different endings, not one — RTP's ends inside the network with a binding decision and an enforced return of funds; FedNow's ends outside it.

How prescriptive the due-diligence duty is. Both rulebooks require the sending bank to vet customers and monitor RFP activity, but RTP's is more explicit on paper. Its standalone Additional Requirements schedule requires documented, risk-based due diligence before approving a customer to send RFPs — for non-consumer customers, a background review confirming legitimate business and no history of regulatory violations, excessive complaints, or fraud — plus, in the schedule's own words, "Monthly monitoring and tracking of a Customer's Request for Payment volume and any reports made to the Participant alleging that a Customer's Requests for Payment are fraudulent or abusive." The same schedule adds a specific obligation to investigate anomalous volume changes by inquiring directly with the customer. FedNow's Operating Circular 8 and Operating Procedures impose a comparable general duty — monitor to identify abuse, track volume with risk-based procedures, investigate anomalous activity — but the retrieved materials for this article do not specify a monthly cadence or separately itemized consumer/non-consumer due-diligence content the way RTP's schedule does. Build the RTP monitoring pipeline to the schedule's specific cadence; build FedNow's to the general standard and confirm any more specific expectation directly with your Reserve Bank contact.

Onboarding tooling. FedNow's Operating Procedures describe a "zero-dollar RFP" market practice: a biller can send a $0 request first, using a simplified two-code subset (Accepted/Rejected only, since nothing is actually presented to the end customer) purely to confirm a new customer's bank can receive and act on RFPs before the biller sends one that asks for real money. No equivalent practice appears in the RTP Operating Rules text retrieved for this article — that does not mean TCH has no comparable guidance elsewhere, only that this article did not find one in the rulebook itself.

A note on staying current. TCH's own RTP document library labels the 1 June 2026 Operating Rules used throughout this article as "Current," but it also already lists two newer editions as "Upcoming," effective 30 September and 4 October 2026 — inside two months of this article's publication. This article did not retrieve either upcoming edition or TCH's own change summaries for them, so it cannot confirm whether Rule VII's RfP provisions move in that cycle. Treat the RTP side of this reference as accurate to the rules in force today, and check TCH's document library directly before relying on it much past that window.

What to build

An operator turning on RfP on either rail needs, at minimum: a legitimate-purpose gate at biller onboarding, matched to the specific rail's test — RTP's gate additionally requires classifying every biller into one of the seven permissible-use categories and notifying TCH; ongoing volume and abuse monitoring, built to RTP's explicit monthly cadence and to FedNow's general risk-based standard; a warranty-claim response pipeline built against the shared 95-day/20-business-day windows on both rails; and escalation logic that ends in the right place — RTP's binding TCH arbitration, FedNow's off-network resolution. On FedNow, add the zero-dollar RFP as a cheap readiness check before a biller's first real request. None of this is optional plumbing bolted onto a generic "request-to-pay" feature — it is what each rulebook actually requires a sending institution to have in place before the first RFP goes out.