Security Overview

Last updated: 2026-08-17

Lexabit is a platform for working with transaction data — compliance and financial intelligence for law firms, financial institutions, and other organisations. This page describes the security architecture as it operates today. Where a control is on our roadmap rather than live, it is labelled Planned — we do not present planned controls as current.

Platform architecture

Lexabit's backend is a Laravel 11 API; the customer portal and administration panel are React single-page applications that consume it over HTTPS. The platform is hosted by DigitalOcean in Amsterdam, keeping infrastructure and data within the EU.

The application database is MySQL, with a self-hosted MongoDB instance on the same server used only for public business-registry data — company information and registered-role information from national registries — it does not contain the customer's own client, case, or user data. Background work — transaction auditing, bank-account synchronisation, and health monitoring — runs through Laravel's database-backed queue system. Production runs on its own dedicated infrastructure, fully separated from all non-production environments; development and staging are separate deployments, each with its own configuration and data, hosted on shared non-production infrastructure.

Tenant isolation

Lexabit runs on a single shared application database — it does not use a separate database per customer. Isolation is enforced in the application layer by the entity-permissions system on every request: each request carries an X-Scope header identifying the entity context (tenant, group, project, client, or case); middleware resolves that header and verifies the authenticated actor can access the requested scope through structural relationship chains and explicit visibility assignments. This follows a four-layer model — Authentication, Visibility, Entitlement, and Action — and scope and permission checks are enforced across the v1 API. Generated reports and documents are access-controlled behind the same permission and scope checks.

Access control

Access to data and actions is governed by a role-based, fine-grained entity-permissions system covering every application entity — tenants, clients, cases, groups, and projects. Every request is evaluated against the authenticated actor's specific role assignments and explicit visibility grants for the requested scope: results are filtered to what the actor can see, and each action is separately permission-gated, rather than access being implied by authentication alone. These checks are enforced across the v1 API.

Authentication

User passwords are hashed with Argon2id before storage. API and single-page-application sessions are authenticated using Laravel Sanctum, and application-to-application access uses Sanctum-issued API keys and OAuth2 client-credentials tokens. Sign-in via Google and Microsoft is supported using OAuth with PKCE, where enabled for a tenant. Session cookies are set with the Secure, HttpOnly, and SameSite=Lax attributes in all deployed environments. Login attempts are rate-limited (6 per minute per IP) and password-reset requests are rate-limited separately (5 per 15 minutes); a credential is locked for 15 minutes after 5 consecutive failed login attempts.

Two-factor authentication (2FA) is Planned and not yet available.

Encryption

All traffic to Lexabit is served over HTTPS (TLS, via Let's Encrypt certificates) with HSTS enabled.

Integration credentials — the secrets Lexabit uses to connect to external providers — are encrypted at rest using AES-256 via the application's encryption layer. Client national identity numbers are also column-encrypted. Column-level encryption at rest is currently limited to these two categories; other application data (including transaction records) is protected by the access controls described above and by infrastructure-level controls rather than field-level encryption.

Banking data & PSD2

Lexabit retrieves banking data through regulated third-party open-banking (AISP) providers, each supervised by its national financial supervisory authority. The currently active provider is Enable Banking; the platform has integration support for additional providers (such as Neonomics), which are only presented as active when they actually are. Customers authenticate directly with their bank during the connection flow; Lexabit never receives or stores bank login credentials. Connected accounts are covered by individual consents, each with its own status and lifecycle; consents expire and must be renewed, and expired or revoked consents are enforced automatically.

Provider credentials Lexabit uses to authenticate with our banking providers are encrypted at rest; per-connection session data is held server-side.

Access granted to a connected banking application is fail-closed: an app's permitted actions are hard-capped to an explicit allowed set at connection time, and an unrecognised app is denied by default rather than implicitly trusted. Transaction data retrieved from connected accounts is subject to the same entity-permission and scope checks as the rest of the platform.

Monitoring & availability

Lexabit publishes a public /health endpoint reporting overall platform status, a token-gated endpoint with detailed diagnostics, and a per-service health check for each core service. The public endpoint is monitored externally by an uptime-monitoring service (UptimeRobot) to alert on availability issues. Background and asynchronous work — including transaction auditing, bank-account synchronisation, and health monitoring itself — runs through dedicated, database-backed job queues rather than inline in the request cycle.

Security contact

Report vulnerabilities or security questions to security@lexabit.com.