Trading platform IB system development is much more than adding referral links, coupon codes and a balance widget. A broker or trading-product operator needs a system that can explain who introduced a client, which commercial agreement applies, which trading or financial event created an earning, when that earning became payable and how the payout was reconciled.
The design principle is simple: marketing attribution, commission calculation and money movement must not be one editable record. Attribution can be corrected, trading data can be amended, rebates can be posted later and payout requests can be disputed. Preserve the original facts, then record corrections as separate, traceable events rather than silently rewriting history.
POLADO designs this kind of operational infrastructure through its FinTech & Trading Systems service, connecting the partner layer to the trading platform, CRM, KYC, wallet and back-office workflow. For an example of our FinTech and analytics work, see ESFX.
What an IB and partner system must answer
“Introducing broker”, affiliate, agent and regional partner are commercial and regulatory concepts that can vary by jurisdiction and operating model. In the U.S. futures market, for example, an Introducing Broker is a defined intermediary category. Your product’s activity may trigger specific registration, disclosure, AML, recordkeeping or conduct requirements. A commission engine is operational software, not a substitute for legal or compliance advice.
From a product and operations perspective, the system must answer these questions precisely:
- Which partner is entitled to a relationship with a particular client or trading account?
- What attribution rule and supporting evidence established that relationship?
- Is the commission based on deposits, lots, notional volume, net trading fees, spread revenue, swaps, or a defined hybrid formula?
- What makes an earning provisional, approved, payable, paid, reversed or disputed?
- What happens after a trade bust, fee correction, client refund, chargeback or fraud review?
- Can operations reconcile every partner payout to the earnings and source events behind it?
A dashboard alone cannot answer these questions reliably. The answers need to exist in the data model, versioned rules, event records and reconciliation process.
Do not treat attribution as a coupon-code field
A coupon code is only one possible attribution signal. A capable introducing broker platform development architecture accepts referral links, registration codes, invited-user relationships, CRM-originated leads, API imports and controlled back-office assignment.
The attribution record should contain
- Subject: client, legal entity or trading-account identifier;
- Partner: IB, master IB, affiliate or agent;
- Source: link, code, CRM import, approved manual assignment;
- Effective period: start and end timestamps;
- Rule and evidence: the applied policy, campaign and evidence reference;
- Status: pending, active, locked, superseded or disputed.
Consider a client who registered through Partner A’s link but was reassigned to Partner B by an internal sales team before KYC was completed. A safe system does not merely keep the user who made the last edit. It evaluates the applicable attribution policy, records when the decision became effective and preserves why the earlier relationship changed. The same revenue event should not reward two partners unless an explicit split rule permits it.
Make commission plans configurable, but versioned
Trading partner commission software should give commercial teams controlled flexibility without allowing them to change historical earnings invisibly. The practical pattern is to separate a commission plan from a commission-plan version.
A plan can include partner tier, instrument group, account type, region, client segment, eligibility conditions, hold period, payout currency and formula parameters. When commercial terms change, close the current version and create a new version with an effective date. Each earning event must retain the exact plan version used for its calculation.
Common models a commission engine may need
- A fixed amount per lot or defined volume unit;
- A percentage of a specified eligible revenue base;
- Different rates by instrument, client tier, account type or region;
- A transparent master-IB and sub-IB split in a multi-level affiliate commission engine;
- Thresholds, caps and progressive monthly tiers;
- Hybrid rules combining qualified funding and trading activity.
Define “revenue” inside the plan, not in a spreadsheet assumption. Gross commission, net trading fee, spread mark-up, swap income and revenue after client rebates are different bases. The formula should also define rounding, currency conversion timing, negative adjustments and what occurs if a source event is cancelled after a payout period has closed.
Use immutable earning events, not editable balances
A robust model consumes source events such as trade executions, fee postings, settled deposits, rebate postings, corrections and reversals. The commission service resolves attribution and the applicable plan version, then writes an earning event.
At minimum, the earning event should store the source-event ID, client and account IDs, partner ID, plan version, calculation inputs, calculated amount, currency, status and timestamps. It should use an idempotency key so that a replayed execution message or provider callback cannot create duplicate income.
If a trade is busted or a fee is corrected, do not delete the original earning. Create a linked reversal or adjustment event. This makes the balance movement explainable to the partner and gives finance a defensible audit trail for trading platform rebate calculation and payout reconciliation.
Historical facts should be retained; the current payable position should be derived from the original earning plus approved adjustment events.
Separate calculation from approval and payout
A calculated commission is not automatically a payable commission. A practical lifecycle may be calculated → pending hold/review → approved → payable → paid, with separate states for disputed, rejected, reversed and expired items.
Approval rules can route higher-risk combinations into an operations queue: a new partner’s first payout, unusually large value, abnormal trading volume, multiple accounts sharing payment credentials, earnings after a chargeback, or a manual attribution change. An approver should record a decision reason, operator identity and timestamp; a generic status flip is not enough.
When a payout batch is created, the system selects approved earnings, excludes held or disputed items, calculates the partner’s net payable amount and creates a payout reference. Bank, wallet or payment-provider results then need to be matched back to that batch. “Paid” should mean reconciled payment completion, not merely that an export file was generated.
What partners should see in an IB portal
IB portal development for brokers requires transparency without exposing unnecessary client data, internal margins or another partner’s performance. The portal should show information allowed by the agreement and make balances explainable.
- Referral funnel: leads, registrations, KYC state and active trading accounts;
- Eligible trading activity or volume, where contractually appropriate;
- Pending, approved, payable and paid earnings;
- Breakdowns by date, account group, instrument and plan;
- Adjustment and reversal reasons;
- Payout history, references and downloadable documents;
- Partner profile, payment details and relevant compliance documents.
Every summary number should have a drill-down route: summary → earning event → source event → applied plan version. This allows partner support, finance and compliance teams to work from the same evidence rather than reconcile competing spreadsheets.
Implementation checklist
- Identify authoritative trading events: executions, fees, corrections, account-state changes and reversals.
- Normalize client identity, KYC eligibility and account mappings from CRM, KYC and trading systems.
- Define attribution precedence, reassignment rules, lock periods and split-commission policy.
- Version commission plans; never overwrite the rule behind historical earnings.
- Keep audit records for source events, earnings, approvals, adjustments and payouts.
- Test duplicate events, delayed callbacks, partial failures, retries and replayed messages.
- Reconcile daily source totals against earned, approved, payable and paid totals.
- Apply role-based access, maker-checker controls and protection for payout data and exports.
An IB system is not a marketing add-on. It touches financial operations, client identity, trading data and payment controls. Designing it alongside the fee engine, ledger, KYC status and back-office workflow produces a more credible partner programme and a substantially easier path for dispute investigation.
Scope an IB commission system with POLADO
POLADO can help map attribution rules, commission-plan versions, source-event integrations, partner portals, approval queues and payout reconciliation for an existing or new trading product. The right first step is usually a technical and operational discovery: document source systems, exceptions, controls and ownership before implementation. For release governance, operational monitoring or an architecture review after launch, see our Technical Support & Consulting service.
If you need a dependable partner-operations layer rather than another referral dashboard, contact POLADO to discuss your trading platform, available APIs, payout process and regulatory constraints. The goal is an explainable commission system that operations can reconcile and partners can trust.