Trust centre
Subprocessors
A subprocessor is a third party engaged to process personal data on a processor's behalf. This page is the register of those engagements — what each one does, which categories of data it reaches, and where the processing happens.
Scope
Which dependencies are ours, and which are yours
This is the question that decides whether a row on this page is a subprocessor at all, and it is answered by the deployment shape rather than by the product.
In the institution-operated deployment shapes — a single node on-premise, a single VPS, an air-gapped data centre, or the institution’s own Kubernetes cluster — the database, the object store, the identity provider, the mail relay and the telemetry platform are contracted, configured and operated by the institution. They are the institution’s own processors, not Baobyte’s subprocessors, and Baobyte holds no copy of the data in them.
In a Baobyte-hosted deployment, those same dependencies would become Baobyte subprocessors and would need to appear on this register with a signed agreement behind each one. Whether that deployment shape will be offered, in which region, and by which contracting entity has not been settled.
Screening and identity-verification providers are a separate case again: the institution generally holds the data licence directly, and the platform integrates with the provider under the institution’s contract. The integration guide requires each provider to have an impact assessment, a data-minimisation contract and explicit timeout and failure semantics before it is put into production.
Register
Dependency categories requiring assessment
The identity, location and contracting party for every row below is outstanding.
Placeholder — TODO: confirm actual subprocessors and data-residency. Every entity name, location and status in this table is a placeholder; nothing here has been contracted, assessed or approved. Replace with sourced, approved content before this page is made public.
| Dependency | Service provided | Personal data reached | Processing location | Status |
|---|---|---|---|---|
| Identity provider (OIDC)TODO — vendor not confirmed | Authenticates human users and issues the tokens the platform validates. | Authentication identifiers, user profile claims, session metadata. | TODO — residency not confirmed | Not confirmed |
| Managed PostgreSQLTODO — vendor not confirmed | System of record for customer, transaction, case, report and audit data. | All categories held by the platform, including encrypted identifiers and suspicion data. | TODO — residency not confirmed | Not confirmed |
| Object storage (S3-compatible)TODO — vendor not confirmed | Stores encrypted CDD documents, case attachments and evidence exports. | Ciphertext only. Documents and filenames are encrypted before the adapter sees them. | TODO — residency not confirmed | Not confirmed |
| Sanctions, PEP and adverse-media data providerTODO — vendor not confirmed | Supplies the watchlist data screened against, and in some designs performs the match. | Names, dates of birth, nationalities and other identifiers submitted for screening. | TODO — residency not confirmed | Not confirmed |
| Identity verification providerTODO — vendor not confirmed | Verifies national and corporate identifiers submitted during onboarding. | Identity numbers and the attributes submitted for matching. | TODO — residency not confirmed | Not confirmed |
| Email relay (SMTP)TODO — vendor not confirmed | Delivers scheduled compliance and board report packs to approved recipients. | Recipient addresses and aggregate report artefacts. Not customer records. | TODO — residency not confirmed | Not confirmed |
| Telemetry and log platformTODO — vendor not confirmed | Receives metrics, logs and optional traces for operational monitoring. | Operational metadata. Identifiers, raw URLs and decrypted data are excluded by design. | TODO — residency not confirmed | Not confirmed |
| Container image registryTODO — vendor not confirmed | Distributes the application images the runtime nodes pull. | None. No personal data is processed by this dependency. | TODO — residency not confirmed | Not confirmed |
| Hosting and computeTODO — vendor not confirmed | Runs the API, worker and web tiers. Applies only to a Baobyte-hosted deployment. | All categories held by the platform, in encrypted form at rest. | TODO — residency not confirmed | Not confirmed |
Governance
How this register is meant to work once it is populated
The process below is the one the data processing agreement draft commits to. It is described here so that the commitment and the register stay in step.
Before an engagement
A prospective subprocessor is assessed for the data it would reach, the lawful basis and transfer mechanism for any processing outside Nigeria, its security posture, and its failure semantics. A written agreement imposing materially the same obligations must be in place before any personal data reaches it.
Notice of change
Customers are to be notified before a new subprocessor begins processing, with an opportunity to object. The notice period and objection window have not been agreed and are therefore not stated on this page.
Ongoing review
Each engagement is reviewed at least annually and after any material incident or change in the data it processes. The integration guide additionally requires a provider’s timeout, retry and circuit-breaker behaviour to be re-verified, since an unavailable provider must never be recorded as a clean result.
The related documents are the data processing agreement, which sets out the sub-processing obligations, and the privacy policy, which describes the categories of recipient. Both are unreviewed drafts pending legal counsel.
Vendor assessment
Ask about a specific deployment
The honest answer to “who are your subprocessors” depends on how the platform is deployed for you. Tell us the shape you are evaluating and we will tell you which third parties are in scope and which are your own.