Geliştiriciler için Sigorta Alanı: Ürünler, Aktörler ve Veri Modelleri
Sigorta dünyasına yeni adım atan bir yazılım geliştiriciyseniz muhtemelen aşılmaz bir jargonla karşı karşıya kalacaksınız: sigortacılık, onay, FNOL, halefiyet, kenarlık. Endişelenmeyin: bu kılavuz alan adının tamamını çevirir bir geliştiricinin anlayabileceği kavramlara, veri modellerine ve mimari kalıplara sigorta, uygulamak ve her şeyden önemlisi doğru şekilde modelleyin kodda.
Sigorta sektörü küresel ölçekte ilerlemeye devam ediyor Yıllık 7 trilyon dolar prim (veri 2025, Swiss Re Sigma) ve dünyada en çok düzenlemeye tabi sektörlerden biridir. Yine de çoğu bunu destekleyen bilgi sistemleri 80'li ve 90'lı yıllara dayanmaktadır: COBOL ana bilgisayarları, gecelik gruplar, yeşil ekran arayüzleri. Endüstrinin dijital dönüşümü olarak bilinen Sigorta Teknolojisi, tüm bunları yeniden tasarlıyor ve geliştiriciler değişimin merkezinde yer alıyor.
Bu makale serinin açılışını yapıyor InsurTech Mühendislik tam bir genel bakış ile etki alanının: sigorta ürünleri, değer zinciri oyuncuları, temel veri modelleri, politika ve hak talepleri yaşam döngüsü ve platform oluşturma için modern mimari modeller bulutta yerel sigorta.
Bu Makalede Neler Öğreneceksiniz?
- Sigorta ürünlerinin kategorileri (Hayat, Hayat Dışı, Sağlık, Özel) ve teknik farklılıkları
- Değer zincirindeki oyuncular: poliçe sahibi, sigortacı, komisyoncu, acente, reasürör, düzenleyici
- Sigorta değer zinciri: dağıtım, sigortalama, poliçe yönetimi, talepler, yatırımlar
- Temel veri modelleri: Politika, Talep, Prim, Kapsam, Onay, Rider
- Poliçenin tüm yaşam döngüsü: teklif, ihraç, değişiklik, yenileme, iptal
- Talebin yaşam döngüsü: FNOL, değerlendirme, uzlaşma, kurtarma
- Sigortaya uygulanan Etki Alanı Odaklı Tasarım: sınırlı bağlam ve toplamlar
- Derecelendirme motorunun mimarisi ve primlerin hesaplanması
- Birlikte çalışabilirlik için ACORD standartları ve API modelleri
- Düzenleyici ortam: Solvency II, IFRS 17, GDPR
Sigorta Sektörü: Bir Geliştiricinin Genel Bakışı
Tek bir kod satırı yazmadan önce şunu anlamak önemlidir: iş nasıl çalışıyor sigorta. Ürünün somut olduğu e-ticaretten farklı olarak sigortada "Ürün" bir söz: bir olayın meydana gelmesi üzerine gelecekteki tazminatın ödenmesi belirsiz olay. Bu, veri modelleme açısından alanı doğası gereği karmaşık hale getirir.
"Sigorta, asla kullanmamayı umarak satın aldığınız tek üründür. Bu paradoks onu yöneten sistemlerin tüm mimarisini tanımlar."
Temel Prensip: Riskin Karşılıklılığı
Anahtar kavram, risk karşılıklılığı (risk havuzu): harika bir tane Bir grup insan veya şirket, çekildikleri ortak bir fona düzenli prim katkısında bulunur zarar gören az sayıdaki kişiyi telafi edecek kaynaklar. Sigortacının rolü ve bunu yönetmesi Toplanan primlerin karşılamaya yeterli olmasını sağlayacak şekilde aktüeryal olarak sürdürülebilir bir şekilde fonlama beklenen hasarlar artı işletme maliyetleri ve kar marjı.
Sigorta Ürün Kategorileri
Sigorta ürünleri birbirinden oldukça farklı teknik özelliklere sahip makro kategorilere ayrılmaktadır. Bu farklılıkları anlamak, verilerinizi doğru şekilde modellemek için çok önemlidir.
| Kategori | Örnekler | Tipik Süre | Riskin Niteliği | Veri Karmaşıklığı |
|---|---|---|---|---|
| Hayat (Hayat) | Dönem, Karma, Birim Bağlantılı, Yönetim Kurulu | 10-40 yıl | Ölüm, uzun ömür | Yüksek (aktüeryal tablolar, matematik rezervler) |
| Hasarlar (P&C) | Araba, Ev, Profesyonel RC, Yangın | 1 yıl (yenilenebilir) | Mülkiyet, hukuki sorumluluk | Ortalama (talep sıklığı, ortalama maliyet) |
| Sağlık (Sağlık) | Masrafların, kazaların, LTC'nin geri ödenmesi | 1 yıl / çok yıllı | Morbidite, sakatlık | Yüksek (ICD, DRG, sağlık ağları kodlaması) |
| Uzmanlıklar | Denizcilik, Havacılık, Siber, D&O, E&O | Değişken | Karmaşık/Afet Riskleri | Çok yüksek (CAT modelleri, birikimler) |
Geliştirici için Çıkarımlar
Sigorta için "herkese uyan tek bir veri modeli" yoktur. Bir Yaşam sistemi yönetir matematiksel rezervler ve ölüm tabloları; P&C sistemi muafiyetleri, limitleri ve değerlendirmeler; Sağlık sistemi tıbbi kodları ve sağlayıcı ağlarını yönetir. Mimari seçim arasında birleşik model e LOB için özel modeller (İş Kolu) bir sigorta platformunun tasarlanmasında en kritik kararlardan biridir.
Değer Zincirinin Aktörleri
Sigorta ekosistemi farklı rollere sahip çok sayıda aktörü içerir. Her biri olur veri modelimizde bir varlık ve genellikle mimaride ayrı bir sınırlı bağlam.
Ana Aktörlerin Haritası
| Aktör | Etki Alanındaki Rol | Anahtar Veri Varlığı | Ana etkileşimler |
|---|---|---|---|
| Yüklenici (Poliçe Sahibi) | Poliçeyi satın alın, primleri ödeyin | Müşteri, Hesap, Ödeme Yöntemi | Kota, Bağlama, Prim Ödeme, Talep Dosyası |
| Sigortalı | Politika kapsamındaki kişi/şey | Sigortalı Taraf, RiskObject | Yükleniciden farklı olabilir |
| Sigortacı (Sigortacı / Taşıyıcı) | Riski alır, tazminatları öder | Şirket, Portföy, Rezerv | Hak Taleplerini Sigortalayın, İhraç Edin, Çözümleyin |
| Ajan | Sigortacıyı temsil eder, poliçe satar | Acente, Acenta, Komisyon | Dağıtılmış, Kotalar, Hizmet |
| Komisyoncu | Müşteriyi temsil eder, koşulları müzakere eder | Broker, BrokerFirma, Yerleştirme | Riski Yerleştirin, Şartları Pazarlaştırın |
| Reasürör | Sigortacıyı sigortalar (aşırı riskler) | Antlaşma, Görevlendirme, Kurtarma | Verim, Geri Çekilme, Yerleşme |
| Uzman (Ayarlayıcı) | Talepleri değerlendirir ve tazminatı belirler | Değerlendirme, Tahmin, Rapor | Denetle, Değerlendir, Tavsiye Et |
| Regülatör (Regülatör) | Piyasayı denetler, kurallar koyar | Dosyalama, Uyumluluk, Raporlar | Ürünleri Onayla, Denetle, Bitir |
Kritik İlişki: Yüklenici vs Sigortalı vs Lehdar
En hafife alınan karmaşıklıklardan biri, Sigortalı, sigortalı ve sigortalı ayrımı yararlanıcı. En basit durumda (bireysel araç politikası), üç rakam çakışmaktadır. Ancak kurumsal hayat sigortası poliçesinde müteahhit ve şirket, sigortalı çalışanlar ve faydalanıcılar onlar belirlenmiş aile üyeleridir. Veri modeli Bu esnekliği bu varlıklar arasındaki çoktan çoğa ilişkilerle destekleyin.
Sigorta Değer Zinciri
Sigorta değer zinciri, müşteriyle ilk temastan itibaren tüm iş akışını tanımlar. Talep çözümlenene ve poliçe yenilenene kadar müşteri. Zincirdeki her halka tipik olarak şuna karşılık gelir: sınırlı bağlam yazılım mimarisinde.
Distribution Underwriting Policy Admin Claims Investment
| | | | |
v v v v v
+-----------+ +-----------+ +------------+ +-----------+ +-----------+
| Marketing | | Risk | | Issue | | FNOL | | Asset |
| Lead Gen | | Selection | | Endorse | | Assess | | Mgmt |
| Quoting | | Pricing | | Renew | | Adjust | | ALM |
| Binding | | Approval | | Cancel | | Settle | | Reserves |
+-----------+ +-----------+ +------------+ +-----------+ +-----------+
| | | | |
+-------+-------+--------+-------+------+-------+-------+------+
| | | |
+---------+ +---------+ +---------+ +---------+
|Reinsur. | | Billing | | Fraud | | Report |
|Cessions | | Collect | | Detect | | Regulat.|
+---------+ +---------+ +---------+ +---------+1. Dağıtım
Dağıtım, sigorta ürünlerinin müşteriye ulaştığı tüm kanalları içerir: ajanlar (tek firma veya çok firma), komisyoncu, banka sigortacılığı, çevrimiçi karşılaştırıcılar e doğrudan kanallar (web, uygulama, çağrı merkezi). Geliştirici için, bu, çok kanallı fiyat teklifi API'lerine, entegre CRM'lere ve ürün yapılandırma motorlarına dönüşür.
2. Sigortalama (Risk Üstlenimi)
Sigortalama, sigortacının önerilen riski değerlendirdiği ve kabul edip etmeyeceğine karar verdiği süreçtir. hangi şartlarda ve hangi fiyata. Sigorta işinin teknik kalbidir ve şunları içerir:
- Risk değerlendirmesi: Risk özelliklerinin değerlendirilmesi (yaş, sağlık, konum, hasar geçmişi)
- Değerlendirme: Primin hesaplanması derecelendirme motoru (aktüeryal algoritmalar + iş kuralları)
- Risk Seçimi: Koşulları kabul etme, reddetme veya değiştirme kararı
- Tavsiyeler: Otomatik parametreler dışındaki riskler için kıdemli sigortacıya iletme
3. Politika Yönetimi (Politika Yönetimi)
Il Politika Yönetim Sistemi (PAS) sistemin tamamını yöneten merkezi sistemdir. Poliçenin yaşam döngüsü: konu, değişiklikler (ciro), yenilemeler, iptaller ve işe iade. Genellikle sigorta BT ekosistemindeki en karmaşık sistemdir.
4. Talep Yönetimi
Hasar yönetimi, talebin bildiriminden itibaren tüm süreci kapsar (FNOL - İlk Bildirim Kayıp) tasfiye ve olası geri kazanıma (halefiyet) kadar. Ve bu süreç Müşteri memnuniyetini ve sigorta şirketinin karlılığını doğrudan etkiler.
5. Yatırımlar ve Rezerv Yönetimi
Sigortacılar, gelecekteki tazminat taleplerini ödeme beklentisiyle toplanan primleri yatırıma yatırıyor. Yönetim yatırımların (Aktif-Pasif Yönetimi) ve hesaplanması rezervler teknikleri bunlar karmaşık aktüeryal modeller gerektiren düzenlenmiş süreçlerdir.
Temel Veri Modelleri
Bir geliştiricinin neyi modellemesi gerektiğinin özüne inelim. Aşağıdakiler agregalar (DDD anlamında) herhangi bir sigorta platformunun temelleri.
Başlıca Kuruluşlar ve İlişkiler
// ============================================
// Core Insurance Domain Model (TypeScript)
// ============================================
/** Tipologia di prodotto assicurativo */
type LineOfBusiness = 'LIFE' | 'PROPERTY' | 'CASUALTY' | 'HEALTH' | 'MARINE' | 'CYBER';
/** Stato della polizza nel suo ciclo di vita */
type PolicyStatus =
| 'QUOTE' // Preventivo
| 'APPLICATION' // Proposta
| 'BOUND' // Vincolata (impegno assunto)
| 'ISSUED' // Emessa
| 'IN_FORCE' // In vigore
| 'SUSPENDED' // Sospesa
| 'LAPSED' // Decaduta (mancato pagamento)
| 'CANCELLED' // Cancellata
| 'EXPIRED' // Scaduta
| 'NON_RENEWED'; // Non rinnovata
/** Aggregato principale: la Polizza */
interface Policy {
readonly id: string;
readonly policyNumber: string;
readonly version: number; // Versioning per endorsement
readonly lineOfBusiness: LineOfBusiness;
readonly status: PolicyStatus;
readonly effectiveDate: Date;
readonly expirationDate: Date;
readonly inceptionDate: Date; // Data prima emissione
readonly policyholder: Party; // Contraente
readonly insuredParties: readonly InsuredParty[];
readonly coverages: readonly Coverage[];
readonly premium: PremiumBreakdown;
readonly endorsements: readonly Endorsement[];
readonly documents: readonly Document[];
readonly underwritingInfo: UnderwritingInfo;
readonly createdAt: Date;
readonly updatedAt: Date;
}
/** Parte coinvolta (persona fisica o giuridica) */
interface Party {
readonly id: string;
readonly type: 'INDIVIDUAL' | 'ORGANIZATION';
readonly firstName?: string;
readonly lastName?: string;
readonly companyName?: string;
readonly taxId: string; // Codice fiscale / P.IVA
readonly dateOfBirth?: Date;
readonly addresses: readonly Address[];
readonly contacts: readonly ContactInfo[];
readonly riskProfile?: RiskProfile;
}
/** Soggetto assicurato con specifico ruolo */
interface InsuredParty {
readonly party: Party;
readonly role: 'PRIMARY' | 'ADDITIONAL' | 'NAMED_INSURED';
readonly relationship: string; // Relazione col contraente
}
/** Copertura: cosa e protetto e fino a quanto */
interface Coverage {
readonly id: string;
readonly code: string; // Es: "TPL", "CASCO", "FIRE"
readonly name: string;
readonly description: string;
readonly type: 'BASE' | 'OPTIONAL' | 'MANDATORY';
readonly limit: Money; // Massimale
readonly deductible: Deductible; // Franchigia
readonly premium: Money; // Premio per questa copertura
readonly effectiveDate: Date;
readonly expirationDate: Date;
readonly exclusions: readonly string[];
readonly conditions: readonly string[];
}
/** Franchigia con diverse modalità di applicazione */
interface Deductible {
readonly type: 'FIXED' | 'PERCENTAGE' | 'WAITING_PERIOD' | 'AGGREGATE';
readonly amount?: Money; // Per FIXED
readonly percentage?: number; // Per PERCENTAGE
readonly waitingDays?: number; // Per WAITING_PERIOD
readonly aggregateLimit?: Money; // Per AGGREGATE
readonly appliesToEach: 'CLAIM' | 'OCCURRENCE' | 'POLICY_PERIOD';
}
/** Scomposizione del premio */
interface PremiumBreakdown {
readonly grossPremium: Money; // Premio lordo
readonly netPremium: Money; // Premio netto (per l'assicuratore)
readonly taxes: Money; // Imposte
readonly fees: Money; // Diritti e commissioni
readonly commission: Money; // Provvigione intermediario
readonly components: readonly PremiumComponent[];
readonly paymentPlan: PaymentPlan;
}
/** Variazione contrattuale in corso di polizza */
interface Endorsement {
readonly id: string;
readonly endorsementNumber: number;
readonly type: 'COVERAGE_CHANGE' | 'LIMIT_CHANGE' | 'ADD_INSURED'
| 'REMOVE_INSURED' | 'ADDRESS_CHANGE' | 'VEHICLE_CHANGE'
| 'GENERAL_CHANGE';
readonly effectiveDate: Date;
readonly description: string;
readonly premiumAdjustment: Money; // Differenza premio (+/-)
readonly previousVersion: number;
readonly newVersion: number;
readonly changes: readonly FieldChange[];
readonly approvedBy?: string;
readonly approvedAt?: Date;
}
/** Valore monetario con valuta */
interface Money {
readonly amount: number;
readonly currency: string; // ISO 4217: "EUR", "USD", "GBP"
}
/** Singola modifica tracciata nell'endorsement */
interface FieldChange {
readonly field: string;
readonly oldValue: string;
readonly newValue: string;
}Anahtar Model: Değişmezlik ve Sürüm Oluşturma
Her arayüzün nasıl kullanıldığına dikkat edin readonly tüm mülklerde. Sigorta alanında,
the izlenebilirlik ve düzenleyici bir gereklilik: bir politikada yapılan her değişiklik,
yeni bir tane onay bu da artırır version. Asla "değişmez".
bir politika; yeni bir versiyon oluşturulur. Bu model şu modelle mükemmel uyum sağlar:olay kaynağı
ve CQRS mimarileriyle.
Politika Yaşam Döngüsü
Politika, var olduğu süre boyunca iyi tanımlanmış durumlardan geçer. Bu yaşam döngüsünü modelleyelim biri gibi durum makinesi, sigorta yazılımında temel bir model.
// ============================================
// Policy Lifecycle State Machine
// ============================================
/** Transizioni valide nel ciclo di vita della polizza */
type PolicyTransition =
| { from: 'QUOTE'; to: 'APPLICATION'; action: 'SUBMIT_APPLICATION' }
| { from: 'QUOTE'; to: 'CANCELLED'; action: 'DECLINE_QUOTE' }
| { from: 'APPLICATION'; to: 'BOUND'; action: 'BIND_COVERAGE' }
| { from: 'APPLICATION'; to: 'CANCELLED'; action: 'DECLINE_APPLICATION' }
| { from: 'BOUND'; to: 'ISSUED'; action: 'ISSUE_POLICY' }
| { from: 'ISSUED'; to: 'IN_FORCE'; action: 'ACTIVATE' }
| { from: 'IN_FORCE'; to: 'IN_FORCE'; action: 'ENDORSE' }
| { from: 'IN_FORCE'; to: 'SUSPENDED'; action: 'SUSPEND' }
| { from: 'IN_FORCE'; to: 'CANCELLED'; action: 'CANCEL' }
| { from: 'IN_FORCE'; to: 'EXPIRED'; action: 'EXPIRE' }
| { from: 'IN_FORCE'; to: 'IN_FORCE'; action: 'RENEW' }
| { from: 'IN_FORCE'; to: 'NON_RENEWED'; action: 'NON_RENEW' }
| { from: 'SUSPENDED'; to: 'IN_FORCE'; action: 'REINSTATE' }
| { from: 'SUSPENDED'; to: 'LAPSED'; action: 'LAPSE' }
| { from: 'LAPSED'; to: 'IN_FORCE'; action: 'REINSTATE' }
| { from: 'LAPSED'; to: 'CANCELLED'; action: 'CANCEL' };
/** Mappa delle transizioni valide per validazione runtime */
const VALID_TRANSITIONS: ReadonlyMap<PolicyStatus, readonly PolicyTransition[]> = new Map([
['QUOTE', [
{ from: 'QUOTE', to: 'APPLICATION', action: 'SUBMIT_APPLICATION' },
{ from: 'QUOTE', to: 'CANCELLED', action: 'DECLINE_QUOTE' },
]],
['APPLICATION', [
{ from: 'APPLICATION', to: 'BOUND', action: 'BIND_COVERAGE' },
{ from: 'APPLICATION', to: 'CANCELLED', action: 'DECLINE_APPLICATION' },
]],
['IN_FORCE', [
{ from: 'IN_FORCE', to: 'IN_FORCE', action: 'ENDORSE' },
{ from: 'IN_FORCE', to: 'SUSPENDED', action: 'SUSPEND' },
{ from: 'IN_FORCE', to: 'CANCELLED', action: 'CANCEL' },
{ from: 'IN_FORCE', to: 'EXPIRED', action: 'EXPIRE' },
{ from: 'IN_FORCE', to: 'IN_FORCE', action: 'RENEW' },
{ from: 'IN_FORCE', to: 'NON_RENEWED', action: 'NON_RENEW' },
]],
]);
/** Funzione pura per la transizione di stato */
function transitionPolicy(
policy: Policy,
action: PolicyTransition['action'],
context: TransitionContext
): Policy {
const validTransitions = VALID_TRANSITIONS.get(policy.status);
const transition = validTransitions?.find(t => t.action === action);
if (!transition) {
throw new InvalidTransitionError(
`Cannot perform ${action} on policy in status ${policy.status}`
);
}
// Crea nuova versione immutabile della polizza
return {
...policy,
status: transition.to,
version: policy.version + 1,
updatedAt: new Date(),
endorsements: action === 'ENDORSE'
? [...policy.endorsements, context.endorsement!]
: policy.endorsements,
};
}Yaşam Döngüsünün Temel Aşamaları
İhraç Öncesi Aşama
- Oranlar: Minimum verilere dayalı gösterge niteliğinde tahmin. Tipik geçerlilik: 30 gün
- Başvuru: Sigortalama için gerekli tüm verileri içeren resmi teklif
- Bağla: Sigortacı teminat sağlamayı kabul eder (ancak poliçe henüz düzenlenmemiştir)
- Sorun: Resmi politika belgesinin düzenlenmesi
İhraç Sonrası Aşama
- Onaylıyor: Geçerli koşulların değiştirilmesi (yeni versiyon)
- Yenile: Süre dolduğunda yenileme (yeniden derecelendirmeyi gerektirebilir)
- Askıya almak: Geçici uzaklaştırma (ör. ödeme yapılmaması)
- İptal etmek: Tahakkuk priminin hesaplanmasıyla iptal
- Sıfırla: Askıya alma veya müsadere sonrasında işe iade
Talep Yaşam Döngüsü
Kaza sigorta vaadini harekete geçiren olaydır. Yaşam döngüsü aynı yapılandırılmıştır ve bir durum makinesi olarak modellemeye mükemmel şekilde uygundur.
// ============================================
// Claims Domain Model
// ============================================
type ClaimStatus =
| 'FNOL' // First Notice of Loss - notifica iniziale
| 'REGISTERED' // Registrato nel sistema
| 'UNDER_INVESTIGATION' // In fase di indagine/perizia
| 'ASSESSED' // Valutato dal perito
| 'APPROVED' // Approvato per liquidazione
| 'PARTIALLY_APPROVED'// Parzialmente approvato
| 'DENIED' // Rifiutato
| 'SETTLED' // Liquidato
| 'REOPENED' // Riaperto
| 'CLOSED' // Chiuso definitivamente
| 'SUBROGATION'; // In fase di recupero
interface Claim {
readonly id: string;
readonly claimNumber: string;
readonly policyId: string;
readonly policyNumber: string;
readonly status: ClaimStatus;
readonly lossDate: Date; // Data del sinistro
readonly reportDate: Date; // Data della denuncia
readonly lossType: string; // Tipo di danno
readonly lossDescription: string;
readonly lossLocation: Address;
readonly claimant: Party; // Chi richiede l'indennizzo
readonly reserves: readonly Reserve[];
readonly payments: readonly ClaimPayment[];
readonly assessments: readonly Assessment[];
readonly documents: readonly Document[];
readonly fraudIndicators: readonly FraudIndicator[];
readonly totalIncurred: Money; // Riserva + Pagato
readonly totalPaid: Money;
readonly totalReserve: Money;
}
/** Riserva: stima del costo futuro del sinistro */
interface Reserve {
readonly id: string;
readonly type: 'INDEMNITY' | 'EXPENSE' | 'LEGAL';
readonly amount: Money;
readonly setDate: Date;
readonly setBy: string;
readonly reason: string;
readonly history: readonly ReserveChange[];
}
/** Pagamento effettuato sul sinistro */
interface ClaimPayment {
readonly id: string;
readonly type: 'INDEMNITY' | 'EXPENSE' | 'LEGAL' | 'SALVAGE' | 'SUBROGATION';
readonly amount: Money;
readonly payee: Party;
readonly paymentDate: Date;
readonly paymentMethod: string;
readonly invoiceReference?: string;
readonly approvedBy: string;
}
/** Valutazione peritale */
interface Assessment {
readonly id: string;
readonly assessor: Party; // Perito
readonly assessmentDate: Date;
readonly damageEstimate: Money;
readonly findings: string;
readonly recommendation: 'APPROVE' | 'DENY' | 'FURTHER_INVESTIGATION';
readonly photos: readonly string[]; // URL delle foto
readonly report: Document;
}
/** Indicatore di potenziale frode */
interface FraudIndicator {
readonly rule: string;
readonly score: number; // 0-100
readonly description: string;
readonly triggeredAt: Date;
}Kazanın Aşamaları Detaylı
| Faz | Etkinlik | İlgili Aktörler | Oluşturulan Veriler |
|---|---|---|---|
| FNOL | Kazayı telefon, web, uygulama, e-posta yoluyla bildirin | Sigortalı, Çağrı Merkezi | Talep Bildirimi, İlk Rezerv |
| Triyaj | Talep sınıflandırması, öncelik ataması, kapsam doğrulaması | Talep Elemanı, Otomatik sistem | Kapsam Doğrulama, Öncelik, Atama |
| Soruşturma | Belgelerin toplanması, değerlendirilmesi, koşulların doğrulanması | Uzman, Araştırmacı, Adli Tıp Uzmanı | Değerlendirme, Fotoğraflar, Bilirkişi Raporu |
| hüküm | Karar: tam, kısmi kabul veya ret | Talep Yöneticisi, Talep Komitesi | Karar, AyarlamaHesabı |
| Yerleşimler | Tazminat ve ödemenin hesaplanması | Hasar Sorumlusu, Ödemeler Ofisi | Ödeme, Uzlaşma Anlaşması |
| İyileşmek | Sorumlu üçüncü kişilere halefiyet, kurtarma kurtarma | Hukuk bürosu, Kurtarma ofisi | HalefiyetTalep, Geri Kazanım |
Derecelendirme Motorunun Mimarisi
Il derecelendirme motoru ve sigorta primini hesaplayan bileşen. Ve bunlardan biri InsurTech ekosistemindeki en kritik ve yüksek performanslı sistemler: binlerce teklifi işlemelidir Aktüeryal hassasiyet ve tam izlenebilirlik ile saniyede.
Prim Hesaplama Nasıl Çalışır?
Prim hesaplaması, risk faktörlerini son fiyat. Araba TPL'si için basitleştirilmiş bir örnek görelim.
// ============================================
// Rating Engine - Esempio RC Auto
// ============================================
/** Fattori di rischio per la tariffazione auto */
interface AutoRatingFactors {
readonly driverAge: number;
readonly driverExperience: number; // Anni di patente
readonly vehicleGroup: number; // Gruppo tariffario 1-20
readonly vehicleAge: number;
readonly postalCode: string;
readonly claimsHistory: number; // Sinistri ultimi 5 anni
readonly bonusMalusClass: number; // Classe CU (1-18 in Italia)
readonly annualMileage: number;
readonly garaging: 'GARAGE' | 'STREET' | 'PARKING';
readonly usage: 'PERSONAL' | 'COMMUTE' | 'BUSINESS';
}
/** Risultato del calcolo tariffario */
interface RatingResult {
readonly baseRate: Money;
readonly factors: readonly AppliedFactor[];
readonly technicalPremium: Money; // Premio tecnico (puro rischio)
readonly loadings: readonly Loading[];
readonly grossPremium: Money; // Premio lordo finale
readonly taxes: Money;
readonly totalPremium: Money; // Totale da pagare
readonly ratingDate: Date;
readonly rateTableVersion: string;
readonly auditTrail: readonly string[];
}
interface AppliedFactor {
readonly name: string;
readonly inputValue: string | number;
readonly factor: number; // Moltiplicatore (es: 1.25 = +25%)
readonly source: string; // Tabella di riferimento
}
interface Loading {
readonly type: 'EXPENSE' | 'COMMISSION' | 'PROFIT' | 'CATASTROPHE' | 'REINSURANCE';
readonly percentage: number;
readonly amount: Money;
}
/** Rating Engine: funzione pura che calcola il premio */
function calculateAutoRate(
factors: AutoRatingFactors,
rateTables: RateTableSet
): RatingResult {
const auditTrail: string[] = [];
// 1. Base Rate dalla tabella territoriale
const baseRate = rateTables.territorial.lookup(factors.postalCode);
auditTrail.push(`Base rate for ${factors.postalCode}: ${baseRate}`);
// 2. Applicazione fattori moltiplicativi
const ageMultiplier = rateTables.ageFactors.lookup(factors.driverAge);
const vehicleMultiplier = rateTables.vehicleGroups.lookup(factors.vehicleGroup);
const bonusMalusMultiplier = rateTables.bonusMalus.lookup(factors.bonusMalusClass);
const experienceMultiplier = rateTables.experience.lookup(factors.driverExperience);
const mileageMultiplier = rateTables.mileage.lookup(factors.annualMileage);
const appliedFactors: AppliedFactor[] = [
{ name: 'Age', inputValue: factors.driverAge, factor: ageMultiplier, source: 'AGE_TABLE_v3' },
{ name: 'Vehicle Group', inputValue: factors.vehicleGroup, factor: vehicleMultiplier, source: 'VEH_TABLE_v2' },
{ name: 'Bonus/Malus', inputValue: factors.bonusMalusClass, factor: bonusMalusMultiplier, source: 'BM_TABLE_v1' },
{ name: 'Experience', inputValue: factors.driverExperience, factor: experienceMultiplier, source: 'EXP_TABLE_v1' },
{ name: 'Mileage', inputValue: factors.annualMileage, factor: mileageMultiplier, source: 'KM_TABLE_v2' },
];
// 3. Premio tecnico = base * prodotto dei fattori
const combinedFactor = appliedFactors.reduce((acc, f) => acc * f.factor, 1);
const technicalPremium = baseRate * combinedFactor;
auditTrail.push(`Technical premium: ${baseRate} * ${combinedFactor.toFixed(4)} = ${technicalPremium.toFixed(2)}`);
// 4. Caricamenti (expense loading, commissioni, profitto)
const loadings: Loading[] = [
{ type: 'EXPENSE', percentage: 0.15, amount: { amount: technicalPremium * 0.15, currency: 'EUR' } },
{ type: 'COMMISSION', percentage: 0.12, amount: { amount: technicalPremium * 0.12, currency: 'EUR' } },
{ type: 'PROFIT', percentage: 0.05, amount: { amount: technicalPremium * 0.05, currency: 'EUR' } },
{ type: 'CATASTROPHE', percentage: 0.02, amount: { amount: technicalPremium * 0.02, currency: 'EUR' } },
];
const totalLoadingPct = loadings.reduce((acc, l) => acc + l.percentage, 0);
const grossPremium = technicalPremium * (1 + totalLoadingPct);
// 5. Imposte (22.25% per RC Auto in Italia)
const taxRate = 0.2225;
const taxes = grossPremium * taxRate;
const totalPremium = grossPremium + taxes;
return {
baseRate: { amount: baseRate, currency: 'EUR' },
factors: appliedFactors,
technicalPremium: { amount: technicalPremium, currency: 'EUR' },
loadings,
grossPremium: { amount: grossPremium, currency: 'EUR' },
taxes: { amount: taxes, currency: 'EUR' },
totalPremium: { amount: totalPremium, currency: 'EUR' },
ratingDate: new Date(),
rateTableVersion: 'RC_AUTO_2026_Q1',
auditTrail,
};
}Modern Derecelendirme Motorunun Mimarisi
Üretimdeki bir derecelendirme motoru bu örnekten çok daha karmaşıktır. Temel özellikler şunları içerir:
- Sürüm Tabloları: Her tarife tablosunun bir geçerlilik tarihi vardır. Sistem güncel tarihe göre değil poliçenin yürürlük tarihine göre doğru tabloyu uygulamalıdır.
- Ayrı Kural Motoru: İş kuralları (limitler, hariç tutmalar, indirimler), genellikle bir kural motoru (Drools, RETE veya JSON tabanlı) aracılığıyla kod dağıtılmadan yapılandırılabilir.
- Tam denetim izi: Hesaplamanın her adımı mevzuata uygunluk açısından izlenebilir olmalıdır
- Yatay ölçeklenebilirlik: Derecelendirme motorunun saniyede binlerce tekliften oluşan zirveleri (karşılaştırıcılar, açık kayıt) yönetmesi gerekir.
- İdempotans: Aynı girdi her zaman aynı çıktıyı üretmelidir (saf fonksiyon)
Sigortacılık için Etki Alanı Odaklı Tasarım
Etki Alanı Odaklı Tasarım (DDD), sigorta alanına en uygun mimari yaklaşımdır içsel karmaşıklığı ve yazılımı işin diliyle uyumlu hale getirme ihtiyacı. Şimdi bunu somut olarak nasıl uygulayacağımızı görelim.
Sigorta Ekosisteminin Sınırlı Bağlamı
Her sınırlı bağlamın kendine ait her yerde bulunan dil, modelleri ve kendi kuralları. "Politika" teriminin Sigortacılık bağlamında farklı anlamları vardır (teklif değerlendirilecek) Politika İdaresi (sözleşme düzenlendi) ile karşılaştırıldı.
// ============================================
// Bounded Context Map
// ============================================
//
// +------------------+ +------------------+ +------------------+
// | Distribution | | Underwriting | | Policy Admin |
// | | | | | |
// | - Lead | | - Submission | | - Policy |
// | - Opportunity |---->| - Risk |---->| - Coverage |
// | - Quote Request | | - Rating | | - Endorsement |
// | - Channel | | - Decision | | - Renewal |
// +------------------+ +------------------+ +------------------+
// | | |
// | | |
// v v v
// +------------------+ +------------------+ +------------------+
// | CRM / Party | | Reinsurance | | Claims |
// | | | | | |
// | - Customer | | - Treaty | | - Claim |
// | - Agent | | - Cession | | - Reserve |
// | - Broker | | - Recovery | | - Payment |
// | - Address | | - Bordereaux | | - Assessment |
// +------------------+ +------------------+ +------------------+
// | | |
// v v v
// +------------------+ +------------------+ +------------------+
// | Billing | | Compliance | | Fraud Detection |
// | | | | | |
// | - Invoice | | - Filing | | - Alert |
// | - Payment | | - Report | | - Investigation |
// | - Collection | | - Audit | | - Score |
// | - Installment | | - Solvency | | - Rule |
// +------------------+ +------------------+ +------------------+
// Context Mapping Relationships:
// Distribution --[Conformist]--> Underwriting
// Underwriting --[Published Language]--> Policy Admin
// Policy Admin --[Shared Kernel]--> Billing
// Policy Admin --[Customer/Supplier]--> Claims
// Claims --[Anti-Corruption Layer]--> Fraud Detection
// Underwriting --[Partnership]--> Reinsurance
// All Contexts --[Conformist]--> ComplianceToplamalar ve Değişmezler
DDD'de her agrega iş değişmezlerini korur. İşte buradalar iki temel toplam için ana değişmezler:
Toplu Politika
- Bir poliçenin en az bir aktif teminatı olmalıdır
- Son kullanma tarihi yürürlük tarihinden sonra olmalıdır
- Toplam prim, teminat primleri + yüklemelerin toplamı olmalıdır
- Her onay sürümü artırmalıdır
- Durum geçişleri durum makinesine saygı göstermelidir
- Açık taleplerle poliçe iptal edilemez
Talep toplamı
- Kaza tarihinin poliçe teminat süresi içerisinde olması gerekmektedir.
- Rezerv negatif olamaz
- Ödenen toplam tutar teminat limitini aşamaz
- Kapatılan bir hak talebi yeni ödeme alamaz (yeniden açılması gerekir)
- Karar en azından bir uzman değerlendirmesini gerektiriyor
- Ödeme, yetki eşiğini aşarsa onay gerektirir
Etki Alanı Etkinlikleri
I etki alanı olayları sınırlı bağlamların bir şekilde iletişim kurmasını sağlayan mekanizmalardır ayrılmış. Her olay, alanda meydana gelen önemli bir şeyi temsil eder.
// ============================================
// Insurance Domain Events
// ============================================
interface DomainEvent {
readonly eventId: string;
readonly eventType: string;
readonly occurredAt: Date;
readonly aggregateId: string;
readonly aggregateType: string;
readonly version: number;
readonly correlationId: string;
readonly causationId?: string;
}
// --- Policy Events ---
interface PolicyQuoted extends DomainEvent {
readonly eventType: 'POLICY_QUOTED';
readonly aggregateType: 'Policy';
readonly quoteNumber: string;
readonly premium: Money;
readonly validUntil: Date;
}
interface PolicyIssued extends DomainEvent {
readonly eventType: 'POLICY_ISSUED';
readonly aggregateType: 'Policy';
readonly policyNumber: string;
readonly effectiveDate: Date;
readonly premium: Money;
readonly coverages: readonly string[];
}
interface PolicyEndorsed extends DomainEvent {
readonly eventType: 'POLICY_ENDORSED';
readonly aggregateType: 'Policy';
readonly endorsementNumber: number;
readonly changes: readonly FieldChange[];
readonly premiumAdjustment: Money;
}
// --- Claim Events ---
interface ClaimFiled extends DomainEvent {
readonly eventType: 'CLAIM_FILED';
readonly aggregateType: 'Claim';
readonly policyNumber: string;
readonly lossDate: Date;
readonly lossType: string;
readonly initialReserve: Money;
}
interface ClaimSettled extends DomainEvent {
readonly eventType: 'CLAIM_SETTLED';
readonly aggregateType: 'Claim';
readonly settlementAmount: Money;
readonly payee: string;
}
// --- Cross-Context Reactions ---
// PolicyIssued -> Billing: createInvoice()
// PolicyIssued -> Reinsurance: calculateCession()
// ClaimFiled -> FraudDetection: screenClaim()
// ClaimFiled -> Reinsurance: notifyCession()
// ClaimSettled -> Billing: adjustReserve()
// ClaimSettled -> Reinsurance: calculateRecovery()ACORD Standartları ve Birlikte Çalışabilirlik
Uzlaşı (Kooperatif Yöneylem Araştırma ve Geliştirme Derneği) e küresel sigorta endüstrisi için veri standartlarını belirleyen kuruluş. Bir geliştirici için ACORD, sağlık hizmetleri için HL7/FHIR'e veya finans için SWIFT'e eşdeğerdir.
ACORD Veri Standartları: Nelerdir?
ACORD ayrıntılı veri modelleri, mesaj formatları (XML ve JSON) ve şemalar sağlar Sigorta süreçlerine özel tasarlandı. Amaç akışı sağlamaktır Ekosistemdeki tüm oyuncular arasında verimli veri işleme: sigortacılar, komisyoncular, acenteler, Reasürörler ve düzenleyiciler.
| Standart ACORD | Biçim | Kullanım | Sektör |
|---|---|---|---|
| AKOR AL3 | Sahip (sabit uzunlukta) | Acente-sigortacı veri alışverişi (ABD) | P&C Kişisel Hatlar |
| ACORD XML'i | XML Şeması | Fiyat teklifi, düzenleme, talepler, faturalandırma | P&C, Yaşam, Sağlık |
| ACORD GRLC 2.0 | JSON/XML | Reasürans ve büyük ticari (küresel) | Reasürans, Uzmanlık |
| ACORD Yeni Nesil | JSON (önce API) | Mikro hizmetler, REST API, eşzamansız olaylar | Sektörler arası |
| ACORD Formları | PDF/XML | Standartlaştırılmış formlar (sertifikalar, ekler) | P&C (ABD) |
GRLC Nesli 2.0 (Nisan 2025)
Son yılların en önemli güncellemesi ve lansmanı GRLC Nesil 2.0, mikro hizmetler gibi hassas işlemler için optimize edilmiş, dijital öncelikli, JSON tabanlı bir standart ve API'ler. Tüm politika yaşam döngüsünün uçtan uca düz işlenmesini destekler küresel reasürans ekosisteminde eski entegrasyonlara gerek kalmadan modern entegrasyonlara olanak sağlanması Toplu XML biçimleri.
Sigorta için API Kalıbı
Modern sigorta API'leri, alanın karmaşıklığını yansıtan belirli kalıpları takip eder:
- Eşzamansız Alıntılama: Karmaşık teklifler (ticari, özel) eşzamansız işlem gerektirir. API bir döndürür
quoteRequestIdve tamamlandığında webhook aracılığıyla bilgilendirin - Geçici versiyonlama: Her kaynağın (politika, kapsam) bir zaman boyutu vardır. API, aşağıdaki sorguları destekler:
asOfDatetarihi durumuna geri dönmek - İdempotans: Bağlama ve ödeme işlemleri idempotent yoluyla yapılmalıdır
idempotencyKeyçoğaltmayı önlemek için - Etkinlik akışı: Durum değişiklikleri, aşağı akışlı sistemlerle entegrasyon için olaylar (webhook veya mesaj aracısı) aracılığıyla bildirilir
Düzenleyici Ortam
Sigorta sektörü dünyada en çok düzenlemeye tabi olanlardan biridir. Bir geliştirici için bu şu anlama gelir: birçok mimari karar uyum tarafından belirlenir, sadece ondan değil mühendislikte en iyi uygulamalar.
Temel Düzenlemeler ve Yazılım Üzerindeki Etkisi
| Düzenleme | Kapsam | Yazılım Üzerindeki Etki |
|---|---|---|
| Ödeme Gücü II | AB - Sermaye ve ödeme gücü gereksinimleri | Risk modelleri, SCR (Solvency Sermaye Gereksinimi) hesaplaması, XBRL raporlaması, veri kalitesi çerçevesi |
| UFRS 17 | Global - Sigorta sözleşmelerinin muhasebeleştirilmesi | CSM (Sözleşmeye Bağlı Hizmet Marjı) hesaplaması, sözleşme gruplaması, ölçüm modelleri (BBA, VFA, PAA) |
| GDPR / Gizlilik | AB - Kişisel verilerin korunması | Ayrıntılı onay, unutulma hakkı ve zorunlu saklama (çatışma), takma ad kullanma, DPIA |
| ID | AB - Sigorta dağıtımı | Danışmanlığın izlenebilirliği, ürün yeterliliği, çıkar çatışmaları, sözleşme öncesi belgeler |
| DORA | AB - Dijital operasyonel dayanıklılık | BİT risk yönetimi, olay raporlama, dayanıklılık testi, üçüncü taraf riski (bulut sağlayıcısı) |
| ICS 2025 | Küresel - IAIG için Sermaye Standardı | Birleşik küresel standartla yasal sermaye hesaplaması (2025'ten itibaren geçerli) |
GDPR ile Sigortayı Saklama Çatışması
Sigorta geliştiricisi için en karmaşık ikilemlerden biri: GDPR, doğru unutulmaya, ancak sigorta düzenlemeleri şunu gerektirir: veri saklama 5 ile 30 yıl arasında değişen sürelerde (açık rezervli alacaklar, hukuki uyuşmazlıklar, yükümlülükler) aktüeryal). Tipik çözüm şunları içerir: aşamalı takma ad verme: veriler tanımlayıcılar işlem verilerinden ayrılır ve mümkün olduğunda silinir; Düzenleyici yükümlülükler için anonimleştirilmiş veriler.
Modern InsurTech Platformunun Mimarisi
Modern sigorta platformları bir mimariyi benimsiyor bulutta yerel, API öncelikli, olay odaklı. Eski monolit, sınırlı hizalanmış mikro hizmetlere bölünmüştür etki alanı bağlamı.
Tipik Teknoloji Yığını (2025-2026)
| Katmanlar | Teknolojiler | İşlev |
|---|---|---|
| Başlangıç aşaması | Angular, React, Vue + mikro ön uç | Temsilci portalı, müşteri portalı, arka ofis |
| API Ağ Geçidi | Kong, AWS API Ağ Geçidi, Apigee | Hız sınırlama, kimlik doğrulama, yönlendirme, sürüm oluşturma |
| Mikro hizmetler | Node.js/NestJS, Java/Spring Boot, Go | Politika, Talepler, Derecelendirme, Faturalandırma, CRM |
| Etkinlik Otobüsü | Apache Kafka, AWS EventBridge, RabbitMQ | Etki alanı etkinlikleri, CQRS, etkinlik kaynağı bulma |
| Veritabanları | PostgreSQL, MongoDB, DynamoDB | Hizmet başına veritabanı (sınırlı bağlam başına veritabanı) |
| AI/ML | Python, TensorFlow, SageMaker | Dolandırıcılık tespiti, fiyatlandırma optimizasyonu, OCR belgeleri |
| Orkestrasyon | Kubernetes, AWS ECS, Temporal.io | Ölçeklendirme, destan modelleri, uzun süren iş akışları |
| gözlemlenebilirlik | Datadog, Grafana, OpenTelemetry | Dağıtılmış izleme, ölçümler, merkezi günlük kaydı |
Anahtar Mimari Desenler
Politikalar için Olay Kaynak Kullanımı
L'olay kaynağı ve özellikle sigorta alanı için uygundur çünkü politika ve doğası gereği bir olaylar dizisi (ihraç, onay, yenileme, iddia). Yalnızca mevcut durumu depolamak yerine tüm olayları depolar ve yeniden oluşturursunuz aracılığıyla mevcut durum tekrar oynatma. Bu otomatik olarak eksiksiz bir denetim takibi sağlar, önemli bir düzenleyici gerekliliktir.
Bağlamlar Arası Süreçler için Saga Modeli
Bir poliçenin düzenlenmesi gibi süreçler birden fazla sınırlı bağlamı içerir: Sigortalama onaylar, Poliçe Yöneticisi düzenler, Faturalandırma faturayı oluşturur, Reasürans atamayı hesaplar. destan deseni (orkestre edilmiş veya koreograflanmış) bu dağıtılmış adımları koordine eder başarısızlık durumunda nihai tutarlılığın ve telafinin sağlanması. Temporal.io e InsurTech'te özellikle uzun süreli durum bilgisi olan iş akışlarının uygulanmasında popülerdir ısrarcı.
Çok Aracılı Yapay Zeka Sistemleri (Trend 2026)
Tek bir yekpare yapay zeka asistanı yerine en gelişmiş InsurTech platformları duruyor uygulamak çoklu ajan sistemleri uzman temsilcilerle: tek temsilci iddiaların alınması, biri dolandırıcılık kontrolü için, biri müşteriyle iletişim için, biri ödemeler ve kurtarma. Bu aracılar net iş akışları aracılığıyla yönetilir ve talep yaşam döngüsünün tamamını otomatikleştirmek için birlikte çalışırlar.
Sonuçlar ve Sonraki Adımlar
Sigorta alanı bir geliştiricinin karşılaşabileceği en zengin ve en karmaşık alanlardan biridir. Bu makalede temelleri oluşturduk: ürünler, aktörler, değer zinciri, veri modelleri, yaşam döngüleri, derecelendirme motoru, uygulanan DDD ve düzenleyici ortam.
İşte paket servisler ana:
- Sigorta ürünü bir vaattir: bu, veri modellerini doğası gereği zamansal ve versiyonlu hale getirir
- Evrensel bir model yoktur: Yaşam, P&C, Sağlık ve Uzmanlığın son derece farklı ihtiyaçları vardır
- Durum makinesi ve temel model: hem politikalar hem de talepler için yaşam döngüsü ve iyi tanımlanmış geçişlere sahip bir durum makinesi
- Değişmezlik düzenleyici bir gerekliliktir: her değişiklik yeni bir sürüm oluşturur, asla üzerine yazma yapılmaz
- DDD ve doğal yaklaşım: Değer zinciriyle uyumlu sınırlı bağlam, iş değişmezlerini koruyan kümeler, ayırma için etki alanı olayları
- Uyumluluk mimariyi yönlendirir: Solvency II, IFRS 17, GDPR ve DORA "sahip olmak hoş" değil, temel mimari kısıtlamalardır
- ACORD ve ortak dil: ACORD standartları (özellikle Yeni Nesil JSON) ekosistemde birlikte çalışabilirlik için gereklidir
Bir sonraki bölümde
InsurTech Mühendislik serisinin bir sonraki makalesinde, bu konuyu daha derinlemesine inceleyeceğiz. Politika Yönetim Sistemi: Ürün yapılandırıcıyla modern bir PAS nasıl tasarlanır, geçici versiyonlama, onay motoru ve derecelendirme motoruyla entegrasyon. göreceğiz Çoklu teminatlı sigorta ürünlerinin karmaşıklığını yönetmek için somut modeller etki alanı odaklı bir yaklaşım.