Semantic Compliance

Definition

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 many US banks were overwhelmed complying with the Comprehensive Capital Assessment and Review (CCAR).

  • Innovations in financial products require new and complex regulations.
  • Volume growth requires compliance automation for many businesses.
    E.g. The subject matter expert and auditor can no longer compile the reports manually in Excel.

The proverbial dog chasing its tail.

Regulators and Financial Institutions have been throwing ever more headcount  and IT systems at the problem. This scales with increasing volumes, but doesn’t manage increasing complexity.

In a great science and engineering achievement, 1960s technologies brought a man to the moon and back safely. The consensus today is that the Apollo approach would not work for the Mars mission.

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 not accessible to IT systems and experts. The Business cannot understand encoded rules and data structures.

This is the root of the problem and the reason that CCAR programs had hundreds of people mapping and documenting.

Prerequisite – the Semantic Web revolution

Most of todays Web 2.0 content is only for human consumption. We browse information in HTML pages, PDF and MS-Office documents.

In 2001 Sir Berners-Lee proposed a new Web of open standard documents that is meaningful to computers as well. 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:

Ontology graph: Blackrock manages iShares ETF triple

Tom Gruber defined ontology for IT as a specification of a conceptualization. The Ontology Web Language (OWL), a W3C standard is an extension of RDF that defines class restrictions and axioms.

OWL goes way beyond the capabilities of XSD/XBRL, data and object model. In particular:

XSD and XBRL only provide a syntax for messages and business reports. OWL is a formal language (just like ANSI SQL, Java, C++). Thus it has the rigor that the current information exchange standard are lacking.

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 with business rules.
    E.g. a registered Investment Advisor must have its form ADV processed and approved by the SEC.
  • Defined Classes specify conditions for resources to be subsumed.
    E.g. We define a class for all Private Funds exempt from SEC registration. If anything this would be like a View in the relational database.

As data modelers, we used to write up restriction and business rules in the entity definitions. Hopefully downstream developers will read end encode correctly and nothing will be Lost in Translation. The modeling revolution is that these semantics now become part of the model.

Model transformation 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 discover relationships, restrictions, business rules later and rework.

All this is already in production in Bio/Medical industries.

  • Academic research, test results, patient data exchanged in RDF, rather than XML/XSD.
  • National Center for Biomedical Ontology (NCBO) portal alone 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 a triple: Requirements, Data, Schema, Metadata, Mapping, Lineage, Rules and Conditions.

Once all compliance data resides within the Triple Store, we have complete transparency and Interoperability. The end of 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 to the left and right.

Semantic architecture: regulatory agents and ontology

The solid arrow is a direct import. E.g. 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. E.g. 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 Code of Federal Regulations (CFR) from the Government Publishing Office. Triples tie the CFR/USC paragraph to implementing ontology classes. This puts an end to endless, faulty, and obsolete Excel mapping spreadsheets.

Data Management

Conventional data integration uses Extract, Transform and Load (ETL) to move data from source into a staging area and then into the target compliance data warehouse.

Semantic ETL – conceptual data integration model

Semantic ETL and data integration follows the same blueprint.The difference is that the Staging Area is in RDF/OWL. This constitutes two steps:

  1. Extract the Source data, transform 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.
  2. 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 requirement to FinRegOnt classes, to Staging and all the way to 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 instance or database.

Jayzed’s presented details at he 2017 FIBO Data Management conference in Atlanta: The XBRL Call Report (FFIEC 031) in FIBO (PowerPoint).

Business Rules and Processing

Semantic Compliance makes extensive use of 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 evaluate complex regulatory requirements in a hierarchy of defined class building blocks.

Semantic Compliance

Jayzed uses the term Legal Reasoning as thinking process by which regulators decide actual compliance cases. The Fund Ontology uses  the Investment Advisor Act as an example:

  1. Issue
    Must firm xyz register as an investment adviser with the Securities & Exchange Commission?
  2. 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 United States Code, Title 15 § 80b–2 – Definitions [of Investment Adviser]
  3. Facts (FIBO)
    The relevant facts about the firm, services, managed companies, clients, assets under management are asserted in the ontology.
  4. Analysis
    The semantic Reasoner or inference engine subsumes firms to be a member of the defined classes based on the asserted facts.
  5. 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 drill-down to details of requirement to register 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 submission and dissemination to the public.

  • Code of Federal Regulations published in RDF/OWL in addition to today’s PDF and XML.
    SEC, FED, FFIEC should set the standard – not Jayzed Data Models.
  • RDF forms alongside and ultimately replacing current XML/XBRL.
    Firms submit in RDF, which the regulator directly load into the Triple Store.
  • Information like Call Reports, IAPD available to the public in Semantic Endpoints. This allows investors, bank, 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

Same 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 from reported 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 and tools; technologies that have 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!