How elevici handles your data

Client records, risk assessments, due-diligence files, and audit trails entered into elevici are processed exclusively to provide the service. We do not sell data, use it to train any model, or share it with third parties outside the sub-processor list below.

Production data lives in a single Postgres database in our hosting provider's region. Access requires an authenticated session tied to an organisation, with role-based authorization checks on every server action and an audit trail entry for every mutation. Two-factor authentication is required for every account.

Data is retained for the regulatory retention period applicable to KYC records in the customer's jurisdiction (typically eight years post-relationship termination for DFSA / FSRA / ADGM regulated firms). Deletion requests, data-portability requests, and breach notifications are handled under the Data Processing Agreement — see “DPA requests” below.

elevici uses a large language model in three places: a reviewer briefing on the Client Risk Assessment screen, the document classifier in the bulk uploader, and the website ↔ licence-activity consistency check that compares an organisation's public website against the regulated-activity list on its licence. All three calls go through OpenRouter with the request constraint data_collection: "deny" and allow_fallbacks: false.

In plain English: OpenRouter only routes the request to underlying providers that have contractually agreed not to log, store, or train on prompts. If no such provider is online for the requested model, the request fails fast rather than silently degrading to a provider that would retain it. The constraint is applied unconditionally inside our request wrapper, so it is impossible for an LLM call to leave our process without it.

We considered three options for V1 and picked the zero-retention allowlist:

Migration between options is a one-file change in our request wrapper. The redaction contract described below applies regardless of which option is in effect — we do not relax it just because we control the box.

Every byte sent to an LLM endpoint passes through one of three redactors first. Which redactor is used depends on the shape of the input.

Structured client data (CRA briefing)

The reviewer briefing on the Client Risk Assessment screen sees a form-field-name allowlist. Anything not on the allowlist is dropped entirely. Identifiers are replaced with placeholders so the model can write natural prose without ever seeing the actual value.

Schema additions default to “not sent” — a new form field is dropped until it is explicitly added to the allowlist. The choice fails closed.

Free-form document text (bulk-uploader classifier)

The document classifier reads extracted text from uploaded files. A regex pass replaces direct-identifier patterns with named placeholders before the text is sent.

Public-website content (website ↔ licence consistency check)

The website-consistency check fetches a regulated firm's public website and asks the model to compare its service claims against the regulator's licensed-activity list. Although the source content is already public, fetched text passes through the same regex suite used by the document classifier above before any LLM call. Names of services and lines of business are preserved — they are the signal — but contact details, identifiers, and account numbers are replaced with placeholders.

No new sub-processor is involved. The fetcher uses native HTTP with a polite, identifying User-Agent (elevici-website-consistency/1.0), honours robots.txt, and caps the number of pages it visits per host. Sites that can't be parsed (JavaScript-only SPAs, 404s, robots-blocked paths, network failures) record a failed run row with the reason captured in the audit log; analysts see a dedicated “last run failed” banner rather than a dismissable finding. The audit trail is never empty.

All three redactors are unit-tested. Every successful AI call writes an audit-log entry containing the count of redactions performed (per category) and the total characters stripped. The redacted text itself is never written to the audit log — telemetry stores counts, not content.

To help firms onboard quickly, elevici keeps a local, searchable copy of the DFSA public register and uses it to pre-fill a firm's licence, address, and activities during onboarding. That copy is refreshed by a scheduled job that re-reads the regulator's public register.

We are explicit about a limit of this approach, because accuracy of regulated data matters to both our customers and their regulators: cached register details can be up to 7 days out of date. Newly authorised firms, name changes, and firms leaving the register are picked up on every refresh. The only change that can lag is an edit made within an existing firm's record (for example, a newly added authorised individual) that does not change how the firm appears in the register's main list — that is reflected within 7 days at most, because every firm is fully re-read on at least that cadence.

So you are never guessing how current a result is, every register-pre-filled result in the product is stamped with how long ago it was indexed (for example, “Indexed · 3d ago”), and is flagged when it is older than 7 days. Pre-filled values are a convenience, not an authoritative source: always confirm a firm's details against the regulator's own public register before relying on them.

The following sub-processors handle data on elevici's behalf. Each row lists what they do, what data flows to them, and the retention posture.

We notify customers at least 30 days before adding a new sub-processor, by email to the organisation owner. Customers may object during that window per the DPA.