29 Nisan 2026 tarihinde Avrupa Komisyonu, DPP Kaydı Uygulama Yönetmeliği Taslağı yayınladı ve eş zamanlı olarak dört haftalık bir geri bildirim süreci başlattı. 27 Mayıs 2026 tarihine kadar, AB içindeki ve dışındaki her kişi ve kuruluş, «Have Your Say» portalı üzerinden görüşlerini iletebilir. Görüşler halka açıktır, her biri isim veya kuruluş adıyla imzalanır ve resmi olarak yönetmeliğin nihai metnine dahil edilir.
Taslağı bu blogda ayrıntılı olarak ele aldık. Bu yazıyı, Komisyon’a ne tür geri bildirimler gönderdiğimize ayırıyoruz.
Neden dört ayrı geri bildirim gönderdik?
Portal, her bir katkı için 4.000 karakter kabul ediyor. Tüm noktaları tek bir uzun katkıya sığdırabilirdik. Bu, Mayıs ayında düzinelerce görüşü inceleyen Komisyon çalışanları için okuması daha zahmetli ve alıntı yapması daha zor olurdu. Dört ayrı görüş, kamuya açık listede her biri ayrı olarak bulunabilir ve her biri, diğer hususları etkilemeden tek başına yanıtlanabilir - ya da reddedilebilir.
Aşağıdaki dört konuyu sunduk:
1. DPP hizmet sağlayıcıları için asgari gerekliliklerin tanımlanması
Yönetmelik taslağı, merkezi olmayan modeli doğru bir şekilde tanımlamaktadır: DPP verileri, ekonomik aktörde veya onun DPP hizmet sağlayıcısında bulunur; Komisyon kaydı ise yalnızca referansları saklar. DPP hizmet sağlayıcıları (ESPR Madde 2, 32. madde) için, onaylanmış sağlayıcıların resmi bir listesi öngörülmüştür.
Eksik olan husus, bir hizmet sağlayıcının bu listeye girebilmesi ve listede kalabilmesi için aslında ne yapması gerektiğinin belirlenmemesidir. Muhtemelen, esas yükümlülükler ESPR ana Yönetmeliğinin 4. maddesine göre bir delege mevzuatta düzenlenecektir. Ancak kayıt sistemi, bu mevzuat yayınlanmadan önce faaliyete geçecektir.
Önerimiz: Ya bu uygulama yönetmeliğinde hizmet sağlayıcılar için asgari kriterler doğrudan belirlenmeli ya da delege mevzuatın ne zamana kadar sunulacağına dair bağlayıcı bir süre belirtilmelidir. Önerilen asgari gereklilikler arasında şunlar yer almaktadır:
- DPP kamu okuma arayüzünün aylık en az %99,5 oranında erişilebilir olması
- Yeni bir DPP sürümünün yedekleme kopyasına ne kadar hızlı ulaşması gerektiğine dair bir hizmet seviyesi anlaşması (Öneri: 24 saat içinde veya teknik olarak mümkünse gerçek zamanlı olarak)
- Hizmet sağlayıcı tarafından gelen sürümlerin zorunlu kriptografik doğrulaması
- Ekonomik aktörün açık anahtarlarının standart bir yol altında yayınlanması (RFC 8615, öneri
/.well-known/dpp-keys/) - Bir sağlayıcının hizmet verememesi durumunda DPP verilerinin düzenli bir şekilde başka bir sağlayıcıya taşınmasını sağlamak için tanımlanmış geçiş ve iflas süreci
Bu yükümlülükler, saygın bir sağlayıcıya hiçbir maliyeti yoktur - zira zaten bunları yerine getirir - ancak ucuz sağlayıcılar arasında, sonuçta listeyi zayıflatacak bir “aşağıya doğru yarış”ın önünü keser.
2. Kayıtlı DPP’lerin Uzun Vadeli Doğrulanabilirliği
Madde 9(4), kayıt belgesinin geçerlilik süresini 90 takvim günü ile sınırlamaktadır. Bu süre içinde, kayıt defteri talep üzerine belgeyi yeniden düzenler. Bu, günlük operasyonlar açısından uygun olmakla birlikte, bunun temelini oluşturan DPP yükümlülüğünün yaşam döngüsüyle uyuşmamaktadır: Madde 10(3), standart saklama süresini kayıt tarihinden itibaren 10 yıl olarak belirlemektedir; sektör mevzuatı daha uzun süreler talep edebilir.
2032 yılında bir piyasa denetim kurumu, bir gümrük memuru, bir geri dönüşümcü veya bir araştırmacı, 2026 yılında kayıt altına alınmış bir DPP’nin gerçekten kayıtlı olduğunu, orijinal ekonomik aktörün hâlâ var olup olmadığına veya yeni bir belge talep edip edemeyeceğine bağlı kalmadan doğrulayabilmelidir.
İki önerimiz de uygulamaya uygun niteliktedir:
- Komisyon tarafından nitelikli mühürle onaylanmış kanıt baytlarının, ekonomik aktör veya hizmet sağlayıcı tarafından geçici olarak depolanabileceğini, arşivlenebileceğini ve yeniden dağıtılabileceğini açıkça belirtmek. eIDAS Yönetmeliği’nin 35(2) maddesine göre nitelikli mühür, baytların nerede bulunduğuna bakılmaksızın bütünlük ve menşe varsayımını taşır.
- Kayıt defterinde, bir kayıt kimliğine imzalı bir yanıt veren, kamuya açık, kimlik doğrulaması gerektirmeyen bir doğrulama uç noktası oluşturmak. Günümüzde her türlü üçüncü taraf denetimi, ekonomik aktörün harekete geçmesini gerektirir; bu, düzenleyiciden daha uzun süre geçerliliğini koruması gereken bir kanıt belgesi için yanlış bir yaklaşımdır.
Ayrıca, hash oluşturma işleminin deterministik olarak belirlenmesini önerdik: SHA-256’yı hash fonksiyonu olarak, JSON Canonicalization Scheme (RFC 8785) ‘i serileştirme yöntemi olarak, imza bloğunun dışında kullanmak. W3C ekosisteminde bu, Transpareo’nun doğrudan imzaladığı eddsa-jcs-2022 kriptosuitesidir. Bu sabitleme tanımı olmasaydı, iki hizmet sağlayıcı aynı DPP’yi farklı hash değerlerine serileştirirdi ve kayıt belgesindeki hash alanı tekrarlanamaz hale gelirdi.
3. Madde 17, kamuya açık DPP verilerine erişimi kısıtlamamalıdır
- madde, “yığın halinde veri indirme”yi kayıt defterinin olası bir kötüye kullanımı olarak belirtmektedir. Kayıt defterinin kendisinde bulunan idari meta veriler (kimlikler, günlükler, denetim izleri) için bu doğrudur - bunlar yığın halinde indirilmemelidir.
Ancak üretici veya hizmet sağlayıcı nezdindeki kamuya açık DPP verileri, tam da ESPR’nin geniş çapta erişime açmak istediği alandır. Ürün filoları hakkında bileşimsel veriler toplayan geri dönüşümcüleri; sürdürülebilirlik beyanlarını çapraz olarak değerlendiren araştırmaları; karşılaştırmalı analizler yapan piyasa denetimi - bunların hepsi, kamuya açık DPP katmanına yönelik «kitlesel veri indirme» biçimleridir ve hepsi de Yönetmelik’in yazılma amac ına uygun kullanımlardır.
Önerimiz, Madde 17’ye, kapsamı kayıt verileriyle sınırlayan ve DPP verileri için ilgili sektöre özgü delege mevzuata atıfta bulunan açıklayıcı bir cümle eklenmesidir. Aksi takdirde, hizmet sağlayıcılar başlangıçta bir seçim yapmak zorunda kalacaklar: ya güvenlik amacıyla kamuya açık erişimi agresif bir şekilde kısıtlayıp tüketici deneyimini bozacaklar ya da erişimi açık bırakıp daha sonra Madde 17 anlamında kötüye kullanım olarak sınıflandırılma riskini göze alacaklar.
4. Başlangıçtan önce OpenAPI spesifikasyonunu ve test ortamını yayınlamak
Madde 3(b), kayıtlar için bir API gerektirmektedir. Madde 8(5) ise bunu kayıt için iki kanaldan biri olarak belirlemektedir. Ancak Yönetmelik, API sözleşmesinin ne zaman yayınlanacağına dair herhangi bir hüküm içermemektedir.
Kayıt iş akışlarını otomatikleştirenler - geniş bir kataloğa sahip her hizmet sağlayıcı ve her ekonomik aktör - API spesifikasyonuna, uygulamayı hayata geçirmek ve gerçek bir uç noktaya karşı test etmek için başlangıçtan çok önce ihtiyaç duyar. Yürürlüğe girmeden bir hafta önce bir spesifikasyonun bulunması, entegrasyon riskini ekosistemdeki tüm sağlayıcılara yükler.
Bu nedenle şu öneride bulunduk:
- Yürürlüğe girmeden en az sekiz hafta önce bir OpenAPI 3.1 spesifikasyonunun yayınlanması - yani 19 Temmuz 2026’da yürürlüğe girecekse, 24 Mayıs 2026’ya kadar
- Hizmet sağlayıcıların ve üreticilerin entegrasyonlarını gerçekleştirebilecekleri ve Madde 8(6) otomatik doğrulamasını test edebilecekleri paralel bir sanal ortam
- Semver uyumlu sürümleme politikası ve en az 18 aylık sonlandırma süresi
Ek tasarım önerileri: Kayıt çağrılarında idempotency anahtarları, büyük kataloglar için toplu kayıt, Webhook geri çağrısı ile asenkron kayıt ve otomatik doğrulama hataları için makine tarafından okunabilir hata kodları.
Bunu neden yapıyoruz
Bir danışma süreci, puan toplamak için oynanan bir oyun değildir. Her bir katkı, nihai metindeki tek bir cümleyi daha kesin hale getirebiliyorsa, amacına ulaşmış demektir. Komisyon bu katkıları gerçekten okur - ESPR sürecinden edinilen deneyim, teknik açıdan sağlam katkıların nihai metinlerde sıklıkla iz bıraktığını göstermektedir.
Zaten, kabul prosedürü yayınlanır yayınlanmaz DPP hizmet sağlayıcıları listesine dahil olmak için başvuruda bulunacağız. Dolayısıyla, yarıştığımız kuralların kesin olması ve adil bir oyun alanı tanımlaması bizim doğrudan menfaatimizdir. Bu dört katkı, listenin salt bir pazarlama etiketi haline gelmemesini sağlamak için attığımız somut adımlardır.
Katılmak isteyenler
Geri bildirim süresi 27 Mayıs 2026’ya kadar devam edecek. Katkılar, AB’nin tüm resmi dillerinde yapılabilir; portalda kayıt olunması gerekir ve katkılar herkese açık olarak yayınlanacaktır. DPP’leri düzenleyecek veya doğrulayacak olanlar - üreticiler, hizmet sağlayıcılar, geri dönüşümcüleri, resmi kurumlar - en az bir kez Have Your Say adresinden bu girişim hakkında en az bir kez gözden geçirmelidir. Kısa ve teknik açıdan doğru bir katkı da değerlidir.
Doğrulama aracımız Transpareo Time Machine , bu arada 2. maddede değinilen doğrulama ihtiyacını açık kaynak uygulamalarında şimdiden karşılıyor: Bir Transpareo-DPP’yi bağımsız olarak doğrulamak isteyenler, Komisyon kayıtlarında resmi olarak oluşturulmuş bir doğrulama noktasını beklemeden, bu araçla bunu şimdiden yapabilirler.