Kullanıma dayalı sigorta (UBI) ve telematik nedir, nasıl çalışır?

Kullanıma dayalı sigorta (Usage-Based Insurance, UBI), primin aracın ne kadar, ne zaman ve nasıl kullanıldığına dair ölçülen verilere göre belirlendiği sigorta modelidir. Bu verileri toplayan teknolojinin genel adı telematiktir: araçtaki bir cihaz, sürücünün akıllı telefonundaki uygulama ya da doğrudan araç üreticisinin bağlantılı araç altyapısı; konum, hız, ivme ve yolculuk bilgilerini sigortacının işleyebileceği bir veri akışına dönüştürür.

Klasik motor sigortası fiyatlaması; yaş, araç tipi, bölge ve hasar geçmişi gibi dolaylı göstergelere dayanır. UBI ise bu göstergelerin yanına doğrudan gözlenen kullanım verisini ekler. Türkiye'de bu yaklaşım ağırlıklı olarak kasko ve filo sigortalarında gündeme gelir; zorunlu trafik sigortasında fiyat çerçevesi düzenleyici tarafından belirlendiği için kullanım verisine dayalı fiyat esnekliği sınırlıdır. Bu yazıda UBI modellerini, veri kaynaklarını, sürüş skorunun fiyata nasıl yansıdığını, yazılım mimarisini ve Kişisel Verilerin Korunması Kanunu (KVKK) boyutunu ele alıyoruz.

Kullanıma dayalı sigorta hangi modellerden oluşur?

Kullanıma dayalı sigorta iki temel modele ayrılır: kullandığın kadar öde (Pay As You Drive, PAYD) ve nasıl kullanıyorsan öyle öde (Pay How You Drive, PHYD). Uygulamada bu iki model sıklıkla birleştirilir ve ürün, hem kilometre hem de sürüş davranışı üzerinden fiyatlanır.

PAYD modelinde operasyonel karmaşıklık görece düşüktür; esas ihtiyaç güvenilir bir kilometre ölçümüdür. PHYD modelinde ise sürüş olaylarını tespit eden, bunları skorlayan ve skoru hasar olasılığıyla ilişkilendiren bir analitik altyapı gerekir. Filo sigortalarında telematik verisi çoğu zaman zaten filo yönetimi amacıyla toplanmaktadır; bu da sigortacı için veri erişimini kolaylaştırabilir.

Telematik veri nasıl toplanır?

Telematik veri; araca takılan cihazlar, akıllı telefon uygulamaları veya araç üreticisinin bağlantılı araç platformları üzerinden toplanır. Her kaynağın maliyeti, veri kalitesi ve müşteri deneyimi farklıdır.

• OBD cihazı: Aracın arıza teşhis portuna (On-Board Diagnostics, OBD) takılan cihazlar kurulumu kolay, veri kalitesi görece tutarlı kaynaklardır. Donanım ve lojistik maliyeti ile cihazın çıkarılabilmesi dezavantajlarıdır.
• Sabit kara kutu: Araca kalıcı olarak monte edilen cihazlar en tutarlı veriyi sağlar ve çarpışma tespiti gibi olaylarda güvenilirdir; kurulum maliyeti ve süreci daha ağırdır.
• Akıllı telefon uygulaması: Donanım maliyeti yoktur ve müşteriyle doğrudan iletişim kanalı sağlar. Buna karşın sürücü ile yolcuyu ayırt etmek, pil tüketimini yönetmek ve telefon sensörlerindeki farklılıkları dengelemek gerekir.
• Bağlantılı araç verisi: Araç üreticisinin platformundan müşteri izniyle alınan veri, donanım gerektirmez. Erişim, üreticiyle yapılacak anlaşmalara ve veri formatlarının standartlaşma düzeyine bağlıdır.

Kaynak seçimi, ürün stratejisini doğrudan etkiler. Pilot aşamada mobil uygulama ile başlayıp filo veya yüksek değerli araç segmentinde cihaz tabanlı çözüme geçmek sık görülen bir yaklaşımdır.

Sürüş skoru nasıl hesaplanır ve fiyata nasıl yansır?

Sürüş skoru, telematik verisinden tespit edilen sürüş olaylarının ağırlıklandırılarak tek bir risk göstergesine dönüştürülmesiyle hesaplanır. Skorun fiyata yansıması ise tarifede tanımlanmış bir indirim ya da katsayı yapısı üzerinden gerçekleşir.

Skorlamada kullanılan tipik değişkenler şunlardır: hız sınırı aşımı ve aşımın süresi, sert fren ve ani hızlanma sayısı, sert viraj alma, gece sürüşü oranı, yolculuk başına ve toplam mesafe, yol tipi (şehir içi, şehirlerarası) ve sürüş sırasında telefon kullanımı. Hız sınırı aşımını ölçmek için konum verisinin yol ağıyla eşleştirilmesi (map matching) ve yol bazında hız sınırı verisine erişim gerekir.

İlk aşamada skor genellikle uzman görüşüyle ağırlıklandırılmış kural tabanlı bir model olarak kurulur. Yeterli poliçe ve hasar verisi biriktikçe aktüerya ekibi, skor bileşenlerinin hasar frekansı ve şiddetiyle ilişkisini istatistiksel modellerle doğrular ve ağırlıkları yeniden ayarlar. Bu doğrulama yapılmadan skorun doğrudan fiyata bağlanması, ürünü teknik olarak savunulamaz hâle getirebilir.

Skorun fiyata yansıması için yaygın yöntemler şunlardır:

• Başlangıçta sabit bir katılım indirimi, belirli bir ölçüm döneminden sonra skora göre güncellenen fiyat.
• Poliçe süresi boyunca biriken skora göre yenilemede uygulanan indirim veya sürprim.
• Aylık ya da dönemsel faturalamada kilometre ve skora göre değişen prim.

Hangi yöntemin seçileceği, tarife yapısı ve mevzuat çerçevesiyle birlikte değerlendirilmelidir. Skorun tarifeye bir risk faktörü olarak nasıl ekleneceğini sigorta tarife kurgusu yazımızda, hesaplamanın teknik tarafını ise fiyatlama motoru yazımızda ayrıntılı anlattık.

UBI için yazılım mimarisi nasıl kurulur?

UBI yazılım mimarisi; cihaz veya uygulamadan gelen yüksek hacimli veriyi alan, işleyen, yolculuklara ve olaylara dönüştüren, skorlayan ve sonucu poliçe ile fiyatlama sistemlerine aktaran katmanlardan oluşur. Poliçe yönetim sistemi bu verinin ham hâliyle değil, yalnızca özetlenmiş skor ve kilometre bilgisiyle çalışmalıdır.

Tipik mimari katmanlar şunlardır:

• Veri toplama: Cihaz yazılımı veya mobil SDK, yolculuk başlangıç ve bitişini tespit eder, bağlantı yokken veriyi tamponlar ve toplu gönderir.
• Veri alımı: Cihaz kimlik doğrulaması yapılan, MQTT veya HTTPS gibi protokollerle yüksek hacimli mesajları karşılayan bir alım katmanı.
• Akış işleme: Konum gürültüsünün filtrelenmesi, yol eşleştirme, sürüş olaylarının tespiti ve yolculukların oluşturulması.
• Skor servisi: Yolculuk ve dönem bazında skor hesaplayan, model sürümlerini yöneten ve skor geçmişini saklayan servis.
• Poliçe ve fiyatlama entegrasyonu: Skor ve kilometre bilgisinin dönemsel olarak poliçe sistemine ve fiyatlama motoruna aktarılması.
• Müşteri deneyimi: Sürücüye yolculuk özetleri, skor değişimi ve iyileştirme önerileri sunan uygulama ekranları.
• Hasar entegrasyonu: Müşteri izniyle çarpışma tespiti ve hasar ihbarının hızlandırılması; hasar anı verisinin eksper ve hasar ekibiyle paylaşımı.

Ham telematik verisi ile poliçe verisinin ayrı tutulması hem ölçeklenebilirlik hem de veri minimizasyonu açısından doğru bir tercihtir. Hasar anı verisi, kasko ve trafik sigortasındaki dijital süreçler ile birlikte ele alındığında hasar ihbar sürecini belirgin biçimde hızlandırabilir.

KVKK ve veri güvenliği açısından nelere dikkat edilmeli?

Telematik verisi, özellikle konum ve hareket bilgisi, kimliği belirli veya belirlenebilir bir kişiye ait olduğu için KVKK kapsamında kişisel veridir. Bu nedenle veri işlemenin hukuki dayanağı, aydınlatma metni, saklama süresi ve güvenlik önlemleri ürün tasarımının başında netleştirilmelidir.

Dikkat edilmesi gereken başlıca konular şunlardır:

• Hangi verinin hangi amaçla işleneceği aydınlatma metninde açıkça belirtilmeli; fiyatlama, hasar ve pazarlama amaçları birbirinden ayrılmalıdır.
• İşlemenin hukuki dayanağı amaç bazında belirlenmeli; açık rızaya dayanılan durumlarda rızanın özgür iradeyle verildiği ve geri alınabildiği süreçler kurulmalıdır.
• Fiyatlama için gerekmeyen ayrıntıda konum verisi tutulmamalı; mümkün olan yerlerde özetlenmiş veya takma adlandırılmış veri kullanılmalıdır.
• Aracı sigortalı dışında kişiler de kullanıyorsa bu kişilerin bilgilendirilmesi konusu ürün şartlarında ele alınmalıdır.
• Veri bulutta veya yurt dışındaki bir sağlayıcıda işlenecekse, yurt dışına aktarım kuralları ayrıca değerlendirilmelidir.
• Saklama ve imha süreleri tanımlanmalı, ham verinin skor hesaplandıktan sonra ne kadar tutulacağı kararlaştırılmalıdır.

Bu başlıkların yazılım gereksinimlerine nasıl dönüştürüleceğini KVKK uyumlu sigorta yazılımı yazımızda ayrıntılı ele aldık.

UBI ürünü adım adım nasıl başlatılır?

UBI ürünü, küçük ölçekli bir pilotla veri kalitesini ve müşteri kabulünü doğrulayarak, ardından skoru hasar verisiyle kalibre ederek başlatılmalıdır. Doğrudan geniş ölçekli bir lansman, doğrulanmamış bir skorla fiyatlama riski taşır.

1. Hedef segmenti ve modeli (PAYD, PHYD veya hibrit) belirleyin.
2. Veri kaynağını seçin ve cihaz ya da uygulama sağlayıcısıyla veri formatı, erişim ve güvenlik koşullarını netleştirin.
3. KVKK değerlendirmesini yapın; aydınlatma ve gerekiyorsa açık rıza metinlerini hazırlayın.
4. Kural tabanlı ilk skor modelini ve skorun fiyata yansıma yöntemini aktüerya ile birlikte tasarlayın.
5. Veri alımı, akış işleme ve skor servisini kurun; poliçe ve fiyatlama entegrasyonunu tamamlayın.
6. Sınırlı sayıda müşteriyle pilot başlatın; veri kalitesini, pil ve bağlantı sorunlarını ve müşteri geri bildirimini izleyin.
7. Biriken hasar verisiyle skor ağırlıklarını doğrulayın ve gerekirse tarifeyi güncelleyin.
8. Ürünü kademeli olarak ölçeklendirin; müşteri iletişimini ve sürüş geri bildirimlerini güçlendirin.

ProdayTech olarak telematik tabanlı ürün çalışmalarında, skor modelinin ve fiyat katsayılarının poliçe sisteminden bağımsız sürümlenebilmesini önemli bir tasarım ilkesi olarak görüyoruz; böylece model güncellemeleri poliçe sistemini yeniden sürümlemeden yapılabilir.