Real-Time Next Best Action in Banking Without Sending Data to a SaaS

Next best action in banking is a real-time decisioning pattern that, for each customer interaction, chooses the most suitable message, offer or service step: it checks eligibility, scores propensity, arbitrates between candidates, applies suppression rules and delivers through a channel. Fed by a customer data platform (CDP), it can run inside the bank's perimeter, which keeps customer data, consent state, model outputs and decision records under the bank's own audit and model risk controls.

This page is for architects, model risk managers and DPOs. It belongs to the financial services hub and builds on customer data platforms for banks and the customer 360 data model.

The five-step pattern

The stage order is a convention. Evaluate hard suppressions (consent, objection, vulnerability, open complaint) before scoring, so that the engine does not compute on data it must not use, and check them again at delivery because state can change in between. Tealium's banking page lists the typical use cases: abandoned-application recovery, cross-sell of products that complement what a customer already holds, and ATM touchpoints 1. Meiro and Acceleraid describe next-best-offer and next-best-action scoring in their banking material 23.

Latency budgets by channel

The figures below are illustrative planning assumptions to agree with channel owners. They are not benchmarks or measured PrivyCDP performance. Replace them with your own measured p95 values and load-test results before accepting a service level.

An illustrative allocation for a 150 ms in-session call: gateway 15 ms, profile and feature lookup 30 ms, eligibility and suppression 15 ms, model scoring 40 ms, arbitration 10 ms, response 10 ms, headroom 30 ms. Write the decision record asynchronously with at-least-once delivery rather than blocking the response on the audit write. If the decision service is unavailable, show default content; a decisioning failure must never block a banking task.

Rules versus machine learning: when rules win

The usual design is hybrid: models produce scores, and rules wrap them. This also shapes governance. The April 2026 US interagency guidance defines a model as a complex quantitative method applying statistical, economic or financial theories to turn input data into quantitative estimates, and excludes simple arithmetic and deterministic rule-based processes 4. A rules-only engine therefore sits outside that definition, while the scores inside a hybrid engine sit within it. Rules still need change management, testing and a decision record.

Model risk management and explainability

United States: SR 26-2 replaced SR 11-7

On 17 April 2026 the Federal Reserve (SR 26-2) and the OCC (Bulletin 2026-13) issued revised model risk guidance that rescinds SR 11-7 and OCC Bulletin 2011-12 45. The old names still appear in vendor documents. The guidance is risk-based, says it sets no enforceable standards, is expected to be most useful for organisations above $30 billion in assets, and keeps validation built on conceptual soundness, outcomes analysis and ongoing monitoring, noting that interpretability measures may be a practical alternative to theoretical review for some models 4. The OCC states that it applies to community banks, subject to its limits 5. Vendor products remain in scope: principles apply even when the vendor does not disclose code, data or methodology 4. A footnote excludes generative and agentic AI models, so an LLM that composes or selects offers is governed by the bank's broader risk management rather than this guidance 4.

United Kingdom

The PRA’s SS1/23 applies model-risk expectations to the UK institutions in its stated internal-model-approval scope. The official page links an April 2026 version; confirm the version and applicability rather than assuming every bank has identical duties. Keep model identification, governance, validation and mitigants in the decisioning assessment. The exact April 2026 changes were not established in this review. PRA source.

EU: automated decisions and the right to an explanation

What to log

A decision record should hold: decision ID, timestamp, customer reference, channel, candidate set with eligibility outcome, suppressions applied with reason, model and rule versions, scores, arbitration weights, winning action, delivery result and response. Add a customer-facing reason code written in plain language. With these fields a decision can be replayed and explained. See explainable AI for customer decisions.

The EU AI Act boundary

Prohibited practices applied from 2 February 2025. Regulation (EU) 2026/1744, in force since 27 July 2026, moved the stand-alone high-risk obligations in Annex III to 2 December 2027 1112. Article 50 transparency obligations apply from 2 August 2026 12.

Annex III point 5(b) lists AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, except those used to detect financial fraud; point 5(c) covers risk assessment and pricing for life and health insurance 13. Marketing segmentation and next best action are not high-risk by themselves. Four points mark the boundary:

1. If the engine uses a creditworthiness output to decide who is offered which credit product on what terms, treat it as in scope until counsel decides otherwise.
2. The Article 6(3) exemptions for narrow or preparatory tasks do not apply where the system profiles natural persons 13.
3. Article 5(1)(b) prohibits AI that exploits vulnerabilities due to age, disability or a specific social or economic situation to materially distort behaviour in a way likely to cause significant harm 13. A financial-vulnerability flag makes this directly relevant to offers of high-cost credit.
4. Article 50(1) requires that people be told when they interact with an AI system, such as a chatbot 13.

The shared fact check records Commission draft high-risk classification guidelines published on 19 May 2026. A draft is not a substitute for the Act or final guidance. Check the current adopted text when classifying credit-related decisioning; see the AI Act guide.

Inference inside the perimeter versus calling a SaaS

Choose an inference location by tracing the features, model access, decision record, fallback and operating owner. For a remote service, assess the recipient, allowed data, contract and outage behavior. For private inference, test capacity, patching, observability and recovery. A tabular model’s operational footprint should be measured in a proof of concept. Neither location establishes compliance by itself. See deployment and the synthetic proof of concept.

Consent and fairness checks

• Consent and objection. Evaluate purpose and channel permissions before ranking an offer, and re-check suppression at activation. Keep service communications distinct from marketing purposes.
• Vulnerability. FCA FG21/1 calls for understanding vulnerable customers’ needs, appropriate staff capability, suitable products and communications, and monitoring outcomes. Its July 2026 note points firms to current Consumer Duty expectations. FCA guidance.
• Fairness testing. Define the population, outcome and lawful testing data with counsel before comparing groups. Check proxy variables and adverse effects; do not infer that a technical parity check establishes legal compliance. US credit decisions require a separate Regulation B assessment.
• Evidence. Record policy/model versions, the permitted action, suppression reasons and the fallback decision. Use synthetic data before live activation.

Reference flow

1. The channel calls the decision API with an identity token and context.
2. The service loads the profile and precomputed features.
3. Hard suppressions run against the consent ledger and flags.
4. Eligibility rules prune the candidate set.
5. Models score the remaining candidates.
6. Arbitration ranks them under business constraints.
7. A final suppression check runs, and the action returns with a reason code.
8. The decision record is written asynchronously, and responses feed monitoring.

Implementation checklist

1. List actions, owners and eligibility rules before choosing a model.
2. Put consent, objection and vulnerability flags in one ledger read by every channel.
3. Separate rules and models in code and in the decision record.
4. Enter every score used in a decision in the model inventory with an owner.
5. Set a latency budget per channel and test p95 and p99 under load.
6. Define fallback content for every channel.
7. Record decision ID, versions, suppressions, scores and outcome for each decision.
8. Provide plain-language reason codes for customer-facing explanations.
9. Decide, with counsel, whether any use touches creditworthiness (AI Act Annex III 5(b)) or Article 22.
10. Run vulnerability and proxy-variable checks before launch and monthly.
11. Keep holdout groups.
12. Block outbound calls to external decisioning or analytics endpoints unless the register entry exists.
13. Test with synthetic data first; see CDP proof of concept with synthetic data.
14. Review rules and models quarterly, and on any change in policy or regulation.

To scope a bank-owned decisioning pilot, start with the deployment qualification form, which collects workload, latency and boundary requirements.