Browse Prior Art Database

Detecting Fraudulent Patterns in Compliance Checklists

IP.com Disclosure Number: IPCOM000246607D
Publication Date: 2016-Jun-20
Document File: 4 page(s) / 330K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a qualitative solution that helps detect compliance system gaming behavior. The novel contribution is a set of enhancements to state-of-the-art compliance systems that help detect fraudulent patterns.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 01 of 4

Detecting Fraudulent Patterns in Compliance Checklists

Determining whether certain essential non-functional requirements (e.g., accessibility, security, etc.) are met before shipping a product is an essential part of compliance processes established within most organizations. In order to make this determination, compliance boards use checklists in the form of detailed questionnaires, soliciting responses from development teams.

Depending on the overall response, the component/product is marked as Compliant (or not) along with estimated compliance scores.

Figure 1: Example compliance table and scores

Due to the nature of software development projects and the need to meet shipping deadlines, compliance specialists often grant exceptions on a few outstanding issues after proper justification.

Figure 2: Example compliance table with exceptions

While providing such leeway is useful, one of the limitations of these tools is that a development team might work around (i.e., game ) the compliance system by seeking successive exceptions release after release, just to keep the software releases

occurring. Establishing whether this situation is taking place is not always a straightforward process. A method is needed to detect these instances.

Presented herein is a qualitative solution that helps detect compliance system gaming behavior. The novel contribution is a set of enhancements to state-of-the-art compliance systems that help detect fraudulent patterns.

1


Page 02 of 4

After the user completes the compliance checklist, the system scans it and identifies any question(s) with questionable responses. Examples of such responses include (but are not limited to): "Yes with Exception", "N/A", "No answer", "Planned", and "Yes but no fully tested".

Figure 3: Examples of responses that can indicate a questionable pattern

If the system does not identify any questionable responses, then it continues to the detection routine.

The system responds to each entry identified as a questionable response.

If the questionable response is "Yes with exception" or "Planned", then the system fetches the entire history of the project as it has persisted in the compliance system.

Figure 4: Example compliance history

For each compliance checklist that has been completed for the project in past, the system cross checks the answer to the same question.

If the number of prior occurrences of the same question with a "Yes with exception" or "Planned" response is greater than a pre-determined threshold (e.g., two), then the system marks the current answer as "suspicious" with a high weight (e.g., 0.7).

If the answer is "Planned" or "Yes, but not fully tested", then the system looks for the

2


Page 03 of 4

planned date to address the non-compliance or when the feature is scheduled for full testing. If there was a prior occurrence of the same question and the planned date (specified earlier) is being extended, then the system searches for a provided "justification" (text in...