PİLOT UYGULAMA MODELLEMESİ – HAVZALAR BİRLİĞİ-

1- HÜDA BİR

Sosyo-Ekonomik Etki, Yönetişim ve Regülasyon Entegrasyonu: Pilot Rehberi, Ölçümleme ve Geçiş Stratejisi

Seri: Fintek Fıkhı (Makale-1 Epistemoloji • Makale-2 Referans Mimari • Makale-3 Geçiş ve Etki)

Özet

Bu üçüncü makale, iki bölümde değerlendirilecek Makale-3; Fintek Fıkhı -3A- Pilot Uygulama Havzası, Makale-4; Fintek Fıkhı -3B- Çok Fıkıhlı Küresel Entegrasyon Regulasyon başlıkları altında ele alınacak. Makale-1’de kurulan epistemolojik çerçeveyi ve Makale-2’de önerilen çok katmanlı referans mimariyi (L0–L7; DID/VC, parselleme/NFT–GTİP token, oracle–çoklu şahitlik, parametrik akit motoru, denetim ve reg-tech katmanları) HÜDA BİR ölçeğinde ölçülebilir bir pilot-disipline dönüştürür. Plot uygulama için tek bir köy kendi kendine yeterli olmayacağından bir yaşam modellemesi olan fıkıh kendi kendisine yetebilirliğe sahip helalinden ihtiyaçların hallolduğu mahaller olan bir mahalli model gerektirdiği için havza planlaması anlayışı ile bir çok köy kasaba ve metropolitan yaşam ile iç içe bir plot uygulama olarak düşünülmelidir. Amaç; şer‘î uyumu kod, süreç, kurum ve davranış düzeylerinde eşzamanlı işletecek “dağıtım disiplini”ni tesis etmek, her kritik kararı kanıt paketi (audit pack) ile kayıt altına almak ve pilotun ekosistem ölçeğine taşınmasını mümkün kılacak standartları üretmektir. Plot uygulama da çoklu olarak küresel ölçekte çeşitlikçi vr çoğulcu bir bakışla örneklem havzalar olarak önerilecektir. Bu havzalar arası entegrasyon 4. Makalede planlanırken Küresel meri akredite kurumlarla da regulasyon ele alınacaktır.

Makale, şer‘î uyumun sadece ‘sonradan denetlenen’ bir uygunluk alanı değil, doğrudan tasarım ve dağıtım disiplini olduğunu savunur. Bu yaklaşım, Makale-2’deki katmanlı mimariyi; regülasyon çatışma senaryoları, teşvik tasarımı, performans hedefleri (SLA), digital divide çözümleri ve pilot yönetim ofisi (PMO) pratikleriyle tamamlar.

Hedef kitle; sistem mimarları, geliştiriciler, şer‘î denetim ve iç denetim ekipleri, regülasyon ve gözetim kurumları ile Ahilik mütehassısları ve tasavvuf erbabıdır. Metin, disiplinlerarası ortak dil üretmeyi ve ‘nereden başlamalı?’ sorusuna uygulanabilir cevap vermeyi hedefler.

Anahtar kelimeler: Fintek Fıkhı, selem, süftece, tokenizasyon, regülasyon teknolojileri, AML/CFT, MiCA, FATF, yönetişim, dijital uçurum, pilot.

İçindekiler

1. Giriş
   2. Dağıtım Boşluğu ve MVP
   3. Yönetişim ve Kurumsal Tasarım
   4. Regülasyon Entegrasyonu ve Çatışma Çözümü
   5. Değer Akışı ve Teşvik Tasarımı
   6. Sosyo-Ekonomik Etki ve Ölçümleme
   7. Performans, Ölçeklenebilirlik, Dayanıklılık
   8. Dijital Uçurum ve Saha Operasyonları
   9. Pilot ve Geçiş Rehberi
   10. Beklenmeyen Sonuçlar ve Red Team
   11. Uygulama Senaryoları
   12. Sonuç ve Makale-4’e Köprü
   EKLER (A-P)
   Dipnotlar
   Kaynakça

1. Giriş

Bu makale; serinin ilk iki çalışmasında kurulan (i) epistemolojik çerçeveyi ve (ii) L0–L7 referans mimariyi, somut bir pilot-disiplinine dönüştürür. Makale‑1’de “güven mimarisi” ve şer‘î uyumun tasarım ilkeleri kuruldu; Makale‑2’de bunu çalıştıracak veri‑kimlik‑oracle‑akit motoru katmanları tanımlandı.[9][10] Makale‑3, bu iki çerçeveyi HÜDA BİR havzasında işletilebilir SOP’lar, kanıt paketleri ve yönetişim kapıları hâline getirir.

Bu makalede pilot havza adı, bölgenin tarihî-kurumsal hafızasını yansıtan “Hüdavendigar Dağ Köyleri Birliği (HÜDA BİR)” olarak tanımlanmıştır. “Hüdavendigar”, Osmanlı idarî teşkilâtında merkezi Bursa olan sancağın adı olarak kullanılmış; zaman içinde eyalet/vilâyet ölçeğinde Bursa merkezli bir idari kimliğe dönüşmüştür.[1] Bu isim, erken dönem kamusal hayat pratiklerinin (cuma camii–cuma yeri–pazar/çarşı ekseni) üzerinde geliştiği bir sosyo-ekonomik arka planı da çağrıştırır.[2] HÜDA BİR’in günümüzdeki kırılganlığı (göç, parçalı üretim, ölçek sorunu) ise pilotun “dezavantajı avantaja çeviren” bir geri dönüş ve adil kalkınma laboratuvarı olmasını sağlar.[3]

Not: Bu pilotun “HÜDA BİR” adıyla kavramsallaştırılması tesadüf değildir. Bölge tarihsel olarak “Hüdâvendigâr” adıyla anılmış; Cuma camileri etrafında “cuma yeri/pazar” düzeni, erken dönem kamusal hayatın (piyasa‑adalet‑emanet) pratik bir laboratuvarı olmuştur.[1][2] Bugün ise göç veren ve kırılganlığı yüksek bir kırsal kuşaktır; buna karşın Bursa metropolüne 1 saat mesafede olması, geri dönüş ve sürdürülebilir kalkınma programları için benzersiz bir avantaj üretir.[3]

Makale-1, dijital finansın krizlerini salt ekonomik değil, epistemik bir kriz olarak ele alıp ‘meta-para’ ve ‘token ontolojisi’ üzerinden bir tartışma kurmuş; Makale-2 ise bu tartışmayı test edilebilir bir referans mimariye tercüme etmiştir. Ancak uygulama gerçekliği, tasarım doğruluğundan ayrı bir zorunluluk taşır: Yönetişim, regülasyon, teşvikler, saha kullanımı ve insan davranışı katmanlarında tasarlanmayan bir sistem; en iyi teknik mimarilere rağmen sahada farklı sonuçlar üretebilir.

Bu makale, ‘dağıtım disiplini’ kavramını önerir: Şer‘î uyum; kod, süreç, kurum ve davranış düzeylerinde eşzamanlı işletilmedikçe süreklilik kazanamaz. Dolayısıyla Makale-3, yalnızca teknik bir ek değil; uygulama gerçekliğinin kurallarıyla (maliyet, teşvik, mevzuat, kullanıcı davranışı) yüzleşen bir geçiş metnidir.

Regülasyon boyutunda, sanal varlıklar ve hizmet sağlayıcılar için küresel AML/CFT standartlarının uygulanmasında FATF’nin güncellemeleri[7] ve AB’de MiCA uygulama takvimi[5] temel referans noktalarıdır. Operasyonel dayanıklılık açısından BCBS ilkeleri[6] ve siber güvenlik yönetişimi bakımından NIST CSF 2.0[7] gibi çerçeveler; Makale-2’deki kontrol hedeflerinin ölçümlenebilirliğini artırır.

2. Dağıtım Boşluğu ve MVP

2.1 MVP’nin tanımı: ‘en küçük doğru sistem’

Not: Bu makalede MVP doğruluğu “tek tip” değildir; seçilen havzanın baskın fıkhî-normatif profilince tanımlanır. HÜDA BİR’de (Hanefî sosyolojik doku) istihsan/örf gibi esneklik mekanizmaları, teslim yeri/teslim usulü gibi alanlarda uygulama maliyetini düşüren güvenli çözümler üretebilir; buna karşılık Şafiî ağırlıklı bir havzada aynı alanlar daha katı parametrelerle işletilebilir. Bu nedenle MVP, ‘özellik seti’ değil, ‘norm profiline bağlı doğruluk seti’dir.

MVP (minimum viable product) kavramı, yazılım dünyasında çoğu zaman ‘minimum özellik’ ile eş anlamlı kullanılır. Fintek Fıkhı yaklaşımında ise MVP, ‘minimum doğruluk’ demektir. Örneğin selem akdini, peşin ödeme doğrulaması olmadan başlatan bir sistem; doğru olmayan bir sistemdir; küçük olsa dahi ‘viable’ değildir.

Bu nedenle pilot MVP’sinin üç çekirdek doğruluğu zorunludur: (i) peşin ödeme kanıtı (time-stamp + bağlanabilir ödeme izi), (ii) nitelik/ölçü/takvim belirginliği (ürün standardı + teslim şartları), (iii) çift rehin/çift temlik engeli (encumbrance registry). Bu üçlü, spekülasyonun ve suistimalin ana kapılarını kapatır.

MVP’nin dördüncü ama vazgeçilmez çıktısı ise ‘kanıt üretimi’dir. Sistemin her kritik kararı, denetim izi üretmezse; pilot sonunda yalnız iddia kalır. Bu nedenle MVP, raporlanabilirlik (audit pack) tasarımını da kapsar.

2.2 Kademeli sertifikasyon: kontrol profilleri

Bu bölümde kullanılan özet çerçeve Tablo 2.1’de sunulmaktadır.

Tablo 2.1 — Sertifikasyon Seviyeleri

Seviye	Zaman Ufku	Kontrol Odağı	Denetim Çıktısı
1	0–90 gün	Akit doğruluğu + temel log	Pilot uygunluk raporu + kanıt paketi
2	90–270 gün	Oracle güveni + dispute + revocation	Bölgesel sertifikasyon + bağımsız denetim özeti
3	270+ gün	Reg-tech + SLA + formal kontroller	Ulusal lisans/uyum paketi + dayanıklılık raporu

2.3 Yalınlaştırma ilkeleri: ‘kontrol ekleme kriteri’

Kontrol sayısını artırmak her zaman doğruluğu artırmaz. Bazı kontroller, aynı risk sınıfını tekrarlar; sadece maliyet üretir. Bu nedenle her kontrol eklemesi için üç ölçüt aranır: (i) risk azalımı kanıtı (pilot bulgusu veya literatür gerekçesi), (ii) toplam maliyet etkisi (CAPEX/OPEX), (iii) saha uygulanabilirliği (kullanıcı yükü, eğitim ihtiyacı).

Bu disiplin, eleştiride ifade edilen ‘analiz felci’ riskini azaltır. Seviye-1’de yalnız en kritik kontrollerle başarı elde edilmeden, Seviye-2’ye geçilmez.

3. Yönetişim ve Kurumsal Tasarım

3.1 Kurul mimarisi ve sorumluluk zinciri

Makale-2’nin teknik bütünlüğü, sahada kurumsal bütünlüğe dönüşmedikçe sürdürülebilir değildir. Bu nedenle yönetişim mimarisi; şer‘î kurul, risk/uyum komitesi, teknik mimari kurulu ve pilot PMO’dan oluşan çoklu bir yapı olarak tasarlanır. Bu yapının amacı, tek bir kurumun (platform, depo, oracle) sistem üzerinde fiilî tekel kurmasını engellemektir.

Bu bölümde kullanılan özet çerçeve Tablo 3.1’de sunulmaktadır.

Şer‘î kurul; akit şablonlarının ve parametre setlerinin normatif uygunluğunu değerlendirir, ancak bu uygunluğun kanıta dönüşmesi için denetim gereksinimlerini de belirler. Risk/uyum komitesi; operasyonel risk, dolandırıcılık, AML/CFT ve tüketici koruması alanlarını birlikte ele alır. Teknik mimari kurulu; kontrol hedeflerinin kod kararlarına nasıl çevrileceğini, standartlar ve testlerle yönetir.

Tablo 3.1 — Decision Gates

Gate	Tetikleyici	Girdi	Çıktı
G1	Akit şablonu değişikliği	Fıkhî gerekçe + test sonucu	Yeni sürüm onayı/ret
G2	Oracle ağı değişimi	Çeşitlilik endeksi + SLA	Ekle/çıkar + izleme planı
G3	Kriz müdahalesi	Anomali + şikâyet artışı	Pause + inceleme + duyuru

3.2 Ahilik ve tasavvuf perspektifi: emanet, kalite, şeffaflık

Ahilik geleneği; üretimde kaliteyi ve ticarette emanet ilkesini, piyasa ahlâkının merkezine koyar. Modern sistemlerde ’emanet’ çoğu zaman sözleşme ve yaptırım diline indirgenir. Fintek Fıkhı yaklaşımı, emanetin önce ‘kanıt’ ve ‘şahitlik’ ile kurumsallaştırılması gerektiğini savunur.

Bu çerçevede oracle aktörleri (depo/lab/sigorta), teknik bir düğüm değil; bir emanet taşıyıcısıdır. Oracle ücretlendirmesi bu yüzden salt piyasa ücretine bırakılmaz; etik beyan, mesleki yeterlilik, çıkar çatışması beyanı ve rastgele denetim şartlarına bağlanır. Tasavvuf perspektifi, niyetin doğruluğunu ‘süreç disiplinine’ bağlar: niyet kontrol edilemez; süreç kontrol edilir.

4. Regülasyon Entegrasyonu ve Çatışma Çözümü

4.1 Uyumun üç düzeyi: teknik, hukuki, kurumsal

Uyum (compliance), tek başına teknik bir özellik değildir; hukuki bağlayıcılık ve kurumsal sorumlulukla tamamlanır. Teknik düzey; izlenebilirlik, seçmeli ifşa, denetim izi ve risk skorları üretir. Hukuki düzey; bu üretimin hangi şartlarda paylaşılacağını, hangi yetkinin hangi kanıtı talep edebileceğini tanımlar. Kurumsal düzey ise; bu kuralları işletir, denetler ve ihlal halinde yaptırım uygular.

Fintek Fıkhı sisteminin uyum iddiası, minimum kanıt paketi üzerinden somutlaşır: imzalı sözleşme olayları, ödeme kanıtı, encumbrance kayıtları, oracle raporları, revocation logları ve dispute karar kayıtları. Bu paketin üretilmediği bir dağıtım, regülatör ve şer‘î kurul açısından ‘denetlenemez’ kabul edilmelidir.

4.1.1 Encumbrance Registry’nin Hukuki Köprüsü: Öncelik ve Delil Standardı

Teknik olarak ‘çift rehin/çift makbuz’ riskini azaltmak, hukuki uyuşmazlık anında delil standardı ve öncelik kuralları net değilse yeterli değildir. Bu nedenle encumbrance kayıtları için hukuki köprü, pilot aşamasında dahi yazılı hale getirilmelidir.

• Öncelik kuralı tablosu: zaman damgası + taraf yetkisi + akit türü (rehin, temlik, haciz) üçlüsüne göre öncelik sırası.
• Asgari delil seti: rehin tesis/kaldırma için kim imzaladı, hangi VC ile, hangi yetki belgesiyle, hangi depo makbuzuna bağlı?
• Paralel kayıt çatışması: noter/odalar/lisanslı depo sistemleriyle hash-ankraj ritmi ve kayıt eşleştirme prosedürü.
• Uyuşmazlıkta kullanım: hakem kararları, bu tablo ve delil setine referansla ‘gerekçeli’ olarak üretilir ve Audit Pack’e bağlanır.

4.2 FATF yükümlülükleri ve mahremiyet gerilimi

FATF standartları; risk temelli yaklaşım, KYC, STR ve Travel Rule gibi yükümlülükleri vurgular[4]. Bu yükümlülükler, şer‘î mahremiyet ilkeleriyle gerilim üretebilir. Çözüm; seçmeli ifşa, gerekçeli talep, asgari veri seti ve zaman sınırlı erişim ile tasarlanır.

4.3 MiCA ve lisanslı operasyonlar

Bu bölümde kullanılan özet çerçeve Tablo 4.1’de sunulmaktadır.

AB’de MiCA çerçevesi, kripto-varlık hizmet sağlayıcıları (CASP) ve ihraççılar için lisanslama ve davranış yükümlülükleri getirir. Fintek Fıkhı sisteminin AB’de kullanımı; CASP rolünün, müşteri varlıklarının ayrıştırılmasının, ücretlerin şeffaflığının ve çıkar çatışması yönetiminin net olarak tasarlanmasını gerektirir.

Bu makale, MiCA’yı bir ‘uyum hedefleri listesi’ olarak ele alır: varlık koruma, şeffaflık, piyasa bütünlüğü, operasyonel dayanıklılık ve gözetim raporlaması. Bu hedefler, Makale-2’deki katmanlara eşlenerek teknik kanıta dönüştürülür.

Tablo 4.1 — Uyum Matrisi (Katman → Kontrol)

Uyum Alanı	Teknik Mekanizma	Yönetişim	Kanıt
İzlenebilirlik	Audit trail + event log	İç denetim	Log hash + rapor
Tüketici koruması	Pause + dispute	Ombudsman/hakem	Case dosyası
Operasyonel risk	SLA + resiliency test	Risk komitesi	Test raporu
Veri koruma	Selective disclosure	Hukuk + uyum	Erişim kayıtları

4.4 Çatışma çözüm akışları (detay)

Senaryo A (AML talebi): Regülatör talebi alındığında, önce hukuki dayanak doğrulanır ve talebin kapsamı netleştirilir. Sistem, asgari veri seti önerir; şer‘î kurul bu setin zaruret ve maslahat şartlarıyla uyumunu değerlendirir. Uyuşmazlık halinde hakem heyeti devreye girer; karar ve ifşa edilen veri, değişmez kayıt olarak saklanır.

Senaryo B (çoklu ülke): İşlem taraflarının jurisdiction etiketleri üzerinden çatışma kuralları işletilir. Varsayılan ilke ‘sıkı olan uygulanır’dır; ancak bazı durumlarda bu imkânsız olabilir. Bu durumda işlem açılmaz (jurisdiction pause), devam eden akitler korunur ve hukuki çözüm kapısı işletilir.

Senaryo C (tüketici şikâyeti): Otomatik icra ile zarar doğma riski varsa, sistem ‘pause-then-review’ uygular. Bu, hem şer‘î zarar kaldırma ilkesi hem tüketici koruması için kritik bir güvenlik valfidir.

5. Değer Akışı ve Teşvik Tasarımı

5.1 Neden teşvik tasarımı zorunludur?

Oracle, depo ve laboratuvar ekosistemi; doğru veri ürettiği sürece sistemin emanet ve güven mimarisidir. Ancak bu aktörlerin yanlış teşviklerle yönlendirilmesi, sahte doğrulama (rubber-stamping), kartelleşme veya kalite düşüşü riskini artırır. Bu nedenle teşvik tasarımı; teknik tasarımın ayrılmaz parçasıdır.

Teşvik tasarımında iki ilke önerilir: (i) kaliteye bağlı ödeme (doğruluk, zamanında yanıt, bağımsızlık), (ii) ölçülü yaptırım (kasıtlı suistimal ile hata ayrımı). Bu ilkeler, hem şer‘î adalet hem operasyonel risk yönetimiyle uyumludur.

5.1.1 Oracle Bağımsızlığı, Yoğunlaşma Metrikleri ve De-Concentration Tetikleri

• Yoğunlaşma ölçümü: depo-lab-sigorta-oracle ekosistemi için Herfindahl-Hirschman Index (HHI) ve bağlı ortaklık grafı hesaplanır.
• Bu bölümde kullanılan özet çerçeve Tablo 5.1’de sunulmaktadır.
• Eşikler: HHI belirlenen eşiği aşarsa yeni oracle onboarding zorunlu olur; aynı gruptan ek doğrulayıcı kabul edilmez.
• Bağımsızlık beyanı: çıkar çatışması beyanları halka açık bir ‘ilişki haritası’ ile yayınlanır (gizlilik sınırlamaları gözetilerek).
• Rastgele denetim ataması: denetim havuzu atamaları üçüncü taraf tohumlu pseudo-random dağıtımla yapılır (anti-collusion).

Tablo 5.1 — Oracle Çeşitlilik Endeksi

Boyut	Ölçüt	Eşik	Yedekleme
Coğrafi	Farklı bölge sayısı	≥2	Alternatif bölge düğümü
Kurumsal	Bağımsız kurum	≥3	Hakem/alternatif doğrulama
Teknolojik	Metod çeşitliliği	≥2	Sensör + manuel çapraz

5.2 Değer akışı: kim, neden, nasıl öder?

Sistemin sürdürülebilirliği için ‘kim, neden, nasıl ödeyecek?’ sorusu netleşmelidir. Birinci kaynak, işlem başına hizmet bedelidir. İkinci kaynak, doğrulama/attestation bedelleridir. Üçüncü kaynak, denetim ve uyuşmazlık havuzlarıdır (tahkim, ombudsman). Dördüncü kaynak ise tekâfül/sigorta primidir.

Bu gelirler, faizsiz finans prensipleriyle uyumlu biçimde ‘hizmete karşılık’ olarak gerekçelendirilmelidir. Özellikle zaman değeri üzerinden otomatik fiyatlama yapan modeller, akit türüne göre şer‘î risk üretir; bu nedenle ücretlendirme şeffaf tarife ve maliyet kanıtına dayandırılır.

5.3 PPP ve sosyalizasyon

Pilotların en büyük maliyeti, zincir ücreti değil; saha koordinasyonu, eğitim, standardizasyon ve denetimdir. Bu maliyetlerin bir kısmı kamu destekleri veya kooperatif fonlarıyla sosyalize edilebilir. Ancak bu yaklaşım, şeffaflık ve denetim olmadan yozlaşma riskini artırır. Bu nedenle PPP modelinde açık raporlama, bağımsız denetim ve performans kriterleri zorunlu kabul edilir.

5.3.1 Performance-for-Funding (Şablon)

• Girdi: kamu/kooperatif katkısı (nakit, altyapı, eğitim bütçesi) ve hedeflenen çıktı (KPI seti).
• Ödeme kuralı: hibe/sübvansiyon dilimleri, sadece ölçülmüş KPI gerçekleşmelerine bağlanır (ör. veri kalitesi skoru, teslim gecikmesi, şikayet çözüm SLA).
• Denetim: her dilim için J1-J7 kanıt paketi + bağımsız denetçi imzası zorunlu.
• Çıkar çatışması beyanı: tüm kurul üyeleri ve doğrulayıcı aktörler için kamuya açık beyan haritası.

5.3.2 Tarife İspatı ve ‘Faizleşme Testi’

• Tarife dosyası: her ücret kalemi için maliyet bileşenleri (gaz, depo, lab, lojistik, çağrı merkezi) ve ölçüm yöntemi.
• Faizleşme testi: gecikme/temerrüt halinde ücret artışının APR-benzeri doğrusal faiz yapısına dönüşmemesi (ceza değil telafi).
• Erişilebilirlik tavanı: küçük üretici için coğrafi-gelir parametreli tavanlar; kamu/kooperatif sübvansiyon kriterleri.

5.3.3 PPP Şeffaflığı için Veri Sözlüğü

• Fon akışları: kaynak, amaç, tarih, miktar, ilgili KPI dilimi, hash referansı.
• İhale/sözleşme: tedarikçi, kapsam, SLA, teslimatlar, ihlal ve telafi kayıtları.
• Kamu panosu: sertifikasyon durumu, ihlal sayacı, telafi özetleri, SLA dağılımı.

7.1.1 Değişken Pencere Tasarımı (Bölgesel Kapasiteye Uyum)

• Bölgesel profil: depo/lab kapasitesi ve erişim koşulları için sınıf tanımı (A/B/C).
• Aşamalı hedefler: 24h -> 36h -> 24h dönüş planı; her sapma kamuya raporlanır.
• Sınır koşulu: 48 saat üstü gecikme -> zorunlu ikinci kalite testi + yedek oracle devreye alma.

7.1.2 İhlal Sonrası Otomatik Tetik Zinciri

1. SLA ihlali tespit edilir ve olay kaydı açılır (incident id).
2. Yedek oracle devreye alınır; şüpheli aktör karantinaya alınır (geçici askı).
3. İkinci kalite testi ve çapraz şahitlik zorunlu kılınır.
4. Otomatik telafi kuponu / ücret iadesi uygulanır; telafi kalemi tarife dosyasında gösterilir.
5. Kök neden analizi + düzeltici faaliyet; sonuçlar Audit Pack’e girer.
6. Bu bölümde kullanılan özet çerçeve Tablo 6.1’de sunulmaktadır.

6. Sosyo-Ekonomik Etki ve Ölçümleme

6.1 Etki iddialarını ölçülebilir kılmak

Fintek Fıkhı yaklaşımı, spekülasyonu azaltacağı, finansmana erişimi artıracağı ve adalet üreteceği iddiasındadır. Bu iddialar, pilotta ölçülebilir hâle getirilmezse; metin güçlü bir tasarım belgesi olarak kalsa da politika ve kurumlar nezdinde ikna üretmez.

Bu nedenle etki ölçümü iki kanalla yürütülür: zincir üstü kanıtlar (olay logları) ve zincir dışı sosyal ölçümler (anket, saha gözlemi, fiyat serileri). En kritik ölçüm, kontrol grubu karşılaştırmasıdır: pilot uygulanan havza/ürün ile benzer ama pilot dışı bir havza/ürün eşlenir.

Tablo 6.1 — KPI (Geniş)

Kategori	KPI	Tanım	Hedef
Erişim	Aktif üretici oranı	Kayıtlı ve işlem yapan üretici	%60
Erişim	Düşük teknoloji kanal	SMS/temsilci payı	%30+
Adalet	Şikâyet çözüm süresi	Median gün	<7 gün
Piyasa	Volatilite farkı	Kontrol grubuna göre	-%10
Operasyon	SLA ihlali	Hedef dışı olay	<%5

6.2 Digital divide ölçümü

Digital divide sadece cihaz sahipliği değildir; okuryazarlık, güven, zaman, temsilciye erişim ve şikâyet kanallarına ulaşım gibi unsurları içerir. Pilot raporunda, düşük teknoloji kanal kullanım oranı yanında ‘başarı oranı’ da ölçülmelidir: SMS ile başlatılan işlem kaç kez destek çağrısı gerektirdi? Temsilci işlemlerinin kaçında itiraz çıktı? Bu veriler, sistemin kapsayıcılığını ölçer.

6.3 Market Integrity Pack: Zincir Dışı Spekülasyon, OTC ve Söylenti İzleme

Sistemde transfer limitleri olsa bile, spekülasyon ikincil kanallardan (sosyal medya, türev sözleşmeler, gayriresmî piyasalar) oluşabilir. Bu nedenle pilot; yalnız zincir içi değil, zincir dışı fiyatlama ve söylenti dinamiklerini de izlemelidir. Kooperatif raporları, bu gözlemi düzenli biçimde üretir.

6.3.1 Gösterge Seti (Örnek)

• OTC hacim tahmini (temsilci işlemleri + nakit hareketleri + depo çıkışlarının korelasyonu)
• Söylenti skoru (sosyal medya metin madenciliği + yerel teyit hattı kayıtları)
• Fiyat sapması endeksi (pilot havza vs kontrol havza; ürün bazlı fark)
• Teslimli / teslimsiz işlem oranı ve istisna kullanım yoğunluğu
• Holding limit ihlali teşebbüsleri ve transfer zinciri yoğunluğu (graph metrics)

6.3.2 Alarm-İnceleme-Tedbir Zinciri

7. Alarm: Eşik aşımı (ör. fiyat sapması > X%, söylenti skoru > Y) otomatik tetikler.
8. İnceleme: ‘pause-then-review’ tetiklenir; delil listesi ve ilgili aktörler kilitlenir.
9. Tedbir: holding limit sıkılaştırma, oracle rotasyonu, ikinci kalite testi, temsilci askıya alma.
10. Kamu duyurusu: Üç cümle kuralı + zaman çizelgesi ile belirsizlik azaltılır.
11. Kapanış: Kök neden analizi + telafi + tekrarını önleme maddeleri Audit Pack’e girer.

6.3.3 Market Integrity Pack – Asgari Kanıt Listesi

• İlgili ürün/lot/parsel işlemleri ve hash referansları
• Söylenti/OTC kaynaklarının timestamp’li özetleri (kişisel veri maskeleme ile)
• Pause olayı, hakem kararı ve gerekçe kaydı
• Oracle attestation seti (depo kabul + lab raporu + sigorta/lojistik şahitliği)
• Bu bölümde kullanılan özet çerçeve Tablo 7.1’de sunulmaktadır.
• Telafi adımları, iptal/geri alma (rollback) kriterleri ve uygulama kayıtları

7. Performans, Ölçeklenebilirlik, Dayanıklılık

7.1 Sayısal hedeflerin gereği

Makale-2’de L2/rollup ve off-chain bileşenler önerilmiş olsa da, pilot yönetimi için sayısal hedefler zorunludur. Hedef yoksa ihlal yoktur; ihlal yoksa iyileştirme yoktur. Bu yüzden SLA tabloları sadece teknik metrik değil, yönetişim aracıdır.

SLA hedefleri pilot ölçeğine göre gerçekçi seçilmeli; ancak kullanıcı güvenini kırmayacak kadar da iddialı olmalıdır. Örneğin selem teslim doğrulaması 24 saati aşarsa, üretici için belirsizlik büyür; bu da sisteme güveni azaltır.

Tablo 7.1 — SLA

Hizmet	Hedef	İhlal Aksiyonu	Sorumlu
Selem aktivasyonu	<30 dk	Otomatik doğrulama	Platform
Teslim doğrulama	<24 saat	Yedek oracle + pause	Depo/Lab
Transfer finality	<2 dk	L2 yönlendirme	Platform
Dispute döngüsü	<7 gün	Hakem havuzu	Yönetişim

7.2 Dayanıklılık testleri (BCBS uyumu)

BCBS operasyonel dayanıklılık yaklaşımı, kritik iş hizmetlerinin tanımlanmasını ve tolerans eşiklerinin belirlenmesini ister. Fintek Fıkhı pilotunda kritik hizmetler: selem aktivasyonu, teslim doğrulama, encumbrance kontrolü, dispute pause ve reg-tech raporlama olarak tanımlanabilir.

Yılda en az iki kez; oracle kesintisi, depo offline, anahtar kompromisi, yüksek hacim testi uygulanır. Her test; tolerans eşiği, iyileştirme planı ve sorumlu atamasıyla raporlanır. Test raporu, Ek-J’deki kanıt paketi formatına göre arşivlenir.

7.3 Tedarik zinciri ve üçüncü taraf riski (NIST CSF 2.0)

NIST CSF 2.0, ‘Govern’ fonksiyonunda tedarik zinciri risk yönetimini vurgular. Bu pilotta tedarik zinciri, sadece yazılım kütüphaneleri değil; sensör üreticileri, laboratuvar cihazları, kimlik sağlayıcıları ve L2 operatörlerini de kapsar. Üçüncü tarafların denetlenebilirliği, uyumun ön şartıdır.

8. Dijital Uçurum ve Saha Operasyonları

8.1 Çok kanallı saha stratejisi

Saha operasyonu, kullanıcı deneyiminden bağımsız değildir. Pilotun en büyük riski, çiftçinin ‘teknoloji yüzünden’ finansmana erişememesi veya temsilciye bağımlı hâle gelmesidir. Bu nedenle üç kanal zorunludur: mobil uygulama, temsilci paneli ve SMS/USSD onay.

Her kanalın yetkisi sınırlanır. SMS ile sadece onay/ret ve teslim bildirimi yapılabilir; temsilci panelinde ise yetki, süreli VC ile verilir. Bu tasarım, hem erişimi artırır hem suistimali azaltır.

8.2 Temsilci modelinin kötüye kullanım önlemleri

Temsilci işlemleri için ‘çift onay’ zorunludur. Temsilci, işlemi başlatır; asil (üretici) SMS ile onaylar. Bu onay akışı, audit trail’de hem kanal hem kişi bazında kaydedilir. Temsilci suistimali şüphesi olduğunda, sistem otomatik olarak temsilci yetkisini askıya alır ve inceleme kapısını açar.

Temsilci ücretleri, erişilebilirlik ilkesine göre tavanlanmalı; aksi hâlde temsilci modeli yeni bir sömürü katmanı üretir. Bu nedenle temsilci tarife ve performans kriterleri, şer‘î kurul ve kooperatif yönetimi tarafından birlikte belirlenir.

8.3 Eğitim ve kapasite geliştirme

Pilot başarısı, eğitim başarısıdır. Eğitim; akdin şartları, dolandırıcılık örnekleri, mahremiyet, şikâyet kanalları ve temel kullanım adımlarını içerir. Eğitim çıktıları; katılım listeleri, kısa sınavlar ve saha gözlemleriyle kanıtlanır. Bu kanıtlar, pilot raporunun ayrılmaz parçasıdır.

9. Pilot ve Geçiş Rehberi

9.0 Havza Ölçeği Pilot: Yaşayan Laboratuvar (Smart City + Smart Tarım + Smart Yaşam)

Köy ölçeği tek başına kendi kendine yeten bir ekonomik ve lojistik sistem üretmez. Bu nedenle pilot birimi, en az bir ilçe-omurga ve ona bağlı onlarca köy/kasaba içeren bir ‘havza’ olarak tanımlanmalıdır. Havza; üretim, depolama, lojistik, tüketim, kamu hizmetleri ve piyasa erişimini birlikte modelleyen bir yaşayan laboratuvardır.

9.0.1 Havza Seçim Kriterleri

• Ürün çeşitliliği: en az 2-3 ana ürün (tahıl, meyve, hayvansal vb.) ve mevsimsellik.
• Lojistik ağı: lisanslı depo erişimi + laboratuvar kapasitesi + en az iki alternatif güzergah.
• Kurumsal omurga: kooperatif/üretici birlikleri + yerel yönetim destek kapasitesi.
• Dijital uçurum profili: düşük/orta/yüksek erişim alt kümeleri (SLA değişken pencereleri için).
• Piyasa bağlantısı: en az bir kent pazarı/hal/işleme tesisi bağlantısı.

9.0.2 Akıllı Tarım-Şehir-Yaşam Entegrasyonu

• Akıllı tarım: ürün sözlüğü, kalite bandı, sensör/ölçüm protokolleri, su ve girdi verimliliği KPI’ları.
• Akıllı şehircilik: lojistik/atık/enerji yönetimi, pazar yerleri, hizmet erişimi; veri yönetişimi.
• Akıllı yaşam: kapsayıcı erişim kanalları (SMS/USSD/temsilci), eğitim, şikayet mekanizmaları, mahremiyet.
• Hepsi için ortak ilke: her kritik kararın kanıtı Audit Pack’e bağlanır.

9.0.3 Örnek Havza Topolojisi: Hüdavendigar Dağ Köyleri Birliği (HÜDA BİR)

Kurumsal çerçeve açısından, HÜDA BİR’in bir mahallî idareler birliği olarak tasarlanması; havza ölçeğinde ortak yatırım, ortak denetim ve ortak hizmet (depo‑laboratuvar‑lojistik) kapasitesini hukuken sürdürülebilir kılar. Bu çerçeve, Mahallî İdare Birlikleri Kanunu ve ilgili mevzuatın izin verdiği “birlik üzerinden hizmet üretimi” mantığına yaslanır.[11]

Not: HÜDA BİR, tarihî “Hüdâvendigâr” adlandırmasının (Bursa ve havalisi) devamı olarak seçil edilmiş bir pilot kimliğidir.[1] Bölgenin “Cuma camileri–Cuma yeri pazar” etrafında oluşan kamusal-ekonomik örgütlenme tecrübesi, normatif (fıkhî) yaşam standardının sahaya nasıl indiğini göstermesi bakımından güçlü bir arka plan sunar.[2] Günümüzde ise kırılganlık düzeyi yüksek; göç veren ancak geri dönüş için lojistik, ekolojik ve pazar erişimi açısından avantajlı bir kuşaktır. Bu nedenle HÜDA BİR, “dezavantajı avantaja çeviren” küresel dayanışma fonlarını ve kardeş havza desteklerini çekebilecek tutarlı bir pilot örneklemdir.

Bu bölümde kullanılan özet çerçeve Tablo 9.1’de sunulmaktadır.

Örnek olarak Hüdavendigar Dağ Köyleri Birliği (HÜDA BİR) Dağ Yöresi (Büyükorhan, Harmancık, Keles, Orhaneli) ilçeleri ve bağlı köyleri; komşu havza etkileşimleri için Balıkesir Dursunbey, Kütahya Tavşanlı ve Domaniç’in komşu köyleri; Bursa ilçeleri (İnegöl, Kestel, Yıldırım, Osmangazi, Nilüfer, Mustafakemalpaşa) komşu kırsal alanları ile birlikte bir pilot havza kümesi oluşturabilir. Bu topoloji; üretim-tüketim-işleme hatlarını birlikte test etmeye ve ‘kardeş havza’ modeline geçiş için referans üretmeye elverişlidir.

9.0.4 Kurumsal Araç: Havza Birliği ve Şeffaf Ayrışma Protokolü

• Havza Birliği: yerel yönetimler, kooperatifler ve lisanslı doğrulayıcıların yer aldığı bir Mahalli İdareler Birliği kurgusu.
• Şeffaf ayrışma: yerel mevzuat veya uygulama pratikleriyle şer’i/etik ilkelerin çatıştığı alanlar önceden listelenir, kamuya ilan edilir.
• Ayrışma yönetimi: çatışma alanlarında ‘pause-then-review’ + alternatif süreç (fallback) tanımı zorunludur.

9.1 İlk 90 gün planı

Tablo 9.1 — İlk 90 Gün

Hafta	Görev	Teslimat	Sahip
1–2	Veri sözlüğü + ürün standardı	Şablonlar	Teknik + saha
3–4	Depo/lab sözleşmeleri	SLA + tarife	Hukuk + risk
5–6	Selem MVP	Canlı pilot	Mühendislik
7–8	Denetim paketi	Rapor	İç denetim
9–12	Eğitim + stres test	Test raporu	Risk + saha

9.2 PMO ritmi ve raporlama

Pilot PMO, haftalık operasyon toplantıları (saha + teknik), aylık mini-denetimler (şer‘î kurul + iç denetim) ve 90 günlük regülatör bilgilendirme paketleri üretir. Bu ritim, sistemin yalnız teknik değil kurumsal bir proje olduğunu sahaya hissettirir.

Pilot boyunca açık bir ‘bulgu yönetimi’ (issue tracking) sistemi kullanılmalıdır. Her bulgu; önem (kritik/önemli/normal), kök neden, düzeltici faaliyet, sorumlu ve hedef tarih ile yönetilir.

9.3 Go/No-Go kapıları

Faz geçişleri için go/no-go kapıları tanımlanır. Örnek: Seviye-1’den Seviye-2’ye geçiş için çift rehin olayı 0, SLA ihlali < %5, şikâyet çözüm süresi < 7 gün ve bağımsız denetim bulgularında kritik seviye 0 şartı aranır. Bu eşikler sağlanmadan ölçek büyütmek, sistemin güven kredisi birikmeden borca girmesi demektir.

10. Beklenmeyen Sonuçlar ve Red Team

10.1 Davranışsal riskler ve arayüz

Kullanıcılar, yüksek getiriyi olduğundan daha muhtemel görmeye eğilimlidir. Tokenizasyon dili, kullanıcı zihninde ‘yatırım’ çağrışımı yaparsa, pilotun sosyal kabulü ve regülasyon riski artar. Bu nedenle arayüz ve iletişim dili tasarımın parçasıdır: risk bildirimi, sınırlı transfer ve net amaç beyanı.

Arayüzde ‘varsayılan’ seçenekler, kullanıcı davranışını belirler. Örneğin varsayılan teslim tarihi veya varsayılan kalite bandı, tarafların rızasını zayıflatır. Bu yüzden kritik alanlarda varsayılan değer kullanılmaz; kullanıcı onayı zorunlu kılınır.

10.2 Kurumsal riskler: oracle karteli ve yolsuzluk

Oracle kartelleşmesi, sistemin en büyük yapısal riskidir. Çeşitlilik endeksi ve rastgele denetimler tek başına yetmez; ekonomik teşvikler ve yaptırımlar da gereklidir. Kartelleşme şüphesinde, sistem yeni oracle eklemesini zorunlu kılan politikayı tetikler; ayrıca bağımsız dış denetim devreye girer.

Yolsuzluk riskine karşı, şahitlik verilerinin çapraz kaynaklardan doğrulanması (depo + lab + sigorta + taşımacı) ve delil zincirinin bozulmaması gerekir. Bu, Makale-2’deki ‘çoklu şahitlik’ deseninin uygulamadaki karşılığıdır.

10.3 Red team tatbikatları

Red team tatbikatları; oracle manipülasyonu, depo suistimali, kimlik sahteciliği ve içerden tehdit senaryolarını oyunlaştırarak test eder. Tatbikatın çıktısı, ‘kanıt’ üretimidir: hangi loglar oluştu, hangi alarm tetiklendi, hangi prosedür işletildi ve kullanıcıya nasıl duyuruldu. Bu çıktılar, Ek-J’deki kanıt paketi formatında saklanır.

11. Uygulama Senaryoları

11.1 Selem ile buğday ön finansmanı (uçtan uca)

Adım 1: Ürün standardı seçilir (buğday için kalite bandı, nem oranı, yabancı madde oranı, ölçü birimi). Bu standart, hem akit metninde hem oracle doğrulamasında aynı sözlükle temsil edilir.

Adım 2: Üretici DID/VC ile kayıt olur. Kimlik doğrulama; asgari veri ilkesiyle yapılır; pilotta kooperatif, kayıt otoritesi rolünü üstlenebilir.

Adım 3: Selem akdi oluşturulur. Peşin ödeme kanıtı (ödeme mesajı hash’i) sözleşmeye bağlanır. Teslim takvimi ve teslim yeri açıkça yazılır; belirsizliğe izin verilmez. (Hanefî selem şartları için bkz.)[8]

Adım 4: Depo kabul ve laboratuvar raporu ile attestation üretilir. Çoklu şahitlik; depo raporunu, lab raporunu ve gerekiyorsa taşımacı kaydını birleştirir.

Adım 5: Teslim doğrulama sonrası akit kapanır. Uyuşmazlık halinde ‘pause-then-review’ işletilir; hakem kararı ve gerekçesi kayıt altına alınır.

11.2 Dijital süftece ile ticaret finansmanı

Süftece, tarihî olarak borç/ödeme emrinin güvenli aktarımıdır. Dijital süftece senaryosunda; ihracatçı, ithalatçı ve garantör rolleri tanımlanır. Garantör, tekâfül veya lisanslı bir kurum olabilir. Amaç, malın teslimi ile ödemenin güvenli eşleşmesidir.

Şer‘î açıdan kritik riskler; riba benzeri fiyatlama, belirsiz gecikme cezaları ve aşırı garanti yükleridir. Bu nedenle parametre seti; hizmet bedelini şeffaflaştırır, ceza/teminatı ölçülü kılar ve uyuşmazlık halinde pause mekanizmasını devreye sokar.

11.3 Mezhep geçiş protokolü (kullanıcı perspektifi)

Pilot sahasında kullanıcıların mezhep parametre seti beyanı değişebilir. Bu durumda bir ‘mezhep geçiş protokolü’ uygulanır: devam eden akitler, kurulduğu parametre setiyle tamamlanır; yeni akitler, yeni parametre setiyle başlatılır. Çifte standardı önlemek için; aynı varlık üzerinde farklı parametre setleriyle çelişen haklar oluşturulamaz; encumbrance kayıtları bunu engeller.

12. Sonuç ve Makale-4’e Köprü

Makale-3, Fintek Fıkhı serisinin uygulama ayağını tamamlar: mimariyi pilot fazlarına, yönetişim mekanizmalarına, regülasyon çatışma senaryolarına, teşvik tasarımına ve sosyo-ekonomik ölçümlemeye bağlar. Böylece sistem, yalnızca tasarım olarak değil; dağıtılabilir bir kamu/özel altyapı önerisi olarak somutlaşır.

Makale-4’te; pilot verilerinden hareketle ekonomik modelin ampirik doğrulanması, spekülasyon ve piyasa manipülasyonu dinamikleri, mezhepler arası uyumun standartlaştırılması ve uluslararası entegrasyon stratejileri geliştirilmelidir.

Bu revizyonda pilot biriminin köy değil havza olarak tanımlanması; akıllı tarım-şehir-yaşam entegrasyonunun ölçülebilir KPI setleriyle birlikte kurgulanması ve ‘yavaş şehir’ benzeri sürdürülebilirlik çerçeveleriyle uluslararası akreditasyona (BM ölçekli işbirlikleri dahil) hazırlanması hedeflenmiştir. Makale-4, bu havza pilotlarını kardeş havzalar ağına bağlayan standardizasyon, sertifikasyon ve meşruiyet mimarisini tamamlayacaktır.

Eleştirilere cevap matrisi – Makale-3 (HÜDA BİR)

Aşağıdaki tabloda her eleştiri için (i) savunma/cevap, (ii) metne eklenecek netleştirme paragrafı ve (iii) beklenen kanıt/çıktı açıkça belirtilmiştir.

Eleştiri	Cevap	Metinde eklenecek netleştirme (1 paragraf)	Beklenen kanıt/çıktı (test suite / pilot metriği)
MVP/Seviye-1 gereksinimleri fazla ağır; “analiz felci” ve yüksek sürtünme (zaman/maliyet) riski.	Makale-3’ün “dağıtım disiplini” yaklaşımı, sahada güven üretmek için asgari kanıtı zorunlu kılar. Bununla birlikte, eleştiri haklıdır: ilk 90 günde “Lite-MVP” tanımı yapılarak işlem sürtünmesi bütçelenmeli ve kademeli sertifikasyon daha görünür bir “pilot hunisi” olarak yazılmalıdır.	Makale-3’te MVP, tek bir eşik değil; (i) Lite-MVP (0–90 gün), (ii) Seviye-1 (90–270 gün), (iii) Seviye-2 (270+ gün) olarak tanımlanır. Lite-MVP’de amaç “en küçük doğru sistem”i korurken sürtünmeyi minimize etmektir: yalnızca peşin ödeme kanıtı + teslim yeri doğrulaması + temel kimlik/doğrulama kaydı zorunlu tutulur; encumbrance ve geniş audit pack, hacim ve risk eşiği aşıldığında devreye girer.	Pilot metriği: (a) ortanca işlem süresi, (b) ortanca doğrulama maliyeti, (c) terk oranı (drop-off), (d) hatalı/eksik kayıt oranı. Test suite: Lite-MVP → Seviye-1 geçiş koşulu testleri (eşik aşımı, zorunlu alanlar, red/accept kuralları).
Pilot havza seçimi ve “neden bu bölge?” gerekçesi literatüre taşınabilir bir referans model için daha kuvvetli gerekçelendirilmelidir.	Eleştiri yerindedir. Pilot alanın yalnız teknik uygunlukla değil, tarihî-kurumsal hafıza, sosyo-ekonomik kırılganlık ve ölçeklenebilir lojistik avantajlarla gerekçelendirilmesi, pilotun “referans model” iddiasını güçlendirir.	Makale-3’te pilot bölge adı “Hüdavendigar Dağ Köyleri Birliği (HÜDA BİR)” olarak sabitlenecek ve seçimin gerekçesi şu çerçevede netleştirilecektir: (i) tarihî Hüdavendigar hafızası ve Osmanlı öncesi kamusal yaşam pratikleri; (ii) Cuma camileri–Cuma yeri pazar örgüsü ile fıkhın gündelik hayata tercüme tecrübesi; (iii) güncel kırılganlık (göç, düşük gelişmişlik) nedeniyle küresel dayanışma/geri dönüş projeleri için tutarlı bir hedef; (iv) temiz toprak–orman–su ekotonları ve çok modlu lojistik (kara/demir/deniz) ile Türkiye nüfusunun önemli kısmına kısa erişim avantajı.	Çıktı: “HÜDA BİR Seçim Gerekçesi” kutusu + bölge profil kartı. Pilot metriği: geri dönüş katılımı, kooperatif kapsaması, lojistik maliyet endeksi, organik/iyi tarım sertifikasyon oranı.
Oracle/depo/lab çıkar çatışması ve kartelleşme; küçük havzada HHI gibi metrikler yetersiz kalabilir.	Doğru: küçük havzada “az aktör” sorunu vardır. Savunma, HHI’a ek olarak (i) bağlılık grafı beyanı, (ii) rastgele atama/denetim, (iii) yedek oracle (fallback) ve (iv) uzaktan şahitlik (IoT/kamera) gibi “de-konsantrasyon tetikleyicileri” ile güçlendirilmelidir.	HÜDA BİR’de doğrulayıcılar için iki katmanlı güven tasarımı uygulanacaktır: (1) birincil doğrulayıcı (depo/lab) ve (2) yedek doğrulayıcı (fallback oracle). Tek depo/tek lab gibi yoğunlaşma koşullarında sistem otomatik olarak uzaktan şahitlik, kooperatif kefaleti ve/veya bölge dışı ikinci lab doğrulamasını zorunlu kılar. Doğrulayıcı ilişkileri (ortaklık/akrabalık/çıkar bağı) halka açık “bağlılık grafı”nda beyan edilir; eşik aşımında yeni doğrulayıcı onboarding’i tetiklenir.	Test suite: (a) yoğunlaşma tetik testi, (b) fallback oracle zorunluluk testi, (c) rastgele denetim tohum doğrulama testi. Pilot metriği: doğrulayıcı çeşitlilik endeksi, itiraz/uyuşmazlık oranı, sahtecilik tespit sayısı ve telafi süresi.
Dijital uçurum ve temsilci modeli; temsilci suistimali yeni bir bağımlılık/sömürü katmanı doğurabilir.	Makale-3’ün çok kanallı tasarımı (SMS/USSD/temsilci) doğru yöndedir. Savunma, temsilci için “menfaat ayrılığı (SoD)”, ücret tavanları, otomatik askıya alma tetikleri ve bağımsız şikâyet/denetim kanıtlarıyla güçlendirilmelidir.	HÜDA BİR’de dijital erişim, ‘hak’ olarak ele alınır: kullanıcı SMS/USSD ile işlem yapabilir; temsilci yalnızca teknik kolaylaştırıcıdır. Temsilci, ticari taraf (alıcı/satıcı) olamaz; aynı işlemde menfaat ilişkisi tespitinde otomatik askıya alma tetiklenir. Temsilci ücretleri tavanlıdır ve ücret dağılımı/şikâyet oranı aylık kamu raporunda yayınlanır; yaşlı/düşük okuryazarlık grupları için yerinde eğitim ve basılı makbuz/QR karşılığı sağlanır.	Pilot metriği: temsilci başına ortanca ücret, şikâyet oranı, askıya alma sayısı, dijital kanal kullanım oranı. Test suite: SoD kuralı ihlal testi; ücret tavanı doğrulama; şikâyet → pause-then-review iş akışı testi.
Regülasyon entegrasyonu küresel standartlara (FATF/MiCA) dayanıyor; yerel bağlayıcılık (KVKK/MASAK/BDDK/SPK vb.) köprüsü zayıf kalabilir.	Küresel standartlar, tasarım hedefi ve ortak dil sağlar; yerel bağlayıcılık ise uygulanabilirliğin şartıdır. Bu nedenle Makale-3’e “TR Uyum Ek’i” eklenmesi, savunmayı güçlendirir ve ‘seçmeci regülasyon’ eleştirisini kapatır.	Makale-3’te, FATF/MiCA hedefleri “tasarım kısıtları” olarak korunurken Türkiye bağlamı için ayrı bir “TR Uyum Ek’i” eklenecektir. Bu ek; KVKK veri minimizasyonu/amaç sınırlılığı, MASAK AML/CFT yükümlülükleri, BDDK/SPK gözetimi ve varsa lisanslı depo/ürün senedi rejimlerini (öncelik, kayıt, delil standardı) aynı L0–L7 katmanlarına eşleyerek somut bir uyum matrisi sunacaktır.	Çıktı: TR Uyum Matrisi (kurum/yükümlülük → tasarım kontrolü), veri işleme envanteri, DPIA taslağı. Pilot metriği: uyum ihlali sayısı, erişim talebi yanıt süresi, denetim bulgu sayısı.
Etki ölçümü KPI’ları var; fakat karşı-olgusal (counterfactual) tasarım, kontrol grubu ve veri protokolü net değil.	Makale-3’te etki ölçüm başlığının bulunması doğru bir niyettir; bunu hakem standardına taşımak için minimum metodoloji (baseline + kontrol grubu + zaman ufku + veri yönetişimi) tek sayfada standartlaştırılmalıdır.	HÜDA BİR pilotunun etkisi, yalnızca token fiyatı veya hacim ile değil; (i) gelir oynaklığı azalımı, (ii) finansmana erişim maliyeti, (iii) ihtilaf çözüm süresi, (iv) yerel çarpan (local multiplier) gibi göstergelerle ölçülecektir. Makale-3’e; eşleştirilmiş kontrol grubu (benzer ürün/ölçek/coğrafya), başlangıç ölçümü (baseline), 6–12 ay zaman ufku ve veri anonimleştirme/seçmeli ifşa protokolünü tanımlayan bir “Etki Değerlendirme Protokolü” paragrafı eklenecektir.	Pilot metriği: 12 metrik/4 boyut skor kartı; aylık etki raporu. Çıktı: anonimleştirilmiş veri sözlüğü, eşleştirme kriterleri, pre-post analiz raporu (etki büyüklüğü + güven aralığı).
Token kavramı spekülatif algılanabilir; sistemin “yatırım ürünü” gibi okunması riski.	Savunma: token burada menkul kıymet değil; teslim/kalite/rehin durumuyla sıkı bağlı ‘mal temsili kayıt’tır. Mint/burn eşleşmesi, teslim oranı ve işlem amaç kısıtları ile spekülasyon daraltılır. Metinde ‘algı yönetimi’ ve piyasa bütünlüğü daha görünür kılınmalıdır.	HÜDA BİR tokeni, ‘yatırım vaat eden’ bir araç değil; malın teslim, kalite ve encumbrance durumunu temsil eden izlenebilir bir kayıttır. Bu nedenle mint/burn, depo teslimi ve çoklu şahitlik kanıtına bağlıdır; teslimsiz ikinci el devreler risk profiline göre kısıtlanır. Metne, tokenın hukuki/iktisadi niteliğini ve spekülasyonla mücadele için “Market Integrity Pack”in sahaya uyarlanmış sürümünü açıklayan bir netleştirme paragrafı eklenecektir.	Pilot metriği: teslimli işlem oranı, volatilite farkı (kontrol piyasaya göre), olağandışı fiyat sapması alarm sayısı. Test suite: mint/burn kanıt zorunluluğu testi; devretme kısıtları testi; piyasa bütünlüğü alarm tetik testi.
Editoryal tutarlılık: Makale-1/2’ye atıf netliği, tablo/şema numaraları, eklerin sırası, İngilizce başlıkların Türkçeleştirilmesi, Makale-3 ↔ Makale-4 kaynakça hizası.	Bu eleştiriler “savunma”dan çok yayıma hazırlık gereğidir; tamamı kabul edilebilir düzeltmelerdir. Makale-3 ile Makale-4 arasında referans ve kaynakça hizalaması ayrıca yapılacaktır.	Makale-3’ün girişine Makale-1 ve Makale-2’ye doğrudan köprü cümlesi eklenecek; tablo/şema numaralandırması bölüm bazında standartlaştırılacak; ekler alfabetik sıraya alınacak; “Digital Divide” başlığı “Dijital Uçurum ve Saha Operasyonları” olarak Türkçeleştirilecektir. HÜDA BİR adlandırması metin genelinde tutarlı biçimde kullanılacak ve pilot bölge kartı ile birlikte tanımlanacaktır.	Çıktı: editoryal kontrol listesi (TOC, tablo listesi, ek listesi), referans eşleştirme raporu (Makale-3 ↔ Makale-4), güncellenmiş ortak kaynakça.

EKLER (A-P)

Ek-A — Şer‘î Kurul Denetim Checklist’i (Detay)

• Peşin ödeme kanıtı: ödeme zamanı, miktar, para birimi, ödeme yöntemi ve akit ile bağlanabilirlik (hash).
• Nitelik ve miktar belirginliği: ürün sözlüğü, kalite bandı, ölçüm yöntemi ve tolerans aralığı.
• Teslim takvimi ve yer: tarih aralığı, teslim noktası, gecikme prosedürü ve fesih koşulları.
• Ücretlerin hizmete karşılığı: platform ücreti, oracle ücretleri, denetim fonu; şeffaf tarife ve gerekçe.
• Encumbrance kontrolü: aynı varlık üzerinde çelişen hakların oluşmadığının kanıtı.
• Uyuşmazlık çözümü: pause kaydı, hakem kararı, gerekçe ve taraflara bildirim.
• Mezhep parametre seti: kullanıcı beyanı, geçiş protokolü, çifte standardın engellenmesi.
• Sosyal adalet: temsilci suistimali, dışlama, şikâyet maliyeti, erişim kanalları.

Ek-B — İç Denetim Checklist’i (Detay)

• Yetki ayrımı (SoD): geliştirme, onay, operasyon, denetim rolleri ayrılmış mı?
• Anahtar yönetimi: rotasyon, kompromi prosedürü, revocation tatbikatı yapılmış mı?
• Oracle SLA: yanıt süresi, hata oranı, yedek protokol kayıtları, çeşitlilik endeksi.
• Log bütünlüğü: hash zinciri, saklama süresi, erişim kontrolleri, değişmezlik kanıtı.
• Olay müdahalesi: incident playbook, tatbikat kayıtları, iyileştirme aksiyonları.
• Veri koruma: erişim yetkileri, seçmeli ifşa kayıtları, gerekçeli talep dosyaları.
• Üçüncü taraf riski: sensör sağlayıcıları, bulut, L2 operatörleri için sözleşme ve denetim.

Ek-C — Pilot Veri Toplama Formları (Şablonlar)

C1. Üretici anketi (aylık): gelir/maliyet; finansman ihtiyacı; teslim deneyimi; memnuniyet; erişim kanalı; temsilci kullanımı; şikâyet durumu; eğitim ihtiyacı.

C2. Tüccar anketi (aylık): fiyat oluşumu; teslim gecikmeleri; kalite uyuşmazlıkları; alternatif piyasa kanalları; manipülasyon şüphesi.

C3. Kooperatif raporu (haftalık): eğitim katılımı; temsilci işlemleri; saha sorunları; destek çağrıları; anomali kayıtları.

C4. Reg-tech paket (aylık): özet işlem hacmi; şüpheli işlem sayısı; talep-ifşa kayıtları; yaptırım ve düzeltici faaliyetler.

C5. Şer‘î kurul raporu (aylık): bulgular; tavsiyeler; parametre değişikliği önerileri; sosyal adalet notları.

Ek-D — Risk Register (Detay)

Tablo D.1 — Risk Register

Risk	Olasılık	Etki	Kontrol	Kanıt
Oracle manipülasyonu	Orta	Yüksek	Çoklu şahitlik + audit	Tatbikat raporu + log
Depo kollüzyonu	Düşük/Orta	Yüksek	Rastgele denetim + sigorta	Denetim bulgusu
Kimlik sahteciliği	Orta	Yüksek	DID/VC + revocation	Revocation testi
Analiz felci	Orta	Orta	Seviye-1 MVP + değer kanıtı	Gate kararları

Ek-E — Operasyon Playbook’ları (Detay)

E1. Oracle kesintisi: (1) alarm tetiklenir, (2) yedek oracle devreye alınır, (3) etkilenen akitler ‘riskli’ olarak işaretlenir, (4) kullanıcıya bildirim yapılır, (5) 24 saat içinde kök neden raporu üretilir.

E2. Depo suistimali: (1) teslim dondurma (pause), (2) bağımsız denetim görevlendirme, (3) sigorta/tekâfül mekanizması tetikleme, (4) hakem kararı, (5) sonuçların şeffaf raporu.

E3. Anahtar kompromisi: (1) revocation, (2) yeni anahtar seti, (3) etkilenen işlem aralığının risk taraması, (4) regülatör/şer‘î kurul bilgilendirme paketi, (5) kullanıcıya telafi adımları.

E4. Şikâyet dalgası: (1) şikâyet sınıflaması, (2) kök neden analizi (ücret, arayüz, temsilci), (3) düzeltici faaliyet, (4) eğitim kampanyası, (5) 30 gün sonra yeniden ölçüm.

Ek-F — Örnek Sözleşme Maddeleri (Taslak Metin)

F1. Depo SLA: ‘Depo, kabul attestation’ını en geç 6 saat içinde üretir; gecikme halinde kullanıcıya bildirim yapılır ve alternatif depo opsiyonu sunulur.’

F2. Oracle bağımsızlığı: ‘Oracle, çıkar çatışmasını beyan eder; aynı işlemde taraflardan biriyle bağlı ortaklık ilişkisi varsa görev alamaz.’

F3. Mahremiyet: ‘Veri paylaşımı, gerekçeli talep ve asgari veri ilkesiyle yapılır; erişim kayıtları denetlenebilir şekilde saklanır.’

F4. Tahkim: ‘Uyuşmazlıklar, önce pause ile dondurulur; ardından hakem heyeti gerekçeli karar üretir; masraf tavanı uygulanır.’

Ek-G — Ekonomik Model Notları (Detay)

G1. Ücret bileşenleri: hizmet bedeli + doğrulama bedeli + denetim fonu + sigorta/tekâfül primi. Pilot raporunda her bileşen ayrı raporlanır.

G2. Sürdürülebilirlik: toplam gelir ≥ toplam maliyet + yedek fon. Yedek fon, kriz ve telafi ödemeleri için zorunludur.

G3. Teşvik uyumu: kalite puanı yüksek oracle daha fazla gelir elde eder; kötü performans kesinti ile karşılanır; kasıtlı suistimalde yaptırım uygulanır.

G4. Erişilebilirlik: ücretler, küçük üreticiyi sistem dışına itmeyecek şekilde tavanlanır; gerekirse kamu/kooperatif sübvansiyonu ile dengelenir.

Ek-H — Uluslararası Entegrasyon (Detay)

H1. Standartlar: ISO 20022 uyumlu mesajlaşma, DID/VC kimlik standardı, reg-tech raporlama paketleri.

H2. Entegrasyon stratejisi: önce kapalı devre, sonra lisanslı aracılar, sonra sınır aşan koridorlar (jurisdiction tags).

H3. Kurumsal işbirliği: AAOIFI/IFSB şer‘î standartlarıyla uyumlu sürüm yönetişimi ve ortak kontrol sözlüğü.

Ek-I — Gün Gün Pilot Uygulama Rehberi (Örnek)

I1. Gün 1–3: Paydaş haritası çıkarılır; kooperatif, depo, laboratuvar, yerel yönetim ve şer‘î kurul temsilcileriyle görev tanımları yapılır. Veri sözlüğü çalışması başlatılır.

I2. Gün 4–10: Ürün standardı netleştirilir; örnek kalite ölçümleri yapılır. Depo ve lab SLA taslakları hazırlanır; ücret tarifesi şeffaflaştırılır.

I3. Gün 11–20: Selem MVP ortamı kurulup test edilir; örnek akitler sahte veriyle çalıştırılır. Audit pack üretimi doğrulanır. Temsilci paneli ve SMS onay akışı denenir.

I4. Gün 21–30: Saha eğitimi yapılır; üretici kayıtları alınır. İlk selem akitleri sınırlı sayıda (ör. 10) açılır. Destek hattı devreye girer.

I5. Gün 31–60: Operasyon ritmi oturur; haftalık sorun listesi ve düzeltici faaliyetler yürür. İlk mini-denetim ve ilk oracle SLA raporu üretilir.

I6. Gün 61–90: Stres testleri uygulanır; red team tatbikatı yapılır; pilot kapanış raporu (KPI, maliyet, şikâyet, denetim bulgusu) hazırlanır.

Ek-J — Denetim Kanıt Paketi Şablonu (Audit Pack)

J1. Akit Kanıtı: akit kimliği, taraf DID’leri (pseudonym), akit şablonu sürümü, parametre seti, imza kayıtları.

J2. Ödeme Kanıtı: ödeme mesajı hash’i, zaman damgası, ödeme doğrulama sonucu, bağlantılı akit referansı.

J3. Encumbrance Kanıtı: varlık kimliği, rehin/temlik kayıtları, çift rehin kontrol sonucu, log referansı.

J4. Oracle Kanıtı: depo kabul attestation’ı, lab raporu, şahitlik imzaları, çeşitlilik endeksi snapshot.

J5. Dispute Kanıtı: pause olayı, delil listesi, hakem kararı, gerekçe, bildirim kayıtları.

J6. Reg-tech Kanıtı: raporlama periyodu, özet metrikler, talep-ifşa kayıtları, uyum ekinin imzaları.

J7. Güvenlik Kanıtı: anahtar rotasyon kayıtları, revocation tatbikatı, incident raporları, üçüncü taraf denetim özetleri.

Ek-K — Örnek Raporlar (Başlık Şablonları)

K1. Aylık Şer‘î Kurul Raporu: bulgular, risk değerlendirmesi, parametre değişikliği önerileri, sosyal adalet notları.

K2. Aylık İç Denetim Raporu: SLA ihlalleri, anomali tespiti, düzeltici faaliyetler, tedarik zinciri riskleri.

K3. 90 Günlük Regülatör Bilgilendirme Paketi: özet işlem hacmi, uyum kanıtı, şüpheli işlem istatistiği, tüketici şikâyetleri, telafi adımları.

K4. Pilot Kapanış Raporu: KPI sonuçları, maliyet/gider, öğrenimler, faz-2 önerileri.

Ek-L — Saha Protokolleri ve Prosedürler (Detay)

L8. Olay müdahalesi protokolü: Kritik olaylarda (anahtar kompromisi, oracle kartel şüphesi, depo suistimali) sistemin ‘dondurma ve kanıt toplama’ refleksi otomatik olmalıdır. Olay raporu; olay zaman çizelgesi, alınan aksiyonlar, etkilenen işlem sayısı, telafi planı ve tekrarını önleme maddelerini içerir.

L7. Eğitim protokolü: Eğitim, tek seferlik değil döngüseldir. Pilotun ilk ayında yoğun, sonraki aylarda hatırlatıcı eğitim uygulanır. Eğitimde ‘yanlış anlatı’ (yatırım vaadi) özellikle engellenir. Eğitim çıktıları; katılım, kısa sınav ve saha gözlemi ile kanıtlanır.

L6. Şikâyet protokolü: Şikâyet, minimum bilgi ile alınır ve kullanıcıya takip numarası verilir. Şikâyet kanalı; telefon, kiosk ve SMS ile erişilebilir olmalıdır. Şikâyet çözüm süresi KPI olarak izlenir; kritik şikâyetlerde (dolandırıcılık şüphesi, temsilci suistimali) 24 saat içinde ön değerlendirme zorunludur.

L5. Teslim protokolü: Teslim doğrulaması, depo ve lab kanıtlarıyla birlikte yapılır. Teslim tamamlandığında taraflara ‘kapanış makbuzu’ verilir. Teslim anlaşmazlığında otomatik pause uygulanır; ürün hareketi durur ve hakem süreci başlar.

L4. Laboratuvar raporu protokolü: Laboratuvar, örnekleme metodunu (numune alma) rapora yazar. Örnekleme, depo personelinden bağımsız yürütülür. Rapor, imzalı veri olarak zincire (veya kanıt deposuna) bağlanır; rapor revizyonu gerekiyorsa yeni bir sürüm olarak üretilir ve eski sürüm iptal edilir.

L3. Depo kabul protokolü: Depoya girişte ürün standardı kontrol edilir; ölçüm cihazları kalibrasyon kayıtlarıyla birlikte raporlanır. Kabul attestation’ı, kalite bandı ve miktar alanlarını içerir; eksik alanla attestation üretilmez. Kabul gecikmesi SLA ihlali sayılır ve otomatik bildirim tetiklenir.

L2. Temsilci yetkilendirme protokolü: Temsilci yetkisi süreli ve kapsamlıdır. Yetki kapsamı; hangi işlemleri başlatabileceği, hangi işlemlerde çift onay gerekeceği ve hangi eşiklerde otomatik askıya alma olacağıyla tanımlanır. Temsilci değişimi, eski yetkinin iptali (revocation) ve yeni yetkinin verilmesi olarak iki adımlı yürütülür; arada boşluk bırakılmaz.

L1. Kayıt (onboarding) protokolü: Üretici kaydı alınırken (i) kimlik doğrulama seviyeleri, (ii) veri minimizasyonu, (iii) rıza metni ve (iv) mezhep parametre seti beyanı birlikte yürütülür. Kayıt tamamlandığında sistem, üreticiye iki ayrı kanıt verir: yazılı/QR makbuz ve SMS onay kaydı. Bu iki kanıt, sahada güven üretir.

Bu ek, pilotun sahada ‘teorik doğruluk’ yerine ‘operasyonel doğruluk’ üretmesi için gereken prosedürleri standartlaştırır. Amaç; temsilci, depo, laboratuvar ve kooperatif personelinin aynı olayda farklı işlem yapmasını engellemek ve kanıt üretimini otomatikleştirmektir.

L14. Parametre güncelleme protokolü: Mezhep parametre seti veya ücret/tolerans değerleri güncelleneceğinde; önce test ortamında koşulur, sonra sınırlı grupta uygulanır, ardından genel yayına alınır. Geri alma (rollback) planı zorunludur.

L13. Çıkar çatışması protokolü: Kooperatif yöneticileri, depo ve oracle operatörleri için çıkar çatışması beyanı alınır. Bağlı ortaklık, akrabalık, komisyon ilişkisi gibi beyanlar kayıt altına alınır ve bağımsız denetime açık tutulur.

L12. Şeffaflık protokolü: Pilotun aylık özet raporu kamuya açık bir formatta yayımlanır: hacim, ücret bantları, şikâyet sayısı, SLA ihlalleri ve alınan düzeltici faaliyetler. Kişisel veriler asla açıklanmaz; ancak sistem performansı şeffaftır.

L11. Veri kalitesi protokolü: Saha verileri (anketler, fiyat serileri, destek çağrıları) için veri kalite kuralları tanımlanır: eksik alan oranı, tutarsız kayıt oranı ve zamanında giriş oranı. Veri kalitesi düşerse, pilot sonuçları yorumlanamaz; bu nedenle veri kalitesi KPI olarak izlenir.

L10. Telafi protokolü: SLA ihlali, yanlış doğrulama veya hatalı kesinti durumunda telafi mekanizması işletilir. Telafi; nakit iade, ücret indirimi veya denetim fonundan ödeme şeklinde olabilir. Telafinin ölçütleri önceden tanımlanır; keyfî telafi yapılmaz.

L9. Ücret ve tarife protokolü: Tarife değişiklikleri, en az 14 gün önce duyurulur; pilot boyunca ani tarife artışı yapılmaz. Ücretler kalem kalem açıklanır ve kullanıcı makbuzunda ayrı satır olarak görünür. Bu görünürlük, şer‘î açıdan ‘haksız kesinti’ şüphesini azaltır ve güven üretir.

Tablo L.1 — Saha Protokolleri ve Üretilen Kanıtlar

Protokol	Üretilen Kanıt	Saklama Süresi
Kayıt	Rıza kaydı + VC çıkarımı + makbuz	5 yıl
Depo kabul	Attestation + kalibrasyon kaydı	7 yıl
Lab raporu	İmzalı rapor + revizyon zinciri	7 yıl
Dispute	Pause olayı + karar gerekçesi	10 yıl
Olay müdahalesi	Incident raporu + telafi kaydı	10 yıl

L16. Süreç olgunluğu protokolü: Faz-2’ye geçiş kararı verilse dahi, pilot prosedürleri bir kez daha gözden geçirilir ve ‘olgunluk matrisi’ ile değerlendirilir. Olgunluk matrisi; süreç disiplini, kanıt üretimi, eğitim kapsaması, şikâyet yönetimi ve üçüncü taraf denetimini birlikte puanlar.

L17. Sürüm yönetişimi protokolü: Fıkhî profil sürümü ile akit şablonu sürümü ‘atomic upgrade’ kuralına bağlıdır. Parametre değişikliği tek başına üretime çıkamaz; mutlaka ilgili akit şablonu, veri şeması ve test çıktılarıyla birlikte yayımlanır. Her sürüm; diff kaydı + gerekçe (proof-of-deliberation) + geri alma (rollback) koşulları içerir.

L18. Uyumluluk matrisi protokolü: Eski->Yeni geçişlerde hangi alanların geriye dönük uyumlu olduğu, hangilerinin yeni akit gerektirdiği kamuya açık bir matriste gösterilir. Uyuşmazlıklarda hakem, bu matrise referansla karar verir; karar kaydı Audit Pack’e eklenir.

L19. Değişken SLA penceresi protokolü: Bölgesel profil sınıfına göre SLA pencereleri önceden ilan edilir; 48 saat üstü gecikme zorunlu ikinci kalite testi ve yedek oracle tetikler.

L15. İletişim protokolü: Pilot, kriz anlarında sessizlikle değil, kısa ve doğrulanabilir duyurularla yönetilir. Kullanıcıya ‘ne oldu, ne yapıyoruz, sizden ne bekliyoruz’ çerçevesinde mesaj verilir. Duyuruların dili; teknik terimlerden arındırılmış, ölçülü ve güven tesis edici olmalıdır.

Ek-M — Uyumluluk Matrisi ve Rollback Standardı

Bu ek, mezhep profilleri ve akit şablonları arasındaki sürüm bağını formelleştirir. Amaç; sahada ‘gizli standart değişimi’ riskini önlemek ve geriye dönük uyuşmazlıklarda net bir karar çerçevesi sunmaktır.

Ek-M.1 Uyumluluk Matrisi

Değişiklik türü	Geriye dönük uyum	Gereken eylem	Zorunlu kanıt
Fıkhî profil parametresi (nisab, vade, ceza/telafi kuralı)	Kısmi	Yeni akit veya açık rıza; atomic upgrade	Parametre diff + şer’i kurul gerekçesi + test çıktıları
Akit şablonu (selem/istisna vb.)	Hayır	Yeni akit; eski kayıtlar ‘legacy’ etiketlenir	Şablon sürümü + hakem kararı gerekçesi
Veri şeması / ürün sözlüğü	Evet (migrasyon ile)	Şema migrasyonu + doğrulama	Migrasyon logu + örneklem doğrulama raporu
Oracle/denetçi listesi ve SLA eşikleri	Evet	Onboarding/rotasyon; HHI tetikleri	Bağımsızlık beyanı + HHI raporu + atama kayıtları
Dispute API / pause politikası	Kısmi	Prosedür güncelleme + eğitim	Playbook diff + tatbikat raporu

Ek-M.2 Rollback Standardı (Özet)

12. Kritik bulgu: Red team veya bağımsız denetim ‘kritik’ seviyede bulgu üretirse, ilgili sürüm otomatik olarak askıya alınır.
13. İmza kotaları: Rollback için şer’i kurul + teknik kurul + uyum biriminden eşik sayıda imza gerekir (çoklu kontrol).
14. Kamu bildirimi: Rollback gerekçesi, etkilenen alanlar ve düzeltme planı kamu panosunda yayımlanır.
15. Geri dönüş testi: Eski sürüme dönüş sonrası conformance test suite tam koşulur; sonuçlar Audit Pack’e eklenir.

Ek-N — HÜDA BİR Tarihî Arka Plan Notu

16. Bu ek, HÜDA BİR’in isimlendirme gerekçesini ve “cuma camii–pazar” eksenli erken kamusal hayat pratiklerinin pilot tasarımına nasıl çevrildiğini özetler: (i) tarihî idari kimlik (Hüdavendigar), (ii) ticaret mekânı olarak pazar/çarşının kurumsal hafızası, (iii) emanet–ölçü–tartı ilkelerinin yerel örf ile birleşerek denetlenebilir kurallara dönüştürülmesi.

Ek-O — Norm Profil Sözlüğü (Okuyucu Dostu Format)

17. Aşağıdaki alanlar, çok-fıkıhlı motorun havza profillerini tanımlamak için asgari veri sözlüğüdür: Profil Kodu; Baskın Norm (Hanefî/Şafiî/…); Akit Kümesi (satım, selem, icâre, …); Yasak Risk Sınıfları (faiz, garar, riba’l-fadl, …); Örf/İstihsan Alanları; İstisna Protokolü; İspat Standardı (şahitlik/oracle seti); Uyuşmazlık Çözümü; Sürüm Politikası; Mahremiyet Profili.

Ek-P — Kardeş Havza Eşleştirme Protokolü (Özet)

18. Kardeş havzalar arası ilişki üç modda tanımlanır: (1) Aynî Kardeşlik (aynı norm profili → native işlem), (2) Kitabî/Kadim Kardeşlik (yakın norm grubu → sınırlı tercüme), (3) İnsanî Kardeşlik (etik/fıtrî taban → geniş tercüme). Her mod için: (i) uyumluluk matrisi, (ii) asgari kanıt paketi, (iii) fiyat keşfi korumaları, (iv) pause-then-review tetikleri, (v) raporlama ritmi ve kamu özet formatı zorunludur.

Dipnotlar

19. [1] Türkiye Diyanet Vakfı İslâm Ansiklopedisi (TDVİA), “Hüdâvendigâr” maddesi (çevrimiçi): https://islamansiklopedisi.org.tr/hudavendigar (erişim: 2025-12-31).
20. [2] TDVİA, “Pazar” maddesi (çevrimiçi): https://islamansiklopedisi.org.tr/pazar (erişim: 2025-12-31).
21. [3] Bursa Eskişehir Bilecik Kalkınma Ajansı (BEBKA), Bursa’nın kırsalı/dağ ilçeleri ve sosyo‑ekonomik görünümüne ilişkin bölgesel raporlar (kurumsal arşiv): https://bebka.org.tr (erişim: 2025-12-31).
22. [4] Financial Action Task Force (FATF), FATF Recommendations: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html; ayrıca “Guidance for a Risk-Based Approach to Virtual Assets and VASPs” (2021): https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets.html (erişim: 2025-12-31).
23. [5] European Union, Regulation (EU) 2023/1114 (MiCA) (EUR‑Lex): https://eur-lex.europa.eu/eli/reg/2023/1114/oj (erişim: 2025-12-31).
24. [6] Basel Committee on Banking Supervision (BCBS), “Principles for Operational Resilience” (2021): https://www.bis.org/bcbs/publ/d516.htm (erişim: 2025-12-31).
25. [7] National Institute of Standards and Technology (NIST), “Cybersecurity Framework (CSF) 2.0” (resmî sayfa): https://www.nist.gov/cyberframework (erişim: 2025-12-31).
26. [8] Şemsü’l‑Eimme es‑Serahsî, el‑Mebsût, Dârü’l‑Ma‘rife, Beyrut, c. 12 (Kitâbü’s‑Selem).
27. [9] USPUM, “Fintek Fıkhı‑1: Blokzincir Teknolojisi ve İslam İktisadı Ekseninde Yeni Bir Epistemolojik Teklif ve Güven Mimarisi” (çevrimiçi): https://www.uspum.org.tr/fintek-fikhi-1-blokzincir-teknolojisi-ve-islam-iktisadi-ekseninde-yeni-bir-epistemolojik-teklif-ve-guven-mimarisi/ (erişim: 2025-12-31).
28. [10] USPUM, “Fintek Fıkhı‑2” (çevrimiçi): https://www.uspum.org.tr/fintek-fikhi-2/ (erişim: 2025-12-31).

[11] Hüdavendigar Dağ Köyleri Birliği (HÜDA BİR) Tüzüğü, Madde 1.2 (merkez), 1.4 (dayanak), 1.5 (tanımlar) — kullanıcı arşivi (DOCX). Dayanak mevzuat: Mahallî İdare Birlikleri Kanunu (Kanun No. 5355).

Kaynakça

• Basel Committee on Banking Supervision. “Principles for Operational Resilience.” Bank for International Settlements, 2021.
• Financial Action Task Force (FATF). “International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation (FATF Recommendations).”
• Financial Action Task Force (FATF). “Guidance for a Risk‑Based Approach to Virtual Assets and Virtual Asset Service Providers.” 2021.
• National Institute of Standards and Technology (NIST). “Cybersecurity Framework (CSF) 2.0.”
• European Union. Regulation (EU) 2023/1114 on Markets in Crypto‑assets (MiCA).
• Şemsü’l‑Eimme es‑Serahsî. el‑Mebsût. Beyrut: Dârü’l‑Ma‘rife.
• Türkiye Diyanet Vakfı İslâm Ansiklopedisi (TDVİA). “Hüdâvendigâr”, “Pazar”.
• “Fintek Fıkhı‑1 … Güven Mimarisi.”; “Fintek Fıkhı‑2.”
• Bursa Eskişehir Bilecik Kalkınma Ajansı (BEBKA). Bölgesel raporlar ve veri notları (Bursa dağ ilçeleri ve kırsal kalkınma).