Request for Payment on RTP and FedNow. A practitioner deep dive into Request for Payment on RTP and FedNow across pain.013 origination, delivery and presentation, pain.014 responses, payer decision, linked pacs.008 execution, expiry, cancellation, warranty controls, exceptions, reconciliation and receivables operations.
Request for Payment looks simple from the outside: a biller, business, government agency, financial institution or individual asks another person or business to pay. Inside a bank, however, Request for Payment is a carefully controlled non-value message journey that must remain distinct from the payment that may follow.
That distinction is the foundation of Chapter 24.
A Request for Payment does not itself debit the payer, settle money between banks or force the receiver to pay. It communicates a request. The payer or payer-side process still has to decide whether to accept or reject the request. If the payer accepts, the bank then creates a separate instant credit transfer—normally a pacs.008 customer credit transfer—under the relevant RTP or FedNow rules. The payment therefore has its own authorization, controls, settlement, posting, status and reconciliation lifecycle.
The chapter focuses specifically on Request for Payment on the RTP network and the FedNow Service. Chapter 21 already established the wider instant-payment architecture. Chapter 22 explains RTP credit transfers. Chapter 23 explains FedNow credit transfers. Chapter 25 will go deeper into reachability, liquidity, limits and fallback routing. Chapter 26 will go deeper into instant-payment exceptions, fraud and return-of-funds requests. Here the objective is to understand the complete request lifecycle and the handoff from request to payment without duplicating those later topics.
The central model is:
payee need → RfP creation → sender-side eligibility and warranty controls → pain.013 → network validation and delivery → receiver-bank validation → customer presentation → payer decision → pain.014 response → if accepted, separate pacs.008 credit transfer → instant settlement and posting → correlation → reporting and reconciliation.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–5, Sections 6–10 and Sections 11–15. For the next 10 minutes, use the chapter’s three diagrams to keep the request lifecycle separate from the linked credit transfer. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: How should a biller treat an accepted request when the related payment has not been confirmed? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- What Request for Payment really is
- RTP and FedNow RfP landscape and boundaries
- Participants, access models and responsibilities
- Use cases, legitimate purpose and customer onboarding
- Creating the request: business data and pain.013
- Network processing, delivery and acknowledgements
- Receiver-bank presentation and customer experience
- RfP responses, statuses and state model
- Acceptance and the handoff to pacs.008
- Expiry, requested execution date and scheduling logic
- Cancellation, amendment and information requests
- Fraud, scam, warranty and monitoring controls
- Exceptions, unknown states and operational recovery
- Reconciliation, reporting and evidence
- Real-bank implementation, resilience and testing
- End-to-end cases, role checklist and authoritative references
1. What Request for Payment really is
A Request for Payment, or RfP, is a structured electronic request asking a payer to initiate a payment. The word request is important. The message does not create a debit mandate, does not pull money from the payer and does not create settlement by itself.
The request can represent a current purchase, an invoice, a bill, a tax or fee obligation, a repayment between individuals, or another legitimate amount the requester expects the payer to pay. The request usually contains information that allows the payer to understand what is being requested: who wants to be paid, the amount, the requested execution date, the expiry, references, remittance information and other data permitted by the applicable implementation guide.
A useful bank architecture therefore treats RfP as a separate business object with its own identifier and lifecycle.
A practical internal record might contain:
rfp_id
network
sender_customer_id
sender_account_or_creditor_reference
payer_routing_number
payer_identifier_or_account_reference
requested_amount
currency
requested_execution_date_time
expiry_date_time
invoice_or_obligation_reference
pain013_message_id
pain014_status
linked_payment_id
linked_pacs008_message_id
cancellation_state
warranty_monitoring_reference
reconciliation_state.
That model immediately prevents one of the most common implementation mistakes: storing the request and the eventual payment as one mutable object.
RfP is not a debit pull
ACH debit begins with authority that allows the originator to initiate a debit against the receiver's account under ACH rules. RfP does not work that way. The RfP asks. The payer decides. If accepted, the payer's institution sends a credit push.
That difference changes control design. The bank should not assume that because a customer received an RfP, payment is authorized. The actual pacs.008 still needs payer authority, account eligibility, available-funds checks, fraud controls, limits and network processing.
RfP is also not proof of payment
An accepted request is not the same as a settled payment. A bank or biller must not mark an invoice PAID because a pain.014 says the request was accepted. Acceptance means a payment is expected to follow. Financial completion should be driven by the linked pacs.008 and its settlement/posting evidence.
That gives us two correlated but separate state machines:
request: created → sent → received → presented → accepted/rejected/expired/cancelled;
payment: initiated → controlled → sent → accepted by rail → settled → beneficiary posted → reconciled.
2. RTP and FedNow RfP landscape and boundaries
Both the RTP network and the FedNow Service support Request for Payment using ISO 20022 pain.013 and related response messages. That common messaging family does not mean the two schemes have identical operating rules, participant enablement, response guidance or warranty framework.
For RTP, The Clearing House publishes current Operating Rules, Rules Interpretations, Additional Requirements for Request for Payment, customer-display requirements, RfP sender-registration instructions and Version 5.0 message specifications through its document library. RTP rules treat RfP as a non-payment message. A request does not constitute a debit initiation and does not impose an obligation on the receiver to pay.
For FedNow, the current FedNow Service Operating Procedures Version 3.6 provide an explicit RfP section. A FedNow participant can send an RfP on behalf of itself or an end customer. The receiving institution must have the appropriate participation type enabled to receive RfPs and be able to present the request to its end customer.
The two-network implementation problem
A bank supporting both networks should not build two completely disconnected RfP products. A stronger model is:
common request product and canonical RfP data → common customer/merchant controls → network-specific eligibility and routing → RTP or FedNow adapter → network-specific response handling.
That still requires the selected network to be stored permanently. Operations must know whether the request traveled through RTP or FedNow because status codes, participant enablement, cancellation mechanics and rule obligations can differ.
Scope boundary with Chapter 25
Chapter 24 needs to explain enough reachability to determine whether a receiving institution can actually receive and present an RfP. It should not become the full cross-rail routing and liquidity chapter. Chapter 25 remains the place for deeper reachability data governance, rail choice and fallback.
Scope boundary with Chapter 26
Chapter 24 must explain warranty controls, fraud monitoring and what happens when a request is alleged to be improper. Chapter 26 remains the place for deeper instant-payment fraud, return-of-funds and investigation mechanics after money has moved.
3. Participants, access models and responsibilities
The main RfP roles are usually:
requester / payee — the person, business, biller or government entity asking to be paid;
sender FI — the institution sending the RfP into RTP or FedNow;
network — RTP or FedNow, validating and delivering the non-value message;
receiver FI — the payer's institution receiving and presenting the request;
payer — the end customer who decides whether to pay;
payment sender — after acceptance, normally the payer or payer-side institution that initiates the linked credit transfer;
payment receiver — the original requester/payee that receives the eventual funds.
Service providers can appear on either side. A biller may use a fintech or payment processor to create requests. A bank may use a third-party service provider for network connectivity. A receiving bank may use digital-banking software to present requests. Those technical roles do not erase the bank's responsibility for eligibility, customer experience, rule compliance and evidence.
FedNow participation nuance
FedNow's current procedures state that participants enabled for credit transfers can send RfPs, while the Receiver FI needs the participation type that permits receiving RfPs and the capability to present them to end customers.
That means fednow_participant = true is not sufficient reachability data. A bank needs capability-level data such as:
credit_transfer_send
credit_transfer_receive
receive_rfp
present_rfp_to_customer
effective_timestamp
source_of_truth.
RTP sender registration and customer qualification
RTP has explicit RfP sender-registration material and additional RfP requirements. The bank should treat customer access to RfP origination as a governed product entitlement rather than allowing every customer that can receive RTP payments to start sending payment requests automatically.
A commercial bank implementation typically requires onboarding checks around business purpose, expected volumes, counterparties, transaction types, complaint history, fraud exposure and the customer's ability to supply legitimate obligation information.
4. Use cases, legitimate purpose and customer onboarding
Request for Payment becomes valuable when it removes friction from a payment that the payer expects to make.
Typical use cases include bill payment, invoice collection, tax and government fees, person-to-person repayment, business-to-business receivables, insurance premium collection, tuition, healthcare bills, merchant payments and other obligations where the payer retains final control.
The strongest RfP propositions do not simply send a message saying “Pay $500.” They provide enough context for the payer to make an informed decision.
Legitimate purpose matters
Both network frameworks emphasize legitimate RfP use. FedNow's current operating procedures include an RfP Warranty under Operating Circular 8. For a business requester, an RfP is not for a legitimate purpose if it seeks payment for something other than a current sale/transaction or an amount due, owed or otherwise previously agreed by the payer. For an individual requester, the framework looks to whether it was reasonable for the receiving customer to expect the request. Uses contrary to applicable law are not legitimate.
The Clearing House has its own rule interpretation on permissible uses and a Scope of the Request for Payment Warranty interpretation. The practical bank lesson is the same: RfP cannot be treated as an open electronic demand channel for unsolicited collections.
Onboarding should control who can send
Before enabling a business to originate RfPs, a bank should understand:
- the business model;
- the reason customers owe money;
- whether customers reasonably expect requests;
- typical values and volumes;
- expected timing and recurrence;
- complaint and fraud history;
- how customer consent/relationship is evidenced;
- how wrong or duplicate requests will be cancelled;
- how reconciliation to invoices works;
- how customer service will handle disputes.
The bank should assign product limits and monitoring thresholds. A new business sending 20 RfPs per day and an established utility sending 500,000 bill requests are different operating profiles.
Receiving-customer experience is part of risk control
A payer should be able to understand:
who is requesting payment; why; how much; when payment is requested; when the request expires; what reference or invoice applies; and what will happen if the payer accepts.
Poor presentation increases wrong-payment and scam risk.
5. Creating the request: business data and pain.013
The pain.013 Request for Payment message is the structured instruction that carries the request through RTP or FedNow.
The request should be created from an authoritative business event. For a biller, that may be invoice issuance. For tax collection, it may be an assessed obligation. For P2P repayment, it may be a customer-entered request.
A bank should capture and validate the business intent before generating network XML.
Typical fields and concepts include:
- requester identity;
- payer / debtor information permitted by the rail;
- requested amount and USD currency;
- requested execution date/time;
- expiry date/time;
- creditor and debtor agents / routing information;
- end-to-end or request identifiers;
- remittance information;
- invoice or obligation reference;
- service-level and proprietary network values where required;
- Business Application Header / message identifiers according to rail specifications.
Canonical request model first
If a bank supports both RTP and FedNow, it should create a canonical internal RfP object and transform it into each network's implementation guide at the edge.
That prevents business channels from needing to understand every network-specific XML detail.
Data quality is operational risk
A request with the wrong invoice number may still be technically valid. A request to the wrong customer can still be syntactically valid. A request with a misleading requester name can still pass schema validation.
Bank validation therefore needs several levels:
schema validation — message structure and required fields;
product validation — customer entitlement, amount, expiry, use case;
counterparty validation — receiving institution RfP capability;
business validation — legitimate obligation, invoice linkage and requester identity;
risk validation — anomalous volume, scam indicators, duplicate request detection.
Duplicate request controls
A retry after a timeout should not accidentally create a second outstanding obligation presentation.
The bank should keep an immutable internal request ID and enforce idempotency around channel/API calls. If the network confirms the first request exists, do not create another simply because the customer-facing API timed out.
6. Network processing, delivery and acknowledgements
Once the sender FI releases the pain.013, the selected network validates the message according to its technical and business rules and attempts delivery to the receiver FI.
The message journey is non-value. No settlement account is debited because a pain.013 is delivered.
Technical acceptance is not customer presentation
Operations should distinguish:
REQUEST_CREATED
RELEASED_TO_NETWORK
NETWORK_ACCEPTED
DELIVERED_TO_RECEIVER_FI
PRESENTED_TO_PAYER
PAYER_DECISION_RECORDED.
This prevents a biller portal from telling a business “customer received the bill” when only the network accepted the technical message.
FedNow receipt acknowledgements
FedNow uses receipt-acknowledgement messaging (admi.007) as part of its nonvalue-message operating model. The operating procedures also provide recommended RfP response timelines in addition to receipt acknowledgement.
For ordinary RfPs, the receiving FI can send pain.014 RCVD immediately as an initial response, then provide a later status when the request is presented or the customer decision is known.
RTP delivery failure
RTP rules require a receiving participant to notify the sending participant if the Request for Payment is not delivered to the receiving participant's customer. That requirement matters because sender-side status should distinguish customer delivery failure from customer rejection.
7. Receiver-bank presentation and customer experience
The receiver FI is not just a passive technical endpoint. It has to convert the structured network request into a safe, understandable customer interaction.
The bank should determine whether the destination customer/account is eligible to receive RfPs and whether the request can be presented.
Customer presentation should preserve truth
A digital banking screen should clearly distinguish:
Requested by: requester/payee name
Amount: requested amount
Reason / invoice: remittance or obligation reference
Requested payment date: when the requester wants the payment initiated
Expiry: last point at which the request can be acted on
Action: pay / reject / review details
The bank should not make the RfP look like an automatic debit notification.
The payer must control the actual payment
When the customer selects Pay, the bank should transition into the ordinary instant-credit-transfer control path: authentication context, account selection, available funds, limits, fraud/scam controls, sanctions/compliance as applicable and final authorization.
An architecture that automatically converts every accepted RfP into a payment without preserving payer authority creates a dangerous control gap.
Requester identity and scam prevention
Receiving banks should display reliable requester information according to network customer-display requirements and bank policy. If a request arrives from an unfamiliar party, new requester, unusual value or unexpected context, the bank may apply additional warnings or risk controls before payment authorization.
8. RfP responses, statuses and state model
Request status is where RTP and FedNow need careful implementation.
FedNow pain.014 statuses
FedNow's current operating procedures identify these core RfP response statuses:
RCVD — Received. The Receiver FI confirms that the RfP was received.
PRES — Presented. The request was presented to the end customer for response.
ACTC — Accepted. The request was accepted and a pacs.008 payment is expected to follow.
RJCT — Rejected. The request cannot or will not be paid—for example because of account ineligibility, a problem with the request, or end-customer rejection.
The bank should store the full history, not just overwrite one status field.
Example:
09:00:00 pain.013 sent
09:00:01 RCVD
09:00:03 PRES
09:08:45 ACTC
09:08:46 linked pacs.008 created
Accepted is not settled
ACTC belongs to the request lifecycle. The linked payment still needs to settle.
Customer and biller status should therefore separate:
REQUEST_ACCEPTED
from
PAYMENT_SETTLED.
RTP response model
RTP also uses Request for Payment and Response to Request for Payment messages under its technical specifications. The bank should follow the current TCH message specification and rule requirements rather than assume FedNow's exact status sequence can be copied one-for-one into RTP implementation logic.
The common internal model can normalize statuses into business meanings while retaining the raw network status.
9. Acceptance and the handoff to pacs.008
This is the most important architectural handoff in the chapter.
A payer accepts the request. That does not make money move. The receiving FI now initiates a separate customer credit transfer.
On FedNow, the operating procedures explicitly say that when an RfP is accepted, the Participant must initiate a pacs.008 Customer Credit Transfer.
The bank should link the request and payment using stable identifiers and remittance correlation.
A useful data relationship is:
rfp_id → pain013_message_id → payer_decision → pain014_ACTC → payment_id → pacs008_message_id → settlement_reference → beneficiary_posting_reference.
Do not reuse the RfP amount blindly
At payment creation, the bank should validate the amount and request rules. If partial payment, overpayment or amount changes are not permitted by the selected network/product use case, the bank must enforce that rather than silently modifying the requested amount.
The payment must run normal controls
The linked pacs.008 should not bypass fraud controls simply because it originated from a trusted RfP workflow.
The bank should know that the source context is RfP because it can improve risk decisioning, but the payment still requires all required release controls.
Biller receivables should close on financial evidence
A biller should receive status such as:
request delivered
request accepted
payment received
payment applied to invoice.
Those stages are different. The accounts-receivable system should normally close the invoice only when the payment is matched and applied.
10. Expiry, requested execution date and scheduling logic
Request for Payment introduces time semantics that are different from a simple immediate transfer.
FedNow's current procedures distinguish requested execution date/time and expiry date/time.
The requested execution date indicates when the payer/customer or Receiver FI should initiate the linked pacs.008 if the RfP is accepted. This is similar to a due date.
The expiry identifies the last date/time by which the request should be accepted or rejected. FedNow notes that these are based on calendar date, not FedNow cycle day.
An expiry date without a time defaults to midnight ET on the specified date under the current FedNow guidance.
Why banks get this wrong
Instant-payment systems often have strong support for event timestamps but weak support for customer-facing obligation dates.
A robust RfP model should distinguish:
request_created_at
network_sent_at
presented_at
requested_execution_at
expiry_at
payer_accepted_at
payment_initiated_at
payment_settled_at.
Late acceptance controls
If a customer attempts to act after expiry, the bank should not simply send the old request's payment without policy. The request should be expired, and any subsequent payment should follow the bank's defined late-payment or ordinary-transfer path.
FedNow cycle day is separate
A request may be presented around the 7:01 p.m. ET FedNow cycle-day rollover, but the RfP requested execution and expiry semantics are calendar based under the current operating procedures. The bank needs both timestamps available for reporting and investigations.
11. Cancellation, amendment and information requests
Request data should not be silently edited after release.
FedNow cancellation model
FedNow uses camt.055 as an RfP cancellation request. The sender FI asks the receiver FI to cancel a previously sent pain.013.
The current procedures state that an RfP cannot simply be changed. If the initial request contains an error, is duplicated, is no longer applicable or was paid through another channel, the sender should cancel the original and submit a new RfP if necessary.
The receiver responds to the cancellation using camt.029 with statuses including:
CNCL — Cancelled
RJCR — Rejection of cancellation
PDCR — Pending investigation.
A cancellation can be requested only while payment has not already been made under the applicable logic.
Cancellation is another state machine
The bank should store:
ACTIVE
CANCELLATION_REQUESTED
CANCELLED
CANCELLATION_REJECTED
CANCELLATION_PENDING.
Information requests
FedNow supports camt.026 information requests and related camt.028 / camt.029 response handling for additional information involving a previous RfP. This is operationally useful when one institution needs clarification without creating a new RfP.
RTP-specific handling
RTP has its own current message specifications, rules and cancellation/response mechanics. Banks should implement the current TCH specification rather than force FedNow camt.055 behavior into RTP if the network requirement differs.
12. Fraud, scam, warranty and monitoring controls
RfP creates a powerful new attack surface because criminals can ask customers to send legitimate credit pushes.
A scam RfP can look technically perfect.
Examples include:
- fake utility bill;
- impersonated government fee;
- false invoice;
- account-recovery scam asking the customer to “confirm” by paying;
- compromised biller account sending fraudulent requests;
- high-volume unsolicited RfPs;
- duplicate requests designed to trigger multiple payments.
Sender FI controls
The sender FI should control who can originate RfPs and monitor how they are used.
FedNow's current RfP warranty framework expects Sender FIs to monitor customer RfP use for anomalous activity and investigate misuse. Monitoring should include risk-based volume analysis and incorporate reports about a customer's RfP behavior.
Useful sender-side signals include:
rfp_volume_vs_profile
unique_payers
new_payer_ratio
rejection_rate
complaint_rate
duplicate_request_rate
average_amount_change
requests_sent_outside_normal_business_pattern
warranty_breach_reports
fraud_reports.
Receiver FI controls
The receiver should assess whether the request appears expected and whether the eventual payment is safe.
High-risk patterns include a new requester, urgent language, unusual amount, first-time payer relationship, repeated rejected requests, payer device compromise or recent password reset.
RfP warranty is not a guarantee of goods or services
The warranty framework concerns legitimate purpose and rule compliance. It should not be taught as a general merchant-quality guarantee.
FedNow's operating procedures specifically note that dissatisfaction with the quality or delivery of goods/services does not by itself create an RfP warranty breach unless additional circumstances indicate that the request was not sent for a legitimate purpose.
FedNow alleged warranty breach after payment
If a participant receives an RfP, sends the linked credit transfer, and later reasonably determines the RfP warranty was breached, FedNow provides a process to seek return of funds. The current procedures describe use of camt.056 with reason code WNTB and a claim submitted within 95 calendar days of settlement of the corresponding credit transfer, along with supporting identifiers and information.
That recovery mechanism belongs at the boundary of Chapter 24 and Chapter 26. Chapter 24 explains why the warranty matters. Chapter 26 should own the deeper return-of-funds investigation mechanics.
13. Exceptions, unknown states and operational recovery
RfP is non-value, but it still needs serious exception handling.
Common exceptions
- request rejected by network validation;
- receiver FI not enabled for RfP;
- request technically delivered but not presented;
- payer account ineligible;
- receiver customer rejects request;
- request expires;
- cancellation arrives after payment initiation;
- sender API times out after request release;
- duplicate request retry;
ACTC received but linked payment never arrives;- payment arrives but cannot be correlated to the request;
- customer pays through another channel while RfP remains active.
Unknown request outcome
Suppose the sender FI transmits pain.013, then loses connectivity before receiving confirmation.
The bank should not blindly create a second RfP. It should determine whether the original message was processed through network inquiry/retrieval tools and local message evidence.
A first-class state such as REQUEST_OUTCOME_UNKNOWN is safer than either FAILED or SENT when the evidence is incomplete.
Accepted request without payment
This should have its own operations queue.
Possible reasons include:
- customer accepted then account funds changed before payment release;
- fraud control declined the linked transfer;
- system failure between acceptance and
pacs.008 creation;
- requested execution date is future;
- payer intentionally chose another payment channel;
- receiving bank's product does not automatically release payment on ACTC.
The requester should not see “paid” until the payment arrives.
Payment received without request match
The bank should be able to accept and post a valid pacs.008 even if RfP correlation is temporarily broken, while routing the receivables match to investigation. Financial settlement truth should not be blocked by a downstream invoice-reference problem unless rules require otherwise.
14. Reconciliation, reporting and evidence
RfP reconciliation is not settlement reconciliation until a payment actually exists.
A mature bank should reconcile four layers.
1. Request-message reconciliation
Prove that each released pain.013 has an authoritative network outcome and receiver-side status where expected.
2. Customer-presentation reconciliation
Prove that requests reported as presented actually reached the correct digital/customer experience and were not lost in internal queues.
3. Request-to-payment correlation
For accepted RfPs, prove whether the expected pacs.008 was created, settled and linked back to the request.
4. Receivables reconciliation
Prove that the incoming payment was applied to the correct invoice, account, tax obligation or receivable.
A practical evidence chain is:
invoice_id → rfp_id → pain.013 message ID → pain.014 status history → payer decision → linked payment ID → pacs.008 message ID → settlement reference → beneficiary posting → cash application → invoice closed.
Useful reporting
Operations and product reporting should show:
- RfPs created;
- network accepted/rejected;
- delivered/presented;
- payer acceptance rate;
- payer rejection rate;
- expiry rate;
- cancellation rate;
- accepted-but-no-payment count;
- average time from request to payment;
- payment-match rate;
- duplicate-request incidents;
- fraud/warranty reports;
- network and participant breakdown.
Do not mix request value and settled value
A dashboard showing “$20 million of RfP payments” when $20 million is merely the value requested is misleading. Report requested value separately from settled linked-payment value.
15. Real-bank implementation, resilience and testing
A production RfP capability crosses product, payments, digital banking, receivables, fraud, customer service and operations.
Recommended logical architecture
request channel / biller API → RfP product service → customer entitlement and warranty controls → canonical request store → RTP/FedNow adapter → network.
On the receiving side:
network adapter → RfP inbox → customer/account eligibility → digital presentation → payer decision → payment orchestration → linked pacs.008.
The canonical request store should preserve every externally meaningful state transition.
Resilience priorities
The most dangerous failures are not always message rejects. They are partial outcomes:
- request sent but response lost;
- payer accepted but payment service unavailable;
- payment settled but biller status not updated;
- cancellation received while payment is being created;
- duplicate request after retry;
- service-provider failover replaying old messages.
Idempotency and correlation are therefore central controls.
Testing catalogue
A serious Chapter 24 test pack should include:
- RTP RfP successful send/presentation/payment.
- FedNow RfP successful send/presentation/payment.
- Receiver not enabled for RfP.
- Receiver account/customer ineligible.
- Immediate FedNow
RCVD followed by PRES then ACTC.
- FedNow
RJCT from receiver FI.
- Customer rejects after presentation.
- Accepted request but
pacs.008 fails before network release.
- Accepted request and payment settles successfully.
- Request expires without response.
- Requested execution date in future.
- Request cancellation before customer action.
- Cancellation after customer accepted but before payment release.
- Cancellation request rejected.
- Cancellation pending investigation.
- Duplicate request API retry.
- Network timeout after
pain.013 submission.
- Payment received without matching RfP.
- RfP accepted but payment comes via another channel.
- Zero-dollar FedNow RfP accepted.
- Zero-dollar FedNow RfP rejected.
- High-volume anomalous RfP sender.
- Warranty-breach report.
- Service-provider outage with queued messages.
- Customer mobile channel unavailable while network still delivers messages.
- Calendar-day expiry around FedNow cycle-day rollover.
- Wrong invoice reference.
- Duplicate bill paid once.
- Reconciliation break between pain.014 ACTC and pacs.008.
- Recovery after dropped-message retrieval.
Operational ownership
A bank should define who owns:
- RfP sender onboarding;
- warranty monitoring;
- network connectivity;
- receiver presentation;
- customer complaints;
- accepted-without-payment exceptions;
- request cancellation;
- fraud escalation;
- payment correlation;
- invoice cash application;
- network reconciliation;
- rulebook/specification changes.
16. End-to-end cases, role checklist and authoritative references
Case 1 — FedNow bill payment
A utility generates a $186.42 bill due next Tuesday. Its bank creates an RfP and sends pain.013 through FedNow. The customer's bank receives the request, returns RCVD, presents the bill in mobile banking and later returns PRES. The customer reviews the utility name, amount and account reference, selects Pay, authenticates and chooses an eligible checking account. The bank returns ACTC, creates a separate pacs.008, runs funds and fraud controls, and releases the credit transfer. FedNow settles the payment through the applicable Master Account arrangement. The utility's bank credits the utility, matches the remittance reference and closes the invoice.
The important lesson is that the RfP did not settle the utility bill—the linked credit transfer did.
Case 2 — Customer rejects a suspicious request
A customer receives an unexpected $2,400 RfP from an unfamiliar business. The receiving bank presents the requester name and details. The customer rejects it. The bank returns the appropriate rejection response. No debit occurs. The sending institution records the rejection in monitoring. If many customers reject similar requests from the same RfP originator, that pattern becomes a risk signal.
Case 3 — Duplicate bill paid elsewhere
A business sends an RfP. Before the payer acts, the invoice is paid by ACH. The requester system should identify that the obligation is already satisfied and issue the applicable cancellation flow rather than leaving a second payable request active.
Case 4 — Accepted request but no payment
The customer accepts an RfP, but the linked instant credit transfer fails an available-funds check. The request state may show accepted, but the invoice remains unpaid. Operations needs an accepted-without-payment exception rather than falsely reporting successful collection.
Role checklist
Business Analyst: define request lifecycle, response codes, date semantics, cancellation, correlation and exceptions separately from payment state.
Product Owner: define eligible use cases, customer proposition, sender onboarding, receiver experience and late/expired behavior.
Architect: separate RfP object, payment object and receivables object; design idempotency and correlation.
Developer: preserve message IDs, timestamps, raw network statuses, retry safety and cancellation races.
Tester: test state transitions and partial failures, not just happy-path request-to-payment.
Fraud / Financial Crime: monitor RfP sender behavior, scam signals, requester complaints and warranty reports.
Operations: investigate delivery, presentation, accepted-no-payment, cancellation and correlation breaks.
Receivables / Accounting: close obligations from settled payment evidence and cash application, not request acceptance.
Authoritative references
The Clearing House — RTP Document Library: https://www.theclearinghouse.org/payment-systems/rtp/document-library
The Clearing House — RTP Technical Documentation: https://www.theclearinghouse.org/payment-systems/rtp/technical-documentation
Federal Reserve Financial Services — FedNow Service Operating Procedures, effective April 28, 2026: https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/042826-fednow-service-operating-procedures.pdf
Federal Reserve Financial Services — Operating Circulars / Operating Circular 8: https://www.frbservices.org/resources/rules-regulations/operating-circulars.html
Federal Reserve Financial Services — FedNow Service Resources: https://www.frbservices.org/resources/financial-services/fednow
Federal Reserve Financial Services — FedNow and ISO 20022: https://www.frbservices.org/financial-services/fednow/what-is-iso-20022-why-does-it-matter
Federal Reserve Financial Services — FedNow Participants and Service Providers: https://www.frbservices.org/financial-services/fednow/organizations/
Federal Reserve Financial Services — FedNow Operating Hours: https://frbservices.org/resources/financial-services/fednow/operating-hours
Federal Reserve Financial Services — FedNow 2026 Fee Schedule: https://www.frbservices.org/resources/fees/fednow-2026
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.