How a Next-Best-Action Engine Decides

Part 1 of 3 in our series on next best action in banking. The next two parts cover channel-specific delivery (Part 2) and why transaction data is the most valuable signal (Part 3).

Why "the one right action" is a computation, not a guess

On any given day, a bank has multiple possible next steps for any given customer: a loan offer, an insurance cross-sell, a nudge about an unused credit card, or simply no contact at all because the contact-frequency cap has been reached. Next best action (NBA) is the approach that turns this set of options into a single, actionable recommendation per 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 key distinction from a traditional campaign is this: "Campaigns are bank-centric and calendar-driven. Next best action is customer-centric and event-driven" (Backbase). That same shift — from campaign waves to continuous micro-decisions — is echoed in McKinsey's framing of retail banking precision moving "from static segmentation to dynamic, real-time, hyper-personalized engagement" (McKinsey Global Banking Annual Review).

This decision cannot be made with a single rule or a single score. It is the outcome of four factors that have to work together — and that a well-built NBA engine, like the one Acceleraid runs, combines in a structured way.

The four building blocks of the decision logic

Propensity scores. The first building block is the likelihood that a customer will respond to a given offer or take up a given product. Unlike a single churn or cross-sell score, an NBA-capable prediction engine handles multiple product lines in parallel: checking accounts, consumer lending, savings, insurance, cards. This multi-product propensity view matters because bank customers are rarely "ready" for just one product at a time — the engine has to compute not just whether a customer is receptive, but to what. There is concrete evidence for the value of this approach: a multi-label model predicting ten event types over the next 90 days achieved a precision@12 of 73% in one documented banking use case, outperforming a heuristic baseline by a factor of eleven (Kumo.ai).

Lifecycle stage. The second building block places the customer within the customer lifecycle — acquisition, growth, maturity, or retention. An identical propensity score for a loan offer means something different in acquisition than it does in retention: one is about first-time outreach, the other about retaining a customer at risk of churning. Lifecycle stage supplies 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. Nowhere is this channel effect clearer than with push notifications: contextualized push messages in banking and finance reach a 14.4% open rate versus 4.19% for generic messages (Batch: Push Notifications Benchmark 2025). An NBA engine has to know this channel behavior and time and format the recommendation accordingly — the subject of Part 2 in this series.

Regulatory guardrails. The fourth building block is not optional in the German and European context. BaFin's MaRisk AT 4.3.5, item 6, explicitly requires "sufficient explainability" for models with characteristics of "technology-driven innovation and artificial intelligence" — alongside the pursued accuracy (BaFin, Circular 06/2024 (BA)). Item 2 further requires that a model's appropriateness and fitness be assessed before deployment and reviewed regularly thereafter. Context matters here: AT 4.3.5 applies to risk-management models, not automatically to every marketing model — the module's implementation deadline was 1 January 2024 (PwC Germany). At EU level, the AI Act's Annex III item 5(b) classifies as high-risk AI systems "intended to be used for the evaluation of the creditworthiness of natural persons or establishing their credit score, with the exception of AI systems used for the purpose of detecting financial fraud" (EU AI Act, Annex III). The EBA's factsheet confirms that this high-risk classification in banking and payments is tied to creditworthiness assessment and scoring — marketing or customer-engagement AI is not named as high-risk on that basis (EBA: AI Act — implications for the EU banking and payments sector). For marketing-driven NBA use cases, the practical takeaway is this: the MaRisk explainability duty remains relevant wherever AI components touch risk management, while the AI Act's high-risk category primarily applies to credit-granting decisions, not to every NBA delivery.

These four building blocks do not operate in isolation. An engine weighs them against commercial goals — margin, contact-frequency limits, campaign targets — and distills the result into the one recommendation delivered to one customer, at one moment, through one channel.

Explainability is a design principle, not an afterthought

A common mistake is to treat explainability as a downstream documentation task that only matters once a supervisor asks for it. MaRisk AT 4.3.5, item 2, however, requires that a model's appropriateness and fitness be assessed before it goes into production — explainability therefore has to be part of the model's design from the outset, not a report bolted on afterward (BaFin). In practice, this means every recommendation an NBA engine delivers should be traceable back to the underlying score contributions — why this customer, why this product, why now. That is not just a supervisory-compliance question but an operational one: a business team that cannot challenge or understand a recommendation will end up ignoring it or misprioritizing it. Explainability is therefore both a compliance requirement and a precondition for operational adoption.

Next best action is more than next best product

A common misconception equates NBA with next best product (NBP). NBP answers only part of the question — which product has the highest likelihood of being taken up by this customer? NBA answers the broader question: is a product offer even the right action, or would a service message, a heads-up about an upcoming fee change, or no contact at all be more appropriate? NBP is therefore an input into the NBA decision — one of several propensity scores — not a substitute for it. This distinction also explains why probabilistic AI scores, per Backbase, are combined with deterministic rules: a high NBP score for a loan offer, for example, can still be overridden by a rule preventing outreach to a customer within the 90-day cancellation window of another product (Backbase).

Why multi-product propensity is the core of it

A checking-account propensity score alone says nothing about a customer's creditworthiness or savings behavior. Only when a bank maintains propensity scores across checking, lending, savings, insurance, and cards for the same customer base in parallel can it answer the real NBA question: which of several possible "next products" is most relevant right now — given what the customer has already been told most recently? This multi-product view is why an NBA engine has to be tightly integrated with the underlying prediction engine: it needs not one score, but a consistent, current scoring portfolio across all product lines.

Without this portfolio view, two failure modes tend to appear. The first is channel overload: if lending, savings, and card teams each act independently on their own score, the same customer can end up receiving three offers in quick succession — quietly defeating contact-frequency limits without any single team noticing. The second is prioritization by internal pressure rather than by relevance: without a layer that weighs all scores against each other, the offer that wins is often simply the one backed by the loudest internal campaign push, not the one most relevant to the customer. An NBA engine solves this coordination problem by making the portfolio view a structural requirement rather than an optional add-on.

How Acceleraid implements this logic

Acceleraid's Prediction Engine & AI Framework computes exactly this portfolio of affinity, churn, propensity, and NBA scores — explainable and auditable, as required by supervisory frameworks such as MaRisk AT 4.3.5 (Platform). CLM/CVM orchestration then connects these scores with lifecycle stage, contact-frequency limits, and channel preferences, translating them into concrete, deployable actions for banks across DACH and internationally (Banking). The result maps directly onto the four building blocks described in this article: propensity, lifecycle, channel, and regulatory guardrails — distilled into a recommendation that can be explained to supervisors and business stakeholders alike.

Conclusion

Next best action is fundamentally a weighting problem: four distinct signal sources — propensity across multiple product lines, lifecycle context, channel preference, and regulatory boundaries — must be continuously distilled into a single recommendation. Banks that fail to model this logic explicitly and traceably risk either falling short of explainability requirements or reaching customers with the wrong action at the wrong time. Part 2 of this series looks at how that one recommendation gets delivered differently across channels — online banking, app, email, SMS, and branch.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.