How an AI personalization platform for banks works: From data to decisioning to delivery

The first two parts of this series covered the selection criteria and business case of an AI personalization platform for banks. This part opens up the technical black box: How is such a platform actually structured so that raw data is turned into a delivery in milliseconds? Anyone interested in the decision logic itself instead — which factors determine a recommendation — will find this in the article "How a Next-Best-Action Engine Decides".

The short answer first

An AI personalization platform for banks consists of three technical layers: a data layer that feeds raw data in real time, a feature and decisioning layer that provides features with latencies in the millisecond range, and a delivery layer that delivers the recommendation to the respective channel. The critical architectural mistake to avoid: No step in this chain may access an offline data warehouse directly in the request path.

Why the warehouse must disappear from the request path

The obvious but wrong approach is to read features directly from the analytical data warehouse with every request. This works for reporting, but not for real-time personalization: Direct access to an offline warehouse adds hundreds of milliseconds per inference call, making real-time serving practically impossible (Redis Documentation, "Redis feature store"). The solution is a dedicated online feature layer built specifically for this read path: feature vectors for inference endpoints under 1 ms P99, sub-millisecond read and write access, millions of read accesses per second from a single shard, with horizontal scaling beyond that (Redis Documentation).

The three layers in detail

Data layer. Raw data from core banking, CRM, and card processing flows in via an event streaming layer. Kafka as a reference technology guarantees exactly-once processing, strict ordering within a topic partition, decoupling of producers and consumers, and continued operation without data loss in the event of server failure (Apache Kafka Documentation). In the production configuration, this usually means a replication factor of 3 — three copies of each record —, while partitioning enables parallel reading and writing across many brokers, with performance remaining "effectively constant with respect to data size" (Apache Kafka Documentation).

Feature and decisioning layer. This is where the actual speed advantage is created. A HMGET command delivers the feature subset required by the model in a single round trip; features for hundreds of entities can also be read in a single round trip via pipelining (Redis Documentation). Measured values show how strongly the choice of server implementation affects performance: For 25 feature views with 10 features each (250 features in total), a Java feature server is at p99 ≈ 1.3 ms via Redis, whereas a Python server is at ≈ 45 ms — for batch requests with 100 entities and 50 features, it is 17 ms compared to 125 ms, i.e., 5 to 7 times faster (Feast, "Feast Benchmarks"). As a throughput reference from the same measurement: around 5,000 requests per second at 100 ms timeout and 50 parallel clients, with a success rate of over 99.9% (Feast Benchmarks).

Delivery layer. Local state stores or local tables in stream processing reduce processing latency and load on remote databases because a network lookup is not required for every record (Confluent Documentation, "Optimize Confluent Cloud Clients for Latency"). From here, the finished recommendation is delivered to the respective channel — online banking, app, email, or branch CRM.

The choice of storage determines latency

Not every online store delivers the same speed, and the difference is significant. With a batch size of 1 and 50 features, Redis is at 8.4 ms compared to 465 ms for GCP Datastore — a factor of 10 to 20 — and at 15 ms compared to 129 ms for DynamoDB; DynamoDB only becomes faster than Redis at a batch size of about 30 (Feast Benchmarks). These figures show why the choice of storage technology is an architectural decision with direct business impact, not just an infrastructure detail: A feature layer that is too slow limits how many decisions per second a bank can make in real time in the first place.

As a managed alternative with documented service level objectives, Snowflake's Online Feature Store for the REST query API lists p50 = 10 ms, p95 < 15 ms, and p99 < 20 ms serving latency (Snowflake Documentation, "Online feature store"). Snowflake explicitly lists fraud detection, recommendations, and personalization as primary use cases for this latency class; Real-Time Feature Views are computed at the time of the request itself (Snowflake Documentation).

Freshness is a design choice, not a side effect

An architecture must define how "fresh" a feature needs to be before it becomes useless — and this differs significantly depending on the feature type. Common practice is to have different expiration times per feature type: streaming features about 5 minutes, batch features 24 hours, implemented technically via HEXPIRE/HTTL from Redis 7.4+ onwards (Redis Documentation). The reason for this is a deliberate fail-safe principle: If an ingestion pipeline fails, features should expire instead of silently passing outdated values to the model (Redis Documentation). In the Snowflake setup, the freshness budget is under 2 seconds for end-to-end freshness with stream ingestion; the offline-to-online sync is configurable via target_lag from 10 seconds to 8 days, with the effective delay resulting from the refresh frequency plus target_lag (Snowflake Documentation).

A well-known error pattern that a clean reference architecture must explicitly avoid: A self-built cache in front of the warehouse reduces latency, but creates training-serving skew — the features used at inference time deviate from the features used during training, and model accuracy drops unnoticed (Redis Documentation). This is precisely why the feature layer should be designed as an independent, consistent component, not as an improvised cache.

The latency-throughput trade-off in the streaming layer

Architectural decisions in the event streaming layer have a direct impact on end-to-end latency. While a higher partition count increases throughput, it can increase end-to-end latency because replication takes longer before messages are considered "committed" (Confluent Documentation). Specific tuning parameters are used for low latency: linger.ms=0, compression.type=none, and acks=1 on the producer side — the default since Kafka 3.0 is acks=all —, as well as fetch.min.bytes=1 on the consumer side and TOPOLOGY_OPTIMIZATION=OPTIMIZE for Kafka Streams (Confluent Documentation). In the reference architecture, Spark usually handles nightly batch materialization, while Flink or Kafka Streams write real-time features to the same entity hash via HSET with their own freshness window; Feast supports Redis as a first-class online store for this (Redis Documentation).

Governance as an architectural component, not an afterthought

In the case of automated decisions with legal or similarly significant effects, human intervention, explanation of one's own standpoint, and contestation of the decision must be technically ensured (Art. 22 para. 3 GDPR) — for the architecture, this specifically means: audit trail, reason codes, and a human-in-the-loop path must be planned as components from the very beginning, not added retroactively (Art. 22 GDPR). For model scoping, there is also an architecturally relevant note: creditworthiness assessment and credit scoring are classified as high-risk under Annex III No. 5(b) of the EU AI Act, while systems for detecting financial fraud are explicitly exempted (EU AI Act, Annex III). A clean separation of these model classes into separate pipelines within the same architecture noticeably reduces the compliance effort, because high-risk requirements do not then automatically extend to all models on the platform.

How Acceleraid implements this architecture

Acceleraid's CDP & Data Governance consolidates data in real time from CRM, core banking, and card processing as a system of record — with consent management, lineage, PII protection, and German hosting according to GDPR-by-design (Platform). The Prediction Engine & AI Framework builds on this, calculating affinity, churn, propensity, and NBA scores in an explainable and auditable way, while the CLM/CVM orchestration plays these scores with contact frequency limits and channel preferences in real time to online banking, app, email, and branch CRM (Banking). The platform is built to be model-agnostic: The underlying AI model can be replaced without losing knowledge, contexts, or configurations of the existing architecture — an architectural principle validated in practice with over 3.5 billion analyzed transactions and more than 250 enterprise deployments (Platform).

Conclusion

A robust reference architecture for personalization in banking cleanly separates three layers: data ingestion via event streaming, a dedicated feature and decisioning layer with latencies in the low double-digit millisecond range, and a delivery layer with no live access to the analytical warehouse. The choice of storage technology, the freshness design per feature type, and the architectural anchoring of governance requirements determine success just as much as the model quality itself. Anyone who does not cleanly separate these three layers will sooner or later fail either on latency, model accuracy, or demonstrability to the regulator.

Illustration: AI-generated. AI-supported content: In creating our posts, we use AI technologies and automated agents, including from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, professional alignment, and final approval remain with our team.