Creating New Title Insurance Systems

In the 1990s, we joked about the title insurance vending machine, and it’s taken a while, but we’re closer than ever before. In 2018, the title insurance industry is gearing up for new technology, from hybrid closings and eClosings to AI title examining. The searching function in other countries is already embracing blockchain technology, and our own Cook County Recorder made an attempt to close a transaction and record the conveyance in blockchain, which was successful, but for the limitation of our Illinois statutes on notarization and recording.

The current state of title technology, bringing the companies firmly into the 1990s, makes me think about what it takes to create new systems. In the early 2000s, I bowed out of title for a while and worked as a systems analyst at Hewitt, a large benefits consulting firm, now AON. Here are my thoughts on systems analysis for title insurance systems, but before I get to that, I’m going to describe on a very high level, the difference between current systems and blockchain.

Current Systems Based on Databases

Current systems are based on databases that can be thought of as tables containing data fields. Think of an Excel table with columns representing various types of data such as name, address, property tax identification number and rows representing all the different data fields for each person or property. Each cell of the database represents a particular piece of information for a particular subject, be it a person or the property, or any individual aspect of the property such as real property taxes, legal description, purchase price, mortgage lender, or any title exception.

Relational databases were all the rage when I was programming because they’re cleaner and more efficient and less prone to error. The user enters any one data field only once. Then, the data field is used throughout the system, not by re-copying or re-entering the data into multiple tables, but by pulling data fields into various parts of the system by reference to a key in the table where the date field resides. For example, if you were going to put a title commitment in its entirety into a database, you’d have tables for the information needed for your particular file, and then separate tables of all the possible title exceptions that get pulled together by relating the tables using a key.

Databases are used in two basic ways. There are user interfaces, mainly forms, used to enter data into the database, and screens and reports that pull data from the database for various uses. Once such report might be a marketing reports that tells the company information about customers like how many orders they made in a month and how many orders closed. In the case of title, a digitally generated title commitment generated from tables of customer, lender, property and title exception information is also a type of report.

These databases, full of various tables, are centralized on large central servers. They have to be protected from hacking, so no one without authority can enter data or pull data from the databases.

Enter Blockchain

I had trouble really understanding blockchain technology until I thought about how it differs from systems created from databases. Blockchain eliminates database tables, and centralized servers and replaces them with decentralized blocks of data that represent transactions as opposed to data fields. The blocks are verified and protected through a system of hashes. If any block is changed in the slightest way, the hash changes, so users know it’s a completely different block. The blocks are somewhat relational in that subsequent blocks make reference to the prior block. For example, the block where Jane Smith purchased her property would be referenced in the block where Jane Smith sold her property.

Blockchain is decentralized. The blocks do not exist on centralized servers. Identical versions of the blocks exist on many nodes existing throughout the world in some cases. The security lies in each node containing identical, reconciled, processed and verified transaction information. Unverified blocks fall by the waste side because the nodes are given incentives to choose only good, verified blocks. Transaction blocks are processed 24/7 while centralized database information is typically verified and uploaded to the main database in large batches at specified times.

Whether the industry decides to use blockchain technology, stick with databases, or use both depending on the function might depend on whether or not the industry is ready to switch from thinking about itself it terms of data fields that apply to people and property or transactions among people and properties.

Analyzing for New Title Systems

If you’re going to create a new system whether you are using databases or blockchain, you are going to need user interfaces and the ability to create reports. You figure that out by analyzing your system. Systems analysis is the process by which you study and break down your processes so you can transfer them to computer logic. It requires understanding of your workflows, problem identification and problem solving.

When creating your system, whether you are using databases or blockchain, you should engage in systems analysis of your entire process. There are basic concepts to incorporate into your analysis. Here are a few:

1. Talk to your users. The entire field of systems analysis is about communicating with users and creating systems that fulfill user needs and steer users to fulfill company needs. Find out what data they need and when do they need it and make sure your system provides that data.
2. Have goals. Think about what you are trying to accomplish after talking to users. The goals should be based on company and user needs. For example, if you want to further automate title examining, digitizing all of your title exceptions is one goal, and making sure the format conforms to current title commitment forms that the user has to produce is another goal.
3. Communicate your goals. If you make a change to the system that affects users, let them know what they received for all the work and headaches of learning a new or revamped system.
4. Users can be both internal and external. Your customers are you ultimate user. You want to make it easy and even fun (if possible) to order title or schedule a closing. But, don’t forget your internal users. Internal users should be given a functional and satisfying experience. It helps with customer service and employee morale. Serving the employee user serves the customer.
5. Think about adding knowledge banks. While customers are using your system, they might want to pull up information about using the system. Most systems have systems help functions explaining how to use the system itself, and its expected now, but wouldn’t it be even more interesting an and more helpful if the customer could also pull up examining and underwriting information at the field related to the information. For example, if an owner dies, the correct title finding is the “heirs at law and/or devisees of [name of owner].” I think it would be very helpful to the attorney or title examiner to be able to click on the field or a button near the field and pull up all the underwriting requirements for decedents’ estates. Remember, one day, if not now, the examining and underwriting rules will execute automatically. If you add the information now, you’ll be ready to analyze those systems for implementation.
6. Think about standardizing outputs and eliminating open fields that have to be filled in. It may or may not be a good idea depending on your goals, but there are benefits. The more variables in each output or report (like a title commitment), the more work, inefficiency and room for mistakes. The output will seem less personalized, so the decision to standardize will relate to the experience you want to give the user.
7. Don’t aggravate users with deep click-throughs. When I was programming websites, the style was short webpages that fit on one screen without scrolling down, and links to click-through for more information. What a pain in the neck that turned out to be! Constant clicking for needed information takes a long time and is frustrating. Now, the style is to put more information on the page, even if it requires some scrolling to eliminate all that clicking, having to know where to click for what, and eliminates all the waiting when the system is slower and each click clocks until the system can process it.
8. Communicate your accomplishments. Each new software version should list its accomplishments the same as each version should be based on goals, and for similar reasons. Let the users know what they have now that’s different from before using specifics.