Finding Optimal Price using Nomis Price Optimizer

The Company

Nomis Solutions, USA

The Project

Nomis Price Optimizer (NPO) is most-used pricing solution in retail banking. It consisted of optimization and forecasting engine that enables banks to create best-in-class, closed-loop analytics tailored to the unique needs and portfolio goals. The NPO is available for multiple line of businesses including Deposits, Lending - (HELOC, and UPL), and Autos.

Some of the features that it includes are

  • Monitor and analyze historical and ongoing portfolio performance.

  • Track and review standard metrics, including bank's own rates, competitive rates, volume, expected losses, and profitability

  • Build view of customer behavior using price, competitive factors, and customer, market, and product characteristics

  • Leverage proven Nomis predictive models.

  • Define your own inputs using industry standard, parameterized, product line specific profit models

  • Compare business-as-usual baselines to alternate scenarios such as what if a competitor rate changes

  • Determine a complete set of prices that will optimally achieve bank's desired business goals while satisfying constraints and operational pricing rules.

  • Create pricing scenarios with a primary portfolio objective depending upon the line of business

  • View optimized rates and recommended changes, along with the corresponding results, in scenario reports.

Tech Stack
  • Java

  • Scala

  • Jenkins

  • MySQL

  • JavaScript

  • React

  • AWS

  • Docker

The Challenges
  • It was difficult to have an NPO instance running on a linux/MAC instances for development purposes. The original product was developed on Windows machines and had assumptions in the entire codebase about the deployment platform. A new engineer may spend anywhere from 1-3 weeks to get a development setup running with little confidence on replicating the process.

  • The teams were not following any code review process. The team in India used to check-in to the develop branch directly without keeping other teams in other locations informed. This caused a lot of confusion in the entire Software Development Lifecycle.

  • The NPO release process did not follow a consistent release scheme. The use of non-standard branches, tags and merging techniques created lot more confusion and a lack of documentation and process made it hard to release NPO.

  • The QA team owned the release process. This posed issues because the development teams did not take responsibility of creating a release candidates for testing purposes.

  • The development teams had no visibility on how NPO is deployed in production. The DevOps team had their own way of deploying NPO (using Jenkins pipeline and custom scripts), which was completely different from how development team used to deploy NPO during development, which was also different from how QA team would deploy NPO for testing purposes. None of the teams working on NPO were aligned because there was no consistent pattern to deploy an instance. Each of the teams were working in their own silo.

  • The software upgrades were owned by Engineering Services team. They are not the team who built the software, but they will fiddle with the product based on a wiki written by engineering team and make their best effort to upgrade a NPO instance for the bank. The wiki provided little to no direct information on "how to" upgrade an instance. As a result, upgrading a customer instance could take anywhere from 12-14 weeks depending on the current NPO version a customer is using. Overall, NPO as a software did not had an upgrade facility baked into the product.

  • Lead the NPO product from backlog to deployed instance. This involved working with multiple teams such as Product Management, Engineering Services, QA, Customer Success to prioritize what the development team should work on.

  • Design, develop, debug, and test NPO features. This included enhancing existing features or new features requested by the banking customers.

  • Made the NPO consistently installable across all platforms. Documented all the steps along with necessary automation in place. Worked with developers and QA to follow the steps and verify if they could install NPO on their machine. This reduced the time to install from weeks to less than 40 minutes.

  • Conducted stand-ups, sprint backlog, and retrospective meetings on a regular cadence to bring visibility into where the product development is headed, it's current status in the sprint, and what things are working/not-working in the process.

  • Worked with DevOps team to learn the entire NPO deployment pipeline. Documented and conducted training to align all remote developers and QA members.

  • Created a DevOps pipeline for the team to deploy their changes using Jenkins and AWS instances. This way code reviewers could see the code and a running instance at the same time. This speeded the code review process and took away "works on my machine" statement.

  • Set up a Design Review process. Every change must be first design-reviewed by the entire team before its development starts. This promoted visibility, education and engagement at all levels with in the developers and QA.

  • Set up a Code Review process. Every commit to the develop branch is now reviewed by senior engineers. Documented the guidelines about what to look for in a code review and how to respectfully communicate the feedback and engage in meaningful discussion.

  • Set up a process for NPO release and now engineering team owns the responsibility. The process is documented, reviewed, communicated and aligned with everyone who touches NPO codebase. This has helped the team to deploy multiple release candidates in a day.

  • Conduct interviews with-in Engineering organization for Developers, Engineering Managers, QA engineers, and Product Management.

  • Communicate with E-staff about NPO development roadmap, the challenges, risks involved and plans to mitigate them.

  • Owned and led the responsibility for NPO software upgrade and delivered an automated rule engine to upgrade configuration per customer. The solution worked on a developer's machine as a command-line utility. It generated a newer set of configurations with an audit file that provides visibility on what changes rule engine performed. The solution was then integrated with-in CI/CD workflow to upgrade a customer in less than an hour and it consistently produced same results for same inputs. To arrive at this stage, a change management process was set up between multiple teams and the process was agreed upon by all the stakeholders.

The Impact
  • The remote teams are aligned in development processes. They communicate better, develop together and deliver features in collaboration.

  • There is one way to deploy an NPO instance and all the teams working on NPO are informed, and they contribute to improve the system using process and automation.

  • The NPO development process is standardized. This includes Design Review and Code Review Process.

  • The release process is standardized and owned by engineering team.

  • The NPO upgrade process has cut down time taken from weeks to an hour. This frees up the time from Engineering Services to focus on new implementations. They work on testing upgraded instances and no longer required to upgrade the instance since engineering teams owns this responsibility.

  • The QA teams get the release candidates deployed using CI/CD pipeline. They focus on testing the NPO and not on creating the release candidates as this work is owned by developers.

Team Structure

NPO has been in existence for almost 15 years and have been worked upon by various people at different parts of the world. The team structure at the time of my tenure was

  • India → 4 developers, 3 QA

  • Belarus → 4 developers, 1 QA

  • California → 2 developers, 3 QA, 1 QA Director, 1 Product Manager, 1 DevOps, 1 VP Engineering, 4-5 Engineering Services (who would deploy and upgrade the NPO instance in collaboration with DevOps).