Compliance Frameworks Reference

Arbitex ships 8 Compliance Bundles — pre-built Policy Packs with detection patterns and enforcement rules mapped to specific regulatory frameworks. This reference describes what each framework requires, how Arbitex controls address those requirements, and which Bundle to activate.

Certification status

Arbitex is not certified under any of these frameworks. Compliance Bundles are designed to support your compliance program. Your organization remains responsible for demonstrating compliance to auditors. Use “designed for” or “built for” framing in audit and procurement conversations.

---

How Compliance Bundles work

Each Compliance Bundle consists of:

1. DLP detection patterns — Regex, NER, and contextual patterns targeting framework-specific data categories
2. Policy rules — Enforcement actions (BLOCK, REDACT, CANCEL, ALLOW_WITH_OVERRIDE) mapped to rule conditions
3. Audit references — Every enforcement action logs the specific framework requirement referenced (e.g., PCI-DSS Requirement 3.4)

Bundles activate through the Policy Engine and occupy a position in your policy chain. Multiple bundles can be active simultaneously for organizations with overlapping regulatory obligations.

Compliance signal table legend

Status	Meaning
Active	Control is in place in the current release
Planned	Control is designed and on the roadmap; not yet available
Organizational	Requirement that falls outside Arbitex scope; your organization is responsible

---

PCI-DSS

Bundle ID: pci_dss Standard: Payment Card Industry Data Security Standard v4.0 Scope: Any system that stores, processes, or transmits payment card data. An AI Gateway that proxies employee or customer conversations creates risk of cardholder data (PANs, CVVs) appearing in prompts.

Detection coverage

The pci_dss bundle detects:

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

Control mapping

PCI-DSS Requirement	Arbitex control	Status
Req 3 — Protect stored cardholder data	BLOCK action prevents PAN transmission through Gateway; matched category logged, content not retained	Active
Req 3.4 — Render PAN unreadable	BLOCK prevents PAN from reaching downstream model; audit log references PCI-DSS Requirement 3.4	Active
Req 6.4 — Protect web-facing applications	Cloudflare WAF with OWASP ruleset + custom AI proxy rules; mTLS on all service connections	Active
Req 8 — Identify users and authenticate	API key authentication + RS256 JWT; SAML SSO; MFA enforced per org policy	Active
Req 8.6 — MFA for all access	MFA policy enforced at authentication layer; FIDO2/TOTP/SMS supported	Active
Req 10 — Track and monitor all access	Tamper-evident HMAC-chained audit trail; all API requests logged with org, user, action, timestamp	Active
Req 10.3.2 — Protect audit logs	90-day active + 2-year archive; HMAC chain detects modification; SIEM export for long-term retention	Active
Req 10.5 — Retain audit logs minimum 12 months	90-day Arbitex retention; SIEM integration required for full 12-month retention	Active
BYOK / customer key management	Bring Your Own Key (Epic H)	Planned

Activate

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

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

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

---

HIPAA

Bundle ID: hipaa Standard: Health Insurance Portability and Accountability Act — Privacy Rule + Security Rule Scope: Covered entities (healthcare providers, health plans, clearinghouses) and business associates. AI Gateways used by healthcare organizations create risk of Protected Health Information (PHI) appearing in prompts.

Detection coverage

The hipaa bundle detects all 18 HIPAA Safe Harbor identifiers:

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

Control mapping

HIPAA Rule / CFR Reference	Arbitex control	Status
45 CFR § 164.312 — Technical safeguards	BLOCK prevents PHI transmission; enforcement logged with framework reference	Active
45 CFR § 164.502 — Uses and disclosures	BLOCK prevents PHI disclosure to model providers or users outside permitted use	Active
45 CFR § 164.312(b) — Audit controls	Complete audit trail; PHI detections logged by category only, content not retained	Active
45 CFR § 164.312(e)(1) — Transmission security	TLS 1.2+ everywhere; mTLS on internal services and Outpost connections	Active
Minimum Necessary standard	Only matched category retained in audit, not PHI content itself	Active
45 CFR § 164.314 — BAA requirements	Business Associate Agreement available; contact account team	Organizational
BYOK for PHI data encryption	Bring Your Own Key (Epic H)	Planned

Activate

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

---

GDPR

Bundle ID: gdpr Standard: EU General Data Protection Regulation (Regulation 2016/679) Scope: Processing of personal data of EU data subjects, regardless of where the processing organization is located. AI systems processing EU resident data through a Gateway are in scope.

Detection coverage

The gdpr bundle detects EU personal data categories:

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

Control mapping

GDPR Article	Arbitex control	Status
Art. 5(1)(c) — Data minimization	Policy Engine enforces purpose limitation at AI layer; REDACT removes personal data before model sees it	Active
Art. 5(1)(e) — Storage limitation	Arbitex does not retain prompt/completion content; audit entries log category, not content	Active
Art. 5(1)(f) — Integrity and confidentiality	Encryption in transit (TLS 1.2+); HMAC-chained audit logs; BLOCK prevents unauthorized disclosure	Active
Art. 25 — Data protection by design	DLP pipeline runs before model invocation; policy controls enforced before data leaves tenant boundary	Active
Art. 30 — Records of processing	Audit trail with per-request logging; SIEM export provides records of processing activity	Active
Art. 32 — Security of processing	TLS everywhere; application-layer Fernet encryption; private endpoints; HMAC audit integrity	Active
Art. 33 — Breach notification	Audit trail provides detection evidence; incident response procedures are organizational	Organizational
Art. 44–46 — International transfers	Audit trail records cross-border data flows; SCCs and transfer assessments are organizational	Organizational
BYOK / data sovereignty	Bring Your Own Key (Epic H)	Planned

Activate

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

---

GLBA

Bundle ID: glba Standard: Gramm-Leach-Bliley Act — Financial Privacy Rule + Safeguards Rule (16 CFR Part 314) Scope: Financial institutions — banks, lenders, insurance companies, investment advisors. The Safeguards Rule requires protecting customer nonpublic personal information (NPI).

Detection coverage

The glba bundle detects financial NPI categories:

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

Control mapping

GLBA Safeguards Rule Section	Arbitex control	Status
§314.4(c) — Risk assessment	Audit trail provides AI system risk signal; detected NPI transmission events logged for risk review	Active
§314.4(d) — Safeguards — access controls	RBAC at API layer (admin/user roles); group-based model access controls; API key scoping	Active
§314.4(d) — Safeguards — encryption	TLS in transit; Fernet application-layer encryption for stored credentials and configs	Active
§314.4(d) — Safeguards — NPI transmission prevention	BLOCK action prevents NPI transmission through Gateway; detection patterns cover GLBA NPI categories	Active
§314.4(h) — Monitor, test, respond	SIEM integration exports GLBA-relevant enforcement events in OCSF format	Active
§314.4(b) — Qualified individual	Organizational governance; not an Arbitex control	Organizational
§314.4(i) — Service provider oversight	Arbitex functions as service provider; contract provisions are organizational	Organizational

Activate

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

---

SOX

Bundle ID: sox Standard: Sarbanes-Oxley Act — Sections 302 and 404 Scope: Public companies and subsidiaries. Section 404 requires assessment of internal controls over financial reporting (ICFR). AI systems used by finance teams are in scope when processing or generating financial reporting data.

Detection coverage

The sox bundle detects financial reporting risk patterns:

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

Control mapping

SOX Control Area	Arbitex control	Status
ICFR — IT general controls: logical access	API key auth + RS256 JWT + SAML SSO; RBAC enforced at middleware layer	Active
ICFR — IT general controls: audit trail	Tamper-evident HMAC-chained audit trail; all AI interactions logged with admin ID and timestamp	Active
ICFR — Change management	Audit log captures all policy chain changes with admin ID, timestamp, and before/after state	Active
ICFR — Monitoring	SIEM export of enforcement events; continuous monitoring of AI system behavior	Active
Access controls for financial data	Policy Engine restricts model access by group; group-based rules vary enforcement by user classification	Active
Whistleblower protections	Organizational governance; not an Arbitex control	Organizational

Activate

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

---

BSA/AML

Bundle ID: bsa_aml Standard: Bank Secrecy Act / Anti-Money Laundering (31 U.S.C. § 5311 et seq.) Scope: Financial institutions, money services businesses, broker-dealers. AI systems used in customer communications or transaction processing are in scope for suspicious activity monitoring.

Detection coverage

The bsa_aml bundle detects patterns associated with suspicious activity:

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

Control mapping

BSA/AML Requirement	Arbitex control	Status
Suspicious Activity Reporting (31 U.S.C. § 5318(g))	Suspicious patterns in AI interactions logged with matched category and rule reference; exported to SIEM for compliance team review	Active
Customer Identification Program (CIP)	Sensitive identification data in prompts triggers BLOCK or PROMPT action; detection patterns cover CIP-relevant identifiers	Active
Recordkeeping (31 CFR § 1010.430)	Audit trail retains enforcement records; SIEM retention should be configured for BSA minimum retention (5 years)	Active
Currency Transaction Reports	CTR threshold indicators trigger PROMPT governance for compliance team review	Active
Compliance officer designation	Organizational governance; not an Arbitex control	Organizational

Activate

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

---

CCPA

Bundle ID: ccpa Standard: California Consumer Privacy Act (as amended by CPRA — Cal. Civ. Code § 1798.100 et seq.) Scope: For-profit businesses operating in California meeting revenue or data processing thresholds. AI systems processing California consumer personal information are in scope.

Detection coverage

The ccpa bundle detects California consumer personal information categories:

• Identifiers (name, email, IP address, account number, SSN)
• Commercial information (purchasing records, financial history)
• Biometric information
• Geolocation data (precise location)
• Professional and employment information
• Sensitive personal information (SPI) under CPRA: government IDs, financial account credentials, health data, racial/ethnic origin, precise geolocation

Control mapping

CCPA / CPRA Provision	Arbitex control	Status
§ 1798.100 — Right to Know / Right to Delete	Arbitex does not retain prompt/completion content; audit entries log category, not PI content	Active
§ 1798.100(a)(3) — Data minimization (CPRA)	Policy Engine enforces purpose limitation; groups with different authorized purposes have separate policy rules	Active
§ 1798.150 — Security obligation	Encryption in transit (TLS) and at rest (Azure platform AES-256 + Fernet application layer); audit trail for all PI processing	Active
CPRA — Sensitive PI restrictions	BLOCK action prevents unauthorized use or disclosure of CCPA sensitive PI categories	Active
§ 1798.135 — Opt-out of sale/sharing	Organizational signal; not an Arbitex control	Organizational
Privacy policy and notice requirements	Organizational governance	Organizational

Activate

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

---

SEC Reg FD

Bundle ID: sec_reg_fd Standard: SEC Regulation Fair Disclosure (17 CFR Part 243) Scope: Issuers subject to Regulation FD. The rule governs selective disclosure of material non-public information (MNPI) — it is a disclosure rule, not a recordkeeping rule.

Detection coverage

The sec_reg_fd bundle detects material non-public information and regulated financial records in AI traffic:

Entity type	What it covers
insider_info	Material non-public information
material_contract	Material contract and trade agreement references
regulatory_action	SEC regulatory enforcement records
bank_account_number	Financial account identifiers
email	Business communications

Control mapping

Reg FD consideration	Arbitex control	Status
Detection of MNPI before it leaves the organization	DLP inline detection on the entity types above, across every configured channel module	Active
Preventing MNPI disclosure to third-party AI providers	Policy Engine BLOCK or REDACT action on bundle rule match	Active
Evidence that a disclosure control was operating	Tamper-evident audit trail; enforcement events exported to your SIEM via OCSF	Active
Determining what constitutes “material” for your issuer	Organizational judgement; not an Arbitex control	Organizational
Public disclosure obligations after an inadvertent selective disclosure	Organizational process; not an Arbitex control	Organizational

Arbitex does not perform records retention

This bundle was previously published under a “SEC 17a-4” label. That label was withdrawn because it asserted a records-retention capability Arbitex does not provide, and its old bundle id is now rejected by the enforcement plane — use sec_reg_fd. SEC Rule 17a-4 imposes genuine non-rewritable, non-erasable retention obligations on registered broker-dealers — but Arbitex does not perform records retention and does not discharge any part of Rule 17a-4 on your behalf. Satisfying it requires a WORM archive, 3–6 years of retention depending on record type, and a designated third-party download agent, all provided by you. Detection behaviour is unchanged by the rename.

Activate

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

---

Activating multiple frameworks

Organizations with overlapping obligations can activate multiple bundles simultaneously. Each occupies a position in the policy chain.

PUT https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/policy/chain
Authorization: Bearer arb_live_your-api-key
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 — all three bundles evaluate before custom organizational packs.

---

OCSF export for compliance reporting

All enforcement events export to SIEM in OCSF v1.1 format. Each Compliance Bundle enforcement action maps to OCSF class 2001 — Security Finding.

Event type	OCSF class
DLP enforcement (bundle match)	2001 — Security Finding
Authentication events	3002 — Authentication Activity
Administrative changes	3001 — Account Change

Filter SIEM dashboards using:

• class_uid = 2001 — all enforcement events
• cloud.account.uid = <org_id> — org-specific events
• 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.

---

See also

• Security Trust Center — Full security architecture overview
• Compliance Bundles — Activate bundles, configure chains
• Audit chain integrity — HMAC-SHA256 tamper evidence
• Audit Data Model Reference — OCSF v1.1 schema and field mapping
• SIEM integration overview — Export enforcement events to your SIEM
• Policy Engine overview — How bundles interact with custom packs