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 engine, 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.

1. Explanation of Proofs of Regulatory (Non-)Compliance
Using Semantic Vocabularies
Sagar Sunkle, Deepali kholkar, and Vinay Kulkarni
Tata Consultancy Services Research, India

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.  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.  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), specific instance, description, and its
ID [From the business context and meaning and representation vocabulary]
Constructing Natural Language Explanation- I
As per rule _, _. For current _that is _; _. Therefore compliance
is achieved for current _ _.

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. 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. Questions?
Thank you all!! I can be reached at sagar.sunkle@tcs.com