Turnkey development of a commission system for a crypto exchange

Crypto exchange commission system development: where the calculation breaks down

Commission is the most common point where an exchange loses user trust.

While tariffs live in manual tables, and trading, withdrawal, and referral circuits calculate charges separately, discrepancies in charges arise out of nowhere: a volume-level discount applied to a trade but not to a withdrawal; a referral charge was calculated from the amount before commission deduction, not after.

Development of a crypto exchange commission system starts not with code, but with a tariff logic model: which attribute sets the rate — volume level, account role, pair type, acquisition channel; who wins in a rule conflict; at what point the rate is fixed to a trade.

While this layer rests on manual tables, editing a tariff results in rebuilding history and a new wave of disputes.

Commission calculation on an exchange must be reproducible: for any trade, an engineer can pull up a snapshot of applied rules and explain the figure down to the last digit.

Then errors in commission charges are caught during reconciliation between circuits, not in a user request, and the calculation period closes according to regulations, not by the number of resolved claims.

We break down how this is covered: a unified tariff model, a log of applied rules, and automatic reconciliation between accounting circuits.

What changes after implementation: effect in measurable values

After moving the calculation into the system, the effect is visible in operational metrics, not in promises.

Charge automation removes the reconciliation stage: the rate is taken from the tariff version in effect at the time of the trade, so the speed of the calculation period stops depending on operator workload — the window closes according to regulations, not by when manual review is done.

The reduction of disputed charges comes from the same place.

A trader sees which rate and which rule applied to a specific trade — tariff transparency for traders replaces correspondence with support, and a dispute is resolved using the charge log, not exports from several sources. The share of requests that reach manual review drops manyfold.

A new tariff goes into production in one approval cycle: levels, limits, and exceptions for market makers are described by configuration, not by editing the calculation core.

Running it on historical trades shows how the tariff would have applied to past turnover — before enabling it in the production circuit.

The volume of manual adjustments shrinks to exceptions: refunds, partner schemes, one-off promotions.

Every edit remains in an immutable log with the author, reason, and link to the original charge — this removes constant manual tweaks and provides reporting suitable for audit under MiCA requirements.

Tariff model options: comparison of approaches

The fee model is part of the trading core, not an accounting setting. It determines what happens when an order is placed, how commission is reserved, how account balances are rounded, and what the client sees in the report.

Therefore, the tariff option is chosen together with the architecture: changing the model on a live exchange affects trade history and already accrued fees.

In practice, the choice is between five families — from a fixed rate to a hybrid tariff model:

Any of them is described by configuration, not code: thresholds, rates, and charge rules are edited without releasing a new version.

A hybrid is assembled from ready-made blocks — for example, a multi-level grid plus partner charges — and tested on historical trades before going live.

How we conduct implementation: stages of engineering work

Commissions are the most sensitive part of exchange economics: a calculation error is visible to the user before monitoring, and costs trust in balances.

Therefore, implementation proceeds not as editing a formula, but as transferring accounting rules with reconciliation at every step.

1. Exchange calculation audit. We collect all charge points: trades, withdrawals, internal transfers, partner payouts. We reconcile operation logs with actual balances and extract rules that exist only in code.
2. Tariff model design. We describe user levels, rates for adding and removing liquidity, rule priorities, and discounts. The model is stored as a versioned configuration, not as branches in code.
3. Charge engine setup. We make the calculation idempotent: a charge is tied to the trade ID, and a repeated run does not double the debits. The applied rule and its version remain in the log.
4. Reporting and control. We aggregate charges by users, pairs, and periods, and set up automatic reconciliations: a discrepancy between calculated and actual commission surfaces before export, not after a complaint.
5. Migration to the new rate grid. We run the new model on an export of past trades and compare it with what was actually charged. We review discrepancies one by one — this is how rare scenarios are found.
6. Transition period. The old and new models calculate in parallel, and discrepancies go into a separate report. We switch by segments — by user groups or pairs — while retaining the ability to roll back.
7. Handover to the client's team. We provide flow diagrams, configurations, and the rate change procedure. Your engineers change the tariff grid and add levels without our involvement.

Implementation artifacts: calculation diagrams, regulations, and exports

We form the documentation set so that the client's team can change charge rules themselves and pass external audits without contacting us.

Artifacts sit next to the code and are versioned together with it: a rule is changed through configuration with an edit history and rollback procedure, not through correspondence. Below is what exactly is handed over at acceptance.

• Charge documentation — all rate levels, rebates, promo periods, rounding procedure, and rule priority when promotions overlap, including scenarios for canceled and partially filled trades.
• Exchange data flow diagram — the path from a trade event in the trading core to a record in the charge log and reporting aggregates, marking idempotency points, retries, and places where data reconciles between systems.
• Rule configuration — parameters for levels, volume thresholds, currency pairs, and validity periods, describing which changes apply without deploying a new version and which require history recalculation.
• Calculation reconciliation procedure — frequency, composition of control sums, the discrepancy share that triggers review, who records the cause, and how an adjustment is documented.
• Export templates for financial reporting — formats, field set, breakdown by periods and currencies, and the procedure for reconciling with the operation log.
• Support instructions — typical charge-related requests, what to look at in the log by operation ID, which edits an operator may make and which only an administrator may make.
• Reference calculation set — control examples for levels, promos, and cancellations, used to verify correctness after any rule changes.

Acceptance follows a checklist: we run the calculation on a sample of operations and compare the result with the reference.

After that, the team performs rate changes and launches new promotions on its own — it has both the configuration and a way to verify that the calculation remains correct.

Case study: transition to a multi-level rate grid

Crypto exchange Orbita Exchange kept rates in a configuration tied to the release cycle: the commission system was updated together with the account service, and the calculation period was closed manually.

Starting point

Rates applied only to new trades; accumulated charges were recalculated with a separate export. Closing the period took 5-6 business days: the finance department aggregated turnover by pairs, looked for fractional rounding discrepancies, and corrected them manually.

The share of support requests about charges stayed at 18% of all tickets, and a new rate level took up to three weeks to release — from analyst task to release.

What was changed

Charges were moved to an event model: commission debits are recorded as a separate operation with a link to the trade, so reprocessing does not double the amounts.

The rate grid became a versioned set with an effective date — a level is configured in the admin panel, applies to trades after the specified date, and does not require deploying the service.

Migrating users to the new grid took place without stopping trading: open positions ran to completion under the previous rules, while new ones were calculated using the updated rates. Every edit leaves a record in the audit log.

Result

The period closes within a day, and discrepancies are visible at the reconciliation stage, not during manual review. The share of charge-related requests dropped to 4%: support has tracing down to a specific trade and applied rate.

A new level is released in a day, and rollback is a return to the previous version of the set without stopping trading.

How does a multi-level rate grid differ from a partner scheme?

A multi-level rate grid and a partner scheme are often perceived as the same thing: both reduce a participant's costs. The difference is in the calculation base.

The grid changes the commission rate itself for a specific account; the partner scheme leaves the rate unchanged and accrues a fee to the inviter.

The key difference is in liability accounting. A grid discount reduces income before it is recognized: the exchange simply receives less.

A partner fee is an expense after commission is charged; it has its own lifetime, cancellation conditions upon fund outflow, and a separate reporting circuit.

A separate story is trading volume thresholds. The rate level is recalculated over the window, and if the threshold is not maintained, a reverse recalculation is triggered for already closed trades. Such a recalculation must be idempotent, otherwise a repeated run will double the charges.

Choosing a scheme is choosing a liquidity acquisition model. Large venues, for example Binance, maintain a level grid and a partner program at the same time: the first works for market makers, the second for retail referral networks.

They cannot be mixed in one entry — the calculation bases and liability recognition procedures diverge.

Frequent technical questions before starting work

Before starting, clients check the same things: how existing users will be migrated, whether rates can be edited on a live exchange, what confirms charge correctness, who is authorized to change tariffs, and how reporting for accounting is assembled from this.

Can rates be changed without stopping trading?

Yes. Tariffs are versioned: a new version takes effect from a specified moment, and trades in process are calculated using the previous one. Rollback is switching to the previous version, without editing the charge log.

How can we make sure charges are calculated correctly?

We run a shadow calculation on archived trades and compare it with actual commissions. The output is a discrepancy report with causes: rounding, tariff priority, period boundaries.

Who has access to tariff settings?

Roles are separated: an analyst sees rates but does not publish; a second employee confirms the change. Production and test circuits are isolated; every action is in the log with author, time, and previous value.

What will accounting receive?

Exports by periods, instruments, account types, and operation types in an agreed format. Amounts reconcile with balance data, and reconciliation is automatic.

Let's discuss the task and come back with an estimate and plan

So that the estimate is based on facts, not assumptions, we start with inputs for your circuit.

Describe the current rates and level logic, operation volumes on average and at peak, how balances and sub-accounts are currently accounted for, and reporting requirements from auditors and regulators.

Based on this data, we assemble a work plan for calculations — from the charge and debit model to reconciliation of calculated and actual balance — select the project team composition, and come back with an estimate for the implementation project. What to send:

• inputs on current tariffs: rates by pairs, levels, and operation types, promotional terms, exceptions for certain client groups;
• balance accounting scheme: accounts, sub-accounts, fund freezes, referral and partner charges;
• expected volumes: number of operations and active accounts at peak and on average, expected growth;
• reporting requirements: composition of exports, frequency, reconciliation format, history retention depth;
• constraints: scheduled maintenance windows, access separation, security rules;
• integration points: exchange core, payment module, accounting system, analytics;
• expected result: what exactly should change in calculations and reporting.

Describe the task in free form — we will come back with an estimate and work plan.