Data processing agreement

This agreement governs Baobyte’s processing of personal data on behalf of a customer institution in connection with the Baobyte AML Suite. It is intended to form part of the agreement between the parties and to be read with the terms of service.

The execution mechanism and the order of precedence between this agreement, the master agreement and the Order have not been settled. Where they conflict on data protection matters, this agreement is intended to prevail; that must be stated expressly and confirmed by counsel.

Where the Platform is deployed on the institution’s own infrastructure and Baobyte holds no copy of the data, Baobyte’s processing is limited to what it is given during a support engagement. This agreement still applies to that processing.

Terms such as personal data, processing, data subject, data controller, data processor and personal data breach have the meanings given to them in the Nigeria Data Protection Act 2023 and any subsidiary legislation or guidance issued under it.

Customer Personal Data means personal data contained in Customer Data and processed by Baobyte on the institution’s behalf. Sub-processor means a third party engaged by Baobyte to process Customer Personal Data. Applicable Data Protection Law means the Nigeria Data Protection Act 2023 and any other data protection law applicable to a party in respect of the processing.

The institution is the controller of Customer Personal Data. It determines the purposes and means of processing, decides what is collected, sets the risk model, and makes every regulatory determination. Baobyte is a processor acting on the institution’s documented instructions.

Baobyte is an independent controller of a limited category of data that is outside this agreement: account and contact details of the institution’s administrators and users, support correspondence, and its own operational records. That processing is described in the privacy policy.

Where the institution instructs Baobyte to transmit personal data to a screening or identity-verification provider under the institution’s own data licence, that provider is generally the institution’s own processor or an independent controller rather than a Baobyte sub-processor. The position must be confirmed per provider.

Baobyte will process Customer Personal Data only on the institution’s documented instructions, which comprise this agreement, the Order, the Platform’s configuration as the institution sets it, and any further written instruction the parties agree.

If Baobyte is required by law to process otherwise, it will inform the institution before doing so unless the law prohibits that notice. If Baobyte considers an instruction to infringe Applicable Data Protection Law, it will inform the institution.

Baobyte will not sell Customer Personal Data, use it to train a model for any purpose other than the institution’s own service, or use it for its own product analytics.

Baobyte will ensure that personnel authorised to process Customer Personal Data are bound by confidentiality obligations, are granted access on a least-privilege basis, and are trained on the handling requirements applicable to financial-crime data.

Baobyte will implement appropriate technical and organisational measures. Those measures are described in Annex 2 and in more detail at trust centre → security. Note the honest position recorded there: the measures are implemented, and no independent certification or penetration test has been obtained.

The institution provides a general authorisation for Baobyte to engage sub-processors, subject to the conditions in this section. The current register is published at trust centre → subprocessors, which is presently unpopulated.

Baobyte will:

• impose on each sub-processor, by written contract, data protection obligations materially equivalent to those in this agreement;
• remain fully liable to the institution for the performance of each sub-processor’s obligations; and
• notify the institution before a new sub-processor begins processing, allowing the institution to object on reasonable data protection grounds.

The notice period, the objection window and the consequence of a sustained objection are not stated in this draft.

Taking into account the nature of the processing, Baobyte will assist the institution:

• with data subject requests, by providing the Platform functionality that lets the institution locate, export, correct, restrict and — where lawful — cryptographically erase a subject’s data, and by promptly forwarding any request received directly rather than responding to it;
• with security obligations, by making available the information described in Annex 2 and by notifying personal data breaches under section 8;
• with impact assessments and prior consultation, by providing the documented description of the processing, the security measures and the data flows that an assessment requires.

One limitation is stated plainly because it recurs: an AML statutory retention obligation or a legal hold can lawfully override an erasure request. The Platform is deliberately built so that a purge which would breach a hold is refused rather than partially applied, and so that an erasure record does not by itself decide the retention boundary. The institution, as controller, decides how to respond to the subject; the Platform will not silently destroy a record the institution is required to keep.

Baobyte will notify the institution without undue delay after becoming aware of a personal data breach affecting Customer Personal Data.

No notification period is stated in this draft. It must be negotiated, and it must be a period that can actually be met.

The notification will describe, so far as known at the time:

• the nature of the breach, including the categories and approximate volume affected;
• the likely consequences;
• the measures taken or proposed to address it and to mitigate its effects; and
• a contact point for further information.

Information will be provided in phases where it is not all available at once. Baobyte will not make a notification to a supervisory authority or to data subjects on the institution’s behalf unless instructed to. The internal handling process — evidence preservation, containment, the affected-data determination and the notification decision — follows the incident response runbook summarised at trust centre → security.

Baobyte will make available the information reasonably necessary to demonstrate compliance with this agreement, and will allow for and contribute to audits, including inspections, conducted by the institution or an auditor it mandates.

Audit frequency, notice, scope, cost allocation and confidentiality terms are not stated in this draft. Nor is there an independent audit report that could be offered in place of an inspection: none exists, as recorded at trust centre → certifications.

An audit must not require Baobyte to disclose another customer’s data, or to grant access that would itself breach a security control. Where an inspection needs access to a tenant, the Platform’s time-bound, reason-coded and audited support-session mechanism is the route.

Baobyte will not transfer Customer Personal Data outside Nigeria except on the institution’s instruction or as permitted by this agreement, and only where the transfer satisfies Applicable Data Protection Law — an adequate destination, an appropriate safeguard, or an available derogation. No transfer position is established in this draft, because the hosting arrangements and the sub-processor register have not been settled. In an institution-operated deployment the institution controls the location of the data and no transfer by Baobyte arises.

On termination or expiry, and at the institution’s election, Baobyte will return Customer Personal Data or delete it, and delete existing copies, unless legally required to retain it.

Three practical constraints must be recognised in this clause rather than discovered afterwards, and counsel should draft around them:

• Statutory retention. AML record-keeping obligations may require the institution to retain records beyond the end of the subscription. The export mechanism and the wind-down window matter more than the deletion promise.
• Evidence immutability. Evidence objects are written once and the storage adapters have no delete operation. Deletion of evidence is achieved cryptographically — by destroying the subject or tenant key material so the ciphertext is unrecoverable — rather than by removing objects. That is a stronger guarantee in practice but a different one in wording, and the clause must say what is actually done.
• Audit chain integrity. Audit events are append-only and hash-chained. Removing an event would break verification for every event after it, which is the point of the design. What the record contains, and for how long, is governed by the retention policy rather than by deletion of individual entries.

The relationship between liability under this agreement and any cap in the master agreement is not stated in this draft. Whether data protection liability sits inside the general cap, attracts a separate higher cap, or is carved out, must be settled by counsel alongside the limitation clause in the terms of service.

Subject matter. Provision of the Baobyte AML Suite and related support to the institution.

Duration. The term of the subscription, plus any wind-down period and any period for which retention is required by law. The retention position is unresolved — see the privacy policy.

Nature and purpose. Storage, structuring, retrieval, analysis and disclosure to the institution of personal data for the purpose of customer due diligence, transaction monitoring, sanctions and PEP screening, investigation, regulatory reporting, audit and record-keeping.

Categories of data subject. The institution’s customers and prospective customers; their beneficial owners, directors, officers and authorised signatories; counterparties to transactions; and the institution’s own personnel who use the Platform.

Categories of personal data. Identity and contact data; government and financial identifiers; identity and address evidence documents; ownership and control relationships; transactional data; risk ratings and their inputs; screening match candidates with their source and version; alerts, cases, analyst notes and decisions; report content; and audit records of access and action.

Sensitive and high-risk data. Data revealing that a person has been screened, alerted on, investigated or reported, and data that may reveal political exposure or alleged criminal conduct. The tipping-off and confidentiality implications are described in the privacy policy.

The measures below are implemented in the Platform. Their detail, and the limits of what has been independently verified, are at trust centre → security.

• Isolation. Tenant context resolved before any handler runs; row-level security forced at the database; composite foreign keys preventing cross-tenant references; a request with no unambiguous tenant fails closed.
• Access control. Authentication delegated to the institution’s identity provider; authorisation declared per API operation in the contract and enforced by the router; role-based permissions with separation of duties; opaque, digest-only, individually revocable service-account credentials.
• Encryption. Field-level encryption of sensitive identifiers under per-subject keys in an envelope hierarchy; HMAC blind index for search; documents and filenames encrypted before storage; transport security enforced, with plaintext object storage and plaintext identity-provider connections refused in production.
• Integrity. Append-only per-tenant audit hash chain with on-demand verification; write-once evidence storage with no delete operation; four-eyes approval on sensitive decisions with same-actor approval refused.
• Availability and resilience. Documented backup, restore and key-escrow obligations; a required alert set including audit-chain verification failure and backup age; a documented recovery sequence and exercise schedule. Recovery objectives are the institution’s to set — see trust centre → uptime.
• Data minimisation in telemetry. Identifiers, raw URLs, job arguments and error text excluded from metric labels; no secrets or decrypted personal data in logs; aggregate analytics with small-cell suppression applied inside the query.
• Support access. Explicit, time-bound, tenant-scoped, reason-coded and audited, with the session record available to the tenant.
• Supply chain. Pinned dependencies and images; signature-verified regulatory content packs, with unsigned packs refused in production; distroless non-root runtime images with a read-only root filesystem.

There is no approved sub-processor list. The register at trust centre → subprocessors publishes the categories of dependency that will require assessment, with every entity, location and status explicitly unconfirmed. Whether this annex incorporates that page by reference — and therefore whether an edit to a web page amounts to a variation of the contract — is a question for counsel.