Customer remediation that finds every affected customer before a dollar moves, pays each refund the right way, and follows every dollar to its end, with a person signing each step
Every affected customer found and paid, and every dollar traced to its end.
See one case, screen by screen ↓Customer remediation in banking is the program a bank runs when it finds it charged customers wrongly: find every affected customer, current and former, refund each one with interest, and prove the population, the math and the payments to regulators and internal audit. Customer Remediation runs that program end to end with agents that build, compute, draft and follow the money, while people approve each step. The whole program reads as one waterfall of plain counts, and a step that does not tie to the one before it says so and shows why.
AI use cases in banking: a buyer's guide to agentic AI for bank and credit union operations →
Updated
Customer remediation in banking starts when a bank finds it charged customers wrongly: a fee it had removed from the schedule, an overdraft it should not have taken, an exemption it ignored. It owes every affected customer, current and former, a refund with interest, and it has to show the CFPB, the OCC and its own internal audit that the population was complete, the math was right and the money arrived. Today an analyst writes one query against the core banking system, a spreadsheet computes the interest, and the method lives in a memo.
One extract and one method miss the customers whose history lives somewhere else: accounts closed before a core conversion, a legacy archive, charged-off accounts. Each miss becomes a second finding and a second program. Spreadsheets with hand-edited rates cannot be re-run by internal audit, letters and checks go to a vendor, returned mail is worked by hand, and a program reports "paid" when the checks are printed, not when the money reached the customer or the state.
Estimated split of the team's working weeks on one program at the demo bank's size, by hand and with the agents, about 10 weeks down to about 4. It leaves out the time customers take to cash a check. Our arithmetic, kept modest.
Seven agents scope, build two blind populations, compute, write and follow the money; five people sign.
Corvane National Bank, a large US regional bank, has eight remediation programs open. In REM-2026-07 a $5.00 savings transfer fee removed on March 1, 2025 kept charging until June 12, 2026, and the bank reported it to the CFPB in a commitment letter on July 20, 2026, with a completion report due March 31, 2027. Here is Thursday, October 22, 2026, screen by screen, in the working solution.
The issue sits on top in one sentence. Below it, seven plain counts read left to right: 1,486,902 accounts screened, 62,414 affected, $8,914,220.40 refund computed, then paid by credit, paid by check, check returned and sent to unclaimed property. Each count has one sentence saying how it was found, with its source. Accounts affected says "Does not reconcile", and the next decision on the right is Delphine's: approve the population.
"Corvane kept charging a $5.00 savings transfer fee after it was removed from the fee schedule on Mar 1, 2025, until Jun 12, 2026."
Population agent A reads fee postings with fee code TRF5 on the new core: 61,230 accounts and 1,699,024 fees. Population agent B replays every transfer out of savings against the fee schedule in force on its date, in the new core and the legacy archive: 62,414 accounts and 1,702,436 fees. Neither sees the other's result, and the program cannot pay until they agree.
Population A's run log: "Did not read: legacy archive."
All 1,184 accounts in B and not in A closed between Mar 1 and Nov 7, 2025, before the core conversion. They were charged 3,412 fees, $17,060.00, plus $993.68 interest, and every one has the fee in the legacy archive's posting history. One click opens the core conversion log, CONV-2025-11.
"Accounts closed before cutover were not converted; their history is kept read-only in the legacy archive."
At 8:52 AM Priya Castellano, the analyst, proposed including all 1,184 former customers. Delphine approves as checker: the approval names the maker, requires a reason code and a note, and asks her to confirm she read both builds, the difference file and the conversion log. The population is 62,414 accounts, and refunds become $8,914,220.40, up from $8,896,166.72 on population A alone.
"PD-1 · missed by one method; source record confirms the charge"
Both population agents agree on 62,414 accounts. The Calculation agent recomputes 1,702,436 fees of $5.00 plus $402,040.40 interest at 4.10% to Nov 16 under method v3. The Payment agent splits 54,759 credits ($7,795,980.53) from 7,614 checks ($1,112,656.48) for closed accounts, with 41 accounts ($5,583.39) held for Legal, and the footer shows $0.00 unaccounted.
The Calculation agent's limit: "Only an approved method pays."
Loretta Vance-Albright's Statement Savings ••4417 closed on Sep 3, 2025 and was found by Population B only. Each of her 14 fees shows its posting date, the days to the payment date and its interest: $70.00 in fees plus $4.17 interest, a refund of $74.17. The Payment agent found her new address through the address service at 0.97, and the page says what to tell her if she calls.
Method v3: "Interest per fee: fee × 4.10% × days from posting to payment ÷ 365, rounded to the cent."
The agents set aside the accounts that need a person, each group with a proposed way to pay: 286 deceased owners (check to the estate), 41 in bankruptcy (held for Legal), 312 charged off (paid by check), 1,906 joint closed accounts (one check to all owners), 219 with no usable address (171 found), 1,288 who complained about the fee and 4,980 letters in Spanish. Priya decides a whole group in one step with a reason code, or assigns groups to Mateus Oyelaran in bulk.
Method v3, rule 6: "Never set off against any debt."
The Letters agent drafts four letters from the approved templates: credit to 54,759 open accounts, check to 7,614 closed accounts, estate to 286, and Spanish to 4,980. Loretta's check letter reads at grade 6.1: we charged you $5.00 fourteen times, a check for $74.17 is enclosed, please cash it by May 17, 2027. Each fact cites the account record, and only Graham approves the letters or returns them with a reason code.
The templates' rule: "No reference to any internal finding, investigation or report."
What leaves the bank: 54,759 credits posting Mon Nov 16, 7,614 checks numbered 400611 to 408224 mailed Wed Nov 18, and 41 refunds held for Legal, totaling $8,914,220.40. The ledger entries debit the 2480-207 remediation reserve, trued up by $18,053.68 for the 1,184. Priya prepared the file; when she tries to approve it herself, she is stopped.
"Not allowed: Priya Castellano prepared this, so another person must approve it."
The same waterfall closes REM-2025-11, NSF fees charged again on re-presented items: 28,906 accounts, $3,207,515.18 refunded and 519 checks ($61,402.77) sent to unclaimed property, every step reconciling with $0.00 unaccounted. The Validation agent re-performed a blind sample of 60 accounts in four strata, all 60 agreeing, rebuilt the population (28,906 = 28,906) and tied the checks to the general ledger. Only Ines signs the validation before the completion report goes to the OCC.
The Validation agent's limits: "Read only. Never edits program data."
Five people at Corvane National Bank who take a fee issue from a population to a validated close-out: what their week looked like, and what it looks like now.
Seven agents scope, build two blind populations, compute, write and follow the money; five people sign.
Drafts the program file from the issue register, linked complaints and fee schedules: the issue in one sentence, the lookback, the products and the governing rules.
Builds the affected population from fee postings, by fee code and date, net of reversals, and reports which systems it read and did not read.
Rebuilds the population by replaying every transaction against the fee schedule in force on its date, across the core and the legacy archive.
Computes each refund with interest under the approved method version, keeps the per-fee working, and compares method versions on a whole program.
Writes plain-language customer letters from approved templates, in the customer's language, with every fact taken from the record.
Splits credits, checks and holds; builds the ledger entries and the check printing file; follows every check to cashed, returned, reissued or unclaimed property.
For Internal Audit: re-performs a blind sample, rebuilds the population on its own, ties the waterfall to the general ledger and assembles the close-out pack.
Approves the population; others sign theirs. The agents propose; a named person decides.
Ask why two counts differ, how a refund was computed or what is due. Every answer cites the record or rule behind it, and opens the screen it is about.
Why do the two populations differ by 1,184?
Population agent A read fee postings on the new core only. The 1,184 accounts closed between Mar 1 and Nov 7, 2025, before the core conversion, so their history is only in the legacy archive. Population agent B replayed that archive and found the $5.00 fee on each: 3,412 fees, $17,060.00.
How was Loretta Vance-Albright's refund computed?
Her savings ••4417 closed on Sep 3, 2025 and was charged 14 fees of $5.00. Method v3 adds 4.10% simple interest per fee to Nov 16, 2026: $4.17. Refund $74.17, by check to the new address the Payment agent found.
Which decisions are due this week?
Today: the REM-2026-07 population. Friday: 7 check reissues on REM-2026-03, and the REM-2026-06 payment file for Finance. REM-2025-14's unclaimed property report is 3 days overdue with Finance.
Build the close-out pack for REM-2025-11
The pack holds the program file, both population builds, the method, letters, payment files, check status and unclaimed property reports, every maker and checker, and Internal Audit's workpaper VM-26-019, with account numbers masked.
13 screens from the working solution, on its sample data. Pick one to see it large.
Tolerances, interest, payees, clocks and privacy are settings. Every change is versioned, and the rules that protect customers, such as no setoff and SAR confidentiality, are locked.
| Setting | Default | Choose from |
|---|---|---|
| Population difference | 0 accounts | Two builds must agree before payment |
| Calculation tolerance | $0.00 | Calculation agent against Validation agent |
| Interest | 4.10% simple a year, per rate memo TF-26-031 | 4.10% or the rate an order sets |
| Minimum amount | None: pay every affected account | None or $1.00 |
| Setoff against debts | Never | Locked off, by policy and commitment |
| Address match | 0.90 | 0.85, 0.90 or 0.95; below it, a person confirms the address |
| Check void | 180 days | 90 or 180 days; then held and reported as unclaimed property |
| Approval SLA | 3 business days, escalated to the CCO after 5 | Escalation after 3 or 5 business days |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate (the split of weeks on one program) · “typical” = published figures (CFPB enforcement orders on consumerfinance.gov: a 2022 order requiring at least $141 million in overdraft refunds from a regional bank, and an earlier order with an estimated $48 million in relief). Rules named for context: UDAAP, 12 U.S.C. 5531 and 5536; Regulation DD, 12 CFR 1030; SAR confidentiality, 31 U.S.C. 5318(g)(2); state unclaimed property laws. The bank, programs, customers, accounts and people named on this page are fictional: characters and sample data in the working solution.
Customer remediation in banking is the program a bank runs when it finds it charged customers wrongly: find every affected customer, current and former, refund each one with interest, and prove the population, the math and the payments to regulators and internal audit. Customer Remediation runs that program end to end with agents that build, compute, draft and follow the money, while people approve each step. The whole program reads as one waterfall of plain counts, and a step that does not tie to the one before it says so and shows why.
Two population agents build the affected list blind, with different methods and systems: one from fee postings, one by replaying every transaction against the fee schedule in force on its date, across the core and its legacy archive. The program cannot pay until they agree to 0 accounts. In the sample program they differed by 1,184 accounts closed before a core conversion, explained with the conversion log cited.
The Calculation agent computes each refund under an approved, versioned method and keeps the working for every fee. In the sample program, method v3 refunds each $5.00 fee plus interest of fee × 4.10% × days from posting to payment ÷ 365, rounded to the cent. Any account can be traced fee by fee, and a new method version is compared on the whole program before anyone approves it.
The Payment agent watches the returned-mail file, searches for a new address and proposes a reissue; a match below 0.90 goes to a person, and the program manager approves reissues in one step. Checks still uncashed after 180 days are held and reported as unclaimed property to the state of the last known address. A program closes only with $0.00 unaccounted.
Yes. Agents propose, explain and cite; they never approve a population, change a method, approve a letter or release a payment file. Every decision has a maker and a different approver: the program manager for populations and methods, Compliance for letters, Finance for the payment file and Internal Audit for close-out, and overrides carry a reason code.
No. SAR confidentiality is a locked setting: no remediation screen, letter or export shows whether a SAR exists, and accounts with a SAR are paid like any other. Letter templates carry no reference to any internal finding, investigation or report, and exports mask account numbers to the last four.
The core banking system and its legacy archive, the issue register and complaint management, the general ledger, the check printing vendor, the correspondence system, the returned-mail file, an address service and the unclaimed property system, each by its role in the program.
The Agentic Solution Engine builds and deploys it from your requirements and documents, such as your issue register entries, fee schedules, account and fee history, and your calculation method, and it goes live once every quality gate has passed. We will walk you through it on one of your own programs first.
Misleading claims, hidden fees and hard exits fixed before launch, not refunded after.
1-min demoConsumer Duty Outcomes MonitoringEvery board report sentence tied to its data, and every weak point challenged first.
1-min demoDeposit Compliance SearchCited answers while the member is on the line, and Reg E claims opened on the first call.
1-min demoWe'll run Customer Remediation on one of your own programs: your issue, your fee history and your method.