Transcript Optimizing Audit Agent Communities of Control Systems

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
1
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
2
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
3
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
4
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
5
Transaction Agent Audit
Framework (cont.)
A Generalized Framework of Transaction Agent Activities within the eCommerce Transaction Model
Trading Partner A
Translation
Interface
Trading Partner B
(b)
Communication
Channel
Translation
Interface
(d)
DB
(c)
DB
Processor
(a)
System-wide (example):
Risk assessment (a)
Control (agent) activities (b)
Monitoring (c)
Acquisition:
Purchase
Agents (e)
Processor
Information and communication flows (d)
Planning and organizing activities: (agent community
self-organization)
6
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.
7
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.
8
The TA Framework with
Logical Modeling
Transaction
Agent
Implementation
Logical
Design Specs.
C(R,f,c)
XML
Validations
DTD
1. Schema
Next slide
2. SAX
a. Filter
b. Rule
9
The TA Framework with
Logical Modeling
The Simple API for XML (SAX) Pipeline Pattern (Filter Design Pattern)
Input
Filter 1
Filter 2
Filter 3
Output
Agent Extension of SAX Pipeline Pattern
Input
Filter 1
Filter 2
Agent
Filter
Filter 3
Agent
Community
Output
Possible Agent Actions:
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
?
Questions?
19