Investigation: The book of a structure

The trading tables enforce the party of a structure's legs and nothing else about them. A trade's book lives on trade_bookings, which is a part of the trade, and a structure holds no book column at all.

Three pages in the tree already state the rule from the other side:

• Nested trade sets: "A trade is in one book, faces one counterparty, sits in one netting set, and belongs to at most one structure." The book is part of the trade's address; the structure is a set the trade belongs to. Nothing there says two legs of one structure share an address.
• Book moves: a trade moves between books when the two books share a legal entity, a branch, a regulatory book and an accounting classification. The boundaries that forbid a move are entity, branch, regulatory book and accounting classification. The structure is not one of them, so a single leg of a structure can move to another book without the structure being involved.
• Trade Structures and Deal Composition: the structure is the customer's commercial unit; the ledger and the netting engine "need the leaves, not the container".

Every structure in the provisioned population has its legs in one book, and nothing required it:

-- Structures, and how many books their legs span.
with books as (
  select s.id, count(distinct b.book_id) as books
  from ores_trading_structures_tbl s
  join ores_trading_structure_members_tbl m
    on m.structure_id = s.id and m.valid_to = ores_utility_infinity_timestamp_fn()
  join ores_trading_trade_bookings_tbl b
    on b.trade_id = m.trade_id and b.valid_to = ores_utility_infinity_timestamp_fn()
  where s.valid_to = ores_utility_infinity_timestamp_fn()
  group by s.id)
select books, count(*) from books group by books order by books;

The answer is one row: 22 structures, each spanning exactly one book. The population generator books a structure's legs together, so the data cannot tell a rule from a habit.

FpML, which is the standard this repository follows for the composition ladder, has no concept of a book. It carries a trade, its party identifiers, its product and its allocations. The book is an internal management and accounting dimension, so a market-wide rule about a structure's book cannot come from the standard at all.

Its two composition mechanisms answer the neighbouring question:

• strategy is a product: it substitutes for product and holds the legs as product+. The legs of a strategy are not separate trades with their own books; they are parts of one product inside one trade.
• tradePackage is "a bundle of trades collected together into a single unit for reporting", and it carries allocations: "the key block economics are stated once within the trade structure, and the allocation data is contained in this allocations structure". A package is therefore designed to be split across accounts after execution.

That is the strongest evidence against the rule as an invariant. The container FpML defines for a bundle of trades has an allocation as a first-class child, and an allocation is exactly the act of putting the same economics into several accounts or books.

In a front-office system a structure is normally booked into one book at execution, because the book is who owns the P&L and the trader's risk, and the package is one commercial act. That is a convention about how desks work, not a property the economics require, and the systems that support allocation are built to break it: a block trade is executed once and allocated to several accounts, and FpML puts that allocation inside the package itself.

What the industry does enforce, and what our model already enforces, is the legal entity. A trade sits on one entity's balance sheet, and a move across entities is a close-out and a rebook. The counterparty and the netting set are the next strongest, because credit exposure is measured per counterparty and per netting agreement, not per book.

A book is the accounting and management unit: Book moves shows that the only things that pin a trade to a book are the entity, the branch, the regulatory book classification and the accounting classification. A structure spans no such boundary by construction, because its legs share a party today.

If the blotter's tree must place each structure row under one book, it needs a rule. There are three, and only the third is honest:

1. Enforce one book per structure. It makes the tree simple and it is wrong: it forbids allocation, it forbids moving one leg, and it states a rule the economics do not have. It is also a booking rule, so it belongs in the store and not in a screen, which would make the same mistake as the party-only counterparty rule in reverse.
2. Put the structure in the book of its first leg. It hides the disagreement and puts a structure in a book that may hold none of its risk.
3. Place the structure at the lowest common ancestor of its legs' books. One book places it under that book, which is the common case and needs no special drawing. Books under one desk place it under that desk. Anything wider places it under the portfolio. The structure row states that it spans, so a reader knows the placement is a summary and not a fact about one book.

The flat option is unaffected: it draws leaves, and every leaf has one book.