Specification, Verification and Explanation of

Violation for Data Aware Compliance Rules

Ahmed Awad, Matthias Weidlich, Mathias Weske

Business Process Technology Group
Hasso Plattner Institute
University of Potsdam, Germany
Motivation

■ Currently design time checking:

□ Limited to control flow aspects only
□ Lack of useful feedback to the user

■ Data Aspects are important

□ More expressiveness
■ The need for “Beyond Checking” support
■ Useful feedback to the user
□ Identification of violation scenarios
□ Showing them on the process model level

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

Contribution

■ Consideration of data flow aspects in compliance rules

□ Pattern based extensions
□ Visually expressing rules as BPMN-Q queries
■ Formalization of data+control flow rules in PLTL
□ Domain-specific knowledge is required
■ Providing useful feedback to the user in case of violation
□ Use of Temporal Logic Querying[Cha00]
□ Visualize violation scenarios as BPMN-Q queries = Anti
Pattern Queries

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

Data Access Semantics

■ Data objects are used to represent data elements

□ A single instance of the data object
□ A data object can assume one state at a time
□ A data object has a known initial state
□ Activities may have a precondition on data object state
□ Activities may change the state of the data object

Data A Data A
[state 1] [state 1]
Activity Activity

Data A Data A
[state 2] [state 2]

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

The Approach

Process Model Repository

Pattern/Query

Query Processor

Show
Violations Process Models Subject to Checking
OK
, inf
orm Model Checker/
us TLQ Solver
er

No
An t O
t i p K,
att gen Anti Pattern
er er Generator
ns at Anti pattern queries
e

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Extra_valuation = yes
Extra_valuation
Extra_valuation [yes]
[initial]
Lookup

Example Evaluation
[failed]
Evaluation = failed
Partner Banks
Extra_valuation = no
Evaluation
[initial] Conduct due
diligence
study Extra_valuation
[no]
Risk
[low] Evaluation = passed
Request R_Bank_Record Evaluation
[initial] [created] [passed] Assess
Respondent Add Respondent
Bank risk Bank to Black List
R_Bank_Record = created
Certificate Evaluation = failed
Receive Risk
Identify [valid] [high]
correspondent
Respondent
Account open Check
Bank
request Respondent (Evaluation = passed or
Bank certificate Evaluation = initial)

Risk
R_Bank_Record R_Bank_Record [initial]
Certificate Certificate
[initial] [exists] [initial] [invalid]
R_Bank_Record = exists

Analyze Open
Respondent Correspondent
Bank annual Account
report Evaluation = passed or
Obtain R_Bank_Record = exists
Respondent Rating
Bank Annual [accepted]
Report

Review (Evaluation = failed or

Rating Respondent Evaluation = initial)
Rating
Ahmed Awad | ICSOC
[initial] Bank rating2009 | BPT@HPI
[rejected] 07.12.21
Compliance Requirements

■ The correspondent banking process is subject to compliance

rules:
□ R1: An account is opened only in case that risk is low
□ R2: The respondent bank must always be added to the black
list in case its due diligence evaluation fails
□ R3: Before opening an account, the respondent bank rating
must be accepted
□ R4: In case the respondent bank rating review is rejected, an
account must never be opened

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

Patterns

■ In previous work, we specified control flow aspects:

□ Existence, absence of activities
□ Ordering between activities: response, precedence
□ Within a scope global, between, before, after
■ Data aspects can be used to refine these patterns
□ Conditional Existence, absence, response, precedence
□ Implicit activity preconditions
■ Patterns are expressed as BPMN-Q behavioral queries
■ They are formalized as PLTL formulas

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

Implicit Preconditions

R1: An account is opened only in case that risk is low

Open
Risk Correspondent
[Low] Account

Mapping into PLTL:

G (ready( Open Correspondent Account) -> state( Risk, low))

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Conditional Response/Existence
0
R2: The respondent bank must always be added to the black list in
case its due diligence evaluation fails

Evaluation Evaluation
[failed] [failed]

Conduct due Add Respondent Add Respondent

diligence // Bank to Black @A // Bank to Black
study <<Leads to>> List <<Leads to>> List

Mapping into PLTL:

1. G (executed( Conduct due …) and state( Evaluation, failed) and
G(! state (Evaluation, passed)) ->
F ( executed (Add Respondent Bank to Black List)))

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Conditional Precedence
1
R3: Before opening an account, the respondent bank rating must be
accepted

Rating Rating
[Accepted] [Accepted]

Review Open Open

Respondent // Correspondent @A // Correspondent
Bank rating Account Account
<<Precedes>> <<Precedes>>

Mapping into PLTL:

G ( ready( Open Correspondent Account) -> O ( state( Rating,
accepted) and executed( Review Respondent Bank Rating) and G
( ! state( Rating, rejected))))

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Conditional Absence
2
R4: In case the respondent bank rating review is rejected, an account
must never be opened

Rating Rating
[rejected] [rejected]

Review Exclude(Open Correspondent Account) Exclude(Open Correspondent Account)

respondent Bank // @A //
Rating <<Leads to>> <<Leads to>>

Mapping into PLTL:

G (executed( Review …) and state( Rating, rejected) and G (! state
(Rating, accepted)) ->
G(! executed( Open Correspondent Account)))

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Anti Patterns
3 ■ An execution scenario that violates a compliance requirements
■ How to represent it on the model level?
□ Model Checker counter example
□ BPMN-Q
■ In previous work, for control flow rules:
□ Declaratively express violation scenarios as BPMN-Q queries
□ Generation of anti pattern was dependent on the rule (Pattern)
□ With consideration of data aspects, we need more details

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Pattern/Anti Pattern
4
Response: If A executes, B must Anti Pattern: A executes and B is
be executed = G( A -> F(B)) not be executed thereafter

A // B A // -- Exclude(B)
<<Leads to>>

Precedence: If B executes, A Anti Pattern: B executes without

must have been executed before A before
= G(B -> O(A))

// -- Exclude(A) B
A // B
<<Precedes>>

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Temporal Logic Querying TLQ
5 ■ Introduced by Chan[Cha00] to:
□ Find software model invariants
□ Gain better understanding of behavioral models
■ Model Checking can be seen as a sub-problem to TLQ
□ In Model Checking, we issue only binary queries
G(A -> F(B))? The answer is Yes/No
■ In TLQ, we can issue more generic queries
□ G(?) what are the invariants?
□ G(A -> F(?)) what will occur after A?

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Deriving TLQ for different Patterns
6 ■ Implicit Precondition G ( ready( a) -> state ( d, s))
□ TLQ 1: G ( ready( a) -> state( d, ?s))
■ Conditional Response
□ Anti pattern can be generated directly
■ Conditional Precedence G (executed (tar) -> O( executed (src)
and state(d,s) and G(!state(d,contra)))
□ TLQ 2: G( executed (tar) -> O( executed (src) and state(d,
s))) is true => G(!state(d,contra)) violation
□ TLQ 3: G( executed ( tar) -> O( executed (src))) is true ->
state(d,s) is violated
□ G(executed (tar) -> O(executed(src) and (state(d,?)))
□ Otherwise executed(src) did not occur

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Back to Example
7 ■ R1: An account is opened only in case that risk is low
□ The rule is violated
□ TLQ : G(ready (open correspondent account) ->
state(Risk,?))
□ Answer is state(Risk, low) or state(Risk, high) or
state(Risk, initial)
□ BPMN-Q anti pattern query

Risk
[high]

Open Open
@A // Correspondent // Exclude(Conduct due diligence study) Correspondent
Account Account

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Extra_valuation = yes
Extra_valuation
Extra_valuation [yes]
[initial]
Lookup
Evaluation Partner Banks
[failed] Extra_valuation = no
Evaluation Evaluation = failed
8 [initial] Conduct due
diligence
study Extra_valuation
[no]
Risk
[low] Evaluation = passed
Request R_Bank_Record Evaluation
[initial] [created] [passed] Assess
Respondent Add Respondent
Bank risk Bank to Black List
R_Bank_Record = created
Certificate Evaluation = failed
Receive Risk
Identify [valid] [high]
correspondent
Respondent
Account open Check
Bank
request Respondent (Evaluation = passed or
Bank certificate Evaluation = initial)

Risk
R_Bank_Record R_Bank_Record [initial]
Certificate Certificate
[initial] [exists] [initial] [invalid]
R_Bank_Record = exists

Analyze Open
Respondent Correspondent
Bank annual Account
report Evaluation = passed or
Obtain R_Bank_Record = exists
Respondent Rating
Bank Annual [accepted]
Report

Review (Evaluation = failed or

Ahmed Awad
Rating |Respondent
ICSOC 2009 | BPT@HPI
Rating 07.12.21= initial)
Evaluation
 Conclusion
9 ■ Including data aspects in compliance requirements
□ Refining control flow rules
□ Domain specific knowledge is needed
■ Explanation of violation
□ Rules are formalized and checked
□ BPMN-Q is used to express both patterns and anti patterns
□ Anti patterns are created by analyzing the different possible
violations on the process structure
■ Future work
□ Support for more complex data conditions
□ Taking more aspects into consideration, e.g., resources
□ (Semi) Automated Resolution of Compliance Violation

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Conclusion & Future Work
0 ■ Conclusion
□ Pattern-based approach for visually representing rules
□ Patterns are formalized in PLTL
□ Domain specific knowledge is needed
□ Temporal logic queries for derivation of violations
□ Anti patterns to describe violations on the process structure
■ Future work
□ Support for more complex data conditions
□ Taking more aspects into consideration, e.g., resources
□ (Semi) Automated Resolution of Compliance Violation

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 References
1
[Cha00] William Chan. Temporal-logic queries. In CAV, volume 1855
of LNCS, pages 450–463. Springer, 2000
[DAC99] Matthew B. Dwyer, George S. Avrunin, and James C.
Corbett. Patterns in property specifications for finite-state verification.
In ICSE, pages 411-420, 1999.

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

2

Thank You!
Questions are welcome
ahmed.awad@hpi.uni-potsdam.de

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21

 Implementation Of A TLQ Solver
3
■ The worst case is 22p model-checking problems
■ Using domain-specific knowledge, we can find more efficient
solutions
□ A data object can assume only one state at a time
■ Example TLQ: G(executed(act) -> state(d,?))
□ We can test 2number of states of d formulas
□ A linear implementation: for each state s of d
□ Issue CTL check: EF executed(act) and state(d,s)

Ahmed Awad | ICSOC 2009 | BPT@HPI 07.12.21