20_Solicitation - Attachment 9B - TPIMS Modernization Blueprint.docx

Policy, Research, and Analysis Department (PRAD) Office of Information Technology (OIT)

Pension Insurance Modeling System (PIMS) Transformation Blueprint

Table of Contents

Table of Figures

Table of Tables

Introduction Executive Summary The Pension Benefit Guaranty Corporation (PBGC) protects the retirement incomes of nearly 35.4 million American workers in more than 24,000 private sector defined benefit pension plans. A defined benefit plan provides a specified monthly benefit at retirement, often based on a combination of salary and years of service. The PBGC’s Single-Employer (SE) program is designed to ensure participants in plans that terminate with insufficient assets receive benefits. Although many insured defined benefit plans are adequately funded, there are a significant number of plans that are highly underfunded. Potential claims against the SE program typically arise from the forfeiture of pension obligations by plan sponsors with underfunded defined benefit pension plans that file Chapter 7 or Chapter 11 bankruptcy petitions. These bankruptcies can potentially increase the liabilities of the PBGC.

The primary focus of SE Pension Insurance Modeling System (PIMS) is to project future claims for plans insured by the PBGC. The model analyzes industry trends, firm financials, and macroeconomic data in order to assess the future risk of the PBGC assuming unfunded liability from future distress terminations. SE PIMS is a stochastic simulation model that quantifies the risk facing the SE insurance program over a range of 500 economic and 10 bankruptcy simulations (combined total of 5,000 simulations), tracking plans' liabilities, assets, contributions, premiums, and claims through time. This PIMS Transformation Blueprint provides an outline for strengthening and modernizing SE PIMS.

Problem Statement SE PIMS has been used by the Policy, Research, and Analysis Department (PRAD) for over 25 years, and over that period has been modified many times to meet legislative and regulatory changes. This has resulted in increased complexity, decreased flexibility, and declining ease of use. PBGC wants to design a new model architecture for SE PIMS and has detailed Performance Objectives to achieve improved modeling performance, scalability, stability, ease of maintenance, and knowledge transfer. PBGC will transform the core PIMS model and supporting infrastructure to meet these Performance Objectives.

Business Objectives & Benefits PBGC has outlined Performance Objectives in the transformation of SE PIMS. Achieving these performance goals for SE PIMS will help PBGC effectively and proactively guarantee the pension plans that it supports, allowing for responsible and effective fiduciary oversight. These goals were used as guiding principles for the transformation blueprint, to drive towards innovation for SE PIMS technical capabilities to perform at or above industry standards. PBGC’s stated performance objectives used to evaluate the considerations within this blueprint to determine best suitability can be found in Table 1 below:

Table 1: PBGC’s Stated Performance Objectives for SE PIMS

These Performance Objectives were used to arrive at actuarial and technical considerations which would increase SE PIMS performance and throughput, while decreasing the operational burden. For example, in the Performance goal, PBGC has documented its desire to increase the number of simulations executed during each stochastic run from 5,000 to at least 10,000, while reducing overall run times. This will provide a wider cone of financial projections, which PRAD feels would improve the output of the SE PIMS analysis.

Transformational PIMS (T-PIMS) Characteristics This Blueprint outlines several enhancements to the legacy SE PIMS structure that will allow PRAD to efficiently model projection scenarios for the overall pension system and PBGC’s resulting financial exposure. These enhancements will take advantage of technological advancements that have occurred since the original development of legacy SE PIMS and align with leading practices from comparable, innovative systems in the industry. The design enhancements will help PBGC achieve the Performance Objectives in Table 1 and achieve its core mission.

Technical Design Characteristics In addition to the Performance Objectives stated in Table 1, scalability, automation, data management, and security are additional business drivers for evaluation in the T-PIMS design criteria. These additional pillars will enable high-performing infrastructure and computation capabilities that allow processes to quickly ingest, integrate, transform, analyze, and store data.

Scalability allows for the system to be able to seamlessly increase or reduce resources to meet the unique needs of PRAD at a specific time. It is normal for the utilization of a system to increase or decrease depending on the business cycle of an organization. A scalable system enables PRAD to achieve operational efficiencies, which may result in realized cost-savings.

Automation criteria enables T-PIMS to improve aspects of data and code lifecycle management, specifically data entry and moving code and data from one environment to another. Automation increases the effectiveness, efficiency, and coverage of business processes and consistency of the expected output. When implemented effectively, automation reduces the burden of manual tasks, freeing staff up for more mission-critical work. Resource provisioning, code development, and script deployment can be automated during any stage of the data and code lifecycle. The following automation criteria are part of the design of the transformed PIMS:

· Infrastructure Provisioning: Reduced effort for compute, network, and storage provisioning, spin-down, and utilization processes

· Operations and Monitoring: DevOps processes, hardened and automated deployments, standardized infrastructure catalogue, and automated CloudOps tools reduces manual processes

· App Testing: Iterative development, automated testing, and continuous integration pipelines improve app testing cycle time, reduce bugs, and increase productivity Technical Infrastructure The technical infrastructure of T-PIMS will detail the technologies required to implement the core model. These technology components will impact several Performance Objectives that are integral to accomplishing T-PIMS’s mission, including speed, simulation bandwidth, and scalability. The legacy SE PIMS is executed on physical, on-premises servers which are expensive to operate and maintain. PBGC will transition to Cloud infrastructure during this transformation effort to take advantage of the many benefits that this innovative technology offers. Per the PBGC Information Security Risk Management Framework, a Cloud system is defined as an externally hosted, owned, and operated system that meets all five essential cloud characteristics outlined below:

· On-demand service

· Broad network access

· Resource pooling

· Rapid plasticity

· Measured Service Cloud infrastructure is a rapidly growing industry standard for efficiently running technical resources. Cloud Services Providers (CSP’s) offer network infrastructure in a virtual environment that can be accessed by customers from any network connection. Cloud services are all managed by a browser, application, or Application Programming Interface (API).

Customers purchase Cloud resources from CSPs using a pay-as-you-go model that only charges for the computational resources that are used. This eliminates the need to purchase physical hardware, which can significantly reduce the overall infrastructure expenses to run and maintain systems. This also enables customers to efficiently scale up and down depending on the unique needs of the organization. Customers can automate the expansion of Cloud resources in the event of increased demand and return to baseline operations after the demand has peaked, utilizing only what is needed. Through this innovative model, CSPs manage the maintenance and security of the hardware to provide secure, up-to-date resources to customers to perform business functions.

The decision to migrate to Cloud infrastructure is made by an organization considering several driving factors. The business drivers that helped PBGC determine whether to migrate to the Cloud include the speed to implement, affordability, continuous improvement, customization, integration, overall availability of the solution, and the Performance Objectives outlined in Table 1. The ability to minimize risk while maximizing business opportunities also makes Cloud infrastructure a prudent option. For example, financial risk is managed through the pay-as-you-go model. Business risk, on the other hand, is managed through the hosted model with common applications. Lastly, availability risk is managed through external professional management of the CSP, reducing system downtime. Another business driver supporting a Cloud infrastructure is the need to secure business data. Cloud infrastructures offer security features such as identity and access management, role-based control, and encryption. The landscape of CSP’s assessed, supporting PBGC’s ultimate CSP decision, can be found in Section 4.3.1.

Programming Language The programming language for T-PIMS will be the backbone of the system. Key considerations in selecting the programming language for T-PIMS included usability, performance/scalability, cloud integration, and flexibility. Each of these considerations correlates to a Performance Objective in Table 1 that PBGC is using to measure the effectiveness of enhancements made to T-PIMS to improve the overall user experience and performance of the system.

The criteria that were used to assess the programming language landscape differentiated Python as the leading programming language to transform the legacy SE PIMS application, making it the selection for the new programming language. Python has several key benefits and features that would enable T-PIMS to effectively achieve vital business objectives. For instance, Python’s simplified syntax structure makes it easy to develop new code, make changes to existing code, and perform code debugging. It also leverages functions to modularize code for reusability, and easily integrates with APIs. These are just a few of the features that would enable new users to have a faster adoption rate and require less training compared to other languages.

Python also provides the ability to review code output for traceability and audit trail purposes. The modular structure of the code allows outputs to be easily reproduced to isolate areas of concern during error analysis for auditability purposes. Python is also compatible with various tools, including source code analyzers and application performance management software used to further assess the code and evaluate gaps between expected and actual performance. The code audit functionality that Python enables would provide additional insight into the performance of the T-PIMS core model and provide evidence to support performance metrics and outputs. The full programming language analysis is outlined in Table 18A with favorable, unfavorable, and neutral attributes.

PBGC will transition from C++ to Python to achieve the Performance Objectives and enable continuous improvement in the future. By leveraging an industry-standard language that has a robust development community, T-PIMS can be a viable, practical, effective, and adaptable platform for the future.

Per ITIOD guidance, and to align with PBGC’s new development standards, the Integrated Development Environment (IDE) where the development of T-PIMS Python code will occur in is Visual Studio and the code will be managed within Azure DevOps.

Data Management Data validations, data dictionary, data sensitivity-based access controls, auditing and traceability, and linkage are always applied to all data. While using Infrastructure as a Service (IaaS), there will be realized storage efficiencies. On-demand and software-defined storage needs enable greater storage utilization. The data model influences the types of analytics that can be performed on the data, and of the data models analyzed to meet PBGC’s stated Performance Objectives, a flexible schema, schema-less database would provide the greatest benefits to T-PIMS per the criteria. Storing original data in a loosely structured form provides flexible ways to traverse the data entities, such as querying and combining tables and columns, leading to new insights.

Distributed System While using Infrastructure as a Service (IaaS), there are realized computational efficiencies. IaaS allows on-demand computing, elastic utilization, and shut-down of environments, ultimately lowering compute burden and enabling higher utilization levels. Establishing a distributed system using clusters (i.e., a group of servers) will also enable the modeling platform to continue operating properly in the event of failure of one or more of its processing or storage nodes.

Integration Services An API can be a technical specification that establishes how information can be exchanged between programs, or a software interface that publishes that specification. API-led connectivity has reusable modular building blocks that enables self-service and application driven design, with governed access and comprehensive visibility. These capabilities of APIs would help achieve the Performance Objectives; therefore, three types of potential APIs were considered for transformed PIMS – System, Process, and Experience APIs.

System APIs are systems of record that connect to different data storages and retrieve data to produce abstracts from the underlying data platform. Process APIs are systems of differentiation that filter user requests or inputs using business logic. Process APIs invoke System APIs to retrieve intermediate calculation data. Lastly, Experience APIs are systems of innovation which include data dissemination through User Interfaces such as Web and Mobile.

With those categories, APIs can be leveraged for T-PIMS through data ingestion, data modeling, or data dissemination/publication. A full analysis and PBGC decisions on potential T-PIMS APIs are included in Section 4.3.5.

Security Design There are instances when PBGC must utilize Personally Identifiable Information (PII) and other sensitive information to execute its mission. Protecting this data from unauthorized access will minimize the risk to companies and pension plan participants who have a relationship with PBGC. PBGC uses a holistic approach to mitigating security threats by implementing appropriate security controls at various layers, detailed in PBGC’s Information Security Risk Management Framework (RMF). There are several security controls that will come as standard with a Federal Risk and Authorization Management Program (FedRAMP) certified instance of Cloud infrastructure. However, the RMF contains additional considerations that must be reviewed to set additional security controls specifically molded to the unique needs of PBGC.

Organizational security standards and the type of data being safeguarded are the driving factors to determine additional security controls that should be implemented to minimize the organization’s exposure to security threats. Data can be secured, and privacy processes can be applied, to ensure compliance to the enterprise policies at a central location. The preferred computational model for a platform such as T-PIMS will leverage processing logic that is co-resident with the data. Any data egress is a potential audit and security risk and must be recorded in a consistent manner. Centralized application and enforcement of security and access policies across various data assets for Administration, Authentication, Authorization, Audit, Data Protection, and Perimeter Security are considered by PBGC.

Administration refers to the ability to set policies across the environment and monitor that they are correctly applied. Authentication matches users against user account credential combinations to confirm user identity. The review of T-PIMS accounts for compliance will align with PBGC’s current processes, which is done annually through the account recertification process. Authorization grants authenticated user access to resources based on access control rules. Audit maintains a trail of access that was granted or denied to each user account. Data Protection safeguards data at rest and in motion using various forms of encryption. Lastly, Perimeter Security secures system access with ability to block services at the boundary of the environment.

PBGC views each of these considerations through an organization-centric lens when determining how it should be implemented. Rules based access controls are used to grant or deny access to technical resources based on criteria set by system administrators. These settings are used to prevent unauthorized access to sensitive information and only provide users with the lowest level of access needed to perform their assigned duties. The protection of data in motion and at rest is another focus, in addition to which system users have access to it. In Cloud infrastructure various levels of encryption can be used to protect data that is stored within T-PIMS or is transmitted to users for access. Encryption provides an added level of security to confirm that data is accessed only by those with appropriate rights. Finally, maintaining an accurate record of access that was requested, granted, or denied is another way that PBGC monitors the overall security of T-PIMS. T-PIMS will follow existing PBGC guidelines to establish a robust audit trail to capture this information and track user access history, as well as identify attempted security threats that were thwarted due to the security policies in place.

In alignment with the PBGC Information Security RMF, additional considerations for Cloud infrastructure platforms include:

· CSP Authorization Package: The CSP is responsible for providing an authorization package in accordance with FedRAMP requirements.

· PBGC Control Selection: The PBGC business unit utilizing the cloud is responsible for authorizing its use of the CSP’s system.

· Plan of Action & Milestones (POA&Ms): As part of the authorization package, the CSP should provide a list of POA&Ms in FedRAMP.gov.

· PBGC System Authorization Package: Must provide evidence of the CSP’s Authority to Operate (ATO), System Security Plan (SSP), Security Assessment Report (SAR), and POA&Ms.

· Authorization Artifact Review: The Information Owner (IO) and Information System Security and Privacy Officer (ISSPO) must perform an annual review on document requirements to gain a comfort level that no significant weaknesses are present that would negatively impact PBGC data.

PBGC considers these various security layers when developing the security strategy for a new system, including T-PIMS. Examining the various security layers helps highlight the vulnerabilities that exist at each layer, helping to develop an extensive security posture that mitigates overall risk. Figure 1 below is a representation of the various security layers that PBGC considers when determining the security controls to best protect sensitive information.

Figure 1: T-PIMS Security Layers

T-PIMS Dynamic Model Figure 2 below depicts the T-PIMS process flow, moving from inputs and assumptions on the left, through feeder/component models, and finally into the core valuation model which produces projection results used to develop PBGC’s Projections Report, as well as any ad hoc analysis (including Technical Assistance requests). Each component of the process flow represents a unique aspect of T-PIMS; collectively, they interact dynamically to project funded status of the SE pension plans insured by PBGC, as well as potential PBGC claims from plan sponsor bankruptcies. The feeder and component models are described in greater detail in the following sections.

PIMS Transformation Blueprint

Figure 2: Potential T-PIMS Process Flow

Core Model Components The core actuarial projection model is envisioned to be comprised of four main component stages: Input Data, Liability Calculation Engine, Plan Output, and PBGC Output. This is outlined in Figure 3 below.

Figure 3: Potential T-PIMS Core Valuation Model

Input Data The input data stage will use the plan’s summary demographic data provided in the Form 5500 Schedule SB and accompanying attachments to generate a set of plan participant census proxy data profiles, which will form the underlying data for the projection and calculation of liabilities within T-PIMS.

The T-PIMS data structure will utilize a two-tiered approach, with the first tier applying to plans modeled individually and the second tier applying to plans modeled in synthetic plan bundles. See Section 4.2.6 for further detail on this data entry process. The key input data components for each data entry tier are described in more detail below:

First Tier –Individually Modeled Plans Active Data Profiles – These profiles consist of active participant counts for a given plan grouped into five-year age and service brackets. As applicable, the profiles will also include average salary and average cash balance account balances, broken into the same age and service groupings. If a specific age and service bracket is missing salary or account balance information (for cells with fewer than 20 participants), imputed averages will be calculated using values from adjacent cells.

Terminated Vested (TV) & Retiree Data Profiles –These profiles consist of TV and retiree participant counts for a given plan, based on Schedule SB classifications, grouped into five-year age and service brackets. The Schedule SB attachments do not provide age and service distributions for TV and retiree participants. Therefore, these profiles are extrapolated based on a plan’s active data profiles - see Section 2.2.2 for further detail on how these inactive census data profiles are developed. As applicable, the profiles also include average salary and average cash balance account balances, broken into the same age and service groupings. While inactive benefits are no longer accruing, this information is used to calculate imputed benefits for inactives, since actual benefit information is not otherwise provided for inactives within the Form 5500 data.

Actuarial Decrement Assumptions – These assumptions are plan-specific, and include retirement rates, separation rates, disability rates, and mortality rates. They will be used to value actuarial liability at each valuation date. Additionally, depending on user input, these assumptions may also be used to project active data profiles forward 100 years to develop the inactive census data profiles, and to project active data profiles forward to each successive valuation date. However, the model will accommodate separate actuarial assumptions for plan demographic experience, in the event that PRAD would prefer to differentiate valuation and experience assumptions (e.g. using experience assumptions determined by plan type, industry, etc.). This information will be updated on a multi-year cyclical basis, with the interval determined by PRAD, to decrease time spent by PRAD on manual plan data review. OCR capabilities may be leveraged in the transformed data entry process to identify and flag structural changes in actuarial assumptions from year to year. Additionally, PRAD may leverage the “Change in Non-Prescribed Actuarial Assumptions” indicator on the Schedule SB, to screen for known assumption changes without the need for a detailed review. See Section 4.2.2 for a list of the plan provision input parameters.

Plan Provisions – Plan-specific plan provision information will be taken from the Schedule SB attachments. The plan provision information will include the key provisions necessary to calculate plan benefits for a given plan participant, based on a specific age and service profile. This information will be updated on a multi-year cyclical basis, with the interval determined by PRAD, to decrease time spent by PRAD on manual plan data review. OCR capabilities may be leveraged in the transformed data entry process to identify and flag structural changes in plan provisions from year to year. Additionally, PRAD may evaluate the possibility of adding a “Change in Plan Provisions” indicator on the PBGC Premium filing requirements, to screen for known plan provisions changes without the need for a detailed review. See Section 4.2.2 for a list of the plan provision input parameters.

Shortfall Amortization Information – This information includes outstanding amortization balances for a given plan, annual amortization installments, and remaining amortization periods, as well as any optional amortization elections for prior years, as provided in the attachments to the Schedule SB.

Projection of Active Data – Refer to Section 2.2.2 for further detail on this subprocess.

Second Tier – Bundled Plans Active, TV, and Retiree Data Profiles – These profiles consist of participant counts grouped into five-year age and service brackets. As applicable, the profiles will also include average salary and average cash balance account balances, broken into the same age and service groupings. These profiles will be based on an underlying standard data profile for each participant status, adjusted for each synthetic plan bundle to reflect actual participant count and collective plan maturity.

Actuarial Decrement Assumptions – For bundled plans, actuarial assumptions will be pulled from a standard set of assumptions tables. These tables will be calibrated each year based on industry, plan size, and other pertinent characteristics identified by PRAD. However, these tables will not vary at the plan level.

Plan Provisions – Plan provisions for bundled plans within PIMS will utilize a uniform benefit formula. However, information on plan benefit formula type will be obtained from Form 5500 electronic datasets (as noted in Section 4.2.2). Having this information available will enable PRAD to perform analysis based on benefit formula type, without necessitating the additional programming complexity of valuing distinct benefit formulas.

Shortfall Amortization Information – Detailed amortization schedule information will not be collected for bundled plans. Instead, aggregate outstanding balances and installment amounts will be collected from Form 5500 electronic datasets and will be used as a proxy to perform minimum funding calculations.

Additional Data Inputs PBGC-Trusteed Plan Liability Data – Liability for plans trusteed by PBGC at the outset of the projection timeline will be obtained from the Individual Participant Valuation of Future Benefits (IPVFB) system maintained by the Actuarial Services Department (ASD). This liability will reflect individual participant census for trusteed plans with completed termination valuations and scaled to account for trusteed plans with pending termination valuations. In conjunction with development of the Cash-Flow Model, PRAD will evaluate whether the underlying cash flows developed by ASD within the IPVFB system are suitable to leverage within the T-PIMS Cash-Flow Model. See Section 2.3 for further detail on Cash-Flow Model structure.

PBGC Asset, Expense, and Premium Data – PIMS will also utilize the following initial input information:

· PBGC starting assets held in the SE program trust and revolving funds will be used to calculate PBGC’s initial net financial position, in conjunction with starting PBGC-trusteed plan liability. This information will come from the PBGC Annual Report.

· Current and historical SE program expenses will be used to calibrate the model’s projection expense and expense reserve assumptions. This information will also come from the PBGC Annual Report.

· Current PBGC flat and variable premium income will be used to calibrate aggregated PBGC premiums calculated by the model. This information will be obtained from the most recent set of PBGC premium filings.

Liability Calculation Engine The liability calculation engine will use the starting census to calculate Year 0 funding target and normal cost, PBGC premium funding target, accounting liability, and PBGC termination liability, as well as developing projected cashflows and expected benefit payments for each year. The calculation engine will then project the census data profiles forward one year using a bankruptcy “Employment” variable (defined in Section 4.2.5), as well as the plan’s new entrant and decrement assumptions (see the Project Data Profiles to Year N + 1 subprocess in Section 2.2.2 for further detail), and then will perform the same actuarial calculations for Year 1. This process will loop through the full projection horizon, generating an actuarial calculation output set for each year of the projection cycle. The key liability calculation engine components are described in more detail below:

Year N Participant Data Profiles – These data profiles consist of the combined set of active data profiles pulled from the Form 5500, as well as the TV and Retiree Data profiles generated through the 100-year inactive projection process.

Year N Economic Variables – The economic variables are stochastically projected by the Economic Model and will be used to project and discount liability cashflows, as well as to project plan asset experience. These variables are described in individual detail in Section 4.2.4. See Section 2.2.3 for further detail on the Economic Model.

Actuarial Decrement Assumptions – See above description in Input Data section.

Plan Provisions – See above description in Input Data section.

Year N Actuarial Calculations – Refer to Section 2.2.2 for further detail on this subprocess Project Data Profiles to Year N + 1 – Refer to Section 2.2.2 for further detail on this subprocess.

Plan Output The Plan Output process will utilize the actuarial liability calculation set for each year, coupled with projected plan assets, to develop net funded status, target normal cost, development and projection of shortfall amortization components, minimum required and actual contribution amounts, PBGC premiums, and expected asset return. The key plan output components are described in more detail below:

Funding Liability for Year N – This represents the funding liability (referred to as the funding target) as defined by the Employee Retirement and Income Security Act of 1974 (ERISA) and the Pension Protection Act of 2006 (PPA). The funding target for a plan for a year will be calculated individually for each of that year’s active, TV, and retiree profiles, using applicable funding segment interest rates and mortality, and based on underlying plan provisions. The aggregated liability across all profiles will constitute the funding target liability for a given year. The projection model will default to current funding regulations but will include parameters to model potential changes to these regulations for future TA requests.

PBGC Premium Liability for Year N – The PBGC premium liability for a plan for a year will be calculated individually for each of that year’s active, TV, and retiree profiles, using applicable interest and mortality, and based on underlying plan provisions. The aggregated liability across all profiles will constitute the PBGC premium funding target liability for a given year.

Accounting Liability for Year N – This will include the Projected Benefit Obligation (PBO) and Accrued Benefit Obligation (ABO) as determined on a Financial Accounting Standards Board Accounting Standards Codification Topic 715-30 (ASC 715) accounting basis. This liability for a plan for a year will be calculated individually for each of that year’s active, TV, and retiree profiles, using ASC 715 interest (derived from high quality corporate bond rates from the economic model, calibrated against cash flow duration) and mortality, and based on underlying plan provisions. The aggregated liability across all profiles will constitute the ASC 715 liability for a given year. The accounting liability calculations will be used as inputs to the model’s de-risking module (described below in the De-Risking Inputs component).

PBGC Termination Liability for Year N – The PBGC termination liability for a plan for a year will be calculated individually for each of that year’s active, TV, and retiree profiles, using ERISA 4044 interest and mortality, based on underlying plan provisions, and reflecting PBGC benefit limitations. Based on a 2019 study performed by PRAD the impact of the various limits are as follows:

· The Maximum Guaranteeable Benefit Limitation resulted in the most significant reduction to trusteed plan benefits relative to other PBGC benefit limitations. The impact of this limitation can also be directly calculated using the individual liability calculations for each age/service participant data profile. Therefore, this limitation will be modeled within T-PIMS at the individual data profile level.

· Accrued at Normal Limitation resulted in substantially lower benefit reductions for trusteed plans than the Maximum Guaranteed Benefit Limitation. However, for the subset of plan to which this limitation would apply, the reductions can be significant. Therefore, the T-PIMS model will include optional scaling parameters to account for impact of Accrued at Normal benefit limitations on a plan-by-plan basis. These parameters will be set by the user, as desired, but otherwise will default to 1 (no impact). This method will allow PRAD to avoid the need for elaborate programming only applicable to a minority of plans, while still providing the capacity to reflect this limitation as needed.

· Phase-In Limitation also resulted in substantially lower benefit reductions for trusteed plans than the Maximum Guaranteed Benefit Limitation. Further, the majority of benefit reductions tied to Phase-In Limitations were attributable to changes to plan provisions increasing benefits (as opposed to new plan phase-in). Because T-PIMS will not house multiple benefit formulas for a given plan, the bulk of the impact from this limitation would not be accessible under the proposed T-PIMS structure. Therefore, this benefit limitation will not be modeled within T-PIMS.

The aggregated liability across all profiles (adjusted for Maximum Guaranteed Benefit and Accrued at Normal Limitations) will constitute the PBGC termination liability for a given plan and year.

Projected Plan Assets for Year N – Plan assets will be projected forward from the prior year using calculated prior year required contributions, PBGC premium, asset return, benefit payments, and expenses. This component represents both the Market Value of Assets (MVA) as well as the Actuarial Value of Assets (AVA) reflecting any applicable asset smoothing.

Shortfall Amortization Information – See above description in Input Data section. New shortfall amortization bases will be calculated for each projection year, as applicable, and projected forward. This information will be used to calculate the minimum required contribution component described below.

Expected Benefit Payments for Year N – This amount will consist of aggregated benefit payments across all participant data profiles for a given year.

Expected Asset Return for Year N – This component will be calculated using the stochastically projected bond and equity return variables. The return calculation will incorporate plan-specific asset allocation information, and will reflect projected assets, contributions, and benefit payments for a given year.

Determine Plan Sponsor Contribution for Year N – Refer to Section 2.2.2 for further detail on this subprocess.

Calculate PBGC Premium for Year N – Refer to Section 2.2.2 for further detail on this subprocess.

Project Assets to Year N + 1 – Refer to Section 2.2.2 for further detail on this subprocess.

Bankruptcy Node – This node encompasses outcomes from the bankruptcy model, which will provide either a probability of bankruptcy based on the projected economic and firm variables, or else a binary yes/no bankruptcy result. See Section 2.2.4 for further detail on the Bankruptcy Model.

De-Risking Inputs – De-risking input information will include: the plan’s participation and accrual status (open, closed to new entrants, or closed to new entrants and accruals); the plan sponsor’s hedged position, determined based on asset allocation and duration information matched against liability duration; and the plan’s funded status on an accounting basis.

De-Risking Activity – This node will encompass both standard plan terminations, as well as partial de-risking behavior.

The proposed criteria to trigger a standard plan termination will be as follows:

1. Plan is already hard frozen (participation and accruals); and

2. Plan reaches full funding level on a Financial Accounting Standards Board Accounting Standards Codification Topic 715-30 (ASC 715) accounting basis.

The above criteria will serve as a starting point for the core de-risking model component. However, the logic underlying de-risking trigger circumstances/events will accommodate any model parameters, such that PRAD can make discretionary adjustments to recalibrate de-risking triggers based on observed or anticipated plan sponsor behavior. For example, Liability-Driven Investment (LDI) strategies will be inferred from plan sponsor investments (based on Form 5500 electronic data) and may also be used as a conditional parameter for targeted de-risking strategies.

Plans that satisfy user-determined de-risking criteria will trigger the standard termination decision node (parameterized based on user input to assign either a scalable probability or binary outcome). If T-PIMS is configured to use a probabilistic approach, ongoing liability for the plan will be scaled by [1 – probability of termination]. If T-PIMS is configured to use a binary approach, the plan will be assumed to leave the insured population of SE plans once the above criteria are met. The model will also incorporate parameters to adjust standard termination probability calculations to reflect specific plan characteristics (e.g. plan size), based on user input.

The above criteria will be initially determined by Form 5500 data inputs; however, de-risking inputs will be modeled over the projection period for plans that don’t satisfy these criteria at Year 0 based on a user-defined set of transition probabilities for plan freeze and investment strategy. These transition probabilities may be set either as a flat probability, or else tied to economic model parameters (if PRAD wants to capture correlation between economic conditions and plan sponsor de-risking behavior). This will provide PRAD with the flexibility to calibrate de-risking behavioral trends based on recent or anticipated plan sponsor de-risking experience.

The criteria to model partial de-risking behavior (lump sum windows and retiree buy-outs) will follow similar logic to that used for the standard termination decision criteria. The partial de-risking triggers will be programmable using the same set of model parameters as the standard termination decision node, but with no requirement to follow the same decision logic. This will enable PRAD to capture more nuanced trends in observed or anticipated plan sponsor behavior. Alternatively, should PRAD wish to model partial de-risking activity at a broader level, the de-risking logic could reference fewer parameters, to simply apply flat probabilities based on a few key plan characteristics.

PBGC Output The PBGC Output process will aggregate plan-level output, applying bankruptcy outcomes for each respective year, to generate the PBGC net position at each year in the projection cycle. The net position will reflect starting PBGC liability for existing trusteed plans, starting PBGC assets, projected PBGC premium revenue, as well as PBGC termination liability and associated plan assets from new potential bankruptcies projected by the model. The key PBGC output components are described in more detail below:

PBGC-Trusteed Plan Liability for Year 0 – Starting PBGC liability in initial projection year for all plans trusteed by PBGC, as provided by ASD.

PBGC Plan Assets for Year 0 – Starting PBGC plan assets in trust fund and revolving fund.

PBGC Net Financial Position for Year 0 – Starting PBGC assets less PBGC liabilities.

PBGC-Trusteed Plan Liability for Year N – Aggregate PBGC liability will be developed by rolling forward the starting PBGC-trusteed plan liability and will incorporate new plan termination liability from insured plans based on plan sponsor bankruptcy outcomes through the model projection period.

PBGC Plan Assets for Year N – PBGC assets at Year N will be developed using the starting PBGC assets in the initial projection year, projected forward reflecting investment income, benefit payments, and expenses. Projected PBGC assets will incorporate new plan assets from insured plans based on plan sponsor bankruptcy outcomes through the model projection period.

PBGC Net Financial Position for Year N – PBGC assets less PBGC-trusteed plan liability for Year N.

Aggregate Liabilities for All Plans – Refer to Section 2.2.2 for further detail on this subprocess.

Aggregate Assets for All Plans – Refer to Section 2.2.2 for further detail on this subprocess.

Project PBGC-Trusteed Plan Liability to Year N + 1 – Refer to Section 2.2.2 for further detail on this subprocess.

Project PBGC-Trusteed Plan Assets to Year N + 1 – Refer to Section 2.2.2 for further detail on this subprocess.

Run Post-Processing Calculations for Projections Report – Refer to Section 2.2.2 for further detail on this subprocess.

Projection Report Output – Refer to Section 5 for further detail on model output.

Core Model Calculation Processes The calculation processes that drive the core actuarial model include the development of inactive data profiles, calculation of actuarial liability, and development of plan-level and PBGC-level results. These processes are described in greater detail below.

Project Active Data to Develop Inactive Census Data Profiles – The inactive census data profiles will be developed by projecting the active data profiles forward 100 years using the plan’s underlying actuarial assumptions for retirement, termination, disability, and mortality experience. For plans that are open to new entrants, the new entrant profile will be based on the age distribution for current active participants with less than five years of service. For plans that are closed to new entrants, the projection will account for the timing of the participation freeze, incorporating this as an inflection point for new entrants. Projecting 100 years provides a sufficiently long-time horizon that the projected inactive age/service distributions for both TVs and retirees reach an equilibrium based on the plan’s particular new entrant profile. The projected TV and retiree counts will then be scaled to align with actual TV and retiree counts taken from the current year Schedule SB.

Note that, if PBGC were to obtain additional information regarding inactive average ages and/or benefit amounts (for example, from additions to PBGC premium filing requirements), T-PIMS would have the flexibility to incorporate this information to refine the process of developing inactive census data profiles.

Year N Actuarial Calculations – Actuarial liability for a given plan and year will be calculated individually for each of that year’s active, TV, and retiree profiles, using applicable funding segment interest rates, actuarial decrement assumptions, and plan provisions. The aggregated liability across all profiles will constitute the funding target liability for a given year. Note that the actuarial calculation methodology for plans modeled individually and for synthetic bundled plans will be the same. Each synthetic bunded plan will have a set of active, TV, and retiree census data profiles, as well as key actuarial assumptions and plan provisions determined as described in Section 2.2.1.

The key elements of the calculation process are described below:

1. Determine Monthly Benefit – The monthly benefit will be calculated for each individual data profile based on service, salary, and/or account balance information for that profile. For actives, ongoing benefit accruals will likewise be calculated at each subsequent valuation date, through the year in which the probability of retirement reaches 100%. Vesting percent will be applied based on the plan’s vesting schedule. Additionally, the PBGC Maximum Guaranteed Benefit Limit will be applied to develop the participant’s guaranteed monthly benefit, for the calculation of PBGC (ERISA) 4044 liability in the event of plan termination.

2. Apply Decrement Assumptions – As applicable (depending on participant status), termination, retirement, and disability decrement probabilities will be calculated to determine the probability of a participant moving to a different valuation status.

3. Develop Payment Form Present Value Factors – Present value factors will be developed…