NDPA Section 24: what enterprise migration platforms must do about automated decision-making

Nigeria's Data Protection Act 2023 (NDPA) Section 24 establishes the right of data subjects not to be subject to decisions based solely on automated processing, including profiling, which produces legal or similarly significant effects.

If you're building a migration platform with AI agents that make decisions about how customer data moves between systems — including dedupe, equivalence resolution, exception classification, and audit-trail generation — Section 24 applies to you. Here's how we read it and what it shaped about Migratio's design.

What "solely automated" means in practice

The keyword is solely. Section 24 doesn't prohibit automated decision-making; it requires that when a decision has legal effect on a data subject, a human be meaningfully in the loop. The bar for "meaningfully" is non-trivial: rubber-stamp approvals don't count.

For Migratio, this shapes how the Reconciliation Agent and Naming Library escalate. Above a confidence threshold, the agent proposes a resolution — it doesn't apply it. A human compliance officer reviews the proposal, sees the agent's reasoning, sees the underlying data, and approves or rejects. Their approval is captured in the audit trail with their name, timestamp, and a free-text reason field they're required to fill.

The agent-explanation requirement

Section 24's right of explanation requires that when an automated decision affects a data subject, that subject can request — and receive — a meaningful explanation of how the decision was reached. For migration platforms, this means every agent decision must produce an auditable explanation in human-readable form.

We design every agent in Migratio to produce three artifacts per decision:

• ●The input — the source record(s) the agent considered
• ●The reasoning — the rules applied, the confidence score, the model version, the rule library version
• ●The proposed action — what the agent recommends, and what threshold it crossed to recommend it

The right to challenge

Data subjects have the right to challenge automated decisions. For migration platforms, this maps to a customer-facing process where any individual taxpayer, bank customer, or licensee can request a review of how their record was migrated. The review must be conducted by a person who wasn't involved in the original decision.

Operationally, this means platforms need:

• ●A request intake mechanism (web form, email, or API)
• ●Audit trail retrieval keyed by data-subject identifier
• ●A separate-reviewer workflow with assignment controls
• ●A documented response within statutory timelines (typically 30 days)

How this maps to Migratio's architecture

We didn't bolt these requirements on. They informed the original design:

• ●Every agent decision emits a structured audit record into a cryptographically-chained log
• ●Every record movement, mapping change, and reconciliation resolution is keyed to a data-subject identifier (TIN, account number, license number)
• ●Approval workflows require named human sign-off with a written reason; rubber-stamp approvals are explicitly flagged
• ●Rule library versions are immutable; changes ship as new versions with a migration path for in-flight decisions
• ●The audit pack export produces the regulator-grade artifact directly — no post-hoc reconstruction

What you should ask any migration platform

• ●Show me a sample audit record for an automated decision
• ●Show me your rule library versioning model
• ●Show me how a data subject can request review of how their record was migrated
• ●What's your statutory response timeline, and how do you enforce it operationally?
• ●What happens to your audit trail if you go out of business? Where does it persist?

These aren't gotcha questions. They're the questions a competent compliance officer at any Nigerian bank or federal ministry will ask before procurement. We've answered all five in our standard MSA. Happy to share the relevant clauses on a discovery call.