EUDI Wallet Data Deletion

Skip key takeaways

Updated September 4, 2026

• The wallet supplies the channel, the GDPR supplies the answer Build the response against Articles 12, 17 and 19 of Regulation (EU) 2016/679. The wallet regulation routes the request and evidences it, and it adds no erasure ground and no deadline of its own. It does carry duties of its own elsewhere: Article 5b caps what a relying party may request and bars an intermediary from storing transaction content.
• One month is the number to engineer against The operative deadline runs one month from receipt. A recital in the wallet regulation calls for immediate erasure, and it does not shorten the statutory period. The two-month extension is conditional and costs a notice inside the first month.
• The refusal path is a deliverable, not an edge case Taking no action has its own one-month deadline and two mandatory content elements: the reasons, and the routes to a supervisory authority complaint and a judicial remedy. Estimate it as a first-class path.
• Erasure is a graph traversal Recipients have to be told unless that proves impossible or disproportionate, and the person can demand the list. Your retention map, not your primary database, is what determines whether the duty is answerable.
• Identity resolution is where the wallet earns its keep Budget the identity step differently. Where your transaction record and the user's agree, that step can close without a document upload, and the saving belongs in the retention map, which is the expensive part of the build.

Copy takeaways

A person opens their EUDI Wallet, finds a presentation they made to you last month and asks you to erase what you kept. What arrives is an erasure request under the General Data Protection Regulation, and every deadline, exception, identity check and downstream notification that answers it comes from there.

The wallet gives the user a button and an itemised receipt of the exchange. It answers nothing itself. Its own function is a data deletion request; the right that function exercises is erasure under Article 17 of the GDPR, and this article uses the Regulation's word, because the deadlines and exceptions below hang on it. This note is for the team that has to service what comes back.

The wallet gives a button and a receipt

Regulation (EU) 2024/1183 puts the erasure route in the wallet's own dashboard. The wallet must let a user "easily request the erasure by a relying party of personal data pursuant to Article 17 of the Regulation (EU) 2016/679;" (Regulation (EU) 2024/1183, Article 5a(4)(d)(ii)). It names an existing GDPR right instead of creating one, which decides the shape of everything below.

Article 5a(5) lists the wallet's common protocols and interfaces, and erasure appears there as one to be supported "for requesting a relying party the erasure of personal data pursuant to Article 17 of Regulation (EU) 2016/679;" (Regulation (EU) 2024/1183, Article 5a(5)(a)(ix)). One provision offers the function, the other carries it.

The complaint route ships alongside it

Next to erasure, the dashboard lets the user "easily report a relying party to the competent national data protection authority, where an allegedly unlawful or suspicious request for data is received;" (Article 5a(4)(d)(iii)).

Article 5a(5) carries that one as a common interface too, "for reporting a relying party to the competent national data protection authority where an allegedly unlawful or suspicious request for data is received;" (Article 5a(5)(a)(x)).

The Architecture and Reference Framework states the same pair in user-facing terms, listing "Request data erasure under Regulation (EU) 2016/679, Article 17 (right to erasure), to maintain privacy." (ARF, EUDI Wallet functionalities).

The next item is "Report suspicious Relying Parties to the relevant national data protection authority." (ARF, EUDI Wallet functionalities). A mishandled request and a regulator complaint are one tap apart.

The receipt is itemised

Article 5a(4)(d)(i) lets the user "view an up-to-date list of relying parties with which the user has established a connection and, where applicable, all data exchanged;" (Regulation (EU) 2024/1183, Article 5a(4)(d)(i)). The list of relying parties is unconditional; the data exchanged carries a "where applicable" qualifier. Expect a person who can name the counterpart and the date, and maybe the attributes.

Recital 13 says of that function that "Such a function should be active by default." (recital 13). A recital binds nothing: read it as the drafters' expectation and plan on the user holding the record.

The recital also sets out what the log holds. "It should allow users to track all transactions executed through the European Digital Identity Wallet with at least the following data: the time and date of the transaction, the counterpart identification, the personal data requested and the data shared." (recital 13). It says "at least", so that is a floor and not a count. Treat the four fields as a minimum for your own request logs.

Where the wallet's machinery stops

Recital 32 states the design intent for wallet providers. "To ensure privacy, European Digital Identity Wallet providers should ensure unobservability by not collecting data and not having insight into the transactions of the users of the European Digital Identity Wallet." (Regulation (EU) 2024/1183, recital 32). A party built to see nothing cannot answer a question about what you hold.

The GDPR defines the role that carries the duty. "‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data;" (Regulation (EU) 2016/679, Article 4(7)). You decided why you wanted the attribute and what happens to it, so the request lands with you. Neither instrument read here gives the wallet provider a role in answering it, and this article invents none.

Scope note, and it is a real one

What the erasure interface looks like on the wire sits in a separate technical specification this article says nothing about. As of 4 September 2026 we could not resolve a rendered, citable version, so any claim about endpoints, payload shape or protocol would be unverifiable.

Even so, everything the GDPR requires once a request arrives is settled and quotable today, and it is the larger part of the build.

The request that actually arrives

Article 17(1) opens with the standard. "The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay" (Regulation (EU) 2016/679, Article 17(1)). The sentence runs into a list of grounds, so the right is conditional on one of them being made out.

Wallet-originated requests often rest on the first ground, where "the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;" (Article 17(1)(a)). A wallet presentation tends to have a narrow, dated purpose, easy to assert and awkward to rebut once the interaction closes.

Two more grounds worth wiring

Where the presentation ran on consent, ground (b) applies when "the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;" (Article 17(1)(b)). The second half of that clause is the one teams tend to drop. Withdrawn consent erases nothing while another legal ground still covers the data.

Ground (d) covers personal data that "the personal data have been unlawfully processed;" (Article 17(1)(d)). Requests citing it often come from someone who believes you over-asked, which is what the complaint route exists for. What a relying party may ask for at all is a separate build, covered in our note on relying party registration.

One month, and a recital that says immediate

Article 12(3) sets the clock. "The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request." (Regulation (EU) 2016/679, Article 12(3)). That is the operative deadline to engineer against.

Recital 13 of the wallet regulation reaches for a different word. "It should allow users easily to request the immediate erasure by a relying party of personal data pursuant Article 17 of Regulation (EU) 2016/679 and easily to report the relying party to the competent national data protection authority where an allegedly unlawful or suspicious request for personal data is received, directly via the European Digital Identity Wallet." (Regulation (EU) 2024/1183, recital 13). The Official Journal text omits the word to before the article reference, and the span is quoted as printed.

Both readings sit unresolved: the recital describes immediate erasure, the operative provision, Article 12(3), gives one month from receipt. Nothing found here turns the recital into a duty or shortens the deadline. Build against one month, and expect users who read the wallet's framing to want faster.

The extension, and the refusal

More time is available, but only where you take action. "That period may be extended by two further months where necessary, taking into account the complexity and number of the requests." (Article 12(3)). It extends Article 12(3)'s own period, conditional on necessity, and the same provision requires notice inside the first month, with reasons. An extension taken silently is not one you took.

Declining is permitted. Declining quietly is not. "If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy." (Regulation (EU) 2016/679, Article 12(4)). No extension reaches this path: Article 12(4) sets a fixed month and words it more strictly, saying "without delay" where Article 12(3) says "without undue delay". Two content requirements travel with it, and build estimates often miss it.

Identity, and the one place the wallet changes the build

Start with the posture. "The controller shall facilitate the exercise of data subject rights under Articles 15 to 22." (Regulation (EU) 2016/679, Article 12(2)). A channel that is hard to find or hostile to use fails on that sentence alone.

Article 12(6) bounds the identity check. "Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject." (Article 12(6)). Two conditions travel with it: the doubt must be reasonable, and the extra information necessary to confirm identity.

Here the wallet changes the engineering. The request is anchored to a prior presentation both sides hold a record of, so what a document upload would normally settle can often be settled by matching the two records. The right and the standard are unchanged; the cost of resolving them is not. Binding the presentation is covered in the verifier implementation note, authentication in the strong customer authentication note.

Two exceptions to model as retention holds

Five purposes, (a) to (e), suspend the erasure duty under Article 17(3) to the extent processing is necessary for one of them. Two are selected here, the two a business holding wallet attributes actually meets. The first is processing "for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" (Regulation (EU) 2016/679, Article 17(3)(b)). Statutory record-keeping lands here, so a FinTech carrying such duties should expect to invoke it.

The second is processing "for the establishment, exercise or defence of legal claims." (Article 17(3)(e)). A live dispute is a retention reason bounded by the same words, holding only to the extent the processing is necessary for that purpose. The three left out cover freedom of expression, public health and archiving or research, which a presentation record rarely reaches.

What the resolver returns

Both exceptions are scoped by necessity and by extent, so neither makes a request disappear; each converts part of the answer into a hold. The resolver has three outcomes per attribute: erased, retained with a stated reason or refused with reasons. A design that can only delete cannot express the middle one, and in a regulated business expect it to be routine.

Erasure travels past your database

Article 19 pushes the work outward. "The controller shall communicate any rectification or erasure of personal data or restriction of processing carried out in accordance with Article 16, Article 17(1) and Article 18 to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort." (Regulation (EU) 2016/679, Article 19). The escape clause covers impossibility and disproportionate effort. Anything meeting neither stays in the traversal, so an attribute copied to a warehouse or a processor is part of the answer.

The same article adds a second duty. "The controller shall inform the data subject about those recipients if the data subject requests it." (Article 19). That one is conditional on the person asking. Your recipient map has to answer to an individual and not only to an auditor.

One duty in that chain comes from the wallet regulation. Where a vendor fronts the wallet interaction, "Intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction." (Regulation (EU) 2024/1183, Article 5b(10)). A recipient that should be holding nothing still belongs on your retention map.

Published copies reach further still

Article 17(2) covers data you made public. "Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data." (Regulation (EU) 2016/679, Article 17(2)). Read the softeners first. Available technology, cost of implementation and reasonable steps all qualify what is owed, and the duty is to inform other controllers against a reasonableness standard.

Free of charge, with one narrow escape

Article 12(5) rules out billing. "Information provided under Articles 13 and 14 and any communication and any actions taken under Articles 15 to 22 and 34 shall be provided free of charge." (Regulation (EU) 2016/679, Article 12(5)). Communications are covered as well as actions, so the refusal letter is free too.

What the escape allows, and who has to prove it

The same paragraph opens a route for requests that are manifestly unfounded or excessive, "in particular because of their repetitive character" (Article 12(5)). The escape has two forms. You may "charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested", or you may "refuse to act on the request." (Article 12(5)).

The proof sits with you. "The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request." (Article 12(5)). The burden attaches to the request, not to the person. A series reaches the test only through its repetitive character, so a standing rate-limit rule is not the demonstration. Record what you rely on per request, in a form a supervisory authority would accept.

A decision table for one inbound request

Three request shapes cover what actually arrives. Each maps to a likely ground, a hold that may suspend part of the answer and a reply with required content.

Built by this article, not by either Regulation; every provision is quoted and linked above. The mapping from request shape to ground and hold is editorial, not statutory, and one request can engage several rows.

Request shape	Ground likely engaged, Article 17(1)	Hold that may apply, Article 17(3)	What the reply must carry
The collection purpose has closed	(a), no longer necessary	(b), where a statutory retention duty covers it	What was erased, what was retained and the obligation relied on
Consent-based presentation, consent withdrawn	(b), no other legal ground	(b) or (e), where another basis or a live claim applies	Whether another ground still applies, and which
The person says you over-asked	(d), unlawfully processed	(e), where a dispute is open	Reasons, plus complaint and judicial remedy information if you decline

Two overlays, and the clock

Two further conditions are not request shapes. Each sits on top of whichever row applies and changes the reply without touching the ground.

• The attribute reached a warehouse, a processor or another recipient. That is your data topology, not the request. It adds the Article 19 duty to tell recipients and to name them if asked.
• You believe a repeat request is excessive. That is a claim you make about how the requester uses the channel, and Article 12(5) puts the demonstration on you, per request.

Every row starts a one-month clock at receipt. Where you act, the period can be extended by two further months where necessary, with notice inside the first month. Where you refuse, the month is fixed: Article 12(4) offers no extension.

What the build contains

Read back as deliverables, the provisions produce a shorter list than teams expect.

1. A resolver mapping an inbound request to the presentation it concerns, using facts the person can already see: date, counterpart, attributes requested and attributes shared.
2. A retention map from every attribute you accepted to every store, backup and recipient it reached, since Article 19 makes recipients part of the answer.
3. A decision function returning erased, retained or refused per attribute, with the ground or the exception recorded against each outcome.
4. A reply for the refusal path carrying reasons plus the routes to a supervisory authority complaint and a judicial remedy.
5. A one-month timer from receipt, with the two-month extension modelled as an event that fires a notice inside the first month, not a silent state change.
6. A recipient-notification job, and the ability to produce the recipient list when the person asks for it.
7. A no-charge policy, plus a documented test for the manifestly unfounded or excessive case that is recorded per request and not carried as a standing rate-limit rule, since Article 12(5) puts the burden of demonstrating that character on you.

Two of the seven touch the wallet channel: the intake that receives the request and the identity match that reads the transaction record. Neither needs the wire format settled, because both work from the record both sides already hold. The other five follow from a Regulation already in force.

Portability is a separate right

The same dashboard also lets the user "exercise the user’s rights to data portability." (Regulation (EU) 2024/1183, Article 5a(4)(g)). That is a different right with a different answer that the work above does not cover. Scope it separately.

FAQ

Last updated: September 4, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 5

• ★ Featured question. Does an erasure request have to arrive through the wallet to count?

  Copy link Copies a direct link to this answer to your clipboard.

  Nothing in the provisions behind this article makes the channel a condition of the right. The deadline runs from receipt of the request, so the same clock starts whether the person raised it from the wallet dashboard, sent an email or said it on a call.

  What the wallet channel changes is the quality of the request rather than its validity, because it arrives attached to a named interaction the person can already see.

• If we are legally required to keep the record, do we still have to reply?

  Copy link Copies a direct link to this answer to your clipboard.

  Yes. The exceptions in Article 17(3) suspend the duty to erase to the extent processing remains necessary, and they do not suspend the duty to answer.

  A partial response is the normal outcome for a regulated business: some attributes go, others are held against a stated obligation, and the reply says which is which. If you take no action at all, the reply also has to carry the reasons and tell the person about complaints and judicial remedies.

• Can we charge for the work of handling one of these?

  Copy link Copies a direct link to this answer to your clipboard.

  No, and the more useful question for a build is what that does to capacity planning. Since the response has to be free whatever it costs you to produce, cost control lives in the resolver and the retention map and nowhere else.

  A team whose attribute-to-store mapping is stale pays for that staleness in manual hours on every single request, with no route to recover them. The narrow exit for a repeat request is not a budget line either, because the demonstration behind it has to be built and recorded before you can use it once.

• Do we need a different erasure process from the one we already run?

  Copy link Copies a direct link to this answer to your clipboard.

  The legal analysis is the one you already have. What changes is triage.

  A wallet-originated request identifies a specific prior presentation, so it can be routed and scoped automatically where a free-text mailbox request cannot. Teams that already run a mature process usually find the work sits in the retention map and the recipient notifications, not in the intake form.

• Does the wallet transaction record satisfy our identity check on its own?

  Copy link Copies a direct link to this answer to your clipboard.

  It is evidence, not a verdict. The controller may ask for additional information only where there are reasonable doubts about identity, and a request that matches a transaction record on both sides will often leave no reasonable doubt to resolve.

  The assessment stays yours, and asking for a document upload when your own record already answers the question is hard to justify against the duty to facilitate the exercise of the right.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.