Changing Your Reward Model Without Losing Pending Referrals
Change referral reward rules without losing pending obligations. Freeze the ledger, reconcile every record, fulfill decisions, and publish the migration policy.
Last updated: October 1, 2026
A reward-model change has two timelines: the new rule for future referrals, and the obligations already pending under the old rule. Treat the second timeline as a reconciliation project. Before the new rule takes effect, establish a baseline, make an explicit decision for each legacy obligation, and give collaborators a policy they can understand.
This guide covers changing reward rules inside a Siren program that is already running. If you are moving from another platform to Siren, start with Migration Overview.
Start with the obligation ledger
When a referred sale qualifies, Siren creates a pending obligation for the collaborator using that program’s configured reward rule. An obligation remains pending until it is processed into a fulfillment or rejected. What Are Obligations? explains the ledger and its pending, complete, and rejected states.
A fulfillment records the obligations selected for payout. Fulfillments are permanent ledger entries, so they preserve the historical record of what was decided and paid. See What Is a Fulfillment? for the underlying record.
Do not rely on a later rule change to explain or resolve work that was already pending. Preserve the pre-change set first, then reconcile it against a documented policy.
1. Freeze and export the pre-change ledger
Before changing program configuration, export the pending-obligation set and treat it as the reconciliation baseline. Capture the collaborator, obligation ID, amount, underlying transaction, current status, and legacy program context for every record. Add the snapshot time, the migration owner, and the effective date for the new rules.
Keep the export with the change record. It gives your team a fixed answer to the question, “What was pending when the policy changed?” and lets reconciliation proceed from evidence rather than from a later view of the program. Use Reporting for reporting and export guidance.
2. Label the new rules with a separate program
Run the new reward rule as a separate program alongside the legacy program. Two differently configured programs can operate on the same site, and pending obligations are tracked separately for each program.
This puts the old-versus-new distinction in the operating data. The legacy program identifies the obligations in the frozen set; the new program identifies activity governed by the new rule. Define the boundary before launch: the effective date, which participants or referral paths belong to each program, and how your team will handle events close to the cutoff.
3. Reconcile every legacy obligation to a decision
Work through the frozen set one obligation at a time. Each record needs an outcome and a retained reason.
| Decision | Operator action | Record to retain |
|---|---|---|
| Honor the accrued reward | Include the obligation in the fulfillment set | Legacy amount, program context, and fulfillment link |
| Apply a conversion policy | Document the calculation and handle the specific obligation under that policy | Conversion method, approver, and resulting decision |
| Reject the obligation | Reject it with an auditable reason | Rejection reason and related transaction or policy record |
A reward-rule change does not convert accrued rewards for you. If you choose to exchange a legacy reward for a different reward, credit, or benefit, publish the terms and carry out that policy through explicit obligation handling. Do not leave the outcome implied by the new program’s configuration.
Refunds are a separate case. If the transaction behind an unpaid, unfulfilled obligation is refunded, Siren rejects the obligation and cancels the transaction, removing it from the amount owed. Record that distinction clearly: a refund is a transaction outcome, not a silent consequence of the reward-rule change.
4. Generate fulfillments for the decided set
After reconciliation, select only the obligations your policy says to fulfill. Siren lets you select specific pending obligations and review a per-collaborator breakdown before committing to a fulfillment. Use that review to confirm that the selected set matches the migration record.
Follow How to Pay Collaborators for the payout workflow. If a payout later needs correction, it can be reverted to unpaid and processed again.
Do not use fulfillment to conceal unresolved records. Leave an obligation pending only while it has an owner, a next action, and a traceable exception process.
5. Publish the migration policy
Publish the policy before, or when, the new rule takes effect. Participants need to know the effective date, how already-pending referrals are treated, how any conversion was calculated, what a rejection means, and where to ask about a specific record.
Keep the public explanation aligned with the reconciliation ledger. If the policy says legacy obligations are honored, the fulfillment record should reflect that outcome. If it offers a conversion, retain the calculation with each affected decision.
A question about one referral calls for a record-level investigation rather than a cohort-wide migration procedure. Direct those cases to Investigating a Collaborator Dispute.
Script the reconciliation when volume requires it
For a large migration set, the REST API can apply an approved policy at scale. Siren provides endpoints to generate fulfillments from specific obligation IDs, update or bulk-transition fulfillment status, and export payouts to CSV.
Review All REST Endpoints before automating the runbook. Automation should carry out decisions you have documented; it should not replace the policy decision.
The change is complete when the new program has a clear start, every obligation in the frozen set has a documented outcome or active exception, and collaborators can understand how their pending referrals were handled.