SBM ve TRAMER entegrasyonu nedir, nasıl yönetilir?

SBM entegrasyonu, bir sigorta şirketinin poliçe ve hasar verilerini Sigorta Bilgi ve Gözetim Merkezi'ne (SBM) ilgili düzenlemelerin öngördüğü biçimde bildirmesi ve fiyatlama, kabul ve hasar süreçlerinde ihtiyaç duyduğu sektör verisini SBM servisleri üzerinden sorgulaması için kurulan teknik ve operasyonel altyapı demektir. TRAMER entegrasyonu ise bu yapının motor branşına, yani zorunlu trafik sigortası ve kaskoya ilişkin bölümüdür.

Pek çok şirkette SBM entegrasyonu, bir kez kurulup unutulan teknik bir bağlantı gibi görülür. Oysa bu entegrasyon; müşterinin doğru hasarsızlık basamağından fiyat almasını, hasar geçmişinin doğru okunmasını, düzenleyici yükümlülüklerin zamanında yerine getirilmesini ve sektör verisinin doğruluğunu doğrudan etkiler. Bu yazıda SBM ve TRAMER'in rolünü, entegrasyonun kapsamını, sağlam bir mimarinin nasıl kurulacağını ve hata ile mutabakat süreçlerinin nasıl yönetileceğini ele alıyoruz.

SBM ve TRAMER nedir?

Sigorta Bilgi ve Gözetim Merkezi (SBM), Türkiye'de sigorta sektörüne ait poliçe ve hasar verilerinin toplandığı, bu verilerin sektör adına saklandığı ve sigorta şirketlerine, kamu kurumlarına ve sigortalılara çeşitli bilgi hizmetleri sunulduğu kurumdur. Trafik Sigortası Bilgi Merkezi (TRAMER) ise SBM bünyesinde motor branşına ait verilerin yönetildiği birimdir.

SBM'nin yapısı branşlara göre farklı bilgi merkezleri içerir; örneğin sağlık sigortalarına ilişkin veriler Sağlık Sigortası Bilgi Merkezi (SAGMER) kapsamında ele alınır. Motor branşında TRAMER'in önemi özellikle yüksektir: zorunlu trafik sigortasındaki hasarsızlık indirimi ve sürprim basamakları, sektör genelindeki poliçe ve hasar kayıtlarına dayanır. Bir sigortalı şirket değiştirdiğinde, yeni şirketin doğru basamağı belirleyebilmesi, önceki şirketin verisinin TRAMER'e doğru ve zamanında bildirilmiş olmasına bağlıdır.

Bu nedenle SBM entegrasyonu, yalnızca şirketin kendi süreçlerini değil, sektördeki diğer şirketlerin ve sigortalıların işlemlerini de etkileyen ortak bir veri altyapısının parçasıdır.

SBM entegrasyonu hangi işlemleri kapsar?

SBM entegrasyonu iki ana yönde çalışır: şirketten SBM'ye yapılan bildirimler ve şirketin SBM'den yaptığı sorgular. Bildirimler poliçe ve hasar yaşam döngüsünü, sorgular ise fiyatlama, kabul ve hasar kararlarını destekler.

Hangi işlemlerin hangi sürelerde ve hangi alanlarla bildirileceği, SBM'nin yayımladığı teknik dokümanlar ve servis tanımlarıyla belirlenir. Bu tanımlar zaman zaman güncellenir; şirket içinde duyuruları izleyen ve değişikliklerin etkisini analiz eden bir sorumlunun bulunması gerekir.

SBM entegrasyonu neden iş açısından kritik?

SBM entegrasyonu; müşteriye verilen fiyatın doğruluğunu, düzenleyici yükümlülüklerin yerine getirilmesini, hasar kararlarının kalitesini ve sektör verisinin güvenilirliğini aynı anda etkilediği için kritiktir. Buradaki bir hata, çoğu zaman şirketin kendi sisteminde değil, başka bir şirketin teklifinde veya bir müşteri şikâyetinde görünür hâle gelir.

Başlıca iş etkileri şunlardır:

• Fiyat doğruluğu: Sorgu servisinden gelen basamak veya hasar bilgisi yanlış yorumlanırsa, müşteri hak ettiğinden yüksek veya düşük fiyat alır.
• Sigortalı hakları: Bildirilmeyen veya hatalı bildirilen bir iptal ya da hasar kaydı, sigortalının başka bir şirketten alacağı teklifi etkileyebilir.
• Mevzuat uyumu: Bildirimlerin süresinde ve doğru yapılmaması düzenleyici risk doğurur.
• Hasar ve dolandırıcılık kontrolü: Sektör genelindeki hasar geçmişine erişim, şüpheli dosyaların belirlenmesinde önemli bir girdidir. Bu konuyu sigorta dolandırıcılığı tespiti yazımızda ayrıntılı ele aldık.
• Operasyon yükü: Reddedilen bildirimler manuel düzeltme gerektirir; kök nedeni çözülmeyen hatalar birikerek kalıcı bir operasyon maliyetine dönüşür.

Motor branşındaki uçtan uca dijital süreçlerin SBM verisine nasıl dayandığını kasko ve trafik sigortasında dijital süreçler yazımızda bulabilirsiniz.

SBM entegrasyon mimarisi nasıl kurulmalı?

Sağlam bir SBM entegrasyon mimarisi; poliçe ve hasar sistemlerini SBM servislerinin ayrıntılarından yalıtan bir uyarlama katmanı, bildirimler için kuyruk tabanlı ve tekrar denenebilir bir gönderim yapısı ve sorgular için zaman aşımı ile yedek senaryoları tanımlanmış bir çağrı katmanı üzerine kurulur.

Mimari tasarımda şu ilkeler öne çıkar:

• Uyarlama katmanı: SBM servislerinin veri modeli ve protokolü, şirketin kanonik veri modeline burada çevrilir. Servis tanımları değiştiğinde yalnızca bu katman güncellenir; poliçe ve hasar sistemleri etkilenmez.
• Kuyruk tabanlı bildirim: Poliçe ve hasar olayları önce bir kuyruğa yazılır, ardından sırayla gönderilir. Böylece SBM servislerinde geçici bir kesinti poliçe üretimini durdurmaz.
• Sıra ve bağımlılık yönetimi: Bir zeyil, ait olduğu poliçe kabul edilmeden gönderilmemelidir. Aynı poliçeye ait işlemler sırayla işlenmeli, bağımlı kayıtlar önceki kaydın sonucunu beklemelidir.
• Mükerrer gönderim koruması: Aynı işlemin tekrar gönderilmesi durumunda mükerrer kayıt oluşmaması için her bildirimin benzersiz bir referansı ve gönderim durumu tutulmalıdır.
• Kod ve alan eşlemesi: Şirket içi ürün, teminat, araç ve hasar kodlarının SBM kodlarıyla eşlemesi ayrı, yönetilebilir tablolarda tutulmalı; koda gömülmemelidir.
• Sorgu dayanıklılığı: Teklif anında yapılan sorgular için zaman aşımı tanımlanmalı ve servis yanıt vermediğinde ne olacağı iş kuralı olarak belirlenmelidir; örneğin teklifin beklemeye alınması veya yetkili onayına yönlendirilmesi.
• Kimlik bilgisi ve sertifika yönetimi: Erişim bilgileri güvenli bir kasada tutulmalı, sertifika ve parola yenileme tarihleri izlenmelidir.
• Tam kayıt: Gönderilen ve alınan her mesaj, hassas alanlar korunarak ve saklama süreleri gözetilerek, denetim amacıyla kaydedilmelidir.

Bu ilkeler, genel API tasarımında kullandığımız yaklaşımın sektör kurumlarına uyarlanmış hâlidir; ayrıntılar için sigortacılıkta API entegrasyonu yazımıza bakabilirsiniz. Entegrasyonun poliçe tarafındaki tetikleyicileri ise poliçe yönetim sistemi tasarımının doğal bir parçası olmalıdır.

Hata yönetimi ve mutabakat nasıl yapılır?

Hata yönetimi, SBM'den dönen her red ve teknik hatanın sınıflandırılıp doğru ekibe yönlendirilmesi; mutabakat ise şirket kayıtları ile SBM'ye başarıyla iletilen kayıtların düzenli olarak karşılaştırılmasıdır. İkisi birlikte, sessizce kaybolan kayıt kalmamasını sağlar.

Reddedilen bildirimler genellikle üç gruba ayrılır:

• Veri hataları: Eksik zorunlu alan, geçersiz kod, hatalı format. Kök neden çoğunlukla kaynak sistemdeki doğrulama eksikliğidir ve kalıcı çözüm oraya konmalıdır.
• İş kuralı hataları: Tarih çakışması, ait olduğu poliçe bulunamayan zeyil, mükerrer kayıt. Bu hatalar süreç veya sıralama sorununa işaret eder.
• Teknik hatalar: Zaman aşımı, bağlantı hatası, servis kesintisi. Bunlar otomatik tekrar denemeyle çözülmeli, belirli sayıda denemeden sonra alarm üretmelidir.

Operasyon ekibi için reddedilen kayıtları hata tipine, yaşına ve etkilediği poliçeye göre listeleyen, düzeltme ve yeniden gönderim yapılabilen bir iş ekranı gerekir. Hata kayıtlarının bekleme süresi izlenmeli, belirli bir süreyi aşanlar üst yönetime raporlanmalıdır.

Mutabakat tarafında her gün, bir önceki güne ait poliçe ve hasar işlemleri ile SBM'ye başarıyla iletilen kayıtlar karşılaştırılmalıdır. Hiç gönderilmemiş, gönderilmiş ama sonucu alınamamış veya reddedilmiş kayıtlar ayrı ayrı raporlanmalıdır. Hasar tarafındaki bildirimlerin hasar dosyasının yaşam döngüsüyle nasıl eşleşeceğini hasar yönetim sistemi yazımızda anlattık.

SBM entegrasyonu adım adım nasıl yönetilir?

SBM entegrasyonu; kapsam analizinden başlayıp test ortamında doğrulama, kontrollü canlıya geçiş ve sürekli izleme ile yönetilir. Yeni bir ürün, yeni bir poliçe sistemi veya SBM tarafındaki bir servis değişikliği için aynı adımlar uygulanabilir.

1. Ürün ve işlem bazında hangi bildirim ve sorguların gerektiğini SBM teknik dokümanları üzerinden çıkarın.
2. Şirket içi kodlar ile SBM kodları arasındaki eşleme tablolarını hazırlayın ve iş birimleriyle doğrulayın.
3. Uyarlama katmanını, kuyruk yapısını ve sorgu servislerini geliştirin.
4. SBM test ortamında yeni poliçe, zeyil, iptal, yenileme ve hasar senaryolarını uçtan uca çalıştırın.
5. Hatalı veriyle red senaryolarını test edin; operasyon ekranının ve alarmların doğru çalıştığını doğrulayın.
6. Mutabakat raporunu kurun ve test ortamındaki sonuçlarla karşılaştırın.
7. Kontrollü canlıya geçin; ilk günlerde tüm bildirimleri ve redleri yakından izleyin.
8. Hata tiplerini düzenli olarak analiz edin ve kök nedenleri kaynak sistemde kalıcı olarak çözün.

ProdayTech olarak SBM entegrasyonu içeren projelerde, mutabakat raporunu canlıya geçişten önce hazır olması gereken bir teslimat olarak ele alıyoruz; kayıp kayıtları erken fark etmenin en güvenilir yolu budur.

SBM entegrasyonu için kontrol listesi

• Ürün ve işlem bazında bildirim ve sorgu kapsamı belgelendi.
• Kod eşleme tabloları ayrı ve yönetilebilir biçimde tutuluyor.
• Bildirimler kuyruk üzerinden, sıra ve bağımlılık kurallarına uyularak gönderiliyor.
• Mükerrer gönderime karşı benzersiz referans ve durum takibi var.
• Teklif anındaki sorgular için zaman aşımı ve yedek iş kuralı tanımlı.
• Redler veri, iş kuralı ve teknik hata olarak sınıflandırılıyor.
• Operasyon ekibinin düzeltme ve yeniden gönderim ekranı çalışıyor.
• Günlük mutabakat raporu üretiliyor ve bir sorumlu tarafından inceleniyor.
• SBM duyuruları ve servis değişiklikleri düzenli olarak izleniyor.
• Erişim bilgileri ve sertifikalar güvenli biçimde saklanıyor, yenileme tarihleri takip ediliyor.