Hyper-Personalisation in Banking: Building a Compliant, AI-Driven Customer Experience on Databricks

How to build an end-to-end hyper-personalisation solution that combines machine learning, generative AI, real-time event processing, journey orchestration, and adversarial AI safeguards — all on a single platform.

Why Hyper-Personalisation, and Why Now

Banks today sit on extraordinarily rich customer data: transaction histories, product holdings, life events, channel interactions, and behavioural signals. Yet most customer communication still follows segment-based templates that treat thousands of clients as if they were one. The result is well-known — generic offers, irrelevant timing, and a steadily eroding customer experience.

Hyper-personalisation changes the equation. Instead of asking “what should we send to this segment?”, the system asks “what is the right action – be it a product or nudge – message, channel, and moment for this individual client?” — and answers it continuously, at scale, in real time.

We’re aware that the journey to hyper-personalisation rarely starts from a clean slate. Most banks we work with are dealing with the opposite: customer data spread across siloed systems, channels managed by different teams on different platforms, and a martech stack that has grown one bolt-on integration at a time. Before any of the architecture we describe in this post becomes possible, the underlying data and platform layer usually needs work — consolidation, migration, and a coherent governance model. We’ve written separately about how we approach modern data platform migrations and won’t repeat that ground here, but it’s worth naming the precondition: hyper-personalisation is downstream of getting the foundation right.

At Datapao, we built an end-to-end hyper-personalisation solution on Databricks that demonstrates exactly this. The solution is delivered through a relationship portal for branch advisors that brings together a unified client profile, the recommended next best action, the message that would go out on the recommended channel, and the journey state across every channel — all in one view. In this post, we walk through the architecture, the modelling approach, the generative AI layer, the journey orchestration, the compliance safeguards, and the business-facing applications that bring it all together.

The Foundation: A Realistic Banking Data Platform

The platform handles the full data lifecycle on Databricks: raw data ingestion, transformation, modelling, analysis, and delivery into business-facing applications.

The pipeline supports both scheduled batch jobs and real-time, event-driven triggers. That distinction matters: hyper-personalisation isn’t only about who and what, it’s about when. Some interactions are best handled through scheduled campaigns, while others (like a client booking a flight) demand a response within minutes. The platform supports both static campaigns and dynamic, user-driven journeys side by side.

Client Tagging and Profiling

Before any model can recommend anything, the system needs to understand who each client is. The solution applies a tagging and clustering layer that enriches each client record with descriptive labels such as mortgage-ready, digital-first, young family, and so on.

Tags do two jobs at once. They give advisors an immediate, human-readable read on each client without needing to drill through raw data.

Predicting the Next Best Action — Not Just the Next Best Offer

At the core of the solution sits a Next Best Action (NBA) engine. The deliberate choice of action over offer matters. A “next best offer” answers only one question: what to sell. A “next best action” answers four: what to do, which product or topic it relates to, which channel to use, and what the message should say.

Behind the UI sits a recommendation engine that combines multiple ML components and produces three coordinated outputs per client: a ranked list of actions, the preferred channel for each action, and the tailored message for that channel.

The starting point is traditional: product-specific propensity models, trained on historical client data, each predicting the likelihood of the client buying the product they cover. These scores are not the end of the story. Two things happen on top of them.

First, the action portfolio is wider than just products. The engine also considers nudges — prompts that move a client forward in an existing journey, for example — and pre-defined bundles, packaged sets of products that complement each other (such as travel insurance paired with home and contents insurance). Bundles are scored against the products a client already holds, so the engine offers only the missing pieces and does so with elevated propensity when the partial match is strong.

Second, the engine integrates with the journey management system. Before an action is ranked, the engine knows whether the client is mid-way through an active journey on a related topic. That prevents the engine from recommending an action that would interrupt or duplicate something already in flight, and it lets the engine prefer actions that move existing journeys forward.

The ranking step combines propensity scores, action types (single product, nudge, or bundle), and journey state into one ordered list. The ordering isn’t a pure sort by probability; it can be weighted by expected value, so a moderately likely sale of a high-value product can outrank an almost-certain sale of a low-value one. The weighting formula is configurable in the backend, letting the bank tune the engine toward conversion rate, revenue, lifetime value, or any blend of those.

The channel for each action is then chosen based on the client’s channel preferences and the type of action — a complex bundle suggests a video call, a time-sensitive nudge suggests a push notification, a longer-form follow-up suggests an email. Once the action and channel are decided, the generative layer produces the tailored message for that specific channel and that specific client.

Because the propensity models are independent, banks can add, remove, or retrain individual product models without disrupting the others — an important property for a system that needs to evolve with the product catalogue.

Single Actions and Bundle Offers

Not every recommendation is a single product. The engine also recommends bundle offers (customizable for each bank or company), packaged sets of products that holistically fit a client’s profile. A bundle is more than a marketing convenience; it changes the client’s experience from “the bank is trying to sell me something” to “the bank has thought about my situation.”

Bundles also handle partial holdings intelligently. If a client already owns one of the three products in a bundle, the advisor sees only the remaining two as recommendations, with the existing product flagged as already held. Clients who match a bundle’s profile and already hold part of it get an elevated propensity score for the rest, so the ranking surfaces the highest-leverage opportunities first.

The Relationship Portal: Putting Predictions in Front of Humans

Predictions only create value when they reach the people who can act on them.

The relationship portal is the front-end designed for branch advisors — the people on the front line of every client interaction. It brings together everything the back-end engines produce — the unified client profile, ranked next best actions, recommended channels, generated messages, and journey state — into one workspace, scoped to the advisor’s portfolio.

A practical note before we go deeper: the architecture described in this post is modular by design. Customers don’t need to adopt the full stack to get value from it. The recommendation engine, the adversarial AI compliance layer, the journey orchestration, the conversational AI layer, and the relationship portal can each be implemented independently and integrated into the bank’s existing infrastructure — the CRM, marketing automation platform, or branch tooling that’s already in production. We’ve delivered some clients the complete end-to-end solution; for others, we’ve added a single module to fill a gap in what they already had.

Advisor-Level Portfolio View

The portal opens on a portfolio overview scoped to a specific advisor with their own client book and KPI profile. In production, this enforces row-level security: an advisor sees only their own portfolio, and a regional manager sees only their region.

The portfolio view summarises everything an advisor needs to plan their day:

• Number of clients and total assets under management
• Average engagement and NPS scores
• Client health distribution and segment breakdown
• Top opportunities: the highest-value next best actions across the portfolio, surfaced from the NBA engine

The client book itself is sortable and filterable on engagement, risk score, sales potential, status, and other dimensions. An advisor sitting at their desk, wondering who I should call today? gets an immediate answer ranked by whichever criterion matters most that morning.

The Client View

Selecting a client through the list, a search bar, or a dropdown — opens a unified profile that combines:

• A KPI card with balance, products held, engagement, and recent activity
• The client’s tags and labels at a glance
• A data disclaimer making explicit what the bank knows and doesn’t know about the client
• Tabbed access to next best actions, journeys, financial analysis, and bundles

The next best actions tab is the heart of the experience. It shows up to five ranked actions for the client, the propensity score, the recommended channel, and the message that would go out on that channel.

Crucially, the system flags when an action ties into an already-active journey. If a client is mid-way through a mortgage awareness campaign, the advisor sees that and can pick up the journey rather than starting a parallel conversation. Data isn’t siloed across channels — the same view that shows what the email campaign sent yesterday also shows what the mobile push triggered this morning and what the advisor said in the branch last week.

The Generative Layer: Personalised Messages and Advisor Scripts

For every recommended action, the system generates the actual communication piece. Three formats are produced in parallel:

• Email — for asynchronous, longer-form outreach.
• Push notification — for short, time-sensitive prompts.
• Advisor script — a teleprompter-style talking-point pitch the advisor can read on the spot.

Each format is tailored to the channel and to the individual client, drawing on the client’s tags, holdings, recent activity, and journey state. The advisor sees the recommended channel for each action: push notification through mobile for a mortgage pre-approval discussion, email for a savings product follow-up, video call for a complex bundle, and can preview the exact message that would go out before approving it.

Directing the LLM: Sales Methodology as a Prompt Layer

Letting an LLM generate sales pitches without guardrails is a fast path to off-brand, off-policy, or simply awkward output. The solution addresses this by directing the model through two layers of constraints:

1. Operational policy rules — what the bank allows the model to say, recommend, or imply.
2. Established sales techniques — structured methodologies the pitch must follow, so output is consistently shaped rather than free-form.

This combination keeps generative output useful without sacrificing control. The LLM still does the heavy lifting of personalization, but it does so within a defined frame.

The Compliance Problem: Adversarial AI as a GDPR Filter

Generative models have a well-documented tendency to drift, leaking patterns from training data, producing biased phrasing, or adopting a tone that pressures rather than informs. In a regulated industry, this isn’t a stylistic issue, it’s a compliance risk.

The solution introduces an adversarial AI agent that sits between the generation step and any human-facing surface. Every personalized message passes through this filter, which checks for:

• GDPR compliance — that the message doesn’t reveal more about the underlying data than it should.
• Tone and bias — that the language is human, neutral, and not pressuring.
• Brand and policy fit — that the output stays within the bank’s defined boundaries.

When the raw output fails any of these checks, the adversarial agent rewrites or rejects it before it ever reaches the advisor’s screen. This pattern (a generative model paired with an adversarial reviewer) is what makes the system safe to deploy in production rather than only in demo environments.

The Conversational AI Assistant for Advisors

Each action card in the portal includes an “Ask” button that opens a conversational AI assistant built on Databricks Genie. The assistant is designed for the moments an advisor needs information faster than they can dig for it: what are the eligibility criteria for this mortgage product? What’s the average income of this client? How does this bundle compare to what we offered last quarter?

The result is an assistant that can answer both “what does this product do?” and “how many of my clients use this product?” without requiring the advisor to switch tools. As with any LLM, output is flagged with a disclaimer prompting the advisor to verify before acting — the assistant accelerates work, it doesn’t replace judgment.

Journey Orchestration and Communication Load Management

On the portal, multi-step campaigns and real-time triggers come together. It’s the operational dashboard for everything the system is doing across all channels for a given client.

Auto-Triggered Journeys

The travel insurance workflow is the canonical example. The system watches for travel-related transactions: a hotel booking, a flight purchase. When one is detected, it cross-references the client against historical data to confirm three things:

1. The client is eligible for the campaign.
2. The client hasn’t already been contacted recently with a travel insurance offer.
3. The offer is genuinely relevant given the client’s overall profile. (defined by business rules)

Only when all three checks pass does the workflow activate the preferred channel activity, e.g., personalised push notification, with a follow-up email scheduled. The advisor sees the entire trigger chain in the tab, when the transaction happened, what notification went out, what the message said, and what’s queued to follow.

The deduplication step matters more than it sounds. Without it, hyper-personalisation quickly becomes hyper-spam, with the same client receiving the same offer through multiple triggered events in a single day.

Communication Load Controls

Frequency caps are a first-class part of the system. Each client has a communication load profile that respects:

• Marketing consent at the channel level.
• Configurable frequency limits: how many push notifications per week, how many emails per month, how many calls per quarter.
• Per-campaign caps prevent any single journey from monopolizing the client’s attention.

When a journey hits a cap, the portal surfaces it explicitly. The advisor sees this transparently rather than discovering it after the fact.

Journey History and Active Tracks

For each client, the platform shows every active journey, the steps that have already happened, the channels they happened on, and the exact message that was delivered at each step. It also keeps a history of completed and paused journeys, so the advisor can see what worked and what didn’t — and the system can learn from the same signal.

This history is what closes the loop. Predictions feed actions, actions feed messages, messages feed journey state, and journey state feeds back into the next round of predictions. The advisor sees one coherent story; the platform tracks and learns from every step of it.

Genie: Hyper-Personalisation for Non-Technical Users

Not every team needs individual-level recommendations. Marketing teams often work in segments, with templates that need to be personalised but not personalised down to the individual. Databricks Genie covers this case.

Through Databricks One, marketing staff can query the underlying data using natural language, with administrators controlling exactly which datasets are exposed. We can ask the system to generate one email template per product, drawing on the features that drive each model’s predictions. The result is a set of segment-level templates, each grounded in the actual signals the underlying models use.

The same interface answers analytical questions e.g. How many clients are predicted to buy each product? These questions used to require a data analyst. Now the marketing team can answer them directly, with the data team controlling the boundaries of what’s accessible.

How the Pieces Fit Together

The full architecture forms a closed loop:

• Data layer — raw banking data ingested and transformed on Databricks, governed by lineage and access controls.
• Recommendation engine — the core of the solution, where propensity models, clustering algorithms, and business logic work side by side rather than in sequence. Independent product propensity models score every client; clustering and ML classifiers produce the descriptive tags that profile each client; bundle definitions and business rules combine these signals to rank next best actions, weight them by expected value, and intelligently account for products already held. The output is a single, ordered list of recommendations per client, grounded in a complete profile.
• Real-time layer — event-driven workflows that listen for trigger transactions and produce personalized output within minutes, with eligibility and frequency checks enforced before anything goes out.
• Generative AI layer — LLMs producing emails, push notifications, and advisor scripts, directed by policy rules and sales methodology.
• Adversarial AI layer — automated review of every generated message for GDPR compliance, tone, and bias.
• Conversational AI layer — Databricks Genie assistant grounded in a product document store and a curated client data space, available to advisors at the point of action.
• Journey orchestration layer — multi-step campaigns and real-time triggers tracked in one place, with communication load and frequency caps enforced across channels.
• Delivery layer — relationship portal for advisors, Genie for marketing, downstream integrations for customer-facing channels like Dynamics or existing email platforms.

What makes this architecture work isn’t any single component, but it’s that all of them live on one platform. The same governance applies to the data the models train on, the prompts the LLMs see, and the messages that go out the door. Lineage is preserved end-to-end. The adversarial filter sees what the generative model produced; the relationship portal sees only what the filter approved; the audit trail covers all of it.

How We Used Databricks Genie

Genie is the conversational layer of the solution. We use it to put a natural-language interface in front of two distinct kinds of context, and the choice to lean on Genie rather than a bespoke LLM stack is deliberate; it keeps the assistant inside Databricks’ governance perimeter, with the same access controls, audit trail, and Unity Catalog integration as the rest of the platform.

The advisor-facing assistant is powered by a Genie space with curated table-level access and column-level masking applied through Unity Catalog. Questions like “what’s the average income of this client?”, “how many clients have this bundle recommended in the top3 places?”, or “which clients in my portfolio have a propensity score above 0.7 for mortgages?” are answered against live data, not a stale extract. The advisor never writes SQL; Genie translates the natural-language question into a query, runs it, and returns the answer with the underlying numbers visible.

The non-technical marketing experience runs on the same foundation. When a marketing team member asks Genie via the Genie Space UI to “generate one email template per product, using the top features that drive each model”, that’s Genie answering against the same governed data, but scoped to a different role with a different view of what’s accessible. The product document store is hidden from this user; the segment-level analytics tables and model feature catalogue are exposed.

What this gives us, end-to-end:

• One tool, two audiences. Advisors get product and per-client answers; marketing gets segment-level analytics and template generation. Same underlying technology, different governance scopes.
• No data movement to enable the assistant. Genie queries against the lakehouse directly. There is no separate vector store to maintain for client data, no nightly export to a third-party RAG system, and no parallel security model to keep in sync.
• Traceable answers. Genie operates inside Databricks’ governance perimeter, which means activity can be logged through the same mechanisms as the rest of the platform. With the right configuration, this gives banks a strong basis for tracing how a recommendation was justified from the action card the advisor saw, to the message that was approved, to the underlying query that informed it. The exact level of auditability depends on how logging and retention are set up; it’s something to design for explicitly rather than assume by default.
• Auditable answers. Every Genie query is logged. When a regulator asks how a recommendation was justified, the bank can trace from the action card the advisor saw, to the message that was approved, to the Genie query that informed the underlying judgment.

The UI surfaces the predictions, journeys, recommendations, and segment views directly. What Genie adds is the ability to go beyond what’s pre-built: asking ad-hoc questions, exploring follow-ups the UI doesn’t anticipate, and getting analytical answers without routing through a data analyst. Without Genie, the platform still works for non-technical users; with Genie, the same users can ask questions the UI designers didn’t think to put on a screen.

How We Used Databricks Lakebase

The hyper-personalisation solution is, structurally, an OLTP application sitting on top of an analytical platform, and that’s exactly the gap Lakebase is designed to close. We use Lakebase as the operational data layer for the relationship portal and every component that needs low-latency, transactional reads and writes.

A handful of workloads in this solution are emphatically not analytical:

• Advisor portal interactions. When an advisor opens a client view, the portal needs sub-100ms reads against the client KPI card, current tags, recent activity, and ranked next best actions. A SQL warehouse is the wrong tool for this; it’s an OLAP engine optimised for scanning terabytes, not for thousands of low-latency point lookups.
• Journey state. Active journeys, paused journeys, the step each client is currently on, the timestamp of the last engagement on each channel, all of this is small-row, high-frequency, transactional data. It needs to be written every time a push notification fires, every time an email opens, every time an advisor logs an interaction.
• Communication load tracking. Frequency caps only work if the system can authoritatively answer “how many push notifications has this client received this week?” in milliseconds, before deciding whether to fire the next one. Reading from a Delta table at the moment of decision is too slow; reading from Lakebase is purpose-built for it.
• Real-time trigger workflows. The travel insurance trigger needs to detect a transaction, check eligibility, check the communication load, generate a message, route it through the adversarial filter, and dispatch it, all in seconds. Lakebase holds the state that every step of that pipeline reads and updates.

We get all of this without standing up a separate Postgres cluster outside Databricks. Critically, Lakebase keeps this operational data inside the same governance perimeter as the rest of the platform:

• Unity Catalog applies end-to-end. The same row-level security that scopes an advisor’s portfolio in the analytical view also applies to the operational queries the portal makes. There is no second permission system to maintain.
• Synced tables eliminate ETL. The propensity scores, client tags, and bundle definitions are computed in the lakehouse and synced into Lakebase as serving tables. The portal reads them with millisecond latency without us building, monitoring, or paying for a custom reverse-ETL pipeline.
• Operational data flows back to analytics. Journey events, advisor actions, message outcomes, and trigger fires written to Lakebase are synced back into Delta for analytics, model retraining, and reporting. The feedback loop from the closed-loop architecture section earlier in this post is mechanically realised through this sync, with no glue code in between.
• Scale-to-zero economics. When the portal is idle outside business hours, Lakebase compute scales down. We’re not paying for an always-on Postgres instance to support a workload that genuinely peaks during the working day.
• Branching for safe development. When we want to test a new journey configuration, a frequency cap change, or a schema migration, we branch the database, apply the change in isolation, validate against production-like data, and only then merge. This is meaningfully faster and safer than the alternative of staging environments and dump/restore cycles.

Together, Genie and Lakebase cover the two halves of the experience that traditional architectures struggle to unify: Genie is how humans and the system talk to each other in natural language, and Lakebase is how the system serves and persists state fast enough to make that conversation feel real-time. Both live inside Databricks; neither requires a parallel stack to govern. That is what makes this solution feasible to operate, not just a demo.

Closing Thoughts

Hyper-personalisation is no longer a question of whether the technology exists. The harder questions are organisational: how to keep generative AI compliant, how to put predictions in front of the right humans, how to react in real time without overwhelming clients, how to coordinate across channels so the client experiences one bank rather than five competing campaigns, and how to give non-technical teams access to the system without giving up control. The solution we built on Databricks is an answer to all of those questions, in a single integrated stack.

If you’re exploring hyper-personalisation for your organisation and want to see this in action, or discuss how the architecture would adapt to your specific data and product mix, get in touch with the team at Datapao. We’re happy to tailor the demo to your priorities, dive into the technical layers, or talk through what a production rollout would look like in your environment.

About Datapao

Datapao is a Databricks-focused data and AI consulting and training company operating in the UK and across Europe, with delivery hubs in the UK and Central Europe. The company helps organisations design, build, and operate modern data platforms while enabling internal teams through hands-on Databricks training. Our approach combines deep engineering expertise with structured knowledge transfer to ensure sustainable, long-term adoption of data and AI.

Get in touch to discuss where to start.