investment account and it's properties

[TomOldSwede]

Hi!

I’m working for a Swedish retail bank, and we are using FIBO as a basis for our own conceptual data model.

Currently I have a task, as part of a bigger “account statement”-work, to propose to the business people how to represent data about things that match pretty good to https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/InvestmentAccount or
https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/BrokerageAccount. But I’m missing the relation to the actual financial assets like number of securities, number of fund units, acquisition price etc, either directly as some sort of balance or via transactions. Some of that is found in https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/BrokerageAccount and it’s provisional subclasses.

I’m leaning on developing, extending https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/BrokerageAccount to cover the things missing. But what do you say, any hint on which path to explore and develop?

Kind regards,
Tomas

[mereolog]

@TomOldSwede I think you should bear in mind not just the actual properties of a concept but also those inherited from its parents.

In this particular case, I would look at the properties inherited from https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/Account, where you have both the balance and transactions aspects - see a snip from https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/BrokerageAccount below:

[TomOldSwede]

Hi Pawel! Thank you for quick reply.
Yes, of course, I'm aware of the inherited properties. But I've tried to find any reference form transaction record and individual transaction to a transaction regarding some financial instrument, but I can't find that. Or, looking at this again, is maybe a financial instrument identifier to be seen as a registry identifier... which I see now that it is! That should be the link, right?

[TomOldSwede]

Hmm, I think I tricked myself with the registry identifier theory...

[mereolog]

Hmm, I think I tricked myself with the registry identifier theory...

My path would be from brokerage account to transaction event via the path shown below.
Then I would look at the subtypes of transaction event, where you can get a grip of a thing being transacted at a individual transaction event.

[TomOldSwede]

Thanks. I've explored that path to some extent also, and it might be a lack of understanding in how to use a classifier concept on my side, but I thought that was only a classification of a transaction. Is it correct that the classifier has properties on it's own, how do those properties relate to the individual transaction concept?

[mereolog]

Thanks. I've explored that path to some extent also, and it might be a lack of understanding in how to use a classifier concept on my side, but I thought that was only a classification of a transaction. Is it correct that the classifier has properties on it's own, how do those properties relate to the individual transaction concept?

I did not mean to go through a classifier of any sort.

My idea is to go through this path:

• account has transaction record
• transaction record has registry entry as individual transaction
• individual transaction exemplifies transaction event.

Then if transaction event is a sale, then it applies to some product, has price, etc.

[TomOldSwede]

Yes, but trade and it's subclass securities transaction are types of classifier. https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/FinancialProductsAndServices/Trade

If they were types of individual transaction we would have the property we need for representing a transaction of a financial instrument of some sort: applies to some financial instrument

Are trade and securities transaction in the wrong taxonomy branch?

[mereolog]

Yes, but trade and it's subclass securities transaction are types of classifier. https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/FinancialProductsAndServices/Trade

If they were types of individual transaction we would have the property we need for representing a transaction of a financial instrument of some sort: applies to some financial instrument

Are trade and securities transaction in the wrong taxonomy branch?

All I can see from the model is that transaction events are exemplified by individual transactions, so in a sense the properties of the former can be seen as the properties of the latter. But frankly, my knowledge of FIBO ends here - perhaps @ElisaKendall could assist you from here.

[ElisaKendall]

@TomOldSwede @mereolog Trade and Securities Transaction are indeed subclasses of Transaction Event, which is an Occurrence Kind. Occurrence Kind is a classifier for individual occurrences (events) that happen. A trade is embodied in a contract - the relevant security should be defined as an instance of a subclass of contract. Similarly for securities transaction.

An Individual Transaction (i.e., an event) exemplifies a Transaction Event. The link between the individual transaction and the security in question should be IndividualTransaction exemplifies TransactionEvent isEmbodiedIn Contract as @mereolog suggested.

We did something similar for a US bank, which worked quite well for account statements associated with credit card transactions. Hopefully this is the connection you were missing. If that doesn't work, please let me know and we can add a property chain or something similar to be more explicit.

[TomOldSwede]

Thank you @ElisaKendall I think I somewhat understand what you are suggesting. But what I don't understand, which as I said may be due to me not fully understanding owl, is how you use a classifier to harbor properties that are valid for the thing it classifies, for me a classifier is just a classifier of things!? The natural way in my head and my proposal is to have something like individual securities transaction as a subclass of individual transaction, i.e. an occurrence, having a unique property, applies to some financial instrument, adding to the inherited properties from individual transaction and above, similar to individual payment transaction.
What do you think about my proposal and could you please explain the relation between the properties of the classifier and the properties of the thing that is classified.

[TomOldSwede]

Good morning (Swedish time :) ) !
Late last night I realized that I've missed that you're using the "examplifies"-property and not the "classifies", and I see that "examplifies" have the definition "is a realization or example of". But I still would very much appreciate an explanation on how this construct works, is it something similar to a subclass construct? And why do we need this when we already have subclasses and instances?

[TomOldSwede]

Hi @ElisaKendall, do you understand my comments and questions, or do you find them irrelevant :) ?

[TomOldSwede]

Hi @ElisaKendall , I apologize for being persistent; I don't mean to harass you :) but I believe this is quite an important question !

I can see that you have deprecated exemplifies-property. But I really think that trade should be placed in the occurrence taxonomy and not in the occurrence kind taxonomy. IMHO it seems quite obvious that this is a type of occurrence and not a type of occurrence kind, just look at the definition and properties(!), and I don't see any support for having trade as a type of occurrence kind in the slides from Deutsche Bank you claim to have adapted the trade concept from. And I even think that you should move transaction event to the occurrence taxonomy.

Based on the definition of trade you could argue that it should be a type of agreement in parallel to being a type of occurrence.

Please let me know your thoughts on this, and, if I'm wrong, please explain why.

Kind regards,
Tomas

[ElisaKendall]

@TomOldSwede

Apologies for the delay - I'm fairly swamped at the moment. The exemplifies property was moved higher up in the 'food chain' so that it could be used more broadly, so it is now in the relations ontology, FYI. Still there, but deprecated in the occurrences ontology, with an equivalent property declaration. One of the things we are working very hard on is to reconcile a number of patterns. Some have already been standardized by OMG and are now part of the Commons Ontology Library, and others are in work. Then we are backfilling FIBO with the standard versions. That enables much broader usage of the patterns and really cleans up things that are still a bit ad hoc due to legacy content. We've been experimenting with FIBO as the basis for question answering with large language models and other ML applications, so cleaning up patterns is really hugely important at this stage.

So to your main question, we are moving trade not to occurrence, but to be a subclass of situation. A trade is typically a long-running 'conversation' - only spot trades are instantaneous occurrences. But the concept of a trade will then be able to take advantage of the other details of a situation, including the parties involved, and allow us to pull at the threads from multiple directions for question answering about a given trade. In most of the more complex cases, the notion of a trade has a lifecycle, including drafting and approval of a deal through settlement and maturity, sometimes involving multiple contracts with cash flows that are traded in some cases.

You'll see that happen once we merge FBC-317 (which is still a work in progress). We'll be moving things like interest rate reset schedules, interest payment schedules, related principal payment schedules, all of that up from a few places where they are currently buried to debt instrument. We're also aligning these 'schedule pieces' so that one could create a composite schedule. The individual payments would be part of the overall contract schedule and related to the individual transactions that make up a statement (record of the transactions against an account). Some of these changes were tested with a large US bank but haven't been fully addressed in FIBO yet, but the work we are doing now will cover the schedule pieces. We might need to revisit the transaction content in a separate issue, but we're getting there. The approach will allow us to relate the relevant contracts, transaction confirmations that are evidence for what has taken place to date, players, and if we can get a decent example, show how a larger situation within an institution that includes additional deal(s) hedging the client deal would work.

Does that make sense to you?

I'd be happy to work through an example with you if you can send some details.

[TomOldSwede]

Thank you for your extensive reply, @ElisaKendall! And no worries, I think that was worth waiting for.

It made me happy for three reasons:

1. At least after a first read I believe I understand the thinking behind your proposed solution, and that it makes sense. And I might pick up on your offer to work through an example with me, but I'll see how things work out for us.
2. It is also reassuring that you are actively working with developing FIBO, and your experimenting with FIBO as a basis for different ML applications sounds inspiring. I think it would be super good with some information on your plans in general for FIBO, the strategy ahead, maybe including some details of know issues and what you see as prioritized. We are for instance currently planning to deviate from FIBO regarding how we represent product(in it's broadest sense) specification since we believe that product and it's surrounding requires some rework.
3. And I'm also happy that you, and @mereolog , took some of your time to answer me. I think we need an active discussion forum around FIBO. Previously I've worked quite a lot with telecom and the Frameworx of TM Forum, especially the Information Framework (SID), which basically is a class diagram based common information model for telecom. It is a common source of knowledge that comes with quite an active discussion forum.

I should also mention that our current use case for FIBO is primarily to act as a basis for our own conceptual data model used as the meta data core of our data catalog, and a basis for data products. We have only just touched upon how to use it with knowledge graphs etc.

Cheers :) !

[ElisaKendall]

@TomOldSwede Hi Tomas,

Please take a look at your convenience -- you'll see that we've just merged the resolution to FBC-317, and so Trade has now been moved under Situation as I mentioned. If it would be helpful to you, we could set up a call sometime to talk through some of the work in progress and goals for normalizing additional patterns, etc. We would also be happy to have you join one or more of our working groups - let me know at your convenience. Feel free to reach out to me directly at ekendall at thematix dot com. I'll be out of pocket for the last two weeks of March due to business travel, but could set something up in early April, for example.

[TomOldSwede]

Thank you Elisa! Sounds super good. We really appreciate your proposal. We'll have a chat internally and get back to you.