The increasing digitization and the use of IT in the course of business operations in banking not only contain opportunities but also new risks and dangers to which banks (credit institutions and financial institutions) are exposed. This has 2018 the FMA moved the banks to provide guidelines as an orientation aid for the design, requirements and precautions relating to ICT security (synonymous for: IT security): the “ FMA Guide to ICT Security in Credit Institutions “. ICT systems are understood to mean systems of information and communication technology.
With the introduction of the “ EBA guidelines for ICT and security risk management “Were from September 30th. 2019 this for the Austrian Banks effective instead of the FMA guidelines
Legal basis in Austria
In Austria, the FMA guidelines and the EBA guidelines represent a supervisory authority specification of Section 39 Paragraph 2b Z 5 and Paragraph 4 BWG in conjunction with Section 11 KI-RMV (operational risk of credit institutions Risk Management Ordinance, Federal Law Gazette II No. 487/2013). The FMA guidelines and the EBA guidelines are not to be regarded as ordinances. Rights and obligations going beyond the statutory provisions cannot be derived from them. These documents can be seen as the basis for the need for documentation of software in banks.
Legal basis in Germany
In Germany, due to the increasing importance of IT in banks, on 14.09.2018 the supervisory authority BAFIN issued the banking supervisory requirements for IT (BAIT) in the form of a circular (BAFIN circular 10/2017) as specifications for the use of ICT systems for the German Enact banking industry. The BAIT are to be seen as a specification of the minimum requirements for risk management (MaRisk) with regard to the introduction and operation of ICT systems at banks.
This circular gives on the basis of § 25a para. 1 of the Banking Act (KWG) provides a flexible and practical framework for the technical and organizational equipment of the institutes, in particular for the management of IT resources and IT risk management.
Due diligence in Austria
The arrangements, requirements and precautions described in the two documents of the EBA and FMA are subject to the principle of proportionality, so that they should be applied appropriately in accordance with the type, scope, risk and complexity of the banking business. The banks in Austria are therefore given a margin of discretion in the implementation, depending on their business model, their risk and the scope of their activities.
The FMA and EBA guidelines essentially contain requirements for the systematic introduction and control of ICT systems (systems of information and communication technology).
The topics of establishing an ICT strategy and the systematic control of ICT systems within the framework of ICT governance are addressed. In order to counter the increasing dangers of IT and cyber risks, the banks have to create their own security guidelines for their ICT landscape.
For the application software used, the EBA and FMA have imposed a duty of care on the credit institutions in connection with ICT projects and application development.
ICT system inventory
The financial institutions in Austria should keep an up-to-date list of their ICT assets (including ICT systems, network devices, databases, etc.) as part of ICT operations management. The ICT system inventory should include the configuration of the ICT systems and the connections and dependencies between the various ICT systems to enable a proper configuration and change management process. ICT assets are a set of software or hardware that can be found in the banking environment.
Introduction of ICT systems
Financial institutions in Austria should have a methodology for reviewing and approving ICT systems before they are used for the first time. This methodology should take into account the criticality of business processes and assets. The tests should ensure that new ICT systems are performing as intended. You should also use test environments that adequately represent the production environment.
In order to ensure the traceability of the bookkeeping in Austria by an expert third party (cf. § 190 Para. 1 UGB), suitable documentation is required when using IT bookkeeping ( Procedural documentation ) required in a clear form. Proper procedural documentation must include a description of all procedural components required to understand the bookkeeping. This also applies to credit institutions in their bookkeeping.
- the user documentation,
- the technical system documentation
- as well as the operating documentation.
The technical system documentation must contain the following information in particular for each new program version:
- Data organization and data structures (data record structure or table structure for databases)
- Processing rules (including control parameters, table settings)
- including automatic controls, voting procedures and error handling
- Data output
- available programs
- Key directories
- Interfaces to other systems (content of the transmitted data, direction of transmission, trigger, etc.).
Change documentation: The system documentation must also be updated accordingly when the configuration is changed (customizing).
The Operational documentation serves to document the correct application of the procedure and covers, among other things:
- Data backup procedure
- Proof of processing (processing and reconciliation protocols)
- List of available programs with version records.
In Austria they have Bank auditor as part of the execution of the annual audit at credit institutions (according to Bank Audit Policy – BPR 2007) to carry out audit procedures in relation to IT systems at credit institutions. In doing so, the bank auditors have to refer to the expert opinion on the correctness of EDP bookkeeping (KFS / DV1) and the expert opinion on the use of information technology (KFS / DV 2) orientate.
Documentation requirements in Germany
In Germany, the BAFIN requires the banks to document all the applications in use and their development in a clear and comprehensible manner for knowledgeable third parties.
The documentation of the application includes at least the following content:
- User documentation
- Technical system documentation
- Operational documentation.
- Versioning of the source code and the requirements documents, for example, contributes to the traceability of application development.
BAFIN sees the need for several different ones Documentation types for the applications of the banks and provides for the following types:
Requirements documents are for example:
- Technical concept (specification sheet or user story)
- Technical concept (specification sheet or product back log).
Non-functional requirements for IT systems are, for example:
- Results of the protection requirement assessment
- Access regulations
- Response times
In the context of application development, appropriate precautions must be taken in accordance with the protection requirements with a view to ensuring that the confidentiality, integrity, availability and authenticity of the data to be processed are comprehensibly ensured after the application has gone live.
BAFIN provides the following suitable precautions:
- Check the input data
- System access control
- User authentication
- Transaction authorization
- Logging of system activity
- Audit trails (audit logs)
- Tracking of security-relevant events
- Handling exceptions.
As part of application development, precautions must be taken to indicate whether an application has been accidentally changed or intentionally tampered with.
BAFIN provides the following suitable precautions:
- A suitable precaution, taking the protection requirements into account, can be to check the source code as part of application development.
- The source code review is a methodological investigation to identify risks.
The banks in Germany have to define and introduce a methodology for testing applications before they are used for the first time and after significant changes. The tests have to include the functionality of the application, the security controls and the system performance under various stress load scenarios. The department responsible for the application is responsible for carrying out technical acceptance tests. Test environments for carrying out the acceptance tests must correspond to the production environment in terms of aspects that are essential for the test. Test activities and test results must be comprehensively documented.
A Test documentation contains at least the following points:
- Test case description
- Documentation of the underlying parameterization of the test case
- Test data
- Expected test result
- Test result achieved
- Measures derived from the tests.
In order to adequately counter the increasing use of ICT systems (ICT systems are understood as systems of information and communication technology) and the associated risks (e.g. fraud and cyber risks), the European supervisory authorities have extensive documentation requirements for the banks during the introduction and the Operation of ICT systems imposed. Here you can find out how you can meet regulatory requirements with Sysparency.