Compliance Frameworks

Arbitex ships eight pre-built compliance bundles that map regulatory frameworks to DLP detectors, enforcement rules, and audit evidence. Each bundle is a named set of DLP entity types with configurable enforcement tiers. When a bundle is active, its associated detectors scan every AI request and response in real time.

Overview

Compliance bundles are managed through the admin UI at Admin → Compliance or via the Compliance Bundles API. Each bundle can be:

Activated / Deactivated — toggles all associated DLP rules on or off atomically.
Assigned to groups — different user groups can operate under different bundles simultaneously.
Versioned — platform upgrades may ship updated bundle definitions; admins review and apply upgrades explicitly.

Bundles use the same DLP rule pipeline as custom rules. A rule’s is_required flag marks it as non-suppressible — it cannot be disabled even if it is shared with another bundle that is deactivated.

Supported Frameworks

PCI-DSS

Payment Card Industry Data Security Standard — protects cardholder data at rest and in transit.

Field	Value
Regulatory body	PCI Security Standards Council
Arbitex bundle name	`PCI-DSS Compliance Bundle`
Default state	Inactive (must be explicitly activated)

DLP detectors activated

Entity type	Description
`credit_card`	13–19 digit card numbers (Luhn-validated), all major networks
`cvv`	3–4 digit card verification values in payment context
`bank_account_number`	US domestic account numbers, 6–17 digits
`ach_data`	ACH routing + account number pairs

Non-suppressible rules: All four entity types carry is_required=true in the seed bundle. They cannot be individually disabled while the PCI-DSS bundle is active.

Audit evidence generated

Every request triggering a PCI-DSS detector produces an audit log entry with:

dlp_triggered: true, dlp_labels: ["credit_card"] (or applicable label)
compliance_framework: "PCI-DSS" (populated when rule is bundle-sourced)
action_taken: one of block, redact, warn, log
Full prompt and response hashes for cardholder data evidence chain

Configuring the bundle

# Activate via API
curl -X POST https://your-platform/api/admin/compliance-bundles/{bundle_id}/activate \
  -H "Authorization: Bearer $ADMIN_TOKEN"

To assign the bundle to a specific group (e.g., payment processing team):

curl -X POST https://your-platform/api/admin/groups/{group_id}/compliance-bundles \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -d '{"bundle_id": "<pci-bundle-id>"}'

Compliance notes: PCI-DSS Requirement 3 prohibits storage of sensitive authentication data (SAD) after authorization. The cvv detector enforces this by blocking or redacting CVV values in AI outputs.

HIPAA

Health Insurance Portability and Accountability Act — protects Protected Health Information (PHI).

Field	Value
Regulatory body	U.S. Department of Health and Human Services
Arbitex bundle name	`HIPAA Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`health_info`	Diagnoses, medications, lab results, clinical terms
`ssn`	US Social Security Numbers (formatted and unformatted)
`name`	Personal name patterns in healthcare context
`date_of_birth`	Date of birth in multiple formats

Non-suppressible rules: health_info and ssn carry is_required=true. Name and date-of-birth detectors can be individually configured via the policy engine if organizational policy permits.

Audit evidence generated

dlp_labels includes all triggered PHI categories
hipaa_phi_detected: true annotation on audit entries (populated by compliance enforcement service)
Minimum Necessary Standard metadata: audit records capture which PHI categories appeared in each request, supporting breach risk assessments under the HIPAA Breach Notification Rule

Configuring the bundle

HIPAA bundles are commonly combined with the require_approval action for clinical use cases:

{
  "name": "PHI Disclosure Review",
  "conditions": [
    {"type": "dlp_label", "operator": "contains_any", "value": ["health_info", "ssn"]}
  ],
  "action": {
    "type": "require_approval",
    "approval_group": "privacy-officers",
    "timeout_action": "block",
    "timeout_minutes": 60
  }
}

SOX

Sarbanes-Oxley Act — financial reporting integrity for US public companies.

Field	Value
Regulatory body	SEC / PCAOB
Arbitex bundle name	`SOX Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`financial_account_numbers`	General financial account identifiers
`employment_info`	Compensation, benefits, HR data
`contract_numbers`	Contract and agreement identifiers

Non-suppressible rules: financial_account_numbers is is_required=true. Employment info and contract number detectors are required=false to allow organizational discretion.

Audit evidence generated

SOX audit support focuses on the completeness and immutability of the audit trail. Every AI interaction involving financial data generates:

Immutable audit log entries (platform uses append-only audit log architecture)
financial_data_detected flag for evidence of internal controls testing
User identity, timestamps, and session IDs for SOX Section 404 documentation

GLBA

Gramm-Leach-Bliley Act — financial privacy for US financial institutions.

Field	Value
Regulatory body	FTC / federal banking agencies
Arbitex bundle name	`GLBA Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`financial_account_numbers`	General financial account identifiers
`ssn`	Social Security Numbers
`account_balances`	Account balance and financial position data

Non-suppressible rules: All three entity types are is_required=true under GLBA, reflecting the Safeguards Rule requirement to protect nonpublic personal financial information (NPPI).

Audit evidence generated

Safeguards Rule compliance: every access to NPPI-containing content is logged with full user context
Annual security program documentation support: audit exports available via the Compliance Export API

General Data Protection Regulation — data protection and privacy for EU residents.

Field	Value
Regulatory body	EU Data Protection Authorities
Arbitex bundle name	`GDPR Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`name`	Personal names
`email`	Email addresses
`telephone`	Phone numbers
`ip_address`	IPv4 and IPv6 addresses
`racial_ethnic_origin`	Special category — racial or ethnic origin data
`political_opinions`	Special category — political opinions
`religious_beliefs`	Special category — religious or philosophical beliefs
`health_info`	Special category — health data
`biometric`	Special category — biometric data for unique identification
`genetic`	Special category — genetic data

Non-suppressible rules: The five special category detectors (racial_ethnic_origin, political_opinions, religious_beliefs, biometric, genetic) are is_required=true, reflecting GDPR Article 9 prohibition on processing special categories without explicit lawful basis. Standard personal data detectors (name, email, telephone, ip_address) are is_required=false.

Audit evidence generated

GDPR requires demonstrable accountability (Article 5(2)). Arbitex provides:

Processing activity records: every AI interaction with personal data is logged with the legal basis annotation (configurable via policy metadata)
Data subject identifiers: email and name detection events support right-of-access and erasure workflows
Cross-border transfer logging: user IP geolocation enrichment on audit records supports transfer impact assessments

GDPR-specific configuration

For Article 22 (automated decision-making) use cases, combine the GDPR bundle with warn or require_approval actions and document the legal basis in policy rule descriptions:

{
  "name": "GDPR Article 22 Guard",
  "description": "Flag automated decisions affecting individuals — legal basis: Article 6(1)(f)",
  "conditions": [
    {"type": "dlp_label", "operator": "contains_any",
     "value": ["racial_ethnic_origin", "health_info", "biometric"]}
  ],
  "action": {"type": "warn", "warn_message": "Special category data detected — review legal basis."}
}

CCPA

California Consumer Privacy Act — consumer privacy rights for California residents.

Field	Value
Regulatory body	California Privacy Protection Agency
Arbitex bundle name	`CCPA Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`name`	Personal names
`email`	Email addresses
`ssn`	Social Security Numbers
`geolocation`	Precise geolocation data
`biometric`	Biometric data

Non-suppressible rules: ssn and biometric are is_required=true. The remaining three are is_required=false, reflecting that CCPA provides opt-out rights rather than a blanket prohibition.

Audit evidence generated

CCPA audit logs support consumer rights request workflows:

Personal information detection logs used to scope data inventory responses to “know” requests
Deletion request scoping: audit exports filterable by user identity (see Compliance Export API)

BSA/AML

Bank Secrecy Act / Anti-Money Laundering — financial crime prevention for US financial institutions.

Field	Value
Regulatory body	FinCEN / federal banking agencies
Arbitex bundle name	`BSA/AML Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`ssn`	Social Security Numbers (Customer Due Diligence)
`bank_account_number`	Bank account numbers
`financial_account_numbers`	Broader financial account identifiers

Non-suppressible rules: All three are is_required=true, reflecting BSA’s mandatory recordkeeping and reporting requirements under 31 CFR 1010.

Audit evidence generated

Customer Due Diligence (CDD) support: SSN and account detection events logged with full context for FinCEN 314(b) information sharing
Suspicious Activity Report (SAR) workflow support: audit exports can be filtered by time range and entity type for BSA/AML investigations
Five-year retention alignment: Arbitex audit logs are immutable; configure your retention policy at Admin → Data Retention to meet BSA 31 CFR 1010.430 requirements

SEC 17a-4

SEC Rule 17a-4 — electronic records retention for broker-dealers.

Field	Value
Regulatory body	U.S. Securities and Exchange Commission
Arbitex bundle name	`SEC 17a-4 Compliance Bundle`
Default state	Inactive

DLP detectors activated

Entity type	Description
`email`	Email addresses (business communications)
`financial_account_numbers`	Securities account identifiers
`contract_numbers`	Trade agreement and contract references

Non-suppressible rules: All three are is_required=true, reflecting Rule 17a-4’s requirement that broker-dealer records be retained in a non-rewriteable, non-erasable format.

Audit evidence generated

SEC 17a-4 imposes strict requirements on the audit trail itself:

Write-once audit records: Arbitex audit logs are append-only with no update path
Indexing and access: all audit log entries are indexed by date, user, and entity type for SEC examination access
WORM compliance: when paired with outpost air-gap mode and SQLite local audit queue, records are durable even during network outages — see Air-Gap Deployment

Bundle Management

Activating a Bundle

# List all bundles (includes seeded frameworks)
curl https://your-platform/api/admin/compliance-bundles \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# Activate a specific bundle
curl -X POST https://your-platform/api/admin/compliance-bundles/{id}/activate \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Activating a bundle sets enabled=true on all its associated DLP rules atomically and fires a bundle_state_change webhook.

Assigning Bundles to Groups

Organizations can operate different bundles for different teams (e.g., HIPAA for clinical staff, PCI-DSS for payment processors). Group-level assignments override the global active bundle for members of that group.

See Admin → Groups → [group] → Compliance to configure per-group bundle assignments, or use the Groups API.

Version Upgrades

When Arbitex ships updated bundle definitions (e.g., new entity types for an updated regulatory standard), an upgrade becomes available:

# Check for upgrade
curl https://your-platform/api/admin/compliance-bundles/{id} \
  -H "Authorization: Bearer $ADMIN_TOKEN"
# Returns: "upgrade_available": true

# Apply upgrade
curl -X POST https://your-platform/api/admin/compliance-bundles/{id}/upgrade \
  -H "Authorization: Bearer $ADMIN_TOKEN"
# Returns: rules_added, rules_removed, rules_preserved counts

Upgrades preserve any custom rules you have added to the bundle. Seed rule changes are applied while custom rules are retained.

Creating Custom Bundles

Seeded bundles (is_seeded=true) cannot be deleted or renamed. You can create custom bundles alongside them:

curl -X POST https://your-platform/api/admin/compliance-bundles \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Internal Data Classification",
    "description": "Internal sensitivity tiers",
    "regulatory_framework": "internal",
    "version": "1.0",
    "enabled": false
  }'

Audit Evidence and Reporting

All compliance-related events are available via the Compliance Export API and the Compliance Reports API. Use the framework filter to scope exports to a specific bundle:

curl "https://your-platform/api/admin/compliance/export?framework=HIPAA&format=json&from=2026-01-01T00:00:00Z" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

For ongoing monitoring, configure alerts on dlp_triggered events using the Alerts API.

DLP Pipeline Configuration — custom DLP rules and label configuration
Policy Engine — rule evaluation model and action types
Compliance Export API — bulk audit evidence export
Compliance Reports API — aggregate compliance reporting
Quota Management — per-group usage limits alongside compliance controls

Compliance Frameworks

Overview

Supported Frameworks

PCI-DSS

HIPAA

SOX

GLBA

GDPR

CCPA

BSA/AML

SEC 17a-4

Bundle Management

Activating a Bundle

Assigning Bundles to Groups

Version Upgrades

Creating Custom Bundles

Audit Evidence and Reporting

Related