Turning a Daily File of Returned IRA Contributions Into a Controlled, Auditable Reversal Run

September 28, 2026

When a participant funds an IRA by ACH, the firm receives provisional credit from its bank. If the debit bounces (for insufficient funds, a closed account, a stopped payment, etc.) the bank pulls the money back and the firm's account is out of balance with the participant's contract until someone reverses the original deposit.

That someone works from a fixed-width report pulled from a legacy archive each morning. A typical day runs ~50 to ~70 rows and can reach ~180. For each row, an analyst looks up the participant, searches a funds repository for the original posting, confirms the reversal with the right reason, then opens a remittance ledger and types the same contract, amount, dates and reason in again. At ~4 minutes a row, a 65-row day is about an hour and a half of careful copy-and-paste, and every keystroke is a chance to reverse the wrong deposit.

The process had also become fragile. The team is small and mostly new to the role, the written procedure had been re-certified year after year without substantive change, and much of the judgment lived with a few long-tenured people. The goal was a control that holds no matter who is on shift.

A script that clicks through screens would handle most rows and quietly get the rest wrong. Exception examples include, but are not limited to:

• Look-alike postings. Two deposits with the same contract, amount and date that differ only by bank routing number. Picking one needs evidence, not a guess.
• Notices of change. Some rows are bank notices with no money attached. They are handled elsewhere and must never trigger a reversal.
• Restricted accounts. If a row belongs to someone on the treasury team, it has to go to an authorized person instead of the analyst on duty.
• Weekend files. Monday's report can carry several processing dates, which changes the search window and which systems apply.

Thread AI built the process as a single Lemma Worker following the team's own sequence: detect, research, reverse, notify. The pilot runs against Thread-hosted simulations of the report archive, participant lookup, funds repository and remittance ledger, rebuilt from screens the team shared, so it can be re-pointed at live systems later with minimal change.

The four review queues:

• Eligible: exactly one matching posting in each system. Pre-filled, ready to approve.
• Manual: ambiguous or missing match. Copy-ready values and a note field; the analyst decides.
• Hold: restricted account. Routed to an authorized reviewer; the rest of the day keeps moving.
• Excluded: notices of change and zero-dollar rows, logged with the reason and never reversed.

The team handed over one real report, tokenized before it left the firm. Thread AI paired it with two designed days that stress the controls.

On a day the pilot hasn't seen, the Worker still parses, classifies and orders every row and hands the analyst a structured worksheet with copy-ready values. That is the shape the process would take on day one against live systems.

Thread AI works with customer stakeholders to establish the unique success criteria for their use case. Examples include but are not limited to:

• Wrong-posting selection percentage
• Number of return codes mapped without a person
• Number of reversals written against the wrong record, or twice
• Percentage of rows reaching a recorded final disposition
• Time to complete the daily file

In production the Worker runs on a schedule, pulls the report straight from the archive, sends it from the firm's own mailbox and enters reversals in the real funds repository and remittance ledger. Classification, review and the audit trail would stay as they are. The same detect, research, reverse, notify pattern would then extend to the adjacent return types the team handles: after-tax annuity and institutional ACH rejects, returned checks and wires.