FIBO CONTENT TEAM Securities Equities Agenda 2 Where
FIBO CONTENT TEAM Securities & Equities
Agenda 2 Where we are v v Financial Business and Commerce (FBC) draft specification materials (posted to the wiki) -https: //wiki. edmcouncil. org/display/FBC/Draft+FBC+Specifi cation+Materials Revisions to the site include all recent presentations, status of the ontologies in Git. Hub, draft versions of the specification (bottom of the page) A few comments have been posted there and on related pages More review is needed … Summary of the specification(s) Open Action Item review Homework discussion Walkthrough of the current draft specification Homework reminders
Recap of last few meetings 3 Participants included the following organizations: • • • • Bloomberg Citi Credit Suisse (new, joining as time permits) Deutsche Bank Fidelity Global LEI Foundation / Tahoe Blue Ltd Goldman Sachs Mphasis No. Magic Nordea State Street Thematix Partners Wells Fargo
FBC Contents – Reminder 4 FIBO Financial Business and Commerce (FBC) common modules/ontologies identified to date: v v Financial Instruments – moved from SEC to FBC Functional Entities § § § § v Products and Services • • v Financial. Services. Entities (most content is new, includes legacy) Markets (moved from legacy) Registration Authorities (new, based on ISO 11179) Regulatory Agencies (mostly new, partially based on ISO 11179) Business Registries (new, extends registration authorities, to support definition of legal entities per our examples) USJurisdiction. Financial. Services. Entities (new, extends Financial. Services. Entities, etc. ) USJurisdiction. Regulatory. Agencies (new, extends Regulatory Agencies, Registration Authorities, etc. ) Financial Products and Services (high-level, very small now, moved to FND for the most part) Clients and Accounts (high-level, most content from legacy) Goal is still to keep this as small as possible and produce an RFC for Cambridge (September) – delayed to incorporate relationships between regulators and services (high-level, but with test cases)
FBC Contents – Additions to FND 5 New ontologies required by FBC, but are more appropriate for Foundations (FND): v Arrangements Module – Ø v Quantities Module – Ø v v Classification Schemes, to use in classifying financial instruments based on ISO 10962, for example (available in Git. Hub) Quantities. And. Units – to support measurement units needed for commodities, among other requirements (now renamed and moved, available in Git. Hub) Accounting Module – Ø Currency. Representation – the primary ontology representing ISO 4127 Ø ISO 4127 -Currency. Codes – individuals representing the currencies and codes defined in ISO 4127 (available in Git. Hub, now uses LCC Country Codes) Ø Business. Centers – individuals representing the business centers defined in Fp. ML (stay tuned) New Products and Services Module – Ø Products. And. Services – moved almost intact from FBC, will be available in Git. Hub tomorrow Ø Payments. And. Schedules – moved intact from FBC, will be available in Git. Hub
FBC Contents – New Languages, Countries, and Codes (LCC) Specification 6 v v Languages Module – Ø Language. Representation – the primary ontology representing ISO 639 (available in Git. Hub, in “pink” LCC) Ø ISO 639 -1 -Language. Codes – individuals representing the languages and codes defined in ISO 639 -1 (available in Git. Hub, in “pink” LCC) Ø ISO 639 -2 -Language. Codes – individuals representing the additional languages and codes defined in ISO 639 -2 (available in Git. Hub , in “pink” LCC) Countries Module – Ø Country. Representation – the primary ontology representing ISO 3166 (available in Git. Hub, in “pink” LCC) Ø ISO 3166 -1 -Country. Codes – individuals representing the countries and codes defined in ISO 3166 -1 (available in Git. Hub, moving to LCC this week) Ø ISO 3166 -2 -Subdivision. Codes – individuals representing country subdivisions and their codes defined in ISO 3166 -2 (in work)
Outstanding Actions / Issues 7 Actions from prior meetings have been noted on the wiki – see https: //wiki. edmcouncil. org/display/FBC/Meeting+notes v v v Refactoring of Products and Services ontologies to move them to FND from FBC – largely complete (new FND ontologies are available, remaining revisions to FBC to do) Reconciliation between the changes in BE (David Newman et al) and FBC – Elisa will create a list of the elements that FBC depends on so that the BE team can be aware (still to do) and will assist in reconciliation Gareth – investigating EU Regulatory Agencies, Repositories/Registries, and EUspecific individuals (in work) MB to revisit his recommendations and suggest a better parent [for License]; by default this would be moved to Legal document – completed this morning Need a list of definitive, high level services we can use to differentiate these kinds of entities and who regulates them. So, e. g. , if someone is regulated by a given regulation, then it means they are a bank holding company (all) July 27 th is preliminary draft spec [in OMG format] – Elisa (starting point for review available, covers most of the FND ontologies, FBC is still incomplete due to refactoring challenges)
Homework Discussion 8 Primary open issues include coverage, gap analysis for EU institutions, analysis with respect to linking regulators to the services they regulate in what jurisdiction Latest versions of the ontologies are in the EDM Council Git. Hub repository, “pink” branch – these include the latest jurisdiction-specific ontologies reflecting US institutions and regulators, revisions to the existing Functional. Entities ontologies based on recent testing Still need more test individuals for functional entities – examples posted in spreadsheets and slides – Gareth is working on EU / UK equivalents Need to review patterns wrt party roles for buyer, seller, etc. to create new pattern recommendations Use cases – v v Use case to cover the ability to identify counterparties via registered identifiers and registration authorities, such as LEI, the various Charter, Fed, and routing numbers, and EU equivalents – need the use case but individuals for testing are available for the US Use case to relate regulators to the services they regulate – need to craft this New use cases for KYC – still need to craft these Original integration use case is focused on CRM, could leverage new clients and accounts ontology, revisions to BE covering Legal. Entity are underway
Revisions to Products. And. Services (FBC-19) 9 Moved all classes but Catalog, Regulated. Commodity to a new Products. And. Services ontology in FND; deleted a number of restrictions that could be added back in FBC, but a full review is needed – refactored version (FND ontology) will be available in “pink” today Moved all of Payments. And. Schedules from FBC to FND – refactored version (FND ontology) will be available in “pink” today) Need to review the remaining ontology (currently called Clients. And. Accounts) to determine whether or not parts of it can/should be moved to FND – it has a number of dependencies on BE, however Need to complete refactoring of Financial. Services. Entities to reflect these changes
Components of the draft specification for review 10 Initial material in Section “ 0” is largely complete Front matter, including introductory content is largely complete – sections 1 through 5 (mostly dictated by the OMG standard structure Section 6, which includes significant text and details for some of the additions to FND by FBC is largely complete, lacking one ontology v v please review – new table in 6. 3 describes the notation Final ontology (Payments and Schedules) will be added this week Sections 7 and 8 are somewhat boilerplate from other specs – (not yet revised) Section 9, main content of FBC, will be added this week
Revisit: Customer/Client distinction 11 Know Your Customer (or is it Client? ), AKA KYC � � � Created to address money laundering challenges Rules vary from country to country Legislative organizations that enforce this vary across countries Basic Principle: � KYC requires that individuals and organizations that have financial interactions with a financial institution (over a certain threshold for some countries) be documented with key information, e. g. , � Name Address Date of birth (for individuals) Identification number (e. g. , Taxpayer Identification Number) Basic identification details are covered in FND/People and in BE/Legal. Persons, but should be reviewed for completeness This suggests that there needs to a singular view of customers/clients for a financial institution…?
Questions / Use Case to Support KYC (Reminder – need input) 12 What questions do we need to be able to ask to state unequivocally that we support KYC? Who is the account holder of record and what do we know about them v Who are the beneficial owners, if any of this account v What sorts of queries need to be run when certain thresholds are met or circumstances arise? What additional due diligence is required at what levels of risk/exposure? How do we manage the additional, relevant, adverse information that might be uncovered about an account holder or beneficial owner, under what circumstances, and with what safeguards?
Homework 13 Please, please do review the definitions v v v slides will be available from the EDM Council site (and emailed to participants ontologies in RDF/XML serialized OWL have been uploaded to Git. Hub and are current Source documents, such as the US regulations cited so far, are available on request Reminder: Use cases, use cases v v Use case for KYC is a good one for FBC; another is counterparty exposure, including support for LEI roll-up based on counterparty intermediaries (see FBC Financial Intermediaries ontology as a starting point) Use case template is available from Thematix, as needed (ekendall@thematix. com) We will iterate as a group, post them to the wiki on Git. Hub for discussion / revision, use them to create test cases Goal is to develop a representative set of competency questions to help scope the development, determine how granular the ontologies need to be, let us know when we can stop … at least at some level
Schedule 14 Next Few Meetings: Aug 10 th – Continued gap analysis and feedback on the draft specification discussion Aug 17 th – Final changes integrated into the ontologies, review of any additional modifications needed Aug 24 th – RFC submission due to the OMG (note that we can make additional revisions up until the Cambridge meeting, as needed, but the more complete the specification is, the better)
- Slides: 14