IFRS 17 nedir, sigorta yazılımlarını nasıl etkiler?

IFRS 17, sigorta sözleşmelerinin muhasebeleştirilmesini, ölçülmesini ve finansal tablolarda sunulmasını düzenleyen uluslararası finansal raporlama standardıdır. Uluslararası Muhasebe Standartları Kurulu (International Accounting Standards Board, IASB) tarafından yayımlanan standart, uzun yıllar farklı yerel uygulamalara izin veren IFRS 4'ün yerini almış ve uluslararası alanda 1 Ocak 2023 ve sonrasında başlayan hesap dönemlerinde yürürlüğe girmiştir. Türkiye'de standart, Kamu Gözetimi, Muhasebe ve Denetim Standartları Kurumu (KGK) tarafından TFRS 17 Sigorta Sözleşmeleri adıyla yayımlanmıştır; sigorta ve reasürans şirketleri için uygulama takvimi ise KGK ile Sigortacılık ve Özel Emeklilik Düzenleme ve Denetleme Kurumu (SEDDK) kararlarıyla belirlenmektedir.

Standardın etkisi muhasebe departmanıyla sınırlı kalmaz. IFRS 17, primin yazıldığı anda kâr tanıma alışkanlığını bırakıp kârı sigorta hizmetinin sunulduğu süreye yayan bir model getirir. Bu model; poliçe, hasar, reasürans, tahsilat ve aktüerya sistemlerinden sözleşme düzeyinde, geçmişe dönük izlenebilir veri ister. Bu yüzden IFRS 17 projeleri çoğu şirkette bir raporlama projesinden çok bir veri ve sistem mimarisi projesine dönüşür.

IFRS 17 neyi değiştiriyor?

IFRS 17, sigorta sözleşmelerinden beklenen kârın sözleşme başında değil, teminat süresi boyunca hizmet sunuldukça tanınmasını zorunlu kılar. Bunun için her sözleşme grubunun gelecekteki nakit akışları güncel varsayımlarla tahmin edilir, iskonto edilir ve belirsizlik için ayrı bir karşılık ayrılır.

Standardın temel yapı taşları şunlardır:

• İfa nakit akışları (fulfilment cash flows): Sözleşmeden beklenen prim, hasar, gider ve komisyon gibi gelecekteki nakit akışlarının iskonto edilmiş bugünkü değeri.
• Finansal olmayan risk için risk düzeltmesi (risk adjustment): Nakit akışlarının tutarı ve zamanlamasındaki belirsizliği taşımak için şirketin talep ettiği karşılık.
• Sözleşmeye dayalı hizmet marjı (Contractual Service Margin, CSM): Henüz kazanılmamış beklenen kâr. Hizmet sunuldukça teminat birimlerine (coverage units) göre gelire aktarılır.
• Zarar bileşeni (loss component): Başlangıçta zararlı (onerous) olan sözleşme gruplarında beklenen zararın beklemeden gider yazılması.

Gelir tablosu tarafında da köklü bir değişim vardır. Yazılan prim artık gelir satırında doğrudan görünmez; bunun yerine sigorta hizmet geliri, sigorta hizmet giderleri ve sigorta finansman gelir ve giderleri ayrı ayrı raporlanır. Sözleşmedeki yatırım bileşenleri (investment components) gelirden ayrıştırılır. Bu sunum değişikliği, muhasebe hesap planından yönetim raporlarına kadar pek çok çıktının yeniden tasarlanmasını gerektirir.

Hangi ölçüm modelleri var ve yazılımı nasıl etkiler?

IFRS 17 üç ölçüm yaklaşımı tanımlar ve her biri farklı veri ve hesaplama ihtiyacı doğurur. Ürün portföyünüzün hangi modele düştüğü, kurmanız gereken hesaplama motorunun karmaşıklığını belirler.

Türkiye'de elementer portföyün büyük kısmı yıllık sözleşmelerden oluştuğu için PAA doğal aday gibi görünse de uygunluk değerlendirmesi yapılmadan varsayılmamalıdır. Çok yıllı mühendislik veya inşaat poliçeleri gibi istisnalar GMM gerektirebilir. PAA kullanılsa bile gerçekleşmiş hasarlar için yükümlülük (Liability for Incurred Claims, LIC) tarafında nakit akışı tahmini ve risk düzeltmesi hesaplanır; hasarların bir yıldan uzun sürede ödenmesi bekleniyorsa iskonto da uygulanır.

IFRS 17 için hangi veriler gerekir?

IFRS 17 hesaplamaları, sözleşmelerin doğru gruplanmasına ve her grup için güvenilir tarihsel verinin varlığına dayanır. Veri eksikse en gelişmiş hesaplama motoru bile denetimden geçemeyecek sonuçlar üretir.

Gruplama: portföy, kohort ve kârlılık

Standart sözleşmeleri üç katmanda gruplar: benzer riskleri taşıyan ve birlikte yönetilen sözleşmelerden oluşan portföyler; aynı portföy içinde en fazla bir yıl arayla düzenlenen sözleşmelerden oluşan yıllık kohortlar; başlangıçta zararlı olanlar, sonradan zararlı hâle gelme olasılığı önemli olmayanlar ve kalanlar şeklinde ayrılan kârlılık grupları. Gruplama ilk tanıma anında yapılır ve sonradan değiştirilmez. Yazılım açısından bu, her poliçenin grup kimliğinin kalıcı bir alan olarak saklanması ve grubun oluştuğu andaki varsayımların, örneğin kilitlenmiş iskonto oranının, sürümlü tutulması demektir.

Kaynak sistemlerden beklenen veri

• Poliçe sisteminden sözleşme başlangıç ve bitiş tarihleri, zeyilname geçmişi, teminat yapısı, prim vadeleri ve iptal bilgileri
• Hasar sisteminden ihbar, muallak, ödeme ve rücu hareketleri; hasar tarihi ile ihbar tarihinin ayrı tutulması
• Tahsilat sisteminden gerçekleşen prim tahsilatı ve komisyon ödemeleri
• Reasürans sisteminden elde tutulan reasürans sözleşmelerinin ayrı gruplanması ve cesyon hareketleri
• Gider sisteminden sözleşme edinme nakit akışları (acquisition cash flows) ve doğrudan atfedilebilir giderlerin dağıtım anahtarları
• Aktüeryadan iskonto eğrileri, mortalite, iptal ve hasar gelişim varsayımları

Bu verinin önemli bir kısmı eski core sistemlerde toplu tutarlar hâlinde tutulur. Sözleşme düzeyine inemeyen veri, IFRS 17 projelerinde en sık karşılaşılan darboğazdır ve çoğu zaman core sistem modernizasyonu gündemini de beraberinde getirir.

IFRS 17 uyumlu yazılım mimarisi nasıl kurulur?

Sağlıklı bir IFRS 17 mimarisi, kaynak sistemleri, hesaplama motorunu ve muhasebe kaydını birbirinden ayıran katmanlı bir yapıdır. Bu ayrım, bir varsayım değiştiğinde yalnızca ilgili katmanın yeniden çalıştırılmasını ve her rakamın kaynağına kadar izlenmesini sağlar.

1. Veri alım katmanı: Poliçe, hasar, tahsilat ve reasürans sistemlerinden periyodik ya da olay tabanlı veri alınır. Kayıt sayısı, toplam prim ve toplam muallak gibi kontrol toplamlarıyla kaynak sistemle mutabakat yapılır.
2. IFRS 17 veri ambarı: Veri, sözleşme ve grup düzeyinde standart bir modele dönüştürülür. Portföy, kohort ve kârlılık grubu ataması burada yapılır ve kalıcı olarak saklanır.
3. Aktüeryal hesaplama motoru: Nakit akışı projeksiyonları, iskonto ve risk düzeltmesi hesaplanır. Varsayım setleri sürümlü tutulur; hangi dönemin hangi varsayımla hesaplandığı sorusu her zaman cevaplanabilir olmalıdır.
4. CSM ve alt defter (subledger) motoru: CSM açılışı, faiz birikimi, varsayım değişikliği etkisi, gelire aktarım ve kapanış hareketleri üretilir. Zarar bileşeni ve elde tutulan reasürans tarafındaki telafi mekanizmaları burada yönetilir.
5. Muhasebe entegrasyonu: Alt defter hareketleri, hesap planı eşleştirme kurallarıyla genel muhasebeye (General Ledger, GL) aktarılır. Yerel mevzuat defteri ile IFRS 17 defteri paralel tutuluyorsa iki defter arasında otomatik mutabakat raporu üretilir.
6. Raporlama ve dipnot katmanı: Hareket tabloları (roll-forward), ölçüm bileşenleri mutabakatı ve dipnotlar bu katmandan beslenir.

Bu yapıdaki en kritik tasarım kararı, hesaplama motorunun hazır bir aktüeryal yazılım mı yoksa şirket içinde geliştirilmiş bir çözüm mü olacağıdır. Karar, hazır paket mi özel yazılım mı sorusundaki ölçütlere benzer biçimde verilmelidir: ürün çeşitliliği, aktüerya ekibinin model üzerindeki kontrol ihtiyacı ve denetçinin izlenebilirlik beklentisi belirleyicidir.

Poliçe ve hasar sistemlerinde neler değişmeli?

IFRS 17, operasyonel sistemlerde yeni alanlar, daha sıkı tarih disiplini ve geriye dönük düzeltmelerin izlenebilirliğini gerektirir. Hesaplama katmanı ne kadar iyi olursa olsun, bu değişiklikler yapılmadan sonuçlar tutarlı olmaz.

• Tarih alanları: Teminat başlangıcı, ilk primin vadesi ve grubun zararlı hâle geldiği tarih farklı olabilir. Standart ilk tanıma için bu tarihlerden en erken olanı esas aldığından hepsi ayrı saklanmalıdır.
• Zeyilname yönetimi: Bir sözleşme değişikliğinin mevcut sözleşmenin devamı mı, yeni bir sözleşme mi sayılacağı muhasebe sonucunu değiştirir. Zeyil tipleri IFRS 17 açısından sınıflandırılmalıdır.
• Hasar verisi: Gerçekleşmiş ancak rapor edilmemiş hasarlar (Incurred But Not Reported, IBNR) ve muallak hasarlar için ödeme örüntüsü, hasar tarihi bazında üretilebilmelidir.
• Gider dağıtımı: Doğrudan atfedilebilir giderler ürün ve portföy bazında dağıtılabilecek biçimde etiketlenmelidir.
• Reasürans: Elde tutulan reasürans sözleşmeleri doğrudan sözleşmelerden ayrı gruplanır ve kendi CSM'lerine sahiptir. Cesyon verisinin poliçe düzeyinde kurulabilmesi gerekir.

Bu değişiklikler poliçe yönetim sistemi ve hasar sistemi yol haritalarına ayrı iş kalemleri olarak yazılmalıdır. Yalnızca muhasebe projesinin bir alt başlığı olarak bırakıldıklarında sıkça ertelenir ve dönem sonlarında elle düzeltme kayıtlarına dönüşürler.

Geçiş dönemi ve paralel çalışma nasıl yönetilir?

IFRS 17'ye geçişte her grup için açılış CSM'sinin belirlenmesi gerekir ve bu, geçmiş verinin kalitesine göre seçilen geçiş yöntemine bağlıdır. Standart üç yöntem tanır: tam geriye dönük yaklaşım, değiştirilmiş geriye dönük yaklaşım ve gerçeğe uygun değer yaklaşımı.

Tam geriye dönük yaklaşım, sözleşmelerin baştan beri IFRS 17 uygulanıyormuş gibi hesaplanmasını ister ve uzun vadeli portföylerde çoğu zaman eksik veri nedeniyle uygulanamaz. Bu durumda diğer iki yöntem devreye girer. Yazılım açısından geçiş; tarihsel veri arşivlerinin açılması, eksik alanların kural bazlı tamamlanması ve bu tamamlama kurallarının belgelenmesi demektir. Eski sistemlerden taşınan verinin kontrollü aktarımı için sigorta veri migrasyonu disiplininin burada da uygulanması önerilir.

Paralel çalışma dönemi, yeni motorun birkaç kapanış dönemi boyunca mevcut raporlamayla yan yana çalıştırılmasıdır. Bu dönemde farkların açıklanabilir olması, rakamların birebir tutmasından daha önemlidir; çünkü denetçi her farkın nedenini soracaktır. Kapanış takvimine hesaplama süresinin, yeniden çalıştırma ihtimalinin ve onay adımlarının gerçekçi biçimde yerleştirilmesi de bu dönemde test edilmelidir.

IFRS 17 hazırlığı için kontrol listesi

Aşağıdaki liste, bir sigorta şirketinin IFRS 17 hazırlığını teknik açıdan değerlendirmesi için kullanılabilir:

• Her ürün için ölçüm modeli (GMM, PAA, VFA) ve PAA uygunluk değerlendirmesi belgelendi mi?
• Portföy, kohort ve kârlılık grubu ataması sistemde kalıcı bir alan olarak saklanıyor mu?
• Poliçe, hasar, tahsilat ve reasürans verisi sözleşme düzeyinde alınabiliyor mu?
• Varsayım setleri (iskonto eğrisi, risk düzeltmesi yöntemi, teminat birimleri) sürümlü ve onay akışına bağlı mı?
• Her hesaplama sonucu kaynak kayda kadar izlenebiliyor mu (veri soy ağacı, data lineage)?
• Alt defter ile genel muhasebe arasında otomatik mutabakat var mı?
• Yerel mevzuat raporlaması ile IFRS 17 raporlaması aynı veri kaynağından mı besleniyor?
• Kapanış takvimi, hesaplama süresi ve yeniden çalıştırma senaryoları test edildi mi?
• Kullanıcı yetkileri ve parametre değişiklik kayıtları iç kontrol beklentileriyle uyumlu mu?

ProdayTech olarak sigorta projelerinde IFRS 17 gereksinimlerini ayrı bir muhasebe modülü olarak değil, poliçe ve hasar veri modelinin baştan tasarlanması gereken bir parçası olarak ele alıyoruz. Mevcut sistemlerinizin bu listeye göre nerede durduğunu birlikte değerlendirmek için iletişim bölümünden bize ulaşabilirsiniz.