Chapter 3 presents a hierarchical framework for blockchain-based immigration management, where subsections follow a workflow from system architecture to real-world validation. “Overview of the peer nodes” section introduces the node roles and PBFT consensus, forming the foundation for secure transactions. “Connecting web application with hyperledger fabric” and “Identity and document management” sections detail document and financial workflows, which rely on the node architecture. “Financial integration layer” and “Customs and security monitoring” sections address customs and tax compliance, leveraging the verified data from earlier stages. Finally, “Tax compliance monitoring”, “Application and integration layer”, “Authority access and verification”, “Security and privacy layer” sections ensure system integrity through authority access controls, anomaly detection, and smart contract deployment. This structure mirrors the operational lifecycle of immigration processes: from submission (3.2) to verification (3.3), compliance (3.4–3.5), and auditing (3.6–3.9).
The proposed blockchain-based immigration management system (Fig. 1) employs a three-layer architecture integrating application interfaces, distributed ledger infrastructure, and data storage components. At the application layer, user-facing portals (web and mobile) and REST APIs facilitate document submission and status tracking through Hyperledger Fabric’s Node SDK. The blockchain layer orchestrates four specialized node types: government nodes (\(N_g\)) for identity verification, financial nodes (\(N_f\)) for AML/CTF compliance, customs nodes (\(N_c\)) for border security monitoring, and integration nodes (\(N_t\)) for legacy system migration, all communicating through segregated private channels (\(C_{\text {ID}}\), \(C_{\text {Fin}}\), \(C_{\text {Cust}}\)) to maintain data confidentiality. Practical Byzantine Fault Tolerance (PBFT) consensus ensures transaction finality with \(N \ge 3f + 1\) fault resilience, while three core smart contracts – DocContract (AES-256/SHA-256 document processing), FinContract (LSTM-based risk scoring), and MigrateContract (XOR hash validation) – automate critical workflows. The data layer bridges on-chain governance with off-chain resources including legacy databases, Interpol/FATF APIs, and IPFS storage, employing Merkle proofs for efficient auditability. This architecture achieves GDPR-compliant privacy through zero-knowledge document verification while maintaining 1,200 TPS throughput and sub-second latency for high-volume immigration processing.
Fig. 1
System architecture of the proposed work.
Overview of the peer nodes
The proposed Immigration and Expatriate Management System is designed using Hyperledger Fabric v2.5.5, incorporating the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism. While Hyperledger Fabric supports modular consensus, enabling the integration of mechanisms such as Proof-of-Authority (PoA) and Proof-of-Stake (PoS), PBFT is selected for its ability to ensure both high scalability and security within a permissioned blockchain framework. The system architecture is modeled as a directed graph \(G = (V, E)\), where \(V\) represents the set of nodes \(\{N_g, N_f, N_c, N_i\}\), including Government Nodes \(N_g\), Financial Nodes \(N_f\), Customs Nodes \(N_c\), and Integration Nodes \(N_i\), while \(E\) denotes the communication channels facilitating secure data exchange and transactions among these nodes. Each transaction in the network, denoted as \(T_i\), consists of attributes: \(T_i = (ID, P, D, S, H, \sigma )\), where \(ID\) is the unique transaction identifier, \(P\) represents the participant identity, \(D\) corresponds to transaction data, \(S\) signifies the smart contract execution outcome, \(H\) is the SHA-256 transaction hash, and \(\sigma\) is the digital signature (e.g., ECDSA, RSA) ensuring authenticity.
The PBFT consensus operates through three sequential phases: Pre-Prepare, Prepare, and Commit, ensuring Byzantine fault tolerance. The consensus mechanism adheres to the relation \(N \ge 3f + 1\), where \(N\) is the total number of nodes in the network and \(f\) is the number of Byzantine nodes that can be tolerated. For instance, if the system must tolerate up to five malicious nodes (\(f = 5\)), then a minimum of \(N \ge 3(5) + 1 = 16\) nodes are required for the network to remain resilient. This guarantees robust security and prevents adversarial attacks, ensuring high transaction throughput and finality.
Government Nodes (\(N_g\)) serve as endorsing peers responsible for validating identity documents, processing visa and work permit applications, and assessing eligibility. The eligibility function is defined as \(f_{\text {elig}}(P)\), where
$$\begin{aligned} f_{\text {elig}}(P) = {\left\{ \begin{array}{ll} 1, & \text {if } P \text { satisfies all immigration criteria} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(1)
This function determines whether an applicant meets the predefined immigration conditions, ensuring only qualified individuals proceed with their applications.
Financial Nodes (\(N_f\)) ensure compliance with anti-money laundering (AML) and counter-terrorist financing (CTF) regulations by monitoring financial transactions. Each financial transaction is represented as \(T_f = (S_i, R_j, A, t, H)\), where \(S_i\) and \(R_j\) represent the sender and receiver identities, \(A\) denotes the amount transferred, \(t\) is the transaction timestamp, and \(H\) is the cryptographic hash. A financial transaction is flagged as suspicious if \(A> A_{\text {threshold}}\), where \(A_{\text {threshold}}\) is the regulatory limit imposed on cross-border remittances. This mechanism facilitates early detection of illicit financial activities, enhancing the security and transparency of transactions.
Customs Nodes (\(N_c\)) are responsible for tracking items carried by immigrants, ensuring compliance with customs regulations. The total value of items carried across borders is computed as
$$\begin{aligned} I_c = \sum _{k=1}^{n} w_k v_k \end{aligned}$$
(2)
where \(w_k\) represents the weight of item \(k\), \(v_k\) denotes its declared value, and \(n\) is the total number of items. If \(I_c\) exceeds predefined regulatory thresholds, an alert is triggered, prompting further inspection. This mechanism enhances border security by ensuring that undeclared or restricted items do not cross international borders undetected.
Integration Nodes (\(N_i\)) facilitate the seamless migration of existing passport and visa records from legacy systems to the Hyperledger Fabric infrastructure. To ensure data integrity during migration, a cryptographic hash verification process is employed, defined as
$$\begin{aligned} H’ = H_{\text {legacy}} \oplus H_{\text {new}} \end{aligned}$$
(3)
where \(H_{\text {legacy}}\) is the hash of the old record, \(H_{\text {new}}\) is the hash of the migrated record, and \(\oplus\) denotes the XOR operation. If \(H’\) deviates from an expected threshold, it indicates a data integrity issue, prompting immediate verification.
The network leverages private channels for secure communication, where each channel \(C_k\) is dedicated to a specific function, ensuring sensitive data remains accessible only to authorized entities. The set of channels is defined as \(C = \{C_{\text {ID}}, C_{\text {Fin}}, C_{\text {Cust}}, C_{\text {Int}}\}\), where \(C_{\text {ID}}\) is responsible for identity verification, \(C_{\text {Fin}}\) handles financial transactions, \(C_{\text {Cust}}\) monitors customs data, and \(C_{\text {Int}}\) facilitates data integration. This channel-based communication model enhances security, prevents data leakage, and optimizes network performance. The node architecture established here enables the document management pipeline described in “Connecting web application with hyperledger fabric” section.
PBFT-enhanced request processing in hyperledger fabric
In standard Hyperledger Fabric, consensus is typically achieved using Raft or Kafka, which provide crash fault tolerance (CFT). However, our framework enhances this by integrating Practical Byzantine Fault Tolerance (PBFT) to address Byzantine faults. This substitution significantly improves resilience against malicious or arbitrary node behaviors.
The process begins with the client request phase. Here, a client such as a visa applicant submits a transaction \(T_i\) to a government node \(N_g\), digitally signed using EdDSA. The transaction is structured as:
$$\begin{aligned} T_i = (ID, P, D, S, H, \sigma ) \end{aligned}$$
In this structure, the document \(D\) is encrypted using AES-256-GCM:
$$\begin{aligned} D = \text {AES-256-GCM(document)} \end{aligned}$$
The digital signature \(\sigma\) is computed over the hash of the transaction using EdDSA:
$$\begin{aligned} \sigma = \text {EdDSA.Sign}(H(T_i)) \end{aligned}$$
Following the request, the transaction enters the PBFT consensus process, which consists of three phases:
Pre-prepare: The primary node \(N_g\) assigns a sequence number to \(T_i\) and broadcasts it to all participating nodes.
Prepare: Each node validates the transaction’s signature, structure, and compliance with defined policies, then multicasts its prepare vote to other nodes.
Commit: Upon receiving at least \(2f + 1\) prepare votes (where \(f\) is the maximum number of faulty nodes tolerated), nodes execute \(T_i\) via smart contracts (e.g., DocContract) and then issue commit votes.
Despite the use of PBFT, our architecture maintains Fabric’s unique execute-order-validate model. In the execute phase, each node simulates the transaction against the current ledger state, including privacy and compliance checks such as GDPR enforcement using zk-SNARKs. In the order phase, PBFT replaces Raft as the ordering mechanism, finalizing the transaction sequence. The validate phase involves additional custom verifications, such as Merkle proof checks for document hash integrity, before committing the transaction to the ledger.
In scenarios involving multiple entities such as a visa workflow that requires consensus from both a government node \(N_g\) and a foreign node \(N_f\) our framework supports cross-channel coordination. Each channel runs its own instance of PBFT, and atomic commitment across these channels is managed using a two-phase commit protocol.
Connecting web application with hyperledger fabric
To establish seamless communication between the web application and the Hyperledger Fabric network, we utilize the Hyperledger Fabric Node SDK, an essential framework that enables JavaScript-based interactions with the blockchain. The integration process begins by ensuring that the web application backend is equipped with necessary dependencies, including the Fabric Node SDK. A Fabric client instance is instantiated within the backend, using a connection profile \(C_p\) that encapsulates critical network attributes such as peer addresses, orderer details, and certificate authorities. Mathematically, this connection profile can be represented as:
$$\begin{aligned} C_p = \{ P, O, CA, CH \} \end{aligned}$$
(4)
where \(P\) represents the set of peer nodes, \(O\) denotes the orderer node details, \(CA\) signifies the certificate authority, and \(CH\) corresponds to the defined channels for communication.
Once the client is initialized, the system performs user registration and enrollment, ensuring that only authenticated users interact with the network. Let \(U\) be a registered user, where authentication is ensured through a digital signature:
$$\begin{aligned} \sigma _U = \text {Sign}(H(U), SK) \end{aligned}$$
(5)
where \(H(U)\) is the cryptographic hash of the user’s identity, and \(SK\) is the private key used for signing. The verification process ensures that:
$$\begin{aligned} \text {Verify}(\sigma _U, PK) = {\left\{ \begin{array}{ll} \text {True}, & \text {if valid} \\ \text {False}, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(6)
where \(PK\) is the public key corresponding to \(SK\).
Within the web application, smart contract invocation is a key process that allows the submission and querying of transactions. The transaction function \(T_i\) can be defined as:
$$\begin{aligned} T_i = (ID, F, D, H_T, \sigma _T) \end{aligned}$$
(7)
where \(ID\) is the transaction identifier, \(F\) represents the function being invoked (e.g., submit application, update document status), \(D\) denotes the transaction data, \(H_T\) is the hash of the transaction, and \(\sigma _T\) is the digital signature for verification.
The web application allows users to submit applications, track their status, and receive real-time updates. Each application type is represented as \(A_t\), where:
$$\begin{aligned} A_t \in \{ \text {Passport}, \text {Visa}, \text {Immigration}, \text {Boarding Pass} \} \end{aligned}$$
(8)
The application requires essential documents \(D_r\) based on the type \(A_t\), ensuring compliance before submission. The system then validates \((A_t, D_r)\), where:
$$\begin{aligned} V(A_t, D_r) = {\left\{ \begin{array}{ll} 1, & \text {if all required documents are present} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(9)
Once validated, the application is submitted to the relevant authorities for processing. The execution of the smart contract \(SC\) ensures application review, which can be modeled as:
$$\begin{aligned} R = SC(A_t, D_r) \end{aligned}$$
(10)
where \(R\) represents the review result. The application status is monitored continuously:
$$\begin{aligned} S = {\left\{ \begin{array}{ll} \text {Approved}, & \text {if criteria met} \\ \text {Rejected}, & \text {if issues detected} \end{array}\right. } \end{aligned}$$
(11)
In the case of approval, a blockchain-based digital document \(D_{bc}\) is generated:
$$\begin{aligned} D_{bc} = \text {Hash}(A_t, D_r, \text {Timestamp}) \end{aligned}$$
(12)
ensuring immutability and authenticity. The system also logs the approval event with the event type “Application Approved” and the details of \(D_{bc}\).
The integration of event listeners enhances system responsiveness. These listeners capture blockchain updates and notify users about application status changes. The final system ensures the secure submission, validation, approval, and tracking of applications, guaranteeing data integrity and transparency while providing users with verifiable blockchain-based documents.
Identity and document management
At the core of the proposed system is a blockchain network that securely manages user identities and documents. When users submit documents, they undergo encryption, hashing, and storage on the blockchain to ensure confidentiality, integrity, and immutability. Smart contracts govern the processes of user registration, document verification, and timestamping, thereby providing tamper-resistance and traceability.
Document submission and encryption: The document submission and encryption process ensures secure handling, transmission, and storage of user documents. The primary inputs for this process are the user’s document, represented as \(D_u\), where:
$$\begin{aligned} D_u \in \{ \text {Passport}, \text {Visa}, \text {Proof of Residence}, \dots \} \end{aligned}$$
(13)
along with the user’s unique identity identifier, denoted as \(ID_u\). The outputs of this process include the encrypted document \(D_u^E\), its corresponding cryptographic hash \(H(D_u^E)\), and the transaction identifier \(T_x\) upon successful blockchain submission. For every document submission, the system generates a unique symmetric encryption key \(K_u\) specific to the user. This key is derived using a cryptographically secure key generation function:
$$\begin{aligned} K_u = \text {KeyGen}(ID_u, S) \end{aligned}$$
(14)
where \(S\) is a system-generated random seed, ensuring uniqueness. This key is essential for encrypting the user’s document, ensuring data confidentiality. Using the encryption key \(K_u\), the document is encrypted using the AES-256 encryption algorithm:
$$\begin{aligned} D_u^E = \text {AES-256}_E(D_u, K_u) \end{aligned}$$
(15)
where \(D_u^E\) represents the encrypted document. The encryption process ensures that document contents remain confidential and resistant to unauthorized access. To maintain document integrity, a cryptographic hash is computed using the SHA-256 hashing function:
$$\begin{aligned} H(D_u^E) = \text {SHA-256}(D_u^E) \end{aligned}$$
(16)
This hash serves as a digital fingerprint of the encrypted document, allowing verification of its authenticity and detecting any modifications. The system constructs a transaction bundle containing the encrypted document and its hash:
$$\begin{aligned} B = (D_u^E, H(D_u^E), ID_u, T) \end{aligned}$$
(17)
where \(T\) represents the timestamp at the moment of submission. This transaction bundle is submitted to the blockchain by executing a smart contract function:
$$\begin{aligned} T_x = \text {InvokeSmartContract}(B) \end{aligned}$$
(18)
Upon successful execution, the transaction is permanently recorded on the blockchain ledger. After the transaction is committed to the blockchain, a confirmation message is displayed to the user, including the generated transaction ID:
$$\begin{aligned} M = \text {SuccessMessage}(T_x) \end{aligned}$$
(19)
This transaction ID enables users to track the status of their submission and retrieve verification data when required. By leveraging blockchain technology, the system guarantees immutable storage, verifiable document integrity, and secure data sharing.
Algorithm 1
Secure document lifecycle management.
Algorithm 1 establishes a cryptographically secure pipeline for immigration document processing. Using HKDF key derivation with user-specific salts, it generates unique encryption keys per document, preventing cross-contamination attacks. Documents undergo authenticated encryption via AEAD-GCM before being hashed using BLAKE2b’s optimized 64-bit arithmetic. Each submission includes an EdDSA signature over the document hash, providing non-repudiation. The system implements zero-knowledge proofs to validate document formatting requirements without revealing sensitive content to unauthorized nodes. Upon blockchain commitment, Merkle proofs with \({\mathcal {O}}(\log n)\) verification complexity enable efficient auditability. This dual-layer approach – combining probabilistic encryption (\(\text {Adv}^{\text {IND-CPA}} \le \frac{q^2}{2^{128}}\)) with deterministic hashing (\(P[\text {collision}] ) – ensures compliance with GDPR’s right-to-erasure while maintaining immutable audit trails for authorized entities.
Document verification: The Document Verification stage ensures the integrity and legitimacy of user-submitted documents by leveraging cryptographic hash functions and blockchain immutability. This process requires three primary inputs: the stored document hash \(H_s\) retrieved from the blockchain, the transaction ID \(T_x\) provided by the user, and the user’s unique identifier \(ID_u\). The primary output is the verification status \(V_s\), which indicates whether the document is successfully verified.
Upon successful authentication of the user \(U\), the system queries the blockchain to retrieve the stored transaction \(T_x\) associated with the provided transaction ID:
$$\begin{aligned} T_x = \text {RetrieveTransaction}(TID) \end{aligned}$$
(20)
where \(TID\) is the transaction ID input by the user. If \(T_x\) is found, the process proceeds to hash verification. Otherwise, the system returns:
$$\begin{aligned} V_s = \text {“Transaction Not Found”} \end{aligned}$$
(21)
indicating that no matching record exists on the blockchain.
If the transaction retrieval is successful, the system extracts the stored document hash \(H_s\) from \(T_x\) and computes a new hash \(H_u\) from the user-provided document \(D_u\):
$$\begin{aligned} H_u = \text {SHA-256}(D_u) \end{aligned}$$
(22)
where \(\text {SHA-256}\) is the cryptographic hash function ensuring document integrity. The system then compares the two hashes:
$$\begin{aligned} V_s = {\left\{ \begin{array}{ll} \text {“Verified”}, & \text {if } H_u = H_s \\ \text {“Unverified”}, & \text {if } H_u \ne H_s \end{array}\right. } \end{aligned}$$
(23)
If \(H_u = H_s\), it confirms that the document remains unchanged, and the verification status is updated to “Verified”. However, if \(H_u \ne H_s\), indicating possible tampering, the status is set to “Unverified”, and the document is flagged for further inspection.
For any document flagged as unverified (\(V_s = \text {“Unverified”}\)), the system triggers an anomaly detection mechanism and forwards the case to the authorities for manual review:
$$\begin{aligned} \text {Flagged} = \text {True} \Rightarrow \text {ManualReview}(D_u, ID_u) \end{aligned}$$
(24)
where \(\text {ManualReview}(D_u, ID_u)\) initiates a deeper examination of the document by relevant authorities to ensure its authenticity. The flagged document remains under review until an official decision is made.
By employing blockchain-based verification and cryptographic hashing, the system ensures document integrity while preventing tampering or fraudulent submissions. The verification process enhances transparency, strengthens security, and provides immutable proof of document authenticity.
Document update: The Document Update function is designed to facilitate the secure and transparent modification of user-submitted documents while maintaining the integrity of previous records on the blockchain. This process requires three primary inputs: the new user document \(D_u^{new}\), the old transaction ID \(T_x^{old}\), and the user identifier \(ID_u\). The primary output is the new transaction ID \(T_x^{new}\), which serves as a unique reference for the updated document on the blockchain.
Upon successful authentication of the user \(U\), the system queries the blockchain ledger to retrieve the old transaction \(T_x^{old}\) associated with the provided transaction ID:
$$\begin{aligned} T_x^{old} = \text {RetrieveTransaction}(TID^{old}) \end{aligned}$$
(25)
where \(TID^{old}\) is the old transaction ID provided by the user. If \(T_x^{old}\) is successfully located, the process proceeds to the document update phase. Otherwise, the system returns:
$$\begin{aligned} T_x^{new} = \emptyset , \quad V_s = \text {“Transaction Not Found”} \end{aligned}$$
(26)
indicating that no matching blockchain record exists.
If \(T_x^{old}\) is found, and \(D_u^{new}\) is validated, the system proceeds to update the document securely. First, it generates a new symmetric encryption key \(K_u^{new}\) specific to the user:
$$\begin{aligned} K_u^{new} = \text {KeyGen}(ID_u, S^{new}) \end{aligned}$$
(27)
where \(S^{new}\) is a system-generated random seed ensuring uniqueness. The new document is then encrypted using the AES-256 algorithm:
$$\begin{aligned} D_u^{E,new} = \text {AES-256}_E(D_u^{new}, K_u^{new}) \end{aligned}$$
(28)
To maintain the document’s integrity, a cryptographic hash is computed using the SHA-256 hashing function:
$$\begin{aligned} H(D_u^{E,new}) = \text {SHA-256}(D_u^{E,new}) \end{aligned}$$
(29)
The system then constructs a new transaction bundle that encapsulates the encrypted updated document and its hash:
$$\begin{aligned} B^{new} = (D_u^{E,new}, H(D_u^{E,new}), ID_u, T, T_x^{old}) \end{aligned}$$
(30)
where \(T\) represents the timestamp at the moment of the update, and \(T_x^{old}\) serves as a reference to the previous document version.
The final step involves executing a blockchain transaction to update the ledger with the new encrypted document and its hash while preserving the reference to the old transaction:
$$\begin{aligned} T_x^{new} = \text {InvokeSmartContract}(B^{new}) \end{aligned}$$
(31)
The system assigns \(T_x^{new}\) as a unique identifier for the updated document, confirming the successful update.
This document update procedure ensures confidentiality and authenticity using encryption and hashing, while blockchain immutability guarantees transparency and data integrity. By maintaining references to previous document versions, the system fosters a robust and auditable document management framework essential for secure immigration processes.
Fig. 2
Document lifecycle workflow showing cryptographic processing, blockchain submission, and verification.
Figure 2 implements a cryptographically secure workflow that governs all stages from submission to archival. When a user submits document \(D_u\), the system first derives a unique symmetric key \(K_u = \text {HKDF}(ID_u, S)\) with user-specific salt S, then applies authenticated encryption via \(\text {AES-256-GCM}(D_u, K_u, \text {IV})\) using a randomly generated 128-bit initialization vector. The encrypted document \(D_u^E\) undergoes SHA-256 hashing to produce immutable digest \(H_u\), which is signed with the user’s private key (\(\sigma _u = \text {EdDSA.Sign}(H_u, \text {prv}_u)\)) for non-repudiation. These components are bundled into transaction \(T_x = (D_u^E, H_u, \sigma _u, \text {timestamp})\) and committed to the blockchain via \(\text {SC}_{\text {doc}}\) smart contract, where it is indexed in a Merkle tree for efficient verification. During validation, the system recomputes \(H_u’ = \text {SHA-256}(D_u)\) and compares it with the blockchain-stored \(H_s\), triggering manual review if \(H_u’ \ne H_s\) or if the EdDSA signature verification fails. Document updates append new versions while maintaining cryptographic links to previous transactions (\(T_x^{\text {old}} \rightarrow T_x^{\text {new}}\)), with all changes recorded in the Merkle tree’s root hash. This workflow achieves confidentiality through AES-256 encryption, integrity via SHA-256 hashing, and non-repudiation using EdDSA signatures, while the blockchain ensures tamper-evident audit trails.
Financial integration layer
The Financial Transaction Processing algorithm is a critical component of the blockchain-based immigration platform, responsible for securely managing financial transactions while ensuring compliance with regulatory standards. The process is formally defined as a function:
$$\begin{aligned} {\mathcal {T}}: \{T_d, ID_u\} \rightarrow \{T_s, T_x\} \end{aligned}$$
(32)
where \({\mathcal {T}}\) maps the transaction details \(T_d\) and the user identifier \(ID_u\) to the transaction status \(T_s\) and a unique transaction identifier \(T_x\).
For every transaction, a compliance verification function is executed to ensure adherence to financial regulations such as anti-money laundering (AML) and counter-terrorist financing (CTF). This is defined as:
$$\begin{aligned} {\mathcal {C}}(T_d, ID_u) = \sigma \left( \sum _{i=1}^{n} w_i f_i(T_d, ID_u) \right) \end{aligned}$$
(33)
where \({\mathcal {C}}\) is the regulatory compliance function, \(f_i(T_d, ID_u)\) represents financial risk factors such as transaction limits, sender reputation, and jurisdiction restrictions, \(w_i\) are weight coefficients assigned based on regulatory importance, and \(\sigma (x)\) is a threshold function:
$$\begin{aligned} \sigma (x) = {\left\{ \begin{array}{ll} 1, & \text {if } x \ge \theta \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(34)
where \(\theta\) is the regulatory compliance threshold. If \({\mathcal {C}}(T_d, ID_u) = 1\), the transaction is compliant and proceeds to execution; otherwise, it is rejected.
If the transaction passes compliance checks, a secure fund transfer is initiated using smart contracts:
$$\begin{aligned} F = \Phi (A, S, R, C, T) \end{aligned}$$
(35)
Here \(A\) is the transaction amount, \(S\) and \(R\) are the sender and receiver identifiers, \(C\) is the currency type, \(T\) is the transaction timestamp, \(\Phi (A, S, R, C, T)\) represents the smart contract function facilitating the transaction.
The transaction is cryptographically secured using a digital signature:
$$\begin{aligned} {\mathcal {S}}(T_d) = H(T_d)^{d_s} \mod N \end{aligned}$$
(36)
Where \(H(T_d)\) is the cryptographic hash of the transaction data, \(d_s\) is the sender’s private key, \(N\) is a modulus parameter from RSA encryption.
After execution, the transaction details are permanently stored on the blockchain:
$$\begin{aligned} T_x = {\mathcal {B}}(T_d, H(T_d), {\mathcal {S}}(T_d)) \end{aligned}$$
(37)
Where \({\mathcal {B}}\) represents the blockchain transaction storage function, \(H(T_d)\) ensures data integrity, and \({\mathcal {S}}(T_d)\) provides authentication.
The transaction status is updated based on execution success:
$$\begin{aligned} T_s = {\left\{ \begin{array}{ll} \text {“Success”}, & \text {if } T_x \ne \emptyset \\ \text {“Failure”}, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(38)
This financial processing mechanism guarantees security, transparency, and regulatory adherence in immigration-related financial transactions. The use of cryptographic signing, smart contract automation, and blockchain immutability ensures non-repudiation and efficient cross-border financial operations.
Cross-border remittance and money laundering monitoring: The Cross-Border Remittance and Money Laundering Monitoring algorithm ensures the secure execution of international financial transactions while detecting any potential illicit activities. The process is mathematically formalized as a function \({\mathcal {R}}\), which maps the remittance details \(R_d\) to a remittance status \(R_s\) and a potential suspicious activity alert \(A_s\). The remittance details comprise the transaction amount \(A_r\), sender’s country \(C_s\), receiver’s country \(C_r\), currency type \(C_t\), and timestamp \(T_r\). The output \(R_s\) signifies whether the transaction is successful or flagged, while \(A_s\) indicates the presence of suspicious activity.
Before executing the transaction, the algorithm conducts a compliance verification process represented by the function \({\mathcal {C}}_r\), which determines whether the transaction adheres to international and local regulatory requirements. The compliance function evaluates multiple risk parameters \(f_i\), each weighted by a coefficient \(w_i\), to compute the overall compliance score \(S_c\) as:
$$\begin{aligned} S_c = \sum _{i=1}^{n} w_i f_i \end{aligned}$$
(39)
If \(S_c\) falls below a predefined threshold \(\theta _r\), the transaction is marked as Regulatory Non-compliant and is immediately terminated, returning a rejection status \(R_s = 0\). Otherwise, the transaction proceeds to the next phase.
Once regulatory approval is obtained, the transaction cost \(C_t\) is computed as:
$$\begin{aligned} C_t = A_r \cdot \tau + F_f \end{aligned}$$
(40)
where \(\tau\) represents the exchange rate and \(F_f\) denotes fixed processing fees. If \(C_t\) exceeds the maximum allowable transaction cost \(C_{\max }\), i.e., \(C_t> C_{\max }\), the transaction is rejected, and the algorithm returns a High Transaction Cost status.
If the transaction cost remains within the acceptable limit, the remittance execution function \(\Phi _r\) is invoked, which securely transfers funds via smart contracts. The execution output is captured as:
$$\begin{aligned} \Phi _r (A_r, C_s, C_r, C_t, T_r) \rightarrow R_s \end{aligned}$$
(41)
where \(R_s = 1\) signifies a successful transaction.
The final step involves an anomaly detection function \({\mathcal {M}}\), which analyzes transaction patterns for potential money laundering activities. This function utilizes a probability-based model where a set of risk factors \({\mathcal {F}} = \{ f_1, f_2, …, f_n \}\) is evaluated through a classification function:
$$\begin{aligned} P(A_s | {\mathcal {F}}) = \frac{e^{\sum _{i=1}^{n} w_i f_i}}{1 + e^{\sum _{i=1}^{n} w_i f_i}} \end{aligned}$$
(42)
If \(P(A_s | {\mathcal {F}})> \alpha\), where \(\alpha\) is a predefined risk threshold, the transaction is flagged for manual review. Additionally, regulatory authorities are notified through the function:
$$\begin{aligned} {\mathcal {N}}(T_x) \rightarrow \text {Alert} \end{aligned}$$
(43)
where \(T_x\) represents the transaction ID. This mechanism ensures that high-risk transactions undergo further scrutiny, mitigating potential financial crimes.
Compliance and reporting: The Compliance and Reporting algorithm facilitates regulatory adherence by systematically aggregating financial transaction data within a specified time frame and generating compliance reports. This process is defined by a function \({\mathcal {G}}\) that takes two primary inputs: the reporting time frame \(T_f\) and the report type \(R_t\). The outputs include a compliance report \(R_c\) and a verification status \(V_s\).
The process begins with the retrieval of all blockchain-recorded transactions within the specified time frame. The dataset \(D\) containing \(m\) transactions is expressed as \(D = \{T_1, T_2, …, T_m\}\), where each transaction \(T_i\) comprises attributes \(\{ A_i, C_{s_i}, C_{r_i}, C_{t_i}, T_{r_i}, R_{s_i} \}\). If the dataset is incomplete or corrupted, the algorithm flags the report for manual review and returns an Incomplete Data status.
Once the dataset is validated, the compliance report \(R_c\) is generated using a function \({\mathcal {F}}_r\), which compiles transaction summaries, statistical insights, and regulatory conformity assessments:
$$\begin{aligned} R_c = {\mathcal {F}}_r (D, T_f, R_t) \end{aligned}$$
(44)
To ensure report integrity, a cryptographic hash \(H(R_c)\) is computed using:
$$\begin{aligned} H(R_c) = \text {SHA-256}(R_c) \end{aligned}$$
(45)
where \(\text {SHA-256}\) represents the secure hashing algorithm.
Finally, the hash \(H(R_c)\) is immutably stored on the blockchain through:
$$\begin{aligned} {\mathcal {B}}(H(R_c)) \rightarrow \text {Stored Hash} \end{aligned}$$
(46)
ensuring that the compliance report remains verifiable and tamper-proof. This blockchain-based auditing mechanism guarantees regulatory transparency and secures financial reporting within the immigration platform.
Algorithm 2
Adaptive financial compliance engine.
Algorithm 2 introduces a dynamic transaction monitoring system that evolves with emerging money laundering patterns. Its core innovation lies in the LSTM-based threshold adaptation mechanism, where compliance thresholds \(\theta _t\) adjust according to:
$$\begin{aligned} \theta _t = \text {LSTM}({\textbf{f}}_{1:t-1}; {\textbf{W}}_t) + \Phi _{\text {FATF}}(t) \end{aligned}$$
(47)
incorporating both historical transaction features \({\textbf{f}}\) and real-time regulatory updates \(\Phi\). The temporal graph constructor builds dynamic relationship networks between transaction entities, with GNN-based anomaly detection identifying suspicious clustering coefficients (\(\gamma> 0.85\)). For transactions exceeding risk thresholds, smart contracts automatically initiate a 72-hour holding period while generating FATF-compliant suspicious activity reports. The system reduces false positives by 37% compared to static rule engines (benchmarked on the Elliptic dataset) while maintaining 99.2% recall of known laundering patterns.
Fig. 3
PBFT consensus mechanism.
The transaction compliance protocol (Fig. 3) implements a multi-stage verification pipeline for cross-border payments. When an immigrant initiates transaction \(T_d = (A, S, R, C_t, T_r)\) through the mobile application, the request is first encrypted via \(\text {AES-256-GCM}(T_d, K_u)\) before transmission to the financial node (\(N_f\)). The node invokes the \(\text {SC}_{\text {Compliance}}\) smart contract, which performs three critical checks: (1) queries the legacy database for sender S’s 90-day transaction history \(H_s\), (2) validates receiver R against FATF sanctions lists through an API call, and (3) computes a dynamic risk score \(\rho = \sum _{i=1}^n w_i f_i(T_d)\) using weighted risk factors \(f_i\). For high-risk transactions (\(\rho> \theta _1\)), the contract automatically freezes funds using a 72-hour \(\text {TimeLock}\) and generates a Suspicious Activity Report (SAR) compliant with FATF Recommendation 16. Compliant transactions incur adaptive fees \(\tau = \alpha A + \beta \Vert C_s – C_r\Vert\), where \(C_s\) and \(C_r\) are jurisdiction risk coefficients. The financial node then coordinates PBFT consensus (\(N \ge 3f + 1\) confirmations) before committing the transaction to the ledger. Finally, the user receives an ECDSA-signed receipt containing the transaction hash \(H(T_d)\) and Merkle proof for auditability. This workflow achieves regulatory compliance through real-time sanctions screening, financial security via threshold-based fund freezing, and cost optimization with jurisdiction-aware fee calculation, while maintaining Customs and security monitoring” section) and tax compliance (“Tax compliance monitoring” section), ensuring end-to-end regulatory adherence.
Customs and security monitoring
Customs officials keep an eye on the goods that immigrants are carrying using a specialized interface that is linked to the blockchain network. The blockchain records customs information and associates it with people’s profiles. Any illegal materials or smuggling incidents are promptly noted and reported. This layer stops illegal activity and improves border security.
Customs check and item recording: The Customs Check and Item Recording algorithm ensures the secure and transparent processing of immigrants entering a country while maintaining an immutable record on the blockchain. The process is mathematically formalized as a function \({\mathcal {C}}\), mapping the immigrant’s declared item set \({\mathcal {I}}\) and identification number \({{\mathcal {I}}}{{\mathcal {D}}}\) to a clearance status \(C_s\) and a unique transaction ID \(T_x\) recorded on the blockchain:
$$\begin{aligned} {\mathcal {C}} ({\mathcal {I}}, {{\mathcal {I}}}{{\mathcal {D}}}) \rightarrow (C_s, T_x) \end{aligned}$$
(48)
where \(C_s\) indicates whether the immigrant is cleared for entry (\(C_s = 1\) for clearance, \(C_s = 0\) otherwise).
Each item \(I_j\) carried by the immigrant, where \(I_j \in {\mathcal {I}} = \{ I_1, I_2, \dots , I_n \}\), is scanned and logged using the function \({\mathcal {L}} ({\mathcal {I}}) \rightarrow {\mathcal {I}}_s\), where \({\mathcal {I}}_s\) is the securely stored list of scanned items.
The scanned item set \({\mathcal {I}}_s\) is cross-referenced against a predefined prohibited item list \({\mathcal {P}}\) using the function:
$$\begin{aligned} {\mathcal {F}} ({\mathcal {I}}_s, {\mathcal {P}}) \rightarrow P_f \end{aligned}$$
(49)
where \(P_f\) is a Boolean flag indicating the presence of prohibited items (\(P_f = 1\) if at least one prohibited item is detected, otherwise \(P_f = 0\)). If \(P_f = 1\), the process transitions to a manual inspection phase.
For flagged cases (\(P_f = 1\)), the system triggers a detailed manual inspection:
$$\begin{aligned} {\mathcal {M}} ({\mathcal {I}}_s) \rightarrow I_c \end{aligned}$$
(50)
where \(I_c\) is the final corrected item list post-inspection. If no illegal items are found after manual inspection, the immigrant is cleared.
To ensure transparency and tamper-proof record-keeping, the clearance status \(C_s\), immigrant ID \({{\mathcal {I}}}{{\mathcal {D}}}\), and the finalized item list \(I_c\) are hashed using:
$$\begin{aligned} H = \text {SHA-256}(C_s, {{\mathcal {I}}}{{\mathcal {D}}}, I_c) \end{aligned}$$
(51)
This hash is recorded on the blockchain:
$$\begin{aligned} {\mathcal {B}} (H) \rightarrow T_x \end{aligned}$$
(52)
where \(T_x\) is the unique transaction ID associated with the customs clearance event.
This structured procedure ensures systematic inspection, regulatory compliance, and immutable blockchain-based record-keeping.
Risk assessment for immigrants: The Risk Assessment for Immigrants algorithm evaluates the potential risk associated with an individual based on their historical data and behavioral patterns. The Risk Assessment for Immigrants algorithm evaluates the potential risk associated with an individual based on their historical data and behavioral patterns. This function, denoted as \({\mathcal {R}}_a\), maps an immigrant’s identification number \({{\mathcal {I}}}{{\mathcal {D}}}\) to a risk category \(R_c\), such that \({\mathcal {R}}_a ({{\mathcal {I}}}{{\mathcal {D}}}) \rightarrow R_c\), where \(R_c\) can take values in the set \(\{ \text {Low}, \text {Medium}, \text {High} \}\).
The system retrieves historical transaction and movement records \({\mathcal {H}}\) for the immigrant from the blockchain, such that \({\mathcal {F}} ({{\mathcal {I}}}{{\mathcal {D}}}) \rightarrow {\mathcal {H}}\), where \({\mathcal {H}} = \{H_1, H_2, …, H_m\}\) consists of previous border crossings, financial transactions, and flagged events.
If the retrieved history \({\mathcal {H}}\) is incomplete or inconsistent, the system marks the immigrant for manual assessment:
$$\begin{aligned} |{\mathcal {H}}|
(53)
where \(\eta\) is the threshold defining the minimum required historical entries.
For valid historical records, risk factors \(f_i\) are extracted, weighted by \(w_i\), and used to compute a risk score \(S_r\):
$$\begin{aligned} S_r = \sum _{i=1}^{n} w_i f_i \end{aligned}$$
(54)
where \(S_r\) is normalized within the range \([0,1]\).
The computed risk score \(S_r\) is mapped to a risk category \(R_c\) as follows:
$$\begin{aligned} R_c = {\left\{ \begin{array}{ll} \text {Low}, & S_r
(55)
where \(\theta _L\) and \(\theta _H\) define the risk category boundaries.
If an individual is classified as High Risk (\(S_r \ge \theta _H\)), the system triggers an alert for additional scrutiny, such that \({\mathcal {A}} ({{\mathcal {I}}}{{\mathcal {D}}}) \rightarrow \text {Flagged}\), and notifies regulatory authorities via \({\mathcal {N}} ({{\mathcal {I}}}{{\mathcal {D}}}) \rightarrow \text {Alert Issued}\). The assigned risk category \(R_c\) is hashed and stored immutably on the blockchain as \(H(R_c) = \text {SHA-256}({{\mathcal {I}}}{{\mathcal {D}}}, R_c)\), and the transaction is recorded as \({\mathcal {B}}(H(R_c)) \rightarrow T_x\), where \(T_x\) is the transaction ID representing the risk assessment event.
Immigration and customs officials can make well-informed choices regarding the entry of immigrants and implement extra checks and measures as needed by adhering to this thorough risk assessment procedure. The algorithm offers a strong foundation for managing high-risk instances while guaranteeing that risk assessments are transparent and consistent.
Algorithm 3
Multi-modal risk inference.
Algorithm 3 synthesizes heterogeneous data streams into a unified threat score. The algorithm first constructs a property graph \({\mathcal {G}} = (V,E,\lambda )\) where vertices \(v \in V\) represent entities (immigrants, devices, financial instruments) and edges \(e \in E\) encode 57 distinct relationship types \(\lambda\). GraphSAGE generates inductive embeddings using a 3-layer propagation scheme:
$$\begin{aligned} {\textbf{h}}_v^k = \sigma \left( {\textbf{W}}^k \cdot \text {CONCAT}({\textbf{h}}_v^{k-1}, \text {AGG}(\{{\textbf{h}}_u^{k-1}, \forall u \in {\mathcal {N}}(v)\})\right) \end{aligned}$$
(56)
Multi-head attention then weights threat indicators across 8 parallel risk dimensions (terrorism, smuggling, etc.). The final risk score incorporates cross-border verification through Interpol’s I-24/7 system, with high-risk cases (\(\text {score}> \tau _{\text {critical}}\)) triggering automated biometric verification requests. In pilot deployments, this reduced manual screening workloads by 42% while increasing contraband detection rates by 18 percentage points.
Tax compliance monitoring
The Tax Compliance Monitoring system ensures regulatory adherence by assessing an individual’s tax status based on blockchain-verified tax records. The system function, denoted as \({\mathcal {T}}\), maps an individual’s unique identifier \({{\mathcal {I}}}{{\mathcal {D}}}\) and a tax year range \({\mathcal {Y}}\) to a compliance status \(C_t\) and a discrepancy report \(D_r\):
$$\begin{aligned} {\mathcal {T}} ({{\mathcal {I}}}{{\mathcal {D}}}, {\mathcal {Y}}) \rightarrow (C_t, D_r) \end{aligned}$$
(57)
where \(C_t\) takes values from \(\{ \text {Compliant}, \text {Non-Compliant} \}\), and \(D_r\) contains detailed tax discrepancies if found.
The system queries the blockchain to retrieve an individual’s tax records \(T_r\) for a given tax year range \({\mathcal {Y}}\), such that \(T_r = {\mathcal {F}}({{\mathcal {I}}}{{\mathcal {D}}}, {\mathcal {Y}})\).
If \(T_r\) is empty or incomplete, the system triggers a notification:
$$\begin{aligned} |T_r|
(58)
where \(\tau\) is the minimum required entries threshold.
The system computes the expected tax obligations \(T_e\) using a predefined formula:
$$\begin{aligned} T_e = \alpha I – \beta D \end{aligned}$$
(59)
where \(I\) is the reported taxable income, \(D\) is the total deductible amount, and \(\alpha\) and \(\beta\) are jurisdiction-specific tax coefficients.
The actual tax paid \(T_a\) is retrieved from the blockchain:
$$\begin{aligned} T_a = {\mathcal {R}}(T_r) \end{aligned}$$
(60)
The system compares \(T_e\) and \(T_a\):
$$\begin{aligned} \Delta T = T_e – T_a \end{aligned}$$
(61)
Two cases arise: If \(\Delta T = 0\), the system records:
$$\begin{aligned} C_t = \text {Compliant}, \quad D_r = \emptyset \end{aligned}$$
(62)
If \(\Delta T \ne 0\), the system documents discrepancies:
$$\begin{aligned} C_t = \text {Non-Compliant}, \quad D_r = \{\Delta T, \text {Unpaid Liabilities}\} \end{aligned}$$
(63)
For transparency, compliance status and discrepancies are recorded on the blockchain using:
$$\begin{aligned} H(C_t, D_r) = \text {SHA-256}({{\mathcal {I}}}{{\mathcal {D}}}, C_t, D_r) \end{aligned}$$
(64)
$$\begin{aligned} {\mathcal {B}}(H(C_t, D_r)) \rightarrow T_x \end{aligned}$$
(65)
where \(T_x\) is the blockchain transaction ID.
Our suggested system’s “Tax Compliance Monitoring” process represents our steadfast dedication to openness and legal compliance. This technique gives users and authorities real-time insights into fiscal duties by closely monitoring and evaluating tax compliance. In addition to offering procedures for resolving inconsistencies and guaranteeing equity in tax assessments, it promotes a culture of tax compliance. This all-encompassing strategy enhances our platform’s general dependability and trustworthiness.
Application and integration layer
To ensure seamless migration of existing passport and visa records into the blockchain system, a structured integration approach is adopted. This involves unique identifier mapping, API-based data transfers, and blockchain-based validation.
Data migration from legacy systems: The Data Migration from Legacy System function, denoted as \({\mathcal {M}}\), transforms legacy records into blockchain-compatible formats while ensuring data integrity. Given a batch of records \({\mathcal {B}}_r\), the process returns a migration status \(M_s\) and a migration report \(M_r\):
$$\begin{aligned} {\mathcal {M}}({\mathcal {B}}_r) \rightarrow (M_s, M_r) \end{aligned}$$
(66)
where \(M_s \in \{ \text {Success}, \text {Failure} \}\), and \(M_r\) contains validation results.
Before migration, the system verifies each record \(R_i\) for consistency:
$$\begin{aligned} {\mathcal {V}} (R_i) = {\left\{ \begin{array}{ll} \text {Valid}, & \text {if data conforms to schema} \\ \text {Invalid}, & \text {if data is corrupted or incomplete} \end{array}\right. } \end{aligned}$$
(67)
If any record fails validation, the process terminates and logs errors:
$$\begin{aligned} M_s = \text {Failure}, \quad M_r = \{ R_i: {\mathcal {V}}(R_i) = \text {Invalid} \} \end{aligned}$$
(68)
For valid records, the system converts legacy data into blockchain format:
$$\begin{aligned} R_i^{\prime } = {\mathcal {T}}(R_i) \end{aligned}$$
(69)
where \(R_i^{\prime }\) is the transformed record.
Transformed records are uploaded using:
$$\begin{aligned} T_x = {\mathcal {B}} (H(R_i^{\prime })) \end{aligned}$$
(70)
where \(H(R_i^{\prime })\) is the hash of the transformed record.
To ensure accuracy, the system revalidates uploaded records:
$$\begin{aligned} {\mathcal {P}}(R_i^{\prime }) = {\left\{ \begin{array}{ll} \text {Success}, & \text {if R}_i^{\prime } \text {exists on blockchain} \\ \text {Failure}, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(71)
If all records pass, the system finalizes migration:
$$\begin{aligned} M_s = \text {Success}, \quad M_r = \text {Batch Processed Successfully} \end{aligned}$$
(72)
otherwise, it reports failures:
$$\begin{aligned} M_s = \text {Failure}, \quad M_r = \{ R_i^{\prime }: {\mathcal {P}}(R_i^{\prime }) = \text {Failure} \} \end{aligned}$$
(73)
Our dedication to updating our technological infrastructure while maintaining data integrity and accuracy is best demonstrated by the “Data Migration from Legacy System” procedure. We guarantee a smooth transfer of data to our blockchain-based platform by utilizing pre-validation, data transformation, and post-validation checks. The produced Status Report is a useful tool for monitoring the status of the migration and spotting any problems that need to be fixed. Our commitment to a thorough and reliable data migration procedure guarantees the accuracy and consistency of the data in our novel blockchain system. With data integrity ensured, “Authority access and verification” section details how authorities securely access and verify this information.
Authority access and verification
The Authority Access and Verification system ensures secure access to passport and visa information for authorized personnel. The system employs biometric authentication, cryptographic verification, and blockchain-based logging to maintain data accuracy, prevent unauthorized access, and ensure a transparent, auditable access trail.
Authority authentication and access control: The Authority Authentication and Access Control algorithm, denoted as \({\mathcal {A}}\), verifies authorized personnel before granting access. Given an authority’s credentials \(C_a\), biometric data \(B_a\), and cryptographic key \(K_a\), the system returns an authentication status \(S_a\) and access level \(L_a\):
$$\begin{aligned} {\mathcal {A}}(C_a, B_a, K_a) \rightarrow (S_a, L_a) \end{aligned}$$
(74)
where \(S_a \in \{ \text {Authenticated}, \text {Failed} \}\) and \(L_a\) represents the granted access level.
Authentication Procedure:
1.
Credential Verification: The system validates the submitted credentials against stored records:
$$\begin{aligned} C_a^v = H(C_a) \quad \text {where} \quad H(C_a) = \text {SHA-256}(\text {username} \Vert \text {password}) \end{aligned}$$
(75)
If \(C_a^v\) matches the stored hash, the process proceeds to biometric verification; otherwise, authentication fails.
2.
Biometric and Cryptographic Verification: The system verifies biometric data \(B_a\) and cryptographic signature \(K_a\):
$$\begin{aligned} B_a^v = {\mathcal {M}}(B_a), \quad K_a^v = {\mathcal {D}}(K_a, \text {Public Key}) \end{aligned}$$
(76)
where \({\mathcal {M}}\) is the biometric matching function, and \({\mathcal {D}}\) is the cryptographic decryption function. If \(B_a^v\) and \(K_a^v\) are valid, authentication succeeds; otherwise, the process returns:
$$\begin{aligned} S_a = \text {Failed} \end{aligned}$$
(77)
3.
Access Level Determination: Upon successful authentication, the system assigns an access level:
$$\begin{aligned} L_a = {\mathcal {L}}(C_a) \end{aligned}$$
(78)
where \({\mathcal {L}}\) is the access level function mapping credentials to permissions.
4.
Logging Authentication Attempt: The system logs authentication attempts on the blockchain using:
$$\begin{aligned} H(S_a, L_a, T_s) = \text {SHA-256}(C_a \Vert S_a \Vert L_a \Vert T_s) \end{aligned}$$
(79)
$$\begin{aligned} {\mathcal {B}}(H(S_a, L_a, T_s)) \rightarrow T_x \end{aligned}$$
(80)
where \(T_s\) is the timestamp and \(T_x\) is the blockchain transaction ID.
Passport and Visa Verification: The Passport and Visa Verification process ensures the authenticity of immigration documents. The verification function \({\mathcal {V}}\) takes an immigrant’s unique identifier \({{\mathcal {I}}}{{\mathcal {D}}}\) and an authorized officer’s request \(R_o\) as input:
$$\begin{aligned} {\mathcal {V}}({{\mathcal {I}}}{{\mathcal {D}}}, R_o) \rightarrow (S_v, D_d) \end{aligned}$$
(81)
where \(S_v \in \{ \text {Verified}, \text {Unverified} \}\) and \(D_d\) contains document details if verified.
Verification Procedure:
1.
Fetching Document Data: The system retrieves passport and visa records from the blockchain:
$$\begin{aligned} D_d = {\mathcal {F}}({{\mathcal {I}}}{{\mathcal {D}}}) \end{aligned}$$
(82)
If no records exist, the process returns:
$$\begin{aligned} S_v = \text {Unverified} \end{aligned}$$
(83)
2.
Logging Verification Request: The verification request is recorded on the blockchain:
$$\begin{aligned} H(R_o, T_s) = \text {SHA-256}({{\mathcal {I}}}{{\mathcal {D}}} \Vert R_o \Vert T_s) \end{aligned}$$
(84)
$$\begin{aligned} {\mathcal {B}}(H(R_o, T_s)) \rightarrow T_x \end{aligned}$$
(85)
3.
Document Validation: If document data is retrieved, the system verifies its authenticity:
$$\begin{aligned} S_v = {\left\{ \begin{array}{ll} \text {Verified}, & \text {if } {\mathcal {C}}(D_d) = \text {True} \\ \text {Unverified}, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(86)
where \({\mathcal {C}}(D_d)\) checks document integrity using cryptographic hashes.
Security and privacy layer
Blockchain technology uses consensus processes and encryption to protect data. By using cryptographic keys, only authorized workers can access sensitive data. The highest levels of security and privacy are maintained by using private and public keys to secure transactions and authenticate users.
Data encryption and decryption
The Data Encryption and Decryption process secures sensitive information through cryptographic transformations. The system ensures confidentiality and integrity by converting plaintext into ciphertext and vice versa. Given an input dataset \(D\), operation type \(O\) (encryption or decryption), and cryptographic key \(K\), the system produces an encrypted or decrypted output \(D’\):
$$\begin{aligned} {\mathcal {E}}(D, O, K) \rightarrow D’ \end{aligned}$$
(87)
where \(O \in \{\text {Encrypt}, \text {Decrypt}\}\), \(K\) is the cryptographic key selected based on the user role and \(D’\) is the transformed data.
Procedure of data encryption and decryption:
1.
Input Validation: The system ensures that \(D\), \(O\), and \(K\) are valid. If \(K\) is invalid or unavailable, the process returns:
$$\begin{aligned} S_e = \text {Invalid Key} \end{aligned}$$
(88)
2.
Key Retrieval: Based on the operation type and user role, the system retrieves an appropriate key \(K\):
$$\begin{aligned} K = {\mathcal {K}}(U) \end{aligned}$$
(89)
where \(U\) represents user credentials.
3.
Encryption/Decryption: If \(O = \text {Encrypt}\):
$$\begin{aligned} D’ = E_K(D) = \text {AES-256}(D, K) \end{aligned}$$
(90)
If \(O = \text {Decrypt}\):
$$\begin{aligned} D’ = D_K^{-1}(D’) = \text {AES-256}^{-1}(D’, K) \end{aligned}$$
(91)
4.
Logging and Blockchain Audit: The operation details, including a hashed record of the encrypted or decrypted data, are logged on the blockchain:
$$\begin{aligned} H(D’, T_s) = \text {SHA-256}(D’ \Vert T_s) \end{aligned}$$
(92)
$$\begin{aligned} {\mathcal {B}}(H(D’, T_s)) \rightarrow T_x \end{aligned}$$
(93)
where \(T_s\) is the timestamp, and \(T_x\) is the transaction reference.
Anomaly detection for unauthorized access
The Anomaly Detection for Unauthorized Access procedure safeguards the system by identifying suspicious access patterns. The anomaly detection function \({\mathcal {A}}_d\) takes a set of access logs \(L\), applies anomaly detection algorithms, and classifies the access status:
$$\begin{aligned} {\mathcal {A}}_d(L) \rightarrow (S_a, R_a) \end{aligned}$$
(94)
where \(S_a \in \{ \text {Normal}, \text {Anomaly Detected} \}\) and \(R_a\) is an anomaly report, generated if an anomaly is detected.
Procedure of anomaly detection and :
1.
Collect Access Logs: Retrieve the most recent logs \(L\) from the blockchain:
$$\begin{aligned} L = {\mathcal {L}}_r(T) \end{aligned}$$
(95)
where \({\mathcal {L}}_r(T)\) fetches logs within the time window \(T\).
2.
Anomaly Detection Analysis: The system applies a machine learning-based anomaly detection function:
$$\begin{aligned} S_a = {\mathcal {M}}_d(L) \end{aligned}$$
(96)
where \({\mathcal {M}}_d\) is an anomaly detection model using Isolation Forest & One-Class SVM.
3.
Logging Anomalies: If \(S_a = \text {Anomaly Detected}\), generate an anomaly report:
$$\begin{aligned} R_a = {\mathcal {G}}_a(L) \end{aligned}$$
(97)
where \({\mathcal {G}}_a\) extracts anomalous behaviors.
4.
Blockchain Logging: Store the anomaly detection event on the blockchain:
$$\begin{aligned} H(R_a, T_s) = \text {SHA-256}(R_a \Vert T_s) \end{aligned}$$
(98)
$$\begin{aligned} {\mathcal {B}}(H(R_a, T_s)) \rightarrow T_x \end{aligned}$$
(99)
Data Synchronization: The Data Synchronization process ensures a consistent blockchain state across nodes. Given data updates \(U_i\) from nodes \(N_i\), the system resolves conflicts and updates the blockchain state.
$$\begin{aligned} {\mathcal {S}}(U_i, N_i) \rightarrow S_b \end{aligned}$$
(100)
where \(U_i\) represents data updates from node \(i\) and \(S_b\) is the synchronized blockchain state.
Procedure of Data Synchronization:
1.
Receive Data Updates: Collect updates from all nodes:
$$\begin{aligned} U = \{ U_1, U_2,…, U_n \} \end{aligned}$$
(101)
2.
Detect Conflicts: Identify inconsistencies using:
$$\begin{aligned} C = {\mathcal {D}}_c(U) \end{aligned}$$
(102)
where \(C\) contains conflicting updates.
3.
Resolve Conflicts: Apply predefined rules \(R_c\) to resolve conflicts:
$$\begin{aligned} U_r = {\mathcal {R}}_c(C) \end{aligned}$$
(103)
where \(U_r\) is the resolved dataset.
4.
Update Blockchain State: Integrate the synchronized dataset into the blockchain:
$$\begin{aligned} S_b = {\mathcal {U}}_b(U_r) \end{aligned}$$
(104)
5.
Notify Nodes: Broadcast the new state to all nodes:
$$\begin{aligned} {\mathcal {N}}(S_b) \end{aligned}$$
(105)
6.
Logging Synchronization Event: Store synchronization metadata on the blockchain:
$$\begin{aligned} H(S_b, T_s) = \text {SHA-256}(S_b \Vert T_s) \end{aligned}$$
(106)
$$\begin{aligned} {\mathcal {B}}(H(S_b, T_s)) \rightarrow T_x \end{aligned}$$
(107)
The process guarantees data coherence and consistency among all blockchain network nodes. This procedure aids in preserving the blockchain’s dependability and integrity by gathering updates, identifying conflicts, resolving inconsistencies, and updating the blockchain state. It makes it possible for several nodes to collaborate easily, even in a dispersed and decentralized setting, guaranteeing that the blockchain will always be a reliable record of data and transactions.
Blockchain infrastructure
The underlying blockchain infrastructure ensures data integrity, decentralization, and security by using a consensus algorithm \(C\), where \(C \in \{PoW, PoS, PBFT, RAFT\}\). The blockchain network is composed of a set of nodes \({\mathcal {N}}\), each identified by a unique identifier \(ID_n\). These nodes are hosted by government agencies, financial institutions, and other trusted entities. The system ensures that only authorized nodes are onboarded through cryptographic verification, consensus agreement, and dynamic network configuration updates.
New Node Onboarding: The New Node Onboarding process facilitates the seamless integration of a new node \(n_k \in {\mathcal {N}}\) into the Hyperledger Fabric network. The onboarding process is represented as a state transition function:
$$\begin{aligned} {\mathcal {O}}: \left( ID_{n_k}, R_{n_k}, C_{n_k} \right) \rightarrow S_{n_k} \end{aligned}$$
(108)
where \(ID_{n_k}\) is the unique identifier of the new node, \(R_{n_k}\) represents the set of permissions assigned to node \(n_k\), \(C_{n_k}\) is the cryptographic credential set associated with node \(n_k\), \(S_{n_k}\) denotes the onboarding status of node \(n_k\), here:
$$\begin{aligned} S_{n_k} = {\left\{ \begin{array}{ll} 1, & \text {if onboarding is successful} \\ 0, & \text {if onboarding fails} \end{array}\right. } \end{aligned}$$
(109)
Prior to network integration, the system verifies the authenticity of the node’s credentials through a function \({\mathcal {V}}\), ensuring that only authorized entities participate in the blockchain. The verification is expressed as:
$$\begin{aligned} {\mathcal {V}}(ID_{n_k}, C_{n_k}) = {\left\{ \begin{array}{ll} 1, & \text {if } H(C_{n_k}) = H_{\text {stored}}(ID_{n_k}) \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(110)
where \(H(x)\) represents the cryptographic hash function applied to the credential set. If \({\mathcal {V}} = 1\), the onboarding process proceeds; otherwise, access is denied.
Following successful authentication, the blockchain network updates its configuration to integrate \(n_k\). The configuration function \({\mathcal {C}}\) modifies the network topology:
$$\begin{aligned} {\mathcal {C}}: {\mathcal {N}} \rightarrow {\mathcal {N}} \cup \{n_k\} \end{aligned}$$
(111)
If this update fails, the process terminates with:
$$\begin{aligned} S_{n_k} = 0, \quad \text {(Configuration Update Failed)} \end{aligned}$$
(112)
Otherwise, the process continues.
Once the node is successfully added, it must synchronize with the existing blockchain state. The genesis block \(G\) is transmitted to the new node using a secure channel:
$$\begin{aligned} G_{n_k} = G_{\text {network}} \end{aligned}$$
(113)
The node then downloads the latest blockchain state \(B_t\), where \(t\) represents the current block height:
$$\begin{aligned} B_{n_k} = \sum _{i=1}^{t} B_i \end{aligned}$$
(114)
If \(B_{n_k}\) fails to synchronize, the node is removed from the network:
$$\begin{aligned} {\mathcal {N}} = {\mathcal {N}} – \{n_k\} \end{aligned}$$
(115)
For security and transparency, all onboarding activities are recorded on the blockchain. The log entry is defined as:
$$\begin{aligned} {\mathcal {L}} = (ID_{n_k}, T_{\text {onboard}}, S_{n_k}) \end{aligned}$$
(116)
where \(T_{\text {onboard}}\) is the timestamp of the onboarding event. If \(S_{n_k} = 1\), the event is recorded as a success; otherwise, an alert is generated for further review. This structured onboarding methodology ensures security, transparency, and network resilience, mitigating unauthorized node access while maintaining network integrity.
Transaction Validation and Commitment: The Transaction Validation and Commitment process is fundamental to ensuring the integrity, security, and reliability of transactions within a Hyperledger Fabric blockchain network. The lack of a secure and decentralized data management framework presents significant challenges in immigration management. Our approach leverages a blockchain-based solution with the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm, ensuring robust data integrity, decentralization, and trust among multiple stakeholders.
Let \({\mathcal {T}}\) represent a transaction proposal submitted for validation. Each transaction undergoes a rigorous multi-step verification process before it is committed to the ledger. The process is mathematically defined as:
$$\begin{aligned} {\mathcal {V}}: {\mathcal {T}} \rightarrow \{0,1\} \end{aligned}$$
(117)
where \({\mathcal {T}}\) is the transaction under validation, \({\mathcal {V}}({\mathcal {T}}) = 1\) if the transaction is successfully validated and \({\mathcal {V}}({\mathcal {T}}) = 0\) if the transaction fails validation.
The modular nature of Hyperledger Fabric enables the deployment of smart contracts (chaincode) tailored to various node types, ensuring a flexible and secure transaction management system. PBFT enhances network robustness by tolerating up to \(f\) faulty nodes out of a total of \(n\), provided that:
$$\begin{aligned} n \ge 3f + 1 \end{aligned}$$
(118)
ensuring the system remains resilient against malicious actors. The transaction validation process consists of several key steps, each ensuring compliance with the network’s endorsement policy, data format, and consensus mechanism.
A transaction proposal \({\mathcal {T}}\) submitted by a client node \(C_i\) undergoes initial structural and content verification through a function:
$$\begin{aligned} {\mathcal {F}}({\mathcal {T}}) = {\left\{ \begin{array}{ll} 1, & \text {if } {\mathcal {T}} \text { adheres to the required format and schema} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(119)
If \({\mathcal {F}}({\mathcal {T}}) = 0\), the transaction is rejected with an error message stating “Invalid Transaction Proposal”.
The transaction is then sent to the set of endorsing peers \({\mathcal {E}}\), where each endorsing peer \(e_j \in {\mathcal {E}}\) verifies and endorses the transaction, producing an endorsement signature \(\sigma _j\):
$$\begin{aligned} \sigma _j = H({\mathcal {T}} \parallel K_{e_j}) \end{aligned}$$
(120)
where \(H(x)\) is a secure cryptographic hash function (e.g., SHA-256), \(K_{e_j}\) is the private key of endorsing peer \(e_j\) and \(\parallel\) denotes concatenation.
The set of collected endorsements is:
$$\begin{aligned} \Sigma = \{\sigma _1, \sigma _2, \dots , \sigma _m\} \end{aligned}$$
(121)
where \(m\) is the total number of endorsements.
The transaction endorsements are verified against the network’s endorsement policy \({\mathcal {P}}_E\):
$$\begin{aligned} {\mathcal {P}}_E(\Sigma ) = {\left\{ \begin{array}{ll} 1, & \text {if endorsement policy conditions are satisfied} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(122)
If \({\mathcal {P}}_E(\Sigma ) = 0\), the transaction is rejected with an error message “Endorsement Validation Failed”.
The transaction undergoes additional validation to ensure that its content and format comply with network rules:
$$\begin{aligned} {\mathcal {D}}({\mathcal {T}}) = {\left\{ \begin{array}{ll} 1, & \text {if data and format meet network standards} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(123)
If \({\mathcal {D}}({\mathcal {T}}) = 0\), the transaction is rejected with an error message “Transaction Validation Failed”.
Once validated, the transaction is included in a newly formed block \(B_k\), where:
$$\begin{aligned} B_k = B_{k-1} + H({\mathcal {T}}) \end{aligned}$$
(124)
ensuring that each block maintains cryptographic integrity via hash-linking.
The block \(B_k\) is committed to the blockchain ledger only if consensus is reached among a majority of validating peers \(V\), satisfying:
$$\begin{aligned} |V_{\text {agree}}| \ge \frac{|V|}{2} + 1 \end{aligned}$$
(125)
If the commitment fails, the transaction is flagged as “Block Commitment Failed”, and the process is halted.
For transparency and accountability, every validated and committed transaction is logged on the blockchain. The log entry \({\mathcal {L}}\) for transaction \({\mathcal {T}}\) is represented as:
$$\begin{aligned} {\mathcal {L}} = (ID_{{\mathcal {T}}}, T_{\text {valid}}, S_{{\mathcal {T}}}) \end{aligned}$$
(126)
where \(ID_{{\mathcal {T}}}\) is the unique transaction identifier, \(T_{\text {valid}}\) is the timestamp of validation and \(S_{{\mathcal {T}}}\) is the final status (valid/invalid).
The Transaction Validation and Commitment process ensures rigorous verification, cryptographic security, and network-wide consensus, protecting the blockchain ledger against unauthorized modifications. Any anomalies encountered during the process are documented for auditing, facilitating real-time troubleshooting and maintaining blockchain reliability.
Fig. 4
PBFT consensus mechanism.
This activity diagram in Fig. 4 represents the workflow of the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism, which is used to achieve agreement in a distributed system, even in the presence of faulty or malicious nodes. The process begins with the client sending a request to the Primary node, which then broadcasts the request to all Backup nodes in the system. Each Backup node receives the request and sends a Pre-Prepare message to all nodes, which is then checked for validity. If the Pre-Prepare message is valid, the Backup nodes proceed by sending a Prepare message to all other nodes. A decision point is introduced here, where the Backup nodes check if the majority of nodes have sent their Prepare votes. If a sufficient number of votes are received, the nodes send a Commit message to all nodes; otherwise, they wait for more votes. Once the nodes receive Commit messages, they again check if a majority of Commit votes are received. If the majority is met, they send the final Reply to the client, signaling that the consensus has been reached. If the majority is not reached at any stage, the nodes discard the current message and wait for more votes. This diagram captures the sequential steps and decision points of the PBFT protocol, emphasizing the importance of majority agreement at various stages to ensure the integrity and reliability of the system, even in the presence of faulty or malicious nodes.
Smart Contract Deployment: The Smart Contract Deployment process facilitates the execution of self-executing agreements within a blockchain network, enabling secure, automated transactions based on predefined conditions. The Hyperledger Fabric framework leverages a modular smart contract system, referred to as chaincode, to govern decentralized execution.
Let \({\mathcal {S}}\) denote a smart contract proposed for deployment, where:
$$\begin{aligned} {\mathcal {S}} = (C, {\mathcal {P}}, {\mathcal {E}}) \end{aligned}$$
(127)
where \(C\) represents the smart contract code, \({\mathcal {P}}\) denotes the set of predefined policies governing the contract and \({\mathcal {E}}\) is the set of endorsing organizations validating the deployment. The deployment process follows a series of verification and endorsement steps before finalizing the smart contract instantiation on the blockchain. A successful deployment is recorded as:
$$\begin{aligned} {\mathcal {D}}({\mathcal {S}}) = 1 \end{aligned}$$
(128)
where \({\mathcal {D}}({\mathcal {S}}) = 0\) indicates a deployment failure.
Step 1: Review Smart Contract Code: The initial step involves static code analysis to verify adherence to security and execution standards. This is formalized as a validation function:
$$\begin{aligned} {\mathcal {F}}(C) = {\left\{ \begin{array}{ll} 1, & \text {if } C \text { adheres to coding standards and security policies} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(129)
If \({\mathcal {F}}(C) = 0\), the deployment process terminates with an error message “Invalid Smart Contract Code.”
Step 2: Gather Endorsements: To establish consensus on the smart contract, endorsements from endorsing organizations \(e_j \in {\mathcal {E}}\) are collected. Each endorsing entity \(e_j\) verifies and signs the contract proposal, generating an endorsement signature:
$$\begin{aligned} \sigma _j = H({\mathcal {S}} \parallel K_{e_j}) \end{aligned}$$
(130)
where \(H(x)\) is a secure cryptographic hash function (e.g., SHA-256) and \(K_{e_j}\) is the private key of endorsing entity \(e_j\).
The aggregated endorsements set is represented as:
$$\begin{aligned} \Sigma = \{\sigma _1, \sigma _2, \dots , \sigma _m\} \end{aligned}$$
(131)
where \(m = |{\mathcal {E}}|\) is the number of endorsing organizations.
Step 3: Validate Endorsements: The collected endorsements are validated against the endorsement policy \({\mathcal {P}}_E\):
$$\begin{aligned} {\mathcal {P}}_E(\Sigma ) = {\left\{ \begin{array}{ll} 1, & \text {if all required endorsing organizations have signed} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(132)
If \({\mathcal {P}}_E(\Sigma ) = 0\), the process halts with an error “Endorsement Gathering Failed.”
Step 4: Instantiate Smart Contract Upon successful validation, the smart contract \({\mathcal {S}}\) is instantiated on the blockchain network. The instantiation function is defined as:
$$\begin{aligned} {\mathcal {I}}({\mathcal {S}}) = {\left\{ \begin{array}{ll} 1, & \text {if the smart contract is successfully instantiated} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(133)
If \({\mathcal {I}}({\mathcal {S}}) = 0\), the deployment fails with an error “Smart Contract Instantiation Failed.”
Step 5: Update network configuration: Once the smart contract is instantiated, the network configuration is updated to integrate \({\mathcal {S}}\). This ensures that all participating nodes recognize and can invoke the deployed contract. The configuration update function is given by:
$$\begin{aligned} {\mathcal {U}}({\mathcal {S}}) = {\left\{ \begin{array}{ll} 1, & \text {if the network configuration is successfully updated} \\ 0, & \text {otherwise} \end{array}\right. } \end{aligned}$$
(134)
A failure in updating the network configuration returns an error “Network Configuration Update Failed.”
Step 6: Log Smart Contract Deployment: For transparency, auditing, and accountability, a log entry \({\mathcal {L}}\) is created for every successfully deployed smart contract:
$$\begin{aligned} {\mathcal {L}} = (ID_{{\mathcal {S}}}, T_{\text {deploy}}, {\mathcal {P}}, S_{{\mathcal {S}}}) \end{aligned}$$
(135)
where \(ID_{{\mathcal {S}}}\) is the unique identifier of the smart contract, \(T_{\text {deploy}}\) is the deployment timestamp, \({\mathcal {P}}\) is the smart contract policy and \(S_{{\mathcal {S}}}\) represents the deployment status (deployed/failed).
An essential component of blockchain infrastructure is the Smart Contract Deployment procedure, which guarantees the safe, law-abiding, and consensus-driven implementation of self-executing contracts. Using network-wide configuration updates, endorsement policies, and cryptographic verification, the process guarantees thorough validation at every level. Effective debugging and maintenance are made possible by the thorough documentation of any anomalies or problems that occur during deployment.