Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Solving Semantic Disparity and Explanation Problems in Regulatory Compliance

315 Aufrufe

Veröffentlicht am

Modern enterprises increasingly face the challenge of keeping pace with regulatory compliances. Semantic disparity between regulation texts, their interpretations, and operational specifics of enterprise often leads enterprises to situations where it becomes difficult for them to establish what compliance means, how they are supposed to affect it in the operational practices, and how to prove that they comply when asked for explanations of (non-)compliance. We take a step toward reducing the semantic disparity by using semantic vocabularies to map regulations with available operational details of enterprise and utilize them in enacting compliance. We also propose to provide explanations of proofs of (non-)compliance. We report our ongoing work in this regard using the design science research (DSR) paradigm. Initial iterations of design cycle from DSR have been useful to us in identifying and matching stakeholder-specific goals in solving these problems.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Solving Semantic Disparity and Explanation Problems in Regulatory Compliance

  1. 1. Solving Semantic Disparity and Explanation Problems in Regulatory Compliance A Research-In-Progress Report with Design Science Research Perspective Sagar Sunkle, Deepali Kholkar, and Vinay Kulkarni Tata Consultancy Services Research
  2. 2. Agenda ∾ Research method ∾ Motivation o Regulatory compliance o Need for semantic similarity between regulations and operational details of enterprise ∾ Mapping regulatory and operational concepts using Semantics of Business Vocabulary and Rules (SBVR) ∾ Ongoing and future work ∾ Questions
  3. 3. Research Method- Design Science Research ∾ Focus on artifacts o Bestow tangible form to stakeholders’ expectations (not yet requirements) o Utility in the operating context as the criteria o Can be constructs, models, methods, and instantiations (proof of concept) ∾ Iterative process o Investigate whether problem is solved, design and validate artifacts, implement and evaluate artifacts o Continue till expectations are met ∾ Meaningful for practical problems- taken to mean problems observed in practice.
  4. 4. Motivation- Regulatory Compliance ∾ Increasing spend on compliance (estimated in billions of $, in US alone at $15 Billion, slated to increase 5 times more by 2018) ∾ Demand for governance, risk management, and compliance (GRC) in US is most high but Canada, Japan, India, Australia, South Africa, and members of EU have started enforcing various regulations for some time now ∾ Non-compliance is penalized severely ∾ Main challenges o Non-compliance identification + remediation + proof explanation o Regulatory change management with risk adjusted decision making
  5. 5. Regula on Text (Semi-) Formal Representa on Interpreta ons Business Process Models Enterprise DataStakeholders Formal Approaches GRC Solu ons Missing Conceptual Mapping Taxonomies 1 2 Problem Investigation (with Current State of the Art and Practice) • Expectations: 1. To make the process of interpretations of regulation text easier for such stakeholders as enterprise legal advisors, compliance experts, CxO level business stakeholders, and operational managers 2. To enable enterprises to leverage formalisms offered by academic research • But, • Missing conceptual/terminological mapping to tell where in the business process a rule from the regulation becomes applicable • In contrast, GRC solutions are document/artefact-oriented and rely on enterprise data to prove compliance to regulations
  6. 6. Regula on Text Formal Representa on Business Process Models Enterprise Data VocabularyReg Terminological_Dic onaryProcess Facet Dependencies Conceptual Data Model Conceptual Mapping 1 2 3a 4 5 3b Artifact Design Existing artifacts • Merely taxonomies are not sufficient if features of GRC and formal techniques are to be integrated
  7. 7. Regula on Text Formal Representa on Business Process Models Enterprise Data VocabularyReg Terminological_Dic onaryProcess Facet Dependencies Conceptual Data Model Conceptual Mapping 1 2 3a 4 5 3b Artifact Validation Existing artifacts • Merely taxonomies are not sufficient if features of GRC and formal techniques are to be integrated • Need to express meaning of concepts- SBVR provides a semantic model of formal terminology + helps in disambiguation by the use of semantic communities • From legal text; [step <1>] focusing on aspects of interest called facets, [step <2>] model the vocabulary of regulations. From operational details [step <3a/3b>] represent them in terminological dictionary to [step <4>] conceptually map them to regulations and [step <5>] check compliance. Method steps
  8. 8. Exemplar Regulation
  9. 9. Business Domain [Banking] Regulatory Domain [Know Your Customer] Facets of regulations  Business Vocabulary Semantic communities- Banking industry, Reserve Bank of India’s Know Your Customer, Bank_A- each containing smaller bodies of meanings  Meaning and Representation Vocabulary Noun and verb concepts- customer noun concept, has characteristic CustomerType, conditions as verb concepts in terms of characteristic = value  Business Rules Vocabulary Each rule is defined as an element of guidance embedding a logical formulation. Obligations are denoted by obligationFormulation elements  Terminological dictionary Map terms used in the enterprise business process as representations of concepts in the regulations body of concepts Enterprise Business Processes/D ata
  10. 10. 11
  11. 11. From Facets to Vocabulary to Data Model
  12. 12. ∾ Implementation o Using SBVR consumable Metamodel from OMG o Business process modeled using Assurance Work Bench TCS o Compliance demonstrated using DR-Prolog compliance engine in tuProlog. ∾ Evaluation With partner stakeholders o Approach sounds better than taxonomies, but maps regulation text directly to operational details without interpretation o Mappings in Terminological Dictionary by consultation with domain experts; should use semantic similarity measures instead o Model transformation for going from facet dependencies to DR- Prolog to ensure consistency of specification Artifact Implementation and Evaluation
  13. 13. Nested DSR and Further Investigations Relevance Design Rigor Cost of Compliance Industry GRC and Academic Process Compliance Checking SBVR based Mapping 1 Relevance Design Rigor Natural Language Explanation of Proofs of Compliance- at RuleML’15 Relevance Design Rigor 2 3 Change Sensitive Compliance- at BMSD’15
  14. 14. Please feel free to reach out to me at sagar.sunkle@tcs.com Questions?

×