Multifamily System Requirements Account Management

· System must support creating/maintaining roles with multiple level of access. Both Internal and External users will need different set of privileges for different needs. At a minimum, the system must support the following roles. The Department may consider systems that propose alternative role structures from what is listed below, so long as the alternative structures allow for the same tasks to be performed in an efficient and logical manner:

· Internal users:

· Application Admin

· Supervisor

· Staff

· External users

· Primary applicant

· Applicant user

· Guest

· Application Admin must be able to create and edit both internal and External user accounts and manage privileges.

· Application Admin must be able to make timely changes to the Multifamily program application according to program rule changes, state, or federal policy changes.

· Application Admin must be able to make necessary text changes and modify contents of the multifamily program application.

· Application Admin and Supervisors must be able to manage/restrict access to External users after program application submission.

· Supervisors must be able to create External user accounts.

· Supervisors must be able to assign/re-assign program application to Staff.

· Primary applicant must have all functionality needed to create/edit/modify a profile.

· Primary applicant must have an option to request accounts for Applicant users to have access to their account.

· Primary applicant must be able to create/edit/submit program application.

· Applicant user must have access to edit program application created by the Primary applicant.

· Primary applicant and Applicant user must be able to view program applications submitted through their account.

· All users must have access to a public portal to view all submitted program applications.

· Primary applicant can invite Guest users to view/interact with specific pages of their program application.

· The System must display a TDHCA system use notification banner message before granting system access informing potential users that the user is accessing a Texas State Government information system.

· The System must display a user agreement for users and require that they acknowledge and accept the agreement prior to accessing the system. The agency will provide the specific language.

· The System must have the capability to display broadcast messages, banners, and alerts to all, specific, or a subset of users.

Multifamily Application

· The application must accommodate multiple multifamily-related programs that operate under different timelines. It has to be nimble to accommodate quick, last-minute changes to the application.

· The system must gather relevant data for each of the multifamily programs the applicant is applying for: 9% LIHTC, 4% LIHTC and Tax-Exempt Bonds, HOME, NHTF, and must be sufficiently flexible to allow similar programs to be added in the future.

· The system should allow for multiple programs to be applied for concurrently.

· The system must gather applicant data based on requirements for that program application cycle. Data gathering may vary for different application cycles.

· The system must allow Internal users to apply rules to applications based on the application cycle year.

· The system must handle application and data structure changes to support new programs, legislatively mandated changes, disaster events, etc.

· Applicants must be able to start the application, save pages completed and return at a later date to resume.

· The system must allow for Application Admins and Supervisors to set specific deadlines for single applications or groups of applications, after which no additional changes will be allowed.

· Applicants must be able to attach documentation to their application at relevant places.

· The system must be able to limit or compress the file size of uploaded documents, especially with architectural drawings (created with CAD or other software) or other images.

· The system must support bulk document uploads with smart naming and filing.

· The System must pre-populate data fields where possible and cascade data between input screens to improve productivity and reduce data entry errors. The System must incorporate a “collect once use many” approach to data entry in order to eliminate redundant data entry.

· The System must capture pre-selected responses in fields where possible, via drop-down menu lists or a similar approach, to standardize responses.

· The System must include all functionality necessary to validate entered or selected data to ensure solution operates on and with clean, correct, and useful data.

· The System must display appropriate and meaningful message(s) to the user when data does not meet the validation requirements.

· The System must provide spell checking in designated fields.

· The system must be configurable by the agency including program application page layout and ordering, new fields, rules engine, etc.

· The system must support electronic signatures.

· The system must support uploading paper-based signatures at relevant places in the program application.

· The system must support gathering information from existing applications to create a new application. If applicants want to reuse information from existing applications from previous cycle in a new application for a different program fund or submit a new application for a development previously not awarded in previous cycles. Such applications will be treated as a new application but with a relationship with the existing application in question.

· The system must allow Primary applicants to view existing and previously submitted applications.

· The system must be able to auto generate application numbers in accordance with program rules and allow Application Admins and Supervisors to assign a new application number, if necessary.

· The system must be able to generate an application log in the public portal.

· The system must support the pre-application process for certain multifamily programs.

· The system must auto populate program application if a pre-application has been submitted.

· The system must allow Internal users to edit submitted applications while maintaining version history.

· The system must be able to generate a report on the sequence of activities that have occurred on a program application.

Underwriting

· The underwriting module must include templates for different types of funding programs.

· The system must allow Supervisors to make changes as necessary to the templates in the underwriting module.

· The system must auto populate data into the templates from submitted program applications which are ready to be underwritten.

· The underwriting module must allow multiple programs to be layered into one template.

· The system must provide Staff with read/write access to data and files uploaded by external users for a program application.

· The underwriting module must pull reference data from different data sources wherever necessary for analysis. The data sources must include, but not limited to the following:

· Income (Rent tool) – must pull from online in CMTS legacy system.

· Comp deal tool – from CMTS or via excel.

· Statewide & Regional Expense Database - from CMTS or via excel.

· Costs - Marshall and Swift, API, if possible, if not, a streamlined update to the current Excel costing tables

· Market Study

· Appraisal

· ESA

· Loan Documents

· Contracts

· LURA’s

· Feasibility Study

· Property Condition Assessment or Scope and Cost Review

· Pull income and expenses from PDF trailing 12 operating statements and categorize line items per TDHCA’s categorization.

· The underwriting module must provide income, expense, and costing data only relevant to the funding program(s) being underwritten.

· The system should generate underwriting reports and memos from financial information in the underwriting analysis based on staff templates of narrative needed.

· Underwriting reports and memos should be automatically submitted to a supervisor for review when complete.

· The underwriting template must compare the applicant’s numbers to TDHCA’s underwritten numbers and adjust whose numbers are used for analysis based on our underwriting rules.

· The system must identify any changes between application updates and automatically update the underwriting template with the new data, i.e., no data input from staff. Changes must be trackable.

· The system must allow for photos or screenshots to be included in the final underwriting report.

· The system must be able to account for multiple underwritings for the same program application, i.e., amendments or adding a loan to previous award.

· The system must provide contextual information from previous underwriting reports of the same property for subsequent analyses.

· The system must populate underwritten data from previously published underwriting report to be compared to the current application.

· The Supervisor must be able to post approved underwriting reports in the public portal.

· The system must send notifications to the applicant when an underwriting report has been posted in the public portal including the link to the published report.

· The system must send notifications to appropriate internal staff when an underwriting report has been posted in the public portal including the link to the published report.

· The system must send notifications to appropriate internal staff when underwriting conditions are cleared by Underwriting Staff.

· The system must provide an option to the Primary applicant to appeal the contents of the underwriting report. The option for an appeal should be made available for a predetermined number of days after the underwriting report has been published.

· The system must allow staff to issue determination notice if all underwriting conditions are satisfied.

· The system must generate a pipeline report for all deals that are currently being underwritten including all pertinent details such as assignee, application status, due dates, and priority.

Asset Management

· Standardized Reporting: Develop a report suite to replace the Access DB, specifically a "Gap Report" that identifies missing or incomplete deal requirements.

· MITAS Loan Integration: Establish a read-only data link to MITAS to display real-time loan statuses within the property dashboard.

· CMTS Financial Sync: Create an interface to pull annual financial compliance reports from CMTS for the "Comp Deal" analysis tool.

· Document Intake & Storage: Implement a centralized repository supporting PDF/Excel uploads for all post-award packages (10% Test, Cost Cert, etc.).

· Dynamic Template Generation: Build a document engine to auto-generate loan origination docs and extension letters using system data.

· Applicant Portal Workflows: Build a secure portal for developers to submit 15+ specific requests. This includes packages for 10% Test, Application Amendments, Cash Flow Loans and Delinquent Loans, Construction Status Reports, Cost Certification, Extensions, LURA Amendments, LURA Origination, Loan Modifications, Other Recorded Documents, Ownership Transfers, Qualified Contract, Rent Approvals, Reserve Tracking, and Right of First Refusal.

· Cost Certification Underwriting: Create a module for internal underwriting of cost certifications with automated math validation.

· Re-Underwriting Triggers: Automatically route "Application Amendments" back to the underwriting queue if they impact financial structures.

· Owners’ compliance module: Enable property owners and external stakeholders to upload and manage required compliance documentation, loan modification documents, construction status reports, 10% test documentation, and materials required for periodic compliance reviews.

· Allow staff to configure and manage task-related notifications, establish due dates, send automated reminders, and grant extensions to deadlines when applicable.

· Support annual rent revision review and approval process for applicable deals and generate automated reminders for upcoming and overdue rent revision activities.

· Replacement Reserve Ledger: Centralize reserve agreement storage and track balances/draws per property.

· PNA Compliance Timer: Automate alerts for Physical Needs Assessments (PNA) due every 5 years after the 11th year of an award.

· Legal Division Hand-off: Create a status-tracking bridge to Legal to replace separate tracking sheets; include "Closed/Not Closed" status for transfers.

· Inter-divisional Comms: Replace "Email-per-deal" with a centralized "Communication Log" shared across REA, Compliance, and Legal.

· Compliance Fee Billing: Export a monthly data feed to Financial Administration containing all data necessary for compliance fee invoicing.

· Data & Document Migration: Migrate all historical Access data and maintain "Deep Links" to legacy files stored on the Q Drive.

Compliance

· CMTS Supplemental Interface: Active interface to pull Unit Status Reports (USR), unit numbers, and building assignments from CMTS.

· Household History Lookback: Database must store and retrieve at least 5 years of historical household and income data.

· Performance Scaling: System must support the processing of at least 800 annual compliance reviews without latency.

· Digital Prep Checklist: Replace the Excel "Pre-Site Visit" file with a digital tool that auto-organizes property details before planning.

· Unified Monitoring Engine: Replace the review Excel file with a system that aggregates LURA, Underwriting, and Cost Cert data.

· Automated Unit Selection: Implement a randomizer that identifies the required sample size and selects units for testing automatically.

· Unit Mix Validation: Automated cross-reference of current occupancy against the required unit-mix set-asides.

· Finding Management: Automatically flag non-compliance and port findings into a report editor for user customization.

· Printable Compliance Reports: Generate a standardized, formatted PDF "On-Site Review" report for physical documentation.

· Travel Optimization Module: Automate travel planning by grouping properties due for review by geographic location/region.

· Risk-Based Scheduling: Automatically assign review dates based on property scores and regulatory cycles.

Workflow Management

· Program applications must follow predetermined submission/review/approval stages in the lifecycle.

· The system must have a capability to send notifications to all system users when a task is assigned to them.

· The system must allow Supervisors to assign tasks to Staff.

· The system must allow Supervisors and Staff to assign task to external users to gather additional program application details.

· The system must provide all pertinent information such as file number, developer name, developer contacts, location, request/program type, NOFA requirements & conditions, Board preference and any other timing considerations to Internal users when the program application is moved between different stages.

· The system must have the capability to include appropriate notes when the program application is progressed to different stages.

· The system must display the current stage/status of the program application and assignee.

· The system must send appropriate notifications to assignees/Supervisors when tasks are overdue.

· The system must let Supervisors to set priorities to tasks.

· The system must allow for Department-initiated correspondence to be saved to the file as a record of actions taken (i.e., Board approval-related documents.)

Document Management

· The system must be able to generate documents from program applications and store them for a predetermined length of time.

· The system must include all functionality necessary to handle version control. Must include version control that keeps track of program application changes.

· The system must use document numbering system followed by the agency.

· The system must archive documents according to business rules and allow authorized users to reinstate and interact with archived data.

· All Internal users must have access to all the documents.

· PDF Form Filler capability for regulatory forms such as IRS Form 8823, 8609’s and other federally required reporting forms for the Multifamily Programs.

· The system must be able to generate LURA’s, contracts and loan documents from underwriting reports and other templates in the system. These legal documents must meet the individual federal program requirements (9% and 4% LIHTC and Tax-Exempt Bonds, HOME, NHTF).

· Data migration of historical applications, underwriting reports, LURA’s, loan documents, etc. as determined by program area.

IT Specifications

· The System must prompt all users to log-on and register for an account. The System’s authentication facilities must support the ability for the user to sign-in and reset their password to a new password using authentication criteria other than password. LDAP/AD based authentication preferred.

· The System must enforce role-based access, enabling access to client records based on user authorizations, while not displaying confidential information elements not required for the intended use.

· The solution must lock out user after three unsuccessful login attempts.

· The solution must have session time out feature and an idle session automated logoff feature which can be defined by a system administrator.

· For web-based solutions, closing all application windows in a browser must log off user.

· The solution must detect and record all attempted accesses, authentications, and authorizations.

· The system must include log and issue tracking for problems, issues, changes and requests, with a sufficient system to seek technical assistance from the vendor.

· The System must ensure error messages are written in plain English and including specific directions to follow in the event of an error.

· The System must store user error messages for later retrieval and review.

· The system must provide backup services in accordance with the data retention and recovery requirements of the data.

· The system must allow audit tracking to keep track of changes made, who made them and when.

· The system must be accessible via multiple internet browsers.

· The solution must provide ease of implementation and maintenance of logical business rules and validation checks; a Configurable, external business rules framework which will permit customization of business rule logic in real-time to enable specific program area policies and other operational decisions to be defined, tested, executed and maintained separately from application code.

· The system must have the capability to connect to internal data sources like HCS, CMTS, MITAS, etc., and be able to update relevant data based on need.

· The system must be able to export data in a common, industry standard format.

· The system must allow read-only queries to the database by Internal users.

· The system must provide statistics on application information and generate report on status and priority of applications.

· The system must include reporting functions that allow users to filter and choose columns for output.

· The system must allow for custom reports to be generated for all Internal users.