Business Requirement

The bank wanted to have a unified platform to offer new products and services based on the customer’s borrowing history and have a single view of all the loan account details and the documents submitted by him.

Problem Statement

The bank faced high operating costs due to a highly complex, tightly coupled technology environment that had been created in-house and absorbed through a series of acquisitions of other mortgage providers. The IT landscape consisted of loan products on four different systems of record (representing the multiple mortgage lending business units the bank had acquired) and over 100 applications across multiple proprietary legacy technologies, many nearing end of life. The bank needed to retire over 50 applications, and to do so without affecting customers.

When it came to operations, each business unit had separate mortgage processes and systems, which required separate operational teams to support. Underwriting, loan onboarding, loan servicing, and other key mortgage processes varied whether a loan was with the legacy bank or one of its acquired firms. Customers were handed off between service providers who had only a limited view of the customers’ interactions with the bank. The experience was disjointed, and the lack of visibility made it more difficult for bankers to offer new products and services based on the customer’s borrowing history.

Approach

The first step was to deliver a set of system APIs to unlock access to internal systems of record and decompose monolithic web-service functionality of external vendors into fine-grained services. The bank began to realize value almost immediately. As the next set of developers began to self-serve the system APIs, they were able to easily bundle the APIs together to orchestrate mortgage processes. Many system APIs such as loans, borrower data, and documents were reused for multiple processes such as aggregating a customer’s loans or assessing the customer’s creditworthiness.

Mortgage processes were also packaged into discrete units. They manifested as process APIs. These process APIs were then consumed by all customer, employee, and partner-facing applications that were directly involved with mortgage servicing or with complementary functions such as accounting and credit risk management.

The resulting asset inventory was also significant. Not only did the project team directly benefit from the reusable assets, some of the assets were reused by a number of other teams across the bank, which signaled the early emergence of the bank’s application network. For example:

• Retrieve loan account details API: This API allowed loan information to be consumed by applications built directly for the bank’s customers and customer-servicing groups, and to meet regulatory reporting requirements.
• Documents APIs: These APIs enable all electronic documents to be tracked and located. While initially built for mortgage loan documents, the bank recognized the APIs’ high potential for reuse by other functions. While initially built for mortgage loan documents, the bank recognized the API’s high potential for reuse by other functions; the APIs can also be used for difficult types of documents such as contract agreements, statements related to mortgages, check images, and other functions. As such, the bank subsequently spun off another project to rationalize document capture and processing across multiple lines of business into one solution.