CDM Trader renders a trade ticket from a product specification — the business fields a trader actually books, mapped onto the CDM paths behind them. Fill it in, and the object you end up with is valid CDM all the way down. Add a specification to the library and the product appears here.
Specification-driven · Validates against the model as you type · No per-instrument UI work
irs-fixedfloat CDM 7.0.0
A generated UI can easily become a flat list of every field in the model, which is complete and unusable. Trader works from a product specification instead: the business fields a trader books, each mapped to its CDM path, with the rest derived or seeded from the canonical product.
Set, derived, or required and empty. You can see at a glance what you entered, what the model worked out, and what is still missing.
Each leg carries its path — payout[0] · interestRate — so the form is visibly the model rather than something sitting beside it.
Contra amount from base and rate, receiver from payer. Derived values are computed and marked, not typed.
Most multi-asset applications are a screen per instrument, hand-built and hand-maintained. Trader has none. It renders whatever specification it is given, so coverage grows by writing a specification rather than by writing a screen.
Any product in the library with a specification, at the CDM version you are running.
Business fields laid out from the specification, seeded from the canonical product.
Values validate against the model as you enter them, not after you submit.
Allocation, novation, termination and the rest, executed as CDM events.
That is also why Trader is the honest answer to "should we build this ourselves?" — it is the thing a team would spend a year building, and the parts that took the year are the ones you would rather not maintain.
Trader does not reimplement the CDM. The interface renders and edits the object; validation, qualification and lifecycle execution happen in CDM Node, against the generated Java. One implementation of correct, not two.
| Layer | Does | Runs |
|---|---|---|
| Trader front end | Renders the ticket, builds and edits the CDM object | Browser |
| Product specification | Business fields, their CDM paths, and what is derived | Versioned with the library |
| Canonical library | Seeds the object the ticket populates | Versioned with the CDM release |
| CDM Node | Validation, qualification, lifecycle events, persistence | Your infrastructure |
Which means a firm evaluating Trader is evaluating Node at the same time — and a firm that already runs Node has most of what Trader needs.
A product is bookable once it has a specification. The library is ahead of the specifications in some asset classes — those products are browsable today and bookable as their specifications are written.
| Asset class | Examples | Bookable | In library |
|---|---|---|---|
| Interest Rate | Fixed/float, basis, OIS, cross-currency, swaptions, caps and floors, FRAs | 15 live | 15 |
| Foreign Exchange | Spot, forwards, swaps, NDFs, vanilla and non-deliverable options | 7 live | 7 |
| Equity | Listed equity, price and total return swaps, CFDs | 1 live | 23 |
| Credit | Single name, index, tranche, swaptions | Planned | 44 |
| Debt | Bonds | Planned | — |
| Commodity | — | Planned | — |
| Financing | Repo, securities lending | Planned | — |
Every product in the library is browsable before you book anything — structure and canonical JSON, in the product library. Specifications are being written class by class; tell us which you need and we will prioritise it.
Browse the canonical products first, or start a trial and book one against your own CDM release.