A passport photo is the most sensitive file most apps ever receive. It carries a face, a full name, a date of birth and a document number, and it is enough to open an account somewhere else. Yet in many upload flows the picture is copied five or six times before anyone asks whether it needs to exist at all.

This post looks at the question from the engineering side: what the GDPR says about keeping data, the places where a passport image quietly piles up, and a pattern called read, return, forget – the image is read, the result is returned, and nothing of the picture is kept. It ends with the part that stays your job, because some businesses are required to keep a copy, and from July 2027 a new EU law spells that out.

What the GDPR actually asks

The GDPR does not say "never store a passport image". It says something more useful: keep what you need, for as long as you need it, and no longer. Art. 5(1) of Reg. (EU) 2016/679 sets the principles. Two of them decide most of the design.

Art. 5(2) adds accountability: you must be able to show that you follow these principles. And Art. 25(1), data protection by design, asks for "appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner".

Read together, they turn a legal question into an engineering one. The fewer copies of an image exist, the fewer places you have to describe, secure, back up and eventually empty. A copy that was never written is the only one that needs none of that work.

Where passport images end up

Most teams store the image on purpose in one place. The trouble is the places nobody chose. Walk through this list against your own flow.

The last row is the one you control least. Your own logs you can fix. A copy held by a vendor is governed by that vendor's settings, and you have to ask what they are.

The pattern: read, return, forget

The image exists only in memory, for the length of one request. What leaves the request is the reading: the extracted values. The picture does not leave at all.

1. Send the image straight to recognition. No upload bucket in between. If a bucket is unavoidable for large files, give the object a lifetime of minutes and delete it when the call returns.
2. Use what you need from the response at once. Crops such as the holder's photo exist only in that response. If your flow compares a selfie to the portrait, do it now.
3. Keep the reading, not the picture. Store the fields your process needs, under your own retention rule. A date of birth and a document number are still personal data, so they get an end date too.
4. Keep the image out of logs and error reports. Strip bodies at the boundary, in one place, rather than trusting every caller to remember.
5. Write down the result. For each place in the table above, note whether the image can reach it and why not. That note is the accountability Art. 5(2) asks for.

Questions to ask your OCR provider

Because the last row of the table is the vendor's, these are the questions worth putting to any service that reads documents for you:

• Is the uploaded image written anywhere – disk, object store, logs – or does it live only in memory for the request?
• Are the crops (the holder's photo, the signature, the page crop) stored, or returned once in the response?
• Can retention be set per request, and does "zero" mean no row at all, or a row that expires soon?
• What does the account default keep, and does shortening it apply to rows already stored?
• Can one result be deleted early through the API?
• What does a retry look like with zero retention? If nothing is stored, an idempotent retry has no first result to return; the service should say so explicitly (for example with a 409) rather than quietly running the scan twice.

For one worked set of answers, the doc.cheap data retention and privacy page describes how that API treats each of these points: the image held in memory for the request only, crops returned once, a per-request window from zero (no row written) up to one year, and early deletion of a single result.

What stays your job

Read, return, forget removes the copies on the provider's side. It does not decide what your business has to keep. For some businesses the answer is "a copy", and the law says so.

The EU's new anti-money-laundering law, Reg. (EU) 2024/1624, applies from 10 July 2027. Art. 90 says: "It shall apply from 10 July 2027, except in relation to obliged entities referred to in Article 3, points (3)(n) and (o), to which it shall apply from 10 July 2029." Its Art. 77 on record retention makes obliged entities, such as banks and other financial firms, keep:

"a copy of the documents and information obtained in the performance of customer due diligence pursuant to Chapter III, including information obtained through electronic identification means;"

Art. 77(3) sets the length: the records are "retained for a period of 5 years commencing on the date of the termination of the business relationship", and then "obliged entities shall delete personal data upon expiry of the five-year period". Art. 77(2) allows, under conditions, "a retention of the references to such information" in place of copies.

So if you are an obliged entity, zero retention at the OCR step does not remove your duty to keep a record. It changes where the record lives. Your own store becomes the one copy, and the storage limitation principle still applies to it: five years after the relationship ends, it goes. The design work is to make that store deliberate – one place, one owner, encryption, access control and a deletion job – rather than the accidental pile from the table above.

If you are not an obliged entity, ask the plain question first: does anything in your process need the picture after the fields are read? Often the honest answer is no.

A checklist

• Every place in the "where images end up" table is checked against your flow.
• The image goes straight to recognition, or through a bucket with a lifetime of minutes.
• Crops are used inside the response handler and not written anywhere.
• The OCR call sets its retention on purpose, zero when nothing needs reading back.
• Retries handle the "nothing to replay" answer of a zero-retention call.
• Logs and error reports strip request bodies at one boundary.
• The fields you keep have an end date, and something deletes them.
• If a law requires a copy, it lives in one deliberate store with its own deletion date.

This is an engineering summary, not legal advice. The original post on doc.cheap also shows a zero-retention call in Python.

A question for you: where did you last find a copy of an identity document that nobody meant to keep? Tell me in the comments.

A passport's machine-readable zone (MRZ) writes every date as six digits, YYMMDD, and leaves the century out. ICAO's specimen passport carries 740812 as the date of birth: 1974 or 2074? A person cannot hold a passport before they are born, so it is 1974. That observation is the whole rule. This post turns it into code that is correct on every day of the year, lists the edge cases that catch simple parsers, and gives Python and JavaScript implementations with a test table. All examples use ICAO's fictitious specimen or synthetic values.

Where the dates are

ICAO Doc 9303 defines two date fields in each MRZ format, date of birth and date of expiry, each YYMMDD and each followed by a check digit. Positions below are 0-based:

On the TD3 specimen line L898902C36UTO7408122F3404159ZE184226B<<<<<16 that yields 740812 (birth) and 340415 (expiry).

The problem with a pivot year

The common shortcut maps two-digit years below a fixed pivot to the 2000s and the rest to the 1900s. Python's time.strptime documents exactly this for %y: "values 69–99 are mapped to 1969–1999, and values 0–68 are mapped to 2000–2068."

Applied to a birth date, that puts someone born on 12 April 1968 (680412) in 2068. Moving the pivot only moves the error, and a fixed pivot drifts further from the truth every year. The correct century depends on the current date, so the current date has to be an input.

Rule for birth dates

Take the year as 2000 + YY. If that full date is after today, subtract 100.

Three details make the difference between almost right and right:

1. Compare full dates, not years. With today = 24 September 2026, 261224 would be 24 December 2026, which has not happened yet, so the answer is 24 December 1926. A year-only comparison would call it 2026.
2. Today is not the future. 260924 stays 2026-09-24; 260925 becomes 1926-09-25. The comparison is strictly "after".
3. Inject today, in UTC. A function that reads the system clock cannot be tested deterministically, and machines in different time zones disagree about the date for part of each day.

Rule for expiry dates

Always 2000 + YY. An expired document from 2012 is a 2012 date, not 2112. The rule is safe until documents start expiring in the 2100s.

Edge cases

• Leap days. Pick the century first, then validate. 280229 (birth) is 1928-02-29, a real date. 000229 is 2000-02-29, real because 2000 is a leap year; 1900 was not. Validating before choosing the century breaks one of these.
• Filler characters. Unknown parts of a date can be written as <, for example 94<<08. That is not a calendar date: return nothing and keep the raw text for display.
• Valid check digit, invalid date. The check digit guards the characters, not the calendar. With weights 7, 3, 1, 741312 sums to 88, check digit 8, so 7413128 passes, yet month 13 does not exist. Run both checks.
• Centenarians. Born in 1925 and born in 2025 look identical. The rule chooses the younger reading; if that matters, compare with the date printed on the data page.

Python implementation

Standard library only; today is a datetime.date supplied by the caller.

import re
from datetime import date, datetime, timezone

SIX_DIGITS = re.compile(r"[0-9]{6}")

def read_mrz_date(raw, kind, today):
    """Turn an MRZ YYMMDD field into a date, or None if it is not one.

    kind is "birth" or "expiry"; today is a datetime.date.
    """
    if kind not in ("birth", "expiry"):
        raise ValueError(f"unknown kind: {kind!r}")
    if not SIX_DIGITS.fullmatch(raw):
        return None  # fillers, letters or the wrong length
    yy, mm, dd = int(raw[0:2]), int(raw[2:4]), int(raw[4:6])
    year = 2000 + yy
    if kind == "birth" and (year, mm, dd) > (today.year, today.month, today.day):
        year -= 100  # the 2000s reading is in the future
    try:
        return date(year, mm, dd)  # checked after the century is chosen
    except ValueError:
        return None  # 13th month, 31 April, 29 February in a common year

# read_mrz_date("740812", "birth", datetime.now(timezone.utc).date())

[0-9] is deliberate: \d and str.isdigit() also accept digits from other scripts, and an MRZ only contains ASCII digits.

JavaScript implementation

today is an ISO YYYY-MM-DD string; such strings sort correctly as plain strings.

export function readMrzDate(raw, kind, today /* "YYYY-MM-DD", UTC */) {
  if (kind !== "birth" && kind !== "expiry") throw new Error(`unknown kind: ${kind}`);
  if (!/^[0-9]{6}$/.test(raw)) return null; // fillers, letters or the wrong length
  const month = Number(raw.slice(2, 4));
  const day = Number(raw.slice(4, 6));
  let year = 2000 + Number(raw.slice(0, 2));
  const iso = (y) => `${y}-${raw.slice(2, 4)}-${raw.slice(4, 6)}`;
  if (kind === "birth" && iso(year) > today) year -= 100; // the 2000s reading is in the future
  // Date.UTC rolls 31 April over to 1 May; a changed month or day means no such date.
  const d = new Date(Date.UTC(year, month - 1, day));
  if (month < 1 || month > 12 || d.getUTCMonth() !== month - 1 || d.getUTCDate() !== day) {
    return null;
  }
  return iso(year);
}

// readMrzDate("740812", "birth", new Date().toISOString().slice(0, 10));

Test table

Today fixed at 2026-09-24; "none" is None / null.

Pin "today" in your tests. With the real clock, a row such as 261224 changes its answer on 25 December.

Summary

Birth dates take the latest century that does not put the date in the future, compared as full dates with today counted as past and today passed in as UTC. Expiry dates stay in the 2000s. Choose the century before validating the calendar date, treat fillers as "no date", and never let a passing check digit stand in for date validation.

If you receive dates already converted by an OCR service, keep the raw MRZ lines alongside them so you can re-apply your own rule where a date decides something important. The original post on doc.cheap also covers how the doc.cheap MRZ parser applies the same rule in the browser.

By 24 December 2026 every EU Member State has to offer its residents a European Digital Identity Wallet. For developers who maintain an identity check that starts with a passport or ID card photo, three questions follow: where exactly does that date come from, what data does a wallet hand over, and do document scans go away? This post answers each from the legal texts themselves, then sketches an architecture that supports both inputs.

The deadline, counted step by step

The obligation sits in Art. 5a(1) of Reg. (EU) No 910/2014, as amended by Reg. (EU) 2024/1183 (often called eIDAS 2). Member States must provide a wallet "within 24 months of the date of entry into force of the implementing acts referred to in paragraph 23 of this Article and in Article 5c(6)".

The relevant implementing acts are dated 28 November 2024; one of them is Implementing Reg. (EU) 2024/2979, on the integrity and core functionalities of wallets. It appeared in the Official Journal on 4 December 2024 and entered into force "on the twentieth day following that of its publication":

The 20 days count from the day after publication, which is why the result is the 24th and not the 23rd.

The data a wallet presents

Instead of an image, a wallet presents a signed credential. For a natural person the attribute set is "person identification data" (PID), defined in the Annex to Implementing Reg. (EU) 2024/2977 and issued in ISO/IEC 18013-5:2021 or W3C "Verifiable Credentials Data Model 1.1" format.

Mandatory attributes about the person:

• family_name, given_name, birth_date, birth_place
• nationality (ISO 3166-1 alpha-2, one or more values)

Mandatory metadata:

• expiry_date (of the PID, not of any physical document)
• issuing_authority, issuing_country (alpha-2)

Everything else is optional: the resident_* address attributes, personal_administrative_number, portrait, birth names, sex (numeric codes 0, 1, 2, 3, 4, 5, 6, 9), email_address, mobile_phone_number, plus metadata such as document_number, issuing_jurisdiction and location_status.

How this compares with what you read off a passport data page:

The last row deserves attention: the Annex says that where a mandatory value "is not known for the person or cannot otherwise be issued", Member States "shall use an attribute value appropriate to the situation instead". Your mapping code should expect placeholder values, not missing keys.

Why document input does not disappear

Art. 5a(15) is explicit: "The use of European Digital Identity Wallets shall be voluntary", and "It shall remain possible to access public and private services by other existing identification and authentication means."

In practice, document input remains necessary for:

• Non-EU travellers and customers. The wallet is tied to "the legal identity of Union citizens, residents in the Union or legal persons".
• Users who have no wallet, by choice or circumstance.
• Processes that need the document itself – its number, image or machine-readable zone – rather than an attestation about the person.
• Rollout gaps. The legal deadline is not the date a particular national wallet reaches users; check that country's own announcement.

One record, two inputs

A pattern that holds up:

            +--> wallet presentation --> verify signature --> map PID ------+
user -------+                                                               +--> identity record
            +--> document photo --> OCR / MRZ read --> map document fields -+

Implementation notes:

1. Define your own internal schema and write two adapters into it, one per input.
2. Normalise country codes at the edge (pick alpha-2 or alpha-3 and convert the other).
3. Record the source of every identity record. A signed wallet presentation and an OCR read are different kinds of evidence, and an auditor will ask which one you relied on.
4. Unify "unknown". Map PID placeholders and OCR nulls to one representation.
5. Verify what you can on the document path. The MRZ check digits (ICAO Doc 9303, weights 7-3-1) catch most misreads; the TD1, TD2 and TD3 layouts are compared on the doc.cheap MRZ formats page. Keep in mind that check digits prove the zone was read consistently, not that the document is genuine.
6. Minimise storage. If the flow only needs a few fields, keep only those.

An adapter for the document side can be as small as this (shown for a JSON response with holder, document and mrz objects; adjust the paths to whatever your OCR returns):

function fromDocument(read) {
  return {
    source: "document_scan",
    family_name: read.holder?.surname ?? null,
    given_name: read.holder?.given_names ?? null,
    birth_date: read.holder?.birth_date ?? null,
    nationality_alpha3: read.holder?.nationality ?? null,
    issuing_country_alpha3: read.document?.issuing_state ?? null,
    document_number: read.document?.number ?? null,
    mrz_status: read.mrz?.status ?? null,
  };
}

The wallet adapter is the mirror image: verify the presentation's signature first, then map family_name, given_name, birth_date, nationality and issuing_country, converting the alpha-2 codes.

Dates to keep on the calendar

• 24 December 2026 – Member States must provide wallets (Art. 5a(1)).
• 24 December 2027 – private relying parties that are required, by law or contract, to use strong user authentication for online identification must also accept wallets on the user's voluntary request (Art. 5f(2)). Sectors named include transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications; micro and small businesses are excluded.
• Very large online platforms must accept wallets for user authentication on the user's voluntary request (Art. 5f(3)).
• Revisions. Recital 4 of 2024/2979 says the Commission "should review and update" the act where necessary, so re-check the 2024/2977 attribute tables before freezing a mapping.

Summary

The wallet deadline is a Member State obligation, wallet use stays voluntary, and document input keeps a permanent place for non-EU users and anyone without a wallet. Designing one internal identity record with two adapters lets you add the wallet path when your users' countries are ready without rewriting the document path.

This is an engineering summary, not legal advice. The original post on doc.cheap includes the full attribute-by-field mapping table.