Initial Setup

The welcome page confirms the system is in provisioning mode and outlines the steps: create the administrator account, choose the setup mode, and create the first tenant. Click Next.

Enter a username, email, and password (with confirmation) for the platform administrator. Keep these credentials safe — this account has unrestricted access to the entire deployment. Click Create & Continue.

Choose how the deployment is organised:

• Single-Tenant — best for evaluation, development, or a single organisation. Creates a default tenant with sensible defaults; you can add more tenants later.
• Multi-Tenant — for production deployments serving several organisations. You configure the first tenant's details on the next page and onboard additional tenants from the Tenants window.

Click Next.

Configure the first tenant:

• Name — the organisation's display name (e.g. "Barclays Plc").
• Code — a short machine code used internally (e.g. barclays_plc).
• Type — the tenant type (see Tenant types): System, Production, Evaluation, or Automation.
• Hostname — the host identifier for the tenant.

Click Next.

Create the initial administrator for the new tenant — a username, email, and password. This account is given the TenantAdmin role: full control within the tenant, but no cross-tenant access. Click Provision Tenant.

ORE Studio provisions the tenant and creates its administrator account, logging each step. When it finishes, click Continue.

The final page summarises what was created and tells you the next step: log in as the tenant administrator to run the Tenant Provisioner. To create further tenants later, use System → Identity → Tenants and click Onboard. Click Finish — the backend leaves provisioning mode and the login dialog appears.

Before anything else, the welcome page offers a choice between two entirely different paths:

• Acme Corporation (full sample bank) — the fastest way to a fully populated, realistic installation. Selecting it skips every other step in this wizard (catalogue selection, data source, party setup) and hands the whole build to the server: a four-legal-entity holding group with business units, portfolios, books, and fifty-eight staff accounts, imported and published in one step. This is the recommended path if your goal is exploring ORE Studio rather than modelling your own organisation — see the Acme Corporation chapter for what you get and why.
• Manual setup — build the tenant up yourself: choose a reference-data catalogue, choose how to seed your own party hierarchy (from the real GLEIF registry or generated synthetic data), and optionally run the Party Setup wizard per party. Choose this path when you want to model your own organisation rather than explore a pre-built one. The rest of this section walks that path step by step.

Selecting Manual setup and clicking Next moves on to catalogue selection, described next.

A catalogue is a ready-made bundle of reference data. The Base System catalogue provides industry-standard ISO and FpML data — country codes, currency codes, and financial-market standards — suitable for production use. Choose a catalogue and click Next.

This step seeds the internal party hierarchy: the legal entities and business units that represent your own organisation — what practitioners call the house. As described in Parties, these are the operational parties that own trades, books, and analytics results.

The data source choice does not affect counterparties (the external entities your organisation trades with — those are imported separately in the Party Setup wizard). It only determines how the house structure is created.

In a group context — for example a bank holding company with separate London and New York subsidiaries — the house hierarchy reflects the corporate structure. The root party is the top-level legal entity; its children are the subsidiary entities; their children are trading desks, books, or booking centres. Each node in this tree represents a real organisational unit, and users log in to the node that corresponds to their own entity.

Two seeding methods are available:¹

• GLEIF Registry — searches the global LEI registry for your real organisation. The entity you select becomes the root party, and its corporate descendants in the GLEIF hierarchy — subsidiaries, branches, and related entities — are created automatically as child parties. This is the recommended approach for production deployments: the GLEIF data provides real legal entity names, LEI codes, and verified corporate relationships.
• Generate Synthetic Data — creates a realistic but fictional party hierarchy using generated names. Use this for evaluation tenants, demonstrations, or testing where you want a plausible structure without importing real organisational data.

Click Next.

It helps to be clear about what this step does and does not do.

What it creates: the party nodes — the named entries in the hierarchy that represent your legal entities and business units. Each node gets a name, a LEI code, and a position in the tree. After this step OreStudio knows that "Barclays PLC" exists as a party, that it is the parent of "Barclays Bank UK PLC", and so on. The hierarchy structure is in place.

What it does not create: the operational content within each party — the books, portfolios, business units, counterparties, and report definitions that each party uses day-to-day. That content is added separately, after provisioning, by the Party Setup wizard (described in The Party Provisioner wizard below). Think of this step as building the org chart; the Party Setup wizard then stocks each office.

To use the GLEIF registry, pick an LEI dataset size (which controls how much of the registry is loaded for searching), filter by Country if needed, and search by entity name. The entity you select becomes the root house party — the top of your internal hierarchy. Its corporate children and grandchildren in the GLEIF registry (subsidiaries, branches, booking centres) are created automatically as child operational parties. You do not need to build the structure by hand; the GLEIF corporate hierarchy data does it for you.

This step is optional — skip it to create parties manually later from the Parties window. Click Next.

OreStudio runs a multi-step publishing pipeline to populate the tenant with all the data selected in the previous steps. The pipeline dispatches datasets in the correct dependency order — classification tables before the entities that reference them, catalogue data before GLEIF data — and shows live progress in the table.

Each row in the table is one dataset. The columns are:

• # — the dataset's position in the dependency graph (zero-based). Datasets with lower numbers are prerequisites for those with higher numbers.
• Name — the dataset identifier, in source.dataset form. The prefix identifies the data source: iso.* datasets contain ISO standard data (currencies, countries); fpml.* datasets contain FpML reference classifications (party types, roles, regulatory sectors); gleif.* datasets contain GLEIF LEI entity data (counterparties, house parties).
• Status — pending (not yet started), in_progress (actively loading), or completed (finished successfully). A red status indicates a failure.
• Warnings — any non-fatal issues encountered during that dataset's load, displayed as a count. Click the row to see details.
• Started At / Completed At — UTC timestamps for the dataset's execution window.

The log panel at the bottom provides a running narrative: which catalogue is being published, how many datasets were dispatched, and the final outcome for each phase (reference data, organisation, activation).

When all rows show completed and the log ends with "Organisation activated successfully", click Commit to finalise the setup, or Back to change your selections.

The final page confirms what was created. Click Finish. The tenant now has its reference data and party hierarchy in place.

By this point the house hierarchy — the party nodes representing your organisation's legal entities — already exists. This wizard populates one specific party within that hierarchy: it attaches the external counterparties that this party trades with, then publishes its operational structure, risk reports, and market data configuration in one step. Click Next.

Counterparties are the external legal entities your organisation trades with — banks, broker-dealers, corporates, funds. Where parties (the house) represent your own organisational structure, counterparties represent the other side of your trades. The distinction is important: house parties own books and positions; counterparties appear on trade tickets as the facing entity.

OreStudio imports counterparties from the GLEIF LEI registry. This is a deliberate design choice: GLEIF contains over two million real legal entities with verified names, LEI codes, countries of incorporation, and corporate relationships. Importing from GLEIF means your OreStudio instance starts with a realistic, authoritative counterparty population rather than a hand-crafted list. In an evaluation or demonstration tenant this is especially valuable — trades booked against real counterparty names (Deutsche Bank, JP Morgan, BlackRock) look and behave exactly as they would in production, making scenario testing meaningful.

The dataset size controls how many GLEIF entities are loaded: smaller sizes load a representative subset quickly; larger sizes import a more complete global population. You can add individual counterparties later from the Counterparties window regardless of which size you choose. Click Next.

OreStudio runs the party setup in five phases, shown in the log panel:

1. Phase 1: importing counterparties — loads the selected GLEIF counterparty dataset into the party's counterparty table. The progress table shows one row per dataset (e.g. gleif.lei_counterparties.small), with the same Status / Started At / Completed At columns as the Tenant Provisioner publishing step.
2. Phase 2: publishing risk management — publishes the risk_management bundle in full: business units (testdata.business_units), portfolios (testdata.portfolios), books (testdata.books) — the lowest-level containers that own individual trades and positions — and the standard set of risk-report definitions (ore.report_definitions), since reports reference the book/portfolio tree.
3. Phase 3: publishing synthetic market data configuration — publishes the synthetic_realistic_2026 bundle in full: the "2026 Realistic" theme's FX spot and IR curve generation configs, and any further asset class added to the bundle in future. Two other themes exist – synthetic_ore_samples_2016 ("2016 ORE Samples", matching the conventions ORE's own sample data comes from) and synthetic_uniform_demo (a simple, non-vintage demo/exercise archetype) – publish those separately (e.g. via ores.shell) if you want them available too. Only one theme's feeds should ever run at once: the Market Simulator's Start action at the collection root prompts you to pick a theme rather than starting them all.
4. Phase 4: publishing FX driver rates — publishes the curated marketdata.reference_vintage_2016_02_05 bundle so the party has real market series/observations to browse.
5. Phase 5: activating party — marks the party as operational so users can log in to it and begin booking trades.

When the log ends with "Party activated successfully", click Commit.

The final page confirms the party is now fully operational: it has counterparties, an organisational structure, scheduled risk reports, and market data configuration.