1 Introduction↩︎

Large language models (LLMs) are increasingly deployed in financial services [1]–[4], ranging from consumer-facing chat assistants to internal compliance copilots. In such settings, even a single non-compliant interaction can expose institutions to regulatory penalties, reputational damage, and direct financial harm to consumers. Financial compliance detection is the task of identifying such interactions, in which an LLM input or output violates specific financial regulations. These violations can originate on either side of the conversation: a user may directly solicit prohibited information (e.g., how to structure transactions to evade anti-money-laundering reporting), or the model itself may produce a non-compliant response (e.g., providing actionable guidance for illegal fundraising).

Existing guard models flag harmful content across broad categories such as toxicity and illegal activity [5]–[8], and they cover a subset of financial violations. However, most financial violations are defined by specific regulatory provisions that general harm taxonomies do not capture. Larger general-purpose LLMs prompted as zero-shot judges are not a reliable substitute either: even Qwen3.5-397B-A17B [9] and GPT-5.1 [10] fall well short of acceptable performance in our experiments, as they lack the regulation-grounded discrimination required to separate compliant elaboration from genuine violations. Building a dedicated detector, however, is non-trivial: regulatory documents specify legal boundaries in abstract language rather than providing examples of the interactions a deployed model will encounter, so both the violation taxonomy and the labeled training data must be derived from these documents rather than reused from existing safety corpora.

In this work, we introduce a regulation-driven pipeline that operates directly on regulatory documents. It first develops a risk taxonomy of financial violation categories, and then synthesizes labeled training data grounded in this taxonomy. We instantiate the pipeline on 3,120 publicly available regulatory documents issued by major Chinese financial regulatory authorities as an initial case study, deriving a two-level taxonomy of 11 top-level categories and 35 subcategories. Building on this pipeline, we construct FinGuard-Bench, an expert-annotated benchmark on which existing guard models and substantially larger general-purpose LLMs fail to reliably identify violations. To close this gap, we train FinGuard, an 8B-parameter detection model initialized from Qwen3-8B, on the regulation-grounded data through supervised fine-tuning and self-play reinforcement learning [11]–[13]. On FinGuard-Bench, the strongest general-purpose baseline (Qwen3.5-397B-A17B) reaches only 78.68 / 64.08 F1 at the query and response levels, while FinGuard achieves 90.23 / 85.43 — a gap of 11.55 and 21.35 points despite its much smaller scale.

Our contributions are summarized as follows:

• We propose a regulation-driven pipeline that induces a financial compliance risk taxonomy directly from regulatory documents and synthesizes grounded training data, without relying on any predefined violation categories.

• We release FinGuard-Bench, to our knowledge the first benchmark for financial regulatory compliance detection, covering 11 top-level categories and 35 subcategories with expert-annotated labels at both the query and response levels.

• We develop FinGuard, an 8B-parameter detection model trained via supervised fine-tuning and self-play reinforcement learning, which outperforms all baselines, including dedicated guard models and substantially larger general-purpose LLMs such as Qwen3.5-397B-A17B and GPT-5.1, while also adapting to unseen institution-specific policies using policy documents alone.

2 Related Work↩︎

2.0.0.1 LLM Safety Benchmarks

Safety benchmarks for LLMs have been developed along several axes, including toxicity and hate speech detection [14], multi-category harm classification [15], red-teaming under diverse attack methods [16], and joint evaluation of prompt harmfulness and model refusal [17]. In all cases, harm categories are defined by general ethical principles rather than specific regulations. Recent work extends safety evaluation to financial scenarios [18], [19], evaluating whether models themselves behave safely when presented with harmful financial requests, but evaluation remains at the level of aggregate safety ratings without identifying which specific violation categories are triggered. FinGuard-Bench addresses this gap with per-category labels at both the query and response level.

2.0.0.2 LLMs in Financial NLP

Financial NLP has expanded from classification tasks such as sentiment analysis and entity extraction to problems requiring multi-step numerical reasoning and autonomous decision-making. LLMs have been adapted accordingly through domain-specific pre-training [20], parameter-efficient fine-tuning [21], [22], distillation of reasoning chains with reinforcement learning [1], [3], [4], and agent architectures with layered memory [23], [24]. Yet the financial compliance dimension remains largely unaddressed. Existing guard models [5]–[7], [25]–[27] classify LLM inputs or outputs against general-purpose harm taxonomies. FinGuard in this paper shifts the focus to financial compliance, training on regulation-grounded data to detect domain-specific violations.

3 Methodology↩︎

3.1 Task Formulation↩︎

We formulate safety classification as the task of determining whether a given text violates a risk definition \(\mathcal{D}\). We consider two settings. Query-level classification assesses whether a user query \(q\) itself poses a compliance risk. The model takes \(q\) and \(\mathcal{D}\) as input and predicts a binary label \(y \in \{\texttt{Safe}, \texttt{Unsafe}\}\), along with any violated subcategories \(\mathcal{C} \subseteq \mathcal{D}\). Response-level classification assesses whether an assistant’s response \(r\) is compliant, conditioned on the query \(q\) for context. Here, \(r\) is the evaluation target while \(q\) provides necessary background — this separation captures cases where a seemingly harmless query can elicit a non-compliant response.

In this work, we instantiate \(\mathcal{D}\) as a financial compliance risk taxonomy (Section 3.2.1), specializing the above formulation to detect regulatory violations in financial scenarios.

3.2 Dataset Construction for Financial Compliance↩︎

As shown in Figure 1 (left), we build our dataset through a multi-stage pipeline. Starting from financial regulatory documents, we induce a risk taxonomy (Section 3.2.1), synthesize adversarial queries (Section 3.2.2), and distill corresponding responses (Section 3.2.3). After automated labeling, deduplication, and quality filtering, we split the resulting corpus into FinGuard-Train and a held-out subset that domain experts annotate to form FinGuard-Bench (Sections 3.2.4 and 3.3).

3.2.1 Financial Risk Taxonomy↩︎

We derive the taxonomy from 3,120 publicly available regulatory documents issued by major Chinese financial regulatory authorities, followed by financial expert verification. Using Qwen3.5-397B-A17B [9], we extract fine-grained compliance points (e.g., prohibited behaviors, violation examples) from each document, encode them with text-embedding-v4 [28], cluster via HDBSCAN [29], and summarize into coherent categories. Three senior financial experts independently review these categories to resolve overlaps between financial risk types (e.g., distinguishing “Illegal Fundraising” from “Unauthorized Investment Advice”) and inject implicit subcategories missed by automated extraction. They reconcile disagreements through discussion until consensus is reached. This yields a two-level taxonomy of 11 top-level categories and 35 subcategories The full taxonomy with detailed definitions is provided in Appendix 7.

3.2.2 Query Construction↩︎

We synthesize user queries based on the financial risk taxonomy through a three-stage pipeline that progressively expands coverage, increases difficulty, and ensures balanced supervision. Unless otherwise noted, we use Qwen3.5-397B-A17B for all stages. The prompts are in Appendix 8.

3.2.2.1 Stage 1: Keyword-Driven Generation.

Direct query generation from categories tends to produce repetitive outputs with insufficient scenario coverage. We first compile 10 manually curated seed keywords for each of the 35 subcategories and expand them into 4,722 unique keywords capturing distinct violation scenarios. For each keyword, we generate 3 user queries, each explicitly incorporating it and adopting a violation-seeking tone, yielding 13,980 queries in total.

3.2.2.2 Stage 2: Multi-Dimensional Adversarial Augmentation.

While queries anchored to explicit keywords express violation intent directly, real-world ones often employ implicit or obfuscated strategies. Drawing on prior taxonomies of jailbreak and persuasion attacks [30], [31], we define 8 adversarial augmentation dimensions tailored to financial scenarios (see Appendix 9 for the full list). For each query, we repeat this process 3 times: randomly sample 1–3 dimensions and apply the corresponding transformations, yielding 41,940 augmented queries.

3.2.2.3 Stage 3: Compliant Counterpart Generation.

To ensure the model learns to distinguish underlying intent rather than memorize surface patterns, we generate a compliant counterpart for each violative query. Specifically, we rewrite each query into a semantically similar variant with reversed intent but preserved surface structure. For example, “How to fabricate financial statements” becomes “How to identify fabricated financial statements”. This yields 55,920 compliant queries, forming paired violative-compliant instances.

3.2.3 Response Generation↩︎

We employ a multi-model distillation strategy to generate corresponding assistant responses. Specifically, we utilize two categories of models. The first comprises five general-purpose language models spanning a range of scales: Kimi-Linear-48B-A3B-Instruct [32], GLM-4-9B-0414 [32], Qwen2.5-7B-Instruct [33], Qwen3.5-9B/397B-A17B [9], GPT-OSS-20B [34], QwQ-32B [35], and Deepseek-R1 [36]. The second consists of four abliterated models², variants with safety alignment removed: Qwen2.5-7B-Instruct-abliterated-v3, Huihui-Qwen3.5-9B-abliterated, Huihui-gpt-oss-20b-BF16-abliterated, and QwQ-32B-abliterated. Each synthesized query is submitted to all models. For reasoning models Qwen3.5-9B and Huihui-Qwen3.5-9B-abliterated, we additionally generate responses with chain-of-thought reasoning enabled to capture deliberation-based behavior. This process yields a total of 1,456,134 responses, encompassing the full range of patterns from explicit refusal to unguarded compliance.

3.2.4 Quality Control↩︎

3.2.4.1 Automated Response Labeling.

The generated responses lack explicit safety and category labels, as the source model alone is not a reliable proxy (e.g., general LLMs may still produce unsafe outputs). To address this, we employ an ensemble-based labeling approach using multiple Qwen model variants (e.g., Qwen2.5-72B-Instruct, Qwen3-235B-A22B). Each model independently assigns a safety label (Safe vs. Unsafe) and one or more financial violation subcategories to each response. Final labels are determined through majority voting across all annotator models. We further validate the annotation quality on a held-out set of 50 human-annotated examples, where the ensemble approach achieves an F1-score above 0.95.

3.2.4.2 Deduplication and Filtering.

We apply TF-IDF [37] deduplication to the synthesized queries and employ LLM-as-a-Judge (Qwen3.5-397B-A17B) to score response quality on a 1–5 scale, filtering out outputs that score below 4. The detailed prompt is provided in Appendix 10. In total, we obtain 111,293 queries and 1,445,664 responses for financial compliance. The overall filtering rate is below 1%, indicating that the generation pipeline already produces high-quality data with minimal redundancy or degradation.

3.2.4.3 Partition

To ensure balanced representation across subcategories, we sample 30 query-response pairs per subcategory with a 2:1 unsafe-to-compliant ratio to form a held-out subset of 1,050 instances reserved for financial expert annotation (Section 3.3), and use the remaining instances as FinGuard-Train.

3.3 FinGuard-Bench↩︎

Existing safety benchmarks focus on general domains and lack coverage of financial violation scenarios. We introduce FinGuard-Bench, a human-annotated benchmark for evaluating financial compliance at the query and response levels. To construct it, three financial experts independently annotate the held-out subset (Section 3.2.4) following structured annotation guidelines (see Appendix 11), achieving an initial inter-annotator agreement of 86.9%. Through deliberative consensus, 108 labels are revised and 30 instances with unresolved disagreements are discarded, leaving 1,020 pairs in the final benchmark.

3.3.0.1 Dataset Statistics.

Table [tab:basic95stats] summarizes FinGuard-Bench, which contains 1,020 query-response pairs spanning 11 categories and 35 subcategories. Unsafe samples account for 72.9% at the query level but only 30.9% at the response level, a 42.0-point gap that highlights the need for dual-level compliance evaluation. Queries average 99.9 tokens and responses 1,723.3 tokens, reflecting the long-form nature of financial advisory content.

3.3.0.2 Category and Safety Distribution.

Tables [tab:benchmark95distribution] and [tab:category95safety] show that category sizes range from 58 to 149 samples, roughly following the number of subcategories. Response-level unsafe ratios vary substantially across categories, from 11.9% to 46.1%, and the gap between query- and response-level unsafe ratios ranges from 28.1 to 49.4 percentage points. This diversity ensures broad coverage of compliance scenarios with heterogeneous risk profiles.

3.3.0.3 Cross-Level Safety Analysis.

Table [tab:cross95level] shows that all four query-response safety combinations appear in the benchmark. Notably, 2.9% of samples are query-safe but response-unsafe, indicating that compliance violations can arise from the model’s own elaboration even when the query is benign.

3.4 Financial Compliance Policy Learning↩︎

As illustrated in Figure 1 (right), we train FinGuard in two stages: supervised fine-tuning (Section 3.4.1) on FinGuard-Train, followed by self-play reinforcement learning (Section 3.4.2) that generates queries at moderate difficulty to further improve classification.

3.4.1 Supervised Fine-Tuning↩︎

We jointly train both tasks defined in Section 3.1. The target \((y, \mathcal{C})\) is linearized into a token sequence \(a = (a_1, \ldots, a_T)\), and the model is trained with the autoregressive objective: \[\mathcal{L}_{\text{SFT}} = -\sum_{t=1}^{T} \log p_\theta(a_t \mid a_{<t}, x)\] where the input is \(x = [q;\; \mathcal{D}]\) for query-level classification and \(x = [r;\; q;\; \mathcal{D}]\) for response-level classification. The corresponding prompt templates are provided in Appendix 12.

3.4.2 Self-Play Reinforcement Learning↩︎

While SFT provides a strong initialization, it is limited to the fixed difficulty distribution of the training data. To address this, we introduce a self-play framework inspired by [13], in which a single model \(\pi_\theta\), initialized from the SFT checkpoint, simultaneously serves as both a Generator that produces queries with intended safety labels \(\hat{y}\), and a Guard that classifies them. Both roles share parameters and are differentiated by role-specific prompts (Appendix 13). The Guard is updated via GRPO [38] with group-normalized advantages across rollouts, while the Generator uses the reward directly as the policy gradient signal. We apply self-play to query-level classification only, as extending to the response level would require an additional generation step and, more critically, would lack a reliable oracle for response safety labels. Algorithm 2 details the full procedure.

3.4.2.1 Guard Reward.

For each Guard prediction \(y_i\) given target label \(\hat{y}\): \[r^{\text{guard}}(y_i, \hat{y}) = \begin{cases} 1.0 & \text{if } y_i = \hat{y} \\ 0.0 & \text{if } y_i \neq \hat{y} \\ -0.5 & \text{if format error}\footnotemark \end{cases}\]

3.4.2.2 Generator Reward.

Let \(s = \frac{1}{N}\sum_{i=1}^{N} \mathbb{1}[y_i = \hat{y}]\) be the Guard accuracy over \(N\) rollouts. We reward the Generator with a Gaussian centered at \(s = 0.5\): \[r^{\text{gen}}(s) = \exp\!\left(-\frac{(s - 0.5)^2}{2\sigma^2}\right), \quad 0 < s < 1\]

where \(\sigma\) controls reward sharpness. Samples with \(s \in \{0, 1\}\) are discarded, as complete Guard agreement indicates the query is either trivially easy or misaligned with its intended label \(\hat{y}\). This filtering implicitly ensures that only well-calibrated queries contribute to training, and encourages the Generator to produce queries that are neither too easy nor too hard for the current Guard.

4 Experimentation↩︎

4.1 Experimental Setup↩︎

4.1.0.1 Datasets.

We train on FinGuard-Train, downsampled to a 1:1 safe-to-unsafe ratio at both the query and response levels, yielding 495,590 training samples in total.

4.1.0.2 Model Training.

We adopt Qwen3-8B [39] as the backbone and fine-tune it with LoRA [40], followed by self-play RL with GRPO [38]. Full hyper-parameter settings are provided in Appendix 14.

4.1.0.3 Baselines.

We compare FinGuard against two groups of baselines. The first group consists of general-purpose LLMs prompted to perform compliance classification in a zero-shot setting, including Qwen3-8B, Qwen3.5-9B, Qwen3.5-397B-A17B, Gemini-3.1-Flash, and GPT-5.1. These models receive the same prompt template as FinGuard. The second group consists of safety guard models designed for general-purpose safety moderation, including LlamaGuard3-8B, NemoGuard-8B, PolyGuard-Qwen-7B, and Qwen3Guard-Gen-8B³. These models are evaluated using their native prompt formats.

4.1.0.4 Evaluation.

We evaluate on FinGuard-Bench. Following prior work on safety moderation [41]–[43], we use F1 score on the unsafe class as the primary metric, reported separately for query-level and response-level classification.

4.2 Main Results↩︎

Table [tab:main95results] presents results on FinGuard-Bench. We have the following observations:

• FinGuard w/o Self-Play already surpasses all general-purpose LLMs — including much larger models such as Gemini-3.1-Flash and GPT-5.1 — achieving F1 scores of 84.13 and 84.71 at the query and response levels. Its own backbone, Qwen3-8B, scores only 16.69 and 22.91 under the same prompt, confirming that general language understanding alone is far from sufficient for this task.

• Safety guard models uniformly underperform FinGuard w/o Self-Play despite being explicitly trained for content safety. The highest query-level F1 among them is 52.46 from PolyGuard-Qwen-7B, while Qwen3Guard-Gen-8B achieves the highest response-level F1 at 73.49. We attribute this gap to mismatch between general safety taxonomies and financial compliance categories.

• With self-play RL, FinGuard achieves 90.23 and 85.43, improving over the SFT baseline by 6.10 and 0.72 at the query and response levels, respectively. Naturally, the query-level gain is larger, as self-play directly targets query-level classification. The modest response-level improvement suggests that shared parameters allow query-level gains to partially transfer.

5 Discussion↩︎

5.1 Effect on General Safety↩︎

A natural concern with domain-specific fine-tuning is whether it degrades the model’s general safety capability. We evaluate FinGuard on five query-level benchmarks (ToxicChat [44], Aegis2.0 [6], SimpleSafetyTests [45], HarmBench [16], WildGuard [17]) and three response-level benchmarks (Aegis2.0, XSTest [46], Beavertails [47]). As shown in Table [tab:general95safety95avg], FinGuard achieves average F1 of 81.00 and 82.37 at the query and response levels, slightly above its Qwen3-8B backbone at 79.18 and 79.60, confirming that financial compliance training does not compromise general safety. Nevertheless, the safety guard models score higher, as they are trained on general safety corpora that our current pipeline does not cover. Extending the pipeline to incorporate such data is a natural direction for future work.

5.2 Cross-Category Performance↩︎

To better characterize where the difficulty of FinGuard-Bench concentrates and how FinGuard’s gains are distributed across compliance topics, we break down query-level F1 score across the 11 top-level categories of our financial compliance risk taxonomy. Table [tab:category-breakdown] reports per-category performance. Self-play RL improves all 11 categories, with gains from 1.26 to 9.90 F1 points. After self-play, FinGuard surpasses Qwen3.5-397B-A17B on every category despite using significantly fewer parameters. The per-category F1 ranges from 82.11 to 96.34, indicating that financial compliance detection is not uniformly difficult across violation types. Categories involving procedural rules with clear regulatory definitions (e.g., Data Security & IT Violations, 96.34) are easier to detect than those requiring judgment over intent and context (e.g., Corruption & Benefit Transfer, 82.11), suggesting that the latter may benefit from richer training signals or explicit reasoning.

5.3 Adaptation to Out-of-Domain Regulations↩︎

To test whether self-play generalizes beyond FinGuard’s training corpus, we collect 10 anonymized policy documents from unseen sources and extract compliance points using the same procedure as in Section 3.2.1. We then run self-play RL restricted to Consumer Rights Violations: the Generator produces queries on the fly from these compliance points, and the Guard learns under the same reward. Evaluation uses 100 unsafe queries manually written by three financial experts grounded in these documents. As shown in Table [tab:adaptation], F1 rises from 68.42 without adaptation to 93.62 after self-play, with no human-annotated training examples, indicating that policy documents alone provide sufficient signal to bridge out-of-domain gaps.

5.4 Case Study↩︎

We examine two FinGuard-Bench cases in Figure 3, comparing FinGuard against Qwen3-8B, Qwen3.5-397B-A17B, and Qwen3Guard-Gen-8B. In Case 1, a query framed as a routine false-positive fix (“We’re not trying to bypass compliance”) in fact adjusts the registered MCC level and whitelists partners to lower risk-control sensitivity, silently weakening an approved control; baselines accept the cooperative framing as Safe, while FinGuard flags it as Unsafe under Corporate Governance Failures. In Case 2, a seemingly procedural query about a non-public API receives a response that endorses bypassing the front-end approval workflow (“this purpose can indeed be achieved”); only FinGuard catches this response-level drift and labels it as Data Misuse.

6 Conclusion↩︎

In this work, we study financial regulatory compliance detection. From 3,120 Chinese regulatory documents, we build a pipeline that jointly induces a two-level risk taxonomy and synthesizes training data, resulting in FinGuard-Bench with expert annotations for both queries and responses. Using supervised fine-tuning and self-play reinforcement learning, an 8B model outperforms much larger general-purpose LLMs and specialized guard models on FinGuard-Bench while preserving general safety capabilities. The same approach also transfers to unseen institution-specific policies using only policy text. In future work, we plan to extend this pipeline to general-domain safety, additional jurisdictions, and multilingual regulatory settings.

Limitations↩︎

Although FinGuard-Bench and FinGuard provide a regulation-grounded compliance benchmark and guard model for the Chinese financial domain, several limitations remain:

• Single-jurisdiction and single-language coverage. FinGuard-Bench is built on 3,120 publicly available Chinese regulatory documents and contains Chinese queries and responses. Other jurisdictions and English-language compliance are not covered, which restricts direct generalisation to multilingual or cross-border deployment.

• Static regulatory snapshot. The 3,120 regulatory documents reflect the state of Chinese financial supervision at the time of collection. Subsequent rule revisions, new supervisory guidance, and enforcement updates will require periodic refresh of the taxonomy and evaluation set.

• Limited adversarial-robustness evaluation. FinGuard is not stress-tested against general-purpose jailbreak attacks. The adversarial augmentation we apply is restricted to financial-domain rewriting along eight dimensions, leaving robustness under generic and out-of-domain attacks an open question.

Ethics Statement↩︎

All source documents used in this work are publicly available Chinese financial regulatory publications, introducing no privacy or intellectual-property concerns. The three financial compliance experts who verified the taxonomy and annotated the benchmark were fully informed of the research purpose and compensated above standard professional consulting rates. We acknowledge that adversarial query synthesis techniques developed for stress-testing could in principle be repurposed to evade compliance systems; however, the synthesized queries are grounded in publicly accessible regulations rather than novel attack vectors, limiting incremental risk. Data handling complies with China’s Personal Information Protection Law, and the study has received Institutional Review Board approval. To facilitate reproducibility, we will publicly release the benchmark construction code, evaluation scripts, and annotation guidelines upon publication, subject only to any third-party licensing constraints on redistributed source materials.

7 Detailed Financial Risk Categories↩︎

Table [tab:taxonomy95detail] presents the full financial risk taxonomy, comprising 11 top-level categories and 35 subcategories derived from Chinese financial regulatory documents.

8 Prompts for Query Construction↩︎

Figure 4 and Figure 5 show the prompts used for keyword generation and keyword-driven query synthesis in Stage 1. Figure 6 shows the prompt for adversarial augmentation in Stage 2, and Figure 7 shows the prompt for compliant counterpart generation in Stage 3.

9 Definition of Adversarial Augmentation Dimensions↩︎

Table [tab:adversarial95augmentation] lists the eight augmentation dimensions, each targeting a distinct strategy by which users may obscure violation intent.

10 Prompt for Response Quality Scoring↩︎

Figure 8 shows the prompt used to score response quality on a 1–5 scale. Only responses scoring 5 are retained.

None

11 Annotation Guideline↩︎

Figure 9 presents the annotation guideline used by financial experts when labeling FinGuard-Bench samples.

None

12 Prompts for Financial Compliance Detection↩︎

Figure 10 and Figure 11 show the prompt templates used for query-level and response-level compliance classification, respectively.

None

None

13 Prompts for Self-Play↩︎

During self-play reinforcement learning , the Generator and Guard roles share the same model parameters but are differentiated by role-specific prompts. The Guard uses the same prompt template as query-level compliance detection (Figure 10). The Generator uses one of two templates depending on the intended safety label \(\hat{y}\): when \(\hat{y} = \texttt{Unsafe}\), it receives the non-compliant proposer prompt (Figure 12); when \(\hat{y} = \texttt{Safe}\), it receives the compliant proposer prompt (Figure 13).

None

None

14 Training Details↩︎

For supervised fine-tuning, we use the LLaMA-Factory  [48] framework and apply LoRA  [40] with a rank of 8 and a scaling factor of 16 to all linear layers. Training is conducted on 8 NVIDIA A100 80GB GPUs for 1 epoch, with a per-device batch size of 4 and gradient accumulation over 2 steps. The learning rate is set to \(3 \times 10^{-5}\) with cosine decay. For self-play reinforcement learning, the SFT checkpoint is further optimized using the VERL  [49] framework with the GRPO  [38] algorithm for 30 steps on the same hardware, with a batch size of 64, a rollout size of 8, and a learning rate of \(1 \times 10^{-6}\). The KL-penalty coefficient is set to 0.01 and the Generator reward sharpness \(\sigma\) to 0.25.

15 Results on General Safety Benchmark↩︎

Table [tab:general95safety] reports per-benchmark F1 scores on general-domain safety benchmarks.

References↩︎

---

1. Corresponding Author↩︎

2. Abliterated checkpoints in this work are obtained from https://huggingface.co/huihui-ai.↩︎

3. Qwen3Guard-Gen-8B is evaluated under both strict and loose settings, which differ in how controversial content is classified.↩︎