Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Explanation of Proofs of Regulatory (Non-)Compliance
Using Semantic Vocabularies
Sagar Sunkle, Deepali kholkar, and Vinay ...
 Regulatory Compliance
o Increasing spend on compliance in Billions of $
o Demand for governance, risk, and compliance (G...
 Use existing compliance engine- We use DR-Prolog
o Compliance engine based on modal defeasible logic
o Possible to acces...
Manual
Specification
Implementation Technology in
boldface
Specification Language/format in
Italics
Legal Text
Business
Pr...
Tailoring Proofs using Metainterpreter
 Defeasible Metaprogram
o A logic metaprogram simulates the proof theory of modal ...
Accessing the Trace
 Meta-interpreter produces trace that minimally contains three pieces of
information
1. Depth of pred...
Processing the Procedure Box Abstraction
 Successful Procedure
o We are interested in CALL EXIT pairs as
shown on left
o ...
Building the Vocabularies- I
Business vocabulary
o Semantic community and sub-
communities owning the regulation and to
wh...
Building the Vocabularies- II
Body of guidance
o Logical formulations based on logical
operations
Terminological dictionar...
Manual
Specification
Implementation Technology in
boldface
Specification Language/format in
Italics
Legal Text
Business
Pr...
Reserve Bank of India’s
Know Your Customer
regulations for a salaried
employee at a private
employer opening an
account at...
Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_docum...
Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_docum...
Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_docum...
Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_docum...
 SBVR model is in XML which needs to be queried to project values of requisite
concepts in the explanation
 We use Apach...
 This gives a natural language statement like the following-
 Similar statement can be constructed whenever obligations ...
Summary and Future Work
 Summary
o Using vocabularies of legal and operational concepts and existing compliance
engine, w...
Questions?
Thank you all!! I can be reached at sagar.sunkle@tcs.com
Upcoming SlideShare
Loading in …5
×

Explanation of Proofs of Regulatory (Non-)Compliance Using Semantic Vocabularies

277 views

Published on

With recent regulatory advances, modern enterprises have to not only comply with regulations but have to be prepared to provide explanation of proof of (non-)compliance. On top of compliance checking, this necessitates modeling concepts from regulations and enterprise operations so that stakeholder-specific and close to natural language explanations could be generated. We take a step in this direction by using Semantics of Business Vocabulary and Rules to model and map vocabularies of regulations and operations of enterprise. Using these vocabularies and leveraging proof generation abilities of an existing compliance checking technique, we show how such explanations can be created. Basic natural language explanations that we generate can be easily enriched by adding requisite domain knowledge to the vocabularies.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Explanation of Proofs of Regulatory (Non-)Compliance Using Semantic Vocabularies

  1. 1. Explanation of Proofs of Regulatory (Non-)Compliance Using Semantic Vocabularies Sagar Sunkle, Deepali kholkar, and Vinay Kulkarni Tata Consultancy Services Research, India
  2. 2.  Regulatory Compliance o Increasing spend on compliance in Billions of $ o Demand for governance, risk, and compliance (GRC) growing worldwide- • Canada, Japan, India, Australia, South Africa, and members of EU having a number of domain- and geography-specific regulations o Non-compliance is penalized severely; • Compliance difficult to achieve since it is uncertain in many cases what constitutes compliance and how it will affect the business-as-usual  Explanation of Proof of Regulatory (Non-) Compliance o Increasing demand to prove and explain (non-)compliance in a way tailored to specific stakeholders o Should be useful in regulatory negotiations as well as in fulfillment of business objectives o Requirements:  Requires access to diagnostic information in compliance checking  Relevant concepts in both regulations and operational practices need to be modeled Motivation
  3. 3.  Use existing compliance engine- We use DR-Prolog o Compliance engine based on modal defeasible logic o Possible to access diagnostic information from Prolog trace- prior work by others exists on proof generation using DR-Prolog  Domain-specific compliance o Our engagements reveal that stakeholder-specific proof explanations are in demand o Difficult for business/operational stakeholders to interpret technical proofs o Close to natural language explanation deemed a starting point to make formal proofs relevant  Semantics of Business Vocabulary and Rules o Express meaning of concepts o Two sets of concepts- legal and business o Can accommodate natural language representation/information of concepts  Tailor proofs so that only the relevant rules and facts are separated out Basics of the Approach
  4. 4. Manual Specification Implementation Technology in boldface Specification Language/format in Italics Legal Text Business Process Models Vocabulary EMF Ecore SBVR Editor Assurance Workbench TCS Rules Facts OMG SBVR Metamodel BPMN 2.0 DR-Prolog TuProlog DR-Prolog TuProlog Metainterpreter in Prolog Interpretation Trace TuProlog Java Procedure Box Abstraction in Trace Success Rules and Facts Failure Rules and Facts Natural Language Explanation Queries with Apache Metamodel API XML Representation of SBVR FreeMarker API Natural Language Templates Implementation Architecture
  5. 5. Tailoring Proofs using Metainterpreter  Defeasible Metaprogram o A logic metaprogram simulates the proof theory of modal defeasible logic and reasons over the theory • The problem theory is expressed in terms of the metaprogram predicates • The metaprogram is a Prolog program  Trace using metainterpreter- leveraging procedure box abstraction o The metaprogram and problem theory is meta-interpreted to reveal procedure box for given query o Predicate invocation type- one of CALL, EXIT, FAIL, REDO o To obtain relevant rules and facts in a given successful and failed procedure, treat the box differently
  6. 6. Accessing the Trace  Meta-interpreter produces trace that minimally contains three pieces of information 1. Depth of predicate invocation 2. Invocation type which is one of CALL, EXIT,FAIL, and REDO 3. Current predicate being processed  Example Trace 0’CALL ’defeasibly(client_account_data(17,open_account),obligation) 1’CALL ’strictly(client_account_data(17,open_account),obligation) 2’CALL ’fact(obligation(client_account_data(17,open_account))) 2’FAIL ’fact(obligation(client_account_data(17,open_account))) …  Meaning of innovation types- o CALL= predicate is entered/invoked o EXIT= successfully returned from o FAIL= completely failed o REDO= failed but backtracked
  7. 7. Processing the Procedure Box Abstraction  Successful Procedure o We are interested in CALL EXIT pairs as shown on left o Remove successive CALL FAIL pairs indicating failed invocations o Failed invocations may occur at various depths, so recursively look for them and remove them  Failed Procedure o We are interested in CALL FAIL pairs as shown on right o Keep only successive CALL FAIL pairs and remove the rest o No need to recurse
  8. 8. Building the Vocabularies- I Business vocabulary o Semantic community and sub- communities owning the regulation and to which the regulation applies o Shared understanding of an area, i.e., body of shared meanings Meanings and characteristics o Categorical concepts with specific details as characteristics
  9. 9. Building the Vocabularies- II Body of guidance o Logical formulations based on logical operations Terminological dictionary o Designations or alternate names for various concepts, definitions for concepts and natural language statements for policies stated in the regulation o capture the vocabulary used by the enterprise in its business processes Mapping rules to processes o Every verb concept in the regulation body of concepts is mapped to corresponding verb concept wording from the process terminological dictionary. o This mapping is used to look up consequent terms of rules and the corresponding process entity is treated as a placeholder for compliance implementation of the rule
  10. 10. Manual Specification Implementation Technology in boldface Specification Language/format in Italics Legal Text Business Process Models Vocabulary EMF Ecore SBVR Editor Assurance Workbench TCS Rules Facts OMG SBVR Metamodel BPMN 2.0 DR-Prolog TuProlog DR-Prolog TuProlog Metainterpreter in Prolog Interpretation Trace TuProlog Java Procedure Box Abstraction in Trace Success Rules and Facts Failure Rules and Facts Natural Language Explanation Queries with Apache Metamodel API XML Representation of SBVR FreeMarker API Natural Language Templates Revisiting Implementation Architecture
  11. 11. Reserve Bank of India’s Know Your Customer regulations for a salaried employee at a private employer opening an account at an Indian Bank An example of banking domain regulation
  12. 12. Success Facts for Client_ID 17 [ fact(client_data(17,ind,pse))., fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCor pCertificate,pse_kyc_document_set)). ] Success Rule r3 Client_ID 17 fulfills all Obligatory requisites. The processed trace shows facts in the successful invocation of rule r3.
  13. 13. Success Facts for Client_ID 17 [ fact(client_data(17,ind,pse))., fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCor pCertificate,pse_kyc_document_set)). ] Success Rule r3 <containsConcepts xsi:type="SBVR.MeaningandRepresentationVocabulary:generalconcept"> <Id>pse</Id> <representation>pse_data</representation> <characteristic>notApprovedCorporate</characteristic> <characteristic>approvedCorporate</characteristic> <moreGeneralConcept>ind</moreGeneralConcept> </containsConcepts> </includesBodyOfConcepts> <includesBodyOfConcepts Id="RBI_KYCRegulationConcepts"> Business Vocabulary with Characteristics Concept pse and its characteristics such as approvedCorporate are defined in the business context and also in the meaning and representation vocabulary.
  14. 14. Success Facts for Client_ID 17 [ fact(client_data(17,ind,pse))., fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCor pCertificate,pse_kyc_document_set)). ] Success Rule r3 <includesBodyOfGuidance Id="RBI_KYCRules"> <includesElementsOfGuidance Id="r3"> <Id>r3</Id> <isMeantBy xsi:type="SBVR.LogicalFormulationofSemanticsVocabulary:obligationformulation"> <antecedent xsi:type="SBVR.LogicalFormulationofSemanticsVocabulary:conjunction"> <logicalOperand xsi:type="SBVR.LogicalFormulationofSemanticsVocabulary:atomicformulation"> <Id>ind</Id> <isBasedOn>client_is_ind</isBasedOn> </logicalOperand> … </isMeantBy> </includesElementsOfGuidance> </includesBodyOfGuidance> Business Rules Vocabulary The rules vocabulary notes the rules and concepts involved.
  15. 15. Success Facts for Client_ID 17 [ fact(client_data(17,ind,pse))., fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCor pCertificate,pse_kyc_document_set)). ] Success Rule r3 <SBVR.VocabularyforDescribingBusinessVocabularies:ComplianceModel> <contains Id="RBI_reference"> <presentsVocabulary Id="RBI_RegulationVocabulary"/> <expressesBodyOfMeanings Id="RBI_KYCRegulation"/> <includes xsi:type="SBVR.VocabularyforDescribingBusinessVocabularies:owneddefinition"> <Id>approvedCorporate</Id> <expression>Employer_is_a_corporate_approved_by_the_bank</expression> <meaning>approvedCorporate</meaning> </includes> <includes xsi:type="SBVR.VocabularyforDescribingBusinessRules:rulestatement"><Id>r3_stmt</Id <expression>It_is_obligatory_for_bank_to_obtain_requisite_documents_Including _approved_employer_certificate_and_additionally_at_least_one_valid_ document_ from_individual_who_is_a_private_salaried_employee _in_order_to_open_account” </expression> <meaning>r3</meaning> </SBVR.VocabularyforDescribingBusinessVocabularies:ComplianceModel> Terminological Dictionary The terminological dictionary contains the natural language representation of the rule in addition to process concepts.
  16. 16.  SBVR model is in XML which needs to be queried to project values of requisite concepts in the explanation  We use Apache Metamodel to query the vocabularies o Type-safe SQL-like API for querying any data store o XML files are hierarchical and MetaModel tables are tabular, so some mapping overhead; carried out with XPath expressions  The projected results are filled into templates  This templates is filled in with o Rule ID, rule statement [From the terminological dictionary and rules vocabulary respectively], o Type of concept (in the case study, a banking customer), description, and its ID [From the business context and meaning and representation vocabulary] Constructing Natural Language Explanation- I As per rule _, _. For current individual that is _; _. Therefore compliance is achieved for current individual _.
  17. 17.  This gives a natural language statement like the following-  Similar statement can be constructed whenever obligations are violated in specific instances. Constructing Natural Language Explanation- II
  18. 18. Summary and Future Work  Summary o Using vocabularies of legal and operational concepts and existing compliance engine, we were able to construct simple natural language explanations  Ongoing- Stakeholder-specific explanations [such as business/legal stakeholders] o Currently general explanation o Stakeholder-specific interpretations of business context vocabulary can be represented in meaning and representation vocabularies and terminological dictionaries  In near future- Elaborating business/legal reasons o Ideally reasons for enterprises actions should be recorded in the explanations o For this, business/legal goals need to be modeled separately and related with the concepts in the business context vocabulary
  19. 19. Questions? Thank you all!! I can be reached at sagar.sunkle@tcs.com

×