A customer remediation platform is software that runs a bank's remediation programs end to end: it builds the affected population from the bank's own systems, calculates each refund under an approved method, prepares letters and payment files, and follows every payment to its end, with named people approving each step and a trail examiners can follow. The way to put one live is on the next real program, with a closed program re-run first as the test, not on a migration project. Our plan for Botminds' Customer Remediation takes eight weeks from read access to the first payment file: two weeks to connect the history and write the method as settings, two to re-run a closed program and match its known results, and four to take a live program from two population builds to payment. The months that checks take to clear come after, and the platform tracks them.
Why the first weeks matter: how long remediation has taken without a platform
1,726
days, on average, for Australia’s major banks to identify a significant breach
ASIC review, 2018
226
days, on average, from the end of an investigation to the first payment to customers
Same review
8
weeks in our go-live plan, from read access to the first payment file on a live program
A plan, not a measured result
What is a customer remediation platform?
It is the system of record for remediation programs: each program's issue, population, method, calculations, letters, payments and evidence in one place, with the decisions and who made them. It differs from an issue tracker, which records that a remediation exists, and from a spreadsheet, which holds one version of one calculation. A platform holds every account, every version and every outcome, so any number can be traced to its source and any program can be re-run.
In Botminds' Customer Remediation the work is done by seven agents with fixed limits: one drafts the program file, two build the population blind to each other, one computes, one writes letters, one builds payment files and follows checks, and one works read-only for internal audit. People approve: the program manager the population and method, compliance the letters, finance the payment file and internal audit the close-out, with the analyst preparing each as maker. Agents never approve anything.
What does a remediation platform do that a project plan does not?
It holds the money and the evidence, not just the tasks. A project plan says that the population is due on Friday; a platform builds it, shows why two methods disagree and records who approved the answer. That matters most when something changes: a new method version, a late addition to the population, a batch of returned checks. In a project plan each change is a new spreadsheet; in a platform it is a re-run with the difference shown.
It also lets a bank start paying sooner without losing control. Regulators have allowed it: the OCC's Wells Fargo order said that “In the interest of expediting relief to affected consumers, the Bank may proceed with providing remediation to consumers under any Remediation Plan, whether or not it has been submitted for, or received, a written determination of no supervisory objection” (OCC Consent Order AA-EC-2018-15; terminated 2025). Paying early is only safe when the population is right the first time.
How long does remediation software take to set up?
About eight weeks to the first live payment file, in our plan, and most of it is getting the history out. Connecting read-only to the core is quick; finding and connecting the archive that holds accounts closed before the last conversion is not, and it is exactly the access the program cannot do without. Writing the method as settings takes days if the bank already has a rate memo and an approved policy, and longer if each past program invented its own.
Regulators' own clocks are the benchmark. Orders have given banks 90 days to submit a redress plan and 60 days after approval to pay, or 45 days to mail every check after approval. A platform that takes six months to set up misses the clock on the program that justified buying it.
The clocks regulators have set for a remediation
| Source | Plan | Pay | Report or validate |
|---|---|---|---|
| CFPB, Regions Bank, 2022 | Redress plan within 90 days; revisions within 15 | Within 60 days of non-objection | Board-approved reports at 90 days and one year |
| CFPB, Navy Federal, 2024 | Redress plan for non-objection | All checks and deposits within 45 days of non-objection | Redress report within 30 days of completion |
| CFPB, U.S. Bank, 2022 | Plan with a consultant’s help | All redress within one year of non-objection | Internal audit validation within 180 days of completion |
| OCC, Wells Fargo, 2018 | Bank-wide program within 120 days | May pay before non-objection | Monthly status reports; validation for every plan |
| ASIC, for licensees | Report a significant breach within 30 days | Without unjustified delay | Records ASIC may ask to see |
What data does a remediation platform need?
Four kinds: the issue, the history, the rules and the money. The issue comes from the issue register and the linked complaints. The history is account, posting and fee data from the core and every archive that held it during the lookback, including accounts closed before a conversion. The rules are the fee schedules in force on each date, the approved calculation method and the interest rate memo. The money is the general ledger, the check vendor's files, the returned-mail file, an address service and the unclaimed property system.
None of it needs to be moved into a new warehouse first. The platform needs read access and a way to exchange files with the systems that post credits, print checks and file state reports. The single most valuable step a bank can take before go-live is to find out where its closed accounts' history lives.
Customer Remediation go-live: the eight weeks, week by week
The plan has three stages: connect and configure, prove on a closed program, then run a live one. Each stage ends with a decision by the bank, and nothing is paid to a customer until the third.
Eight weeks to the first payment file on a live program with Customer Remediation
- Read access: core, archive, schedulesWk 1
- Method, settings, templatesWk 2
- Re-run both builds and the refundsWk 3
- Match known results; audit observesWk 4
- Two builds, population approvedWk 5
- Refunds, exceptions, lettersWk 6
- Payment file releasedWk 7
- Returns and reissues liveWk 8
Weeks 1 and 2: connect and configure. Read access to the core, the archive and the fee schedules; the method written as versioned settings (interest rule, day count, rounding, minimum, setoff policy, address match threshold, void period); letter templates approved by compliance; approvers named for each step.
Weeks 3 and 4: prove it on a closed program. The agents re-run a program the bank has already paid, with its results held back: both population builds, every refund, the payment split. Every difference from the bank's own figures is explained, and the explanations decide whether the platform goes live. Internal audit watches this stage; it is the cheapest validation it will ever do.
Weeks 5 to 8: the next live program. Two population builds and the approval, then refunds, exceptions and letters, then the payment file through finance, then the returned-mail and reissue loop running daily. The program's long tail, checks clearing over the following months, stays on the same screens until every dollar has a final state.
Can the first program run in parallel?
Yes, and it should, in one specific way: the closed-program re-run is a parallel run with the answer known. For the live program, a bank that wants extra comfort can have its analysts build the population their usual way at the same time, as a third build; the platform's two builds and the analysts' one should all agree, and any account where they do not is the most useful finding of the go-live.
What should not run in parallel is the payment. One payment file, released once by finance, tied to one reserve. Two systems both able to pay the same customer is the risk a go-live has to remove, not add.
Test the platform on a program you have already paid. If it cannot find the customers you found, it should not be trusted with the ones you missed.
What should be tested before paying customers?
Everything that would be expensive to fix after payment: the population, the method, the letters, the payment file and the controls around them. The CFPB judges a bank partly on speed, asking “How long after the violation was uncovered did it take to implement an effective response?” (CFPB Bulletin 2020-01); a second payment run to fix a first one adds months to that answer.
Tested before the first live payment file is released
- The closed program reproduced
Population, refunds and payment split match the bank’s known results, or each difference is explained.
- Both builds independent
Different methods, different systems where possible, neither able to see the other’s result.
- The method re-performed by hand
A handful of accounts, including the earliest and the smallest, recomputed outside the platform to the cent.
- Exceptions routed
Deceased, bankruptcy, joint, charged-off and no-address groups each have an approved way to pay.
- Letters approved and read
Every template approved by compliance; a sample of filled letters read against the account.
- Maker and checker enforced
Try to approve your own payment file; the platform should refuse.
- The file ties to the general ledger
Credits, checks and holds equal refunds computed and the reserve, to the cent.
- Returns and reissues work
A returned item is matched, searched, proposed for reissue and blocked on the original.
Who approves go-live?
The same people who approve each step of a program, plus whoever owns technology risk at the bank. The program manager confirms the closed-program results; compliance confirms the letters and rules; finance confirms the payment and general ledger integration; internal audit confirms that it can re-perform from the platform independently. Where the bank treats the agents as models, its model risk function reviews them under the bank's own policy.
The regulator does not approve a bank's software, but it will judge the outcome. The CFPB's supervision page, last modified August 20, 2026, describes the Bureau “encouraging self-reporting and resolving issues in Supervision, where feasible, instead of via Enforcement” (CFPB). A bank that intends to self-report needs a remediation it can show, and a platform is how it shows it.
How do you move open programs over?
At their current stage, without re-deciding what was already decided. A program still building its population moves whole: the platform builds both populations and the earlier work becomes a third comparison. A program with an approved population and method brings both in as approved versions, and the platform recomputes to confirm the amounts. A program already paid brings its payment file and check states in, so the returns, reissues and state reports are tracked from then on.
UK rules show why programs that are not yet formal still count. A firm that finds harm must act even where nobody complained, and must “explain to the retail customer promptly and in a way that is fair, clear and not misleading that harm has been identified” (FCA Handbook, PRIN 2A.10); the complaints rules ask firms to consider “whether it is fair and reasonable for the firm to undertake proactively a redress or remediation exercise, which may include contacting customers who have not complained” (DISP 1.3.6G). An issue waiting in a backlog is a remediation that has not started, and ASIC warns that a remediation “unjustifiably protracted or delayed” may itself breach a licensee's obligations.
Week 5: refunds recomputed after the population decision, every step reconciling
Every decision across programs, with who prepared it and who may approve
Week 8 onward: returns and reissues on a daily loop
The weeks after go-live are where most of the evidence is produced. The KPIs that price a program show what to report while checks clear, and how internal audit tests a remediation describes the close-out the platform has to support.
Questions people ask
Does a remediation platform need a data warehouse first?
No. It needs read access to the systems that hold the history and file exchange with the systems that move money. A warehouse that already holds archived postings helps; building one first usually delays the remediation it was meant to serve.
What does the bank's team do during the eight weeks?
Grant access, write down the method and the policies (interest, minimums, setoff, void period), approve letter templates, choose the closed program for the test and check its results. On the live program, they make the same decisions they always make, with the extracts and arithmetic done for them.
What if our past methods live in spreadsheets?
Bring the spreadsheet to week 2. The method is rewritten as settings, and the closed-program test in weeks 3 and 4 shows whether the settings reproduce the spreadsheet's results. Differences usually trace to hand-edited rates or rounding, which is worth knowing before the next examination.
Is a platform worth it for a bank with one or two programs a year?
It depends on the programs' size and on how much of the team's year they consume. A small program with clean data can run on a careful spreadsheet; a program that crosses a core conversion, or pays thousands of former customers by check, is where a second population build and check tracking pay for themselves.
Can the platform pay customers electronically instead of by check?
It credits every open account in the core, which is the cheapest and fastest payment there is. For former customers it builds the check file the vendor prints, and it can carry other payment routes where the bank offers them; the choice of route belongs in the method the program manager approves.