Abstract background illustration for How Settlement Allocator rules vary in Minnesota

How Settlement Allocator rules vary in Minnesota

6 min read

Published June 4, 2026 • By DocketMath Team

Verified · 2 primary sources

This page has current canonical verification receipts.

Quoted from the source law itself. Not legal advice; confirm how it applies to your matter.

Current verified answer

Minnesota settlement-allocator: interest rate is 4; high value interest rate is 10.

Run the allocation

Authority and key facts

Citation: Minn. R. Civ. P. 23.01-23.05

View the primary source

Verified April 27, 2026

  • Interest Rate: 4
  • High Value Interest Rate: 10
  • Interest Rate Source: Minn. Stat. § 549.09 (1-year T-bill secondary yield, min 4%; 10% if over $50k)
  • Escheat Years: 3

What varies by jurisdiction

Settlement allocation rules determine how a global settlement amount is split among class members (or other defined participants) in a court-supervised settlement. For Minnesota, you generally don’t use a standalone “settlement allocator” statute; instead, you align your allocation approach with Minnesota’s civil procedure class action framework.

In practical terms, that means DocketMath’s allocation method should be consistent with the process courts expect in Minnesota class settlements under:

What varies when you move into Minnesota (and why it matters for allocation)

Even if two allocators compute the same underlying math, Minnesota’s class action procedure can affect what the court will require you to justify. The “variation” you’ll encounter tends to show up in the inputs and plan documentation rather than in a different formula called “Minnesota settlement allocation.”

Common Minnesota-facing differences you should anticipate:

  • Court expectations around fairness and administrability: allocation plans should be explainable and workable using the data available for administration.
  • Procedural gates tied to Rule 23: your allocation approach usually needs to fit into the class settlement process governed by Rule 23.01–23.05.

The period/rule default you should use (and what we did not find)

Many settlement allocation workflows require a “settlement allocation period” or a timing window for identifying eligible claimants/participants. For Minnesota, you should be explicit about defaults.

Note: No claim-type-specific sub-rule was found for Minnesota Rule 23.01–23.05 in the referenced material. Treat the referenced rule set as the general/default period for allocator-aligned administrative timing unless the court order specifies otherwise.

This matters for DocketMath because the selected period can change:

  • which people fall into the eligible population,
  • the denominator used for proportional or per-unit calculations, and
  • downstream outputs (allocated amounts and cohort totals).

What to verify

Before using DocketMath’s Settlement Allocator for Minnesota (US-MN), verify the following items to keep your allocation aligned with the Minnesota class-action rule framework in Minn. R. Civ. P. 23.01–23.05.

Start at the primary tool here: /tools/settlement-allocator

1) Confirm you’re using the right Minnesota rule set

Use the Minnesota Civil Procedure Rule 23 provisions as your grounding framework:

Then, ensure your DocketMath workflow is consistent with the procedural posture of your class settlement (for example, how the notice and claims/administration mechanism is expected to operate).

(Gentle reminder: this guide is informational and not legal advice; when in doubt, confirm the operative requirements with the case record.)

2) Verify your eligibility logic matches the “default period”

Because no claim-type-specific timing sub-rule was found within the referenced Rule 23.01–23.05 range, apply the allocator timing window using the general/default approach unless the court order overrides it.

In DocketMath inputs, this typically affects:

  • start/end dates used to define eligibility or participation,
  • the mapping between participants and allocation units, and
  • cohorting that changes the denominator (how many eligible units/people are in the allocation pool).

Practical check:

  • Recompute eligibility counts from your raw dataset using the same date logic you enter into DocketMath, and ensure the denominator matches your expectations.

3) Confirm your allocation basis is “fair and administrable”

DocketMath can calculate allocations using different bases (for example, proportional to a metric or using claim-form values/tiers). Minnesota Rule 23 class settlements generally require an allocation approach that can be explained and administered.

Verify your plan in three practical ways:

  • Data consistency: can the plan be run reliably with the records you have?
  • Documentation readiness: can you explain the chosen allocation metric and how it maps to settlement value?
  • Avoid arbitrary distinctions: ensure similarly situated class members are treated consistently under the plan.

4) Reconcile “court order terms” with allocator settings in DocketMath

If your court order contains allocation-specific directions, those terms govern even if DocketMath has reasonable defaults.

Use this checklist to map order terms into the tool:

  • The settlement/court order states the allocation basis (proportional metric, tiers, or fixed amounts)
  • The settlement/court order defines eligible class members and any relevant period
  • Any carve-outs, exclusions, or special handling are captured in your data fields and DocketMath settings
  • Participant/claim identifiers in your dataset match what the plan requires

5) Validate denominators and proration logic

Settlement allocator outputs are highly sensitive to exclusions and denominator definitions.

Common verification steps:

  • Total eligible units (denominator) equals what your plan defines under the default eligibility window
  • Exclusions (if any) are applied in the correct stage relative to allocation math
  • Rounding rules don’t systematically bias particular cohorts

Warning: A frequent allocator error is applying exclusions after computing proportional shares. That can undermine the “fairness” narrative because the math may not reflect the eligibility definition the court accepted.

Using DocketMath for Minnesota (US-MN) without losing jurisdiction alignment

Use DocketMath’s jurisdiction-aware calculator to keep assumptions clear as you configure the run.

Workflow suggestion:

  1. Set jurisdiction to Minnesota (US-MN).
  2. Choose the allocation basis that matches the documented settlement allocation plan (from the court order or settlement agreement).
  3. Enter the eligible period using the general/default period approach.
    • Because no claim-type-specific sub-rule was found in the referenced Rule 23.01–23.05 text, avoid creating claim-type-specific allocator windows unless the order requires it.
  4. Import the claimant/participant metrics that drive the allocation formula.
  5. Review outputs by cohort internally (even if you don’t publish cohort tables) to catch denominator and eligibility mismatches early.

To make results easier to validate, generate an internal comparison table including:

  • Claimant cohort
  • Eligible units / claim metric
  • Proportional share (or tier)
  • Final allocated amount
  • Any rounding adjustment

Output comparison table (what to watch in Minnesota)

Item to reviewWhat changes in MinnesotaHow to catch errors
Eligibility windowUses general/default period unless order specifies otherwiseCompare eligibility counts before vs after date filtering
DenominatorDepends on the default eligibility list and exclusionsRecompute totals from raw data
Allocation cohortingMust follow how eligibility/admin is definedEnsure cohorts align with dataset fields
Special handlingOnly if required by orderCheck that allocator settings match order language

Sources and references

  • Minn. R. Civ. P. 23.01–23.05 (Minnesota class action rules) — https://www.revisor.mn.gov/court_rules/cp/id/23/
  • TODO: If your use case depends on any Minnesota-specific settlement administration order terms, extract those exact provisions from the court’s docket/settlement order and map them to DocketMath inputs.

Related reading