AWS で銀行向け説明可能な商品推薦システムを構築

Building a deep learning-based explainable next-best-product recommendation system helps banking institutions predict which product a customer needs next. Banks hold vast amounts of customer data, including transaction histories, product ownership records, demographic profiles, and behavioral patterns. Translating this data into actionable, personalized product recommendations remains a significant challenge. Traditional rule-based systems and collaborative filtering approaches often fail to capture the complex temporal patterns in customer product adoption journeys.

In this post, we present the architecture and design decisions behind a Next-Best-Product (NBP) recommendation system using Amazon SageMaker AI and PyTorch. We explain the reasoning behind a multi-tower neural network architecture, how learned attention provides per-customer explainability, and how AWS services work together to take this solution from research to production. This is an architectural overview, not a step-by-step deployment guide. Whether you are building recommendation systems for financial services or other domains with heterogeneous customer data, the architectural patterns described here can help you design more accurate and interpretable models.

Prerequisites

To follow along with the architectural patterns and code examples in this post, you need:

• An AWS account with permissions for SageMaker AI, Amazon Simple Storage Service (Amazon S3), AWS Glue, and Amazon CloudWatch

• This solution requires an AWS Identity and Access Management (IAM) execution role with access to the following AWS services. Create policies with least-privilege permissions scoped to only the resources needed for this solution.

• SageMaker AI – Create, describe, start, stop, and delete training jobs, processing jobs, batch transform jobs, models, endpoints, endpoint configurations, pipelines, experiments, and monitoring schedules. InvokeEndpoint for real-time inference.

• Amazon S3 – Read and write access to the data bucket. Create and delete bucket. List, upload, download, and delete objects.

• AWS Glue – Create, run, and delete ETL jobs. Create and delete crawlers. Create and delete Data Catalog databases and tables.

• CloudWatch – Read and write access to log groups, log streams, and metrics. Delete log groups during cleanup.

• IAM – Create and delete roles. Attach and detach policies. PassRole (restricted to the named execution role ARN, scoped to sagemaker.amazonaws.com and glue.amazonaws.com).

For guidance on writing least-privilege IAM policies for SageMaker AI, see Identity-based policy 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 recommend using a virtual environment and scanning dependencies for known vulnerabilities using tools like pip-audit before deployment.

• Basic understanding of deep learning concepts (embeddings, recurrent networks, attention mechanisms)

Note: Deploying this solution creates billable AWS resources including SageMaker AI training jobs (ml.g5.12xlarge GPU instances), SageMaker AI endpoints, Amazon S3 storage, and AWS Glue jobs. Follow the clean up instructions at the end of this post to avoid ongoing charges.

Solution overview

The solution uses a multi-tower deep learning architecture with four specialized neural network towers, each processing a different aspect of customer data. The towers are fused using a learned attention mechanism that provides both high accuracy and per-customer explainability.

The following diagram illustrates the high-level architecture of the solution.

The architecture addresses a common challenge in banking: predicting which product a customer is most likely to purchase next from multiple product categories (such as credit cards, deposits, insurance, loans, and mortgages), while providing explainable results that satisfy regulatory requirements.

Tech stack

The following table summarizes the technology choices and their roles in the solution.

Component

Technology

Purpose

ETL & Data Processing

AWS Glue (PySpark)

Serverless Spark-based ETL for data unification, service mapping, feature engineering at scale

Deep Learning Framework

PyTorch

Dynamic computation graphs, research-to-production flexibility, native GPU support

Feature Engineering

Pandas, Dask, PyArrow

ML-specific feature engineering (sequence creation, windowed aggregations)

ML Utilities

scikit-learn

Label encoding, standard scaling, train/test split, evaluation metrics

Training Compute

SageMaker AI (ml.g5.12xlarge)

192 GB RAM, 4× NVIDIA A10G GPUs

Data Storage

Amazon S3

Snappy-compressed Parquet files for raw, intermediate, and processed data

Data Catalog

AWS Glue Data Catalog

Schema management, table metadata, crawlers for auto-discovery

Model Registry

SageMaker AI model registry

Versioned model artifacts, approval workflows

Inference

SageMaker AI Batch Transform / endpoint

Batch and near-real-time predictions

Orchestration

Amazon SageMaker Pipelines

End-to-end ML pipeline orchestration

Monitoring

CloudWatch

Training metrics, inference latency, model drift detection

Why PyTorch?

This solution uses PyTorch for dynamic computation graphs (needed for variable-length sequences with pack_padded_sequence), rapid iteration across multiple architectural phases, and native integration with SageMaker AI training jobs and inference containers.

Why Parquet on Amazon S3?

The solution stores data as Snappy-compressed Parquet on Amazon Simple Storage Service (Amazon S3). Parquet’s columnar format enables column pruning (reading a fraction of a wide file), predicate pushdown (skipping irrelevant row groups), 3-5× compression over CSV, and type preservation without re-parsing on every read.

Why AWS Glue for ETL?

The project uses AWS Glue jobs running on PySpark for serverless, auto scaling data processing. AWS Glue provides native Spark integration, the DynamicFrame API for flexible schemas, automatic Data Catalog registration, job bookmarks for incremental processing, and pay-per-DPU cost efficiency.

Data pipeline architecture

The data pipeline consists of two stages: an AWS Glue ETL job for data unification, followed by an Amazon SageMaker Processing job for ML-specific feature engineering.

Data unification with AWS Glue

Banking data typically arrives from multiple source systems with inconsistent schemas. The AWS Glue ETL job normalizes schemas, maps raw transaction types to unified service categories, combines all data into a single chronological record per customer, and engineers temporal features. The processed output is written as Parquet to Amazon S3 and registered in the AWS Glue Data Catalog.

ML-specific feature engineering with Amazon SageMaker Processing

After the AWS Glue job produces the unified history, an Amazon SageMaker Processing job creates product adoption sequences per customer, computes time-windowed transaction aggregations (across 7, 30, 60, 180, and 365-day windows) using Dask for parallelism, and pads sequences to a fixed length for model input.

Handling large scale data

For large datasets that exceed available memory, the solution uses a parallel chunked processing strategy with PyArrow for metadata inspection, ProcessPoolExecutor for parallel chunk processing, explicit garbage collection between batches, and incremental merging to avoid memory spikes.

import gc
from concurrent.futures import ProcessPoolExecutor

chunksize = 5_000_000
n_workers = 4

for batch_start in range(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.result()
    gc.collect()  # Force garbage collection between batches

Note: When working with real customer data, see the Security considerations section for guidance on PII handling, regulatory compliance, and data governance.

Model architecture

The model uses a multi-tower approach where each tower specializes in processing one type of customer data, followed by an attention-based fusion mechanism.

Why multi-tower over a single network?

Different types of customer data have fundamentally different structures. Sequences are ordered lists of discrete IDs. Transactions are numerical aggregations. Demographics are a mix of categorical and numerical features. Behavioral segments are categorical codes.

Forcing all these through the same layers wastes model capacity. Instead, the architecture uses four specialized towers, each designed for its data type:

Tower

Input Type

Architecture

Output

Sequence Tower

Product adoption history (padded to fixed length)

nn.Embedding → 2-layer GRU → Fusion with active product count

64-dim vector

Transaction Tower

Time-windowed transaction features

2-layer MLP (128 → 64) with ReLU and Dropout

64-dim vector

Customer Tower

Demographics, income, family, account features

2-layer MLP (128 → 64) with ReLU and Dropout

64-dim vector

Behavioral Tower

Segmentation codes, loyalty, usage patterns

2-layer MLP (128 → 64) with ReLU and Dropout

64-dim vector

Sequence Tower: Capturing temporal patterns

The Sequence Tower processes the customer’s product adoption history using a 2-layer Gated Recurrent Unit (GRU). This is the core architectural component because it captures the order in which customers adopt products, not just which products they own.

class SequenceTower(nn.Module):
    def __init__(self, num_products, embedding_dim=32, hidden_dim=64, dropout=0.2):
        super().__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 forward(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, update) versus LSTM’s three (input, forget, output), resulting in approximately 33% fewer parameters. For short sequences (20 items or fewer), GRU performs comparably to LSTM while training faster. The update gate’s interpolation mechanism also creates a natural residual-like gradient path.

Why pack_padded_sequence?

Customer sequences have variable lengths. Packing tells the GRU to ignore padding tokens, preventing the model from learning noise from zero-padded positions.

Tower Attention Mechanism: Learned fusion with explainability

Instead of simple concatenation, the architecture uses a learned attention mechanism to fuse tower outputs. This is what provides per-customer explainability without requiring post-hoc interpretation methods like SHAP or LIME.

class TowerAttentionMechanism(nn.Module):
    def __init__(self, hidden_dim=64, num_heads=4, dropout=0.1):
        super().__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 forward(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 range(4)
        ]
        return weighted_outputs, tower_weights

The tower weights are per-customer. A customer with rich transaction history gets a high transaction tower weight, while a new customer with few transactions but clear demographics gets a high customer tower weight. This adaptivity improves accuracy and provides natural explainability for relationship managers and regulators.

Context-Aware Fusion: Residual blocks for stable training

The weighted tower outputs pass through a fusion network with residual connections. Residual connections help with gradient flow during training and allow the network to learn identity mappings when additional depth is not needed.

class ContextAwareFusion(nn.Module):
    def __init__(self, hidden_dim=64, dropout=0.2):
        super().__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 forward(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

Feature Importance Module: Built-in explainability

Banking regulators require model explainability. Rather than relying on post-hoc methods, the architecture includes a Feature Importance Module that produces per-customer importance scores summing to 1.0 as part of the forward pass.

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

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

This produces outputs like: “For this customer, 40% of the recommendation was driven by their product sequence, 30% by transaction patterns, 20% by demographics, 10% by behavioral segment.” Relationship managers can use this to tailor their conversations with each customer.

Training strategy

The following table summarizes the training configuration and the rationale behind each choice.

Parameter

Value

Rationale

Optimizer

Adam (lr=0.001, weight_decay=1e-5)

Adaptive per-parameter learning rates, light L2 regularization

Loss

CrossEntropyLoss

Standard for multi-class classification, numerically stable

LR Scheduler

ReduceLROnPlateau (factor=0.5, patience=3)

Automatically halves LR when validation loss plateaus

Gradient Clippi