Sandbox

A firm with hundreds of users cannot share one sandbox. Desks would see each other's experiments and imports, and the permission model must be able to enforce Chinese walls between desks (see Book access and permissions). A sandbox is therefore an entity of its own, opened where the work belongs.

The name follows market usage: a sandbox is a space where actions have no effect outside it. The analysis notes use the same word for the holding area where broker-originated trades wait for a human check.

Every book the firm trades in maps to a book in the ledger and is created by Finance; the trading system holds a view of them and cannot create one. A virtual book is the one exception, and the rules that make it safe are what define it:

1. It is created by the trading system, inside a sandbox, by the user or process that needs it.
2. It is never mapped to the ledger. Its ledger feed is none, and no ledger book corresponds to it.
3. It belongs to exactly one sandbox. A virtual book sits only in its sandbox's portfolio tree, and a real book never does.
4. It holds no position of the firm. The next section states what its trades may be.
5. Nothing official reads it. Official P&L, risk, capital, the ledger, settlement, confirmation and regulatory reporting exclude virtual books by construction, because the trades in them cannot reach the states those processes act on.

A virtual book has a classification like any other book, because valuation needs one — a what-if is meaningless if it does not know whether the trade would sit in the trading or the banking book. The classification describes the book the experiment imitates; it does not make the book part of either regulatory book.

The trade classification decides which machine a trade runs through, and the hypothetical and test machines hold no transition that confirms, settles or reaches the ledger. A draft is not an agreement either (see Trade lifecycle).

The lifecycle also files a pre-live trade — an agreement struck but missing details — under draft. That trade is an agreement, so it belongs in a real book, not in the sandbox; only a draft recorded before any agreement may sit in a virtual book.

A trade in a virtual book can never be live. That is the single rule the schema enforces, and the regulatory rules below follow from it.

Every route out of the sandbox goes through the ordinary lifecycle, so a trade that becomes real is checked, authorised and confirmed exactly like any other.

Leaving a virtual book is therefore not a book move: a sandbox trade has no position to move and no ledger history to carry. A live trade cannot enter a virtual book at all; to experiment on it, a user makes a hypothetical copy.

A what-if on a live trade never edits it. The user makes a hypothetical copy in one of their sandboxes, linked to the original, and changes the copy. The copy needs read access to the original, so a user experiments only on trades they may already see. The link lets a report set the copy beside the original, and lets a reader see what the experiment was about. A structure or a hedge can be tried the same way, from copies.

Market data needs no sandbox of its own, because the resolution pipeline already separates what exists from what a valuation uses:

• Imported market data enters the market data universe under its own source. The official configuration does not resolve to that source, so official valuations never see it.
• Changed market data is a new item with its own identity, which declares its source and the change applied. The analysis notes state the rule: market data is immutable, and anything derived by perturbation is a new element, never an edit.
• Run-time scenarios — the shifts ORE applies in a stress or sensitivity run — change nothing that is stored.
• A snapshot fixes the values a run used, so an experiment can be repeated (see Market data snapshot).

Analytics configuration — conventions, curve and pricing engine configurations — works the same way: an ORE sample brings its own configuration under its own name, and nothing official refers to it.

Making imported market data official is a decision, not a copy: the data's source is admitted to the official configuration, and that admission is recorded as an activity with who and why.

A report definition states its inputs explicitly: the trades in scope, the market data configuration and snapshot, and the analytics configuration. An experiment is a report whose scope is a sandbox, or whose market data or configuration points at sandbox data. A comparison is two runs that differ in one input. A report whose scope reaches into a sandbox is marked unofficial, and an official report cannot include any sandbox.

An import is a run of a process with an identity: who ran it, when, from what source, and what it created (see Trade sets and trade groups).

• An import to inspect, reconcile or rehearse runs into a sandbox whose purpose is import, anchored where the importing team works. It creates hypothetical or test trades in that sandbox's virtual books, its market data under the import's source, and its configuration under the import's name. Discarding it cancels what it created; nothing is deleted.
• An ORE sample is such an import into a sandbox whose purpose is sample: one sample set, one sandbox, one source, one configuration, and a report definition that ties them together. A team that keeps firm-wide samples anchors their sandboxes at the top of the tree.
• Real deals are never imported into a sandbox. A concluded deal is booked into a real book at once, and held as unauthorised until Operations releases it; the authorisation queue is the controlled staging area for agreements. The next section explains why.

An import is run more than once: an operator re-runs it after a failure, and a nightly job re-runs it over a directory that grew. It is planned from what the document set is, not from when it was read, so a second run names the same portfolios, the same books and the same trades. The trades it names are already booked, so the store refuses them and the run reports each one rather than booking it again.

A row the import cannot book is reported against its source file and its trade id, with the store's own message. Nothing of that row is stored: the booking it had already written is closed again before the run moves on, so a row is either booked whole or absent.

A row that does book raises the same operational authorisation request a manual booking does, because it takes the same write. A sandbox trade is a test and raises none.

The sandbox stays outside every regulatory obligation by holding nothing that the obligations apply to. Each rule below is met by the single rule that a trade in a virtual book is never live.

Two further controls follow from book classification: test trades in production use test counterparties and entities, so nothing can mistake them for real business; and a sandbox report is never a source for official P&L, capital or regulatory figures.

This section is analysis rather than reported practice.

The sandbox is modelled as ores.refdata.sandbox, its members as ores.refdata.sandbox_member, and the rights at a node as ores.refdata.portfolio_right. A virtual book is a book whose sandbox_id is set; the book model holds the rules.

• sandbox is an entity: name, purpose, anchor (an official portfolio), owner, visibility, members, status and review date. Its root portfolio is its own, and no official portfolio contains it.
• The right to open sandboxes is held at a node of the official tree, and a sandbox's anchor must be a node where its owner holds it.
• A book carries whether it is virtual. A virtual book has no ledger book and belongs to exactly one sandbox's portfolio tree; a real book never does.
• Copying a trade into a sandbox checks the user's read access to the original.
• A trade's booking may name a virtual book only while the trade is draft, test or hypothetical. The transition to live requires a real book in the same write.
• The links what-if copy (original to hypothetical) and dealt from (hypothetical to actual) join a sandbox trade to its official counterpart.
• An import is an activity with participants, like every other act.
• Market data and configuration carry their source; the official configuration names the sources it admits.
• Report definitions mark whether they are official, and an official definition cannot select sandbox inputs.

• Sample counterparties. An ORE sample names its own counterparties and netting sets. Creating them as test counterparties keeps them out of real business but adds them to the tenant's reference data; a dedicated demonstration tenant keeps the tenant clean at the cost of switching tenants to explore a sample.
• Retention of experiments. Whether hypothetical trades in an experiment sandbox fall under the record-keeping rules — they are neither orders nor transactions — decides whether a user may discard an experiment completely or only cancel it.