1 / 19

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

gari
Download Presentation

Optimizing Audit Agent Communities of Control Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 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:

  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?

More Related