Wash books and risk routing

Client ──trade──► WASH BOOK ──back-to-back (system generated)──► RISK BOOK
                   (0 net risk)                                  (holds market risk)

The client-facing trade lands in the wash book. A system-generated, internally-countered back-to-back trade immediately routes the resulting market risk out of the wash book and into the risk book actually responsible for managing it.

This is borrowed terminology from equities, used in FX as well. It must not be confused with the unrelated regulatory/surveillance concept of "wash trading" — a pre-arranged trade with no genuine transfer of market risk, used to manipulate reported volume or price. That is a market-abuse pattern tracked for compliance purposes, not an operational process.

Wash books, IDTs, and risk routing are jointly classified as Risk Moves: putting the risk in the right book for the risk manager responsible for it — as distinct from position management, which moves cash/balances rather than risk (see the funding process and sweep for position-management examples).

Book purpose governs eligibility, following the same permissioning pattern as Funding Books (see Funding process): a book flagged as a Wash book is constrained so it must always remain risk neutral — the system enforces this as a property of the book's purpose, not booking discipline. A wash book must also carry a designated paired risk book — a book-to-book relationship, not merely a flag — since every back-to-back trade needs a target to route the risk into.

Implementation sizing (not yet built): a nullable self-referencing book.paired_risk_book_id FK to books.id is the right shape — directly following the existing business_unit.parent_business_unit_id and portfolio.parent_portfolio_id self-referencing nullable-FK precedent, so the field itself is a small, well-trodden addition. Two things push this past a trivial field-add and justify sizing it separately before pulling into a sprint:

• Conditional validation — paired_risk_book_id must be set if and only if book_purpose_type = Wash, plus a self-loop guard (a book can't be paired to itself). The trigger/=validate_*_fn= plumbing this needs already exists for single-field validation (e.g. regulatory_book_type), so extending it to a second, cross-field condition is straightforward, not a novel mechanism — but no existing book (or other entity) validation function currently checks one field's value against another's, so this is a genuinely new trigger shape to write and test.
• Qt UI — the field should only be enabled/visible when book_purpose_type is Wash in the detail dialog. No existing generated detail dialog conditionally enables one field based on another field's live value (setEnabled calls found elsewhere only gate toolbar actions/save buttons, not sibling form fields), so this needs either a codegen extension or a hand-written override — small in isolation, but the reason this doesn't already exist anywhere to copy from.

Both gaps are modest, not blocking, but real enough that this should land as its own scoped implementation task rather than a trivial field add. No code changes made as part of this sizing pass.

Because risk is deliberately split across two books via a system-generated back-to-back, it must always be possible to trace a deal back through the split/route/move to find the original client trade — the same traceability principle required for the funding process and sweep runs.