Change, Development, and Audit Risks in Indonesian
Banking Sector
1)Evi Maria, 2)George J. L. Nikijuluw
Faculty of Information Technology Satya Wacana Christian University Jl. Diponegoro 52-60, Salatiga 50711, Indonesia
E-mail : 1) trifosa.evi@gmail.com, 2)gnikijuluw@yahoo.com
Abstract
The use of information technology (IT) in banking sector can enhance risks in addition to rapidity and accuracy of transactions and services to customers. This year’s effective technology could be left behind in the next 3 years, so information system (IS) is becoming more complex. That causes changes and development of a system in banking sector to be normal for the bank managers. This article explains the risks of changing and developing a system, the possible causes of the risks, and the influences on audit risk in Indonesian banking sector. The result shows that the changes and development of a system caution bank management against the emerging risks. Besides, auditors need to be more attentive if auditees change their systems impacting on the audit risk whose inherent risk and control risk are considered high and detection risk is low by auditors.
Keyword: Information System, Auditing, Audit Risk
1. Introduction
for all banks. Each bank must build a risk management system that agrees to the function and organization of risk management system in their environment. In Indonesia, risk management of the use of IT is regulated by Bank Indonesia through the Bank Indonesia regulation of PBI No 9/15/PBI/2007 that is about the Application of Risk Management towards the Use of IT by Public Banks.
In general, IS in banking sector consists of two types. They are main systems that is known as Core Banking Applications (i.e. a system including module of Deposit, Saving, Credit, Wire Transfer, and General Ledger) and support systems (i.e. Treasury, Internet Banking, and Credit Card). The system is becoming more complex following the demand for enhancing the rapidity and accuracy of transactions and services to customers. The complexity of IS can be seen from the scope of operation system, database, application, infrastructure (LAN and WAN) to model of management that is currently more varied. This year’s effective technology could be left behind in the next 3 years, so information system (IS) is becoming more complex [1]. In banking sector, based on Nugroho’s finding in 2008, he found that there were a lot of banks in Indonesia changing their old systems to new systems within these last 5-10 years. The complex system of banking sector causes the demands for IS audit. The problem is that auditors are required to be more attentive whenever auditees change their systems. Therefore, this article explains the risks of changing and developing a system, the possible causes of the risks, and the influences on audit risk in Indonesian banking sector.
2. Result and Discussion
amount of work at certain time) and response time (i.e. the average delay time interrupting two transactions). Furthermore, the new system is expected to improve the quality of the presented information, control, and efficiency, so that impacts on business profit and customer service. Information System Development Method
(ISDM )defines information system development method (ISDM) as: “A collection of procedures, techniques, tools, and documentation aids which will help the system developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of subphases, which will guide the system developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control, and evaluate information systems project” [3]. In outline, categorize ISDM into three major groups (1) structured methods; (2) Rapid Application Development or RAD method; (3) object-oriented methods. Structured methods were introduced in the 1980s and use linier models in its development process. Input and output in each stage are clearly identified. The data and process modeling is made in a structured framework [5]. System Development Life Cycle (SDLC) is one of the methods. RAD method uses models of iterative development process and, in general, specifies the stages based on several prototypes [5] RAD method normally can be adapted to existing condition since it does not give any details of the techniques used. Dynamic Systems Development Method (DSDM) is an example of this method [4]. Object-oriented methods are relatively new methods and now become quite popular among the developers of information system. These methods focus on consistent objects starting from the stage of analysis, design, and implementation of information system [6]. Unified Modeling Language (UML) is one of the model variants [7]. This article informs seven main stages of SDLC in banking sector, i.e. Planning, Requirements Analysis, Design, Development, Testing, Implementation, and Monitoring (Post Implementation). These stages are explained as follows:
1. Planning. At this stage, banks review various alternatives of system development, i.e. (a) in-house development, (b) outsourcing system development to vendors, or (c) purchasing ready-to-use system. Besides, banks must ensure that the plan for the system change agrees with the future business plan of banks and also ensure availability of funds for new systems.
2. Requirements Analysis. Every new-system-supported business requirement must be written in a document that is called User Requirement. If a bank decides to buy a ready-to-use system, the bank must reconsider user needs, fund availability, features of a new system, expiry of the features, system capability to develop, reputation of the vendor, audit trail assessment against transactions and system security, and vendor support for maintenance.
3. Design. This stage encompass such activities as (a) designing system with flowchart and entity relationship diagram, (b) designing input that is needed by a system including designing user interface of a new system, (c) designing reports created by a system, (d) designing processing steps of a system including a count mechanism performed by a system, and (e) designing the plan for data conversion from an old system to a new one including its manual.
development stage includes (a) making a program and documenting a system (system-level documents), (b) testing programs of a system for possible errors (debugging), (c) making a program for converting data from an old system to a new one, (d) making procedure and training users while having a system change, (e) making certain that each stage of development is documented including changes of a system.
5. Testing. At this stage, there is a series of testing making sure that the system is error-free. In addition, there are two kinds of testing. They are (1) unit testing in which performance of each part is studied using test data that could be derived from either compiling or sampling and if a program is written by a team of programmers, each part of the program is tested separately, and (2) system testing in which parts are connected to each other using test data to find if those parts can work together. The system can also be tested with actual data of the organization.
6. Implementation. Before implementing a new system, if the new system has data structure different from the old system, a bank initially converts the data to allow data in the old system to move into the new one. After the conversion, process of system implementation is commenced. The strategy commonly used in implementation process is abrupt changeover strategy. It is a strategy in which a bank uses a new system and deactivates the old one right after implementation process. The strategy has a weakness, i.e. there is not any back-up system, if a new system fails. However, the strength of the strategy is that the implementation process is quicker since the implementation does not need to be processed twice and is cheaper for there is no need for back-up servers and over-timed employees. Another implementation strategy is parallel run strategy in which a bank uses two different systems simultaneously, i.e. new and old systems, in order to act contingency plan so that if a new system errs, a bank is still operative with the old one. As a result, a bank employee has to input data to the system twice where a bank is supposed to use a new system for regular operations. Another consequence is that at nights, a bank employee must input overall transaction data of the day to the old system. Furthermore, a bank employee still has to process the reconciliation for testing the fitness between new and old systems.
7. Monitoring (Post Implementation). The purpose of this stage is to find if a new system fit the business unit requirement in particular and bank requirement in general. The activities of this stage are (1) assessing the user satisfaction of a new system, (2) assessing the fitness between the system and User Requirement, (3) identifying post-implementation problems that is caused by system errors, untrained human resource, weak procedures, insufficient documentation of a system, and failed follow-ups to solve the problems.
Tabel 1 Risks of Change and Development of System and The Possible Causes
No Risks Possible Causes
1 System developed does not fit business plan of a bank.
The IT Strategic Plan does not fit business plan of a bank.
2 System developed does not fit user needs.
User requirement states unclearly the needs of a user.
3 System chosen is not the best problem solution for a bank because of its high cost and features that is not the best.
Bank does not both analyze cost and benefit, and carry out feasibility study.
Bank tidak melakukan cost and benefit analysis dan feasibility study.
4 System development is time-consuming.
Userrequirement changes too often.
No functions control the time frame of a system development project.
Members of a system development team cannot focus more intensely on one project because they must distribute their efforts into more than 1 project.
5 The cost of system development is higher than the budget fixed by a bank.
There is not any watch on the spending of the
Internal audit is not involved in the process of system design and development.
Programmer only focuses on system development suitable to user needs.
7 High-dependence on the vendors and/or key personnel.
Less training.
Insufficient system documentation. 8 Errors/bugs are either undetected or
detected after applying a system.
System testing is inadequate.
9 Not all systems developed can be run. System testing is inadequate. 10 User makes mistakes while
implementing and converting data.
Less training.
Bank does not reconcile pre-conversion and post-conversion data.
Unauthorized users access the system. 11 Regular users gain unauthorized access
to upper levels of authority even to the highest.
Bank does not have any documentation holding access rights to each function in the structure of an organization.
also be hacked by those who try to harm, so comes up privacy risk and terrorism risk. Hence, a company that applies information technology needs information system audit. That happens because, essentially, the purpose of information system audit is to review and evaluate internal control that is applied to keep secure, check the trust in information system, and review the operation of application system.
In the process of audit and audit procedure planning, SA section 312-paragraph 12 requires an auditor to consider audit risks. The purpose is to collect enough and competent audit evidence that forms the basis for eliciting expert opinions. Audit risk is risk that is caused by an auditor when he/she misjudges over information technology. The auditor is failed to reveal the material faults/frauds. The more certain an auditor’s opinion, the lower audit risk [8]. SA section 312-paragraph 27 says that there are three elements of audit risk. First, inherent risk that is the susceptibility of an account balance or a class of transactions to misstatement based on the assumption that related control does not exist. Second, control risk that is a risk in which a misstatement in an assertion cannot be prevented and detected in time by the entity of internal control. Third, detection risk is a risk where auditors cannot detect misstatement in an assertion. Auditors need to pay enough attention when their auditees are banks that change their system since the system change impacts on the height of the audit risk. One of the factors that influences inherent risk is the number of activities in a company. The greater the number of activities in a company, the higher the inherent risk. In this case, the use of new technology in banking certainly has an influence on the more efficiency of data processing time, so that the number of business activities is mounting. This influences the height of inherent risks. Auditors will review dan evaluate the introduction to internal control because they need to gain knowledge of accounting system to comprehend both control environment as a whole and transaction flows. At this stage, auditors will be careful to comprehend because auditees use new systems. That is because the adequate comprehension of internal auditee control and it is perceived to be foundation for auditors to assess the control risk. If the new result of control review done by system auditors is less effective, auditors will set control risk high and the other way around. The high control risk impacts auditors. That makes them more careful to test control. The testing of the control is conducted in order to assess effectiveness and efficiency of the internal control used by a bank. The control testing is designed with correct audit procedure, so that faults/frauds can be detected. SA section 312-paragraph 28 says that the detection risk is in inverse relation to both inherent risk and control risk. It means that the lower inherent and control risks believed by auditor, the higher detection risk received and vice versa. Thus, in the case of auditee in which banks change their systems, because inherent and control risks are believed high by auditor, detection risk is automatically low. That is caused by the emergence of detection risk. In that case, auditors use samples with high inherent and control risks to do auditing. That leads to the use of multiple samples for auditing.
3. Conclusion
transactions and services to costumers but also increases risks. The effective present technology could be left far behind in the next 3 years, so information system is becoming more complex. System changes and development normally happened in banking sector. However, those changes and development could trigger risks to which bank management must be alert. Auditors must be attentive enough when auditees change their systems because that has an influence on audit risk where inherent and control risks are high and detection risk is low.
4. References
[1] Priandoyo. Anjar. (2006). “Audit Sistem Informasi Berbasis Risiko Untuk Usaha Kecil dan Menengah”. Prosiding National Confrence of Information Technology and Comunication for Indonesia, Institute Teknologi Bandung. [2] Nugroho, Yudi. (2008). “Petunjuk Bila Bank Berganti Sistem”, Accounting
Training Programme.Yogyakarta:Universitas Gadjah Mada.
[3] Avison, D., & Fitzgerald, G..(2003). “Information Systems Development”. London: McGraw-Hill.
[4] Avison, D., & Fitzgerald, G..(2006).“Information Sistems development metodologies, techniques & tools”. 4th Edition, Page 32 -37.
[5] Beynon-Davies, P., & Williams, M. D. (2003). “The diffusion of information systems development methods”. Journal of Strategic Information Systems, 12, 29-46.
[6] Iivari, J., & Maansaari, J. (1998). “The usage of systems development methods: are we stuck to old practices? Information and Software Technology”. 40, 501-510.
[7] Rumbaugh, J., Jacobson, I., & Booch, G. (1999). “The Unified Modelling Language Reference Manual”. Reading, Mass: Addison-Wesley.
[8] Hunton, E. James.(2004).“Core Concept of Information Technology Auditing”, 1sted., John Wiley & Sons.
[9] Hall, James; Tommie Singleton, Thomson. (2005). “IT Audit and Assurance”. Southwestern Publishing : 2nd Edition, .
[10] Ikatan Akuntan Indonesia.(2011).“Standar Profesional Akuntan Publik”, Jakarta:Penerbit Salemba Empat.
[11] John Watkins. (2001).“Testing IT, An off-the-shelf Software Testing Process”. Cambridge University Press.
