Compliance Frameworks Reference

Arbitex ships 8 Compliance Bundles — pre-built Policy Packs mapped to specific regulatory frameworks. This reference describes what each framework requires, what Arbitex detects and enforces, and how to activate coverage.

For each framework, Arbitex provides:

• A Compliance Bundle with detection patterns and policy rules mapped to the framework
• An audit trail that captures framework-referenced matches (e.g., PCI-DSS Requirement 3.4)
• SIEM export of enforcement events in OCSF format for your compliance team

Note

Arbitex is not currently certified under any of these frameworks. Compliance Bundles are engineered to support your compliance program. Your organization remains responsible for demonstrating compliance to auditors.

---

Policy actions and their compliance meaning

When a Compliance Bundle rule matches, the policy engine applies one of these terminal actions. Each action has a distinct compliance interpretation:

Action	Behavior	Compliance signal
BLOCK	Request rejected before reaching the model	Preventive control — data never transmitted
CANCEL	Completion cancelled; user prompted to revise	Detective + corrective control — user must acknowledge
REDACT	Matched content replaced before model sees it	De-identification control
ALLOW_WITH_OVERRIDE	Request logged and allowed after user attestation	Governance control — creates an accountable exception record
PROMPT	Governance challenge interposed before proceeding	Approval workflow control

All enforcement actions — regardless of type — produce a security_finding audit log entry with the framework reference, rule ID, pack ID, and matched entity category. Audit entries do not store the matched content itself.

---

OCSF export for compliance reporting

Enforcement events are exported to SIEM in OCSF v1.1 format. Each Compliance Bundle enforcement action maps to OCSF class 2001 — Security Finding (category: Findings).

Authentication events (login, MFA, SSO) from the same audit trail export as OCSF class 3002 — Authentication Activity. Administrative changes (policy updates, user management) export as OCSF class 3001 — Account Change.

Your compliance team can filter SIEM dashboards by:

• class_uid = 2001 — all enforcement events (framework matches, DLP blocks, CredInt hits)
• cloud.account.uid = <org_id> — events for a specific organization
• activity_name — specific action type (e.g., dlp_block, policy_block)
• metadata.framework_reference — specific regulatory reference (e.g., PCI-DSS Requirement 3.4)

See Audit Data Model Reference for the full field-level OCSF mapping.

---

PCI-DSS

Bundle ID: pci_dss Standard: Payment Card Industry Data Security Standard

Scope

PCI-DSS applies to any system that stores, processes, or transmits payment card data. An AI Gateway that proxies employee or customer conversations creates a risk of cardholder data appearing in prompts or completions.

What Arbitex detects

The pci_dss bundle includes inline DLP detection patterns for:

• Primary Account Numbers (PANs) — all major card network formats (Visa, Mastercard, Amex, Discover) with Luhn checksum validation
• Card verification values (CVV/CVC) in proximity to PANs
• Card expiration dates

Detection runs in the DLP pipeline before policy evaluation. Findings are consumed by bundle rules.

What Arbitex enforces

Requirement area	Arbitex control
Req 3 — Protect stored cardholder data	Block transmission of PANs through the Gateway. Matched content category logged (not the content itself).
Req 3.4 — Render PAN unreadable	BLOCK action prevents PAN from reaching downstream model or user. Audit log references PCI-DSS Requirement 3.4.
Req 10 — Track and monitor access	Tamper-evident audit trail with HMAC chain. All API requests logged with org, user, action.
Req 10.5 — Protect audit trails	90-day active + 2-year archive retention. HMAC chain detects modification.

Activate

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

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

Then add bundle_pci_dss to your policy chain. See Compliance Bundles for the full two-step activation procedure.

---

HIPAA

Bundle ID: hipaa Standard: Health Insurance Portability and Accountability Act (Privacy + Security Rules)

Scope

HIPAA applies to covered entities (healthcare providers, health plans, clearinghouses) and their business associates. AI Gateways used by healthcare organizations create risk of Protected Health Information (PHI) appearing in prompts or completions.

What Arbitex detects

The hipaa bundle includes inline DLP detection patterns for the 18 HIPAA Safe Harbor identifiers, including:

• Patient names in clinical context
• Medical record numbers
• Dates of service, birth dates, admission/discharge dates
• Geographic subdivisions below state level
• Account numbers, certificate/license numbers
• Device identifiers, URLs, IP addresses in clinical context
• Biometric identifiers, full-face photographs

What Arbitex enforces

Rule area	Arbitex control
45 CFR § 164.312 — Technical safeguards	Block transmission of PHI. Enforcement action logged with framework reference.
45 CFR § 164.502 — Uses and disclosures	BLOCK prevents PHI disclosure to model providers or end users outside permitted use.
45 CFR § 164.312(b) — Audit controls	Complete audit trail of all requests; PHI detections logged by category (not content).
Minimum Necessary standard	Detection at content level; only the matched category is retained in audit, not the content.

Activate

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

---

GDPR

Bundle ID: gdpr Standard: EU General Data Protection Regulation

Scope

GDPR applies to processing of personal data of EU data subjects, regardless of where the processing organization is located. AI systems that process EU resident data through a Gateway are in scope.

What Arbitex detects

The gdpr bundle includes inline DLP detection patterns for EU personal data categories:

• Names and contact information (email, phone, postal address)
• National identification numbers (EU member state formats)
• EU financial identifiers (IBAN)
• IP addresses (treated as personal data under GDPR)
• Special categories: health data patterns, religious/political affiliation indicators

What Arbitex enforces

Article	Arbitex control
Art. 5(1)(f) — Integrity and confidentiality	Encryption in transit; BLOCK action prevents unauthorized disclosure.
Art. 25 — Data protection by design	Policy Engine enforces data minimization at the application layer. PROMPT governance for sensitive operations.
Art. 30 — Records of processing	Audit trail with per-request logging. SIEM export provides the organization’s record of processing activity.
Art. 32 — Security of processing	TLS everywhere; HMAC-chained audit logs; private endpoints for all data stores.
Art. 5(1)(e) — Storage limitation	Arbitex does not retain prompt/completion content. Audit entries log category, not content.

Activate

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

---

GLBA

Bundle ID: glba Standard: Gramm-Leach-Bliley Act (Financial Privacy and Safeguards Rules)

Scope

GLBA applies to financial institutions — banks, lenders, insurance companies, investment advisors. The Safeguards Rule requires protecting customer nonpublic personal information (NPI).

What Arbitex detects

The glba bundle targets financial customer NPI patterns:

• Account numbers and routing numbers
• Social Security Numbers
• Customer names with financial account context
• Income and financial history indicators

What Arbitex enforces

Safeguards Rule requirement	Arbitex control
§314.4(b) — Designate a qualified individual	Not applicable to Arbitex. Organizational governance.
§314.4(c) — Risk assessment	Arbitex audit trail provides the AI system risk signal. Detected NPI transmissions are logged for risk review.
§314.4(d) — Safeguards implementation	BLOCK action prevents NPI transmission through the Gateway. Detection patterns cover GLBA-defined NPI categories.
§314.4(h) — Monitor, test, respond	SIEM integration exports GLBA-relevant enforcement events in OCSF format for your security team.

Activate

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

---

SOX

Bundle ID: sox Standard: Sarbanes-Oxley Act (Sections 302 and 404)

Scope

SOX applies to public companies and their subsidiaries. Section 404 requires management assessment of internal controls over financial reporting (ICFR). AI systems used by finance teams are in scope if they process or generate financial reporting data.

What Arbitex detects

The sox bundle targets financial reporting data categories:

• Internal financial figures in draft reporting context
• Material nonpublic information (MNPI) indicators
• Earnings guidance and forecast language
• Audit communication patterns

What Arbitex enforces

Control area	Arbitex control
ICFR — Information technology general controls	Audit trail for all AI interactions involving financial data. HMAC chain provides tamper evidence.
Access controls	Policy Engine restricts financial data access by group. Model access controls limit which LLM providers receive sensitive financial prompts.
Change management	Audit log captures policy chain changes with admin ID and timestamp.
Monitoring	SIEM export of enforcement events enables continuous monitoring of AI system behavior.

Activate

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

---

BSA/AML

Bundle ID: bsa_aml Standard: Bank Secrecy Act / Anti-Money Laundering

Scope

BSA/AML requirements apply to financial institutions, money services businesses, and broker-dealers. AI systems used in customer communications or transaction processing are in scope for suspicious activity monitoring obligations.

What Arbitex detects

The bsa_aml bundle targets patterns associated with suspicious activity reporting:

• Transaction amounts and account identifiers in structured patterns
• Currency transaction report (CTR) threshold indicators ($10,000+)
• Structuring language indicators
• High-risk jurisdiction references
• Correspondent banking and wire transfer identifiers

What Arbitex enforces

BSA requirement	Arbitex control
Suspicious Activity Reporting	Suspicious patterns in AI interactions are logged with matched category and rule reference. Exported to SIEM for compliance team review.
Customer Identification Program	Sensitive identification data detected in prompts triggers BLOCK or PROMPT action depending on configuration.
Recordkeeping	Audit trail retains enforcement event records for the required minimum retention period (5 years for BSA). Ensure SIEM retention is configured accordingly.

Activate

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

---

CCPA

Bundle ID: ccpa Standard: California Consumer Privacy Act (as amended by CPRA)

Scope

CCPA applies to for-profit businesses operating in California that meet certain revenue or data processing thresholds. AI systems processing California consumer personal information are in scope.

What Arbitex detects

The ccpa bundle targets California consumer personal information categories:

• Identifiers (name, email, IP address, account number, SSN)
• Commercial information (purchasing records, financial data)
• Biometric information
• Geolocation data
• Professional and employment information
• Sensitive personal information (SPI) categories under CPRA

What Arbitex enforces

CCPA/CPRA provision	Arbitex control
Right to Know / Right to Delete	Arbitex does not retain prompt/completion content. Audit entries log category, not PI content.
Data minimization (CPRA § 1798.100(a)(3))	Policy Engine enforces purpose limitation at the AI layer. Groups with different authorized purposes can have different policy rules.
Security obligation (§ 1798.150)	Encryption in transit and at rest. Audit trail for all processing of consumer PI.
Sensitive PI restrictions (CPRA)	BLOCK action prevents unauthorized use or disclosure of CCPA sensitive PI categories.

Activate

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

---

SEC 17a-4

Bundle ID: sec_17a4 Standard: SEC Rule 17a-4 (broker-dealer recordkeeping)

Scope

SEC Rule 17a-4 applies to registered broker-dealers and imposes strict requirements for electronic record retention — immutability, indexing, and third-party audit access.

What Arbitex detects

The sec_17a4 bundle targets broker-dealer business communications and records:

• Trade confirmation and order execution patterns
• Customer account communication markers
• Research report and recommendation indicators
• Regulatory correspondence patterns

What Arbitex enforces

Rule requirement	Arbitex control
17a-4(f) — Electronic storage	Audit trail with HMAC chain provides tamper-evidence. Records retained 90-day active + 2-year archive. Ensure SIEM retention covers the full required period (3 years for most records, 6 years for certain books).
Non-rewritable, non-erasable	HMAC chain detects modification. Archive tier in Azure Log Analytics provides immutable storage.
Indexing	Audit entries are structured JSON with consistent field schema — indexable by SIEM.
Third-party access	SIEM export via OCSF provides the mechanism for designated third-party access to records.

Activate

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

---

Activating multiple frameworks

Organizations with overlapping regulatory obligations can activate multiple bundles simultaneously. Each bundle occupies a position in your policy chain. Use sequence numbers to control evaluation order.

PUT https://api.arbitex.ai/api/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": "bundle_pci_dss", "sequence": 2 },
    { "pack_id": "bundle_glba",    "sequence": 3 },
    { "pack_id": "pack_01HZ_CUSTOM", "sequence": 10 }
  ]
}

A healthcare finance organization might activate hipaa, pci_dss, and glba simultaneously, with all three bundles evaluating before custom organizational packs.

---

See also

• Compliance Bundles — Bundle activation, chain positioning, and read-only rule model
• Audit Data Model Reference — Full audit log schema, OCSF v1.1 class mapping, and HMAC chain details
• Security Overview — Encryption, PKI, access controls, and audit trail design
• Audit chain integrity — HMAC-SHA256 chain verification for tamper-evident records
• SIEM integration overview — Export enforcement events in OCSF format for compliance reporting
• Audit log export — Admin API for audit log search and export
• Policy Engine overview — How bundles interact with custom packs