An OMS event is just a vendor-shaped message. The sidecar reads your native format, maps the fields that determine economic identity, and derives the Sigrid locally. Four adapters ship today; a new format is a small adapter, not a platform change.
Each adapter reads one system's own message shape and produces the same canonical form. A CDM trade and a Murex trade describing the same economics derive the same identifier — and different economics derive different identifiers, with the differing field named.
Reads NEW_DEAL / AMEND / CANCEL messages with rates as percentage strings and calendars as currency codes.
Reads TRADE_BOOKED / TRADE_AMENDED events with PAY/RECEIVE leg roles and USD-SOFR-style index spellings.
Reads the trade feed with word-form frequencies (Semi, Quarterly) and benchmark spellings like SOFR-Compound-OIS.
Reads the CDM interestRatePayout tree directly. The same swap as CDM, Murex, Aladdin or ThinkFolio lands on one identifier.
The sidecar runs inside your network and takes events the way your system already produces them. In production it usually subscribes to a message bus; for a pilot, HTTP is enough.
Kafka · Solace · IBM MQ — the sidecar subscribes and processes events as they fire.
No bus? POST raw OMS events to the sidecar's /ingest endpoint. Good for a pilot.
Scheduled file drops for systems that export rather than stream.
Anything not in the live list is a new adapter, not new infrastructure. Give us a sample message and the field map, and the canonical form on the other side is the same derivation every adapter already feeds.
The happy path was always going to derive cleanly. The edges are the work, and we document them field by field rather than hand-wave them. Today the adapters handle vanilla IRS and cross-currency swaps with an MTM-reset leg. Known gaps:
The fuller version of this argument — with the worked example and the canonical bytes — is in What “CDM-compatible” has to mean.