What "CDM-compatible" has to mean

Two months ago I wrote that the gap between ISDA CDM and a working matching system is the canonical form: the part the working group has consciously left out of scope. That post ended on half a dare. Anyone pitching you a "based on CDM" recon platform should be able to recite how they get from a CDM object to bytes both parties agree on. Currency-precedence-sorted legs. Fixed-decimal notional. ACT/360-canonicalised day counts. RFC 8785 JSON. SHA-256, first 100 bits.

We built that. Here is the demonstration.

Take the 5-year USD interest-rate swap from the Sigrid spec's worked examples. Ten million notional, pay fixed 3.50% against USD-SOFR compounded, quarterly float against semi-annual fixed, 30/360 on the fixed leg and ACT/360 on the float, NY calendar, modified following, end-of-month roll. The kind of line that books a hundred times a day at 10 Paternoster Square.

Write it as CDM JSON: an interestRatePayout array, a fixedRate on one leg and a floatingRate referencing USD-SOFR-COMPOUND on the other, a notionalStepSchedule carrying the currency, paymentFrequency as a Period, dayCountFraction as a value. The full Rosetta-shaped structure, the same one the FINOS distribution hands you.

Feed it through the derivation and you get:

IRUSD5Y-BKH2V9DYAMW9012RHQEK-M

That identifier is not assigned. Nobody minted it, looked it up, or reserved it. It fell out of the trade's economics. The canonical JSON behind it is one byte sequence:

{"effectiveDate":"2026-04-24","legs":[{"businessDayConvention":"MODFOLLOWING","calendar":["USNY"],"currency":"USD","dayCount":"30/360","legType":"Fixed","notional":"10000000.0000000000","paymentFrequency":"6M","rate":"0.0350000000","rollConvention":"EOM"},{"businessDayConvention":"MODFOLLOWING","calendar":["USNY"],"currency":"USD","dayCount":"ACT/360","fixingOffset":"-2D","index":"USD-SOFR-COMPOUND","indexTenor":"1D","legType":"Floating","notional":"10000000.0000000000","paymentFrequency":"3M","resetFrequency":"3M","rollConvention":"EOM","spread":"0.0000000000"}],"productType":"InterestRateSwap","stubHandling":"SHORT_INITIAL","terminationDate":"2031-04-24"}

SHA-256 of those bytes, top 100 bits, Crockford base32, a prefix that reads the asset class and tenor off the front, a check character on the end. Deterministic the whole way down. Move the fixed rate by a quarter of a basis point and the hash body changes completely. Spell the day count Actual/360 instead of ACT/360 and nothing changes, because the synonym collapses before the hash sees it.

Here is the part that's load-bearing for an ops desk.

The CDM adapter is not the only way into that identifier. The same trade arriving as a Murex deal message, rates as percentage strings and calendars as currency codes, derives IRUSD5Y-BKH2V9DYAMW9012RHQEK-M. The same trade out of Aladdin, with PAY/RECEIVE leg roles and USD-SOFR as its index spelling, derives IRUSD5Y-BKH2V9DYAMW9012RHQEK-M. ThinkFolio, with Semi and Quarterly as frequency words and SOFR-Compound-OIS as its benchmark: same identifier.

Four input formats. One identity. That is what "CDM-compatible" has to mean to be worth anything in a recon context. Not that the platform can parse a CDM file. That a CDM trade and a Murex trade describing the same economics land on the same identifier, and a CDM trade and a Murex trade describing different economics land on different identifiers with the differing field named.

CDM gives you the first half: a shared vocabulary for what a trade is. It does not give you the second half on its own, because two CDM-valid encodings of the same swap are not byte-identical, and the model declines to say which encoding is normative. The adapter is where the second half lives. It reads the CDM tree, pulls the fifteen-odd fields that determine economic identity, drops everything that doesn't (the payer/receiver perspective, the trade date, the documentation block), and hands a normalised structure to the same derivation every other adapter uses.

I want to be honest about the edges, because the failure mode of a post like this is to oversell a demo.

The adapter handles vanilla IRS and cross-currency swaps with an MTM-reset leg. It does not yet handle amortising notional schedules: it reads the initial notional and would treat a stepped schedule as flat. Stub handling defaults to short-initial rather than reading the regular-period dates out of the CDM calculation-period block. Compounding is baked into the index name, so a CDM trade describing USD-SOFR with a separate compounding flag, rather than USD-SOFR-COMPOUND directly, needs a mapping rule we haven't written. And the JSON paths target CDM's recent shape; a partner on an older or newer major version needs a per-version shim. None of these are hard. All of them are unwritten. The mapping is documented field by field, gaps included, rather than hand-waved.

The reason to show the demo with its edges attached is that the edges are the work. The happy path was always going to derive cleanly. The question a buy-side ops head should put to a vendor is not "can you read CDM" but "what happens to my amortiser, my stub, my compounding flag, my version skew." A platform that can't name its own gaps hasn't met them yet.

So the line from the last post stands, one word changed. Whoever builds the canonical form first writes the de facto standard. We've built one, bilaterally, in the open, with the worked example pinned so anyone can re-derive it and check. It is not an industry-blessed standard. It is a reference point that didn't exist three months ago.

Ask the vendor for their identifier for this exact swap. If the answer isn't a single deterministic string, you have your answer.