Case Study: iApply Loan Application Flow
This is an overview of the iApply loan application flow project I ran in my role as Product Manager at Leveraged.
The purpose of this project was to increase revenue, reduce the time lag between marketing spend and revenue generation, and grow the business by losing fewer customers in the funnel. We would do this by eliminating paper-based applications, reduce processing time drastically below 30 days, and increasing the number of first-time approvals. This would also help us remain competitive with other market participants moving towards same-day loan approval by 2026. Leveraged loan approvals at the time took more than a month, which was slow by industry standards. The estimated impact of this project was several million dollars in revenue which, if achieved, would reflect a noticeable inflection in growth.
This project was ultimately unsuccessful as the bank made redundant a large chunk of its technical staff, so I want to look at:
- The process I followed
- How I diagnosed the issues, evaluated that they were commercially valuable, and got buy-in
- How I circumvented issues that had derailed the project previously, and
- The end result
Thoughts and feedback welcome.
Background:
Leveraged, the margin lending subsidiary of Bendigo & Adelaide Bank (ASX:BEN), has an outdated loan application flow that had not been meaningfully updated for somewhere around 8-10 years. It was complicated, slow, and had high drop-off rates. Several projects to revamp it had previously failed & the reaction to another attempt to improve was somewhere between “lukewarm” and “actively hostile”. When I reviewed the (sparse) previous project documentation I found that it had not progressed past the “collect issues” stage with a couple of kanban-style boards and email trails. There had been no clear vision of what the future state looked like, which made the issues with the form difficult to integrate into a solution. I prioritised starting with the vision, but more on that later.
In terms of the form itself, there were multiple branching paths and lots of complex if-then scenarios that were not well signalled and made it difficult for a customer to complete. The overwhelming majority of customers who started an application did not submit, and of the handful of customers that did submit, over 99% of applications were incomplete and required additional follow-ups from the Operations team.
The organisation was still using “paper” applications with high-net-worth clients as this allowed a sales representative to work with a client to get the application filled out correctly. There had also evolved a practice of complex handovers (which I won’t go into as it’s commercially sensitive), but basically issues with the form had caused a number of unnatural side effects within the business as it attempted to work around these issues.
Tracking / Data collection:
The organisation did not actively track loan submission/funnel information, so it did not recognise that the submission rate had been steadily declining for the past 3 years and had halved since 2019 – previously it had been around the average for other loan flows across the bank. Parts of the information existed in several different systems, including paper records, and not all systems used the same application number (for example the loan application number in the application software was different to the loan number in the operations/credit review stage) so it was difficult to follow a loan from application to approval.
With some effort I measured the average processing time as around ~30 business days. I introduced the concept of “revenue-days” because the primary tracking was done in Operations which mostly concerned about throughput (“actions per business-day”), whereas interest is earned (or not earned) on every calendar day. For the purpose of improving the application we wanted to improve both revenue and throughput, and the processing time based on a typical trailing three-month period was around 42 revenue-days.
Being deliberately vague with numbers here but ballpark half of your customers will draw down within 90 days after taking a loan and the majority will draw down within 180 days. A small percentage “never” draw down (at least not during any commercially relevant window). When combined with the time to approve a loan, this means you are waiting something like 130 days to generate first revenue from half of your customers.
Lead time to revenue:
When you factor in that the application itself is complicated (requires documentation etc) and may take several days or weeks to be ready to submit, and then add on the lead time from advertising conversion, you’re looking at 9 months or more from advertising spend to generate $1 in revenue. This slows the velocity of the entire business and makes it hard to replenish lost/retired loans. Even without any improvement to growth, simply speeding up processing time of new loans pretty obviously had a value in the millions. (For the purpose of this project I calculated a year-1 payback figure, which I won’t share as it’s commercially sensitive, but what this showed is the ROI with very conservative assumptions was enormous, conceivably easily a 20-50x return on spend simply by reducing processing time, and much more if it increased loan submissions).
I also did a sanity check of the credit process and found it was robust. Around xx% of loans would be rejected for credit reasons which was around the standard for the bank, and notes on the rejected applications I reviewed showed they were clearly not creditworthy. Funny story: I had to jump through several hoops including seeking explicit permission from the Head of NSW to review the case notes, and I think this was positively received as it was literally the first time in history anyone had ever asked. I was checking that loans weren’t being rejected for being incomplete, but the credit and operations teams were both really good & had a solid working relationship where they would move a loan back into operations to rectify any outstanding questions with the customer rather than risk rejecting the loan and force the customer to reapply.
The vision:
The appetite for change was not large enough to redesign the entire system or change vendor. It was however large enough to “just make it work” which is the initial language I used in discussion with stakeholders. As I held workshops and informal discussions I highlighted the unnatural behaviours that the organisation was doing (“this seems really difficult”) and observed reactions, and then asked people “what does ‘make it work'” mean for you?
We settled on three principles which were “make it easy to complete, make it fast, and make it crystal clear so that the customer doesn’t have to guess.” I subsequently started every meeting by reminding everyone of those principles & used them when broadcasting through the org and they resonated well.
The process:
Now we needed to look at the causes of drop-offs and processing difficulties. There was no tracking within the form whatsoever, but you could at least see the last question that a customer answered, and operations manually tracked issues within every submitted application. Issues occurred primarily in three key places:
- Identity verification
- Statement of position
- Supporting documentation
100% of received applications had issues with at least one, and usually 2-3 of these, and they were a big driver of customer drop-off.
ID verification:
The online identify verification was unclear and had no error messaging, but it required the customer to correctly enter their legal name and information on several separate pages. For example you would enter your name e.g. “Jack” on the first page, but then on the fourth page you would enter your ID number 12345 which would check your Drivers License or Passport where your name might be “Jackson”. There were a lot of little issues like this where it was not clear that you needed to enter your correct legal name on the first page because that’s what would be used to check your ID on page 4.
Likewise the ID verification checked both the electoral roll and your chosen form of ID, but it didn’t explain to the customer that it was checking both. So if you’d moved house and updated your ID but not your electoral roll, it would reject ID verification but not tell you why – you wouldn’t even know it checked the electoral roll – and then you’d need to manually ID in a branch. This was obviously frustrating and it cost us customers as well as tying the team up verifying ID.
Statement of Position:
The statement of position was unclear in what it was asking for. For a loan application you need to provide absolutely everything; employment income, investment income, all expenses, all liabilities (credit card, HELP loan, BNPL, home loan), all assets (investment property, shares, etc). Failing to list any one of those would require the team to follow up and query it with you.
Additionally, the layout of the form was really unclear and not intuitive – much more like a spreadsheet than actual software. For example, if you’d listed on an earlier page that you earned dividends from investments, the statement of position would not recognise that, and you would have to enter that manually (whereas in reality it could be partly prefilled based on information you’d already provided).
This section came at the end of a form that was already 30 pages long and by this stage the customer was tired/bored – and this was the hardest section of the form by far. Again, it was a big driver of drop-off and consumed hundreds of man-hours of follow-ups from the operations team.
Leveraged employed a person full-time simply to call customers who dropped off during applications and coax them through to the end. Darren was absolutely brilliant, and as you’d expect a fount of insight; he’d spent 4 years on this and knew all the pain points inside and out. I spent a lot of time with him (and got his number when I left so I can hire him some day) but spending $100k on someone simply to help customers complete the application is another example of the unnatural contortions that had emerged in the business.
In terms of the form, there was no sensible grouping or automation to make it easier. For example if you had an investment property, you would have to make at least four entries manually:
- Rental income
- Expenses (insurance, maintenance etc)
- Asset details (property value, location)
- Liability details (list your mortgage, interest rate, mortgage provider, etc)
So if you had 3 investment properties you’d have to make 12 entries, plus all of the other entries for income, expenses, credit card etc etc. Most people couldn’t be bothered and literally nobody ever filled this out correctly. Ken Jackman the Sales manager had made a big push to improve this with his team, and when I was there, they had the first-ever “clean” application (no follow-up queries, straight through to approval) in something like 8 years.
Supporting documentation:
Lastly, the supporting documentation page was unclear. It was basically a single button where you had to upload all of your 20+ documents, but there were no prompts and no minimum requirements – you could simply click “next” and move on to the next page.
How this should have worked was something more like a box for each section based on information you had previously provided. For example, if you’d selected that you had investment properties, include a box to upload mortgage statements.
Solving:
At a high level the solutions were:
- Make the ID verification clearer. Show the provided name on the page, make it clear it was being checked against both electoral roll and your chosen ID records. Also provide clearer error messaging to the extent possible (being a bit vague here as there are several possible vectors for fraud if you include too much info in the error messages).
- Statement of position prefill based on information provided. E.g. if you indicate you have an investment property, prefill/pop out questions for you to enter mortgage value, home value, rental income and so on. Remove all possible instances of the customer adding entries to a spreadsheet.
- Documentation requirements based on information provided. E.g. if you’d selected options ABCD during the application and listed assets/liabilities WXYZ, ask specifically for the exact documentation e.g. “latest mortgage statement for property 1, property 2, property 3” rather than making the customer guess.
To get buy-in for these, I put all of the recommendations in a list and circulated it with the relevant teams in credit, operations, sales, customer service, and product. The list went through 3-4 rounds with these stakeholders, initially starting very high level and evolving into the exact specific change that would be made. Everyone had extensive opportunity to comment. In parallel I worked with the technology product owner to ensure these reflected the way that the changes would work within the iApply software itself (a drag-and-drop form builder) and could easily be turned into actionable initiatives.
Results
Unfortunately, after I left the organisation, Bendigo Bank conducted a layoff of several of its technology teams and this form was outsourced to [Firm] who wanted [$$$$$$$] per day to work on it with its offshore devs, which necessitated going through a complex funding process for approving the spend, and the project died.
The same issues still exist and are waiting for somebody to pick it up. Markets are not efficient, sometimes there is a million dollar note left lying on the ground.
No Comments