Customer Lifetime Value (CLTV) is the metric I think about most. In most financial institutions, it is calculated with a formula that looks clean:
Current Margin + Expected Margin from future purchases * Probability of purchases * Discount
Such a formula looks like a purely financial task: take revenues, subtract expenses, add forecast, get customer Value. This formula is fair for big data. But customers never live inside statistics, their relationship with your banking product changes several times a year (job changes, relocations, economic crisis and so on).
Since CLTV looks like an absolute model, it's used as a standard working tool. Here's CLTV at year-end, here's what we want next year. But I'm convinced that this metric is far more complex than this arithmetic arrow and it can show which clients need to be retained, what conditions to offer, where to set limits and how to evaluate the effectiveness of acquisition channels.
CLTV should be recalculated automatically and quickly to react to changes in customer behavior. If a customer started paying by card more often, went into arrears, stopped logging into the app, closed a deposit, got a change in credit rating, got a mortgage from a competitor, and I can come up dozens more similar triggers that should affect CLTV recalculation, because behavior after them affects future margins.
In financial companies customer data is most likely scattered across different places. For example, transactions and accounting sit in ERP and adjacent systems, risk in software for risk management, customer contacts in CRM, product economics in card, deposit, credit systems. Each system holds its own piece of customer information. And usually information from a neighboring department is not transparent to other departments.
Without combining these sources it's impossible to build a working CLTV model. Value in the moment won't be visible based on averages and historical coefficients and adjustments. That will work for retro reports.
That's why CLTV is not only a financial model, but also an IT task: integration of sources, stable connections and pipelines, unified rules for identification and customer management, data quality control, computing environment, monitoring, principles for recalculating the metric for different customers.
Core Systems Required for CLTV
To start working with CLTV you need data from at least four systems: financial, risk, customer and product. These are three viewpoints on the customer to see revenue, risk and cost of service.
Financial systems give the main information: revenues, expenses, funding costs, capital constraints. ERP and treasury are the places where data about real revenue, commission flows and cost of money live. In financial economics you need to calculate not only the cost of accrued interest, but also the cost of money used. If you don't connect funding cost and transfer curves by terms to CLTV, then the value of products will turn out inadequate.
Risk systems add data for calculating loss reserves, credit rating dynamics, probability of default assessment, exposure models. These indicators change expected margin. Two clients with identical revenues are not equal if one of them had a sharp drop in risk profile. If you don't connect risk to CLTV, then we won't be able to properly count expensive clients who bring expected loss.
Customer systems add the cost of customer interaction with the bank. CRM store data about onboarding channels, frequency and type of contacts, segmentation, churn, communication history. From contact centers and digital communication channels you can get information about how often a customer reaches out, which scenarios break for them, how much it costs to service them in different channels, the size of commission to a partner for customer acquisition. This way, you can calculate at what price the bank retains a customer, and therefore the revenue from them. We include this to properly evaluate service in segments with high support load and complex product behavior.
Product systems give information on granular unit economics. We can take here information about economics at the product level and each transaction. Here we'll see how much we earn from commissions, how much from interest, where operational costs lie, how elastic the dependency on tariff changes is. Without product detail, CLTV gets averaged out, and we lose information about which products pull value up and which down.
Building the CLTV Sandbox
After we've defined the sources, a question arises where we will calculate all the math. Actual CLTV is a high-load task. The IT department will work with massive JOINs, aggregation of large data volumes and regular recalculation. Unfortunately, this can't be done in production systems so as not to ruin their performance. That's why CLTV is separated into a dedicated sandbox.
Such a sandbox will have several basic requirements.
Performance. Calculation must fit into a time window to deliver data to business within expected timeframes.
Scalability. After first successful tests, the model will grow with new products, new variables, new data sources. Architecture must withstand expansions without regular overhauls.
Security. Financial and personal customer data participate in CLTV calculation, so access control, action audit and correct processing procedures are needed.
Monitoring and observability. If a pipeline fails or delays, this must be immediately reflected in the system, otherwise CLTV will be calculated on an incomplete set of variables, and business will start working with corrupted data.
The sandbox must receive ready parameters, not raw data. Heavy components must be calculated on the source side, in those departments that own the logic and data. Risk calculates reserves and ratings on their side. Treasury transfer curves and cost of money. Customer service itself calculates behavioral flags and service costs. Channels onboarding cost and partner commissions for acquisition. The sandbox receives this data calculated and assembles from it a unified customer record and final CLTV.
This approach will allow distributing the load on calculating complex components and managing the quality and timeliness of these parameters.
Data Quality as a Critical Infrastructure Issue
What I haven't mentioned yet and what can ruin all calculations is data quality. In parallel systems one and the same customer can have different IDs. Finance manages the customer by their ID from ERP, risk looks at the number from the credit system and so on. As a result JOIN doesn't work as expected, and because of crawling data CLTV calculates in fragments.
The ideal goal is a golden customer record in MDM. Here there will be a unique ID to which all representations in all systems are linked. But implementing MDM is a very expensive project, so you can apply an approach with pseudo-golden IDs. This will be a set of rules that glues identifiers from different sources into a universal customer key. This is a compromise that's needed to launch CLTV.
As I already said, data quality must be checked before entering the sandbox. Deduplication and validation must be solved before data acceptance. Preparation needs to be moved to the agent side. Standard procedures here will be: name normalization, elimination of duplicates, setting flags for missing data, aligning the update window, determining which of the repeating parameters is truthful.
Data problems are also typical: customer duplicates, missing fields, data appearance lags, contradictions between systems. Some of them can be overlooked if they're controlled by quality rules and metrics. The minimum set for CLTV consists of:
data completeness (number of parameters per customer),
match rate (how many JOINs trigger),
consistency of key indicators between systems
timeliness (time between event and its appearance in the sandbox)
the volume of variables per each customer is not so important
Required Roles and Team Structure
Since CLTV is built around constantly changing user behavior and regularly appearing new factors, for implementation of this approach you need to think through roles connected with this new work. My experience implementing CLTV usage in financial companies showed that it will be necessary to create the following roles.
Data Quality Lead. The person in this position is responsible for data quality and their validation rules. They determine how customer IDs are mapped between systems, and also control cleansing on the department side, monitor metrics and resolve data conflicts between departments. For this position SQL and data governance are important, and soft skills for communicating with data owners.
Development + Product Owner. This person owns the CLTV formula, the logic of calculating profitability from future products, cross-sell probabilities, comparing forecast with actual and formula calibration. The model updates together with the product lineup, tariffs and risk model updates.
IT Support. This can be several roles that provide infrastructure and pipelines. The responsibility of these positions is sandbox and agents, batch schedules, performance and availability monitoring, error elimination. Since CLTV is a high-load system, any failure or slowdown gives business outdated data, which reduces trust in the metric.
Analytics. As with IT support there can be several people here who translate CLTV results into business decisions. They take requests from CRM, products and finance, build dashboards and reports, do ad-hoc calculations and help find new applications for CLTV.
Implementation Pattern (Generalized Banking Example)
To implement CLTV at your place it's easiest to approach this in several steps.
First departments build calculation of components on their side. Risk department launches PD/LGD and calculates reserves. Treasury forms transfer curves. CRM and customer service collect data about customer behavior. Operational blocks and channels calculate service costs, partner commissions and onboarding expenses.
After which the sandbox receives clean data and calculates CLTV. In a regular batch the system collects data from all agents, does JOIN by golden or pseudo-golden ID and forms a unified customer record with a set of variables. After this calculation begins: current economics, probabilities of future products, expected NPV. The result is written to final tables.
After this CLTV usage begins. CRM uses the metric for retention and customer prioritization. Product teams apply the metric for evaluating promotions and tariff changes. Finance evaluates effectiveness of channels, partners and branches. Channels use data to justify investments in functionality and service. Risk takes CLTV into account when setting conditions and limits.
To the calculation system you need to add iterativeness. When launching new products, they need to be added to the model and probabilities calibrated. Changes in commissions and rates lead to updating unit economics. Regulatory changes require recalculation of reserves and FTP. It's also necessary to add regular comparison of CLTV results with actual earned money and based on results adjust probabilities.
CLTV Is a Permanent System, Not a Project
CLTV is an excellent tool that many banks and financial companies bypass. This metric shows the true value of customers and helps increase business efficiency. Its implementation requires preparation and introduction of new structures in business and setting up new pipelines for data exchange between departments. With successful setup CLTV quickly becomes the foundation for making business decisions.