The world’s second-largest bank by market capitalization headquartered in San Francisco, California provides services across community banking, wholesale banking, as well as wealth and investment management.
Competitors in the small and medium-sized business lending space were outpacing the client–taking away market share through the speed of fund distribution. In an industry with shrinking margins and increasing commoditization, the client determined that legacy architecture and slow loan approval process were making the loan product uncompetitive.
Excessive loan review times, manual data re-keying, as well as an opaque risk evaluation engine, were contributing to loan approvals taking four to six times longer the industry average. The business had to request IT for continued support because the risk evaluation rules were embedded directly in a Fortran codebase. The inaccessible rule engine prevented the business from improving the loan offering and identifying new products opportunities.
The opportunity: Introduce a reliable, automated loan decisioning engine that would handle eighty percent of the business, allowing the teams to focus on complex exception handling in the remaining twenty. Reducing manual tasks, improving processing transparency, and enabling enhanced analytics were secondary objectives that would drive a competitive advantage long-term.
The Devbridge team identified all personas using the platform and created journey maps together with the stakeholders at the bank. From underwriters to funding analysts, to account representatives–the team identified major frustrations, goals, resources used, and typical daily workflows. Areas of risk, opportunity, and challenging technical dependencies were lifted into non-functional requirements. Upon review of workflows, the cross-functional team identified the three pillars of the product charter:
Improve rule modeling and authoring
Automate 80% of loan decisioning
Introduce workflow and queue management
For rule modeling and authoring the Drools open source engine was selected, providing the best combination of off-the-shelf functionality and unlimited extensibility and customization. It was important for the product team to not only move the rules out of legacy code but also to create a user interface that was accessible for non-technical users–removing the IT bottleneck between business and risk modeling. Once implemented, the rule modeling engine would allow underwriters to not only visualize the decisioning workflow but also demonstrate how a specific loan application executed through a selected model.
The architecture of the application was designed with multiple lines of business in mind, allowing the client to scale the implementation as soon as the business would onboard their product specific rule set. Furthermore, the teams implemented configurable workflow management–the ability to route specific loans through multiple stages and needed personas. Each type of user had designated queues that would allow them to pick up pending loans and move them along the decisioning workflow when exceptions were raised. Due to the multi-tenant nature of the ecosystem, functionality was established that allowed users to lock a specific deal while data was being actively changed.
The application integrated into existing systems such as onboarding services, system of record, access control, KYC, sign-on, entitlements amongst many others.
Devbridge used a multi-stage product maturity model to demonstrate the feasibility of the product, as well as win alignment and buy-in along the way. The initial roadmap identified three product stages and funding gates–a proof of concept, a minimum viable product, and a feature-rich product. Due to the size and high complexity of the organization, Devbridge facilitated workshops and discovery sessions over the course of a month, followed by a three-month proof of concept build that was used to run user testing sessions. The technical feasibility of selected Drools engine was fleshed out prior to expanding the Devbridge footprint. A single small product team scaled to two large teams once funding was secured and the teams could progress to the minimum viable product.
In the next four months, an MVP was implemented, following by another three months implementing the feature-rich version of the platform. Finally, the footprint of the platform continues to scale to this day, adding additional business lines to the decisioning workflow.