Scoping a forex CRM: client portal, KYC workflow and IB commissions

IB commission rules: write them as worked examples

Commission rules are the part of a forex CRM scope most likely to be underspecified. Every broker can describe its partner deal in one sentence, and that sentence hides five decisions.

Start with the basis. A per-lot rebate pays an introducing broker a fixed amount for each lot their clients trade, often with a different rate per account type or instrument group. A percentage model pays a share of the spread or commission the broker earns, so the CRM needs that revenue figure for every trade, not just the volume. Multi-level schemes add sub-IBs: the top partner earns on their own clients and an override on the clients of partners below them. Say how many levels you allow and whether rates are set per plan or per partner.

Then timing. Is commission calculated per closed trade, daily or at month end? Does it stay pending until finance approves it? Can it be clawed back when a partner abuses the scheme? Does the payout go to a wallet, a trading account or a bank?

My rule is firm. I would not start building the IB module until the broker has worked out three real payouts by hand, including one multi-level case and one awkward edge case. If finance and the partner team reach different totals from the same example, that gets settled before any code exists.

KYC review states and the audit trail behind them

A KYC workflow is a set of states with rules for moving between them. The screens come second.

The list I usually start from: not started, documents submitted, under review, more information requested, approved, rejected, and expired when a document passes its validity date. Some brokers add an enhanced review step for higher-risk clients. Which states you need, which documents each client type provides and what triggers a review are compliance decisions. They belong to the broker and its advisers. Nothing in this article is legal advice.

The software must record every move: who made it, when, the old and new state, the reason entered and the document version reviewed. Documents are never overwritten; a re-upload becomes a new version. Then fill in a small table: in each state, can the client log in, open a demo account, deposit, trade or withdraw? That table drives most of the traders' room logic.

Deposits and withdrawals need an approval path on paper

Money movement is where a vague scope gets expensive.

For deposits, decide whether a provider's confirmation credits the client automatically or a back-office user approves it first, and whether that varies by amount, method or KYC state. Withdrawals raise more questions. Who reviews the request? Is there a second approver above a threshold you set? Should the system check open positions or free margin before releasing funds? What happens to a request the provider rejects?

Each request gets its own status history, the same as a KYC file. I also want one ledger view with wallet balance, trading account balance and pending requests side by side, so finance can reconcile against the provider's reports.

What the traders' room needs first, and what it connects to

The traders' room is the part clients see. In the Forex CRM it is where clients open accounts, upload documents and request funding, so it inherits every rule from the sections above.

For a first version I would keep it to registration, KYC uploads, live and demo account requests, deposits, withdrawals and transfers between a client's own accounts. Extras can wait.

Two lists decide most of the integration effort: the trading platform you run and the payment providers you have contracts with. For the platform I need its name, who grants access and whether a test environment exists. For each payment provider I need its documentation and sandbox credentials. I do not estimate an integration from a provider's name alone.

Roles, brands and the checklist I send brokers

Access rules are cheaper to design early than to retrofit. A compliance officer approves KYC files but should not edit commission rates. A finance user approves withdrawals but should not change client documents. Sales staff may see only their own leads. Write roles as a grid of actions and data, not job titles.

If you run more than one brand, say so now. The Forex CRM is multi-tenant, with each broker on its own domain and branding and data kept separate per tenant, and that decision belongs in the architecture from the first week.

This is the checklist I work through before writing a quote:

From written answers to a fixed quote

Custom software like a forex CRM has no published price. I quote it as a fixed price after scoping, once the answers above are written down and agreed. A first phase usually covers onboarding, KYC, the traders' room and the back-office, with the IB portal and further integrations in later phases, each with its own written scope and price.

Third-party fees and hosting sit outside the quote. Licensing and regulatory decisions stay with you. I build the software, the workflows and the audit trail that shows what was decided and by whom.

If you can answer half the checklist, send that half. The gaps are what the scoping call is for.