Rule sets explained: Building conditional logic for ALM calculations in SAS Viya

[#1]

Have you ever loaded portfolio data into your Asset and Liability Management system only to discover halfway through your analysis that something was off? Maybe interest rates were negative when they should not be, or remaining terms were longer than original terms. These kinds of data issues can throw off your entire risk calculation.

The purpose of this post is to walk you through what rule sets are in SAS Asset and Liability Management on Viya, how they help you catch and fix data problems, and how you can build your own to keep your ALM analysis reliable.

What exactly is a rule set?

In SAS ALM, a rule set is a collection of condition based rules that examine your portfolio data and either flag issues or apply corrections. Think of it as a quality inspector that checks every transaction before it moves through the ALM workflow.

Rule sets are applied to analysis data to define, configure, and manipulate data. They come in two main types: business rules (which include data quality checks) and allocation rules (which handle how values get distributed across segments).

The solution comes with sample rule sets out of the box, but most banks create their own to match their specific data requirements and business logic.

To give you a real world analogy, imagine you run a bakery and every morning you receive a delivery of ingredients. Before you start baking, you check each item. Are the eggs cracked? Is the milk expired? Is the flour the right type? You do not just dump everything into the mixer and hope for the best.

Rule sets work the same way. Your portfolio data is the delivery, and the rule set is your quality check. It examines each transaction, flags anything suspicious, and can even apply corrections before the data moves into your ALM calculations.

The categories of rule sets

SAS ALM organizes rule sets into categories based on their purpose:

• Data quality rule sets check your data for problems. They validate that values fall within expected ranges, that required fields are not empty, and that relationships between fields make sense.
• Adjustment rule sets fix data issues. When you find problems during the data quality check, adjustment rules can automatically correct them based on logic you define.
• Stage allocation rule sets handle how data gets assigned to different stages or categories, useful for regulatory reporting requirements.

What rule sets can check

The power of rule sets comes from the conditions you can define. Here are common types of checks banks implement:

Missing value checks flag transactions where required fields are empty. For example, if a mortgage record has no interest rate, that is a problem you want to catch early.

Range validation ensures values fall within acceptable limits. An interest rate of 150 percent or a negative balance on an asset probably indicates a data entry error.

Consistency checks verify that related fields make sense together. The remaining term should never be greater than the original term. The maturity date should always be after the origination date.

Reference validation confirms that codes in your data match valid values in your reference tables. If a transaction has a product code that does not exist in your product master, something is wrong.

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

Building your first rule set

Let me walk you through a simple example. Say you want to check that all your mortgage transactions have valid interest rates.

First, you create a new rule set and select Business Rules as the type and Data Quality as the category. You link it to your portfolio data definition so the system knows which data fields are available.

Then you add a rule that checks: "If product type equals MORTGAGE and interest rate is blank, then flag as error." You can add another rule: "If product type equals MORTGAGE and interest rate is greater than 1%, then flag for review."

Now every time you run data quality on your portfolio, these rules automatically check every mortgage transaction and report any issues.

Simple rule setup in the SAS Asset and liability Management Solution 

The data quality workflow

Rule sets fit into a specific step in the ALM workflow. After you ingest your portfolio data, you run the data quality script which applies your rule sets. The results appear in the Data Quality Report in Visual Analytics.

From there, you have three choices: approve the data and move forward, reject the data and go back to fix the source, or apply corrections using an adjustment rule set.

If you choose to apply corrections, you select which rule set to use and the system creates a new adjusted portfolio. You then run data quality again on the adjusted data to verify the fixes worked.

This cycle continues until you are satisfied with the data quality and approve it to move forward in the workflow.

Rule sets do not run automatically just because they exist. They are linked to specific scripts that execute during your workflow.

The ALM Data Quality script runs your data quality rule sets. The Data Quality Corrections script runs your adjustment rule sets. You select which rule set to use when you configure the parameters for each workflow task.

This means you can have multiple rule sets for different purposes and choose the right one for each situation. Maybe you have a quick validation rule set for daily checks and a comprehensive one for month end reporting.

View of the Data Quality dashboard after running the rules (SAS Visual Analytics) 

Common use cases for rule sets

In my experience working with banks implementing SAS ALM, here are the most common ways rule sets get used:

• BCBS 239 compliance checks validate that your risk data meets the accuracy, integrity, and completeness requirements from the Basel Committee. The data quality report above shows scores for these categories.
• Pre calculation validation catches issues that would cause the ALM engine to fail or produce incorrect results. Better to find a missing maturity date before the calculation than to debug a failed run.
• Business policy enforcement ensures data meets your institution's specific requirements. Maybe your bank requires all floating rate loans to have a rate reset frequency defined, even if the ALM engine does not strictly require it.
• Audit trail documentation provides evidence that data was checked and approved before being used in regulatory calculations. The workflow tracks who reviewed and approved the data quality results.

One helpful feature is the ability to export your rules to Excel, edit them there, and import them back. This makes it much easier to build or modify large rule sets than clicking through the user interface one rule at a time.

You can also use this to share rule sets between environments or to maintain version control of your rule logic outside the system.

Tips for building effective rule sets

• Start with the most critical checks first. It is tempting to create dozens of rules on day one, but this leads to rule sets that are hard to maintain. Begin with the validations that would cause the biggest problems if missed, then expand over time.
• Use clear naming conventions. Six months from now, you or a colleague will need to understand what "Rule_Check_V7_Final" actually does. Names like "MORT_RATE_RANGE_CHECK" are much more helpful.
• Test with known bad data. Create a small test portfolio with deliberate errors and verify your rules catch them. This is much better than discovering gaps during a production run.
• Document your logic. Add descriptions to your rules explaining why they exist and what business requirement they address. This helps when auditors ask questions.

Conclusion

Rule sets might not be the most exciting part of ALM, but they are one of the most important. They are your first line of defense against data problems that could compromise your risk calculations and regulatory reports.

The key is to think of rule sets as an investment in data quality. The time you spend building good validation rules pays off every single cycle when you catch issues early instead of discovering them in your final reports.

If you are just getting started with SAS ALM on Viya, I encourage you to explore the sample rule sets that come with the solution. They give you a good foundation to understand how rules are structured and what kinds of checks are possible. From there, you can build your own rules tailored to your specific data and business requirements.

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.

For more details on creating and managing rule sets, the SAS ALM documentation provides step by step guidance. And as always, feel free to reach out if you have questions about applying these concepts to your specific situation.

Find more articles from SAS Global Enablement and Learning here.