Explanation of Proofs of Regulatory (Non-)ComplianceUsing Semantic Vocabularies

Sagar Sunkle, Deepali kholkar, and Vinay Kulkarni

Tata Consultancy Services Research, India

Regulatory Complianceo 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-) Complianceo Increasing demand to prove and explain (non-)compliance in a way tailored to specific

stakeholderso 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

Use existing compliance engine- We use DR-Prologo Compliance engine based on modal defeasible logico Possible to access diagnostic information from Prolog trace- prior work by others exists on

proof generation using DR-Prolog

Domain-specific complianceo Our engagements reveal that stakeholder-specific proof explanations are in demando Difficult for business/operational stakeholders to interpret technical proofso Close to natural language explanation deemed a starting point to make formal proofs

relevant

Semantics of Business Vocabulary and Ruleso 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

Manual Specification

Implementation Technology in boldface

Specification Language/format in Italics

Legal Text Business

Process ModelsVocabulary

EMF Ecore SBVR Editor

Assurance Workbench TCS

Rules Facts

OMG SBVR Metamodel

BPMN 2.0

DR-PrologTuProlog

DR-PrologTuProlog

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

Tailoring Proofs using Metainterpreter

Defeasible Metaprogramo 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 abstractiono The metaprogram and problem theory is meta-interpreted to reveal procedure box for given

queryo Predicate invocation type- one of CALL, EXIT, FAIL, REDOo To obtain relevant rules and facts in a given successful and failed procedure, treat the box

differently

Accessing the Trace

Meta-interpreter produces trace that minimally contains three pieces of information

1. Depth of predicate invocation2. Invocation type which is one of CALL, EXIT,FAIL, and REDO3. Current predicate being processed

Example Trace0’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/invokedo EXIT= successfully returned from o FAIL= completely failedo REDO= failed but backtracked

Processing the Procedure Box Abstraction

Successful Procedureo We are interested in CALL EXIT pairs as

shown on lefto Remove successive CALL FAIL pairs

indicating failed invocationso Failed invocations may occur at various

depths, so recursively look for them and remove them

Failed Procedureo We are interested in CALL FAIL pairs as

shown on righto Keep only successive CALL FAIL pairs and

remove the resto No need to recurse

Building the Vocabularies- I

Business vocabularyo 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 characteristicso Categorical concepts with specific details as

characteristics

Building the Vocabularies- II

Body of guidanceo Logical formulations based on logical

operations

Terminological dictionaryo 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 processeso 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

Manual Specification

Implementation Technology in boldface

Specification Language/format in Italics

Legal Text Business

Process ModelsVocabulary

EMF Ecore SBVR Editor

Assurance Workbench TCS

Rules Facts

OMG SBVR Metamodel

BPMN 2.0

DR-PrologTuProlog

DR-PrologTuProlog

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

Reserve Bank of India’sKnow Your Customer regulations for a salaried employee at a private employer opening an account at an Indian Bank

An example of banking domain regulation

Success Facts for Client_ID 17[fact(client_data(17,ind,pse)).,

fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCorpCertificate,pse_kyc_document_set)).]

Success Rule r3

Client_ID 17 fulfills all Obligatory requisites. The processed trace shows facts inthe successful invocation of rule r3.

Success Facts for Client_ID 17[fact(client_data(17,ind,pse)).,

fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCorpCertificate,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 aredefined in the business context and also in the meaning and representation vocabulary.

Success Facts for Client_ID 17[fact(client_data(17,ind,pse)).,

fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCorpCertificate,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.

Success Facts for Client_ID 17[fact(client_data(17,ind,pse)).,

fact(pse_data(17,approvedCorporate))., fact(pse_KYC_document_data(17,acceptApprovedCorpCertificate,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.

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 vocabularieso Type-safe SQL-like API for querying any data storeo 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 _ _.

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

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 explanationo Stakeholder-specific interpretations of business context vocabulary can be

represented in meaning and representation vocabularies and terminological dictionaries

In near future- Elaborating business/legal reasonso Ideally reasons for enterprises actions should be recorded in the explanationso For this, business/legal goals need to be modeled separately and related with

the concepts in the business context vocabulary

Questions?

Thank you all!! I can be reached at sagar.sunkle@tcs.com