Unit 01 · Chapter 3 · 10 min read

ACH, bank debits, and returns

Separate account access, authorization, settlement, and return exposure.

Lantern offers bank payments to save processing cost. Someone suggests shipping as soon as account verification passes. The accountant pauses: a real account can still be empty, a verified login can still be compromised, and a payment can still be returned.

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.

Know the roles and directions Know the roles and directions — the flow Follow the sequence. Receives it for the account. Originator Creates the entry ODFI Introduces it to ACH RDFI Receives it for the account — Follow the sequence. Receives it for the account. Chapter sources · Open image

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.

Verification is not authorization Verification is not authorization — the flow Follow the sequence. Check subsequent payment behavior. Verify Establish account facts Authorize Record permission and scope Monitor Check subsequent payment behavior — Follow the sequence. Check subsequent payment behavior. Chapter sources · Open image

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.

Returns need reason-aware handling Returns need reason-aware handling — the flow Follow the sequence. Apply the eligible next step. Receive Validate return reference Classify Use code and context Act Apply the eligible next step — Follow the sequence. Apply the eligible next step. Chapter sources · Open image

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.

Exposure continues after a status change Exposure continues after a status change — the flow Follow the sequence. Returns and recoveries develop. Collect Payment enters its lifecycle Release Seller receives usable funds Resolve Returns and recoveries develop — Follow the sequence. Returns and recoveries develop. Chapter sources · Open image

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

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.

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

Monitor both incoming and outgoing flows Monitor both incoming and outgoing flows — the distinction These concepts answer different questions. Read each definition in the context of the section. Rule requirement Current obligations for the participant Product control Additional safeguards chosen for exposure — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Monitor both incoming and outgoing flows Monitoring coverage matrix Fictional teaching record. Detect stale scope. Monitoring coverage matrix Illustrative data; not a real customer record or a prescribed policy. Outgoing originations Creation-side visibility Incoming received credits Receiver-side visibility Review dated mapping Detect stale scope Both sides observe different parts of the flow — Fictional teaching record. Detect stale scope. Chapter sources · Open image

Monitor both incoming and outgoing flows Monitor both incoming and outgoing flows — control and failure modes Both sides observe different parts of the flow. The branches show why alternative designs fail. Control design Receiver behavior adds evidence unavailable to the sender. Both sides observe different parts of the flow. Failure mode 1 Incoming money cannot be suspicious. Direction alone does not establish legitimacy. avoid Failure mode 2 It removes the need for authorization. Permission still matters. avoid Failure mode 3 It guarantees recovery. Monitoring does not guarantee return of funds. avoid — Both sides observe different parts of the flow. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Cards, authorization, and disputes. Continue with Instant payments and cross-border transfers to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17