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.

This applies to an official book, one that maps to a book in the ledger. A virtual book inside a sandbox follows no such process; see Book types and the controls on each.

Creating a new official 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. Book moves covers it in full; in brief:

• A deal moves by amending its booking when the source and destination books share a legal entity, a branch, a regulatory book and an accounting classification. The deal keeps its identity, and the move cuts an internal version with book move as its reason.
• Any other change of book is not a move. The deal is closed out and rebooked in the destination book, and the two are joined by an explicit link.
• The ledger sees an allowed move as a pair of postings, a back-out in the source book and an opening in the destination, written in one transaction.
• Book moves are one of the highest-priority trade activity types in the reason-for-update taxonomy, and are supported as a bulk operation, "with or without historic cash flow moves". An erroneous move is reversed by an explicit Undo Book Move.
• Book moves are a known source of P&L breaks that are hard to explain when only the current book is kept on the deal; a booking that keeps its history removes them.
• Moving risk rather than a deal — intra-book hedging and Risk Routing — is not a book move.

• 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.