Nacha's fraud monitoring rules take effect next year, raising a critical question: when should you catch fraud?
The framework requires risk-based monitoring for all ACH transactions, including traditional and Same Day ACH, debits and credits, and every Standard Entry Class code. However, it doesn't mandate pre-processing monitoring. You can flag fraudulent payments before they move, or catch them after they've hit the receiving account.
This flexibility divides practitioners into two camps, each with valid operational and risk arguments.
The Case for Post-Processing Monitoring
Post-processing monitoring aligns with how most fraud detection systems currently operate. Transactions flow through authorization and settlement, then fraud rules evaluate them against behavioral baselines, velocity checks, and anomaly patterns. If something triggers a threshold, such as a large corporate transaction landing in a consumer account, you investigate after the fact.
This approach has operational benefits. It avoids adding latency to payment processing. Your fraud team can review alerts in batches rather than making real-time decisions. You can apply more sophisticated machine learning models that require complete transaction context.
Devon Marsh, Nacha's Managing Director of ACH Network Rules & Risk Management, confirmed that the rule allows this: "It's ideal if it's done prior, but what the rule calls for are risk-based processes and procedures to detect fraudulently initiated payments."
Post-processing monitoring can still recover funds. When an RDFI detects a fraudulent incoming credit, it can freeze the receiver's account or return the payment to the originator. Nacha's checklist guides fraud victims on contacting the receiving institution for a freeze or return. If you act quickly, you might recover funds before they're moved.
For institutions with limited fraud operations staff, post-processing monitoring is more manageable. You're reviewing flagged transactions, not making hold/release decisions for every payment in real time.
The Case for Pre-Processing Monitoring
Pre-processing monitoring stops fraud before it completes, offering a cleaner operational process and a better customer experience.
Consider the difference: In post-processing, your customer initiates a payment to what they believe is their bank's fraud department. The payment processes, and hours later, your fraud team flags it as suspicious. By then, the receiving account may already be drained. The customer sees the debit on their statement and waits for a return that may never come.
In pre-processing, your system flags the transaction before it moves. Your fraud team contacts the customer: "You just initiated a $15,000 payment to an account we've never seen before. Is this legitimate?" The customer realizes they've been scammed, and the payment never leaves their account.
Pre-processing monitoring also gives you more control over your risk exposure. You're not relying on another institution's fraud detection or willingness to freeze funds. You're making the hold decision yourself, based on your risk assessment.
For credit push fraud, pre-processing has another advantage: the victim is still engaged. If you interrupt the moment with a fraud alert, they're more likely to recognize the scam.
The operational cost is real, though. Pre-processing monitoring introduces latency. Your fraud rules must execute in milliseconds. You need staff available to review holds in real time, and you'll generate more false positives.
Where Practitioners Actually Land
Most institutions are implementing hybrid models. High-risk transactions get pre-processing review, large dollar amounts, new receivers, unusual Standard Entry Class codes. Everything else flows through to post-processing monitoring.
The risk assessment drives the split. If your originator population includes businesses with regular high-value payments, you may set a higher dollar threshold for pre-processing holds. If you serve consumers who rarely initiate ACH credits, any outbound credit might warrant pre-processing review.
The gap analysis is crucial. Many organizations already have fraud detection systems that can identify red flags. The question is where to insert the monitoring decision point in your existing payment flow.
Third-party providers offer both models, and the vendor vetting process should clarify which approach each solution supports. Some tools are optimized for real-time decisioning, while others are built for post-processing batch analysis.
Our Take
Pre-processing monitoring is worth the operational cost for credit push fraud specifically.
This fraud type depends on immediate action by the victim. Automated push payment scams create urgency. If you can interrupt that moment with a legitimate fraud alert, you break the attack.
Post-processing monitoring still has a role. You can't pre-process every transaction without disrupting your payment operations. But the high-risk scenarios that Nacha's rules address, social engineering attacks that trick customers into initiating fraudulent payments, are where pre-processing intervention is most effective.
The rule's flexibility is intentional. It allows institutions to implement risk-based processes that fit their customer base and operational capacity. But when conducting your risk assessment and setting monitoring thresholds, prioritize pre-processing for outbound credits, new receivers, and unusual transaction patterns.
Doing nothing isn't an option. Marsh made that clear: conducting a risk assessment and concluding you don't need monitoring isn't acceptable. The question isn't whether to monitor, it's when.
