Reg E-aware notices
Variable-amount autopay sends the advance notice the rule expects, automatically, with the amount rendered from ledger facts — not a template someone forgot to update.
Solutions · Payment operations
Payments that handle themselves — including the ones that fail
Value-dated from authorization, so the on-time payer is never marked late while ACH settles. Returns trigger automated paths instead of exception queues. And every transaction ties to an intent, so reconciliation is a query — not a month-end hunt.
The payment lifecycle
Ledger
Payment authorized on the due date
System
In flight — never marked late, fees suppressed
System
Return? The automated path fires
Ledger
Posted as of the day they paid
Every transition recorded against the originating intent — full lifecycle below
The payment lifecycle
Authorize → in flight → settled → posted
One payment, start to finish, with every branch automated — including the unhappy paths. Note the value-dating annotation while the payment is in flight, and that every branch — retry, hard return, correction — leaves an evidence record.
- Ledger
Payment authorized on the due date
A payment intent is created and value-dated to the moment of authorization. From here, everything that happens is tied back to this intent.
Evidence: Payment intent with amount, instrument, and authorization timestamp.
- Ledger
In flight — and the borrower is already on time
While ACH settles, the in-flight payment suppresses late fees and stands collections down. A payment authorized on the due date never shows the borrower late. Any open promise to pay sits in pending-evaluation.
Evidence: Value-dating annotation plus the late-fee and collections suppression records.
- Ledger
Settled — funds confirmed by the network
Settlement confirmation arrives and is matched to the original intent automatically.
Evidence: Settlement confirmation linked to the intent.
- Ledger
Posted — backdated to the authorization date
The posting lands on the books as of the day the borrower acted, not the day the network finished. Statements, delinquency status, and promise evaluation all agree.
Evidence: Posted transaction with value date and the full intent lineage.
- System
And when the network says no
Returns and corrections are not exceptions a person has to notice — each return code triggers its own automated path, and every path opens with the facts attached.
R01 — insufficient funds
- Smart retry scheduled within network retry limits
- Borrower status and fees handled consistently through the retry window
- Outcome recorded against the original intent
Hard return — e.g. account closed
- Instrument auto-invalidated so nothing retries into a dead account
- Case opened with the return details for follow-up
- Borrower notified to provide a new payment method
NOC — notification of change
- Instrument details auto-corrected from the network's correction
- Future payments use the corrected details
- No human touch required — the change is still fully recorded
Evidence: Return code, the automated response taken, and the resulting case or correction — all chained to the intent.
Value dating
The on-time payer is never late
ACH takes days. Borrowers act in moments. Value dating resolves that mismatch in the borrower's favor: a payment authorized on the due date counts from the due date — period.
No late fee in flight
While a payment settles, late fees are suppressed automatically. The borrower who paid on time is never charged for the network's timeline.
Collections stands down
An in-flight payment suppresses collections activity on the debt. No agent — human or AI — dials a borrower whose money is already moving.
Promises wait for facts
A promise to pay covered by an in-flight payment sits in pending-evaluation, then resolves to kept, partially kept, or broken from ledger facts — never from a guess.
Autopay
Autopay done right
Recurring payments are where small mistakes compound quietly. Here, the notices, the retries, and the pauses are all governed actions — explicit, automatic, and recorded.
Retry policy, not retry improvisation
Failed debits follow your configured retry policy within network limits. Every attempt is an explicit, recorded decision — not a job that silently re-runs.
Pauses itself when it must
A bankruptcy filing or other protected state pauses autopay automatically as part of the same governed action that suppresses outreach. No list to remember, no debit against a stayed debt.
Return-code automation
Every return code already has a plan
A sample of how NACHA returns are handled the moment they arrive — no exception queue, no morning triage. Each automated response is recorded against the original payment intent.
| Code | Meaning | Automated response |
|---|---|---|
| R01 | Insufficient funds | Smart retry scheduled automatically, within network retry limits. Status stays consistent through the retry window; the final outcome is recorded against the intent. |
| R02 | Account closed | Hard return: instrument invalidated immediately, a case opens with the return details, and the borrower is notified to provide a new payment method. |
| R03 | No account / unable to locate | Hard return: same automated path — instrument invalidated, case opened, borrower notified. Nothing retries into an account that does not exist. |
| R10 | Unauthorized debit | Instrument invalidated and autopay halted on it; a case opens for review with the dispute facts attached, and downstream payment activity is restricted while it is worked. |
Representative codes shown; the same pattern — match to intent, take the governed response, record the outcome — applies across the return-code catalog.
Reconciliation
Nothing diverges silently
Reconciliation is not a report you run — it is a property of the system. Intents in, transactions out, and any gap between them becomes work somebody is assigned, with evidence attached.
Every transaction has a parent
Every ledger transaction ties back to a payment intent. There is no such thing as an orphaned posting you discover at month-end.
Divergence becomes a work item
When the processor's view and the ledger's view disagree, the difference becomes a case with the facts attached — never a silent discrepancy waiting in a spreadsheet.
Exam-ready by construction
Intents, postings, returns, retries, and corrections are hash-chained into the evidence graph. Reconstructing what happened to a payment is a query, not a project.
FAQ
Payment operations, answered
It simplifies it. Postings are backdated to the authorization date while settlement is tracked separately against the same intent, so borrower-facing status, statements, and the books all tell one story. Every entry carries both dates and reconciles to the network's records.
Trace a payment from authorized to posted — returns included
Bring your gnarliest return scenario. We will walk it through the intent model, the automated branches, and the evidence graph with the founding team.