Rebate tier drift, and the reconciliation nobody runs
Introducer agreements are renegotiated continuously and calculated from a spreadsheet that is updated occasionally. The gap between those two facts is a recoverable liability.
Partner payouts are calculated monthly from a spreadsheet that encodes agreements renegotiated continuously. Nothing validates one against the other. The result is a slow, compounding liability that surfaces at audit, when it is least convenient and hardest to recover.
Where the error actually originates
The intuitive assumption is that mistakes come from the tier table, someone typed 8 instead of 6. In practice the tier table is the most-checked artefact in the chain. The errors accumulate upstream, in attribution, where nobody is looking.
| Stage | What can go wrong | How visible |
|---|---|---|
| Attribution | Account credited to the wrong introducer, or to none | Invisible |
| Volume aggregation | Closed accounts, bonuses, or internal accounts included | Invisible |
| Tier resolution | Stale tier, or the wrong effective date applied | Semi-visible |
| Rate application | Per-lot rate applied to notional, or currency not converted | Usually caught |
| Payment | Right number, wrong beneficiary | Always caught |
payout = Σ over accounts a [ lots(a, period) × rate( tier( volume_total ) ) ]Because the tier is a function of aggregate volume, one wrongly attributed account does not cause one wrong line. It causes the whole introducer to be paid at the wrong rate.
Why it drifts rather than breaks
An agreement is a document. A payout run is a query. Nothing connects them, so they diverge gradually rather than failing loudly:
- A renegotiation is agreed by email in March and the spreadsheet is updated in June, or not at all.
- An effective date is applied from the start of the month rather than the date signed, or the reverse.
- A sub-introducer is added and inherits the parent tier, when the agreement says otherwise.
- An introducer is moved to a new entity, and volume history does not follow, resetting them to the lowest tier.
- Clawback terms for early withdrawals exist in the agreement and in nobody’s query.
Each of these is individually small and individually defensible. Together they mean the payout run and the signed agreements have not agreed for some time, and no one knows by how much or in which direction.
The reconciliation that should run
- 01Rebuild attributionFrom account origin records, not the CRM field
- 02Recompute volumeExcluding bonus, internal and closed accounts
- 03Resolve tier from the agreementUsing the signed effective date
- 04Compare to the proposed payoutLine by line, per account
- 05Hold every mismatchPay the rest on time
Direction matters more than magnitude
Underpayment is a support conversation. Overpayment is a recovery conversation with a counterparty who is bringing you business, and it is usually unwinnable, commercially if not legally. Any control that runs after payment has already lost. This is the rare case where the value of the check is almost entirely in its timing.
| Introducer | Proposed | Recomputed | Difference | Cause |
|---|---|---|---|---|
| IB-0412 | $18,900 | $14,180 | −$4,720 | Tier 2 applied, agreement says Tier 3 |
| IB-1180 | $7,240 | $7,560 | +$320 | 19 accounts attributed to no one |
| IB-2207 | $11,050 | $11,050 | , | Matches |
Illustrative figures, chosen to show the mechanism. Your own numbers will differ.
What it takes to run every time
The blocker is rarely the calculation. It is that the signed agreement lives in a contract folder, the attribution lives in the platform, the volume lives in the trade database and the proposed payout lives in a spreadsheet on somebody’s machine. A reconciliation that spans four systems gets run once, after an incident, and then never again.
Holding the agreement itself, terms, effective dates, clawback conditions, as structured data joined to the accounts it covers is what turns this from a quarterly project into a check that runs before every payout without anyone remembering to start it.