Security & trust — what we do, and what we don't yet claim

Ichnos is a compliance product, so we hold our own security claims to the same standard we ask of a screening result: say what is true, and say plainly what is not yet proven. This page describes the controls that are actually in place today, and marks clearly where something is intended or on the roadmap rather than already certified. We would rather under-claim and be trusted than over-claim and be wrong.

1. Data handling & residency

Ichnos is hosted in the EU. The data Ichnos processes to do its job is deliberately narrow:

• Wallet addresses and counterparties you submit for screening.
• Entity names and identifiers when you run a name/entity check.
• Screening results — the risk tier, matches, exposure findings and the report we return, retained so you have a defensible record.
• Account and billing data — the identity of your users and your subscription state, needed to operate the service.

Ichnos is multi-tenant, and tenant data is isolated per tenant. Every stored record is scoped to the tenant that created it, and requests are constrained to the caller's own tenant — one customer's screenings, reports and account data are never visible to another. We do not sell customer data, and we do not use one customer's submissions to serve another.

2. Encryption

All traffic to and from Ichnos is encrypted in transit using TLS 1.2+; the public site and the application are served over HTTPS only. At rest, your data lives on our EU hosting infrastructure, with at-rest controls provided by that underlying platform. Where disk- or volume-level encryption-at-rest is not already provided by the platform, hardening it is part of our security roadmap — we would rather describe this honestly than assert an at-rest guarantee we cannot yet fully evidence to an auditor.

3. Access control & authentication

Authentication is handled by a dedicated identity provider (Keycloak) rather than hand-rolled login code. On top of that:

• Role-based access. Users are granted roles, and what a user can see or do is constrained by their role within their own tenant.
• Per-tenant isolation. Access is scoped to the caller's tenant, so a token issued for one customer cannot reach another customer's data.
• Least-privilege API keys. Programmatic access uses API keys scoped to a single tenant, so an integration only ever reaches that tenant's data.
• Signed webhooks. Outbound webhooks are signed with an HMAC so your systems can verify a callback genuinely came from Ichnos and was not tampered with in transit.

4. Auditability

The audit trail is not a bolt-on for Ichnos — it is the product. Every screening is written as an append-only record that captures the dataset versions (which OFAC, EU and OpenSanctions snapshots were in force) and the engine version that produced the result. Because that provenance is stored with each result, every screening is reproducible: you can show a supervisor precisely what data and what logic cleared or flagged a given transfer, on the date it happened.

That means your compliance file is defensible by construction, not reconstructed after the fact. For the full account of how a result is produced and what it does and does not prove, see our screening methodology & limits.

5. Availability & resilience

Ichnos runs on a container-orchestrated (Kubernetes) platform with the operational practices that implies. We aim for:

• Backups & recovery. Our infrastructure supports point-in-time restore of the data stores, and a regular backup programme is part of our security roadmap. We would rather be precise than over-promise here — ask us and we will tell you exactly what backup cadence and restore approach are in place for your data today.
• Monitoring & logging. The platform is under continuous monitoring with centralised logging, so we can detect and diagnose issues rather than wait for a customer to report them.
• Incident response. We follow an internal process to triage, contain and communicate about incidents, and we will notify affected customers of any incident that materially affects their data. A formally documented, externally reviewed incident-response programme is part of our maturity roadmap.

We describe these as our intent and current practice; we do not publish a contractual uptime SLA while Ichnos is in early access, and we say so plainly rather than imply one.

6. Subprocessors

A small number of third parties process data on our behalf so Ichnos can operate. We keep this list short and purpose-bound:

• EU infrastructure hosting — the cloud/hosting provider that runs the Ichnos application and its data stores within the EU.
• Stripe — payment and subscription processing. Card data is handled by Stripe; we do not store raw card numbers.
• Sanctions & watchlist data sources — OFAC (US Treasury), the EU consolidated list, and OpenSanctions. These supply the reference data Ichnos screens against; we send them the data needed to keep those lists current, not your screening submissions.

We will provide a current, named subprocessor list on request as part of a due-diligence or DPA process, and we commit to keeping enterprise customers informed of material changes to it.

7. Compliance posture

Ichnos is built for EU crypto-asset service providers, so our posture is oriented around EU obligations:

• GDPR-aligned. EU-hosted, data-minimising by design, with privacy terms published on our privacy page. We support data-subject and controller obligations as a processor of the data you submit.
• MiCA / Travel Rule oriented. The product exists to help you evidence the checks MiCA and the Transfer of Funds Regulation expect — see MiCA & Travel Rule compliance.

If your security review needs something specific — a subprocessor list, a data-flow diagram, a DPA, or a walkthrough of any control above — reach our security contact at hello@ichnos.dloizides.com and we will get the right detail in front of your team.