Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Jeff's suggestion was that any such identifier should be entirely opaque, it's just a unique identifier, and John Gemski agreed with him.  Pete and Elisa think that if some amount of structure is inherently available, and if one can learn something about what is being identified, or by whom if you have the LEI, then that's valuable to capture.  The question is how best to do so.  The concept of ordering came up - in a UTI, the LEI precedes the internal transaction identifier.  That identifier could be minted by either counterparty to the transaction, although at least given a UTI one should be able to identify the party that minted the UTI through their LEI.  Our current model for a structured identifier says that it may be comprised of another code and may be comprised of another identifier but says nothing about how those elements are ordered with respect to that structured identifier.  A UTI is comprised of an LEI and an internal transaction identifier that is intended to be unique to the counterparties involved, with the LEI followed by the transaction identifier.  Essentially it is a pair of tuples that includes exactly one tuple that is (1, LEI) and exactly 1 tuple that is (2, transaction id). If the ordering is encoded that way then it doesn't matter which order the tuples themselves occur in, and a regular expression could be developed that unpacks the text string representing the values expressed in those tuples.  Similarly, an ISIN is a pair of tuples that includes (1, alpha 2 country code) and (2, NSIN).  We need to put a little thought into this, but capturing the minimal information suggested in these two cases, and for other similar identifiers, makes sense, at least to Pete and Elisa.  We opened DER-129 as a place to work on this via JIRA/GitHub.

Decisions:

Action items

  •