Book classification

The most consequential classification a book carries — market risk capital vs credit risk capital hinge on it. See FRTB trading book / banking book boundary for the full regulatory treatment: intent-based assignment, the presumptive lists, trading desk structure, capital treatment, and switching restrictions.

• There is roughly a 1:1 mapping between "source" books (the books used in the trading/booking system) and ledger books. A single ledger book can be fed by several source books, provided they are related and one is designated the primary book to which the others (secondary, tertiary, etc.) defer. The subservient books may supply valuation events or cash flows for trades booked in the primary book.
• Not every ledger book is fed from a source book: some are manual ledger books, updated by hand.
• Central books aggregate and feed a balance up to a higher entity, such as the Group General Ledger.

• Risk-bearing books are actively used to risk-manage a position.
• Wash books carry no risk: every client trade is immediately hedged back-to-back, so the risk sits in a separate "risk book" while the wash book holds the offsetting legs (typically two of the three legs of a back-to-back booking).
• Reserve books hold reserve deals, usually booked against special reserve counterparties, to isolate reserve amounts from the trading book proper.
• Write-off books are managed separately from the main portfolio, not continuously delta-hedged. A write-off book sits apart on the book tree but still participates in P&L and end-of-day (EOD) reporting like any other book.
• Funding books hold net cash balances during the funding process.

• Test books — used to book dummy/test trades in production, isolated from the main book population, ideally owned by test entities restricted to IT users.
• Sales books / desk-specific risk books — e.g. a forward desk's risk book, used when routing risk between spot and forward desks.
• Central Sweep Book — the book spot sweep centralises Sweepable books' cash balances into.
• Central Remittance Book — the book against which monthly/quarterly profit sell-down and remittance trades are booked (see Central remittance (profit remittance)). Not combinable with the Central Sweep Book role — see that note's "Sweep target and remittance target are not combinable" for why.
• Naming conventions exist for certain classes of book, e.g. Mortuary or Legacy books for retired/closed-down positions.

A book carries three independent fields for these dimensions, not one "type" enum:

book_purpose_type is a lookup entity rather than a set of independent booleans, following the same precedent as regulatory_book_type (originally a raw boolean, converted to a lookup entity when it turned out to be an extensible regulatory category rather than a bare flag): its values are mutually exclusive — a book plays exactly one risk role — and the set is expected to grow (the domain notes already anticipate Wash, Write-off, Test, Sales, Sweep target, and Remittance target beyond the original Reserve/ Funding pairing), so a lookup entity avoids a new boolean column, SQL migration, and generator wiring each time a new purpose is discovered. ledger_feed_type likewise replaces what would otherwise be two correlated booleans (Is Ledger Book + Is Manual Ledger Book) with one 3-state field, removing the invalid state where "manually fed" is true but "is a ledger book" is false.

is_sweepable remains a plain independent boolean: it is a genuine binary operational property, orthogonal to all three other axes. Nothing prevents any book_purpose_type value from being marked sweepable in the schema, though in practice a Reserve book (holding static provisions, not live tradeable cash) is not expected to be.

Top-level book examples: Options, Spots, Forwards, Prime Brokerage, Emerging Markets, Credit Exposure, Local Markets, Hybrids. It is also useful to segregate non-trading-system functions (Profit Remittance, Funding) into their own books, distinct from trading books proper.

The three dimensions above — regulatory type (trading/banking), ledger feed (not fed / automatically fed from a source book / manually fed), and risk role (reserve, funding, wash, write-off, and so on) — are modelled as independent axes, and that independence holds up under scrutiny, but not for the reason it might first appear.

Basel has no concept of a "reserve book" or a "funding book" at all. These are internal, bank-specific chart-of-books constructs; the FRTB trading/banking boundary looks through the book label entirely and classifies based on the trading intent of what is actually booked in it, assessed at the trading-desk level against the presumptive lists. There is therefore no regulatory rule of the form "a reserve book must be banking book" — nothing in BCBS d457 references risk role at all.

In practice, reserve books (isolating provisions against reserve counterparties) and pure funding/treasury cash books usually do end up classified as banking book — but this is a consequence of what they hold failing the trading-intent test on its own economic substance, not a rule about the risk-role label itself. A book carrying trading intent could in principle be both, say, a Funding-purpose book and a Trading-type book simultaneously, however unusual that combination would be in practice. Because the correlation is a business/compliance judgement made per book rather than a structural constraint, it should not be hard-coded as a validation rule (e.g. a check constraint forcing Reserve to imply Banking) — regulatory type and risk role are kept free to combine, and the correlation is expected to live in process, training, and UI defaults rather than in the schema.

The same independence argument applies to the ledger-feed axis: how a book's balance is populated is an operational/accounting concern, unrelated to both its regulatory capital treatment and its risk role.

This cross-axis independence is distinct from the mutual exclusivity within the risk-role axis itself. Regulatory type, ledger feed, and risk role are three separate fields that combine freely with each other (any Trading/Banking value with any risk role, any ledger-feed state with any risk role); but within the risk-role axis, a book has exactly one value — Reserve, Funding, Wash, and so on are alternatives, not flags that stack. The Sweep-target/Remittance-target pairing makes this concrete: despite both being singleton "central" books that other books' balances flow into, they are owned by different departments (Treasury vs Finance), run on different cadences, and carry different P&L treatment (Sweep realises trading P&L; Remittance is deliberately balance-sheet-only) — see Sweep for the full reasoning. Mixing the two roles on one book would blur exactly the audit/reconciliation separation these processes exist to provide, so they are modelled as two further mutually-exclusive book_purpose_type values rather than independent flags a book could carry at once.

Book-level limits (credit, notional, or settlement limits set at the book level) are not a distinct classification concept — the closest analogues are trade-level checks performed at quote or booking time (credit line utilisation, margin, daily settlement limits), which are generic to the deal rather than specific to the book.

Similarly, a book-scoped "netting set" is not a named concept; the related mechanisms are netting/allocation via internal deals (IDTs) moving risk from netted risk books to trader books, and compression (identifying offsetting positions across entities) — neither of which is framed as a book-scoped netting set.