Business Unit

Summary
Detail
See also

Summary

A business unit is FpML's BusinessUnit type: an identified unit within a legal entity's organisation, named and optionally country-located, used to attribute a role – trader, confirmation, settlement – to a specific desk or department rather than to the legal entity as a whole. FpML defines the type flat, with no parent/child structure of its own; the organisational hierarchy a real firm needs – region, branch, desk, sub-desk, each nested inside the last – is a self-referencing structure built on top of it: every level of a typical investment bank's structure (e.g. EMEA → London → FX Options Desk → G10 Vol) is modelled as one business unit pointing to its parent business unit, at whatever depth that level of the org chart requires. A business unit is the node to which the org-chart properties that matter operationally attach: an optional business centre (a location/calendar reference every unit may carry, whether inherited from a parent or assigned directly, and independent of whether that unit runs its own end-of-day process), and, orthogonal to that, an aggregation currency. A cost centre is a third, unrelated property tracked directly on a book rather than on the unit. A book sits below the tree, owned by exactly one business unit – the org chart's implicit, but load-bearing, link between the two.

Detail

FpML's BusinessUnit type

FpML defines BusinessUnit as "a type that represents information about a unit within an organization", carrying a name, a businessUnitId ("an identifier used to uniquely identify organization unit"), optional contactInfo, and an optional country (the ISO 3166 code "where the individual works"). Its purpose in an FpML document is to be referenced by a BusinessUnitRole, which attributes one of a scheme of roles to that unit for a given trade or message – FpML's own scheme lists "Trader, Collateral, Confirmation, Settlement, etc." as examples, extensible to custom roles. FpML's BusinessUnit is deliberately identity-only: it names a unit and locates it by country, but defines no parent/child relationship to any other unit – the type says nothing about organisational hierarchy.

The organisational hierarchy: a self-referencing tree of units

The hierarchy itself – a legal entity subdivided into regions, branches, desks, and sub-desks – is a self-referencing structure of business units: each unit optionally has a parent unit, and a unit with no parent sits directly under the legal entity. A typical investment bank's structure composes entirely from this single node type, nested as deep as the real org chart requires – for example EMEA (a region-level unit with no parent) containing London (a branch-level unit whose parent is EMEA) containing FX Options Desk (a desk-level unit whose parent is London) containing G10 Vol (a sub-desk one level deeper still). Nothing distinguishes a "region" unit from a "desk" unit except its depth and its name; the same generic type is reused at every level. The Cost Centre accounting axis a book also belongs to (Legal Entity → Entity → Business Unit → Cost Centre → Ledger Book) is a distinct, parallel hierarchy – it groups books for accounting and management reasons, this one groups them by organisational and operational placement – and the two must not be conflated even though both ultimately root at the same legal entity.

Business centre: a location/calendar reference a unit can carry

A business unit may carry a business centre – an FpML-coded identifier naming the holiday calendar and, more operationally, the rates centre whose end-of-day market-data snapshot a book revalues against (see Book groups and rates centres for the rates centre concept in full). This assignment is not mandatory at every node: by default, a unit and its books inherit the nearest ancestor's business centre up the tree, exactly as any other org-chart property would be inherited absent an override. Carrying a business centre is distinct from running an EOD process against it, however: a unit may be assigned its own business centre purely for inheritance or reporting purposes without itself triggering any end-of-day run. Whether a given unit actually runs its own EOD is a separate, independent question – we may run EODs for business units if they are so configured, but that configuration is orthogonal to which business centre a unit or its books are associated with. Concretely, a book's own rates centre code is where the business-centre assignment resolves to a single, unambiguous value for revaluation purposes – the org chart supplies the default, a book may override it directly.

Cost centre: a distinct, unrelated property

A cost centre is tracked on the book, not the business unit, and has no relationship to a unit's business centre: two books under the same business unit may carry different cost centres, and books under different business units may share one. Where a business centre governs which market data a book revalues against, a cost centre governs how its P&L is grouped for accounting – the two properties answer unrelated questions and happen only to share a book as their common attachment point.

Aggregation currency

A business-unit-tree node also carries an aggregation currency, the reporting counterpart to a business centre's EOD role – see Aggregation Currency for its definition, Risk Reporting§"Aggregation Level" for the rollup hierarchy it converts figures through, and CRM risk and recentering for how it governs risk star-shaping.

Relationship to book

A book belongs to exactly one business unit – the org chart's own link between the two, carried as a plain reference on the book rather than as any richer relationship. This single reference is what makes the tree operationally meaningful: a book's default business centre, its place in regional/desk reporting rollups, and its aggregation are all reached by walking up from the book through its owning business unit.