HomeServicesAPIPricingDocumentationAboutContact
LoginGet Started

Legal

Data protection

How IDEX handles personal data as a matter of operations rather than intention: the roles each of us holds, the controls we run, what happens if something goes wrong, and who to write to.

Last updated: 19 August 2026

How to read this page

This page supplements the privacy policy. Where you submit a third party's identifier for verification, it also forms the data processing terms between you as controller and us as your processor.

1. Roles: who is controller, who is processor

Under the Nigeria Data Protection Act 2023 (the NDPA), the controller decides why and how personal data is processed and the processor acts on the controller's instructions. On this platform both roles exist at once, and it matters which applies.

Processing Our role Your role
Your account, profile and authentication data Controller Data subject
Wallet, ledger, payments and invoices Controller Data subject
Security, audit and rate-limit logs Controller Data subject
Support correspondence you send us Controller Data subject
An identifier you submit for verification, and the result returned Processor, acting on your instruction Controller

Where we act as your processor, we process the data only to perform the verification you submitted, to bill for it, to evidence that it happened and to meet a legal obligation. We do not use it for our own purposes, we do not enrich it, and we do not disclose it to anyone except the provider that performs the check and the recipients listed in section 5.

Where we act as controller — your account, your billing and our own security records — we are responsible for those decisions and answerable to you for them.

2. The scope of processing we carry out for you

The NDPA requires a processing arrangement to be specific. This is ours, for the processing we carry out on your instruction.

Subject matter Identity verification checks you submit through the dashboard or the API
Duration For as long as your account is open, plus the retention periods in section 7
Nature of processing Collection, encryption, transmission to a provider, receipt and normalisation of a result, storage, display to you, and deletion
Purpose Performing the check you asked for, and evidencing that it was performed
Types of personal data National Identification Number, Bank Verification Number, and supporting fields a service requires such as name, date of birth or telephone number; and the result fields the provider returns
Categories of data subject The individuals whose identifiers you submit — for example your customers, applicants, agents or staff
Instruction Your submission of a verification is the documented instruction to process

We will tell you if we believe an instruction from you infringes the NDPA, and we may decline to act on it. We do not process outside your instructions except where a law requires it, in which case we will tell you before processing unless the law forbids that.

3. Technical and organisational security measures

These are the measures actually implemented in the platform, not an aspiration. They are reviewed when the architecture changes and at least annually.

3.1 Technical measures

  • Encryption at rest — submitted identifiers, provider result payloads and two-factor secrets are encrypted with AES-256-GCM, an authenticated cipher, before storage. The key is held in an environment file outside the web root, never in the database and never in the code repository.
  • Encryption in transit — HTTPS only, with HTTP Strict Transport Security. Provider and payment calls are made over TLS.
  • Credential handling — passwords are hashed with a memory-hard algorithm; API secrets are stored only as hashes and compared in constant time; provider credentials are encrypted and never rendered in an interface.
  • Masking — identifiers appear in masked form everywhere except the result panel of the verification the customer paid for.
  • Least-privilege database access — the application connects with a single restricted account; no interactive database access is exposed to the web tier.
  • Injection resistance — every query uses bound parameters with emulated prepares disabled; every rendered value is escaped at the point of output.
  • Request integrity — every state-changing form carries a CSRF token; webhook callbacks are signature-verified; payment and refund operations are idempotent on a unique reference.
  • Session security — HTTP-only, secure, SameSite cookies; session fingerprinting; central session revocation; optional TOTP two-factor authentication with backup codes.
  • Abuse controls — rate limiting in shared storage on sign-in, registration, password reset, the contact form and the API; account lockout after repeated failures.
  • Content security — a strict content security policy with no inline script, plus the usual framing, MIME-sniffing and referrer protections.
  • Integrity of financial records — an append-only ledger; corrections are new opposing entries, never edits.
  • Backups — regular encrypted database backups, held for a limited period and restorable to a point in time.

3.2 Organisational measures

  • Administrative access is granted by role, only to staff who need it, and is separated from customer access.
  • Every consequential action — administrative or otherwise — is written to an audit log with actor, entity, time, IP address and user agent. Sensitive fields are scrubbed before storage.
  • Staff are bound by confidentiality obligations that survive the end of their engagement.
  • Access is reviewed when a role changes and revoked on the day an engagement ends.
  • Changes to the platform are reviewed before release; security-relevant changes are prioritised.
  • Third parties are engaged only under a written agreement containing data protection obligations.

4. Personal data breach notification

A personal data breach is any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Our process is:

  1. Contain. On detection we contain the incident — revoking credentials, closing an exposed path, isolating an affected component — before anything else.
  2. Assess. We establish what data was involved, how many data subjects, the likely consequences and whether the data was encrypted.
  3. Notify the Commission. Where the breach is likely to result in a risk to the rights and freedoms of data subjects, we notify the Nigeria Data Protection Commission within 72 hours of becoming aware of it, and sooner where we can.
  4. Notify you. Where we act as your processor, we notify you without undue delay after becoming aware, with the information you need to meet your own notification duty. We do not wait for a complete picture before telling you that something happened.
  5. Notify data subjects. Where a breach is likely to result in a high risk to data subjects, we notify them, or assist you in doing so, in clear language and without unnecessary technical detail.
  6. Record and remediate. Every breach — notifiable or not — is recorded with its facts, effects and remedial action, and the remedial action is tracked to completion.

If you believe you have found a vulnerability or evidence of a breach, tell us immediately through the contact form with "Security report" in the subject line. Security reports are triaged ahead of everything else in the queue.

5. Sub-processors

To deliver the platform we engage the categories of sub-processor below. Each is engaged under a written agreement imposing data protection obligations no less protective than those we owe you, and each receives only the data it needs for its function.

Category Function Data it receives
Verification providers Performing the identity check behind a service The identifier submitted and any supporting field the check requires
Hosting and infrastructure Running the application and its database All platform data, at rest in encrypted form where the field is encrypted
Payment processors Taking wallet funding payments Amount, reference and the contact details needed to process a payment
Email delivery Sending account, security and receipt emails Your name, email address and the content of the message
Backup storage Holding encrypted database backups Encrypted backup files

No provider that has not been mapped and activated receives anything at all, because a service without a live provider connection cannot be submitted.

You consent to our use of sub-processors in these categories. We will give you reasonable notice before adding a new category or replacing a sub-processor in a way that materially affects the processing of your data, and you may object on reasonable data protection grounds; if we cannot resolve the objection you may terminate the affected service and receive the return of any unused balance. We remain responsible to you for the acts and omissions of our sub-processors. The current named list is available on request from the contact in section 9.

6. International transfers

The platform and its database are operated for the Nigerian market, and customer data is processed accordingly. Where a sub-processor — typically email delivery or a payment processor — processes limited personal data outside Nigeria, we rely on a transfer mechanism permitted by the NDPA:

  • an adequacy determination made by the Nigeria Data Protection Commission in respect of the destination; or
  • contractual safeguards binding the recipient to standards equivalent to those in the NDPA, together with an assessment of the destination's legal environment; or
  • another basis expressly permitted by the Act.

We do not transfer verification identifiers or results outside Nigeria for convenience or cost. Where a transfer is necessary, it is limited to what the function requires, and we record the mechanism relied on.

7. Retention and secure deletion

Personal data is kept only as long as it serves its purpose or as long as the law requires, and deletion is carried out by scheduled processes rather than left to somebody remembering.

  • Verification results and submitted identifiers — cleared 30 days after completion by a scheduled purge, which stamps the record so the history and the ledger still reconcile. After the purge the verification can be proved to have happened and cannot be re-read.
  • Verification metadata — reference, service, masked identifier, status, amount and timestamps are retained with the financial records below, because they evidence a charge.
  • Wallet ledger, payments and invoices — at least six years, as required for accounting and tax records.
  • Account data — for the life of the account. On closure it is deleted or anonymised, except where a record must be kept by law.
  • Audit and security logs — up to 24 months, then removed.
  • Contact messages — up to 24 months from the last message in the thread.
  • Backups — held on a rolling window and overwritten in the ordinary course. Data deleted from the live system persists in a backup only until that backup expires, and a restored backup is re-purged before use.

Deletion means the record is removed or irreversibly anonymised. Where a field was encrypted, deletion of the ciphertext together with the ordinary key management practice leaves nothing recoverable. We do not keep a shadow copy of a purged result "just in case".

On termination of your account, and at your request, we will delete or return the personal data we process on your behalf, other than data we are required to retain by law.

8. Assisting you with data subject requests and compliance

Taking account of the nature of the processing and the information available to us, we will assist you:

  • in responding to a request from a data subject to access, correct, erase, restrict, object to or port their personal data, where that data is one we process on your behalf;
  • in meeting your own security obligations under the NDPA;
  • in notifying a personal data breach to the Commission or to data subjects;
  • in carrying out a data protection impact assessment relating to your use of the platform, and in any prior consultation with the Commission that follows from it.

If a data subject contacts us directly about data we process on your behalf, we will not respond to the substance of the request ourselves. We will tell them to contact you, and tell you promptly that they made contact.

We will make available the information reasonably necessary to demonstrate our compliance with these terms, and will contribute to an audit or inspection you conduct or mandate, on reasonable notice, no more than once a year unless a breach or a regulator requires otherwise, and subject to confidentiality.

9. Data protection contact

We have appointed a data protection contact who is responsible for overseeing compliance with this page and with our privacy policy, and who is the point of contact for data subjects, customers and the Nigeria Data Protection Commission. Where we are required to designate a Data Protection Officer under the NDPA, this is that role.

Subject line to use Data protection
Contact form Send a message
Hours Mon–Fri, 8:00am – 6:00pm WAT
Response time Within one month of a verified request

We will verify the identity of anyone making a request before we act on it, so that the process cannot be used to reach somebody else's data. If you are not satisfied with our response you may complain to the Nigeria Data Protection Commission.

Related documents: privacy policy, terms of service, acceptable use policy.