ALTA Registry Standard Operating Procedures Ver 2.1

Click to enlarge

Standard Operating Procedures

Owner: ALTA Director of Business Development

1800 M Street, NW, Suite 300 | Washington DC | 20036

855-618-2582

www.alta.org

www.altaidregistry.org

Contents

Overview

This document describes the procedures for the operation and management of the ALTA Registry.

Scope

The scope of this document extends to the ALTA Registry website www.altaidregistry.org and the ALTA Staff assigned to its operation and management.

Organization

1. The ALTA Registry is an ALTA product authorized by the American Land Title Association ("ALTA") Board of Governors and its management is delegated to the ALTA Registry Committee and ALTA Staff.

2. The organizational structure of the ALTA Registry Staff and operations is detailed in Appendix A. ALTAs Committee structure is detailed in Appendix B.

Ownership

The ALTA Director of Business Development is responsible for the development and maintenance of this document.

Definitions

1. ALTA Registry. The ALTA Registry is an online database of Title and Settlement Agents ("ALTA Registry"). It is owned and operated by Title and Settlement Agent Registry, LLC ("TASAR") which is wholly owned by ALTA.

2. Data Providers. Data Providers are companies and law firms that perform mortgage closings and or issue title insurance policies, these are defined as Title Insurance Companies ("Title Underwriters"), Title and Settlement Agents ("Title Agents") and Real Estate Attorneys ("REA") and Title Underwriter Direct Offices ("Direct Offices"), collectively Data Providers ("Data Providers").

3. Data Consumers. Data Consumers ("Data Consumers") are companies that have entered into a Customer Licensing Agreement ("CLA") (see below). CLAs are available only to the following types of organizations involved in the mortgage lending industry:

   1. Banks and warehouse banks.
   2. Non-bank lenders.
   3. Technology companies that provide services to the financial service industry.
   4. Due diligence companies.
   5. Business process out-sourcing companies.
   6. Title Insurance Underwriter and their subsidiaries.
   7. Regulators.

4. Confirming Underwriters. Confirming Underwriters ("Confirming Underwriters") are Title Underwriters that underwrite title insurance policies issued by Title Agents and confirm data entered submitted to the ALTA Registry as part of the listing process.

5. Customer Licensing Agreements. Customer Licensing Agreements ("CLA") are agreements between TASAR and Data Consumers. These are agreements that govern access to the ALTA Registry data via user accounts. CLAs are to be executed by an ALTA VP and the underlying customer. A CLA is evergreen, however, where a subscription fee is required, payment of the subscription is to be made to obtain and or continue the level of access granted by the CLA.

6. Technology Companies. The ALTA Registry Director or Designee is responsible for the verification of Technology Companies extant relationships with at least one Lender and incorporate it in the CLA.

7. Record. A Record ("Record") is a data file in the ALTA Registry. Each Record is assigned a unique, systemically, and sequentially generated seven-digit identification number called the ALTA ID ("ALTA ID"). The ALTA ID is an identifier for a single, physical location.

8. Listing. A Listing is the publication of a Record in the ALTA Registry.

9. re:Members (formerly Impexium). re:Members (formerly Impexium) is ALTAs membership database. ALTA Registry data is managed and maintained by Data Providers and Confirming Underwriters through an re:Members (formerly Impexium) interface called the Registry Management System ("RMS"). re:Members (formerly Impexium) is out of scope.

10. Registry Management System. The RMS is accessed by Data Providers via the web address www.alta.org/registry.

Information Standards

1. Data Provider Information Consent.

   1. The ALTA Registry contains data that is available for a multitude of public websites such as Federal and State websites, public telephone directories and business websites. Data Providers have provided information with the explicit knowledge that it will be published in the ALTA Registry.

   2. When a Data Provider requests a Listing, a systemic, pop-up, click through screen contains the following message, which a Data Provider must acknowledge and agree to this to continue in the Listing process. "Please Review. This will submit the principal business location and all associated branches to the confirming underwrites. Check that you have selected all confirming underwriters and added all branch locations. By clicking the "Continue" button, below you acknowledge your request to be listed in the ALTA Registry".

2. No Confidential Information. The following data is not collected or published in the ALTA Registry:

   1. Non-Public Information ("NPI").
   2. Sensitive Personal Identifiable Information ("PII")
   3. Confidential Information ("CI").
   4. Sensitive Information ("SI").
   5. Financial Information.
   6. Health Information.
   7. Any information governed by Regulations and is not already public.
   8. Any information cover by Privacy laws.
   9. Any information governed by any form of Right to Be Forgotten regulations.
   10. ALTA Registry is available from the ALTA Registry Website and is not transported via physical media.

3. Data Fields. ALTA Registry Listing data fields, labels and data types are listed at Appendix C.

Hosting

The ALTA Registry is hosted in the Cloud by a third-party vendor, it is segmented from ALTAs own computer network.

Roles and Responsibilities

1. The ALTA Registry Committee ("Committee") is responsible for the ongoing operations of the ALTA Registry.

2. The Committee's purpose and scope is to seek opportunities to:

   1. Improve the Registry organization, structure, products, and services.
   2. Provide communication, training, and outreach to the land title industry.
   3. Engage with customers.
   4. Provide guidance and oversight to ALTA staff for the strategy, design, and maintenance of the ALTA Registry.

3. The Committee is also responsible for:

   1. Monitoring and reporting on the status of the ALTA Title & Settlement Agent Registry to the ALTA Board and membership.
   2. Make recommendations, as may be appropriate, to the ALTA Board of Governors.

4. The Committee has delegated the strategic and day to day management of the ALTA Registry to ALTA Staff in the form of the ALTA Registry Director who is responsible to an ALTA Vice President.

5. The ALTA Registry Director is responsible for the following:

   1. Product Management.

      1. Directs the complete product planning and execution of the ALTA Registry.
      2. Determines product life cycle from strategic planning to tactical activities.
      3. Oversees responsibility for project schedule, including product releases with phases and milestones.

   2. Product Development.

      1. Responsible for working with product customers to understand, curate, and document new ideas and articulate proposed features.
      2. Develops proposals for ALTA Board as appropriate.
      3. Defines the features and requirements necessary to deliver a complete product to market and leads the product team to success.
      4. Ensures that key feedback and requests are seamlessly integrated into product planning and development processes.
      5. Application security.

   3. Testing/Quality Control.

      1. Acts as primary resource responsible for quality control of the ALTA Registry including the Registry website, Registry Management System, ALTA database, resource content, on-boarding, and testing.
      2. Oversees employees responsible for technology and staff support.
      3. Participates in discussions and decisions on strategy, infrastructure operations, and user experience.
      4. Shares responsibility for currency and accuracy of ALTA Registry Management System technical requirements and related documentation.

   4. Documentation and Training.

      1. Responsible for development and maintenance of ALTA Registry Management System documentation including back office Job Aids, customer Job Aids, Registry FAQs, and related documentation.
      2. Works with outside website resource to manage/maintain the website presence for the ALTA Registry.
      3. Develop and maintain customer-facing overview and education materials.
      4. Works with the Vice President and HR staff to develop ongoing staff education on product enhancements and support.

   5. Marketing and Communications.

      1. Responsible for marketing and promotion of the ALTA Registry Management System.
      2. Facilitates the activities of the ALTA Registry Committee (ALTA leadership) with the Vice President.

   6. Ensures that key feedback and requests are seamlessly integrated into product planning and development.

   7. Conducts product demonstrations and oversees the development and delivery of all marketing communication content.

   8. ALTA Registry Analyst.

Data Collection

1. Data collection is initiated by Data Providers through the RMS. Access to the RMS is controlled through user controlled credentialling via ALTAs website, this credentialing is out of scope for this document.

2. Data Providers enter data into the RMS via a series of screens that guide the user through the Listing request process. This process and screen images are fond at Appendix D.

3. Once a record has been created and populated in the RMS the Data Provider then requests a Listing. This request triggers a systemically created email that is sent to those Confirming Underwriters that the Data Provider has selected to confirm its data and that it has an extant business relationship.

4. Confirming Underwriters access the RMS and review the data entered and either confirm or deny the Listing request.

5. On a nightly basis ALTA Registry is populated with data from the RMS via an automated nightly JSON file ("JSON Push"). A Record is Listed in the ALTA Registry when at least one Confirming Underwriter has confirmed the details in the Record.

6. A Listing must have at least one Confirming Underwriter's confirmation to remain in the ALTA Registry. Once a remaining confirmation is lost, that Record will remain in the ALTA Registry for a further 45 days, in an unconfirmed status, on the 46th day if the Record fails to be Confirmed it will be systemically removed and archived.

Procedures

1. Access Control. Access to the ALTA Registry is controlled as follows:

   1. Data Consumer Access. Data Consumer access is managed by a Registry role called ALTA Admin. ALTA Admin access creation is restricted to the ALTA Registry Director or designee.

   2. Vendor Access. See below.

2. Passwords.

   1. Access to the ALTA Registry website for Data Consumers with an extant CLA is via Username and Password entered on the home page of the ALTA Registry.

   2. Usernames are systemically restricted to the email address of the user.

   3. Initial passwords are systemically generated, sent to users via encrypted email and, are user managed subsequently.

   4. Password reset, either on initial access or periodically is not required. Initial passwords and password resets are sent to users via encrypted emails.

   5. Password standards are machine controlled and are restricted to the following:

      1. Passwords need to be at least 8 characters in length and must contain at least one of each of the following:
      2. Upper case characters (A-Z)
      3. Lower case characters (a-z)
      4. Numeric digit (0-9)
      5. Special characters (` ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] \ | : ; " ' < > , . ? /).

   6. Multi-factor Authentication of passwords and password changes is not required.

   7. ALTA Admins may view and append passwords of Customer Admins and Users.

3. Basic Operations.

   1. Data Consumers access to the ALTA Registry is defined in Individual Company Accounts ("ICA"). When a CLA has been executed by a Data Consumer an ALTA Admin with create new Company Record and within it a Customer Admin Record.

   2. The creation of new Customer Admin accounts is systemically restricted to ALTA Admins. Once created, a Customer Admin can create additional Customer Admins within its own record. Customer Admins can create Customer Users where access rights may not exceed their own, this is systemically controlled.

   3. ICAs allow for credentialed access to Listings with the following functions:

      1. Individual web searches without the Recapture routine.
      2. Data downloads in a manual Excel or XML export.
      3. Manual JSON file.
      4. A semi manual query JSON export controlled by a key managed by the Customer Admin.
      5. A Data Consumer may be granted access to the ALTA Registry for assessment and development purposes where a Non-Disclosure Agreement ("NDA") has been executed.

4. ALTA Registry Code Installation. The ALTA Registry Code is installed in accordance with the ALTA Registry Software Installation Guide. This guide is to be provided to external auditor in preparation for code audits.

5. Website Development.

   1. Website development is performed by outside vendors selected by the ALTA Registry Director, and allocated work on either an enduring or project by project basis.
   2. When enhancements to the ALTA Registry are required either in response to market demands or at the direction of Committee, the ALTA Registry Director or Designee will prepare a high-level specification document that describes the changes envisioned. The document will them be presented to a selected vendor for a time and materials estimate. The ALTA Registry Director or Designee will review response from Vendors and select the solution that represents the best value to the Membership.
   3. Vendor selection is made based upon prior experience on ongoing projects, industry reputation and business references and at the discretion of the ALTA Registry Director.

6. Registry Environments.

   1. The ALTA Registry environments are used for different purposes:

      1. The ALTA Registry is available to users from the ALTA Registry Production Environment ("Prod").
      2. Development and testing is performed in the Staging Environment ("Staging") where vendors and ALTA Staff test the solution and is segmented from Prod. Changes are migrated from Staging to Prod once the ALTA Registry Director or Designee instruction the vendor to perform the migration. Testing of the new solution will include regression testing.
      3. The environments are fully described in Appendix D.

7. Vendor Access.

   1. Vendor access is controlled by ALTAs IT Department in response to requests from the ALTA Registry Director or Designee. Access to Dev, Staging and Prod is granted by the ALTA Registry Director or Designee, where the vendor will be issued credentials to perform work through ALTA Registry Virtual Private Network ("VPN"). Vendor access may be granted as follows:

      1. Enduring Access. Enduring access is granted when it is known that a series of development projects and or ongoing development work is required by a specific vendor.
      2. Limited Access. Limited access will be granted for vendors performing limited scope and time projects.

8. Source Code Repository.

   1. The ALTA Registry uses the distributed version control system Git, in a Bitbucket repository. ALTA uses Bitbucket for collaboration and version control of the ALTA Registry source code for its day-to-day operations and collaboration with vendors; it is used to review and merge code and apply controls to read and write access. Access to the ALTA Registry instance is controlled by the ALTA Registry Director or Designee. Vendors selected to perform development and enhancements are issued credentials and must also be signed on to the ALTA Registry VPN to access the ALTA Registry servers and Bitbucket repository.

   2. Code Development Standards. All code development is to be implemented using the Registry Source Code Repository Best Practices Guide.

9. Software Development Life Cycle Process. Changes and enhancements are subjected to a Software Development Life Cycle ("SLDC") process that maybe managed and tracked using a List in SharePoint called Registry Change Management ("Registry Change Manager"). A flow diagram that illustrates this process is found at Appendix E. In summary, to begin a change and commensurate with the complexity of the change, the ALTA Registry Director or Designee takes the following steps:

   1. Opens a record in the Registry Change Manager and creates a project record and identifies who is the primary for the project.

   2. High level specifications are drafted by the ALTA Registry Analyst and a technical review approval is made by the ALTA Registry Director. From this review more detailed technical specifications may be prepared. The review may be iterative, where relevant factors include risks are discussed before the final detailed specifications are prepared. The final specifications are submitted to a selected vendor for scoping and pricing together with several rounds of Q&A. Once the vendor signals that it fully understands the changes it submits a detailed timeline and costs for development and implementation of the proposed changes. Once the vendor has completed programming and testing in Dev it requests permission to transfer the changes to Staging where it and ALTA staff may perform UAT. The vendor is responsible for regression testing. Once UAT is competed the ALTA Registry Director or Designee will direct the vendor to move the changes to Prod. Changes that are regarded as minor need not be subjected to the SLDC.

   3. Changes to the Production Environment.

      1. Changes to the Production environment are normally implemented outside normal business hours, or at the direction of the ALTA Registry Director or Designee.
      2. Commensurate with the degree and complexity of changes the ALTA Registry Director or Designee may perform subsequent testing in Production environment.
      3. Testing may include checks to ensure any changes made do not grant Customer Admins the same rights as ALTA Admins.
      4. The ALTA Registry is a mature application where Data Consumers are not normally notified of Changes to Production as most changes are incremental enhancements that do not impact the availability of the service as defined in extant CLAs. Where notification is deemed necessary the ALTA Registry Director or Designee would notify those Data Consumers that are impacted.

   4. Once changes have been migrated to Prod the ALTA Registry or Designee completes and closes the Project Record in the Registry Change Manager.

10. Server Requirements. The ALTA Registry Server requirements are found at Appendix F.

11. Secure Code Analysis. On a periodic basis or when substantial enhancements have been made to the code, the ALTA Registry Director is to subject the ALTA Registry code to a code audit by an independent auditor, obtain a report, review the report with the Vice President and, where agreed implement remediation. Periodic code audits are to be tracked in the SharePoint List called Registry Compliance Testing ("Registry Compliance Testing") and reports are to be saved as evidence.

12. Maintenance windows. When routine maintenance that impacts a Data Consumers accessing to the ALTA Registry website the ALTA Registry Director or designee may inform those Data Consumers impacted, when deemed necessary.

13. Security and Fraud Events. In the event of a security and or fraud incident that impacts Prod, the ALTA Registry Director or Designee is responsible together with the Vice President for reviewing the nature and extent of the incident. The review will recommend whether the extent of the incident is sufficient to warrant notification of users. When notification is warranted the ALTA Registry Director or Designee is responsible for the notification process. Notification may be made via email or phone; a record of the notification need not be retained.

14. Pandemic Response Plan.

    1. ALTA. ALTA operates with 40% of staff remote working as BAU. In the event of a pandemic all staff moved to remote working as BAU.
    2. ALTA Registry Committee. The ALTA Registry Committee meets via conference call as BAU.
    3. ALTA Registry Staff. All ALTA Registry staff remote work as BAU, the response to a pandemic is to operate BAU.

15. Business Resilience Plan.

    1. ALTA Registry staff operate remotely as BAU.

    2. In the event of an interruption of ALTA Registry availability the ALTA Registry Director is responsible for notifying constituents and initiating the establishment of service in conjunction with:

       1. ALTA Registry Analyst
       2. ALTA Vice President
       3. ALTA IT Manager
       4. DesignData.

Reporting and Monitoring

1. ALTA Registry Monthly Report. On a monthly basis the ALTA Registry Director or designee is to submit a monthly report to the Committee.

2. ALTA Registry website availability. On a monthly basis the ALTA Registry Director or Designee is to review the Executive daily detective reports from the prior month to monitor prior application availability, records of the inspection are to be maintained in a SharePoint List called Registry Performance Monitoring ("Registry Performance Monitoring").

3. Daily Update reporting. On a daily basis the ALTA Registry Director or Designee is to inspect their email in box for systemic emails and determine that the nightly JSON upload was successful. Records of these inspection need not be retained. In the event of an incomplete upload the ALTA Registry Director or Designee is to begin research as to the cause of the upload error and rectify. If an interruption lasts more than 12 hours and impacts a Data Consumers accessing to the ALTA Registry website or interferes with routine JSON updates, the ALTA Registry Director or designee may inform those Data Consumers impacted and a record is to be created in the ALTA Registry Compliance Oversight

4. The following reporting routines relace and retire the ALTA Registry Record Retention Policy and Procedure data 2018.

   1. Uniqueness of ALTA ID. On an annual basis the ALTA Registry Director or Designee is to produce a report of all Records in the Basic Download and inspect it for duplicate ALTA IDs. All discrepancies are to be reported to the ALTA Registry Director for review and where errors are detected reported to the Vice President.

   2. Public View Testing. On an annual basis the ALTA Registry Director or Designee is to produce a report of all Records in the Basic Download and from it a random sample of 10 records is to be selected. The ALTA ID of each selected Record is to be used in a Public anonymous search to determine if the Record associated with the ALTA ID appears, summary is to be created and saved as evidence in Registry Compliance Testing. All discrepancies are to be reported to the ALTA Registry Director for review and where errors are detected reported to the Vice President.

   3. NPI Testing.

      1. Although NPI and confidential data forms no part of the ALTA Registry Dataset there is a risk that a Data Provider might enter confidential data in one of the free text fields. To mitigate this risk, on an annual basis the ALTA Registry Director or Designee is check a download of the Basic Records and search for numbers that are formatted in the SSN structure.
      2. A report of the results of all testing is to be compiled and saved as evidence in Registry Compliance Testing. All discrepancies are to be reported to the Vice President.

   4. Testing results are to be stored in the ALTA SharePoint site and retained for a minimum of 3 years with testing started in 2018.

5. Office of Foreign Asset Control. ALTA is not financial services entity and as such does not perform OFAC checks on Data Providers or Data Consumers.

6. Privacy Policy. ALTA Privacy policy is found at Appendix G and is post on the ALTA Registry Website, https://www.alta.org/about/privacy-policy.cfm

Reference Documents

• ALTA Registry Software Installation Guide
• Registry Source Code Repository Best Practices Guide
• ALTA Computer and Technology Resource Usage Policy

Revision History

Date	Version	Action	By
12/14/2020	1.0	Published	ALTA Registry Director
1/25/2021	2.0	Amended Staging and Production environment descriptions Appendix D Added Server Requirements Appendix F	ALTA Registry Director
12/4/2023	2.1	New logos	Director of Business Development

Appendices

• A. ALTA Committee Structure
• B. ALTA Organization Structure – ALTA Registry
• C. ALTA Registry Listing Data Fields
• D. RMS Listing Request Process and Input Screens
• E. ALTA Registry Environments
• F. Software Development Life Cycle Flow Chart
• G. ALTA Registry Server Requirements
• H. ALTA Privacy Policy

Appendix A to

ALTA Registry Standard Operating Procedures

Version 2.0

In this guide

• Appendix A. ALTA Committee Structure
• Appendix B. ALTA Organizational Structure
• Appendix C. ALTA Registry Listing Data Fields V5
• Appendix D. Software Development Life Cycle Flow Chart
• Appendix E. Software Development Life Cycle Flow Chart
• Appendix F. ALTA Registry Server Requirements
• Appendix G. ALTA Privacy Policy