How Structured Settlement rules vary in Utah

What varies by jurisdiction

In Utah, structured settlements are governed by the Utah Structured Settlement Protection Act (the “Act”), located at Utah Code § 78B-6-1101 through § 78B-6-1108. A central theme of Utah’s statute is that transferring structured settlement payment rights is heavily restricted—and, if a transfer is intended to be effective, the Act’s conditions determine whether payment rights can be enforced as to a transferee.

If you’re using DocketMath (including the /tools/structured-settlement calculator), it’s helpful to separate two ideas:

1. The math (present value / discounting based on inputs like payment dates and remaining term), and
2. The legal “switches” (whether the payment stream is actually enforceable in the hands of a transferee under Utah law).

Utah’s baseline rule (the practical default)

Per the note in your jurisdiction summary, no claim-type-specific sub-rule was found. That means Utah’s approach—at least as captured here—does not appear to change the transfer-validity framework based on claim category (e.g., auto vs. medical vs. workplace).

So, the practical default is:

• No direct or indirect transfer of structured settlement payment rights is effective unless the requirements in the Act are satisfied.
• The statute also restricts how a structured settlement obligor and annuity issuer must handle payments when a transferee is involved.

Why this matters for outputs: even if DocketMath’s calculation is arithmetically correct, the valuation could be based on the wrong “recipient” assumption if a proposed transfer is not enforceable under the Act.

Where Utah differs from other places (the practical impact)

Across jurisdictions, structured settlement regulation commonly varies in operational details such as:

• whether assignment/transfers are permitted at all,
• notice and documentation requirements,
• disclosure rules,
• timing conditions for when changes become enforceable,
• how the obligor/issuer must treat a payment-right change.

For Utah specifically, because the Act emphasizes transfer effectiveness and who is entitled to receive payments, your DocketMath workflow should be designed around an important modeling question:

• Who receives the payment stream in the enforceable scenario?

If the transaction is not legally effective, the original payee may remain the practical recipient for valuation purposes. If transfer effectiveness is confirmed, you can model the payment stream as going to the transferee.

What to verify

Use DocketMath to organize and quantify the payments, then verify the Utah-specific legal conditions that affect whether the payment stream can be routed to a transferee under Utah Code § 78B-6-1101–§ 78B-6-1108.

Gentle disclaimer: This is informational and helps you structure the workflow. It’s not legal advice.

Think of it as a two-layer checklist: (1) transaction validity and (2) payment-stream modeling.

1) Confirm whether a “transfer” is being attempted

Start by identifying whether your scenario involves:

• an outright sale/assignment of structured settlement payment rights, or
• another mechanism that could be treated as a direct or indirect transfer.

From the Act’s framing, Utah’s restrictions are triggered where payment-right transfers are involved.

Quick verification questions (workflow-level):

• Is the current payee seeking to sell or assign future payments?
• Will a transferee attempt to have the obligor/issuer pay them (directly or indirectly)?
• Are you modeling proceeds to someone other than the original payee?

2) Verify whether Utah’s conditions for effectiveness are satisfied

Utah’s cited language indicates that if transfer effectiveness is not established, the obligor/annuity issuer may not be required to treat a transferee as the payment recipient.

For DocketMath modeling, this creates a key requirement:

• Confirm whether the transaction is legally enforceable such that the transferee actually receives the payments.

If you can’t confirm enforceability yet, you risk valuing an outcome that may not be achievable.

3) Apply the “general/default period” (since no claim-type-specific sub-rule was found)

Because your note indicates no claim-type-specific sub-rule was found, your Utah workflow should treat the transfer-protection framework as general/default rather than swapping rules by claim type.

Practical effect in DocketMath:

• You may reuse the same core cash-flow inputs across claim types in Utah, but
• you still must validate transfer effectiveness because that’s the gatekeeper to whether the payment stream can be routed.

4) Document the factual inputs that drive DocketMath outputs

Even though legal effectiveness controls who receives payments, DocketMath outputs still depend heavily on the underlying stream inputs. Capture what you can from settlement paperwork so calculations can be audited later.

5) If you’re uncertain, model two scenarios

If you can’t yet confirm the transaction’s enforceability under the Act, consider running two DocketMath scenarios:

• Mode A: original payee receives payments
• Mode B: transferee receives payments (only after Utah requirements are confirmed)

This quantifies how sensitive value is to the legal routing of cash flows.

Related reading

• How to calculate Structured Settlement in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Structured Settlement in Philippines — Worked example with real statute citations
• Inputs you need for Structured Settlement in Philippines — Input checklist with sourcing guidance

For a Utah-run valuation workflow, start here: /tools/structured-settlement

Sources and references

• Utah Structured Settlement Protection Act, Utah Code § 78B-6-1101 to § 78B-6-1108 (source: https://le.utah.gov/xcode/Title78B/Chapter6/78B-6-P11.html).

  • Statute text provided in your brief indicates: “No direct or indirect transfer of structured settlement payment rights shall be effective … [and] no structured settlement obligor or annuity issuer shall be required to make any payment … to any transferee …”