Real-time risk management, in a market that never closes

Digital-asset markets trade continuously and move faster than a batch cycle can describe. Safetifi revalues the entire book on a continuous loop and streams the result — so the number on the screen is the number now, not the number at last night’s close.

What "real-time" actually means here

The phrase is used loosely, so here is the mechanism. Venue prices arrive over WebSocket, so a move reaches the book in milliseconds rather than on the next poll. A price move triggers a revaluation of the whole book — exposure, margin, collateral and limits — throttled to about a second and self-limiting, so the screen reflects the market roughly as fast as a person can read it. Fills land over a persistent connection with per-source sequence numbers, gap detection and resync, and the book applies them as events rather than overwriting a snapshot. Results are pushed to every open screen over a live stream with a polling fallback. The browser displays; it never calculates.

  • Prices streamed over WebSocket, with a REST sweep behind it as reconciliation
  • Revaluation triggered by price moves, not only by a timer
  • Streaming ingestion of fills — WebSocket with sequence gap detection, FIX drop-copy, NATS
  • Event-sourced book: corrections are appended as events, never silent overwrites
  • Results pushed to every client over a live stream, with a polling fallback

Why batch risk fails an intermediary

Overnight risk assumes the market pauses and that the difference between two closes is the story. In digital assets the damaging moves happen between those points, and the margin schedules themselves change intraday — a venue can raise initial margin on a symbol at any hour, which silently turns every client tier priced beneath it loss-making. A report produced the next morning tells you what the loss was. A live book tells you while it can still be acted on.

Two cadences, kept separate

A digital asset can move fifty per cent in a minute, so a breach discovered on the next scheduled slot is a breach discovered late. Safetifi therefore runs two clocks and does not compromise between them: price-driven recomputes reach the screen immediately, while a separate aligned grid on exact UTC boundaries — :00, :15, :30, :45 — is what gets recorded to history and what an end-of-day figure is stamped with. Recording every price-driven compute would turn the series into one row per tick; scheduling the screen off the grid would make you wait.

Before the fill, not after it

The only moment a limit is cheap to hold is before a trade exists. Safetifi prices a hypothetical ticket against the live book: the margin spread on that trade, its marginal portfolio-margin effect after offsets, the before-and-after view of net exposure, value-at-risk and liquidity, and a limit check that isolates this trade’s own contribution rather than flagging a breach the book was already carrying.

Questions

Real-time risk management: common questions

Venue prices arrive over WebSocket, and a price move triggers a revaluation of the whole book throttled to about a second. Positions arrive as they fill over a streaming connection. Results are pushed to connected screens rather than polled for. Separately, snapshots on an aligned fifteen-second UTC grid are what get recorded to history. There is no overnight batch and no manual refresh in the workflow.

Ingestion uses per-source sequence numbers with gap detection: an out-of-order message is rejected with the expected sequence and the source resends from there, and after a gap the client resyncs to a current snapshot. On the display side, the live stream falls back to polling automatically.

No. Safetifi reads from the systems you already run, over the transport your operations team already supports, and stores state in your own database. It is an intelligence layer, not a migration.

See it against your own book

A pilot connects one channel against a slice of your live book and reports what it finds — client by client, product by product.