AWS blog: next-best-product recommendation system for banking using deep learning

AWS has released an architectural overview describing how to build an explainable Next-Best-Product recommendation system for banking using Amazon SageMaker AI and PyTorch. The core problem the system addresses is that banks hold vast amounts of customer data—transaction histories, product ownership records, demographic profiles, and behavioral patterns—but traditional approaches like rule-based systems and collaborative filtering fail to capture the complex temporal patterns that characterize how customers adopt new products over time.

The solution uses a multi-tower deep learning architecture with four specialized neural network towers, each processing a different aspect of customer data. The Sequence Tower processes a customer's product adoption history using a 2-layer Gated Recurrent Unit (GRU) and an embedding layer, outputting a 64-dimensional vector; the article notes this is the core component because it captures the order in which customers adopt products. The Transaction Tower processes time-windowed transaction aggregations (computed across 7-, 30-, 60-, 180-, and 365-day windows) via a 2-layer MLP with ReLU and Dropout, also outputting 64 dimensions. The Customer Tower handles demographics, income, family status, and account features through a similar 2-layer MLP architecture. The Behavioral Tower processes segmentation codes, loyalty metrics, and usage patterns, again using a 2-layer MLP. All four towers are fused together using a learned attention mechanism that provides both high model accuracy and per-customer explainability—showing which aspects of a customer's profile most influenced the recommendation—thereby satisfying banking regulatory requirements.

The data pipeline consists of two stages. First, an AWS Glue ETL job running on PySpark normalizes schemas from multiple banking source systems, maps raw transaction types to unified service categories, combines all data into a single chronological record per customer, and engineers temporal features; the output is written as Snappy-compressed Parquet to Amazon S3 and registered in the AWS Glue Data Catalog. Second, an Amazon SageMaker Processing job performs ML-specific feature engineering: creating product adoption sequences per customer, computing the time-windowed transaction aggregations using Dask for parallelism, and padding sequences to fixed length for model input. For datasets exceeding available memory, the architecture uses parallel chunked processing with PyArrow for metadata inspection, ProcessPoolExecutor for parallel processing, explicit garbage collection between batches, and incremental merging to avoid memory spikes.

The solution requires Python 3.11+, PyTorch 2.9+, Pandas 2.3+, NumPy 2.3+, scikit-learn 1.7+, and Dask 2025.11+. Training runs on ml.g5.12xlarge GPU instances (192 GB RAM, 4× NVIDIA A10G GPUs) via SageMaker AI. The full pipeline is orchestrated by Amazon SageMaker Pipelines, inference is performed via SageMaker Batch Transform or real-time endpoints, and monitoring occurs through CloudWatch. AWS cautions that deploying this solution creates billable resources including SageMaker AI training jobs, SageMaker AI endpoints, Amazon S3 storage, and AWS Glue jobs, and users must follow cleanup instructions to avoid ongoing charges. The article states this is an architectural overview rather than a step-by-step deployment guide, and notes that the patterns described can be applied to recommendation systems in other domains with heterogeneous customer data beyond banking.

Banks have long struggled to convert their rich internal datasets into actionable product recommendations. The article identifies a specific gap: traditional rule-based systems and collaborative filtering approaches cannot capture the temporal order in which customers adopt products—they see only a static list of what each customer owns, not the journey of how they acquired those products. The multi-tower architecture addresses this by assigning different neural network towers to different data modalities (sequences, transactions, demographics, behavior), each optimized for its data type, rather than forcing all data through a single generic pathway. This specialization both improves model capacity utilization and creates a clearer path to explainability: the learned attention mechanism that fuses the towers can show, per customer, which towers (and therefore which aspects of their profile) most influenced the recommendation.

The technology choices reflect production considerations for financial services. AWS Glue provides serverless ETL for normalizing data arriving from multiple banking systems with inconsistent schemas—a universal challenge in banking. The use of Parquet with Snappy compression on S3 offers both cost efficiency (3–5× compression over CSV) and performance gains (column pruning, predicate pushdown). PyTorch was selected for its dynamic computation graphs, which the article notes are necessary to handle variable-length customer sequences via pack_padded_sequence, and for its native SageMaker AI integration. The data pipeline is split into two stages: AWS Glue for schema unification and temporal feature engineering, then Amazon SageMaker Processing for ML-specific operations like sequence padding and windowed aggregations across 7-, 30-, 60-, 180-, and 365-day windows.

No comments yet. Be the first to share your thoughts!