What Is Positive Pay? How Platforms Protect Against Check Fraud and Unauthorized ACH Debits

How Positive Pay helps prevent check fraud and unauthorized ACH debits#

Positive Pay needs a daily decision process. A flagged item is useful only if an authorized reviewer can inspect it, submit the appropriate decision before the bank deadline and confirm that the bank recorded it.

Two-rail coverage. Positive Pay applies to both check and ACH payment streams, and that split matters in day-to-day operations. Check Positive Pay addresses check risk. ACH Positive Pay adds a control layer that restricts which ACH transactions can post to your accounts. If your platform issues checks and also carries ACH debit exposure, covering only one rail can leave a gap.

Exception decisions are the real control. The value of Positive Pay shows up in exception handling, because flagged payments still need a business decision. In practice, potentially fraudulent payments are identified so businesses can approve or reject them, and pending exceptions are tied to cutoff notifications. What matters most is not alert volume but timing. If you cannot name the decision owner for every exception before the bank's deadline, you do not yet have a setup that is likely to hold up in production.

A good checkpoint is simple: pull one day of exceptions and verify that each item has an owner, a pay or return decision, and a timestamp another reviewer could follow later. One failure mode is an unowned queue. Once items sit unresolved near cutoff, teams start rushing decisions or chasing approvals in chat and email. That weakens both the control and the record.

Governance matters as much as configuration. This article is written for compliance, legal, finance, and risk owners because Positive Pay decisions may become reviewable records, not just treasury operations. That framing matters. The ICBA's October 2025 guide presents Positive Pay through a checklist of operational considerations, and it also explicitly warns that such materials should not be taken as legal advice.

What matters here is defensibility. Your setup should leave an audit trail that shows what was flagged, who decided, when they decided, and what support they reviewed.

The goal is practical: reduce check fraud and unauthorized ACH debit exposure with controls that can stand up under review. In practice, that means clear ownership, enforceable decision timing, and records you can export without reconstructing events by hand. Just do not assume one bank program's rules, cutoffs, or approval expectations carry over to another.

How to choose a Positive Pay setup for your platform#

Choose for evidence, not feature count. If your team runs multi-entity payouts with recurring ACH debit exposure and check issuance risk, use a setup where a user with real account decision authority can decide each exception before cutoff. If you cannot prove who approved or returned each exception item, do not treat the setup as production-ready.

If the platform cannot make bank-account decisions, assign that step to the authorized account owner or bank-partner workflow. Internal triage can support the decision, but does not confer account authority.

Record the contracted cutoff and time zone for each service and exception type. Check daylight-saving treatment, holiday calendars and the default pay or return action. Test both primary and backup access before relying on an alert.

Before choosing, request one sample day of exceptions, one sample export, and exact cutoff rules by rail. This usually surfaces the real risk early: an unowned decision queue when deadlines hit.

For a platform-specific look at check controls, see Positive Pay for Platforms: How Check Fraud Prevention Works in Digital Payment Systems.

Check Positive Pay and ACH Positive Pay compared for platform risk owners#

Check Positive Pay and ACH Positive Pay are complementary, not interchangeable: one validates check presentment against issued-check data, while the other constrains ACH debits using authorized-originator logic.

1. Scope first: choose by rail exposure, not by feature list#

Use check controls for check-presentment risk and debit filters for incoming ACH debit exposure. If both apply, assess both services. ACH Positive Pay does not by itself screen outgoing ACH credits or prevent a fraudulent authorized payment instruction.

2. Inputs are the control surface#

For checks, the issued-check file is the control. If it is late, valid items can be pushed into exceptions due to your own timing. For ACH, the control is filter precision. Overbroad filters can let unwanted debits post, while overly restrictive filters can overload manual review.

3. Exception timing determines outcomes#

Both rails route nonmatching items to exception decisioning, and non-decision within the defined window can result in return processing. In ACH programs with short windows, this is especially operational: alerts alone are not enough if no entitled approver can act before cutoff.

Common failure modes:

1. Stale issued-check data.
2. Overbroad or poorly tuned ACH filters.
3. Delayed exception decisions in the queue.

The five Positive Pay operating models and what each is best for#

Use the lightest model that still lets you prove three things on demand: what data was submitted, who made each pay/return decision, and whether each decision was made before cutoff.

Where the bank offers a Positive Pay API, verify its supported issue-file, exception and decision endpoints. Test permissions, response meanings and cutoff handling for that exact program. An accepted API request and a completed bank decision can be different stages.

For deeper context on rule design tradeoffs, see Fraud Detection for Payment Platforms: Machine Learning and Rule-Based Approaches.

Minimum control stack to launch without overbuilding#

If you're launching with limited time or headcount, prioritize decision quality over automation depth. A workable minimum stack is: complete bank-matching inputs, clear exception ownership, enforceable decision timing, and retained decision evidence.

Set the review deadline from the actual bank cutoff, leaving time for required second approval and submission. Keep account, service, exception type, time zone and business-day rules with the deadline; one SLA per rail can hide different bank programs.

Export the decision history before the bank’s retention window expires. Retain it under your approved record policy, with account scope, item identity, evidence, reviewer and bank acknowledgment. Track aged exceptions, returns and repeated suspicious patterns.

Daily exception handling that stands up to audit review#

Daily exception handling should produce one outcome: each item is decisioned on time, with evidence and an audit trail you can retrieve later.

Ingest alerts and classify the item before anyone decides#

Reconcile notifications to the actual bank exception queue, then classify each item by rail, reason and deadline. Test alert delivery to authorized reviewers and backups; a reminder schedule is a program setting, not a substitute for checking the queue.

Apply the pay-or-return decision from item-level evidence#

Each exception needs an explicit pay/return (or approve/return) decision based on the record, not on queue-clearing speed. For check exceptions, review the exception reason and check image before deciding. For ACH exceptions, review each transaction and decide whether to approve or return it. If your program applies a default action at cutoff, make sure the team knows that setting and its consequence for undecided items.

Separate review and approval where your setup supports it#

Avoid concentrating evidence review, decision submission, and record verification in one person when your platform can enforce separation. Dual-approval decisioning is available in some setups, including a secondary approver after the first approver submits. If you use dual approval, test primary and backup access regularly so approvals do not stall near cutoff.

Close the queue with audit-ready records, then monitor exceptions#

Close an item only after checking the bank’s decision status or acknowledgment. Preserve the submitted decision, reviewer, timestamp, evidence and any default action the bank applied. A local button click without bank confirmation is insufficient proof that the item was paid or returned.

Escalation rules for suspicious activity across checks and ACH#

When suspicious activity repeats across related items, treat it as a pattern case, not routine queue work. Use a documented escalation matrix that contains risk quickly without turning every anomaly into a legal event.

Escalate urgent items and linked patterns#

Escalate a single high-value or clearly suspicious item immediately when the risk or cutoff requires it. Link repeated unauthorized debits, counterfeit checks or bursts into a pattern case, using account, originator, counterparty or check-range references. Repetition strengthens an investigation; it is not a prerequisite to action.

Attach available item evidence without delaying urgent containment: return reason, originator ID, check image, timestamps and decision history. Nacha’s fraud-monitoring rules took effect in phases on March 20 and June 19, 2026. By October 2026, the volume threshold no longer limits the covered non-consumer originators, third-party senders and service providers; apply duties according to the participant’s role. Positive Pay is one control, not proof of full rule compliance.

Use tiered escalation with explicit handoffs to compliance and legal#

A practical matrix is operations triage, then compliance review, then legal or bank-partner involvement when internal suspected-fraud thresholds are crossed. Each handoff needs a named owner, deadline, and required evidence set.

For an institution with SAR duties, assess the applicable rule and reporting criteria. Under the FDIC rule for covered banks, the usual deadline is 30 calendar days from initial detection of facts that may constitute a filing basis; when no suspect is identified, it may extend to 60 days. A first raw alert is not necessarily that detection point, and platform teams do not automatically inherit a bank’s filing duty. Coordinate urgent cases with the responsible compliance team.

Apply containment by rail, and keep controls scoped and reversible#

Ask the bank which debit blocks, filters and return actions the account supports. If your platform originates debits, do not reinitiate a returned unauthorized entry or continue using revoked authorization. Resolve the return reason with the ODFI; a genuinely new debit authorization obtained after the return is distinct from retrying the returned entry.

For checks, temporary counterparty freezes or mandatory dual approval for high-risk items can buy investigation time. Scope the action to the suspect stream first, verify bank-side setting changes the same day, and define owner, start time, and exit criteria so containment does not unintentionally block legitimate activity.

Related: Velocity Checks for Payment Platforms: How to Cap Payout Frequency and Amount to Prevent Fraud.

Common failure modes and monthly control testing#

Monthly testing should answer two questions first: did the bank receive complete, matchable data, and was every exception decisioned with evidence before cutoff. Most breaks come from operational drift, not obvious fraud spikes.

Data integrity drift#

Test issued-check feed completeness, accepted imports and matching fields. Missing issue data can itself create a no-issued-item exception; it does not mean the bank cannot flag the check. Verify payee-name matching separately because basic Positive Pay may check number and amount without payee verification. For ACH, test the supported originator and amount filters.

Process reliability gaps#

Test the contracted deadline and default action for each service. Include an unresolved item, a rejected decision request and a backup reviewer in the exercise. Check that the final bank status agrees with your internal record.

Governance and evidence decay#

Check that approver lists are current, overrides are documented, and return rationales are applied consistently enough to support ACH return-rate monitoring. Keep testing independent from day-to-day exception handling, and maintain segregation of duties for sensitive control tasks.

Close each cycle with one remediation owner and one verification checkpoint before the next month. Use concrete checks, such as confirming corrected issued-check data in the next transmission and confirming the next sample has no unresolved exceptions at cutoff with complete audit-trail history.

What to implement first in the next 30 days#

In the first 30 days, prioritize complete coverage and cutoff-ready operations over advanced detection.

Before adding more detection rules, establish a staffed queue, account-specific decision deadlines and retrievable bank-confirmed decision history. Test missed-deadline behavior so reviewers know when an unresolved item will pay or return.

For a broader view of layered fraud controls, see Transaction Monitoring for Platforms: How to Detect Fraud Without Blocking Legitimate Payments.