Who controls what? A simple guide to user access roles in ALM on Viya

[#1]

Have you ever been in a kitchen with too many cooks? Everyone is chopping something, someone is adjusting the seasoning without asking, and by the time the dish is done, nobody really knows who did what. A bank's Asset and Liability Management system can feel exactly the same if access is not managed properly.

SAS Asset and Liability Management on Viya solves this with a clear set of user roles. Each role comes with a specific set of permissions, a defined list of things a person can do, and just as importantly, a list of things they cannot do. Get this right, and your ALM process runs like a well-organised restaurant kitchen. Get it wrong, and you have analysts deleting configurations and reviewers accidentally kicking off end of quarter calculation runs before all numbers are in.

This post walks you through the six roles in SAS ALM, what each one can actually do, and how they connect to the day-to-day ALM workflow.

How SAS ALM solution controls access

Before talking about the roles, it helps to understand that access in SAS ALM works in layers. In simple terms is like entering an office building.

• The first layer is the front door, where the SAS Viya platform decides whether you can enter at all.
• The second layer is the floor plan, where role-based permissions decide which rooms you can walk into.
• The third layer is object-level scope, where even inside a room, some cabinets are locked to certain people.

All three layers work together. A user needs to clear all three before they can do anything meaningful in the solution.

SAS ALM ships standard out-of-the-box with 6 roles, but you can always modify or define your own according to your organisation needs.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

What can each role actually do?

Each role has a defined set of permissions per solution object. The permissions are Create, Read, Update, and Delete, or CRUD for short. The table below maps the key objects across all six roles.

A few things worth noting. The Reviewer can only ever read. The Administrator can do everything but is not involved in daily workflow tasks. The Data Analyst and Risk Analyst are the workhorses of the daily cycle. The Quant Analyst owns the modelling objects but stays out of the data preparation side.

Who does what in the workflow?

Permissions on objects are one thing, but the workflow tells the complete story. The ALM cycle has a fixed sequence of tasks, and each task is assigned to specific roles. The swimlane below shows the full picture from cycle initialisation through to the Manager sign-off and Reviewer check.

You may notice that the Data Analyst and Risk Analyst share the same workflow tasks. The difference is not in the tasks but in the object permissions shown in Figure 2. The Risk Analyst has broader Create and Update rights on objects like Allocation Schemes and Analysis Runs. Banks that want strict separation of duties keep both roles. A Data Analyst handles data preparation only and cannot touch modelling objects at all. Banks with simpler setups often just use the Risk Analyst role for everything on the data side.

Common mistakes when setting up roles.

Getting the roles wrong at the start creates headaches down the line. Here are the four most common mistakes we see.

• Giving everyone the Administrator role If everyone is an admin, nobody is accountable. Keep the number of Administrators very small. These roles have wide-reaching access across all SAS Risk Cirrus applications.
• Skipping the reviewer role Banks often skip the Reviewer because it seems passive. But it creates a clear audit trail and ensures sign-off accountability without allowing anyone to tamper with results.
• Mixing up Data Analyst and Risk Analyst Both roles handle data tasks, but only the Risk Analyst can also configure scenarios and build growth assumptions. Assigning a Data Analyst where a Risk Analyst is needed will block the workflow at the modelling step.
• Forgetting the Cirrus group memberships Solution roles alone are not enough. Users also need to be in the correct SAS Risk Cirrus groups to run calculations. Missing group membership is the most common reason a user can log in but cannot execute a cycle.

 

Conclusion

Getting user roles right is something that does not feel urgent until something goes wrong. A misconfigured role means someone deletes a configuration they should never have touched, or a cycle runs before the data is ready, or nobody can tell the regulator who signed off on last quarter's results.

Done properly, roles should be invisible. Everyone just does their job. The data team loads and validates. The quant team builds the assumptions. The manager reviews and signs off. The reviewer checks the results. No overlap, no confusion, no awkward conversations after the fact.

If you are setting up SAS ALM for the first time, sort the roles out before you do anything else. Everything else in the process depends on getting this foundation right.

For more information on SAS Risk Management Solutions visit the software information page here.

For more information on curated learnings paths on SAS Solutions and SAS Viya, visit the SAS Training page. You can also browse the catalog of SAS courses here.

Find more articles from SAS Global Enablement and Learning here.