ESBD_521962_1781812816788_QA 332-RFO26-1007 Final.pdf

221 East 11th Street P.O. Box 13941 Austin, Texas 78711-3941 (800) 525-0657 (512) 475-3800

TEXAS DEPARTMENT OF HOUSING AND COMMUNITY AFFAIRS

www.tdhca.state.tx.us

A D D E N D U M #2

Request for Offer (RFO)

332-RFO26-1007

Multifamily Management System 06/18/26

Answers to Questions from Potential Proposers

1. What is meant by Actuarial Services in this questionnaire?

Response:

- Oversight of Purchaser. The question should read: In your opinion, would you use this Vendor again for Application, Infrastructure, Hosting, Data Hosting and Cloud Computing Services.

2. Thank you for sharing the Multifamily System RFO. We have carefully reviewed the requirements outlined in the document and are very interested in supporting TDHCA in modernizing its multifamily program operations.

To prepare a thorough and accurate cost estimate with detailed hourly breakdowns across all proposed modules, we respectfully request clarification on the following areas:

• APPLICANT PORTAL & APPLICATION INTAKE • Approximately how many unique applicants or organizations submit applications annually across all multifamily programs? • Will the portal support multi-language requirements, ADA/WCAG compliance standards, or specific accessibility mandates? • What is the expected maximum number of concurrent users on the portal during peak application periods? • Will the Multifamily Uniform Application be entirely digital, or will hybrid (paper + digital) submission workflows need to be supported? • What third-party documentation types are expected (e.g., financial statements, environmental studies, architect certifications), and is there a volume estimate per application?

Questions to Answers from Potential Responders June 18, 2026

- Typically, the agency receives 400-500 applications a year across all different multifamily programs.

- Yes. The solution must comply with all applicable State of Texas accessibility requirements, including WCAG 2.1 Level AA standards. Multilingual support is not currently a mandatory requirement.

- TDHCA anticipates around 2000 concurrent external users and around 200 concurrent internal users.

- The proposed solution should support electronic submission, review, approval, and document management processes.

- Applicants are expected to submit a broad range of supporting documentation, including but not limited to:

Financial statements Market studies Environmental reports and assessments Site control documentation Architectural plans Organizational and ownership documentation Cost estimates and development budgets Compliance and regulatory certifications

• APPLICATION FRAMEWORK & ANNUAL RULE CHANGES How frequently are rule changes expected per year, and what is the average scope of change (e.g., adding/removing fields, restructuring sections, or full workflow changes)? • Should TDHCA staff be able to configure rule changes independently through an admin interface, or will changes require vendor involvement? • Are there specific regulatory bodies or legislative timelines that drive rule change cycles (e.g., QAP updates, federal reporting cycles)?

Response:

- TDHCA's multifamily programs are subject to annual updates. Typically, annual changes are incremental, however, the system should be capable of accommodating substantial changes without significant redevelopment. TDHCA has an implementation window of approximately 1 to

1.5 months to operationalize changes within the system. The proposed solution should be capable of supporting this level of rapid implementation.

- TDHCA is open to both options – handling changes through an admin interface or partnering with a vendor.

- Yes, all multifamily programs rule changes are governed by the Qualified Allocation Plan (QAP)

• UNDERWRITING MODULE • What underwriting methodologies or scoring models are currently in use that the system must replicate or integrate with? • Is there a need to support automated underwriting decisions, or is the system intended to support analyst decision-making only? • What financial data inputs are required (e.g., proforma analysis, debt coverage ratios, tax credit calculations)? • How many underwriting staff users are anticipated?

- Current underwriting processes include the review of development budgets, sources and uses of funds, operating proformas, financial feasibility metrics, and program-specific eligibility requirements.

- The new system is intended to support decision making, not to automate it.

- Financial data for Underwriting such as Development budgets, sources and uses, Operating proformas, rent schedules, financial feasibility assessments are gathered from the users. In addition to user input data, Underwriters utilize comparable rent and income data gathered by the agency and external data sources such as Marshall and Swift database.

- TDHCA anticipates 15-20 dedicated underwriters.

• ASSET MANAGEMENT & COMPLIANCE • How many active assets/properties are currently tracked under asset management? • What compliance frameworks must the system support (e.g., IRS Section 42, HOME, CDBG, HUD reporting)? • Are there existing third-party monitoring or compliance platforms (e.g., RealPage, Yardi, MITAS) the system must interface with? • What are the expected audit and inspection tracking requirements?

Response:

- Asset Management tracks around 3000 active properties.

- The proposed system should support the following Federal, State and individual LURA requirements for the following programs:

o LIHTC (Section 42) o HOME o BOND o Neighborhood Stabilization Program (NSP) o National Housing Trust Fund (NHTF) o Texas Housing Trust Fund (THTF) o Section 811 PRA (HUD) o Texas State Housing Tax Credit o HOME-ARP o Tax Credit Assistance Program (TCAP) o Tax Credit Exchange Program

- The agency uses MITAS and few in-house developed monitoring systems such as Compliance Monitoring and Tracking System (CMTS) and Housing Contract System (HCS). The proposed system should have the capability to gather data through APIs from these systems.

- The solution should provide configurable workflows, notifications, and reporting capabilities to support TDHCA's compliance monitoring processes and demonstrate compliance with applicable program requirements.

• DOCUMENT MANAGEMENT • What is the estimated total volume of documents currently managed, and the expected annual growth rate? • What document formats must be supported (PDF, Excel, Word, images, CAD files, etc.)? • Are there specific retention schedules, legal hold, or public records act (TPIA) requirements the system must comply with? • Does the system need to generate or publish documents (e.g., award letters, public notices) as part of the document lifecycle?

- Historically, the volume of documents has ranged between 40GB – 80GB per year.

- The proposed system should support PDF, Word, Excel, common image files such as JPEG, PNG, TIFF, etc. and text files.

- The documents are required to be retained for a period of seven years, however, awarded deals will need documents to be retained for 30-40 years.

- Document generation and publication capabilities are important components of the desired solution.

• 6. WORKFLOW MANAGEMENT • How many distinct workflow types are anticipated across all divisions (e.g., application review, environmental review, credit underwriting, compliance monitoring)? • What is the current average number of steps and approvers in a typical application workflow? • Are workflows expected to support conditional branching, parallel approvals, or escalation paths? • How many total internal staff users are anticipated, and across how many divisions?

Response:

- The selected solution should provide a configurable workflow framework capable of supporting multiple workflow types. Respondents are expected to develop a detailed understanding of TDHCA’s business processes during discovery phases and translate those requirements into a configurable software solution. TDHCA will provide subject matter expertise and process guidance; however, the responsibility for eliciting, validating, and configuring these processes within the proposed system rests with the selected vendor. The list of initial workflows is as below:

o Application intake and eligibility review o Scoring and evaluation o Underwriting and financial review o Asset management o Compliance monitoring o Deficiency process

- Workflow complexity varies significantly depending on program type, funding source, and business process. An application review process may involve multiple stages of review across several functional areas such as program staff and underwriting.

- Yes. Workflow flexibility is a key requirement of the proposed solution.

- TDHCA anticipates approximately 150–200 internal users requiring varying levels of system access.

• INTER-DIVISION ROUTING & HISTORICAL DATA • Which divisions are expected to share application data, and what are the handoff points between them? • How much historical application data exists, and in what format (legacy database, paper records, flat files)? • Is a full historical data migration required, or is read-only access to historical records sufficient? • What is the acceptable data migration timeline and acceptable level of downtime during cutover?

- Application data will need to be accessible to the following divisions:

o Multifamily programs o Underwriting o Asset Management o Compliance o Legal services o Program services o Executive and Management staff

- The Asset Management division has maintained digital records for approximately 13 years. This structured data is stored across multiple Access databases. All property-related data maintained by Asset Management is expected to be migrated to the new system. The intent is for the new system to serve as the primary system of record for Asset Management activities going forward.

- Yes, full migration of data maintained by Asset Management is required. However, documents that are stored in agency’s internal file systems (Q:\ drive) need not be migrated.

- TDHCA expects the selected vendor to develop a comprehensive data migration and cutover strategy that minimizes operational disruption.

• REPORTING & NOTIFICATIONS • What specific regulatory or compliance reports are required (e.g., HUD IDIS, IRS Form 8609, federal allocation reports)? • Will reports need to be scheduled and auto-distributed, or are on-demand reports sufficient? • What notification channels are required beyond email (e.g., SMS, in-portal notifications, API webhooks to other systems)?

Response:

- The proposed system is not required to directly generate any regulatory or compliance reports. It should, however, produce reports with data that the staff can use to create regulatory or compliance reports.

- On-demand reporting is a mandatory requirement, and the solution must support user-driven generation of reports at any time. Scheduled reporting may be proposed as an additional capability.

- Email notifications are a core requirement along with in-portal alerts and notifications.

• INTEGRATIONS & EXISTING SYSTEMS • What existing TDHCA systems must the new platform integrate with (e.g., financial systems, GIS platforms, state government identity/SSO, reporting tools)? • Are there specific API standards required (REST, SOAP, SFTP file exchange)? • Will Single Sign-On (SSO) be required, and if so, which identity provider is currently in use (e.g., Microsoft Azure AD, Okta)? • Are there any planned system retirements that affect integration scope?

- The proposed solution must support integration with TDHCA’s existing multifamily and enterprise systems such as MITAS, CMTS, and HCS.

- The solution should support modern, standards-based integration approaches.

- Yes. Single Sign-On (SSO) is a required capability for the proposed solution. The agency uses

Microsoft Entra ID.

- Currently there are no system retirements planned that will impact the multifamily system.

• TECHNICAL & HOSTING ENVIRONMENT • Is TDHCA expecting a cloud-hosted (SaaS), state-hosted, or hybrid deployment model? • Are there specific state IT security standards or DIR (Department of Information Resources) requirements the solution must comply with? • What are the expected uptime/SLA requirements? • Will TDHCA require source code ownership or escrow arrangements?

Response:

- TDHCA is open to a modern, scalable deployment approach that aligns with State of Texas IT policies and security requirements.

- The proposed solution must comply with all applicable State of Texas information security requirements, including, but not limited to, Texas Administrative Code (TAC) Chapter 202 Information Security Standards and Texas Government Code (TGC) Section 2054. Any cloud-hosted solution proposed should be Tx-RAMP certified.

- The system is expected to support mission-critical multifamily program operations. Vendors should propose enterprise-grade Service Level Agreements (SLAs).

- The ownership requirement will depend on the selected solution architecture and will be negotiated as part of the contract structure.

• PROJECT DELIVERY & IMPLEMENTATION • What is the expected go-live target date or phased implementation timeline? • Will TDHCA provide dedicated business analysts and subject matter experts during requirements and UAT phases? • Are there any blackout periods (e.g., active QAP cycle, HTC application rounds) during which the system cannot undergo major changes or go-live activities? • Is an Agile, Waterfall, or hybrid delivery methodology preferred?

- The go-live is expected to be no later than August 31, 2027.

- Yes. TDHCA will provide dedicated business participation throughout the project lifecycle and will make Subject Matter Experts (SMEs) available to support project activities. However, there will be no dedicated Business Analyst who will be working with the selected vendor.

- Yes. Change to how programs are administered are dictated by QAP adoption cycles and multifamily application cycles. The implementation plan should account for a deployment window outside of peak program activity.

- TDHCA does not have a preference for a delivery methodology.

• HSP Form Under “Agency Special Instructions/Additional Requirements—" on page 20, it states, “If Respondent is not subcontracting any portion of the contract, Sections 1, 2(a), 3 and 4 must be completed.” However, under Section 2, if the Respondent checks “Yes”, the HSP form requires only pages 1 and 2 to be completed. Pages 1 and 2 only consist of sections 1, 2 and 3; which instruction should be followed, the HSP form or the RFO instructions?

Response: Please follow instructions under Section 2 of the HSP form. Under Section 2, if the Respondent checks “Yes”, the HSP form requires only pages 1 and 2 to be completed.

3. Attachment D, Multifamily System Requirements, pages 3-6. There are several requirements to interface with the Compliance Management and Tracking System (CMTS). Can additional information on CMTS integration capabilities be provided? For example, does CMTS currently support APIs, file exchanges, database connectivity, or other methods?

Response:

- CMTS supports API-based integration. Specific technical integration capabilities for CMTS will be confirmed during the requirements validation and technical discovery phase.

4. Attachment D, Multifamily System Requirements, page 4. There is a requirement to interface with the Mortgage and Information Technology Automated Systems (MITAS). What integration options are currently available within MITAS?

Response:

- Specific technical integration capabilities for MITAS will be confirmed during the requirements validation and technical discovery phase.

5. Attachment D, Multifamily System Requirements, page 7. There is a requirement to interface with the Home and Community-Based Services (HCS). What data exchanges are expected between HCS and the new Multifamily System?

Response:

- Specific technical integration capabilities for HCS will be confirmed during the requirements validation and technical discovery phase.

6. Attachment D, Multifamily System Requirements, page 5. Does TDHCA use any third-party inspection contractor platforms that the vendor’s compliance module needs to interface with?

Response:

- TDHCA does not require integration with any third-party inspection contractor platform for purposes of this RFO.

7. Attachment D, Multifamily System Requirements, page 5. Does the Travel Optimization Module need to integrate with any existing travel, expense, or scheduling systems currently in use at TDHCA?

- TDHCA does not require integration with any third-party inspection contractor platform for purposes of this RFO.

8. Attachment D, Multifamily System Requirements. Attachment D references a number of internal and external data sources with which the solution will interact. Will the selected vendor be required to acquire licenses for any of those data sources, or are they all internal, public non-commercial, or already licensed for use by TDHCA?

Response:

- The selected vendor need not procure any licenses for any third-party systems. TDHCA will work with the selected vendor to acquire any license, if need be.

9. Attachment D, Multifamily System Requirements. What is the estimated volume of historical records including applications, underwriting reports, LURAs, and loan documents expected to be migrated from legacy Excel files, Access databases, and the Q Drive? What are defined retention requirements that govern what must be migrated versus archived?

Response:

- Asset Management keeps a track of around 3000 properties. All data related to different activities for these properties are stored in different Access databases as structured data. This data is expected to be migrated to the new system to preserve historical information, support ongoing operations, and ensure business continuity. However, documents related to these properties are stored in agency’s file server (Q:\ drive). Migration of these documents into the new system is not required. However, the proposed solution should maintain references to these documents by storing and displaying location information or links to the existing file storage locations, thereby preserving access to historical records.

- Asset Management tracks certain properties for 30-40 years. Accordingly, the proposed solution must support long-term data retention.

10. Is the expectation for the solution to be cloud hosted? Should we include pricing for infrastructure or would TDHCA provision the needed infrastructure?

Response:

- TDHCA is open to vendor recommendations regarding the best-suited deployment model, provided that the solution meets all the requirements.

11. Are you open to secured, compliant cloud-hosted, fully managed service, SaaS solution? - In this option, we will build, configure, customize, support, host. All of it will be delivered as a per user subscription solution.

Response:

- TDHCA is open to consider any deployment model, provided that the solution meets all the requirements.

12. Application Intake: Does TDHCA envisage replacing the spreadsheets that applications fill OR retain those spreadsheets?

Response:

- Spreadsheets are not intended to remain the primary application mechanism, but the system should support spreadsheet import.

13. Functionality: Would you want all module functionalities be mobile enabled?

- Mobile accessibility is not a requirement for this RFO.

14. We understand the Underwriting module is expected to pull data from various data sources. Can you please provide additional information on these sources like, but not limited to:

• What are the integration or data extraction capabilities of these tools

• Are they client-server, desktop based or web-enabled applications?

• Are they home grown or COTS applications?

Response:

- The primary data source for underwriting is the data provided by the user through the application.

all data should flow to the underwriting module from the application seamlessly within the application. Other data sources are either developed in-house or can be imported in the form of excel spreadsheets. In-house tools such as an online income and rent tool do not currently provide API-based integration capabilities, but the proposed system should support alternative methods for data capture.

15. Are you envisioning the resulting new application also have AI capabilities

• Underwriters be able to make conversational queries that intelligently provides the information

• TDHCA users are able to get AI enabled applicant and/or application specific summary or assessment

• Use conversational statements to simply search rather than having to choose various search & filter conditions

Response:

- The agency is open to consider AI-capable systems considering that they follow agency and DIR-specified regulations around AI. The agency does not anticipate or require a chat-based AI interface. AI can assist in data extraction from unstructured document formats and supporting report generation based on staff-reviewed financial assessments. It should operate in a human-in-the-loop model and provide full control to the staff/user as applicable.

16. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf

Section / page Section 4, page 7; Section 7, page 12; Section 17.1, pages 22-23

Identified issue / discrepancy The RFO states TDHCA may enter preliminary negotiations with more than one top respondent and may choose to award the solicitation to more than one respondent, but Section 7 refers to selection of one respondent for contract negotiations.

Clarification question Please clarify whether TDHCA intends to make a single award or whether multiple awards are contemplated under this RFO. If multiple awards are possible, please explain how scope would be divided and how pricing/evaluation would be applied across multiple vendors.

Response:

- TDHCA’s intent under this RFO is to award a single contract to a primary vendor responsible for delivering the end-to-end Multifamily Management System solution. At this time, multiple awards are not contemplated as the primary procurement approach. If TDHCA were to determine that multiple awards are necessary, scope would likely be divided along functional or modular boundaries. Under such a scenario, each vendor will be evaluated against specific functional scope.

17. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

ESBD_521962_1780349172804_Exhibit A Terms And Conditions 6-1-26.pdf

Section / page RFO Sections 6, 10.4, 12, pages 10, 14, 17; Exhibit A Section 78, page 11

Identified issue / discrepancy The RFO defines Maintenance and Support for Year 1 as go-live through August 31, 2027 and asks bidders to price option Years 2-5. Exhibit A states the contract will terminate approximately twelve months after execution and may be renewed for three additional 12-month periods.

Response:

- Exhibit A are our standard Terms & Conditions. For this RFO, the initial term is approximately 13 months. Maintenance and Support will start September 1, 2027 and will end August 31, 2032 per the renewal options available.

18. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf

Section / page Sections 4, 5, 6, pages 7-10

Identified issue / discrepancy The RFO calls for full implementation of a comprehensive solution, but also references continuity of existing functionality and development of integration or bridging solutions for modules or systems not immediately replaced.

Clarification question Please identify which modules/capabilities are mandatory for the initial go-live versus those that may be phased or supported temporarily through bridging/integration solutions.

- TDHCA prefers a single go-live release. The agency recognizes that certain supporting enhancements, optimizations, and extended capabilities may be introduced post-implementation as iterative enhancements following stabilization of the core system.

19. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx

Section / page RFO Sections 4-5, pages 7-9; Attachment D Asset Management and Compliance sections, lines 97-99 and 116-117

Identified issue / discrepancy The solicitation references existing systems including CMTS, MITAS, and other legacy processes, but does not fully define which system remains authoritative for each function or dataset after implementation.

Clarification question Please clarify TDHCA’s intended future-state architecture and system-of-record boundaries for CMTS, MITAS, HCS, Excel/Access tools, and the new Multifamily System. Which functions/data sets are expected to remain in existing systems, and which are expected to be fully moved into the new platform?

Response:

- The existing systems such as CMTS, MITAS, and HCS will remain as-is; they are not expected to be retired. Data and functional boundary will be preserved as they currently exist. Only manual processes related to multifamily divisions as outlined in the RFO will be moved into the new system.

20. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

Section / page RFO Section 4.1, page 8; Attachment D Account Management and Multifamily Application, lines 24, 53, 88-92

Identified issue / discrepancy The RFO requires applicant portals and real-time status tracking. Attachment D also states all users must have access to a public portal to view all submitted applications and that approved underwriting reports may be posted publicly.

Clarification question Please define the expected public-facing portal behavior. What specific application data, documents, or underwriting reports must be available to the public, what redactions/confidentiality rules apply, and which users are considered public versus registered external users?

Response:

- Any application that has been submitted to the agency for any multifamily program is public information. The full application needs to be displayed in the public portal. Any changes made to submitted applications through the deficiency process will also need to be notated and displayed.

Finalized underwriting reports should also be posted on the public-facing portal.

21. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx

Section / page Attachment D Underwriting, lines 65-79

Identified issue / discrepancy The underwriting requirements reference multiple data sources, including CMTS, Excel, third-party cost sources, and extraction of income/expense line items from PDF trailing 12s, but do not define which data sources are available via API, file feed, manual upload, or vendor-provided parsing.

Clarification question For each underwriting source listed in Attachment D, please clarify the expected integration method (API, file import, manual upload, or reference-only), whether TDHCA will provide licenses/access rights where needed, and whether automated PDF extraction/classification of T-12 operating statements is a mandatory Day 1 requirement.

Section

Clarification question The underwriting section requires pulling structured data from PDFs, such as trailing 12s.

Can TDHCA clarify whether the expectation is full automation of extracting financial data from PDF documents, or if assisted/manual validation workflows are acceptable?

Response:

- Responses to questions regarding underwriting data sources have been provided in earlier questions. Please refer to those responses for additional detail.

- The expectation for the new system is to standardize data collection and streamline the submission and aggregation of financial documents, making it easier for applicants to provide required materials and for staff to review, organize, and utilize financial information in a consistent manner. For financial data contained in PDF documents, the proposed system should be capable to read, extract and store data in templates designed for underwriting analysis.

22. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx

Section / page Attachment D Underwriting, lines 88-93

Identified issue / discrepancy Attachment D requires public posting of underwriting reports, applicant notice of posting, and a right for the primary applicant to appeal within a predetermined number of days, but the actual appeal period and mechanics are not defined.

Clarification question Please specify the required applicant appeal period, what portions of the underwriting report are appealable, whether supporting documents may be submitted with the appeal, and whether posted reports are public or restricted to applicant-specific portal access.

Response:

- For system design purposes, the solution should support a configurable appeal window. This ensures the appeal period can be adjusted based on program requirements.

- Any portion of the underwriting report can be subjected to an appeal. As a part of the appeal process, the applicant can submit supporting documentation.

- All finalized underwriting reports should be publicly posted.

23. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

Section / page RFO Section 5, page 9 and Section 6 Stage 5, pages 11-12; Attachment D Asset Management, line 113

Identified issue / discrepancy The RFO calls for migration of legacy Excel files, PDFs, and other data sources.

Attachment D additionally requires migration of all historical Access data and maintenance of deep links to legacy files stored on the Q Drive.

Clarification question Please clarify the exact historical migration scope, including years of historical data, specific repositories, whether “all historical Access data” means all tables/records, and what TDHCA means by maintaining “deep links” to legacy files. What tools will TDHCA be providing to the selected vendor i.e. data dictionary, schema, expert resources please be specific.

Response:

- TDHCA expects the historical migration scope to be defined as part of the implementation discovery phase. The intent is to migrate all historical data to ensure operational continuity for Asset Management. Response to question regarding data migration has been provided in earlier questions.

Please refer to that response for additional detail.

- “Deep links” refers to the capability of the new system to store and display links to the agency’s file server (Q:\ drive), where legacy and historical documents will be maintained.

- TDHCA will support the selected vendor with available technical and business artifacts; however, detailed documentation and artifacts may not be fully developed for all systems.

24. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx

Section / page Attachment D Asset Management, line 98; IT Specifications, line 164

Identified issue / discrepancy Attachment D requires a read-only MITAS loan link and also references broader system connectivity to internal sources, but does not define MITAS access method, refresh expectations, or field scope.

Clarification question Please clarify the MITAS integration expectations, including whether TDHCA will provide API/database/file-feed access, the required refresh frequency for loan status data, and the minimum MITAS data elements expected in the new system.

Response:

- Responses to questions regarding MITAS have been provided in earlier questions. Please refer to those responses for additional detail.

25. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

Section / page RFO Section 4, page 7; Attachment D Asset Management line 99 and Compliance line 116

Identified issue / discrepancy The RFO says the new solution should “compliment and have an active interface with” CMTS. Attachment D separately requires CMTS financial sync and a supplemental interface for USR/unit/building data.

Clarification question 1. Please clarify which CMTS integrations are mandatory for the base scope, whether CMTS remains the authoritative source for tenant/unit/financial compliance data, and whether TDHCA expects one-way or bi-directional interfaces for each required CMTS integration.

The RFO also states that the proposed solution must “compliment and have an active interface with” the Compliance Monitoring and Tracking System (CMTS), while Attachment D further identifies CMTS as a source for Unit Status Reports (USR), unit numbers, building assignments, annual financial compliance reports, and certain underwriting reference data. Please clarify which compliance and reporting activities TDHCA expects to remain within CMTS versus which activities, data, or workflows are intended to move into the new Multifamily System.

Clarification question 2. Can the agency confirm whether documented APIs, data schemas, and access credentials will be provided for CMTS, MITAS, and HCS integrations, and whether TDHCA will support coordination with those vendors if required?

Clarification question 3. Can the agency clarify the expected frequency and latency requirements for data synchronization with external systems such as MITAS and CMTS, for example, real-time, scheduled batch, or near real-time?

Response:

- CMTS integration is required for core compliance and asset management functionality, however, CMTS is not being replaced by the new system. There is no expectation of a bi-directional interface to

CMTS.

- TDHCA will provide reasonable support to the selected vendor for integration planning and execution.

The level of pre-existing documentation, schemas, and direct system access varies by system and will be further clarified during the discovery phase.

- TDHCA’s expectation is that data synchronization patterns with external systems will either be near real-time, batch, or on-demand.

26. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

Section / page RFO Current System Section 3.4, pages 6-7; Attachment D Compliance, lines 118, 125-126

Identified issue / discrepancy The RFO states recurring inspections are typically conducted at least once every three years and in accordance with standards such as NSPIRE. Attachment D also requires support for at least 800 annual compliance reviews, risk-based scheduling, and travel optimization.

Clarification question Please confirm the authoritative inspection/review cadence, annual review volume assumptions, the meaning of “800 annual compliance reviews,” and whether travel optimization is a mandatory base requirement or a desired enhancement.

- The reference to approximately 800 annual compliance reviews is intended as a planning estimate to provide vendors with a general understanding of the scale of TDHCA's compliance monitoring operations across the multifamily portfolio. Travel optimization is considered a desirable capability rather than a mandatory base requirement.

27. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

Section / page RFO Exhibit E, page 31; Exhibit A Section 61, page 9

Identified issue / discrepancy Exhibit E instructs respondents to stamp confidential pages with the term “CONFIDENTIAL” in bold red letters. Exhibit A Section 61 instructs respondents to label such pages “Proprietary Information” in bold size 12 or greater font.

Clarification question Please confirm the required marking convention for confidential/proprietary proposal content. Should TDHCA follow Exhibit E (“CONFIDENTIAL” in bold red letters), Exhibit A (“Proprietary Information”), or accept either format if consistently applied?

Response:

- Respondents are encouraged to use a single, consistent marking convention throughout their proposal. Either format is acceptable as Proprietary or Confidential will require Legal review before being released.

28. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

ESBD_521962_1780349172552_EXHIBIT F VENDOR REFERENCE QUESTIONNAIRE.pdf

Section / page RFO Section 8.1, page 13; Exhibit F questionnaire

Identified issue / discrepancy Section 8.1 requires references for at least three successfully completed similar implementations within the last five years. The separate questionnaire is labeled “EXHIBIT G” in the content even though the RFO lists it as Exhibit F, asks whether the reference purchased services in the past two years, and twice refers to “Actuarial Services.”

Clarification question Please confirm the governing reference requirement and questionnaire language.

Should respondents provide references for implementations completed within the last five years per Section 8.1, even if the questionnaire asks about services in the past two years? Also, please confirm that “Actuarial Services” is a typographical carryover and should be read as the multifamily system services solicited here.

Response:

- Typographical error on Purchasers part the correct Exhibit should be “ F” in the content of RFO as for actuarial services, please refer to question #1 for answer.

- Respondents should provide references for qualifying implementations completed within the last five

(5) years as outlined in Section 8.1.

29. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf

Section / page Section 7, page 12; Sections 10.2 and 10.3, pages 15-16; Section 17.2, page 23

Identified issue / discrepancy Section 7 states optional tasks will not be considered in evaluation. Section 10.3 still asks for a Project Grand Total that includes both required and optional pricing. The evaluation criteria assign 35% weight to cost.

Clarification question Please confirm whether optional deliverable pricing will be excluded from cost scoring and best-value evaluation, and whether respondents should assume TDHCA will evaluate only the required deliverable price for award purposes.

Response:

- TDHCA intends to evaluate proposals based on the requirements and evaluation criteria identified in the RFO. The required deliverable pricing will serve as the primary basis for cost scoring.

30. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

ESBD_521962_1780349172686_Exhibit C VETHub Subcontracting Plan.pdf

Section / page RFO Section 15.1.5, pages 19-20; Exhibit C Sections 1-3, pages 1-3

Identified issue / discrepancy The RFO states respondents must carefully review, complete, and return all VetHUB forms and that incomplete HSP submissions are disqualifying. Exhibit C states a self-performing vendor should submit pages 1 and 2 only, while elsewhere it says every responding vendor must submit a complete subcontracting plan.

Clarification question For a self-performing prime contractor with no subcontractors, please confirm the exact pages/forms that must be submitted to be considered responsive under Exhibit C and Section 15.1.5.

Response:

- Please follow instructions under Section 2 of the HSP form. Under Section 2, if the Respondent checks “Yes”, the HSP form requires only pages 1 and 2 to be completed.

31. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf

Section / page Section 15 Vendor Response, page 17

Identified issue / discrepancy The e-procurement portal compatibility list includes Internet Explorer 11, along with Edge, Chrome, and Firefox.

Clarification question Please confirm whether Internet Explorer 11 support is still a current requirement/expectation for respondent-implemented browser compatibility, or whether modern browser support (for example Edge, Chrome, and Firefox) is sufficient.

Response:

- Respondents must provide solutions that support current, industry-standard web browsers. Internet Explorer 11 is not a required browser platform.

32. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf

Section / page Section 6, page 10

Identified issue / discrepancy The RFO states that all deliverables will be subject to review and approval by applicable State and Federal authorities prior to final acceptance and payment, but does not identify which authorities review which deliverables or the expected review process.

Clarification question Please identify which deliverables are expected to require review/approval by State or Federal authorities, which authorities are involved, and whether respondents should assume any review/approval timelines when developing the project schedule.

Response:

- Respondents should not assume any specific State or Federal approval durations. There may be certain project activities and deliverables may require review. However, the specific review requirements will depend on the proposed solution, hosting model, security architecture, integration approach, and applicable program requirements.

33. ESBD_521962_1780349172804_Exhibit A Terms And Conditions 6-1-26.pdf Section / page Exhibit A Section 59, pages 8-9; Section 42, page 7 Identified issue / discrepancy Exhibit A defines all work product developed, produced, generated, or provided in connection with the services as work made for hire and TDHCA property, while Section 42 separately grants TDHCA a non-exclusive perpetual license to deliverables.

Clarification question Please clarify how TDHCA intends these provisions to apply to respondent pre-existing software, platform components, configuration frameworks, and other background technology that may be used to provide the solution. Specifically, what is TDHCA’s intended distinction between project-specific work product and respondent pre-existing intellectual property?

Response:

- TDHCA does not intend to acquire ownership of a respondent's pre-existing software, platform components, configuration frameworks, and other background technology. TDHCA expects to receive sufficient rights to use, access, maintain, and support the delivered solution.

34. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf Section / page Section 8, Page 12-13, Section 15. Page 20-21. Identified issue/discrepancy Section 8.2 states that the Functional and Technical Requirements are provided in Attachment D and that respondents are expected to review those requirements and provide detailed responses demonstrating how the proposed solution meets or exceeds them.

However, Section 15.1.6 (Respondent Qualifications and Experience) does not specifically identify Attachment D responses as part of that section, while Section 15.1.8 (Respondent Narrative and Preliminary Work Plan) requests a narrative explanation of how the offered services will meet the requirements of the RFO. Clarification question Please clarify TDHCA's preference for how and where respondents should submit detailed responses to Attachment D, Multifamily System Requirements. • a separate Attachment D response matrix; • responses included under Section 15.1.6 Respondent Qualifications and Experience; or • responses embedded within Section

15.1.8 Respondent Narrative and Preliminary Work Plan

- Respondents can include their responses within Section 15.1.8 Narrative and Preliminary Work Plan.

35. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section Multifamily – Bullet 10 Clarification question File upload requirements include compression and large CAD drawings. Are there defined maximum file size limits for uploads and expected storage volumes, and should long-term storage be included within the solution or externalized?

Response:

- Respondents should assume that the solution will be the primary repository for documents generated and submitted through the system. Respondents should describe their approach to records retention, archival storage, and long-term document management.

36. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section Multifamily

– Bullet 23 Clarification question Please clarify what an application log is. Is this referring to the physical deal application or is this specific to a software application. (MF Bullet 22)

Response:

- The term application log refers to the multifamily program application record and its associated change history, not a software system or technical application log.

37. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section Asset Management – Bullet 17

Clarification question Would need additional information on migrating their historical access data and Deep Links to legacy files store on Q Drive

Response:

- Responses to questions regarding data migration and “deep links” have been provided in earlier questions. Please refer to those responses for additional detail.

38. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section References various areas of the Requirements Doc Clarification question The entire document assumes multiple legacy systems remain in place. Is TDHCA open to proposals that consolidate or replace certain existing systems, such as CMTS or MITAS, as part of a long-term modernization strategy, rather than only integrating with them?

- Respondents should assume that existing systems will remain operational and will not be replaced.

39. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section References various areas of the Requirements Doc

Clarification question They require document generation for legal artifacts (LURA, contracts, etc.). Will TDHCA provide standardized document templates and legal language for all generated documents, and how frequently are updates expected?

Response:

- TDHCA will provide available templates, but vendors will be responsible for implementing, configuring, and maintaining these within the document generation framework of the proposed solution. The templates may need to be updated on an as-needed basis, typically driven by QAP annual changes.

40. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section IT Specifications Bullet 17

Clarification question The system must provide statistics on application information and generate report on status and priority of applications. Please clarify that this is expected to be a software statistics report or a deal application report. NG currently runs audits logs from a software perspective, but additional clarity will be required to understand which metrics are expected.

Response:

- TDHCA expects this capability to focus on business and operational reporting related to multifamily applications. It is intended to support program and application monitoring and management.

41. ESBD_521962_1780494597214_Attachment D - Multifamily System Requirements.docx Section Compliance – Bullet 10 Clarification question There is an item regarding “travel optimization” and “risk-based scheduling” in compliance. Can TDHCA define the criteria and scoring model for risk-based scheduling and whether the vendor is expected to design this model or implement an existing one?

Response:

- TDHCA currently utilizes an Excel-based scheduling and travel optimization module to support compliance monitoring activities. The selected vendor may propose an approach to integrate this functionality into the proposed solution or provide equivalent or enhanced capabilities within the system.

42. ESBD_521962_1780349173039_Multifamily System RFO_Final w vethub 6-1-26.pdf;

Section / page Terms and Conditions. Section / Term 59.

Clarification question Please clarify if this solicitation is intended to be a Work Made for Hire Agreement?

Response:

- TDHCA is open to solutions based on either a custom-developed approach or a commercial off-the-shelf (COTS)/pre-existing platform.

For solutions involving custom development, TDHCA expects that project-specific work products and components created specifically for the agency under the resulting contract will become the property of TDHCA.

For solutions based on a respondent's pre-existing software, COTS products, SaaS platforms, or other technology, TDHCA recognizes that ownership of the underlying software, platform, frameworks, and other pre-existing intellectual property will remain with the respondent. In such cases, TDHCA expects to receive the rights necessary to use, access, maintain, and support the delivered solution.

Respondents should clearly identify any proprietary or pre-existing components included in their proposed solution and distinguish them from project-specific deliverables and customizations.

43. Regarding Exhibit F - What is meant by "Actuarial Services" in this questionnaire?

Is the subcontracting plan evaluated as a scored criterion in the proposal evaluation process, or is it reviewed solely based on qualifications and responsiveness?

For HCS, CMTS, and MITAS, do the systems provide APIs for the integrations?

Response:

- Please refer to question #1 for response on Actuarial Services.

- HSP is not part of the scoring criteria. However, the HSP form is required to be completed and submitted.

- Respondents can assume an API-based integration is possible with the mentioned systems. Please refer to earlier questions for more detail on external systems and integration.

Answers to Questions from Potential Proposers