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+Specification +Materials Challenges include uploading the latest version, which is more than 10 MB. Otherwise, revisions to the site include all recent presentations, status of the ontologies in Git. Hub, draft versions of the specification (bottom of the page) Few comments (see discussion, in a few slides) this week 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 Functional Entities § § § § § v Financial. Services. Entities Markets Registration Authorities Regulatory Agencies Business Registries USJurisdiction/USFinancial. Services. Entities USJurisdiction/USRegulatory. Agencies (see discussion) EUJurisdiction/EURegulatory. Agencies – waiting on input, but must include ECB, if nothing else EUJurisdiction/EUFinancial. Services. Entities – waiting on input, but must include Central Counterparty and the ESMA registry Products and Services • • Financial Products and Services Clients and Accounts
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 Ø Ø Currency. Amount – revisions to support Currency Codes ISO 4127 -Currency. Codes – individuals representing the currencies and codes defined in ISO 4127 Business. Centers – individuals representing the business centers defined in Fp. ML (stay tuned) Products and Services Module – Ø Ø v Quantities. And. Units – to support measurement units needed for commodities, among other requirements Accounting Module – Ø v Classification Schemes, to use in classifying financial instruments based on ISO 10962, for example Products. And. Services Payments. And. Schedules Law Module – Ø Revisions to Legal. Capacity to cover licensing
FBC Contents – New Languages, Countries, and Codes (LCC) Specification 6 v v Languages Module – Ø Language. Representation – the primary ontology representing ISO 639 Ø ISO 639 -1 -Language. Codes – individuals representing the languages and codes defined in ISO 639 -1 Ø ISO 639 -2 -Language. Codes – individuals representing the additional languages and codes defined in ISO 639 -2 Countries Module – Ø Country. Representation – the primary ontology representing ISO 3166 Ø ISO 3166 -1 -Country. Codes – individuals representing the countries and codes defined in ISO 3166 -1 Ø ISO 3166 -2 -Subdivision. Codes – individuals representing country subdivisions and their codes defined in ISO 3166 -2 (all of North America is available in Git. Hub, need to determine what other coverage is required for an initial RFC)
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 Refactoring of Products and Services ontologies to move them to FND from FBC – complete 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 EU-specific individuals (in work) 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)
Discussion of Definitions 8 Suggested revised definition for Financial Instruments – see wiki comments (Jeff Braswell) Need to rethink the definition of Depository. Institution, which is too narrow and too US-specific (may mean that a Central. Bank can’t be a Depository. Institution, which is wrong – the Fed acts as a depository institution for US banks, as one example)
Homework Discussion 9 Primary open issues include coverage, gap analysis for EU institutions, analysis with respect to linking regulators to the services they regulate in what jurisdiction Still need more test individuals for functional entities – examples posted in spreadsheets and slides – Gareth is working on EU / UK equivalents Use cases (section 7) – 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
Components of the draft specification for review 10 Complete through section 9, but use cases in 7 need to be augmented with more text (MB) Section 10, Jurisdiction specific material – v Specification document includes financial services entities for the US, v Git. Hub includes that and the US regulatory authorities, v challenges in uploading the revised specification due to 10 MB limit
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, including LCC 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 17 th – Final changes integrated into the ontologies, review of any additional modifications needed (today) 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