Mortgage processes are by far the most complex specimen of the retail banking BPM solution family. These processes can amass more than a thousand variables, dozens of automated legal documents and also several sub-processes. Covering most of the possible ramification the commercialization of mortgages can have, the BPM project time line of such an undertaking can extend to some 2 years and sometimes even more.

With the objective of optimizing implementation budgets and project extensions, savings due reutilization can be achieved by either utilizing personal– and specific car loan process components as process base templates for a mortgage BPM solution or by using an automated mortgage process in turn for later retail banking processes, depending on which processes you automated first. In any case, when retail banking processes are to be automated, a holistic vision is required when accumulatively and progressively adding new BPM solutions into production, making sure that features, forms, integrations, reports, design and handling of all retail processes among each other are fully compatible, hence allowing for process re-utilizations of perceptible degrees.

More often than not have we encountered situations were each BPM implementation represented only a narrow part of the company operation as whole, limited buy rigid departmental boundaries and therefore causing not only a lack of encompassing insights but also that process components had to be completely re-worked for each new retail banking BPM implementation, whereas otherwise components such as Core Banking integrations, KYC, AML, credit scoring and many others could have been completely inherited from previous implementations.

Besides the typical process divisions detailed all retail banking BPM solutions, covering the TTY and TTC process components, the differentiation between both component types is gaining with mortgage processes a whole new dimension to be taken into consideration: time.

While personal loans, car loans and credit card processes are very short lived in nature (TTY to TTC don’t extend to more than 1 to 4 weeks), mortgage processes can be extremely long-lived. Process cases can span several years for new building constructions, for example.

In that sense, given the high process complexities and the sometimes extreme long incident cycle times, a good design practice for NSI has been not only the division of the overall mortgage process into  separated TTY and TTC processes, but to also terminate the incident life cycle of the mortgage request once the TTY process part has been concluded. After the lengthy construction phases have advanced enough, the original process case gets reactivated in the TTC process part accordingly.

That way a saturation of static incidents in the databases and reports can be circumvented, cluttering dashboards and KPI’s otherwise, sometimes even having effects on the overall BPM engine performance from technical point of view.

As a direct result of prolonged process times, regardless of the temporal incident “deactivation” after TTY, the concept of periodic credit reference checks and profile evaluations have to be tailored into the process designs. While it’s quite enough to check the requesters reference once in any other retail banking process, for mortgages – especially in case of constructions for new housing – the customer will have to be evaluated several times (usually per partial disbursement), as construction milestones are being met.

Common Process Components

Despite credit and risk policy diverging greatly for mortgage processes when compared with car- or personal loan processes, several process components and concepts do remain and can be re-utilized among retail banking BPM implementations.

So, we find here as well objects such as core banking integrations (read/write), legacy system integrations, AML checks, KYC reviews, FATCA and credit bureau integrations.

Collecting data to establish the requester’s internal (existing data) and external (lists and bureaus) profile and contrasting it with the request data itself, and emitting an initial request, product and customer profile score is also something – at least structurally – alike that automated retail banking processes share. The differences here lay within the policies themselves, reflecting different scoring equations, weights and parameters. The different policy layers of an automated retail banking process could be visualized and simplified as follows:

• Basic screening and pre-scoring, quote steps

• Complementary screening and final scoring, request steps

• Policy evaluation sequence per process component

 

• Policy evaluation in BPM during runtime – determination of customer type

• Policy evaluation in BPM during runtime – determination of product type

• Policy evaluation in BPM during runtime – customer and product type match

• Policy evaluation in BPM during runtime – determining policy set

• Policy evaluation in BPM during runtime – determining product exposure limits

• Policy evaluation in BPM during runtime – generating a requester score*

 

* The score in turn will be used for request decision making and loan amount adjustments.

The policy mechanisms in retail banking are indispensable element for an effective process automation. It pinnacles in a holistic credit scoring of the customer in correlation with the internal and external references, requested amount, banks product exposure and cross sales’ strategy.

This vertical sequence of policy evaluation steps typically takes place behind scenes in the retail banking process during the execution of the quote and request steps.

From a technology perspective it would be wise to evaluate incorporating the policy process features as hard coded and database fed web services in to the BPM solution, acquiring a credit scoring platform or opting for an iBPMS with a proven BRE engine, capable of handling the inherent policy complexities.

Unique Process Components

As mentioned above unique to the mortgage process are mostly its own variance of credit policies. In addition to these variations we can find a marked difference in process incident cycle times for retail banking processes, representing credit card processes the shortest cycle times while the incidents in a mortgage process face the longest times that on occasion can last for several years.

Among the unique product types that would have to be considered, exclusively for mortgages are:

1. New houses
2. Used houses
3. Private construction projects (with/without 3^rd party involvements such as developers)
4. Apartments (new/used)
5. Land sales
6. Collaterals and many other types

Taking these differences into account during process design times, it is more likely to encounter TTY/TTC separated processes for mortgages than for any other retail banking process.

Common mortgage processes are

Process Types

1. New houses and apartments
2. Used houses and apartments (policy differ greatly from first process type)
3. Construction projects
4. Land sales
5. Home improvements and collaterals

Macro activities (core process)

• Mortgage Quote:
  • Identify requester as customer and/or prospect
  • Basic credit background check and validation
  • Emit with minimal possible information an initial quote (loan type, amount and conditions based on desired car)
  • Identify if customer/prospect is apt and/or interested (capture data even if not apt for future purposes)
• Mortgage Request:
  • Refine and complete customer/prospect data
  • Refine and complete quote
  • If possible: negotiate and approve here
• Mortgage Review:
  • Intended for special requests, considerations and exceptions (rest should be filtered and routed automatically)
• Mortgage Approval:
  • If possible, automate through integrations with scoring systems
  • Manual approval for exceptions only
• Logistics + Formalities;
  • Gather signatures
  • Validate documents and policies
  • Insurance
  • Terms of payment and direct salary discounts
• Legal registries
• Construction control
  • Partial disbursements
  • Periodical re-profiling and scoring
• Closure
  • Welcome kit
  • QA Step (activated for a definable % of cases at random)

Integrations (core process)

• BPM <–> Core Banking System
  • Read CIF
  • Create/Update CIF
  • Create/Update product
  • BPM <–> Blacklists
    • Internal and external (like OFAC)
    • BPM <-> Other BPMS and/or processes (eg.: prospect exists not as a customer but as a requester in a mortgage process, about to be approved)
    • BPM <-> Other Legacy systems (Document processors, e-mail…), CRM and ERPs