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, customized product suggestions stays a major problem. Conventional rule-based programs 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-Finest-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 companies 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’re constructing suggestion programs for monetary companies or different domains with heterogeneous buyer knowledge, the architectural patterns described right here may also help you design extra correct and interpretable fashions.

Conditions

To comply with 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 position with entry to the next AWS companies. 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. Record, 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 position 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 surroundings and scanning dependencies for recognized vulnerabilities utilizing instruments like pip-audit earlier than deployment.

• Fundamental 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 costs.

Resolution overview

The answer makes use of a multi-tower deep studying structure with 4 specialised neural community towers, every processing a special side 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 almost certainly to buy subsequent from a number of product classes (comparable to bank cards, deposits, insurance coverage, loans, and mortgages), whereas offering explainable outcomes that fulfill regulatory necessities.

Tech stack

The next desk summarizes the expertise decisions 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 permits column pruning (studying a fraction of a large file), predicate pushdown (skipping irrelevant row teams), 3-5× compression over CSV, and sort preservation with out re-parsing on each learn.

Why AWS Glue for ETL?

The venture makes use of AWS Glue jobs operating on PySpark for serverless, auto scaling knowledge processing. AWS Glue gives native Spark integration, the DynamicFrame API for versatile schemas, computerized Knowledge Catalog registration, job bookmarks for incremental processing, and pay-per-DPU value 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 programs with inconsistent schemas. The AWS Glue ETL job normalizes schemas, maps uncooked transaction sorts to unified service classes, combines all knowledge right into a single chronological document 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 set size for mannequin enter.

Dealing with massive scale knowledge

For giant datasets that exceed out there 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()  # Pressure rubbish assortment between batches

Be aware: When working with actual buyer knowledge, see the Safety concerns part 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 makes a speciality of processing one kind 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 by the identical layers wastes mannequin capability. As an alternative, the structure makes use of 4 specialised towers, every designed for its knowledge kind:

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, overlook, output), leading to roughly 33% fewer parameters. For brief sequences (20 gadgets or fewer), GRU performs comparably to LSTM whereas coaching quicker. 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 an alternative of straightforward 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 by a fusion community with residual connections. Residual connections assist with gradient circulation throughout coaching and permit the community to be taught identification mappings when extra depth just 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. Relatively 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 selection.

All random seeds are mounted (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 mechanically.

from sagemaker.pytorch import PyTorch

estimator = PyTorch(
    entry_point="practice.py",
    source_dir="src/",
    position=position,
    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 instantly map to enterprise worth:

The manufacturing mannequin achieved sturdy efficiency throughout all metrics, with the proper product constantly 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 Remodel processes your complete 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 programs and relationship supervisor dashboards.

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

Every suggestion contains:

• 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, price limiting, and digital non-public cloud (VPC) isolation, see the Safety concerns part.

Be aware: The code snippets on this submit illustrate architectural patterns and aren’t production-ready. For manufacturing, add enter validation (tensor shapes, NaN checks, sequence size bounds and so on.), 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 want to concurrently learn to course of sequences, mixture transactions, encode demographics, and interpret behavioral segments. Separate towers let every concentrate on its knowledge kind, then the attention-based fusion learns how you can mix them optimally per buyer.
• Why GRU for manufacturing over Transformers? Transformers excel on lengthy sequences (100+). For sequences of 20 gadgets or fewer, GRU is ample, 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 an alternative 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 three hundred and sixty five days captures annual patterns. A buyer who abruptly will increase transaction frequency within the final 7 days has totally different intent than one with regular exercise over three hundred and sixty five days.

Operational concerns

All random seeds are mounted throughout PyTorch, NumPy, and CUDA for deterministic coaching. Mannequin artifacts, hyperparameters, and knowledge variations are tracked by 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 complete workflow: knowledge processing, coaching, analysis, and conditional deployment (deploying provided that metrics enhance over the present manufacturing mannequin).

Safety concerns

• 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 take into account Amazon Cognito and Amazon API Gateway for client authentication and price 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 costs, 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 Remodel 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 possibly can delete these sources by 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 how you can construct a Subsequent-Finest-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 sorts 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 factors 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 possibly can adapt this multi-tower structure to your individual product catalog and buyer knowledge. To get began, discover the SageMaker AI documentation. For added examples of PyTorch on AWS, see PyTorch on AWS. If you want assist constructing a suggestion system to your group, contact an AWS consultant.

Concerning the authors