Straight answers.

Sigrid derives a deterministic identifier from a trade’s canonical economic terms, so two counterparties independently arrive at the sameidentifier for the same trade — and a different one, with the disagreeing field named, when they don’t. The shared pair room turns that into a live exception queue both sides see.

No. Sigrid is not an OMS, trade booking system, chat tool, or allocation workflow. It does not execute, book, or legally confirm anything. It sits beside your existing systems and gives both sides one identity and one exception surface for the matching problem.

A UTI is assigned — one side generates it and the other adopts it, so it tells you who created it, not whether you actually agree on the trade. A Sigrid is derived from the economics, so it only matches if the terms match. More in What a UTI isn’t.

Not on day one. Sigrid is a bilateral identity and exception layer you can run alongside existing rails, targeting the gap they leave — opaque, side-of-the-trade reconciliation. Context in What MarkitWire actually does.

Your raw OMS message never leaves your network. The sidecar runs on-prem, reads your native event, and derives the Sigrid locally. What it attests is the canonical economic terms plus the Sigrid — the fields both sides would independently agree on — scoped to one counterparty. Internal book IDs, trader and desk annotations, and your signing secret stay with you. The economic terms cross because they are what make a field-level diff possible on a break; they are never shared beyond that pair.

Inside your own network, next to your OMS. It subscribes to your message bus or accepts events over HTTP, normalises and derives locally, and signs attestations on-prem. Signing secrets never reach a browser — see Security.

Three things: the canonical economic terms, the derived Sigrid, and the match_id with the counterparty it is scoped to. The raw OMS payload, internal identifiers, and confidential annotations do not.

In a pilot, a shared service that only ever receives normalised fields — never raw OMS data. The hosting model (neutral-hosted, or run by one party for a bilateral pair) is part of the design-partner conversation; the privacy boundary is the same either way.

Native adapters ship today for Murex, Aladdin, ThinkFolio, and ISDA CDM. Anything else is a small adapter, not new infrastructure — see Integrations.

Yes. The sidecar accepts events over HTTP and can take scheduled file drops. A message bus (Kafka, Solace, IBM MQ) is the production path, not a prerequisite for a pilot.

An adapter is roughly a field map plus a sample message — on the order of fifty lines, not a re-platform. The canonical form on the other side is the same derivation every adapter already feeds, so most of the work is reading your format correctly.

It doesn’t matter for identity. A Sigrid is derived from the economics, not assigned, so two sides agree without exchanging a UTI at all. Mismatched or missing UTIs are exactly the situation deterministic identity is meant to cut through.

Honestly: vanilla IRS and cross-currency swaps with an MTM-reset leg derive cleanly today. Amortising schedules are read as flat and flagged, not silently flattened; stubs default to short-initial; compounding is carried in the index name. These edges are documented field by field on Integrations.

Amendments and novations don’t fragment the trade. A changed trade derives a new Sigrid linked to its parent, so the lifecycle reads as a single lineage from open to current — visible to both sides on the lineage timeline.

Sigrid is early and we say so. The derivation engine, adapters, and pair room are built and tested; formal certifications, a penetration-tested deployment, and production SSO are on the roadmap. The demo here runs on synthetic trades, not real counterparty data — posture and gaps are laid out on Security.

A design-partner pilot: one counterparty pair, one or two OMS adapters, and a short window to see real breaks surface against deterministic identity. Reach out and we’ll scope it.