Date
Attendees
Agenda
1) News
2) Composite Date Value Proposal
3) Contracts hierarchy and abstractions review
- along with review of Arrangements abstractions
4) FCT Changes / Use Case review
5) JIRA Issues Review
6) Where we are on our road map.
7) For next wee
Proceedings:
FND 235 - proposal from EK to add a datatype and property to the dates ontology
John Gemski: Can you give the link for the new actions page?
https://wiki.edmcouncil.org/display/FND/Actions
EK - reusing the same existing datatype (union of dateTime, dateTimestamp or string) - problem using the current structure with multiple restrictions. Proposing a composite date value in circumstances where comparisons are important
EK - new pattern is for specific purposes (for efficiency) purposes - when challenges exist for mapping (one of the three data types don't work)
TradeDate and SettlementDate (i.e. when optionality is needed) is the driver of the composite date
Varying registration dates - another example
PR - not keen on "name" (composite date and value might not be appropriate)
PR - potential redundancy for xsd:string
PR - dispute need for "hasReleaseDateTime"
PR - dispute need for hasReleaseDateTime "property" (he is OK with the data type)
EK - created the property hasReleaseDateTime for convenience (PR thinks it is the opposite)
EK - there are lots of examples where the datatype is used (hence the driver for the proposal)
FND group is in agreement on the value of the property hasReleaseDateTime
- but not with that name, and it must have some semantics e.g. a domain. Not simply a property for every possible reference to that datatype.
JG - would like two date representations (release date and event date - including time zone)
JG - the distinction btw release and event date is important for trading time stamp
EK - this can already be accomplished using existing date structures (does not allow for time stamp at nano-seconds)
JG - look at the problem from the perspective of the business user who is evaluating FIBO from the CONCEPTS that they care about. Not only about how it might be implemented - must also include the concept
JG - two problems (for events need nano-seconds); #2 how to represent time zones (+/- UTC is ISO recommendation)
MG - future exercise date cannot be represented as an offset from GMT (in January you have a different time from June due to daylight savings time) - must be represented as "exercisable"
MG - "offset" is inadequate for any future event
MB adds: surely future events are an ‘occurrence kind’ rather than an ‘occurrence’ – even if they have a calendar date it has not happened yet. EK concurs.
EK - recognizes MG issue is important (unclear on how to address) - request examples for evaluation of options
EK - back to notion of "composite" - this could handle event dates (raise two issues (1) for nano-seconds (2) time zone challenge - do we need two datatypes to implement?)
MB to raise JIRA issue on event dates
EK - back to naming issue (what is the alternative to "union" date)
PR - proposes "general" date as option
MB - proposes "combined date value"
Action - EK to research date naming convention options for consideration
John Gemski: Here's the problem. NYC is normally -5 UTC. For 2 weeks every year the US goes to DST 2 weeks before Europe. So for that 2 week period the time difference is -4 UTC and then it goes back to -5 UTC when Europe goes to DST. Problem is there's no conformity when time zones change between DST and standard time.
MB adds: there is an ontological distinction between a point in time in and of itself, and 'the time in (some city)'.
Jeff Braswell: What if an Occurrence is something that occurs over a range of dates and time?
EK still sees value in keeping the property hierarchy for composite date (for rollup) as long as domain and range can be expressed
MB/EK to work offline to create a proposal for onward consideration
Jeff Braswell: A conference, or a music festival, or a business trip, etc
Jeff Braswell: debt instruments are also transferable, as are other contracts
Slides
Here are the slides:
(I re-did the Contracts diagram to captre all the existing relationships between things that are on the page. I also added the remaining sub classes of Financial Instrument, for completeness)
Decisions:
Action items
- Mike Bennett Raise 2 new JIRAs, for date/time that includes nanoseconds, and for the ability to deal with tome zone differences.
4 Comments
Cory Casanave
With respect to Financial Instruments
The point I was raising is that none of these financial instruments are “contracts”, they are rights or obligations with respect to a role in a contract – the contract creates the financial instrument (including currency, which I didn’t realize).
Example; when a trader “buys an options contract”, he buys it from someone, who sells that contract. There are 2 parties. Each may be able to exchange their right/obligation. In some cases only one side may be traded. “Buying a contract” is convenient slang.
So, I question the idea of subclassing “financial instrument” from contract at all – a financial instrument is a right or obligation. (asset/liability) with a relationship to a contract.
Looking thru the FIBO definitions there are also a lot of conflicts and ideas “mixed together”, they need a semantic analysis.
For these financial instruments there are a set of independent partitions, which I am starting to document. These include:
You can then name the permutations. E.g. Securities are fungible exchange tradable financial instruments.
Investopedia: A security is a fungible, negotiable financial instrument that holds some type of monetary value. It represents an ownership position in a publicly-traded corporation (via stock), a creditor relationship with a governmental body or a corporation (represented by owning that entity's bond), or rights to ownership as represented by an option.
This makes it clear that non-negotiable security makes no sense. Perhaps U.S. savings bonds are financial instruments but not securities. The industry definitions do not seem consistent here, we should be.
I am working on a document with these distinctions, but I need to bring in some more definitions from reliable sources.
By the way, I also have a diagram of this hierarchy in FIBO already done.
Mike Bennett
From email:
John Gemski wrote:
security vs financial instrument -- look at this
https://en.wikipedia.org/wiki/Security_(finance)
I think we can say “security” is a tradable financial instrument although as the wiki says what’s considered a security does differ by legal jurisdiction. As was mentioned what doesn’t qualify as securities are government bonds and miscellaneous assets such as oil, painting, etc. The interesting question is since they’re not tradable should they be considered financial instruments at all? The answer I believe is that they can be assigned a value and affect the portfolio value of the owner. They may not be traded but they can be sold or redeemed in the case of government bonds. Interestingly real estate falls under this umbrella of non-tradable financial instruments and represents major portions of the portfolios of the super-rich.
John
Mike Bennett replied:
The problem is this:
If we are thinking in vocabulary terms, the words Security and Financial instrument are used more or less interchangeably to refer to a class of thing (a class of contract) BUT the etymology of both of those words actually refers to a distinct set of concepts, which are ‘relative things’:
Financial Instrument: a kind of ‘instrument’ (in the sense that a multimeter or oscilloscope are instruments); this is a thing in a role and the role is to facilitate (or ‘instrument’ (vt)) some activity. The particular activity that is instrumented is not specified but might for example be investment growth, a hedge or something else of a financial nature.
Security: Something that makes you secure.
The words we use in language legitimately range over the concepts of the things in these roles or functions (context) and over the things in themselves that may be used to perform those roles or functions.
In the standards, we really only want to nail down the things-in-themselves for these matters, at least for now. That is what ISO does with its use of the word Security. Further, ISO (as ISO 20022, as WG1 that would have been ISO 19312, and ISO 10962 (CFI)) specifically only care about that subset of things in the world that are tradable on exchanges (or over the counter, for debt) and that have publicly issued identifiers (ISINs). The real range of things that might be covered by the word Security (in this thing-in-itself sense) ranges over a slightly broader category of things, including privately held shares, directors shares and so on. So even locally the name is a slight misnomer, for the sole and simple reason that we agreed (under pressure from SWIFT) to use the label ‘Security’ for the class of things that are covered by these ISO standards – the class of thing that I otherwise wanted to call ‘Negotiable Security’ but perhaps should even have been ‘Publicly Issued Negotiable Security’.
Subsequently Elisa has introduced the separate class Negotiable Security. Based on today’s call, I would assume that this is based on the class called Security being perceived as potentially ranging over nearly everything that that word would normally cover, including those other things she mentioned that are not tradable but that provide some level of security to the holder (I can't remember what they were called). These would certainly be kinds of thing-in-itself that can perform the function of security in that relative sense, but they were never intended to be part of the set of things covered by the ISO 20022 ‘Security’ concept (as they were out of scope for ISO), hence the narrower written definition that Pete read out. Other things that can perform that function include these oil paintings and things.
Cory Casanave
Mike,
We are talking about finance; buying and selling stuff is quite central, as are rights and obligations. You can buy and sell stocks and bonds (avoiding the loaded terms) or horses or sex or gold or renewable energy credits. You are buying and selling rights and obligations (per REA). There are certainly differentia for what you can buy and sell in various ways that ultimately get down to exchange tradable fungible rights, like stocks or bonds. That ISO 20022 starts in the middle is their business, I suggest we need to be more precise. We need not be fooled by others sloppy use of language or inconsistent laws.
I'm not sure what the best term is for exchange tradable fungible rights to assets is, but I don't think FIBO can sidestep the question of what they really are because other parts of FIBO deal with the more general concepts. I should add that I have never considered "security" and "financial instrument" to be the same thing, i'm not sure if that means i'm out of touch or ahead.
Right now the hierarchy reflects our confusion.
Cory Casanave
I have posted an issue to cover this here: FBC-215 - Getting issue details... STATUS