Skip to content
All articles

The ID photos you copied after KYC are the breach you will have to report. Here is how to hold less.

Charles Archibong

, Co-founder

The law tells you to keep a KYC record for years. It does not tell you to copy the passport photo into your warehouse, your logs and your support inbox. Every extra copy is one more thing to breach, hand over and report. Here is how to hold less.

One ID card locked in a vault while faded copies of it sit in an inbox, a log file and a spreadsheet.

Key takeaways

  • Record-keeping law asks for a record that is kept for a period and can be produced. It does not ask for copies in every system.
  • FATF, Nigeria and South Africa set a minimum of five years after the relationship ends. Check the rule for each country you serve.
  • Nigeria and Kenya give a controller 72 hours to notify the regulator of a qualifying breach.
  • Copies pile up in webhook stores, logs, support tools and analytics. Most were never a decision.
  • Keep the verdict and a reference in your own systems. Fetch the image by link only when someone needs to look at it.

A new analyst is asked to tidy the data warehouse. In a table nobody owns she finds a column of long text values. She decodes one. It is a passport photo page. There are hundreds of thousands of rows.

Nobody decided to put them there. Two years ago an engineer saved every webhook payload so that failed deliveries could be replayed. The payloads carried images, and the warehouse sync copied the table.

That is the pattern. The verification finished long ago and the copies stayed. Each one is a place a customer's face and ID number can leak from, and you are answerable for all of them.

What it costs when a copy leaks

A leaked password is reset. A leaked face and national ID number are not. The costs arrive quickly.

  • A deadline. In Nigeria a data controller must notify the Commission within 72 hours of becoming aware of a breach that is likely to put people's rights at risk, and must tell the affected people immediately where the risk is high (Nigeria Data Protection Act 2023, section 40 (opens in a new tab)). Kenya also sets 72 hours for the regulator, and gives a processor 48 hours, where reasonably practicable, to tell the controller (Data Protection Act 2019, section 43 (opens in a new tab)).

  • A question you cannot answer. The Nigerian notice should describe the categories and approximate numbers of people and records concerned. For a table nobody owned, you start the clock without knowing.

  • Every request, multiplied. A customer asking for their data, or asking you to erase it, is now a search across every system that might hold a copy.

South Africa and Ghana do not set a number of hours. Both require notice to the regulator and the person as soon as reasonably possible after discovery (POPIA, section 22 (opens in a new tab); Ghana's Data Protection Act 2012, section 31 (opens in a new tab)).

What record-keeping law actually asks for

The usual reply is: we have to keep it, the regulator says so. That is half right.

FATF Recommendation 11 (opens in a new tab) says financial institutions should keep records obtained through customer due diligence, which it describes as copies or records of official identification documents, along with account files and business correspondence, for at least five years after the business relationship ends. The records should be available to the competent authorities.

The countries we checked follow it closely, as of October 2026:

We did not read the anti-money laundering retention periods for Kenya or Ghana, so we do not state them here. Sector regulators can also set longer periods than the Act. Check the rule for each licence you hold.

Notice what those provisions ask for: a record, kept for a period, that can be produced. None asks for the image to sit in your warehouse, your logs and your help desk as well.

What data protection law asks for

Data protection law applies to the same files, and pulls the other way.

The two sets of rules do not conflict. One says keep a retrievable record for the period. The other says keep no more than that, in no more places than that, and remove it when the period ends. One governed copy satisfies both. Seven ungoverned ones satisfy neither.

This is general information, not legal advice for your business. Nigeria's Commission has also issued a General Application and Implementation Directive, which we have not reviewed for this article.

Where the copies pile up

  • Webhook stores. Payloads saved for replay, with everything the provider sent inside them.

  • Logs. Request and response bodies written by a debug setting that was never turned off.

  • Support tools. A customer emails a photo of their ID. An agent attaches a screenshot of a verification to a ticket.

  • Analytics. A nightly sync that copies whole tables, images and ID numbers included.

  • People. Exports for an audit, screenshots in chat.

How to hold less

  • Store the verdict and a reference. Your systems need to know that a customer passed, when, at what level, and the ID of the verification. They rarely need the picture.

  • Fetch images by link, when someone needs to look. A link that needs a secret key is not a copy. Do not download media by default.

  • Choose what is delivered. If a field never reaches your webhook, it never reaches your logs, your warehouse or your replay table.

  • Give every store a retention period. Start with logs and webhook stores.

  • Give the record one home. Decide which system holds the legally required record, write it down, and treat every other copy as a defect to remove.

What Toden does, and what it does not

  • Selfies, liveness video and document images are captured in the SDK and uploaded straight to Toden. Your servers do not need to handle them.

  • Webhooks carry each image as a link, not as bytes. The link is fetched with a secret key and is scoped to your organisation and environment. A publishable key cannot read media, results or personal data.

  • Each workflow step has a Returned data setting that limits which fields and media links are sent in your webhooks. It is described in the data retention guide (opens in a new tab).

  • Uploads that are never submitted are deleted, most within 30 minutes. Supporting documents can be given their own period per workflow, from 1 to 3,650 days, through supportingDocuments.retentionDays. API request logs are kept for 7 days.

  • You can delete a verification or a customer record from the console or the API. Media links sent in earlier webhooks then stop working.

  • ID numbers, phone numbers and record photos are encrypted at rest.

The limits, stated as limits:

  • Completed production verifications and their captures are kept until you delete them. Apart from supporting documents, there is no automatic expiry you can set for them today, so the five-year clock is yours to run.

  • Deletion is soft. The record leaves everything you can read, and Toden keeps it marked as deleted so that a compliance history cannot be rewritten without trace. Two removals are permanent: revoking a biometric enrolment, and removing an entry from a face list.

  • Media links do not expire. Access is controlled by your secret key, so restrict it to your own IP addresses and revoke it if it leaks.

  • Toden holds no SOC 2 or ISO 27001 certification yet. The Trust Centre states the current position.

  • Holding less lowers your exposure. It does not remove your duties as the controller of the data.

Questions to ask any provider

  • Do your webhooks carry images, or links to them?

  • Can I choose which fields and media you send me?

  • How long do you keep captures, and can I set that period myself?

  • What does delete actually do? Is the file destroyed, or hidden?

  • If you are breached, how quickly do you tell me, and what will you be able to tell me?

Want to see what your own integration receives? Open a Toden workspace (opens in a new tab), send a sandbox verification and read the webhook. Our guide to biometric data under African data protection law covers face images in more depth.

Sources

Filed underRisk & ComplianceIdentity Verification

Charles Archibong

About the author

Charles Archibong

Co-founder

Charles Archibong co-founded Toden. He writes about identity verification, financial technology, and the practical work of building trusted digital services.

  • Risk & Compliance

    Handling biometric data under African data protection laws

    All three laws treat biometric data as a special category. Nigeria names facial images and limits sensitive data to listed grounds, Kenya treats biometric processing as high risk, and POPIA prohibits it unless an authorisation applies. Plan a lawful ground, a DPIA and minimisation.

  • Developers

    Verifying webhook signatures and handling retries correctly

    Verify the V2 signature over the raw request bytes, reject timestamps outside the replay window, record the event ID under a unique constraint before doing any work, and return 2xx only once the event is durably stored.

Build your product.We'll handle the rest.

Identity and compliance, end to end, built to global standards, priced for founders.

KYC data retention: keep the record, not every copy · Toden