Acme Corporation

Overview
What is Acme Corporation
The organisational model: parties, business units, portfolios, and books
The holding-group structure
The holding company's own treasury footprint
Departments and segregation of duties
Staff and accounts
Provisioning Acme Corporation
Conclusion
See also

Every screenshot in this manual, and every worked example in every other chapter, needs somewhere to point. This chapter introduces the entity that gives them one: Acme Corporation, a synthetic four-legal-entity holding group standing in for a real global investment bank, provisioned with a single command and ready to explore the moment it lands. It sets out what Acme Corporation is, the organisational model its holding-group structure is built from, the structure itself, the departments that populate it and why they are kept separate, and how to provision it yourself.

Overview

The chapter advances the argument that understanding Acme Corporation means first knowing what it is, then the organisational model its structure is built from, then the structure itself, then the departments within it, and finally how to stand it up — and it proceeds in that order. It begins by establishing the premise in What is Acme Corporation. From there The organisational model: parties, business units, portfolios, and books sets out the two hierarchies — organisational and portfolio — that every party's structure is built from, the premise the rest of the chapter assumes. Building on that model, The holding-group structure walks Acme's four legal entities and the trading floor each one carries, The holding company's own treasury footprint sets out what the group centre itself carries and how that differs from an operating company's trading floor, Departments and segregation of duties explains why a trading floor is never a single undifferentiated team, and Staff and accounts introduces the people who staff those desks and the org-chart view that renders their reporting lines. Finally Provisioning Acme Corporation shows how to stand the whole entity up yourself, from the Qt wizard or the shell, before the Conclusion draws these steps together.

What is Acme Corporation

Acme Corporation is ORE Studio's reference entity: a synthetic four-legal-entity investment-bank holding group, fully populated with business units, portfolios, books, and staff, provisioned in one command and ready to explore the moment it lands. Every screenshot in this manual and every worked example in every other chapter needs a populated system to point at, and Acme Corporation is that system — a fully populated organisational structure to walk through rather than a single flat party.

"Acme" is the archetypal fictional-company name — from the Acme Corporation, the mail-order supplier of absurdly over-engineered products in Looney Tunes' Road Runner cartoons, now a byword for any generic placeholder business. Reusing it here signals plainly, to anyone browsing the data, that Acme Corporation is a synthetic reference/demo entity, not a real institution — the same signal slovaris, ORE Studio's other synthetic dataset, sends for its own domain. But the resemblance stops there. Slovaris is a fully self-contained fictional universe, deliberately isolated from the system's real reference data. Acme Corporation takes the opposite approach: it is designed to integrate. Its four legal entities carry LEIs that are fake but well-formed — real, checksum-valid (ISO 17442 / mod-97) 20-character codes built on GLEIF's reserved 9695 pre-LOU test prefix, which GLEIF explicitly sets aside for non-production use and will never assign to a real entity — stored in exactly the same refdata_party_identifiers_tbl rows a real GLEIF-imported LEI occupies, so nothing in the schema or the UI needs to special-case a "fake" identifier. Acme's counterparties, in turn, are not synthetic at all: they are the real, GLEIF-imported counterparty universe — Deutsche Bank, Barclays, and every other institution the GLEIF registry supplies — so Acme's own trades can reference real-world institutions exactly as a production tenant's would.

With the premise established — a synthetic house trading real counterparties — the rest of the chapter turns to the model that gives Acme's own structure its shape.

The organisational model: parties, business units, portfolios, and books

ORE Studio organises trading activity around two hierarchies that share a common root but serve different audiences. The first is organisational: a party — a legal entity or organisational subdivision — owns a tree of business units, typed and geographically anchored, that mirrors the bank's actual reporting lines. A division sits above business areas, which sit above trading desks and cost centres, each carrying a business-centre code (GBLO for London, USNY for New York, and so on) that ties it to a physical trading location. This hierarchy is what risk and middle office read: which desk, in which jurisdiction, is accountable for a given position.

The second hierarchy is portfolio: books, the atomic unit to which every trade is booked, sit beneath physical portfolios that aggregate their risk and P&L, which in turn can sit beneath virtual portfolios — reporting overlays with no organisational meaning of their own, used to build cross-desk or cross-region views such as "Global Rates" spanning both London and New York. This is the hierarchy traders and front office read: not who is accountable, but how risk rolls up for management reporting. The two hierarchies are independent but linked at the book level — every book carries both an owning business unit and a parent portfolio — which is precisely how a bank practises "follow the sun" trading without a single book ever appearing to move between cities: London's book and New York's book are two separate books, each owned by its own desk, reconciled at end of day through an interbook trade, and reunited only in a virtual portfolio's consolidated view.

Both hierarchies are scoped to a party within a tenant, following the same tenant isolation and party-visibility rules set out in the Tenants chapter. Acme Corporation's four legal entities are four such parties, each the root of its own pair of hierarchies — which is exactly the shape the next section walks in concrete terms.

The holding-group structure

Acme Corporation comprises four legal entities: Acme Corporation Plc, the group holding company, and three regional operating companies — ACME Corporation UK plc, ACME Corporation US Inc, and ACME Corporation HK Ltd — each booking business in its own jurisdiction (London, New York, and Hong Kong respectively). Every entity carries its own checksum-valid, 9695-prefixed LEI, and the three operating companies are children of the holding company in the party hierarchy: a real corporate shape built from fake-but-valid identifiers.

Acme Corporation Plc              (party, root — group holding company)
  ├─ ACME Corporation UK plc      (party — booking entity, GBLO)
  ├─ ACME Corporation US Inc      (party — booking entity, USNY)
  └─ ACME Corporation HK Ltd      (party — booking entity, HKHK)

Each operating company carries its own trading floor, modelled on a global investment bank's Markets division: a Global Markets division split into Rates, Credit, and FX trading desks, alongside a Risk Management division and Middle Office and Market Risk cost centres — the follow-the-sun pattern the previous section introduced, expressed concretely. ACME Corporation UK plc's Global Markets division goes further, with EMEA, Americas, and APAC business areas beneath it — the London entity is where Acme's global trading footprint is broadest, reflecting a UK head office coordinating trading across time zones rather than each region booking in total isolation. Today only the EMEA business area is actually staffed; the Americas and APAC business areas exist as structural placeholders for that footprint to grow into, with desks defined but no accounts or books under them yet.

Every desk owns one book, sitting beneath a physical portfolio scoped to that desk; every operating company's business units, portfolios, and books carry the company_code that ties them back to their owning legal entity, since each of the four entities needs its own independent organisational structure. Open the Parties window on a freshly provisioned Acme Corporation tenant and the hierarchy above is what you see, four levels deep and fully populated.

Figure 1: The Parties window on a freshly provisioned Acme Corporation tenant: all four legal entities (Acme Corporation Plc and its three operating companies), each flagged by its business centre, alongside the tenant's own system party.

With the corporate shell and its trading floors in place, the chapter turns first to the holding company's own footprint at the group centre, before turning to why a trading floor is divided the way it is.

The holding company's own treasury footprint

Acme Corporation Plc is not a pure legal shell sitting above the three operating companies with nothing of its own underneath it — unlike a holding company with zero market-data footprint, it carries genuine parent-level treasury activity: FX visibility into the rates its subsidiaries trade in, for remittance and hedging decisions, and a Group Treasury book/portfolio for the intercompany loans and FX hedges the parent itself carries. This is what distinguishes a real holding company from a passive legal wrapper, and it is deliberately modelled differently from an operating company's trading floor rather than as a fourth, smaller copy of one.

This section is currently text-only: the Cross-Rates Matrix and Org Explorer screenshots that illustrate it elsewhere in this manual are pending and will be added in a follow-up pass.

FX visibility works without the holding company needing a feed of its own: the Cross-Rates Matrix, opened at Acme Corporation Plc, shows live cross rates across GBP, USD, and HKD — the three operating companies' own currencies — fed entirely by the offices' FX feeds. A EUR/USD print is the same real-world rate regardless of which office's feed_binding happens to be subscribed to it, so FX driver ticks are tenant-wide for CRM-matching purposes rather than scoped to whichever party's feed produced them; each party's own topology configuration still governs what it is authorised to see, so this shares nothing beyond what a real FX rate already is.

Where each operating company's own business unit is a full trading floor — Global Markets, Risk Management, desks and cost centres, as the previous section walked — Acme Corporation Plc's own business unit is a single DIVISION-type unit, "Group Treasury" (acme_group.treasury), holding one virtual GBP portfolio ("Group Treasury Portfolio") and two books, both classified Banking rather than Trading: "Group Intercompany Loans" (GL-TREAS-001) and "Group FX Hedges" (GL-TREAS-002), both carrying cost centre CC-GROUP-TREASURY and rates centre GBLO. Neither book is a held-for-trading desk. "Group Intercompany Loans" carries the loans and deposits between the holding company and its subsidiaries; "Group FX Hedges" carries the forwards and swaps that hedge the group's remittance and translation exposure back to GBP, the group's own reporting currency — the Banking classification is the correct prudential treatment for financing and for hedges of non-trading exposure, not the Trading classification an operating company's desks carry.

Consolidated group-level risk reporting — rolling the three operating companies' books up into a single group-level NPV/VaR/XVA view at the holding company — is the natural next question a real group treasury function would ask, and the underlying data-visibility a report like that would need already exists (a session scoped to the holding party already sees every subsidiary's books and trades, the same mechanism that grants staff cross-entity access during provisioning); building and exposing that view is not yet in place.

With the holding company's own footprint established alongside its three operating companies, the chapter turns from structure to why a trading floor is divided the way it is.

Departments and segregation of duties

A trading floor is never a single undifferentiated team, and Acme Corporation's structure exists to make that concrete rather than abstract. Each operating company separates three functions that never report through one another: the desks that take positions, Middle Office, which processes and reconciles what the desks book, and Market Risk, which independently measures and monitors the resulting exposure. This three-way split — front office takes risk, middle office processes it, risk management measures it — is the standard shape of a bank's control environment: no single function both takes a position and marks or monitors it, so no single individual's error or misconduct can go unchecked by construction of the org chart alone. The rest of this section walks each department in turn — what it does, who staffs it, and which of ORE Studio's seeded roles its accounts hold — before the following section on leadership and the caveat about what this buys you today.

Front office: the trading desks

Each operating company's staffed trading floor runs three desks — Rates, Credit, and FX — the instrument classes a follow-the-sun trading floor is built around (ACME Corporation UK plc's Americas and APAC business areas define four further desks structurally, but carry no staff yet, per the note above). A Head of Desk leads each staffed desk (nine across the three operating companies), with a Senior Trader and a Junior Trader beneath them (nine of each), and a single Head of Trading per operating company (three total) above all three desk heads, reporting in turn to the Country Head. The desk is where risk is actually taken: traders price and execute, the Head of Desk carries overall accountability for the desk's book, and every position they book carries the desk's owner_unit_id, tying it to this business unit for both day-to-day P&L attribution and regulatory desk-level reporting. Every front office account — Head of Trading, Head of Desk, Senior Trader, and Junior Trader alike — holds the Trading role, which grants read access to reference data and the ability to create, modify, archive, and delete the workspaces a trader actually works in (see Accounts and Roles for the full permission profile).

Middle office: processing what the desk books

Middle Office sits alongside the trading desks as its own COST_CENTRE-typed business unit, not folded into the same branch of the tree as the desks it processes for. A Head of Middle Office leads each operating company's function (three total), reporting to the COO rather than to the trading side at all, and supported by Senior Analyst and Junior Analyst accounts drawn from the same shared pool the Market Risk function below also staffs. Middle Office's job is operational, not directional: confirming trades, reconciling positions, and keeping the books the desks feed clean and current — the unglamorous processing work that has to happen correctly for every downstream report to mean anything. The Head of Middle Office holds the Operations role — read, write, and delete on reference data, plus the ability to view accounts — reflecting a function that maintains shared data rather than takes risk or grants capability to others; the analysts beneath them hold the read-only Viewer role.

Market risk: independent measurement

Market Risk is Middle Office's structural sibling, not its subordinate — its own COST_CENTRE, reporting through a separate Head of Risk rather than through the COO, precisely so that a desk's risk cannot be measured by anyone in the same reporting line that processes that desk's trades. A Head of Market Risk leads each operating company's function (three total), reporting to the Head of Risk, again supported by Senior and Junior Analysts. Where Middle Office confirms that a trade happened, Market Risk measures what it means: monitoring exposure against limits, running the sensitivity and P&L-attribution queries the desk-level owner_unit_id tagging described above exists to support, and flagging breaches independently of the desk being measured. Role assignment mirrors Middle Office exactly — Operations for both the Head of Risk and the Head of Market Risk, Viewer for the analysts beneath them — because both functions are maintaining and reading shared data rather than taking positions; what keeps them independent of each other and of the desks is the organisational hierarchy's separate branches, not a difference in which role they hold.

Leadership: country heads and the group centre

Each operating company's three departments do not report to their Country Head directly — each sits under its own intermediate head, and it is those three who report to the Country Head: the Head of Trading for the desks, the COO for Middle Office, and the Head of Risk for Market Risk (three of each, nine accounts total). The Country Head (three total) carries overall accountability for the legal entity these nine roll up into. Above the three operating companies sits a single Group Chief Executive Officer at the holding-company level, the one account with no company_code of its own and every Country Head reporting to them — the root of the fifty-eight-account tree the next section renders as an org chart. Leadership accounts — Group CEO, Country Head, COO, and Head of Risk alike — hold the Operations role, the same broad-but-not- administrative profile Middle Office and Market Risk staff hold: read, write, and delete on reference data, and visibility into accounts, without the tenant-wide TenantAdmin or SuperAdmin capability that provisioning itself required.

What this does and does not enforce

It is worth being precise about what the structure above buys you today and what it does not. The organisational hierarchy and the job titles just walked through are real, queryable structure — a Head of Market Risk's account genuinely sits in a different business unit from the Head of Desk they monitor, and that separation is visible in the data and in the org chart. What it is not, yet, is a per-desk access-control boundary: the Trading, Operations, and Viewer roles above are seeded at the tenant level, not scoped to an individual desk or business unit, so two Heads of Desk on different desks hold the identical Trading role and the identical capabilities — a login does not currently gain or lose capability by virtue of which specific business unit its account happens to sit under, only by which role it holds. The organisational separation Acme's structure demonstrates is the model a future desk-scoped RBAC extension would enforce; today it documents who is accountable for what and groups accounts into the right tenant-wide role for their function, without yet gating action by desk membership.

With the departmental shape established, the chapter turns to the people who actually staff it.

Staff and accounts

The fifty-eight accounts the previous section walked by department share a common identity pattern regardless of which one they belong to. Every account's name is generated from the office's own locale — British names for London, American names for New York, Cantonese-appropriate names for Hong Kong — rather than a single Western default stamped across all three, and every account carries a profile picture drawn from a tagged face dataset, loosely matched to the generated name's apparent gender and the office's predominant ethnicity mix. Every generated account shares one fixed demo password, so any of the fifty-eight is immediately usable for exploring party-scoped access without a separate credential to look up per account.

Reporting lines run true to the departmental structure: a trader reports to their Head of Desk, who reports to their Head of Trading; an analyst reports to their Head of Middle Office (under the COO) or Head of Market Risk (under the Head of Risk); every one of those intermediate heads reports to their Country Head, and each Country Head to the Group Chief Executive Officer — so the whole fifty-eight-account structure is one connected tree rather than three disconnected regional trees. Rather than tracing that tree by hand through each account's detail dialog, open it at a glance from User Accounts > Org Chart: a maximisable window that lays every account out top-down as a card — photo, name, job title, office — connected to its manager, with a distinct colour per operating company and the currently logged-in account's own card highlighted.

Figure 2: The Org Chart window scrolled to the Group CEO and the full ACME Corporation US Inc branch beneath its Country Head, each card showing photo, name, job title, and office, connected down to the trading floor's traders and analysts.

A multi-party account — tenant_admin, for instance, which carries cross-entity access to all four legal entities — is not locked to whichever party it logged in against. The party picker in the top-level toolbar switches the in-session party context without logging out, so moving from ACME Corporation UK plc's books to ACME Corporation US Inc's is a menu selection, not a re-login.

With the people in place, the chapter closes with how to bring this entity into being on your own installation.

Provisioning Acme Corporation

Acme Corporation is the fastest way to get a fully populated ORE Studio installation: one command, no manual party-by-party setup. It is provisioned the same way any tenant is — through the platform administrator's tenant-creation wizard, or the equivalent shell command — with one difference: rather than the Manual path, where you build up parties, business units, and staff one wizard screen at a time, selecting Acme Corporation (full sample bank) hands the entire holding-group build to the server. One command imports the four-entity LEI hierarchy, publishes every entity's business units, portfolios, books, and accounts dataset, and activates the tenant — no repeated per-party logins, no client-side orchestration to babysit. The choice sits on the tenant-creation wizard's Welcome page, reached via System > Administration > Tenants > Onboard: a simple radio choice between Acme Corporation (full sample bank) and Manual setup — see the Initial Setup chapter for the full wizard walkthrough, including the Manual path for setting up your own organisation instead.

The same choice is available from the shell, for scripted or repeatable provisioning: bootstrap the platform, then provision the tenant with --source acme.

provision system super_admin Secure-Password-123 super_admin@localhost.com --tenant-admin-password Secure-Password-123 --tenant-code acme_corporation --tenant-name "Acme Corporation" --tenant-hostname acme_corporation
logout

login tenant_admin@acme_corporation Secure-Password-123
provision tenant --source acme
logout

This follows exactly the shell provisioning sequence the Provisioning from the Shell chapter sets out — system, then tenant, with the logout between stages that refreshes the session's view of the newly active tenant — and the full worked example, runnable end to end against a fresh installation, is documented as its own recipe: How do I provision the system with Acme Corporation (holding group)?. Either path — wizard or shell — ends with the structure this chapter has walked: four legal entities, their trading floors, and fifty-eight staff accounts, ready to log in and explore.

Conclusion

The chapter set out to show that understanding Acme Corporation means knowing what it is, the organisational model its structure is built from, the structure itself, the departments within it, and how to stand it up, and it has traced exactly that path. Acme Corporation is a synthetic house, identified by fake-but-valid LEIs, integrated into the system's real GLEIF counterparty universe rather than isolated from it. That house's four legal entities are built from the same organisational and portfolio hierarchies every party in ORE Studio uses — business units typed and anchored to a business centre, books aggregating beneath physical and virtual portfolios — and those hierarchies exist to enforce a real control principle: trading, processing, and risk measurement kept organisationally separate, even though that separation is not yet an access-control boundary. The holding company at the group's centre is not a passive shell either: its own Group Treasury business unit, FX visibility across every subsidiary's currency, and Banking-classified books for intercompany funding and remittance hedging show a real parent company's own treasury activity, modelled distinctly from an operating company's trading floor rather than as a smaller copy of one. Populated concretely with fifty-eight staff across Rates, Credit, and FX desks, Middle Office, and Market Risk, whose reporting lines the org-chart view renders at a glance, provisioning — from either the Qt wizard's one-click choice or the equivalent shell command — showed that the whole entity, structure and staff and all, is one command away on any installation. Every other chapter's screenshots and worked examples now have somewhere to point.