Matrics - Reduce Operational Risk
Use Separation of Duties

A large trading organization is faced with many forms of operational risk. One of these is a failure to measure the correct trading positions due to human errors when entering contracts or other data. These risks can never be eliminated completely, but a good trading system will support good working routines and separation of duties that will try to minimize the likeliness of such errors.

Matrics separates the users into different roles, using the well-established front office (trader) / middle office (risk controller) / back office model, which is the accepted standard for trading organizations in most markets. In addition to these primary user categories, Matrics defines read-only and administrator users. Read-only users can only view results, but not modify any data. Administrator users have extended privileges that are not available to ordinary users, such as creating new users and setting permissions.

Each user role has well-defined primary tasks and permissions. For example, front office users are responsible for entering new trades, but a trade will not be included in the official portfolio before it has been checked and accepted by a back-office user. Official forward curve and risk settings may only be changed by Middle Office users, etc. For moderate to large organizations, this separation of duties is important to ensure that data is not modified in error and that important changes are verified by two persons. For small organizations it may be desirable that one user have more than one role. This is easily defined – one user can have any number of roles in Matrics. Even if one user has all the roles, the separation of duties ensures that the model can adapt when the organization grows.

Limit User Access

In addition to system defined restrictions, Matrics has a flexible system for setting user-defined restrictions. Restrictions can be applied to almost any object in the system. Restrictions are set in the folder structure and apply recursively to all objects in the folder. Both read or write access can be restricted. Permissions can be granted to specific user roles, specific users, specific departments, or combinations.

Trap Input Errors with Logical Validations

Although it is not possible to guard completely against human input errors, a good system will apply a number of logical validations that can trap many common input mistakes. Where some systems may crash, or even worse, simply produce the wrong answer if presented with illegal input data, Matrics will try hard to trap these situations and present the user with a meaningful error message instead.

Example: Setting Permissions
Screenshot illustrating how to set permissions
Example: Simple Input Error
Screenshot illustrating simple input error
Example: Trying to Run Report with Missing Input Data
Screenshot illustrating trying to run report with missing input data