If you run — or are about to launch — a leveraged trading product, the risk engine is the component that decides whether you are running a business or an uncontrolled exposure. A broker risk engine is the server-side system that computes margin, PnL, margin calls, stop-outs and liquidations for every open position, continuously, from one authoritative set of formulas.
That last part — server-side, one set of formulas — sounds obvious. It is also where a surprising number of platforms quietly cut the corner.
The client-side margin trap
The fastest way to ship a leveraged product is to put the margin math where the UI already is: in the app. The web terminal computes required margin from the quote it has; the mobile app duplicates the formula; the API documentation describes a third variant that was true two releases ago.
Each copy is individually reasonable. Together they are a machine for manufacturing disputes:
- Two screens show two different margin levels for the same account, because they saw two different ticks.
- A stop-out fires "too early" according to the app the trader was watching — and support has no single number to point to.
- A partner integrates over the API, re-implements the formula with one wrong rounding rule, and their users' numbers drift from yours.
When margin math is scattered across client apps, every screen computes its own truth — and the broker pays for the difference.
None of these are exotic edge cases. They are the default outcome of client-side risk, and they surface at the worst possible time: during volatility, when positions are large, spreads are wide and everyone is already angry.
What a server-side risk engine actually does
In our stack the risk engine is part of Bicut Core — the same production system that runs our own live brokerage. Its responsibilities, in the order traders meet them:
| Stage | What the engine computes |
|---|---|
| Before the order | Required margin, resulting margin level, liquidation preview — the exact stop-out price, shown before submission |
| While the position is open | Unrealized PnL, equity, margin level per tick — isolated and cross modes |
| At the thresholds | Margin call and stop-out events, emitted server-side and pushed to every connected client |
| At liquidation | Deterministic close-out through the same order pipeline, with an auditable trail |
Because the engine emits events rather than letting apps infer state, every client — web, mobile, a partner's bot connected over the API — renders the same account at the same moment. The 198 REST endpoints and 102 WebSocket events of the backend all read from that one calculation, not from parallel copies of it.
The parts that only hurt in production
A margin formula fits on a napkin. A risk engine is everything around the napkin:
Price sources. Which price liquidates a position — bid, ask, mid, index? What happens when a source stalls for four seconds? If your vendor has no answer rehearsed, the market will improvise one for you.
Isolated vs cross. Cross margin turns one account into one shared pool of risk; isolated turns every position into its own little account. Supporting both is not a UI toggle — it changes every formula downstream, including how funding and partial closes settle.
The audit trail. When a client disputes a liquidation, the winning answer is a replay: these ticks came in, these thresholds were crossed, this event fired at this timestamp. Logs are not a compliance decoration; they are how you end arguments.
This is also why we treat the risk engine as a product with its own audit service around it. Findings like "margin call fires from a stale price during failover" are cheap to fix on a test stand and existentially expensive on a Friday evening in production.
Build, rent, or take a running one
Building a risk engine in-house is legitimate — if risk is your product and you have a couple of years. Renting one inside a monolithic platform works until you need a trading mode the vendor doesn't have.
The third option is taking a production engine as a module: keep your custody and execution, plug the risk layer into your own stack. That is the shape we sell, because it is the shape we run — the same engine backs CFDs, perpetuals, spot, swaps, mempool trading and prediction markets on our own brokerage, and uptime on that core is measured in production, not in a slide.
Whichever way you go, the diligence question is the same one we opened with:
Where does the margin call fire — in the app, or on the server?
If the answer takes longer than one sentence, you already have your answer.