Title: OFHEO GUIDELINE 408 - Risk Based Capital - Guidelines for Preparing 
and Submitting System Change Requests (SCRs)

Approved By: Armando Falcon, Jr. Date: November 8, 2002

I. PURPOSE: 
The purpose of a System Change Request (SCR) is to describe and justify a 
modification to the software and/or the documentation (including RBC Business 
Rules, the RBC Report Instructions, and FAQs) associated with Risk-based Capital 
model. 
II. Scope: 
The policy set forth in this guideline applies to OFHEO employees and 
contractors. It also provides guidance to the Enterprises or other parties that 
may propose changes to the software or related documentation associated with 
the Risk-based Capital model. 
The Director of OFHEO or his/her designee has the discretion to alter any of the 
procedures set forth within this guideline. 
III. Authority And References: 
Change Management Control Board (CMCB) Charter. 
IV. Effective Date: 
These guidelines are effective upon approval by the Director. The Change 
Management Control Board has authority for modifying procedures for preparing 
SCRs (see Appendix), as appropriate. 
V. Policy: 
At a minimum, an SCR must contain sufficient information to allow individuals 
with a general understanding of OFHEO, its mission, and the RBC rule, but who 
otherwise are not subject matter experts, to evaluate the proposed change. 
SCRs are prepared in the format established and maintained by OFHEO’s Change 
Management Control Board (CMCB). 
SCRs are submitted to the CMCB for review and approval in accordance with the 
guidelines established for the operation of the CMCB (Guideline 409). 
VI. Responsibilities: 
All OFHEO offices – Ensure the preparation of SCRs, as needed, to present any 
Risk Based Capital rule issue identified that relates to an area for which the 
specific OFHEO office has responsibility, and for which a change to the RBC 
source code and/or related documentation is required. 
Office of General Counsel (OGC) –As appropriate, provide subject matter 
expertise to assist in the preparation and evaluation of an SCR. 
Office of Information Technology (OIT) – As appropriate, provide subject 
matter expertise to assist in the preparation and evaluation of an SCR. 
Office of Policy Analysis and Research (OPAR) – As appropriate, provide 
subject matter expertise to assist in the preparation and evaluation of an SCR. 
Office of Risk Analysis and Model Development (ORAMD) – As 
appropriate, provide subject matter expertise to assist in the preparation and 
evaluation of an SCR. 
Chair of the Change Management Control Board (CMCB Chair) or 
Designee – Manage to established guidelines and procedures to ensure the 
prompt review and consideration of all SCRs. 
Change Management Control Board (CMCB) – Review all submitted SCRs 
and make a determination as to the SCRs’ status. 
VII. Definitions: 
SCR: System Change Request. The standard form used to describe and justify a 
modification to the software and/or the documentation (including the RBC Report 
Instructions and FAQs) associated with Risk-based Capital model. 
VIII. Types of Records Created or Received: 
  System Change Requests. Appendix 
Procedures for Preparing and Submitting SCRs 
Overview 
An SCR is submitted to the Change Management Control Board (CMCB) once: 
1. a recommended resolution to an open issue involving the implementation or 
processing of OFHEO’s Risk-based Capital Rule (the Rule) has been determined, 
or 
2. a similar enhancement has been developed, 
that requires a change to the source code, RBC Business Rule, and/or RBC Report 
Instructions, or requires the creation of an FAQ. The CMCB reviews the SCR and 
determines whether: 
1. the SCR contains sufficient clarity and detail for consideration by the CMCB, 
2. the requested change falls within the scope of the CMCB’s approval authority, 
3. the SCR’s recommendation is appropriate. 
If approved, the CMCB assigns a priority to the change based on its capital impact as 
well as its processing impact. Additionally, the CMCB schedules the implementation 
date of the approved change and monitors the implementation of the change through 
systems analysis and development, acceptance and integration testing, and final 
approval. 
SCR Preparation 
Each OFHEO Office as well as each Enterprise may establish its own process for 
performing the analysis required to prepare an SCR, and for any internal review of the 
SCRs prior to the submission to the CMCB. Subject matter experts within OFHEO and 
at the Enterprises are available to assist in the preparation of SCRs. In particular, it is 
advisable to consult with OFHEO’s Office of General Counsel (OGC) for any issues 
where it is unclear if the resolution requires a rule change or a rule correction. 
Similarly, OFHEO’s Office of Information Technology (OIT) may need to be included in 
the SCR preparation process to determine the feasibility of the issue resolution, or the 
best way to express the resolution. In addition to preparing SCRs, the Enterprises are 
available to provide background on their specific business practices, and SCR preparers 
are strongly encouraged to discuss any SCR that has a material impact on an 
Enterprise’s capital calculation or on its operations with the Enterprises prior to 
submission to the CMCB. 
It is the preparer’s responsibility to ensure that each SCR provides enough information 
to support the decision-making process and gives adequate direction to implement the 
requested change. To that end, the CMCB has approved the System Change Request 
form (both hardcopy and electronic versions) to assist the preparer in organizing and 
presenting required information. The data fields required are detailed below, along 
with a description of the required information. 
Unless otherwise indicated, the data fields on the SCR form are completed by the 
preparer. 
Unless otherwise indicated, all fields must be completed. 
SCR Information Requirements 
SCR Number: Uniquely identifies each SCR for tracking purposes. Assigned by the 
change tracking system when the SCR is submitted for consideration by the CMCB. 
JVMT Number: Identifies the tracking number of the Joint Validation Management 
Team issue to which the SCR relates. If there is no associated issue, None is entered. 
Related SCRs: Indicates any other SCRs that relate to the change being requested. 
Most commonly used to associate code changes with Report Instructions changes. If 
there are no associated SCRs, None is entered. Usually, the preparer will not know the 
SCR numbers at time of submission, and must work with the CMCB’s change tracking 
coordinator to ensure that the fields are completed prior to consideration by the CMCB. 
SCR Date: The date the preparer submits the SCR to the CMCB for consideration. 
SCR Description: A concise summary that captures the general topic of the change 
requested. Used to identify the content of the SCR. 
SCR Type: Indicates that the SCR proposes a change to the RBC source code, the RBC 
Business Rules, the Report Instructions, or that the SCR is an FAQ. 
Change Type: Indicates if the change is needed to correct an existing defect, to 
enhance the current functionality, or to accommodate a Rule change/correction. There 
are situations where the distinction between a defect and an enhancement is not clear. 
Generally, changes are corrections when the existing code processes the submitted 
data in a manner that is inconsistent with the methodology explicitly described in the 
Rule. Similarly, changes to the Report Instructions that are necessary to make the 
Instructions consistent with the Rule are also considered corrections. An enhancement 
might include code changes that make the processing more efficient without changing 
the model results, or Instruction changes that improve the understanding of how to 
submit required data without changing the data submitted. For FAQs, None is entered. 
Rule or Report Instruction Section(s): Identifies all sections of the Rule and/or Report 
Instructions that relate to the issue prompting the SCR. 
Modules: Identifies the modules within the Code that are affected by the SCR. 
Completed by OIT during technical analysis, after the CMCB has approved the SCR. 
Development LOE: For source code changes, specifies the total number of “person- 
days” required by OIT to implement the requested change and release the modification 
for testing. Completed by OIT during technical analysis, after the CMCB has approved 
the SCR. 
OFHEO Contact: Provides the name and extension of the OFHEO employee who 
prepares or sponsors the SCR. For SCRs prepared by the Enterprises, the OFHEO 
contact is responsible for verifying and validating all information contained in the SCR 
prior to submission to the CMCB. 
CMCB Date: The date the SCR is considered by the CMCB. Completed by the CMCB 
change tracking coordinator. 
Reason: Provides any necessary background related to the request, as well as a 
thorough description of the problem/issue, in terms understandable by someone who is 
familiar with OFHEO and the Enterprises, but is not necessarily a subject matter expert 
in the issue at hand. 
For FAQs, provides any necessary background as well as a short discussion as to why 
the FAQ is necessary (e.g., to answer actual questions received, to try and avoid future 
questions, to address data submission problems, etc.). For FAQs that are being used to 
communicate forthcoming technical amendments, the preparer must certify that a Form 
40 has been prepared and approved. For FAQs clarifying or amplifying existing 
documentation, the preparer must include a statement certifying that the preparer has 
reviewed the applicable sections of the Rule and the Report Instructions, and that the 
FAQ is consistent with information contained in those other sources. 
Functional Requirements: Provides a description of the functionality required to resolve 
the issue. The description should be of sufficient detail for OIT to use for coding purposes. The section also includes a discussion of the logic behind the code changes, 
including the inputs and outputs affected, and the reason that the proposed solution 
has been chosen (if other options have been considered). In cases where a calculation 
is involved, the Functional Requirements field includes specific equations to be used in 
determining the desired results. The SCR does not introduce new nomenclature or 
variable names that are different from those contained in the Rule or other 
documentation for the same data elements. (All acronyms used in the equations 
supplied by the preparer must be defined within the text of the SCR, even if they are 
defined in the text of the Rule.) 
For significant modifications to the existing code, or for the introduction of new 
treatments, the Functional Requirements are presented in the format of the Rule, with 
an input section (including any necessary definitions), a procedures section that 
provides equations and descriptive text about the calculations, and an output section 
that defines each output variable and explains where it is used in the model. 
If possible, an example, either within the text of the SCR or as part of an attachment, is 
included. Examples, such as cash flow files, are used both to illustrate errors and to 
show desired results. The examples are annotated to clearly relate to the description in 
the SCR. 
Examples of source code or pseudo-code are not required, and are often 
counterproductive in that the source code example may constrain OIT in determining 
the best approach to provide the required functionality. 
For changes to the Report Instructions, the preparer must: 
1. identify the Section(s) and or Appendixes to be changed. 
2. provide the exact language that is currently in the Instructions. 
3. provide the exact language that will be in the Instructions after the change is 
implemented. (The language provided will be used as the new text for the 
Report Instructions; therefore, simply describing necessary edits is not sufficient. 
The new language must appear verbatim in the SCR.) 
For both code changes and Report Instructions changes, any alternatives considered 
are also provided, along with the reason(s) the alternative is not the recommended 
solution. 
For Business Rule changes, the relevant Rule and Report Instruction sections are 
referenced, along with a description of any existing related Business Rule. If necessary, 
rationale supporting the proposed change is also provided. For FAQs, the Functional Requirements contain only the text that will be published (in a 
question and answer format). 
Capital Impact: When applicable, provides an estimate of the dollar impact of the 
requested change on the capital requirement (or in some cases, on the Enterprises’ 
available capital). Estimates are included for each Enterprise for each of the statutory 
interest rate scenarios. Generally, qualitative descriptions such as “small” and “large” 
are not sufficient. 
The estimate of an SCR’s impact on capital does not have to be based on actual model 
results but may be produced from some alternative analytical approach. (OIT resources 
that are required to produce model runs are usually better utilized on SCR’s that have 
been approved by the CMCB, rather than on preparing SCR’s for CMCB approval.) 
When it is not possible to quantify the capital impact of an SCR, a discussion of the 
circumstances that prevent an estimate from being determined is included. 
Additionally, the volume (both number and dollar) of instruments and/or loan groups 
affected by the change is provided for each Enterprise based on the latest data 
submitted, along with an indication as to whether the requested change will increase or 
decrease an Enterprise’s capital requirement (or capital available). OFHEO staff may 
request capital impact or volume estimates from the Enterprises where appropriate. 
Priority: Indicates the importance and urgency of the requested change. Completed by 
the preparer at time of submission to the CMCB, but may be modified by the CMCB as 
needed. Generally, the following definitions apply: 
Priority 1 indicates that the change is necessary in order to make the code run, 
(2) the change (or related change) is necessary in order to make the code or 
instructions consistent with the published rule (including rule changes and 
amendments) or (3) the change will result in a capital or capital requirement 
change for either of the Enterprises in excess of $1 billion. 
Priority 2 indicates that the change (1) will result in a capital or capital 
requirement change for either of the Enterprises between $100 million and $1 
billion or (2) eliminates the need for manual intervention or for running scripts 
outside of the code. 
Priority 3 indicates that the change (1) will result in a capital or capital 
requirement change for either of the Enterprises that is less than $100 million or (2) will significantly enhance running or testing the Financial Simulation Model 
(FSM). 
Priority 4 indicates that the change has no capital impact but is important to the 
usability or testing of the FSM. 
Priority 5 indicates that the change will improve the operation of the FSM 
somewhat, but there is little adverse impact if the requested change is not 
implemented. 
Acceptance Criteria: provides a general description of the performance standards to be 
used to determine whether or not the implemented code changes or Business Rule 
changes provide the expected/desired results as described in the requirements section 
of the SCR. Additionally, identifies a specific instrument or test case along with the 
related expected results that will be used for testing. This section is not completed for 
FAQs or changes to the Report Instructions. 
Acceptance Testing LOE: For source code changes, specifies the total number of 
person-days required by ORAMD to perform unit testing on the requested change. 
Completed by ORAMD after the SCR is approved by the CMCB. 
Proprietary Information and Public Release of SCRs 
Many SCRs will contain information that is proprietary to one or both Enterprises, but is 
essential for the CMCB to have as part of its decision-making process. Such proprietary 
information is not shared outside of OFHEO. Public dissemination of SCRs is the 
responsibility of the CMCB, and is not undertaken by the individual preparer. 
Review Process 
Although any analyst may research and draft an SCR, the SCR is submitted through the 
CMCB representative of the analyst’s Office, after review by that Office. The purpose of 
the review is to ensure that the SCR contains all of the required information and 
presents all material issues in a way that will allow the CMCB to take appropriate action. 
This review process may be different for each OFHEO Office, but includes the CMCB 
representative so that he or she understands the SCR and its issues well enough to lead 
the CMCB discussion. For complex issues, the preparer may be called upon to present 
the SCR to CMCB. 

(Date: 11/8/02)
(Revision: 0)