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.

The welcome page outlines the steps: select a catalogue, choose how to populate the party hierarchy, and execute. Click 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, creates the internal organisational structure (business units, portfolios, and books), and defines the risk reports that will run on its data. 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.

Optionally create a set of standard risk-report definitions — model calibration, yield curves, FX spot rates, volatility surfaces, credit curves, NPV, cashflows, Delta and Gamma, Vega, bucketed DV01, exposure, CVA, DVA, and others. Use Select All / Deselect All, or tick individual reports; they can be edited later from the Reporting menu. Click Next.

OreStudio runs the party setup in four 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 organisation structure — creates the internal organisational entities within the party: business units (testdata.business_units), portfolios (testdata.portfolios), and books (testdata.books). Books are the lowest-level containers that own individual trades and positions.
3. Phase 3: creating report definitions — creates the scheduled risk-report configurations selected in the previous step.
4. Phase 4: 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 what was set up. The party is now fully operational: it has counterparties, an organisational structure, and scheduled risk reports.