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

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

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

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

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

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)

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.

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.

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

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 Agent Community Input Filter 1 Agent Filter Filter 2 Filter 3 Output Possible Agent Actions:

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

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

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

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

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

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

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

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

? Questions?

Optimizing Audit Agent Communities of Control Systems