Introduction   SAS Risk Engine on Viya provides a modern, cloud-native toolkit for financial institutions to measure, manage, and mitigate risk, with simulations as one of its core strengths. Since financial markets are inherently uncertain and shaped by many interacting factors, simulations are essential for modeling this uncertainty and estimating potential losses or exposures under varied conditions. Leveraging high-performance computing, advanced analytics, and flexible deployment, SAS Risk Engine executes large-scale simulations with speed and efficiency. Beyond the capabilities of PROC RISK, it delivers greater flexibility, scalability, and seamless CAS integration, supporting sophisticated analyses on massive datasets and enabling faster responses to regulatory and market changes.   This article illustrates simulation examples using the syntax for riskSim action set, a core part of SAS Risk Engine. With riskSim, users can run sensitivity analyses, generate scenarios, perform historical and Monte Carlo simulations, model market factors stochastically and much more. Sensitivity tests show portfolio reactions to factor shifts, scenarios assess hypothetical shocks, and simulations capture outcome distributions under uncertainty. This article assumes readers have a basic understanding of SAS Risk Engine action sets, sequential workflows, and the use of environment tables, market data, historical data, and scenario states. Together, these components form a robust framework for assessing risk in both normal and stressed market conditions.     For detailed information on the SAS Risk Engine, risk-related action sets, and guidance on interpreting outputs, please refer to the following:   Using the SAS Risk Engine Interface   Programming with SAS Risk Engine A Brief on RiskSim Action Set   The Risk Factor Simulation (riskSim) action set provides a comprehensive framework for generating market states and calculating related artifacts that underpin simulations, sensitivity analyses, and scenario testing in SAS Risk Engine.   The riskSim action set enables you to simulate the behavior of market risk factors. Depending on the analysis type, risk factors can be shocked deterministically (for sensitivity and delta-normal analysis) or stochastically (for covariance and Monte Carlo simulations).   The following table provides an overview of available actions in riskSim action set. The table highlights what each action does and how it fits into practical risk analysis workflows — from preparing data (calcReturns, calcCorrelation), to building shocks (genScenarioStates), to running sensitivity and simulation analyses (genSensitivities, genSimulation), and finally transforming data for modeling (transformRiskFactors).   Action Purpose Example Use Case calcCorrelation Calculates the correlation or covariance matrix of selected risk factors using historical data. Estimate the covariance matrix of USD interest rates and equity indices to use in VaR calculations. calcReturns Computes returns of market factors from historical price or level data. Convert daily closing prices of SP500 into daily log returns for volatility analysis. genScenarioStates Generates market states under user-defined stress or hypothetical scenarios. Create a “RateUp100bp” scenario where USD interest rates shift up by 1% and SP500 falls 10%. genSensitivities Calculates portfolio sensitivities (deltas, gammas) with respect to specified risk factors. Compute how a bond portfolio’s value changes when 6M or 12M USD rates move slightly. genSimulation Produces simulated market states using historical simulation, Monte Carlo, or stochastic processes. Simulate 1000 paths of future SP500 and USD rates using a Geometric Brownian Motion model. transformRiskFactors Applies mathematical transformations to market factors (e.g., scaling, shifting, or decorrelating) through methods. Convert correlated equity and bond returns into uncorrelated principal components.     Specific Examples for Typical Market Risk Analysis   In risk management, analysts rely on a range of quantitative methods to evaluate how market movements, credit events, or external shocks could affect portfolio value. Each technique serves a unique purpose, from sensitivity testing to full-scale simulations. Below is a brief overview of key terms and methods along with sample syntax that form the foundation of market risk analysis. Note that the syntax is limited to riskSim related actions. For full analysis users must use other actions sets like riskMethods, riskRun and riskResults in a logical sequence to get the full picture. Refer to the training programs mentioned in the article or refer to the SAS official Help Documentation for more guidance.     Sensitivity Analysis   Sensitivity analysis measures how much a portfolio’s value changes when a particular risk factor shifts, while all other factors remain constant. This approach helps identify which variables exert the greatest influence on outcomes and provides a direct way to understand exposure to individual risks. For example, measuring how a bond portfolio’s value drops when interest rates rise by 1%, while credit spreads and FX rates are unchanged.   Typical Syntax:   This PROC CAS code is using the riskSim.genSensitivities action from the Risk Simulation (riskSim) action set in SAS Viya.    Illustration of Syntax for Generating Sensitivities.    The riskSim.genSensitivities action in PROC CAS is used to calculate first- and second-order sensitivities of a portfolio or instrument with respect to selected risk factors. In this example, the input environment (Portfolio_envTbl) and current market data (Portfolio_currMktData) are provided, and the analysis is restricted to specific factors—USD_RATES, USD_6M, USD_12M, and USD_36M—to focus only on relevant interest rate points. The options parameter sets the context and calculation controls: asOfDate specifies the valuation date, gammas=TRUE requests second-order sensitivities (convexity), while crossGammas=FALSE excludes cross-factor interactions. The epsilon value (0.002) determines the bump size for finite-difference perturbations, and hlowerbound (0.001) sets the minimum step size for the calculation. The results are stored in two output tables: Portfolio_sensEnv, which contains the updated environment with sensitivity definitions, and Portfolio_sensStates, which holds the generated shocked market states for the chosen factors.     Scenario Analysis   Often described as “what if” analysis, scenario analysis evaluates how a portfolio responds under predefined market conditions. For example, an analyst might model the effect of a sudden interest rate hike or a geopolitical event. By applying these scenarios, decision-makers gain insight into potential vulnerabilities and resilience under stress. Another simple example is estimating portfolio losses if oil prices spike by 20% due to a geopolitical shock.   Typical Syntax:   This code uses the riskSim.genScenarioStates action in SAS Viya is used to generate stressed or shifted market states (scenarios) based on specified factors and shock definitions. Note that risk factors and shock definitions are usually done using tools like SAS Risk Factor Manager.  This is often used for scenario analysis such as “what happens if rates shift up 100bps” or “what if equity falls 10%. The  riskSim.genScenarioStates action can simply read the tables and bring it to your analysis. Note that the action in itself is powerful and has the capability to compute variables based on a custom code as well. For more information and full syntax details click here.   The following code is a sample syntax for simply reading scenario input tables and bring them to your analysis.   Illustration of Generating Scenario States    This PROC CAS code uses the risksim.genScenarioStates action to generate scenario states for risk simulation. It takes a current market environment from the Portfolio_envTbl table and market data from the Portfolio_currMktData table as inputs. The scenarios block specifies a scenario input table (Portfolio_scenarios) containing predefined scenario perturbations, sets the analysis date (asOfDate) as January 01, 2025, and specifies an output table (Portfolio_scenStates) to store the generated scenario states, with replication=0 indicating only a single replication is written. The envOut parameter defines Portfolio_scenEnv as the output table to store any environment-related results from the action. In short, this code combines market data, environmental settings, and scenario and related perturbation definitions to produce a set of scenario states and related environment outputs for further risk analysis.     Historical Simulation   Historical simulation uses actual past market data to model possible future outcomes. It assumes that if similar conditions recur, portfolio values will change in ways consistent with historical patterns. This method is intuitive and data-driven, though it depends heavily on the relevance of past events to future market conditions. For example, recalculating a portfolio’s value using daily market moves from the 2008 financial crisis to see how it would perform under similar conditions.   Typical Syntax:   This PROC CAS code uses the riskSim.genSimulation action to generate simulated market states for risk analysis using historical simulation.   Illustration of Historical Simulation    This PROC CAS code uses the riskSim.genSimulation action to generate simulated market states for risk analysis. It takes current market data (Portfolio_currMktData) and historical data (Portfolio_histData) as inputs and produces simulated environments and states for further valuation or stress testing. The results are written to two outputs: an updated environment table (Portfolio_envSim), which stores simulation configuration details, and a scenario states table (Portfolio_scenStates), which contains the generated simulated paths and replaces any existing data. Simulation behavior is controlled by the options: nHorizons=4 specifies the number of forecast horizons, nDraws=101 sets the number of simulation paths, and seed=54321 ensures reproducibility by fixing the random number generator. The asOfDate marks the starting point of the simulation (January 1, 2025), interval='DAY' defines daily time steps, and analysisType='HISTSIM' indicates that historical simulation is used, meaning scenarios are generated by resampling historical market data instead of relying solely on statistical modeling.     Scenario Simulation   Scenario simulation combines the flexibility of scenario analysis with the statistical rigor of simulation. Instead of using historical data or purely random draws, it models portfolio outcomes based on a user-specified distribution of possible market movements. This approach allows analysts to design simulations that reflect forward-looking expectations or expert judgment. For example, modeling portfolio outcomes under a hypothetical distribution where equity markets have a 40% chance of a 10% drop and a 60% chance of a 5% rise.   Typical Syntax:   The riskSim.genSimulation action in PROC CAS is used to generate simulated market scenarios for risk analysis. In this example, the code creates multiple future market states based on current and historical data, with controlled randomness and variance reduction techniques.   Illustration of Scenario Simulation    This PROC CAS code runs the riskSim.genSimulation action to generate simulated market states using both current and historical market data. The action takes Portfolio_currMktData as the current market input and Portfolio_histData as the historical reference data, then produces two outputs: an updated environment table (Portfolio_envSim) that stores the simulation setup, and a states table (Portfolio_scenStates) that contains the simulated scenarios, replacing any existing data. The simulation settings are defined in the options block: nHorizons=4 specifies four forecast points into the future, nDraws=101 generates 101 random simulation paths, and seed=54321 ensures reproducibility of results. The asOfDate sets the simulation start date to January 01, 2025, and interval='DAY' defines daily simulation steps. Unlike the historical simulation example, this code uses the Mersenne Twister random number generator (generator='TWISTER') to create simulated draws and enables useAntithetic=TRUE, which applies variance reduction by pairing random draws with their opposites to stabilize simulation outcomes.     Monte Carlo Simulation   Monte Carlo simulation employs statistical models to generate a wide range of potential future market movements. By running thousands or even millions of randomized trials, analysts can estimate the probability distribution of portfolio value changes. For example, running 1000 randomized paths of equity price and volatility changes to estimate the distribution of portfolio returns. Unlike historical simulation, Monte Carlo simulation can incorporate complex correlations and non-linear risk factors, but it requires strong modeling assumptions.   Typical Syntax:   This PROC CAS code uses the riskSim.genSimulation action to generate simulated market states with enhanced flexibility by including a stochastic process specification table.   Illustration of Monte Carlo Simulation    The inputs are current market data (Portfolio_currMktData), historical data (Portfolio_histData), and process specifications (Portfolio_processSpecs), which define the stochastic models—such as Geometric Brownian Motion or Hull–White—that drive the evolution of risk factors. The outputs include an updated environment table (Portfolio_envSim), which stores the simulation configuration, and a scenario states table (Portfolio_scenStates), which contains the generated scenarios and replaces any existing table with the same name. Simulation options specify four forecast horizons (nHorizons=4), 1000 random draws (nDraws=1000), and reproducibility through a fixed random seed (seed=54321). The asOfDate is set to January 01, 2025, with a daily interval (interval='DAY'). The simulation uses the Mersenne Twister random number generator (generator='TWISTER'), and variance reduction is enabled through antithetic variates (useAntithetic=TRUE), which improve the stability and efficiency of simulation outcomes. The key highlight of the above method is usage of stochastic process specification table.   Example of Stochastic Process Specification Table   Consider the following code: Illustration of Stochastic Specification Table    This DATA step creates the stochasticProcessSpecs table in the CASUSER caslib, which defines the stochastic processes and their parameters for different risk factors. Each row specifies a model (such as Geometric Brownian Motion, Brownian Motion, Cox–Ingersoll–Ross, or Vasicek), the associated risk factor (e.g., HPI, VIX, DOW, SP500), and parameter values like drift, volatility (sigma), mean, or mean reversion rate. These specifications tell the riskSim.genSimulation action how to evolve each risk factor over time when generating simulated market state.   The following table provides an overview of stochastic process or stochastic models supported in the riskSim action set.   Process Description Key Parameters Simple Example Brownian Motion (BM) A random walk with continuous paths and normally distributed increments. Drift (trend), σ (volatility). Stock price moving randomly with no mean reversion: S(t) = S(0) + drift·t + σW(t) Cox–Ingersoll–Ross (CIR) Mean-reverting process with strictly non-negative values (used for interest rates). Mean reversion rate, long-term mean, volatility. Short-term interest rate pulled toward 5% but fluctuates randomly above/below it. Geometric Brownian Motion (GBM) Multiplicative Brownian motion, ensures positive values (commonly used for stocks). Drift, σ (volatility). Stock price evolving lognormally: S(t) = S(0)·exp((μ−σ²/2)t + σW(t)) Hull–White One Factor An extension of Vasicek with time-dependent parameters; used for term structure. Mean reversion, volatility, time-dependent drift. Interest rate curve where short rate reverts to a moving mean over time. Ornstein–Uhlenbeck (OU) Mean-reverting Gaussian process, can take negative values. Mean reversion rate, long-term mean, volatility. Commodity price fluctuating around $50, sometimes dipping below zero in the model. Rendleman–Bartter (RB) Exponential Brownian motion with deterministic drift; no randomness in variance. Drift, volatility. Bond price modeled as exponential growth with volatility shocks. Vasicek Mean-reverting Gaussian process for interest rates; can allow negative rates. Mean reversion rate, long-term mean, volatility. Short rate fluctuating around 3%, sometimes going below zero due to normal shocks.   Note that similar capabilities also exist in a Python based environment for SAS Risk Engine. To learn more about how Python and SAS Risk Engine interact, click here.      Conclusion   The riskSim action set in SAS Risk Engine provides a powerful and flexible framework for conducting comprehensive risk simulations, ranging from simple sensitivity analyses to advanced stochastic and Monte Carlo modeling. By combining cloud-scale computation in SAS Viya with a wide suite of simulation and scenario-generation tools, financial institutions can efficiently support activities like assess portfolio exposures, stress test against extreme events, and model future uncertainty with greater accuracy. The examples in this article illustrate how riskSim actions—such as genSensitivities, genScenarioStates, and genSimulation—which fits into an end-to-end workflow for robust market risk management. Ultimately, SAS Risk Engine continues to empower analysts to move beyond static risk measurement toward dynamic, forward-looking insights that support more informed decision-making in today’s volatile financial landscape.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   The SAS Viya platform enables seamless integration between open-source technologies and enterprise systems for scalable, agile analytics. Organizations in finance, insurance, banking, and telecommunications that began their analytics journey with open-source tools often require advanced analytics and risk modeling. Integrating Python or R with SAS Risk Engine enables them to combine open-source flexibility with SAS’s scalable, enterprise-grade risk analytics to meet regulatory, operational, and strategic objectives.   This article demonstrates how Python—a leading open-source language—can be integrated with the SAS Risk Engine on Viya. It presents sample syntax using the SAS Scripting Wrapper for Analytics Transfer (SWAT) package for performing common SAS Risk Engine tasks within a Python environment. The article assumes a basic understanding of the SAS Risk Engine and its associated action sets used for risk analytics. The focus of the article is the syntax rather than interpretation of the analytical outputs.       For detailed information on the SAS Risk Engine, risk-related action sets, and guidance on interpreting outputs, please refer to the following:   Using the SAS Risk Engine Interface   Programming with SAS Risk Engine   The SWAT Package:  The Bridge   The SAS Scripting Wrapper for Analytics Transfer (SWAT) is an open-source package that enables seamless interaction between programming languages like Python and R and the SAS Cloud Analytic Services (CAS) server. SWAT allows users to submit CAS actions, transfer data, and retrieve results within their native coding environments, combining the flexibility of open-source tools with the high-performance analytics of SAS Viya.   Available for Python and R via the SAS Software GitHub page—and for Lua through the SAS Lua Developer site—SWAT offers platform-specific versions along with system requirements, prerequisite packages, and example notebooks to simplify setup and usage.   With syntax that mirrors native open-source code, SWAT makes it easy to manipulate, analyze, and visualize CAS in-memory tables using familiar Python or R commands. This integration enhances productivity and streamlines workflows, allowing data scientists and analysts to harness the full power of SAS Viya without leaving their preferred environments.    Illustration of Open Source, SWAT and CAS Interaction.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   For example, with SWAT, you can apply familiar functions like head() to a CAS table to preview its first few rows. In R, you can use dim() and in Python, the shape attribute to view the dimensions of a CAS data table—just as you would with native data frames. Additionally, results from CAS actions can be saved to variables by setting the result parameter, and you can easily access fields from these results using the $ operator in R or bracket notation in Python. This consistency with open-source syntax makes it easy to adopt and integrate SAS Viya into existing analytical workflows.     Risk Action Sets for SAS Risk Engine   A risk action set is a structured collection of actions, each representing a specific task grouped by related functionality. It can be viewed as a package, with its individual actions functioning as executable routines that the SAS Cloud Analytic Services (CAS) server exposes to client applications. These actions enable streamlined access to risk-related capabilities within the broader SAS Viya analytics environment. Note that these action sets are equally valid while using Python. However, there are a few changes in the syntax when it comes to the usage of open source along with SWAT package.   The following table presents the standard action sets available in CAS for SAS Risk Engine.   Action Set Example Actions Description riskMethods add Load method programs into CAS tables for use by other CAS risk actions. riskResults cubeinfo Aggregate or consolidate your risk analysis results and use the results to generate additional information. details query riskRun aggregateToBasecell Perform risk analyses (for example, counterparty risk analysis and portfolio valuation) and manage risk environments. evaluatePortfolio join loadEnv loadValues promoteEnv saveEnv updateEnv riskSim genScenarioStates Compute returns or residuals from historical data, estimate a covariance matrix, and generate simulated market states.   genSensitivities   genSimulation     What Changes When You Use Python?   When the logic, workflow, and objectives remain consistent, the differences between the standard SAS Risk Engine and its Python-integrated counterpart are minimal—limited primarily to minor syntax variations. The following table presents a high-level comparison of these two approaches, highlighting key similarities and distinctions in their implementation.   Purpose Standard SAS Risk Engine Python integrated SAS Risk Engine Connectivity and Data Access CAS and LIBNAME statements SWAT based CAS connectivity functions Performing Risk Analytics Predominant use of PROC CAS for using risk related action sets and related syntax for actions. Predominant use of loadActionSet (SWAT functionality) for using risk related action sets and related syntax for actions.     The Typical Workflow   Here is a typical workflow for SAS Risk Engine for using action sets.   Illustration of Steps in a Typical SAS Risk Engine Usage.      1. Establish a CAS Session   In SAS you use CAS and LIBNAME statement to establish a connection for CAS. In Python, the syntax changes. You use import for SWAT package import and swat.CAS function for CAS connection. Here are the examples:    Illustration of Making CAS Connections      2.Create and Load Data Plus Generate Environment Table   In SAS, you create several data sets using a data step as one of the options. You should create or load tables for instrument or portfolio data, market data and scenario data. The environment table is created using a data step. In Python, you create several data sets using a dataStep action set via SWAT package. Here again, you must create or load tables for instrument or portfolio data, market data and scenario data.  Here is an example.   Illustration of Table Creation      3. Apply Methods   In SAS, you apply methods using PROC CAS and riskMethods Add action. Here is an example.   Illustration of Adding a Method in SAS    In Python, you need to load the action set riskMethods .The syntax do not change heavily. Look at the code snipped below.   Illustration of Loading Action Set and Adding a Method Code in Python via SWAT      4. Generate Market States   In SAS, you use PROC CAS and risksim,genScearioStates for generating market states. Here is an example.   Illustration of Generating market States in SAS    In Python, you load the action set riskSim and use the riskSim.genScenarioStates action. Again, the syntax do not change heavily.   Illustration of Adding Action Set and Generating Market States in Python via SWAT   5.Evaluate the Portfolio   In SAS, you use PROC CAS and riskrun.evaluatePortfolio action for evaluating the portfolio. In Python, you load the action set riskRun and use the riskrun.evaluatePortfolio action.   Here is an example.   Illustration of Evaluating Portfolio in SAS and Python    6.Query the Results   In SAS, you use PROC CAS and riskresults.query action for querying the results. In Python, you load the action set riskResults and use the riskresults.query action.   Illustration of Querying the Results in SAS and Python    Using Python in SAS Viya's open-source integration allows data scientists to leverage existing Python code and libraries for tasks such as visualization, custom analysis, and charting, while seamlessly accessing SAS Viya’s high-performance in-memory analytics through the SWAT package—particularly beneficial for advanced applications like risk analytics.   Note that as a user you may use SAS Studio for your SAS codes or Python codes. You can also configure a JUPYTER notebook for running your SAS or Python codes. The latter is preferred more with open-source languages. Here is sample depiction.   Illustration of SAS Studio and Jupyter Notebook as Programming Interfaces.      Conclusion   In conclusion, the integration of open-source tools like Python with the SAS Risk Engine on the SAS Viya platform offers a powerful and flexible framework for modern risk analytics. Leveraging the SWAT package as a bridge, users can perform end-to-end risk management workflows—ranging from data preparation and environment setup to portfolio evaluation and results querying—directly within their preferred open-source environment. While the core logic, analytical workflow, and functionality remain consistent between traditional SAS and Python implementations, the syntax is tailored to align with open-source coding conventions. This seamless integration not only enhances agility and collaboration across teams but also maximizes the strengths of both open-source innovation and SAS's robust enterprise capabilities, making it an ideal approach for scalable, governed, and high-performance risk analytics.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   The SAS Risk Engine on SAS Viya is a robust, scalable platform designed to support advanced risk analytics tailored to the evolving needs of financial institutions. One of its key strengths lies in its extensibility—users can enhance the platform’s capabilities by integrating custom code, allowing organizations to align risk analytics with their specific business objectives.   This article provides developers, administrators, and implementation specialists with a structured overview of the Execute Custom Code node within a SAS Risk Engine pipeline. It is targeted towards the readers who possess a foundational knowledge of SAS programming including CAS language, along with a working familiarity with the SAS Risk Engine environment. The Execute Custom Code node an essential tool for users seeking to extend the native functionality of SAS Risk Engine and incorporate specialized logic directly into their analytical workflows.      You can obtain more information on SAS Risk Engine using the following links.   Using the SAS Risk Engine Interface   Programming with SAS Risk Engine   Overview of Nodes in SAS Risk Engine   The SAS Risk Engine leverages pipelines to execute risk analytics in a structured and efficient manner. A risk pipeline is a modular, repeatable workflow that facilitates the development of customizable risk analyses. Through pipelines, users can perform a wide range of tasks, such as creating risk environment tables, scoring counterparties based on scenario perturbations or simulated market conditions, evaluating risk portfolios under various scenarios, conducting cash flow analyses, and interactively exploring results across different levels of aggregation.   A risk pipeline is composed of nodes, each representing a modular, preconfigured unit of analysis. A node can be understood as a prewritten, executable component that is readily accessible through the user interface and can be seamlessly integrated into a pipeline. Users can add nodes by dragging and dropping them from the Node pane on the left side of the interface and then configure their properties using the Properties pane on the right. This modular approach enhances flexibility and efficiency in designing and executing complex risk analytics workflows. The following table describes each node briefly:   Node Group Node Description Data Nodes Portfolio Data Adds instrument data and counterparty data to the analysis Data Nodes Market Data Adds market data, scenario perturbations, and risk factor variables to the analysis. Action Nodes Simulate Risk Factors Adds simulated market states to the analysis. Action Nodes Score Counterparties Scores counterparties based on scenario perturbations or on simulated market states. Action Nodes Evaluate Portfolio Evaluates a risk portfolio based on scenario perturbations or on simulated market states. Action Nodes Execute Custom Node Executes any user-defined SAS code along with the pipeline code Output Nodes Query Results Aggregates or consolidates the analysis results or uses the results to generate additional information. Output Nodes Manage Environment Saves the risk environment table, the methods tables, and the internally generated tables in SASHDAT format in the output location that you specified in the pipeline’s properties.   The following figure illustrates an example of SAS Risk engine pipeline along with the Node pane:     Illustration of Nodes Pane and Pipeline in SAS Risk Engine.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.     Execute Custom Code Node   This node within a SAS Risk Engine pipeline provides a powerful mechanism for injecting user-defined logic at chosen and specific points in the workflow. This node allows developers and analysts to write and execute custom SAS code directly within the pipeline, offering maximum flexibility to tailor the analytical process to specific business or technical requirements.   One of the primary use cases for this node is updating or modifying the environment table—a task that cannot be accomplished using standard nodes and requires direct code intervention. Additionally, the Execute Custom Code node can be used to create new output datasets, restructure or reformat data produced by earlier nodes, or apply custom transformations and calculations that go beyond the capabilities of prebuilt components.   A notable example of its application is in the generation of simulated states for risk factor analysis. The Simulate Risk Factors node expects input in the form of a table that already contains simulated states. However, in many cases, these states must be derived from scenario data. The Execute Custom Code node facilitates this by enabling the use of CAS (Cloud Analytic Services) actions or other SAS code within the pipeline interface to programmatically generate simulated states from predefined scenarios. These generated states can then seamlessly feed into the Simulate Risk Factors node, enabling end-to-end scenario-based risk simulations within the pipeline environment.   The following figure illustrates various placements for the node.     Illustration of different placements for the node depending on your need.     Types of Codes Supported   Regardless of the specific objective you intend to achieve with the Execute Custom Code node, the platform provides a range of flexible options to accommodate your needs. This node is designed to support a variety of coding approaches, allowing users to tailor the logic according to the requirements of their risk analysis workflow.     Types of Codes Supported by SAS Risk Engine    Within the node, you can write traditional DATA step code, which is ideal for row-wise data manipulation, filtering, merging, or creating new variables. The DATA step is particularly useful when working with structured data transformations that are familiar to most SAS programmers.   In addition, you can utilize CAS (Cloud Analytic Services) actions to take full advantage of the high-performance, distributed computing capabilities of SAS Viya. CAS actions allow for efficient processing of large datasets in memory, enabling you to perform complex operations such as aggregations, simulations, or model scoring across distributed environments with minimal latency. This is especially beneficial when working with high-volume risk data.   Furthermore, the Execute Custom Code node supports the use of legacy PROC RISK, a procedure for performing risk-related computations such as scenario analysis, value-at-risk (VaR), and expected shortfall calculations. Integrating a PROC RISK step like to migrate environment tables from your older environment within the node allows you to execute advanced risk analytics that are not readily available through standard nodes.   If you have enabled Python integration in your environment, the node can also be utilized to submit Python code in risk pipelines. For more details, refer to the following link:   SAS Risk Engine Help Documentation: Calling External Python Functions   Together, these options—DATA step, CAS actions, PROC RISK and Python—provide a powerful toolkit within the Execute Custom Code node, enabling users to implement tailored, efficient, and scalable custom logic. This versatility makes the node an essential component for extending the analytical capabilities of the SAS Risk Engine and adapting pipelines to meet the specific risk assessment needs of an organization.     Supporting Macros   It’s important to note that when you use the Execute Custom Code node, your coding process is supported by a robust set of predefined macros that significantly streamline development. These macros are automatically populated and readily available within the node, allowing you to focus more on the logic of your analysis rather than on manual configurations or hardcoding values.   The available macros provide access to a variety of essential elements needed during pipeline execution. This includes dynamic references to key table names, input and output library references, analysis dates and other critical metadata. By using these macros, you can write cleaner, more maintainable, and more portable code that adapts seamlessly to the pipeline’s context and execution environment.   For example, instead of hardcoding a table name or date, you can use a macro variable that dynamically resolves at runtime, ensuring your code remains consistent and reusable across different executions and scenarios. This macro support enhances both efficiency and accuracy, making the node not only flexible but also developer-friendly in complex risk analytics workflows. The following table lists examples of most of the available macros:   Macro Brief Description RE_PIPELINE_NAME It stores the value of the name of your current pipeline. RE_CAS_SESSION_NAME It stores the value of the name of your current CAS session name. RE_ASOF_DATE It stores the value of your analysis date. It refers to the run-as-of date that is set as part of the pipeline properties. RE_OUTPUT_CASLIBREF It stores the value of your CAS library reference for storing output. RE_OUTPUT_CASLIB It stores the value of your CAS library for storing output. RE_ENVTABLE_CASLIB   It stores the value of your CAS library for storing input environment table. This library is defined at the time of creation of your pipeline. RE_ENVTABLE_TABLE   It stores the value of your input environment table name. This table is created at the time of creation of your pipeline. RE_ENVOUT_CASLIB   It stores the value of your CAS library for storing updated or output environment table. RE_ENVOUT_TABLE   It stores the value of your updated or output environment table name   For the complete list of macro variables refer to the SAS help documentation for the SAS Risk Engine. The Code node has only one property, which is the Open Code Editor button.  It opens a window for you write your code or paste in any code that you have written outside of the solution.   On the left side of the window is a list of macro variables that are available for you to use within your code.     Illustration of the Code Editor and available macros in SAS Risk Engine.     Example: Creating an output table at different location   Consider the following code.      Illustration of a SAS Code for handling Results Data.   The first part of the code is dedicated to setting macro variables, which are used throughout the remainder of the script. The subsequent portion of the code utilizes CAS actions to manage data within the SAS Viya environment. Specifically, the tableExists action checks whether the statistics table already exists either as an in-memory table or as a SASHDAT file in the Public caslib, thereby preventing errors that could occur from attempting to overwrite an existing table. If the table does not exist, the save action is used to persist the data as a SASHDAT file. Finally, the loadTable action brings the saved table into memory within the Public caslib, making it available for use in downstream steps of the pipeline. Such a code is usually placed after Query Results node in a pipeline.     Example: Updating an Environment Table   Consider the following code. It presents a way of using supported macro variables and IF THEN statements with DO groups in a data step to modify the environment table. It adds attributes to risk factors rf1 and rf7 in the environment table.     Illustration of a SAS Code for adding attributes to an environment table.   Such a code is usually placed before Evaluate Portfolio node in a pipeline.   Note that this example assumes a basic understanding of the environment table related concepts. For more information refer to the following link:   SAS Risk Engine Help Documentation: Overview of Risk Environment Tables     A word of Caution   The Execute Custom Code node cannot create new tables for use by later nodes. You have two options: overwrite an existing table (not ideal if it’s needed elsewhere) or use a predefined table that’s empty or filled with dummy values. The node can then write output into this table. Such dummy or empty tables can be easily created using a DATA step in SAS Studio.     Conclusion   In summary, the SAS Risk Engine on SAS Viya stands out for its robust support for custom code integration, empowering organizations to tailor risk analytics to align with their specific operational and strategic needs. This article has provided an overview of the Execute Custom Code node, detailing its core features, supported macros, and example codes to demonstrate its practical application within risk analysis workflows. The ability to embed custom logic directly into the pipeline enhances the platform's versatility, positioning the Risk Engine not merely as a predefined solution, but as a highly adaptable framework capable of evolving alongside the dynamic demands of modern risk management.               Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   The SAS Risk Engine on SAS Viya stands as a powerful, scalable platform engineered to deliver modern risk analytics tailored for the complex needs of financial institutions. As an integral part of SAS’s comprehensive risk management suite, it harnesses the agility of Viya’s cloud-native architecture. Among its many capabilities, the SAS Risk Engine allows users to extend its functionality by incorporating custom functions, enabling organizations to align risk analytics precisely with their unique business requirements.   This article offers the developers, administrators and implementers a guided overview of the process involved in creating and integrating a custom SAS function within the SAS Risk Engine. It is intended for readers with a foundational understanding of SAS programming, SAS functions and a working familiarity with the SAS Risk Engine environment.       You can obtain more information on SAS Risk Engine using the following links.   Using the SAS Risk Engine Interface   Programming with SAS Risk Engine SAS Functions in SAS Risk Engine   In the SAS Risk Engine, functions play a critical role in supporting pricing methodologies and enabling the creation of user-defined statistics. These functions are organized into function sets, which can be invoked within risk methods and model groups to extend analytical capabilities. Included with the SAS Risk Engine is a built-in function set named RE_BASE_FUNCTIONS. This core library offers essential tools such as random number generators, piecewise-linear interpolation utilities, and functions for computing both the cumulative distribution function (CDF) and its inverse.   However, there may be situations where the out-of-the-box functions provided by SAS do not fully meet your analytical needs. In such cases, you can develop custom functions, much like those created using PROC FCMP. Within a function block, you have the flexibility to embed the necessary logic—using SAS statements and other callable functions—to compute and return the desired result.   Note that SAS Risk Engine supports python and C based functions as well. For more information refer to Help Center documentation using the following link:   SAS Risk Engine Help Documentation   Here is a simple example of a custom SAS function along with the general syntax.     Illustration of a simple custom SAS function.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.     At a minimum, a custom function must define the following required arguments:   function-name – the name of the function you are creating argument – the input(s) the function will accept expression – the logic or formula that defines the function's output   In addition to these core components, optional arguments can also be specified to enhance the function’s flexibility or tailor its behaviour to specific use cases.   For a comprehensive list and details on using optional arguments, please refer to the Help Center documentation.     Steps to Add a Custom Function   Primarily there are five steps:   Write and Test: Write the code and test the function using SAS Studio Create function set: Create a function set in the SAS Risk Engine Add: Add your code to the function set Apply: Use the function in your method code. Test: Test by running a task in a cycle    Illustration of steps for adding a custom function   Write and Test   You may add your custom function code directly to SAS Risk Engine. However, is always suggested to write your custom function code in SAS Studio. Test it for the logic and syntax before you add it to SAS Risk Engine. You may choose to use PROC FCMP or PROC COMPILE. Here is an example of a simple function in SAS Studio editor along with a sample code to test the function.      Illustration of a SAS Program for a Custom Function in SAS Studio   In the example above, we define a custom function called simple_interest using PROC FCMP in SAS. This function calculates simple interest based on the formula (Principal × Rate × Time) / 100 and is stored in a custom function library. We then test the function by calling it in a DATA step, passing sample values for principal, rate, and time. The result is stored in a new variable and printed using PROC PRINT, verifying that the function returns the correct interest amount.   Create a Function Set   This step is easy. It enables you to create a placeholder for your custom function or functions within the SAS Risk Engine. It not only helps you to store your function code, but it also helps the solution to recognize and make the function available to your environment wherever necessary.   To create a new function set, navigate to the Function Sets page and   Click the New Function Set In the window that appears, provide a unique name in the Name field. Choose the appropriate language from the drop-down menu—SAS, C Language Prototype, or Python—depending on the type of functions you plan to include. Optionally, you can add tags (comma-separated) to help organize and filter your function sets and enter a description for better clarity. Click OK to create the set, which will take you to the function set details page. From there, you can begin adding functions, with options tailored to the language you selected.   Illustration of New Function Set Window.   Add   Add your code to the function set. You can use the original code created in SAS Studio. You need to include only the function statement. PROC FCMP and Quit statements are not required here.   In the following example, The OtherRetailRW or RevolvingRetailRW function calculates the capital requirement (risk weight) for retail credit exposures under the Basel II framework using Probability of Default (PD) and Loss Given Default (LGD) as inputs. It applies PD flooring and capping, computes a correlation factor (R), and uses the Vasicek model to estimate unexpected loss (K). The business purpose is to determine regulatory capital that banks must hold against credit risk, ensuring compliance and effective risk management for retail portfolios. Note that there are other similar functions included in the code not shown in the screenshot below.     Illustration of Adding Code to a Function Set.   Apply   In this step, you incorporate the function into your method code, which serves as the core logic for risk analytics. SAS solutions that leverage the SAS Risk Engine—such as SAS Stress Testing, SAS Allowance for Credit Loss, and others—commonly utilize these functions within risk methods or method codes defined in model groups for a specific project. Additionally, you can embed these functions in custom code tailored to the unique requirements of your project.   Here is an example of custom risk weighted custom functions being used in SAS Stress Testing solution.     Illustration of Using a Custom Function in a Method Code.   Test   Testing can be performed by running a specific task within any standard or custom cycle that includes the method code, allowing you to validate the function’s behavior within a complete risk workflow. The SAS Risk Engine automatically generates execution logs for any method code it runs, which can be accessed from the main pipeline page.     Illustration of a Successfully Executed Pipeline.   Additionally, each SAS solution presents these logs in text format and provides results in various formats, such as raw CAS tables or both standard and custom reports in SAS Visual Analytics. As a user, you can review the execution logs to identify any runtime errors and examine the output tables and reports to detect potential logical issues in the custom function.       Conclusion   In conclusion, the SAS Risk Engine on SAS Viya distinguishes itself with the powerful ability to integrate custom functions, offering organizations the flexibility to tailor risk analytics around their unique business requirements. This article has walked through the process of creating and embedding a custom SAS function within the SAS Risk Engine, serving as a practical companion for developers and solution implementors working across diverse SAS solutions within financial institutions. It is this blend of adaptability and precision that makes the Risk Engine not just a tool, but a strategic asset in the evolving landscape of risk management.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   SAS Risk Stratum empowers you to tailor screens for the solutions it supports, ensuring a seamless and customized user experience. Whether you're working with SAS Model Risk Management, SAS Governance and Compliance Manager, SAS Solution for IFRS 17 or any other solution based on Risk Stratum, the process of screen modification remains consistent, as all these solutions leverage the SAS Risk Governance Framework as their user interface. This article aims to provide a comprehensive overview of the steps required to customize a selected screen by incorporating additional fields, enabling end users to input values dynamically while using the solution. You must have a familiarity with SAS Risk Governance Framework and basic knowledge of XML to perform the activities and appropriate administrator level access to the SAS platform.       You can obtain more information on SAS Risk Governance Framework and  SAS Risk Stratum using the following links.    SAS Risk Governance Framework Solution Overview   Data Preparation, Configuration, and Administration in SAS Risk Stratum   Screen Definitions   Screen definitions in solutions supported by SAS Risk Stratum uses XML for handling the underlying display logic. XML is a powerful yet easy language which uses simple tags to carry the logic for any screen used by SAS solutions. Note that XML (Extensible Markup Language) is a structured, self-descriptive data format used for storing and transporting data. It consists of root tags that encapsulate the entire document, nested elements that represent hierarchical data, and attributes that store metadata within elements. Additionally, DTD (Document Type Definition) defines the structure, rules, and allowed elements in an XML document, ensuring data consistency.   The following table provides an example of tags used most across various screen definitions across the solutions.   Tag Description <ui-definition> Root element defining the UI configuration, with attributes like id and type. <title> Specifies the title of the UI definition. <screen> Represents a screen layout within the UI, identified by an id attribute. <initialize> Defines initialization logic, setting default values for variables and components. <set> Assigns a value to a variable or field, often using conditional logic. <if> Specifies a conditional block that executes based on a test expression. <field> Defines a UI field, with attributes such as name, type, component-name, default, visible, and required. <label> Specifies the label for a field or UI element. <message> References a localized message key for display text. <param> Defines parameters for components, using name and value attributes. <on-change> Specifies an action to be taken when the field value changes. <refresh> Refreshes a specified UI component when triggered. <tab-section> Groups multiple tabs together within the UI. <tab> Represents a UI tab, identified by an id, containing fields and components. <validation> Defines validation rules for a field, ensuring correct data input. <errmsg> Specifies an error message to display when validation fails. <finalize> Marks the finalization block, potentially used for cleanup or final adjustments   Here is an example of screen XML code for Users screen in SAS Risk Governance Framework. Note that this screen is same for any SAS solution based out of SAS Risk Stratum. To edit any screen, you may use the Edit Screen Definition icon at the top right corner of any screen.   Figure 1: Illustration of XML code for a screen.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   You can also access and manage screen definitions through the Administration module or menu by navigating to the Screen Definitions tab. This tab allows you to edit, download, upload, or delete any screen definition as needed. However, to perform these actions, you must have administration-level access within the SAS Risk Governance Framework.   Figure 2: Illustration of Screen Definitions tab under Administration menu.     Steps to modify a screen definition   Primarily there are five steps:   Add fields to the data base Add field labels in Custom Message Properties Download or edit on screen Add XML code related to the fields and upload plus activate the screen Open the screen to verify and test the newly added fields   Figure 3: Illustration of steps for modifying a screen definition.     In this article, we take an example of modifying the screen Create Risk for the Risk Management module in SAS Governance and Compliance Manager. Note that the business object Risk is known as CustomObject96 in SAS Risk Governance Framework.     Add Fields   To capture the required fields, you must first ensure they exist in the database. This can be seamlessly achieved using the Data Loader functionality in the SAS Risk Governance Framework. The data is imported through MS Excel templates, which can be conveniently downloaded from multiple locations within the solution. One efficient way is to navigate to the Administration module, click on the Data tab, and select "View Available Loaders" to download the appropriate loader for your screen.   Figure 4: Illustration of Data Loader facility.     Each of the Excel template has a specific sheet name and column names. You can learn more about these Excel template and related topics by referring to the following link.   Administration and Customization Guide   The Excel template we are using in this article defines two fields using four excel sheets. The two fields are:   x_empDep, which captures employee department from a drop-down list.   x_empId, which captures employee ID as string.   Here is a brief description of the sheets.   Sheet Name Description CustFieldDefns It defines fields for different objects. It stores custom field definitions, including object name, field name, type, length, and description. NamedLists It contains predefined lists that can be used for the fields with type OPS (field with multiple possible options, like a list of departments) NamedListMappings It connects specific object fields (in CustFieldDefns) to the corresponding lists (in NamedLists) NamedListTranslations provides values with codes & descriptions) for each list option for the lists defined (in NamedLists)   Following figures provide illustrations for these sheets. Ensure that you carefully observe the column names and values in these sheets, as they follow a predefined structure. It is crucial to retain the original sheet and column names in these standard templates without any modifications. Your task is solely to add the corresponding data while maintaining the integrity of the existing format.   Figure 5: Illustration of CustFieldDefns and NamedLists sheet.      Figure 6: Illustration of NamedListMappings and NamedListTranslations sheets.     Uploading of the Excel is very simple. You must click Browse under Data tab for loading and click Load. You must select Test Mode radio button first and if there are no errors then select Process All Records mode. Check the Figure 4 above for these options.     Add Labels   SAS Risk Stratum uses a specific text file called Custom.MessageProperties which is used to store various labels used across the screens. The file is available on SAS Content Server and can be accessed using a browser or a free application like DAVTree.   You must add your labels for your fields in the file. Using DAVTree you can simply open the file and edit the file to update your changes. Following is an example of the code or label that should be added in our case.   customObject96.field.x_empId.displayName.txt = Emp ID customObject96.field.x_empDep.displayName.txt = Emp Department   Following figure shows the typical location of the file CustomMessage.Properties using DAVTree.   Figure 7: Illustration of DAVTree utility.     Download or Edit Screen   If the modification is minor, you can edit the screen’s XML directly using the Edit Screen Definition icon. In this step, we will insert the following code into the Risk screen definition at a suitable location of our choice, ensuring the necessary customization is seamlessly integrated.   <field type = "string" name = "x_empId">   <label><message key="customObject96.field.x_empId.displayName.txt" /></label> </field>   <field type = "dropdown" name = "x_empDep">   <label><message key="customObject96.field.x_empDep.displayName.txt" /></label> </field>   This XML code defines form fields with different types and dynamic labels. The first field, x_empId, is a string field (text input) representing an employee ID, while x_empDep is a dropdown field for selecting an employee's department. Both fields use a <label> tag with a message key (customObject96.field...), which fetches display text dynamically for localization and flexibility. The dropdown field has predefined options, though you need not specify here.     Open the Screen and Verify   You must click the appropriate workspace or module and open the relevant screen to see or test the effect of these changes. In our example of modifying the screen for Create Risk page in SAS Governance and Compliance Manager, you must click Risk Management menu and then click Create New icon for creating the new risk.   Figure 8: Illustration of modified screen with custom fields.     Conclusion   In conclusion, SAS Risk Stratum offers a robust and highly flexible approach to customizing screens across various solutions, enabling organizations to create a seamless, intuitive, and user-centric experience. With its adaptability, users can tailor interfaces to meet unique business needs, ensuring that critical data is captured efficiently. This article has provided a structured overview of the key steps required to incorporate additional fields, allowing end users to dynamically input values and interact with the solution in a more meaningful way.   By effectively leveraging these customization features of SAS Risk Governance Framework, organizations can improve decision-making, and align the solution with their evolving requirements, ultimately driving greater efficiency and maximizing the value of their SAS Risk solutions. For more information, use the following link: Administration and Customization Guide.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   The SAS Dynamic Actuarial Modeling Premier solution offers a comprehensive renewal optimization workflow specifically designed to streamline and enhance the process of optimizing price increases for premium renewals. This workflow is tailored to support actuarial teams in analyzing, modeling, and executing pricing strategies that balance profitability with customer retention. By leveraging advanced data analytics capabilities, the workflow provides actionable insights to determine optimal price adjustments during the renewal process, ensuring alignment with both organizational goals and market dynamics.   This article focuses on setting up the optimization model and it assumes that you have a basic level familiarity with terminologies involved in optimization, insurance pricing, SAS Model Studio and SAS Dynamic Actuarial Modeling solution.     You can obtain more information on SAS Model Studio and SAS Dynamic Actuarial Modeling  using the following links.   Machine Learning Using SAS Viya   SAS Dynamic Actuarial Modeling Site Page   SAS Dynamic Actuarial Modeling Support   The Workflow   SAS Dynamic Actuarial Modeling Premier offers a Renewal Optimization Workflow (RENEWAL_OPTIMIZATION_WORKFLOW_<version number>) designed specifically for optimizing price increases during premium renewals.   Following represents the steps involved in the workflow.              Illustration of steps in the Renewal Optimization Workflow.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Below is a concise overview of the main steps and key objectives involved in the workflow.   Task Objectives Supporting Tool Import Data This task loads data into the CAS server, including a Customer Table and a Rate Increase Table:   Customer Table: Contains customer profiles, including protected characteristics, and columns representing rate increases. Each row has an ID to link it to the corresponding rate increase in the Rate Increase Table. Rate Increase Table: Contains IDs and the numeric rate increase iii, along with renewal probabilities for each increase   SAS Data Explorer   Prepare Data This task enables you to validate the input data and map or append any required columns needed for optimization. SAS Scripts Analyze Data This task enables you to analyze information assets, such as data tables, utilized throughout the cycle. SAS Information Catalog Explore Solution This task enables you to explore your optimization results. SAS Visual Analytics Review Results This task enables a senior analyst or actuary to review results SAS Visual Analytics Validates Results This task enables you to filter optimization results based on a retention level or the primary constraint defining the scenario. SAS Scripts   Open Optimization Model Task   The Open Optimization Model task is executed using SAS Model Studio, a powerful platform for advanced analytics and modeling. This task provides the tools and framework necessary to construct a robust optimization model. By leveraging SAS Model Studio's capabilities, users are enabled to define objectives, incorporate constraints, and integrate various data inputs to develop a model that optimally aligns with the organization's goals. This step is essential in ensuring that the optimization process is tailored to address specific business needs, such as balancing profitability and retention.   It is important to note that for an insurance company, increasing premiums too much may result in customers leaving, and too low premiums might result in a loss in net customer value or overall profits. The plan is to use analytics to optimize the premium hike. Optimization helps to deliver a value of premium increase that has low or negligible impact on customer turnover rate.   In the solution, there are four prerequisites for carrying out renewal optimization model related activities. These are as follows:   First, it is necessary to have a churn or renewal model that calculates the probability of churn for a specific customer profile and price. Second, it is necessary to train the model using data from the same rise or decrease range for the price. For instance, if a model is based on data with increases up to 10%, the result for a 12% increase might not reflect actual customer behavior. It might be safer to stay in the known rise or decrease range of data in certain circumstances, or a pilot is required to retrain the model. Third, it is necessary to optimize a curved function with a mathematically possible optimal solution. You should use the function that is most appropriate for your organization. There is no optimum for a linear function. In general, the function is the profit margin function multiplied by the renewal probability. The profit margin function is an estimate of expenses and claims for the next year per customer profile. Fourth, it is necessary that the constraints should avoid overpricing the vulnerable customers and should provide enough increase to the high-cost claimants. You should create constraints that protect vulnerable customers. For example, limit the percentage increase for economically weak customers with specific features. This enables you to avoid overpricing them.   Pipeline Nodes   The task involves configuring the data node by assigning roles, such as the target variable, and setting up the optimization node by defining the objective function, calculated measures, and constraints using the node's property panel.   Illustration of the nodes in optimization pipeline.    The Data node prepares the input data set for analysis by subsequent nodes. In the Data tab, you must review and, if necessary, modify each variable's role, level, and transformation values. For instance, in the sample data, the variable NEW_PREMIUM_AMT is automatically assigned the role of the target variable, but you should verify and adjust roles for your data needs.   Illustration of Data tab for setting up variable roles.    The Pricing Optimization node attempts to find the most advantageous pricing strategy for insurance renewals or other similarly defined optimization problems. The node can be used to optimize multiple metrics. Some examples of metrics that you might want to optimize are the number of customers that are retained, the total amount of retained premium and the measure of profitability for an entire portfolio. The pricing optimization node enables you to set up objectives and constraints for your optimization model.   An Example of Objective Function and Constraints   Here’s an example of how to configure an objective function in the solution. The objective function is represented by the measure Total_NetCustomerValue, which needs to be maximized. To set this up, enter the objective function and associated variables using the Objective Functions Editor, found in the objective function options in the property panel for Pricing Optimization node.   Illustration of objective function and calculated measures.    In this example, an insurance company aims to maximize the profit from its existing portfolio of policies. The company defines the new premium (new_premium_amt) as the previous premium plus an increase. The rate increase table contains the base variable for this increase. The New_Profit is calculated as the new premium minus costs like claims, expenses, and commissions.   To define the objective function, a Net_Customer_Value formula is used, which multiplies the new profit by the probability of renewal (representing expected profit). This process is repeated for all customers, with two key measures: the Net_Customer_Value for each individual customer and the Total_NetCustomerValue, which is the sum of individual values across the portfolio. Note that you must run Data node before proceeding for the configuration of objective function and constraints. You must use the property panel for the Pricing Optimization node to configure the settings. You must provide the appropriate rate increase table in the property panel. The following figure highlights the important parts of the property panel for the node.   Illustration of the property panel for pricing optimization node.    You must click Open Objective Function to open a new window that enables you to define calculated measures and the objective function. Following is a sample of values you enter.   Next, click the Add Calculated Measure (+) icon. For the Variable Name, enter new_premium. Leave the Description blank, as it is optional. In the Code field, input the formula: &previous_premium_amt.*(1 + &increase_rt.).   Illustration of Calculated Measures and Objective Function window with sample values.    You can add constraints as well. As an example, following two constraints to avoid or limit high increase for low premium paying customers e:   For customers with premium amount less than 1000, the increase rate should not be more than 4 percent. This constraint protects low premium customers from a high increase rate. For customer with premium amount greater than 3000, the increase rate should be up to 6 percent. This constraint ensures that higher premium customers have a relatively higher increase rate.   To add a constraint, click Open Constraints in the property panel, which opens the Add Constraint window. Provide a Constraint Name, an optional Description, and specify the Customer Filter (for example, PREVIOUS_PREMIUM_AMT < 1000) and the Rate Limit (for example, Rate Increase < 0.04). Use the dropdown menus to select the appropriate variables for the filters. Once completed, press OK to confirm and Save to store each entered constraint.   Illustration of windows used for adding constraints.   Results   The execution of Pricing Optimization node produces a variety of results including tables and charts.  An Efficient Frontier Chart visually represents the trade-offs between retention probability (x-axis) and Total_NetCustomer_Value, the objective function value (y-axis). Illustration of an Efficient Frontier chart.    The chart illustrates that as retention probability increases, the objective function value decreases. This inverse relationship occurs because higher retention probabilities result from lower rate increases, which reduce premium collection and subsequently lower the objective function value. The chart provides decision-makers with a clear set of options to evaluate and select optimal retention rates while considering their impact on the total net customer value.   Note that the optimization workflow using SAS Model Studio along with SAS Visual Analytics provides a variety of tasks and options to review and validate the results by exploring optimization result tables.   Illustration of a tabular output for optimization solution.    Conclusion   The article introduces the renewal optimization workflow and provides examples of the setting up objectives and constraints using SAS Model Studio in SAS Dynamic Actuarial Modelling for your optimization needs.  This article shall motivate actuaries and modelers to try out and test several configuration options based on your requirements. Such steps might be beneficial in the development and implementation of renewal optimization models at your site. For more details refer to the documentation of the solution available at Documentation for SAS Dynamic Actuarial Modeling     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   Developers and testers associated with SAS solutions which are based on SAS Risk Stratum can leverage the batch run facility. A batch run macro execution service streamlines testing for developers and consultants by eliminating the need to navigate the UI manually. It allows you to execute a Risk Governance Framework cycle—either fully or partially—in batch mode. By predefining all parameters and workflow choices in an Excel document, you can run the entire cycle with a single click, avoiding repetitive task-by-task execution and waiting for system responses. This article presents an overview of using batch run facility for cycle execution in SAS Risk Governance Framework. It assumes that readers are proficient in SAS programming and have basic knowledge of SAS Risk Governance Framework.     You can obtain more information on SAS Risk Governance Framework and SAS Risk Stratum using the following training programs.   SAS Risk Governance Framework Solution Overview   Data Preparation, Configuration, and Administration in SAS Risk Stratum    Batch Service Options   Following three options are available:   Execute a complete cycle Creating a new cycle Run a Cycle task   In this article we shall focus on executing a complete cycle using a program, batch_run_sample_cycle.sas, shipped with SAS Risk Governance Framework. The program is in the batch execution folder in the federated area.      Illustration of sample codes in Batch Execution folder in a federated area.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   A typical location is as follows:   <SAS Repository>\SASIRM\fa.rmc.yyyy.mm\rgf\sas\batch_execution (yyyy.mm represent year and month of your current version)   The code comes along with an excel file template, sample_cycle_param_table.xlsx, for storing tasks related parameters for your cycle.   Using the batch code   There are four major steps for using the batch code as the following:   Simple illustration of steps for batch execution   Supply Macro Parameters   Open the script batch_run_sample_cycle.sas in Base SAS or SAS Studio. After making changes, you must save it with a different name and preserve the original copy of the code. The script for the batch mode runs several macros. You must provide the following parameters for the successful execution of the script. Following is a brief description of the parameters:   Parameter Description Sample Values Host SAS Risk Governance Framework host sas-aap.demo.sas.com, sasbap.demo.sas.com Port SAS Risk Governance Framework port 80 Server SAS Risk Governance Framework server SAS Risk Governance Framework (Default value) Solution SAS Risk Governance Framework content id rmc.2023.03 or rmc.* to pick up the latest version of rmc Username Username (must have necessary RGF access to run through the cycle) sasdemo, rgfadmin (Any user with the RGF: Administration role) Password Password for the user Password of the user Solution_version Version of the solution content  icv.v09.2023, cecl.2022.02 Stratum_version Version of the Stratum core rmc.2023.03 or rmc.* to pick up the latest version of rmc) Scenario_file_path Path to the scenario files (if loading scenarios via this script) D:\scenarios.xlsx Prespective Perspective id (valid id value for solutionCreatedin parameter) Sampl,icv,ifrs9,ldti Param_table_path Path to the file containing the parameters for batch execution D:\ Param_table_name Name of the file containing the parameters for batch execution Param_table.xlsx Log_level Debug logging level 1-5, 1 being the least amount of logging and 5 being the most, defaults to 1   Following is a depiction of supplied values:   Illustration of supplied parameters in the script.   Supply Cycle Parameters   Your cycle tasks need several parameters depending on the tasks involved in the cycle. You must provide each of these parameters for each of the tasks in a predefined template. Following are the steps you should follow:   Copy the File   Navigate to the repository: \<repository>\rgf\sas\batch_execution. Locate the file: sample_cycle_param_table.xlsx. Make a copy of this file to a local folder of your choice. (Example: D:\) You can rename this copy as required (Example: param_table.xlsx) Note: Do not modify the sheet names in the file.   Edit the Cycles sheet   Open the copied file using Excel. Navigate to the Cycles sheet. Specify the details of the cycles you want to create, such as:   Cycle Name Cycle Id Cycle base date Additional cycle configuration parameters (if any).   Illustration of Cycles sheet.   Note that there are several columns that you can configure. The Cycles sheet in the parameter table defines various cycle configurations for execution. Each cycle is uniquely identified by a cycle_id (e.g., RMC Test Batch01) and is accompanied by a descriptive cycle_name and optional cycle_description to provide context. Column A determines whether the cycle is executed; leaving it blank allows the batch program to process the cycle, while adding a # ignores it. The cycle_base_dt specifies the base date for the cycle in yyyy-mm-dd format, and the entity_id associates the cycle with a valid entity ID linked to the data for that base date. The initial_run_flg indicates whether the cycle is an initial run, defaulting to Y (yes) if left blank, while subsequent runs should be marked as N. The workflow_template_id identifies the workflow template to be used, and the optional dimensional_points field can be left blank to default to the solution perspective (e.g., rmc) or filled with comma-separated values for customized dimensions. The control_framework_id links the cycle to a specific control framework, and the func_currency defines the functional currency for monetary value conversion (e.g., USD, EUR). Together, these fields ensure that cycles are properly configured for batch execution, with flexibility for customization where needed.   Edit the Workflow sheet Navigate to the Workflow sheet. Define the cycle-task combinations for execution:   Cycle Name: Match it with a cycle defined in the Cycles sheet. Task Name: List the task(s) to be executed as part of the cycle. Specify other task-related parameters or dependencies, if required.   Illustration of Workflow sheet.   The Workflow sheet contains additional parameters to define tasks and their behavior within a cycle. The task_for_parameters field specifies the parameters to be applied for a particular task, ensuring accurate task execution. The activity_choice parameter offers options for user actions in a task sub-flow, while transition_choice outlines the necessary steps for advancing to the next task in the workflow. The analysisRunTitle allows for customized naming of an analysis run, but if left empty, a default naming convention is applied. The waitFlg reads the wait flag parameter, determining any delays or conditions before proceeding. The create_link_instances field enables linking objects, such as analysis data from previous runs, with an example format like {cycle_analysisData_prev_1=""and(eq(baseDate,2018-12-31),eq(solutionCreatedIn,'CECL'),eq(resultsCategoryCd,'FR_HTM'))""}. Finally, the control_param_lookup_key is used to define specific parameters for the control framework, allowing for tailored execution and validation. These fields collectively provide detailed control over the task execution process within the workflow.   Edit the Param_table sheet To manage task parameters, navigate to the param_table tab, which includes key fields for defining and organizing parameters.   Illustration of Param_table sheet.   The name column specifies the parameter associated with the model required for the task, uniquely identifying it within the model's context. The task column links the parameter to a task, as defined in the task_for_parameters field in the workflows, while the value column assigns the parameter's value, which may be numeric, textual, or conditional, depending on its purpose. For tasks involving nested parameters or hierarchical structures, the parent column identifies the parent parameter, ensuring logical organization. The filter field is particularly useful when assigning a value to a model parameter that references a custom object instance with an unknown instance key, as it enables the use of dynamic conditions to identify the instance. Filter values must align with the value column and the base date choice for accuracy. Additionally, the OUTANLYSISDATANAME parameter should adhere to the site's naming conventions to maintain consistency and clarity in data references, ensuring that parameters are accurately linked to custom objects even when exact identifiers are not available.   Note that with in this context of article no scenarios are used. So the Scenarios sheet is empty and not discussed here.  The control_param_table sheet is similar to param_table sheet. It contains parameter for the control framework if it is used in the cycle. It might be optional in many cases.   Save Your Changes After editing relevant sheets, save the file in a different location. For example, D:\param_table.xlsx.   Ready for Execution Use the updated file to execute cycles and workflows as per your system's batch execution process.   Execute the Code   The code once ready can be easily run in Base SAS or SAS Studio.   Click the Submit icon to execute it. Note that the total execution of the script depends on several factors like size of the data, number of tasks in the cycle, complexity of the tasks, computational requirements, hardware configuration and so on.   Validate the Cycle   Log in into the solution. On the Cycles workspace, verify that your batch cycle exists with Cycle Status of Completed.   Illustration of a batch executed cycle.    You can click on a cycle to access related workspaces or reports, allowing you to verify that the cycle's results are logical and valid. This provides a convenient way to cross-check outputs and ensure accuracy across associated tasks and data.   Conclusion   The batch run feature in SAS Risk Stratum simplifies the development and testing process for implementors. It leverages a macro execution service that enables users to execute Risk Governance Framework cycles in batch mode by utilizing predefined parameters from an Excel file. With just one click, this functionality removes the reliance on manual UI interactions and minimizes repetitive tasks. This enhances efficiency and ensures a more seamless  experience, making it an invaluable tool.   For more information on SAS Risk Stratum and related topics, refer to the following documentation   SAS Risk Stratum Cookbook     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   The SAS Solution for IFRS 17 leverages the robust capabilities of SAS Visual Analytics to deliver impactful financial and management reporting. SAS Visual Analytics simplifies the creation and dissemination of reports and dashboards that track business, managerial, and financial performance. This article demonstrates how to create a custom financial report within the Detailed Postings report, leveraging two essential output tables from the SAS IFRS 17 solution’s calculation and accounting processes: IFRS17_SL_JOURNAL_FLAT and IFRS17_SL_BALANCE_FLAT. These tables provide the foundational data necessary for generating comprehensive financial insights and supporting IFRS 17 compliance. While this article is particularly relevant during the solution development and implementation phase, it also worth noticing that reports in a production environment can be easily modified using similar steps. This flexibility ensures that the reporting process remains adaptable and responsive to evolving business needs, even after deployment.   It assumes a foundational understanding of the SAS Solution for IFRS 17 on SAS Risk Stratum and SAS Visual Analytics. Users should be familiar with the basic steps involved in adding pages, importing data, and assigning data or object roles within SAS Visual Analytics.       You can obtain more information on SAS Risk Stratum and SAS Solution for IFRS 17 and SAS Visual Analytics through the following training programs.   Business Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum   SAS® Visual Analytics 1 for SAS®9: Basics    Detailed Postings Report   This is one of the important reporting outputs that is used for analysing postings in the solution. The report consists of two key pages: Detailed Journal Entries and Balance Verification. The Detailed Journal Entries page allows you to view debit and credit entries for a specified period, covering all relevant accounting events. It also provides essential insurance contract group details, along with the ability to filter and subset accounting entries based on specific insurance contract groups.   The Balance Verification page presents a summary of balances, showing the amounts entered in both credit and debit entries, based on the selected filtering criteria. This page ensures that users can verify balances efficiently and accurately.   This report can be filtered by:   Entity Reporting Date Scenario ID Insurance Contract Group ID Insurance Contract Subgroup ID Reporting Entity Filters: Ledger Basis Code / Reporting Entity Level 1/ Reporting Entity Level 2/ Reporting Entity Level 3   Illustration of Detailed Posting Report    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The steps in this article can also be used for adding or amending reports in the Financial Dashboard which has the following reports.   Balance Sheet Statement of Comprehensive Income Movement Analysis by Component (Gross) Movement Analysis by Component (Ceded) Production – All Movements Differences between CSM calculations and SLAM Posting Comparison of Journal and GL Postings   We shall amend the detailed postings report as an illustration in the article.     High Level Steps   The users who customize SAS Visual Analytics reports must have the necessary Edit access rights and roles for both metadata access as well as for SAS Risk and Governance Framework. A user with read-only rights can add only comments to various objects in the reports but cannot customize the reports themselves. The following figure describes the high level steps involved in amending the report. High Level Illustration of Steps      Add a New Page   You must add a new page to the detailed postings report. Any report in SAS Visual Analytics can have multiple pages. Multiple pages can be used to present different views of the data. Each page can have one or more data sources. You can have one or more objects on a page.   The report can be found on   SAS Solution for IFRS 17: Dashboard > “Detailed Postings” Tab or SAS Visual Analytics: “IFRS17 - Detailed Postings”   You must access the report through SAS Visual Analytics from the predefined server location. Here is an example of such a location.   Illustration of SAS IFRS 17 Visual Analytics Report Location      There is no limit to the number of pages in a report. You must access the report on the server and select Edit report in the Menu and click the New Page (+) icon. Note that you can rename the newly created page to Journal vs Balance by double-clicking the name.   Illustration of "Edit Report"       Illustration of "New Page"     Add Data Sources   You must add the data sources to your report. The required tables are loaded beforehand are readily available for adding to an existing or new report. You must click Data object in the left pane and then click Actions and select Add Data Source and select IFRS17_SL_BALANCE_FLAT table. Note that the table IFRS17_SL_JOURNAL_FLAT is already there.    Illustration of Adding a Data Source    Both tables are essential in the IFRS 17 reporting process, with the journal table is focused on debit and credit entries finally feeding into the general ledger and the balance output table supporting high-level financial reporting and disclosures for a given accounting period. Note that the underlying data for these two tables is gathered in a different manner from the source results and that the IFRS17_SL_BALANCE_FLAT table is not a simple subset of the IFRS17_SL_JOURNAL_FLAT table.     Add Cross Tabs   You must add two cross tab objects from the left panel. You can select the cross tab object from the Objects menu and assign IFRS17_SL_JOURNAL_FLAT to the left tab and IFRS17_SL_BALANCE_FLAT to the right tab. Using the property panel on the right you must assign the following roles.   For Columns, select all the variables associated with GL Account Level (Level1 to Level 6)   For Rows, select GL Account Description   For Measures, select Balance Amount (RC)    Illustration of Role Assignment      Map Variables   A side-by-side report is ready based on the two tables. For this report to work with the global filters at the top of the report, you must map the variables between the two tables. Variables can be mapped only when the columns from the two corresponding tables have identical data points. Multiple variables can be used to map data between the tables, with the more variables used in the mapping process, the better. You must click Data object in the left pane and then click Actions and select Map Data Sources. In the Map Data Sources window.   Illustration of Mapping Data Sources       Illustration of Mapping Variables      Apply Filters   After mapping you can try any filter like a Date based filter and check the filtered values in both the tables. You can also add appropriate titles to your cross tabs using the property panel on right. Select Options > Objects > Title > Custom Title > Enter Title   Illustration of Filters and Titles.      Save and Test   You must save the report and check the Dashboard Workspace. The report should now be available in the workspace.     Conclusion   The article outlines a series of steps for modifying existing SAS Visual Analytics reports for the SAS Solution for IFRS 17, enabling you to experiment with and test new reports tailored to your specific needs, ultimately enhancing their overall impact. These steps are not only valuable during the development and implementation phases of the SAS Solution for IFRS 17 but can also be seamlessly applied to reports already in a production environment. This flexibility ensures continuous improvement and adaptation of reports to meet evolving business requirements. For more details refer to the documentation of the solution available at Documentation for SAS Solution for IFRS 17       Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   A key aspect of IFRS 17 compliance is effectively managing complex financial data to ensure precise reporting. The SAS Solution for IFRS 17 offers powerful tools to assist insurers in handling these challenges, including options for making temporary journal and manual adjustments. These features are crucial for maintaining accurate and current financial statements. This article offers a basic overview of the two methods for using the manual adjustments facility for accounting entries within the solution. The article assumes that you have a basic knowledge of SAS Solution for IFRS 17 on SAS Risk Stratum.   You can obtain more information on SAS Risk Stratum and SAS Solution for IFRS 17 through the following training programs.   Data Preparation, Configuration, and Administration in SAS® Risk Stratum   Business Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum   Manual Adjustments to Temporary Journal   Temporary journal adjustments are manual changes or adjustments to the provisional entries made in the financial records to correct or adjust account balances for a specific period. These adjustments are not intended to be permanent changes; instead, they are used to address temporary discrepancies or to reflect changes that will be resolved in subsequent periods. In the context of IFRS 17, temporary journal adjustments might be necessary to account for unforeseen events or remove erroneous entries to align the financial data as late adjustments.   For example, an insurance company might make a temporary journal adjustment to account for a sudden change in claims experience that has not yet been fully reflected in the actuarial models or solution's database. These adjustments ensure that the financial statements for the period accurately reflect the company's financial position, even before a permanent adjustment or model update can be made.   Tasks Associated with Adjustments   Manual Adjustments contains four main tasks:   Adjust Temporary Journal Manual Adjustment (There are separate tasks to Review, Approve and Reject manual adjustments) Load External Accounting Events or Measures Run End of Period Adjustments    Illustration of subtasks for Manual Adjustments.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   In the Manual Adjustment step, users have several options: they can generate manual entries from scratch, query the journal for previously posted entries to review details or use them as templates for new entries, manually reverse journal entries, or delete previously entered manual entries that have not yet been signed off. The two ways the entries can be adjusted are:   Edit on Screen: This option is used when the number of adjustments to entries are small. For adjusting via "Edit on screen", use the Add Row button to add two new rows to the spreadsheet. One row will be for a debit entry and the other for a credit entry. Alternatively, if having queried the journal, select one or more rows and use the Add Row button, and the selected row(s) will be duplicated to the top of the spreadsheet to provide a template. The row number on all new rows will contain an asterisk (*) to mark that the row is new and not a queried entry. Edit via Excel file: This option is used when the number of adjustments to entries are large. You query the journal, and you get a return file in the specified location that provides the ability to verify any issues with the entries, make changes and upload it back.   To perform manual reversals or delete adjustments, you can use the same two methods. If adjusting via "Edit on screen," identify the entries to reverse or delete by selecting the appropriate check boxes in the list of journal entries. If adjusting via "Use local file," download the returned entries from the Queried Entries File cell, remove any entries in the Excel file that should not be reversed or deleted, and then upload the file to the Adjustments File cell. Additionally, for manual reversals, ensure you enter the SL Comment to log the specific Subledger comment.   Furthermore, there is another option available to the user, which is to generate new journal entries from data provided through external files. This option is not discussed in this article.   What Roles Perform Late Adjustments?   Apart from Administrator or IFRS 17 Analyst roles, SAS Solution enables you to configure three optional roles:   Manual Adjustment Entry Officers Manual Adjustment Entry Review Officers Manual Adjustment Entry Approval Officers   The tasks or features related to Manual Adjustments usually get customized during the implementation. For example, IFRS 17 user or analyst can act as manual adjustment entry officers, and a senior finance officer can act as both manual adjustment entry review officers and manual adjustment entry approval officers. New roles can be configured using SAS Management Console and SAS Solution for IFRS 17 Administrator interface. For more information, refer to the course Data Preparation, Configuration, and Administration in SAS® Risk Stratum.   Case 1: On Screen Adjustments   Initial Assumptions: This case assumes that a cycle using the standard solution workflow for a complete accounting cycle is underway and the trail balance report is created. The current task is Review Trail Balance. It also assumes that the review of trail balance and details postings report reveals that late adjustments are required.   Steps to Perform Manual Adjustments   Review the Trial Balance Report. Access the relevant Cycle. In the Cycle, for Workflow Actions, select Adjust. Notice that the Manual Adjustment subtasks open. For Workflow Actions, select Manual Adjustments. There are other options of Review Manual Adjustments and Load External Entries. For Query for journal entries, use dropdown to select "No" or "Yes". Note that, if "No" is selected, the user can only add manual entries to the journal. To select existing entries to be reversed or deleted, the user must choose to query the journal. For Adjustment method, select Edit on Screen. For Entry type code: Keep the default value of MANUAL. Click Add a row Notice that two rows are added for handling credit and debit entries. Enter the modified entries in the two rows. Use dropdown to select the values. For a person entering the values using this method, it is expected that the person has experience or knowledge of accounting events, GL account ids, insurance contract groups and so on.   Here is a sample of entries:   Illustration of Manually Added Entries.    For Workflow Actions, select Run Manual Adjustments.         At this stage, the manual entry officer will log out and manual entry review/approval officer will login.   In the upper right corner, for Workflow Actions, select Review Manual Adjustments. The entries can be reviewed on screen when you access the task. In the cycle, you must click the task to access the details.     Illustration of Entries Available for Review    Note that there are additional foreign exchange related adjustment entries generated by the script in case reporting and functional currencies are different.   In the upper right corner, for Workflow Actions, select Approve. This approval is provided by Manual Adjustment Entry Review Officers. In the upper right corner, for Workflow Actions, select Approve. This approval is provided by Manual Adjustment Entry Approval Officers. For Workflow actions, select Run EOP Adjustments.   Note that you are back to Review Trial Balance task. Usually, a financial analyst or IFRS 17 user logs in and verifies the entries using the Detailed Postings report and Trial Balance report.   Case 2: Using Excel File   The initial assumptions in this case are similar to Case 1 above.   Steps to Perform Manual Adjustments (Using Excel file)   This step assumes that a corrected Excel file with right entries is created and is available for upload. Following are the steps, note that some steps are different from case 1.   In the Cycle, for Workflow Actions, select Adjust. Notice that the Manual Adjustment subtasks open. In the upper right corner, for Workflow Actions, select Manual Adjustments. For Query for journal entries, select Yes. For Expression Editor, click Configuration. Enter the Expression: INSURANCE_CONTRACT_GROUP_ID = “sub_ptf_01” (This is just an example; you can add any complex expression using logical operators.)   Illustration of Expression Editor. Only a simple Expression is presented.    Click OK. For adjustment method, select Use file on server. Notice that the screen refreshes and it should resemble the following:   Illustration of adding entries via Excel file using the file on server.    Notice that the New entries file name is modified to manual_entries_rev. Keep the default value of Trigger Export for the option, Trigger the export of the entries to the provided server location. It will create a file Queried_entries_production.xlsx.   Illustration of Excel File Used for Uploading Manual Entries.   For New entries file name manual_entries_rev. For Validate adjustments, select Yes. Verify that there are no validation error messages. For Workflow actions, select Run Manual Adjustments. Wait the task to complete. Verify that the following files: Checked_manual_entries.xlsx and Queried_entries_production.xlsx   exist at the following location: D:\SAS\Config\Lev1\AppData\SASIRM\fa.ifrs17.10.2021\rgf\misc   You can explore the checked_manual_entries.xls file. The columns with prefix E_ tell us about any errors. This return file contains information about the validity of each entry in added columns. The valid_flg column indicates whether an entry is valid or not. If not, the columns starting with E_ followed by the dimension lookup key name, indicate whether there is an error with a given dimension. The columns AMOUNT_INVALID_FLG and the DC_CD_INVALID_FLG indicate whether there is an issue with the DC_CD (should be D or C) or the posting amount (should be non-missing and positive.)   For Workflow actions, select Review Manual Adjustments. Access the task, scroll down and review the entries. For Workflow actions, select Approve. This approval is by the reviewer.   Note that the same review screen shall be available to the approver officer. In your case, the reviewer and approver might be the same person. If it is not the case, the reviewer must sign out and approver must sign in to proceed in the workflow.   For Workflow actions, select Approve. This approval is by the Approver. For Workflow actions, select Run EOP Adjustments.   Note that you are back to Review Trial Balance task. Usually, a financial analyst or IFRS 17 user logs in and verifies the entries using the Detailed Postings report and Trial Balance report.   Conclusion   Manual adjustments are crucial because they provide the necessary flexibility to adapt financial statements, ensuring that they accurately represent the company's true financial position. This is particularly important when dealing with unforeseen events or errors that could otherwise distort the financial picture. The process of making these late adjustments allows accountants to correct discrepancies and maintain the integrity of the financial reports. It's important to note that the steps outlined in the article are merely indicative, serving as examples to illustrate the process rather than definitive instructions. This highlights the need for professional judgment in applying these adjustments effectively. For more details refer to the documentation of the solution available at Documentation for SAS Solution for IFRS 17.                    Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   SAS Solution for IFRS 17 provides a comprehensive facility to manage the solution configuration via Configuration Sets workspace. This workspace provides a flexibility of creating custom configurations and plug them in using MS Excel workbook. The objective of the article is to provide an overview of steps to configure a new custom configuration and its related aspects in the solution.    You can obtain more information on SAS Risk Stratum and SAS Solution for IFRS 17 through the following training programs.   Data Preparation, Configuration, and Administration in SAS® Risk Stratum   Business Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum   Configuration Set Tables   The solution interface enables controlled uploading of static and mapping configuration set tables through a dedicated screen. After installing or upgrading to version 07.2022 or any later version, system configuration is automatically deployed and can be adjusted by overlaying modified tables. The upload uses an Excel workbook for easy embedding of tables in their native structure. New configurations can undergo an approval process (optional) with extendable prebuilt validations and comparison functionality. The system allows for both group and local (entity-specific) configurations, with restricted access in a multi-entity context.   The following table provides an example for types of configurations and a sample of configuration tables available in the configuration set that can be modified based on your requirements.   Example Configuration Area Example Tables Data Management DATASTORE_CONFIG, DQ_CONFIG, DQ_INPUT_TABLE_THRESHOLD.   Calculations CALCULATION_DETAILS, CALCULATION_FLOW_DEFINITIONS, DISCOUNTING_CONFIG Subledger Accounting Module SUBLEDGER_DIM, SUBLEDGER_SCHEME, ACCOUNT_POSTING_GROUP ACCOUNTING_EVENT_TYPE_DIM and many other static and mapping tables. Reporting REPORT_CONFIG, REPORT_OPTION, VA_REPORT_CONFIG Batch Execution BATCH_CYCLE_PARAM_TABLE, BATCH_CYCLE_TASK_LIST System Configuration RUN_OPTION Process and Job Flow Parameters ANALYTICS_OPTION   If you are new to SAS Solution for IFRS 17, you can learn more about configuration tables by studying the data model of the solution with a focus on static and mapping tables.   Steps to add a custom configuration   Primarily there are five steps:   Download an existing configuration set. Update or modify the required tables. Upload and validate the set as new configuration. Compare the changes. Test by using the new configuration in a cycle.    Illustration of Steps for Adding a New Configuration Set    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Download    Downloading a configuration task is really easy.   Access SAS Solution for IFRS 17 using credentials with administrative rights. Navigate to the Configuration Sets workspace interface. It is available under configuration related workspaces, and it displays a list of configured sets.   Illustration of Available Configuration Sets   Identify the configuration set you want to download. This might involve browsing through a list of available configuration sets. Click the configuration set to view the details. Notice the option to download the configuration set.   Illustration of Configuration Download Link    Click the link Download Configuration Set Template. Notice that an Excel file GROUP_ CONFIG_SET is available in the Downloads folder. This will be an Excel workbook with tables embedded in their native Data Definition Language (DDL) structure.   Update   For updating the file you need a deep understanding of the solution's data model and your requirements.   Select the relevant table in the Excel file. Identify and modify the parameter values, options or settings depending on your requirement.   Note that your change might vary from couple of changes in few tables to several changes in various tables.   Example of simple updates: You may want to make a new configuration for testing few changes like options for day basis settings or discounting curve interpolation method in ANALYTICS_OPTION table or updating a newly configured reports in REPORT_CONFIG table.   Example of complex updates: Configuring a new SLAM. This involves making several changes to tables like SUBLEDGER_DIM, SUBLEDGER_SCHEME, CALCULATION_DETAILS, POSTING_DETAILS, RULE_SL_ACCOUNT_EVENT_TYPE, ACCOUNT_POSTING_GROUP, ACCOUNT_EVENT_TYPE_DIM, COA_GL_DIM, and DATASTORE_CONFIG.     Illustration of a Downloaded Configuration Excel Worksheet    Save your changes in the Excel file.   Upload and Validate   Validation is a must. If there are errors, SAS do not enable you to proceed without removing the errors.   Ensure that the configuration set you want to upload is in the correct format. Verify that all necessary tables and parameters are included and correctly formatted. Navigate to the Configuration Set Interface. From the list of configurations, use the same configuration you downloaded and click the Actions icon and select Create New From.    Illustration of Actions Menu   Click Save. Note that you can choose an optional approval workflow. Here we are not using the workflow. Click Add icon available in the section Configuration Files. Notice that a new window Add Document.    Illustration of Add Document Window   Click Browse and select your newly prepared excel file. Click OK. Verify that there are no validation errors. Click Move to Final.   Illustration of Validation Message    SAS validates an updated file. The prebuilt validations are   Structural checks are the changes compliant with the DDL definition (like primary keys). Completeness checks for tables like RUN_OPTION or ANALTICS_OPTION.   Compare   Comparison is always a good idea.   On the Configuration Sets workspace, click Compare Configuration Sets. For Scope, select Group and choose the two configuration sets. Pick the one you recently loaded and for the other one, click any previous version you need to compare. Select Yes for Compare Configuration Set.    Illustration of Compare Configuration Sets Tab   Download the Excel file for the differences between the two configurations. Verify that the changes are reflected in the comparison file. Note that there are two following sheets.   A summary sheet (no_differences) that lists all the configuration tables for which there are no changes (and their source configuration). A sheet by configuration table for which there are changes, which contains all the observations with differences. The differences will be shown one by one. If one row for one configuration is not followed by a row for the other, then the row is missing in the other configuration (new/dropped).   Test   For testing or deployment. You just need to create a new cycle and simply initialize the cycle with the newly created configuration. Note that the Initialize Cycle is the first task in any cycle.     Illustration of Configuration Set Usage in Initialize Cycle Task   Note that as you progress with the steps of the cycle, during the data management step the selected configuration set will be written to the landing area.  You must verify that the tasks in the desired cycle are executing without errors and the results are according to your requirements.   Conclusion   The article presents steps to manage Configuration Sets workspace in SAS solution for IFRS 17. These steps enable you to try setting up and testing new or custom configuration sets based on your requirements. Such steps might be beneficial in the development and implementation stages of SAS Solution for IFRS 17. For more details refer to the documentation of the solution available at Documentation for SAS Solution for IFRS 17     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   SAS Solution for IFRS 17 uses pre-configured workflows for creating cycles in the solution for process orchestration. Authorized users are enabled to customize the workflow based on your business needs. The objective of the article is to provide developers or implementers an overview of mechanism of making simple customizations to the workflows. The article assumes that you have a basic knowledge of SAS Solution for IFRS 17 on SAS Risk Stratum specifically SAS Risk Governance Framework and can create new cycle and execute tasks.   Learn More: You can obtain more information on SAS Risk Stratum and SAS Solution for IFRS 17 through the following training programs.    Data Preparation, Configuration, and Administration in SAS® Risk Stratum                                                           Business Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum   A Brief Idea of Excel Based Workflows   One of the easier methods to customize a workflow is using Excel based templates available for modifying the workflows. You can find such templates in the federated area. A typical location is as follows:   D:\SAS\Config\Lev1\AppData\SASIRM\fa.ifrs17.10.2021\rgf\rfw_process_definitions.   These Excel files have a typical structure that supports the workflows used in the solution user interface. One such Excel file is IFRS17_v10_2021.xlsx which supports the main workflow IFRS17 - Single Workgroup. It is used as an example in this article and is presented in the following diagram.   Illustration of a standard workflow template   A typical Excel based workflow template has three main sheets. These are:   Tasks Actions Transitions   Tasks Sheet   This sheet enables you to make changes to tasks, their labels, due days, associated scripts, their sequence and so on. There are columns like ID,ROLES, DUE DAYS STATUS CODE, LABEL and so on which enables you to identify the areas for making desired changes. For example, You can also enable email notifications using NOTIFICATIONS column and set notification parameters using NOTIFICATION PARAMETERS.  The following screenshot illustrates a part of the task sheet.    An illustration of Tasks sheet.    Note that the sheet holds the columns like NODE TYPE, TASK and TASK PARAMETERS which enable you to associate any custom script relevant to a task which executes the script when performed through user interface. You must validate the script and add it to the models workspace. Here is a snapshot of the columns available in the sheet.    Another Illustration of Tasks   A typical customization might involve actions like removing a task like discounting task from the workflow or assigning a new custom script that gets triggered when the task is triggered through the user interface by an end-user.   Actions Sheet   This sheet presents the actions that are defined in the workflow. These are typically actions like reject, approve, run model, adjust or review a task. Following screenshot presents a list of actions on the sheet.   An illustration of Actions sheet.   Transition Sheet   This sheet defines all the possible transitions logically required to accomplish a successful execution of the cycle. The FROM and TO columns define the transition between specific tasks. Using the EXPRESSION column, you can provide specific expressions and you use ACTION column to define corresponding actions to be taken for a transition. You can make a specific action visible in the UI using the VISIBLE column. Specific transition values can be defined in custom properties file on content server and associated with the Excel file using the column TRANSITION VALUE. Following screenshot illustrates the transition sheet.   An illustration of Transitions sheet.   Adding a custom template in the solution   The process of adding a custom workflow template is simple and the following diagram depicts the steps.    An illustration of simple series of steps   Clone   A good starting point is to make a copy of existing Excel template for the workflow. Any desired changes should be made in a copy of the file and not the original template. In this example we will use and load the modified file by the name My_Custom_Cycle.xlsx.    Update   In this step you should make the desired changes. Following is a list of indicative or typical changes:   Update the due dates using DUE DATE column. Delete Tasks but ensure that transitions are logically connected to the remaining tasks. There should not be any break in the continuity of the workflow. Make necessary modification in the transition sheet for FROM and TO columns. Change the script by using the TASK PARAMETERS column. Use the ID of the new script. Ensure that the script exists in the model workspace of the solution and is tested beforehand. Change Labels of the task using the LABEL column in the Tasks sheet. Change authorization for a task using ROLE column in the Tasks sheet. Ensure that the role exists in SAS Management Console and is synced with the SAS Solution   Here is an example of changes. Notice that the tasks of Data Processing (ID 0200), Run Data Quality (ID 0202), and Review Data Quality (ID 0203) are removed or absent in the file My_Custom_Cycle.xlsx. Note that there are corresponding changes in the transition sheet not shown in the screenshot below.   An illustration of changes done in the Tasks sheet.   Register   log in to SAS Solution for IFRS 17. Within the solution, navigate to the Workflow Templates In the upper right corner, click the New In the Cycle details section, enter or select the following: ID: Leave the default value Name: My_Custom_Cycle Workflow tag: Cycle To Register workflow template, click Browse. Select the My_Custom_Cycle.xlsx file from the location you saved it. Check for any errors when the screen refreshes. If there are no errors the workflow diagram should appear on your screen.   Save   Click Save and then close your new template.   Test   Create a new cycle and verify that the tasks are running.   Following diagram compares two templates with example differences.    Illustration of a custom template versus a standard template.   Conclusion   The article presents a series of steps to add a customized Excel based workflow template to the SAS solution for IFRS 17. These steps enable you to try out and test several customized workflows based on your requirements. Such steps might be beneficial in the development and implementation stages of SAS Solution for IFRS 17. For a working demo of above steps or advance knowledge of the topic refer to the training program Technical Overview of SAS Solution for IFRS 17.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   SAS Solution for IFRS 17 utilizes SAS Infrastructure for Risk Management job flows to carry out various computations and data processing tasks. The job flows are a collection of interrelated tasks. Each job flow is executed based on a variety of configuration possibilities or options. Developers use these options to suit the business requirements of a certain task at a particular location. The system allows you to execute and test a whole job flow by selecting options from the user interface and downloading the results. The goal of this article is to give developers and testers an overview of how to execute a job flow with modified options and analyse the consequences of the changes. The article assumes the basic knowledge of tools like SAS Infrastructure for Risk Management and technical know-how of SAS Solution for IFRS 17.   Overview of Steps      You can obtain more information on SAS  Infrastructure for Risk Management and SAS Solution for IFRS 17 through the following training programs.   SAS®  Infrastructure for Risk Management Overview   Business Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum   Steps to execute a job flow separately with modified options.   Clone the job flow and download results Identify the options and download corresponding table Update the table with modified options Upload the table Execute the job flow Download and analyse results     We take an example of the steps to change the configuration options in the analytics_option table and then it explores the effect on cash flow calculations. General Overview of Steps for Testing Configuration Options   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.     1. Clone the Job Flow and Download Results   The first step is to access the job flow interface of SAS Infrastructure for Risk Management and locate the desired job flow, open and clone it and then download results. Following are the steps:   Using the interface of SAS Infrastructure for Risk Management access the list of job flows. For the specific job flow, Click More icon and from options and select clone. Double click to open the cloned job flow. In the top right corner, click Run instance icon to execute it Using the miniature window and buttons to zoom in and out, focus on the task, EIR Calculation. Double-click the output table, Discounted Cashflows (based on constant rates), to download it in the MS Excel format. Copy the file to the desktop and rename it OriginalCashflows_DefaultOptions.   Illustration of Instance Page and Results Table     2. Identify the Options and Download Corresponding Table   In this step, you must identify the desired configuration table like analytics_option for changing discounting related configuration options. You need a basic understanding of main configuration tables like analytics_option, report_option, run_option and so on using the user guide and data model of the solution. You must change the table in the initial tasks of the job flow.   Return to the SAS Infrastructure for Risk Management interface and using the miniature window and buttons to zoom in and out, focus on the first task, Collect previous reporting data, of the flow. Double-click the input table, Configuration-Analytical Parameters, to download it in the MS Excel format. Notice that the name of the Excel file is xls.     3. Update the Table with Modified Options   Copy the file to the desktop and rename it modified_analytics_option. Double-click the Excel file to open it and make the following changes:   Note that these options are used as an example. It changes the day basis for accounting and disable forward rate based discounting calculations.   CONFIG_NAME CONFIG_VALUE DAY_BASIS 30/360 DAY_BASIS_LIAB 30/360 FWD_IR_CRV_ORGN_QUOTE_DT_FLG N FWD_IR_RECOG_SHIFT_FLG N   Save the file.     4. Upload the Table   Return to the SAS Infrastructure for Risk Management interface, which has the cloned job flow opened. Right-click the input table, Configuration-Analytical Parameters, and select Upload. The following window appears:     Illustration of upload file facility.    Click Browse and navigate to the Excel file modified_analytcis_option and click it. For Comment, enter the text Changed Analytics Options.     5. Execute the Job Flow   In the top right corner, click Run instance to execute it. Wait for the instance to successfully execute.     6. Download and Analyse Results   Using the miniature window and buttons to zoom in and out, focus on the task EIR Calculation. Double-click the output table Discounted Cashflows (based on constant rates) to download it in the MS Excel format. Notice that the name of the Excel file is xls and is available at the default location of the Downloads folder in the training image. Copy the file to the desktop and rename it NewCashflows_ChangedOptions. Compare the Cash Flows in the Excel Files. Open both the Excel files NewCashflows_ChangedOptions and OriginalCashflows_DefaultOptions.   Notice that the structure of both files is same. Observe the first few values of the column in both the files. It represents the discounted cash flow PV_INVESTMENT_AMT. There are slight differences in the values due to the setting changes made in the file.     Illustration of different results for different configurations.   You can observe the small differences, which are mostly at decimal levels. Notice that the impact of the changes can be further studied, and mathematical reasons can be established. However, the focus of the demonstration is to illustrate the steps of trying and testing out an option on a specific flow.   Post Activities   The six steps described above enables you to try different options and analyse results. If the results are satisfactory, you must configure the options as part of static tables using the configuration workspace for deploying them in production and make them the part of your modified process.   Conclusion   The article presents a series of steps to test or evaluate configuration options in SAS solution for IFRS 17. These steps enable you to try out and test several configuration options based  on your requirements. Such steps might be beneficial in the development and implementation stages of SAS Solution for IFRS 17. For a working demo of above steps refer to the training program Technical Overview of SAS Solution for IFRS 17.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction   SAS Solution for IFRS 17 uses pre-configured MS Excel based reports for reporting financial information for internal or external consumption. Authorized users are enabled to  generate and review any (preliminary or definitive) disclosure reports in format of MS Excel as needed. The objective of the article is to provide developers or implementers an overview of mechanism of these reports and high level steps to add and test new reports. The article assumes that you have a basic knowledge of SAS Solution for IFRS 17 on SAS Risk Stratum and you know basic skills to update or modify SAS tables.   You can obtain more information on SAS Risk Stratum and SAS Solution for IFRS 17 through the following training programs.   Data Preparation, Configuration, and Administration in SAS® Risk Stratum   Business Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum   A Brief Idea of Excel Based Reports   The solution enables you to generate and review preliminary financial reports using the subtasks of Generate Initial Financial Reports and Review Initial Disclosure Reports under the main task of Prepare Trail Balance in the default workflow for a typical IFRS 17 based accounting cycle. A similar set of subtasks (Generate Financial Reports and Review Disclosure Reports) are available in Finalize Postings task of the workflow.   The mechanism of generating the reports is same in both the tasks. However, the reports generated in the subtasks of Finalize Postings are based on approved and finalized accounting entries and hence the reports are definitive. There are various reports available. The following snapshot provides a list of reports that can be generated.       List of reports with names used in the solution.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   In the solution a user can follow simple steps to generate these reports. Following is a brief summary of steps needs to be performed:   For Generate Financial Reports:   Sign on to SAS Solution for IFRS 17  as a user with appropriate role such as the IFRS17: User role. Click the relevant cycle in the "My Tasks & Notifications" section of the homepage, or in the Cycle summary table of the cycles list, to view details of the cycle. In the project details page, under Finalize Postings select Generate Financial Reports. Change any Model Parameters if necessary: Choose the Logging Level. The default value is INFO (minimum logging). Enter the Script timeout. The default value is 3600 (seconds). Select the Chart of Accounts that you wish to use to produce the disclosure reports. Specify whether you want to re-execute the job flow instance. The default value is N. Choose the Report Interval. The default value is YEAR. Choose whether to leverage the reporting entity dimension to build a reporting hierarchy with the option “Use Reporting Hierarchy", the default is No. Select the set of Reports to run. Select at least 1 report to be able to move on to the next task. Should you not want to produce any reports, select Mark complete from the workflow actions button. Click the Workflow Actions button and select Generate Financial Reports to execute the task.   For Review Financial Reports   The user can analyze all the disclosure reports prepared in previous step and go back in the process if required. Otherwise, the step can be marked as completed.   Sign on to SAS Solution for IFRS 17 as a user with the IFRS17: User role. Click the appropriate cycle used to generate reports in the "My Tasks & Notifications" section of the homepage, or in the Cycle summary table of the cycles list, to view details of the cycle. In the cycle details page, select Review Disclosure Reports. Notice the links available under the Review tab. These are: Initial Disclosure Reports – Clicking this opens an analysis run and each report can be downloaded individually. Download all reports – Clicking this creates a Zip file containing all the selected reports. Control Framework Report Click the Workflow Actions button and select Generate Additional Reports to return to the previous step or Approve to continue.   Steps to Add a New Report   The solution is quite adaptable when making adjustments to these reports. Customizations are possible at various levels. You can choose to modify existing layouts of the reports or create a new report altogether. The steps that are required to be carried out are simple however the amount of work in each step depends on your requirements. The following graphic provides an overview of steps.     General overview of steps for custom reports    1. Create or Modify At this step, you start with an existing Excel template. Quite often the required changes may involve only changing the layouts or titles in the report. Simple skills in Excel enables you to carry on the desired changes. Note that all the Excel templates follow a similar structure. Every Excel template has three sheets. These are :   Report - This sheet has the final report. It usually have simple or pivot tables that showcase the results calculated from the configuration sheet. Input - This sheet has raw data populated by a SAS code. Configuration - This sheet carries formulae and aggregation logic involving input data.   You can choose to make a simple changes in the Report sheet  like changing the titles, adding a chart and so on. Or you may want to change the input data in the Input sheet or configuration logic in the Configuration sheet depending on your requirements. Here is the summary of skills required.   Target Sheet Customization Possibilities  Desired Skills Report Report Layouts Basic MS Excel skills involving tabulation, pivot tables and charts. Configuration Logic Advanced MS Excel Skills involving application of simple and advance aggregation formulas across sheets. Input Data Extraction Advance programming skills including SAS SQL, SAS Macros and SAS Data step programming.     The following snapshots provide an example for the three sheets.   A sample of Analysis of Revenue Report. The sheet involves simple tabulation of numbers related to revenue.    In the above snapshot the Report sheet presents a simple table showcasing relevant number for amounts related to liabilities for remaining coverage, recovery of acquisition cash flows and insurance revenue. The values are based on the logic defined in the configuration sheet. Notice that you are free to change the titles, colors , font  and so on in the underlying template. You may add a chart or pivot table of your choice.     The configuration sheet for Analysis of Revenue report. The sheet involves formulae for reading and aggregating data from the input sheet.    The above snapshot illustrate the usage of SUMIFS Excel formula that reads and aggregates values from the Input sheet. This configuration sheet can be modified for its formulae. You may add more configurations based on your requirements.   An example of the Input sheet for Analysis of Revenue report. This sheet holds the raw data.    The above snapshot presents a portion of the input sheet. Note that it is based on the data extracted from SLAM mart tables of the solution. A predefined but customizable SAS code  populates this input sheet.   Note that all the Excel templates can be found at a predefined location in the federated area. An example of such a location is as follows:   D:\SAS\Config\Lev1\AppData\SASIRM\fa.ifrs17.yyyy.mm\irm\report_templates   The following snapshot illustrates simple changes made to the template Insurance_Revenue.xlsx.   An example of simple customizations    2. Update The SAS code responsible for populating the input sheets of the excel based report is available in the landing area. The name of the code is irmif_run_disclosure_reports.sas. An example of a typical location of this code is as follows:   D:\SAS\Config\Lev1\AppData\SASIRM\\fa.ifrs17.yyyy.mm\irm\source\sas\ucmacros   If you have created a new Excel template with your own inputs, you must provide the logic for extracting the data in the SAS code. If however, you have made changes only to the configuration or report sheet, then no updates are required in the SAS code. This code is long, complex and it creates many intermediate tables. The good thing is that it has got comments which help you to look at the portion of the code that matters to you. You need an advanced level of SAS programming skills to make, validate and test any changes.   For example, if you need to have additional column in the Exposure_to_Currency_Risk report. You must modify the KEEP statement in the data step for MKT_FX_1 table. Here is a snapshot of the required portion of the code. Refer to the %let statement followed by a data step in the second part of the code (lines are marked in boldface).   /* create the FX_MKT table for the Exposure_to_Currency_Risk report*/ %let where_clause_FX = %bquote((asofdate = input("&cycle_date.",date9.) or asofdate = &END_PREV. ) and ENTITY_ID="&ENTITY_ID." and workgroup="&workgroup." and to_currency_cd = "&curr."); %irm_check_details(libref = SLAMMRT , table_name = MKT_FX , where_clause = &where_clause_FX. , schema_version =&content_version. , table_id = 0 , out_ds =MKT_FX_0);%let keep_fx_1 = From_currency_cd To_currency_cd Quote_dt TYPE quote_rt; Data MKT_FX_1 (keep = &keep_fx_1. ) ; retain &keep_fx_1.; SET MKT_FX_0; if quote_dt = input("&cycle_date.",date9.) or quote_dt = &END_PREV.; format quote_dt date9.; run;/*End of creating the MKT_FX table*/   3. Add You must add your new report to the table REPORT_CONFIG.SAS7BDAT. The table is available in the static folder of your landing area  This is an example of the location -   D:\SAS\Config\Lev1\AppData\SASIRM\fa.ifrs17.yyyy.mm\irm\landing_area\base\ifrs17.vmm.yyyy\static.   The following table shows the content of the table.   The configuration table. Notice the variable and their values.    You can edit the table to add a new entry for your custom report. Following is a sample of an entry.           Variable        Values for a New Report                                          Comments REPORT_ID Revenue_Chart This variable stores the unique values for your report IDs. You must provide a unique value to your new or modified report. REPORT_NAME Revenue_Chart This variable stores the unique names for your reports to be used in the UI. TEMPLATE_NAME Revenue_Chart.xlsx This is the name of the template of the newly created or modified report template. SOURCE_CODE irmif_run_disclosure_reports.sas This is the name of the code responsible for populating the Input sheet in your Excel template. The code is either remains unchanged in case of simple report customizations in the report sheet or gets modified in case of advanced configuration requirements with additional columns added to the input sheet.   The following screenshot illustrates an example of the update done to the REPORT_CONFIG table.   An example of an update made to the REOPRT_CONFIG table.    4. Execute and Test The steps to execute and review the report is same as described in the previous section - A Brief Idea of Excel Based Reports . Execute the task by selecting your newly created report. Download and review for any errors or logical inconsistencies. Here is an example of a successfully executed report with desired numbers.   A custom report. Users must test the validity of numbers.    Post Activities   The four steps described above adds the new report to the solution. The new report is available to be used in any new cycle you create for testing or direct usage. It is recommended to test the report by creating a few new cycles on a test data.   Conclusion   The article presents a series of steps to add a new or customized Excel based report to the SAS solution for IFRS 17. These steps enable you to try out and test several new reports (or any customized existing reports) based on your requirements. Such steps might be beneficial in the development and implementation stages of SAS Solution for IFRS 17. For a working demo of above steps refer to the training program Technical Overview of SAS Solution for IFRS 17.     Find more articles from SAS Global Enablement and Learning here. ... View more

Introduction SAS Solution for IFRS 17 uses pre-configured data quality rules to assure that the right data is utilized by the solution. These quality rules are applied at the initial stages in the standard workflow immediately after the data is loaded into the solution. This helps to reduce any calculation issues in the downstream processes. The solution also enables data administrators or implementers to edit existing rules and add new rules based on the specific requirements. The objective of the article is to provide developers, data administrators or implementers an overview of steps to add and test new data quality rules. The article assumes that you have a basic knowledge of SAS Solution for IFRS 17 on SAS Risk Stratum and you know basic skills to update or modify SAS tables.   You can obtain more information on SAS Risk Stratum and SAS Solution for IFRS 17 through the following training programs.   Data Preparation, Configuration, and Administration in SAS Risk Stratum   Technical Overview of SAS Solution for IFRS 17 in SAS Risk Stratum A Brief Idea of Data Quality Rules The solution applies the data quality rules to the incoming data during the Run Data Quality subtask under the main Data Processing task in the workflow for IFRS 17 process. Note that the IFRS 17 standard for insurance contracts do not provide specific rules for data quality. SAS provides pre-configured rules (that are editable) based on the best practices in several insurance and non-insurance industries. The data quality rules in the solution are based on the principles of accuracy, integrity, and completeness. The solution hence provides flexibility to modify existing rules and add more rules according to your requirements. Here is a snapshot of types of rules that SAS applies to ensure data quality.   Data Quality Rule Type Description Example NUMERIC Verifies whether the numeric values have been provided The values of the variable CASHFLOW_AMT cannot be missing. CHARACTER Verifies whether appropriate character values have been provided If a value for the variable CURRENCY_CD is supplied, then it must be a two-character string. DATE Verifies whether the necessary dates values have been provided and the relationship between such dates has been respected Any value of the variable BEGIN_COV_DT for an insurance contract cannot be missing and must be less than the value of END_DT. STRING_LIMITED_CHOICES Verifies whether provided values fall within the list of acceptable or required values The values of the variable CEDED_FLG must be ‘Y’ or ‘N’.   All the existing rulesets can be accessed from the Rule Sets workspace available in the main menu of the solution. Following is an illustration of Rule Sets workspace.   An Illustration of Rule Sets workspace.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Rules are organized into rule sets based on the underlying solution data model and corresponding data definitions or tables. For example, rules for all the market data (information related to risk factors, risk factor curves and quotes) are organized into four rule sets. In the solution, each rule set instance of a rule set object is associated with input data (for example, INSURANCE_CONTRACT_PORTFOLIO for insurance contract portfolio data) and each rule is associated with a column in that specific table. The following is a list of the solution data model's input tables for which the rules are configured.   INSURANCE_CONTRACT_GROUP INSURANCE_CONTRACT_GROUP_ASSOC INSURANCE_CONTRACT_GROUP_DETL INSURANCE_CONTRACT_PORTFOLIO ENTITY INSURANCE_CONTRACT_GROUP_X_CURVE QUOTES INSURANCE_RISK_DRIVER ALLOCATION_DIMENSION INSURANCE_CASHFLOW ALLOCATION_DRIVER INSURANCE_CONTRACT_GROUP_PVCF CALC_INPUT_MEASURE INSURANCE_CONTRACT_GROUP_PVCF_DT CSM_RUNOFF_SCHEDULE INSURANCE_CSV FINANCIAL_DISCLOSURE_INPUT JOURNAL_ADJUSTMENT GL_ACCOUNT LIAB_RUNOFF_SCHEDULE GL_ACCOUNT_BALANCE_SEGMENT RISK_FACTOR GL_ACCOUNT_BALANCE_SEGMENT_AGG RISK_FACTOR_CURVE INSURANCE_AOC RISK_FACTOR_X_RISK_FCTR_CURVE INSURANCE_AOC_CALC RUN_DETAIL INSURANCE_CASHFLOW_AGG RUN_UNIVERSE INSURANCE_CONTRACT_GROUP_ALLOC SLAM_OPEN_SUBLEDGER_BALANCE   For more information on the data model and data definitions you can follow the Technical Overview of SAS® Solution for IFRS 17 in SAS® Risk Stratum training program. On the Rule Sets workspace you can click a specific ruleset to see the details of all the rules configured in the ruleset. Following is an illustration of all the rules configured for the ENTITY table. An illustration of Entity rule set and its rules.    Two methods of adding new rules   Manually using the user interface Bulk Loading rules using an excel loader   Most of the customizations to the rules can be carried using the interface. If you have a few rules to be configured then you can directly add new rules in a rule set or modify existing rules directly using the interface. When dealing with large number of rules , you can first exporting rules to an Excel file, modify it or add all your rules, and then import it back . If you are adding any new rules, you must update the configuration table MAP_RULE_X_DATADEF data by making the new entries of the data definitions or tables and the new rules. Following diagram illustrates these steps.  Overview of steps to add a new data quality rule.    1. Choose At this stage you need to know your input table and a column in the table for which you want to configure the new rule. The need to add a rule is specific to your site. The current state of data quality of the source systems and the underlying ETL (Extract Transform and Load) process may demand more rules to be configured for certain input tables. You can navigate the entire list of available rules from the rule set workspace or the Data Quality section of the help documentation available in the Home workspace of the solution. As an example,  we will choose Risk factor rule set for the table RISK_FACTOR  and we will add or set a new rule for the column  MATURITY_TIME_UOM_CD.  The rule will check for a valid list of values, which are MONTH, YEAR, and SPOT.   2. Access You can access all the available rules sets from the Rule Sets workspace. You can search for a specific rule set and then click to open the rule set. Note that in order to modify or add a new rule you must have administrator access. Following is an illustration of the default Risk Factor Rule set which has only one rule configured. An illustration of Risk factor ruleset and its default rule.    3. Add To add your new rule set from the UI, you must click Add a row in the menu available at the top right corner of the rule set table. You must add all the relevant details like primary key, rule id, rule name and so on. In our example, the following data must be entered. Note that the comments column in the table below is only for your information. It is not meant for data entry.   Column in the Rule definition  Data to be Entered Comments  Primary Key RISK_FACTOR_ID Copy from the first row. This key is same for the rules for a given data definition or a table. Rule Id RISK_FACTOR_RULE_02 (ifrs17.2021.10) Rule 2, it differentiates it from other rules. Rule Name Check valid values of MATURITY_TIME_UOM_CD (ifrs17.2021.10) The name reflects the name and basic logic of the rule. Rule Description Check Missing Risk Factor ID (ifrs17.2021.10) Same as Rule Name. Rule Component Condition Use the drop-down menu to select value for the rule component. The other option is Action. Operator   Leave blank. Not required. Parenthesis   Leave blank. Not required. Column Name MATURITY_TIME_UOM_CD Use the drop-down menu Rule Type Not in a list of values Use the drop-down menu to select values for rule type. Rule Details  "Month","Year","Spot" Provide a list of valid values. Message MATURITY_TIME_UOM_CODE must be set to "Month","Year", or "Spot". Provide a message for display in reports. Aggregation Reference Name   Leave blank. Not required. Aggregation Expression   Leave blank. Not required. Group-By Variables   Leave blank. Not required. Aggregated Rule Flag   Leave blank. Not required. Rule Reporting Level 1 Completeness Copy or Type. Useful in report filters. Rule Reporting Level 2 Instrument Features Copy or Type. Useful in report filters. Rule Reporting Level 3 Not In List Copy or Type. Useful in report filters. Rule Weight 1 Treat rule with equal importance to other rules. The value presently is 1 for all rules.   The other way is to click Export tab and save the resultant excel file. The entries described in the table can be added to the excel. To bring back the data entered in the excel, you need to import the file into the solution from the same page by clicking the Import tab. The following diagram indicates the import and export tabs available in the rule set menu for managing rules.    An illustration of important tabs in the rule set menu.   4. Save You must save the newly added rule either by importing from the excel file or manually adding it directly to the UI. The save button is available at the top right of the screen.   5. Configure You must add the information regarding the new rule to the configuration table MAP_RULE_X_DATADEF. The table is available in the federated area. The location is known to your system or solution administrator.  An example of a location is: D:\SAS\Config|Lev1\AppData\SASIRM\fa.ifrs17.10.2021\irm\landing_area\base\ifrs17.v10.2021\mapping You can edit the table and manually add the row to the SAS table using SAS 9 or you may prefer to write a SAS SQL script to update the table with a new row. In our case, following values must be added as a row must be added to the table. Note that the comments column in the table below is only for your information. It is not meant for data entry.   Column Name Value Comments LIBRARY_NM ic_stg Staging library name TABLE_NM risk_factor Name of the table for which the rule is added DATA_DEFINITION_KEY 10032 Data definition key available in UI RULE_SET_KEY 10026 Rule set key available in UI CONFIG_CHANGE_DT   Leave blank CONFIG_CHANGE_TYPE_CD   Leave blank CONFIG_CHANGE_USER_ID   Leave blank CONFIG_CHANGE_COMMENT_TXT   Leave blank   Post Activities The five steps described above adds the rule to the solution. The new rule is available to be used in any new cycle you create for testing or direct usage. It is recommended to test the rule by creating a new cycle on a test data. You may enter known violation or test cases in the relevant table. The rule should reflect in the data quality report and must point out all the data error in the testing data. Typical data quality errors are presented in the Data Quality Details section in the Data Quality report.   Conclusion   The article presents a series of steps to add a new data quality rule to the SAS solution for IFRS 17. These steps enable you to try out and test several new rules and any customizations to the existing rules done based on your requirement. Such steps might be beneficial in the development and implementation stages of SAS Solution for IFRS 17. For a working demo of above steps refer to the training program Technical Overview of SAS Solution for IFRS 17.   Find more articles from SAS Global Enablement and Learning here. ... View more