A topic of high importance but rarely considered is the audit trail in SimCorp Dimension. It is ready for you to use right out of the box. But there might be some aspects worth considering to increase system performance and lower database volumes or alternatively increase usage in SCD. In this piece, we will take a closer look at some topics that might be useful for your organizations.
First things first, the Audit Configuration window is where you define which tables are audited and which ones are not. This comes predefined with your SimCorp Dimension installation, so theoretically you do not need to worry about this at all. And to be fair, it is pretty well defined and will cover most if not all auditors’ requirements. The table is organized slightly differently from tasks and commands and the usual SimCorp window paths. Generally speaking, the tables are organized into data that is
Static data and configuration
Not auditable data
‘Static data and configuration’, ‘free codes’, and ‘adjustable data’ are generally audited by default. An exception to this is the prices with time stamps and risk factor sensitives. The characteristics of these are that they generate large data volumes to which there is little or no business reason to audit.
‘Generated data’ are log files and calculation results from various forms that by default are not audited. The idea is that rather than audit the calculation results, other means can be used to lock down results from key calculations such as authorizations on certain calculations or via extracts to a DWH, downstream systems, or SimCorp tables.
‘Not auditable data’ by definition cannot be audited.
One major reason for deactivating audit trails on a table often comes from poor system performance. Frequent updates to the audit tables can have a severe impact on how well SCD performs, so this could lead to a discussion on deactivating some tables from audit. Data volumes could be another. On the other hand, there might be a compliance need to audit a field or table which is not audited by the default. Whatever the scenario it is important to thoroughly review this with your auditors and assess any business impact. When a table is disabled from audit, there is no possibility anymore to know who changed the content.
In the Audit Configuration window, you furthermore have the option to do a more granular audit per price type for various windows that uses price types (e.g. FX rates, prices). For example, this means you can activate audit on price types Close, Fixing and Last, but records for any other price types in that table would not be audited. This is very useful to reduce the amount of audit data created as these tables generally create a lot of data.
In the Exclude Users from Audit window, it is possible to circumvent the batch and server users from audit by tables defined here. This could for example be reference rates being imported via a batch job where updates from the batch do not require any audit trail, whereas a user changing it would require a log.
In most windows, you can View Audit Trail from the View menu. Here you can fetch the audit trail for the data already loaded into the window. For example, if you have loaded 5 records into the bonds static data window, select View > View Audit Trail, select the field(s) or table(s) you want to see, and press load, the result will be the audit for those 5 records loaded. For a more generic search, the window of the same name View Audit Trail from the main portal provides you with a more general search on tables without having to preload data into the single-entry form. Here you can search directly on individual tables and limit your search via various criteria. As the audit tables are very large it is a good idea to limit the search as much as possible. Hopefully, this piece has offered some relevant insight. We look forward to hearing your comments and feedback.