Optimizing Audit Agent Communities of Control Systems

1
Optimizing Audit Agent Communities of Control
Systems

• Rob Nehmer
• Oakland University
• Presented at the Twelfth Continuous Auditing and
  Reporting Symposium, Rutgers University, November
  3 and 4, 2006

2
Overview

• Modeling internal control
• The Logical Model
• Framework of the Transaction Agent System with
  Logical Modeling
• Logical Design Specifications
• Transaction Agents at the Application Level
• Conclusions

3
A Transaction Agent Framework for IC

• Transaction agent activities and risk
• Risk assessment ()
• Control activities ()
• Monitoring ()
• Information and communication ()
• Planning and organizing
• Acquisition and implementation
• COSO and COBIT
• () included in the simulation

4
Transaction Agent Audit Framework

• Points and bands of risk
• Point of control is a single control activity
• Band of control is a system of control activities
• Agents can be designed to perform the activities
• The mapping is not one-to-one

5
Transaction Agent Audit Framework (cont.)

• Transaction agent activities and risk
• Risk assessment
• Control activities
• Monitoring
• Information and communication
• Planning and organizing
• Acquisition and implementation
• COSO and COBIT

6
Transaction Agent Audit Framework (cont.)
A Generalized Framework of Transaction Agent
Activities within the eCommerce Transaction Model
Trading Partner A
Trading Partner B
Communication Channel
(b)
Translation Interface
Translation Interface
DB (c)
DB
(d)
Acquisition Purchase Agents (e)
Processor (a)
Processor
System-wide (example) Risk assessment
(a) Information and communication flows
(d) Control (agent) activities (b) Planning and
organizing activities (agent community
Monitoring (c) self-organization)
7
The Logical Model

• Construct the relations and functions of C such
  that
• i) each n-place relation RC of C is the
  restriction to C of the relation RA which
  corresponds to it RC (RA ? (C)n) U (R ? Mod
  ?)
• ii) each m-place function fC of C is the
  restriction to C of the function fA which
  corresponds to it fC (fA ? (C)m) ? (f ? Mod
  ?).
• This eliminates relations and functions of A not
  appearing in ?.
• iii) each constant c of C is the interpretation
  of cA in C. It is easy to see that C ? A. If C ?
  A, C is a submodel of A.

8
Corollary

• A ? B and B ? A
• Proof
• The proof relies on the fact that, for arbitrary
  models of the information systems of a firm and
  an investor, the appearance of exactly the same
  relation and function symbols cannot be expected.
  For example, a firm's model must include
  functions for computing employee payroll
  withholdings, whereas the investor model need
  not. Conversely, an investor needs to know his or
  her total income relation for total cash flow.
  This relation is of no concern to the firm. This
  suffices to show that neither is a submodel of
  the other.

9
The TA Framework with Logical Modeling
Transaction Agent Implementation
Logical Design Specs. XML DTD
C(R,f,c)

• Validations
• Schema
• SAX
• Filter
• Rule

Next slide
10
The TA Framework with Logical Modeling
The Simple API for XML (SAX) Pipeline Pattern
(Filter Design Pattern)
Input
Output
Filter 1
Filter 2
Filter 3
Agent Extension of SAX Pipeline Pattern
Input
Filter 1
Agent Filter
Agent Community
Filter 2
Filter 3
Output
Possible Agent Actions
11
Logical Design Specifications

• Existing IC matrices which include items to
  verify, acceptable ranges, and required
  procedures and approvals can be used to collect
  the R, f, c parameters
• The existence and truth validity of these are
  straightforward to implement
• The specs will not be all-inclusive or eliminate
  audit judgments

12
Logical Design Specifications (cont.)

• Development of sparse axiom systems
• The axiom system can be designed to give complete
  IC system coverage while minimizing
• Space considerations (complexity of the axiom
  system itself)
• Time considerations (processing complexity)
• An extension of this work can more completely
  formalize this idea

13
Transaction Agents at the Application Level

• XML-based agents
• Not written in XML
• Access documents through the Document Object
  Model using API or memory
• Access documents through the Simple API for XML
  through its API calls
• Write an agent parser

14
Transaction Agents at the Application Level

• XBRL (eXtensible Business Reporting
  Language)-based agents
• Very similar to XML
• Simpler than general XML because the language is
  more restricted
• Inherit methods and object classes from XML agents

15
Transaction Agents at the Application Level

• XBRL agent activities
• Traditional validation
• Parse for validation of schema or Document Type
  Definition
• Check for valid business rules (not XML native)
• Software validation

16
Transaction Agents at the Application Level

• XBRL agent activities
• Extending validation
• Handling constraints in legacy systems
• Checking logical specifications through the
  consistency of the logical design specification
• Exploiting SAX application design patterns
• Filtered designs
• Rule-based designs checking traditional
  business rules implemented through the IC matrices

17
Transaction Agents at the Application Level

• XBRL agent activities
• Other activities
• Trigger control activities based on XBRL keywords
  and keyword values
• Monitor XBRL documents for trends
• Combine data across firms and periods providing
  analytical measures

18
Conclusions

• Adding logical specifications gives a good way to
  motivate the design of IC regimes
• The system provides natural means of validation
• Cost / benefit aspects of regimes of IC are
  comparable to aid in IC design decisions

19
?

• Questions?