user_mobilelogo

Por Kay Winkler

 

Mortgage processes are by far the most complex unit 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 that 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, we have encountered situations were each BPM implementation represents 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 resulting in process components that have 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.

In addition to the typical process divisions previously detailed (retail banking process components), the differentiation within mortgage processes between both component types (TTY, TTC) gains 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 extremely 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 which normally result in the 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 requester’s 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 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 - 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

1st

  • Complementary screening and final scoring, request steps

2nd

  • Policy evaluation sequence per process component

3rd

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

4th

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

5th

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

6th

  • Policy evaluation in BPM during runtime – determining policy set

7th

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

 

8th

 

 

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

 

9th

 

* The score in turn will be used to 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 consider 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 3rd 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; Legal registries
    • Gather signatures
    • Validate documents and policies
    • Insurance
    • Terms of payment and direct salary discounts
  • 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