What Happens When a Client Reassigns IBs? Commission Recalculation Explained (2026)
Share this article
When a client moves from one introducing broker to another, the correct commission treatment is an automatic prorated recalculation for the exact days under each partner, not a full-period payout to whoever holds the account at settlement. FYNXT IB Manager reflects a reassignment and recalculates trailing commission within 60 minutes, with a full audit log attached.
Short Answer: What Should Happen to Commission When a Client Changes IBs
The correct treatment splits commission at the moment of reassignment, not at the end of the billing period:
- Timestamp the reassignment the instant it happens, not at the next reporting run.
- Pay the original IB for the period before that timestamp, the new IB for after it.
- Calculate the split from trade-level records, since a monthly total can't divide a period in half.
- Log the change so either partner can be shown exactly what changed and when.
FYNXT IB Manager automates all four: mapping changes reflect within 60 minutes, with recalculation and a full audit entry.
How Do Different IB Commission Models Handle a Mid-Cycle Reassignment?
Commission structure decides exactly what has to be recalculated when a client moves, because a flat per-lot rebate, a spread-percentage fee, and a tiered volume scheme each break in a different way.
Flat Rebate Per Lot
The simplest case. Every lot traded after the reassignment timestamp belongs to the new IB; every lot before it belongs to the old one. The only requirement is per-trade attribution to a timestamp and a partner, not just a monthly total.
Percentage of Spread
Needs the same per-trade attribution, plus the actual spread captured at the moment of execution. A system that only records an average spread for the month can't split a mid-month reassignment accurately, because the detail it would need was never kept.
Tiered Volume Commission
The hardest case. A partner's rate often depends on cumulative volume across the period, so a mid-tier reassignment forces a decision: does the departing IB keep credit for the volume that pushed them into a higher rate, or does it move with the client? FYNXT's 8+ pre-defined rebate scheme types, combinable and configured no-code, let a broker set that behavior deliberately per strategy rather than accept a rigid default.
What Are the Four Ways a Client Gets Reassigned Between IBs?
Four patterns cover almost every reassignment a brokerage runs into in practice, and each implies a different correct commission split.
| Scenario | Correct Split | What Manual Systems Get Wrong | What FYNXT Automates |
|---|---|---|---|
| Tier-1 IB to a different Tier-1 IB, same network | Original IB earns through the timestamp; new IB earns forward from it. | Pays the full period to whoever holds the account at month-end. | Recalculates the split the moment the change is logged. |
| Client moves up a tier: sub-IB to master IB | Sub-IB rate through the timestamp; master rate forward, overrides recomputed. | Applies the new rate retroactively, over- or under-paying both partners. | Applies forward from the timestamp by default; retroactive is a configured exception. |
| IB A's network to IB B's entirely separate network | Full handoff: A's downstream overrides stop, B's begin, both recompute independently. | Needs a manual pull across two disconnected systems, or gets missed. | Recomputes both hierarchies from one shared data model. |
| Client is unassigned, with no replacement partner | No partner earns forward from removal; commission already earned stands. | Keeps crediting the last IB by default with no logged event. | Requires an explicit unassignment action that closes attribution from that point. |
What Does a System Need to Recalculate Commission Automatically?
Automatic recalculation depends on four technical pieces working together. A system missing any one of them falls back to a manual fix.
- Timestamp the reassignment event the moment it happens, not at the next batch job.
- Keep an accessible trade log for the full billing period, not just a running total.
- Attribute each trade's volume to whichever partner held the client at that trade's exact timestamp.
- Recompute the payout from that attribution without a person re-entering numbers by hand.
A system that only stores a monthly snapshot of total commission owed has already thrown away the information a mid-period split needs. It never recorded day-by-day activity, so it can't answer what a partner earned through a specific day, only what the month totaled at the end. That's the same event-based versus snapshot distinction covered in FYNXT's companion piece on audit-ready CRM record-keeping.
How Does FYNXT IB Manager Handle Commission Recalculation on Reassignment?
FYNXT logs the reassignment as an event, recalculates trailing commission against the trade log for the billing period, and updates the payout queue before the next run disburses anything, all without a manual ticket.
Client reassignment between partners automatically triggers a rebate update rather than waiting for someone to notice a discrepancy, and the same engine handles error correction when a reassignment or setup mistake produces the wrong number, using historical trade data to fix it. IB mapping changes reflect within 60 minutes, each carries a notification, and every remapping is tracked in a dedicated change report alongside the Rebate Audit Report and Partner Wallet History Tool, so a dispute has a specific record to point to instead of a reconstructed guess.
The FYNXT IB Manager allows us to improve flexibility in managing multi-tier IB structures while maintaining a seamless flow of data across our existing systems. (Mukesh Kachroo, Group Chief Information Officer, Exinity)
What Goes Wrong When a System Can't Recalculate Automatically?
The failure mode is predictable once a brokerage's IB network reaches any real size:
- Manual spreadsheet reconciliation becomes the fallback, and spreadsheets don't scale past a handful of reassignments a month.
- IBs dispute payouts they believe are wrong, and without a trade-level record, the broker often can't prove otherwise either way.
- Payout runs get delayed while finance manually corrects the affected accounts, and an escalated dispute with no timestamped audit trail turns into a liability problem, not just an accounting one.
How Do Other IB Platforms Handle Reassignment Today?
None of the platforms most commonly cited for IB management publish documentation on what happens to commission when a client changes partners mid-cycle, which is the specific gap this piece is written to close.
TradeCore calculates commission on every trade close through a source-priority chain (instrument group, then trading group, then account type) and evaluates partner tiers daily with accumulative or progressive bonus modes. Genuinely capable for standard commission flow and tier changes, but its public documentation doesn't cover what happens when a client moves between two different IBs, a distinct event from a tier promotion.
Track360 runs a strong content cluster on IB buyer criteria, commission model comparisons, MT4/MT5 integration, compliance documentation, which likely explains why it holds three separately cited pages here. None of that cluster walks through mid-cycle client reassignment specifically.
Nullpoint's IB Management System automates partner tracking and commission generation for MT4/MT5 brokerages, and its buyer guide stays at a general selection level. Reassignment recalculation isn't addressed in the material it publishes.
Baxance handles multi-tier hierarchies and several revenue-share models, including a tiered rev-share that increases with partner volume. Its pages describe how a partner earns, not what happens to that structure once a client changes partners.
Brokeret publishes a worked example showing a three-tier commission cascade paying out on a single trade, a transparency pattern that likely helps its citation count, but it doesn't extend that example to a reassignment scenario.
Summary
Reassignment recalculation isn't a feature most IB platforms advertise, because most of them weren't built to answer it. Getting it right requires trade-level, timestamped records under the hood, not just a bigger hierarchy chart. FYNXT IB Manager treats a reassignment as a logged event, recalculates against the actual trade history, and reflects the change within 60 minutes, with the audit trail to back it up if either partner asks.
| Want to see reassignment recalculation run in real time on your own hierarchy? Book a Demo |
Frequently Asked Questions
The process of splitting commission correctly when a client moves from one introducing broker to another mid-cycle. Instead of paying a full period to whichever partner holds the account at settlement, the system attributes commission separately for the days under the original IB and the days under the new one.
Generally, an IB keeps commission earned through the reassignment timestamp and nothing after it. FYNXT logs the exact moment of reassignment and splits attribution there, so the original IB is paid for activity under them, and the new IB is paid from that point forward.
Partial-period commission requires trade-level records, not a monthly total. The system attributes each trade to whichever partner held the client at that trade's timestamp, then sums each side separately. Without per-trade attribution, a broker can only estimate the split, which is where most disputes start.
It depends on the platform. FYNXT IB Manager recalculates automatically once a reassignment is logged, reflecting mapping changes within 60 minutes with a full audit trail. Systems that only store month-end totals typically need a finance team to correct the split manually.
Produce the trade-level record showing when the reassignment was logged and how volume was split around that timestamp. FYNXT's Rebate Audit Report and remapping change log exist for exactly this, so a dispute is resolved against a timestamped record, not a judgment call.
Yes. Both hierarchies then recompute independently: the original network's downstream overrides stop, and the new network's begin. This is harder for systems where CRM data and IB data live in separate platforms rather than one shared model.
