Statistically, we at Negocios y Soluciones Informáticas, NSI (http://www.nsisoluciones.com) found that Personal Loans Processes (PL processes) are often gateway implementations for banks first BPM initiatives, right beside Credit Card processes (covered in the previous article), mainly due to the seemingly rigid and replicable process flow structure and rules structure these processes seem to have.
While initially PL processes abide to the same basic structure we detailed in the preceding posts – you have a request step, review and approval steps, legal, insurance and contractual steps, disbursements and QA steps – proceeding with the detailed task and policy analysis of these processes as part of the BPM initiative, you will often find a surprising complexity consisting of multiple legacy system integrations, KYC policies, deep credit scoring ramifications, exception handlings and what we call complexity exponents that caused by processing several compounded personal loan requesters in a single process incident (all policies have to be applied for each individual separately and after that conjunctly). Hence PL processes can often take up to 4 man/months of project time to be fully automated. The results of the automation are usually impressive however, judging from working time savings standpoint alone…
Having automated close to 20 PL processes in the last 5 years alone, we observed that the average time to yes (TTY) portion of the processes could be reduced from some 43 working hours down to about 21 working hours per incident, comparing partially automated or completely manual processes against processes automated with BPM (both, BPMS and BPM methodology). The time to cash (TTC) portion of the PL processes could be reduced from some 132 working hours down to 73 working hours.
To put PL processes in context of Credit Card processes (CC processes) that we saw before, let’s have a look at the similarities first.

Common Process Components
Why is it worthwhile to compare similarities between process components in the first place? Same principles as SOA alignment in programming applies. You want to be able to re-use as many process components between your processes as possible, reducing error margins, implementation times and improving upon scaled “BPM” economies. The caution one would want to have is not to expose your processes to too many operational and technical risks, while “interconnecting” shared elements among them. Think about a policy change in a PL process forcing you to re-test your entire retail loan processes environment, because all policies have been stored and shared within a single point of entry. Try to account for a “healthy” balance of redundancy and process element separations, while perusing a BPM SOA environment.
PL process share the aforementioned TTY-TTC process structure when compared to CC process – or most other retail banking processes for that matter. At a closer look, you’ll also find shared components such as an initial “quick quote step” for engaging and pre-evaluating the customer, a more detailed PL loan request step to fill in the blanks once a customer has been id-ed as apt and interested, approval and committee steps with all the necessary core banking and credit scoring integrations – basically, most of the TTY components are similar to what you already saw in a CC process. Especially when working on automating retail banking processes, the credit scoring and core banking integration components of the solution should always be designed with all the retail banking processes in mind. Doing so may require a steep initial learning curve but it will be worthwhile for when such components are to be-reused during follow up implementations and process enhancements such as cross- and upselling among the different products.

Unique Process Components
One will find a vast amount of variances among PL processes, especially post approval (TTC), depending on the geographical region you find yourself implementing such a BPM solution. We came across interesting socio-demographic process adaptations that were tailored to flexibly and aggressively cater to markets such as micro credits (small amounts, decentralized, fast approval directly at a retailer), loans for retirees who benefit from a fixed pension, “fast track” personal loans that are backed by priority direct discounts from the recipient’s paycheck and many other flavors.
In that sense, the legal paperwork, required insurances, background checks and even the ways of disbursement itself differ greatly from each other, and absolutely from the way TCC process are structured post approval (you wouldn’t have a disbursement step, for instance).
In that sense, PL processes typically will have to be created from scratch for their TTC components, when compared to CC processes.
Following, a sample of PL processes you would typically face:

Process Types
1. Walk-In PL processes: That’s your typical scenario of an interested individual (existing customer/prospect) through the banks various channels. In case it’s a prospect (not an existing customer), try to keep the customer onboarding, KYC and account opening processes integrated but separated from the PL process itself.

2. Pre-approved PL: Usually, starting from the bank’s core databases, creating filtered customer subsets that fit specific product promotions. One of the most notable differences to the walk-in variant would be that in a pre-approved PL processes, most of the process instances (incidents) are being processed as massive batch files and not 1×1. Once all established filters and policies have been applied to those batches, all resulting incidents typically get inserted into the PL walk-in core process for now contacting each of the pre-approved customers individually. If the customer’s response is positive, all approval steps will be skipped, invoking the TTC portion of the PL core process automatically.

3. Micro PL: This process structure is normally exactly as the core PL walk-in process structure (almost everything can be re-utilized), with the exception of rules and policy simplifications. Also the request-able loan amount is capped off at a lower maximum than at a “normal” walk-in process. That makes the process suitable to be enabled for the banks external sales channels.

4. Cross Selling: The cross selling PL feature, abides to structure, outlined in our CC process post:

• a. Mortgages -> Personal Loans + (and/or) Credit Cards
• b. Car Loans -> Personal Loans + (and/or) Credit Cards
• c. Personal Loans -> Credit Cards

So, the PL process could serve a cross selling originator for Credit Cards or be the recipient of incidents originated from Mortgage or Car Loan processes.
The PL cross selling process (recipient) supposes that the TTY portion of the PL evaluation already took place at the originating process and only covers the TTC steps till loan disbursement.
As the following paragraphs reiterate, CC processes and PL process are very alike, when it comes to the request and approval steps (TTY) and required core and legacy integrations:

Macro activities (core process)

• PL 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)
• PL Request:
• Refine and complete customer/prospect data
• Refine and complete quote
• If possible: negotiate and approve here
• PL Review:
• Intended for special requests, considerations and exceptions (rest should be filtered and routed automatically)
• PL Approval:
• If possible, automate through integrations with scoring systems
• Manual approval for exceptions only
• Logistics + Formalities;
• Gather signatures
• Validate documents and policies
• Loan Insurance
• Terms of payment and direct salary discounts
• Disbursement
• Closure
• Welcome kit
• QA Step (activated for a definable % of cases at random)

Integrations (core process)
As mentioned above, there are several different integrations from and to the BPM Credit Card Solution to be considered. Among the most common ones we have:

• 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

Next up – “Car Loan Processes”

Follow