Eagle Accounting stores all MBS/ABS factors used for processing in the Corporate Action table. You can input factors for processing using the Create Final Factor panel in Reference Data Center. The system stores factor history records for each security, based on the security asset identifier.
The Add Pool Factor panels, in contrast, are used solely for reporting and reference information, and do not base any processing against values stored in that table.

...

...

For detailed information about how to manually input factors and use Global Process Center Processes to process factors, see "Managing Manage Factor Corporation Actions."Corporate Actions

About Factors

When you use factors, be aware that:

• The Global and Retrospective Amortization processes only use factor values that have a corporate action status of Released.
• When processing an MBS/ABS trade, Eagle Accounting, by default, enters the most appropriate Factor and Factor Date (from the Corporate Action table) in the trade panels. If no factors are found, Eagle Accounting uses a default factor of 1. Regardless of whether a factor is found, you can override the default factor.
• The Trade Date of the paydown transaction is equal to the Effective Date of the factor. Settlement Date is calculated from the Effective Date of the factor, plus the number of Delay that appear in the security master record.
• Trade Date of the payup transaction is equal to the Effective Date of the factor. The Cost Object Settlement Date is equal to the Effective Date of the factor, to properly facilitate the accrual process; on the Cash Object, the Settlement Date is calculated from the Effective Date of the factor, plus the number of Delay Days that appear in the security master record, to offset the receivable.
• Income and principal are received as two different receivables.
• Paydown factors and gain/loss are applied, and calculate at the lot level.
• Eagle Accounting processes all factor payments based on a pro-ration approach. Pro-ration is the process of taking the percentage of par being reduced, and applying that percentage to the amortized cost, to calculate the gain or loss caused by a paydown.
• IO Paydown transactions are for zero cash.
• For Eagle Accounting to calculate the paydown amount, a factor must also exist in Eagle Accounting for the prior month.
• When earnings are rolled backed past a factor date, Eagle Accounting automatically cancels that factor. You have to manually re-trigger the factor, via factor processing, to replay the corporate action.

...

Process a Paydown Factor Example

This example uses security 31296TG32. The panel information for this security follows.

...

...

...

Trade Details

Security 31296GT32 is purchased in Portfolio MBSDEMOG, with:

...

• The entity is set up to recognize the gain/loss caused by a paydown as gain/loss; that is, Gain/Loss on Paydowns is set to Yes, and
• The gain/loss is posted to Income; that is, Paydown Gain/Loss Account is set to Income.

Eagle Accounting posts the following general ledger entries, if:

• The entity is set up to recognize the gain/loss caused by a paydown as gain/loss; that is, Gain/Loss on Paydowns is set to Yes, and
• The gain/loss is posted to Capital; that is, Paydown Gain/Loss Account is set to Capital.

Eagle Accounting posts the following general ledger entries, if:

• You recognize gain/loss on paydowns as Amortization.

The 9,975.81 Gain created from the paydown displays in the Income Archive and general ledger when earnings are run.

...

Process a Payup Example

This example demonstrates payup processing in Eagle Accounting, using the following security information.

...

...

Trade Details

The security PAYUP DEMO is purchased with the following attributes:

1. The security is then accrued for the period, producing a Receivable of 33,188.76.

...

(Original face * Current factor) - Current Face
or,
(2,000,000.00 * 2.007920081) - 3982651.40 = 33.188.76.

After the new lot is created, Eagle Accounting automatically processes an open adjustment transaction, to allocate a portion of the original face from the parent lot, to the new lot created from the payup transaction. Eagle Accounting allocates the original face by dividing the new lot by the current factor:
(33,188.76 / 2.0079200810) = 16,528.92479
of Original Face is Allocated From Parent to new Lot.
By allocating a portion of the original face, each lot is now in sync based upon the current factor. Eagle Accounting allocates the original face to new lots caused by payup because this allocation facilitates disposition processing. Each lot for disposition processing must have the original face.

...

About Stale Factor Processing

Stale factor processing automatically corrects trades that are processed with incorrect or stale factors.

An example of a stale factor trade occurs when a security is bought in one month and settled in a future month. Because factors are not known in advance, the trade is set up with the current month's factor. When the factor for Settlement Date becomes available, the factor on record for the trade is now known as "stale." The trade would now have to be cancelled, and rebooked with the current factor.

Eagle Accounting can auto-correct trades that were input with stale factors when running factor processing. Stale factor processing works as follows: when factoring is run against a position with stale factor buys and/or sells, the factor procedure rolls back the stale trade, then replays the trade with the correct amounts, based on the new factor. The original trade is canceled and stored with the original amounts, reflecting the stale factor.

Eagle Accounting does not automatically roll back and replay a trade with a stale factor. If you want Eagle Accounting to automatically roll back and replay stale factor trades when factor processing is invoked, you must set the Stale Factor Processing (tag 8141) field to Yes at the entity level. For details, see "Setting Up Entities for Fixed Income Processing." Create/Edit Entity Panel Options.

When you set the entity's Stale Factor Processing field to:

• Yes. Stale factor processing occurs when you run factor processing and process paydown/payup transactions. Processing ignores the lot level Stale Factor Processing value but updates it to reflect the current value of the entity level Stale Factor Processing field. The system determines rollback by the Settlement date, orders replay by the Trade date, and creates paydowns with the correct quantity.
• No. Stale factor processing does not occur when you run factor processing. Processing ignores the lot level Stale Factor Processing value but updates it to reflect the current value of the entity level Stale Factor Processing field. The system determines rollback by the Settlement date and orders replay by the Trade date.
  
  All activity with the Trade date less than the Paydown date and the Settlement date less than the Paydown date created with a stale factor needs to be rebooked. Paydowns that occur when there is a Close with the Trade date less than the Paydown date and the Settlement date greater than or equal to the Paydown date and have a stale factor do not have the correct quantity until the Close is rebooked with the correct factor. If the Close has the current factor at the time of the paydown, the paydown has the correct quantity.

State Factor Processing Example

An example of Stale Factor Processing follows.

A trade was bought on 3/8 and settled on 4/4, with a Factor of 1 (a Stale Factor):, as shown in the following table. 

You enter a Factor of .9 on 4/1. When the factor process is run, Eagle Accounting automatically rolls back the original trade and replays it with the correct 4/1 factor of .9.

The trade now appears as followsshown in the following table.

If the Stale Factor Processing option is not enabled for the entity associated with the trade in Eagle Accounting, you have to manually cancel the original trade when the factor is known, and then manually rebook the new trade using the current factor.