Architecture Overview

Last updated: 2026-08-17

This page describes how the platform actually fits together: the components, how a request travels through them, where data lives, and what the platform depends on. It is written for technical and security reviewers; the security properties of each part are covered in depth in the Security Overview.

The system at a glance

Everything inside the boundary below runs within Lexabit's own hosted infrastructure in the EU.

   Users & API clients
   customer portal (SPA) · admin panel (SPA) · direct API clients
         │
         │  HTTPS (TLS + HSTS)
         ▼
┌─ Lexabit platform — EU-hosted infrastructure ─────────────────────┐
│                                                                   │
│   Backend API — versioned service APIs (/{service}/v1)            │
│   authentication · scoping · permission checks on every request   │
│         │                                                         │
│         ├──►  Application database                                │
│         │     client, case, user, account & transaction data      │
│         │                                                         │
│         ├──►  Data Registry — self-hosted registry service        │
│         │     public company & registry data — no customer data   │
│         │                                                         │
│         └──►  Background workers — isolated job queues            │
│               account sync · transaction auditing · health        │
│                                                                   │
│   Integration layer — pluggable connectors to external providers  │
└─────────┬─────────────────────────────────────────────────────────┘
          ▼
   Third-party providers & data sources
   open-banking (PSD2) providers · public business registries

The backend is a single API exposing versioned service APIs (/{service}/v1/...). The customer portal and administration panel are single-page applications with no backend of their own — every capability goes through the same API, so the access-control path below applies to all surfaces equally.
There is one shared application database — isolation between customers is enforced in the application layer on every request, not by separate databases per customer.
The Data Registry is a separate, self-hosted registry service deployed inside the same infrastructure. It is deliberately segregated by content: it holds only public business-registry data (companies, registered role holders, beneficial owners) and never the customer's own client, case, or user data.
The integration layer connects the platform to external providers through a common integration framework — providers are pluggable behind it and engaged per provider. Which providers are active, and on what basis, is documented on Banking & Data Providers rather than hard-wired into the architecture.

What happens on a request

Every API request passes through the same pipeline before any data is returned:

request ──► TLS (HTTPS + HSTS)                        transport encryption   ENC-5
        ──► Authentication (session / API token)      who is the actor?      AUTH-2
        ──► Scope resolution (X-Scope header)         which entity context?
        ──► Visibility check                          may the actor SEE it?
        ──► Entitlement & action check                may the actor DO this?
        ──► Filtered response                         only what the actor may see

The scope, visibility, and entitlement stages are the entity-permissions system's four-layer model (Authentication → Visibility → Entitlement → Action), enforced across the v1 API — including generated reports and documents. The Security Overview describes the mechanism in full.

Where data lives

Data	Store	Notes
Client, case, user, and account/transaction data	Application database (MySQL)	Single shared database; application-layer isolation per request
Public company & registry data	Data Registry — self-hosted registry service (MongoDB)	Public-registry content only, fed by national business registries; no customer data
Uploaded files & generated documents	DO object storage (AMS3)	Generated reports/documents are permission-gated; signed-URL storage for uploaded profile media is Planned
Bank login credentials	Nowhere	End users authenticate at their bank; Lexabit never receives them
Integration/provider credentials	MySQL, encrypted	AES-256 via the credential-management layer

The full data map, by category and source, is on Data Protection & GDPR.

Data flows in and out

Banking data (in) — retrieved through regulated open-banking providers under a PSD2 consent authorized in the bank's own flow, by the account holder or another party entitled to access the accounts. Consents have individual lifecycles and expiry is enforced automatically. The currently active provider is listed on Banking & Data Providers.
Registry data (in) — public national business registries feed the self-hosted Data Registry.
Email (out) — transactional notifications via Mailtrap (Railsware).
Monitoring (out) — a public /health endpoint is polled externally by UptimeRobot; per-service health checks run internally.

Background work — bank-account synchronisation, transaction auditing, and health monitoring — runs on isolated, database-backed queues rather than inline in the request cycle.

Environments & deployment

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. Production releases are tag-based and deployed through a controlled pipeline with environment-scoped secrets and approvals — no ad-hoc production changes.

Key technical dependencies

Dependency	Role
DigitalOcean (Amsterdam, EU)	Hosting: application server, databases, object storage, CDN
Laravel 11 / PHP	Backend framework — parameterized queries, CSRF protection, output escaping by default
React	Customer portal and administration panel SPAs
MySQL / MongoDB (self-hosted)	Application database / Data Registry storage
Laravel Sanctum	API and session authentication
Enable Banking	Open-banking (PSD2) account and transaction access
Let's Encrypt	TLS certificates; HTTPS with HSTS on all traffic
Mailtrap (Railsware)	Outbound transactional email
Google Workspace	Internal business email and support correspondence
UptimeRobot	External availability monitoring

Third parties that process customer personal data, with data categories and regions, are listed on the Sub-processors & Service Providers page.

Questions

Architecture questions from security reviews: security@lexabit.com.

The system at a glance​

What happens on a request​

Where data lives​

Data flows in and out​

Environments & deployment​

Key technical dependencies​

Questions​