arXiv CSopen access

Blockchain-Linked Auditable Decision Management for Telecom/IoT Fraud-Control Requests

1

Blockchain-Linked Auditable Decision Management for Telecom/IoT Fraud-Control Requests

arXiv:2607.09259v1 [cs.CR] 10 Jul 2026

Saviz Changizi, Nasibeh Mohammadzadeh, Mohammad Shojafar, and Rahim Tafazolli

Abstract—Telecom fraud-control studies often stop at detectorlevel classification, but deployment use requires request-level policy resolution, lifecycle traceability, and auditability. This paper reframes fraud control as blockchain-linked auditable decision management for synthetic telecom/IoT fraud-control requests, and its main result is that the QLoRA-tuned LLM branch becomes much more usable than zero-shot prompting but mainly approaches, rather than outperforms, a lower-cost centralized ensemble. The framework maps each synthetic deployment record to a managed request, blocks explicit outof-boundary cases through a deterministic hard-fraud gate, scores non-hard requests using centralized ML (M1), federated meta-learning (M2), or LLM-family risk sources (M3), and resolves actions through a shared five-state policy, two-zone refinement mechanism, and local Ethereum-compatible audit layer. Evaluation uses separate synthetic training data and a 100,000-record deployment replay corpus, so the study should be read as controlled drift-replay evidence rather than field validation or proof of live deployability. On validation, M1 gives the strongest balance, with legitimate-request FPR 0.0890 under the 0.10 operating cap and soft-fraud recall 0.8341. On labeled deployment replay, however, the legitimate-FPR gap becomes large: M1 rises to 0.1646 and M3-QLoRA to 0.1801, while M3QLoRA reduces the M3-Base legitimate FPR from 0.3915 and reaches 0.8240 soft-fraud recall. Blockchain telemetry shows that lifecycle gas, cost, latency, and throughput differences are driven by submitted off-chain decision profiles rather than changes in fraud logic. Index Terms—Telecom fraud control, IoT security, auditable decision management, blockchain audit, federated learning, large language models, QLoRA, deployment replay.

I. I NTRODUCTION Telecom fraud detection has been framed as a critical problem in telecom networks because fraudulent activity can threaten users’ privacy and property security [1]. Industry reports further indicate the economic scale of the problem, with the Communications Fraud Control Association (CFCA) estimating global telecommunications fraud losses at USD 38.95 billion in 2023, equivalent to 2.5% of telecommunications revenues [2]. More recent industry reporting citing the latest CFCA Fraud Loss Survey indicates that global telecom fraud losses increased further to approximately USD 41.82 billion by 2025 [3]. Wangiri fraud provides a concrete telecom-fraud example: it exploits missed calls and premiumrate numbers and has commonly been studied using Call Detail Record (CDR)-style telecom data [4]. Saviz Changizi, Mohammad Shojafar, and Rahim Tafazolli are with the 6G Innovation Centre, Institute for Communication Systems, University of Surrey, UK (e-mail: {s.changizi, m.shojafar, r.tafazolli}@surrey.ac.uk). Nasibeh Mohammadzadeh is with the Department of Network Engineering, Polytechnic University of Catalonia, Barcelona, Spain (e-mail: [email protected]).

At the network-management level, sixth-generation (6G)oriented telecom environments are shaped by requirements such as ultra-low latency, ultra-dense connections, high reliability, low power consumption, energy efficiency, intelligence, and security [5]. In 6G-Internet of Things (IoT) resourcemanagement settings, relevant quality-of-service and resourcemanagement variables include delay, bandwidth utilization, power consumption, throughput, device mobility, and location [6]. Static thresholds and predefined rules may fail to adapt to evolving fraud patterns, leading to false positives or missed fraud cases, and highly imbalanced, unlabeled CDR data further complicate fraud-model training and evaluation [4]. More broadly, rule-based anomaly detection has been reported as insufficient in fast-evolving telecom environments [7]. Time-series anomaly-detection benchmarks may include flawed examples, making published algorithm comparisons unreliable [8]. Temporal data preparation can introduce leakage, especially when preprocessing choices do not preserve temporal causality [9]. Chronological validation and test splits can help avoid leakage from future samples, and public benchmark elements can improve reproducibility in telemetrystyle anomaly detection [10]. Telecom fraudsters may commit co-fraud and disguise themselves among benign users, while sequential-pattern approaches may ignore synergistic fraud patterns [11]. Federated learning can support collaborative telecom fraud model training by sharing model updates rather than raw data [12]. Large language models can support telecom fraud reasoning, but prompt-based reasoning may remain unstable across diverse fraud texts and long-tail cases [13]. Blockchain is positioned in communication networks as a trust substrate that can support secure logs, decentralized identity, and auditability [14]. Despite these advances, most telecom fraud studies remain detector-centric: they focus on identifying suspicious records but provide limited support for deployment-stage service decisions. In practical network/service management, fraud control also requires request-level policy resolution, execution control, lifecycle traceability, and auditable decision handling. Existing ML, federated-learning, LLM-family, and blockchain-enabled studies are rarely evaluated in a unified deployment setting where heterogeneous off-chain risk signals share the same request substrate, hard/soft policy, frozen decision logic, and blockchain-linked audit workflow. To address this gap, this paper proposes a blockchainlinked auditable decision-management framework for telecom/IoT fraud-control request handling in a controlled synthetic deployment-replay setting. The framework treats fraud

2

control as a managed request-resolution workflow rather than as a standalone classification task. During deployment replay, each synthetic telecom/IoT service-usage record is mapped to a managed fraud-control request; the off-chain decision is then resolved through a shared policy layer and submitted to the audit and execution layer. The generated corpora support controlled deployment replay and are not intended to represent real operator traffic or measurements from a live operator network. The framework compares three deployment-stage risksource families: M1, a centralized ML configuration; M2, a federated meta-learning configuration; and M3, an LLMfamily configuration evaluated through zero-shot and QLoRA sequence-classification variants. Across all configurations, explicit hard-fraud cases are blocked by a deterministic hardfraud gate, while non-hard requests are scored by the active risk source and resolved through a common five-state policy, two-zone refinement mechanism, and audit workflow. Blockchain transactions in this paper refer only to Web3/Ethereum operations for request submission, decision logging, review resolution, and approved-request finalization; they do not denote financial transactions in the generated dataset. The main contributions are as follows. 1) Deployment-stage fraud-control request workflow: We propose a unified framework that maps synthetic telecom/IoT service-usage records to managed fraud-control requests. Fraud-control behavior is evaluated as part of a request-level management workflow during deployment replay, while the runtime input, policy resolver, and decision logic remain fixed across M1–M3. 2) Hard/soft fraud-aware policy resolution: We introduce a shared decision logic that separates deterministic hard-fraud blocking from inferential non-hard fraud scoring. Out-of-boundary requests are assigned to HARD_FRAUD, while non-hard requests are mapped into NO, MAYBE_LOW, MAYBE_HIGH, and YES states, with ambiguous cases handled through two-zone refinement. 3) Controlled deployment-replay evaluation: We construct separate synthetic training and deployment corpora for a controlled synthetic telecom/IoT deployment-replay setting. The design emphasizes schema alignment, splitaware preprocessing, leakage control, controlled drift, hard/soft fraud composition, and post-training deployment replay under a common decision and audit protocol. 4) Blockchain-linked request lifecycle and audit telemetry: We integrate the retained off-chain decision profiles with a shared Ethereum-compatible audit and execution layer. The blockchain component records already-formed off-chain decisions rather than performing fraud detection, supporting request submission, decision logging, optional review resolution, approved-request finalization, blocked-request retention, state retrieval, and execution telemetry analysis. A preliminary conference-stage study by the present authors combined machine learning, GPT-based LLM reasoning, and blockchain smart contracts for telecom fraud detection [15].

This journal version substantially extends that study by reformulating the problem as deployment-stage fraud-control request decision management. It adds the M1–M3 risk-source comparison, separates deterministic hard-fraud handling from non-hard fraud scoring, uses separate controlled training and deployment corpora, applies validation-frozen five-state policy resolution with two-zone refinement, and expands the blockchain component into a request-lifecycle audit layer with run-isolated execution modes. The remainder of this paper is organized as follows. Section II reviews related work, Section III presents the problem setup, Section IV describes the architecture variants and audit layer, Section V details the experimental design, Section VI reports the results, Section VII discusses implications and limitations, and Section VIII concludes the paper. II. R ELATED W ORK AND R ESEARCH G AP Telecom fraud and anomaly-detection studies provide important detector-level foundations, but they are primarily centered on identifying suspicious behavior rather than managing request-level service decisions. Wangiri fraud detection has been studied with highly imbalanced and unlabeled Call Detail Record (CDR) data, and static thresholds may fail to adapt to evolving attack patterns, leading to false positives or missed fraud cases [4]. Graph-based telecom fraud research shows that fraudsters may engage in co-fraud and camouflage themselves among benign users [11], while Hawkes-enhanced sequence modeling indicates that fraudsters may behave like normal users and collaborate as highly organized groups [16]. Cost-sensitive graph neural networks such as GAT-COBO address graph imbalance in telecom fraud detection by applying cost-sensitive boosting over Graph Attention Network (GAT)-based node representations and validating the approach on real-world telecom fraud datasets derived from operator-side CDR-style data [17]. While such studies are useful for constructing fraud-risk detection signals, they primarily focus on model-level fraud identification rather than deployment-stage network/service management workflows involving shared policy resolution and lifecycle audit. Benchmark rigor is important when detector outputs are used in operational decision workflows. Prior work shows that common time-series anomaly-detection benchmarks may contain flawed examples, making published algorithm comparisons unreliable [8]. Leakage-aware temporal benchmarking further shows that preprocessing choices can materially affect model performance and may introduce leakage when future information enters scaling, feature engineering, or repair steps [9]. Chronological or rolling-origin evaluation, trainingonly preprocessing, online test execution without future samples, and publicly available benchmark components can improve the reliability and reproducibility of telemetry-style anomaly detection studies [10]. The network context further motivates network/service-level evaluation [18], [19]: sixth-generation (6G) visions emphasize key performance indicator (KPI) trade-offs around latency, connection density, reliability, energy efficiency, and intelligence [5], while 6G-enabled Internet of Things (IoT) resource

3

management involves quality-of-service (QoS) and allocation factors such as delay, bandwidth utilization, power consumption, throughput, mobility, and location [6]. In this paper, controlled synthetic deployment replay is used to separate training-side model selection from runtime request execution and to examine decision-management behavior under documented experimental conditions. Federated Learning (FL) and LLM-family reasoning/classification provide two relevant but distinct risk-signal streams. FL can support collaborative telecom fraud model training by sharing model updates rather than raw data [12]. In 6G-security studies, FL is positioned as a distributed and privacy-preserving artificial intelligence approach, although practical deployment still faces challenges such as non-independent and identically distributed (non-IID) data, scalability, system heterogeneity, adversarial clients, and poisoning attacks [20], [21]. In parallel, LLM-based telecom fraud studies have investigated structured prompting for fraud text detection, but conventional prompting can be unstable for diverse fraud texts, long-tail categories, and confusing cases [13]. LLM neuron-selection work further supports the use of intermediate LLM representations for telecom fraud text classification [22]. FL and LLM-family studies support distributed learning, language-based reasoning, and fine-tuned language-model classification, but they are typically evaluated as separate modeling or reasoning approaches rather than as risk-signal configurations operating under one runtime request substrate, policy resolver, and audit workflow. Blockchain-oriented work supports auditability, trust, and service management in communication networks. In Beyond 5G (B5G) and 6G networks, blockchain and smart contracts can support decentralized reputation and trust management by providing immutability, transparency, Service Level Agreement (SLA) compliance, and feedback-based reputation scoring [23]. In Dynamic Spectrum Access (DSA) and network slicing, blockchain and smart contracts can provide traceability, auditability, accountability, and automation for resource sharing and slice orchestration [24]. Spectrum fraud or misuse has been defined as unlawful access, whether intentional or unintentional, to licensed radio spectrum that can interfere with rightful spectrum owners, and blockchain-based DSA work has explored consensusbased mechanisms for detecting and handling spectrum-access violations [25]. Related access-control work provides a comparable architectural pattern in which computationally intensive Machine Learning (ML) and Explainable Artificial Intelligence (XAI) tasks run off-chain, while access decisions and audit logs are immutably recorded on blockchain [26]. The present study adopts this off-chain/on-chain separation in a telecom/IoT fraud-control request setting, where risk assessment is performed off-chain and blockchain is used to preserve the resulting request lifecycle, audit trail, and execution telemetry. Table I provides a stream-level positioning of related work. The comparison is conceptual and architectural rather than a numerical benchmark, since the reviewed studies differ in task definition, data availability, deployment assumptions, and evaluation protocol. Based on this synthesis, existing

work provides limited support for evaluating heterogeneous off-chain risk signals under a common deployment-stage request-management, policy-resolution, and audit workflow. The present framework addresses this gap by comparing centralized ML, federated meta-learning, and LLM-family risk sources in one controlled synthetic telecom/IoT deploymentreplay setting. III. U NIFIED F RAMEWORK AND P ROBLEM S ETUP Deployment-stage fraud control is formulated as an auditable decision-management problem for telecom/IoT fraudcontrol requests in a controlled synthetic deployment-replay setting. Let xi denote the i-th unlabeled synthetic telecom/IoT service-usage record in the deployment replay. During blockchain-linked execution, each record is mapped to a managed fraud-control request, while fraud labels are retained only for post-hoc evaluation and audit. Let Mk denote the active deployment configuration, where k ∈ {1, 2, 3} and Mk ∈ {M1, M2, M3}. The objective is to produce, for each mapped request, an off-chain request-level action ai,k ∈ {APPROVE, BLOCK} under a common decisionmanagement structure. The resulting action is then forwarded to the shared blockchain-linked execution and audit pathway. Fig. 1 presents the end-to-end workflow of the proposed framework. The proposed framework separates explicit operational violations from inferential fraud-risk assessment. A deterministic hard-fraud gate h(xi ) is applied first. If h(xi ) = 1, the corresponding request is assigned to the HARD_FRAUD state and the final action is fixed as BLOCK. Otherwise, the request is treated as non-hard and is passed to the active configuration-specific scoring chain. For each non-hard request, the active configuration outputs a retained score si,k ∈ [0, 1]. M1 obtains this score from the centralized ML ensemble, M2 from the federated meta-learner over stacked base-detector probabilities, and M3 from an LLM-family source. In M3-Base, the score is extracted from a schema-validated zero-shot artifact, whereas in M3-QLoRA it is the fraud-class probability obtained from softmax-normalized sequence-classifier logits. The supervised training tasks in M1, M2, and M3-QLoRA are binary non-hard-branch classification tasks, distinguishing nominal in-range records from soft-fraud in-range records, while hard-fraud records are handled separately by the deterministic OOB gate. The four operational non-hard states are not directly trained output classes; instead, this score is mapped downstream into request-level operational decision states. Configuration-specific score boundaries map si,k into one of four non-hard coarse states: NO, MAYBE_LOW, MAYBE_HIGH, and YES. Let the retained configurationspecific boundaries be b1,k < b2,k < b3,k . The mapping is defined as si,k < b1,k for NO, b1,k ≤ si,k < b2,k for MAYBE_LOW, b2,k ≤ si,k < b3,k for MAYBE_HIGH, and si,k ≥ b3,k for YES. The NO and YES states are resolved directly as APPROVE and BLOCK, respectively. Requests in MAYBE_LOW and MAYBE_HIGH are routed

4

TABLE I

C ONCEPTUAL STREAM - LEVEL POSITIONING OF RELATED WORK Stream

Refs.

Supported focus

Gap relative to this paper

Position of this paper

Telecom fraud and anomaly detection

[4], [11], [16], [17]

Wangiri/CDR fraud detection with imbalance and unlabeled data [4]; co-fraud and synergy-aware graph detection [11]; temporal/interaction-aware sequence modeling [16]; graph-imbalance handling [17].

Primarily detector-centric; not designed to define a shared request-level policy-resolution and audit workflow.

Treats detector outputs as inputs to a deployment-stage fraud-control request-management workflow.

Benchmark rigor and [8]–[10] leakage-aware evaluation

Flawed benchmark examples can distort comparisons [8]; temporal preprocessing may introduce leakage [9]; chronological splits and public benchmark elements improve reproducibility [10].

Not designed to examine telecom/IoT fraud-control deployment replay or blockchain-linked request execution.

Uses controlled deployment replay to separate training-side model development from runtime request-level execution.

Federated/distributed learning for telecom/network security

[12], [20], [21]

FL supports telecom fraud learning through shared model updates rather than raw data [12]; FL is positioned for 6G security but faces non-IID, scalability, heterogeneity, and poisoning challenges, including poisoning attacks in zero-touch B5G settings [20], [21].

Generally does not evaluate federated Evaluates M2 as a federated risk-signal meta-learning under the same runtime policy configuration under the same request, and audit substrate as centralized ML and policy-resolution, and audit workflow as M1 LLM-family configurations. and M3.

LLM-based fraud/security reasoning and classification

[13], [22]

Prompt-based telecom fraud reasoning can be unstable for long-tail and confusing cases [13]; LLM neuron/representation selection supports telecom fraud classification [22].

Primarily focuses on text reasoning/classification rather than telecom/IoT service-usage records with shared request-level policy resolution.

Blockchain-enabled audit, governance, and service management

[23]–[27]

Smart contracts support B5G/6G reputation Not primarily designed to integrate Uses blockchain as a shared audit, and SLA trust management [23]; blockchain centralized ML, federated meta-learning, and traceability, lifecycle logging, provides traceability for DSA/slicing [24]; LLM-family off-chain risk signals into one execution-recording, and telemetry layer for blockchain-based DSA addresses fraud-control request lifecycle. already-formed off-chain decisions. spectrum-access violations [25]; off-chain ML with on-chain audit is used in access control [26]; blockchain supports transparent 5G resource trading [27].

5G/6G/IoT [5], [6], [24], network/service[25] management context

Evaluates M3 as an LLM-family risk configuration covering zero-shot structured artifacts and QLoRA sequence-classification probabilities.

6G visions emphasize latency, dense Does not primarily define a telecom/IoT Instantiates these concerns in a controlled connectivity, reliability, energy efficiency, fraud-control request workflow that couples synthetic telecom/IoT deployment-replay intelligence, and security [5]; 6G-IoT hard/soft policy resolution with setting. resource management involves delay, heterogeneous risk-source comparison and bandwidth, power, throughput, mobility, and lifecycle audit. location [6]; DSA/slicing are relevant resource-management settings [24], and blockchain-based DSA has been used for spectrum-access violation handling [25].

to zone-specific refinement using only deployment-available signals from the active configuration. The policy structure separates direct decisions from refinement-mediated resolution of ambiguous fraud-control requests. All coarse-state boundaries, refinement models, selected feature sets, and operating thresholds are selected during development and frozen before deployment-stage inference. M1 and M2 derive their boundary evidence from out-of-fold and validation-side model scores, using centralized ensemble probabilities and federated meta-probabilities, respectively. M3 uses variant-specific evidence: frozen zero-shot artifact probabilities for M3-Base and sequence-classifier fraud probabilities for M3-QLoRA. The available training and validation evidence is then pooled to fit the retained coarse-state boundary mechanism. Validation-stage operating selection is governed by a shared recall–FPR operating rule, denoted R0.10,1.00 . This rule imposes a legitimate-request FPR ceiling of 0.10 and targets soft-fraud recall of 1.00 across M1, M2, and M3. When the target soft-fraud recall is infeasible under the FPR ceiling, the retained policy falls back to the threshold or threshold pair that maximizes validation soft-fraud recall while remaining under the same FPR cap. Here, si,k denotes a retained deployment-

time risk signal rather than a newly trained runtime model. In addition, a validation-based feasibility guard was applied to the direct YES boundary when necessary, ensuring that requests resolved directly by the hard gate or the YES state did not already violate the retained FPR ceiling before twozone refinement was applied. For M3, the LLM-family component is treated as a nonhard risk-signal provider rather than as the final decision engine. In M3-Base, the raw zero-shot response is constrained to a fraud-risk probability and short explanatory reasons; auxiliary artifact fields such as confidence, status indicators, and audit tags are derived or normalized in the artifact layer and retained only as metadata for downstream compatibility and audit. In M3-QLoRA, no free-form labels, explanations, or JSON responses are generated; the retained risk signal is the fraud-class probability obtained from the softmax-normalized sequence-classifier logits, while derived confidence fields and fixed audit tags are retained only for artifact compatibility and audit. In both variants, the shared downstream policy uses the retained probability signal to derive the operational state, refinement routing, and final action. In this formulation, MAYBE_LOW and MAYBE_HIGH are operational policy states rather than directly supervised LLM output classes.

5

Anomaly Normal Data Data

Feature Engineerin g

Split-aware Train/Val/Test

Training-side Model Development

Metric Calculation

Results Comparison

Retained Risk-Source Artifacts

Synthetic Data

Five-State Decision Structure HARD-FRAUD

MAYBE-LOW

MAYBE-HIGH

NO

YES

M3: LLM-Family

M1: Centralised M2: Federated Meta-Learning ML Block

Two-Zone Refinement

Contract ABI & Address

Solidity

Smart Contract

Remix IDE

Approve

Block

APPROVE/BLOCK

Ganache Web3.py Gateway

Blockchain Execution

On-Chain Execution Records

Local Ethereum-compatible implementation

Fig. 1. End-to-end workflow of the proposed blockchain-linked auditable decision-management framework for telecom/IoT fraud-control

requests. The workflow separates training-side artifact development, configuration-specific risk-source generation, shared five-state policy resolution, and blockchain-linked execution/audit recording.

The final off-chain action ai,k is forwarded to the shared blockchain-linked execution and audit layer. This layer records the request lifecycle, logs the off-chain decision, stores reviewstage resolution where applicable, finalizes approved requests, and preserves blocked requests in a non-executed state. Algorithm 1 formalizes the shared off-chain request-level decision protocol applied across M1–M3 before blockchainlinked execution. The protocol first applies the deterministic hard-fraud gate. Requests that violate the synthetic OOB policy are assigned to HARD_FRAUD and blocked without probabilistic scoring. All remaining requests are scored by the active configuration Mk , mapped into one of the non-hard operational states, and either directly resolved or passed to zone-specific refinement. In the algorithm, srci,k denotes the decision source recorded for audit, indicating whether the final request-level decision was triggered by the deterministic hardfraud gate or by the active configuration Mk . The algorithm returns the final off-chain action and an audit payload that is later submitted to the blockchain-linked execution layer. The configuration-specific implementation of R ISK S IGNAL is summarized in Table II and detailed in the configuration-specific descriptions of M1–M3; the remaining abstract functions denote state mapping, refinement-feature construction, zone refinement, audit-payload construction, validator selection, and

telemetry collection. Throughout the decision protocol, si,k denotes the retained probability signal used for non-hard requests, mi,k denotes configuration-specific score metadata, and bi,k denotes the audit payload submitted to the blockchain-linked execution layer. The frozen policy artifact Pk contains the retained coarse-state boundaries, selected refinement features, zonespecific refinement models, and operating thresholds selected under the shared rule R0.10,1.00 . The frozen configuration artifact Ak contains the retained scoring artifacts needed to construct si,k . IV. A RCHITECTURE VARIANTS AND B LOCKCHAIN -L INKED AUDIT L AYER A. Comparative Deployment-Stage Configurations The three deployment-stage configurations instantiate the common request-level formulation in Section III and the shared decision protocol in Algorithm 1. Their methodological difference lies in the construction of the non-hard fraud-risk signal before policy resolution: M1 uses centralized ensemble scoring, M2 uses federated meta-level scoring, and M3 uses LLM-family risk scoring. Holding the request substrate, policy resolver, and blockchain-linked audit layer fixed allows

6

Algorithm 1 Shared deployment-stage decision protocol Require: Deployment record xi , active configuration Mk , frozen policy artifacts Pk , frozen configuration artifacts Ak Ensure: Decision state ci,k , final action ai,k , audit payload bi,k 1: CR ← {MAYBE_LOW, MAYBE_HIGH} 2: if h(xi ) = 1 then 3: ci,k ← HARD_FRAUD, ai,k ← BLOCK 4: si,k ← ∅, mi,k ← ∅, srci,k ← H ARD G ATE 5: else 6: (si,k , mi,k ) ← R ISK S IGNAL(xi , Mk , Ak ), srci,k ← Mk 7: ci,k ← M AP TO S TATE(si,k , Mk , Pk ) 8: if ci,k = NO then 9: ai,k ← APPROVE 10: else if ci,k = YES then 11: ai,k ← BLOCK 12: else if ci,k ∈ CR then 13: zi,k ← B UILD R EFINE F EATURES(xi , si,k , mi,k , Mk , ci,k , Pk ) 14: ri,k ← Z ONE R EFINER(zi,k , Mk , ci,k , Pk ) 15: ai,k ← R ESOLVE R EFINEMENT(ri,k , Mk , ci,k , Pk ) 16: end if 17: end if 18: bi,k ← B UILDAUDIT PAYLOAD(xi , Mk , ci,k , si,k , mi,k , srci,k , ai,k ) 19: return ci,k , ai,k , bi,k

the resulting request lifecycle without generating or revising the fraud decision. The blockchain-linked lifecycle consists of request submission, off-chain decision logging, review-stage resolution where applicable, finalization of approved requests, and retrieval of recorded request states. The same blockchain substrate is reused across M1–M3 so that differences in fraud-control outcomes can be attributed primarily to the configurationspecific risk signal and retained policy artifacts. Implementation details, including the smart contract, Web3 integration, contract-function mapping, validator assignment modes, and run-isolation protocol, are described in Sections V-I and V-J. V. E XPERIMENTAL D ESIGN A. Controlled Synthetic Corpora

TABLE II

S UMMARY OF M1–M3 DEPLOYMENT- STAGE CONFIGURATIONS Cfg.

Risk source

Risk signal

Main role

M1

Centralized ML ensemble

Calibrated AVG6 ensemble probability

M2

Federated metalearner over retained basedetector outputs LLM-family risk source

Federated metaprobability

Centralized non-hard scoring backbone for fraud-control requests Federated meta-level nonhard scoring over stacked retained detector probabilities

M3

Zero-shot artifact probability or QLoRA fraud-class softmax probability from classifier logits

LLM-family non-hard scoring through either structured prompting or QLoRA-tuned sequence classification

these configurations to be compared as alternative risk-signal backbones rather than as unrelated detector pipelines. 1) Configuration Space and Design Logic: M1 uses the retained centralized ML ensemble as the non-hard fraud-risk source. M2 keeps the retained base detectors fixed and replaces centralized aggregation with a federated meta-learner over their probability outputs. M3 is implemented as an LLMfamily risk configuration for the risk signal used for nonhard requests. Accordingly, the empirical comparison reports M1 and M2 as single retained configurations, while M3 is reported through two implementation variants, M3-Base and M3-QLoRA. Its zero-shot branch retains the probability component of schema-validated structured LLM artifacts, whereas its QLoRA branch retains the fraud-class probability obtained from softmax-normalized sequence-classifier logits. In all cases, M1–M3 differ only in the source and construction of the non-hard risk signal. Table II summarizes the three deployment-stage configurations considered in this paper; the shared blockchain-linked audit layer is described separately in the following subsection. B. Blockchain-Linked Audit Layer In the proposed architecture, blockchain is used as a shared audit and execution substrate rather than as a fraud detector. The off-chain decision-management service combines the active M1, M2, or M3 risk signal with the shared policy resolver to produce the request lifecycle state and final APPROVE/BLOCK action, while the blockchain layer records

Deployment-oriented telecom/IoT fraud-control evaluation is highly sensitive to data design, anomaly realism, leakage control, and deployment mismatch; weak or overly simplified anomaly benchmarks can lead to misleading conclusions [8]– [10], [28]. Real operator-scale telecom fraud data is rarely available for open academic evaluation because it contains sensitive subscriber behavior, location traces, network-operation information, commercial traffic patterns, and security-relevant fraud signatures. The generated corpora enable transparent fraud injection, explicit hard/soft fraud separation, leakageaware preprocessing, and repeatable replay under documented drift. The evaluation should be interpreted as a controlled posttraining replay, not as direct field validation on real operator traffic or measurements from a live operator network. Two related but methodologically distinct corpora were constructed: a training corpus for supervised model development and an independent deployment corpus for post-training replay and auditing. Their main differences in population, record count, fraud prevalence, class composition, fraud complexity, and drift regime are summarized in Table III. Both corpora were generated from profile-based, stateful, and temporally ordered user activity rather than isolated independent records. Activity was conditioned on radio, spatial, service, device, temporal, mobility, and environmental context, including signal strength, bandwidth, transmission power, latency, location, application behavior, weather condition, and frequency-band family. Device and service context were represented through device type and application type fields, covering customerpremises equipment (CPE), Internet of Things (IoT) devices, drones, laptops, mobiles, tablets, vehicles, and traffic classes such as streaming, gaming, browsing, video calling, Voice over IP (VoIP), file transfer, IoT telemetry, and augmented/virtual reality (AR/VR). The corpus design follows the view that suspicious telecom behavior is often expressed through interactions among behavioral, temporal, spatial, and signaling factors rather than through a single isolated variable [4], [11]. Domain-informed operating ranges were enforced over bounded runtime variables to preserve a coherent nominal operating envelope. Fraud injection followed the eight-type taxonomy reported in Table IV. Each fraud type has paired soft and hard realizations: soft fraud remains inside the admissible operating

7

TABLE III

S UMMARY OF THE TRAINING AND DEPLOYMENT CORPORA Item

Training

Deployment

Role

Model development, validation, testing Population 100 base users; 2,700 scenario trajectories Records 27,000 Scenario structure 27 scenario instantiations Fraud rate Aggregate 15.0% across the controlled 10/15/20% scenario grid Class composition 22,950 nominal; 2,430 soft; 1,620 hard Soft/hard fraud share 60.0% / 40.0% Fraud taxonomy Eight controlled types Fraud complexity 1,338 single; 1,350 double; 1,362 triple Drift regime Controlled scenario grid Drifted components

No deployment drift; controlled scenario variation only

Offline replay and audit 1,000 separate users 100,000 Single replay corpus 5.0%

95,000 nominal; 500 soft; 4,500 hard 10.0% / 90.0% Same eight types 1,666 single; 1,667 double; 1,667 triple Moderate contextual/behavioral drift Weather, app persistence, load, mobility, band preference, latency/bandwidth noise, signal noise, off-hour bias

TABLE IV

C ONTROLLED FRAUD INJECTION TAXONOMY Fraud type

Soft realization

High-power usage

In-range power increase

Spoofed location Long-duration usage Extreme-load behavior Latency spike Bandwidth spike Band hopping Off-hour activity

Hard realization

Power above nominal maximum Suspicious in-range location Location outside admissible shift area Extended but admissible Duration above nominal duration maximum High-load context with inExcessive latency under very range degradation high load In-range latency escalation Latency above nominal maximum In-range bandwidth surge Bandwidth above nominal maximum Suspicious admissible band Disruptive hop with extreme transition deviation Suspicious late-night/early- Off-hour activity with morning activity abnormal conditions

envelope while showing suspicious behavioral or contextual deviation, whereas hard fraud violates at least one explicit operational boundary. Fraudulent records could contain one, two, or three coordinated components, and ground-truth labels were retained only for post-hoc evaluation and audit. The taxonomy should not be confused with the deterministic OOB gate. The eight fraud types define how synthetic fraud is injected, whereas the OOB gate is a label-blind boundaryenforcement mechanism over available runtime variables such as latency, bandwidth, transmission power, signal strength, and usage duration, with geographic validity applied only in views where raw coordinate fields are retained. B. Data Validation, Preprocessing, and Schema Alignment After data generation and fraud injection, both corpora were validated against the intended experimental design. The training corpus used chronological per-trajectory 70/15/15 splitting, resulting in 18,900 training, 2,700 validation, and 5,400 test records, while the deployment corpus was kept

as an independent offline replay corpus. The boundary audit confirmed the intended hard/soft separation: nominal and softfraud records had zero OOB violations, whereas all hard-fraud records had at least one available OOB violation in the relevant audit view. After schema alignment, both corpora used the same 77 retained model-input fields, consisting of 59 numerical and 18 categorical fields, which expanded to 436 transformed features after fitted scaling and one-hot encoding. No missing feature columns or missing values were observed after preprocessing. Labels, fraud descriptors, scenario tags, seeds, anomaly counts, raw identifiers, and construction metadata were excluded from model inputs and retained only for audit. The training corpus was transformed through a splitaware preprocessing pipeline. Temporal, numerical, distancebased, interaction, discretized operating-state, history-aware, and profile-derived descriptors were constructed without using future records. Candidate models were refit on the training split, operating thresholds were selected on the validation split, and final training-corpus performance was reported on the test split. The independent deployment corpus was then processed through the same training-defined feature specification and fitted preprocessing pipeline, with labels retained only for posthoc audit. C. Training-Side Model Development and Backbone Selection After split-aware preprocessing, training-side model development was conducted under a unified protocol for comparing heterogeneous model families under the same deploymentaligned decision logic. Supervised fitting was restricted to the soft branch, consisting of nominal in-range and soft-fraud inrange observations from the training split, while hard-fraud cases were excluded from statistical fitting and handled by the deterministic OOB policy. Calibrated probabilities were exported for validation and test reporting, and the OOB policy was applied as a final-policy override after probability export. Within the training split, candidate models were developed using five-fold group-aware cross-validation, with the scenario-specific user trajectory used as the grouping unit. Each candidate model was evaluated under a fixed hyperparameter budget of 15 trials. Out-of-fold predictions were used for Platt calibration, after which selected candidates were refit on the full soft-branch training subset and evaluated on the validation and test splits. Operating thresholds were selected on the validation soft branch using the shared recall– false-positive-rate (FPR) rule R0.10,1.00 , prioritizing soft-fraud recall subject to the legitimate-request FPR ceiling. This recalloriented selection was motivated by the imbalanced nature of telecom fraud detection, where minority-class fraud can be missed when models overfit the majority class [17]. No explicit class-reweighting strategy was imposed; imbalance was handled through the soft-branch formulation, calibrated scoring, and threshold-constrained validation selection. The candidate pool covered three model families: classical models including Logistic Regression (LR), Random Forest (RF), Adaptive Boosting (AdaBoost), Gradient Boosting Machine (GBM), Histogram-based Gradient Boosting Machine

8

(HistGBM), XGBoost, Light Gradient Boosting Machine (LightGBM), and Categorical Boosting (CatBoost); deep tabular models including Multilayer Perceptron (MLP), TabTransformer, and Feature Tokenizer Transformer (FT-Transformer); and sequence-inspired models including Convolutional Neural Network Only (CNNOnly), One-Dimensional Convolutional Neural Network (CNN1D), Long Short-Term Memory Only (LSTMOnly), Gated Recurrent Unit Only (GRUOnly), Convolutional Neural Network plus Long Short-Term Memory (CNNLSTM), Convolutional Neural Network plus Gated Recurrent Unit (CNNGRU), and Temporal Convolutional Network (TCN). Classical models and MLP used the dense transformed tabular representation, transformer-based tabular models used categorical-index and continuous-variable inputs, and sequence-inspired models used per-record feature vectors enriched with lag, rolling, transition, and profile descriptors. Ensemble search was restricted to a shortlisted pool of strong validation-side candidates. Three candidate forms were considered: retained single models, arithmetic probabilityaveraging ensembles, and stacked ensembles with a logisticregression meta-learner over base-model outputs. The final hybrid ensemble, denoted AVG6, was defined as an arithmetic average of six calibrated member-model probabilities from LightGBM, XGBoost, GBM, RF, MLP, and FT-Transformer. AVG6 was retained as the centralized soft-fraud scoring backbone for M1, while its member-model probability outputs formed the base-probability representation used by the federated meta-learner in M2. D. Shared Deployment-Stage Runtime Input All deployment-stage configurations follow the common decision formulation defined in Section III and consume the same unlabeled deployment runtime substrate prepared under the shared preprocessing and schema-alignment pipeline. The runtime records retain the operational variables required for inference together with traceability fields such as anonymized user identifiers, mapped Ethereum addresses, temporal descriptors, and selected record-level metadata. Fraud labels and target annotations are excluded from the runtime decision path and retained only in the auditable view for post-hoc evaluation. Downstream decision-input realization remains configuration-specific. Model-backed configurations use the corresponding saved preprocessing and model artifacts, while the LLM-family configuration processes the same records through the active M3 variant to generate frozen structured-artifact or sequence-classification risk outputs. The resulting configuration-specific outputs are then passed to the common policy-resolution and blockchain-linked execution stages. Under this design, M1, M2, and M3 share the same runtime substrate and audit pathway while differing only in the source of the non-hard fraud-risk signal.

out-of-boundary (OOB) policy used throughout the framework and ensured that clearly invalid requests were blocked through fixed operational rules rather than delegated to probabilistic inference. A request was assigned to the HARD_FRAUD path whenever at least one available critical operational variable violated its admissible synthetic operating boundary. In the retained deployment runtime substrate, the executable hard-gate inputs were latency, bandwidth, transmission power, signal strength, and usage duration. The hard-fraud decision was defined as the logical union of the available OOB conditions: latency > 110 ms, bandwidth > 100 Mbps, transmission power > 20 dBm, signal strength outside [−105, −25] dBm, or usage duration > 60 minutes. Violation of any available condition was sufficient to trigger deterministic blocking. Geographic validity was retained only as a source/audit-side OOB condition when raw latitude and longitude fields were available; in the retained deployment runtime file, the deployed hard-gate execution did not require raw coordinate columns. Geographic behavior nevertheless remained represented in the deployment substrate through derived distance, movement, and geo-history descriptors. The admissible ranges were defined as part of the controlled synthetic telecom environment used in this study and should be interpreted as design-specific synthetic operating boundaries rather than universal telecom engineering limits. During deployment-stage execution, hard-gate records were assigned to HARD_FRAUD rather than the non-hard probabilistic branch. During training-side validation/test reporting, the same OOB definition was applied as a final-policy override after probability export, keeping reported final-policy metrics consistent with the deployment rule. Under this policy, nominal and soft-fraud records were constrained to remain inside the admissible operating envelope, whereas hard-fraud records were required to violate at least one available OOB condition. The distinction was enforced during data validation before deployment-stage inference. F. M1: Centralized ML Risk Configuration M1 denotes the centralized ML-based risk configuration. Under M1, the configuration-specific non-hard fraud-risk signal was produced by the retained calibrated AVG6 ensemble obtained during training-side model development. The M1 scoring engine applied this frozen ensemble directly to the shared unlabeled deployment input defined in Section V-D; no online retraining or deployment-time model adaptation was performed. For non-hard requests, the resulting ensemble probability supplied the M1 risk signal, which was mapped into the common coarse decision states and resolved through the retained two-zone refinement mechanism. In the retained M1 implementation, the refinement representation reduced to the ensemble fraud-risk probability alone.

E. Shared Deterministic Hard-Fraud Gate and Policy Resolution

G. M2: Federated Meta-Learning Risk Configuration

Before probabilistic scoring, deployment requests were subjected to the shared deterministic hard-fraud gate used across M1–M3. The hard-fraud gate was aligned with the operational

M2 denotes the federated meta-learning risk configuration. Its methodological difference from M1 is the source of the non-hard fraud-risk signal: M2 replaces centralized ensemble

9

averaging with a federated meta-learning probability obtained from a simulated client-partitioned training setting. Federation was introduced at the meta-learning layer rather than at the level of the original telecom feature space. The retained calibrated base detectors were not retrained in an end-to-end federated manner; instead, they were treated as fixed probability generators, and a federated meta-learner was trained over the stacked probability representation formed from their outputs. M2 is a federated meta-learning configuration, not a fully federated end-to-end retraining pipeline. For training, the aligned base-model probability streams were partitioned into seven simulated device-type clients: customer-premises equipment (CPE), Internet of Things (IoT), drone, laptop, mobile, tablet, and vehicle. The meta-input consisted of six retained calibrated base-model probability streams generated by LightGBM, XGBoost, Gradient Boosting Machine, Random Forest, Multilayer Perceptron, and FTTransformer detectors. A logistic meta-classifier was trained over this stacked probability representation using a federated averaging-style procedure with 12 communication rounds, one local epoch per round, constant-learning-rate SGD with learning rate 0.01, and sample-size-weighted aggregation of local client updates. At deployment time, the saved federated meta-model was applied to the aligned stacked probability representation under the retained base-feature ordering, producing the M2 federated meta-probability used by the downstream policy layer. Ambiguous MAYBE_LOW and MAYBE_HIGH states were refined using validation-selected deployment-available descriptors derived from the retained base probability streams and the federated meta-probability. In the retained implementation, these refinement signals were probability-range and entropy descriptors. H. M3: LLM-Family Risk Configuration M3 denotes the LLM-family deployment configuration. Its methodological difference lies in the source of the non-hard fraud-risk signal, which is obtained from one of two LLM-family variants. M3-Base uses a locally served zero-shot Qwen3-8B instruction-following model to produce schema-constrained structured risk artifacts, whereas M3QLoRA uses a Qwen2.5-7B-Instruct model instantiated as an AutoModelForSequenceClassification model and adapted with QLoRA for binary sequence classification. Thus, M3-Base is a generative structured-artifact branch, while M3QLoRA is a fine-tuned LLM-based sequence-classification branch. In both variants, the LLM-family component supplies a retained non-hard fraud-risk probability and audit metadata; it does not directly produce the operational APPROVE/BLOCK action. 1) Deployment-Stage LLM-Family Risk-Signal Construction: Both M3-Base and M3-QLoRA use the same locked, leakage-filtered engineered input schema for LLM-family scoring. Deterministic hard-fraud/OOB records are not passed to the LLM scorer and are routed by the shared hard gate, while non-hard records are scored by the corresponding LLMfamily branch. Row labels, downstream scores, policy states,

final actions, and blockchain/execution fields are not used as LLM input features. In M3-Base, retained model-input fields are serialized as compact key–value feature text inside a schema-constrained zero-shot prompt. The raw response is constrained to a fraud-risk probability and short explanatory reasons, while confidence fields, parsing status, schema-validation status, fallback flags, and audit tags are derived or normalized in the artifact layer for downstream compatibility and audit. In M3-QLoRA, the same locked feature content is used as sequence-classification text input with labels LEGITIMATE and FRAUD; the retained risk signal is the softmaxnormalized probability of the fraud class. The sequence input used compact key–value feature pairs with maximum length 768 tokens, and the QLoRA configuration used 4-bit NF4 quantization with double quantization and bfloat16 computation, with adapters attached to Qwen-family attention and MLP projection modules. Deployment-stage inference was performed using the retained local base model, tokenizer, and QLoRA adapter artifacts. 2) Validation, Reliability, and Policy Use: The reliability procedure is variant-specific. For M3-Base, generated responses must satisfy the expected structured-output schema; invalid JSON, missing fields, invalid probability/confidence values, incorrect batch lengths, or parsing failures trigger retries within a fixed retry budget, followed by conservative fallback artifacts when needed. For M3-QLoRA, no freeform JSON is generated; reliability handling focuses on rowindex alignment, hard/non-hard masking consistency, probability bounds, artifact length consistency, and inference status. In both variants, the retained probability is treated as the M3 nonhard fraud-risk signal and passed to the shared policy layer for state mapping and two-zone refinement. I. Shared Blockchain Execution and Audit Layer To support auditable runtime handling, the proposed framework was integrated with a local Ethereum-compatible blockchain layer. The audit layer did not perform fraud detection itself; instead, it provided a shared execution and audit substrate through which already-formed off-chain decisions were registered, reflected in request state, and traced during deployment-time operation. Thus, differences across configurations arise from the configuration-specific non-hard risk signal and retained policy artifacts rather than from changes in the blockchain substrate. The shared audit layer was implemented on a local Ethereum-compatible Ganache test chain using a Solidity smart contract, Remix-based contract development, and Web3.py over HTTP RPC. The local chain provided 1,000 unlocked accounts, from which five were authorized as decisionwriting validators. Deployment records were deterministically mapped to blockchain accounts through a one-to-one anonymized user-to-address mapping over 1,000 deployment users. The contract supported request submission, off-chain decision logging, optional review resolution, approved-request finalization, and request-state retrieval. User accounts were restricted to request-side actions, while authorized validators recorded off-chain decisions and resolved

10

review-stage cases. Fraud labels were excluded from the inference path and retained only for post-hoc audit. The implementation kept off-chain decision formation separate from on-chain execution and audit. The implementation artifacts, including data-generation scripts, model/artifact builders, Solidity source, compiled ABI, bytecode, and Web3 execution notebooks, are available in the project repository. J. Blockchain-Linked Execution Modes and Run-Isolation Protocol The shared blockchain layer defined in Section V-I was evaluated under five consensus-inspired validator-assignment modes over the same local Ethereum-compatible substrate. The modes varied only validator-selection logic while keeping the Ganache environment, smart contract, Web3 interface, and lifecycle execution path unchanged. PoS used predefined stake-weighted validator selection, PoW used stochastic selection from the authorized validator set, PoA used deterministic round-robin assignment, DPoS selected the highest-vote delegated validator from a predefined vote-allocation profile, and PBFT used deterministic rotating-primary assignment. These modes should be interpreted as controlled validatorassignment policies, not as native implementations of full consensus protocols. Each run used a fresh contract deployment, validator reauthorization, and run-specific output files to avoid crossrun state carryover. All modes followed the same contract path: requestSpectrum, recordAIDecision, optional resolveReview for MAYBE_LOW or MAYBE_HIGH, and finalizeRequest for approved requests only. The protocol was applied after the off-chain decision state, final action, and audit payload had been produced by Algorithm 1; the blockchain layer only recorded the already produced offchain decision, applied the corresponding request-lifecycle operations, and stored execution telemetry for post-hoc audit. VI. R ESULTS A. Training-Side Backbone Selection and Risk-Artifact Readiness Before deployment-stage comparison, the statistical backbones and LLM-family artifacts were checked under the shared alignment protocol. Operating thresholds were selected on the validation soft branch to maximize soft-fraud recall subject to the 10% nominal-row FPR ceiling. Threshold-only performance refers to the learned model operating point before the deterministic OOB override, whereas final-policy performance refers to the same threshold after applying the OOB override. The results in this subsection support artifact selection and readiness; deployment replay results for M1, M2, M3-Base, and M3-QLoRA are reported in Section VI-B. The training-side screening compared classical ML, deep tabular, and sequence-inspired candidates under the shared validation-led operating rule. Boosted-tree models formed the strongest standalone group for soft-fraud scoring, while neural tabular models were retained mainly for ensemble diversity. Final-policy hard-fraud recall was not treated as a sufficient

TABLE V

VALIDATION - SELECTED TRAINING - SIDE BACKBONE CANDIDATES Candidate

Method

Composition

Best single Best stack

Single Stacking

Final backbone

Averaging

LightGBM HistGBM + GBM + LR + FT-Transformer LightGBM + XGBoost + GBM + RF + MLP + FTTransformer

Val. soft recall Test soft recall 0.8251 0.8341

0.7926 0.7926

0.8386

0.8029

model-selection criterion, since hard-fraud cases were protected by the deterministic OOB override. Validation soft-fraud recall under the FPR-constrained operating rule remained the primary selection signal. Ensemble candidates were evaluated under the same validation-led threshold policy. The best validation-selected single model was LightGBM. The strongest stacked model improved validation soft recall but did not improve heldout soft recall over LightGBM. The selected training-side ML backbone was the six-model averaging ensemble AVG6, composed of LightGBM, XGBoost, GBM, Random Forest, MLP, and FT-Transformer. As summarized in Table V, AVG6 achieved the highest validation soft-fraud recall among the retained final candidates and improved held-out soft-fraud recall over the validation-selected single-model baseline while preserving full final-policy hard-fraud recall. Although CatBoost produced the highest held-out softfraud recall among individual models, it was not selected as the primary validation-selected single-model baseline because model selection was governed strictly by validation evidence. AVG6 was retained for deployment-stage evaluation: in M1, it is used directly as the non-hard risk-signal generator; in M2, its member-model probability outputs provide the baseprobability representation for federated meta-learning. The statistical-learning deployment artifacts produced aligned probability outputs for the full 100,000-record deployment corpus. For M1, the AVG6 artifact contained the ensemble probability, validation-selected threshold, deterministic OOB indicator, threshold-only prediction, and finalpolicy prediction. The artifact contained no missing values, with 95,500 non-OOB records and 4,500 OOB records, and the final-policy prediction matched the logical union of the threshold decision and the OOB rule. For M2, the federated meta-learning artifact pipeline produced aligned validation and deployment probability outputs over the same six retained base-detector probability streams used by AVG6. For M3-Base, the retained zero-shot artifact pipeline produced structured risk artifacts for the non-hard branch, with parsing, validation, fallback, and audit-status fields retained as metadata for downstream policy execution. For M3-QLoRA, the retained sequence-classification branch was trained on the non-hard branch after removing deterministic OOB hardfraud rows. It used Qwen2.5-7B-Instruct with QLoRA adapters and produced a softmax-derived fraud-class probability signal. The artifact builder produced aligned train and validation outputs with no fallback cases. In the training split, 17,749 non-hard records were scored and 1,151 OOB records were routed to the deterministic hard-fraud gate; in the validation split, the corresponding counts were 2,538 and 162. These

11

artifacts confirm the intended separation between deterministic hard-fraud handling and QLoRA-based non-hard risk scoring. Final validation and labeled-deployment replay performance is reported together with M1, M2, M3-Base, and M3-QLoRA in Section VI-B. B. Deployment-Stage Results for Off-Chain Risk Configurations This subsection reports the off-chain deployment results under the common runtime layer, deterministic hard-fraud gate, five-state policy, two-zone refinement mechanism, and blockchain-linked execution pathway. M1 uses the AVG6 ensemble score, M2 uses a federated meta-learner over retained base-detector probabilities, and M3 is evaluated through two LLM-family variants: zero-shot structured artifacts in M3Base and QLoRA-tuned sequence-classification probabilities in M3-QLoRA. This comparison isolates how different nonhard risk backbones behave under the same downstream decision logic. 1) Risk-Score Distributions and Retained Operating Profiles: The deterministic hard-fraud gate assigned 4,500 of the 100,000 deployment records, corresponding to 4.5%, directly to the blocking path for all off-chain configurations. The remaining 95,500 non-hard requests, corresponding to 95.5%, were passed to the configuration-specific risk scorer. For M1, the retained AVG6 ensemble probability had a mean of 0.073620, a standard deviation of 0.094921, a minimum of 0.006870, and a maximum of 0.987308. For M2, the federated meta-learning probability had a mean of 0.068554, a standard deviation of 0.125094, a minimum of 0.023868, and a maximum of 0.995749. For M3-Base, the zero-shot non-hard artifact probability had a mean of 0.275786, a standard deviation of 0.174389, a minimum of 0.050000, and a maximum of 0.850000. For M3-QLoRA, the QLoRA fraudclass softmax probability had a mean of 0.011354, a standard deviation of 0.097083, a minimum of 6.16 × 10−12 , and a maximum of 1.000000. The retained operating profiles are summarized in Table VI. M1 used the centralized AVG6 ensemble probability and refined ambiguous requests using the ensemble fraud-risk probability. M2 used the federated meta-learning probability and refined ambiguous requests using probability-dispersion descriptors. Within the M3 family, M3-Base used the zero-shot structured-artifact probability with a mild OOB refinement signal, whereas M3-QLoRA used the QLoRA fraud-class softmax probability with probability, confidence, and mildOOB refinement signals. In Table VI, b1 /b2 /b3 denotes the retained coarse-state boundaries for the NO, MAYBE_LOW, MAYBE_HIGH, and YES mapping defined in Section III; the low and high thresholds are the refinement cutoffs used inside MAYBE_LOW and MAYBE_HIGH. Table VI shows that the four configurations retained substantially different score-to-policy mappings under the same validation-led operating rule. M1 retained a comparatively moderate set of coarse-state boundaries, consistent with its calibrated ensemble probability distribution. M2 used a lower NO boundary and a broader refinement-sensitive region, reflecting the sharper dispersion of the federated meta-probability

TABLE VI

R ETAINED DEPLOYMENT POLICY VALUES FOR THE OFF - CHAIN RISK CONFIGURATIONS Config.

b1 /b2 /b3

M1 0.1053 / 0.2647 / 0.5717 M2 0.0463 / 0.1255 / 0.6249 M3-Base 0.2000 / 0.3750 / 0.6500 M3-QLoRA 0.0004 / 0.0054 / 0.9408

Low threshold High threshold 0.1116 0.0966 0.1669 0.1082

0.3978 0.2721 0.2138 0.2907

Fig. 2. Deployment decision-state and outcome profiles across off-

chain risk configurations. (a) Percentage and count of deployment requests assigned to each decision state under M1, M2, M3-Base, and M3-QLoRA. (b) Corresponding final operational outcomes. Percentages are computed over the full 100,000-record deployment replay.

signal. M3-Base retained more discrete and higher zero-shot probability boundaries, which is consistent with the coarser probability granularity of the structured LLM artifacts. M3QLoRA retained a very low NO/MAYBE_LOW boundary and a high direct-YES boundary, indicating that most non-hard requests were separated into low-risk or refinement-mediated regions rather than directly assigned to the highest-risk state. These differences confirm that the shared policy layer does not force the configurations into an identical decision profile; instead, it exposes how each risk source behaves under the same deployment-stage decision-management protocol. 2) Deployment Decision-State Profiles: Fig. 2 summarizes the deployment decision-state and outcome profiles over the full 100,000-record deployment run. Panel (a) reports the percentage and count of requests assigned to each decision state, while Panel (b) reports the corresponding final operational outcomes. M3-Base produced the most aggressive blocking profile, whereas M3-QLoRA moved the LLM-family deployment profile closer to M1 and M2. As shown in Fig. 2(a), the shared hard-fraud gate fixes the HARD_FRAUD count across all configurations, so the observed differences arise from the non-hard risk signal and the subsequent two-zone policy resolution. M1 produces the least disruptive blocking profile, while M2 shifts more nonhard cases toward review-mediated or blocking outcomes. M3Base is substantially more aggressive and routes a large share

12

Fig. 3. Pairwise blocked-request-set overlap across deployment con-

figurations. Each bar reports the Jaccard overlap, 100 × |Bi ∩ Bj |/|Bi ∪ Bj |, between the requests blocked by two configurations. The percentages measure similarity between blocked-request sets, not the percentage of all deployment requests that were blocked.

of non-hard cases into MAYBE_HIGH, indicating that zeroshot structured LLM probabilities are less suitable as direct operational risk scores in this deployment setting. By contrast, M3-QLoRA brings the LLM-family deployment profile much closer to the statistical-learning configurations, supporting the interpretation that supervised QLoRA sequence classification provides a more operationally usable LLM-family risk signal than zero-shot structured prompting. Fig. 2(b) further shows how these state profiles translate into final operational outcomes. M3-Base reaches the highest block rate at 42.07%, while M1, M2, and M3-QLoRA remain closer to each other, with block rates of 20.56%, 23.23%, and 22.03%, respectively. This confirms that the aggressive M3Base state distribution directly increases operational disruption, whereas M3-QLoRA preserves a more balanced outcome profile. Beyond aggregate block rates, Fig. 3 compares the blockedrequest sets produced by different deployment configurations. The reported value is the Jaccard overlap between two blocked-request sets, defined as |Bi ∩Bj |/|Bi ∪Bj |, where Bi and Bj denote the requests blocked by configurations i and j, respectively. Higher values indicate that two configurations block more similar request subsets, rather than blocking a larger fraction of all deployment requests. The highest overlap is observed between M1 and M2, indicating that the centralized ML and federated meta-learning configurations block largely similar request subsets under the shared policy layer. M3-QLoRA shows intermediate overlap with M1 and M2, whereas M3-Base has lower overlap with the statistical-learning configurations. This indicates that the more aggressive blocking behavior of M3-Base is not merely a higher-volume version of the M1/M2 profile, but reflects a different blocked-request subset. 3) Validation and Labeled-Deployment Replay: Table VII summarizes the validation and supplementary labeleddeployment replay results. The deployment decision-state profile in Fig. 2 is reported over the full 100,000-record runtime corpus, whereas the labeled-deployment replay in Table VII is reported over 99,996 matched records after the supplemen-

tary label-alignment step. The validation rows contain 2,700 records, and the low and high refinement thresholds are those reported in Table VI. Since deterministic hard-fraud cases are captured by the shared hard-fraud gate, final-policy hard-fraud recall is 1.0000 for all rows and is omitted from the table. Table VII shows the validation and labeled-deployment replay trade-offs behind the deployment profiles. The deployment-side FPR values exceed the validation-side 0.10 operating cap for several configurations because the cap was used only for validation-time operating selection, whereas the labeled deployment replay reflects an independent drifted corpus with different fraud prevalence and hard/soft composition.These values should be interpreted as deployment-drift effects rather than validation-rule violations. On validation, M1 provides the strongest overall balance among the retained configurations, achieving the highest precision, the lowest legitimate-request FPR, and full final-policy hard-fraud recall. M2 matches M1 in validation soft-fraud recall but does so with lower precision and a higher legitimaterequest FPR, indicating a more recall-oriented but more disruptive operating profile. On the labeled deployment replay, M2 obtains the highest soft-fraud recall, but this improvement is accompanied by the highest legitimate-request FPR among M1, M2, and M3-QLoRA. M3-Base performs weakest within the LLM family: its validation soft-fraud recall is substantially lower and its deployment legitimate-request FPR is markedly higher, confirming the aggressive blocking pattern observed in Fig. 2. M3-QLoRA substantially improves over M3-Base by increasing validation soft-fraud recall, reducing deployment legitimate-request blocking, and moving the LLM-family profile closer to the statistical-learning configurations. Overall, the results reveal a clear deployment-stage trade-off: M2 provides the strongest soft-fraud recall on labeled deployment replay, M1 provides the most balanced validation-side profile, and M3-QLoRA is the more viable LLM-family option compared with zero-shot M3-Base. 4) Diagnostic Soft-Fraud Complexity Recall: Table VIII complements the aggregate soft-fraud recall values reported in Table VII by decomposing the labeled soft-fraud subset according to component complexity. Since deterministic hardfraud cases are fully captured by the hard-fraud gate across all evaluated configurations, the diagnostic view focuses on soft-fraud cases, where the remaining false negatives occur. The labeled soft-fraud replay subset contains 166 singlecomponent, 167 double-component, and 167 triple-component soft-fraud requests. Across configurations, missed soft-fraud cases are concentrated mainly in lower-complexity soft-fraud requests, while triple-component soft-fraud cases are generally recovered with higher recall. The rows in Table VIII partition the labeled soft-fraud subset by the number of fraud components. This diagnostic view explains why aggregate soft-fraud recall remains lower than hard-fraud recall: the most difficult cases are lower-signal, single-component soft-fraud requests. M1 and M2 recover double- and triple-component soft-fraud cases most strongly, while M3-Base remains weaker on higher-complexity softfraud cases despite recovering more single-component cases than the statistical-learning configurations. M3-QLoRA im-

13

TABLE VII

VALIDATION AND LABELED - DEPLOYMENT REPLAY RESULTS FOR M1, M2, M3-BASE , AND M3-QL O RA Config.

Evaluation set

M1 M1

Validation Labeled deployment play Validation Labeled deployment play Validation Labeled deployment play Validation Labeled deployment play

M2 M2 M3-Base M3-Base M3-QLoRA M3-QLoRA

Precision Recall

F1

F2

Soft recall Legit. FPR Legit. blocked Total errors

re-

0.6282 0.2390

0.9039 0.7412 0.8309 0.9830 0.3845 0.6058

0.8341 0.8300

0.0890 0.1646

206 15,641

243 15,726

re-

0.6031 0.2117

0.9039 0.7235 0.8219 0.9838 0.3484 0.5689

0.8341 0.8380

0.0989 0.1927

229 18,305

266 18,386

re-

0.5130 0.1159

0.6130 0.5586 0.5900 0.9756 0.2072 0.3928

0.3318 0.7560

0.0968 0.3915

224 37,192

373 37,314

re-

0.6029 0.2229

0.8753 0.7140 0.8028 0.9824 0.3634 0.5843

0.7848 0.8240

0.0959 0.1801

222 17,114

270 17,202

TABLE VIII

D IAGNOSTIC SOFT- FRAUD COMPLEXITY RECALL ON THE LABELED DEPLOYMENT REPLAY Config.

Soft-fraud slice

TP FN Recall

M1 M1 M1

Single-component 107 Double-component 144 Triple-component 164

59 0.6446 23 0.8623 3 0.9820

M2 M2 M2

Single-component 108 Double-component 147 Triple-component 164

58 0.6506 20 0.8802 3 0.9820

M3-Base M3-Base M3-Base

Single-component 111 Double-component 122 Triple-component 145

55 0.6687 45 0.7305 22 0.8683

M3-QLoRA Single-component 116 M3-QLoRA Double-component 138 M3-QLoRA Triple-component 158

50 0.6988 29 0.8263 9 0.9461

proves over M3-Base across all complexity slices and narrows the gap to M1 and M2, especially for double- and triplecomponent soft fraud. Fig. 4 further decomposes missed soft-fraud cases according to the fraud-injection taxonomy in Table IV. Unlike the complexity-level diagnostic table, this component-level view identifies which soft-fraud realizations are more frequently missed by each deployment configuration. The horizontal axis reports a component-level false-negative rate, not an overall deployment FPR or block-rate value. The results indicate that missed soft-fraud cases are not uniformly distributed across fraud types: spoofed-location and bandwidth-spike realizations remain comparatively difficult across configurations, while M3-Base shows higher miss rates for several components, including high-power usage, long-duration usage, latency spike, and off-hour activity. C. Shared Blockchain-Linked Execution Results Across Deployment Configurations Using the shared blockchain-linked execution substrate and run-isolated execution modes defined in Sections V-I and V-J, this subsection reports the observed execution telemetry for the retained off-chain deployment policies. The blockchain layer did not generate fraud decisions; it recorded already-formed off-chain actions under the common request-submission, decision-recording, optional review-resolution, and approvedrequest finalization workflow. Thus, differences in the reported

Fig. 4. Component-level soft-fraud miss profile on the labeled deployment replay. Each point reports the component-level false-negative rate, computed as the percentage of soft-fraud requests containing the corresponding component that were incorrectly approved by a deployment configuration. The value n denotes the number of soft-fraud requests containing that component; multicomponent soft-fraud requests may contribute to more than one row. These percentages are component-level miss rates, not overall deployment FPR or block-rate values.

execution outcomes reflect the submitted off-chain decision profiles rather than changes in the blockchain substrate. 1) Lifecycle Realization and Execution Integrity: Fig. 5 summarizes the request-lifecycle workload for the completed deployment configurations. All completed lifecycle runs use the same five validator-assignment modes, namely PoS, PoW, PoA, DPoS, and PBFT. For each completed configuration and validator-assignment mode, 100,000 managed fraud-control requests are submitted and 100,000 off-chain decisions are logged. The reported lifecycle counts are per validatorassignment mode and are identical across the five modes within a given configuration. All four deployment configurations executed the corresponding off-chain decision profiles without lifecycle execution failures. For the completed runs, the lifecycle counts are consistent with the off-chain deployment decision profiles reported in Fig. 2. As shown in Fig. 5, the number of review transactions equals the number of requests routed to MAYBE_LOW or MAYBE_HIGH, and the number of finalization transactions equals the number of approved requests. M3-Base induces the

14

Fig. 5. Blockchain-linked lifecycle workload per validator-assignment

mode. The bars report review-resolution, approved-request finalization, and blocked-request retention counts for each deployment configuration.

largest review workload because many non-hard requests are routed to MAYBE_HIGH, whereas M3-QLoRA produces a lifecycle footprint closer to M1 by reducing the LLM-family review and blocking burden. The corresponding total on-chain operation counts per validator-assignment mode are 295,503 for M1, 300,206 for M2, 296,449 for M3-Base, and 295,555 for M3QLoRA. These totals are derived from the common lifecycle path: 100,000 request-submission transactions, 100,000 off-chain decision-log transactions, the configuration-specific review-resolution transactions, and the configuration-specific approved-request finalization transactions. Rows marked as BLOCKED_REQUEST are not treated as failed rows; they correspond to requests intentionally retained in a non-finalized state after an off-chain BLOCK decision. Across the completed runs, all recorded transaction hashes were unique within the executed lifecycle operations, and no failure reason was recorded. 2) Gas, Latency, and Throughput Telemetry: Table IX reports gas, latency, and throughput telemetry for the completed blockchain-linked execution runs. Each telemetry row corresponds to 100,000 deployment requests; the request-count column is omitted. Within each configuration, the gas footprint is nearly identical across validator-assignment modes because the same smart-contract functions and request lifecycle are executed under each mode. Across configurations, gas and latency differences mainly reflect the number of review-stage and finalization transactions induced by the submitted offchain decision profile. The observed throughput differences reflect local execution behavior under the tested validatorassignment policies. The mean gas per request remains nearly constant across validator-assignment modes within each configuration, confirming that the execution mode changes validator assignment and local timing behavior rather than the smart-contract lifecycle itself. Across configurations, M3-Base has the largest gas footprint because it induces the largest review workload, whereas M3-QLoRA reduces the LLM-family lifecycle cost and moves the gas profile closer to the statistical-learning configurations. The M1 runs achieve the highest throughput because they require fewer lifecycle operations, while M3-Base

and M3-QLoRA show lower throughput under the completed local execution runs. These values should be interpreted as execution-mode telemetry within the controlled local substrate, not as a claim about the performance of native PoS, PoW, PoA, DPoS, or PBFT consensus implementations. 3) Validator-Assignment Behavior: Table X summarizes validator-assignment behavior across the completed blockchain-linked execution runs. All completed rows correspond to 100,000 runtime requests over five authorized validators; the request-count column is omitted and validator participation is implied by the number of active validators. The assignment statistics show how the consensus-inspired execution modes changed validator selection while the smart contract, Web3 interface, request lifecycle, and off-chain decision profile for each configuration remained fixed. In Table X, HHIPdenotes the Herfindahl–Hirschman Index, defined as HHI = j p2j , where pj is the share of assignments handled by validator j. Lower HHI values indicate more balanced validator participation, whereas values closer to one indicate stronger concentration. The validator-assignment pattern is mode-driven rather than risk-source-driven. The PoA- and PBFT-inspired modes produced balanced validator assignment across the five authorized validators, while the PoW-inspired mode produced an approximately uniform stochastic distribution. The PoS-inspired mode reflected the predefined stake-weighted assignment profile, and the DPoS-inspired mode routed all decisions through the delegated validator. The same assignment pattern is preserved across M1, M2, M3-Base, and M3-QLoRA, confirming that the execution modes changed validator-assignment behavior while preserving the same request-lifecycle execution pathway. VII. D ISCUSSION A. Risk-Source Trade-Offs and Soft-Fraud Behavior The results show that the proposed framework should be interpreted as a deployment-stage decision-management system rather than as a standalone fraud classifier. Since M1, M2, M3-Base, and M3-QLoRA share the same runtime substrate, deterministic hard-fraud gate, five-state policy, twozone refinement mechanism, and blockchain-linked execution pathway, the observed differences mainly reflect the behavior of the non-hard risk signal supplied by each configuration. The deterministic hard-fraud gate stabilizes explicit operational-violation handling across configurations. The remaining challenge is concentrated in the non-hard branch, especially soft-fraud cases that remain inside the admissible operating envelope. M1 provides the most balanced statisticallearning profile, M2 shifts the operating point toward stronger soft-fraud recovery with higher disruption and review workload, and M3-Base produces a more aggressive and less calibrated LLM-family profile. M3-QLoRA improves over M3Base by using supervised sequence-classification probabilities and moves the LLM-family deployment profile closer to the statistical-learning configurations. The soft-fraud diagnostics show that residual errors are concentrated mainly in lower-signal soft-fraud cases. Singlecomponent soft-fraud requests are generally more difficult

15

TABLE IX

B LOCKCHAIN - LINKED RUNTIME TELEMETRY ACROSS DEPLOYMENT CONFIGURATIONS AND VALIDATOR - ASSIGNMENT MODES Config.

Mode Duration (s) Requests/s Operations/s Avg latency/request (ms) Avg gas/request Total runtime gas

M1 M1 M1 M1 M1

PoS PoW PoA DPoS PBFT

13,619.27 14,388.05 15,247.23 16,136.17 16,201.28

7.34 6.95 6.56 6.20 6.17

21.70 20.54 19.38 18.31 18.24

116.01 123.35 131.04 138.62 139.57

1,252,779 1,252,780 1,252,782 1,252,786 1,252,787

125,277,937,477 125,277,957,089 125,278,228,677 125,278,575,877 125,278,679,477

M2 M2 M2 M2 M2

PoS PoW PoA DPoS PBFT

26,530.09 18,535.00 20,049.55 21,132.02 21,974.84

3.77 5.40 4.99 4.73 4.55

11.32 16.20 14.97 14.21 13.66

227.92 160.80 174.14 184.23 191.96

1,293,836 1,293,805 1,293,808 1,293,814 1,293,819

129,383,616,244 129,380,488,676 129,380,787,856 129,381,351,424 129,381,937,320

M3-Base M3-Base M3-Base M3-Base M3-Base

PoS PoW PoA DPoS PBFT

32,826.93 28,835.07 30,776.85 31,877.68 32,849.08

3.05 3.47 3.25 3.14 3.04

9.03 10.28 9.63 9.30 9.02

285.60 249.18 267.17 276.89 283.20

1,373,425 1,373,406 1,373,416 1,373,422 1,373,430

137,342,479,103 137,340,605,919 137,341,586,359 137,342,229,183 137,342,951,035

M3-QLoRA M3-QLoRA M3-QLoRA M3-QLoRA M3-QLoRA

PoS PoW PoA DPoS PBFT

34,166.08 32,510.57 36,374.00 29,390.55 30,861.88

2.93 3.08 2.75 3.40 3.24

8.65 9.09 8.13 10.06 9.58

292.74 278.85 311.85 249.93 264.80

1,261,142 1,261,138 1,261,148 1,261,130 1,261,133

126,114,235,621 126,113,761,277 126,114,793,185 126,113,001,309 126,113,253,717

TABLE X

VALIDATOR - ASSIGNMENT BEHAVIOR ACROSS CONFIGURATIONS AND EXECUTION MODES Config.

Mode Active validators Top share

HHI

M1 M1 M1 M1 M1

PoS PoW PoA DPoS PBFT

5 5 5 1 5

0.3355 0.2011 0.2000 1.0000 0.2000

0.2449 0.2000 0.2000 1.0000 0.2000

M2 M2 M2 M2 M2

PoS PoW PoA DPoS PBFT

5 5 5 1 5

0.3335 0.2014 0.2000 1.0000 0.2000

0.2447 0.2000 0.2000 1.0000 0.2000

M3-Base M3-Base M3-Base M3-Base M3-Base

PoS PoW PoA DPoS PBFT

5 5 5 1 5

0.3366 0.2019 0.2000 1.0000 0.2000

0.2450 0.2000 0.2000 1.0000 0.2000

M3-QLoRA M3-QLoRA M3-QLoRA M3-QLoRA M3-QLoRA

PoS PoW PoA DPoS PBFT

5 5 5 1 5

0.3333 0.2015 0.2000 1.0000 0.2000

0.2448 0.2000 0.2000 1.0000 0.2000

because they contain fewer coordinated suspicious indicators, whereas double- and triple-component cases provide stronger combined evidence for the policy layer. The component-level miss profile further indicates that missed soft-fraud cases are not uniformly distributed across the fraud taxonomy, motivating targeted feature construction and refinement logic for difficult component types. B. Blockchain-Linked Execution Implications The blockchain-linked layer provides lifecycle traceability rather than fraud intelligence. It records already-formed off-chain decisions, review resolutions, finalization events, blocked-request retention, validator assignment, and execution telemetry. Differences in lifecycle cost, gas, latency,

and throughput are consequences of the submitted off-chain decision profiles rather than evidence that the blockchain layer changed the fraud decision. The lifecycle and runtime telemetry show that configurations producing more review-stage cases or different approval/blocking profiles induce different execution costs. M3-Base creates the heaviest review burden, while M3QLoRA reduces the LLM-family lifecycle footprint and moves closer to the statistical-learning configurations. The validatorassignment results further show that validator behavior is mode-driven rather than risk-source-driven, supporting the interpretation of the execution modes as controlled validatorassignment policies over a shared local blockchain substrate.

C. Limitations and Future Directions This study uses controlled synthetic corpora rather than real operator traffic. The synthetic design enables repeatable fraud injection, hard/soft separation, leakage-aware preprocessing, controlled drift, and auditability, but it cannot capture all behavioral, commercial, regulatory, and adversarial properties of real telecom networks. The blockchain evaluation is also conducted on a local Ethereum-compatible test chain with consensus-inspired validator-assignment modes; the reported telemetry should be interpreted as controlled execution evidence rather than measurements of native production-grade consensus systems. Future work should evaluate the framework on operatorsupported or more realistic telecom datasets, extend deployment replay toward online and streaming operation, add drift monitoring and recalibration mechanisms, and study privacypreserving audit designs. Further extensions may also integrate graph-based coordinated-fraud signals, richer LLM adaptation strategies, and larger-scale blockchain deployments with more realistic validator and network conditions.

16

VIII. C ONCLUSION This paper presented a blockchain-linked auditable decisionmanagement framework for telecom/IoT fraud-control requests under a controlled synthetic deployment-replay evaluation. The framework treats fraud control as an auditable request-resolution problem that combines a shared runtime substrate, deterministic hard-fraud gate, five-state policy, twozone refinement, and blockchain-linked audit pathway rather than as a standalone classification task. The results show that M1 provided the strongest overall statistical-learning baseline, while M2 improved soft-fraud recovery at the cost of higher legitimate-request disruption and review workload. M3-Base exposed the risk of using zeroshot structured LLM probabilities as direct operational risk scores, whereas M3-QLoRA provided a substantially more usable LLM-family signal by reducing the large false-positive burden of the zero-shot branch. However, M3-QLoRA mainly narrowed the gap to the lower-cost centralized ensemble rather than outperforming it. The deployment replay also showed a clear legitimate-request FPR gap relative to the validation operating cap, so the results should be interpreted as controlled drift-replay evidence rather than field validation in a live operator network. Blockchain execution confirmed that lifecycle workload, gas, latency, and throughput are driven by submitted off-chain decision profiles, while validator-assignment behavior is mainly determined by the selected execution mode. ACKNOWLEDGMENT This work was supported by the Engineering and Physical Sciences Research Council under grant EP/Y035534/1. R EFERENCES [1] G. Chu, J. Wang, Q. Qi, H. Sun, S. Tao, H. Yang, J. Liao, and Z. Han, “Exploiting spatial-temporal behavior patterns for fraud detection in telecom networks,” IEEE Transactions on Dependable and Secure Computing, vol. 20, no. 6, pp. 4564–4577, Nov./Dec. 2023. [2] Communications Fraud Control Association, “Telecommunications fraud increased 12% in 2023 equating to an estimated $38.95 billion lost to fraud,” https://cfca.org/telecommunications-fraud-increased12-in-2023-equating-to-an-estimated-38-95-billion-lost-to-fraud/, Nov. 2023, accessed: 15 May 2026. [3] Transaction Network Services, “The telecom fraud landscape in 2026: How the industry is fighting back,” https://tnsi.com/resource/com/thetelecom-fraud-landscape-in-2026-how-the-industry-is-fighting-backblog/, Jan. 2026, accessed: 8 June 2026. [4] A. Balouchi, M. Abdollahi, A. Eskandarian, K. K. Pour Kerman, E. Majd, N. Azouji, and A. Baniasadi, “Wangiri fraud detection: A comprehensive approach to unlabeled telecom data,” Future Internet, vol. 18, no. 1, p. 15, 2026. [5] C.-X. Wang, X. You, X. Gao, X. Zhu, Z. Li, C. Zhang, H. Wang, Y. Huang, Y. Chen, H. Haas, J. S. Thompson, E. G. Larsson, M. Di Renzo, W. Tong, P. Zhu, X. Shen, H. V. Poor, and L. Hanzo, “On the road to 6G: Visions, requirements, key technologies, and testbeds,” IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 905–974, 2023. [6] S. S. Sefati, A. Ul Haq, Nidhi, R. Craciunescu, S. Halunga, A. Mihovska, and O. Fratu, “A comprehensive survey on resource management in 6G network based on Internet of Things,” IEEE Access, vol. 12, pp. 113 741–113 784, 2024. [7] E. Edozie, A. N. Shuaibu, B. O. Sadiq, and U. K. John, “Artificial intelligence advances in anomaly detection for telecom networks,” Artificial Intelligence Review, vol. 58, no. 4, p. 100, 2025. [8] R. Wu and E. J. Keogh, “Current time series anomaly detection benchmarks are flawed and are creating the illusion of progress,” IEEE Transactions on Knowledge and Data Engineering, vol. 35, no. 3, pp. 2421–2429, Mar. 2023.

[9] M. M. Sesay, “Leakage-aware benchmarking of temporal data preparation for hourly energy forecasting,” Energy Conversion and Management: X, vol. 30, p. 101791, 2026. [10] K. Kotowski, C. Haskamp, J. Andrzejewski, B. Ruszczak, J. Nalepa, D. Lakey, P. Collins, A. Kolmas, M. Bartesaghi, J. Martinez-Heras, and G. De Canio, “European space agency benchmark for anomaly detection in satellite telemetry,” arXiv preprint arXiv:2406.17826, 2024, revised 2025. [11] J. Wu, R. Hu, D. Li, L. Ren, Z. Huang, and Y. Zang, “Beyond the individual: An improved telecom fraud detection approach based on latent synergy graph learning,” Neural Networks, vol. 169, pp. 20–31, Jan. 2024. [12] K. Hasan, M. N. Hosen, and K. Saha, “Federated learning for telecom fraud detection: A privacy-preserving approach to overcoming data fragmentation and enhancing security,” European Journal of Theoretical and Applied Sciences, vol. 2, no. 6, pp. 99–109, Nov. 2024. [13] J. Ding and H. Zhou, “Telecom fraud detection based on large language models: A multi-role, multi-layer prompting strategy,” Applied Sciences, vol. 16, no. 1, p. 544, Jan. 2026. [14] Q. Mamun, Z. Pan, and J. Wu, “Blockchain in communication networks: A comprehensive review,” IET Blockchain, vol. 6, no. 1, p. e70031, Jan. 2026. [15] S. Changizi, N. Mohammadzadeh, and M. Shojafar, “Hybrid telecom fraud detection with machine learning, large language models, and blockchain,” in Proceedings of the 2025 IEEE International Conference on High Performance Computing and Communications (HPCC), 2025, pp. 1094–1102. [16] Y. Jiang, G. Liu, J. Wu, and H. Lin, “Telecom fraud detection via Hawkes-enhanced sequence model,” IEEE Transactions on Knowledge and Data Engineering, 2022, early access. [17] X. Hu, H. Chen, J. Zhang, H. Chen, S. Liu, X. Li, Y. Wang, and X. Xue, “GAT-COBO: Cost-sensitive graph neural network for telecom fraud detection,” IEEE Transactions on Big Data, vol. 10, no. 4, pp. 528–542, Aug. 2024. [18] F. Michelinakis, J. S. Pujol-Roig, S. Malacarne, M. Xie, T. Dreibholz, S. Majumdar, W. Y. Poe, G. Patounas, C. Guerrero, A. Elmokashfi, and V. Theodorou, “Ai anomaly detection for cloudified mobile core architectures,” IEEE Transactions on Network and Service Management, vol. 20, no. 2, pp. 1976–1992, Jun. 2023. [19] M. Raeiszadeh, A. Ebrahimzadeh, R. H. Glitho, J. Eker, and R. A. F. Mini, “Real-time adaptive anomaly detection in industrial iot environments,” IEEE Transactions on Network and Service Management, vol. 21, no. 6, pp. 6839–6856, Dec. 2024. [20] C. de Alwis, O. Aouedi, J. Xu, S. Wang, Y. Siriwardhana, T. Hewa, E. Zeydan, C. Sandeepa, and M. Liyanage, “Federated learning for 6G security: A survey on threats, solutions, and research directions,” IEEE Communications Surveys & Tutorials, vol. 28, pp. 4883–4914, Feb. 2026. [21] S. Ben Saad, B. Brik, and A. Ksentini, “Toward securing federated learning against poisoning attacks in zero touch b5g networks,” IEEE Transactions on Network and Service Management, vol. 20, no. 2, pp. 1612–1624, Jun. 2023. [22] L. Jiang, C. Zhang, X. Qin, Y. Zhou, G. Huang, H. Li, and J. Li, “Telecom fraud recognition based on large language model neuron selection,” Mathematics, vol. 13, no. 11, p. 1784, May 2025. [23] C. Núñez-Gómez, V. Garcia-Font, H. Rifà-Pous, and M. Asad, “NxGenT: A decentralized trust system for B5G and 6G networks based on blockchain and smart contracts,” Blockchain: Research and Applications, p. 100447, 2026. [24] S. T. Muntaha, P. I. Lazaridis, M. Hafeez, Q. Z. Ahmed, F. A. Khan, and Z. D. Zaharis, “Blockchain for dynamic spectrum access and network slicing: A review,” IEEE Access, vol. 11, pp. 17 922–17 944, 2023. [25] P. Fernando, K. Dadallage, T. Gamage, C. Seneviratne, A. Braeken, A. Madanayake, and M. Liyanage, “Distributed-proof-of-sense: Blockchain consensus mechanisms for detecting spectrum access violations of the radio spectrum,” IEEE Transactions on Cognitive Communications and Networking, vol. 9, no. 5, pp. 1110–1125, Oct. 2023. [26] M. Alashwal, U. Waheed, M. Algarni, H. Jamshed, M. Zwawi, Y. Mansoor, and A. Hussain, “Trust aware and explainable access control for Internet of Medical Things: A lightweight hybrid blockchain approach,” IEEE Internet of Things Journal, 2026, early access. [27] E.-h. Diallo, K. Al Agha, and S. Martin, “TRADE-5G: A blockchainbased transparent and secure resource exchange for 5G network slicing,” Blockchain: Research and Applications, vol. 6, p. 100246, 2025. [28] B. Ruszczak, K. Kotowski, D. Evans, and J. Nalepa, “The OPS-SAT benchmark for detecting anomalies in satellite telemetry,” Scientific Data, vol. 12, p. 710, 2025.