Semantic Compliance® is an ontological approach to regulatory reporting and oversight, using W3C standard extensions to the Web for specification and design and semantic web technologies for implementation.
Jayzed Data Models provides Semantic Compliance education, training, design, and program advice to Regulators and Financial Institutions.
Current State
Every 10 years, the regulatory burden doubles in volume and complexity.
Chasing my tail! (Animaatjes, Holland)
When Jayzed designed Basel 2 (credit & market risk) data models and architecture for global banks in 2003, the programs were still manageable with conventional approaches and technology. Ten years later, however, many US banks were overwhelmed by the Comprehensive Capital Assessment and Review (CCAR).
Innovations in financial products require new and complex regulations.
Volume growth requires compliance automation for many businesses. For example, the subject matter expert and auditor can no longer compile the reports manually in Excel.
The proverbial dog chasing its tail.
Problem
Consolidated Life New York offices, 1960. (Jack Lemon in Billy Wilder’s “The Apartment”, MGM)
The conventional approach to compliance has a translation problem. Namely:
Numerous heterogeneous systems require mappings and transformations.
Regulations and specifications formulated in natural language are inaccessible to IT systems and experts, and business users cannot understand encoded rules and data structures.
This is the root of the problem and why CCAR programs had hundreds of people mapping and documenting.
Prerequisite – the Semantic Web revolution
Most of today’s Web 2.0 content is only for human consumption. We browse information in HTML pages, PDFs, and MS Office documents.
In 2001, Sir Berners-Lee proposed a new Web of open standard documents that is also meaningful to computers. The World Wide Web Consortium (W3C) has since released many open standards that facilitate his vision, most foundationally the Resource Description Framework (RDF). In RDF, everything is a triple of subject-predicate-object:
Tom Gruber defined ontology for IT as a specification of a conceptualization. The Ontology Web Language (OWL), a W3C standard, is an RDF extension defining class restrictions and axioms.
OWL goes way beyond the capabilities of XSD/XBRL, data, and object models. In particular:
XSD and XBRL only provide a syntax for messages and business reports. OWL is a formal language (just like ANSI SQL, Java, and C++). Thus, it has the rigor that the current information exchange standards lack.
OWL can express all constructs a modeler uses in a Logical Data Model (LDM) and much more:
The Ontology modeler can specify property (= LDM attribute and relationship) hierarchies and cardinalities.
Primitive Classes (= entities) can be restricted by business rules. For example, a registered Investment Advisor must have their form ADV processed and approved by the SEC.
Defined Classes specify conditions for resources to be subsumed. For example, we define a class for all Private Funds exempt from SEC registration. This would be like a View in the relational database.
As data modelers, we used to write restrictions and business rules in the entity definitions. Hopefully, downstream developers will read and encode the end result correctly, and nothing will be Lost in Translation. The modeling revolution is that these semantics now become part of the model.
Model transformations are available to derive LDM, Taxonomy, and Dictionaries out of OWL.
Cascade of Ontology, Logical Data, Taxonomy, and Dictionary model.
The point is that architects should consider all semantics rather than starting at the bottom and discovering relationships, restrictions, and business rules later and rework.
All this is already in production in the Bio/Medical industries.
Academic research, test results, and patient data are exchanged in RDF rather than XML/XSD.
The National Center for Biomedical Ontology (NCBO) portal lists 530 ontologies with millions of classes.
Triple Stores, the databases for RDF approach RDBMS performance.
The public can query Web Semantic Endpoints in SPARQL, the semantic world equivalent to conventional SQL.
It is time for Finance to catch up!
The Semantic Compliance solution
In RDF/OWL, everything is triple: requirements, Data, Schema, Metadata, Mapping, Lineage, Rules, and Conditions.
We will have complete transparency and interoperability once all compliance data resides within the Triple Store. Eliminating import/export and translations simplifies architecture, data management, and processing.
Architecture
The reference data integration diagram for Financial Regulation Ontologies is at the center, and sample regulators with current XSD and XBRL specifications are on the left and right.
Semantic architecture: regulatory agents and ontology
The solid arrow is a direct import. For example, FinRegOnt has an OWL import for financial industry business ontology (FIBO). Eurofiling imports XBRL schema definition. The dotted arrows indicate a schema transformation and load of data. For BankOnt, the Banking Ontology has reverse-engineered the Federal Financial Institutions Examination Council (FFIEC) Call report XBRL schema and loads XBRL instances. Likewise, Fund and Hedge Fund Ontology import the Securities and Exchange Commission (SEC) forms ADV for investment advisors and PF for private funds.
Semantic Compliance is not just about forms and reports, however. Having the requirements within the ontology mapped to a schema and to rules is just as important. We load the text of the United States Code (USC) from the Office of the Law Revision Council and the Code of Federal Regulations (CFR) from the Government Publishing Office. Triples ties the CFR/USC paragraph to implementing ontology classes. This ends with endless, faulty, and obsolete Excel mapping spreadsheets.
Data Management
Conventional data integration uses Extract, Transform, and Load (ETL) to move data from the source into a staging area and the target compliance data warehouse.
Semantic ETL – conceptual data integration model
Semantic ETL and data integration follow the same blueprint. The difference is that the Staging Area is in RDF/OWL. This constitutes two steps:
Extract the Source data, transform it, and load it into the RDF/OWL staging area. The staging schema is a one-to-one representation of the XSD/XBRL or database source. The import populates staging classes with data. This step is dumb and tool-based.
Extract triples from Staging and transform the information into our target ontology. This step involves business rules, matching, and data integration. We use Semantic Technologies for mapping and ETL. (TopQuadrant‘s SPINMap a W3C member submission)
The mapping and transformation rules are stored within the ontology. We can query from CFR data requirements to FinRegOnt classes, Staging, and the data source.
The inference engine attaches lineage triples to the target instance. We can query compliance data records to their ultimate source record in XML/XBRL instances or databases.
Jayzed presented details at the 2017 FIBO Data Management conference in Atlanta: The XBRL Call Report (FFIEC 031) in FIBO (PowerPoint).
Business Rules and Processing
Semantic Compliance extensively uses Defined Classes to express regulatory conditions. Although in a different notation, the expressiveness of OWL matches conditions in the Decision Model and Notation, an Object Management Group standard.
Ontology editors and RDF databases have an Inference Engine (a.k.a. Reasoner) to evaluate Defined Class restrictions and subsume matching instances. Class restrictions can refer to other Defined Classes. Thus, we can model and assess complex regulatory requirements in a hierarchy of defined class building blocks.
Semantic Compliance
Jayzed uses Legal Reasoning as a thinking process by which regulators decide compliance cases. The Fund Ontology uses the Investment Advisor Act as an example:
Issue Must firm XYZ register as an investment adviser with the Securities & Exchange Commission?
Rules (LKIF) The text of the law and regulations are stored in FRO. An ontology module encodes the rules in a hierarchy of defined classes. The screenshot below shows the rule class for the United States Code, Title 15 § 80b–2 – Definitions [of Investment Adviser]
Facts (FIBO) The ontology asserts the relevant facts about the firm, its services, managed companies, clients, and assets under management.
Analysis Based on the asserted facts, the semantic Reasoner or inference engine subsumes firms as members of the defined classes.
Conclusion The firms have a new property “regulated as” inferred. For example firm xyz is regulated as required to register (or excluded as a family office, exempted as a commodity trading adviser, or prohibited as a small state regulated adviser).
Legal Reasoning example – USC s80b Required to register
Inferred membership of the defined classes enables drilling down to details of the registration requirement or the applied exclusion, exemption, and prohibition. For example, the fictional Malboro [VT] Charity Advisers firm only advises charities and becomes an inferred member of class Exempted_Ex_USC_s80b_3_b_4_A.
Vision and Roadmap for Regulators and Supervisory Agencies.
The end state applies Semantic Compliance to public rulemaking, forms and reports, firm submissions, and dissemination to the public.
Code of Federal Regulations published in RDF/OWL in addition to today’s PDF and XML. SEC, FED, and FFIEC should set the standard – not Jayzed Data Models.
RDF forms alongside and ultimately replaces current XML/XBRL. Firms submit in RDF, which the regulator directly loads into the Triple Store.
Information like Call Reports and IAPD is available to the public in Semantic Endpoints. This allows investors, banks, and insurance customers to join the data with other government and public endpoints.
Regulator’s roadmap to Semantic Compliance
This may take 10 years.
Vision and Roadmap for Financial Institutions
US banks and investment funds already have semantic web programs and are actively involved in FIBO development.
The end state is complete transparency, accuracy, and efficiency in reporting financial information, its compilation, lineage, and ultimate sources.
Financial Institution’s Roadmap to Semantic Compliance
The Semantic Endpoint extends transparency and accessibility to the institution’s clients.
Conclusion
The ever-increasing compliance burden overwhelms Financial Institutions and their regulators. The complexity is no longer manageable with conventional approaches.
The Semantic Web revolution provides more powerful methodologies, tools, and technologies with proven performance and scalability in other industries.
Semantic Compliance applies the ontological approach to regulatory compliance. The uniform representation of requirements, data, and rules simplifies architecture, data management, and processing.
Everything within the ontology – everything is a triple!