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.

Model-Driven Regulatory Compliance: A Case Study of “Know Your Customer” Regulations

58 views

Published on

Regulatory Compliance using Models of Regulations

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Model-Driven Regulatory Compliance: A Case Study of “Know Your Customer” Regulations

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. Evolution of KYC from 2008-2014- Kinds of Banking Customers
  28. 28. Evolution of KYC from 2008-2014- Kinds of Documents to be Submitted for KYC
  29. 29. Evolution of KYC from 2008-2014- Kinds of Due Diligence Activities Banks Must Perform
  30. 30. Evolution of KYC from 2008-2014- Kinds of Risks RBI warns Banks to Take Care of
  31. 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. 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. 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. 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. 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. 36. Thanks! Questions? You can reach me at sagar.sunkle@tcs.com
  37. 37. 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..*
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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

×