Book lifecycle

The process below is a state model derived from the workflow described in this note; the underlying system does not name these states explicitly, but the note's own requirement — "the system must track exactly where in this process a given book sits" — implies something equivalent to it.

Source: book_lifecycle.puml. Regenerate with plantuml -tpng doc/knowledge/domain/book_lifecycle.puml.

Creating a new book is a deliberately heavyweight, multi-party process:

1. Book initiation — the request is authorised internally by the desk.
2. Controller review — a controller reviews and approves the initiation request.
3. Enrichment — the book is enriched with required data by three separate functions: Finance, Market Risk, and Operations.
4. Approval — each enriching party must approve their own changes before the book can proceed.
5. Access review — the book access process begins; once complete, the book is set up on the booking systems for use.
6. This includes the corresponding Finance ledger setup (see Book and the ledger).

Throughout, the system must track exactly where in this process a given book sits, and who still needs to authorise or enrich it — an explicit workflow-state model, not just a binary open/closed flag.

Opening a book is not a single-owner request — it is a controlled hand-off across four distinct functions, each with its own concern and its own sign-off, matching the front-office / middle-office / back-office separation of duties standard in a trading operation:

• Desk (Front Office) — initiates the request. The desk knows it needs a new book (e.g. a new product line or a new trading strategy) but cannot itself create or enrich one; a book remains an accounting construct even though the desk is the one that will trade out of it (see Books and portfolios).
• Controller — the first independent check on the request, before any of the three enriching functions get involved. A controller's review-and-approve step exists specifically to prevent a desk from self-authorising its own new book.
• Finance — one of the three enriching functions. Finance's enrichment is what wires the new book into the accounting hierarchy and sets up its ledger book counterpart — functional currency, cost-centre placement, and the monthly/yearly balance carry-forward machinery (see Book and the ledger). This is also the function that later executes book closure "through accounting" and books the Profit Sell Down / Central Remittance entries against live books.
• Market Risk — the second enriching function. Market Risk's enrichment establishes how the book will be risk-managed once live: its trading-book/banking-book classification and the regulatory capital treatment that follows from it (see FRTB trading book / banking book boundary), and its assignment to a rates centre for consistent revaluation market data (see Book groups and rates centres).
• Operations (Middle Office / Back Office) — the third enriching function, and the one that actually sets the book up on the booking systems once every approval is in. Operations owns the book's allowed-currency and allowed-product constraints (see Book access and permissions) and administers the recurring access review once the book is live.

Because Finance, Market Risk, and Operations enrich the book in parallel rather than in sequence, each of the three must independently approve its own contribution before the book can move to access review — no single function's sign-off implies the others are done.

Once live, book access itself is not permanent: it must be periodically reviewed (monthly, quarterly, etc.). If nobody renews a user's access to a book, it is automatically invalidated and must be re-requested — see Book access and permissions.

Moving a deal's book assignment (a "book move") is a routine but tightly governed operation:

• Deals can only change books freely if the move keeps them within the same logical grouping — same legal entity, same branch, etc. — so that there is no legal impact. The system should support this automatically.
• If the target book has different ownership (e.g. a different branch), a direct move is not allowed; instead the deal must go through a novation-like activity: close out the original deal and rebook it in the new book, generating an explicit linkage between the two.
• Operationally, a book move should result in a single transaction pairing a deal that backs out the original trade with the new trade in the destination book.
• Book moves are one of the highest-priority trade activity types in the reason-for-update taxonomy (ranked above funding rolls, reserve postings, CEM charges, contra revenue, and close-outs), and are supported as a bulk operation ("book move of trades with or without historic cash flow moves").
• Book moves are a known source of P&L breaks that are hard to explain: a deal's book history is not fully retained (only the current book ID is reported), so a downstream P&L explain has to locate the deal's previous day's record to discover what its prior book was.
• Erroneous moves can be reversed via an explicit Undo Book Move action.
• A related but distinct mechanism is intra-book hedging, used when a trader wants to move risk (not a specific deal) from one book to another: a deal is booked in the source book for the amount to be moved, and an offsetting deal with inverse direction is booked in the destination book, both against an internal counterparty to denote the intra-desk hedge. The broader term for moving risk (rather than deals) across books is Risk Routing, governed by routing rules that determine how trades are split and aggregated to reach the right desk (e.g. spot vs forward desk).

• A book is considered flat on a given business date if every balance held against it is zero.
• A book can only be closed if it is flat.
• Closure is executed via a clean-down process: all live deals are moved to a different book, and the closed book is "deleted" — but it remains in the system rather than being physically removed, mirroring the Root Book / Recycle Bin model described in Books and portfolios. Closure must be actioned through accounting.
• A related year-end process, Year End Clear Down, flattens a book's currency balances by booking an FX deal that converts the year's life-to-date P&L into a base currency (e.g. GBP) plus an equal-and-opposite cash deal, zeroing the book out for the new year.