A Blockchain-Based Vehicle Customs Clearance System for Secure Sequential Verification and Fraud Detection

2.1 Blockchain in customs and border control

Recent research has shown the potential benefits of blockchain technology in customs operations, vehicle authentication, and fraud prevention. Early customs-oriented blockchain frameworks were discussed in these studies [5, 6], while later studies extended these concepts to operational customs and logistics environments [7, 8]. Several efforts have been proposed for blockchain-based customs solutions to improve data integrity and regulatory compliance in customs processes but most are still in concept and do not support vehicle level authentication or process workflow control. Other solutions have been based on transportation and customs-related solutions, which have adopted the blockchain, IPFS and NFT technologies to secure document management and show the cyber-resilience of the solution, but without implementing multi-attribute vehicle verification or sequential stage control [7, 8]. Additionally, blockchain has been paired with statistical and machine learning methods for customs risk assessment and anomaly detection, and these solutions typically involve a risk score but do not necessarily enforce the workflow deterministically or enforce severity checks for attributes [9, 10]. Thus, the current customs clearance systems do not address the integration of workflow enforcement, multi-vehicle attribute verification, and structured fraud alert [11, 12].

2.2 Blockchain for vehicle identity and registration

Blockchain technology has been used more and more in the vehicle authentication, record management, registration, and certification. Previous works have shown that distributed ledgers could be used to enhance vehicle identity protection, track the origin of a vehicle, record the integrity of the documents involved, and provide security for the vehicle's identity during document verification, including using digital signatures and blockchain-based registration systems [13-19]. The methods presented contribute to the vehicle record management and anti-forgery protection but are mainly concerned with the registration, authentication or record-tracking operation. The existing literature does not fully tackle real-time multi-attribute cross-verification in the midst of customs processing, severity classification of fraud detection and strict enforcement of the sequential processing.

2.3 E-government and fraud detection

In the literature, several permissioned blockchain architectures have been studied for various applications, including government record management, identity management, government document sharing, vehicular network integrity, and smart government applications [20-27]. The studies illustrate how blockchain technology can enhance transparency, auditing, trust and security in public-sector services. Besides, blockchain-based audit trails have been investigated for fraud detection [28] and anomaly classification [29], and immutability of record management has been demonstrated to decrease the opportunities for tax evasion and document fraud. In spite of these developments, current solutions are limited to general e-government services and record management in public-sector workflow, and do not consider the detection of attribute mismatch, enforcement of sequential workflow, or severity-classified fraud alerting in an operational customs clearance workflow.

2.4 Research gap

Table 1 summarises the capabilities of existing approaches relative to the proposed system.

As shown in Table 1, no existing system simultaneously provides end-to-end stage enforcement, multi-attribute vehicle verification, severity-classified fraud alerts, and a role-based multilingual interface. In Table 1, “√” denotes explicit implementation with experimental validation, while “Partial” denotes limited implementation of the capability without full workflow integration, as reported in the cited works. Comparisons are feature-based and derived from published system descriptions rather than direct experimental benchmarking.

Table 1. Comparison of related systems

4.1 Block structure

As illustrated in Figure 3, each block contains eight fields: index, timestamp (ISO-8601 UTC), vehicle_id, stage, permit_id, data (stage-specific vehicle attributes), previous_hash (SHA-256 of the preceding block), and hash (SHA-256 of current block contents). The block hash is computed as:

hash(Bᵢ) = SHA-256(JSONᴺ({index, timestamp, vehicle_id, stage, permit_id, data, previous_hash, created_by}))

where, JSONᴺ applies lexicographic key sorting and UTF-8 encoding for deterministic serialisation [30]. Modification of any block Bᵢ invalidates the hashes of all subsequent blocks, providing comprehensive tamper detection [4].

In addition to SHA-256 hash chaining, each block is digitally signed using the ECDSA-SHA256. Public–private key pairs are assigned to authorised participants, and signature verification is performed during chain validation to ensure transaction authenticity, integrity, and non-repudiation. Furthermore, a Merkle root is computed from the block contents to strengthen integrity verification and facilitate tamper detection. This design constitutes a cryptographically secured hash-chained prototype rather than a distributed blockchain with consensus. The security guarantee provided is tamper-evidence through hash linkage, not Byzantine fault tolerance. Distributed deployment is a defined direction for future work. Blockchain records are stored in encrypted form using symmetric encryption, providing an additional confidentiality layer for persisted vehicle records.

tu_pian_6.png

Figure 3. Blockchain block structure of the proposed system, showing index, timestamp, data, hash, and previous_hash fields ensuring tamper-evident integrity through SHA-256 hash linkage

4.2 Genesis block and permit ID generation

The ledger initialises with a genesis block assigned vehicle_id = 'GENESIS' and previous_hash = '0' [3]. Upon ENTRY registration, a permit identifier is generated as: permit_id = 'PERMIT-{YYYYMMDD}-' + SHA-256('PERMIT|{vehicle_id}|{UTC_timestamp}|{chain_length}') [8]. Zero collisions were observed across 10,000 generated identifiers.

4.3 Stage ordering and chain integrity

Stage ordering is enforced through three constraints: (1) the initial constraint requires that every vehicle's first recorded stage is ENTRY; (2) the uniqueness constraint prohibits any stage from being recorded more than once per vehicle; (3) the ordering constraint ensures that all stages follow the prescribed sequence without omission or bypass. The validate_chain() method performs an O(n) full-chain audit, verifying both hash correctness and previous_hash linkage [4]. Chain validation includes verification of block hashes, previous-hash linkage, and digital signatures. Any modification to signed block contents invalidates the corresponding signature and is detected during validation.

4.4 Fraud detection mechanism

Vehicle profile and alert classification

The ENTRY block is the reference block that cannot be modified. Each of the following stages involves a cross-verification of 7 attributes: permit_id, plate_number, chassis_number, engine_number, car_colour, car_type and image_hash (SHA-256 of the image of the car taken at ENTRY). Table 3 provides details of the types and severity of alerts.

Table 3. Alert types and severity classification

Note: CRITICAL alerts (chassis and engine mismatches) carry the highest risk as these identifiers are legally definitive for vehicle identity [1]. HIGH alerts indicate strong evidence of document or physical fraud [28]. MEDIUM alerts trigger investigative review without mandatory vehicle detention.

Alert record structure

Alerts are recorded as structured dictionaries containing vehicle_id, alert_type, severity, message, stage, and timestamp. Alerts are non-blocking by design: they are logged to the audit trail without interrupting blockchain recording, preserving forensic completeness regardless of officer action [9]. Officers may override alerts in exceptional circumstances, with all overrides permanently logged.

The experimental results show that the prototype can meet the design goal under the single-node scope. The rule-based verification and stage-ordering mechanisms identified all predefined fraud patterns across the seven evaluated attributes and prevented all tested invalid workflow transitions. These results prove the correctness of the prototype in the specified test cases.

The rule-based method was intentionally used rather than machine learning methods to give interpretable and auditable decision logic that is appropriate for regulatory environments where officers are required to explain automated alerts [10]. The current scope of detection is for exact-match verification of seven attributes and does not consider partial attribute matches, noisy input data, human transcription errors, or coordinated multi-stage manipulation of the data, or forged images that recreate a legitimate hash. These limitations represent opportunities for future improvement and further investigation. Further, input validation detection is done before the recording on the blockchain, such as the mandatory fields and the consistency of the input formats, and the detection of the missing records does not fall in the range of the automatic detection system which is in place at the moment.

The implementation is a single-node prototype with cryptographic security that uses hash chaining, digital signatures and Merkle-root verification, not Byzantine fault tolerance, to provide tamper-evidence. The 0.82 ms latency is the time for executing an in-process Python script, excluding the time for network or consensus. Future studies will need to understand the scaling behaviour under distributed deployment conditions.

Table 5: Stage Enf. = Programmatic Prevention of Out-of-Order Stage Execution; Attr. Verif. = Cross-Checking of Multiple Vehicle Identity Attributes Against a Fixed Reference Profile. Used as recommended by published descriptions.

Limitations: The evaluation data was based on anonymous data and operational processes from real Iraqi customs workflows. Even though the experimental scale was small, the test scenarios were arranged in such a manner that it was representative of realistic customs processing situations. There are three main limitations of the study. The first is that evaluation was done on a prototype scale, using anonymised customs operational records and customs procedures from Iraq. Although the evaluation was conducted on a prototype scale, the experiments were derived from real operational customs records and procedures. The second is that the prototype is based on a single node and is therefore not distributed consensus or Byzantine fault tolerant. But there are mechanisms for integrity protection including cryptographic hash chaining, digital signatures, merkle-root verification and chain validation. Third, current fraud detection relies on exact-match verification of pre-defined vehicle attributes, while more complex scenarios such as partial-match verification, noisy data, image forgery and large-scale operational validation are further research tasks.