Books

The chapter advances the argument that managing a book well means first understanding what it represents, then the interface that governs its lifecycle — and it proceeds in that order. It begins by establishing what a book is in What is a Book?, distinguishing a book from the counterparties and portfolios it sits alongside, and by working through the real-world Book lifecycle a book moves through — from its multi-party opening to closure — that the Status field on-screen only partially reflects; this is the premise the rest of the chapter builds on. From there it surveys the body of records in The Books window before narrowing to a single record in Book Details and its General and Provenance tabs. It then turns to changing a record under audit — Editing, Deleting, and Book history — culminating in reverting to an earlier version, the point at which the bitemporal audit trail does its work. The Conclusion draws these steps together.

A book is the internal ledger unit that owns positions within a party's trading organisation. Every trade books into exactly one book; a book aggregates the trades it owns for risk, P&L, and reporting purposes. A book is, first and foremost, an accounting concept rather than a purely trading-system one: it must reconcile with the firm's general ledger, and OreStudio's own view of a book is downstream of that ledger rather than the other way round.

Books sit within a party's organisational structure alongside business units and portfolios, and it helps to keep the two apart: a portfolio groups related books for a trading strategy or desk, and can itself be composed of other portfolios; a book is the leaf-level unit that actually carries positions. A useful shorthand is that books are the physical representation and portfolios the logical one — or, borrowing a filesystem analogy, a portfolio is a folder and a book is a file. In the real-world accounting sense a book can have child books through ledger setup, but ORE Studio deliberately does not model that book-to-book hierarchy: a book has no parent-book field. Instead, all hierarchy in ORE Studio is expressed through the portfolio tree — portfolios can nest inside other portfolios, and every book links to exactly one portfolio — so the folder/file split above is also the whole of the tool's hierarchy, not just an analogy for it.

Every book carries a functional currency — the accounting currency its positions are reported in. Trades themselves can happen in whatever currency the deal was struck in, but the ledger needs one settled currency per book to carry balances and P&L in; that currency is designated by the ledger, not chosen freely by the desk. A book also carries a GL account reference, which is simply the general ledger account in the firm's accounting system that this book's activity maps to — the trading system's record of a position only means something once it can be traced back to a specific line in the firm's books of account. Alongside that sits a cost centre, the internal code that activity in this book is charged against for cost allocation and management reporting; a full treatment of how functional currency, GL accounts, and cost centres compose into the wider accounting hierarchy belongs to a future ledger-focused chapter, not this one.

A book also carries a status — its current operational state, such as active, closed, or frozen — chosen from the set of statuses configured for the tenant. See Book lifecycle below for what drives a book between these states.

Perhaps the most consequential classification a book carries is whether it is a trading book or a banking book — a distinction that traces back to the Basel III/IV capital adequacy framework, and specifically to a component of it called FRTB (the Fundamental Review of the Trading Book).

The distinction is about intent, not instrument type: a position held with the intent of benefiting from short-term price movements, market making, or hedging other trading-book positions belongs in the trading book; a position held to maturity or for longer-term investment purposes belongs in the banking book. The same instrument — a bond, a swap — can sit in either book depending on why it is held.

The distinction matters because the two books are subject to entirely different capital regimes. Trading-book positions are capitalised for market risk — the risk that market prices move against an open position — recognising that these positions may be actively traded and revalued daily. Banking-book positions are instead capitalised for credit risk — the risk that a counterparty fails to pay — reflecting that these positions are typically held to term. Getting this classification wrong, or moving positions between the two books opportunistically to reduce capital charges, is precisely what regulators police most closely; switching a position's classification after the fact is heavily restricted for that reason.

A book moves through a much heavier real-world process than a simple open/closed flag suggests: a deliberate opening workflow, a live phase in which deals move and access is periodically reviewed, and a closing process gated on the book being flat. This section walks through that process in its own terms; c.f. the Status field on the General tab below, which is OreStudio's simplified, editable reflection of it.

Open the Books window from the Trading menu. It lists all books defined in the tenant, with one row per book.

The toolbar buttons reload the list and open the add, edit, delete, and history actions. The list is paginated; use the page controls at the bottom right to navigate. Double-clicking a row opens the Book Details dialog.

The Book Details dialog has two tabs — General and Provenance. The three action buttons at the bottom — Delete, Close, and Save — apply to the book as a whole.

To edit a book, open it in the Book Details dialog, make your changes, and click Save. Before the record is written, OreStudio prompts for a change reason — the same Change Reason Required dialog shown in the Currencies chapter, and not repeated here. Select a Reason from the drop-down and add optional Commentary, then confirm. Every save creates a new version; the previous version is never overwritten.

To delete a book, open it and click Delete. OreStudio asks for confirmation before the record is closed off. Deletion is a soft close — the record's history is preserved and remains visible in the History dialog.

To view the full change history, open the details dialog and click the history icon in the title bar, or right-click the row and choose History.

Pick the two versions to compare from the Compare drop-downs. The All Fields / Only Changes toggle switches between showing every field and showing only the fields that differ between the two selected versions. The Revert button reinstates any historical version as a new version, preserving the full audit chain — the old version is never rewritten.

The chapter set out to show that managing a book well follows from understanding what it represents and the interface that governs its lifecycle, and it has traced exactly that path. A book is the leaf-level ledger unit that owns positions, identified within its party by an id and name and carrying a functional currency, a GL mapping, a cost centre, a status, and a trading/non-trading flag. Building on that, the Qt interface took the record from the list view down to a single detail dialog — its currency picker showing flags, its status governed by the book lifecycle — and through the editing, deleting, and history workflows, where reverting to an earlier version demonstrated the same bitemporal audit trail described in the Reference Data chapter. Shell and command-line access to books is not yet implemented; it is tracked separately as part of the shell and CLI commissioning work.

• Reference Data — the shared data quality and audit framework this chapter builds on.
• Currencies — the functional currency a book references, and the Change Reason Required dialog.