Stripe-Delegated Sanctions Compliance with supplementary platform controls, immutable audit logging, and GDPR/CCPA-compliant data handling.
exact.works delegates primary sanctions screening to Stripe, our payment processor. Stripe maintains comprehensive OFAC compliance programs and performs identity verification on all connected accounts. exact.works supplements this with additional platform-level controls to catch obvious bad actors before they reach Stripe onboarding.
Full compliance details are documented in our Platform Terms of Service, Section 1.8:
Defense-in-depth compliance controls
exact.works implements a multi-layered compliance architecture where Stripe serves as the primary screening authority, supplemented by platform-level controls at each stage of the seller onboarding and transaction lifecycle.
Stripe is documented as the primary sanctions screening provider in our Terms of Service.
Lightweight OFAC SDN check at account creation to catch obvious bad actors before Stripe.
Stripe account status verified at execution time for every transaction.
Every screening event logged permanently in the SanctionsScreening table.
Specially Designated Nationals List
Our Tier 2 screening checks names against the U.S. Treasury's OFAC Specially Designated Nationals (SDN) list. This is a supplementary check designed to catch obvious matches before they reach Stripe's more comprehensive screening.
Official OFAC SDN list downloaded directly from the U.S. Department of the Treasury website.
Automated cron job refreshes the SDN data daily with atomic pointer swap for zero-downtime updates.
SDN data stored in Vercel KV for low-latency serverless access with version control.
GDPR/CCPA Compliance
exact.works balances regulatory evidence requirements with data minimization principles. SanctionsScreening records are retained permanently for compliance, but personally identifiable information is minimized according to GDPR/CCPA.
IP addresses in SanctionsScreening records are automatically nullified after 90 days. A daily cron job at 3:00 AM UTC handles this cleanup.
Screening records themselves are NEVER deleted. They serve as regulatory evidence that compliance checks were performed.
While screening records cannot be deleted due to regulatory requirements, users may request access to their screening history and the personal data we hold. Contact [email protected] for data access requests.
SanctionsScreening Record Fields
Every screening event creates an immutable record in the SanctionsScreening table. These records support regulatory audits and demonstrate due diligence.
| Field | Type | Description |
|---|---|---|
| id | String | Unique screening event ID |
| userId | String | User being screened |
| screenedName | String | Name that was screened |
| screenedEntity | String? | Entity name (if applicable) |
| screenType | Enum | ACCOUNT_CREATION, TRANSACTION, MANUAL |
| screenMethod | String | OFAC_KV_CHECK, STRIPE_STATUS, etc. |
| result | Enum | CLEAR, POTENTIAL_MATCH, ERROR |
| matchDetails | JSON? | Match information if flagged |
| ipAddress | String? | IP address (nullified after 90 days) |
| screenedAt | DateTime | Timestamp of screening |
F500-grade security infrastructure
exact.works implements defense-in-depth security controls designed to meet the requirements of Fortune 500 procurement teams and enterprise security reviews.
All data stored in exact.works is encrypted at rest using AES-256. Database encryption is provided by Supabase infrastructure.
All responses include security headers protecting against common web vulnerabilities.
All state-mutating operations are logged to an immutable audit trail with user context, timestamps, and action details.
Enterprise OIDC single sign-on — Okta, Azure AD, or any OIDC-compliant identity provider — is not available. SAML 2.0 and SCIM provisioning are not built, and we are not giving a date for either.
Multi-framework governance infrastructure
The standard form and its schedules are drafted against the major AI regulatory frameworks, so a deployer can point at where each obligation is written down. We do not observe, record or assess anyone's compliance: the evidence is produced by the deployer, kept by the deployer, and read by their auditor. Nothing below is a certification, and none of it is evidence we hold on your behalf.
The record schedule names the fields Article 12 requires — who provided oversight, operation period, legal effect, incident classification — as records the deployer keeps. Specifying the standard is ours; keeping the log is theirs, in their own storage, and it is theirs to produce to a competent authority.
Each risk below is allocated in the agreement — a warranty, a scope limit, an approval point, or a record one party owes the other. That is not the same as a control that prevents it: preventing these is your stack's job, and the configuration we emit is what tells your stack how to be set. Read the table as “the contract says whose problem this is,” not as coverage.
| # | Risk | Mechanism | Status |
|---|---|---|---|
| 1 | Prompt Injection | SAISA Section 3.7 Content Environment Warranty | IN TERMS |
| 2 | Insecure Tool Use | ToolManifestEntry typed schema | IN TERMS |
| 3 | Excessive Agency | Authorised envelope, compiled to a tool allowlist | IN TERMS |
| 4 | Insufficient Human Oversight | Human approval points, agreed and emitted | IN TERMS |
| 5 | Supply Chain Vulnerabilities | Delegation terms + the seal over agreed scope | IN TERMS |
| 6 | Insecure Output Handling | Acceptance criteria + the record standard | IN TERMS |
| 7 | Sensitive Data Leakage | Confidentiality terms between the two parties | IN TERMS |
| 8 | Overreliance on Agents | Human acceptance as a term, not an assumption | IN TERMS |
| 9 | Data Poisoning | Section 3.8 Knowledge Base Integrity Warranty | IN TERMS |
| 10 | Model DoS | Budget Ceiling (caps blast radius) | PARTIAL |
Annex A controls are mapped to the clauses that carry them, so a customer building an AI management system can show their certification body where each control is written down. The mapping is a drafting aid. It is not a certification, and the evidence an auditor assesses is the customer's own.
exact.works is a drafting tool, not an AI system and not a control plane. Where a subcategory corresponds to something two parties can agree in writing, the form says so and the mapping points at the clause. Satisfying it is the deployer's work, on their own deployment.
Counts are of subcategories the agreement speaks to. 26 are partial — the term exists but the work is buyer-side — and 7 are organisational processes no contract can reach.
We do not hold your conformity evidence, and we cannot hand an auditor a package of it. Execution records go from your agent to your own storage, in your own account, and both parties to an engagement should keep a copy so the party holding the evidence is never the only one who has it.
What we publish instead: the standard form and its schedules, the clause-level mappings above, and a canonical hash over the terms as agreed so the version is not arguable. The gap that closes is real — operational telemetry has no hash chain, no sequence-gap detection and no third-party anchor.
For questions about our compliance framework or to report a concern: