FedNow Service settles U.S. instant credit transfers through Federal Reserve accounts. Learn the payment flow, finality, availability, returns, and risks.
The FedNow Service is the Federal Reserve Banks’ instant-payment system for eligible U.S. dollar credit transfers between participating financial institutions. It clears and settles each accepted payment within seconds through Federal Reserve settlement accounts and operates continuously, including nights, weekends, and Federal Reserve holidays.
FedNow is the interbank infrastructure, not a consumer payment app. An individual or business uses a participating bank or credit union’s service, and that institution decides which customers, accounts, interfaces, limits, and use cases it supports.
7:01 p.m. ET.FedNow provides interbank clearing and settlement for eligible instant payments. Participating financial institutions can use it to support services such as account-to-account transfers, bill payments, business disbursements, supplier payments, payroll-related payments, and other time-sensitive transfers.
The service can:
FedNow does not itself:
| Party or record | Role | Evidence to examine |
|---|---|---|
| Sender | Authorizes the underlying payment through a bank or credit union | Authentication, account, amount, beneficiary, purpose, and confirmation screen |
| Sender’s financial institution | Accepts the customer instruction and submits the payment when eligible | Customer debit, fraud controls, message ID, participant status, and submission timestamp |
| FedNow sender | Participant that sends the payment order through the service | Sending routing number, customer credit-transfer message, acknowledgement, and settlement report |
| Federal Reserve Banks | Validate messages and settle accepted payment orders | Request for confirmation, rejection or settlement status, settlement-account entries, and advice of credit |
| FedNow receiver | Participant asked to confirm and receive the payment order | Receiving routing number, account check, response code, advice of credit, and posting status |
| Receiver’s financial institution | Makes the funds available to the beneficiary, directly or through its customer systems | Customer-account credit, availability timestamp, exception status, and notification |
| Beneficiary | Receives the payment and applies it to the intended purpose | Account activity, remittance data, invoice, receipt, and reconciliation record |
A participant can use its own Federal Reserve master account as its settlement account or, under the applicable arrangements, settle through a correspondent’s master account. A service provider can operate technical connections and process messages for a participant. Those arrangements do not remove the participant’s responsibilities under the governing rules.
Participation is not all-or-nothing. An institution can be configured to receive customer credit transfers without offering the same sending functionality. It can also establish customer and participant limits below the service maximum. Confirm the institution’s current capabilities instead of relying only on the FedNow name or a general participant list.
flowchart TD
A["Sender authorizes a credit transfer through its financial institution"] --> B["Sender FI authenticates, screens, and submits the payment message"]
B --> C["FedNow validates the message and participant settings"]
C --> D["Receiver FI gets a request for confirmation"]
D --> E["Receiver FI confirms that it intends to accept the payment"]
E --> F["Federal Reserve settlement accounts are debited and credited"]
F --> G["Receiver gets advice of credit; sender gets settled status"]
G --> H["Receiver FI makes funds available to the beneficiary"]
H --> I["Both sides reconcile the payment and its purpose"]
The standard accepted flow is designed to occur within seconds:
The payment may be rejected before settlement because of message errors, participant status, routing, limits, timeout, settlement-account conditions, or the receiver’s response. A rejected attempt and a settled payment are materially different events.
| Message or status | What it can establish | What it does not establish by itself |
|---|---|---|
| Customer authorization | Sender approved an instruction through the customer channel | Sender’s institution submitted it to FedNow |
| Receipt acknowledgement | Service or participant received a message | Payment passed all checks or settled |
| Accepted technical validation | Message met an initial processing stage | Receiving institution accepted the beneficiary payment |
| Receiver rejection | Receiver does not intend to accept the payment under the response flow | A corrected new payment will never be sent |
| Accepted and settled | FedNow completed final interbank settlement | Beneficiary applied the receipt to the correct invoice |
| Advice of credit | Receiver was notified of the settlement-account credit | Customer-facing notification was delivered |
| Confirmation of posting | Receiver reports that funds were made available to the beneficiary | Purchase, invoice, or beneficiary instructions were legitimate |
| Request for return | A participant asked for some or all funds to be returned | Funds moved back or the receiver agreed to the request |
| Payment return | A separate value message sends funds back through the service | Original payment never settled |
Use the original message ID and related references to connect these records. An app notification such as “sent,” “completed,” or “received” can be useful, but the institution should be able to identify which operational state that label represents.
Current Operating Circular 8 states that FedNow settlement is final at the earlier of the time the service records the related debits and credits and the time it sends the advice of credit to the receiver. Settlement remains final even if the account entries appear later in another Federal Reserve system or are not yet visible to the participant.
For a normal acceptance response, the receiver must make funds available to the beneficiary immediately after the Reserve Bank makes the advice of credit available. This explicit customer-availability obligation is an important difference from systems whose rules stop at interbank settlement.
These events should still be kept separate:
FedNow includes a limited Accept Without Posting (ACWP) response for specified legal or compliance concerns about whether the beneficiary is entitled or permitted to receive the payment. ACWP is not a general-purpose delay status. When it applies, the receiver follows special investigation, status-update, posting, rejection, and return requirements in the current rules.
FedNow instant-payment messages are processed during a 24-hour funds-transfer business day on every day of the week, including weekends and Federal Reserve holidays. The next cycle day begins at approximately 7:01 p.m. ET, immediately after the preceding cycle day ends, without interrupting instant-payment processing.
The FedNow business date can therefore differ from the calendar date between cycle rollover and midnight. A payment processed at 8:30 p.m. ET on Friday can carry Saturday’s FedNow cycle date even though it was initiated on Friday’s calendar date.
Continuous service availability does not mean every customer has identical access at every moment. A financial institution can have planned or unplanned downtime, sign off from receiving certain messages, apply account maintenance, or restrict a product channel. Customer-service and exception staff may also have different support hours from the payment system.
Liquidity management transfers have a separate operating schedule. Their availability should not be inferred from the around-the-clock schedule for customer instant-payment messages.
As of this article’s review date, the FedNow network maximum for customer credit transfers and payment returns is $10 million. The current operating procedures also allow participants to configure lower transaction limits, and a bank can impose separate limits by customer, account, channel, time, or risk profile.
The network maximum does not mean:
$10 million customer payment;For an actual transfer, check the current service rules and the sending and receiving institutions’ limits. Network limits and product features can change.
A settled FedNow payment is not undone by changing an app status or deleting a customer instruction. The system distinguishes several actions:
Operating Circular 8 states that a Reserve Bank has no obligation to cancel or amend a payment order merely because it receives a request for return or another cancellation-related message. Its obligation for an accepted request is to transmit the message to the identified participant. Recovery then depends on the applicable rules, facts, available funds, participant action, account status, and legal rights.
If a sender suspects fraud or error, the sender should contact the financial institution immediately through a verified channel and preserve the payment reference, account activity, communications, and beneficiary instructions. Prompt reporting can improve the chance of investigation, but it does not guarantee a return.
Consumer, commercial, and financial-institution transfers can be subject to different laws, agreements, warranties, and allocation-of-loss rules. Do not infer a final legal result from the payment rail alone.
A request for payment (RFP) is a nonvalue ISO 20022 message through which a participant, for itself or a customer, asks another participant or customer to make a payment. The request does not move money and does not authorize FedNow to pull funds from the recipient’s account.
If the recipient chooses to pay, the recipient’s institution initiates a separate customer credit transfer. That payment is subject to the normal authorization, validation, confirmation, settlement, and availability flow.
Before acting on an RFP, verify:
An RFP can improve bill presentation and reconciliation, but it can also be used in impersonation and social-engineering attempts. Treat urgency and changed instructions as risk signals, not proof that payment is required.
FedNow uses ISO 20022 messages for credit transfers, returns, status reporting, requests for payment, inquiries, and liquidity management. Structured identifiers and remittance fields can improve validation and automated reconciliation when institutions preserve and use them correctly.
ISO 20022 compliance does not establish that:
The payment message, settlement record, customer postings, and business documents answer different questions. A robust system preserves the original identifiers across all four layers.
Assume a manufacturer must pay a repair company $42,500 on Saturday evening so emergency work can continue. Both institutions offer the required FedNow functionality to these business customers.
| Stage | Illustrative evidence | Question answered |
|---|---|---|
| Payment approval | Invoice, verified beneficiary instructions, and dual approval for $42,500 | Was the business instruction authorized? |
| Sender-bank acceptance | Customer debit and unique payment reference | Did the sender’s institution accept the request? |
| Receiver confirmation | Receiver response for the stated account | Did the receiving institution intend to accept it? |
| FedNow settlement | Accepted-and-settled status, sender debit, receiver credit, and advice of credit | Did interbank settlement become final? |
| Beneficiary availability | Repair company’s account credit and posting confirmation | Could the beneficiary use the funds? |
| Invoice reconciliation | Payment reference matched to the emergency-repair invoice | Was the correct obligation paid? |
Suppose the sender approves the payment at 8:29 p.m. ET Friday and FedNow settles it at 8:30 p.m. ET. The FedNow record can carry Saturday’s cycle date because the service rolled to the next funds-transfer business day at approximately 7:01 p.m. ET. The company’s internal ledger should preserve both the actual timestamp and the relevant business date instead of treating one as an error.
If the repair company says the payment is missing, the manufacturer should trace the existing payment reference before sending a duplicate. The bank should distinguish a rejected instruction, final FedNow settlement, an ACWP exception, beneficiary posting, and invoice application.
| System or method | Primary role | Timing and settlement | Important distinction |
|---|---|---|---|
| FedNow Service | U.S. instant credit transfers through participating institutions | Individual real-time gross settlement, continuously available | Standard accepted payments include immediate beneficiary availability requirements |
| Fedwire Funds Service | Large-value and time-critical U.S. dollar credit transfers | Individual real-time gross settlement during the Fedwire operating day | Different messages, operating schedule, participation settings, and customer-availability framework |
| ACH | Payroll, bills, account transfers, and other bank-account payments | Batch clearing with scheduled settlement, including Same Day ACH options | Supports credit and debit entries, returns, and different authorization rules |
| RTP network | Private-sector U.S. instant payments | Individual, continuous settlement using prefunded positions | Different operator, settlement structure, rules, participation, limits, and service arrangements |
| Card network | Purchase authorization, clearing, and settlement | Customer authorization can appear immediate while interbank settlement occurs later | Often includes merchant-acquiring, dispute, and chargeback processes |
| Payment app or wallet | Customer interface and stored credential or balance experience | May use FedNow, RTP, ACH, cards, book transfers, or another route | Brand and screen speed do not identify the underlying rail |
FedNow and Fedwire are both Federal Reserve services and both use gross settlement, but they are not interchangeable. Regulation J expressly defines FedNow Service separately from Fedwire Funds Service. Always identify the named service and message record.
Useful controls include independent verification of new beneficiary instructions, strong authentication, role-based approval, transaction and velocity limits, duplicate detection, participant and account validation, anomaly monitoring, clear status labels, round-the-clock escalation, and end-to-end reconciliation. No control guarantees prevention or recovery.
$10 million network maximum as every bank’s customer limit.$10 million network maximum and the ability of participants to set lower limits.Official service material does not prove whether a particular payment was authorized, correctly addressed, legally valid, or available to a particular customer. Use the actual institution, account, message, and transaction records for a specific case.
This article provides general financial education. It is not payment-operation, banking, fraud-recovery, accounting, legal, regulatory, cybersecurity, sanctions, compliance, or transaction-specific advice. Use current Federal Reserve rules, institution records, account agreements, and qualified professional guidance for an actual payment.