2022-04-12 Meeting notes
- Elisa Kendall
Date
Attendees
Agenda
1) Use Case reminder
2) Where we are on our road map.
3) Open Action Items
4) JIRA Issues Review - https://jira.edmcouncil.org/projects/DER/issues/DER-10?filter=allopenissues
5) Todays content discussion.
6) For next week.
Proceedings:
Today we revisited our discussion of representation of the various identifiers we need to track for derivatives. We talked about the UPI, which is a classifier for derivative products, the Digital Token Identifier, which is standardized via ISO 24165 parts 1 and 2, and the UTI - unique transaction identifier, which we need to ensure that we have proper representation for. Representation of the UTI will require at least temporary revision of our identifier concept to cover what we've done in the Commons ontologies for structured identifiers. The UTI is an LEI plus an additional identifier to represent individual transactions involving specific counterparties. For the UPI there is a data model for representation that we might consider including in FIBO. The UPI is currently limited to derivatives, and bins contracts based on certain features which we could actually model.
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.