This document discusses model-driven regulatory compliance using a case study of "Know Your Customer" banking regulations. It outlines key challenges in compliance such as semantic disparity between formal regulations and business operations, generating explanations of compliance proofs, and managing changes to regulations over time. The authors propose addressing these challenges by developing formal vocabularies of regulatory and business concepts, mapping the vocabularies to address semantic differences, and using the mapped models to reason about compliance and regulatory changes. A banking example is provided to illustrate mapping KYC regulations to customer account opening processes. The proposed approach aims to help organizations more rigorously and cost-effectively ensure ongoing regulatory compliance.

1. Model-Driven Regulatory Compliance:
A Case Study of “Know Your
Customer” Regulations
Sagar Sunkle, Deepali Kholkar, and Vinay Kulkarni
Tata Consultancy Services
Research, India

2. Compliance is adherence to policies and decisions. Policies may originate in
internal directives as well as external regulations.
 Cost of Compliance
o Increasing spend on compliance- in Billions of $ and expeceted to rise
o Several regulations across various domains
 Banking KYC [Know Your Customer], FATCA [Foreign Account Tax
Compliance Act], BASEL III [Bank Capital Adequacy and Market Liquidity]
 Mortgage CFPB [Consumer Financial Protection Bureau]
 Healthcare HIPPA [Federal Health Insurance Portability and
Accountability Act]
o Compliance is difficult to achieve
o It is uncertain in many cases what constitutes compliance
o It is not clear how it will affect the business
o It changes with time and space [geography-specific]
 Non-compliance is penalized severely
Regulatory Compliance Context

3.  Compliance checking research
o Checking whether processes comply with regulations based on given
formalism
o Siloed research in business process compliance checking, risk modeling,
process change management
Largely manual and expert-driven in practice
 Industrial Governance, Risk, and Compliance (GRC) solutions
o Based on tagging mechanisms- tag regulations to enterprise content
(using domain-specific taxonomies when available)
o Tagging itself is mostly manual, sometimes (semi-)automated
o (Non-/Semi-) formal solutions means less rigorous
• Less than 50% of enterprise content is correctly indexed
• Multiple labeling and classification errors
• Average cost of tagging an item ranges from $ 4.00 to $ 7.00
Current State of Art and Practice

4.  Semantic Disparity
o Before checking compliance, need to map regulatory concepts to
enterprise operational concepts to find out to “what” in enterprise data a
regulation is applicable to [in business processes “where” it is applicable]
o Largely ignored/implicitly assumed in research approaches, industrial
GRC solutions depend on domain experts
 Explanation of Proofs of Compliance
o An explanation which compliance officers/internal auditors and business
stakeholders can use in a legally defensible way
 Change Management for Regulations
o Regulations change over time and with geography- need to keep
operations compliant with changing regulations
o Operations may change and need to re-comply with existing regulations
Key Challenges

5. Changes in
Internal
Controls
Changed
Processes
Change
Risks
Inquiries/
Surveys
Business Process Modeling + Change Propagation
Formal Compliance Checking + Norm Change
Changes in
Regulations
and Standards
Risk Modeling + Change Risk
use
prevent,
detect,
correct,
track
associated
Identify
risks in
ensure
compliance
with
define
fulfill
enact
in
Integrating Research Silos with Conceptual
GRC Model
Vicente and da Silva: A Conceptual Model for Integrated Governance, Risk and Compliance. CAiSE 2011

6. Changes in
Internal
Controls
Changed
Processes
Change
Risks
Business Process Modeling + Change Propagation
Formal Compliance Checking + Norm Change
Changes in
Regulations and
Standards
Risk Modeling + Change Risk
ensure compliance with
fulfill
Propagate to prevent, detect,
correct, track
associated
Using Purposive Models for Integrated
Compliance

7. Changes in
Internal
Controls
Changed
Processes
Change
Risks
Business Process Modeling + Change Propagation
Formal Compliance Checking + Norm Change
Changes in
Regulations and
Standards
Risk Modeling + Change Risk
ensure compliance with
fulfill
Propagate to prevent, detect,
correct, track
associated
Formal Model of
Regulations
SBVR Models of
Regulation Concepts
Using Purposive Models for Integrated
Compliance

8. Semantic
Mapping and
Proof
Explanation
Changes in
Internal
Controls
Changed
Processes
Change
Risks
Business Process Modeling + Change Propagation
Formal Compliance Checking + Norm Change
Changes in
Regulations and
Standards
Risk Modeling + Change Risk
ensure compliance with
fulfill
Propagate to prevent, detect,
correct, track
associated
Formal Model of
Regulations
Formal Model of
Business Process
SBVR Models of
Regulation Concepts
SBVR Models of Process
Concepts
Mapping
Rule
Integration
Change Management
Using Purposive Models for Integrated
Compliance

9. Semantic
Mapping and
Proof
Explanation
Changes in
Internal
Controls
Changed
Processes
Change
Risks
Business Process Modeling + Change Propagation
Formal Compliance Checking + Norm Change
Changes in
Regulations and
Standards
Risk Modeling + Change Risk
ensure compliance with
fulfill
Propagate to prevent, detect,
correct, track
associated
Domain
Metamodel
Formal Model of
Regulations
Formal Model of
Business Process
SBVR Models of
Regulation Concepts
SBVR Models of Process
Concepts
Mapping
Rule
Integration
Change Management
Regulatory
and
domain
concepts
Using Purposive Models for Integrated
Compliance

10.  Create formal vocabularies regulatory and operational concepts and
map them to address Semantic Disparity
 Use the vocabularies [specifically terminological dictionary] to
capture natural language representation to address generation of
Proof Explanation
 Rematch/retag regulations to operational specifics using vocabulary
and mappings, use formal representation of regulations to reason
about Regulatory Change
Addressing Regulatory Challenges with
Model-driven Integrated GRC Architecture

11. Regulation: “A discount of 10% is granted if the
customer is a gold customer; 5% are granted if
the customer is a silver customer.”
Disparity between labels in formal regulations
and operational specifics- Exhibits
Petri Net
Approach
An event log
describing the
observed
operational
behavior is
aligned with a
Petri-net
pattern that
formalizes a
regulation.

12. Regulation: “A discount of 10% is granted if the
customer is a gold customer; 5% are granted if
the customer is a silver customer.”
Disparity between labels in formal regulations
and operational specifics- Exhibits
Petri Net
Approach
An event log
describing the
observed
operational
behavior is
aligned with a
Petri-net
pattern that
formalizes a
regulation.

13. Regulation: “For payment runs with amount
beyond euro 10,000, the payment list has to be
signed before being transferred to the bank and
has to be led afterwards for later audits.” +
Event “payment list A is transferred to the bank”
Disparity between labels in formal regulations
and operational specifics- Exhibits
Compliance Rule
Graph-based
Approach
Events from
operational event
trace are checked
against graph-
based compliance
rule language CRG
that formalizes a
regulation.

14. Regulation: “For payment runs with amount
beyond euro 10,000, the payment list has to be
signed before being transferred to the bank and
has to be led afterwards for later audits.” +
Event “payment list A is transferred to the bank”
Disparity between labels in formal regulations
and operational specifics- Exhibits
Compliance Rule
Graph-based
Approach
Events from
operational event
trace are checked
against graph-
based compliance
rule language that
formalizes a
regulation.

15. Regulation: “For payment runs with amount
beyond euro 10,000, the payment list has to be
signed before being transferred to the bank and
has to be led afterwards for later audits.” +
Event “payment list A is transferred to the bank”
Disparity between labels in formal regulations
and operational specifics- Exhibits
Compliance Rule
Graph-based
Approach
Events from
operational event
trace are checked
against graph-
based compliance
rule language CRG
that formalizes a
regulation.
The same observations can be made about other formal approaches-
Defeasible logic, BPMN-Q, Pi-Calculus based compliance checking

16. Building the Vocabularies
Semantics of Business
Vocabulary and Rules (SBVR)
Semantic model of formal
terminology
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

17. Mapping the Regulatory and Operational
Vocabularies
Rules as Bodies 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
or enterprise data
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 using similarity measures.
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.

18. Reserve Bank of
India’s Know Your
Customer
regulations for a
salaried
employee at a
private employer
opening an
account at an
Indian Bank
Addressing Semantic Disparity- An example of banking
domain regulation mapping to banking process
Formal model [based on deontic, modal, defeasible logic]

19. 2009
Annotate rule to task
r
1
r
2
…
Customer account opening process (CAO process)
KYC states customer acceptance policies (CAP) where different kinds of
customers submit different identification and address documents which
need to be checked- in the process above at the “review documents” task
determined through vocabularies of CAP regulation and CAO process

20. Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_document_data(17,acceptApp
rovedCorpCertificate,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.
Addressing Natural Language Proof Explanation

21. <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.
Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_document_data(17,acceptApp
rovedCorpCertificate,pse_kyc_document_set
)).
]
Success Rule r3
Addressing Natural Language Proof Explanation

22. <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,acceptApp
rovedCorpCertificate,pse_kyc_document_set
)).
]
Success Rule r3
Addressing Natural Language Proof Explanation

23. <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.
Success Facts for Client_ID 17
[
fact(client_data(17,ind,pse)).,
fact(pse_data(17,approvedCorporate)).,
fact(pse_KYC_document_data(17,acceptApp
rovedCorpCertificate,pse_kyc_document_set
)).
]
Success Rule r3
Addressing Natural Language Proof Explanation

24.  Query SBVR model in XML
 The projected results are filled into templates
 Template above 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
As per rule _, _. For current _that is _; _. Therefore
compliance is achieved for current _ _.

25.  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

26. Toward Addressing Regulatory Change
Management
 Regulations change
o As the regulatory body strives to bring more scenarios under
regulatory umbrella
o Enterprise operations evolve independent of specific regulations and
need to be kept in sync with already compliant regulations

27. Evolution of KYC from 2008-2014- Kinds of Banking
Customers

28. Evolution of KYC from 2008-2014- Kinds of Documents to be
Submitted for KYC

29. Evolution of KYC from 2008-2014- Kinds of Due Diligence
Activities Banks Must Perform

30. Evolution of KYC from 2008-2014- Kinds of Risks RBI warns
Banks to Take Care of

31. Existing
Techniques
Integrated
Regulatory Changes
Integrated Process
Changes
RisksNewBusiness
RulesOriginal BusinessProcessOriginal
RulesMod BusinessProcessMod
Rules BP
BusinessProcessNewBusinessRulesOriginal
Business
Process
changes…
Applicability
Applicability
Applicability
Applicability
RisksOriginal
Applicability
Applicability
RisksMod
Risk
Toward Addressing Regulatory Change
Management

32. 2009
2011
2012
Annotate rule to task Rule deleted
Risk Mitigation applicable to a rule
r
1
r
2
r
1
2010
r
1
r
1
r
2
r
2
r31
…
…
…
…r
2
r
3
r
3
o Formal norm change techniques to reason about what to change on
regulations side
o Rules can be embedded or treated as constraints on specific tasks, we
used the latter

33. 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
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
Various
Models
SEMILAR

34. Further Challenges in Compliance
 Semantic Disparity
o Creating vocabulary models of regulations and operational details
is an intensive effort, but we think it will pay off, could use natural
language processing for faster/aided creation of vocabularies
o Domain taxonomies are often published by regulatory bodies,
need to find ways to use these or map vocabularies to these for
interoperability
 Proof Explanation
o Not just natural language, but consisting mainly of stakeholder-
specific terms
o Explanations not just of (non-) compliance, but reparation, and
change suggestions
 Change Management
o When changing processes, how should they be changed?
o How to carry out compliance incrementally for changed process
for which compliance needs to be rechecked?

35. Conclusion
 Regulatory compliance is a complex practical problem- abstraction
and automation models can be immensely useful for enterprises in
being compliant
 Regulatory compliance poses interesting challenges requiring
multi-paradigmatic models working together
 Early work with SBVR vocabulary models, defeasible rule models,
and business process models seems promising; need to
improve/automate model making for each of these

36. Thanks!
Questions?
You can reach me at sagar.sunkle@tcs.com

40. BankType
IdentityProof
CustomerType DocumentType
AddressProof
obligatedTo
Perform
admits
1..
*
hasRelated
obtain
1..
*
1.
.*
DocumentSubmission
1..*
RiskProfile
hasRelated
1 hasRelated
Process
applicableTo
1..
*
Processes
Risk Regulations
BranchType
has
RiskPerception
isBasedO
n
1..
*
drives
1..
*
DDDOfficer
DueDillegenceActivity
isCarriedOut
By
1..
*
1..
*
usedToMitigateAMLRis
k
1..*
Rules
customerType_data(Customer_ID,Conditions...)
customerType_KYC_document_data(Customer_ID,Conditions...)
Low < Medium < High
Prob(ML/FTevent,
Consequence)
customerRiskProfile(
Customer_ID,
Risk_Status)
1..*

41. 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

42. 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

43. Rule 1: Before opening an account,
customer information must be obtained
and verified.
Rule 2: Whenever a customer
requests to open a deposit
account, customer information
must be recorded before opening
the account.
Disparity between labels in formal regulations
and operational specifics- Exhibits

44. November
December
Januar
y
February
MarchAprilMay
SBVR MM and M in RDF,
queries using SPARQL for
explanations and reparations;
Business rules M to
incorporate into domain M for
generation of DR-Prolog rules;
domain M assisted NLP for
SBVR M generation; SBVR to
BPMN
Domain M assisted LDA
for similarity; Layered
rules for BP
implementation
simulation- with BPMN
and 1st layer DR-Prolog,
2nd layer Drools,
computation of degree of
compliance without and
with business objectives;
simulation of sequence
diagrams/use cases;
relating regulation M to
enterprise M
Explanation of reparation,
simulation of reparation to
re-compute degree of
compliance; relating
ontology architecture to
FIRO and FIBO
Explanation of reparation,
simulation of reparation to
re-compute degree of
compliance; relating
ontology architecture to
FIRO and FIBO