Skip to main content
HubSecure

Blog

Why African Fintechs Are Moving Sensitive Customer Files Off Google Drive and Dropbox

What started as a practical workaround for fast-growing startups is becoming a compliance liability. Here is why regulated African fintechs are rethinking their document infrastructure.

· By HubSecure Strategy

Every African fintech has the same founding story about document infrastructure. In the first year, you share customer onboarding documents in a Google Drive folder. KYC scans go into a shared Dropbox. Loan application files get emailed between the ops team and the credit officer. It works. You are moving fast, and the alternative—building a document management system—sounds like an enterprise problem for a different company at a different stage.

Then you raise your Series A. You cross 50,000 customers. You apply for a Payment Service Provider licence. You hire a compliance officer. And the compliance officer opens Google Drive and discovers that two years of customer KYC documents, income statements, and bank statements are sitting in a shared folder accessible to every person who has ever worked at the company, with no audit log, no retention policy, and no way to produce a deletion record for a data subject request.

This is the moment most regulated African fintechs recognise that Google Drive and Dropbox are not document infrastructure for a regulated business. They are productivity tools that were never designed to carry compliance obligations.

Why the workaround worked for so long

The tools themselves are not the problem. Google Drive and Dropbox are excellent for what they were built to do: make files accessible to people who need them. The problem is the combination of what regulated financial services requires and what these tools were designed to provide.

Regulated document handling requires: access controls tied to specific roles and specific files (not just folders), immutable access logs that survive employee departures, automated retention enforcement with verifiable deletion, data subject rights support (finding all documents relating to a specific customer, across all systems, within 30 days), and breach detection with a clear chain of custody.

None of these requirements are in the design mandate of a consumer file-sharing product.

The specific compliance problems

Access control. Google Drive permissions are managed at the folder and document level by whoever owns the folder. There is no role-based access control that maps to your organisational structure. When a credit officer leaves the company, their Google Drive access may be revoked, but files they shared externally remain accessible. Shared Dropbox folders cannot enforce least-privilege by job function.

Audit trail. Google Drive logs file access in Google Workspace admin audit logs—but only if you are on the right tier, only for a limited period, and only if someone extracted the logs before they aged out. Dropbox Business provides basic activity logs. Neither produces the structured, queryable, long-retention audit record that NDPA auditors, POPIA examiners, or CBN inspection teams expect to see.

Data residency. Nigerian data protection law requires certain categories of sensitive data—financial records, health data—to be stored on servers in Nigeria. Google Drive and Dropbox store data in their own cloud infrastructure, which for most African accounts means European or US data centres. This is not a configuration option; it is a structural feature of how these products work.

Retention and deletion. A regulated fintech needs to retain certain customer documents for defined periods (typically 5–7 years for AML records under most African frameworks) and delete others on schedule. Manual deletion from Drive or Dropbox does not produce a verifiable deletion record. An automated retention policy that executes and generates evidence does not exist in either platform.

Data subject requests. When a Nigerian customer exercises their right to access all personal data you hold about them, you need to find every document across every system, collate it, and respond within 30 days. “Search Google Drive for this customer’s name” is not a reliable or auditable process.

What the migration looks like in practice

The fintechs that have gone through this transition typically do it in phases.

Phase 1: Inventory. Map every location where customer documents currently live—Drive folders, Dropbox folders, email attachments, local hard drives on ops team laptops. This is usually worse than expected. The inventory itself is the compliance risk disclosure.

Phase 2: Classification. Categorise document types by regulatory classification. KYC documents, income verification, AML case files, loan agreements—each has different retention requirements, access requirements, and deletion obligations. The classification determines what controls apply.

Phase 3: Controlled migration. Move documents from uncontrolled locations to the governed platform. Assign access controls based on job role, not folder ownership. Establish retention schedules. Revoke access from departed staff and verify the revocation is complete.

Phase 4: Process re-engineering. Stop new documents going into the old system. Update onboarding workflows, credit assessment processes, and AML case management to generate documents in the governed platform from the start. This is harder than the migration—it requires changing how people work, not just where files live.

What regulated document infrastructure looks like

A governed document platform for a regulated African fintech does five things that Drive and Dropbox cannot:

1. Role-based access that maps to your compliance structure. Credit analysts see credit files. AML officers see AML cases. External auditors see a scoped collection assembled for their review—not your entire document repository.

2. Immutable audit logs. Every file access, every download, every sharing action is logged with the authenticated identity, timestamp, and outcome. Logs are retained for the defined period and cannot be deleted or edited by users.

3. Automated retention enforcement. Documents are tagged with their retention category at ingestion. Retention policies execute automatically. When a document reaches its deletion date, deletion is executed and a deletion certificate is generated—a verifiable record that the data is gone.

4. Data subject request support. Search across all documents by customer identifier, produce a complete collection for review, and generate the access response record—all within a single workflow.

5. Data residency compliance. For markets with localisation requirements, documents are stored in the appropriate jurisdiction with no action required by the user.

The cost of the workaround

The cost of building proper document infrastructure has fallen sharply. The cost of the workaround—remediation under enforcement pressure, regulatory fines, audit findings that delay fundraising, and the practical cost of manual document retrieval for data subject requests—has gone up.

The CBN, NDPC, and other African financial regulators are increasingly sophisticated about document infrastructure in their examination processes. “We use Google Drive” is a finding, not an answer.

The fintechs that are ahead of this recognise that document infrastructure is not an IT decision. It is a compliance decision that happens to have technical implementation.