Compliance Bundles

A Compliance Bundle is a Policy Pack with pack_type: "bundle". Each bundle is built and maintained by Arbitex, contains rules mapped to a specific regulatory framework, and is read-only: you activate it, position it in your policy chain, and the rules enforce automatically. You cannot modify, suppress, or delete individual rules inside a bundle.

Compliance Bundles contain both DLP detection patterns (what to look for) and policy rules (what to do when a detection occurs). When you add a bundle to your policy chain, both layers activate together.

Available frameworks

Arbitex ships 8 Compliance Bundles:

Bundle ID	Framework	Focus Area
`pci_dss`	PCI-DSS	Payment card data protection
`hipaa`	HIPAA	Protected health information (PHI)
`gdpr`	GDPR	EU personal data protection
`glba`	GLBA	Financial institution customer data
`sox`	SOX	Financial reporting data integrity
`bsa_aml`	BSA/AML	Anti-money laundering suspicious activity
`ccpa`	CCPA	California consumer privacy
`sec_reg_fd`	SEC Reg FD	Material non-public information (MNPI) detection

How bundles work in the Policy Engine

A Compliance Bundle behaves identically to a Custom Pack during evaluation — the Policy Engine does not treat bundles differently at runtime. The distinction is ownership and editability:

	Compliance Bundle	Custom Pack
Created by	Arbitex	Your organization
Rules editable	No — read-only	Yes
Rules suppressible	No	Yes
Position in chain	You control via sequence number	You control via sequence number
Evaluation	Same as any pack — first-match semantics	Same

When you activate a bundle, it appears in your org policy chain as a pack entry with a sequence number you assign. Rules inside the bundle evaluate in their own internal sequence order, just like rules in a custom pack.

Inline detection patterns

Three frameworks (PCI-DSS, HIPAA, and GDPR) include inline detection patterns — regular expressions purpose-built for the framework’s most critical data types. These patterns run in the DLP pipeline alongside platform defaults and produce findings that the bundle’s policy rules consume.

For example, the PCI-DSS bundle includes patterns that target primary account numbers in the formats defined by major card networks, with Luhn checksum validation.

Activating a bundle

Activation is a two-step process: enable the bundle, then add it to your policy chain.

Step 1: Enable the bundle

POST https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/compliance/bundles
Authorization: Bearer arb_live_your-api-key-here
Content-Type: application/json

{
  "bundle_id": "hipaa",
  "enabled": true
}

Enabling a bundle makes its detection patterns active in the DLP pipeline and makes its pack available for chain configuration. The bundle is not enforcing policy rules until you add it to your chain.

Step 2: Add the bundle to your policy chain

PUT https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/policy/chain
Authorization: Bearer arb_live_your-api-key-here
Content-Type: application/json

{
  "combining_algorithm": "first_applicable",
  "packs": [
    {
      "pack_id": "bundle_hipaa",
      "sequence": 1
    },
    {
      "pack_id": "pack_01HZ_TRADING_DESK",
      "sequence": 10
    }
  ]
}

Position the bundle in the chain using the sequence field. Lower sequence numbers evaluate first. In this example, the HIPAA bundle at sequence 1 evaluates before the custom Trading Desk pack at sequence 10.

You can activate multiple bundles simultaneously. An organization in healthcare finance might add both bundle_hipaa (sequence 1) and bundle_pci_dss (sequence 2) before any custom packs.

Chain positioning and precedence

Compliance Bundles follow the same first-match semantics as every other pack. There is no special precedence override — you control precedence by setting sequence numbers.

If you want bundle rules to take absolute precedence over custom rules, position bundles at the lowest sequence numbers (e.g., 1, 2, 3). If you need a custom ALLOW rule to override a bundle BLOCK for a specific group, position the custom pack before the bundle in the chain. This is explicit and auditable.

Under deny_overrides combining algorithm, any BLOCK action from any pack — bundle or custom — takes precedence regardless of sequence order. See Combining algorithm.

Bundle rules are read-only

You cannot modify, suppress, or delete individual rules inside a Compliance Bundle. This is by design: compliance requirements are maintained by Arbitex to ensure they remain aligned with the regulatory framework as standards evolve.

If a bundle rule produces unacceptable results for your organization, you have two options:

Add a custom ALLOW rule before the bundle in the chain — this lets a specific group or condition bypass the bundle rule under first_applicable mode.
Deactivate the bundle entirely — this removes all of the bundle’s rules from your chain. You can then implement the framework’s requirements with custom rules that you control.

Deactivating a bundle

POST https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/compliance/bundles
Authorization: Bearer arb_live_your-api-key-here
Content-Type: application/json

{
  "bundle_id": "hipaa",
  "enabled": false
}

Deactivating a bundle removes its detection patterns from the DLP pipeline and removes its pack from the policy chain. The bundle does not persist in your configuration after deactivation.

Bundle seeding

All 8 Compliance Bundles are seeded into the platform database at application startup. The seeding process is idempotent — restarting the platform does not duplicate bundles or modify existing configurations.

Each bundle is pre-populated with:

The framework identifier (snake_case key)
The complete set of policy rules for that framework
Framework-specific DLP detection patterns (where applicable)
Metadata mapping rules to specific framework sections and control references

Audit trail integration

When a Compliance Bundle rule matches, the audit log entry includes:

The bundle ID (e.g., pci_dss)
The specific rule within the bundle that matched (matched_rule_id)
The framework section reference (e.g., PCI-DSS Requirement 3.4)
The enforcement action taken
The matched content category (not the content itself, for data minimization)

This audit data supports compliance reporting by providing a direct mapping between detected events and the regulatory controls they relate to. See Audit log for the full audit entry schema.