FedNow fraud controls sit at three different layers: the service can reject known-bad account activity, stop transfers that breach configured value or velocity thresholds, and return network-level risk insights before a sending bank decides to release a payment. None of those controls replaces the bank’s own authentication, sanctions screening or fraud decisioning.
Checked against FedNow Service Operating Procedures version 3.7 (October 2026) and Operating Circular 8 on October 15, 2026.
The control stack
A bank connecting to FedNow is not buying a single fraud score. It is assembling several controls with different jobs.
| Control | Where it acts | What it does |
|---|---|---|
| Participant negative list | FedNow service | Rejects eligible instant payments to or from accounts a participant has placed on its managed list |
| Account activity thresholds | FedNow service | Rejects pacs.008 credit transfers when configured cumulative value or transaction-count criteria are exceeded |
| Network Intelligence API | Before the sending decision | Returns network-level data insights that a sending institution can combine with its own customer and transaction signals |
| Financial institution net send limit | Settlement relationship | Lets a correspondent cap net sending activity for a respondent or account structure |
The first two are transaction controls inside the service. Network Intelligence is different: the October 2026 procedures describe it as an API that a sending financial institution calls for information to help assess a potential payment. The Federal Reserve Banks enable the API after a participant or its service provider requests access.
That distinction matters in an architecture review. A response from Network Intelligence is an input to the bank’s decisioning layer, not an instruction to approve the transfer. The bank still owns its customer-risk model, step-up authentication, sanctions and AML controls, case management and the decision to send.
Negative lists block known account relationships
The participant negative list is the simplest control conceptually. A participant maintains account identifiers it does not want to send to or receive from. FedNow checks eligible instant payments against that list and rejects a match.
A negative list is useful after a confirmed scam, account takeover or mule investigation, but it is deliberately narrow. It cannot identify a newly opened mule account that has never appeared in the bank’s cases. It also needs governance: who can add or remove an account, how long an entry remains, and how analysts document the reason.
The operating procedures assign edit permissions separately from general account-management access. That is a useful hint for implementation: treat changes to the list as a controlled operational action, not an ordinary customer-service update.
Activity thresholds control value and velocity
FedNow automatically provides default cumulative criteria for send-enabled participants. An appropriately credentialed user can change them. When a pacs.008 transfer breaches the configured criteria, the service rejects it.
Thresholds are most useful when they reflect customer segments. A small-business account that sends payroll and supplier payments has a different normal pattern from a new consumer account. The Federal Reserve’s June 2025 launch notice for the feature said participants could define dollar-value and transaction-velocity thresholds by customer segment. It launched alongside an increase in the network transaction limit to $1 million, but a higher network ceiling does not require a bank to offer the same ceiling to every customer.
A practical design keeps three numbers separate:
- the FedNow network maximum;
- the participant’s service-level thresholds; and
- the customer or product limit enforced in the bank’s own channel.
Only the last layer knows whether a transfer fits the customer’s history, device, payee and purpose.
Network Intelligence belongs in the pre-send path
The Federal Reserve announced the Network Intelligence API for early adopters on April 28, 2026. The October operating procedures now place it alongside the negative list and activity thresholds.
For a bank or processor, the clean integration point is before the pacs.008 credit transfer is submitted. The sending system assembles its own signals, requests the network insight, and applies a documented decision policy. If the policy calls for a manual review, the payment should not be sent while that review is open; instant-payment finality leaves little room to recover funds later.
The official public description does not turn the API into a guarantee that a payment is legitimate. Product teams should therefore avoid labels such as “safe payee” or “Fed approved.” Store the response used for the decision, the rule version and the action taken so a later investigation can reconstruct why the transfer was released or stopped.
Finality changes the recovery playbook
FedNow settles through entries to Federal Reserve Bank master accounts. Version 3.7 says settlement becomes final when the service records the debit or credit, or when it sends the relevant advice of credit, whichever happens first. That is why prevention sits before submission.
FedNow supports a return request (camt.056) and payment return (pacs.004), but a request is not a card chargeback. The receiving institution must act on it under the service rules and its own obligations. Operations teams need a staffed fraud-reporting and return workflow that runs outside normal banking hours, because FedNow operates 24x7x365.
What an embedded-finance platform needs from its bank
A platform does not configure FedNow controls unless it is itself a participant or authorized service provider. In most embedded-finance programs, the sponsor bank owns the participant profile and settlement account.
The platform still needs a precise operating agreement with the bank:
- who performs customer authentication and transaction monitoring;
- which limits apply by product and customer segment;
- who can pause sending when a control is misconfigured;
- how negative-list additions are requested and approved;
- which Network Intelligence result fields the platform receives, if any;
- who handles fraud reports and return requests overnight; and
- how both sides reconcile service reports to the program ledger.
This is the same division-of-responsibility problem described in FedNow participation: how banks and cores connect. It should also appear in a platform’s sponsor-bank due-diligence checklist.
