Construct an explainable next-best-product suggestion system for banking on AWS

Constructing a deep learning-based explainable next-best-product suggestion system helps banking establishments predict which product a buyer wants subsequent. Banks maintain huge quantities of buyer knowledge, together with transaction histories, product possession data, demographic profiles, and behavioral patterns. Translating this knowledge into actionable, personalised product suggestions stays a major problem. Conventional rule-based techniques and collaborative filtering approaches usually fail to seize the complicated temporal patterns in buyer product adoption journeys.

On this submit, we current the structure and design choices behind a Subsequent-Greatest-Product (NBP) suggestion system utilizing Amazon SageMaker AI and PyTorch. We clarify the reasoning behind a multi-tower neural community structure, how realized consideration gives per-customer explainability, and the way AWS providers work collectively to take this answer from analysis to manufacturing. That is an architectural overview, not a step-by-step deployment information. Whether or not you might be constructing suggestion techniques for monetary providers or different domains with heterogeneous buyer knowledge, the architectural patterns described right here will help you design extra correct and interpretable fashions.

Stipulations

To observe together with the architectural patterns and code examples on this submit, you want:

• An AWS account with permissions for SageMaker AI, Amazon Easy Storage Service (Amazon S3), AWS Glue, and Amazon CloudWatch
• This answer requires an AWS Identification and Entry Administration (IAM) execution function with entry to the next AWS providers. Create insurance policies with least-privilege permissions scoped to solely the sources wanted for this answer.
• SageMaker AI – Create, describe, begin, cease, and delete coaching jobs, processing jobs, batch remodel jobs, fashions, endpoints, endpoint configurations, pipelines, experiments, and monitoring schedules. InvokeEndpoint for real-time inference.
• Amazon S3 – Learn and write entry to the information bucket. Create and delete bucket. Listing, add, obtain, and delete objects.
• AWS Glue – Create, run, and delete ETL jobs. Create and delete crawlers. Create and delete Knowledge Catalog databases and tables.
• CloudWatch – Learn and write entry to log teams, log streams, and metrics. Delete log teams throughout cleanup.
• IAM – Create and delete roles. Connect and detach insurance policies. PassRole (restricted to the named execution function ARN, scoped to sagemaker.amazonaws.com and glue.amazonaws.com).

For steerage on writing least-privilege IAM insurance policies for SageMaker AI, see Identification-based coverage examples for SageMaker AI.

• Familiarity with Python 3.11+ and PyTorch
• Required packages to create this recommender system:
  • Python 3.11+
  • PyTorch 2.9+
  • Pandas 2.3+
  • NumPy 2.3+
  • scikit-learn 1.7+
  • Dask 2025.11+

We suggest utilizing a digital atmosphere and scanning dependencies for recognized vulnerabilities utilizing instruments like pip-audit earlier than deployment.

• Primary understanding of deep studying ideas (embeddings, recurrent networks, consideration mechanisms)

Be aware: Deploying this answer creates billable AWS sources together with SageMaker AI coaching jobs (ml.g5.12xlarge GPU cases), SageMaker AI endpoints, Amazon S3 storage, and AWS Glue jobs. Observe the clear up directions on the finish of this submit to keep away from ongoing prices.

Resolution overview

The answer makes use of a multi-tower deep studying structure with 4 specialised neural community towers, every processing a distinct facet of buyer knowledge. The towers are fused utilizing a realized consideration mechanism that gives each excessive accuracy and per-customer explainability.

The next diagram illustrates the high-level structure of the answer.

The structure addresses a typical problem in banking: predicting which product a buyer is most probably to buy subsequent from a number of product classes (resembling bank cards, deposits, insurance coverage, loans, and mortgages), whereas offering explainable outcomes that fulfill regulatory necessities.

Tech stack

The next desk summarizes the expertise selections and their roles within the answer.

Why PyTorch?

This answer makes use of PyTorch for dynamic computation graphs (wanted for variable-length sequences with pack_padded_sequence), speedy iteration throughout a number of architectural phases, and native integration with SageMaker AI coaching jobs and inference containers.

Why Parquet on Amazon S3?

The answer shops knowledge as Snappy-compressed Parquet on Amazon Easy Storage Service (Amazon S3). Parquet’s columnar format allows column pruning (studying a fraction of a large file), predicate pushdown (skipping irrelevant row teams), 3-5× compression over CSV, and kind preservation with out re-parsing on each learn.

Why AWS Glue for ETL?

The venture makes use of AWS Glue jobs working on PySpark for serverless, auto scaling knowledge processing. AWS Glue gives native Spark integration, the DynamicFrame API for versatile schemas, automated Knowledge Catalog registration, job bookmarks for incremental processing, and pay-per-DPU price effectivity.

Knowledge pipeline structure

The information pipeline consists of two phases: an AWS Glue ETL job for knowledge unification, adopted by an Amazon SageMaker Processing job for ML-specific characteristic engineering.

Knowledge unification with AWS Glue

Banking knowledge usually arrives from a number of supply techniques with inconsistent schemas. The AWS Glue ETL job normalizes schemas, maps uncooked transaction varieties to unified service classes, combines all knowledge right into a single chronological file per buyer, and engineers temporal options. The processed output is written as Parquet to Amazon S3 and registered within the AWS Glue Knowledge Catalog.

ML-specific characteristic engineering with Amazon SageMaker Processing

After the AWS Glue job produces the unified historical past, an Amazon SageMaker Processing job creates product adoption sequences per buyer, computes time-windowed transaction aggregations (throughout 7, 30, 60, 180, and 365-day home windows) utilizing Dask for parallelism, and pads sequences to a hard and fast size for mannequin enter.

Dealing with giant scale knowledge

For giant datasets that exceed accessible reminiscence, the answer makes use of a parallel chunked processing technique with PyArrow for metadata inspection, ProcessPoolExecutor for parallel chunk processing, express rubbish assortment between batches, and incremental merging to keep away from reminiscence spikes.

import gc
from concurrent.futures import ProcessPoolExecutor

chunksize = 5_000_000
n_workers = 4

for batch_start in vary(0, total_chunks, n_workers):
    with ProcessPoolExecutor(max_workers=n_workers) as executor:
        futures = [
            executor.submit(process_chunk_range, input_path, output_path, i, start_row, end_row)
            for i in range(batch_start, min(batch_start + n_workers, total_chunks))
        ]
        for future in futures:
            future.consequence()
    gc.acquire()  # Power rubbish assortment between batches

Be aware: When working with actual buyer knowledge, see the Security considerations section for steerage on PII dealing with, regulatory compliance, and knowledge governance.

Mannequin structure

The mannequin makes use of a multi-tower method the place every tower focuses on processing one sort of buyer knowledge, adopted by an attention-based fusion mechanism.

Why multi-tower over a single community?

Various kinds of buyer knowledge have basically totally different constructions. Sequences are ordered lists of discrete IDs. Transactions are numerical aggregations. Demographics are a mixture of categorical and numerical options. Behavioral segments are categorical codes.

Forcing all these via the identical layers wastes mannequin capability. As a substitute, the structure makes use of 4 specialised towers, every designed for its knowledge sort:

Sequence Tower: Capturing temporal patterns

The Sequence Tower processes the shopper’s product adoption historical past utilizing a 2-layer Gated Recurrent Unit (GRU). That is the core architectural part as a result of it captures the order by which clients undertake merchandise, not simply which merchandise they personal.

class SequenceTower(nn.Module):
    def __init__(self, num_products, embedding_dim=32, hidden_dim=64, dropout=0.2):
        tremendous().__init__()
        self.embedding = nn.Embedding(num_products + 1, embedding_dim, padding_idx=0)
        self.gru = nn.GRU(
            input_size=embedding_dim, hidden_size=hidden_dim,
            num_layers=2, batch_first=True, dropout=dropout
        )
        self.active_count_layer = nn.Sequential(
            nn.Linear(1, hidden_dim // 2), nn.ReLU(), nn.Dropout(dropout)
        )
        self.fusion = nn.Sequential(
            nn.Linear(hidden_dim + hidden_dim // 2, hidden_dim),
            nn.ReLU(), nn.Dropout(dropout)
        )

    def ahead(self, sequence, seq_length, active_count):
        embedded = self.embedding(sequence)
        packed = nn.utils.rnn.pack_padded_sequence(
            embedded, seq_length.cpu().clamp(min=1),
            batch_first=True, enforce_sorted=False
        )
        _, hidden = self.gru(packed)
        seq_features = hidden[-1]
        active_features = self.active_count_layer(active_count)
        return self.fusion(torch.cat([seq_features, active_features], dim=1))

Why GRU over LSTM?

GRU has two gates (reset, replace) versus LSTM’s three (enter, neglect, output), leading to roughly 33% fewer parameters. For brief sequences (20 objects or fewer), GRU performs comparably to LSTM whereas coaching sooner. The replace gate’s interpolation mechanism additionally creates a pure residual-like gradient path.

Why pack_padded_sequence?

Buyer sequences have variable lengths. Packing tells the GRU to disregard padding tokens, stopping the mannequin from studying noise from zero-padded positions.

Tower Consideration Mechanism: Discovered fusion with explainability

As a substitute of easy concatenation, the structure makes use of a realized consideration mechanism to fuse tower outputs. That is what gives per-customer explainability with out requiring post-hoc interpretation strategies like SHAP or LIME.

class TowerAttentionMechanism(nn.Module):
    def __init__(self, hidden_dim=64, num_heads=4, dropout=0.1):
        tremendous().__init__()
        self.tower_attention = nn.MultiheadAttention(
            embed_dim=hidden_dim, num_heads=num_heads,
            dropout=dropout, batch_first=True
        )
        self.context_weighting = nn.Sequential(
            nn.Linear(hidden_dim * 4, 4), nn.Softmax(dim=1)
        )

    def ahead(self, tower_outputs):
        stacked = torch.stack(tower_outputs, dim=1)  # [batch, 4, 64]
        attended, _ = self.tower_attention(stacked, stacked, stacked)
        stacked = stacked + attended  # Residual connection
        concat = torch.cat(tower_outputs, dim=1)  # [batch, 256]
        tower_weights = self.context_weighting(concat)  # [batch, 4]
        weighted_outputs = [
            tower_outputs[i] * tower_weights[:, i:i+1]
            for i in vary(4)
        ]
        return weighted_outputs, tower_weights

The tower weights are per-customer. A buyer with wealthy transaction historical past will get a excessive transaction tower weight, whereas a brand new buyer with few transactions however clear demographics will get a excessive buyer tower weight. This adaptivity improves accuracy and gives pure explainability for relationship managers and regulators.

Context-Conscious Fusion: Residual blocks for secure coaching

The weighted tower outputs move via a fusion community with residual connections. Residual connections assist with gradient stream throughout coaching and permit the community to be taught id mappings when further depth isn’t wanted.

class ContextAwareFusion(nn.Module):
    def __init__(self, hidden_dim=64, dropout=0.2):
        tremendous().__init__()
        self.initial_projection = nn.Linear(hidden_dim * 4, hidden_dim)
        self.fusion1 = nn.Sequential(
            nn.Linear(hidden_dim, hidden_dim * 2), nn.LayerNorm(hidden_dim * 2),
            nn.ReLU(), nn.Dropout(dropout), nn.Linear(hidden_dim * 2, hidden_dim)
        )
        self.layer_norm1 = nn.LayerNorm(hidden_dim)
        self.fusion2 = nn.Sequential(
            nn.Linear(hidden_dim, hidden_dim), nn.ReLU(), nn.Dropout(dropout)
        )
        self.layer_norm2 = nn.LayerNorm(hidden_dim)

    def ahead(self, weighted_outputs):
        concat = torch.cat(weighted_outputs, dim=1)
        projected = self.initial_projection(concat)
        out1 = self.layer_norm1(projected + self.fusion1(projected))  # Residual
        out2 = self.layer_norm2(out1 + self.fusion2(out1))  # Residual
        return out2

Characteristic Significance Module: Constructed-in explainability

Banking regulators require mannequin explainability. Somewhat than counting on post-hoc strategies, the structure features a Characteristic Significance Module that produces per-customer significance scores summing to 1.0 as a part of the ahead move.

class FeatureImportanceModule(nn.Module):
    def __init__(self, hidden_dim=64):
        tremendous().__init__()
        self.feature_contribution = nn.Sequential(
            nn.Linear(hidden_dim, 4), nn.Softmax(dim=1)
        )

    def ahead(self, fused_features, tower_weights):
        feature_importance = self.feature_contribution(fused_features)
        return feature_importance * tower_weights

This produces outputs like: “For this buyer, 40% of the advice was pushed by their product sequence, 30% by transaction patterns, 20% by demographics, 10% by behavioral section.” Relationship managers can use this to tailor their conversations with every buyer.

Coaching technique

The next desk summarizes the coaching configuration and the rationale behind every alternative.

All random seeds are fastened (PyTorch, NumPy, CUDA) for full reproducibility throughout coaching runs.

The coaching course of makes use of SageMaker AI with ml.g5.12xlarge cases. The SageMaker AI Python SDK gives a PyTorch Estimator that packages the coaching code, provisions GPU cases, runs coaching, and shops mannequin artifacts to Amazon S3 robotically.

from sagemaker.pytorch import PyTorch

estimator = PyTorch(
    entry_point="prepare.py",
    source_dir="src/",
    function=function,
    instance_count=1,
    instance_type="ml.g5.12xlarge",
    framework_version='2.5.0',
    py_version='py311',
    hyperparameters={
        'epochs': 50,
        'batch_size': 32,
        'learning_rate': 0.001,
    },
)

Analysis metrics

The mannequin is evaluated utilizing metrics that straight map to enterprise worth:

The manufacturing mannequin achieved robust efficiency throughout all metrics, with the proper product persistently showing within the top-3 suggestions. The characteristic significance module confirmed that the sequence tower (product adoption historical past) contributes probably the most sign, adopted by transaction patterns, buyer demographics, and behavioral segmentation.

Inference and deployment

The inference pipeline helps each batch scoring and real-time predictions utilizing SageMaker AI.

For batch scoring, SageMaker AI Batch Rework processes the whole buyer base nightly, producing top-k suggestions with explainability scores for every buyer. Outcomes are saved as JSON on Amazon S3 for consumption by CRM techniques and relationship supervisor dashboards.

For real-time predictions, a SageMaker AI real-time endpoint serves on-demand suggestions when a buyer logs into the cell banking app or a relationship supervisor opens a buyer profile.

Every suggestion consists of:

• Product ID and likelihood rating.
• Characteristic significance breakdown: share contribution from every tower.
• Confidence indicator: primarily based on likelihood distribution entropy.

def generate_batch_recommendations(mannequin, dataloader, top_k=5):
    with torch.no_grad():
        for batch in dataloader:
            outputs, feature_importance = mannequin(
                batch['sequence'], batch['seq_length'],
                batch['active_count'], batch['transaction'],
                batch['customer'], batch['behavioral']
            )
            possibilities = F.softmax(outputs, dim=1).cpu().numpy()
            # Generate top-k suggestions with explainability scores

For steerage on securing endpoints with IAM authentication, fee limiting, and digital non-public cloud (VPC) isolation, see the Security considerations section.

Be aware: The code snippets on this submit illustrate architectural patterns and should not production-ready. For manufacturing, add enter validation (tensor shapes, NaN checks, sequence size bounds and so forth.), error dealing with, and inference logging. Configure Amazon SageMaker Mannequin Monitor to alert on enter distribution drift.

Key design choices

• Why multi-tower over a single community? A single community would wish to concurrently learn to course of sequences, combination transactions, encode demographics, and interpret behavioral segments. Separate towers let every specialise in its knowledge sort, then the attention-based fusion learns learn how to mix them optimally per buyer.
• Why GRU for manufacturing over Transformers? Transformers excel on lengthy sequences (100+). For sequences of 20 objects or fewer, GRU is enough, gives clearer interpretability than transformer consideration maps, avoids quadratic consideration computation, and produces a smaller mannequin (~5 MB in comparison with ~15 MB).
• Why realized tower weights as a substitute of concatenation? With concatenation, the mannequin treats all towers equally for each buyer. With realized consideration weights, the mannequin adapts per buyer: a buyer with wealthy transaction historical past will get excessive transaction tower weight, whereas a brand new buyer will get excessive demographic tower weight.
• Why time-windowed transaction options? Totally different time home windows seize totally different indicators: 7 days captures speedy intent, 30 days captures month-to-month patterns, 180 days captures seasonal patterns, and 12 months captures annual patterns. A buyer who instantly will increase transaction frequency within the final 7 days has totally different intent than one with regular exercise over 12 months.

Operational issues

All random seeds are fastened throughout PyTorch, NumPy, and CUDA for deterministic coaching. Mannequin artifacts, hyperparameters, and knowledge variations are tracked via Amazon SageMaker Experiments.

Amazon SageMaker Mannequin Monitor detects knowledge drift (adjustments in enter characteristic distributions), mannequin drift (degradation in prediction high quality), and potential bias (over-reliance on demographic options).

The Amazon SageMaker Pipelines workflow retrains the mannequin month-to-month with the newest buyer knowledge. The pipeline automates the total workflow: knowledge processing, coaching, analysis, and conditional deployment (deploying provided that metrics enhance over the present manufacturing mannequin).

Safety issues

• When deploying this answer with actual banking knowledge, implement least-privilege IAM roles scoped to solely the required SageMaker AI, Amazon S3, AWS Glue, and CloudWatch actions.
• Encrypt knowledge at relaxation utilizing AWS Key Administration Service (AWS KMS) buyer managed keys on S3 buckets and SageMaker AI coaching volumes, and implement TLS for all knowledge in transit by way of S3 bucket insurance policies.
• Deploy coaching jobs and endpoints in non-public VPC subnets with no web gateway, use VPC endpoints (AWS PrivateLink) for AWS service communication, and set enable_network_isolation=True on coaching jobs.
• Safe inference endpoints with AWS Signature Model 4 signing, and think about Amazon Cognito and Amazon API Gateway for shopper authentication and fee limiting.
• For knowledge governance, assess regulatory obligations (PCI-DSS, GDPR, CCPA), implement knowledge minimization, and outline retention insurance policies.
• Allow AWS CloudTrail for API audit logging and S3 versioning for mannequin artifact integrity.

For full implementation steerage, see the SageMaker AI safety documentation.

Clear up

To keep away from ongoing AWS prices, delete the next sources after you end evaluating this answer.

• SageMaker AI endpoints and endpoint configurations.
• SageMaker AI fashions and coaching job output in Amazon S3.
• Amazon SageMaker Processing job output in Amazon S3.
• SageMaker AI Batch Rework jobs and configurations.
• Amazon SageMaker Pipelines definitions.
• Amazon SageMaker Mannequin Monitor schedules.
• Amazon SageMaker Experiments trials and experiment knowledge.
• Amazon S3 buckets containing coaching knowledge, mannequin artifacts, and batch remodel outcomes.
• AWS Glue ETL jobs and Knowledge Catalog sources.
• CloudWatch log teams created by SageMaker AI and AWS Glue.

You may delete these sources via the AWS Administration Console or utilizing the AWS Command Line Interface (AWS CLI).

Warning: Deleting these sources is irreversible. Earlier than continuing:

• Export any mannequin artifacts or analysis outcomes you might want to retain.
• Confirm that deletion aligns along with your knowledge retention insurance policies and regulatory necessities.
• Delete all S3 object variations if versioning is enabled.
• Take away IAM roles and insurance policies created for this answer.
• Deleting S3 buckets completely removes all coaching knowledge, mannequin artifacts, and batch remodel outcomes.

Conclusion

This submit confirmed learn how to construct a Subsequent-Greatest-Product suggestion system for banking utilizing PyTorch and SageMaker AI. The multi-tower structure with realized consideration fusion achieves excessive prediction accuracy whereas offering the explainability required by banking regulators.

The important thing takeaways are:

• Specialised towers for various knowledge varieties outperform monolithic architectures for heterogeneous banking knowledge.
• GRU-based sequence processing captures temporal product adoption patterns that flat characteristic aggregation misses.
• Discovered tower consideration gives each accuracy positive aspects and per-customer explainability with out post-hoc interpretation strategies.
• SageMaker AI gives the end-to-end infrastructure for coaching, mannequin administration, and inference at scale.

You may adapt this multi-tower structure to your individual product catalog and buyer knowledge. To get began, discover the SageMaker AI documentation. For extra examples of PyTorch on AWS, see PyTorch on AWS. If you need assist constructing a suggestion system in your group, contact an AWS consultant.

Concerning the authors