How do you implement B-book exposure monitoring?

Start with the decision the dealer must make

An exposure dashboard is useful when it answers an operational question: which instrument, client group or legal entity needs attention, what evidence supports the alert, and who owns the next action? Start discovery with the dealer, risk owner and platform operator. Record the limits they use, the hedges they can place and the evidence they need before acting. A screen full of notionals without an agreed response is another report to watch.

Separate this implementation from the broader decision about holding or hedging flow. The broker must approve its execution, risk and client-treatment policies. The monitoring system should expose those policies and their versions; it should not silently invent routing rules or optimise against an individual client's outcome. Begin with read-only monitoring and require a separate review before connecting any execution action.

Build a position ledger before adding an AI layer

Use an ingestion adapter for each permitted trading-platform or bridge interface. Capture the source event identifier, account, symbol, contract size, side, quantity, price, event time and receipt time. Preserve amendments, partial closes and corrections as events. A deduplication key makes replay safe, while a checkpoint records how far each source has been consumed. Keep the original event available for investigation under an approved retention policy.

A deterministic projection converts those events into open positions and realised activity. Normalise symbol aliases, contract specifications, account currency and time zones explicitly. Keep price marks and foreign-exchange conversion rates with their timestamps. The calculation must distinguish gross exposure from net exposure: offsetting positions can reduce the net number while leaving concentration, basis or liquidity risks that still matter to the desk.

Compare the projection with authoritative platform snapshots on an agreed schedule and after reconnects. Unexplained differences belong in a reconciliation queue with a named owner. Do not label the view current while a source is missing or the ledger disagrees with the platform. The dealer should see a clear degraded state and the last successful reconciliation time.

Define each integration and its failure behaviour

The following is an implementation contract to agree during discovery. The exact interfaces and tolerances depend on the broker's platforms, permissions and operating policy.

Calculate risk in code; use AI for the explanation

Implement limit checks and scenario calculations as tested code. Define the units, rounding policy, price source and treatment of unusual instruments before agreeing the output. A simple currency pair, an index CFD and an option exposure cannot be made comparable merely by putting them in the same notional column. Where the desk requires sensitivity or scenario measures, document the model and its limits with the responsible risk specialist.

An AI assistant can draft a case summary from the resulting evidence: what changed, which limit was crossed and which positions contributed. Give it a narrow, permission-filtered view and require links to the exact calculation and source records. It must not invent a missing price or recalculate a position from prose. A dealer should be able to inspect the evidence without relying on the summary, and an unavailable model should not interrupt the underlying monitoring.

Acceptance tests that expose the hard failures

Agree measurable tolerances with the desk before building the interface. Test the calculation, recovery path and operator response together using controlled data.

• Replay duplicate, delayed and out-of-order events; the final positions must match the authoritative snapshot without double-counting.
• Exercise partial closes, amended trades, symbol aliases, contract-size changes and currency conversion; each expected result must be independently explainable.
• Disconnect an event source and freeze a price feed; the affected view must show its age and degraded state rather than continue appearing healthy.
• Trigger a limit crossing, a recovery and a repeated crossing; verify alert grouping, acknowledgement, escalation and the stored evidence for each transition.
• Check permissions across legal entities and roles; an operator must see only the accounts and actions their role permits.

Run in shadow mode, then hand over an operating system

Run the new ledger beside the desk's existing process before relying on it. Compare positions, valuations and alerts over representative sessions, including quiet periods and volatile or illiquid conditions where available. Investigate disagreements instead of averaging them away. Record which source is authoritative for each field and obtain the risk owner's acceptance of the remaining limitations.

The handover should include reconciliation runbooks, data-age thresholds, incident ownership, alert escalation, access reviews and a rollback procedure. Name the person who approves limit changes and the person who responds outside the normal session. Monitor event lag, reconciliation breaks, price age and failed deliveries. Review alerts with dealers after launch so that changes to thresholds and grouping remain deliberate, versioned and testable.