Parametrik sigorta nedir, yazılım altyapısı nasıl kurulur?

Parametrik sigorta, tazminatın gerçekleşen zararın ekspertizle ölçülmesine göre değil, önceden tanımlanmış ve bağımsız bir kaynaktan ölçülen bir parametrenin belirlenen eşiği aşmasına göre ödendiği sigorta modelidir. Deprem büyüklüğü veya yer ivmesi, belirli bir istasyonda ölçülen yağış miktarı, sıcaklık, rüzgâr hızı ya da bir uçuşun gecikme süresi bu parametrelere örnektir. Olay gerçekleştiğinde ve parametre eşiği aştığında ödeme, poliçede önceden belirlenen formüle göre yapılır.

Bu yapı, hasar sürecini ekspertiz ve belge toplama yükünden büyük ölçüde kurtarır ve ödeme süresini kısaltır. Karşılığında yeni bir risk türü ortaya çıkar: ödenen tutar ile sigortalının gerçek zararı arasındaki fark, yani baz riski. Parametrik bir ürünün başarısı; doğru parametrenin seçilmesine, güvenilir veri kaynağına ve olay anında otomatik çalışabilen bir yazılım altyapısına bağlıdır. Bu yazıda kavramı, kullanım alanlarını, tetikleyici tasarımını ve yazılım mimarisini ele alıyoruz.

Parametrik sigorta ile klasik tazminat sigortası arasındaki fark nedir?

Temel fark, ödemenin neye dayandığıdır: klasik sigortada ödeme ekspertizle belirlenen gerçek zarara, parametrik sigortada ise ölçülen bir endeksin önceden tanımlanmış eşiği aşmasına dayanır. Bu fark; hasar sürecini, ödeme hızını, ürün tasarımını ve yazılım ihtiyaçlarını baştan sona değiştirir.

Parametrik yapı, klasik sigortanın yerini almaktan çok onu tamamlayan bir araç olarak konumlanır. Örneğin tazminat esaslı bir konut veya işyeri poliçesinin yanında, afet sonrası ilk günlerdeki nakit ihtiyacını karşılamak üzere parametrik bir teminat sunulabilir.

Parametrik sigorta hangi alanlarda kullanılır?

Parametrik sigorta; olayın objektif ve bağımsız biçimde ölçülebildiği, klasik ekspertizin yavaş veya pahalı olduğu risklerde kullanılır. Doğal afetler, hava koşullarına bağlı gelir kaybı ve seyahat aksaklıkları en bilinen örneklerdir.

• Deprem ve doğal afet: Belirli bir bölgede ölçülen deprem büyüklüğü veya yer hareketi şiddetine bağlı ödeme. Türkiye'nin deprem riski düşünüldüğünde, afet sonrası hızlı likidite sağlama amacıyla ilgi gören bir alandır.
• Tarım ve hava durumu: Kuraklık, aşırı yağış, don veya sıcaklık gibi meteorolojik göstergelere bağlı ödeme.
• Turizm ve etkinlik: Sezon boyunca yağışlı gün sayısı veya belirli tarihlerdeki hava koşulları nedeniyle oluşan gelir kaybına karşı koruma.
• Seyahat: Uçuş gecikmesi veya iptalinde, uçuş veri kaynağından doğrulanan süreye göre otomatik ödeme.
• Enerji: Güneş ışınımı veya rüzgâr hızının beklenen seviyenin altında kalmasıyla oluşan üretim kaybına karşı koruma.

Türkiye'de ölçüm verisi için akla gelen kaynaklar arasında Afet ve Acil Durum Yönetimi Başkanlığı (AFAD), Boğaziçi Üniversitesi Kandilli Rasathanesi ve Deprem Araştırma Enstitüsü ile Meteoroloji Genel Müdürlüğü (MGM) bulunur. Uçuş ve bazı meteorolojik veriler için ticari veri sağlayıcılar da kullanılabilir. Hangi kaynağın seçileceği; verinin yayımlanma hızına, tarihsel derinliğine, revizyon politikasına ve ticari kullanım koşullarına göre değerlendirilmelidir.

Parametrik ürünler kısa ve basit yapıları nedeniyle bir iş ortağının satış akışına kolayca yerleştirilebilir. Bu nedenle gömülü sigorta (embedded insurance) modelleriyle, örneğin uçuş biletiyle birlikte sunulan gecikme teminatında, sıkça birlikte anılır.

Tetikleyici ve ödeme yapısı nasıl tasarlanır?

Tetikleyici tasarımı; ölçülecek parametrenin, ölçüm noktasının, ölçüm döneminin, eşik değerlerin ve ödeme formülünün birlikte tanımlanmasıdır. Bu tanımlar poliçede hiçbir yoruma yer bırakmayacak açıklıkta yazılmalıdır.

Tasarımda cevaplanması gereken sorular şunlardır:

• Parametre: Zararı en iyi temsil eden ölçülebilir değişken hangisidir? Deprem için büyüklük mü, sigortalı konumdaki tahmini yer ivmesi mi?
• Konum: Parametre nerede ölçülecek? En yakın istasyon, belirli bir yarıçap, bir grid hücresi ya da idari bir bölge mi esas alınacak?
• Dönem: Ölçüm tek bir anda mı, günlük toplamda mı, sezon boyunca kümülatif olarak mı yapılacak?
• Veri kaynağı ve yedeği: Birincil kaynak erişilemez olduğunda hangi kaynak kullanılacak? Veri sonradan revize edilirse hangi değer esas alınacak?
• Ödeme formülü: Tek eşikli (eşik aşıldığında sabit tutar), kademeli (her eşik bandı için farklı oran) veya doğrusal (eşiğin üzerindeki her birim için artan ödeme) yapı mı kullanılacak?
• Limit: Poliçe başına ve olay başına azami ödeme ne olacak?

Kademeli yapı, sigortalı için anlaşılır olması ve baz riskini tek eşikli yapıya göre yumuşatması nedeniyle sık tercih edilir. Formülün teminat, limit ve parametre ilişkisini ürün tanımında nasıl yapılandıracağınızı sigorta ürün modelleme yazımızdaki yaklaşımla ele alabilirsiniz.

Mevzuat boyutu da tasarımın ayrılmaz parçasıdır. Mala ilişkin sigortalarda tazminatın gerçek zararla sınırlı olması ilkesi ile parametrik ödemenin nasıl bağdaştırılacağı, ürünün hangi branş ve sigorta türü altında konumlanacağı ve SEDDK nezdindeki gereklilikler, ürün tasarımının başında hukuk ve aktüerya ekipleriyle birlikte değerlendirilmelidir.

Baz riski nedir ve nasıl yönetilir?

Baz riski, parametrik poliçenin yaptığı ödeme ile sigortalının gerçekte uğradığı zarar arasındaki uyumsuzluktur. Sigortalı zarar gördüğü hâlde parametre eşiği aşmayabilir ya da tersine, zarar olmadığı hâlde ödeme tetiklenebilir.

Baz riski tamamen ortadan kaldırılamaz, ancak şu yöntemlerle azaltılabilir:

• Parametre ile tarihsel zarar verisi arasındaki ilişkinin analiz edilmesi ve zararı en iyi açıklayan göstergenin seçilmesi.
• Ölçüm noktasının sigortalı konuma olabildiğince yakın tanımlanması veya birden fazla istasyonun ağırlıklı ortalamasının kullanılması.
• Tek eşik yerine kademeli ödeme yapısının tercih edilmesi.
• Parametrik teminatın klasik bir tazminat poliçesiyle birlikte sunulması.
• Müşteriye baz riskinin satış öncesinde açık ve anlaşılır biçimde anlatılması.

Son madde özellikle önemlidir. Parametrik ürünlerde şikâyetlerin önemli bir kaynağı, müşterinin zarar gördüğü hâlde ödeme almamasıdır. Bilgilendirme belgeleri, ödemenin zarara değil parametreye bağlı olduğunu örneklerle açıklamalıdır.

Parametrik sigortanın yazılım altyapısı hangi bileşenlerden oluşur?

Parametrik sigorta altyapısı; dış veri kaynaklarından veri alan, veriyi doğrulayan, tetikleyici kurallarını değerlendiren, etkilenen poliçeleri bulan, ödeme tutarını hesaplayan ve ödemeyi onay akışıyla gerçekleştiren katmanlardan oluşur. Bu altyapı, klasik bir hasar yönetim sisteminden farklı olarak olay odaklı ve büyük ölçüde otomatik çalışır.

• Veri alım katmanı: Deprem, meteoroloji veya uçuş verisini API ya da dosya aktarımıyla düzenli aralıklarla çeker; kaynağın yanıt vermemesi durumunda yedek kaynağa geçer.
• Veri doğrulama: Gelen veriyi tutarlılık kurallarıyla kontrol eder, revizyonları izler ve poliçede tanımlı kesinleşme koşulunu uygular.
• Olay ve tetikleyici motoru: Her ürün sürümünün tetikleyici kurallarını olay verisiyle karşılaştırır. Kurallar koda gömülü değil, ürün tanımında parametre olarak tutulmalıdır.
• Coğrafi eşleştirme: Olay alanını poliçelerin konumlarıyla eşleştirir. Adreslerin koordinata doğru dönüştürülmesi bu katmanın kalitesini belirler.
• Ödeme hesaplama ve onay: Formülü uygular, limitleri kontrol eder ve ödeme listesini hasar yetkilisinin onayına sunar. Toplam tutar belirli bir seviyeyi aşarsa ek onay istenebilir.
• Ödeme ve bildirim: Onaylanan ödemeleri banka entegrasyonuyla gerçekleştirir, sigortalıya bildirim gönderir ve muhasebe ile reasürans kayıtlarını oluşturur.
• Denetim izi: Hangi veri değerinin, hangi kural sürümüyle, hangi ödemeyi tetiklediği değiştirilemez biçimde kaydedilir.

Dış veri kaynaklarıyla bağlantının güvenilirliği, altyapının en zayıf halkası olabilir. Bu nedenle bağlantı tasarımında sigortacılıkta API entegrasyonu yazımızda anlattığımız zaman aşımı, tekrar deneme ve izleme ilkeleri uygulanmalıdır. Akıllı sözleşme (smart contract) gibi dağıtık defter teknolojileri de bu alanda tartışılır, ancak parametrik bir ürünün çalışması için zorunlu değildir; iyi tasarlanmış bir kural motoru ve denetim izi aynı şeffaflığı sağlayabilir.

Parametrik ürün adım adım nasıl hayata geçirilir?

Parametrik ürün, veri analiziyle başlayan, tetikleyici tasarımı ve mevzuat değerlendirmesiyle olgunlaşan ve kontrollü bir pilotla canlıya alınan bir süreçle hayata geçirilir.

1. Hedef riski ve müşteri segmentini tanımlayın; parametrik yapının bu riske gerçekten uygun olup olmadığını değerlendirin.
2. Aday parametreleri ve veri kaynaklarını belirleyin; tarihsel veri derinliğini, yayımlanma hızını ve kullanım koşullarını inceleyin.
3. Parametre ile tarihsel zarar arasındaki ilişkiyi analiz ederek baz riskini ölçün.
4. Tetikleyici, ödeme formülü ve limitleri aktüerya ve reasürans ekipleriyle birlikte tasarlayın.
5. Hukuki konumlandırmayı ve SEDDK gerekliliklerini netleştirin; bilgilendirme belgelerini baz riskini açıklayacak biçimde hazırlayın.
6. Veri alımı, tetikleyici motoru, coğrafi eşleştirme ve ödeme katmanlarını kurun.
7. Geçmiş olay verileriyle simülasyon yapın; sistemin geçmişte hangi poliçelere ne kadar ödeme yapacağını doğrulayın.
8. Sınırlı bir bölge veya iş ortağıyla pilot başlatın ve süreçleri canlı olay verisiyle izleyin.

ProdayTech olarak parametrik ürün tasarımlarında, tarihsel olay verisiyle yapılan geriye dönük simülasyonu canlıya geçişin ön koşulu olarak ele alıyoruz; bu test, hem formüldeki hataları hem de veri kaynağındaki boşlukları erken gösterir.