ACH Fraud Controls, Debit Blocks and Filters. A practitioner deep dive into ACH fraud monitoring, debit blocks and filters, 2026 Nacha requirements, account validation, ODFI/RDFI controls, credit-push fraud, return-rate signals, decisioning, reconciliation and real-bank operations.
ACH fraud control is not one product, one score or one rule. It is a set of decisions made by several parties before, during and after an ACH entry moves through the Network. The Originator decides whether a payment instruction is genuine. The ODFI decides whether it is willing to originate that entry. The RDFI decides how to protect receiving accounts and how to monitor incoming activity. Third-Party Senders and processors may perform important parts of that work, but they do not make the underlying responsibility disappear.
Chapter 12 therefore asks a practical banking question:
How does a bank reduce the chance that an ACH entry is fraudulent, unauthorized or fraud-induced without turning every legitimate payment into an exception?
The answer requires layered controls. Authentication and entitlements reduce account takeover. Dual approval reduces insider and credential risk. Account validation improves account-data confidence. Originator profiling helps identify unusual activity. Debit blocks and filters protect corporate accounts from unwanted ACH debits. RDFI credit monitoring helps identify suspicious incoming credit-push activity. Return-rate monitoring identifies poor origination quality. Reconciliation, alert handling and customer communication prove whether controls actually worked.
The 2026 Nacha fraud-monitoring changes make this topic especially important. Phase 1 became effective March 20, 2026. It applies to all ODFIs, to higher-volume non-consumer Originators, Third-Party Senders and relevant Third-Party Service Providers, and to higher-volume RDFIs for incoming ACH credit monitoring. Phase 2 has a formal effective date of June 19, 2026; because that date is a federal holiday, Nacha states that the practical compliance date is Monday, June 22, 2026. Phase 2 removes the volume thresholds for the affected non-consumer Originators/TPSPs/TPSs and RDFIs. The rules are deliberately risk-based and technology-neutral rather than prescribing one vendor, one algorithm or one score.
The governing mental model for this chapter is:
customer identity → entitlement → payment intent → beneficiary/account confidence → transaction risk monitoring → ODFI release decision → ACH processing → RDFI receiving controls → posting/return decision → alert investigation → accounting/reconciliation → feedback into future controls.
This chapter does not repeat Chapter 9’s detailed authorization rules or Chapter 11’s return/reversal/NOC mechanics. Chapter 13 will go deeper into research and investigation. Here the focus is preventive and detective ACH fraud control design, especially the control decisions a real bank, Originator and RDFI must make.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–4, Sections 6–9 and Sections 12–15. For the next 10 minutes, use the chapter’s three diagrams to locate each fraud decision and its operational owner. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: How should a legitimate debit blocked by an account filter be investigated and resolved? 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 ACH fraud control really means
- Fraud patterns: unauthorized entries, false pretenses and account takeover
- The 2026 Nacha fraud-monitoring requirements
- Participants and control ownership across the ACH chain
- Originator controls before an ACH entry is created
- ODFI monitoring, exposure and release controls
- Account validation, beneficiary controls and change-risk management
- RDFI debit blocks, debit filters and ACH Positive Pay patterns
- RDFI incoming-credit monitoring and credit-push fraud
- Return-rate monitoring, thresholds and quality signals
- Fraud rules, scoring, alerts and decision orchestration
- Statuses, holds, returns and customer communication
- Settlement, accounting and reconciliation under fraud controls
- Reporting, MI, model governance and control effectiveness
- Real-bank operating model, resilience and control governance
- End-to-end cases, BA checklist and testing
1. What ACH fraud control really means
Fraud control begins by separating several questions that are often mixed together.
Was the person or system genuine? That is an authentication question.
Was that person entitled to create or approve this payment? That is an entitlement question.
Did the account holder or business actually permit the ACH entry? That is an authorization question.
Was the payment authorized but induced by deception? That is a false-pretenses or fraud-inducement question.
Does the receiving account want to permit this type of debit? That is where RDFI-side debit blocks and filters become relevant.
Does the transaction look abnormal compared with the customer’s normal behavior? That is a transaction-monitoring question.
A bank that puts all of these into one field called fraud_check = PASS loses the information needed to explain a decision later.
A practical control model is layered:
identity control → entitlement control → authorization/approval → beneficiary/account control → behavioral/transaction monitoring → release decision → receiving-side monitoring → post-event feedback.
Prevention and detection are different
A debit block can prevent an unwanted ACH debit from posting to a corporate account. A velocity alert can detect an unusual burst of outgoing credits. A return-rate dashboard can identify a poor-quality Originator after patterns emerge. These are all risk controls, but they operate at different moments.
Prevention tries to stop the suspicious event before financial harm.
Detection identifies something suspicious enough to review, hold, return, escalate or investigate.
Monitoring also supports learning. If many fraud cases share the same beneficiary-change pattern, the bank can tighten the control at beneficiary setup rather than waiting for the transaction stage.
Fraud control is not the same as sanctions or AML
ACH fraud monitoring, sanctions screening and anti-money-laundering monitoring can share data and alerting infrastructure, but they answer different questions.
A payment may be legitimate from the customer’s perspective but prohibited by sanctions law. A payment can be permitted from a sanctions perspective but fraudulent. A receiving account can look like a money-mule account from an AML perspective even when the ACH message itself is syntactically valid.
The bank should allow those controls to share intelligence without collapsing them into one decision reason.
Risk-based does not mean vague
Nacha’s 2026 rules are risk-based and technology-neutral. That does not mean a bank can simply document “we monitor fraud” and stop there.
A risk-based program should be able to explain:
- which populations are monitored;
- which risks the controls address;
- what data is used;
- when alerts are created;
- who reviews them;
- how urgent decisions are handled;
- how false positives are measured;
- how controls are tuned;
- how evidence is retained.
Risk-based flexibility should produce a design appropriate to the institution, not an absence of design.
2. Fraud patterns: unauthorized entries, false pretenses and account takeover
ACH fraud does not have one shape.
An unauthorized debit can occur when an Originator sends an ACH debit without valid permission, after authorization was revoked, or in another manner that does not conform to the applicable authority. Chapter 9 owns the detailed authorization framework; Chapter 12 focuses on the controls that reduce the chance of such entries being created or accepted.
An unauthorized credit can occur when a criminal takes over an account or payment channel and sends money without the real customer’s permission.
A payment authorized under false pretenses is different. The real customer may log in, approve the payment and pass all authentication controls, but only because a fraudster deceived the customer. Business email compromise is a classic corporate example: a fraudster impersonates a supplier, sends changed banking instructions, and convinces an employee to approve a genuine payment to the fraudster-controlled account.
This distinction explains why authentication alone cannot solve credit-push fraud.
A bank can prove that the legitimate corporate user logged in with multifactor authentication. It can prove that two approvers released the transaction. Yet the payment may still be fraud-induced because the beneficiary master was changed after a deceptive email.
Common fraud scenarios
Corporate ACH risks can include:
- compromised online-banking credentials;
- malware or session takeover;
- fake supplier bank-detail changes;
- payroll diversion after employee-account change fraud;
- insider manipulation;
- duplicate or unauthorized file submission;
- compromised API credentials;
- fraudulent account-to-account transfers;
- money-mule receiving accounts;
- unauthorized ACH debits against corporate accounts.
Consumer-facing risks can include account takeover, fraudulent WEB debit origination, deceptive merchant activity, scam-induced credit pushes and misuse of stolen account information.
Fraud classification should not be inferred from direction alone
ACH debits historically receive heavy unauthorized-transaction attention because the Originator pulls funds from the Receiver. But credit-push fraud has become a major risk because the payer can be deceived into pushing value outward.
The 2026 Nacha changes deliberately broaden monitoring toward unauthorized entries and entries authorized under false pretenses, including incoming ACH credits at RDFIs.
A modern ACH control architecture therefore needs both:
debit-risk controls and credit-push controls.
3. The 2026 Nacha fraud-monitoring requirements
The 2026 amendments are a major shift because more parties in the ACH chain now have explicit fraud-monitoring responsibilities.
Phase 1 — March 20, 2026
Phase 1 applies fraud-monitoring requirements to all ODFIs.
For non-consumer Originators, Third-Party Senders and relevant Third-Party Service Providers, Phase 1 applies when 2023 ACH origination or transmission volume exceeded 6 million entries.
For RDFI incoming-credit monitoring, Phase 1 applies to RDFIs whose 2023 ACH receipt volume exceeded 10 million entries.
The volume numbers are scope thresholds for Phase 1. They are not fraud transaction limits and should never be used as customer-payment limits.
Phase 2 — June 2026
Phase 2 has a formal effective date of June 19, 2026. Nacha’s operations guidance notes that June 19 is a federal holiday, so the practical effective date is the next Banking Day, Monday, June 22, 2026.
Phase 2 removes the volume threshold for the remaining affected non-consumer Originators, TPSPs and TPSs. It also extends the incoming ACH credit monitoring requirement to the remaining RDFIs.
As of October 5, 2026, these requirements are no longer future planning items. Banks and affected organizations should be operating under them.
What the rules require conceptually
The affected origination-side parties must establish and implement risk-based processes and procedures, relevant to their role, that are reasonably intended to identify ACH Entries suspected of being unauthorized or authorized under false pretenses.
RDFIs must establish risk-based processes and procedures for receiving ACH credits that are reasonably intended to identify incoming credit Entries suspected of being unauthorized or authorized under false pretenses and to define how identified suspicious credits are handled.
The Rules do not prescribe one fraud engine, one model, one score threshold or one vendor. Nacha explicitly allows risk-based approaches and provides examples such as velocity checks, anomaly detection, behavioral tolerances and pattern recognition.
Technology neutrality creates governance responsibility
Because the rule does not say “use score 700” or “hold every first payment,” each organization has to justify its own control design.
A small corporate Originator may use dual approval, approved beneficiary controls, change verification, payment limits and bank-provided fraud services.
A large bank may combine customer behavior models, device intelligence, beneficiary risk, file-level analytics, account history, receiving-account intelligence and manual review.
Both can be risk-based. What matters is that the design is proportionate, documented, implemented and monitored.
Existing WEB debit obligations still matter
The 2026 rules do not replace the pre-existing WEB debit fraud-detection/account-validation framework. First-use consumer account information for WEB debit origination remains subject to the account-validation requirement introduced earlier. The broader 2026 monitoring framework sits alongside those specific controls.
4. Participants and control ownership across the ACH chain
Fraud prevention becomes weak when every party assumes someone else is watching.
The Originator owns the business instruction. It knows the employee, supplier, customer, invoice, payroll population or transfer purpose better than the ACH Operator. It is therefore well placed to detect unusual beneficiary changes, duplicate invoices, abnormal payee requests or unexpected user behavior.
The Third-Party Sender can aggregate or process ACH activity for Originators. It may operate file validation, risk rules, exposure controls or monitoring. Under the 2026 framework, TPSs and relevant TPSPs have their own role-based responsibilities rather than functioning as invisible technology pipes.
The ODFI owns the ACH origination relationship into the Network. It needs to understand the risk of its Originators and Third-Party Senders, monitor the activity it transmits, manage exposure, enforce agreements and decide whether entries should be released.
The ACH Operator processes ACH files and entries. FedACH and EPN provide network processing, but the operator is not a substitute for the Originator’s and banks’ fraud-control obligations.
The RDFI sees the receiving account and incoming activity. It can know whether the account is new, dormant, unusually active, restricted, protected by a debit filter or receiving a suspicious pattern of credits. That receiving-account perspective is exactly why RDFI monitoring matters.
The Receiver or corporate account holder also participates in control. A business can define debit blocks/filters, review alerts, protect credentials and report suspicious activity quickly.
Shared responsibility is not duplicated responsibility
Each party sees different evidence.
The Originator sees commercial context.
The ODFI sees origination behavior across the banking relationship.
The RDFI sees the receiving account.
A Third-Party Sender may see patterns across multiple Originators.
A strong model uses these views as layers. It does not assume every party must run the exact same algorithm.
5. Originator controls before an ACH entry is created
The cheapest fraud to handle is often the payment that never gets created.
Corporate Originators should therefore put controls around the business event before the ACH file exists.
User identity and entitlement
A payment creator should be authenticated. Entitlements should define what the user can do: create payments, edit beneficiary data, upload files, approve transactions, release files, change limits or administer users.
The user who can create a beneficiary should not automatically be able to approve a payment to that beneficiary if the organization’s risk model requires segregation.
Dual control
Dual control means more than one person participates in creating/releasing a payment. Nacha’s 2026 Originator guidance includes dual controls among possible layered protections.
Dual control is useful but not infallible. Two employees can both be deceived by the same fake supplier instruction. Therefore dual control should be combined with beneficiary-change verification and transaction-risk checks.
Payee/beneficiary maintenance
Beneficiary changes are high-risk because they can redirect every future payment.
A mature process can distinguish:
new beneficiary
bank-account change
address/contact change
one-time payment override
first payment after change.
The organization may use independent callback verification, trusted contact data, maker-checker approval, cooling periods or enhanced first-payment review depending on risk.
The control should avoid verifying the change using the same compromised email that requested it.
File and API controls
File-based Originators should protect upload credentials, file channels and file identity. Useful controls include file naming standards, expected submission windows, hash/duplicate checks, file totals, allowed Company IDs, expected SEC Codes and approval before release.
API-based origination should use strong authentication, scoped credentials, replay protection, idempotency keys, request signing where appropriate, rate limiting and monitoring of unusual API behavior.
A secure API connection does not prove that the underlying supplier bank-detail change was legitimate. Channel security and payment-fraud control remain separate.
Limits and behavioral tolerances
An Originator may establish payment, batch, daily or user limits. Limits should be risk controls, not invented Nacha thresholds.
A company that normally sends $50,000 of supplier ACH credits per day may choose to require enhanced approval for a $750,000 day. That is an internal risk decision, not a universal network rule.
Useful behavioral questions include:
- Is this a new beneficiary?
- Has the beneficiary account changed recently?
- Is the amount unusually high?
- Is payment being sent outside normal hours?
- Is the user or device new?
- Is the file volume unusual?
- Is the Company ID or SEC Code expected?
- Is the instruction inconsistent with prior invoices or payroll patterns?
6. ODFI monitoring, exposure and release controls
The ODFI is not simply a courier that forwards whatever the Originator sends.
The bank needs a release decision that combines customer agreement, funding/exposure, file validity and fraud risk.
Originator risk profile
The ODFI can maintain an Originator profile including business type, expected ACH products, typical volume/value, SEC Codes, normal submission times, historical return rates, known third-party relationships and agreed limits.
A new utility Originator sending recurring WEB debits has a different risk profile from a long-established employer sending PPD payroll credits.
Exposure is not fraud
ODFI exposure management asks whether the bank could be financially exposed if entries are returned or settlement occurs before funds are secured.
Fraud monitoring asks whether the entries themselves appear unauthorized or fraud-induced.
The same transaction can be low exposure but high fraud risk, or high exposure but perfectly legitimate.
A bank should therefore keep separate decisions such as:
funding_status
exposure_status
fraud_status
file_validation_status
release_status.
File-level and entry-level monitoring
File controls can detect duplicate files, unexpected Company IDs, abnormal total value, unusual batch composition or transmissions outside expected windows.
Entry-level controls can detect new accounts, amount outliers, unusual velocity, repeated beneficiary patterns or other anomalies.
Both are necessary. A fraudster may hide suspicious entries inside an otherwise normal payroll-sized file.
Hold versus reject versus release
A fraud engine can produce several outcomes.
PASS — proceed to normal release checks.
REVIEW — hold internally for authorized review before transmission.
BLOCK — do not transmit until the issue is resolved or the payment is recreated.
These are internal states, not ACH network statuses.
Once an entry has been transmitted, later correction is governed by ACH mechanisms such as returns, reversals or recovery requests. Chapter 11 owns those mechanics.
False-positive cost matters
If the bank holds every unusual payroll file, it may create salary incidents. If it releases every unusual file to avoid customer friction, controls are meaningless.
Risk design therefore needs measurable false-positive and detection performance rather than only “number of alerts.”
7. Account validation, beneficiary controls and change-risk management
Account validation is one layer in ACH risk management. It should not be described as proof that a payment is legitimate.
Nacha’s Account Validation Resource Center explains that first-use consumer account information for WEB debits must be validated under the WEB debit fraud-detection framework. The Rules are technology-neutral. Methods can include prenotification, Micro-Entry verification or commercially available validation services.
What account validation can tell the bank
Depending on the method, validation can help determine whether an account number is open and capable of accepting ACH, and some services can provide additional attributes such as ownership-related information.
But the bank must know what its chosen method actually proves.
A routing/account check may tell the Originator that an account exists. It may not prove that the supplier who emailed the account change owns it.
A prenote is a non-monetary ACH entry. It can support account-data validation but should not be treated as identity proof.
Micro-Entries use small ACH credits and permitted offsetting debits within the specific rule framework. Successful verification is stronger evidence of account access than simple syntax validation, but it still belongs inside a broader fraud-control model.
Account validation versus beneficiary verification
These are different.
account validation asks whether the receiving account information is usable/valid according to the method.
beneficiary verification asks whether the account belongs to or is legitimately controlled by the intended beneficiary.
payment authorization asks whether the payer approved the transaction.
A bank or Originator may use all three where appropriate.
Change-risk controls
A first payment after beneficiary change is often higher risk than the hundredth payment to a stable beneficiary.
Useful controls include:
- enhanced approval after account change;
- independent callback using trusted contact details;
- first-payment amount cap under customer policy;
- temporary review period;
- comparison with invoice or supplier-master data;
- alerting on rapid payee creation-and-payment behavior.
None of these should be presented as universal Nacha requirements. They are examples of risk-based controls an organization can adopt.
8. RDFI debit blocks, debit filters and ACH Positive Pay patterns
Debit blocks and filters are receiving-side controls used especially for business accounts.
Nacha has described debit blocks and debit filters as services an RDFI may offer to business customers to protect accounts against unauthorized debits. They are not intended as a mechanism for avoiding legitimate obligations.
Debit block
A debit block is the simplest concept: do not allow ACH debits to post to the protected account, subject to the bank’s product design and permitted exceptions.
This can be appropriate for an account that should only receive credits or where all outgoing activity is controlled through other mechanisms.
The block should be explicit in the account-control profile. It should not rely on an operations user remembering to return unwanted entries manually every morning.
Debit filter
A debit filter is more selective.
The customer can define rules such as:
- approved Originator/Company IDs;
- expected debit transaction types;
- amount ceilings;
- specific accounts;
- one-time exceptions;
- recurring authorized debit relationships.
The exact commercial product varies by bank.
A filter decision can be modeled as:
incoming ACH debit → account control profile → Company ID/criteria match → allow, review or return according to product/rule handling.
ACH Positive Pay
Many banks use terms such as ACH Positive Pay for customer-facing services that allow business customers to review or pre-authorize ACH debits. The name and implementation are bank products, not one universal Nacha network service.
A common pattern is:
incoming debit → compare to approved rules → exception alert → customer decision before bank cutoff → post or return.
The product must define what happens if the customer does not respond. Default-post and default-return create different risk/customer outcomes.
Company ID controls need governance
Company ID is a useful attribute but should not be treated as cryptographic identity.
If the customer approves Company ID 1234567890, the bank can use that value as part of a filter. But control design should consider how Company IDs are maintained, whether multiple legitimate IDs exist and how changes are approved.
Debit filters do not replace authorization
A debit passing a filter does not prove the Originator has valid authorization under Chapter 9.
The filter says the business account has chosen to allow that pattern. Authorization is a separate legal/rule relationship.
9. RDFI incoming-credit monitoring and credit-push fraud
The 2026 rules make RDFI monitoring of incoming ACH credits a formal part of the fraud-control story.
This is important because the receiving bank sees information the sending side may not have.
The RDFI can know:
- age of the receiving account;
- normal balance and transaction behavior;
- sudden changes in credit velocity;
- whether the account was dormant;
- whether many unrelated Originators suddenly send credits;
- whether funds are rapidly moved onward;
- whether the SEC Code is unusual for the account type;
- whether prior fraud or mule indicators exist.
Nacha specifically describes risk-based RDFI approaches and notes factors such as velocity, anomalies and account characteristics.
Incoming credit does not automatically mean safe funds
A credit posting to an account is not proof that the payment is legitimate. A mule account can receive funds from a defrauded corporate payer.
The RDFI therefore needs a defined handling process when incoming credits are suspected of being unauthorized or authorized under false pretenses.
Possible internal outcomes can include enhanced review, account restriction under applicable bank/legal authority, communication with fraud/operations teams, contact with the ODFI, or an ACH return where the rules and facts support it.
The chapter should not invent a universal “hold every suspicious credit” requirement. The rule is risk-based and institutions must align handling with ACH rules, customer agreements, law and their internal risk framework.
Credit monitoring must not destroy funds-availability logic
Fraud review and customer funds-availability obligations must be understood together. A bank cannot solve fraud risk by ignoring applicable funds-availability requirements.
Where the bank has a lawful/rule-based reason to restrict or return funds, the action should be documented clearly. Where no such basis exists, an internal fraud score should not silently become an indefinite hold.
Receiving-account intelligence can support recovery
If an RDFI identifies suspicious incoming credits quickly, it may be better positioned to prevent dissipation of funds and respond to bank-to-bank recovery communication.
Chapter 11 explained Request for Return. Chapter 12’s lesson is that early detection increases the chance that recovery processes have something left to recover.
10. Return-rate monitoring, thresholds and quality signals
Return rates are important risk and quality indicators for ACH debit origination.
Nacha distinguishes an Unauthorized Return Rate Threshold from the Administrative Return Rate Level and Overall Return Rate Level.
Unauthorized Return Rate Threshold — 0.5%
The unauthorized debit return-rate threshold is 0.5%. It covers the specified unauthorized return reasons in the Nacha framework.
This is a threshold with enforcement significance. It should not be described as “fraud is acceptable up to 0.5%.” The correct interpretation is that excessive unauthorized returns are a serious origination-quality/risk signal and can trigger ODFI obligations under the Rules.
Administrative Return Rate Level — 3.0%
The administrative return-rate level is 3.0% and focuses on specified account/data-related return reasons such as R02, R03 and R04.
This is called a level rather than the same kind of threshold. Exceeding it can trigger preliminary inquiry into origination practices; it is not automatically identical to a Rules violation.
Overall Return Rate Level — 15.0%
The overall debit return-rate level is 15.0%, with RCK treatment handled according to the rule calculation framework.
Again, this is an inquiry/evaluation level, not a statement that a 14.9% return rate is healthy.
A bank can impose tighter internal monitoring long before a network threshold or level is reached.
Calculation discipline matters
Nacha provides calculation methods using preceding 60 days or two calendar months. A bank should implement the chosen rule method consistently and retain numerator/denominator evidence.
A dashboard that counts returns by the month they were received without linking them correctly to originated debits can produce a misleading rate.
Rates need segmentation
Useful segmentation includes:
Originator
Third-Party Sender
SEC Code
Company ID
product
channel
reason family
consumer/corporate.
A blended portfolio rate can hide one high-risk Originator inside millions of clean entries.
Return rate is not the same as fraud rate
Insufficient funds can drive returns without fraud. Administrative returns can reflect poor account data. Unauthorized returns may signal weak authorization or deceptive behavior, but root-cause investigation is still required.
The safest interpretation is:
return data is risk telemetry; it is not a complete fraud verdict.
11. Fraud rules, scoring, alerts and decision orchestration
A modern fraud engine often combines deterministic rules and statistical or machine-learning models.
A deterministic rule can say:
new beneficiary + amount > customer-defined threshold → enhanced review.
A behavior model can compare the transaction with historical patterns and produce an anomaly score.
A consortium or receiving-account service can contribute external risk information where permitted.
The bank then needs decision orchestration: how do these signals become a release, review, block or escalation outcome?
Separate signal from decision
A high-risk signal is not the final decision.
Useful data fields include:
signal_code
signal_score
model_version
rule_version
decision
decision_reason
reviewer
decision_timestamp.
That distinction becomes essential when a model is recalibrated later.
Alert queues need priority
Not every alert has the same urgency.
A payroll file waiting for a Same Day ACH window may have minutes available for review. A future-dated supplier file may have hours. An incoming suspicious credit into a rapidly draining account may need immediate fraud-team attention.
Queue priority can consider:
time_to_cutoff
financial_value
customer criticality
risk score
funds movement velocity
manual action required.
Explainability matters operationally
Operations cannot act effectively on risk_score = 913 with no reason.
Human-readable drivers are more useful:
New supplier account added 45 minutes ago
Payment 8.4x customer normal maximum
New device and new beneficiary
Receiving account has abnormal incoming-credit velocity.
The underlying model may be complex, but the operational decision should be explainable enough to review and audit.
Manual override needs governance
If an analyst can override a fraud block, the system should record who did it, why, what evidence was reviewed and whether second-level approval was required.
A fraud engine with unlimited unaudited manual override is not a controlled system.
12. Statuses, holds, returns and customer communication
Fraud controls create states that should not be confused with network status.
Before ACH transmission, internal states might be:
RISK_SCREENING
FRAUD_REVIEW
CUSTOMER_CONFIRMATION_REQUIRED
BLOCKED_BEFORE_RELEASE
RELEASED_TO_ACH.
After transmission, the bank should preserve network facts separately:
OPERATOR_ACCEPTED
SETTLED
RETURN_RECEIVED.
A payment can be SETTLED at the ACH layer while a related fraud investigation is still open.
Hold language must be precise
Customer-facing teams should distinguish:
“Payment is under bank review and has not been released”
from
“Payment has been sent and we are trying to recover it.”
Those situations have completely different recovery options.
Fraud alert does not equal unauthorized ACH return
An internal fraud alert may eventually lead to an ACH return, but only if the return is permitted under the applicable facts and rules.
Chapter 11 explains those mechanisms. Chapter 12 should teach that the fraud system must not generate arbitrary network returns just because an internal model score is high.
Debit-filter exception communication
For business accounts using ACH debit filters/Positive Pay, the customer needs clear information:
- Originator/Company ID;
- amount;
- effective/posting date;
- decision deadline;
- approve/allow instructions;
- consequences of no response under product terms.
The screen should not force the customer to understand raw Nacha record structure to make the decision.
13. Settlement, accounting and reconciliation under fraud controls
Fraud controls interact with money movement, but timing matters.
A transaction blocked before ACH release has no ACH interbank settlement event. Internal holds or customer-account reservations may exist depending on product design, but the bank should not record network settlement that never occurred.
A transaction detected after operator transmission may settle unless an applicable network or bank process changes the outcome.
A receiving-side debit filter can result in the RDFI returning an unwanted debit. In that case, Chapter 11’s return lifecycle creates a separate financial exception and settlement effect.
A suspicious incoming credit may post, be returned under an applicable reason, become subject to internal restriction under appropriate authority, or become part of a recovery case. Those outcomes have different accounting.
Fraud reserve versus settlement position
An internal fraud-loss reserve or suspense account is not the ACH settlement position.
Banks should distinguish:
ACH settlement/control account
customer ledger posting
fraud suspense/recovery receivable
loss reserve/write-off
returned-item settlement.
The exact GL design varies by bank. The control objective is that each financial event can be traced to the ACH event and fraud-case outcome.
Reconciliation should prove both money and control action
A bank should reconcile:
payments screened
payments released
payments blocked
payments reviewed
against
ACH files transmitted
and later
operator acceptance/settlement.
If 10,000 entries passed fraud screening but only 9,998 reached the ACH file, two entries need an operational explanation.
Likewise, an inbound debit blocked by Positive Pay should reconcile to the actual return/exception outcome rather than disappearing from customer history.
14. Reporting, MI, model governance and control effectiveness
A fraud program is not strong because it generates many alerts.
Management information should show whether the controls reduce loss and unauthorized activity without creating unacceptable customer friction.
Useful metrics include:
- screened ACH entries and value;
- alerts by control/rule/model;
- block, review and release decisions;
- confirmed fraud value;
- prevented fraud value using documented methodology;
- false-positive rate;
- customer-confirmation rate;
- beneficiary-change alerts;
- account-validation failure rate;
- debit-filter exceptions and customer decisions;
- suspicious incoming-credit alerts;
- unauthorized/admin/overall return rates;
- alert ageing and review time;
- manual override volume;
- recovery outcomes after fraud;
- missed or late control decisions.
Model and rule versioning
A fraud decision should be reproducible.
If a transaction was blocked on August 10, operations should be able to determine which rule set/model version produced the alert at that time.
Do not overwrite historical cases with today’s recalculated score unless the system clearly labels it as a retrospective score.
Tuning requires governance
A rule that generates 98% false positives may need tuning. But lowering sensitivity to improve customer experience can increase fraud loss.
Changes should therefore have documented rationale, testing, approval and post-change monitoring.
Return rates are control feedback
If unauthorized returns rise after a fraud-rule change, the bank should investigate whether the control became too weak.
If administrative returns rise after account-validation changes, the bank may have a data-quality problem.
Control effectiveness should connect fraud alerts, ACH outcomes and return data rather than analyzing each in isolation.
15. Real-bank operating model, resilience and control governance
Fraud control has to work at 2:00 a.m., during outages and near cutoffs—not only in design documents.
Operating ownership
A real bank may divide responsibility among payments operations, fraud operations, treasury services, information security, customer service, compliance, relationship management and technology.
The important thing is not which department name owns the control. It is whether the handoff is explicit.
For example:
fraud engine alert → payment operations hold → fraud analyst review → relationship/customer verification → release/block decision → ACH processing → reconciliation.
Resilience
If the fraud engine is unavailable, the bank needs a defined fail-safe or fail-operational policy.
Automatically releasing everything because “fraud is down” can be unsafe.
Automatically blocking every payment can miss payroll and critical supplier obligations.
The contingency design may vary by product and risk: lower limits, manual review, restricted populations, delayed release or alternate controls.
The decision must be intentional and tested.
Idempotency
A replayed payment instruction should not create a second fraud-approved payment simply because the first API response timed out.
Stable payment IDs and idempotency controls should operate before fraud review and through ACH submission.
Control changes are production changes
Changing an allow list, Company ID filter, fraud threshold or beneficiary-rule configuration can move money. Such changes need access control, audit evidence and appropriate approval.
Third-party dependency
If the bank uses a vendor for account validation, device risk or fraud scoring, the bank still needs to understand service availability, data quality, fallback behavior and evidence retention.
A vendor response code that nobody in operations can interpret creates operational risk even if the model is sophisticated.
16. End-to-end cases, BA checklist and testing
Case 1 — fake supplier bank-detail change
A corporate receives an email appearing to come from a supplier asking that future invoices be paid to a new account.
The employee updates the beneficiary master. The payment is then created for $420,000.
Strong controls can detect several risk events before ACH release: beneficiary account changed recently, amount is high, contact verification has not been completed, and the payment is the first to the new account.
The correct control story is not “MFA passed, so payment is safe.”
It is:
user authenticated → beneficiary change detected → independent verification required → payment held → verified with trusted supplier contact → release or reject based on evidence.
Test that the same email address used to request the change is not automatically treated as independent verification.
Case 2 — account takeover sends outgoing ACH credits
A fraudster obtains corporate credentials and tries to upload an ACH credit file at 2:30 a.m. from a new device. The file has a new Company ID pattern and beneficiaries never used before.
The bank’s ODFI monitoring generates an alert. The payment remains internal and is not released to ACH while the bank confirms the instruction.
Test authentication evidence, device/new-session signal, file-level anomaly, hold status, customer contact and timeout/escalation behavior.
Case 3 — unauthorized corporate ACH debit
A business account normally accepts ACH debits only from three approved Originators. A debit arrives with an unapproved Company ID.
The RDFI’s debit filter creates an exception. Depending on the customer product, the item may default to return, require customer decision or follow another defined path.
Test Company ID matching, amount rules, decision cutoff, no-response behavior, customer audit trail and actual ACH return linkage.
Case 4 — legitimate debit blocked by poor filter maintenance
A corporate changes utility provider but forgets to update its ACH debit filter. The first legitimate utility debit arrives and is blocked.
This is a false positive created by stale customer control data.
Test customer communication, filter-maintenance entitlement, one-time approval, future allow-list update and reporting so operations can distinguish genuine unauthorized debits from customer-configuration errors.
Case 5 — suspicious incoming credit to a mule account
A recently opened consumer account begins receiving multiple large ACH credits from unrelated corporate Originators and rapidly transfers funds out.
The RDFI incoming-credit monitoring detects abnormal velocity and account behavior. The fraud team reviews the account and coordinates appropriate handling.
Test that the system distinguishes the network fact CREDIT_RECEIVED/SETTLED from the fraud-case state SUSPICIOUS_INCOMING_CREDIT.
Case 6 — WEB debit first-use account validation
A consumer enters a new bank account online for recurring subscription debits.
The Originator must apply the WEB debit first-use account-validation requirement through its chosen compliant method before live debit processing according to the applicable rule framework.
Test new versus previously validated account, changed account number, validation result, evidence, failure handling and prevention of live debit release before required validation is complete.
Case 7 — Originator unauthorized return rate rises
An Originator’s unauthorized debit return rate rises sharply toward/above the Nacha threshold.
The ODFI should not wait for a monthly meeting to discover it. Monitoring should calculate the rate using the correct Nacha methodology, identify the contributing return reasons, segment by SEC Code/channel and trigger the applicable risk/compliance process.
Test numerator/denominator lineage and the difference between the 0.5% unauthorized threshold, 3% administrative level and 15% overall level.
Case 8 — fraud engine outage before payroll cutoff
A payroll customer sends a valid 25,000-entry file. The bank’s primary fraud engine is unavailable shortly before the customer’s release cutoff.
The bank should execute its documented contingency policy rather than improvising. Depending on risk design, it may use alternate controls, reduced functionality, manual review or another controlled decision path.
Test that the outage does not automatically mark every payment as FRAUD_PASS.
BA requirements checklist
Before approving an ACH fraud-control design, ask:
- Are authentication, entitlement, authorization, fraud monitoring and sanctions/AML states separate?
- Can the platform identify entries suspected of being unauthorized or authorized under false pretenses?
- Are the 2026 Nacha Phase 1/Phase 2 populations and practical June 22 date understood correctly?
- Does the Originator/ODFI control model cover beneficiary changes, file/API security, duplicate detection, limits and behavioral monitoring?
- Is account validation implemented correctly for applicable WEB debit first-use account data?
- Does the system know what the validation method actually proves?
- Are corporate debit blocks and filters modeled as customer/account controls rather than universal Nacha mandates?
- Can debit filters use Company ID, amount and other bank-supported criteria with governed maintenance?
- Is incoming ACH credit monitoring implemented at the RDFI with risk-based handling?
- Are unauthorized, administrative and overall return-rate measures calculated correctly?
- Does the platform distinguish threshold from inquiry level?
- Are rule/model signals stored separately from final decisions?
- Are manual overrides entitled and auditable?
- Can customer-facing statuses distinguish pre-release review from post-settlement recovery?
- Does fraud screening reconcile to actual ACH files and settlement outcomes?
- Are model/rule versions retained?
- Are false positives measured?
- Is there a tested fraud-engine outage policy?
- Can third-party service failures be handled safely?
Testing minimum
A serious Chapter 12 test pack should include new-beneficiary credits, beneficiary-account changes, file duplicates, credential compromise, unusual upload times, high-value outliers, payroll criticality, WEB first-use validation, failed validation, debit block, debit allow-list, amount filter, Company ID change, Positive Pay approval and no-response behavior, incoming-credit velocity alerts, mule-account patterns, return-rate threshold calculations, rule/model version changes, manual overrides, fraud-engine outage, replay/idempotency and reconciliation breaks.
The final practitioner principle is:
A good ACH fraud control does not simply ask whether a transaction looks strange. It knows who is acting, what that party normally does, what account or beneficiary is involved, what the ACH rules require, what the bank is allowed to do before and after settlement, and what evidence will prove the decision later.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.