Every CDM integration starts by mapping somebody else's payload onto the model — the same party and instrument mappings, written again at every firm. These services do that step and hand back a CDM object that has been through the model's own validation. Give one an identifier, get a document you can use.
Live against GLEIF · Mapped with cdm-java · Validated before it is returned
Enter a Legal Entity Identifier. The service reads the entity's record from the
public LEI data and returns a Party — the LEI as a
PartyIdentifier, the legal name, and the registered address under
contactInformation. The identifier type is set to LEI,
so what comes back says where it came from.
The same shape for instrument data. This one answers from a fixed demo set rather than a live feed — instrument reference data is licensed, so the production service sits behind a data provider agreement. Responses here are marked as samples, in the page and in the JSON, so a document saved from this page is never mistaken for a real security record.
The browser calls this site, not the data source. The service holds the CDM
dependency, so the object is built with the generated types, post-processed and
put through RosettaTypeValidator before it is serialised. Nothing
here hand-writes CDM JSON, which is the whole point — a hand-written mapping
drifts from the model the moment the model moves.
Posts an identifier to this site. Same origin, so no cross-origin request and no key in the page.
Reads the source record, maps it onto CDM types, runs post-processing and validation.
Returned in the CDM 7 serialisation — the same document your own code would deserialise.
Written against CDM 7.4.0. The party service reads public LEI reference data, which is published under CC0; FINXIS is not affiliated with or endorsed by GLEIF.
Tell us which source and which CDM type, and we will tell you whether it is a service, an adapter you run yourself, or a morning's work either way.