Building a Next Best Offer system for Corporate Banking Clients using Machine Learning
Updated on
I have 14 years of experience in machine learning, including building and maintaining large-scale recommender systems and working with banking clients. Many interviews for ML engineering roles—especially in non–big tech companies—involve discussing how one would build a system similar to one already in place at the company. Such interviews typically assess the following skills:
- Translating a business problem into a machine learning problem
- Demonstrated experience working with machine learning systems in production
- Machine learning system design
Here, we walk through these skills using the example of a Next Best Offer system for corporate banking products—a recommendation engine designed to suggest the most appropriate product to offer a client at any given moment.
It Is a Recommendation System ...
At its core, the system needs to recommend the best offer for a client by ranking products according to their expected margin (EM). The expected margin is calculated as:
EM = max (over products) of (PTB × MGB)
Where:
- PTB (Probability to Buy): Estimated by a classification model.
- MGB (Margin Given Buy): Estimated by a regression model.
In some cases, a product with a lower probability to buy might be chosen if its margin is sufficiently high. This dual-objective naturally leads us to design two complementary models.
... but with a twist
Sales of corporate banking products are unique—they are predominantly done in person by dedicated advisors. This means that model interpretability isn’t just a nice-to-have; it’s essential. If we send a senior Corporate Bank Advisor a recommendation that her main account should enter into a Forward Rate Agreement, she will undoubtedly as "Why?". And our answer cannot be “Because the AI says so”. Our answer must be clear and business-friendly. While techniques such as LIME or SHAP can help explain model predictions, they key is to understand the meaning of a feature - how it was built in the first place. So, the manual feature engineering is natural choice. In this scenario, neural networks lose their primary advantage of automated feature detection (like in computer vision) because we need to understand and explain how they came up with a given prediction.
Manually engineered features offer several additional advantages:
- Incorporation of heuristics from veteran sales people - these are typically the strongest features
- Quick isolation of problems during production incidents
So in summary, we will go with manually engineered features, and any model from the GBDT Big 3 family (as the overwhelming evidence for tabular data suggests). Light GBM seems to be the fastest among them on a standard CPU setting.
This Is a Data-Centric Problem, Not a Model-Centric Problem
The biggest risk in any ML project is ensuring that the data we have—both at training time and at inference—contains the signal necessary to predict the target. For tabular data, a model like LightGBM (LGBM) with out-of-the-box hyperparameters can quickly reveal whether the signal exists. If the data doesn’t carry the necessary information, no amount of modeling will help.
How to De-Risk the Project
Understanding what drives the sale of each product is crucial. I recommend a three-step approach:
- Familiarize Yourself with the Product: Do your own research on the range of corporate banking products.
- Talk to Sales People: Leverage the deep domain expertise and heuristics that seasoned advisors have developed over the years.
- Translate Insights into Features: Convert these ideas into quantifiable features and verify that the necessary data is available both during training and at inference. For example, if your system is updated daily, make sure your features account for any data delay.
Below is an overview of typical corporate banking products available in the market:
Corporate Banking Products
| Category | Products |
|---|---|
| Cash Management | Virtual Cash Pooling, Multi-currency Cash Pooling with Interest, Actual Cash Pooling, Sweeping Topping, Virtual Consolidated Account |
| Accounts | Current Account, Settlement Account, VAT Account, Custodial Account, Virtual Accounts, Housing Custodial Accounts |
| Payments & Settlements | Payment Service Providers, Swift MT101 Service, Domestic Transfers, International Transfers, Mass Payouts, Direct Debit Orders |
| Cards | Corporate Card, Corporate Executive Card, Prepaid Debit Card, Visa Business Debit Card, Metal Credit Card, Silver/Gold Business Credit Cards |
| Terminals | Payment Terminals for Public Entities, Cash Deposit/Withdrawal Terminals |
| Financing | Revolving Working Capital Loan, Non-revolving Working Capital Loan, Ecological Loan, Technology Loan, Investment Loan, Municipal Bonds, Multi-purpose Credit Limits |
| Trade Finance | Bill Discounting, Collection Services, Letters of Credit, Bank Guarantees, Bill Endorsements |
| Treasury & Derivatives | FX Forward, FX Swap, FX Spot, Currency Options, Interest Rate Swaps, Interest Rate Options, FRA, Commodity Options, Commodity Swaps |
We need to deeply understand the client motivations for any of the product that we want to build model for.
Feature Engineering
As we've argued above, manual feature engineering is the backbone of the Next Best Offer system. Understanding client behavior and market dynamics is essential to driving product sales. For example, let’s consider the case of an FX Forward product.
FX Forward: Product Key Features
| Feature # | Description |
|---|---|
| 1 | Negotiated forward exchange transaction for convertible currencies |
| 2 | Executed in non-cash form at a forward exchange rate, starting no earlier than the third business day after conclusion |
| 3 | Can be settled on a specific date (FX Forward) or within a specified date range (FX Forward Time Option) |
| 4 | Settlement can occur through physical delivery of currency or by payment of a net settlement amount |
| 5 | Helps businesses hedge against currency exchange rate risk, ensuring more predictable future cash flows |
| 6 | Reduces potential negative impacts of foreign exchange volatility |
FX Forward: Feature Engineering Ideas
| No. | Reasoning | Feature |
|---|---|---|
| 1 | Identify clients with significant foreign currency transactions who may need FX risk protection | Total foreign currency transaction volume over the last 3/6/12 months |
| 2 | Clients with high exposure to currency fluctuations may require hedging products | Ratio of foreign currency transactions to total transactions |
| 3 | Sudden increases in foreign currency inflows could indicate emerging FX risk exposure | Growth rate in foreign currency inflows (MoM/ QoQ) |
| 4 | Sharp increases in foreign currency outflows might signal a need for hedging strategies | Growth rate in foreign currency outflows over recent periods |
| 5 | Seasonality in foreign currency transactions could create predictable periods of FX risk | Seasonal pattern indicators (e.g., quarter-over-quarter differences, seasonal peaks) |
| 6 | Historical currency volatility can influence the appeal of forward contracts | Average volatility of relevant currency pairs (e.g., standard deviation over 3/6/12 months) |
| 7 | Frequent short-term cross-border transactions suggest ongoing FX needs | Transaction frequency in foreign currency (number of transactions per month/quarter) |
| 8 | Clients who have used hedging products before may be more likely to use FX Forward | Previous hedging product usage (binary indicator or count) |
| 9 | A client’s credit standing can affect their capacity and eligibility for hedging instruments | Client credit rating or internal risk score |
| 10 | Industries with high import/export exposure often need FX risk mitigation | Industry classification (e.g., manufacturing, wholesale trade) |
| 11 | Large short-term foreign currency debt may drive the need to lock in exchange rates | Outstanding foreign currency-denominated liabilities |
| 12 | Sustained growth in multiple foreign markets indicates an ongoing need for FX hedging | Percentage of revenue from foreign markets and its growth rate |
| 13 | Upcoming international contracts or expansions may require hedging | Pipeline of documented future foreign currency commitments (e.g., purchase orders) |
| 14 | Longer cash conversion cycles in foreign currency may necessitate forward contracts | Average days of foreign currency receivables/payables |
| 15 | Impact of past recommendations on FX product uptake | Previous product offer history and acceptance rate |
| 16 | History of significant currency exchange losses may drive hedging needs | Historical foreign exchange losses over past periods |
| 17 | High transaction values can yield greater benefits from hedging | Average transaction value in foreign currency |
| 18 | Strategic plans for international expansion may increase hedging requirements | Documented strategic plans for international expansion |
| 19 | A high number of international suppliers can elevate FX risk exposure | Number of international suppliers and their transaction volumes |
| 20 | A high number of international customers can elevate FX risk exposure | Number of international customers and their transaction volumes |
| 21 | History of using financial derivatives may indicate affinity for FX Forward | Usage history of other financial derivatives (e.g., options, swaps) |
| 22 | High levels of foreign currency reserves might reduce the need for hedging | Level of foreign currency reserves held by the client |
| 23 | Significant foreign currency receivables may require protection against depreciation | Level of foreign currency receivables |
| 24 | Significant foreign currency payables may require protection against appreciation | Level of foreign currency payables |
| 25 | History of currency speculation may signal a propensity for FX Forward usage | History of currency speculation activities |
The above long list of ideas can be a starting point for a discussion with the sales team, when we validate and come up with new ideas. And yes, a table like the above needs to be prepared for EVERY SINGLE product you want to recommend. However, as you add more and more products, you will notice that features repeat the same patters, and so the number of unique querries to the database will be quite modest.
Modeling
With a well-defined set of features from tabular data, modeling becomes quite straightforward:
- Classification Model: To estimate the probability to buy, a LightGBM (LGBM) classifier with out-of-the-box hyperparameters is often sufficient.
- Regression Model: To estimate the margin given a buy, additional steps—such as outlier detection and target manipulation (e.g., log transformation)—may be required to mitigate the impact of anomalous values.
Evaluation
Before deployment, it’s critical that decision-makers trust the model. Two key factors help build this trust:
- Transparency: Stakeholders need to understand how the model works and the risks it entails.
- Performance: The model’s metrics should clearly outperform the current baseline—even if the numbers aren’t perfect—and be validated through A/B testing.
Evaluation Strategies
- Feature Importance: For each product (since separate models are trained per product), show that the most important features align with business intuition.
-
Classification Evaluation: Segment the predictions into 10 probability buckets and display a line chart showing the actual vs predicted purchase rate in each bucket. A positive correlation validates the model.
-
Regression Evaluation: Bin the target into 10 intervals and display the confusion matrix, highlighting that most observations fall along the main axis. The upper right-hand corner can signal potential for immediate cross-selling.
-
A/B Testing: Roll out the recommendations to a subset of advisors, gather their feedback, and compare success rates against the current approach.
System Design
In our ML system design, the architecture is structured around a monthly retraining cycle coupled with a daily inference routine to ensure that recommendations remain both current and accurate. Every month, a training virtual machine (VM) is initiated that extracts historical data from the data warehouse, loads it into an environment equipped with Python, LightGBM, and other necessary libraries, and then trains the model. Upon completion, the newly trained model is securely stored in a centralized model repository, and the training VM is decommissioned to optimize resource usage. Every night at midnight, an inference VM is launched to pull the most recent data from the data warehouse, retrieve the current model from the repository, and perform inference to calculate the best offers for each client. These recommendations are subsequently pushed into the CRM system, ensuring that corporate banking advisors are greeted with fresh, tailored offers when they start their day. This systematic approach not only ensures efficiency and scalability but also bolsters model reliability and business confidence through continuous, data-driven updates.
Conclusion
Building a Next Best Offer system for corporate banking products is about more than just sophisticated modeling—it’s about understanding your data, the products, and client motivations. By integrating interpretable models with carefully engineered features, you can develop a recommendation engine that is not only effective but also trusted by sales advisors. This data-centric approach de-risks the project and paves the way for measurable business impact.
Explore further insights on model interpretability with LIME and SHAP as you refine your system.
Happy modeling!