1. SWAP DEFERRED TERMINATION EXPENSES

Q: How are data submitted to report swap deferred termination expenses?

A: Submit unamortized termination expenses in the AMT table using existing ledger account codes. Report the unamortized balances and report $0.01 for the face value.

2. LEDGER CODE FOR FAS-RELATED DERIVATIVES

Q: Which OFHEO Ledger Code should be used to submit FAS-related adjustments for derivative instruments?

A: Submit FAS-related adjustments for derivative instruments in A592 (Unamortized premiums, discounts, and fees on derivatives) or L1517 (Unamortized premiums, discounts, and fees on derivatives).

3. CALCULATING RECOMBINABLE SECURITIES

Q: For multiclass securities for which cashflows are generated using Intex, is the ownership percentage calculated correctly for recombinable securities?

A: The ownership percentage is calculated in the RBC Model using the submitted balance as the numerator and the total tranche balance from Intex as the denominator. This formula works with Intex-generated cash flows; however, the percentage may be greater than 100% for certain recombinable CMOs. Below is a summary of how recombinable securities work, and how Intex treats them.

RECOMBINABLE SECURITIES

In many REMIC and SMBS structures, the holders of two classes can surrender them in order to receive a third, different class, whose properties are the same as the sum of the two surrendered classes. For instance, in a deal collateralized by 7% mortgages, the holder of $100 IO and $100 PO could have the right to surrender these bonds in order to receive a $100 7% pass through. A holder of $100 IO and $50 PO could have the right to surrender these bonds in order to receive $50 of a 14% pass through. The amount of any class that would theoretically be outstanding at any point is in most deals called the amount “issued” and is the amount that is recorded in the Federal Reserve electronic payment system. The amount of a class that is currently outstanding for any class is called the amount “circulated”. Among CMO modelers, there is at times a worry over making sure that the two amounts are not confused or inadvertently interchanged.

INTEX

Intex’s modeling staff considers whatever is on the prospectus to be the face amount of the bond, regardless of potential recombinations. When Intex is executed it generates a principal runoff and interest stream that is sized initially off of the initial face amount. To the extent that a system connected to Intex is interested in a portion of a tranche, the connected system must use its concept of ownership percentage to scale the cash flows appropriately In infrequent cases where the initially CIRCULATED amount of a class is less than the full ISSUED amount, then there is the unusual possibility that the ownership percentage will be greater than 100%. In the example above, if the deal were initially circulated as $25 7% pass through, $75 IO, and $75 PO, and subsequently the circulated IO and PO were recombined into 7% pass through, then an investor could own 400 % of what Intex thinks is the face amount for the pass through class. This is ok. The cash flows will merely need to scale UP instead of down, as they are usually. The end result will still be the right cash flows.

4. SIGN CONVENTIONS FOR REPORTING DISCOUNTS AND PREMIUMS

Q: What sign conventions are used to report discounts and premiums?

A: The RBC Rule sign conventions require that all principal and notional amounts for assets, liabilities, and off-balance-sheet instruments be reported as positive values. Discounts and premiums are defined in terms of the face value (F) and the original market value (M) of an instrument as follows: if M > F then premium = M – F, if F > M then discount = F – M. Consistent with these definitions, the cash flow generation and the postings follow the following rules:

• Asset discounts are credit postings to an asset account and amortized discounts have positive values in the cash flow files (i.e., asset discounts increase interest revenues).
• Asset premiums are debit postings to an asset account and accreted premiums have negative values in the cash flow files (i.e., asset premiums decrease interest revenues).
• Liability discounts are debit postings to a liability account and amortized discounts have positive values in the cash flow files (i.e., liability discounts increase interest revenues).
• Liability premiums are credit postings to a liability account and accreted premiums have negative values in the cash flow files (i.e., liability premiums decrease interest revenues).

The accounting rationale for these rules is that discounts and premiums adjust the interest revenues (expenses) to the level dictated by market interest rates.

For example, consider two instruments:

Instrument A.

Balance = $100, term = 1 year, coupon = 6%, payment frequency = annually,

market rate = 10%, price = $96.36

Instrument B.

Balance = $100, term = 1 year, coupon = 10%, payment frequency = annually,

market rate = 6%, price = $103.77

Case 1: Buy A as an asset.

Accounting entry at acquisition:

Accounting entry for interest payment:

Accounting entry for principal payment:

Case 2: Buy B as an asset.

Accounting entry at acquisition:

Accounting entry for interest payment:

Accounting entry for principal payment:

Case 3: Issue A as a borrowing

Accounting entry at issuance:

Accounting entry for interest payment:

Accounting entry for principal payment:

Case 4: Issue B as a borrowingAccounting entry at issuance:

Accounting entry for interest payment:

Accounting entry for principal payment:

5. DATA SUBMISSION PROCEDURES FOR TAX-RELATED ITEMS

Q: For a given Reporting Date, what are appropriate data submission procedures for tax-related items for the Operating Expenses, Taxes, and Accounting table?

A: The RDM assumes calendar year modeling. A December 31 (4Q) data submission is used to run the model beginning January 1 of the following year and a March 31 (1Q) data submission is used to run the model beginning April 1. The table below indicates the time period that the submitted data must cover for three example quarters.

6. END DATE FIELD FOR PLAIN VANILLA 3-MONTH LIBOR FLOATING RATE NOTE

Q: We have a plain vanilla 3-month LIBOR floating rate note. How should we populate the end_date field in the Index Formula schedule?

A: Report the maturity date (mty_date) in the end_dte field for simple floating rate instruments.

7. END DATE FIELD FOR STEP-UP BOND

Q: We have a step-up bond that matures on December 27, 2004, the current coupon is 6.05%, and the rate increases to 6.14% on December 27, 2002, and then the rate increases again to 6.27% on December 27, 2003. How should we populate the end_date field in the Index Formula schedule for the 2Q02 submission?

A: Prepare three idx_Formula records for this instrument. Populate the first idx_Formula as follows: rpt_dte=Jun 30 2002, start_dte=Dec 27 2001, end_date=Dec 27 2002, spread_qty=0.0605, idx_cde=FIXED.

Populate the second idx_Formula as follows: rpt_dte=Jun 30 2002, start_dte=Dec 27 2002, end_date=Dec 27 2003, spread_qty=0.0614, idx_cde=FIXED.

Populate the third idx_Formula as follows: rpt_dte=Jun 30 2002, start_dte=Dec 27 2003, end_date=Dec 27 2004, spread_qty=0.0627, idx_cde=FIXED.

8. CALCULATING MONTHLY INTEREST ACCRUAL

Q: We are having trouble recreating your “monthly_int” column for a fixed-rate cash flow. Can you point us to the problem? It is not due to coupon rounding, since the monthly accruals are not perfectly in sync with the number of calendar days in the period.

A: As is stated in Section 3.8.3.8 of the Technical Appendix to the rule, monthly interest accrual is calculated by prorating the interest cash flow that occurs for an instrument on an actual-day basis. This means that the interest accrual for a particular month has to be offset by an interest payment that occurs somewhere in the cash flows. If this were not the case, then certain accruals would remain on the balance sheet after an interest payment has been made or an interest payment could in fact be larger than the sum of it’s monthly interest accruals.

To obtain the correct interest accruals, all calculations must be made using the exact days in the relevant period. For example, because most years have 365 days, dividing them in two for an instrument that pays semiannually will result in one period having more actual days than the other. To correctly calculate monthly interest accrual you have to divide the semiannual payment for a period by the number of actual days in the period (either 182 or 183) and then multiply this daily accrual by the number of actual days in the month. To simply divide by the actual number of days in the year (365) and then multiply by the actual number of days in the month is to assume that each period has 182.5 days. This would overstate monthly interest accrual in one period and understate it in the other period. (The only situation where the calendar year can truly be divided in half is when there is a leap year and each period has 183 days.)

As detailed in 3.8.3.8, it is important to remember that “…the term “from” means from and including, “to” means up to and not including, and “through” means up to and including.” The Technical Appendix also includes some examples relating to these definitions.

The issue is further complicated for months where there is an interest payment other than the final interest payment, or maturity. For those months, you must split the month on the day where the interest payment occurs. To calculate the interest accrual for the portion of the month prior to the interest payment, multiply the interest cash flow amount times the number of days from the beginning of the month through the interest cash flow day, and divide by the day count between the previous interest cash flow and the date of this interest cash flow (prior day count). To calculate the interest accrual for the portion of the month after the interest payment, the product of the next interest cash flow amount times the number of days from the current month’s cash flow date to the end of the month is used as the numerator, and the day count from the current month’s interest cash flow to the next interest cash flow (following day count) is used as the denominator. The total interest accrual for the month is the sum of the interest accruals for the two portions of the month.

The issue is also complicated when the month is the maturity month for the instrument. In this case, accrued interest should only be calculated up to the maturity date. (Multiply the final interest cash flow amount times the number of days from the beginning of the month through the final maturity and divide by the number of days from the previous interest cash flow date to the maturity date.)

If you follow the instructions in the rule, summarized below with illustrative formulas, you will calculate appropriate monthly accruals that will correspond to the interest payments that occur for a fixed rate instrument:

1. If the current month is not an interest payment month:

(# of days in month) *((Princ Bal * (Int Rate/Pmt Freq)) / ( # of days between the last Int Pmt Date and the next Int Pmt Date))

2. If the current month is an interest payment month:

(# of days between Int Pmt Date and start of month) * ((Princ Bal * (Int Rate/Pmt Freq)) / (# of days between the current Int Pmt

Date and the last Int Pmt Date))

+

(# of days between end of month and Int Pmt Date) * ((Princ Bal * (Int Rate/Pmt Freq)) / ( # of days between the next Int Pmt

Date and the current Int Pmt Date))

3. If the current month is the maturity month:

(# of days between Int Pmt Date and start of month) * ((Princ Bal * (Int Rate/Pmt Freq)) / ( # of days between the current Int Pmt

Date and the last Int Pmt Date))

9. ALLOWABLE VALUES FOR POSITION CODE

Q: What values should be entered in the Position Code field (position_cde) in the Financial Instrument Master table for the option leg of a swaption?

A: The Position Code should be set to “PAY” if the Enterprise has the right, but not the obligation, to enter into the swap agreement with the counterparty at a specified future date.

The Position Code should be set to “RECEIVE” if the counterparty has the right, but not the obligation, to enter into the swap agreement with the Enterprise at a specified future date.

10. REPORTING MULTIFAMILY STEP RATE LOANS

Q: How should multifamily step rate loans be reported for the risk-based capital data submission?

A: Multifamily step-rate loans should be reported in a manner similar to single family step rate loans.

Step rate loans are adjustable rate loans that either (a) adjust only one time in the life of the loan (typically at the end of year 5 or year 7) or (b) adjust more than once in the life of the loan (typically annually for the first two or three years), with no further adjustments thereafter. Step rate loans may adjust based upon an index or according to a contractually-specified amount and, after adjustment, step rate loans resolve to a fixed rate of interest for the remaining term. The stress test models step rate loans that adjust more than once, as if they adjust only once.

To report multifamily step rate loans, enter “STP” as the Multifamily Product Code (Classification Variable) in the Multifamily Data Elements—Individual Loans table. In the ARM Related Data Elements—Individual Loans Table, assign “TR012” as the ARM Index (Classification Variable). If the step rate loan adjusts according to a contractually-specified amount rather than an index, enter the rate of the final adjustment for the Life Ceiling Rate as well as for the Life Floor Rate.

For the Multifamily Data Elements—Loan Groups table, if the Multifamily Product Code is “STP”, restate it as “ARM” after Loan Group aggregation.

11. ENTERING CORRECT VALUES FOR STRIKE PRICE AND FUTURES PRICE WHEN REPORTING FUTURES CONTRACTS AND OPTIONS ON FUTURES

Q: How should I report the strike price for a futures contract, and the futures price for a put or call option?

A: The strike price is only applicable for a put or call option. For a futures contract enter zero. Likewise, the futures price applies only to a futures contract, and should be reported as zero for a put or call option.

12. TRANSACTION CODE FOR DEBT REPURCHASES, EXCHANGES AND PUTS

Q: How do we submit the Transaction Code in the Trade History Table for debt repurchases, exchanges and puts?

A: The trade history transaction code was designed to work like a trade ticket and indicate whether or not an Enterprise is the owner of an instrument. The easiest way to view the entries is to consider the accounting entries that would be produced. BUY, PUT_I, and CALL_E are transactions that would require cash to be paid out. Consequently they are debits. Correspondingly, SELL, ISSUE, REOPEN, CALL_I, and PUT_E are credits. Since assets are posted to debit accounts and liabilities/equity are posted to credit accounts, BUYing an instrument would increase the account balance if the instrument is an asset and would decrease the account balance if the instrument is a liability.

A debt repurchase would follow an ISSUE or REOPEN to a liability account for a given instrument. Since the liability account is a credit account and the ISSUE is a credit, the account balance would increase. A debt repurchase should reduce the account balance and, therefore, should be a debit. Hence it must be a BUY.

A debt exchange is the repurchase (BUY) of the existing debt instrument and an issuance (ISSUE or REOPEN) of another debt instrument.

There are two cases for puts. First if an investor puts debt back to an Enterprise, it would get a PUT_I transaction code. If an Enterprise puts back a purchased asset, a PUT_E should be used.

13. Reporting Mortgage Records in the AMT Table

Q: The Report Instructions are silent about reporting loan information either as discrete records or in aggregate format in the Alternative Modeling Treatment (AMT) table. May I submit aggregated loan records in the AMT table? If so, how should they be aggregated? What are the benefits to submitting aggregated records?

A: Loans may be submitted in the AMT table either at loan-level or in aggregate format using the "loan-group" classification variables and procedures provided in the RBC Report Instructions. The aggregate format is recommended because reporting "loan level" data can potentially create reconciliation problems for loans split across retained and sold portfolios. Also, submitting aggregated records reduces the number of records to be processed by the Model and, therefore, reduces processing time.