Loan Record

Loan records store information about each loan in the member’s account.

This document contains the field name, field description, field number, mnemonic, data type, and default information for each field. Other pertinent information includes:

**Source**  
Indicates where the data in the field comes from:

    **User-entered**  
    The user creates the information in this field.

    **System-entered**  
    A system process populates the value for the field. This value can include data transmitted by the ATM network, when applicable.

    **System-calculated**  
    The system calculates but does not store the value of the field each time the field appears on an inquiry or file maintenance screen.

The Loan record includes the following fields, which are defined below:

Description

This field stores a loan description that appears in inquiries and on statements.

Enter a description of the loan (up to 30 characters).

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Description field from the specified Application record. If you do not make an entry, the following message appears:

Cannot be blank

You cannot save the Loan record until you enter a description.

Loan Type

This field stores a credit union-defined code to identify the type of loan.

Enter a credit union-defined code (00-99 or 0000-9999) to identify the type of loan. If you want to use a four-digit code, contact Jack Henry Support.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Loan Type field from the specified Application record.

The loan type determines what defaults, screens, and GL translations are used for this loan. Many batch programs select a group of loans by their loan type.

Loan ID

This field stores a unique two or four-character ID that identifies the Loan record.

You assign the Loan ID field when you create the Loan record. You cannot access this field for file maintenance. Once you assign a value for the Loan ID field, that ID remains permanently associated with the loan, and you cannot assign the same ID to any other Loan record in the account.

Note: We must make a system parameter setting to let loan IDs be either two or four digits. If you wish to change from two to four-digit IDs, notify your account executive. If you change the number of digits, analyze all specfiles that reference share or loan IDs and make any necessary changes. The following list describes conditions that require changes:

• If the specfile prints a report that includes a share or loan ID, and if there is insufficient space on the report to support a four-character ID, you should reformat the report to allow for four characters.
• If a specfile references a share or loan ID in a temporary field that is defined as CHARACTER(2), you should change the field definition to CHARACTER, or CHARACTER(4).
• If the specfile writes a share or loan ID to an output file, expand the output field to four characters. If subsequent PowerOn specfiles use this file, also change those specfiles to reference a four-character ID. If a third party uses the file, the third party should make changes to their file format to accept the new ID length.

Loan Code

This field stores a code that defines certain characteristics of the loan and determines how Symitar Quest processes the loan.

Data Type Descriptions

(0) Closed End

The loan is a closed-end loan. A description of Closed End appears whenever anyone accesses this Loan record, and Symitar Quest processes the record as a closed-end loan. When a transaction brings the value in the Loan Balance field to 0.00, and if the value in the Interest Unpaid field is also 0.00, Symitar Quest sets the value in the Close Date field of the loan to the system date.

(1) Open End

The loan is an open-end loan. A description of Open End appears whenever anyone accesses this Loan record, and Symitar Quest processes the record as an open-end loan. Symitar Quest does not automatically set a close date for open-end loans, since open-end loans can remain open with a zero balance.

When the value in the ARM Notice field is set to (1) Secured by principal dwelling, and you set this field to a value other than 0 or 1, this error message appears:

Loan Code not allowed for ARM notice

Symitar Quest lets you make advances against an open-end loan. If you set up a line of credit loan as an open-end loan, however, the member cannot take automated advances (through the audio response system, ATM, SymXchange, or for overdraw protection). The open-end loan code is useful for signature loans when the financial institution wants to recalculate the member’s debt ratio or credit score before making an advance.

(2) Line of Credit

The loan is a line of credit loan. A description of Line of Credit appears whenever anyone accesses this Loan record, and Symitar Quest processes the record as a line of credit loan. Symitar Quest does not automatically set a close date for line of credit loans, since line of credit loans can remain open with a zero balance.

You cannot change this field to (2) Line of Credit if the loan is in a participation.

(3) Credit Card

The loan is a credit card loan. A description of Credit Card appears whenever anyone accesses this Loan record, and Symitar Quest processes the record as a credit card loan. Symitar Quest does not automatically set a close date for credit card loans, since credit card loans can remain open with a zero balance. For complete information on in-house processing of credit card loans, see Credit Cards.

You cannot change this field to (3) Credit Card if the loan is in a participation.

Note: Payment Application Methods parameters for user-created mortgage method types (10-9999), (2) Alternate Standard Method I, and (3) Alternate Standard Method II do not apply to a Loan record when this field is set to (3) Credit Card.

(4) Lease

The loan is a lease loan and you have purchased the Leasing Support module from us. A description of Lease appears whenever anyone accesses this Loan record, and Symitar Quest processes the record as a lease loan. When a transaction brings the value in the Loan Balance field to $0.00, and if the value in the Interest Unpaid field is set to $0.00, Symitar Quest sets the value in the Close Date field of the loan to the system date.

Note: Payment Application Methods parameters for user-created mortgage method types (10-9999), (2) Alternate Standard Method I, and (3) Alternate Standard Method II do not apply to a Loan record when this field is set to (4) Lease.

(5) Avg Daily Bal LOC

The loan is an average daily balance line of credit loan. This option can also be used for any line of credit loan that uses average daily balance finance charge calculations. It works properly only when the loan has a value in the Interest Type field set to 10-99. Symitar Quest does not accrue interest for these loans.

This option does not work with promo fields.

Note: If you change this field for existing loans from (3) Credit Card to (5) Avg Daily Bal LOC, make sure that the following Loan record fields contain the correct values:

• Interest Rate Index
• Interest Rate Margin
• Interest Rate Margin Sign
• Interest Rate Maximum
• Interest Rate Minimum
• Discount Rate (optional)
• Risk Rate (optional)
• Schd Rate Change Date
• Periodic Cap
• Periodic Cap Start Rate
• Periodic Cap Start Date
• Periodic Cap Frequency

Note: Payment Application Methods parameters for user-created mortgage method types (10-9999), (2) Alternate Standard Method I, and (3) Alternate Standard Method II do not apply to a Loan record when this field is set to (5) Avg Daily Bal LOC.

(6) LOC Combination

The loan is a SymChoice Loan. SymChoice Loans can have multiple segments, each with its own interest rate and term.

When you select this option, Symitar Quest sets the value in the Max Due Date Advance Period field to 1.

If you select this option, you cannot use the options 1, 5, 6, 7, 8, or 10–8999 in the Loan record Interest Type field.

If you select this option when the Loan has a Schedule record as a child record, this error message appears: If you select this option when the Loan has a Rate Change record as a child record, this error message appears:

Loan Code cannot be set when Schedule record is found

Loan Code cannot be set to Combination Loan due to Rate Change record

Note: Payment Application Methods parameters for user-created mortgage method types (10-9999), (2) Alternate Standard Method I, and (3) Alternate Standard Method II do not apply to a Loan record when this field is set to (6) LOC Combination.

This field must be either (0) Closed End or (1) Open End if a bankruptcy chapter (options 1–4) is selected in the Bankruptcy Chapter Reported field. If you attempt to enter a value other than (0) Closed End or (1) Open End, the following error message appears:

Bankruptcy Chapter Reported is only allowed with Closed End and Open End loans

Symitar Quest prevents you from entering a loan code value other than 0 or 1 when a Loan Bankruptcy record exists. If you attempt to enter a value other than (0) Closed End or (1) Open End, the following error message appears:

Loan Code cannot be changed when Bankruptcy record is found

Symitar Quest does not update this field from the Application record when you use the Pull Fields From App action field.

Activity Date

Symitar Quest stores the date of the previous monetary transaction that affected the Loan record in this field.

Whenever a teller, ATM network, MemberConnect system, SymXchange client system, or batch program posts a monetary transaction to the Loan record, Symitar Quest updates this field with the effective date of the previous monetary transaction.

When you update the Activity Date field in the Loan record, the Activity Date field in the Account record is automatically updated.

When a Loan record is first created, Symitar Quest sets this field to the open date.

The following types of teller transactions and batch transactions do not update this field:

• Insurance (unless you have the Insurance Updts Activity Date parameter in Miscellaneous Parameters set to Yes)
• Fees
• Dividends
• Withholding
• Interest refunds

The following batch programs do not update this field:

• Dividend Posting
• Fee Posting
• Insurance Posting (unless you have the Insurance Updts Activity Date parameter in Miscellaneous Parameters set to Yes)

Under normal circumstances, you should not revise this field.

Check Digits

This field stores check digits that you may use to help Symitar Quest verify account numbers when processing drafts, ATM transactions, or outside processor transactions. Both the account number and the check digits must be valid, or Symitar Quest reports the transaction as an exception.

• Enter up to two check digits that can be used for account verification.
• Type ***** to cause Symitar Quest to calculate the check digits, based on the method set up for your financial institution.

Reference

This field stores any loan-related reference information for an auto loan.

Enter any reference information about the loan (up to 20 characters).

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Loan Ref field from the specified Application record.

Note: The Statement (Data Only Format) file includes this information in the Credit Card Loan Information (Record ID 580) in the Credit Card Number field (field 49).

This reference relates only to this Loan record. Enter any references for the entire account in the Reference field of the Account record.

Nickname

This field stores a nickname for a loan.

Enter a nickname for the loan, such as MY 2007 CAR LOAN.

PowerOn can access this field for reading and writing.

Branch

This field stores the number of the branch that “owns” the loan. When you create a loan record, the default is the branch at which you create the Loan record.

Data Type Descriptions

0

Main branch

1–9999

Credit union-defined branch number

If your financial institution uses branch accounting, you can use this field to specify the branch to which transactions for the loan should be posted. To translate loan transactions to the General Ledger by branch, you must set the GL Translation Branch Level parameter in the Miscellaneous Parameters to (1) Pull GL Branch by Share/Loan Record.

Some batch programs can also produce reports by share or loan branch.

Note: For NetTeller users, the query 60 processes a branch number value of three characters. When the branch number is longer than three characters, the JHADRIVER sends a blank value to NetTeller.

Created By User

Symitar Quest stores the user ID in this field and is populated when this Loan record is created.

Data Type Descriptions

0–9998

The user ID of the creator of the record.

9999

The system is unable to determine the information because it is not available.

Note: This field is also automatically filled with the User ID upon creation of an Account, Loan, Application, or Card record.

Under normal circumstances, you should not revise this field.

Created At Branch

Symitar Quest stores the branch ID in this field of the branch where the Loan record is created.

Data Type Descriptions

0

The system is unable to determine the information because it is not available.

1–9999

The branch ID where the record was created.

Under normal circumstances, you should not revise this field.

Loan Purpose

This field stores the credit union-defined code to indicate the purpose of the loan.

Enter a credit union-defined code (0-999) to indicate the purpose of the loan.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Purpose field from the specified Application record.

Coupon Code

This field stores a code that specifies how Symitar Quest handles loans with the Payment Method field set to (1) Coupon.

Data Type Descriptions

(0) Normal

The coupons have not been generated for loan payments. The first time you run the Daily Posting batch program, Symitar Quest generates a year’s worth of coupons (one coupon for each loan payment scheduled during the year), and sets this field to (2) Generated until the first payment is posted for the loan. This process keeps Symitar Quest from generating duplicate coupons. When the first loan payment is posted, Symitar Quest resets this field to (0) Normal.

The number of coupons Symitar Quest generates depends on the value in the Payment Frequency field for this loan.

Examples:

• If the value in the Payment Frequency field is (4) Monthly, Symitar Quest generates coupons when the value in the Payments Made field is a multiple of 12.
• If the value in the Payment Frequency field is (9) Weekly, Symitar Quest generates coupons when the Payments Made field is a multiple of 52.

(1) Generate

Symitar Quest should reissue coupons for loan payments. You can use this coupon code to regenerate loan coupons if a member has lost them. When you first run the Daily Posting batch program after manually changing the coupon code to (1) Generate, Symitar Quest checks the values of the Payment Count and Payments Made fields and generates the number of coupons necessary to bring the loan into the regular coupon cycle.

Note:

• If the value in the Payment Frequency field is (4) Monthly, the Payment Count field is 48, and Payments Made field is 3, Symitar Quest generates nine new coupons.
• If the value in the Payment Frequency field is (9) Weekly, the Payment Count field is 104, and Payments Made field is 3, Symitar Quest generates 49 new coupons.

Once the Daily Posting batch program generates the new coupons, Symitar Quest sets this field to (2) Generated. When the next loan payment is posted, Symitar Quest resets this field to (0) Normal.

(2) Generated

Under normal circumstances, you should not select this option. The Daily Posting batch program sets this value to indicate that coupons have been generated for the loan, and a loan payment has not posted since the coupons were generated. Symitar Quest monitors the loan and resets this field to (0) Normal when a payment posts.

VIN

Symitar Quest stores a member’s Vehicle Identification Number.

Symitar Quest pulls this value from an Application or Account record.

Under normal circumstances, you should not revise this field.

MFOEL ID

This field stores the credit union-defined code to identify a loan that is part of a Multi-Featured, Open-End Lending (MFOEL) plan.

Enter the credit union-defined code (1-99) to identify a loan that is part of a Multi-Featured, Open-End Lending (MFOEL) plan. Zero is not a valid MFOEL ID.

The Statement Generation batch program uses this field to include closed-end loans in the tabular statement format.

Note Number

This field stores a credit union-defined number associated with this loan.

If your financial institution assigns note numbers to loans, enter the note number of the loan (up to 10 characters) in this field.

You can cause the system to increment the note numbers in new Loan records by specifying a Next Note Number and a Next Note Step in the Miscellaneous Parameters.

When you create a Loan record, the system adds the Next Note Step increment to the last note number assigned to determine the default note number for the new note and stores the new default note number in the Next Note Number parameter. Each time you assign a note number, Symitar Quest updates the Next Note Number parameter with the note number you assigned.

If you create a Loan record and leave this field blank, the system prompts for the note number before you okay the new Loan record. The default at this prompt is NEXT, and if you accept the default, Symitar Quest automatically assigns the note number based on the Next Note Number and Next Note Step parameters.

MICR Account Number

This field stores the account number portion of a draft’s MICR line.

This field can be blank or can contain the account number portion of the MICR line that corresponds to the Loan record. Only enter digits 0–9. There is no minimum length and no enforced check digit requirement. If you use this field, the field’s contents appear along with the Description field value in several places throughout Symitar Quest, including Teller Transactions.

Note: It is the financial institution’s responsibility to ensure that the selected format meets the Financial Industry Standards from Accredited Standards Committee X9, Inc.

The MICR account number information is not included on member receipts and statements. This field is for reference and display purposes only; the system does not use it unless you request that we modify your financial institution’s draft posting edit logic. There is no automatic or enforced connection between this field and any other field in any record, including Lookup records and Check Order records.

Note: No built-in logic calculates or validates this field, but you can write a custom routine as part of the VALIDATE.SHARE specfile, the VALIDATE.LOAN specfile, or a batch file maintenance specfile to set this field.

Last Payment Date

The system stores the date of the last loan payment in this field.

The system updates this field with the effective date of each Loan Payment (LP) teller transaction posted to the loan. You may have to adjust this field manually if you void or adjust a Loan Payment (LP) transaction.

First Payment Date

The system stores the date of the first scheduled payment date for this loan.

The system sets this field to the same value as the Due Date field when the due date is calculated. If the value in the Due Date field is changed before the first payment, the system also updates this field to the same value. This process can occur at the following times:

• During creation of a new loan
• When the Due Date field is blank at the time of a Loan Payment (LP) teller transaction
• During Loan Application Processing if the value in the Due Date field is copied to the Loan record from the Application record

Once the first payment date has passed or the first payment has been made, the system makes no further changes to this field.

After a payment has been received, you cannot perform file maintenance on this field via the Loan record. You can, however, perform file maintenance via a specfile.

Note: If you perform a File Maintenance (FM) transaction and make a change to this field, the system does not update the Due Date field.

Under normal circumstances, you should not revise this field.

Payment Type

This field stores a code to indicate how the system should calculate loan payments.

Data Type Descriptions

(0) Level Payment

The system should calculate equal periodic loan payments. The system does the following: - Calculates a payment schedule that pays off the loan in equal payments (principal + interest = the same amount each period) - Applies the standard payment amount first to the unpaid interest, next to Billed Fee Unpaid field, and only then applies any remainder to the principal

The amount applied to the loan principal changes each period, since the amount of interest due each period depends on the loan balance and the number of days in the loan period. This is the normal option for most daily interest loans.

Select this option for daily billed interest-only loans. Daily billed interest is used for loans where the amount of interest due at the time of statement cutoff is billed to the member. When the member makes a payment, the system takes only the amount of interest that has been billed, even though more interest has accrued. The system applies any amount that the member pays over the billed interest first to the unpaid interest, next to Billed Fee Unpaid field, and only then toward principal reduction.

(1) Level Principal

Symitar Quest should calculate loan payments so that the same amount is applied to the loan principal each period. Symitar Quest does the following: - Calculates a standard principal amount (Original Balance ÷ Payment Count) for each loan payment - Adds any unpaid interest to the payment amount

The total payment changes each period, since the amount of interest due each period depends on the loan balance and the number of days in the loan period. This option is often used for single payment loans, real estate loans, or interest-only payment loans (but not for daily billed interest-only loans). It is also used when loans reach their balloon dates (the value in the Payment Type field changes from (0) Level Payment to (1) Level Principal).

Note: If the value in the Loan Code field is set to (6) LOC Combination, the value in the Payment Type field applies to Segment 0, not the entire loan.

If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Payment Type field of the loan calculation screen.

If you use the MBS Multiple Repayment Programs Per Loan module and have a Schedule record associated with this Loan record that is active, the value of this field is copied from the Schedule record.

For more information on how the payment type affects the loan payment, see the Payment field description.

Payment Method

This field stores a code that specifies how loan payments are to be made.

Data Type Descriptions

(0) Cash

Members must make the loan payments in cash, either over the counter or by mail. The member must also initiate loan payments. Depending on the financial institution services offered to members, the member can make over-the-counter loan payments, pay by mail, pay via ATM or audio response unit, or pay by an EFT ACH origination.

(1) Coupon

The system issues coupons for loan payments. The system generates coupons for loan payments. The member then returns a coupon with each loan payment.

(2) Auto Transfer

Loan payments are made by automatic transfer of funds from the same account or from another account at the financial institution. Create at least one Loan Transfer record that specifies the account and the share from which funds are transferred. Use this option for transferring funds on the due date only. For other options, see options (7) Scheduled Auto Transfer or (8) Scheduled Auto Transfer After Due.

The Daily Posting batch program transfers the full or partial loan payment amount from one or more Share records on the due date of the loan. If the entire loan payment amount is not available, the system transfers the funds each time you run the Daily Posting batch program until the full loan payment amount is satisfied, even if a partial payment was transferred the last time the Daily Posting batch program ran. The system does not advance the due date until the entire loan payment amount has been transferred, not for just two or more partial amounts.

This posting depends on how you have set the Grace Days After Due Date prompt in the Daily Posting batch program. The funds transfer on the due date if the Grace Days After Due Date prompt is set to 0. If it is set to 1, the transfer occurs the day after the due date; if it is set to 2, it occurs two days after the due date, and so on.

(3) Payroll

The loan payments are made by automatic payroll deduction. Create an EFT payroll record for the payroll group from which the loan payments are deducted, if one does not exist.

The Payroll Posting batch program deducts all or a specified part of the loan payment from the first EFT payroll transaction in the loan period.

(4) Payroll After Due

The loan payments are made by automatic payroll deduction from the first payroll after the due date of the loan. Create an EFT payroll record for the payroll group from which the loan payments are deducted, if one does not exist.

The Payroll Posting batch program deducts the loan payment from the first EFT payroll transaction after the due date of the loan. This option is useful if you must increase an automatic payroll deduction to cover a loan payment. Once the loan payment has been deducted, the system resets this field to (3) Payroll.

(5) Distribution

The loan payments are made by distribution of an electronic funds transfer (EFT). Create an EFT record for the payroll group from which the loan payments are deducted, and at least one EFT transfer record specifying the distribution of the payroll funds.

The Payroll Posting batch program deducts the loan payment according to the distribution established for the first EFT payroll transaction in the loan period.

(6) Distribution After Due

The loan payments are made by distribution of the first electronic funds transfer (EFT) after the due date of the loan. Create an EFT record for the payroll group from which the loan payments are deducted, and at least one EFT Transfer record specifying the distribution of the payroll funds.

The Payroll Posting batch program deducts the loan payment according to the distribution established for the first EFT payroll transaction after the due date of the loan. This option is useful if you must increase an automatic payroll deduction to cover a loan payment. Once the loan payment has been deducted, the system resets this field to (5) Distribution.

(7) Scheduled Auto Transfer

The loan payments are made by automatic transfer on a scheduled date, whether a payment is due. Create at least one Loan Transfer record that specifies the account and the share from which funds are transferred.

The Daily Posting batch program transfers the loan payment on a specified date, regardless of whether the loan is paid ahead. If the loan is paid ahead and funds are not available on the date of the scheduled transfer, the system does not attempt to transfer the funds again until the next scheduled transfer date. This option allows the system to accept additional loan payments, regardless of the due date.

The system can temporarily change this field from (7) Scheduled Auto Transfer to (8) Scheduled Auto Transfer After Due under the following conditions: - The value in the Loan Code field is (2) Line of Credit - A loan advance add-on is made on the loan - The value in the New Loan Due Date Code field is a specified number of days (10–99) - The value in the Due Day 1 field is set to a specific day of the month - The date in the New Loan Due Date Code field plus the date of the advance is greater than the value in the Due Day 1 field

The system sets the value in the Due Date field to the day in the nearest Due Day 1 field after the days in the New Loan Due Date Code field from the advance date. However, this payment method ignores the month and year of a loan due date. To prevent a payment being posted on the day in the Due Day 1 field only a few days away, the system changes this field to (8) Scheduled Auto Transfer After Due. Once the first payment is made, the system changes this field back to (7) Scheduled Auto Transfer.

Note: If you have a zero balance loan with a value in the Payment Frequency field of (4) Monthly, the Payment Method field of (7) Scheduled Auto Transfer, the New Loan Due Date Code field of 30, and the Due Day 1 field set to 20; an advance posted on September 17 results in a new value in the Due Date field of October 20. The system changes this field to (8) Scheduled Auto Transfer After Due so that no payment is posted on September 20 (which is three days past the date of the advance). Once the payment is made on October 20, the system changes this field back to (7) Scheduled Auto Transfer.

(8) Scheduled Auto Transfer After Due

The loan payments are made by automatic transfer on the first scheduled transfer date that matches the loan’s due date. Create at least one Loan Transfer record that specifies the account and the share from which funds are transferred, and there must be an entry in the Due Day 1 field of the Loan record.

The Daily Posting batch program transfers the loan payment on the first scheduled transfer date after the due date of the loan, regardless of whether the loan is paid ahead. If funds are not available on the date of the scheduled transfer, the system does not attempt to transfer the funds again until the next scheduled transfer date. This option is useful if you must increase an automatic payroll deduction to cover a loan payment. Once the loan payment has been deducted, the system resets this field to (7) Scheduled Auto Transfer.

For example, if you allow your members to pay ahead on their loans paid by transfer, you either set this field to (8) Scheduled Auto Transfer After Due at the time of the loan creation or you set the effective date of the Loan Transfer record to the first due date at the time of loan creation.

Payment method (7) Scheduled Auto Transfer only looks to the day of the loan in the Due Date field to determine if a transfer payment is due for the loan while payment method (8) Scheduled Auto Transfer After Due causes the system to wait until the due date is reached then looks at the month, day, and year, and then takes the payment.

Example: A member takes out a loan today that is due the 15th of each month beginning in May. Tomorrow is April 15. If the payment method is (7) Scheduled Auto Transfer, the Daily Posting batch program takes a payment. To prevent that, you either set the payment method to (8) Scheduled Auto Transfer After Due or set the loan transfer Effective Date field value to the date of the first payment. If you set the payment method to (8) Scheduled Auto Transfer After Due, the system changes the payment method back to (7) Scheduled Auto Transfer when the first payment is taken.

(9) Amortization Transfer

The loan payments are based on calculations using the Amortization Schedules parameters.

- The calculation is based on the "adjusted" original loan amount and the factor. The system takes any additional payments or advances into account when calculating the "adjusted" original loan amount. The system adds outstanding interest and fees to the calculated amount, if applicable.
- The transfer has the effective date set to the value in the **Effective Date** field in the Amortization Schedules parameters.
- Transfers are not considered for Regulation E.

The system automatically creates a Type 8 Transfer record.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Payment Method field from the specified Application record.

You could ignore this field if you use the Forced Transfer Option Count option in the Daily Posting Batch Program. This prompt lets you force payments to delinquent loans that are not necessarily set up for automatic transfer.

Payment Frequency

This field stores a code that specifies when the member makes a payment.

Data Type Descriptions

(0) Single Pay

The member is to repay the loan in a single payment.

Note: If you select this option in a loan projection, Symitar Quest updates the Payment Type field to Level Principal and automatically updates the Balloon Date field to match the Maturity Date field.

(1) Annual

The member makes loan payments once a year.

(2) Semiannual

The member makes loan payments semiannually (twice per year).

(3) Quarterly

The member makes loan payments quarterly.

For loans with the Interest Type field set to (1) Monthly 360 day, this field must be set to (3) Quarterly, (4) Monthly, or (5) Semimonthly.

(4) Monthly

The member makes loan payments monthly.

For loans with the Interest Type field set to (1) Monthly 360 day, this field must be set to (3) Quarterly, (4) Monthly, or (5) Semimonthly.

For loans with the Interest Type field set to (3) Daily billed I, (4) Daily billed II, (6) Daily Billed 360, or (10-8999) Credit Card Interest this field must be set to (4) Monthly.

For loans with Schedule records, this field must be set to (4) Monthly.

Note: The DQ Calculation Method field should never be changed from Payment Buckets Only Contains Changes to Payment Buckets are Calculated Monthly. However, if this change must be made, you need to look at the payment buckets and ensure that there is a bucket for each due date you want to be able to track delinquency for. Buckets may need to be created for each due date that the loan was delinquent at the time the change needs to be made. This ensures that the system properly recognizes the loan as delinquent. If the buckets are not created, the system assumes that the payments between the current due date and the last due date were $0.00.

(5) Semimonthly

The member makes loan payments semimonthly (twice per month).

Note: If you select this option, you must also enter dates in the Due Day 1 and Due Day 2 fields.

For loans with the Interest Type field set to (1) Monthly 360 day, this field must be set to (3) Quarterly, (4) Monthly, or (5) Semimonthly.

(6) Biweekly skip first

The member makes loan payments biweekly (every two weeks), skipping the first payment of the month if there are three scheduled payments in the month.

(7) Biweekly skip last

The member makes loan payments biweekly (every two weeks), skipping the last payment of the month if there are three scheduled payments in the month.

For loans with the Interest Type field set to (7) Actual/364 or (8) Scheduled/364, this field must be set to (7) Biweekly skip last or (8) Biweekly.

(8) Biweekly

The member makes loan payments biweekly (every two weeks), regardless of the number of payments in the month.

For loans with the Interest Type field set to (7) Actual/364 or (8) Scheduled/364, this field must be set to (7) Biweekly skip last or (8) Biweekly.

(9) Weekly

The member makes loan payments weekly.

(10) Immediate

The loan must be repaid immediately in a single payment.

(11) Weekly skip first

The member makes loan payments weekly, skipping the first payment of the month if there are five scheduled payments in the month.

(12) Weekly skip last

The member makes loan payments weekly, skipping the last payment of the month if there are five scheduled payments in the month.

(13) Bimonthly

The member makes loan payments every other month.

(14) Amortized Schedule

No longer used. The loans are tied to a schedule to pay on the date and for the amount that is in the schedule. The Amortization Schedule field value should be used in these instances and points Symitar Quest to the amortization schedule to decide when to take a payment. The schedule is set up in Parameter Manager.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Payment Frequency field from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Payment Frequency field of the loan calculation screen.

Original Loan Date

This field stores the date the loan was originally disbursed.

Symitar Quest updates this field with the effective date under the following conditions:

• During the most recent New Loan (LN) teller transaction affecting the loan, the Original Loan Date field always updates to the effective date of the LN transaction.
• During the first Loan Advance (LA) teller transaction affecting a zero-balance loan, if the value in the Loan Code field is set to (1) Open End, (2) Line of Credit, or (3) Credit Card), and you disburse the loan using the Loan Advance (LA) teller transaction, Symitar Quest sets this field to the value of the Effective Date field.
• During an advance on an overdraft loan or a credit card loan via NetTeller, Symitar Quest sets this field to the value of the Effective Date field.

Symitar Quest does not update this field with the effective date under the following conditions:

• An advance on an overdraft loan via the Draft Posting batch program
• An advance on a credit card loan in the ATM Dialog work area

Under normal circumstances, you should not revise this field.

Open Date

This field stores the date when the Loan record is created.

Symitar Quest updates this field with the system date when the Loan record is created.

Under normal circumstances, you should not revise this field.

Close Date

This field stores the date the loan is closed.

When you open a new loan, Symitar Quest sets this field to blank.

Symitar Quest updates this field with the effective date of any Loan Payment (LP) teller transaction that pays off a closed-end loan (the value in the Loan Code field is 0). Otherwise, you must update this field manually.

Once a loan has a value in this field, Symitar Quest does not allow any further monetary transactions that affect the loan on or after that date.

Symitar Quest does not allow you to enter a value in this field if the value in the Loan Balance field is not set to 0.00, or if there is an amount in the Interest Unpaid field, or if there are any open Segment records on that Loan record. If you attempt to enter a value in this field when the loan has a non-zero balance, unpaid interest, or open segments, this message appears:

Nonzero balance or unpaid interest

Symitar Quest does not allow you to enter a value in the Close Date field if a Loan Bankruptcy record is open and the value in the Balance field is not 0.00 in any Loan Bankruptcy PrePetition Bal record. If you attempt to enter a value in this field when a Loan Bankruptcy record is open and the value in the Balance field is not 0.00 in any Loan Bankruptcy PrePetition Bal record, the following message appears:

Open Bankruptcy record exists, loan cannot be closed

You must use the Purge Account Processing batch program to delete a Loan record. A Loan record must have a value in this field that is on or before the system date, you must have generated the final statement for the loan, and the loan must have a loan balance of 0.00, or the Purge Account Processing batch program cannot delete that loan.

If you populate this field and there is a balance greater than zero in the Unapplied Partial Payment field, the following message appears:

Error: Unapplied Partial Payment balance, loan cannot be closed.

Due Day 1

This field stores the day of the month on which the first payment is due for semimonthly loans, or the day of the month on which all payments are due for annual, semiannual, quarterly, bimonthly, or monthly loans.

Symitar Quest does not use this field for single pay, weekly, or biweekly loans.

Data Type Descriptions

0

If the value in the Payment Method field is set to anything other than (7) Scheduled auto transfer or (8) Scheduled auto transfer after due and the Payment Frequency field is not set to (5) Semimonthly, type 0 to set the value in the Due Date field to the system date plus one frequency if an advance is taken on the 1st through 27th of the month. If the advance is taken on the 28th through 31st of the month, the value in the Due Date field is set to the last day of the month.

Note:

If a loan has the value in the Payment Method field set to (5) Distribution, the Payment Frequency field set to (5) Semimonthly, and you leave this field to the default 0, when the distribution is posted or when the member makes a manual payment, Symitar Quest blanks out the value in the Due Date field.

1–30

If the value in the Payment Frequency field is set to (5) Semimonthly, enter a value 1–30 to store the day of the month the first payment is due for semi-monthly loans. You must enter a non-zero value in the Due Day 1 field.

The value in the Due Day 1 field must be less than the value in the Due Day 2 field for semi-monthly payment frequencies.

1–31

- If the value in the **Payment Method** field is set to anything other than **(7) Scheduled auto transfer** or **(8) Scheduled auto transfer after due** and the **Payment Frequency** field is not set to **(5) Semimonthly**, enter a value 1–31 to store the specified day of the month in the **Due Date** field.
- If the value in the **Payment Method** field is set to **(7) Scheduled auto transfer** or **(8) Scheduled auto transfer after due**, enter a value 1–31 to store the specified day of the month in the **Due Date** field for the scheduled auto transfer. You must enter a non-zero value in the **Due Day 1** field.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the Due Day 1 field value from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the Due Day 1 field value of the loan calculation screen.

Due Day 2

This field stores the day of the month on which the second payment is due for semimonthly payment loans.

Data Type Descriptions

0

If the value in the Payment Frequency field is not set to (5) Semimonthly, this field is not used. Leave the default at 0.

1–31

- If the value in the **Payment Frequency** field is set to **(5) Semimonthly**, enter a value 1–31 to set the value in the **Due Date** field to the specified day of the month for payment. The value in the **Due Day 2** field must be greater than the value in the **Due Day 1** field.
- If the value in the **Payment Method** field is set to **(7) Scheduled auto transfer** or **(8) Scheduled auto transfer after due**, enter a value 1–31 to set the value in the **Due Date** field to the specified day of the month for scheduled auto transfer.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the Due Day 2 field value from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the Due Day 2 field value of the loan calculation screen.

Due Date

Symitar Quest stores the date the next loan payment is due.

You can update this field manually, or you can let Symitar Quest calculate due dates based on the value in the Payment Frequency field, the Due Day 1 field, and the Due Day 2 field:

• When the loan is set up, Symitar Quest computes the due date by adding one payment frequency to the system date. If there is a value in the Due Day 1 field or the Due Day 2 field, Symitar Quest also ensures that the due date is advanced to the appropriate day of the month.
• If you type 0 in the Due Day 1 field and set the Payment Method field to (3) Payroll, (4) Payroll after due, (5) Distribution, or (6) Distribution after due, Symitar Quest sets the due date to the last day of the month.
• After the loan has been set up, Symitar Quest updates this field as appropriate each time a Loan Payment (LP) teller transaction affects the loan. For additional information about how Symitar Quest calculates due dates, see the Partial Payment field description.
• If you void a Loan Payment (LP) teller transaction, Symitar Quest adjusts this field accordingly. If you adjust a Loan Payment (LP) teller transaction, you may have to update this field manually.
• If the value in the Payment Frequency field in the Loan record is set to (4) Monthly or less, you can set this field when you book the individual loan.
• When you set the Due Date field for a SymChoice Loan, you ensure that Symitar Quest calculates the Due Date field consistently for all Segment records of the loan.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the First Due Date field value from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the Due Date field value of the loan calculation screen.

The following updates occur when the loan Due Date field is extended in the Loan Calculation screen:

• The Maturity Date and Balloon Date fields are updated. Symitar Quest calculates these fields by adding the values from the Loan Months fields to the modified Due Date field.
• The Payment field is updated based on the Symitar Quest loan payment calculation formula.
• Loans that have the Interest Type field set to something other than 1 or 8 calculate interest from the Interest Date field to the modified due date.
• Mortgage loans: Loans that have the Interest Type field set to 1 or 8 calculate the interest per the payment frequency, regardless of the Interest Date field. Example: A monthly payment frequency calculates interest as Balance * Interest Rate / 12. A biweekly payment frequency calculates interest as Balance * Interest Rate / 26. Extending the due date on this loan type is not recommended. Note: If your institution elects to use the Loan Calculation screen for Interest Type fields with a value of 1 or 8, the following Loan record fields must be manually updated:
  • Interest Unpaid: For any unpaid interest
  • Interest Date: To one payment frequency in arrears from the loan due date
  • Pmt Bucket Amt: To store the payment change
  • Pmt Bucket Due Date: To store the effective date of the payment change

If you are using Metro 2® Format (Symitar v.2) and want to report a loan as deferred, be sure to set both the Due Date and the Credit Rpt Deferred Pmt Start fields to an appropriate future date.

Max Loan Due Date

This field contains the calculation of how far the loan’s due date is allowed to advance into the future.

This field is calculated in near-real-time using the Max Due Date Advance Period field value to display how far the loan’s due date is allowed to advance into the future. The value in the Due Date Advance Code field must be set to the (0) Use Max Due Date Advance Period option.

You cannot access this field for file maintenance.

New Loan Due Date Code

This field stores a code that specifies how Symitar Quest advances the due date for an add-on to a zero-balance loan.

Data Type Descriptions

(0) No Change

Symitar Quest should not update the Due Date field. The Due Date field remains the same as it was before the add-on. Use this option for loans with the Loan Code field value set to (0) Closed End and for loans with the Interest Type field value set to (1) Monthly 360 day.

Note: Do not use this option in this field for a SymChoice Loan. This option can cause a SymChoice Loan to become delinquent if you take an advance when the loan balance is zero.

(1) One Period

Symitar Quest should advance the due date by one period from the date of the add-on. If you specify a value in the Due Day 1 field, Symitar Quest advances the Due Date field to that date. The period is determined by the value in the Payment Frequency field.

(2) From the First

Symitar Quest should set the Due Date field as follows: - Start from the first day of the month in which the add-on occurs. - Move forward one period, as indicated by the Payment Frequency field value. For example, if the Payment Frequency field value is set to (4) Monthly, Symitar Quest moves forward one month from the first day of the month of the add-on to set a new value in the Due Date field. - If the Payment Frequency field value is set to (1) Annual, (2) Semiannual, (3) Quarterly, (4) Monthly, or (5) Semimonthly, and if the Due Day 1 or Due Day 2 field values are set, Symitar Quest sets the Due Date field value to the next due day in the month. In most cases this is the value in the Due Day 1 field, unless the Due Day 1 field value is set to the first day of the month, in which case it is the value in the Due Day 2 field. - If the Payment Frequency field value is (1) Annual, (2) Semiannual, (3) Quarterly, or (4) Monthly, and if the resulting date is 28 or higher, Symitar Quest adjusts the value in the Due Date field to the last day of the month.

In some cases using this option in a loan with a Payment Frequency field value of (5) Semimonthly, (6) Biweekly skip first, (7) Biweekly skip last, (8) Biweekly, or (9) Weekly can cause Symitar Quest to set the value in the Due Date field to a date before the add-on occurred.

Note: If an add-on occurs on March 25, this field is set to (2) From the First, and the value in the Payment Frequency field is (8) Biweekly, Symitar Quest starts at March 1 and moves the value in the Due Date field forward 14 days to March 15. The new Due Date field value for the loan becomes March 15, which is 10 days before the add-on occurred.

The same problem can occur when the Payment Frequency field value is (5) Semimonthly, this problem also occurs when Due Day 1 and Due Day 2 field values are set.

Example: If an add-on occurs on March 25, this field is set to (2) From the First, the value in the Payment Frequency field is (5) Semimonthly, and the value in the Due Day 1 field is March 15, the new Due Date field value becomes March 15, 10 days before the add-on occurred.

If the Payment Frequency field value is (5) Semimonthly and the add-on occurs after the value in the Due Day 1 and Due Day 2 fields, the new Due Date field value is always set to a date before the add-on occurred.

(3) From the Last

Symitar Quest should set the Due Date field as follows: - Start from the last day of the month before the add-on occurs. - Move forward one period, as indicated by the Payment Frequency field value. For example, if the Payment Frequency field value is (4) Monthly, Symitar Quest moves forward one month from the last day of the month before the add-on to set a new value in the Due Date field. - If the Payment Frequency field value is (1) Annual, (2) Semiannual, (3) Quarterly, (4) Monthly, or (5) Semimonthly, and if the values in the Due Day 1 or Due Day 2 fields are set, Symitar Quest sets the Due Date field value to the first due day in the month. - If the Payment Frequency field value is (1) Annual, (2) Semiannual, (3) Quarterly, or (4) Monthly, and if the calculated date is 28 or higher, Symitar Quest adjusts the value in the Due Date field to the last day of the month.

In some cases using this option in a loan with a Payment Frequency field value of (5) Semimonthly, (6) Biweekly skip first, (7) Biweekly skip last, (8) Biweekly, or (9) Weekly can cause Symitar Quest to set the value in the Due Date field to a date before the add-on occurred.

Note: If an add-on occurs on March 25, this field is set to (3) From the Last, and the value in the Payment Frequency field is (8) Biweekly, Symitar Quest starts at February 28 and moves the value in the Due Date field forward 14 days to March 14. The new Due Date field value for the loan becomes March 14, which is 11 days before the add-on occurred.

The same problem can occur when the Payment Frequency field value is (4) Monthly, this field value is (3) From the Last, and the Due Day 1 or Due Day 2 field values are set.

Note: If an add-on occurs on March 12 and the Due Day 1 field value is March 10, Symitar Quest starts on February 28 and moves the Due Date field value forward one month to March 28, then uses the Due Day 1 field value to set the new Due Date field value to March 10, two days before the add-on occurred.

If the Payment Frequency field value is (5) Semimonthly and the add-on occurs after the value in the Due Day 1 field, the new Due Date field value is always set to a date before the add-on occurred.

Note: If an add-on occurs on March 25, this field value is (3) From the Last, the Payment Frequency field value is (5) Semimonthly, and Due Day 1 is March 15, the new Due Date field value for the loan becomes March 15, 10 days before the add-on occurred.

(4) From Bucket One

Symitar Quest should set the Due Date field by advancing the date in the Pmt Bucket Due Date 1 field by one period, as determined by the value in the Payment Frequency field. Use this option only for loans that have the Loan Code field value set to (3) Credit Card and for loans that have payments that are being calculated by statement cutoff and that also have the DQ Calculation Method field value set to (1) Payment Buckets are Calculated Monthly. Never select this option for other kinds of loans.

Because the due date in the Pmt Bucket Due Date 1 field is always the due date for the current statement cycle, the resulting new due date for the loan is always the due date for the next statement cycle. The only exception is that for a loan that has not gone through its first statement cutoff, Symitar Quest will not change the Due Date field value if it has been filled in. If the Due Date field is blank, Symitar Quest sets the due date to the Due Day 1 field value in the month following the transaction.

(7-25)

For SymChoice Loans using the Payment Calculation Type Parameters to calculate payments for Segment 0, we recommend that you set all the related fields to a value that coincide with and support each other.

Set the New Segment Cutoff Option field in the Loan record to (0) Number of days, set the New Segment Cutoff Days field in the Loan record to 7-25, and ensure that the Due Grace Days parameter in the Payment Calculation Type Parameters and the New Loan Due Date Code parameter all coincide with each other.

(10-99) Number of Days

Enter a number 10–99 to specify the minimum number of days before the first due date. Symitar Quest calculates the next due date by adding the number days you specify to the day the add-on occurs. The Due Date field value may also be affected by the Payment Frequency and Due Day 1 field values as follows: - If the Payment Frequency field value is set to (4) Monthly and the Due Day 1 field is filled in, Symitar Quest does the following to set a new due date: - Adds the number of days specified in this field to the date of the add-on - Advances the Due Date field value to the next Due Day 1 field value that is on or after the day indicated by the number in this field Note: If you have zero balance loan with a value of (4) Monthly in the Payment Frequency field, a value of 45 in this field, and a value of 1 in the Due Day 1 field, an add-on posted on July 10 results in a new due date of September 1. An add-on posted on July 29 results in a new due date of October 1. - If the Payment Frequency field value is set to (6) Biweekly skip first, (7) Biweekly skip last, (8) Biweekly, or (9) Weekly, Symitar Quest does the following to set a new due date: - Adds the number of days specified in this field to the date of the add-on - Starts at the existing due date and calculates the first scheduled due date on or after the day indicated by the number in this field Biweekly or weekly due dates that coincide with specific days of the week will continue to do so after an advance to a zero-balance loan.

The value in this field can cause Symitar Quest to temporarily change the Payment Method field value from (7) Scheduled auto transfer to (8) Scheduled auto transfer after due under the following conditions:

• The Loan Code field value is (2) Line of Credit
• A loan advance add-on is made on the loan
• This field value is a specified number of days (10-99)
• The Due Day 1 field value is set to a specific day of the month
• The days in this field plus the date of the advance is greater than the value in Due Day 1 field

Symitar Quest sets the value in the Due Date field to the nearest Due Day 1 field value after the field days entered in this field from the advance date. However, the (7) Scheduled auto transfer payment method ignores the month and year of a loan due date. To prevent a payment being posted on the value in the Due Day 1 field only a few days away, Symitar Quest changes the value in the Payment Method field to (8) Scheduled auto transfer after due. Once the first payment is made, Symitar Quest changes the value in the Payment Method field back to (7) Scheduled auto transfer.

Note: If you have a zero balance loan with a Payment Frequency field value of (4) Monthly, a Payment Method field value of (7) Scheduled auto transfer, a value in this field of 30, and the Due Day 1 field value set to 20, an advance posted on September 17 results in a new Due Date field value of October 20. Symitar Quest changes the Payment Method field value to (8) Scheduled auto transfer After Due so that no payment is posted on September 20 (which is three days past the date of the advance). Once the payment is made on October 20, Symitar Quest changes the Payment Method field value back to (7) Scheduled auto transfer.

Due Date Advance Code

This field stores a code that specifies how Symitar Quest advances the Due Date field when a payment is made to the loan.

Data Type Descriptions

(0) Use Max Due Date Advance Period

Symitar Quest should use the number of periods by which the due date can advance in the Max Due Date Advance Period field. This option is the default and the most commonly used value for this field.

(1) Overlimit payment use ‘Max Due Date Advance Period’ else use ‘One when due’

This option is for loans with credit card interest types 10–8999 that are set up for automatic transfer payments with a Transfer record that fits this criteria: - The Amount Option field value is set to (5) Grace Amount. - The Amount field value is set to 0.00.

Symitar Quest uses the standard maximum due date advance logic if the loan was overlimit at the end of the last statement cutoff. Otherwise the batch program sets the beginning cycle date so that the due date advances only if the payment is received on or after the due date.

This option prevents the system from advancing the due date if the loan is not overlimit and the member makes a payment before the due date that satisfies the minimum payment due, but does not equal or exceed the grace amount. Preventing the system from advancing the due date in this scenario ensures that the transfer that satisfies the grace amount still occurs.

Max Due Date Advance Period

This field stores a code that defines the maximum number of periods the due date can be advanced into the future.

Data Type Descriptions

0

There to be no limit on how far the due date can advance.

1

Required if the Loan Code field value is set to (6) LOC Combination. In this case, you cannot perform file maintenance on this field. If you attempt to do so, this error message appears:

Error: Max Due Date Advance Period must equal 1 when Loan Code = 6!

Note: For loans that have the Interest Type field set to 1, 3, 4, 6, 8, or 10–9999 this field must be set to 1.

Interest Type fields that are set to 3, 4, 6, and 10–9999 are cycled loans for which the Statement Cutoff batch program calculates the payment. The system does not allow a due date to advance beyond the next cycle.

For mortgages that have the Interest Type field set to 1 or 8, when the due date is beyond the current cycle and a payment is received, the system applies the entire payment to principal only. This could result in loss of interest income and the amortization schedule will be affected.

For mortgages that use any interest type and have escrow tied to them, the system is unable to determine if a payment made on a paid-ahead loan should reserve funds for escrow. This could result in significant escrow shortage and the amortization schedule will be affected.

Note: All mortgage loans that receive the periodic statement must have the Max Due Date Advance Period field set to 1, regardless of interest type, to ensure an accurate payment breakdown on the statement. If a mortgage loan that uses a simple daily interest calculation is paid ahead and no payment is due for the current cycle, the payment breakdown for the subsequent cycle will be inaccurate due to the excess interest accrued between due dates.

1–9999

The maximum number of periods the due date can be advanced into the future.

Initial BCD Setting Option

This field stores a code that determines how the beginning cycle date will be set for non-billed loans and loans that use the (1) Use Loan Due Date (One when due) option.

Data Type Descriptions

(0) Use Current Cycle Due Date – 1 Period + 1 Day

This loan does not use a beginning cycle date.

(1) Use Loan Due Date (One when due)

The beginning cycle date for a new loan is set to the value of the Loan record Due Date field value for the One when due functionality.

The One when due functionality advances the Due Date field value by one period only when a payment is made on or after the due date. Symitar Quest does not advance the due date for loan payments made before the due date.

The purpose of this option is to specify that the loan requires a full payment on the due date, no matter how much extra was paid before the due date. Use this function for loans with a value in the Payment Method field of (2) Auto transfer if you do not want over-the-counter transactions to affect the amount taken by automatic transfers on the due date.

BCD Day 1

This field stores the day that each billing cycle starts for a loan.

Symitar Quest automatically sets the value of this field when you disburse the loan based on the following rules:

• For loans with an interest type of (3) Daily Billed I, (4) Daily Billed II, (6) Daily 360, or (10-8999) Credit Card Interest, the value of this field is always 0. When you run the Statement Cutoff Processing batch program to calculate set payments for these loans, the system populates the loan’s Beginning Cycle Date field with the day after the cutoff date. For these loans, this is the date the new cycle begins.
• For all loans with biweekly or weekly payment frequencies, the value of this field is 0.
• For loans with any other interest type and payment frequency combination, the value of this field is normally the day after the value entered in the Due Day 1 field (if populated) or the day after the day value of the Due Date field. Exceptions:
  • For loans that have the Initial BCD Setting Option field value set to (1) One When Due, this field is the same as the Due Day 1 field value or the day value of the Due Date field value.
  • For loans that have the Payment Frequency field value set to (5) Semimonthly and that do not use One when due functionality, the BCD Day 1 field value must be the lesser of the Due Day 1 field value plus 1 or Due Day 2 field value plus 1. In other words, if the loan’s Due Day 1 field value is 15 and the Due Day 2 field value is 31, this field value is 1, not 16. This change is because the day values must be stored in numeric order from low to high. This field value cannot have a value of 0 for semi-monthly payment frequencies. If the loan balance is zero, then there is no field validation for this field or the BCD Day 2 field.

If you change the value of a loan’s Due Day 1 field value or the day portion of the loan’s Due Date field value, you must modify this field value following the rules described above. If you change a loan’s Payment Frequency field value, you must also modify this field value.

Loans that use Loan Batch FM Processing to calculate the payment [DQ Calculation Method field value set to (1) Payment Buckets Are Calculated Monthly] may have this field value set to the day after the loan cycles into the new period by a specfile or other process after the loan is disbursed. For example, if the loan is due on the 25th of the month and it cycles on the last day of the month, you can reset this field to 1 after disbursing the loan.

BCD Day 2

This field stores the loan’s beginning cycle date only for loans that have the Payment Frequency field value set to (5) Semimonthly.

Symitar Quest automatically sets the value of this field for loans that have the Payment Frequency field value set to (5) Semimonthly based on the following rule:

For a loan with semimonthly payments, both the Due Day 1 and Due Day 2 fields must be populated. When you disburse the loan, the system populates this field with the greater of the Due Day 2 field value plus 1 or the Due Day 1 field value plus 1. In other words, if the loan’s Due Day 1 field value is 15 and the Due Day 2 field value is 31, this field value is 16, not 1. This change is because the day values must be stored in numeric order from low to high.

Exception: For loans that have the Initial BCD Setting Option field value set to (1) One When Due, this field is the same as the Due Day 2 field value.

If you change the value of a loan’s Due Day 2 field or Payment Frequency field, you must also modify this field accordingly.

This field cannot have a value of 0 for semi-monthly payment frequencies.

If the loan balance is zero, then there is no field validation for the BCD Day 1 field or this field.

Beginning Cycle Date

This field contains the calculation of when a loan payment can advance the loan’s due date and, in combination with the Max Due Date Advance Period field, how far into the future the total amount of multiple payments can advance the loan due date.

When using an interest type of 3, 4, 6, or 10–8999, the Beginning Cycle Date field is updated by the Statement Cutoff batch program. For new billed loans, the Beginning Cycle Date field is populated with the statement date plus one day once the loan has been funded.

When a SymChoice loan is an interest-only loan with additional segments that are not interest only, the Beginning Cycle Date field updates to a date that matches the lowest beginning cycle date in the segments instead of the day after the statement cutoff.

Note: If the statement cutoff occurs on the last day of the month and the loan is due on the 25th day of the month, when Segment 1 has a Beginning Cycle Date field value that is set to the 26th of the month, then the statement cutoff does not update the Beginning Cycle Date field in the Loan record to the 1st of the month. Instead, it updates the Beginning Cycle Date to the 26th.

The Daily Posting batch program also updates this field for the following interest types and represents the beginning cycle date for the current payment period:

• 0
• 1
• 2
• 5
• 7
• 8

Note: You must run the Daily Posting batch program to update the Beginning Cycle Date field to reflect the start of the new payment period for non-daily billed loans.

You cannot access this field for file maintenance.

Balloon Date

This field stores the date any balloon loan payment comes due.

Enter the date any balloon loan payment comes due. Once the loan’s due date reaches or exceeds this date, Symitar Quest resets the Payment field value to the remaining loan balance and resets the Payment Type field value to (1) Level Principal. If the loan has an interest type of (3) Daily billed I or (4) Daily billed II, Symitar Quest resets the Interest Type field value to (0) Daily 365 day. If the Interest Type field value is set to (6) Daily Billed 360, Symitar Quest resets the Interest Type field value to (5) Actual/360.

Whenever a partial payment is made to a balloon payment loan after the balloon date, the Daily Posting batch program resets the Payment field value to the new loan balance. Whenever a loan is paid ahead beyond the balloon date, the Daily Posting batch program does not set the payment amount to the loan balance until one payment frequency before the balloon date.

Note: Using PowerOn, you can generate notices (based on the Balloon Date field) to notify members of upcoming due dates for balloon payments.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Balloon Date field from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Balloon Date field of the loan calculation screen.

• For an interest-only loan (including loans that have the Interest Type field value set to (3) Daily billed I, (4) Daily billed II, or (6) Daily Billed 360), the balloon date must always be set to the loan’s due date.
• If the Loan Code field value is set to (6) LOC Combination, the Balloon Date field applies to Segment 0, not the entire loan. If you want the entire loan to balloon on a specific date, you must enter the same date in the Balloon Date field in the Loan record and in all the associated segment records.

Balloon Amount

This field stores the amount of the final payment (including principal and interest) of a loan.

Use this field when you want to calculate a loan to make the final payment (including principal and interest) equal a specified amount. For example, to calculate the payment on a $10,000 loan so that the final balloon payment, due in 36 months, is $5,000, simply enter $5,000 in this field.

If you specify (2) Calculate Loan Term for the calculation type on the loan calculation screen, Symitar Quest ignores the value in this field.

Note: If the Loan Code field value is set to (6) LOC Combination, the value in this field applies to Segment 0, not the entire loan.

Maturity Date

This field stores the date the loan will be paid off.

Enter the date the loan will be paid off.

If the Loan Code field value is set to (6) LOC Combination, this field must be equal to or later than the latest field values of the Maturity Date fields for all segments associated with the loan.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Loan Maturity Date field from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Maturity Date field of the loan calculation screen.

Note: This field must have a non-blank value for the early Payoff Chargeback function of Dealer Reserve Accounting Processing to work properly.

Loan Balance

This field stores the current principal balance of the loan.

Symitar Quest updates this field with the current principal balance whenever a Loan Payment (LP), New Loan (LN), Loan Addon (LA), or Loan Refinance (LR) teller transaction affects the loan.

When the Loan Balance field has a value greater than 0.00, Segment 0 of a SymChoice Loan can only go forward one cycle when a Loan Advance (LA) transaction is performed through Teller Transactions on Segment 0 using a defined Payment Calc Type field value of 0001 to 8999.

You cannot access this field for file maintenance.

Original Balance

This field stores the original balance of the loan or the balance after an add-on to the loan.

For line-of-credit loans, Symitar Quest updates this field with the new Loan Balance field value whenever the balance changes because of a New Loan (LN) teller transaction, or whenever any Loan Addon (LA) teller transaction, except for insurance or fee add-ons, brings the loan balance above the balance currently in this field. For closed-end loans, the value in the Original Balance field changes when you perform a New Loan (LN) transaction, but it does not change when you perform a Loan Advance (LA) transaction.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Loan Amount field from the specified Application record.

Symitar Quest updates this value for the loan when you use loan calculation only during the initial loan creation. Symitar Quest does not update this field during revisions of the loan record, even if you use the Loan Calc Screen action field. In that case, you may need to manually change this field value, if the loan has not yet been funded.

Under normal circumstances, you should not revise this field.

Credit Limit

This field stores the credit limit for line of credit or credit card loans.

Enter the credit limit for line of credit or credit card loans. For loans with a Loan Code field value of (1) Open End, (2) Line of Credit, (3) Credit Card, or (5) Avg Daily Bal LOC, Symitar Quest calculates the value in the Available Credit field by subtracting the Loan Balance field value and any loan hold amounts from the amount in this field.

This calculation may also be affected depending on your setting in the Credit Card LOC Available parameter in Miscellaneous Parameters if the Loan Code field value is (3) Credit Card or (5) Avg Daily Bal LOC.

Note:

• For loans with a Loan Code field value of (0) Closed End, (1) Open End, or (4) Lease, a value in this field of 0.00 indicates an unlimited credit limit. For loans with those loan codes, a loan advance is allowed without an override when this field value is 0.00. There is a Teller Transaction privilege to allow loan advances for loans with a Loan Code field value of (0) Closed End.
• For loans with a Loan Code field value of (2) Line of Credit or (3) Credit Card, a value in this field of 0.00 indicates a zero credit limit. For loans with those loan codes, a loan advance requires an override when this field value is 0.00.

If you attempt to complete a transaction that exceeds this field value for the loan, a warning message appears, and you cannot complete the transaction unless you have the privilege to do so.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Loan Credit Limit field from the specified Application record.

When you enter an amount in this field that is less than the value in the BT Limit Max, CA Limit Max, or Combined CA/BT Limit Max fields, Symitar Quest sends the following warning:

Warning: Amount entered is less than the CA/BT Limiting Limit Max field(s)!

Available Credit

This field contains the computed available credit.

This field is used in inquiries only. This field value is always 0.00 for closed-end loans and credit card loans with a Credit Limit field value set to 0.00. For loans with a Loan Code field value of (1) Open End, (2) Line of Credit, (3) Credit Card, and (5) Avg Daily Bal LOC with a non-zero Credit Limit field value (if the Available Credit Calculation field value is set to (0) Revolving), Symitar Quest computes this field as the Credit Limit field value minus the Loan Balance field value, minus any related loan holds.

Note: For loans with a Loan Code field value of (3) Credit Card and (5) Avg Daily Bal LOC, the Available Credit field is affected by the value in the Credit Card LOC parameter in Miscellaneous Parameters.

If Available Credit Calculation field value is set to (1) Non-Revolving, Symitar Quest computes this field as the Credit Limit field value minus the Amount Advanced field value, minus any related loan holds.

When the Credit Limit field value is 0.00, this field value is equal to the outstanding Loan Balance field value (negative). If the date in the Credit Limit Expiration field is on or before the system date, this field value is equal to the outstanding Loan Balance field value (negative).

You cannot access this field for file maintenance.

Cash Advance Limit

This field contains the computed maximum cash advance limit at the time of inquiry.

This field applies only to credit card loans (the Loan Code field value is 3) with an Interest Type field value of (10-8999) Credit Card Interest.

This field is used in inquiries only. Symitar Quest computes this field as the maximum cash advance limit at the time of inquiry and as the lesser of the following:

• The CA Limit Max field value when not 0.00
• The CA Percent field value
• The Combined CA/BT Limit Max field value when not 0.00
• The Combined CA/BT Percent field value

This field is recalculated when the following fields are modified:

• CA Percent
• CA Limit Max
• Combined CA/BT Percent
• Combined CA/BT Limit Max
• Credit Limit

Note:

You cannot perform file maintenance on this field.

Available Cash Advance

This field contains the computed amount of cash advance available at the time of inquiry.

This field applies only to credit card loans (the Loan Code field value is 3) with an Interest Type field value of (10-8999) Credit Card Interest.

This field is used in inquiries only. Symitar Quest computes this field as the Cash Advance Limit field value minus the Total CA Balance to Date field value, minus the Interest Unpaid field value (the Interest Unpaid field value depends on the value in the Credit Card LOC Available parameter), minus any related cash advance loan holds.

This field may display a value less than or equal to 0.00 when the CA Percent or Combined CA/BT Percent field values equal 0.00 because there could be prior transactions driving the available amount negative.

At the time of inquiry, this field cannot be greater than the Available Credit or Available Combined CA/BT field values. When the calculated value is greater, Symitar Quest modifies this field to display the lesser of the Available Credit or Available Combined CA/BT field values.

When the Credit Limit field is modified, Symitar Quest recalculates the Cash Advance Limit field value which affects this field calculation.

This field is affected by the Credit Card LOC Available parameter in Miscellaneous Parameters:

• When you select the (0) Credit Card LOC Available is Cred Limit minus Full Balance option at the Credit Card LOC Available parameter, Symitar Quest includes the Interest Unpaid field value in calculating this field value at the time of inquiry. The Interest Unpaid field value is a combination of interest due and interest billed for purchases, cash advances, and balance transfers as of the last statement cutoff date. The value in this field may decrease as loan payment transactions are applied to the loan.
• When you select the (1) Credit Card LOC Available is Cred Limit minus Principal Balance option at the Credit Card LOC Available parameter, Symitar Quest does not include the Interest Unpaid field value in calculating this field value at the time of inquiry.
• When you select the (2) Same as (0) for Statement Cutoff and Generation, (1) elsewhere option at the Credit Card LOC Available parameter, Symitar Quest uses the (0) Credit Card LOC Available is Cred Limit minus Full Balance option procedure to calculate this field value for statement cutoff and statement generation and uses the (1) Credit Card LOC Available is Cred Limit minus Principal Balance option procedure elsewhere to calculate this field value.

Note: The computed value in this field is an approximate calculation and may not be entirely accurate. You may see variances between this field and a payoff inquiry, and you may see a variance when the loan payment application is finalized once Statement Cutoff Processing is completed.

You cannot perform file maintenance on this field.

Balance Transfer Limit

This field contains the computed maximum balance transfer limit at time of inquiry.

This field applies only to credit card loans (the Loan Code field value is 3) with an Interest Type field value of (10-8999) Credit Card Interest.

To enter a value in this field, the CC Balance Transfer internal parameter must also be set to (1) Yes. We must enable this parameter. Contact Support for details.

This field is used in inquiries only. Symitar Quest computes this field as the maximum balance transfer limit at time of inquiry and as the lesser of the follow:

• The BT Limit Max field value when not 0.00
• The BT Percent field value
• The Combined CA/BT Limit Max field value when not 0.00
• The Combined CA/BT Percent field value

This field value is recalculated when the following fields are modified:

• BT Percent
• BT Limit Max
• Combined CA/BT Percent
• Combined CA/BT Limit Max
• Credit Limit

Note:

You cannot perform file maintenance on this field.

Available Balance Transfer

This field contains the computed amount of balance transfer available at the time of inquiry.

This field applies only to credit card loans (the Loan Code field value is 3) with an Interest Type field value of (10-8999) Credit Card Interest.

This field is used in inquiries only. Symitar Quest computes this field as the Balance Transfer Limit field value minus the Total BT Balance to Date field value, minus the Interest Unpaid field value (the Interest Unpaid field value depends on the Credit Card LOC Available parameter).

This field may display a value less than or equal to 0.00 when the BT Percent or Combined CA/BT Percent field values equal 0.00 because there could be prior transactions driving the available amount negative.

At the time of inquiry, this field cannot be greater than the Available Credit or Available Combined CA/BT field values. When the calculated value is greater, Symitar Quest modifies this field to display the lesser of the Available Credit or Available Combined CA/BT field values.

When the Credit Limit field is modified, Symitar Quest recalculates the Balance Transfer Limit field value, which affects this field calculation.

This field is affected by the Credit Card LOC Available parameter in Miscellaneous Parameters:

• When you select the (0) Credit Card LOC Available is Cred Limit minus Full Balance option at the Credit Card LOC Available parameter, Symitar Quest includes the Interest Unpaid field value in calculating this field value at the time of inquiry. The Interest Unpaid field value is a combination of interest due and interest billed for purchases, cash advances, and balance transfers as of the last statement cutoff date. The value in this field may decrease as loan payment transactions are applied to the loan.
• When you select the (1) Credit Card LOC Available is Cred Limit minus Principal Balance option at the Credit Card LOC Available parameter, Symitar Quest does not include the Interest Unpaid field value in calculating this field value at the time of inquiry.
• When you select the (2) Same as (0) for Statement Cutoff and Generation, (1) elsewhere option at the Credit Card LOC Available parameter, Symitar Quest uses the (0) Credit Card LOC Available is Cred Limit minus Full Balance option procedure to calculate this field value for statement cutoff and statement generation and uses the (1) Credit Card LOC Available is Cred Limit minus Principal Balance option procedure elsewhere to calculate this field value.

Note: The computed value in this field is an approximate calculation and may not be entirely accurate. You may see variances between this field and a payoff inquiry, and you may see a variance when the loan payment application is finalized once Statement Cutoff Processing is completed.

You cannot perform file maintenance on this field.

Combined CA/BT Limit

This field contains the computed maximum combined cash advance and balance transfer limit at time of inquiry.

This field applies only to credit card loans (the Loan Code field value is 3) with an Interest Type field value of (10-8999) Credit Card Interest.

This field is used in inquiries only. Symitar Quest computes this field as the maximum combined cash advance and balance transfer limit at time of inquiry and as the lesser of the following:

• The Combined CA/BT Limit Max field value when not 0.00
• The Combined CA/BT Percent field
• The sum of the Cash Advance Limit and the Balance Transfer Limit field values.

When the following fields are modified, this field is recalculated:

• CA Percent
• CA Limit Max
• BT Percent
• BT Limit Max
• Combined CA/BT Percent
• Combined CA/BT Limit Max
• Credit Limit

Note:

You cannot perform file maintenance on this field.

Available Combined CA/BT

This field contains the computed combined cash advance and balance transfer amount available at the time of inquiry.

This field applies only to credit card loans (the Loan Code field value is 3) with an Interest Type field value of (10-8999) Credit Card Interest.

This field is used in inquiries only. Symitar Quest computes this field as the Combined CA/BT Limit field value minus the Total CA Balance to Date field value, minus the Total BT Balance to Date field value, minus the Interest Unpaid field value (the Interest Unpaid field value depends on the Credit Card LOC Available parameter), minus any related cash advance loan holds.

This field may display a value less than or equal to 0.00 when the Combined CA/BT Percent field value equals 0.00 because there could be prior transactions driving the available amount negative.

At the time of inquiry, this field cannot be greater than the Available Credit field value. When the calculated value is greater, Symitar Quest modifies this field to display the Available Credit field value.

When the Credit Limit field is modified, Symitar Quest recalculates the Combined CA/BT Limit field value which affects the Available Combined CA/BT calculation.

This field is affected by the Credit Card LOC Available parameter in Miscellaneous Parameters:

• When you select the (0) Credit Card LOC Available is Cred Limit minus Full Balance option at the Credit Card LOC Available parameter, Symitar Quest includes the Interest Unpaid field value in calculating this field value at the time of inquiry. The Interest Unpaid field value is a combination of interest due and interest billed for purchases, cash advances, and balance transfers as of the last statement cutoff date. The value in this field may decrease as loan payment transactions are applied to the loan.
• When you select the (1) Credit Card LOC Available is Cred Limit minus Principal Balance option at the Credit Card LOC Available parameter, Symitar Quest does not include the Interest Unpaid field value in calculating this field value at the time of inquiry.
• When you select the (2) Same as (0) for Statement Cutoff and Generation, (1) elsewhere option at the Credit Card LOC Available parameter, Symitar Quest uses the (0) Credit Card LOC Available is Cred Limit minus Full Balance option procedure to calculate this field value for statement cutoff and statement generation and uses the (1) Credit Card LOC Available is Cred Limit minus Principal Balance option procedure elsewhere to calculate this field value.

Note: The computed value in this field is an approximate calculation and may not be entirely accurate. You may see variances between this field and a payoff inquiry, and you may see a variance when the loan payment application is finalized once Statement Cutoff Processing is completed.

You cannot perform file maintenance on this field.

Credit Limit Expiration

This field stores the expiration date of the credit limit for line of credit or credit card loans.

Enter the expiration date of the credit limit for line of credit or credit card loans.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Cred Lim Exp Date field from the specified Application record.

Under normal circumstances, you should not revise this field.

Available Credit Calculation

This field stores a code that determines how available credit is calculated only for line of credit loans.

Data Type Descriptions

(0) Revolving

For revolving line of credit loans, the available credit decreases as advances are taken and increases as the principal is paid off. Symitar Quest automatically selects this option for loans with a Loan Code field value of (6) LOC Combination.

(1) Non-Revolving

For non-revolving line of credit loans, the available credit decreases as advances are taken, but does not increase as the principal is paid off.

See Non-Revolving Line of Credit Loans in the Miscellaneous Loan Features topic for more information.

Credit Limit Group

This field stores a code that identifies the credit limit group with which this Loan record is associated.

Data Type Descriptions

0

The home equity loan does not use any other loans to determine the available credit limit. Therefore, the home equity loan’s available credit limit is $35,000.00.

1–99

Symitar Quest accumulates all loan balances in the accounts that share this same group value, and uses this amount to determine the available credit limit.

Note:

The following loans are from a sample member account:

In this example, the LOC and VISA loans share the same credit limit group, and their combined balances are used to determine each loan’s available credit limit.

The available credit limit on the LOC loan is calculated by adding the two loan balances ($500.00 (LOC) + $1,000.00 (VISA) = $1,500.00) and subtracting this total from the Credit Limit field value of the LOC loan alone ($3,000.00 - $1,500.00 = $1,500.00). This calculation results in an available credit limit of $1,500.00.

The available credit limit on the VISA loan is calculated by adding the two loan balances ($1,500.00) and subtracting this total from the Credit Limit field value of the VISA loan alone ($4,500.00 - $1,500.00 = $3,000.00). This calculation results in an available credit limit of $3,000.00.

Note: You should not set the Due Date Advance Code field value to (1) Overlimit payment use ‘One period max’ else use ‘One when due’ for any loan with a shared credit limit. This combination is not supported by Symitar Quest.

To determine the available credit for a loan that shares its credit limit with other loans, the system uses the credit limit from the effective loan that you are trying to post the add-on to (it does not sum the credit limits of all loans linked by credit limit group). The system then subtracts all loan balances (if the Available Credit Calculation field value is (0) Revolving) or it subtracts the amounts already advanced on the loans (the Available Credit Calculation field value is (1) Non-Revolving). The system also subtracts any outstanding holds for any of the linked loans. The result is the available credit.

Note:

Three loans are linked under the same account to share credit.

Posting an add-on to Loan B causes the system to use the loan’s credit limit of $100,000 less the outstanding balances of $75,000; resulting in $25,000 as available credit for the add-on. The credit limits of Loan A and C are grayed out because those limits are not used when the add-on is occurring for Loan B.

The system allows the add-on to occur for a loan even if another loan that is part of the credit limit group is delinquent.

Amount Advanced

Symitar Quest stores the total amount of advances against the loan in this field.

This field does not include add-ons for insurance, fees, or taxes. Symitar Quest uses this field to determine available credit for non-revolving loans (non-revolving means that the available credit decreases as advances are taken, but does not increase as the principal is paid off).

See Non-Revolving Line of Credit Loans for more information.

Under normal circumstances, you should not revise this field.

Last Advance Date

Symitar Quest stores the last date an advance was taken against the loan.

Symitar Quest does not update this field for loan add-ons for insurance, taxes, fees, adjustments, or recasts.

When a loan advance is taken, Symitar Quest automatically updates the Last Advance Date field value to the current system date or to the effective date for the advance, if used. Symitar Quest does not update this date for loan add-ons in which the member is not receiving an advance (for example, insurance, tax add-ons, or fees).

Symitar Quest does not back out the Last Advance Date when a loan advance is voided.

Symitar Quest initially sets the value of the Last Advance Date field in existing loans to the most recent advance date from transaction history. If no advance date is found, Symitar Quest uses the value in the Open Date field.

Under normal circumstances, you should not revise this field.

Cancelable

This field sets a line-of-credit (LOC) loan as cancelable, meaning it can be revoked under the terms of the loan’s agreements.

Data Type Descriptions

(0) No (Default)

When set this field to No, the loan is flagged as non-cancelable.

(1) Yes

When set this field to Yes, the loan is flagged as cancelable.

The Cancelable field is most useful when reporting LOC loans to the Financial Performance Suite (FPS), but it is available for all loan types.

Origination Balance

Symitar Quest stores the opening day balance of the loan. This information is used on IRS form 1098 for the Outstanding Mortgage Principal (box 2).

Under normal circumstances, you should not revise this field.

The Daily Posting batch program updates the Origination Balance field value based on the loan codes as follows:

• With the Loan Balance field value the first time it is run after the open date for loan codes 1, 2, 3, 5, or 6.
• With the first non-zero Loan Balance field value for loan codes 0 or 4.

Beginning Year Balance

Symitar Quest stores the balance of the loan at the start of the current calendar year in this field.

The first time you run the Close Day Processing batch program to start a calendar year, Symitar Quest copies the amount in the Balance field to this field. This update takes place for all Loan records.

When the Loan Bankruptcy record Type field value is (1) Bankruptcy, and the Loan Bankruptcy PrePetition Bal record Amount Code field value is (1) Principal, the Loan Bankruptcy PrePetition Bal record Balance field value is added.

Under normal circumstances, you should not revise this field.

Prev Beginning Year Balance

Symitar Quest stores the balance of the loan at the start of the previous calendar year in this field.

The first time you run the Close Day Processing batch program to start a calendar year, Symitar Quest moves the amount in the Beginning Year Balance field to this field. This update takes place for all Loan records.

Under normal circumstances, you should not revise this field.

Payment

This field stores the amount of the standard loan payment.

You can update this field manually, or Symitar Quest can calculate the loan payment amount based on the Loan Code, Payment Type, and the Balloon Date field values and on the parameters set with the Payment Calculation Types parameters.

If Symitar Quest computes the payment, it assumes that the payment is monthly unless you specify otherwise with the Payment Frequency Adjustment parameter in the Payment Calculation Types parameters. You can use this parameter to change the computed monthly payment to match the Payment Frequency field value.

• If the Loan Code field value is (0) Closed End, you can compute the payment amount using Projections, or by running the Rate Change Processing batch program. Payments for closed-end loans are computed as follows:
  • If the loan has a Payment Type field value of (0) Level Payment, Symitar Quest does the following:
    • Computes a payment schedule that pays off the loan in equal periodic payments
    • Applies the difference between the total payment amount and the interest due to the loan principal Symitar Quest checks the Balloon Date field value each time you run the Daily Posting batch program. If a balloon payment is due before the end of the full loan amortization term, Symitar Quest computes the final loan payment as the Loan Balance field value plus all unpaid interest. Symitar Quest still computes the payment amount using the full amortization term.
  • If the loan has the Payment Type field value set to (1) Level Principal, Symitar Quest computes a payment schedule that ensures that the same amount of principal is paid each period. To do so, Symitar Quest does the following:
    • Calculates the fixed principal amount as the Original Balance field value divided by the Payment Count field value
    • Adds the interest due each period to the fixed principal amount to determine the payment amount The total payment due varies each period, since the amount of interest due each period varies depending on the loan balance and the number of days in the period. Symitar Quest checks the Balloon Date field value each time you run the Daily Posting batch program. If a balloon payment is due before the end of the full loan amortization term, Symitar Quest computes the final loan payment as the Loan Balance field value plus all unpaid interest. Symitar Quest still computes the payment amount using the full amortization term.
• If the Loan Code field value is (1) Open End or (2) Line of Credit, Symitar Quest can compute the payment amount according to the parameters for the payment calculation type, or the Loan File Maintenance Processing batch program can recompute the loan payments each month. Payments can be computed as follows, depending on the value in the Payment Calculation Formula parameter:
  • If the value in the Payment Calculation Formula parameter is set to (0) Fixed Percent of balance, loan payments are calculated as a fixed percentage of the loan balance.
  • If the value in the Payment Calculation Formulaparameter is set to (1) Payment from balance table, Symitar Quest determines the loan payment by where the loan balance falls in a range of loan balances. Each balance range is associated with a fixed payment amount. The payment amount changes as the balance changes.
  • If the value in the Payment Calculation Formula parameter is set to (2) Percent from balance table, Symitar Quest calculates the loan payment as a percentage of the loan balance, depending on where the current loan balance falls in a user-specified range of loan balances. Each balance range is associated with a fixed percentage of the loan balance. The payment amount changes as the loan balance changes.
  • If the value in the Payment Calculation Formulaparameter is set to (3) Percent from int rate table, Symitar Quest calculates the loan payment as a percentage of the loan balance, with the percentage determined by the interest rate of the loan. The payment amount changes as the interest rate changes.
  • If the value in the Payment Calculation Formula parameter is set to (4) Pmt based on balance increments, Symitar Quest computes the loan payment as a percentage of the loan balance. Symitar Quest determines the payment percentage according to the interest rate of the loan. The payment amount changes when the loan interest rate changes.
  • If the value in the Payment Calculation Formula parameter is set to (5) Reamortize to loan maturity date, Symitar Quest computes a new fixed loan payment amount by amortizing the remaining loan balance and its interest over the remaining term of the loan.
• If the Loan Code field value is (3) Credit Card and the Interest Type field value is set to 10-8999, Symitar Quest calculates payments according to the Interest Type Parameters (the Parameter Manager). You can also include any overlimit amount in the loan payment, depending on how you set the Payment Overlimit Option parameter.
• If the Loan Code field value is (6) LOC Combination, Symitar Quest calculates this field as the sum of all payments for all segments, including Segment 0. If you or Symitar Quest performs file maintenance on the same field on an associated Segment record, Symitar Quest updates this field accordingly.

For each of the above loan payment calculations, the Payment Calculation Types parameters include a Payment Minimum and a Payment Calculation Set Code parameter that determines whether the payment amount should change each time you make an add-on or advance, or only if the add-on or advance would increase the current payment amount.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Payment field from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Payment field of the loan calculation screen.

If you use the MBS Multiple Repayment Programs Per Loan module and have a Schedule record associated with this Loan record that is active, the value of this field is copied from the Schedule record.

Alternate Payment

This field stores an amount greater than the standard payment that the member would like to pay between the dates in the Alternate Pmt Effective and the Alternate Pmt Expiration fields.

Enter an amount greater than the standard payment that the member would like to pay between the dates in the Alternate Pmt Effective and the Alternate Pmt Expiration fields. This field is not useful for loans with a Payment Method field value of (0) Cash or (1) Coupon. Symitar Quest uses this field amount during automatic payment transfers performed during Daily Posting. Symitar Quest also uses this amount during payroll and ACH distribution posting when the loan distribution amount specified is 0.00 (zero).

Symitar Quest attempts to take this field amount instead of the standard payment amount when all the following conditions are met:

• This field is filled in.
• This field is based on the system’s standard interpretation of the Alternate Pmt Effective and Alternate Pmt Expiration dates. Alternate Pmt Effective and Alternate Pmt Expiration Dates are optional fields to allow more control over when to collect the higher amount. If these fields are blank, Daily Post always attempts to pull this field value.
• This field value is greater than the standard loan payment.

Note: Symitar Quest still performs all calculations based on the standard payment amount, such as calculating the amount of any delinquency, the amount of any late charge, the amount of the remaining partial payment, and the advancement of the loan due date. This field simply specifies that Symitar Quest should attempt to take a larger amount than the standard payment.

If this field amount is not available for automatic payment transfers during Daily Posting, Symitar Quest reverts to taking only the standard payment amount. For automatic transfer payment loans (Payment Method field value is (2) Auto transfer) and for scheduled automatic transfer payment loans that are not paid ahead (Payment Method field value is (7) Scheduled auto transfer or (8) Scheduled auto transfer after due), Symitar Quest can take partial payments as long as the Ignore Partial Payment option in Daily Posting is set to N.

• If the full amount in this field is taken, Symitar Quest clears the Partial Payment field. This clearing allows Symitar Quest to take a partial payment on the loan due date if less than the standard payment is available, then take the rest of the amount that makes up the full amount in this field when it becomes available. Once the remaining amount of this field (or of the standard payment if this field amount is not available) is taken, Daily Posting clears the Partial Payment field so that the full amount in this field can be attempted on the next due date.
• If the full amount in this field is not available, but the standard payment amount is available, Symitar Quest takes the standard payment amount only, advances the loan due date, and does not attempt any more transfers until the next due date.

For automatic transfer payment loans (Payment Method field value is (2) Auto transfer), you should set the loan’s Due Date Advance Code field value to any value other than (0) Use Max Due Date Advance Period and set the Max Due Date Advance Period field value to 0 if you set this field value greater than or equal to twice the standard payment. This change is because Symitar Quest still advances the due date based on the standard payment amount. Therefore, if the Due Date Advance Code field value is set to (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 0, and if twice the standard payment is taken during Daily Posting, the due date advances by two payment frequencies, and the next automatic transfer payment due date will be skipped. If you set the loan Due Date Advance Code field value to (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1, no payment due dates will be skipped.

Symitar Quest also uses this field amount during Payroll Posting and during ACH Posting when the distribution amount is specified as 0.00 (zero). Symitar Quest uses this field amount only if the Loan payment amount field value is not (1) Amount required to bring current. If this field amount is not available during Payroll Posting and ACH Distribution Posting, Symitar Quest does not revert to using the standard payment amount. Symitar Quest does not clear the Partial Payment field.

Alternate Pmt Effective

This field stores the date on which the value in the Alternate Payment field becomes effective.

Enter the date on which the value in the Alternate Payment field becomes effective. This increased payment amount is in effect until the date specified in the Alternate Pmt Expiration field.

This field is not useful for loans with a Payment Method field value of (0) Cash or (1) Coupon.

Alternate Pmt Expiration

This field stores the date on which the value in the Alternate Payment field expires.

Enter the date on which the value in the Alternate Payment field expires.

This field is not useful for loans with a Payment Method field value of (0) Cash or (1) Coupon.

Partial Payment

Symitar Quest stores the amount of any partial payments made to the loan in this field.

This field does not apply to loans with the Interest Type field value set to (1) Monthly 360 or (8) Scheduled/364. For those loans, you can only post unapplied partial payments (see the Allow Unapplied Partial Pmt field description). Whenever a Loan Payment (LP) teller transaction affects this loan, Symitar Quest determines the value of this field according to the Due Date Advance Code field value in the Loan record, as described below:

• If the value in the Due Date Advance Code field is (0) Use Max Due Date Advance Period and the value in the Max Due Date Advance Period field is set to 0, the loan’s due date advances each time a full payment is made. To accomplish this advance:

  • Symitar Quest subtracts any late charge amount from the amount of the payment if the late charge is calculated in addition to the standard payment.
  • Symitar Quest adds the amount arrived at in the previous step to any existing amount in this field.
  • Symitar Quest determines the amount due for the current due date by searching each Pmt Bucket Due Date field in the Loan record (from bucket 8 to bucket 1) until it finds the first date on or before the due date.
  • Symitar Quest finds the Pmt Bucket Amt field that corresponds to the Pmt Bucket Due Date field found in the previous step, or if all bucket due dates are blank, uses the value of the Payment field as the due amount.
  • If the value of the current transaction amount plus any existing amount in Partial Payment equals or exceeds the due amount, Symitar Quest advances the due date of the loan by one frequency and increments the Payments Made field value by one.
  • Symitar Quest repeats the preceding steps until it runs out of funds or until the amount remaining is not sufficient to equal a full payment. Any amount remaining is stored in the Partial Paymentfield.

• If the value in the Due Date Advance Code field is (0) Use Max Due Date Advance Period and the value in the Max Due Date Advance Period field is set to 1–99, the loan’s due date can only advance until it matches the value in the Max Loan Due Date field. To accomplish this advance:

  • Symitar Quest checks the value in the Max Loan Due Date field to determine whether the due date can advance. If the current loan due date equals or exceeds the value of the Max Loan Due Date field, the payment is applied to the loan but the due date does not advance and no amount is stored in the Partial Payment field.
  • If the due date can advance by at least one frequency, Symitar Quest subtracts any late charge amount from the amount of the payment if the late charge is calculated in addition to the standard payment.
  • Symitar Quest adds the amount arrived at in the previous step to any existing amount in this field.
  • Symitar Quest determines the amount due for the current due date by searching each Pmt Bucket Due Date field in the Loan record (from bucket 8 to bucket 1) until it finds the first date on or before the due date.
  • Symitar Quest finds the Pmt Bucket Amt field that corresponds to the Pmt Bucket Due Date field found in the previous step, or if all bucket due dates are blank, uses the value of the Payment field as the due amount.
  • If the value of the current transaction amount plus any existing amount in the Partial Payment field equals or exceeds the due amount, Symitar Quest advances the due date of the loan by one frequency and increments the Payments Made field value by one.
  • Symitar Quest repeats the preceding steps until one of the following is true:
    • There are no funds remaining
    • The amount remaining is not sufficient to equal a full payment
    • The due date reaches the value in the Max Loan Due Date field
  • If the value in the Max Loan Due Date field has not been reached, any amount remaining is stored in the Partial Payment field.
  • If the value in the Max Loan Due Date field is reached, the remainder of the payment is applied to the loan but the value of the Partial Payment field remains at $0.00.
  • If a payment is made before the date in the Beginning Cycle Date field, it is applied as principal and is not stored in the Partial Payment field to apply to the next payment due date.

• If the value in the Due Date Advance Code field is (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1 and the Initial BCD Setting Option field value set to (1) Use Loan Due Date (One when due), the loan’s due date can only advance by one frequency when a payment is received on or after the due date. To accomplish this advance:

  • Symitar Quest compares the loan’s due date to the value in the Max Loan Due Date field.
  • If the loan’s due date equals or exceeds the value in the Max Loan Due Date field, the transaction posts to the loan but the due date does not advance and no amount is stored in the Partial Payment field.
  • If the loan’s due date is less than the value in the Max Loan Due Date field:
    • Symitar Quest subtracts any late charge amount from the amount of the payment if the late charge is calculated in addition to the standard payment.
    • Symitar Quest determines the amount due for the current due date by searching each Pmt Bucket Due Date field in the Loan record (from bucket 8 to bucket 1) until it finds the first date on or before the due date.
    • Symitar Quest finds the value of the Pmt Bucket Amt field that corresponds to the value of the Pmt Bucket Due Date field found in the previous step, or if all bucket due dates are blank, uses the value in the Payment field as the due amount.
    • If the value of the current transaction amount plus any existing amount in the Partial Payment field equals or exceeds the due amount, Symitar Quest advances the due date of the loan by one frequency and increments the Payments Made field value by one.
    • Symitar Quest repeats the preceding steps until one of the following is true:
      • There are no funds remaining
      • The amount remaining is not sufficient to equal a full payment
      • The due date reaches the value in the Max Loan Due Date field.
    • If the value in the Max Loan Due Date field has not been reached, any amount remaining is stored in the Partial Payment field.
    • If the value in the Max Loan Due Date field has been reached, the remainder of the payment is applied to the loan but the Partial Payment field remains at $0.00.

• If the value in the Due Date Advance Code field is (1) Overlimit payments use ‘Max Due Date Advance Period’ else use ‘One when due’:

  • If the loan was overlimit at the last statement cutoff, Symitar Quest determines the effect of a loan payment on this field as described above using the value in the Due Date Advance Code field set to the (0) Use Max Due Date Advance Period.
  • If the loan was not overlimit at the last statement cutoff, Symitar Quest determines the effect of a loan payment on this field as described above using the value in the Initial BCD Setting Option field set to (1) One When Due. Note: If you attempt to maintain the Partial Payment field and the Allow Unapplied Partial Pmt field value is set to (1) Yes, Symitar Quest sends the following error:

Error: Update not allowed when Allow Unapplied Partial Pmt is set to Yes. ``` For non-SymChoice Loans, anytime a payment is posted to a loan, Symitar Quest posts a comment noting the value of the Partial Payment field before the associated loan payment. No comment is posted if the Partial Payment field value was set to $0.

```text

Due Date mm/dd/yy %% PartialPmt xxx.xx to xxx.xx ``` For SymChoice Loans, the comments are posted per the Loan Segment record:

```text

Due Date mm/dd/yy %% Sxxxx PartialPmt xxx.xx to xxx.xx ``` These comments are suppressed on receipts and statements, but display and print in member history and online banking. When a payment is voided, the %% comment restores the partial payment value. No comment is posted if the Partial Payment field value was $0 before the transaction you are voiding. The %% comments are used to automatically repopulate the Partial Payment field when a payment is voided. If you do a payment adjustment, you can use this field to update the Partial Payment field manually.

For loans with a value of (6) LOC Combination in the Loan Code field, the Partial Payment field value is the total partial payments for all segments, including Segment 0. If you or Symitar Quest perform file maintenance on the same field on an associated Segment record, Symitar Quest updates this field accordingly.

Whenever you void a Loan Payment (LP) teller transaction, Symitar Quest resets the Partial Payment field value to the value it held before the transaction. If you adjust a Loan Payment teller transaction, you should determine the effect of the adjustment on the value in the Partial Payment field and update this field manually.

Unapplied Partial Payment

Symitar Quest stores and accumulates the unapplied partial payments made to loans with the Interest Type field value set to (1) Monthly 360 day or (8) Scheduled/364, through loan payment and Loan Payment Adjustment (LPZ) transactions until a full payment can be posted to the loan.

• As additional loan payments are received, Symitar Quest checks the balance in this field to determine if the balance combined with the new loan payment amount equals or exceeds the next loan payment due amount.

  • If the combined total is not enough to fulfill a standard or threshold loan payment, the new payment amount is applied to this field where it stays until additional funds are received.
  • If the combined total equals or exceeds a standard or threshold loan payment, the entire amount is moved from this field to post to the loan payment due, which advances the value in the Due Date field by one frequency and increments the value in the Payments Made field by one. Symitar Quest applies any remaining funds to the loan, according to the applicable Excess Order parameter in the Payment Application Methods parameter.

• Symitar Quest attempts to clear this field balance each time a loan payment is applied that advances the loan Due Date, and applies the funds according to the applicable Excess Order parameter. Note:

  • Example 1 - Additional funds received: A member’s standard loan payment is $1,000. Earlier in the month a partial payment of $600 was received and applied to this field. Today, another payment of $600 is received. The combined amount of $1,200 is applied to the loan: $1,000 to the loan to advance the Due Date, and the remaining $200 is applied according to the Excess Order parameter.
  • Example 2 - Full payment received: A member’s standard loan payment is $1,000. Earlier in the month a partial payment of $250 was received and applied to this field. Today, a payment of $1,000 is received. Symitar Quest applies the $1,000 to the loan to advance the Due Date, and moves the $250 from this field and applies it to the loan according to the Excess Order parameter.

• Transactions to this field appear in Transaction History as Unapplied Partial Pmt Chg in the extended view, and in the Description field as Unap in the collapsed view.

• This field balance resides in a non-interest bearing GL account by loan type, titled Loan Unapplied Partial Payment.

• Whenever a transaction affects this field balance, there is a corresponding Loan Unapplied Partial Payment GL entry, and Unapplied Partial Pmt Chg (and Unap) transaction record entry.

• The method of accumulating partial payments in this field applies to loans with the Interest Type field value set to (1) Monthly 360 day or (8) Scheduled/364.

• The method of accumulating partial payments in this field applies to all defined payment application methods (Standard, SBA Required Method, or mortgage method) parameters.

• The method of accumulating partial payments in this field can occur through all posting programs, which is controlled by a parameter or posting prompt.

• Transactions to this field can only occur when a loan payment is made, or through Teller Transactions Loan Payment Adjustments (LPZ).

• The balance in this field cannot be less than zero.

• When a Void (VO) transaction is made to a loan payment, Symitar Quest resets this field to the value it held before the transaction.

• A Loan Payment Adjustments (LPZ) that creates a negative balance in this field excepts out, sending the following error message:

Error: Unapplied Partial Payment balance cannot be negative! ```

• You can only manually transfer funds from this field through the Loan Payment Adjustment (LPZ) teller transaction to:
  • A loan payment
  • An assessed fee/late charge
  • An Escrow Share
  • Additional principal
  • Another Share or Loan record under the Account Manager
  • Return to the member

You cannot perform file maintenance on this field.

Stmt Unapplied Partial Pmt

Symitar Quest stores the loan balance in this field from the Unapplied Partial Payment field as of the Statement Date field value.

You cannot perform file maintenance on this field.

Allow Unapplied Partial Pmt

This field stores a code that specifies if unapplied partial payments are allowed to accumulate in the Unapplied Partial Payment field for loans with the Interest Type field value set to (1) Monthly 360 day or (8) Scheduled/364.

This field allows you to selectively turn the functionality on or off at the loan level.

Data Type Descriptions

(0) No

Reject partial payments for this loan through all posting programs even if the posting program allows it. For example, if Daily Posting allows payment shortages and this field option is selected, the system rejects the payment shortage.

Symitar Quest lets you set this field to No when the Unapplied Partial Payment field value is greater than 0. If a posting program allows for unapplied partial payments, the system attempts to take the difference of the amount due for the loan (LOANDUECALC) minus the balance in the Unapplied Partial Payment field. If there are sufficient funds, the loan Due Date field value is advanced and the Unapplied Partial Payment field is cleared. If there are insufficient funds to advance the loan Due Date field value, the system returns an error stating partial payment is not allowed.

(1) Yes

Allow partial payments to accumulate in Unapplied Partial Payment field for this loan.

- Symitar Quest documents accepted partial payments applied to the **Unapplied Partial Payment** field on applicable posting program exception reports, or to the front-end user.
- If this field option is selected and the **Interest Type** field value is not **(1) Monthly 360 day** or **(8) Scheduled/364**, Symitar Quest returns this error message:
    ```text

Error: Interest Type does not Allow Unapplied Partial Payment. - Symitar Quest does not allow you to answer **Yes** to the **Allow Unapplied Partial Pmt** loan field if the **Partial Payment** field is **> 0** and returns this error message:text Error: Update not allowed, Partial Payment field is greater than zero. ``` This process eliminates the possibility of a balance in both the Unapplied Partial Payment and Partial Payment fields.

Last FM Date

Symitar Quest stores the date of the last file maintenance of this Loan record or a child record of this Loan record in this field.

Whenever you perform file maintenance on this Loan record using Account File Maintenance or the File Maintenance (FM) teller transaction, Symitar Quest updates this field with the system date.

Note: This field in the Loan record is not updated when the file maintenance is performed by a batch process. Creation and revision of a Loan Tracking record does not update this field, although the deletion of a Loan Tracking record does.

You cannot access this field for manual file maintenance.

Record Change Date

Symitar Quest stores the system date in this field when you create, change, or save the Loan record. Sometimes Symitar Quest updates this field because the record was saved, even though there may not be any actual changes in the record.

Note: Symitar Quest does not change the Record Change Date when a calculated field changes.

You cannot perform file maintenance on this field.

Last Transaction Date

Symitar Quest stores the date of the last teller or batch transaction that affected this Loan record in this field.

Whenever a teller or batch transaction affects a Loan record, Symitar Quest updates this field with the posting date of the transaction posted to the loan.

Unlike the Activity Date field in the Account record, insurance, dividend, withholding, interest refund, and fee transactions cause Symitar Quest to update this field.

If you void the first transaction ever posted to the loan, Symitar Quest resets this date to date null (–/–/–).

You cannot perform file maintenance on this field.

Last Purge Date

Symitar Quest stores the date in this field of the last loan history purge for this loan type.

Whenever you purge loan history for this loan type using the Purge Transaction Processing batch program, Symitar Quest updates this field with the date that is one day before the date you enter at the Save Share Transactions From prompt in the batch program.

You cannot perform file maintenance on this field.

Collateral Code

This field stores the credit union-defined code to identify the collateral, if any, for the loan.

Enter the credit union-defined code (0–999) to identify the collateral, if any, for the loan.

Note: You must populate the Collateral Code, Credit Report Number, Credit Reporting Code, and ECOA Code fields accordingly when reporting a loan to a credit bureau.

You define collateral codes with the Credit Reporting Parameters in the Parameter Manager.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Collateral Code field from the specified Application record.

Collateral Date

This field stores the date the collateral, if any, was pledged for the loan.

The use of this field is entirely credit union-defined. For example, instead of using this field to store the date collateral was pledged for the loan, you can enter the date the collateral for the loan should be re-evaluated.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Collateral Date field from the specified Application record.

Approval Code

This field stores a user number or a credit union-defined code to indicate who approved the loan, depending on credit union policy.

Enter either a user number or a credit union-defined code (0-9999) to indicate who approved the loan, depending on credit union policy.

If your approval codes match the user numbers, you can use the Teller Tran Fund Approved privilege to allow or prevent users from funding a loan that they approved.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Approval Code field from the specified Application record.

Approval Date

This field stores the date the loan was approved.

Enter the date the loan was approved.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value in the Approval Date field from the specified Application record.

Military APR Loan

This field stores a code that indicates whether the loan qualifies for the military APR program.

For the loan to qualify, both the borrower and the kind of loan must qualify. The user determines whether the loan and borrower qualify, and then sets this field value.

Data Type Descriptions

(0) No

The loan and borrower do not qualify for the military APR program.

(1) Yes

The loan and borrower qualify for the military APR program.

The RB.LOAN.CALCULATE.MAPR and RD.LOAN.CALCULATE.MAPR specfiles use this field to determine whether to make a Military APR calculation for the loan.

Universal Loan Identifier 1

This field is used for HMDA reporting; it stores the unique loan identifier (ULI) of the covered loan.

The ULI is not the loan number, but the credit report number (the tradeline) that is sent to the credit bureaus.

Enter a unique identifier of the covered loan. The system validates the entered value to determine if a duplicate ULI exists. The system does not validate the Universal Loan Identifier 1 and Universal Loan Identifier 2 fields for duplicates between different record types.

Note: You can set field-level security privileges for this field to let you control file maintenance. To set the privileges, go to the Parameter Manager, select Field Control Parameters, and then select Loan. If you do not specify field-level security privileges, the default lets all users perform file maintenance on this field.

Universal Loan Identifier 2

This field is used for HMDA reporting; it stores up to five additional universal loan identifier (ULI) characters, if the ULI was previously established outside of Symitar Quest and is more than the 40 characters allowed in the Universal Loan Identifier 1 field.

The ULI is not the loan number, but the credit report number (the tradeline) that is sent to the credit bureaus.

Enter up to five additional ULI characters. The system validates the entered value to determine if a duplicate ULI exists. The system does not validate the Universal Loan Identifier 1 and Universal Loan Identifier 2 fields for duplicates between different record types.

Note: You can set field-level security privileges for this field to let you control file maintenance. To set the privileges, go to the Parameter Manager, select Field Control Parameters, and then select Loan. If you do not specify field-level security privileges, the default lets all users perform file maintenance on this field.

Calculate Universal Loan ID

This field is an action button that allows Symitar Quest to populate the Universal Loan Identifier 1 field on the Loan record.

If you click this button, Symitar Quest populates the Universal Loan Identifier 1 field on the Loan record.

Symitar Quest generates the universal loan identifier (ULI) in following format:

• The first 20 characters are from your credit union’s Legal Entity Identifier (LEI) field in Miscellaneous Parameters.
• The next 18 characters are a system-generated random numerical value.
• The last two characters are the two-character check digit.

The format is LLLLLLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRRRRCC

• L = LEI from Miscellaneous Parameters
• R = Random number
• C = Mod 97–10 check digit

If the Legal Entity Identifier field in Miscellaneous Parameters is blank, the creation of the ULI number fails and Symitar Quest sends an error message to the Misc FM Posting Exceptions report. Symitar Quest does not stop the Miscellaneous Processing batch process and the following error message is generated:

Legal Entity Identifier not found.

Note: You can set field-level security privileges for this field to let you control file maintenance. To set the privileges, go to the Parameter Manager, select Field Control Parameters, and then select Loan. If you do not specify field-level security privileges, the default lets all users perform file maintenance on this field.

Statement Group

This field stores a credit union-defined statement group number that can be used to specify groups to categorize loans for reports, displays, and statement printing.

Enter the number of the statement group (0-99) that includes statements for this loan. Whenever the Statement Generation batch program generates statements for the statement group specified in this field, Symitar Quest produces the statement for this loan.

Statement Mail Code

This field stores a credit union-defined non-mail codes to categorize reasons for not mailing statements.

Data Type Descriptions

(0) Normal

Statements for this loan should be mailed to the member in the usual manner.

1–99

Statements for this loan should not be mailed to the member. You can use credit union-defined non-mail codes (1-99) to categorize reasons for not mailing statements: incorrect address, foreign address (extra postage required), employee account, etc.

If custom text descriptions for each mail code in Statement Mail Code Names Parameters have been defined, those text descriptions display in the drop-down menu when revising this field. These descriptions help you select the correct mail code as defined by your financial institution. Symitar Quest displays the description and the mail code in the field; however, only the mail code is included on the member’s statement.

The Statement Generation batch program lets you sort loan statements according to this field.

Statement Date

Symitar Quest stores the date of the most recent statement cutoff for this loan in this field.

Whenever the Statement Cutoff Processing batch program affects this loan, Symitar Quest transfers the value in this field to the Statement Previous Date field and updates this field with the effective date of the Statement Cutoff Processing batch run.

Under normal circumstances, you should not revise this field.

Statement Previous Date

Symitar Quest stores the date the previous statement was produced for this loan in this field.

Whenever the Statement Cutoff Processing batch program affects this loan, Symitar Quest transfers the value in the Statement Date field to this field.

Under normal circumstances, you should not revise this field.

Payment Calc Type

This field stores a credit union-defined payment calculation type that defines how Symitar Quest should calculate the loan payment.

This field is useful if a loan has a tiered payment range that depends on the loan balance. For example, a tiered payment range defined with the Payment Calculation Types parameters might specify a payment of $25 for loan balances up to $500, $50 for loan balances from $500 to $1,000.

Data Type Descriptions

(0) No Change

- Symitar Quest should use the value in the **Payment** field as the loan payment.
- The loan has an **Interest Type** field value of **(1) Monthly 360 day** or **(8) Scheduled/364**.
- The loan's payments are set by a batch program such as Loan File Maintenance Processing or Statement Cutoff Processing.

This option can also be used for a SymChoice Loan (Loan Code field = (6) Combination LOC).

0001-8999

Symitar Quest should calculate loan payments during Loan Advance (LA) and Loan Segment Transfer (LG) transactions using the parameters defined for this payment calculation type with the Payment Calculation Types parameters in the Parameter Manager.

When the Loan Code field value is set to (6) LOC Combination and the payment calculation type is greater than zero, we recommend that you set up payment calculation type parameters for your SymChoice Loans so that the value of the Due Grace Days parameter matches that of the New Loan Due Date Code, New Segment Cutoff Option and New Segment Cutoff Days Loan record fields.

A defined payment calculation type appears with four-digit type numbers and a description.

The Payment Calc Type field values, 9000–9999, are reserved for future system-defined use.

Note: If the Loan Code field value is set to (6) LOC Combination, this field applies to Segment 0, not the entire loan.

If you use the MBS Multiple Repayment Programs Per Loan module and have a Schedule record associated with this Loan record that is active, the value of this field is copied from the Schedule record.

Payment Skips

This field specifies a code that specifies the number of loan payments the member is allowed to skip.

This field is useful if the credit union allows members to skip loan payments for a portion of the year. For example, a credit union might allow teachers and other educator members to skip payments during the summer months, if they are not paid during the summer. In this case, enter the number of payment skips allowed in this field, and enter the due date of the first payment the member is allowed to skip in the Payment Skip Start Day field.

Note: If you intend to allow payment skips, you must perform file maintenance on this field and the Payment Skip Start Day field before the date of the last scheduled payment before the skip. For example, if a member’s loan is paid monthly on the first of the month, and the member wants to skip payments for 11/1 and 12/1, you must perform file maintenance on the Payment Skips and Payment Skip Start Day fields before 10/1, since it is the payment on 10/1 that causes the due date to advance. If you perform file maintenance on these fields on 10/1 or after, Symitar Quest will still take a payment on 11/1.

The number of payments the member can skip is determined by the Payment Frequency field value on the loan.

Data Type Descriptions

0

No payment skips allowed if the Payment Frequency field value is set to (0) Single Pay, (1) Annual, (2) Semiannual, or (10) Immediate.

1

One payment skip is allowed if the Payment Frequency field value is set to (3) Quarterly.

1–3

Up to three payment skips allowed if the Payment Frequency field value is set to (4) Monthly

1–6

Up to six payment skips allowed if the Payment Frequency field value is set to (5) Semimonthly.

1–7

Up to seven payment skips allowed if the Payment Frequency field value is set to (6) Biweekly skip first, (7) Biweekly skip last, or (8) Biweekly.

1–9

Up to nine payment skips allowed if the Payment Frequency field value is set to (9) Weekly, (11) Weekly skip first, or (12) Weekly skip last.

If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Payment Skips field of the loan calculation screen.

You cannot specify payment skips for a loan that has the Interest Type field value set to (1) Monthly 360 day.

Note: Although Symitar Quest does not restrict you from applying payment skips to an escrow loan, doing so may cause a shortage in escrow.

Payment Skip Start Day

This field stores a code that represents the due date of the first payment the member can skip.

This field and the Payment Skips field work together. If you enter a value in the Payment Skips field to allow members to skip that number of loan payments, you must enter a date in this field to tell Symitar Quest when to begin allowing the member to skip payments.

Note: If you intend to allow payment skips, you must perform file maintenance on this field and the Payment Skips field before the date of the last scheduled payment before the skip. For example, if a member’s loan is paid monthly on the first of the month, and the member wants to skip payments for 11/1 and 12/1, you must perform file maintenance on the Payment Skips and Payment Skip Start Day fields before 10/1, since it is the payment on 10/1 that causes the due date to advance. If you perform file maintenance on these fields on 10/1 or after, Symitar Quest will still take a payment on 11/1.

Data Type Descriptions

0000

The member cannot skip any payments.

0101–1231

The due date (MMDD) of the first payment the member can skip.

If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Payment Skip Start Day field of the loan calculation screen.

Payment Application Method

This field stores a system or credit union-defined code that defines how Symitar Quest should apply loan payments for this loan.

Data Type Descriptions

(0) Standard

The standard functionality is used when applying loan payments. Payments are applied in the following system-defined order: 1. Escrow 2. Termination fee (applies to loans with the Loan Code field set to (4) Lease) 3. Disposition fee (applies to loans with the Loan Code field set to (4) Lease) 4. Late charges 5. Sales tax (applies to loans with the Loan Code field set to (4) Lease) 6. Interest 7. Billed fees 8. Principal

This order is the standard way Symitar Quest applies payments for non-mortgage and non-SBA loans.

(1) SBA Required Method

Apply payments in the following system-defined order: 1. Escrow 2. Interest 3. Principal 4. Late charges 5. Additional principal

This order conforms to the SBA requirements for applying payments on a 365-day calendar basis. On loans based on a 365-day calendar year, interest must be collected to the date the payment is received. These payments are applied in the manner indicated, regardless of how the payment is processed (teller transactions, Daily Posting, ACH, batch programs, SymXchange, transfers, ATM, home banking, audio response, etc.).

The Escrow portion of each payment installment due will be collected first for SBA escrowed loans, using a daily interest type method. This collection ensures the member’s escrow account is properly maintained, and accurately depicts the escrow balance as of the loan due date. This process provides the ability to accurately run escrow analysis and ensure that sufficient funds are available when escrow disbursements are due.

You should consider using the mortgage order method for SBA Loans using the Interest Type field value option (1) Monthly 360 day.

This method uses the Fees/Charges Posting Option field value to determine how Symitar Quest collects late charges when applying a loan payment.

(2) Alternate Standard Method I

Follow the posting order for applying loan payments and to defer uncollected billed fees and late charges in the following system-defined order: 1. Escrow 2. Interest 3. Principal 4. Billed fees 5. Late charges

This method uses the Fees/Charges Posting Option field value to determine how Symitar Quest collects billed fees and late charges when applying a loan payment.

Additionally, you cannot use this method in a Loan record when the Interest Type field value is set to (1) Monthly 360 day or (8) Scheduled/364 and theLoan Code field value is set to (3) Credit Card, (4) Lease, (5) Avg Daily Bal LOC, or (6) LOC Combination.

(3) Alternate Standard Method II

Follow the posting order for applying loan payments and to defer uncollected late charges and billed fees in the following system-defined order: 1. Escrow 2. Interest 3. Principal 4. Late charges 5. Billed fees

This method uses the Fees/Charges Posting Option field value to determine how Symitar Quest collects billed fees and late charges when applying a loan payment.

Additionally, you cannot use this method in a Loan record when the Interest Type field value is set to (1) Monthly 360 day or (8) Scheduled/364 and the Loan Code field value is set to (3) Credit Card, (4) Lease, (5) Avg Daily Bal LOC, or (6) LOC Combination.

(10-9999)

Apply payments on a mortgage loan (the Interest Type field value set to (1) Monthly 360 Day or (8) Scheduled/364) in the following system-defined order: 1. Interest 2. Principal 3. Escrow 4.

These mortgage payment application method selections (10–9999) only appear if they are defined in the Payment Application Methods parameters.

Note: If you select a payment application method that uses a mortgage payment order (10–9999), and either of the following is true, Symitar Quest sends an error:

• The Loan Code field value is not (0) Closed end, (1) Open end, or (2) Line of credit
• The Interest Type field value is not (1) Monthly 360 day or (8) Scheduled/364

Payment Count

Symitar Quest stores the total number of payments in the term of the loan in this field.

Symitar Quest calculates this value using the value in the Loan Months field from the loan calculation screen and the value in the Payment Frequency field in the Loan record, as follows:

• If the Payment Frequency field value is set to (0) Single Pay or (10) Immediate, the value in this field is set to 1.
• If the Payment Frequency field value is set to (1) Annual, the value in this field is set to the Loan Months field value divided by 12.
• If the Payment Frequency field value is set to (2) Semiannual, the value in this field is set to the Loan Months field value divided by 6.
• If the Payment Frequency field value is set to (3) Quarterly, the value in this field is set to the Loan Months field value divided by 3.
• If the Payment Frequency field value is set to (4) Monthly, the value in this field is set to the Loan Months field value.
• If the Payment Frequency field value is set to (5) Semimonthly, (6) Biweekly skip first, or (7) Biweekly skip last, the value in this field is set to the Loan Months field value multiplied by 2.
• If the Payment Frequency field value is set to (8) Biweekly, the value in this field is set to the Loan Months field value divided by 12, with the result multiplied by 26.
• If the Payment Frequency field value is set to (9) Weekly, the value in this field is set to the Loan Months field value divided by 12, with the result multiplied by 52.
• If the Payment Frequency field value is set to (11) Weekly skip first or (12) Weekly skip last, the value in this field is set to the Loan Months field value multiplied by 4.

If you use the Pull Fields From App action field, Symitar Quest updates this field with the value calculated from the Payment Frequency and Loan Months fields from the specified Application record. If you use the Loan Calc Screen action field, Symitar Quest updates this field with the value calculated from the Payment Frequency and Loan Months fields of the loan calculation screen.

Under normal circumstances, you should not revise this field.

Payments Made

Symitar Quest stores the number of payments made during the term of the loan in this field.

Symitar Quest updates this field each time a Loan Payment (LP) teller transaction posts to the loan and the scheduled payment amount is satisfied. To understand how and when Symitar Quest updates the value in this field, see the Partial Payment field description. When you void a Loan Payment (LP) transaction, Symitar Quest decreases this field by the appropriate number of payments. If you perform a Loan Payment Adjustment (LPZ) or a Recast Loan (RL) transaction, you must update this field manually, if necessary.

FASB 91 Alternate Term

This field stores a credit union-determined term that is shorter than the term of the loan calculated for the Payment Count field.

Symitar Quest uses this field as the term for straight-line calculations performed during the GL Posting batch program for Loan FASB 91 accruals. The calculations determine a monthly amount from the Original Amortized Fees field that the Loan FASB 91 Accruals posts when you run the GL Posting batch program.

Note: An interactive demonstration explaining how changes to this field affect the calculation of the loan term is available on the For Clients portal: FASB Alternate Term calc.xlsx.

If this field is zero, then the Payment Count field value is used as the term for straight-line calculations.

11- 30 Days DQ

Symitar Quest stores the number of times loan payments have been late by the number of days specified in the Payment History Day Cutoff 1 parameter defined in the Miscellaneous Parameters.

The field value is customizable and the field name reflects the value you entered into Miscellaneous Parameters. As an example, you can change the parameter definition to 35 days changing the field name to 11-35 Days DQ to fit the needs of your credit union. However, the Name value in PowerOn Control remains as 11-30 Days DQ.

Whenever a Loan Payment (LP) transaction affects this loan and the payment is late, Symitar Quest updates the values in the 11- 30 Days DQ, 31- 60 Days DQ, 61- 90 Days DQ, 91- 120 Days DQ, and 121 and up Days DQ fields according to the number of days the payment is late. If you void a Loan Payment teller transaction, Symitar Quest adjusts the values in these fields accordingly. If you adjust a Loan Payment teller transaction, you may have to update the values in these fields manually.

This field is not related to the Payments Made field.

31- 60 Days DQ

Symitar Quest stores the number of times loan payments have been late by the number of days specified in the Payment History Day Cutoff 2 parameter defined in the Miscellaneous Parameters.

The field value is customizable and the field name reflects the value you entered into Miscellaneous Parameters. As an example, you can change the parameter definition to 65 days changing the field name to 31-65 Days DQ to fit the needs of your credit union. However, the Name value in PowerOn Control remains as 31-60 Days DQ.

Whenever a Loan Payment (LP) transaction affects this loan and the payment is late, Symitar Quest updates the values in the 11- 30 Days DQ, 31- 60 Days DQ, 61- 90 Days DQ, 91- 120 Days DQ, and 121 and up Days DQ fields according to the number of days the payment is late. If you void a Loan Payment teller transaction, Symitar Quest adjusts the values in these fields accordingly. If you adjust a Loan Payment teller transaction, you may have to update the values in these fields manually.

This field is not related to the Payments Made field.

61- 90 Days DQ

Symitar Quest stores the number of times loan payments have been late by the number of days specified in the Payment History Day Cutoff 3 parameter defined in the Miscellaneous Parameters.

The field value is customizable and the field name reflects the value you entered into Miscellaneous Parameters. As an example, you can change the parameter definition to 95 days changing the field name to 61-95 Days DQ to fit the needs of your credit union. However, the Name value in PowerOn Control remains as 61-90 Days DQ.

Whenever a Loan Payment (LP) transaction affects this loan and the payment is late, Symitar Quest updates the values in the 11- 30 Days DQ, 31- 60 Days DQ, 61- 90 Days DQ, 91- 120 Days DQ, and 121 and up Days DQ fields according to the number of days the payment is late. If you void a Loan Payment teller transaction, Symitar Quest adjusts the values in these fields accordingly. If you adjust a Loan Payment teller transaction, you may have to update the values in these fields manually.

This field is not related to the Payments Made field.

91-120 Days DQ

Symitar Quest stores the number of times loan payments have been late by the number of days specified in the Payment History Day Cutoff 4 parameter defined in the Miscellaneous Parameters.

The field value is customizable and the field name reflects the value you entered into Miscellaneous Parameters. As an example, you can change the parameter definition to 125 days changing the field name to 91-125 Days DQ to fit the needs of your credit union. However, the Name value in PowerOn Control remains as 91-120 Days DQ.

Whenever a Loan Payment (LP) transaction affects this loan and the payment is late, Symitar Quest updates the values in the 11- 30 Days DQ, 31- 60 Days DQ, 61- 90 Days DQ, 91- 120 Days DQ, and 121 and up Days DQ fields according to the number of days the payment is late. If you void a Loan Payment teller transaction, Symitar Quest adjusts the values in these fields accordingly. If you adjust a Loan Payment teller transaction, you may have to update the values in these fields manually.

This field is not related to the Payments Made field.

121 and up Days DQ

Symitar Quest stores the number of times loan payments have been late by the number of days specified in the Payment History Day Cutoff 5 parameter defined in the Miscellaneous Parameters.

The field value is customizable and the field name reflects the value you entered into Miscellaneous Parameters. As an example, you can change the parameter definition to 125 days changing the field name to 125 and up Days DQ to fit the needs of your credit union. However, the Name value in PowerOn Control remains as 121 and up Days DQ.

Whenever a Loan Payment (LP) transaction affects this loan and the payment is late, Symitar Quest updates the values in the 11- 30 Days DQ, 31- 60 Days DQ, 61- 90 Days DQ, 91- 120 Days DQ, and 121 and up Days DQ fields according to the number of days the payment is late. If you void a Loan Payment teller transaction, Symitar Quest adjusts the values in these fields accordingly. If you adjust a Loan Payment teller transaction, you may have to update the values in these fields manually.

This field is not related to the Payments Made field.

Fees/Charges Posting Option

This field stores a code that determines how billed fees and late charges are collected after a loan payment is applied.

This field does not apply to late charges when the late charge comes out of the standard payment.

This field applies only to loans that use one of the following options in the Payment Application Method field: If the Payment Application Method field is set to anything other than one of these options, the field cannot be revised and Symitar Quest displays one of the following default values:

• (1) SBA Required Method

• (2) Alternate Standard Method I

• (3) Alternate Standard Method II

• (0) Not Used for this Payment Application Method

• (1) Not Used for this Payment Application Method

• (2) Not Used for this Payment Application Method

(0) Pay when loan is current

Automatically postpone billed fees and late charges until the loan is current.

Symitar Quest considers the loan current if the member satisfies the payment due for that billing cycle. Once the loan is current, Symitar Quest applies the excess amount to billed fees, late charges, and unpaid escrow before satisfying the next payment due date.

(1) Pay per due date

Pay billed fees and late charges, per due date, after the periodic payment for that due date has been satisfied.

- When the member satisfies the first periodic payment, Symitar Quest applies the excess funds to billed fees (including postponed billed fees) and late charges (including postponed late charges), based on the payment order.
- When the member satisfies billed fees and late charges, Symitar Quest applies the excess funds to unpaid escrow.
- When the member satisfies the unpaid escrow balance, Symitar Quest applies the excess funds to the payment order for the next period and fully distributes the loan payment.

(2) Pay after periodic payments are applied

Pay billed fees and late charges per due date, with excess funds remaining after satisfying as many full periodic payments as possible.

The loan is current when the member satisfies the payment for that billing cycle.

- When the member does not satisfy the loan due date for the current billing cycle, but does satisfy full periodic payments, Symitar Quest applies the excess funds to billed fees (including postponed billed fees) and late charges (including postponed late charges), based on the payment order.
- After the member satisfies billed fees and late charges, Symitar Quest applies the excess funds to unpaid escrow.

Stmt Fees YTD

Symitar Quest stores the amount in this field to be printed on statements of total fees charged to this loan this year.

This field, populated by the Statement Cutoff Processing batch program, is the sum of the following fields:

• Billed Fee YTD No Adj
• CA/BT Trans Int Chg Billed YTD
• Fees YTD No Adj
• Insurance YTD No Adj
• Late Charge YTD No Adj

Under normal circumstances, you should not revise this field.

Stmt Fees Last Year

Symitar Quest stores the sum of all fields that make up the Stmt Fees YTD field for this loan during the previous year in this field.

The following fields are used to get the sum in the Stmt Fees YTD field:

• Billed Fee YTD No Adj
• CA/BT Trns Int Chg Billed YTD
• Fees YTD No Adj
• Insurance YTD No Adj
• Late Charge YTD No Adj

When you run the Close Day Processing batch program at the end of a calendar year, Symitar Quest copies the amount in the Stmt Fees YTD field and puts it in the Stmt Fees Last Year field. After the first run of the Statement Cutoff batch program, Symitar Quest sets the Stmt Fees YTD field to zero.

This field does not include adjustments.

Under normal circumstances, you should not revise this field.

Fees YTD

Symitar Quest stores the amount in this field of total fees charged to this loan this year.

This field is updated by transaction processing of any fee. During a teller transaction, all charged fees designated in Miscellaneous Parameters as Regulation Z Fee Types are also included in value in this field.

Under normal circumstances, you should not revise this field.

Fees YTD No Adj

Symitar Quest stores the total amount in this field of transaction fees charged to a loan during the current year, not including adjustments.

Symitar Quest adds the fee amount to this field whenever any transaction fee is processed. During a teller transaction, all charged fees designated in Miscellaneous Parameters as Regulation Z Fee Types are also added to this field.

When you run the Close Day Processing batch program at the end of a calendar year, Symitar Quest transfers the amount in this field to the Fees Last Yr No Adj field and resets this field to 0.00.

Under normal circumstances, you should not revise this field.

Fees Last Year

Symitar Quest stores the amount in this field of total fees charged to this loan during the previous year.

The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the value in the Fees YTD field to this field.

Under normal circumstances, you should not revise this field.

Fees Last Yr No Adj

Symitar Quest stores the amount in this field of fees assessed on the loan the previous year, not including adjustments.

Under normal circumstances, you should not revise this field.

Stmt Max Late Fee

This field stores value of the maximum late fee to be printed in the Late Payment Warning disclosure on member statements for credit card loans.

If this field is 0.00, then the Late Payment Warning is determined by the Late Charge Type Parameters.

Stmt Max Penalty APR

Symitar Quest stores the maximum penalty Annual Percentage Rate (APR) on a loan in this field to print in the Late Payment Warning section on statements.

If this field is 0.000%, then Statement Generation batch program uses the Late Charge Type parameters to calculate the maximum penalty APR. If 0.000% is calculated from the Late Charge Type parameters, then the Late Payment Warning will not print.

Under normal circumstances, you should not revise this field.

Current Statement Period Fees

Symitar Quest stores the accrued amounts of fees paid on the loan in this field for the current statement period.

The Regulation Z Fee Types parameter in the Miscellaneous Parameters identifies the fee types accrued in this field.

Placing a fee into the Military APR Fee Types parameter in Miscellaneous Parameters does not affect whether that fee accrues to this field. The amount of a fee with a fee type of (0) Unknown does not accrue to this field.

Under normal circumstances, you should not revise this field.

Previous Statement Period Fees

Symitar Quest stores the accrued amounts of fees paid on the loan in this field for the previous statement period.

The Regulation Z Fee Types parameter in the Miscellaneous Parameters identifies the fee types accrued in this field.

Under normal circumstances, you should not revise this field.

Current Stmt Interest Accrued

Symitar Quest stores the total interest charged or accrued for the current statement period in this field.

This field accumulates interest during a statement period that the Reg Z APR calculation uses for a Loan record Loan Code field with a value of (1) Open End, (2) Line of Credit, or (6) LOC Combination.

The field also includes the total interest paid during the current statement period for loans with a Loan record Loan Code field that has a value of (0) Closed End or (4) Lease, unless those loans also have a Loan record Interest Type field with the value (1) Monthly 360 Day or (8) Scheduled 364.

For SymChoice Loans, this field contains the accumulated interest for all loan segments, not just segment 0 (zero). The Loan record Seg 0 Current Stmt Int Accr field holds the accumulated interest for segment 0 only.

Under normal circumstances, you should not revise this field.

Previous Stmt Interest Accrued

Symitar Quest stores the total interest charged or accrued for the previous statement period in this field.

For SymChoice Loans, this field contains the previously accumulated interest for all loan segments, not just segment 0. The Loan record Seg 0 Previous Stmt Int Accr field holds the previously accumulated interest for segment 0 only.

Under normal circumstances, you should not revise this field.

MAPR Current Stmt Int Accrued

Symitar Quest stores the total interest charged or accrued for the current statement period in this field, beginning on the day following the date in the Statement Date field.

Symitar Quest uses this field for the Military APR calculation.

This field accumulates interest during a statement period for loans with one of the listed values in both of the indicated Loan record fields:

• The Military APR Loan field value is set to Yes.
• The Loan Code field value is set to one of these values:
  • (0) Closed End
  • (1) Open End
  • (2) Line of Credit
  • (4) Lease
  • (6) LOC Combination If the Loan record has the Loan Code field set to (0) Closed End or (4) Lease, Symitar Quest populates this field. The system does not use the interest amount in calculating the MAPR. Only calculations for open-end loans use the value in this field.

This field does not accumulate interest for loans with a value in the Interest Type field of (1) Monthly 360 Day or (8) Scheduled/364.

For SymChoice Loans and credit card loans, this field contains the accumulated interest for all loan segments.

When you run the Statement Cutoff Processing batch program, Symitar Quest resets this field to 0 (zero).

Under normal circumstances, you should not revise this field.

Statement Escrow Unpaid

Symitar Quest stores the balance in the Escrow Unpaid field in this field as of the date in the Statement Date field.

Under normal circumstances, you should not revise this field.

DQ Notice Type

This field stores a code that identifies which set of delinquency notices are to be used for the loan.

Enter a defined DQ notice type code (0-99) defined in the Delinquent Notice Messages parameters to indicate the type of delinquent notice to be used.

DQ Notice

This field stores the total number of delinquent notices generated for this loan. The field can also indicate if Symitar Quest should not generate delinquent notices for this loan.

Data Type Descriptions

0–8

Initially set to 0, Symitar Quest increments this field by 1 each time the Daily Posting batch program generates a delinquent notice for the loan, until all eight possible delinquent notices have been generated, or until the loan is brought current.

(9) No Notices

Enter this value if Symitar Quest should not generate delinquent notices for this loan (for example, if the loan is charged off).

Under normal circumstances, you should not revise this field.

DQ Notice Date

Symitar Quest stores the last date a delinquent notice was generated for this loan in this field.

Symitar Quest updates this field each time the Daily Posting batch program generates a delinquent notice for the loan.

Under normal circumstances, you should not revise this field.

DQ Card Date

Symitar Quest stores the last date a delinquent card was generated for this loan in this field.

Symitar Quest updates this field each time the Daily Posting batch program generates a delinquent card for the loan.

Under normal circumstances, you should not revise this field.

DQ Calculation Method

This field stores a code that indicates if Symitar Quest should calculate the values for the payment buckets each month.

Data Type Descriptions

(0) Payment Buckets Only Contain Changes

Symitar Quest should not calculate the values for the payment buckets each month. For closed and open-end loans with a fixed payment amount, Symitar Quest does not use the payment buckets.

When you run Loan file maintenance processing, Statement Cutoff Processing, or Rate Change Processing for loans with a variable payment amount, Symitar Quest updates the value in the Pmt Bucket Amt and Pmt Bucket Due Date fields only when the payment amount changes.

(1) Payment Buckets Are Calculated Monthly

Symitar Quest should calculate the values for the payment buckets each month. Symitar Quest updates each value in the Pmt Bucket Amt and Pmt Bucket Due Date field on a monthly basis, regardless of whether the payment amount changes.

This delinquency method can be used on line of credit and credit card loans only if they meet the following characteristics:

• The Payment Frequency field value must be (4) Monthly.
• No value in the Payment Skips field.
• A payment required each month (cannot be paid ahead).
• The Payment Calc Type field value must be (0) No Change.
• There must be a monthly amount in the Payment field calculated by the Loan File Maintenance Processing batch program (for line of credit loans) or by the Statement Cutoff Processing batch program (for credit card loans). Note: You must run the Set Loan Payments Amounts function of the Loan File Maintenance Processing batch program on a monthly basis to calculate the payment amount for line of credit loans, or they show totally incorrect delinquency information.

This delinquency method can also be used for interest-only loans with the following characteristics: - The Payment Type field value must be (1) Level Principal. - The Payment field value must be 0.00 (for interest-only payments). - The Due Date Advance Code field value must be (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1 and the Initial BCD Setting Option field value set to (1) Use Loan Due Date (One when due). - The Due Day 1 field value must be completed to enable Symitar Quest to calculate the scheduled due dates. - The Payment Calc Type field value must be (0) No Change. - There must be a monthly amount in the Payment field calculated by the Daily Posting Batch Program. - You can only use this option for loans with the Interest Type field set to (0) Daily 365 Day or (5) Actual/360. Loans with this setup must be paid by automatic transfer and they do not comply with Reg Z because there is no advance billing. - The Balloon Date field value must be set to the date the loan is to be paid off. Since these loans are interest-only loans, there must be a value in the Balloon Date field. Note: Do not run the Loan File Maintenance Processing batch program to set payment amounts for interest-only loans. Setting the loan fields as described above allows the Statement Cutoff Processing batch program to determine the payment amount for these loans.

For an explanation of how Symitar Quest uses the Pmt Bucket Amt and Pmt Bucket Due Date fields to track delinquency or payment amounts for loans with a DQ Calculation Method of**(1) Payment Buckets Are Calculated Monthly**, see the Pmt Bucket Amt 1 field description.

If you use the MBS Multiple Repayment Programs Per Loan module and have a Schedule record associated with this Loan record that is active, the value of this field is copied from the Schedule record.

We do not advise changing this field from (0) Payment Buckets Only Contain Changes to (1) Payment Buckets are Calculated Monthly on any loan that has a balance. If this field is set incorrectly in the loan and you must change it, you must also populate the payment buckets for each due date and payment amount for which you want the system to be able to calculate delinquency. When this field is set to (1) Payment Buckets are Calculated Monthly and there is no bucket corresponding to an iteration of the due date, the system assumes that the payment due for that date was $0.00 and behaves accordingly. Changing the field without updating the buckets on a loan that is currently delinquent causes the Loan File Maintenance Processing batch program to treat the loan as if it were current and pull the due date forward to the cycle for which it is setting the current payment amount, erasing the prior delinquency and forgiving all missed payments.

Early Intervention Notice Date

This field stores the last date that you sent an Early Intervention Notice to the member.

This date is for reference only. Symitar Quest does not use it for any functions.

Charge-off Date

This field stores the date that the loan was charged off.

Enter the date that the loan was charged off. When you enter a date in this field, Symitar Quest automatically creates a GL transaction entry that transfers the charged-off balance to the GL account number specified in the GL translation table for (10) Loan Principal Charge Off (see Charging Off Loans). Symitar Quest posts the GL transaction to the General Ledger when you run the Close Day Processing batch program.

Once you enter a value in this field, Symitar Quest accepts only Loan Payment (LP) teller transactions for the loan. Symitar Quest applies loan payments in the order specified by the value in the Charge Off Payment Order parameter in the Miscellaneous Parameters. You can define either of the following orders:

• Principal, then interest, then late charges
• Late charges, then interest, then principal

Note: You cannot enter a value in this field if the loan is in a participation and the Allow Charge-Off field value in the Participation record is set to No. You must remove the loan from the participation first.

If you populate this field and there is a balance greater than zero in the Unapplied Partial Payment field, Symitar Quest sends the following error:

Error: Unapplied Partial Payment balance, loan cannot be charged off.

To assign a status code of (64) Account Paid in Full, Was a Charge Off or (97) Unpaid Balance Reported as a Loss, set the Credit Reporting Code field value to (0) Normal and Symitar Quest automatically assigns the status code based on whether it is reported as paid in full or as a loss.

Charge-off Type

This field stores a credit union-defined code to indicate why this loan was charged off or what type of loan was charged off.

Enter a credit union-defined code (0-99) to indicate why this loan was charged off or what type of loan was charged off. The use of this field is entirely credit union-defined. You can use this field to categorize charge-off types for reports and displays.

Charge-off Amount

This field stores the amount charged-off.

If you charge off the loan, enter amount charged-off in this field. The amount should be positive. For example, if the loan balance is -750.00 at the time of the charge-off, type 75000. Any negative amount results in a zero on the credit report.

To assign a status code of (64) Account Paid in Full, Was a Charge Off or (97) Unpaid Balance Reported as a Loss, set the Credit Reporting Code field value to (0) Normal and Symitar Quest automatically assigns the status code based on whether it is reported as paid in full or as a loss.

If the credit union is using Metro2 format, this amount is reported to the bureau as the charged-off amount. As the member makes recovery payments, the balance may go down, but the amount in this field is the balance at charge-off.

Refund Post Code

This field stores how portions of the interest payments may be refunded, used mainly for real estate loans.

This field is for information only and does not affect interest refund postings. It merely describes how the refund is disbursed.

Data Type Descriptions

(0) To Share

Post interest refunds to a Share record.

(1) By Check

Mail interest refund checks to the member.

(2) Transfer

Transfer interest refunds to another account.

Refund YTD

Symitar Quest stores the total of all interest refunds in this field during the current year to date.

Symitar Quest adds the amount of any Interest Refund (IR) teller transaction to the value in this field. For proper IRS reporting, this field must include the amount of any refund of interest paid in a previous year. The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the value in this field to the Refund Last Year field and resets this field to 0.00.

Note: If you refund interest in the same year it was paid, you should subtract it from the value in the Interest Paid YTD field. You should place the refunded interest amount in this field only if the refund is for interest paid in a previous calendar year. For example, if you post an interest refund on December 31 that represents a refund of interest paid in the same year, you should subtract that amount from the value in the Interest Paid YTD field. If you post an interest refund on January 1 that represents a refund of interest paid in the previous year, you should add that amount to this field.

Under normal circumstances, you should not revise this field.

Refund Last Year

Symitar Quest stores the total amount of all interest refunded to the member in this field during the previous year.

The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the value in the Refund YTD field to this field.

Under normal circumstances, you should not revise this field.

Principal YTD

Symitar Quest stores the total amount applied to the principal of this loan during the current year to date.

Whenever you post a Loan Payment (LP) teller transaction to this loan, Symitar Quest adds the balance change amount to this field. If you void a Loan Payment (LP) teller transaction that affects this loan, Symitar Quest adjusts this field accordingly.

The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the value in this field to the Principal Last Year field and resets this field to 0.00.

Under normal circumstances, you should not revise this field.

Principal Last Year

Symitar Quest stores the total amount applied to the principal of this loan in this field during the previous year.

The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the value in the Principal YTD field to this field.

Under normal circumstances, you should not revise this field.

Principal Paid From Open

Symitar Quest stores the total amount of principal paid on a loan in this field.

If a loan is refinanced, the amount in this field may not be accurate.

Under normal circumstances, you should not revise this field.

Stmt Principal YTD

Symitar Quest stores the amount in the Principal YTD field in this field at the time of statement cutoff.

Under normal circumstances, you should not revise this field.

Stmt Principal Last Year

Symitar Quest stores the amount contained in the Principal Last Year field in this field at the time of statement cutoff.

Under normal circumstances, you should not revise this field.

Stmt Principal Paid From Open

Symitar Quest stores the amount in the Principal Paid From Open field in this field at the time of statement cutoff.

Under normal circumstances, you should not revise this field.

Minimum Balance

This field stores the minimum balance for the loan.

Enter the minimum balance for the loan. Symitar Quest does not allow any payment that would bring the loan balance below this minimum. This is useful for specific line of credit loans that must maintain a minimum balance.

Minimum Advance

This field stores the minimum advance amount for line of credit or credit card loans.

Enter the minimum advance amount for line of credit or credit card loans. Symitar Quest does not allow advances for less than this amount.

Reg E Count

Symitar Quest stores the total number of Regulation E transactions in this field that affected this loan during the current statement period.

Symitar Quest increments this field by 1 each time you post a transaction with a Reg E Code field value of 1 in a Transaction record for this loan. When the Statement Processing batch program updates the value in the Statement Date field, Symitar Quest resets this field to 0.

Under normal circumstances, you should not revise this field.

Secured Code

This field stores a code that indicates how this loan is secured.

Data Type Descriptions

(0) Not Pledged

The loan is not secured by any shares or stock portfolios.

(1) 100% Pledged

The loan is completely secured by one or more shares or stock portfolios.

(2) Partial Release First

The shares or stock portfolios partially securing a loan should be released before other collateral securing the loan. This option is useful if a share or stock portfolio is only one form of security pledged for the loan.

(3) Partial Release Last

The shares or stock portfolios partially securing a loan should be released after other collateral securing the loan. This option is useful if a share or stock portfolio is only one form of security pledged for the loan.

If you select (1) 100% Pledged, (2) Partial Release First, or (3) Partial Release Last, you must also create a Pledge record under the Loan record. The Loan Pledge record identifies the share or stock portfolio securing the loan, as well as the percentage or amount pledged. When you have created both the Loan record and the Pledge record (in that order), Symitar Quest creates a Hold record under the specified Share or Portfolio record.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Secured Code field from the specified Application record.

When you fund the loan using the New Loan (LN) transaction, Symitar Quest fills in the Hold Amount field in the Share Hold or Portfolio Hold record. The Share Hold or Portfolio Hold record ensures that sufficient funds are left in the share or stock portfolio to cover the percentage or amount of the security pledged for the loan.

For common pledge scenarios, go to Pledge Records.

Secured Amount

This field stores the total amount secured for this loan.

For loans that have the Secured Code field set to (1) 100% Pledged, (2) Partial Release First, or (3) Partial Release Last, Symitar Quest enters the initial value in this field when you fund the loan with the New Loan (LN) teller transaction, based on the secured amounts or percentages in the loan’s associated Pledge records. Symitar Quest updates this field with the balance change amount of any transaction that affects this loan.

Under normal circumstances, you should not revise this field. If, however, you created and funded a share-secured loan and did not set the Secured Code field to (1) 100% Pledged, (2) Partial Release First, or (3) Partial Release Last, follow the procedure described below to correct the Pledge and Hold records:

• Delete the current Loan Pledge record from the secured loan (if one exists).
• Change the Secured Code field in the Loan record to (1) 100% Pledged, (2) Partial Release First, or (3) Partial Release Last.
• Change the Secured Amount field in the Loan record to the current loan balance if the Secured Code field is set to (1) 100% Pledged, or to the appropriate partial amount of the current loan balance if the Secured Code field is set to (2) Partial Release First or (3) Partial Release Last.
• Create a new Loan Pledge record under the secured loan.

For common pledge scenarios, see Pledge Records.

FASB 91 Code

This field stores a credit union-defined code used in conjunction with loan type codes to create combinations that post to designated General Ledger accounts.

Symitar Quest usually sets the value in this field to the value in Loan Defaults. You can also enter a code (1-199) manually.

Note: You can specify loan types and FASB 91 code combinations to result in something like the following:

• Loan types 0015-0020 with FASB 91 codes 5–10 use specific General Ledger accounts.
• Loan types 0015-0020 with FASB 91 codes 11–16 use other specific General Ledger accounts.

In the FASB 91 Loan Accruals function of the GL Posting batch program after the Loan Branch List prompt, the Break Totals Down By FASB 91 Code? prompt appears. If you select Y, Symitar Quest breaks down totals by FASB 91 code. If you select N, Symitar Quest breaks down totals only by loan type.

The GL Accrual Detail for FASB 91 and GL Accrual Exceptions for FASB 91 reports have a new column that displays the FASB 91 code for each account.

Refinance Balance

Symitar Quest stores the balance of the refinance when the next Loan Refinance (LR) transaction is processed.

The Original Balance field value is not changed. This field is initially set to 0.

Refinance Date

Symitar Quest stores the date of the refinance when the next Loan Refinance (LR) transaction is processed.

The Original Loan Date field value is not changed. This field is initially set to date null (//____).

Refinance Counter

This field stores the number of Loan Refinance (LR) transactions that occurred.

With each Loan Refinance (LR) transaction created for this loan, Symitar Quest increments the value in this field by 1. This field is initially set to 0.

You can manually change this field if you want to reflect the number of Loan Refinance (LR) transactions that occurred.

Interest Payoff Calculation

This field is reserved for future use.

This field stores a code that determines how payoff interest is calculated when a payoff inquiry is performed or when the loan payment amount received is sufficient to pay the loan in full.

This field is only used for loans where the Interest Type field value is set to (1) Monthly 360 day. If the Interest Type field value is set to anything else, Symitar Quest displays one of the following and the field cannot be revised:

• 0 Not Used for this Interest Type
• 1 Not Used for this Interest Type

Data Type Descriptions

(0) Use Interest Type method

Use the method defined for interest type (1) Monthly 360 day to calculate the payoff interest due.

This method complies with Fannie Mae® and Freddie Mac® servicing guidelines. An interest type of (1) Monthly 360 day calculates interest on a 360-day year using a 30-day month basis for each full month outstanding, and calculates daily interest on a 365-day basis for a partial month.

Symitar Quest calculates interest as follows:

• For full months: Loan Balance × Interest Rate ÷ 12 (for each delinquent payment) since the Interest Date to the current due date
• For partial months: Loan Balance × Interest Rate ÷ 365 × the number of days from the current due date to the payoff date

(1) Use Daily 365-day

Use the method defined for interest type 1 to calculate payoff interest daily on a 365-day basis.

Symitar Quest calculates interest as follows: Loan Balance × Interest Rate ÷ 365 × the number of days since the Interest Date to the payoff date.

Interest Type

This field stores either a system-defined or a credit union-defined code that indicates the method Symitar Quest uses to calculate interest on the loan.

Data Type Descriptions

0 (Daily 365 day)

Calculate loan interest on a 365-day basis. Symitar Quest calculates interest as follows: Interest Rate ÷ 365 x Loan Balance x the number of days since the Interest Date.

1 (Monthly 360 day)

Calculate loan interest on a 360-day basis. This option is normally used for real estate loans only and is designed so that the payment schedule is known to the penny from the date the loan is funded. Interest calculations depend on the value in the Payment Frequency field: - If the Payment Frequency field value is set to (1) Annual, Symitar Quest calculates interest as follows: Loan Balance X Interest Rate. - If the Payment Frequency field value is set to (2) Semiannually, Symitar Quest calculates interest as follows: Loan Balance X Interest Rate ÷2. - If the Payment Frequency field value is set to (3) Quarterly, Symitar Quest calculates interest as follows: Loan Balance X Interest Rate ÷ 4. - If the Payment Frequency field value is set to (4) Monthly, Symitar Quest calculates interest as follows: Loan Balance X Interest Rate ÷ 12. - If the Payment Frequency field value is set to (5) Semimonthly, Symitar Quest calculates interest as follows: Loan Balance X Interest Rate ÷ 24.

Under this option, Symitar Quest does not accept extra principal reduction amounts on payments that are more than one payment past due. Therefore, if the loan is four months past due and you want to post four monthly payments, you must post four separate Loan Payment (LP) transactions.

Partial payments will not be accepted during the Loan Payment (LP) transaction for loans of this interest type unless your financial institution has the Accept Unapplied Pmt in Tlr? parameter set to Yes in Miscellaneous Parameters. If you absolutely have to post a partial payment, then you must use the Loan Payment Adjustment (LPZ) transaction and post it as an adjustment. Mortgage servicing rules generally do not allow for the application of partial payments. Symitar Quest does not allow the member to make a partial payment by transfer from shares. The batch programs that perform loan payments does not take partial payments on 360-day interest loans, regardless of how you answer any of the options at the Take Partial Payments? prompt in the Daily Posting batch program.

There are two times when 360-day loans are treated like 365-day loans:

• When the loan is initially funded, a special interest payment is taken that pays the interest up to one month before the first scheduled payment due date.
• When the loan is paid off, the interest due after the last scheduled payment is calculated using the normal 365-day method (see the Interest Due field description).

Note: 360-day interest loans of this type must have the following fields set as specified:

• The Interest Type field value must be set to 1 (Monthly 360 day).
• The Payment Frequency field value must be set to one of the following:
  • (1) Annual
  • (2) Semi-annual
  • (3) Quarterly
  • (4) Monthly
  • (5) Semi-monthly
• The Payment Skips field value must be set to 0.
• The Due Day 1 field value (and the Due Day 2 field value, if semimonthly) must be filled in.
• The Due Date Advance Code field value must be set to one of the following:
  • (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1
  • (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1 and the Initial BCD Setting Options field value set to (1) Use Loan Due Date (One when due)
• The Initial BCD Setting Option field value must be (1) Use Loan Due Date (One when due) to use the One when due functionality.
• The New Loan Due Date Code field value should be set to 0.
• The Loan Code field value should be set to (0) Closed End.
• The Payment Calc Type field value must be set to (0) No Change.
• The DQ Calculation Method field value must be set to (0) Payment Buckets Only Contain Changes.

2 (Daily 365.25 Day Interest)

Calculate loan interest on a 365.25-day basis. This option is normally used for student loans. Symitar Quest calculates interest as follows: Interest Rate ÷ 365.25 x Loan Balance x number of days since the Interest Date.

3 (Daily Billed Interest I)

This interest type is valid only for interest-only loans. During Statement Cutoff Processing, Symitar Quest calculates interest as follows: Interest Rate / 365 x Loan Balance x number of days since the Interest Date.

- Symitar Quest puts this amount of interest in the **Int Unpaid Billed** field.
- Symitar Quest puts this interest amount, less any delinquent interest amount, in the **Payment** field.
- Symitar Quest adjusts the **Payment Bucket** field values accordingly.
- Symitar Quest subtracts any interest payments from the **Int Unpaid Billed** field value, until it reaches 0.00 (zero), after which Symitar Quest applies any further payments to the **Billed Fee Unpaid** field value and then to principal, even if there is additional accrued interest.
- For delinquent loans when the system date has reached the balloon date, or for non-delinquent loans when the system date has reached the due date prior to the balloon date and the due date equals the balloon date, the Daily Posting batch program automatically sets this field value to **0**, the **Payment Type** field value to **(1) Level Principal**, and the **Payment** field value to the loan balance. This process causes the entire loan balance plus all accrued interest to become due and payable on the balloon date.
    **Note:** If the date in the **Due Date** and **Balloon Date** fields of the Loan record equal 03/25/2019, the loan balloons when you run the Daily Posting batch program on 02/25/2019, which is the due date prior to the balloon date.

Daily billed interest loans of this type must have the following fields set as specified: - This field value must be set to 3. - The Payment Type field value must be set to (0) Level Payment. This differs from other interest-only loans, which are set to (1) Level Principal. - The Payment Frequency field value must be set to (4) Monthly. - The Due Date Advance Code field value must be set to (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1. - The DQ Calculation Method field value must be set to (1) Payment Buckets Are Calculated Monthly. - The Balloon Date field value must be set to the loan’s due date. For example, if the loan’s due date is the 15th, the Balloon Date field value must also be set to the 15th. Since these loans are interest-only loans, there must be a balloon date.

Note: You must run Statement Cutoff Processing on a monthly basis for loans with this interest type, and you must run it for the statement group identified in the Loan record a minimum of 10 days before the loan’s due date. By regulation, you may need to run the program more than 10 days before the due date, but 10 days is the minimum to ensure that the statement can be generated and sent to the member before the loan payment is due.

4 (Daily Billed Interest II)

This interest type is valid only for interest-only loans. During Statement Cutoff Processing, Symitar Quest calculates interest as follows: Interest Rate / 365 x Loan Balance x number of days since the Interest Date.

- Symitar Quest puts this amount of interest from the **Int Unpaid Billed** field.
- Symitar Quest puts this interest amount, less any delinquent interest amount, in the **Payment** field.
- Symitar Quest adjusts the **Payment Bucket** field values accordingly.
- Symitar Quest subtracts any interest payments from the **Int Unpaid Billed** field value, until it reaches 0.00 (zero), after which Symitar Quest applies any further payments to the **Billed Fee Unpaid** field value and then to principal, even if there is additional accrued interest.
- When the system date has reached the balloon date, the Daily Posting batch program automatically sets this field value to **0**, the **Payment Type** field value to **(1) Level Principal**, and the **Payment** field value to the loan balance. This causes the entire loan balance plus all accrued interest to become due and payable on the balloon date.

Daily billed interest loans of this type must have the following fields set as specified:

• This field value must be set to 4.
• The Payment Type field value must be set to (0) Level Payment. This differs from other interest-only loans, which are set to (1) Level Principal.
• The Payment Frequency field value must be set to (4) Monthly.
• The Due Date Advance Code field value must be set to (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1.
• The DQ Calculation Method field value must be set to (1) Payment Buckets Are Calculated Monthly.
• The Balloon Date field value must be set to the loan’s due date. For example, if the loan’s due date is the 15th, the Balloon Date field value must also be set to the 15th. Since these loans are interest-only loans, there must be a balloon date.

Note: You must run Statement Cutoff Processing on a monthly basis for loans with this interest type, and you must run it for the statement group identified in the Loan record a minimum of 10 days before the loan’s due date. By regulation, you may need to run the program more than 10 days before the due date, but 10 days is the minimum to ensure that the statement can be generated and sent to the member before the loan payment is due.

5 (Actual/360)

Calculate daily interest on a 360-day basis. Symitar Quest calculates interest as follows: Interest Rate ÷ 360 x Loan Balance x number of days since the Interest Date.

6 (Daily Billed 360)

This interest type is valid only for interest-only loans. Use this interest type for loans where you bill to the member the amount of interest due at the time of statement cutoff. During Statement Cutoff Processing, Symitar Quest calculates daily interest as follows: Interest Rate ÷ 360 x Loan Balance x number of days since the Interest Date.

- Symitar Quest puts this amount of interest in the **Int Unpaid Billed** field.
- Symitar Quest puts this interest amount, less any delinquent interest amount, in the **Payment** field.
- Symitar Quest adjusts the **Payment Bucket** field values accordingly.
- Symitar Quest subtracts any interest payments from the **Int Unpaid Billed** field value, until it reaches 0.00 (zero), after which Symitar Quest applies any further payments to the **Billed Fee Unpaid** field value and then to principal, even if there is additional accrued interest.
- After the last standard payment has been received, if the due date matches the value in the **Balloon Date** field, the Daily Posting batch program automatically sets this field value to **5**, the **Payment Type** field value to **(1) Level Principal** and the **Payment** field value to the loan balance. However, if the last periodic payment is not received, then the Daily Posting batch program also automatically sets this field value to the **Payment Type** field value and the **Payment** field value to the loan balance when the system date matches the balloon date. This causes the entire loan balance plus all accrued interest to become due and payable on the balloon date.

Daily billed interest loans of this type must have the following fields set as specified:

• This field value must be set to 6.
• The Payment Type field value must be set to (0) Level Payment. This differs from other interest-only loans, which are set to (1) Level Principal.
• The Payment Frequency field value must be set to (4) Monthly.
• The Due Date Advance Code field value must be set to (0) Use Max Due Date Advance Period with the Max Due Date Advance Period field value set to 1.
• The DQ Calculation Method field value must be set to (1) Payment Buckets Are Calculated Monthly.
• The Balloon Date field value must be set to the loan’s due date. For example, if the loan’s due date is the 15th, the Balloon Date field value must also be set to the 15th. Since these loans are interest-only loans, there must be a balloon date.

Note: You must run Statement Cutoff Processing on a monthly basis for loans with this interest type, and you must run it for the statement group identified in the Loan record a minimum of 10 days before the loan’s due date. By regulation, you may need to run the program more than 10 days before the due date, but 10 days is the minimum to ensure that the statement can be generated and sent to the member before the loan payment is due.

7 (Actual/364)

Calculate daily interest on a 364-day basis as shown below:

Actual/364 day interest loans of this type must have the following set as specified:

• In the Interest Type Parameters, set the Interest Type Method parameter to (1) Actual/364 (364 Day).
• In the Late Charge Type Parameters, set a number in Late Charge Grace Days parameter.
• This field value must be set to 7.
• The Payment Frequency field value must be set to (8) Biweekly or (9) Weekly.
• The Payment Skips field value must be set to 0.
• The Due Day 1 field value must be left blank for weekly and biweekly.
• The Due Date Advance Code field value must be set to (0) Use Max Due Date Advance Period with the following:
  • The Max Due Date Advance Period field value set to 1.
  • The Initial BCD Setting Option field value set to (0) Use Current Cycle Date - 1 Period + 1 Day or (1) Use Loan Due Date (One when due).
• The New Loan Due Date Code field value must be set to (0) No Change.
• The Loan Code field value must be set to (0) Closed End.
• The Payment Calc Type field value must be set to (0) No Change.
• The DQ Calculation Method field value must be set to (0) Payment Buckets Only Contain Changes.

You must also install RD.LOANPROJECT PowerOn specfile to create the job file for transfers.

8 (Scheduled/364)

Calculate daily interest on a 364-day basis as shown below:

Scheduled/364 day interest loans of this type must have the following set as specified:

• In the Interest Type Parameters, set the Interest Type Method parameter to (1) Scheduled/364 (364 Day).
• In the Late Charge Type parameters, set a number in the Late Charge Grace Days.
• This field value must be set to 8.
• The Payment Frequency field value must be set to (8) Biweekly or (9) Weekly.
• The Payment Skips field value must be set to 0.
• The Due Day 1 field value must be blank for weekly and biweekly.
• The Due Date Advance Code field value must be set to (0) Use Max Due Date Advance Period with the following:
  • The Max Due Date Advance Period field value must be set to 1.
  • The Initial BCD Setting Option field value must be set to (0) Use Current Cycle Date - 1 Period + 1 Day or (1) Use Loan Due Date (One when due).
• The New Loan Due Date Code field value must be set to (0) No Change.
• The Loan Code field value must be set to (0) Closed End.
• The Payment Calc Type field value must be set to (0) No Change.
• The DQ Calculation Method field value must be set to (0) Payment Buckets Only Contain Changes.

You must also install RD.LOANPROJECT PowerOn specfile to create the job file for transfers.

9

This option does not display since it is reserved for future system use.

10–8999 (Credit Card Interest)

A credit union-defined interest type to calculate loan interest according to the parameters defined for that interest type. You can use this option for credit card loans only.

- You cannot enter a value 10–8999 in this field when a Loan Rate Change record exists under the loan. If you make such an entry, this error message appears:
    ```text

This Interest Type cannot be set when Rate Change record exists ``` - Check the specified interest type parameter fields CA, BT, and PU Interest Period Option to confirm the interest calculation. It will be defined in one of the following ways: - Select the (0) Monthly option to use the following formula to calculate interest: average daily balance x (interest rate/12) - Select the (1) Daily option to use the following formula to calculate interest: average daily balance x days in period x (interest rate/365) - Performing these calculations in Statement Cutoff Processing results in interest rounding to the nearest penny. Amounts in the range of $0.0000–0.0049 round down to $0.00. Amounts in the range of $0.0050-.0099 round up to $0.01.

Note: You can define interest calculations for up to 8990 different interest types (10-8999) in the Interest Type Parameters in the Parameter Manager. You must define the calculation for any interest type used at your financial institution except options 0–9. You must specify a defined interest type to proceed. If you specify an interest type you have not defined, this message appears:

Undefined Interest Type

9000–9999

Reserved for future system-defined use.

If you select an interest type of 0, 2, 3, 4, 6, 7, or 8, which are each calculated daily, Symitar Quest performs the interest calculation based on the rates currently available for that loan.

If you use the MBS Multiple Repayment Programs Per Loan module and have a Schedule record associated with this Loan record that is active, the value of this field is copied from the Schedule record.

If you select an option in the Payment Application Method field that uses a mortgage payment order (10-9999), and this field value is not set to 1 or 8, Symitar Quest sends an error.

Payment Application Methods parameters (2) Alternate Standard Method I and (3) Alternate Standard Method II do not apply to a Loan record when this field value is set to 1 or 8.

Note: Payment calculations by the Statement Cutoff Processing batch program, for loans with interest types 3, 4, or 6, may give unexpected results when you do not clear the Partial Payment field. To clear the Partial Payment field, create a job file to run the CLEAR.PARTIAL.PAY PowerOn specfile before running the Statement Cutoff Processing batch program. This non-library specfile and usage instructions are on the For Clients portal. Go to Products & Services>Symitar>Release Information>PowerOn Programs.

The Mortgage Investor Servicing (MIS) system calculates the interest amount for each monthly payment by using the following steps:

1. Calculate the monthly interest rate factor. Note rate / 12 + 0.0000000005 (rounding factor) Example: 07.250% / 12 + 0.0000000005 = 0.006041671666667
2. Calculate interest portion of the monthly payment. Interest rate factor x unpaid principal balance (UPB) + 0.005 (rounding factor) Example: 0.006041671666667 x $77,125.00 + 0.005 = 465.96

Interest Rate

This field stores the interest rate charged for the loan.

Enter the interest rate charged for the loan. Symitar Quest limits the rate to three digits after the decimal point. If you specify a value in the Interest Type field of 10-8999, Symitar Quest uses the rate specified for that interest type in the Interest Type Parameters.

Note: If the Loan Code field value is set to (6) LOC Combination, the Interest Rate field value applies to Segment 0, not the entire loan.

If you pull this value using the Pull Fields From App action field, Symitar Quest updates this field with the value from the Interest Rate field from the specified Application record. If you pull this value using the Loan Calc Screen action field, Symitar Quest updates this field with the value in the Interest Rate field of the loan calculation screen.

Interest Date

Symitar Quest stores the most recent date from which interest accrues in this field, which means interest has been calculated on this loan through the previous day (but not including today).

Any interest accrued but not collected as of the day before the value in this field is added to the amount in the Interest Unpaid field.

• If the loan’s Interest Type field value is set to 0 (Daily 365 Day), 2 (Daily 365.25), 3 (Daily Billed I), 4 (Daily Billed II), 5 (Actual/360), 6 (Daily Billed 360), or 7 (Actual/364), Symitar Quest sets this field to the effective date of any New Loan (LN), Loan Payment (LP), Loan Advance (LA), Loan Refinance (LR), or Loan Segment Transfer (LG) transaction.
• If the loan’s Interest Type field value is set to 1 (Monthly 360) or 8 (Scheduled 364), Symitar Quest sets this field to match the due date of the last fully satisfied payment. For example, if the loan’s due date is 08/01/2024, and you post a payment on 08/05/2024, that advances due date to 09/01/2024, this field is set to 08/01/2024, not 08/05/2024.
• If the loan’s Interest Type field value is set to 3 (Daily Billed I), 4 (Daily Billed II), 6 (Daily Billed 360), or10-8999 (Credit Card Interest), Statement Cutoff Processing sets this field to the value in the Statement Cutoff Date field + 1 day when it sets the loan’s payment amount. For credit card interest types, the Interest Date field value is not updated by transactions because interest is calculated and accrued only during Statement Cutoff Processing.
• For all loans except those with a value in the Interest Type field of 10-8999, Symitar Quest sets this field to the date of any rate change, whether the rate is set by Rate Change Processing (for immediate rate changes) or by Daily Posting (for scheduled future rate changes).
• If necessary, to prevent interest from accruing until a future date (as in the case of student loans), you can update this field manually.

Under normal circumstances, you should not revise this field.

Interest Unpaid

Symitar Quest stores the amount of unpaid interest due on the loan in this field as of the day before the loan’s Interest Date field value.

A Loan Payment (LP) transaction affects this field as follows:

• If the loan has an interest type of 0 (Daily 365 Day), 2 (Daily 365.25), 3 (Daily Billed I), 4 (Daily Billed II), 5 (Actual/360), 6 (Daily Billed 360), or 7 (Actual/364), Symitar Quest:
  • Calculates the interest that has accrued from the Interest Date field value through the day before the effective date of the payment
  • Adds the calculated amount to this field to determine the total interest due
  • Subtracts the amount of the loan payment applied to interest from the total interest due to determine the new value for this field Note: For loans with an interest type of 3, 4, and 6, the value of this field is always greater than $0.00 after a regular payment is received.
• If the loan has an interest type of 1 (Monthly 360) or 8 (Scheduled 364), the value in this field after a completed payment is always $0.00. Symitar Quest treats all payments to loans of this type as unapplied partial payments until a full or threshold payment is received. Because interest on these loans is calculated and collected per payment, it is impossible for a full payment to fail to satisfy all interest due.
• If the loan has an interest type of 10-8999 (Credit Card Interest), the value in this field is reduced by the amount of interest received until it reaches 0.00. Once the value in this field is $0.00, the system does not populate this field again until Statement Cutoff Processing runs.

A Loan Advance (LA) transaction affects this field as follows:

• If the loan has an interest type of 0 (Daily 365 Day), 2 (Daily 365.25), 3 (Daily Billed I), 4 (Daily Billed II), 5 (Actual/360), 6 (Daily Billed 360), or 7 (Actual/364), Symitar Quest adds the interest that has accrued from the Interest Date field value through the day before the effective date of the advance to the amount stored in this field to determine the new value of interest.
• If the loan has an interest type of 10-8999 (Credit Card Interest), the value in this field is unaffected by advances. The Statement Cutoff Processing batch program calculates all interest due for credit card loans.

Note: If the loan has an interest type of 1 or 8, you cannot perform an advance.

A Loan Refinance (LR) transaction always results in a value of $0.00 in this field because the transaction automatically adds any interest unpaid as of the date of the refinance to the principal balance of the loan.

A Loan Segment Transfer (LG) transaction calculates unpaid interest on all segments from the Interest Date field through the day before the effective date of the transfer and populates this field with the total interest due on all segments.

Rate changes, whether posted by Rate Change Processing (immediate rate changes) or with the Daily Posting batch program (scheduled future rate changes) updates this field by adding the amount of interest accrued from the last interest date through the day before the rate change takes effect. (Exception: Loans with interest types of 10-8999.)

The Statement Cutoff Processing batch program updates this field as follows:

• For loans with an interest type of 3 (Daily Billed I), 4 (Daily Billed II), and 6 (Daily Billed 360), Symitar Quest calculates interest accrued from the interest date through today and adds that amount to any existing amount in this field.
• For loans with an interest type of 10-8999 (Credit Card Interest), Symitar Quest calculates the finance charge from the interest date through today and adds that amount to this field. If the Statement Cutoff Processing batch program calculates a cash advance transaction finance charge for the loan, Symitar Quest adds the amount of that charge to this field.

For loans with a Loan Code field value of (6) LOC Combination, this field is the total amount of unpaid interest charged to all segments. Each segment has its own Interest Unpaid field that stores the interest due on that segment. Symitar Quest calculates the value of the Seg 0 Interest Unpaid field by subtracting the amounts in all other segment’s Interest Unpaid fields from the amount in this field. If you want to adjust the amount of interest due on Segment 0, you must manually add or subtract the difference to or from the value in that Interest Unpaid field. You cannot perform file maintenance on the Seg 0 Interest Unpaid field.

Under normal circumstances, you should not revise this field.

Int Unpaid Billed

Symitar Quest stores the total amount of unpaid interest in this field for which the member has been billed.

This field is only used for loans with an interest type of 3 (Daily Billed I), 4 (Daily Billed II), or 6 (Daily Billed 360). During Statement Cutoff Processing, Symitar Quest:

• Sets the Payment Type, Due Date Advance Code, Max Due Date Advance Period, and DQ Calculation Method fields to the appropriate values if they are not set properly
• Calculates the amount of interest due up through the cutoff date
• Adds this amount to any amount already in this field
• Sets the loan’s Interest Date field value to the statement cutoff effective date plus one day
• Sets the loan’s Payment field to the amount of the Int Unpaid Billed field value
• Rolls the existing payment buckets and sets the Pmt Bucket Amt 1 field value to this calculated field and the Pmt Bucket Due Date 1 field to the due date to which this payment amount applies

When a user performs a Loan Payment (LP) transaction on a loan with any of the daily billed interest types, Symitar Quest caps the amount of interest collected at the amount in this field. Any additional funds apply first to any amount in the Billed Fee Unpaid field and then to principal. Any interest that accrues between the cutoff date and the payment date is collected in the next billing cycle.

Although this field is not used for payment calculations on non-daily billed interest loans, any monetary adjustment to interest for any interest type updates this field. For example, if you perform a Void (VO) transaction on a loan with an interest type of 0, this field is populated with the amount of interest that was voided. Because this field has no effect on loans that do not use daily billed interest types, you do not need to manually correct this field.

For loans with a loan code of (6) LOC Combination, this field value is the total interest unpaid billed for all daily billed segments, including Segment 0. Each segment has its own Int Unpaid Billed field that stores the billed interest due on that segment if it has a daily billed interest type. Symitar Quest calculates the value of the Seg 0 Int Unpaid Billed field by subtracting the amounts in all other segments’ Int Unpaid Billed fields from the amount in this field. If you want to adjust the amount of billed interest due on Segment 0, you must manually add or subtract the difference to or from the value in that Int Unpaid Billed field. You cannot perform file maintenance on the Seg 0 Int Unpaid Billed field.

Under normal circumstances, you should not revise this field.

Interest Paid YTD

Symitar Quest stores the total of all interest paid on the loan in this field during the current year to date.

Whenever a Loan Payment (LP) teller transaction is posted to the loan, Symitar Quest adds the interest amount to the value in this field. The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the value in this field to the Interest Paid Last Year field and resets this field to 0.00.

For loans that have the Loan Code field set to (6) LOC Combination, this field is the total of all interest paid for all segments, including Segment 0, during the current year to date. If you or Symitar Quest performs file maintenance on the same field on an associated Segment record, Symitar Quest updates this field accordingly.

Under normal circumstances, you should not revise this field.

Interest Paid Last Year

Symitar Quest stores the total of all interest paid on the loan in this field during the previous year.

The first time you run the Close Day Processing batch program in a new calendar year, Symitar Quest transfers the amount in the Interest Paid YTD field to this field.

For loans that have the Loan Code field set to (6) LOC Combination, this field is the total interest paid for all segments last year, including Segment 0. If you or Symitar Quest performs file maintenance on the same field on an associated Segment record, Symitar Quest updates this field accordingly.

Under normal circumstances, you should not revise this field.

Interest From Open

Symitar Quest stores the total of all interest paid on the loan in this field since the loan was opened.

Whenever a Loan Payment (LP) teller transaction is posted to the loan, Symitar Quest adds the interest amount to the value in this field. The value in this field accumulates throughout the loan term.

Under normal circumstances, you should not revise this field.

Stmt Interest From Open

Symitar Quest stores the amount in the Interest From Open field at the time of statement cutoff.