Loan Electronic Reporting Interface-Redesign (LERI-R)

Business Requirements Document

April XXXX
 Table of Contents
1. Purpose 4
2. Overview 4
3. Scope 5
4. Customer and Primary Stakeholders 7
5. Goals/Objectives and Outcome Measures 7
6. Business Requirements 8
6.1. Themes, Epics (Needs), and User Narratives (Business Requirements) 8
6.2. User Access Levels 28
6.3. Known Interfaces and Data Sources 29
6.4. Related Projects or Work Efforts 30
7. Service Level Requirements 30
7.1. Availability 30
7.2. Capacity & Performance 31
8.3. Interfaces and Security 33
7.3. Assumptions 34
7.4. Dependencies 34
7.5. Constraints 35
7.6. Business Risks and Mitigation 35
Appendix A References 37
Document References: 37
Appendix D Enterprise Requirements 39
Appendix E User Interface/User Centered Design Principles 41
Appendix F Acronyms and Abbreviations 45
1. Purpose
The Business Requirements Document (BRD) is authored by the business community for the
purpose of capturing and describing the business needs of the customer/business owner. The
BRD provides insight into the AS-IS and TO-BE business areas, identifying stakeholders and
profiling primary and secondary user communities. It identifies what capabilities the
stakeholders and the target users need and why these needs exist, providing a focused overview
of the request requirements, constraints, and other considerations identified. This document is a
business case and does not mandate a development methodology, however the requirements are
written using agile methodology terminology. The intended audience for this document is the
Office of Information and Technology (OI&T) to facilitate project planning when the project is
approved and funded. These requirements are not documented at a level sufficient for
development.

2. Overview
The Department of Veterans Affairs (VA) Loan Guaranty (LGY) Service provides home loan benefits to
eligible Veterans obtaining mortgage loans through private lenders by guaranteeing a portion of the loan
against default. This allows Veterans to obtain mortgage loans at competitive rates with little or no down
payment. When a default occurs on these guaranteed loans, Veterans receive help in retaining their homes
and minimizing their financial losses through primary servicing performed by their servicers and
servicing by exception performed by VA. The Veterans Affairs Loan Electronic Reporting Interface
(VALERI) was conceptualized to enable Loan Administration (LA) to improve services to Veterans,
improve oversight capability over VA loan servicers, and reduce the cost to the Government for defaulted
loans. VALERI supports VA and LGY’s mission in helping Veterans and their families retain their homes.

VALERI is a web-enabled rules-based solution, designed to improve VA’s oversight capability and to
reduce the cost to the Government for the servicing and liquidation of VA-Guaranteed loans. It provides
an interface between VA and the mortgage servicing community, allowing mortgage servicers to report
significant event updates to VA focusing on default, loss mitigation, foreclosure, and claim payments.
The current VALERI system provides both a web-interface and an integration component to allow
automated loading of updates from VA mortgage servicers. The web-interface allows VAs technicians to
manage VA loans and evaluate servicer performance, allowing VA to intervene on the Veteran’s behalf,
when necessary. Implementation of VALERI began February 20, 2008. Since November 2008, all
servicers and all VA-Guaranteed loans have been managed through the VALERI environment. Currently,
VALERI assists VA in managing over 2.02 million active and 2.05 million inactive VA loans (inactive
loans are defined as 425 calendar days following the termination of a VA loan). By Fiscal Year (FY)
2019, VA anticipates managing 2.7 million active and 10 million inactive loans.

VALERI is able to accomplish VA’s mission of providing improved service to Veterans by:

● Providing Veterans assistance earlier in the default

● Maximizing loss mitigation
● Standardizing organizational structure
● Providing total case management
● Conducting post-audits of servicer actions to ensure compliance
● Offering detailed reports on performance data
 ● Offering standardized and recurring employee training; and
● Providing data on all outstanding VA-Guaranteed loans

VA does not own the source code or have any rights to the existing VALERI system, and is interested in
replicating the functionality in-house and enhancing the system so that it better serves the needs of VA
employees, loan servicers, and veterans. Beyond this, VA also wants to achieve concrete organizational
goals by replatforming VALERI by incorporating new technological capabilities into VA’s loan servicing
process and taking advantage of any opportunities to innovate how VA interfaces with its loan servicers.

VALERI, as envisioned here, consists of several capabilities that are each critical to supporting VA’s
needs. VA requires a portal for loan servicers to monitor their VA loan portfolios and to report loan
events to VA. VA also requires a data aggregation capability and service to combine automated data feeds
from thousands of individual loan servicers and to outsource the maintenance of data connections from
VA staff. VA also requires a loan management/case management/customer relationship management
application where VA staff can perform various actions related to addressing delinquent loans and also
monitoring the activities of loan servicers. Additionally, VA requires VALERI to integrate with the
Financial Management System, FMS, so it can pay claims, issue BOCs, etc. VA requires the ability to
take the data generated by these various input methods and use it to automate various loan processes.
Lastly, VA requires the ability to aggregate all the data produced from these various components and use
it to drive a business intelligence capability to support VA operational and reporting needs.

3. Scope
As described above, VA’s need for VALERI encompasses multiple capabilities, including
systems/solutions and services. The below adds detail to the capabilities briefly described
above in the overview:

Servicer Portal
VA requires an internet-accessible portal where loan servicers can take self-service
actions associated with the VA home loans they manage. This includes the ability to
submit loan information (loan events, claims associated with loans, etc.) in both bulk and
transactionally for single loans. Servicers must also be able to look up individual loans,
their status and generate reports on their entire loan portfolios. Additionally, they must be
able to upload documentation to the system in support of their loan. Data input into the
servicer portal must be integrated with the other components of VALERI to enable
automated processing of some loan functions and business intelligence reporting, as well
as access to the data in other LGY systems and VALERI components.
Data Aggregation Services
VA requires a service provider to manage its interconnections with the thousands of VA
loan servicers. This aggregator will maintain connections with the servicers and bundle
data provided by them into a single, consolidated data stream for VA. This includes
administratively managing the interconnections and ensuring documentation of each
connection exists. While the data will belong to the VA, the data aggregator service
provider will play an essential role in managing the data and how it is shared. This
 contractor will also facilitate limited administrative processes associated with VA home
loans for loan servicers, such as training them on the servicer portal.
Case management /loan management portal for LGY staff
VA requires an internal application/portal to allow for loan management activities to be
conducted in support of managing the delinquency process for VA home loans. When a
VA home loan goes into delinquency, VA staff review actions taken by the loan servicer,
including contacts/notifications to Veteran homeowners and may also contact the
homeowners directly. This application/portal must also allow staff to review and approve
payments to loan servicers and adjudicate claims made by the servicers. For all of this
work, the internal portal must include workflow and work queue capabilities to ensure
efficient routing of home loans to LGY staff. This portal must also interface with
appropriate VA systems such as FMS, CPTS, WebLGY to allow payments and bills to be
made to loan servicers and provide VA REO department information of an acquired
property.
Shared database and shared document repository
VA requires that all of the VALERI components/capabilities utilize a shared database and
document repository so information may be shared between the components quickly and
efficiently and so business intelligence activities can be performed on the data. The
database must include audit trails for transactions made. A shared document repository is
also required and access to various documents must be able to be limited/filter via
security settings and other metadata.
Transition Activities
VA requires all of these capabilities be enabled through a careful transition from the
existing VALERI to ensure VA’s Loan Guaranty Service can maintain operations
throughout the entire transition period and that no negative impacts occur for servicers or
for Veterans.
Reporting, Analytics, and Business Intelligence
VA requires a shared data repository that will enable business intelligence solution to
generate predefined reports . This will allow VA to use information to satisfy operational
needs and strategic analyses.
VA requires the ability to enable a risk-based oversight environment that will determine
stakeholder performance evaluation; align processes to strategic goals; insight into benefit
delivery; identify deficiencies so that remedial action can be taken; Reduce risk to program
integrity by having greater awareness overall performance; respond to internal and external
inquiries and increased ability to reconcile data; ability to perform analysis on multiple disparate
sources of data; and Enable an automated underwriting environment.
4. Customer and Primary Stakeholders
Randy Cope, Assistant Director for Program Management and Data Integration, representing the
Veterans Benefits Administration’s Loan Guaranty Service is the primary stakeholder for this
request. Review Appendix C for the complete list of primary and secondary stakeholders.

5. Goals/Objectives and Outcome Measures

Goal/Objective and Impact/Benefit Measurement

Desired Outcome
Address VALERI contractual Allows continued LGY Binary measure – was the
issues and successfully create operations. solution created and does it
in-house VA solutions for Addresses security concerns eliminate the
needed VALERI capabilities. regarding liquidated damages. security/contractual
considerations associated with
liquidated damages?
Update VALERI and update Improves service to the Veteran LGY leadership and loan servicer
relationships with servicers to and keeps more Veterans in their leadership satisfaction with
account for the homes. measured before and after
progress/evolution of the loan Allows LGY to more effectively project on relationships with
servicing industry and more use resources. servicers.
modern technology. Percentage of business
Improves relationships with loan
servicers. processes that can be performed
automatically as opposed to
pre-project.
Time and motion study of LGY
staff to see if new solutions allow
more efficient operations.
Preserve the core functionality Ensures continued, efficient Percentage completion of
of VALERI and ensure LGY business operations for LGY. requirements listed in the BRD.
staff does not lose critical Time and motion studies of LGY
features. staff efficiency for various tasks
before and after to ensure the
solution(s) created don’t just
satisfy the functionality, but
optimize it.
Improve handling of loan Service to Veteran homeowners. Percentage of Veterans who
deficiencies; keep more could successfully be kept in
Veterans in their homes by their houses under the existing
gathering richer data from VALERI system and under the
servicers and using automation new one and an analysis to see if
to speed outcomes. the software had any effect on
these rates.
Ensuring a successful transition LGY business operations. LGY performance metrics before
from the existing solution to the the transition and post-transition
new VALERI capability. for the first few quarters of new
system operation.
6. Business Requirements
6.1. Themes, Epics (Needs), and User Narratives
(Business Requirements)
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
BN 1: Adhere to the Enterprise Level requirements within the Enterprise Requirements Repository (ERR) and as
specifically addressed in Appendix D of this document.
BN 2: The system shall have an electronic portal that allows users employed by a loan servicer to take self-service
actions.
2.1 The system shall allow for servicers to access the self-service portal High
accessible on the public internet.
2.1.1 The system shall adhere to VA Handbook 6500 requirements (and other
documents referenced within VA Handbook 6500) for all security
requirements. Any security requirements within VA Handbook 6500 that
may be defined by the project shall be elaborated in subsequent
Requirements Specification Documents (RSDs).
2.1.2 The system shall interface with the Identity and Access Management
Access Services suite of services and applications for all access-related
functions, to include authentication, authorization and user provisioning.
2.1.3 The system shall allow VA to define specific loan servicing companies
(hereafter “servicers”) and associate groups of loans and groups of users
to the servicers.
2.1.4 The system shall allow for servicers to create users for their respective
companies.
2.1.4.1 The system shall restrict user access to loan information to only loans
associated with a user’s particular servicer.
2.2 The system shall have a persistent navigation pane or location within the
user interface that allows a user to access key defined functions at any
time they are logged into the portal.
2.2.1 These key defined functions may include but are not limited to: “search
for a loan,” “upload documents,” “submit appeals and claims,” etc., and
shall be defined by VA in subsequent requirements specifications
documents.
2.3 The system shall allow for a user to search for their assigned loans based
on a variety of loan characteristics and view loan information.
2.4 The system shall return similar match results related to a search, and not
restrict results to exact matches.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
2.4.1 The system shall allow for a VA employee to search using the following
characteristics:
• VA Loan Number
• Servicer Loan Number
• Borrower Name
• Property Address
• Loan Origination Date
2.4.2 The system shall allow for a servicer to search using the following
characteristics:
• VA Loan Number
• Servicer Loan Number
• Borrower Name
• Property Address
• Loan Origination Date
2.4.3 The system shall allow a user to filter the search results by the following
criteria:
• Filter by Region
• Filter by Status
2.5 The system shall allow a user to view specific administrative details
regarding a loan and its related reported loan events.
2.5.1 The system shall allow a user to filter or view the loan events by date or
status.
2.5.2 The system shall allow a user to click the loan event for more detail.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
2.5.2.1 The system shall allow a user to view loan servicing related information
on a loan, including but not limited to:
• VA Loan Number
• Servicer Loan Number
• Servicer Name
• Guaranty Date
• Guaranty Status
• Guaranty Amount
• Original Guaranty Percentage
• Current Guaranty Percentage
• Loan Term
• Loan Amount
• Loan Type
• Loan Modifications
• Indemnified Loan
• Interest Rate
• Origination Date
• Termination Date
• Borrower Name
• Property Address
• Net Value
• NOV Issue
• NOV Expiration
• UPB
• P&I Amount
• T&I Amount
• Other Payments
• Refinance Type
• Post Audit Technician
• Assigned Technician
• Case Notes (currently only available to VA users)
• Payment History (to include bills of collection)
2.5.3 The system shall present the user with the status of forms (documents)
submitted through the portal that will either take action or record
information about a loan.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
2.5.3.1 Forms can be in one of five types of status:
• Pending
o This event has yet to be processed.
• Unprocessed
o This event was withdrawn or cancelled before it was
processed.
• Accepted
o This event has been accepted with no errors.
• Accepted with Errors
o This event has been accepted, but with at least one
failed business rule.
• Rejected
o This event was not accepted by VALERI because the
event failed at least one fatal business rule.
2.6 The system shall allow the user to submit various forms either taking
action on or recording information about a loan within the servicer
portal.
2.6.1 The system shall validate form data entered by users and shall clearly
indicate to the user if data entered does not match the formatting or
allowable data types.
2.6.1.1 The system shall prevent the user from submitting until the data is
corrected.
2.6.2 Once a form is submitted, the system shall store the data in its database
and/or send it to business rules for automated processing as appropriate
for the form type.
2.6.3 The system shall notify the user when form information is successfully
saved or if an error occurred and data could not be saved.
2.6.4 The system shall allow the user to upload attachments (to include
multiple document types) in support of a form to a document repository
created for each loan.
2.6.4.1 The system shall require users to select specific document types
associated with the attachment.
2.6.4.2 The system shall require users to enter metadata (specific either to the
document or form type) when attaching a document.
2.6.4.3 The system shall perform a virus scan of all documents uploaded prior to
storage in VA systems.
2.6.4.4 The system shall notify the user if a document was successfully stored or
if an error occurred.
2.6.4.4.1 The system shall log every error and exception encountered and provide
the user a tool to view the errors and exceptions.
2.6.4.5 The system shall allow users to view documents they have uploaded (or
that all servicer users have uploaded) in the web portal after the
document has successfully submitted and shall follow document load
times and screen load times established in the forthcoming service level
agreement (SLA).
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
2.6.4.5.1 The system shall allow servicers to view documents a VA user has
uploaded in the web portal pertaining to a loan.
2.6.4.6 The system shall store all attachments in the database/system repository
or record for VBA/Loan Guaranty Data.
2.6.5 The system shall allow the various types of forms to be submitted,
including but not limited to, loan events, appeals, and claims.
2.6.6 The system shall allow the user to submit forms manually.
2.6.6.1 The system shall present the user with a case specific list of forms that
can be manually submitted for a loan when the user is looking at the
detailed loan information in the portal.
2.6.6.2 The system shall allow the user to click on a link to allow entry of form
information when showing the user the list of forms that can be manually
submitted.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
2.6.6.3 The system shall allow the user to submit forms for the following loan
events by manually entering data, including but not limited to:
● Monthly Loan Status Update
● Loan Paid In Full
● Transfer of Ownership
● Release of Liability
● Partial Release of Security
● Loss Mitigation Letter Sent
● Electronic Default Notification
● Foreclosure Attorney Contact Information
● Foreclosure Referral
● Foreclosure Sale Scheduled
● Results of Sale
● Transfer of Custody
● Improper Transfer of Custody
● Invalid Sale Results
● Confirmed Sale Date with No Transfer
● File a Claim
● File a Supplemental Claim (after a claim is filed)
● Refund Settlement
● Bulk Event Upload
● Delinquency Status
● Servicing Transfer - Transferring Servicer
● Servicing Transfer - Receiving Servicer
● Contact Information Change
● Occupancy Status Change
● Partial Payment Returned
● Default Reported to Credit Bureau
● Default Cured/Loan Reinstated
● Repayment Plan Approved
● Special Forbearance Approved
● Loan Modification Approved
● Loan Modification Complete
● Compromise Sale Complete
● Deed-In-Lieu Complete
● Bankruptcy Filed
● Bankruptcy Update
2.6.6.4 The system shall assist the user by auto-completing any form fields
possible (as defined in further requirements) based upon a user’s initial
keystrokes.
2.6.7 The system shall allow the user to bulk upload or submit forms by
uploading files that contain multiple forms.
2.6.7.1 The system shall allow users to include forms for more than one loan at a
time in these files.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
2.6.7.2 An example list of forms that can be submitted is included in Attachment
A.
2.6.7.3 The forms for loan events that can be submitted via the VALERI
servicing events import spreadsheet are included in Addendum 1
2.6.7.4 The system shall validate all of the forms submitted in the file uploaded
by the user.
2.6.7.4.1 The system shall reject files where the data types, lengths or other
information does not match standards established for that information or
existing files.
2.6.7.4.2 The system shall notify the user if uploaded files either fail validation or
are successful.
2.6.8 After form validation, the system shall immediately store form data in
the database/system of record for Loan Guaranty/VBA.
2.6.9 The system shall initiate any required post-processing for form data,
including rules-based processing to be defined in later business needs
within this BRD.
2.6.9 The system shall initiate any required post-processing for form data,
including rules-based processing to be defined in later business needs
within this BRD.

BN 3: The system shall allow designated users employed by VA to take administrative actions on delinquent loans.

3.1 The system shall allow VA employees to access the system within the
VA internet including users connected to the intranet via Virtual Private
Network (VPN) connection or through the Citrix Access Gateway
(CAG).
3.1.1 The system shall adhere to VA Handbook 6500 requirements (and other
documents referenced within VA Handbook 6500) for all security
requirements. Any security requirements within VA Handbook 6500 that
may be defined by the project shall be elaborated by Loan Guaranty
Service in subsequent Requirements Specification Documents (RSDs).
3.1.2 The system shall interface with the Identity and Access Management
Access Services suite of services and applications for all access-related
functions, to include authentication, authorization and user provisioning
(including workflows to request assignment of user roles, functions, etc.
to route business requests to Information Security Officers (ISO) for
approval).*
3.1.2.1 At a minimum, the system shall allow users to authenticate using their
personal identification verification (PIV) cards and associated security
certificates.
3.1.3 The system shall limit access to certain functions in the loan
management portal based upon the user role(s) and functions assigned to
a user.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.1.3.1 The following roles shall be available to Loan Administration
employees:
• Read Only High (ROH)
• Central Office Servicer Liaison (COSL)
• Central Office Loan Manager (COLM)• Assistant Loan
Technicians (ALT)
• Loan Technician (LT)
• Senior Loan Technician (SLT)
• Servicing Officer (SO)
• Loan Administration Officer (LAOs)
3.1.3.2 The system shall allow for attribute-based access controls to be assigned
to individual users.
3.1.4 When a user logs into the portal, the system shall authenticate the user’s
credentials and take the user to the VALERI Main menu screen where
applications are listed depending on the user’s defined role.
3.1.5 At a minimum, users shall have access based on a user’s role to links to a
predefined set of applications, such as:
• Loan Management & Work Queue – This is where users may
complete assigned tasks and manage their workload.
• Reports – this is where Servicing Officers (SOs) and Loan
Administration Officers (LAOs) can access servicer operational and
Loan Administration reports.
• Servicer Web Portal – this is where authorized servicers, along
with the following VA employees can access information seen by loan
servicers:
o Senior Loan Technicians (SLTs)
o Servicing Officers (SOs)
o Loan Administration Officers (LAOs)

3.1.5.1 The system shall allow access to the Servicer Web Portal for Assistant
Loan Technicians and Loan Technicians on an authorized case-by-case
basis.
3.1.6 The system shall allow for the creation, edit and deletion of loan
servicing companies and loan servicer users from the servicer portal in
the VALERI application and reflect these changes in the Stakeholder
Information Management (SIM) application.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.1.6.1 The system shall allow a Loan Administration supervisor to request or
update accounts for a new loan servicer user in the system by providing
or selecting the following information:
• Company
• Whether the account shall be locked
• Whether the user is a GSM Admin
• Whether the account shall be available for password resets
• Whether the user is a Company Admin
• Office
• Roles

3.1.6.2 The system shall integrate with the LGY Stakeholder Information
Management (SIM) system to add new servicers.
3.2 The system shall provide users with a work queue and with access to
various loan management functions.
3.2.1 The work queue and loan management interface shall have a persistent
navigation toolbar or location within the user interface in the work queue
that allows a user to access key defined functions at any time they are
logged into the portal.
3.2.2 The persistent work queue navigation pane shall provide users the
following options at a minimum:
• A link to return the user to the Loan Management & Work
Queue Homepage.
• A link to return to the previous screen the user was on.
• A search toolbar that allows a user to search for a loan based on
specified criteria set by the user.
• A link to enable users to access payment history reports.
• A link that shall enable a user to log out from the VALERI
application.
• A link to return a user to the VALERI Main Menu screen.
3.2.3 After a user logs in, the system shall display any announcements that
have been issued to users on the general loan management interface.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.2.4 On the Loan Management & Work Queue Homepage, the system shall
display the following options for a user to select:
• A link to allow a user to access tasks assigned to them. This
link shall allow a user to access a queue made up of tasks that they have
assigned to themselves or have been assigned to them by another user
regarding loans that are currently assigned to them. It is a work
management tool for follow-up action.
• A link to a user’s Workbasket (applicable to Assistant Loan
Technician (ALT) and Loan Technicians (LT). This location allows a
user who completes work processes to view all loan processes assigned
to them.
• A link to view approval /certification processes assigned to their
approval workgroup (applicable only to, Senior Loan Technicians
(SLTs), Servicing Officers (SOs), and Loan Administration Officers
(LAOs)), or other designated role or attribute based control.
3.2.5 When a user selects to view their Work Queue, the system shall allow for
them to view pending tasks in the delinquent loan servicing process for a
specific loan assigned to them.
3.2.5.1 The workbasket shall display the cases requiring action. The columns
include but are not limited to:
• Loan Number
• Funding Fee Exempt
• Process Name
o Indicates the type of action a user needs to take.
• Step Name
o Indicates the specific action a user needs to take.
• Due Date
• RLC
• Technician Name
• Servicer Number
• Servicer Name
3.2.5.2 The system shall allow a user to sort their Work Queue by any of the
above criteria by selecting the respective column heading.
3.2.5.3 The system shall default a user’s Work Queue to prioritize the process
steps in the descending order of earliest due date.
3.2.5.4 The system shall allow a user to apply filters against the process step
parameters so that he/she can view and access cases that fall into a
specified criteria.
3.2.5.4.1 The system shall allow a user to save a filter for later use.
3.2.5.4.2 The system shall allow a user to delete any saved filters.
3.3 After a servicer automatically or manually reports that a loan is
delinquent for 61 days through the Electronic Default Notification
(EDN), the system shall automatically assign the case to the next
available Loan Technician’s work queue through a balanced assignment
process nationwide.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.3.1 The system shall automatically review the number of cases that each
Assistant Loan Technician and Loan Technician has been assigned.
3.3.2 The system shall automatically assign the case to the next available
technician with the least number of cases.
3.3.3 The system shall assign all processes associated with that loan from the
default notification through the claim payment, including appeals and
supplements OR through reinstatement of the default to the same Loan
Technician.
3.3.4 The system shall assign loans that have been in default and ensure that
loans requiring Post Audit are assigned to different users than those who
initially worked on them.
3.4 The system shall allow a user to access and view a process assigned to
them by selecting the loan from their Work Queue.
3.4.1 Once a loan is selected, the system shall display general information on
the loan along with steps that a user must complete for the selected
process.
3.4.2 For the step that needs to be completed for the selected task, the system
shall display the following information, including but not limited to:
• A description of the process step
• The number of days a user has to complete each step in the
entire process
• The original due date
3.4.3 If the loan has more than one process, the system shall default to show
the user the process that is closest to being due or the process that is most
overdue.
3.4.4 The system shall allow a user view all of the processes on a loan by
selecting View All.
3.4.4.1 The system will display a link to allow a user to access the Manual
Process Utility function to transfer in a process. This is an important
functionality for a user that would like to complete a process on a loan,
but has not been automatically assigned the process by the system.
3.4.5 The system shall filter processes by business area.
3.4.6 The system shall display the following business areas, at a minimum:
• Acquisition
• Claim
• Finance
• Loss Mitigation
• Oversight
3.5 The system shall route loans and processes through a workflow process
where the completion of one process step triggers the initiation of
another step or another process.
3.5.1 The system shall accept that a user has completed a process when they
enter a date of completion for a specific loan process, or take other
actions substantiating completion.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.5.1.1 The system shall, in warranted cases, auto-populate dates based on the
validated completion of a step.
3.5.2 Once a Completed date has been entered, or other action taken the
system shall generate the next step in the appropriate Work Queue.
3.5.4 The system shall allow some workflow actions to be routed for multiple
levels of review and approval by different user groups. The review and
approval level shall be end-user configurable in the system.
3.5.4.1 A user assigned a role that requires additional approval on certain
processes (Assistant Loan Technicians (ALT) or Loan Technicians (LT))
shall have that specific work routed to appropriate approval workbaskets
in VALERI.
3.5.4.1.1 Senior Loan Technicians (SLT), Servicing Officers (SO) and Loan
Administration Officers (LAO) shall be provided the authority to work
the appropriate approval workbaskets.
3.5.4.2 A user assigned the role of Loan Technician (LT) shall have the ability to
approve some of their own recommendation, but shall require approval
from a Senior Loan Technician (SLT) or Servicing Officer (SO) for most
of the work they complete or Loan Administration Officer (LAO).
3.5.5 The system shall assign cases for post-audit review and validation to a
Loan Technician that was not originally assigned to the loan.
3.5.6 The system shall restrict a Loan Technician from conducting a post-audit
on a case that was previously assigned to them at any time during its
default.
3.5.7 The system shall assign the post-audit cases by round-robin scheduling
across technicians nationwide without regard for the number of pending
audits or other cases in the technician’s work queue.
3.6 The system shall allow manual management of work queues, workflows
and loan assignment by Loan Administration Officer (LAO).
3.6.1 The system shall allow for the assignment and reassignment of loans to a
user to oversee all delinquent loan events.
3.6.2 The system shall allow Loan Administration management, including
Loan Administration Officers, to reassign individual cases, groups of
cases, and individual tasks to employees.
3.6.3 The system shall, when one of the following conditions is satisfied,
remove the loan from being assigned to a Loan technician:
• The status of the loan changes to reinstated (and 45 days have
passed) or terminated (and 395 days have passed).
• Timeframes for claim filing, system processing, payment
certification and/or appeals are expired.
3.6.4 The system shall, when one of the following conditions is satisfied,
remove the loan from a user’s Work Queue:
• The Loan Technician completes all open processes
• The system validates that no new processes were created
3.7 The system shall allow a user to upload, view and store documents in
support of a loan to a document repository created for each loan.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.7.1 The system shall allow for a user to associate documents to a loan
process.
3.7.2 The system shall require users to select specific document types
associated with the attachment.
3.7.3 The system shall require users to select or enter metadata (specific either
to the document or form type) when attaching a document.
3.7.4 The system shall perform a virus scan of all documents uploaded prior to
storage in VA systems.
3.7.5 The system shall notify the user if a document was successfully stored or
if an error occurred.
3.7.6 The system shall allow users to view documents they have uploaded (or
that other users have uploaded) in the portal after the document was
successfully submitted.
3.7.7 The system shall reject files where the data types, lengths or other
information does not match standards for that information or existing
files.
3.7.8 The system shall allow for a user to search for a loan based on a variety
of loan characteristics and view loan information.
3.8 The system shall allow for a user to search for a loan using the following
criteria:
• Loan Number Exact
• Loan Number Like
• Borrower Name
• Property Address
• Servicer LIN
• Servicer Name
3.8.1 The system shall retrieve the search results and allow the user to select
and open a loan.
3.9 The system shall provide functions to allow the Loan Technician to
complete their assigned work.
3.9.1 The system shall provide the following tools:
• A tool to allow users to generate loss mitigation
recommendations for borrowers.
• A tool to allow users to analyze claims submitted by servicers
and approve or make adjustments to claim payments if necessary.
• A tool to allow users to access an appeal to make a
recommendation to allow or deny the appeal.
• A tool to allow users review cases for Post-Audit purposes.
• A tool to allow users to manually add and take action on a
regulatory infarction when they identify when a servicer fails to comply
with a VA regulatory requirement.
3.10 The system shall allow for a Servicing Officer to manually open the
Return Custody event.
3.11 The system shall allow for a user to evaluate and monitor general loan
events for the adequacy of servicing.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.12 The system shall allow for a user to provide information and instructions
to borrowers about servicing procedures.
3.12.1 The system shall allow for Holds and Issues to be attached to a loan,
which requires approval of the action by a Senior Loan Technician or
higher supervisor.
3.13 The system shall allow a user to add case notes, tasks for the specific
loan, and issues to a loan process.
3.13.1 The system shall allow a user to manually add general case notes to a
loan and not associate it to a specific loan process.
3.13.1.1 The system shall require users to select a Note Type.
3.13.1.1.1 The system shall not default the Note Type to Other.*
3.13.1.2 The system shall allow a user to select a note and display it entirely in
the system (without needing to export it to Microsoft Word).
3.13.2 The system shall automatically record case notes for any action a loan
technician takes on a loan.
3.13.3 The system shall not time-out on users manually entering case notes on a
loan.
3.14 The system shall allow a user to conduct exception-based servicing when
necessary.
3.15 The system shall allow a user to review and make a recommendation to
approve or deny appeals made by servicers on VA decisions.
3.15.1 The system shall allow for appeals to be filed on claims, acquisitions,
regulatory infractions, bills of collection, existing appeals, and additional
items.
3.15.1.1 The system shall allow a user to review the circumstances surrounding
the loan being appealed, justification provided by the servicer, and any
supporting documentation submitted at the time of the appeal.
3.15.2 The system shall allow a user to recommend to approve or deny the
appeal.
3.15.3 The system shall route the recommendation to the approval work queue
where a Senior Loan Technician (SLT), Servicing Officer (SO) or Loan
Administration Officer (LAO) can make the final determination whether
to approve or deny the recommendation on the appeal.
3.16 The system shall automatically calculate payments on necessary
processes submitted by servicers.
3.16.1 The system shall automatically calculate the payment for a submitted
claim.
3.16.1.1 The system shall calculate the payment amount for a claim submitted by
a servicer by examining total eligible indebtedness, maximum guaranty
amount as provided by WebLGY integration, and credit to the
indebtedness (net value or proceeds from the sale, whichever is greater).
3.16.1.2 This system shall present this claim amount to a VA certifying official
for certification. If denied, the system shall close the process and re-open
the Review Non-Routine Claim for additional review by the ALT or LT.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
3.16.1.3 If the system is presented with a non-routine claims, it shall allow a user
to review and possibly adjust the system-calculated claim amount prior
to certification of the claim payment.
3.16.2 The system shall automatically calculate the payment for an incentive to
be paid after the servicer reports the Default Cured/Loan Reinstated
event (for home retention options) or after the servicer files their claim
(for alternatives to foreclosure).
3.16.2.1 The system shall calculate the incentive payment based upon the loss
mitigation option that was completed and the servicer’s tier ranking at
the time the incentive payment is calculated.
3.16.2.2 The system shall present the incentive payment amount to a VA
certifying official for approval.
3.16.3 The system shall automatically calculate the payment for an acquisition.
3.16.3.1 The system shall track the NV Factor to apply different factors to
multiple time periods.
3.16.3.2 The system shall calculate the property acquisition payments for
approved Transfer of Custody events based on net value and bid type.
3.16.3.3 The system shall automatically present the payment amount for routine
acquisitions to a VA certifying official for certification.
3.16.3.4 The system shall automatically present the payment amount for
non-routine acquisitions to a Loan Technician for review and
recommendation for approval to a VA certifying official.
BN 4: The system shall provide approved payment authorizations to the Financial Management System (FMS) to
oversee day-to-day Loan Administration financial operations.

4.1 The system shall send a payment file to FMS for processing which
includes the following certified payment transactions:
• Acquisition payments
• Claim and incentive payments on pre-credit reform
loans with no debt
• Claim and incentive payments on post-credit reform
loans with no debt
• Refunded loans on post-credit reform loans
• Claim payments on post-credit reform loans with debt
• Refunded loans on pre-credit reform loans
4.2 The system shall receive notification from FMS when it transmits a
payment file to Treasury.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
4.3 The system shall receive notification on changes in payment status and
payment details from FMS on a daily basis.
4.4 The system shall transmit loan modification data, including new loan
terms and established bills of collection, to FMS.
4.5 The system shall receive a daily file to update vendorization information
from FMS in SIM.
4.5.1 This daily file will be constituted with information on vendor addition,
deletion, or modification in SIM.
4.6 The SIM system shall maintain records of vendor information that
mirrors the vendorization information maintained in FMS.
4.7 The system shall log all incoming and outgoing FMS transactions to
allow for reconciliation.
4.7.1 The system shall update its status log as transactions are received and
shall always remain current.
4.7.2 The system shall archive transactions indefinitely in the database.
4.7.2.1 Transaction logs stored in the database by the system shall contain the
following:
• Entire contents of the transaction files
• Significant metadata including the date and time when the file
was received
• Whether it was able to be parsed and imported into the system
successfully
4.7.3 The system shall allow transactions to be viewed “online” for no less
than 180 days.
4.7.4 After 180 days, the system shall allow for transactions to be moved
offline for performance or storage considerations.
4.7.5 The system shall allow authorized users to access offline data when it is
required.
4.8 The system shall post a notice in the Servicer Web Portal and Loan
Management Portal when acquisition, incentive, or claim payments are
issued by FMS.
4.9 When the user identifies a new servicer through documentation received
on a VA guaranteed loan, they will request required documents from the
servicer to complete and submit electronically through SIM.
Note: The system shall not be able to identify a new servicer, the above
is a manual user process conducted outside of the system.
4.10 Once the SIM system validates that the servicer has not already been
established, it shall create a LGY Servicer ID Number for them.
4.10.1 The Servicer ID number shall be a 6 digit number composed of:
• Two Digit State Code
• Two Digit Month
• Two Digit Day
4.11 The SIM system shall send the Servicer ID number to FMS for
establishment.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
4.11.1 The SIM system shall receive a LGY Vendor ID and confirmation from
FMS that the servicer’s information has been processed.
4.11.2 Once the LGY Vendor ID has been received, the SIM system shall allow
a user to establish a servicer profile in the system.
4.11.3 A VA employee shall receive a confirmation notification email when a
servicer is successfully established.
BN 5: The system shall collect data sets and provide the ability to generate web-based, detail summary reports in a
format that is accessible through the business intelligence tool.

5.1 The system shall store all data sets captured by the VALERI application
suite in a centralized database and/or send it to a data warehouse from
which Loan Guaranty can extract and run reports.
5.2 The centralized Loan Guaranty data warehouse shall be capable of
importing external data sets that can be matched and compared for
analysis purposes.
5.3 The system shall provide an interface for users to access available reports
based on their user role.
5.4 The system shall provide an interface for servicers to access available
reports based on their approved authorization.
5.5 The system shall allow reports to be sorted, filtered, and exported to in
different formats such as different formats such as Crystal Reports
(RPT), Adobe Acrobat (PDF), Excel Spreadsheets (XLS), Microsoft
Word documents (DOC), and Rich Text Format documents (RTF).
5.5.1 The system shall allow for filtering functionality on reports, at a
minimum based on the following examples:
• Date parameters
• RLC Office parameters
• Supervisor parameters
• Servicing Officer
• Team
5.6 The system shall be able to generate real-time production reports
anytime of the day for a user upon request.
5.6.1 The system shall allow for a user to run a report query from answering
prompts.
5.7 The system shall allow for supervisors to schedule reports to run at a
scheduled time.
5.8 The system shall be able to generate reports for the day, for the week, for
the month, and for the year, and over multiple years as requested.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
5.9 The system shall provide the following types of reports for authorized
users:
• Reports with program management and operations information
that can be accessed by Central Office Management and Regional Loan
Center Management.
• Reports with operations information to be accessed by VA
organizations such as Administrative Loan Accounting Center (ALAC),
the Debt Management Center (DMC), Loan Production (LP), Monitoring
Unit (MU), and Property Management (PM).
• Reports to communicate information with servicers.
5.10 The system shall provide the following information on each report when
it is listed:
• Brief description of the report
• Report Type
• Report Owner
• Date and time of last generation
• Actions that can be performed on the report
5.10.1 The system shall allow a user to filter a report once it is selected with the
following characteristics, including but not limited to:
• Date parameters
• RLC Office parameters
• Supervisor parameters
• Servicing Officer
• Team
• Role
5.11 The system shall generate the following servicer reports, at a minimum,
to communicate information with servicers:
• Acquisition Payment Status Report
• Appeal Status Report
• Bill of Collections Status and Offsets Report
• Claim Payment Status Report
• Claims Summary Report
• Incentive Payment Status Report
• Post-Audit Results Report
• Post-Audit Selection Detail Report
• Post-Audit Selection Report
• Re-conveyance Status Report
• Refund Status Report
• Servicer Action Required Report
• Servicer Events Report Log Report
• VA Contact Information Report
• Payment Denial Report
• Non Matching Report
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
5.11.1 The system shall allow access to the servicer operational reports to
Servicing Officers and Loan Administrative Officers, along with
additional designated individuals given permissions.
BN 6: The system shall provide interfaces for the VALERI application between the Servicers, internal VA staff, and
third party vendors that comply with all VA security requirements.
6.1 The system shall manage a single interface provided by an aggregator
(contractor) to VA.
6.2 The aggregator (contractor) shall be provided a performance based goal
to comply with the information security requirements in VA Handbook
6500 and work with the industry to maximize the efficiency of servicer
submissions.
6.3 The system shall, as needed, aggregate industry data sets (turning
thousands of files from servicers into a single database for VA
consumption).
6.3.1 The system shall store aggregate data sets in tables pursuant to data
architecture’s final VALERI application design.
6.3.2 The system shall store aggregate data for an unlimited amount of time
for all active loans and transfer the data to the VALERI central database
on a routine scheduled basis.
6.3.3 Prior to transmission of data sets to VA, vendors shall perform data
validation on all files submitted.
6.4 The aggregator (contractor) shall collect all of the data from servicers
and send it to VA in a repeatable, sustainable data transfer (i.e.
transactional, Batch, etc.) so that the data can be imported into VA
systems.
6.4.1 The aggregator (contractor) shall report any issues aggregating data from
servicers, and provide updates through daily status reports and critical
issue reports.
6.4.2 The aggregator (contractor) shall send an email status to a support email
inbox for each batch job run (indicating success or failure, the number of
records, etc.).
6.5 The aggregator (contractor) to VA will maintain the system linkages with
a large quantity of loan servicers to collect loan reporting data that is
transmitted electronically.
6.6 The aggregator (contractor) shall maintain the business process,
procedures, and the administrivia that cannot be handled by VA
associated with onboarding servicers for data purposes.
6.6.1 The aggregator (contractor) shall facilitate the completion of any VA
paperwork that is required to identify new servicers.
6.7 The aggregator (contractor) shall be able to accept multiple aggregate
types.
6.8 The system shall send frequent notifications to the third party and
non-frequent ad hoc notifications to third parties when needed.
BN 7: The system shall automatically process loan data, and select loan events, claims and appeals through a
rules-based processing engine.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
7.1 The system shall validate data received from the data aggregator by
delinquent and current loan events prior to its reflection in the system.
7.2 The system shall automatically process the following delinquent loan
events, at a minimum:
• Delinquency Status Update.
• Monthly Status Update (MSU)
• Contact Information Change
• Occupancy Status Change
• Servicing Transfer (Transferring Servicer)
• Servicing Transfer (Receiving Servicer)
• Bankruptcy Filed
• Bankruptcy Update
• Default Cured/Loan Reinstated
7.2.1 The system shall automatically update the due date and current unpaid
balance on a loan when it receives Delinquency Status Update and
Monthly Status Update (MSU) events.
7.2.2 The system shall automatically update contact information when it
receives a Contact Information Change event.
7.2.2.1 The system shall reflect this updated contact information under the
Borrower Contact Information tab.
7.2.3 The system shall automatically update occupancy information when it
receives an Occupancy Status Change event.
7.2.4 The system shall automatically update servicer information when it
receives Servicing Transfer (Transferring Servicer) and Servicing
Transfer (Receiving Servicer) events.
7.2.5 The system shall automatically update the bankruptcy indicator when it
receives a Bankruptcy Filed event indicating that bankruptcy has been
filed.
7.2.5.1 The system shall automatically allow an additional 180 days of interest if
a claim is subsequently filed as a result of that default, evidence is
received regarding a bankruptcy filing and that Relief of Stay was filed
and/or granted.
7.2.6 The system shall automatically update the loan status when it receives a
Bankruptcy Update (of dismissal or Relief of Stay Granted) event.
7.2.7 The system shall kick off an incentive to review for payment when it
receives a Default Cured/Loan Reinstated event only on repayment,
special forbearance or loan modification.
7.2.7.1 The incentive, when reviewed and approved, will be paid via FMS.
7.2.7.2 The system shall automatically change the language from Delinquency
Status Update to Monthly Status Update when it receives a Default
Cured/Loan Reinstated event.
7.3 The system shall reflect the updated loan payment date within 24 hours
of the payment. Currently, when a payment is made, the loan payment
date is not reflected until the first to the seventh of the month.
Busines OWNR Owner Requirement (OWNR) Priority*
s Need Number
(BN)
7.4 The system shall differentiate between conveyed and non-conveyed
statuses of terminated loans and calculate the correct payment amount
based on a set of rules that VA is responsible for paying.
7.5 The system shall provide a list of all actions that a technician takes on a
claim or appeal in one area of the interface to be easily reviewed by the
approving official.
7.6 The system shall provide an error message when supporting documents
are not attached to an appeal as at least one document must be attached
to provide detail on the action that is under appeal.
7.7 The system shall clearly display the amount that will be paid on an
appeal once a loan technician reviews and updates the system with the
information received on a servicer’s appeal.
7.8 The system shall clearly display the amount that will be paid on an
appeal once a loan technician reviews and updates the system with the
information received on a servicer’s appeal.
BN 8: The system shall supply general information and updates to the Customer Relationship Management Unified
Desktop (CRUM-UD) system in order to assist the Loan Technician in resolving LGY general-purpose calls.*

8.1 The system shall provide basic information to LGY employees on the
LGY program and benefits and data that is specific to the LGY line of
business.
8.1.1 The system shall provide information to LGY employees associated with
a veteran or beneficiary.
8.1.1.1 The system shall provide relevant information to allow for LGY
employee to ID the veteran or authorized caller.
8.1.2 The system shall provide unambiguous LGY eligibility information
based on the LGY eligibility rules system.
8.1.2.1 The system shall provide LGY employees the ability to determine LGY
eligibility for other services provided by VA, such as refinancing, etc.
8.1.3 The system shall allow LGY employees to perform “Change of Address”
related to the loan and have it reflect in the VALERI application.
8.2 The system shall provide loan technicians with a customer relationship Future
management tool (future state) access that will allow for a holistic view state
of a claimant during the life cycle of a loan as it displays all information
available on a veteran in VBA.
8.2.1 The system shall display whether a veteran is in receipt of VA disability
compensation, education, pension benefits, etc.
8.2.2 The system shall display whether a veteran is going to school and
receiving Education benefits.
8.2.3 The system shall display whether a veteran has VR&E assessments.
8.2.4 The system shall display whether a veteran has Insurance coverage.
8.2.5 The system shall display whether a veteran has any pending claims.
8.2.6 The system shall display whether a veteran has been awarded benefits,
such as Specially Adaptive Housing
8.2.6.1 The system shall display the amount of a veteran’s award benefits.
* Note: This symbol denotes requirements that are not in the current VALERI system and will be
incorporated in the new system.

6.2. User Access Levels

User Level Role Responsibilities VALERI Access Level

Primary User VA Loan There are approximately 200 to 300 ● Ability to view all
Technician Loan Technicians claimants’ data.
Their primary role is Level 2 Support ● Will be subject to the
Sensitivity Level
permissions settings.
Primary User Loan Servicer The system interfaces with ● Ability to view authorized
approximately 1,500 loan servicers. assigned claimants’ data.
● Ability to submit forms
either taking action on or
recording information
about a loan.
Secondary User FMS The system interfaces with the FMS ● Ability to process
system to process and pay acquisition, approved payment files
claim and incentive payments to from VALERI.
servicers when authorized.
● Ability to view and
maintain vendorization
information.
Secondary User NCC LGY would like to route LGY ● Ability to view information
general-purpose calls to the NCC for associated with a
level 1 call resolution. Veteran/ beneficiary.
NCC staff will service LGY calls upon ● Will be subject to the
receipt. If they are unable to resolve a Sensitivity Level
call they will have the option to perform permission settings.
a warm transfer to LGY.

6.3. Known Interfaces and Data Sources

The table below outlines what the business community believes to be the list of known
interfaces. All required interfaces will be stated as Business Needs in Section 7.1.
Name of Application Description of current application Interface Type
Master Veteran Index (MVI) Source of VA person identity information Outbound
Knowledge Management (KM) Storage and management of LGY content Outbound
Identity Access Management Management of identity access and VA Outbound
(IAM) Enterprise Person Search capability
Loan Servicer Data Feeds Existing loan servicers send information on Inbound
VA loans electronically to VALERI
LGY Database Data on loans, servicers, lenders, etc. Inbound/Outbound
 Name of Application Description of current application Interface Type
CPTS (Centralized Property CPTS provides LGY with the information it Inbound
Tracking System) needs to monitor the progress and
performance of selling VA properties and to
process sales proceeds.
FMS Financial Management System Outbound/Inbound

SIM Stakeholder Information Management Inbound

PA&I Office of Performance Analysis & Integrity Outbound

develops and maintains the Enterprise Data
Warehouse to enable the generation of
recurring and ad hoc reports in response to
VBA decision-making and business needs.
IBM Cognos Connection The software is designed to enable Outbound
business users without technical knowledge
to extract corporate data, analyze it and
assemble reports.

6.4. Related Projects or Work Efforts

The table below provides the additional related projects or work efforts that were used in the
development of design requirements in this BRD.

Related Projects Description

IAM MVI Person Search

MSTI Correspondence Service

MSTI Interaction / Activity Service

MSTI Certificate of Eligibility Service

MSTI Eligibility Determination Service

Knowledge Management Provide content to generate Smart Scripts

FMS Financial Management System

EVSS Enterprise Veterans Self Service

SEP VSO (Veteran Services Organization) Self-Serve Portal

CRMe CRM Enterprise project

WebLGY Web Loan Guaranty Application

SIM Stakeholder Information Management

7. Service Level Requirements
7.1. Availability
Service Level Requirement SLR Criteria Description
(SLR) Question
1. How much time should the 99.9% (8.76 hours down time) The system needs to be
system be available (and how maintained to be as available as
much down time is acceptable the current VALERI system.
due to incident [unexpected] This system has not experienced
outage)? these levels of downtime any year
since inception, and the SLR
criteria is approximately 1,200%
higher than actually experienced.
2. When should the system be 24x7 The system is currently available
available (what will be the core 24x7.
operating hours of the
system)?
3. How soon should the system 4 hours The current system must recover
fully recover from an outage? from an outage within 4 hours,
(Includes Mean Time to
Restore)
4. How much data will be 100% (continuous back up)
restored when outage is
recovered?
5. What time period should be After hours Usually maintenance is
considered for maintenance completed after hours or
periods? overnight on Saturdays from
8pm – 12pm EST.
6. What standard time zone will Eastern Standard Time.
the system operate in?

7.2. Capacity & Performance

SLR Question SLR Criteria Description
1. How many users will be on the 101-1000
system hourly?

2. How many transactions will >10 Note: the system creates millions
each average user perform of events each month that are not
each hour? manually performed by a user.
3. What are the anticipated peak 9AM – 3PM EST, M-F The peak time is on business
user times during the day? days, Mondays through Friday
from 9AM – 3PM EST. This peak
time is made up of a variety of
users in different time zones.
SLR Question SLR Criteria Description
4. What is the anticipated peak 9AM – 3PM EST, M-F The peak transaction load is on
transaction load (when do you business days, Mondays through
think that there will be the Friday from 9AM – 3PM EST.
most transactions being
performed on the system)
during the day?
5. How many new users will be >100 This includes VA employees and
added in one year? servicers.

6. How many more (if any) >10 This number is much greater than
transactions will be added in 10.
one year?
7. What kind of information will Forms & Documents Servicers and VA employees will
be stored (specify average of be able to upload and store
1) PDF non-editable documents.
each kind per month)?
2) GIFs We may need to revisit this to
3) JPEGs allow for editing/annotating
needs for VA employees for
oversight purposes.

8. What kind of search capacity Medium (11-1000 per hour)

is required?

9. What type of system(s) is/are Internet (public) The system will be located on the
required? internet, but only authorized users
will be able to log in.
10. Is there a need for heavy End of day. Servicers report daily files most
application reporting? If yes, commonly at end of day. They are
when? then processed at 6AM EST.

VA employees & servicers run

reports throughout the day and
after the business day.
8.3. Interfaces and Security
SLR Question SLR Criteria Description
1. Will this system interact with other existing Yes The following existing
systems? systems interact:
▪ FMS
▪ WebLGY
▪ Servicer
System
▪ ALAC (this is a
department
and not a
system)
▪ CPTS
▪ Reporting
Databases
▪ eBenefits
▪ CRM
(potential)
▪ Corporate
Database
▪ Enterprise
Services
▪ VBMS
2. Will this system require additional Yes The new VALERI
monitoring for Information Technology system will require
system metrics? additional monitoring
for external systems
that may impact
accessibility (i.e. Active
Directory).
3. Will this system contain Personally Yes The system will contain
Identifiable Information (PII), Protected PII and other regulated
Health Information (PHI), Health Insurance and confidential data.
Portability and Accountability Act (HIPAA)
information, or other confidential/regulated
data?
SLR Question SLR Criteria Description
4. Who will be the anticipated users of this VA Restraint: Users
system? authorized by loan
▪ VA employees
servicers cannot be
Public foreign contractors.
▪ Authorized Loan They also must
Servicers Authorized complete all required
Contractors that are training, pursuant to
employed by the directive 6500.
Loan Servicer.

7.3. Assumptions
● Subject Matter Experts (SME) and key stakeholders will be identified in collaboration
with the Business Owner (BO) or designee and remain engaged throughout the lifecycle
of the work effort
● Project priorities have been established and funding has been requested for FY17 and will
be approved.
● Appropriate technical staff will be assigned and engaged to participate in the work effort
● This effort will provide VA with available options, which it will then consider from a
resources/budget perspective
● All options generated by this group will provide a highly confident, cradle to grave,
estimate of time/budget. Options need to account for all aspects; gathering requirements,
development, testing (unit, regression, functional, user acceptance), training (internal VA
and all external users), coding changes required by industry, and overall transition
activities.
● All options must include all functionality currently available in the VALERI solution
hosted by BKFS.
● All options must include the enhancements that will be made to the VALERI solution
prior to the termination of the existing contract (or subsequent contracts awarded to
“bridge” this effort).
● All options must account for long-term enhancements planned, but not reasonably
achieved, prior to the termination of the existing contract (or subsequent contracts
awarded to “bridge” this effort).
● All meetings will include meeting minutes and pertinent meetings/demonstrations will be
recorded.
● LGY expects stability in the project team. If new non-LGY resources (i.e. OI&T) are
added to the project, LGY will not be expected to conduct rework to “bring the new
resources up to speed”.

7.4. Dependencies
● WebLGY
 o The new VALERI system is dependent on WebLGY for data regarding new and
inactive VA guaranteed loans.
● Corporate Database
o The new VALERI system is dependent on the Corporate Database to determine
claim status and Disability Compensation verification.
● Enterprise Services
o The new VALERI system is dependent on Enterprise Services for military service
data.
● FMS
o The new VALERI system is dependent on FMS for performing acquisition, claim
and incentive payments and the issuance of bills of collections for any and all
payments.
● CRM (future state)
o The new VALERI system is dependent on its integration with CRM in order to
assist the Loan Technician in resolving LGY general-purpose calls.
● ALAC
o The new VALERI system is dependent on ALAC in order to establish any
required receivables or payables for a refund or BOC.

7.5. Constraints
● Requirements Analyst and Business Architect staff availability may be limited.
● Availability of resources may be limited due to strategic priorities or funded work efforts.
● The current VALERI system must stay in operation in parallel to the new system being
built.
● Contracting clauses restrict vendor selection.
● Regulation Title 38, Chapter 36, Part B: Guaranty or Insurance of Loans with Electronic
Reporting.

7.6. Business Risks and Mitigation

Business Risks Mitigation Category
If there is insufficient funding to support Coordinate with Business Owners and Business/
development or acquisition, then leadership to ensure project funding. Operational
necessary data will not be collected.
If the system is not employed and Implement organizational change Organizationa
integrated or does not meet the business management on activities from begin to l and Change
requirements, then the employees will not end. Management
have correct guidance on servicing loans.
If the system is not available, LGY will not Coordinate with Business Owners and Strategic
be able to provide proactive services and leadership to ensure project funding.
benefits to Veterans as directed by VBA’s
strategic goals.
If the system is not secure, VA Deploy Enterprise Services. Privacy
employees will be able to access
unauthorized loan records.
Business Risks Mitigation Category
If the system is not available, VA Coordinate with IT to ensure the system is Data/
employees will not be able to provide available 24x7. Information
oversight and assist Veterans with
maintaining and retaining home
ownership.
If there is insufficient security, then the PII Coordinate with stakeholders to ensure PII Security/
will be exposed to unauthorized users. is protected and safeguards are in place. Privacy
If a servicer is unable to provide loan Coordinate with stakeholders and ensure Data /
status information, then VA is unable to that the Data Aggregation Service is Information
provide necessary oversight to assist available 24x7.
Veterans.
Appendix A References
The authority to produce the Business Requirements Document (BRD), which is authored by the
business community, is found in the following:
● OneVA EA Enterprise Technical Architecture (ETA) Compliance Criteria
http://vaww.ea.oit.va.gov/wp-content/uploads/2014/10/OneVA_EA_ETA_Compliance_v
5_08312014.pdf
● Requirement Level Guide
http://vaww.oed.wss.va.gov/process/Library/requirement_level_guide.docx

Document References:
● Department of Veterans Affairs (VA) Handbook 6500 – Information Security Program
http://vaww.va.gov/vapubs/viewPublication.asp?Pub_ID=793&FType=2

The following resources were used in the creation of the recommendations included in this BRD:

● LGY homepage: http://www.benefits.va.gov/homeloans/

Addendum 1
The following form types for loan events can be submitted via the VALERI servicing events import
spreadsheet (from SWP_Bulk_Upload_Template and Claims_Bulk_Upload_Template V8):
● Monthly Loan Status Update
● Loan Paid in Full
● Transfer of Ownership
● Release of Liability
● Unauthorized Transfer of Ownership
● Partial Release of Security
● Servicing Transfer – Transferring
● Servicing Transfer – Receiving
● Electronic Default Notification
● Delinquency Status Update
● Contact Information Change
● Occupancy Status Change
● Bankruptcy Filed
● Bankruptcy Update
● Loss Mitigation Letter Sent
● Partial Payment Returned
● Default Cured Loan Reinstated
● Default Reported to Credit Bureau
● Repayment Plan Approved
● Special Forbearance Approved
● Loan Modification Approved
● Loan Modification Complete
 ● Compromise Sale Complete
● DIL Complete
● Foreclosure Attorney Contact Info
● Foreclosure Referral
● Foreclosure Sale Scheduled
● Results of Sale
● Transfer of Custody
● Improper Transfer of Custody
● Invalid Sale Results
● Confirmed Sale Date With No TOC
● Appraisal Fees
● Attorney Fees
● DIL Recording Fees
● Filing Fees
● Foreclosure Facilitation Fees
● Foreclosure Recording Fees
● Other Fees
● Property Inspection Fees
● Title Fees
● Foreclosure Buydowns
● Insurance Loss Proceeds
● Origination Buydowns
● Prepayments
● Association Fee Advances
● Boarding Advances
● Debris Removal Advances
● Equip Repair Replace Advances
● Ground Rent Advances
● Hazard Abatement Advances
● Insurance Advances
● Securing Advances
● Special Assessment Advances
● Tax Advances
● Utilities Advances
● Winterization Advances
● Yard Maintenance Advances
● ARM Interest Rate Change
● SCRA Interest Rate Change

Appendix D Enterprise Requirements

Below is a subset of Enterprise-level Requirements that are of particular interest to the business
community. These requirements MUST be addressed within each project resulting from this
work effort. If OI&T cannot address these Enterprise-level requirements, the Business Owners
responsible for each area MUST be engaged in any waiver discussions prior to any decisions
being made. This section is not meant to be a comprehensive list of all Enterprise-level
requirements that may apply to this work effort and should not preclude the technical community
from reviewing all Enterprise-level requirements and identifying others that should apply to this
work effort as well.
Requirement Type Description
Security All VA security requirements will be adhered to. Based on Federal Information
Processing Standard 199 and National Institute of Standards and Technology
(NIST) SP 800-60, recommended Security Categorization is
<<High/Moderate/Low>>.
The Security Categorization will drive the initial set of minimal security controls
required for the information system. Minimum security control requirements
are addressed in NIST SP 800-53 and VA Handbook 6500, Appendix D.
Privacy (Standard) All VA Privacy requirements will be adhered to. Efforts that involve the
collection and maintenance of individually identifiable information must be
covered by a Privacy Act system of records notice.
508 Compliance All Section 508 requirements will be adhered to. Compliance with Section 508
(Standard) will be determined by fully meeting the applicable requirements as set forth in
the Veterans Health Administration (VHA) Section 508 checklists (1194.21,
1194.22, 1194.24, 1194.31 and 1194.41) located at:
http://www.ehealth.va.gov/508/resources_508.html or as otherwise specified.
Checkpoints will be established to ensure that accessibility is incorporated
from the earliest possible design or acquisition phase and successfully
implemented throughout the project.
Executive Order All executive order requirements will be adhered to.
(Standard)
Identity Management All Enterprise Identity Management requirements will be adhered to. These
(Standard) requirements are applicable to any application that adds, updates, or performs
lookups on persons.
System Performance Include instrumentation to measure all performance metrics specified in the
Reporting - Service Level Requirements section of the BRD. At a minimum, systems will
Performance Metric have the ability to measure reporting requirements for Responsiveness,
Measuring Capacity, and Availability.
Instrumentation
Performance Make the performance measurements available to the Information Technology
Measurement (IT) Performance Dashboard to enable display of “actual” system metrics to
Availability customers and IT staff.
VistA Evolution (VE): Computer systems shall track accounting of disclosure information when the
HIPAA system is accessed by a non-VA user.
VE: HIPAA Computer systems shall allow for the correction or amendment of any piece of
individually identifiable information.

Appendix E User Interface/User Centered Design Principles

User Experience encompasses direct and indirect interactions between the user and the system
Improving usability over the prior version is a key requirement for this application. The
International Organization for Standardization (ISO) defines usability as “the extent to which a
product can be used by specified users to achieve specified goals with effectiveness, efficiency,
and satisfaction in a specified context of use” (1998).
For an optimal user experience the system must meet the requirements outlined in this section,
which involve attributes of the application and the process required to achieve them.
In order to improve usability of VA-developed or purchased applications, the following actions
are required:
● In accordance with the Office of the National Coordinator for Health Information
Technology’s Meaningful Use Stage 2 final ruling, employ an industry recognized User
Centered Design (UCD) process. The methods for UCD are well defined in documents
and requirements such as ISO 9241–11, ISO 13407, ISO 16982, National Institute of
Standards and Technology Interagency Report 7741, ISO/International Electrochemical
Commission 62366, and ISO 9241-210. Developers will choose their UCD approach;
one or more specific UCD processes will not be prescribed.
● Adhere to an industry recognized User Interface (UI) Best Practices Guideline or Style
Guide. For example, first follow UI guidelines for the development platform. In
instances where platform guidelines are not available, adhere to VA’s Best Practices
Guidelines/Style Guide.
● Inform requirements and designs with detailed human factors work products that have
been/will be completed for the specific project. Examples of specific human factors
activities might include heuristic evaluations, site visits, interviews, application-specific
design guides, and usability testing on existing systems or prototypes.
A sound UCD and development process based on human factors should include the following
activities:
● Understanding of the users, the users’ tasks, and the users’ environments
● Review of similar or competitive systems to inform requirements and design
● Heuristic evaluation of prior versions, prototypes, or baseline applications, if applicable
● Iterative design and formative usability testing (formative usability testing is used to
discover usability problems during the design and development process)
● User risk analysis
● Summative validation usability testing (summative usability testing is used to quantify
and validate usability of a product with measures of effectiveness, efficiency, user
perceptions, etc.)
To demonstrate high usability, the application should be:
● Intuitive and easy to learn, with minimal training
● Effective by allowing users to successfully complete tasks
● Efficient by allowing users to complete their work in a manner consistent with clinical
practice and workflow
● Perceived to have high usability, as demonstrated by appropriate survey measures
● Designed to aid users in meeting task goals without being an additional burden
The system must be reliable and enable user trust by providing:
● Stable and reliable performance
● Accurate data
● Display of all data that is available in native or interfaced systems and intended to be
available in the application
● Accessible information related to the source of data
The application should include a modern Graphical User Interface that allows the user to view
data from multiple sources and include:
● Integrated display of structured and unstructured data
● Rich data visualization and graphical display of data
● Ability to switch between tabular and graphical data views
● Ability to interact with displayed data to obtain additional details related to the data and
source of the data
● User customizable components and settings
The application must provide for advanced and up-to-date searching, to include:
● Fast search functionality with auto-complete and real-time display of matched results
during typing
● Search history
The application must provide for advanced filtering capabilities, to include:
● Filtering of data tables, lists, and grids
● Filtering of search results
The application design should be modified to:
● Address the specific findings from a human factors heuristic evaluation conducted on the
prior version of the application
● Address the specific findings reported from field use of the prior version
● Address the specific findings reported from usability testing of the prior version or
relevant prototypes
Identifier Usability/User Interface Requirements
Left align content in table cells to facilitate quick visual scan.
Left align text for column headers to facilitate visual scan and make columns and
content appear more organized.
Use mixed case instead of all caps whenever possible (e.g., dropdown list items, table
data, table headers, hyperlinks, tab names). Limit the use of “all caps” throughout the
application.
Simplify button labels. Re-label buttons to reflect standard terminology that is common in
web interfaces and other applications (e.g., “Cancel”). Emphasize the action being
performed in the most succinct way possible. Minimize redundancy in text/terminology
that is used to convey the same action.
Identifier Usability/User Interface Requirements
Left align page/section titles to anchor titles in consistent locations regardless of window
sizing.
Labels for fields should be left aligned to facilitate quick visual scan and make forms and
field groupings appear more organized.
Avoid using acronyms or abbreviations unless (a) they are widely understood/well
known or (b) there is very limited space to display the full meaning. This supports naïve
user understanding. If limited space results in using a non-common
acronym/abbreviation, ensure it is specified within “Help” and/or as a tooltip.
Use colors such as red and green only for status driven content. Avoid using red for
text/content, links, button labels, etc. This will reduce risk for user error, improve link
discoverability, and facilitate understanding of differences in navigation/actions/content.
It will also help users to isolate important status information (using red, green, etc.) from
other less important information when viewing and processing information provided to
them on a page.
Provide visual separation between the navigation space and the main content area.
Add field level validation and notification of missing information on the same page
without launching a new window or navigating to another page.
Make all text hyperlinks appear consistent in style.
Make drop-down selection box widths appropriate for content and visual appeal.
Use standard and always visible radio buttons for “Yes/No” options instead of requiring
the user to click in a drop down box and then click to select the “Yes” or “No” option.
Use standard date and time selection widgets. Where date and time are selected/picked
from a standard widget, also provide direct data entry to support keyboard navigation.
Enable field level validation immediately upon entry. Include instructional format text
within the field entry box.
Provide standard sort behavior and visual indications on columns in all tables.
Define and adhere to a standard model for use and design of controls, buttons,
hyperlinks, and navigation elements.
Ensure that text is sized to be readable (for example, by using the 007 Rule to assure
text size is readable for users with 20/40 vision. The formula: Text height = .007 *
distance between eyes and screen).
Place common navigation elements in consistent locations.
Place critical information “above the fold” (i.e., in the top portion of the screen that is
immediately viewable).
Use consistent screen flow models, elements, and terms to support similar workflows.
Use consistently named buttons when actions are the same (e.g., Add vs. Save vs.
Submit).
Enable users to print views from where they are in the interface. Avoid requiring the user
to “run a report” in order to print something that is viewable on the screen.
Provide field entry tool tips at the field location. Ensure consistency across the
application in field labels, formats, location of tooltips, and tool tip text.
Provide visual indication of required fields.
Display field labels in close proximity to entry elements.
Use consistent elements to filter data.
Use consistent elements to sort data.
Identifier Usability/User Interface Requirements
Use a consistent model for display, layout, and grouping of data entry fields.
Provide alternate row shading in lengthy tables of data, form elements, etc.
Ensure that icons are recognized by users.
Provide some “white space” between status icons in report views, white board views,
etc.
Auto-populate default values in entry / selection fields when possible and appropriate.
Visually differentiate status icons from clickable icons, when appropriate.
Define and support the appropriate user tab sequence through fields in forms in order to
support keyboard navigation when entering data in forms.
Define and adhere to standard action button placement on screens, forms, etc.
Visually distinguish the primary action button on a page.
Consistently use screen elements, action elements, workflow sequences within/across
screens, language, etc.
Provide error messages in user-centric language with specific instructions on the
meaning of the error and how to recover from it. Use error messages and method of
display consistently across the interface.
Provide context-specific Help.
Do not use the term “sex” or any like abbreviations of that to represent gender.
Appendix F Acronyms and Abbreviations
Term Definition
ALT Assistant Loan Technician
APG Agency’s Priority Goal
ASD Architecture, Strategy and Design
BKFS Black Knight Financial Services
BO Business Owner
BOC Bill of Collection
BRD Business Requirements Document
CAG Citrix Access Gateway
COE Certificate of Eligibility
CRM-UD Customer Relationship Management - Unified Desktop
EDN Electronic Default Notification
EVSS Enterprise Veterans Self Service
FFPS Funding Fee Payment System
FISMA Federal Information Security Management Act
FNOD First Notice of Death
HAP Homeowners Assistance Program
HELP Homeowners Loss Prevention Program
HIPAA Health Insurance Portability and Accountability Act
HUD Housing and Urban Development
FMS Financial Management System
ISA Information Security Agreement
ISO Information Security Officer
IT Information Technology
LA Loan Administration
LAO Loan Administration Officer
LAPP Lender Appraisal Processing Program
LGC Loan Guaranty Certificate
LGO Loan Guaranty Officer
LGY Loan Guaranty
LP Loan Production
LT Loan Technician
MOU Memorandum of Understanding
MSU Monthly Status Update
NCC National Call Center
NIST National Institute of Standards and Technology
NTRID NewTrak Rail ID
OI&T Office of Information and Technology
PII Personally Identifiable Information
Term Definition
PIV Personal Identification Verification
RSD Requirements Specification Document
SEP Stakeholder Enterprise Portal
SLR Service Level Requirements
SLT Senior Loan Technician
SDE Service Delivery Engineering
SME Subject Matter Expert
SO Servicing Officer
UCD User Centered Design
UI User Interface
USDA U.S. Department of Agriculture
VA Department of Veterans Affairs
VALERI VA Loan Electronic Reporting Interface
VBA Veterans Benefits Administration
VPN Virtual Private Network
VRM Veterans Relationship Management