Class Action Settlement Administration Software: How Do You Notice a Class, Score Fraud and Distribute a Fund Without Filing a Correction With the Court?

Why settlement administration has no product to buy

Every settlement is a bespoke legal instrument. The agreement defines the class, the eligibility tiers, the proof required for each tier, the deadlines for claims, objections and exclusions, the fee and cost deductions from the gross fund, the allocation formula, the treatment of residual funds and the reporting the court expects. The next settlement will define all of those differently. That is why there is no dominant packaged product in this category the way there is for case management or e-discovery, and why most administrators run on an internal database, a mail house, a bank portal and a web form built per case by whoever was free that month.

The operational bar, however, is unusually high. Distribution errors are not a customer service issue, they are reported to a judge. If a claimant is paid twice, or a tier is calculated on the wrong denominator, or notice reached fewer people than the plan represented, the administrator explains it in a declaration. Meanwhile the volume side is brutal: a class list of several hundred thousand records arrives from the defendant as a compressed folder of exports from three different systems, with names in mixed case conventions, addresses that have not been validated since acquisition, and a unique identifier that is unique only within each source file.

The pattern we see across administration projects is that the firm is not short of expertise. It is short of a spine. Each case is stood up by hand, the same logic gets rewritten in slightly different form, and the institutional knowledge of what worked last time lives in the head of whoever ran that case.

Problem 1: the settlement agreement is the configuration, and code is the wrong place for it

The instinct on a first build is to write the eligibility and allocation logic for a case in code. It works, it ships, and it means every subsequent case needs a developer. That is the trap, because the whole economic argument for a platform is that a new case is stood up by an operations lead in days.

What a build must do is express the case as data. Class definition and membership rules. Tiers with their eligibility conditions and proof requirements. Deadlines as a calendar of named events with dependencies, since a cure period runs from a deficiency notice date rather than from a fixed date. Deduction order from the gross fund. The allocation formula, expressed as a composable set of operations covering fixed payments, weighted units, tier caps, floors and pro rata scaling to the net fund. Residual handling. Get that model right and case setup becomes configuration plus a portal theme. Get it wrong and you have built one case very expensively.

Problem 2: the class list arrives dirty and identity is the whole game

Class member identity determines whether notice reaches people, whether duplicates are caught, and whether payments land. Defendants supply what their systems hold, which may be a customer table, a former employee export and a warranty registration list, with the same person present in all three under different spellings and two addresses.

A build handles this with a proper ingestion and resolution pipeline: source aware ingestion that preserves the original record, standardization, address validation and change of address processing through postal services, then identity resolution producing a class member record with linked source rows and a confidence score. Nothing gets silently merged. Merges are recorded, reversible and reportable, because you may need to explain to a court why two entries became one person.

The pay off is not tidiness. It is that notice deliverability, deduplication of claims and the final distribution all key off the same resolved identity, so the numbers in your declaration reconcile with each other by construction rather than by a late night spreadsheet.

Problem 3: notice is a campaign with legal consequences, run in tools built for marketing

Notice obligations typically combine direct mail and email to identifiable class members with a digital and publication campaign to reach the rest, plus the notice to federal and state officials that the Class Action Fairness Act requires for proposed settlements in federal court. Undeliverable mail must be tracked, addresses re-traced and re-mailed, and the whole effort described in a declaration supporting final approval.

Generic email platforms and mail houses each do their piece and report separately, so the administrator assembles the picture manually. A build orchestrates notice as one campaign per case: recipients drawn from the resolved registry, per channel delivery with bounce and undeliverable handling, automatic re-trace and re-mail queues, and a live view of reach against the plan. Because the campaign runs off the registry, the declaration numbers are generated with drill down to individual records instead of being reconstructed from four exports at the last minute.

Problem 4: claims arrive by web, paper and bot farm

Claim volumes on consumer settlements have become a fraud problem rather than a data entry problem. Aggregator sites submit on behalf of people who barely know what they joined. Automated submissions arrive in bursts sharing devices, addresses or payment details. Paper claims arrive as photocopies of the same form with different names. The administrator has to protect the fund for genuine class members while not rejecting real people who filled in a form clumsily, and every rejection needs a defensible reason.

What a build does is score rather than block. Signals include submission velocity and burst patterns, device and network fingerprints, address and payment instrument reuse, mismatch against the class list, internal inconsistency in the claim, and image similarity across uploaded proofs. Scores drive routing: clean claims auto validate, borderline claims go to review, high risk clusters get held as a group so a reviewer can judge the pattern rather than the individual. Every decision records the signals that produced it, because the fraud methodology itself may be described to the court. Machine assistance is genuinely useful on the proof documents, extracting fields from receipts and forms and flagging duplicates and manipulated images, and it should never be the sole basis of a denial.

Problem 5: allocation and distribution have to be re-runnable and provable

Allocation is where the money is decided. It happens after claims close, after deficiencies cure, after opt outs and objections resolve, and after the court sets fees and costs. It almost never runs once. Counsel asks what happens if a tier is capped differently, or a late claim tranche is accepted, or a court adjusts the fee award. Each of those changes every claimant's number.

A build treats an allocation as a versioned artifact: inputs frozen, formula version recorded, results stored immutably, and a diff against any prior run showing exactly which claimants moved and why. Distribution then draws from an approved version only. Payments go out across rails that suit the class, with reissue and stop payment handling, uncashed check tracking, second distribution logic if the fund allows, tax reporting where payments are reportable, and finally residual treatment whether that is cy pres or escheatment. The accounting sits against the qualified settlement fund so the balance is provable at any date. The declaration you file at the end should be an export, not a project.

What this costs and how long it takes

A first release covering the case configuration engine, class member ingestion with address hygiene and identity resolution, a per case claims portal that can be branded and deployed quickly, and deduplication with fraud scoring runs $100,000 to $220,000 and ships in 16 to 24 weeks in our delivery experience. A full platform adding multi channel notice orchestration, deficiency and cure workflows, the versioned allocation engine, payment rails with reissue and uncashed handling, tax reporting and court reportable audit exports runs $250,000 to $600,000 across 9 to 18 months.

What drives price up specifically in settlement administration: payment rail count, since checks, ACH, digital wallets and prepaid cards each have their own reconciliation and failure handling. International classes, which add currency, tax documentation and data protection obligations. Paper claim intake with scanning and extraction at volume. Call center integration, because large notice campaigns generate phone traffic that must be logged against class members. And security posture, since you are holding a large volume of personal data on people who never chose to deal with you, which justifies stronger controls than a typical business application.

What keeps it down: the configuration engine, the registry and one payment rail. Everything else can follow once the spine exists.

Build versus buy, and when buying is right

Do not build for a single case, ever. Engage an established administrator, pay their fee, and let them absorb the operational risk. Even a large settlement does not justify creating a platform you will use once, and a court will reasonably ask why an untested system was used to distribute a fund.

Build when administration is your business and two or more of these are true. You run more than roughly eight settlements a year and each one is stood up by hand. Your fraud detection is a set of manual spot checks and you cannot describe your methodology in a declaration without discomfort. Allocation runs happen in spreadsheets that cannot be diffed. Your notice reporting is assembled from vendor exports at the last minute. Or you are competing for mandates against administrators whose portals and reporting are visibly better, which affects selection more than most administrators admit.

The honest tipping point is repeatability. If a new case takes three weeks of engineering and manual setup, your capacity is capped by your developers rather than by your operations team, and every additional mandate makes that worse rather than better.

How to choose a developer for settlement administration software

Ask them to model an allocation with two tiers, a per claimant cap, a floor and pro rata scaling to a net fund, on a whiteboard, before you sign. Then ask how a re-run with a changed fee award is compared against the previous run. If versioning and diffing are not in the answer, you will be reconciling allocations by hand exactly as you do now.

Ask how a new case gets stood up. If the answer involves a developer, the platform will not scale your business. You want configuration by an operations lead, with a portal that can be branded and deployed in days.

Ask how fraud decisions are recorded. Every score needs its contributing signals stored, because your methodology may need describing in a filing, and a denial that cannot be explained is a denial that gets reversed.

Ask about security and data handling specifically. You hold personal data on hundreds of thousands of people who never chose to deal with you, so ask about encryption, access control, retention and deletion after final distribution, and independent testing.

Ask who owns the code and put it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. A platform that will hold court reportable records for years should never sit on a vendor's infrastructure account.