The market simulator screens

Table of Contents

1. Summary

The synthetic area authors and runs the market data the platform generates rather than receives. One window does most of the work, the Market Simulator. It browses the configured feeds, shows what demand makes run, and lets an operator start or stop one as a test. It shows what a running feed is producing. The per-entity editors sit behind it, one per configured entity.

The Qt implementation is in the separate ores.qt checkout under synthetic/, and its menu is Market Data > Synthetic. Each screen below is restated as plain HTML under doc/prototypes/ so its layout and its arguments can be reviewed without a session.

This note holds the screen inventory, the cascade rule and the prototype reference for each window. What each editor writes belongs to the config notes, which are The generation config collection and folders, The FX spot generation config, The GMM component, The IR curve generation config, The IR curve template and its parameters and The yield curve process type catalogue.

2. The composite window

2.1. Market Simulator

The one-stop authoring window. A toolbar (New Collection, New FX Rate, New IR Curve, Edit, Delete, Start, Stop, Reload), a tree of the configured feeds on the left, and a hero header, a summary and a live chart on the right. FX feeds show a mid-price tick chart. IR curves show recent curve snapshots overlaid, newest bold, with the number of snapshots under a History control.

Where an FX feed starts, and why, is on the calibration screens: the class list, the feed's record and the policy.

The prototype is at synthetic feeds.

3. The cascade rule

Demand starts a generator on its own. The start and stop paths below are the operator's test controls, not the way a feed normally runs.

A tree node carries one of three states, running, stopped, or partial, and a partial node reads as a count such as "3 of 8 running".

Starting a non-leaf node sends one folder-scoped request, and the server fans it out over the subtree. The client does not walk the tree and it does not send one request per feed, so a collection of twenty feeds costs one round trip. A Feed leaf, or a selection that mixes a leaf with a non-leaf, uses the per-feed request instead.

The same two paths exist outside the window. The shell exposes them as synthetic start folder, synthetic start feed and the matching stop verbs, and the folder token grammar is the same on both surfaces.

A feed is identified by its source_name, which mirrors its namespace path, for example synthetic.bloomberg.gbpusd. The source_name is the identity and not the row id, so a rename is a re-identification.

4. The editors behind it

4.1. Author an FX price feed

The FX spot generation config editor, three tabs. The Instrument tab holds the pair, the oresmd URI, the source name, the description and the enabled flag. The Price behaviour tab chooses an engine (Geometric Brownian Motion, Ornstein-Uhlenbeck, or Gaussian Mixture), the tick clock ("New price every N s", echoed as ticks per hour), and a Simple or Advanced mode. Simple exposes drift and volatility, and for the mean-reverting engine it also exposes the long-term mean and the reversion speed with the derived half-life. Advanced edits the raw GMM components with the weight sum normalised on save.

Two live previews sit beside the form, the return distribution f(x) = Σ wᵢ·N(x; μᵢ, σᵢ) and sample price paths with a Reseed control. The Provenance tab chooses "Fixed", where the initial price is entered, or the "From vintage data" option, where the available vintages are browsed.

The prototype is at author an FX price feed.

4.2. Author an IR curve feed

The IR curve generation config editor, four tabs. ores.web draws the same journey with the shared feed screens of the Feed screen standard. Instrument holds the currency, the index name, the tenor, the role (Discount, Projection or Self-discounting), the fixed leg frequency and the oresmd series URI of the curve it publishes. Process chooses one of the seeded short-rate models, Vasicek, Cox-Ingersoll-Ross, Hull-White, Two-Factor Gaussian or Black-Karasinski, and renders one row per parameter the catalogue defines for it, with the symbol, default, minimum and maximum. Two previews argue the choice, the curve shape the parameters and the template imply, and sample short-rate paths. Curve Template is the ordered tenor ladder the curve is bootstrapped from (DEPO, FRA, IRS, OIS), and at least one entry is required.

The prototype is at author an IR curve feed.

4.3. Manage synthetic collections

The Generation Configs window, which edits a collection, its name, its description, its enabled flag, the feeds it owns, and its version history. In the tree these same rows are the Collection nodes, seeded as Basic, Realistic 2026, Uniform Demo and ORE Samples 2016. Deleting a collection deletes its feeds. The prototype is at manage synthetic collections.

4.4. Manage GMM components

The GMM Components window, which shows the same rows the FX editor edits in Advanced mode, browsed across every FX feed at once. Each component belongs to one feed and carries a description, a mean, a stdev and a weight. The weights are normalised across a feed's components when it is saved, so the screen shows both the raw sum the user typed and the normalised weights. The prototype is at manage GMM components.

4.5. Manage yield curve process types

Two runtime-managed catalogues that together drive the IR curve editor's Process tab, the process types and their parameter definitions, each with a parameter name, a display name, a symbol, a short label, a data type, a default, a minimum, a maximum and an order. Because the catalogue is data, a new model needs no code change to appear in the editor. The prototype is at manage yield curve process types.

5. The curve build, which is not a synthetic screen

5.1. Bootstrapping the curve a feed produces

There is no synthetic curve bootstrap. Bootstrapping is one capability. A strip of instruments reprices to par and the curve is solved one pillar at a time, and it does not care whether each rate was observed or generated. The IR curve feed here produces observations, the same build then bootstraps them, and only the provenance differs. A generated rate is marked generated, so nothing downstream mistakes it for market data.

The bootstrap screen carries a real or a synthetic input source and belongs to the market data journeys, at Bootstrap or refresh a curve (prototype).

6. What is missing

  • The Market Simulator's tick chart and the IR curve snapshot overlay read a live stream. A history range, and a read as of a past instant, do not exist.
  • The GMM weight sum is normalised on save but the raw values are not kept, so a reviewer cannot see what was typed.
  • The process type and parameter definition catalogues are runtime managed, but the FX editor's engines are still a code-side list, so the two halves of the same idea are managed differently.
  • A feed's source_name is the identity and not the row id, so a rename is a re-identification.
  • No screen shows a collection's coverage, which asset classes, instruments and currencies it spans, before it is started.

7. See also

Emacs 29.3 (Org mode 9.6.15)