How a Next-Best-Action Engine Decides

Part 1 of 3 of our series on Next Best Action in Banking. The following two parts will cover deployment per channel (Part 2) and transaction data as the most important signal (Part 3).

Why "the single right action" is a math problem

For every customer on any given day, a bank has several possible next steps: a loan offer, a cross-sell for insurance, a reminder of an unused credit card, or simply no contact at all because the contact frequency limit has been reached. Next Best Action (NBA) is the approach that derives a single, actionable recommendation from this set of options for each customer and moment. Pega defines NBA as an approach that "combines artificial intelligence with real-time interaction data to create hyper-relevant customer experiences" (Pega). The difference to a classic campaign is crucial: "Campaigns are bank-centric and calendar-driven. Next Best Action is customer-centric and event-driven" (Backbase). Exactly this shift — from campaign waves to continuous micro-decisions — is also described by McKinsey's classification, according to which precision in retail banking must develop "from static segmentation to dynamic, real-time, hyper-personalized delivery" (McKinsey Global Banking Annual Review).

This decision cannot be made with a single rule or a single score. It is the result of four factors that must work together — and which an NBA engine like the one from Acceleraid combines in a structured way.

The four building blocks of decision logic

Propensity Scores. The first building block is the probability with which a customer will respond to a specific offer or accept a specific product. Unlike a single churn or cross-sell score, an NBA-capable Prediction Engine handles multiple product lines in parallel: current account, consumer loan, savings product, insurance, credit card. This multi-product propensity is necessary because banking customers are rarely "mature" for only one product at a time — so the engine must calculate not only whether, but also for what a customer is most approachable. Concrete evidence of the value of this approach: A multi-label model predicting ten event types for the next 90 days achieved a Precision@12 of 73% in a documented banking use case, making it eleven times more accurate than a heuristic baseline (Kumo.ai).

Lifecycle Phase. The second building block locates the customer in the customer lifecycle — acquisition, growth, maturity, or retention. An identical propensity score for a loan offer means something different in the acquisition phase than in the retention phase: in the first case, it is about initial contact, in the second, about retaining a customer at risk of churning. The lifecycle phase thus provides the context that turns a score into a meaningful action.

Channel Preference. The third building block determines where and how the action is delivered — online banking, app push, email, or branch. How differently channels work is most clearly demonstrated by push notifications: contextualized pushes achieve an open rate of 14.4% in the banking and finance sector compared to 4.19% for generic messages (Batch: Push Notifications Benchmark 2025). An NBA engine must know this channel impact and time and format the recommendation accordingly — details on this in the second part of this series.

Regulatory Guardrails. In the German and European context, the fourth building block is not optional, but mandatory. BaFin expressly demands "sufficient explainability" — in addition to the desired accuracy — in MaRisk AT 4.3.5 Tz. 6 for models with features of "technology-supported innovation and artificial intelligence" (BaFin, Circular 06/2024 (BA)). Tz. 2 also requires that the appropriateness and suitability of a model be assessed before use and reviewed regularly thereafter. Important for classification: AT 4.3.5 applies to models in risk management, not automatically to every marketing model — the implementation deadline for the module was January 1, 2024 (PwC Germany). At the EU level, the AI Act in Annex III No. 5(b) classifies AI systems as high-risk that are "intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud" (EU AI Act, Annex III). The EBA notes in its factsheet that this high-risk classification in the banking and payments sector links to creditworthiness and scoring — marketing or customer engagement AI is not named as high-risk there (EBA: AI Act — implications for the EU banking and payments sector). For NBA applications in marketing, this means: The explainability obligation from MaRisk remains relevant as soon as AI components are used in risk management — the AI Act high-risk category, on the other hand, primarily applies to credit decision-making, not to every NBA delivery.

These four building blocks do not act in isolation. An engine weights them against commercial objectives — margin, contact frequency limits, campaign guidelines — and distills from them the single recommendation that is delivered to a customer at a specific moment through a specific channel.

Explainability is not a retrofit, but a design principle

A common misconception is to treat explainability as a downstream documentation obligation that only arises when the regulator asks for it. However, MaRisk AT 4.3.5 Tz. 2 requires that the appropriateness and suitability of a model be assessed before its use — explainability must therefore be part of the model design from the very beginning, not a subsequently added reporting (BaFin). In practice, this means: Every recommendation that an NBA engine delivers should be traceable back to the underlying score contributions — why exactly this customer, why exactly this product, why exactly now. This is not only a matter of regulatory compliance, but also of internal management: A business department that cannot contest or comprehend a recommendation will, in case of doubt, ignore it or prioritize it incorrectly. Explainability is therefore both a compliance requirement and a prerequisite for operational acceptance.

Next Best Action is more than Next Best Product

A frequent misunderstanding: NBA is equated with Next Best Product (NBP). NBP only answers a partial question — which product has the highest probability of purchase for this customer? NBA answers the broader question: Is a product offer even the right action, or would a service message, a warning about an upcoming fee change, or no contact at all make more sense instead? NBP is therefore an input into the NBA decision — one of several propensity scores — but not its replacement. This distinction is also the reason why, according to Backbase, probabilistic AI scores are combined with deterministic rules: For example, a high NBP score for a loan offer may be overridden by a rule that prevents a customer in the 90-day cancellation period of another product from being additionally advertised to (Backbase).

Why Multi-Product Propensity is the core

A current account propensity score alone makes no statement about a customer's creditworthiness or savings behavior. Only when a bank runs propensity scores for current accounts, loans, savings, insurance, and cards in parallel for the same customer base can the actual NBA question be answered: Which of the several possible "next products" currently has the highest relevance — taking into account what the customer was already communicated with most recently? This multi-product view is the reason why an NBA engine must be closely integrated with the underlying Prediction Engine: It does not need one score, but a consistent, up-to-date scoring portfolio across all product lines.

Without this portfolio view, two typical mistakes occur in practice. The first is channel fatigue: If the loan, savings, and card teams each react independently to their own score, the same customer may receive three offers in quick succession — an effect that bypasses contact frequency limits without any single team losing the overall picture. The second mistake is prioritization by chance instead of relevance: Without an instance that weighs all scores against each other, the team with the greatest internal campaign pressure often simply wins, rather than the proposal that is actually most suitable for the customer. An NBA engine solves exactly this coordination problem by making the portfolio view a structural requirement, not an optional extension.

How Acceleraid implements this logic

The Prediction Engine & AI Framework from Acceleraid calculates exactly this portfolio of Affinity, Churn, Propensity, and NBA scores — explainable and auditable, as required by regulatory specifications such as MaRisk AT 4.3.5 (Platform). The CLM/CVM orchestration connects these scores with lifecycle phase, contact frequency limits, and channel preferences, translating them into concrete, deployable actions for banks in the DACH region and internationally (Banking). Thus, the NBA engine maps exactly the four building blocks described in this article: propensity, lifecycle, channel, and regulatory guardrails — condensed into a recommendation that can be explained to both regulators and the business department.

Conclusion

Next Best Action is at its core a weighting task: four different signal sources — propensity across multiple product lines, lifecycle context, channel preference, and regulatory limits — must be continuously condensed into a single recommendation. Banks that do not explicitly and comprehensibly model this logic run the risk of either failing to meet explainability requirements or addressing customers with the wrong action at the wrong time. These four building blocks thus form the foundation upon which all other operational questions — channel choice, timing, data sources — can be meaningfully answered. The second part of this series will cover how this single recommendation can be deployed differently per channel — online banking, app, email, SMS, and branch.

Illustration: AI-generated. AI-supported content: In the creation of our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, technical direction, and final approval remain with our team.