Security and trust at Arkē

Arkē's three pillars process the minimum data necessary to deliver compliance analysis. You control what you send. We process it, return results, and — by default — do not persist anything beyond the request lifecycle.

• → Counterparty screening: receives entity names, jurisdiction, optional registration numbers. No full PAN, no biometric data, no full national ID required for the screening API.
• → Transaction monitoring: receives transaction metadata — amounts, corridors, timestamps, counterparty references. No raw payment credentials, card numbers, or IBAN sequences are required or retained.
• → SAR drafting: receives the facts you provide about the suspicious activity. The narrative is generated and returned to you. Nothing is filed on your behalf or stored without your instruction.
• → Default retention: none. In the MVP tier, data is not stored beyond the request–response cycle. Growth and Scale tiers offer configurable audit-trail retention (30, 90, or 365 days) with explicit opt-in.
• ✗ Never sent to third parties: your counterparty names, transaction data, and SAR drafts are not shared with, sold to, or used to train models for any third party. OpenAI receives only the anonymised analytical prompt — see sub-processors below.

• → In transit: All traffic between clients and Arkē endpoints is encrypted with TLS 1.3. TLS 1.0 and 1.1 are disabled. Cipher suites are restricted to AEAD constructions (AES-GCM, ChaCha20-Poly1305).
• → At rest: Any data persisted when the retention layer ships (Growth/Scale tiers) will be encrypted using AES-256 via the database provider's native encryption. This applies to all application data and backups.
• → Key management: Encryption keys are managed via the cloud provider's KMS (Neon / Render key management infrastructure). Keys are rotated automatically. Arkē does not hold or manage raw key material outside the KMS boundary.
• → API keys: Your Arkē API key is transmitted only over TLS. It is stored hashed (bcrypt) server-side. If compromised, revoke and reissue from your dashboard — old key is invalidated within 60 seconds.

Arkē operates as a data processor under GDPR Article 28. Your organisation is the data controller. You determine the purpose and means of processing. We process only on your documented instructions.

Arkē uses a minimal set of sub-processors. No data is sent to any service not listed here. We notify customers at least 14 days before adding or replacing a sub-processor.

Every Arkē action — sign-in, screening, monitor run, SAR draft — is authenticated against the calling user's identity. We do not share or impersonate accounts. Tier boundaries are enforced server-side; a user on the MVP tier cannot query the Screening API at Growth-tier request volumes, and an API key minted for one workspace cannot read results from another.

• → User sessions (JWT): Every authenticated request carries an HS256 JSON Web Token whose payload is {userId, email}, minted and verified in lib/auth.js (sign / verify at lines 22–45). Tokens expire after 7 days; revocation requires deleting the user row in the users table.
• → API key isolation: Inbound API calls on /api/screen carry an X-API-Key header; the key is recorded against each persisted screening_results row (db/screening.js lines 4–12) so each tenant owns a strictly partitioned result set.
• → Per-user scope: Authenticated screens are written to the screenings table with the caller's user_id foreign key (db/auth.js lines 49–57). A query that omits a user_id filter returns zero rows — there is no cross-tenant read path.
• → Tier boundaries: Free / MVP / Growth / Scale map to per-month screening volume, monitor batch size, and SAR draft retention. Volume checks happen inside the route handler before the database call, so a misuse attempt cannot trigger downstream AI charges.
• → Internal access (least privilege): Production database credentials are stored as deploy-time secrets. Engineering access is via short-lived CLI sessions scoped to a single table at a time during incident response. Standing read access is logged through the cloud provider's audit trail.
• ✗ Never shared with third parties: tenant identifiers, API keys, and JWT secrets never leave Arkē's infrastructure. They are not surfaced in lead forms, error logs, or support tickets, and are not exposed to any of the sub-processors listed above.

Every interaction that produces a compliance artefact is logged with a timestamp, the calling identity, and the structured request payload. The audit record is the same artefact that would be shown to an AMLA supervisor during a review — it must answer the question "who screened what, when, with what evidence" without reconstruction.

• → Screening records: Every authenticated /api/screen call writes a row to screenings (per-user log, FK-bound to users.id) and, when an X-API-Key is supplied, a parallel row to screening_results. Both include entity name, country, score, risk level, and a JSONB matches payload with the OFAC entries that fired.
• → SAR drafts: Every /api/reporting call returns a structured AMLD6 FIU-format draft. The request payload and the returned draft are returned to the caller verbatim — the draft is the audit record; we do not silently transform it server-side.
• → Monitor evidence: Every /api/monitor run returns the original transactions alongside the typology flags that fired, so a reviewer can re-run the analysis offline and confirm the same conclusion.
• → Per-request timing: Each API response carries a timing field — searchTime on /api/screen, analysisTime on /api/monitor, generationTime on /api/reporting — useful for reconstructing the order of events during a supervisory review.
• → Default retention: none. In the MVP tier, only authenticated screening rows are held (the unbounded AI results are returned-only). Growth and Scale tiers enable configurable audit-trail retention at 30, 90, or 365 days, opt-in per workspace.

All Arkē inference, storage, and application hosting runs inside the European Economic Area. No data leaves the EEA at any point in the processing lifecycle. This is a hard architectural constraint, not a configuration option.

• → Application hosting: Render Frankfurt region (eu-central-1). The Arkē API, web interface, and all compute run in EU.
• → AI inference: OpenAI EU API endpoint. Requests are routed to OpenAI's EU infrastructure. Data is not processed outside the EEA by OpenAI under this configuration.
• → Database: Neon PostgreSQL on AWS eu-central-1 (Frankfurt). All stored data, backups, and read replicas remain in EU.
• → DORA Art. 28 relevance: Financial entities subject to DORA must contractually ensure their ICT third-party service providers process data in the EU (or under adequate safeguards). Arkē's EU-only architecture satisfies this requirement by design — no SCCs needed.
• → MiCAR Art. 68 relevance: CASPs must ensure outsourced functions comply with applicable data protection and residency requirements. Arkē's EU processing satisfies the MiCAR outsourcing framework for compliance tooling.

If you find a security vulnerability in Arkē, we want to know. We commit to responding promptly, keeping you informed, and crediting researchers who report in good faith.

• → Report to: security@arke.polsia.app. Encrypt sensitive reports with our PGP key (published on request).
• → Acknowledgement: We acknowledge receipt within 1 business day. Initial triage assessment within 3 business days.
• → Disclosure window: 90-day coordinated disclosure window from date of acknowledgement. We will fix and publish a summary within this window, or request a single extension if a fix requires significant architectural change.
• → Bug bounty: No monetary bounty programme at this stage. Researchers who report valid vulnerabilities are credited publicly (with permission) in the security acknowledgements log.
• ✗ Out of scope: Social engineering, physical attacks, denial of service, vulnerabilities in third-party software outside Arkē's control, and issues already reported by another researcher.