ACH, bank debits, and returns

Know the roles and directions

ACH credits push funds; ACH debits pull funds under an authorization arrangement. The originator initiates the entry, the ODFI sends it into the network, and the RDFI receives it for the receiver. The same customer can occupy different roles in different flows.

Draw the direction of the instruction separately from the direction of value. This prevents an easy mistake: assuming a debit is safe because the receiver bank accepted a file. A file acknowledgment and an authorized, funded transfer are different facts. Track origination, processing, settlement, and any return as linked records.

Inside the mechanism. Direction and role determine what an event means. An ACH debit requests funds from an account; an ACH credit sends funds toward one. The originator, originating institution, operator, receiving institution, and receiver do different work. Preserve direction, entry context, effective date, settlement observation, and the relevant partner references. A risk control designed for an outgoing consumer transfer may not cover an incoming debit that funds a later payout. Map the whole economic sequence.

A concrete example. A subscription platform initiates bank debits through its payment partners. An origination record and a later settlement or return describe different stages. The batch begins with $128,000 of instructions and $122,880.00 of captured value. At the observation cutoff, $3,686.40 remains pending. After the stated refunds, fees, and restrictions, $101,007.36 is available for payout. The unresolved instruction count is 2; an unknown external result is handled separately from a known decline.

When the assumption fails. The product treats successful submission as final collection. Separate origination, settlement evidence, return handling, and customer availability. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A subscription platform initiates bank debits through its payment partners. An origination record and a later settlement or return describe different stages.

Subscription debit batch: reference condition figure preview

01Reference conditionSubscription debit batch

Subscription debit batch: failure and stress figure preview

02Failure and stressSubscription debit batch

Subscription debit batch: controlled response figure preview

03Controlled responseSubscription debit batch

Know the roles and directions Know the roles and directions — the distinction These concepts answer different questions. Read each definition in the context of the section. Credit push Sender initiates value to receiver Debit pull Originator requests value from receiver — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Know the roles and directions Bank debit specimen Fictional teaching record. Account being debited. Bank debit specimen Illustrative data; not a real customer record or a prescribed policy. Originator Lantern Collects a purchase payment Entry debit Pull direction Receiver Maya Account being debited The originator creates the collection instruction — Fictional teaching record. Account being debited. Chapter sources · Open image

Know the roles and directions Know the roles and directions — control and failure modes The originator creates the collection instruction. The branches show why alternative designs fail. Control design The originator through its ODFI. The originator creates the collection instruction. Failure mode 1 Every network participant independently. That would duplicate the instruction. avoid Failure mode 2 Only the shipping carrier. The carrier is outside this role. avoid Failure mode 3 The dispute reviewer after settlement. Review is not origination. avoid — The originator creates the collection instruction. The branches show why alternative designs fail. Chapter sources · Open image

Verification is not authorization

Account verification can establish facts about an account. Authorization establishes permission for the specified debit under applicable requirements. Available balance gives a time-sensitive view of funds. None substitutes for the others. A customer who owns an account has not necessarily agreed to every amount or recurring schedule.

Store the authorization text and the facts needed to identify its scope. Keep account tokens rather than exposing raw account numbers across systems. If a provider supplies verification results, record what the provider actually tested. A match result without a documented meaning is hard to use consistently.

A customer can prove control of a bank account and still lack authority to use it for a particular business obligation. A successful account check answers a narrow evidence question. Authorization records must explain who permitted the debit, what activity was permitted, and how the product handles changes or withdrawal of that permission under the applicable arrangement. Treat these as connected records, not as one permanent verified flag.

The same distinction matters after onboarding. A valid account can later close, change ownership, or become the subject of a complaint. A control that runs only on the day an account is linked may miss the relevant change. Event-based checks can reduce this gap, but each new check needs a defined purpose and a response when its result is uncertain.

Inside the mechanism. Account existence, account control, and permission for a specific debit are separate claims. A successful account check does not itself establish the scope of authorization. Store which party gave permission, for what action, under which terms, and how the record was obtained. Revocation and changes in the relationship need their own transitions. A verification result should remain a dated observation; treating it as permanent authority hides the very change the control is meant to detect.

A concrete example. A customer proves access to a bank account while the product also needs authority for the intended debit. Those are related but distinct records. The case identifies 1,584 eligible records from a source population of 2,200. The required workflow completes for 1,536, but 23 completed records miss the illustrative internal target. Another 48 remain incomplete. Communication evidence covers 1,521 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. An old account-verification flag is reused as permanent authorization. Link the relevant authorization, scope, changes, and withdrawal handling to each applicable debit. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A customer proves access to a bank account while the product also needs authority for the intended debit. Those are related but distinct records.

Linked-bank authority: reference condition figure preview

01Reference conditionLinked-bank authority

Linked-bank authority: failure and stress figure preview

02Failure and stressLinked-bank authority

Linked-bank authority: controlled response figure preview

03Controlled responseLinked-bank authority

Verification is not authorization Verification is not authorization — the distinction These concepts answer different questions. Read each definition in the context of the section. Account ownership Whose account is involved Debit permission Which collection was agreed — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Verification is not authorization Authorization record Fictional teaching record. Protected reference. Authorization record Illustrative data; not a real customer record or a prescribed policy. Amount 40 USD Agreed debit amount Frequency one time Not recurring permission Account token-82 Protected reference Ownership does not establish permission for this debit — Fictional teaching record. Protected reference. Chapter sources · Open image

Verification is not authorization — control and failure modes

Control design

Evidence of debit authorization. Ownership does not establish permission for this debit.

Failure mode 1avoid: A second logo. It provides no consent.
Failure mode 2avoid: A faster settlement file. Speed does not establish consent.
Failure mode 3avoid: A higher model score. Prediction does not create permission.

Ownership does not establish permission for this debit. The branches show why alternative designs fail. Chapter sources · Open image

Returns need reason-aware handling

A return can indicate insufficient funds, account problems, or an authorization issue. These causes require different responses. Treating all returns as fraud distorts labels; retrying all returns automatically can create customer harm and rule violations.

Create a return policy keyed by the applicable code, account type, product, prior attempts, and current network requirements. Preserve the original authorization and entry reference. An engineering example can use a configurable retry eligibility flag, but the flag must come from an approved rules table. Do not hard-code a universal return window or a universal retry count into a textbook example.

Inside the mechanism. A return reason is operational evidence with a defined scope. It can change routing, recovery, customer communication, and the outcome label. Preserve the original reason and later corrections rather than flattening everything into failed. Separate known returns from missing settlement evidence. A retry policy must account for the reason and applicable rules, not simply retry every non-success response. The state model should also prevent a returned funding event from leaving an unrelated payout marked as safely funded.

A concrete example. A seller receives an early payout against a debit that later returns. The platform now has a collection and exposure problem, not merely a processing error. The batch begins with $84,500 of instructions and $81,120.00 of captured value. At the observation cutoff, $2,433.60 remains pending. After the stated refunds, fees, and restrictions, $66,599.52 is available for payout. The unresolved instruction count is 2; an unknown external result is handled separately from a known decline.

When the assumption fails. A return reason is mapped to a generic retryable failure. Use reason-aware handling and avoid resubmitting actions outside their permitted authority. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A seller receives an early payout against a debit that later returns. The platform now has a collection and exposure problem, not merely a processing error.

Returned debit exposure: reference condition figure preview

01Reference conditionReturned debit exposure

Returned debit exposure: failure and stress figure preview

02Failure and stressReturned debit exposure

Returned debit exposure: controlled response figure preview

03Controlled responseReturned debit exposure

Returns need reason-aware handling Returns need reason-aware handling — the distinction These concepts answer different questions. Read each definition in the context of the section. Funding issue May reflect temporary shortfall Authorization issue Questions permission for the debit — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Returns need reason-aware handling Return handling record Fictional teaching record. Illustrative policy pending review. Return handling record Illustrative data; not a real customer record or a prescribed policy. Entry ach-451 Original reference Category authorization concern Needs permission review Retry disabled Illustrative policy pending review A return code alone may not capture all conditions — Fictional teaching record. Illustrative policy pending review. Chapter sources · Open image

Returns need reason-aware handling Returns need reason-aware handling — control and failure modes A return code alone may not capture all conditions. The branches show why alternative designs fail. Control design Applicable return rules and authorization context. A return code alone may not capture all conditions. Failure mode 1 Always retry tomorrow. Not all returns permit the same action. avoid Failure mode 2 Always call it stolen identity. Many returns have other causes. avoid Failure mode 3 The merchant sales target. Commercial pressure does not define eligibility. avoid — A return code alone may not capture all conditions. The branches show why alternative designs fail. Chapter sources · Open image

Exposure continues after a status change

If Lantern pays a seller before bank-payment risk resolves, it finances the gap. A hold can reduce that gap but affects seller cash flow. The correct hold is a product and risk decision informed by return behavior, contracts, customer rights, and concentration. It is not a magic guarantee after a fixed number of days.

Estimate exposure as funds released while related obligations remain uncertain. Add pending refunds and returns, then subtract eligible funds that are actually available to cover them. Do not subtract a reserve that is legally unavailable for the obligation or has already covered another exposure.

Imagine that Lantern lets a seller withdraw funds as soon as an incoming ACH debit is submitted. If that debit later returns, the platform has already advanced value. The exposure is created by the availability policy as well as by the payment rail. Holding a payout can reduce one loss path while creating delay and support costs for legitimate sellers. A useful policy analysis compares the timing of returns, the seller’s ability to repay, and the value still available for recovery. An early processing status cannot resolve those economic facts.

Inside the mechanism. Exposure follows open promises and recoverability, not the color of a status badge. If the platform releases value before the funding leg is sufficiently resolved, it can retain a receivable or recovery risk after the customer experience looks complete. Track the linked funding and payout amounts, the remaining uncertainty, and usable cover. Reducing the payout delay changes the interval of exposure even when the transaction count and average ticket remain unchanged.

A concrete example. The platform advances usable value before the incoming collection is fully resolved. The merchant’s future ability to repay matters if the funding fails. The case has $310,000 of exposure. Its stated one-year PD and LGD imply $9,377.50 of expected loss, while the cover analysis leaves $241,000.00 of stress exposure. Monthly cash coverage is 1.12×. These are separate measures: one describes an average under probability assumptions, one describes available cover, and one describes a period’s funding capacity.

When the assumption fails. A return cluster arrives after the merchant has withdrawn proceeds. Measure the advance, available cover, concentration, and exposure remaining after payout. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The platform advances usable value before the incoming collection is fully resolved. The merchant’s future ability to repay matters if the funding fails.

Early-availability merchant: reference condition figure preview

01Reference conditionEarly-availability merchant

Early-availability merchant: failure and stress figure preview

02Failure and stressEarly-availability merchant

Early-availability merchant: controlled response figure preview

03Controlled responseEarly-availability merchant

Exposure continues after a status change Exposure continues after a status change — the distinction These concepts answer different questions. Read each definition in the context of the section. Payment status A milestone in processing Residual exposure What can still become a loss — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Exposure continues after a status change Illustrative payout gap Fictional teaching record. Simplified exposure difference. Illustrative payout gap Illustrative data; not a real customer record or a prescribed policy. Released 50000 USD Seller already paid Eligible cover 12000 USD Available once only Uncovered 38000 USD Simplified exposure difference Subtract available cover once from the released exposure — Fictional teaching record. Simplified exposure difference. Chapter sources · Open image

Exposure continues after a status change Exposure continues after a status change — control and failure modes Subtract available cover once from the released exposure. The branches show why alternative designs fail. Control design $38,000. Subtract available cover once from the released exposure. Failure mode 1 $62,000. That adds cover rather than subtracting it. avoid Failure mode 2 $12,000. That is cover rather than uncovered exposure. avoid Failure mode 3 Zero because the file settled. Settlement does not erase every return obligation. avoid — Subtract available cover once from the released exposure. The branches show why alternative designs fail. Chapter sources · Open image

Monitor both incoming and outgoing flows

Monitor both incoming and outgoing flows — the flow

Outgoing viewEntry creation and authorization
Incoming viewReceiver profile and fund movement
CoordinationShare relevant alerts through approved routes

Follow the sequence. Share relevant alerts through approved routes. Chapter sources · Open image

Receiving institutions see patterns that a sender may miss, including unusual incoming credits followed by rapid outflow. Originating parties see payment creation and authorization behavior. A complete control map uses both views and a route for urgent contact.

Nacha identifies Phase 2 fraud-monitoring changes with a June 19, 2026 effective date and June 22 practical date because of the federal holiday. Its public explanation distinguishes role-based monitoring from a universal pre-processing requirement. Use the current rule text and partner obligations for implementation. Engineering teams should version the requirements map and test that monitored populations match it.

Inside the mechanism. Monitor the entry population and the economic destination. Incoming funds may support rapid outgoing movement, while an outgoing transfer can carry risk concentrated at the receiver. Join only on supported identifiers and retain the direction of each edge. Controls also need proof that the relevant population reached monitoring. A quiet alert queue can mean low risk, a narrow rule, or a broken feed; those explanations require different responses.

A concrete example. Incoming and outgoing bank activity can each reveal a distinct risk path. Coverage depends on receiving the right events for the organization’s actual role. The daily source population is 6,800 items, but 136 are outside the completed monitoring run. The included population creates 300 hits and 246 unique cases. With 35 cases already open and capacity for 260, the queue closes at 21. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

When the assumption fails. Only outgoing transfers reach the scenario pipeline. Reconcile direction-specific populations and route evidence to an owned review process. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Incoming and outgoing bank activity can each reveal a distinct risk path. Coverage depends on receiving the right events for the organization’s actual role.