Unique Loan ID
Q: What is Ginnie Mae's approach to the reuse of Unique Loan IDs in another pool; for example a loan leaving one pool and being repooled into another?
A: Each loan within a Ginnie Mae pool will have a Unique Loan ID. A Unique Loan ID for any given loan will not be reused in any other pool. APMs 08-02 and 09-13 define the application of the Unique Loan ID for all loans in Ginnie Mae systems, including the loan 'reuse' question.
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 Unique Loan ID (a unique identifier) that will be assigned by Ginnie Mae. This ID will be used by Ginnie Mae and by issuers to uniquely identify each loan in a Ginnie Mae pool.
Q: Will the Unique Loan ID be a new unique value or will these be based on existing case numbers?
A: The Unique Loan ID will be a newly generated number.
Issuer Testing
Q: Is Issuer Testing for RFS still occurring?
A: Ginnie Mae's Issuer Testing Periods 3 and 4 have completed with all current issuers. Any new issuers to Ginnie Mae are required to complete a "New Issuer Testing" process for these Ginnie Mae systems:
- GinnieNET - Please call 800-234-4662, option 1 to coordinate GinnieNET testing procedures
- Reporting and Feedback System (RFS) - Please review the RFS testing procedures.
Q: Which systems will Issuers use when they go live with RFS?
A: Starting July 1, 2009, Issuers that go live reporting RFS will be using the following systems:
- Ginnie Mae Enterprise Portal (GMEP)
- RFS Pool Accounting / Exception Feedback
- e-Access
- e-Notification
- Web IIS/SCRA
- Queries and Reports
- WHFIT Tax Reporting
- HRA (HMBS)
- GinnieNET
Starting October 1, 2009, ALL Issuers will be using the following systems:
- Ginnie Mae Enterprise Portal (GMEP)
- RFS Pool Accounting / Exception Feedback
- Web IIS/SCRA
- Queries and Reports
- e-Access
- e-Notification
- WHFIT Tax Reporting
- HRA (HMBS)
- GinnieNET
Q: How can we download our Pool Accounting exceptions?
A: To download your exceptions in the GMEP, follow these steps:
- Click on the "Exception Feedback" link on the RFS menu
- Click on "Download" on the Pool Accounting Exceptions menu bar
- Click on "Download Exceptions" on the Pool Accounting Exceptions menu bar
- Select All Exceptions for the type of file
- Click "Download"
- Right-click on the "Download Exceptions" link
- Left-click on "Save Target As"
- Type a new file ending with the letters ".csv" (example: Mar09exceptions.csv)
- Select a location in which to save the file and left-click the Save button
- Find the saved file and open it in MS Excel
Q: I am logged in to the GMEP with my Security Officer (S.O.) account. Why can't I see the RFS menu options?
A: GMEP Security Officer (S.O.) accounts do not have access to view the RFS menu options. You should create a user account, then log in with that user account.
Q: Will training be provided to issuers?
A: Yes, in addition to the online training that Ginnie Mae provided issuers in Spring 2009, Ginnie Mae will be providing additional training for Pool Accounting/Exception Feedback, SCRA, e-Notification, Matching/Suspense, and Issuer Feedback in Fall 2009. Look for specific announcements from Ginnie Mae. Also, the "RFS Training" section of the RFS web page provides the RFS training presentation from Spring 2009 in PDF format.
Q: Are issuers required to attend the RFS issuer training classes?
A: No. Attendance in training classes is optional.
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.
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 is the case number format for RMF loans?
A: When reporting the case number of RMF loans, the Issuer should report the case number formatting it with:
- Format is: Total of 15 character positions. 1st character is a zero followed by the case number which is made up of two digit state code, then three digit county code, and a nine digit number.
Q: After uploading an RFS file through the Portal, I received an email saying that my submission was accepted, yet there is no change to my reporting results. Why?
A: The email that you receive following the File Upload indicates that your file was received for processing in RFS. Your file is then processed by RFS, with results ("A" for Accepted, "R" for Rejected) displayed in the Portal under Exception Feedback/Download. These results are your file's Functional Acknowledgement (FA).
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: Report initial and correction Security RPB values to GinnieNET. RPB exceptions will be provided by the Central Paying and Transfer Agent ("CPTA") via e-Notification. The Security RPB should also be reported in RFS' monthly reporting, Pool Record, field 10. Also, please refer to APM 09-11, which provides an accelerated reporting timeframe for reporting Security RPB balances.
Q: Are the monthly reporting deadlines going to be changing under RFS?
A: Yes. Please refer to APM 09-11, which provides an accelerated reporting timeframe for the following:
- Reporting monthly Pool and Loan data elements in RFS record format
- Reporting Security RPB balances
Q: Once RFS is implemented, will issuers/service bureaus continue to transmit Security 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 directly to GinnieNET as well as within the Pool Activity (Pool record, field 10) 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 Unique Loan ID 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 includes web-based data entry capability for monthly Pool Accounting activity; this includes web entry for each of the fields in the Pool, Loan, Sensitive, and Various records of Section 7 of the Issuer Reporting Technical Specification.
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, which can be found in Section 7 of the IRTS.
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 the Issuer 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
|
Unique Loan ID
|
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 IRTS monthly reporting layout defines the pool number field, Pool ID (field 2 of the Pool Record), 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 Chapter 27, page 27-6 of the Ginnie Mae MBS Guide.
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. APM 09-11 provides the RFS "Go-Live" dates, which includes the Construction Loan Principal fields.
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 these "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 version 5.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; this should include any and all adjustments 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 RFS Loan Record 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: Why am I receiving these exception messages: E-NOTE500 and/or E-NOTE600?
A: E-NOTE500 is "Social Security Number/Tax ID must be specified" occurs when an SSN/TIN is not received when a corresponding First Name/Last Name is received (e.g. Field 7, SSN 1, is blank when Fields 8 and 9 have values).
E-NOTE600 is "Borrower Last Name/Company Name must be specified" occurs when a Last Name is not received when a corresponding SSN/TIN is received (e.g. Field 9, Last Name 1, is blank when Fields 7, SSN 1, has a value).
Similarly, these exceptions apply to borrowers 1 through 5 (in Fields 7 through 21 of the Sensitive Record).
Q: When are we required to submit the Sensitive Loan Record?
A: The following is the guidance from the IRTS regarding reporting of the Sensitive Loan Record:
- This loan level record contains "static" information and personally identifiable information (PII). It is typically not reported and is only reported if there is a change to the data or if there is a reporting exception message that requires correction of the data.
Q: When Sensitive Record 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 are we required to submit the Various Loan Record?
A: The following is the guidance from the IRTS regarding reporting of the Various Loan Record:
- This loan record contains various other "static" information related to the loan. It is typically not reported, and is only reported if there is a change to the data or if there is a reporting exception message that requires correction of the data.
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 "1-Regular", "2--Refinance", "3-Loss Mitigation", "4-Other"?
A: This field is used to record the borrower's reason for obtaining the loan. 1-Regular should be used to denote the purchase of a property. 2-Refinance should be used to denote the refinancing of an existing mortgage loan. 3-Loss Mitigation should be used to denote a loan subject to Loss Mitigation procedures. 4-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: Of the following fields in the Various Loan Record are any of them required? Loan Purpose, Living Units, Loan to Value, Debt Service Ratio and Credit Score.
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 at origination.
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".
 |
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: How does summarization occur?
A: Summarization occurs in the following ways:
- Single pool - Through the GMEP, an issuer can navigate to the pool and click "Summarize Pool" to summarize a single pool.
- All pools within a given Issuer ID - This will occur for any uploaded file (via GMEP or via SFTP) whose Summarization Flag in the Trailer Record is "Y".
- All pools for all Issuer IDs - A process beginning at 8 PM EST daily will summarize all pools for all Issuer IDs for that reporting month.
Note: Any time summarization occurs without sufficient supporting information (e.g. sufficient number of loans in a pool have not been reported at the time of summarization), an exception message of RFS997 is provided.
Q: What will happen if an Issuer forgets to set the Summarize Flag to "Y"? Will RFS "force" a summarization?
A: As summarization is a critical function of Pool Accounting, all pools for all issuer IDs will begin summarization at 8 PM EST beginning on the 2nd business day of the month. This process will occur at the same time each day.
 |
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 effect 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.
 |
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: Yes. 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, the date received, file size, the number of records contained in the file, and a status indicator (A for Accepted, R for Rejected).
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 higher priority exceptions can be easily distinguished from less critical exceptions. APM 09-11 provides the accelerated timeframes for reporting.
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 Unique Loan ID must be specified" and "RFS152 Ginnie Mae Unique Loan ID could not be found"?
A: RFS150 occurs when a Unique Loan ID is not provided. RFS152 occurs when a Unique Loan ID is provided but the system cannot find that Unique Loan ID in the database. These errors occur wherever a Unique Loan ID must be provided.
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, Loan, Severity, Code, Field , Value, Message, Expected, Rec Type and Updated. 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, RFS153, RFS165, RFS997, RFS998, 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 Unique Loan ID that belongs to another issuer.
RFS165 - The issuer submitted loan data for an MF pool, but the Unique Loan ID used is for a loan that is not an MF project loan.
RFS997 - The issuer receives this alert following summarization of pools within an Issuer ID when more than 10% of loans or pools are missing.
RFS998 - The issuer receives this alert when invalid Loan Activity (i.e. "E" level severity) is submitted to Ginnie Mae when valid Loan Activity for the loan already exists.
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 from a GMEP account that does not have authority to submit data for the issuer number in the submission file.
 |
If you have any additional questions about RFS, please e-mail Ginnie Mae's RFS Helpdesk.
|