1. 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. 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. 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. 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. 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. 6 Transaction Agent Audit Framework (cont.) Trading Partner ATrading Partner B Translation Interface Processor (a) Translation Interface Processor DB (c) DB Communication Channel Acquisition: Purchase Agents (e) (b)(b) (d)(d) A Generalized Framework of Transaction Agent Activities within the eCommerce Transaction Model 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. 7 The Logical Model Construct the relations and functions of C such that i) each n-place relation R C of C is the restriction to |C| of the relation R A which corresponds to it: R C = (R A  (|C|) n ) U (R  Mod  ) ii) each m-place function f C of C is the restriction to |C| of the function f A which corresponds to it: f C = (f A  (|C|) m )  (f  Mod  ). This eliminates relations and functions of A not appearing in . iii) each constant c of C is the interpretation of c A in C. It is easy to see that C  A. If C  A, C is a submodel of A.

8. 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. 9 The TA Framework with Logical Modeling C(R,f,c) Logical Design Specs. XML DTD Transaction Agent Implementation Validations 1.Schema 2.SAX a.Filter b.Rule Next slide

10. 10 The TA Framework with Logical Modeling InputOutputFilter 1Filter 2Filter 3 InputFilter 1Agent Filter Agent Community Filter 2Filter 3Output The Simple API for XML (SAX) Pipeline Pattern (Filter Design Pattern) Agent Extension of SAX Pipeline Pattern Possible Agent Actions:

11. 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. 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. 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. 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. 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. 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. 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. 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. 19 Questions? ?