Cross-border logistics risk warning system based on federated learning

SafeLogFL is a secure and Federated Logistics Risk Alert System that uses FL for privacy-aware cross-border logistics risk warning collaboration. It maintains confidentiality by training local models on confidential datasets, communicating model updates to a central server, and computing them with the Fed Avg algorithm. Figure 2 shows the working process of the SafeLogFL framework.

Data collection

Data collection in the SafeLogFL framework is based on a decentralized architecture where each party e.g., shipping lines, customs, and port operators has and processes its operational data locally. This strategy protects sensitive data within organizations, enabling GDPR compliance and data privacy. Each organization warehouses structured records like shipping information customs information, and disruption to operations. SafeLogFL supports local data management and computation to prevent data exposure and enable secure interactive instruction without central hosting.

A non-IID partitioning technique was used to distribute the dataset across the clients in the SafeLogFL studies. This was done to provide an accurate representation of the cross-border logistics scenarios encountered. Only the local operational data of each client is stored, and each client corresponds to a stakeholder, such as a shipping business, port authority, or customs agency. The data segmentation was carried out according to geographical locations and the types of shipments, which meant that each customer had records from specific warehouses, shipping routes, or cargo classifications. This guarantees that local models capture patterns that are distinct to stakeholders, thereby emulating the heterogeneity that exists in the real world. The FedAvg algorithm aggregates the locally trained models, taking into consideration the non-IID distribution, while also protecting the confidentiality of the data. Due to its close simulation of genuine multi-stakeholder logistics networks, this partitioning technique enhances the validity and reproducibility of the results.

Data preprocessing

Every stakeholder (\(\:{P}_{i}\)) in the SafeLogFL platform does local preprocessing on its dataset (\(\:{D}_{i}\)) to prepare the data for model training. The process starts with feature extraction, where appropriate attributes are chosen or extracted from raw logistic data. Such features include shipment weight, transport distance, port traffic index, and history of delays records, mathematically represented as a feature vector \(\:x=[shipment\_weight,\:\:distance,port\_traffic\_index,delay\_history,\dots\:]\). To ensure numerical stability and boost the performance of the model, each stakeholder standardizes its data individually using the formula \(\:x{\prime\:}=\frac{x-{\mu\:}_{i}}{{\sigma\:}_{i}}\)​​ ​, in which \(\:{\mu\:}_{i}\) and \(\:{\sigma\:}_{i}\)​ are the mean and standard deviation of the features of dataset (\(\:{D}_{i}\)). Subsequently, each data instance is assigned a label \(\:{y}_{j}^{i}\), based on historical results. For binary risk classification, the label is denoted as in Eq. 1.

Preprocessing operations are done locally so that no raw data is communicated outside the organization. Model parameters (e.g., weight updates) are only passed during federated training time, shown as \(\:{D}_{i}\:\nrightarrow\:central\:server\).

Model training with federated learning

In the SafeLogFL framework, after local data preprocessing, every involved stakeholder learns its machine learning model independently on its local data, e.g., shipping company, port authority, or customs agency. This regional model does not share sensitive information and is a Federated Learning (FL) building block.

Model architecture: Multi-Layer perceptron (MLP)

In SafeLogFL, a neural network MLP learns from structured log data like shipping data, port traffic, and customs manifests. Figure 3 shows the architecture of an MLP in the SafeLogFL framework.

MLP is an artificial feed forward neural network that receives input features and outputs predictions, propagating through a series of computation layers. It can be applied particularly well to tabular classification problems, e.g., forecasting delay or logistics disruption. The structure of an MLP with (\(\:L\)) layers are shown in Table 4.

Where \(\:{h}_{i-1}\)​ is the output from the previous layer (or input \(\:x\:if\:i=1\)) \(\:{W}_{i}\)​ is the weight matrix. \(\:{b}_{i}\)​ is the bias vector, \(\:{f}_{i}(\cdot\:)\) is the activation function (typically ReLU: \(\:f\left(z\right)=max(0,z)\)), \(\:\sigma\:\) is the sigmoid function is for binary classification, \(\:{W}_{L}\:and\:{b}_{L}\)​ are the weights and biases of the output layer, \(\:{h}_{L-1}\)​ is the output of the last hidden layer, \(\:\widehat{y}\:\in\:\left(\text{0,1}\right)\) represents the predicted probability of a shipment being delayed. Equation 2 summarizes the overall output of the MLP with \(\:L\) layers.

This expression denotes the transformation of the input through a series of layers, each applying weighted sums and activation functions, ultimately producing a probabilistic output. Figure 4 shows the MLP layer flow for logistics in the SafeLogFL framework.

Model updates and global model aggregation in federated learning

After the model has been initialized, every participant (e.g., a warehouse or a supplier) conducts local training on its data and calculates model updates, i.e., weights and gradients. These updates, not the original data, are uploaded to the central server. The central server collects these updates via the Federated Averaging (Fed Avg) algorithm and averages all participants’ weights to create an accurate global model without sacrificing privacy.

The global model aggregating process enables the central server to combine the locally updated models into a global model. The updated global model signifies learning from data for all stakeholders, acquiring valuable insights unavailable in any individual dataset. The global model is remitted to participants after aggregation, updated with respective data if required.

1. 1.

   Initialization: The central server initializes a global model \(\:{w}_{0}\)​.

2. 2.

   Broadcast: The server sends the current global model \(\:{w}_{t}\)​ to selected clients (e.g., individual warehouses).

3. 3.

   Local Training: Each client \(\:k\) trains the model on its local data for a few epochs and computes updated model parameters \(\:{w}_{t}^{k}\)​.

4. 4.

   Send Updates: Each client sends its updated model \(\:{w}_{t}^{k}\)​ back to the central server.

5. 5.

   Aggregation (Fed Avg): The server aggregates all client updates using Fed Avg to obtain the new global model \(\:{w}_{t+1}\)​.

6. 6.

   Repeat: this process continues for multiple rounds.

Algorithm 1 describes training a global model through FL in order. It preserves data privacy because clients can train models locally and transmit only model updates to a central server, aggregating them using the Fed Avg technique.

In a FL environment, the training process starts with the central server starting the weights of the global model as \(\:{w}_{0}\). Every client (\(\:k\)) keeps its local data set represented as (\(\:{D}_{k}\)), which is kept on the client to maintain data privacy. For every communication round \(\:t\), a subset of clients (\(\:{S}_{t}\)) is picked to help train. The global model \(\:{w}_{t}\) is then sent to these selected clients. Each client trains locally on its data (\(\:{D}_{k}\)) using the global weights as initial weights. The process, Local Train (\(\:{w}_{t}\)​ ,\(\:{D}_{k}\)​ ), produces new local model weights (\(\:{w}_{t}^{k}\)). Apart from these weights, each client sends the local dataset size, \(\:{n}_{k}\). The global server then aggregates all client updates and calculates the new global model (\(\:{w}_{t+1}\)) based on the Fed Avg algorithm. This is done by calculating a weighted average of the clients’ updates to their models, where each client’s contribution to the aggregate is weighted by its data size compared to the total data in all the clients involved. Figure 5 shows the global model aggregation in federated learning.

Every client \(\:k\), one of the different cross-border logistics participants, trains the model locally on its local dataset \(\:{D}_{k}\) and receives an updated model \(\:{w}_{t}^{k}\). The number of samples from the data in client k is \(\:{n}_{k}\). Once locally trained, the clients return their new model weights to the server. The server then aggregates the global model and the Fed Avg algorithm. The updated global model \(\:{w}_{t+1}\:\) is calculated as a weighted sum of the clients’ updates, with each client’s update weighted by the size of the local data, as in Eq. 3.

Here, \(\:n\) stands for the total number of clients’ samples, and \(\:K\) for the number of clients encompassed. During the aggregation phase, clients with more or broader data sets would have greater control over the novel global model.

The aggregate \(\:{w}_{t+1}\:\)​model captures are then redistributed to all participants to continue training or fine-tuning. This continuous process improves the model’s risk factor capture capacity and anomaly prediction in various logistics environments, yielding a strong cross-border risk warning system that ensures data sovereignty and privacy regulations.

Model update frequency and adaptability

The update frequency of how SafeLogFL updates its model plays a crucial role in maintaining the system’s accuracy and responsiveness to new threats. Depending on circumstances, the model updates might be in varied forms:

• For operations or routes that do not often alter, updates can be batched—e.g., once a day or once weekly. This is suitable if fast change is less likely to occur and the compute and network usage is less.

• More updates can be done in rapidly changing or high-risk situations. Here, everyone often updates the model on small chunks of new information and transmits more quickly. This allows the system to respond more to new problems such as delays, weather, or immediate policy changes.

SafeLogFL’s adaptive nature enables it to work efficiently even in fluctuating scenarios, updating the global model accurately and consistently. Table 5 compares SafeLogFL’s model update strategies based on operational context, responsiveness, and system efficiency.

Risk prediction and alerts using the federated global model

After the global model has been trained and retrained using the Federated Learning (FL) process, it is applied in carrying out risk forecasting operations on the logistics network. The key aim of this phase is early identification of potential disruption in advance and issuing warnings to stakeholders like warehouses, suppliers, and transportation companies. Cross-border logistics shared risk drivers are Ship-out delays because of border congestion or customs inspection, Customs issues because of incomplete or conflicting documentation, Supply chain disruption because of weather, labor strikes, or inventory differences. With the trained global model, every participating client can forecast whether an impending shipment or operation will likely be at risk, based on features derived from historical and real-time logistics data.

Input features for risk prediction

Let \(\:{x}_{i}\)​ represent the feature vector for the \(\:{i}^{th}\) shipment or transaction. Each sample \(\:{X}_{i}\)\mathbf{x}_i\(\:{X}_{i}\)​ is associated with a label \(\:{y}_{i}\), as in Eq. 4.

Prediction using the global model

Let \(\:f(\cdot\:;w)\) Denote the trained global model parameterized by weights \(\:w\). Given an input feature vector \(\:{x}_{i}\)​The model outputs a predicted probability of risk. This can be obtained through Eq. 5.

If \(\:{\widehat{y}}_{i}\ge\:\tau\:\), where \(\:\tau\:\in\:\left[\text{0,1}\right]\) is a predefined risk threshold, then the shipment is considered at risk and an alert is triggered. The alert mechanism is shown in Eq. 6.

The threshold \(\:\tau\:\) The threshold may be set based on the stakeholder’s risk tolerance. For example, it may be lower for high-priority global shipments to detect more potential anomalies, whereas it may be higher for regular shipments to reduce false alarms. If.

\(\:x=[3\:days\:to\:delivery,250\:km\:route,1\:customs\:check,incomplete\:documentation,bad\:weather]\) Feeding this into the global model yields,

.

If τ = 0.75, then \(\:\widehat{y}=0.82\ge\:\tau\:=0.75\Rightarrow\:Alert=1\).

Therefore, the system gives the logistics operator an early warning to react, such as rerouting, adding documentation, or pre-notifying customs.

SafeLogFL can be more responsive by integrating it with real-time logistics tracking systems and live data feeds. By being linked to live data feeds, such as shipping tracking systems, GPS data, customs inspection status, or weather forecasts, SafeLogFL can be fed continuous new input features for risk prediction. The integration enables proactive decision-making, and logistics partners can take early action to preclude or reduce delays and compliance problems.

Privacy and compliance in federated learning

The use of FL on a cross-border logistics warning system is its capacity to keep sensitive and proprietary information secure while allowing for concurrent model training and cooperative sharing. In FL, unprocessed training data is never disclosed beyond the organizational boundary or the local device. All users update the model locally based on their local dataset (operational records, shipment files, and history of incidents, e.g.) and send just the model updates to the server (as weights or gradients, say). Nothing that involves revealing a single point data is shared from any update.

Legal and regulatory compliance

Federated Learning supports data protection laws by design directly:

GDPR: GDPR is focused on data minimization and locality. FL aligns with these principles since it prevents the transfer or centralization of personal data.

Data Residency Requirements: Certain jurisdictions mandate that data created within their borders be stored and processed locally. FL ensures computation is done where the data is located, inherently satisfying such regulations.

Confidential Business Information: Global supply chain firms view logistics information as confidential. FL architecture allows for cooperative intelligence without any party revealing sensitive operation details.

Security improvements

Apart from imposing compliance and privacy, FL systems can also include:

Secure Aggregation Protocols: These protocols do not allow the server to observe a client update, only the aggregated result.

Differential Privacy: By introducing controlled noise to the updates, FL systems can make individual data records impossible to infer even from model updates.

Authentication and Access Control: Only authorized participants can engage in training rounds, excluding unauthorized access to data exchanges and model updates.

Collaborative trust model

The decentralized nature of FL facilitates a secure environment where autonomous stakeholders with varying legal and cultural paradigms can yet find value in shared accumulated knowledge. This is particularly relevant in cross-border logistics where international coordination is necessary, but information sharing has legal and ethical limits.

Table 6 compares typical centralised logistics systems with the SafeLogFL solution. Typical systems gather all data in one location, which means greater risks of data breaches and hinders compliance with privacy regulations. SafeLogFL has a decentralised system where data is on the periphery and only transmits model updates. This significantly minimizes privacy attacks, simplifies GDPR compliance, and allows secure regional collaboration. Therefore, SafeLogFL presents a safer and privacy-conscious solution for risk management of worldwide logistics.

Research methodology

This paper introduces the Secure and Federated Logistics Risk Warning System with Federated Learning (SafeLogFL) to address these issues. SafeLogFL utilizes a Multi-Layer Perceptron (MLP) neural network to learn the structured logistics data like shipment history and customs declarations. All parties train the model locally using their local data without sharing any raw data. Model updates are exchanged and combined by using the Federated Averaging (Fed Avg) algorithm. This decentralized training approach maintains confidentiality, honors regulatory compliance, such as GDPR, and increases system resilience by eliminating points of central failure. This approach facilitates cooperative risk forecasting among entities while safeguarding sensitive data and provides real-time alerting for cross-border logistics delay, fraud, and non-compliance.