Listing of Principles :
5 Risk Management Systems
Principle no. 43: Frequency of information delivery
The application architecture should define the required frequency and format of all risk reporting, including ad hoc queries.
Principle no. 44: Data storage
The data architecture should define the data storage requirements of the company, including structure, level of detail and location.
Principle no. 45: Data integrity and ownership
The data architecture should ensure the completeness and accuracy of all risk information, through validation and reconciliation procedures. Ownership and maintenance responsibilities should also be defined.
Principle no. 46: Inter-operability
The technical architecture should ensure risk system comparatbility with the firmís stated IT strategy, in terms of hardware platform, operating system, database management system and communications infrastructure.
Principle no. 47: Level of sophistication
The technical architecture should define the level of sophistication required for treasury management, including the appropriate use of emerging technologies and package solutions.
Principle no. 48: System and model security
The technical architecture should define the required levels of security, to ensure integrity and confidentiality of the companyís information, systems and models.
Principle no. 49: Back-up, recovery and contingency planning
The technical architecture should define adequate back up and recovery procedures to ensure the company can withstand failures of hardware, software or telecommunications with an acceptable level of disruption. Full contingency plans should be in place in the event of failure.
back to top
Principle no. 50: IT developments
All treasury IT developments, whether bespoke or package based, should be specified, developed and implemented in a controlled manner.
