Handle FedNow Request for Payment (RfP) pain.013/pain.014 message flow end-to-end
domain: frbservices.org · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Understand RfP is a Nonvalue Message in FedNow: the RFP Sender FI builds a pain.013 (Request to Pay) on behalf of a biller/end customer and routes it to the RFP Receiver FI.
Populate the pain.013 fields the receiving customer needs to act on the request — creditor/debtor identification, amount, and requested expiry.
On the receiving side, present the RfP to the payer and respond with a pain.014 (Request for Payment Response) that references the original RfP by its identifiers rather than repeating its full contents.
Handle all payer outcomes — accept, reject, or let the RfP lapse — and reconcile each against your internal request state.
Expire unanswered RfPs locally once the requested expiry passes rather than waiting indefinitely for a pain.014.
Known gotchas
An accepted RfP does not itself move funds — the payer's FI must separately originate a pacs.008 credit transfer; don't treat pain.014 acceptance as settlement.
Not every FedNow participant supports receiving RfPs — confirm receiver capability before sending rather than assuming universal support.
The pain.014 response doesn't echo the full original request, so your matching logic must key off the original message/instruction identifiers, not resent payment details.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?