The Financial Industry Business Ontology (FIBO) defines the sets of things that are of interest in financial business applications and the ways that those things can relate to one another. In this way, FIBO can give meaning to any data (e.g., spreadsheets, relational databases, XML documents) that describe the business of finance.
Home Page: https://spec.edmcouncil.org/fibo/
License: MIT License
Spot rates are quoted. Those quoted rates, as market data, are what’s referenced here. That should be reflected in the definition, which implies a specific rate for a (potential) trade. It is not the same as a rate in an actual Fx deal, since it is a quoted market rate.
Definition is currently as follows:
The exchange rate at a point in time, with settlement at that same point in time.
See also Bank of England definition:
"The data represent indicative middle market (mean of spot buying and selling) rates as observed by the Bank's Foreign Exchange Desk in the London interbank market around 4pm. A monthly working day average is published. They are not 'official' rates and are no more authoritative than rates provided by any commercial bank operating in the London market. Spot rates are applicable to deals executed for settlement two working days later."
Following up on comment elsewhere from @rivettp: "Wouldn’t it be more useful in short term to work on some test cases for FIBO-IND which we can use to test and update that specification (with both fixes and documented examples for ease of understanding) before it hits the world via formal RFC?"
Info I need in order to do this:
Tagging team because I don't know who has or knows about what (both materials and timeline info).
@EnterpriseDataManagementCouncil/fibo-core-team
I have started wiki page https://github.com/EnterpriseDataManagementCouncil/FIBO/wiki/How-GitHub-can-be-used-to-make-process-easier-and-smoother
and posted the links there to both the blog-entry description of GitHub-Flow and the 5-step diagram version, to start.
To be supplemented with specific-to-us description.
To the added method concept defined in another issue, define sub class for the method used to determine Volatility, with appropriate methods or features.
@ElisaKendall
@MikeHypercube
@ajvizedom
@dsnewman
@rivettp
@lonniev
@DennisWisnosky
Each Core Team member must
-- open an issue for the task of getting all the materials you are holding that belong in the repository in there. The description of the issue should include mention of which materials you are going to be putting in.
-- assign it to yourself.
-- Start working on it by uploading your materials.
See separate spreadsheet from Bruce Kendall, and possible subsequent updates.
The definition is as follows:
"the date this version of the specification was published"
if we're submitting a draft for review/RFC then it's not a formally published version (even for RFC it's not published until after approval by FTDF, AB and DTC) so we should not really use that annotation (we could use the less-specific dct:issueDate) , or we should update the definition of the property in Specification Metadata.
We cannot use "1.0" until the FTF has completed.
OMG does not use a format of the form "1.0.1" - it has to be 1.0 or 1.0.1.
If a subsequent RFC changes a module, do we increase the version of just that module or also its parents?
This term was intended to encompass all measures within the Indices and Indicators universe, but realistically Economic Indicators are not ever referred to as kinds of market base rate. They are measures of an economy, where base rates (index, interest rate) are measures of a market. It’s not clear where Fx stands on this either.
Proposed change: Remove the inheritance to the (renamed) MarketBaseRate from EconomicRate
Think of a better name for this (this name came from IBM Research and is not an attested industry label).
MarketBase is a more widely attested term.
Comment that the inclusion of Fed Funds Rate seems too specific a thing to include.
Reponse: SMEs were clear that this is widely used enough that it needs to be present. Review whether there are others which should be included based on the same criteria.
With properties as seen for the current class.
• Rename InterestReferenceRate to ReferenceRate
• Rename OvernightInterestRate to OvernightRate
• Rename USFedFundsRate to FedFundsRate
• Rename BaseRate to BankBaseRate
I was surprised to see the Magicdraw files / UML models in this folder; was expecting OWL files. Maybe need different label/distinction here.
Include property in Fx Spot / all Fx Rates for the block amount against which a quoted Fx rate is quoted.
This should possibly be a feature of the “Method”.
@ajvizedom please track down your info on Jira and add it to our Wiki.
Details to follow from Elisa / Bruce Kendall.
One or other or both of these might be affected by other changes identified in these issues.
In more detail:
cc: @DennisWisnosky
Applies to forward as well as spot, so should be applied to parent class (but NB change to Forward elsewhere)
Volatility and Spread are not kinds of parameter even in the loosest sense.
Separate these from the MarketReferentialParameter inheritance tree.
Following addition of new terms Analytics (see separate issue) these should be children of Statistical Measure.
This should be renamed to EconomicIndicator
Introduce “Method” and use it here (as well as for unemployment rates etc. as noted previously).
Also make it clear this is not the rate for a given transaction but a market quote
Determine where in the folder structure the two manifestations of the EA source file should go, put these there and check the structure back in.
We need a folder structure for the files managed by this repository. Let's sketch the ideas over in the Wiki pages. See https://github.com/EnterpriseDataManagementCouncil/FIBO/wiki/Suggestions-for-a-Folder-Structure
Add new terms for Dealt versus Term, being the currencies of the exchange itself.
From Investopedia:
Base Currency; Quote or Counter Currency where Base is the one there is 1 of.
Revision of released ontologies can be greatly reduced by the use of small, stability-optimized, ontology modules and architecture approaches such as spindling and pushing many integration dependencies into modules separate from main content modules. The current factoring of the FIBO ontologies is not optimized for stability. Current process assumes that it will be acceptable to users and to the OMG to revise released modules frequently, potentially with each new package release. If such revision is to be minimized, instead, some FIBO-wide refactoring will be necessary.
It is good practice to minimize the need to revise released ontologies. Frequent revision of previously released ontologies forces users to re-evaluate and possibly revise their own applications, mappings, etc. Extension of released ontologies is fine. Breakage and sync problems are less likely and more easily managed because of the separation of new and existing content, and the need to explicitly import new release content before changes are seen. This can't completely replace revision -- errors and bugs discovered post-release still need to be fixed by revision -- but it can dramatically reduce the frequency.
Remove inheritance link from Fx Forward to Fx Rate. Review whether Fx Rate would still exist as an abstract of anything other than Fx Spot. Add object property to Fx Forward identifying the rate against which it is quoted. Revise the datatype for Fx forward to reflect that it is a premium not a rate.
Add as synonym as appropriate (no synonyms seen in this model – check EA model for synonyms).
This enhancement covers a subset of pre-release tests, namely, those that apply to all FIBO OWL ontologies.
This test set should include
They should cite the actual version number/date. Otherwise they all have to be updated unnecessarily at the next version (which is often forgotten).
It is good practice to minimize the need to revise released ontologies. Revising once released tends to cause breakage in user applications. In a standard, it also causes downstream models to become out of sync.
Extension of released ontologies is fine. Breakage and sync problems are less likely and more easily managed because of the separation of new and existing content, and the need to explicitly import new release content before changes are seen. This can't completely replace revision -- errors and bugs discovered post-release still need to be fixed by revision -- but it can dramatically reduce the frequency.
Two main items on the path to making released ontologies more stable:
(1) Rigorous testing and evaluation, against well-specified requirements, before release. This must be addressed by the tests, test materials, and evaluation process in development.
(2) Small and stability-optimized ontology modules. The current factoring of the FIBO ontologies is not optimized for stability. In fact, it assumes the acceptability of regular revisions to released products. If such revision is to be minimized, some refactoring will be necessary.
InterbankOfferRate is a type of InterbankRate (and e.g. LIBOR is a kind of Interbank Offer Rate). Add this to the now renamed class that used to be InterbankOfferRate.
Also add others as identified, including InterbankBidRate and any others which are publicly quoted somewhere.
Change of name to this ontology.
Consequent change of namespace.
Namespace abbreviation changes to /…/ (to be determined)
(OR this may retain the same namespace)
This is to be removed. Other changes identifies in these Issue reports make this redundant: MarketBaseRate to be direct child of new Measure concept in analytics ontology; Volatility and (local) Spread to be direct children of StatisticalMeasure in Analytic ontology.
Add “Method” as a class, and add a property to the most general type of quoted index/rate, relating it to the method by which it is determined. Add sub-classes of “Method” as identified in other issues around specific types of rate and index. Some of the properties given for those should then be properties of those Method sub-classes.
This will to some extent be a “Black box” for many of these.
-- Is it clear enough to all contributors what each folder contains?
-- Is it clear enough to all contributors where various types of documents can be found?
-- Is it clear enough to all contributors where various types of documents should be put?
-- Are there any major gaps (Are there whole type of files such that they should be in the repository, but it isn't clear where they go)?
Things can still be changed after initial set-up, but we want to be reasonably sure that the initial set-up is reasonably clear and complete, so that all contributors can immediately begin adding materials they hold, with minimum confusion about where things go.
If included FedFundsRate should also be remodeled as an Individual
I'm going to spend a bit of time today gathering our GitHub-related process refinements so far into one doc of some kind, and noting things we need to decide or find out.
I will add that document to the repository itself, under some obvious name, to make easily findable for team use and collaborative updating.
Note that the repository has a new name: FIBO is now called "FIBO-Development".
This has the two EA files: Sparx EAP file, and UML XMI 2.4.1 (also ZIP).
These are in a place in the "Source Models" place in the folder structure.
@DennisWisnosky cc.
Raised by PR as: "I could not find definition for “parameter” on its own and the term is used in the definition of many other concepts. "
Proposed changes:
Change Parameter to Measure; move Measure to the new Math ontology (see separate Issue), and give it a suitably sourced definition.
Review definitions of other concepts and change references from Parameter to Measure in those.
In my GitHub repositories there is a repository for the code, scripts, and document templates for the FIBO Profile. That profile/plugin enhances baseline VOM to give the FIBO models a few in-situ tables and a reporting template for the generation of the FIBO ODM BE profile specification.
https://github.com/lonniev/com.nomagic.cameo.partners.omg.fibo.plugins.derivedproperties
I recommend that the FIBO team migrate that repository to this GitHub community out of my personal area.
Add a class called Market. Add a relationship property to this, from the most general type of rate / index.
Include relationship to “Venue” and “place” as properties of Market (these are all in the SR / BCO model under Securities Common).
This is to some extent a black box. More detail may be added after conversion of Securities Common, and with addition of market convention to that model.
This requirement applies specifically to interest rates and Fx. Economic indices already refer to Economy, which is comparable but different. Use a similar model pattern to that used for Economy.
See BoE definition for Spot rate. Settlement is a market convention and “2” is an example of such a convention for the London market.
See also Bank of England definition:
"The data represent indicative middle market (mean of spot buying and selling) rates as observed by the Bank's Foreign Exchange Desk in the London interbank market around 4pm. A monthly working day average is published. They are not 'official' rates and are no more authoritative than rates provided by any commercial bank operating in the London market. Spot rates are applicable to deals executed for settlement two working days later."
Previously we only used this metadata to identify sources outside of the EDM Council. Going forward we should assert when a definition was the result of an EDM Council SME review so we can weight this against other sources (compared for example with a draft definition made up by MB before the SME reviews).
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
