Unique Loan ID
Q: When will our 'one-time' Loan Key files be available? Are these Loan Keys 'actual', or are they still the 'test' files?
A: The files for the One-Time Assignment of Unique Loan IDs were made available in e-Access as of May 19th, 2008. These files are those announced in APMs 08-02 and in 08-07, and are for loans reported to Ginnie Mae for the April 2008 reporting period. These are actual production Unique Loan IDs, and issuers should apply them to their systems of record.
Q: How do I access my loan key download files for our issuer numbers?
A: Loan Key Download files are accessible from Ginnie Mae’s e-Access. Per APM 08-07, issuers can access test files for test application of loan keys in their internal systems, as of April 1, 2008.
Q: Can the file posted in April to E-Notification containing the loan key data be used for production or is this a test file only?
A: There has been no change to APM 08-07, which states: "While the test file includes Unique Loan IDs for all loans active through February 2008, the test file is for testing purposes only."
Q: Will Ginnie Mae begin using a unique loan identifier in the reporting processes?
A: Yes. Under the BPI there will be implementation of a Ginnie Mae loan key (a unique identifier) that will be assigned by Ginnie Mae. This key will be used by Ginnie Mae and by issuers to uniquely identify each loan in a Ginnie Mae pool.
Q: How and when will issuers get the Ginnie Mae unique Loan IDs for existing portfolios?
A: As detailed in APM 08-02, Ginnie Mae will provide the Loan IDs to all issuers in May 2008:
- One-time assignment for the existing portfolio. These will be sent to each issuer in the form of a flat file. The APM has a link to the flat file layout to be used.
- Ongoing assignment for new originations. This will begin with May 2008 issuances, assigned through GinnieNET.
Q: Will the Loan Key be a new unique value or will these be based on existing case numbers?
A: The loan key will be a newly generated number.
Q: When, how, and in what format will issuers receive the newly assigned Ginnie Mae Loan Key?
A: In May 2008, Ginnie Mae will assign and distribute Loan IDs for the loans in each issuer's existing portfolio in a flat text file format. Ongoing assignment of Loan IDs for new loan originations will begin for May 2008 issuances through the GinnieNET system. For details please see APM 08-02 and the one-time loan key layout.
 |
Issuer Testing
Q: Will training be provided to issuers?
A: Yes, Ginnie Mae will provide training for all RFS modules. This web page provides the latest training timeframe announcement.
Q: Are issuers required to attend the RFS issuer training classes?
A: No. Attendance in training classes is optional.
Q: Will materials from the RFS training classes be available for download?
A: Yes, the presenter slides and associated presenter notes will be made available for download on GinnieNET and the RFS web page after September 30, 2008.
Q: During RFS Issuer Testing period, should issuers/service bureaus submit data files from their own test environments?
A: Issuers and service bureaus should prepare data for BPI/RFS test submissions from systems that have been modified to work in the BPI/RFS format. It is up to the issuer/service bureau to determine which data processing environment they will use to prepare test data for submission.
Q: During the Issuer Testing period, will issuers be required will report data to Ginnie Mae using both the existing reporting process and the new reporting process?
A: No. Today's MBS monthly reporting (existing reporting process) will continue without change throughout the entire RFS Issuer Testing period and until Ginnie Mae announces that issuers should report monthly reporting in accordance to its Business Process Improvement (BPI) plans. For RFS Issuer Testing (new reporting process), issuers must:
- Have applied the new Ginnie Mae loan keys to loans in their own systems
- Prepare and transmit data for the June 2008 (calendar month, August 2008) and July 2008 (calendar month, September 2008) reporting periods in the RFS format
- use of this data will be for RFS Issuer Testing only.
The RFS Issuer Testing Guide provides the details of RFS Issuer Testing.
Q: When will Ginnie Mae publish specific services for data transmission and detailed security requirements for RFS?
A: Version 3.0 of the IRTS and the RFS Issuer Testing Guide contain basic information regarding transmission methods and security requirements. Ginnie Mae is developing further guidance that complies with all applicable Government laws and regulations.
Q: Who should I contact if I have technical questions regarding the RFS implementation?
A: Please submit your technical questions to the Ginnie Mae RFS Helpdesk through this web address: http://www.ginniemae.gov/issuers/rfs_ques.asp?Section=Issuers. APM 08-02 requires that issuers designate an RFS Business Point of Contact and an RFS Technical Point of Contact by February 15th, 2008 at this web address: https://survey.deloitte.com/wsb.dll/1769/Ginnie_Mae_RFS_Issuer_Testing.htm.
Q: Will software vendors who are not service bureaus be required to sign an Interface e-Commerce Agreement with Ginnie Mae?
A: No. Only issuers are required to sign an Interface e-Commerce Agreement.
|
Reporting Questions
Q: What do Issuers/Service Bureaus need to do to use Secure Transfer File Protocol (sFTP)?
A: For files larger than 5MB, secure file transfer protocol (sFTP) must be used. Issuers should contact the Ginnie Security Administrator at 800-234-GNMA (4362) for instructions and a registration form to use this option.
For security purposes, the following checks will be applied during the process of submitting data:
- Must be ASCII-file
- Must comply with RFS file format specification
- Must pass anti-virus check
The user will be notified that the file has been successfully transferred. If the file is rejected, it will not be uploaded to RFS and the user will be notified with the reason for the rejection.
Issuers that currently use NDM to upload files will need to use sFTP. sFTP provides secure encryption between parties. NIST requires that all sensitive data be encrypted.
Q: Does RFS allow for "net" current month's installments collected?
A: RFS requires that issuers report interest adjustments and/or principal adjustments as explicit, signed, dollar amounts in the specified RFS data fields. Such information is not to be reported as "netted" into current month's installments collected.
Q: How should we report monthly Security RPBs?
A: There is also a change in the method used by Issuers to report monthly security RPBs. The consolidated monthly data stream to RFS will contain the monthly security RPBs. Issuers will no longer be required to report the RPBs directly to the Central Paying and Transfer Agent ("CPTA"). The CPTA will process the RPB reported through RFS. RPB exceptions will be provided by the CPTA via eNotification. Issuers will continue to submit RPB corrections through GinnieNET. RPB corrections should not be included on any RFS corrected submissions. The CPTA for Ginnie Mae will continue to be responsible for assisting Issuers with RPB exceptions.
Q: Are the monthly reporting deadlines going to be changing under RFS?
A: Yes. Under RFS, there will be changes to the reporting timeline such that the security RPB, the loan level data elements, and the pool level data elements will all be due on the 2nd business day, with adjustments/corrections relating to monetary data elements due by the 4th business day. Exception information will be provided on a similar schedule.
Q: Once RFS is implemented, will issuers/service bureaus continue to transmit RPBs to Ginnie Mae on the second business day of the month?
A: Yes, Issuers/Service Bureaus should report initial RPBs by the 2nd business day of the month. Issuers/Service Bureaus should report corrections to RPBs by the 4th business day of the month.
Q: Is Ginnie Mae planning to collect more borrower information under RFS than it collects under the current system?
A: Yes. Additional borrower information will be collected at Pooling, as part of the GinnieNET enhancements. Refer to APM 08-02 for the new GinnieNET Single Family and Multifamily file layouts. At the loan level, Ginnie Mae will collect co-borrower information. Currently, Ginnie Mae only collects information pertaining to one borrower. With the BPI, Ginnie Mae will collect information pertaining to up to five borrowers for each loan record, as applicable to the particular loan.
Q: Please define the following acronyms found in the RFS Issuer Reporting Technical Specification: FHA, FH1, FMF, RHS, RMF.
A: Below are the definitions:
FHA - FHA Single Family
FH1 - FHA Title 1 Manufactured Housing
FMF - FHA Multifamily
RHS - Rural Housing Service
RMF - RHS Multifamily
Q: What are the valid pool type codes for Multifamily and construction loan?
A: The valid pool type codes have not changed. These codes can be found in Chapter 1 of the MBS Guide.
Q: Currently, we are able to recover funds if there are excess monies from curtailments and payoffs at pool level. Under RFS, will we be able to recover from curtailments and payoffs within the pool even if the impacted loan does not have the available funds, but the pool does? How should this be reported under RFS?
A: Assuming that the principal is held back and not passed through and that there is no direct connection to a loan, then the issuer should report the amount recovered in the Pool Record through the "Net Adjust RPB" field.
Q: Once RFS is implemented, will Ginnie Mae derive RPBs from submitted loan level information?
A: No, Ginnie Mae will not derive RPBs. Instead, issuers/service bureaus should report initial RPBs within the Pool Activity (Pool and Loan data) submissions. Additionally, issuers/service bureaus should report RPB corrections via GinnieNET. RFS will perform Security RPB reconciliation on submitted loan, pool, and Security RPB values.
Q: Will the loan substitution process change under RFS?
A: Yes. Loan substitutions (per the MBS Guide 5500.3, Chapter 14) will be controlled by RFS. Issuers requesting loan substitutions will be required to contact the RFS Operations Group to coordinate the assignment of a Ginnie Mae loan key to the new loan.
Q: Is there a specific file format for the RFS monthly reporting?
A: Yes. For RFS reporting, Ginnie Mae is specifying a flat file, ASCII text format. Further information is in Sections 6 and 7 of the RFS Issuer Reporting Technical Specification (IRTS) document.
Q: Once RFS is implemented, will issuers have the option of reporting information by entering it directly into a web based application instead of submitting data files?
A: RFS will include web-based data entry capability for monthly Pool Accounting activity.
Q: When an issuer submits a data file containing corrected data to RFS, should the file contain all of the records sent within the original data file?
A: The issuer may submit one of the following to RFS:
- A data file containing all of the records
- A data file containing only the records that were corrected
Note: The data file format is the same regardless of which option is chosen. The data file must contain header and trailer records.
Q: Is there a method for retracting any Record type that is sent to Ginnie Mae in error?
A: RFS does not provide issuers functionality to retract a data file submission. However, issuers are able to correct data file submissions through two methods: a.) Submit a corrected data file or b.) Enter corrected values through the RFS user interface. For additional information on Exception Feedback Processing, see Sections 5 and 6 of the RFS Issuer Reporting Technical Specification.
Q: Will RFS accept a data file containing data for multiple issuers?
A: Yes, the file must contain 1 header record and 1 trailer record for each issuer number represented in the file. The file must be named according to the naming convention. The naming convention was updated in version 3 of the RFS IRTS to allow for a multiple issuer submission.
Q: Should issuers encrypt data files submitted to RFS?
A: Since issuers will transmit data files to RFS through one of two encrypted communication protocols (HTTPS and sFTP), it will not be necessary for issuers to encrypt data files.
Q: The RFS data submission file will contain various types of records (Header, Pool, Loan, etc.) each having a unique set of columns. The length of the longest record type is 401 characters. Does this mean that we should pad the length of the other record types? For more information, refer to Appendix A of the RFS Issuer Reporting Technical Specifications Document.
A: The upload file contains records of varying lengths (from 11 to 401) but the length of each record is predetermined by the type of information it contains. The record types are referred to as fixed length because the software is expecting values in specific positions on the record. It is not necessary to pad the record beyond the length specified by the record type. Data files containing records that do not meet the record lengths specified in the RFS Issuer Reporting Technical specification will be rejected.
Q: What are the original locations (either HUD forms or EDI files) of each of the data fields in the RFS Pool Record and Loan Record (as described in Reporting Technical Specifications Document Appendix E)?
A: See the "Remarks" column in the following tables:
P - Pool Record
|
Field #
|
Field Name
|
Start
|
End
|
Type
|
Length
|
Remarks
|
|
1
|
Record Type
|
1
|
1
|
Character
|
1
|
Constant P -
Pool
|
|
2
|
Pool Id
|
2
|
7
|
Character
|
6
|
Must be a valid
Ginnie Mae pool.
|
|
3
|
Adjust FIC
|
8
|
19
|
Numeric
|
12
|
99999999.99
Signed Field
11710A – Section 1C
|
|
4
|
Pool FIC
|
20
|
30
|
Numeric
|
11
|
99999999.99
11710A – Section 1D
|
|
5
|
Servicing Fee
|
31
|
41
|
Numeric
|
11
|
99999999.99
11710A – Section 1H
|
|
6
|
Weighted
Average Interest Rate
|
42
|
48
|
Numeric
|
7
|
99.9999
11710A – Section 1A D
|
|
7
|
Net Adjust RPB
|
49
|
62
|
Numeric
|
14
|
9999999999.99
Signed Field
11710A – Section 2D
|
|
8
|
Deferred GPM
Interest
|
63
|
73
|
Numeric
|
11
|
99999999.99
11710A – Section 2H
|
|
9
|
Serial Note
|
74
|
86
|
Numeric
|
13
|
9999999999.99
11710A – Section 3C
|
|
10
|
Security RPB
|
87
|
99
|
Numeric
|
13
|
9999999999.99 The reported security RPB for the reporting
period
11710A – Section 3D
|
|
11
|
T&I Escrow
Balance
|
100
|
111
|
Numeric
|
12
|
99999999.99
Signed Field
11710A – Section 5B1
|
|
12
|
P&I Fund
Balance
|
112
|
123
|
Numeric
|
12
|
99999999.99
Signed Field
11710A – Section 5B2
|
|
13
|
Other Balance
|
124
|
135
|
Numeric
|
12
|
99999999.99
Signed Field
11710A – Section 5B3
|
|
14
|
Replacement
Reserve Balance
|
136
|
146
|
Numeric
|
11
|
99999999.99
New field
|
|
15
|
Construction Loan Principal
Balance
|
147
|
158
|
Numeric
|
12
|
99999999.99
Signed Field
New field
|
|
16
|
P&I Account
Number
|
159
|
168
|
Character
|
10
|
11710A – Section 5A
|
|
17
|
P&I Bank
ID
|
169
|
177
|
Character
|
9
|
New field
|
|
18
|
T&I Account
Number
|
178
|
187
|
Character
|
10
|
11710A – Section 5A
|
|
19
|
T&I Bank
ID
|
188
|
196
|
Character
|
9
|
New field
|
|
20
|
Replacement
Reserve Account Number
|
197
|
206
|
Character
|
10
|
New field
|
|
21
|
Replacement
Reserve Bank ID
|
207
|
215
|
Character
|
9
|
New field
|
|
22
|
Construction Loan Principal
Account Number
|
216
|
225
|
Character
|
10
|
New field
|
|
23
|
Construction Loan Principal
Bank ID
|
226
|
234
|
Character
|
9
|
New field
|
|
24
|
Filler
|
235
|
246
|
Character
|
12
|
|
|
25
|
Filler
|
247
|
255
|
Character
|
9
|
|
Loan Record
|
Field #
|
Field Name
|
Start
|
End
|
Type
|
Length
|
Remarks
|
|
1
|
Record Type
|
1
|
1
|
Character
|
1
|
Constant L – Loan
|
|
2
|
Loan Key
|
2
|
10
|
Numeric
|
9
|
New
field
|
|
3
|
Pool Id
|
11
|
16
|
Character
|
6
|
Must be a valid Ginnie Mae
pool.
EDI file – REF*VI*
|
|
4
|
Loan Type
|
17
|
19
|
Character
|
3
|
FHA, FH1, FMF, RHS, RMF,
PIH, VAG, VAV
EDI file – RLT05
(modified)
|
|
5
|
Case Number
|
20
|
34
|
Character
|
15
|
EDI file – RLT02
|
|
6
|
Issuer Loan Id
|
35
|
54
|
Character
|
20
|
EDI file – RLT04
|
|
7
|
First Payment
Date
|
55
|
62
|
Date
|
8
|
MMDDYYYY
EDI file – DTP 564
|
|
8
|
Loan Maturity Date
|
63
|
70
|
Date
|
8
|
MMDDYYYY
EDI file – DTP 577
|
|
9
|
Loan Interest
Rate
|
71
|
77
|
Numeric
|
7
|
99.9999
EDI file – INT*C*
|
|
10
|
Loan OPB
|
78
|
90
|
Numeric
|
13
|
9999999999.99
EDI file – AMT*PZ*
|
|
11
|
Loan FIC
|
91
|
101
|
Numeric
|
11
|
99999999.99
EDI file – AMT*YE*
|
|
12
|
Last
Installment Paid Date
|
102
|
109
|
Date
|
8
|
MMDDYYYY
EDI file – DPT*731*D8*
|
|
13
|
In Foreclosure
Flag
|
110
|
110
|
Character
|
1
|
N or Y
(default N)
EDI file – YNQ*9M*
|
|
14
|
Delinquent
Interest
|
111
|
121
|
Numeric
|
11
|
99999999.99
New
field
which summarizes to 11710A – Section 1G
|
|
15
|
Delinquent
Principal
|
122
|
134
|
Numeric
|
13
|
9999999999.99
New
field
which summarizes to 11710A – Section 1G
|
|
16
|
Prepaid
Interest
|
135
|
145
|
Numeric
|
11
|
99999999.99
New
field
which summarizes to 11710A – Section 1F
|
|
17
|
Prepaid
Principal
|
146
|
158
|
Numeric
|
13
|
9999999999.99
New
field
which summarizes to 11710A – Section 1F
|
|
18
|
Install
Interest
|
159
|
169
|
Numeric
|
11
|
99999999.99
New
field
which summarizes to 11710A – Section 1B1
|
|
19
|
Install
Principal
|
170
|
182
|
Numeric
|
13
|
9999999999.99
New
field
which summarizes to 11710A – Section 1B1
|
|
20
|
Curtailment
|
183
|
195
|
Numeric
|
13
|
9999999999.99
New
field
which summarizes to 11710A – Section 1B2
|
|
21
|
Adjust Interest
|
196
|
207
|
Numeric
|
12
|
99999999.99
Signed Field
New
field
which summarizes to 11710A – Section 1C
|
|
22
|
Net Adjust UPB
|
208
|
221
|
Numeric
|
14
|
9999999999.99
Signed Field
New
field
which summarizes to 11710A – Section 1C
|
|
23
|
Loan UPB
|
222
|
235
|
Numeric
|
14
|
9999999999.99
Signed Field
EDI file – AMT*UB* or
11710E Principal Balance
|
|
24
|
Removal Date
|
236
|
243
|
Date
|
8
|
MMDDYYYY
11710E
Date Removed
|
|
25
|
Removal Reason
|
244
|
244
|
Numeric
|
1
|
1, 2, 3,
4, 5, 6
11710E
Reason for Removal
|
|
26
|
Liquidation
Interest Due
|
245
|
255
|
Numeric
|
11
|
99999999.99
11710E
Total Interest Due
|
|
27
|
Liquidation
Principal Remitted
|
256
|
268
|
Numeric
|
13
|
9999999999.99
11710E
Principal Remitted
|
|
28
|
Liquidation Principal
Balance
|
269
|
282
|
Numeric
|
14
|
9999999999.99
Signed
Field
11710E
Liquidated Balance
|
|
Pool Record
Q: Is there any change in the Ginnie Mae Pool Number format?
A: Not at the present time. However the monthly reporting layout defines the pool number field as "alphanumeric". The field size remains as length of six, and currently Ginnie Mae is continuing to use the six-digit pool numbers. However, to allow for more pool numbers within the current six-position pool number field, Ginnie Mae will, at some point in the future, transition to an alphanumeric pool number assignment, while maintaining the six-position field.
Q: When Ginnie Mae begins adding alpha characters to the Pool Number field, will they be assigned to the left of the number?
A: Ginnie Mae will publish information regarding the Pool ID format in the future.
Q: Will you be validating the Pool Record field #6 "Weighted Average Interest Rate" against the loan level data we submit?
A: The only validation checks to be performed on the Pool Record field #6 "Weighted Average Interest Rate" will be the exceptions (POOL200 - POOL204), listed on page 23 of the RFS Issuer Reporting Technical Specifications Document.
Q: Would you please confirm that all of the following fields are not signed fields?
- Pool FIC
- Servicing Fee
- Weighted Average Interest Rate
- Deferred GPM Interest
- Serial Note
A: Correct, these fields are unsigned.
Q: How should Net Adjust RPB (field #7 of the Pool Record layout) be calculated?
A: Net Adjust RPB is equivalent to Section 2 D. Other (+ or -) on the current HUD 11710-A form.
Q: Is the "Deferred GPM Interest" field of the P-Pool Record a required field (see page 21 of the RFS Issuer Reporting Technical Specifications Document)?
A: Deferred GPM Interest is a required field for Graduated Payment Mortgage (GPM) pools. Issuers are required to report deferred interest paid as principal for GPM pools. For more information, see pages 21 and 23 of the RFS Issuer Reporting Technical Specifications Document and page 27-6 of the Ginnie Mae MBS Guide, http://www.ginniemae.gov/guide/pdf/chap27.pdf.
Q: Does GNMA require that Replacement Reserve Funds be held in a separate custodial account so that the funds are not co-mingled with other funds, or is it okay to have the funds in the same custodial account as long as we track and report the balances separately?
A: Replacement Reserve funds shall follow Section 31-15(B) of the Ginnie Mae Guide 5500.3, Pool and Loan Servicing, Escrow Deposit Requirements, and be consistent with Section 16-5, Escrow Custodial Accounts.
Q: In the RFS Issuer Reporting Technical Specifications Document, please clarify the definition of Field #15 Construction Loan Principal Balance?
A: This is the amount of principal being held. Existing guidance is located on page 32-12 of the Ginnie Mae MBS Guide 5500.3, Rev. 1 Section 32-10(C). This section describes the handling of principal payments received during the construction phase that do not get disbursed to security holders. For more information see Chapter 32 of the MBS Guide.
Q: When will the new construction loan reporting requirements found in the RFS Issuer Reporting Technical Specifications Document (fields 15, 22, and 23) go into effect?
A: Construction loan reporting requirements are included in the RFS Issuer Reporting Technical Specification. Per APM 08-02, the implementation of the RFS "go-live" date is for the October 2008 reporting period. An APM with further construction loan details should be anticipated.
Q: Weren't the "Market Discount Fraction" and the "Original Issue Discount" fields at the end of the Pool Record?
A: Recent APM 08-11 regarding Widely Held Fixed Investment Trust (WHFIT) reporting mandates that Original Issue Discount (OID) and Market Discount Fraction (MDF) data elements are reported solely via Ginnie Mae's WHFIT application. These are no longer data elements in the IRTS monthly reporting file layout (Pool Record). They have been replaced in the IRTS file layout with Filler.
|
Loan Record
Q: We currently recover or pass through funds at the pool level on the 11710A. How will we recover or pass through funds (for payment reversals, etc) at the loan level?
A: RFS provides various "adjustment" fields:
- Pool Record
- Adjust FIC
- Net Adjust RPB
- Loan Record
- Adjust Interest
- Net Adjust UPB
Issuers may use these fields to report various scenarios. For detailed information on the use of these fields under various scenarios, please see the table labeled "Usage Scenarios for Field 21, Adjust Interest and Field 22, Net Adjust UPB" in the RFS Issuer Reporting Technical Specification document v3.0.
Q: Why are the tax and insurance balances not present in the Loan Record layout?
A: RFS will not require reporting tax and insurance balances at the loan level.
Q: Regarding field 21 of the Loan Record "Adjust Interest", how does Ginnie Mae calculate Curtailment Interest Adjustment?
A: Ginnie Mae does not calculate Curtailment Interest Adjustment. Issuers should report the net interest lost (or gained) for that loan due any and all adjustment reasons including: 1) Curtailment interest adjustment, 2) Reversal of an installment payment because the check bounced, 3) Corrections to mistakes made in prior reporting.
Q: In the new RFS export layout, if the loan is NOT liquidated, should the liquidation related fields be 0.00 or blank?
A: Fields 25-28 in the Loan Record are the numeric liquidation related fields and, in this example, should either be left blank or contain 0.00.
Q: Regarding the RFS Loan Record field #25 "Removal Reason", please define the valid value "3" (Foreclosure with Claim Payment).
A: Foreclosure with Claim Payment means the Loan was liquidated from the pool because insurance/guaranty funds were received from FHA, VA, RHS, or PIH. For more definitions of all liquidation reason codes see Appendix VI-04 of the MBS Guide.
|
Sensitive Record
Q: When sensitive information changes for a single loan, should we submit a single sensitive loan record for the loan that changed or should we submit sensitive loan records for all loans serviced?
A: When sensitive information changes for a single loan, submit a single sensitive loan record for the loan that changed.
Q: If the sensitive information changes for a loan having more than one property, should we submit a sensitive loan record for each property associated with the loan?
A: The rule will not change under RFS: issuers must report a single property address per loan. In the case where there are multiple buildings per property, the issuer should report the main property address. For example, if there is a loan for "Park Way Complex" project and this project has three buildings: Building A, Building B, and Building C, the issuer should report the address for "Parkway Complex" (the issuer should not report 3 separate addresses).
Q: The RFS Sensitive Loan Record contains fields that allow issuers to report the first name, last name, and social security number of five borrowers. Will Ginnie Mae require issuers to report this information for all borrowers on a loan?
A: Sensitive Loan records are used to report changes to loans. Issuers are only required to submit Sensitive Loan records to RFS when a change occurs to a loan at any time after the loan origination data has been submitted to GinnieNET. When such a change occurs to a loan, the issuer must report all of the borrower information for all of the borrowers (co-borrowers) on the loan.
|
Various Record
Q: When you are reporting on a new GNMA pool for the first month, are we to create a Sensitive or Various Loan Record? Technically, the information in the fields that would trigger an S or V loan record would have changed from the previous month, because there was no information reported the previous month due to this being the first month of reporting. However, we didn't know if you would want to see an S and V loan record on every new pool or not.
A: Sensitive or Various Loan records are used to report changes to loans. Issuers are only required to submit Sensitive or Various Loan records to RFS when a change occurs to a loan at any time after the loan origination data has been submitted to GinnieNET.
Q: Regarding the field "Loan Purpose" in the Various Loan Record, what are the definitions of the valid values "P-purchase", "R-Refinance", "O-Other"?
A: This field is used to record the borrower's reason for obtaining the loan. P-Purchase should be used to denote the purchase of a property. R-Refinance should be used to denote the refinancing of an existing mortgage loan. O-Other should be used to denote any reason besides (for example a loan used to pay for repairs/alterations to a property).
Q: Regarding the field "Loan Purpose" of the Various Loan Record, does GNMA expect us to report originated loans as "O-other"?
A: No. This field records the borrower's purpose for obtaining the loan.
Q: The RFS IRTS document states that the Various Loan Record field 10 - MIN has length of 18, a start position 31, and an end position of 50. Shouldn't the end position be 48 instead?
A: Yes, the start and end positions of the Various Loan Record fields 10, 11, and 12 have been changed in the latest RFS Issuer Reporting Technical Specification document.
Q: Of the following fields in the Various Loan Record are any of them required? Loan Purpose, Number of Living Units, Loan to Value, Previous Loss Mitigation Flag, Debt Service Ratio, Credit Score, and Buy Down Flag.
A: No, these are optional (they can be left blank). However, RFS will accept and store data reported in any of the fields. These fields allow issuers to report changes to data that was previously reported.
Q: What is the purpose of the Field #13 Down Payment Assistance Flag? Also what are the correct values for this field?
A: This field denotes whether the borrower received any assistance for the down payment. This refers to "gift funds" (cash) as generally described in FHA and VA regulations regarding gift funds. The field is required for all single family loans. Valid values for this field are either 1 or 2 where 1 means "Borrower received gift funds for down payment" and 2 means "No gift assistance". The table on Page 42 of the IRTS document v 4.0 contains a typographic error in the "Remarks" column for this field. Please ignore the text "N or Y" that appears in that column. The text should read "1 or 2".
|
Header/Trailer Record
Q: We do not intend to set the Summarization flag to 'Y' until the final RFS file submission on the 10th of the month. Will you please confirm that this is how the flag is to be used?
A: The Summarization flag in the Trailer record relates to reconciliation of Security RPB to issuer loan and pool reporting; this summarization/reconciliation must be finalized by close of business on the 4th business day of the month.
Q: What will happen if an Issuer forgets to set the Summarize Flag to "Y"? Will RFS "force" a summarization?
A: Currently there are no plans for RFS to "force" a summarization. If an issuer neglects to set the summarization flag to "Y", then RFS will not summarize the issuer's reported data. Issuers who register for web access to RFS will be able to use the summarization functionality available on the web to request summarization. This web function is available regardless of whether the issuer submits their data in bulk or through the web-based RFS data entry functionality.
|
Reporting Scenario Questions
Q: Let's say a payment was made but two days later it was reversed. The net effect on our collections is zero and the reversal is not a reversal of a prior month's activity. In this case would we report the receipt of payments in Field 18 and Field 19 of the Loan Record and report the reversal in Field 21 or 22 or would we report only zeros in all four fields?
A: The preferred method for reporting this scenario is to report zeros in all four fields. However, issuers have the option to report this scenario using either method.
Q: If there is a collection and reversal that occurs in the same period and the net affect is zero, do you want zero to be reported or do you want the detail collections and reversals regardless of the net affect?
A: Issuers may report this scenario (installment application and reversal in the same reporting period) in one of two ways:
1. Report current month installment in Loan Record fields 18 and 19; report Interest Adjustment from current month reversal in Loan Record field 21; report Net Adjust UPB from current month reversal in Loan Record field 22.
2. Report zeros in the Loan Record fields 18, 19, 21, and 22.
Q: If an issuer incorrectly reports a loan as liquidated, will RFS allow the issuer correct this situation?
A: The issuer can make this type of correction only during the same reporting period in which the loan was reported as being liquidated. This can be accomplished by submitting a corrected data file prior to the reporting cut-off date. In this case, the loan record field 24 - Removal Date must be reported as blank and other loan liquidation fields should reflect no liquidation values. Note: Ginnie Mae policy does not allow issuers to make this type of correction after the reporting period cut-off date.
Q: Does Ginnie Mae foresee a negative impact on field reviews stemming from the RFS implementation? For example, under the current process Ginnie Mae's field review auditors compare our 11710A facsimile to our collections report. Once we change our systems to work with RFS, the net collections listed on the 11710A will not match those of the collections report. This means that the auditors will need to take the collections on the 11710A plus/minus any adjustments and then tie to our collection report.
A: Ginnie Mae does not foresee a negative impact on field reviews that occur during the Comparison Testing period as issuers will continue to report information using the existing process and data formats. Once RFS is implemented, Ginnie Mae will provide guidance to issuers/document custodians of any changes to the field review process and will ensure that field review teams follow any compliance changes in their review procedures.
Q: Will the import file format for QTR_rmb.999 via WebIIS (used for SCRA import via e-Access) change under RFS?
A: No. There have been no file format changes in Web IIS. Any changes to the import file format for SCRA quarterly reimbursements in RFS will be announced at a later date.
|
Functional Acknowledgements
Q: Will issuers still be able to receive Functional Acknowledgements or the equivalent for monthly loan submissions?
A: Yes. RFS will provide the equivalent of the current Functional Acknowledgement. For more details, see Section 7 of the Issuer Reporting Technical Specification (IRTS).
Q: When an issuer submits a data file, will RFS provide a confirmation?
A: RFS generates a Functional Acknowledgement file for each submitted data file immediately upon receipt of a data file. The Functional Acknowledgement documents that a file was received and the number of records contained in the file. A file layout for the Functional Acknowledgement file is available in the RFS IRTS document v3.0.
Q: If the data passed validation and there are no exceptions to report, will GNMA send back anything? It would be nice to get the exception file with a header or trailer that says there are no exceptions. Is it feasible?
A: RFS will not provide a file documenting that no exceptions were generated. As a matter of policy Ginnie Mae will not take responsibility for ensuring that data files are delivered to issuers or for notifying issuers that files are ready. Issuers will be able to download Functional Acknowledgement Files and the Exception Files from RFS.
Q: When an issuer submits a data file containing data for multiple issuers, how many Exception files and Functional Acknowledgement files will RFS generate?
A: One Functional Acknowledgement file will be created for each data file submitted to RFS. If a data file submitted to RFS contains data for multiple issuers, one Functional Acknowledgement file will be created for each issuer number in the submitted file.
One Exception file will be created for each data file submitted to RFS. If a data file submitted to RFS contains data for multiple issuers, one Exception file will be created for each issuer number in the submitted file.
|
Exception Feedback
Q: Currently we receive notification from Ginnie Mae about RPB reporting "failed edit reports", separate loan level edit exception reports (Web IEDS), and separate pool errors exception information. Now that reporting of RPBs and Pool and Loan data will consist of one process under RFS, what will happen with exception notification?
A: Under RFS, exception feedback information for pool level and loan level reporting will be consolidated and presented to issuers as one integral set of exception information. However, issuers will continue to receive "failed edit reports".
Q: Under RFS, can we expect the exception feedback timing and format to remain the same?
A: No. The exception feedback timeline will be accelerated so updates or corrections can be made during the reporting period. The "severity level" ranking of exceptions is changing such that high priority exceptions can be easily distinguished from less critical exceptions.
Q: How long does it take for RFS to generate an Exception File once an issuer submits a data file?
A: RFS generates the Exception File for a submitted data file immediately after it finishes processing the submitted data file. RFS processes submitted data files continuously around the clock in a "first in, first out" fashion. Processing times vary depending on various factors including the number of data files in the queue and the size of the files in the queue. In most cases, the Exception File should be generated within one hour after a data file was submitted.
Q: Under what conditions will the following two error messages arise: "RFS150 Ginnie Mae Loan Key must be specified" and "RFS152 Ginnie Mae Loan Key could not be found"?
A: RFS150 occurs when a Loan Key is not provided. RFS152 occurs when a loan key is provided but the system cannot find that key in the database. These errors occur wherever a Loan Key must be provided.
Q: Under what conditions will the following error message arise: "RFS161 Ginnie Mae Loan Key must have liquidation reversed in the current reporting period."?
A: Once an RFS reporting period has closed, any loan liquidations reported in that period cannot be reversed. RFS161 will be generated if a liquidation reversal is attempted after the reporting period closed. (e.g. Loan liquidation reported in January reporting period; then in February reporting period, a loan liquidation reversal is attempted; RFS161 will be generated in the February reporting period).
Q: The RFS Issuer Reporting Specification describes an exception message called "RFS100 - Pool ID must be specified" which applies to both Pool records and Loan records. If our data submission generates this exception, how will we know whether the exception applies to the Pool or Loan record? Also, will we receive that exception more than once if the pool id is missing from both the pool and loan records?
A: Exception messages are accessible in one of two ways: the RFS web interface and the downloadable exceptions file. When using the web interface to view exception messages, a user selects an error message to see a list of the individual records (including record type) to which the exception applies. When viewing exception messages in the downloadable exceptions file, the user may use the following column headers to determine where the exception applies: Pool ID, Loan Key, Severity, Exception Code, Field Name, Value, Message, Expected Value. The RFS100 exception will appear once for every pool record that is missing a Pool ID value. The RFS100 exception will appear once for every loan record that is missing a Pool ID value.
Q: Can you provide more information about the various categories of RFS exception message identifiers. For example, are there specific exception messages that will only be generated by GNMA or that cannot be corrected by the Issuer? Examples of exceptions we are not sure how to determine are: RFS110, RFS 153, RFS160, RFS165, RFS999, and SEC055.
A: Yes, certain exception codes are only generated (and correctable) by Ginnie Mae. Below are descriptions of the exceptions codes:
RFS110 - The issuer no longer owns the pool, so it should not submit data for that pool.
RFS153 - The issuer submitted a loan with a loan key that belongs to another issuer.
RFS160 - The loan key submitted does not belong to the issuer.
RFS165 - The issuer submitted loan data for an MF pool, but the loan key used is for a loan that is not an MF project loan.
RFS999 - This does not require any action of the part of the issuer. This is an exception generated by the validation process that points to an internal RFS problem.
SEC055 - The issuer has submitted a submission file with an invalid issuer number in submission file name.
|
If you have any additional questions about RFS, please e-mail Ginnie Mae's RFS Helpdesk.
|
