کالبدشکافی هسته بیمه‌گری: اجزا، سازوکار و ملزومات ساخت

این یادداشت هسته بیمه‌گری را از دید ساخت باز می‌کند، نه از دید خرید. برای هر زیرسیستم سه چیز آمده است: چه کاری می‌کند، با چه سازوکاری آن را انجام می‌دهد، و اگر بخواهیم خودمان بسازیم چه تصمیم‌هایی باید بگیریم.

یک جمله که کل معماری را تعیین می‌کند: هسته بیمه‌گری یک سیستم ثبت رویداد مالی زمان‌دار است، نه یک CRUD روی جدول بیمه‌نامه. هر تصمیمی که این را نقض کند، دیر یا زود به بن‌بست الحاقیه عطف‌به‌ماسبق و مغایرت مالی می‌رسد.

---

۰. مرز هسته کجاست؟

قبل از هر چیز باید معلوم شود چه چیزی داخل هسته است و چه چیزی نیست. مرز اشتباه، شایع‌ترین دلیل بزرگ شدن بی‌کنترل پروژه است.

قاعده تفکیک: هر چیزی که بر عدد حق بیمه، تعهد بیمه‌گر یا ذخایر اثر می‌گذارد داخل هسته است. بقیه، مصرف‌کننده هسته‌اند و باید فقط از طریق API با آن حرف بزنند.

---

۱. مدل دامنه

ستون فقرات همه چیز. اگر این مدل درست نباشد هیچ زیرسیستمی درست در نمی‌آید.

Party (شخص)
  └─ حقیقی / حقوقی، کد ملی یا شناسه ملی، نقش‌ها
       └─ نقش‌ها: بیمه‌گذار، بیمه‌شده، ذی‌نفع، نماینده، ارزیاب، طرف ثالث

Product (محصول)                    ← نسخه‌دار، دارای بازه اعتبار
  ├─ Coverage[] (پوشش‌ها)          ← اجباری/اختیاری، سقف، فرانشیز
  ├─ RatingModel                   ← ارجاع به نسخه مشخصی از موتور نرخ
  ├─ UnderwritingRules             ← شرایط پذیرش و ارجاع
  └─ FormTemplate                  ← فرم چاپی و شرایط عمومی/خصوصی

Policy (بیمه‌نامه)
  ├─ PolicyVersion[]               ← هر الحاقیه = یک نسخه جدید، نه ویرایش
  │    ├─ effectiveFrom / effectiveTo      (زمان کسب‌وکار)
  │    ├─ recordedAt / supersededAt        (زمان سیستم)
  │    └─ RiskItem[] (موضوعات بیمه)        ← خودرو، ساختمان، فرد، محموله
  │         └─ CoverageInstance[]          ← پوشش + سرمایه + فرانشیز + حق بیمه
  ├─ PremiumBreakdown              ← تفکیک‌شده، هرگز یک عدد واحد
  ├─ Installment[]                 ← اقساط و سررسید
  └─ Commission[]                  ← سهم هر عضو شبکه فروش

Claim (خسارت)
  ├─ بستگی به PolicyVersion معتبر در «تاریخ حادثه»، نه تاریخ امروز
  ├─ ReserveMovement[]             ← تاریخچه ذخیره خسارت معوق
  ├─ Payment[]
  └─ Recovery[]                    ← بازیافت و ورود ثالث

Treaty (قرارداد اتکایی)
  └─ Cession[]                     ← سهم واگذارشده هر ریسک و هر خسارت

سه تصمیمی که همین‌جا باید گرفته شود:

۱. بیمه‌نامه هرگز ویرایش نمی‌شود. هر تغییر یک نسخه جدید می‌سازد و نسخه قبلی دست‌نخورده باقی می‌ماند. UPDATE روی رکورد صادرشده ممنوع است.

۲. حق بیمه یک عدد نیست، یک تفکیک است. حق بیمه پایه به تفکیک هر پوشش، تخفیف‌ها، اضافه‌نرخ‌ها، عوارض قانونی و مالیات، همه باید جدا نگهداری شوند. اتکایی، کارمزد، تخصیص خسارت و گزارش نظارتی هر کدام به یک لایه متفاوت از این تفکیک نیاز دارند و اگر از اول جدا نگه داشته نشود، دیگر قابل بازسازی نیست.

۳. موضوع بیمه (RiskItem) موجودیت مستقل است. یک بیمه‌نامه آتش‌سوزی می‌تواند ده ساختمان داشته باشد و یک بیمه‌نامه گروهی درمان ده هزار نفر. مدل «یک بیمه‌نامه = یک ریسک» در رشته دوم فوراً می‌شکند.

---

۲. کارخانه محصول (Product Factory)

چه می‌کند: امکان تعریف یک محصول بیمه‌ای جدید بدون نوشتن کد.

چگونه: محصول به‌صورت متادیتا ذخیره می‌شود نه کد: فهرست پوشش‌ها، فیلدهای ورودی مورد نیاز هر پوشش، اعتبارسنجی‌ها، سقف‌ها، فرانشیزها، وابستگی پوشش‌ها به هم و ارجاع به نسخه‌ای از مدل نرخ. موتور صدور این متادیتا را می‌خواند و فرم و منطق را از روی آن می‌سازد.

تصمیم‌های کلیدی:

• نسخه‌بندی با بازه اعتبار. هر محصول نسخه دارد و هر نسخه یک validFrom/validTo. بیمه‌نامه به نسخه مشخصی از محصول ارجاع می‌دهد، نه به شناسه محصول. وقتی تعرفه سال بعد ابلاغ شد، نسخه جدید ساخته می‌شود و بیمه‌نامه‌های قبلی همچنان با نسخه قدیم قابل بازسازی‌اند.
• جدا کردن ساختار محصول از نرخ. ساختار پوشش‌ها کند تغییر می‌کند، نرخ‌ها سریع. اگر در یک موجودیت قاطی شوند، هر ابلاغ تعرفه یک مهاجرت داده می‌شود.
• پرهیز از موتور قواعد بیش‌ازحد عمومی. وسوسه ساخت یک DSL کامل زیاد است؛ نتیجه معمولاً زبانی است که هیچ‌کس جز سازنده‌اش نمی‌تواند دیباگ کند. یک مدل اعلانی محدود و قابل اعتبارسنجی، در عمل بهتر جواب می‌دهد.

---

۳. موتور نرخ (Rating Engine)

قلب سیستم و جایی که بیشترین بدهی فنی جمع می‌شود.

چه می‌کند: از مشخصات ریسک، عدد حق بیمه در می‌آورد.

چگونه: ترکیبی از جدول نرخ (نرخ بر حسب گروه خودرو، کاربری، منطقه، سن، شغل) و فرمول (ضرب در سرمایه، ضرایب، تخفیف عدم خسارت، اضافه‌نرخ ریسک، حداقل حق بیمه، تسهیم زمانی برای مدت‌های غیر یک‌ساله).

الزامات غیرقابل‌مذاکره:

• تابع خالص و قطعی (deterministic). با ورودی یکسان و نسخه نرخ یکسان، همیشه خروجی یکسان. هیچ فراخوانی به «الان»، هیچ رندوم، هیچ خواندن مستقیم از پایگاه داده وسط محاسبه.
• نگهداری ورودی محاسبه روی بیمه‌نامه. نه فقط نتیجه، بلکه همه ورودی‌ها و شناسه نسخه نرخ باید روی نسخه بیمه‌نامه ذخیره شود. بدون این، محاسبه دو سال بعد در زمان اختلاف با بیمه‌گذار یا حسابرسی قابل بازتولید نیست.
• بازپخش (replay) به‌عنوان ابزار تست. هر نسخه جدید نرخ باید روی چند ده هزار بیمه‌نامه واقعی گذشته اجرا و اختلافش گزارش شود. این تنها راه فهمیدن اثر ناخواسته یک تغییر تعرفه است.
• گرد کردن با قاعده صریح. در چه مرحله‌ای گرد می‌شود، با چه دقتی، و جمع اجزا با کل چه می‌شود. اگر گرد کردن در سطح پوشش و در سطح بیمه‌نامه هر دو انجام شود، اختلاف چند ریالی تولید می‌شود که در تسویه اتکایی و کارمزد به مغایرت تبدیل می‌شود.

rate(riskAttributes, productVersion, rateVersion) → PremiumBreakdown

PremiumBreakdown {
  perCoverage: [{ coverageCode, basePremium, loadings[], discounts[], net }]
  netPremium
  statutoryCharges[]     // عوارض قانونی — حق بیمه نیست
  tax
  gross
  rateVersionId          // بدون این، محاسبه غیرقابل بازتولید است
  inputSnapshot          // عکس لحظه‌ای ورودی‌ها
}

نکته ایرانی: در شخص ثالث، اقلامی مثل سهم صندوق تأمین خسارت‌های بدنی و مالیات بر ارزش افزوده روی حق بیمه سوارند اما حق بیمه نیستند؛ در درآمد شرکت، در مبنای کارمزد و در مبنای اتکایی نباید بیایند. مخلوط کردن این‌ها با حق بیمه خطای رایجی است که تا صورت‌های مالی بالا می‌رود. درصدها و اقلام دقیق باید با آخرین بخشنامه راستی‌آزمایی شود.

---

۴. قواعد پذیرش و ارجاع (Underwriting)

چه می‌کند: تصمیم می‌گیرد که آیا این ریسک اصلاً پذیرفته می‌شود، خودکار یا با ارجاع به کارشناس.

چگونه: مجموعه‌ای از قواعد که خروجی‌شان یکی از سه حالت است: ACCEPT، REFER (ارجاع به سطح بالاتر با ذکر دلیل)، DECLINE. معیارها: سقف اختیارات نماینده، سرمایه بالای حد مجاز، سابقه خسارت، فهرست‌های محدودیت، ظرفیت باقی‌مانده قرارداد اتکایی.

تصمیم کلیدی: سقف اختیارات باید داده باشد نه کد — هرمی از سطوح (نماینده، شعبه، ستاد) که مدیر بتواند بدون انتشار نسخه جدید تغییرش دهد. و هر ارجاع باید ردپای کامل داشته باشد: چه کسی، چه زمانی، با چه دلیلی تأیید کرد.

---

۵. چرخه عمر بیمه‌نامه

اینجا جایی است که سیستم‌های ساده‌انگارانه می‌میرند.

Quote (پیش‌نویس/نرخ‌دهی)
  → Proposal (پیشنهاد)
  → Issued (صادرشده)  ──┬─→ Endorsement (الحاقیه)  → نسخه جدید
                        ├─→ Cancellation (ابطال)   → برگشت حق بیمه
                        ├─→ Renewal (تمدید)        → بیمه‌نامه جدید با پیوند به قبلی
                        └─→ Expired (انقضا)

الحاقیه فقط «ویرایش» نیست؛ انواع مختلف دارد و هر کدام سازوکار مالی متفاوت:

• الحاقیه افزایشی/کاهشی سرمایه یا پوشش → محاسبه حق بیمه اضافی یا برگشتی به‌نسبت مدت باقی‌مانده
• الحاقیه اصلاحی بدون اثر مالی (اصلاح نام، شماره پلاک)
• الحاقیه تغییر مدت
• الحاقیه انتقال مالکیت
• الحاقیه عطف‌به‌ماسبق — تاریخ اثر در گذشته است. این حالت است که مدل داده را تعیین می‌کند.

ابطال هم یک نوع نیست: ابطال از ابتدا (تمام حق بیمه برمی‌گردد) در برابر ابطال از تاریخ معین با کسر حق بیمه مدت گذشته، و هر رشته قاعده برگشت خودش را دارد (روزشمار یا جدول کوتاه‌مدت). این قواعد باید داده محصول باشند، نه شرط if در کد.

---

۶. مدل زمانی داده — تصمیم بنیادی

سیستم به دو محور زمان نیاز دارد:

• زمان کسب‌وکار: این واقعیت از چه تاریخی تا چه تاریخی معتبر است (effectiveFrom/To)
• زمان سیستم: این رکورد چه زمانی ثبت شد و چه زمانی جایگزین شد (recordedAt/supersededAt)

بدون محور دوم، این دو سؤال قابل پاسخ نیستند و هر دو در عمل پرسیده می‌شوند:

• «پوشش این بیمه‌نامه در تاریخ حادثه چه بود؟» → پرس‌وجو روی زمان کسب‌وکار
• «در پایان اسفند که تراز بستیم، سیستم چه چیزی نشان می‌داد؟» → پرس‌وجو روی زمان سیستم

مورد دوم برای حسابرسی و ذخیره‌گیری حیاتی است: الحاقیه‌ای که امروز با تاریخ اثر دی‌ماه ثبت می‌شود نباید ذخایر اسفند سال قبل را که قبلاً گزارش شده، عوض کند. باید بتوان هر دو تصویر را همزمان داشت.

پیامد عملی: جدول‌ها append-only هستند. هیچ حذف فیزیکی، هیچ به‌روزرسانی درجا. هر تغییر یک رکورد جدید با ارجاع به رکورد قبلی است.

---

۷. شماره‌گذاری، چاپ و اتصال به سنهاب

شماره بیمه‌نامه: معمولاً ترکیبی از کد شعبه، کد رشته، سال و سریال. باید تحت همزمانی یکتا بماند — یعنی از دنباله پایگاه داده یا قفل، نه از max(id)+1.

کد یکتای سنهاب: بیمه‌نامه پس از صدور باید در سنهاب ثبت شود و کد یکتا بگیرد. این یعنی صدور یک تراکنش توزیع‌شده با یک سامانه بیرونی است و باید طوری طراحی شود که:

• اگر سنهاب در دسترس نباشد، صدور در حالت «ثبت‌نشده» بماند و صف تلاش مجدد داشته باشد
• هرگز بیمه‌نامه دوباره ارسال نشود و کد یکتای تکراری تولید نکند (کلید تکرارناپذیری)
• وضعیت آشتی‌دهی (reconciliation) روزانه با سنهاب وجود داشته باشد

این دقیقاً همان نقطه‌ای است که در عمل باعث توقف سراسری فروش می‌شود؛ در معماری باید از اول به‌عنوان حالت خرابی محتمل دیده شود، نه استثنا.

چاپ: قالب چاپی هر رشته با شرایط عمومی و خصوصی، نسخه‌دار. نسخه چاپ‌شده باید بایگانی شود، نه اینکه هر بار از نو تولید شود — چون قالب و داده هر دو ممکن است بعداً عوض شوند.

---

۸. وصول، اقساط و تخصیص

چه می‌کند: حق بیمه را از بیمه‌گذار می‌گیرد و به بیمه‌نامه تخصیص می‌دهد.

سازوکار: جدول اقساط با سررسید، ثبت دریافتی‌ها (نقد، چک، درگاه، انتقال)، و تخصیص دریافتی به قسط. مسئله واقعی تخصیص است: یک واریز ممکن است چند بیمه‌نامه را پوشش دهد یا ناقص باشد.

قواعدی که باید داده باشند: مهلت پرداخت، اثر عدم پرداخت بر اعتبار پوشش (تعلیق یا ابطال)، جریمه تأخیر، ترتیب تخصیص (قدیمی‌ترین قسط اول؟ اصل قبل از جریمه؟).

---

۹. شبکه فروش و کارمزد

چه می‌کند: نماینده، کارگزار و بازاریاب را مدیریت و کارمزدشان را محاسبه و تسویه می‌کند.

سازوکار: سلسله‌مراتب شبکه (به‌ویژه در بیمه‌های زندگی که ساختار چندلایه دارد)، نرخ کارمزد به تفکیک رشته و پوشش، محاسبه در لحظه صدور، و برگشت کارمزد در صورت ابطال یا الحاقیه کاهشی. صورت‌حساب دوره‌ای هر نماینده و تسویه.

تله: کارمزد باید بر مبنای حق بیمه خالص محاسبه شود نه مبلغ کل پرداختی مشتری. اگر عوارض و مالیات وارد مبنا شوند، اضافه‌پرداخت سیستماتیک اتفاق می‌افتد که ماه‌ها بعد کشف می‌شود.

---

۱۰. خسارت

چرخه: اعلام حادثه (FNOL) → تشکیل پرونده → تعیین ذخیره اولیه → ارزیابی و کارشناسی → تأیید → پرداخت → بستن پرونده → احتمال بازگشایی → بازیافت.

نکات معماری:

• پرونده خسارت باید به نسخه‌ای از بیمه‌نامه که در تاریخ حادثه معتبر بوده وصل شود، نه به آخرین نسخه. این تنها کاربرد مدل زمانی بخش ۶ نیست، ولی مهم‌ترینش است.
• ذخیره خسارت معوق (Outstanding) یک عدد نیست، یک تاریخچه است. هر بار که کارشناس برآورد را تغییر می‌دهد یک ReserveMovement ثبت می‌شود. تحلیل توسعه خسارت (loss development) و محاسبه IBNR روی همین تاریخچه ساخته می‌شود؛ اگر فقط عدد آخر نگه داشته شود، این تحلیل برای همیشه از دست می‌رود.
• تخصیص خسارت به پوشش لازم است، نه فقط به بیمه‌نامه — چون سهم اتکایی و مصرف سقف پوشش در همان سطح محاسبه می‌شود.
• بازیافت و ورود ثالث (subrogation) جریان مالی معکوس دارد و باید به همان پرونده بچسبد.

---

۱۱. اتکایی

معمولاً دست‌کم‌گرفته‌شده‌ترین بخش در پروژه‌های داخلی.

چه می‌کند: بخشی از ریسک هر بیمه‌نامه را به بیمه‌گر اتکایی واگذار می‌کند و متناسب با آن، بخشی از حق بیمه و بخشی از خسارت را.

انواع قرارداد که هسته باید پشتیبانی کند:

• نسبی (Proportional): مشارکت (Quota Share) و مازاد سرمایه (Surplus) — درصد یا سهم مشخصی از هر ریسک واگذار می‌شود؛ حق بیمه و خسارت به همان نسبت تقسیم می‌شود.
• غیرنسبی (Non-Proportional): مازاد خسارت (Excess of Loss) — واگذاری بر اساس لایه خسارت است نه سرمایه؛ محاسبه در سطح رویداد انجام می‌شود، نه در سطح بیمه‌نامه. این دو منطق کاملاً متفاوت‌اند و نمی‌شود یکی را حالت خاص دیگری گرفت.
• اختیاری (Facultative): واگذاری تک‌ریسک با مذاکره جداگانه.

آنچه باید تولید شود: سهم واگذارشده هر ریسک (cession) در لحظه صدور، کارمزد اتکایی، صورت‌حساب دوره‌ای (bordereau) به تفکیک قرارداد و دوره، و سهم بیمه‌گر اتکایی از هر خسارت. همچنین ظرفیت باقی‌مانده هر قرارداد که باید در لحظه صدور در دسترس موتور پذیرش باشد.

---

۱۲. حسابداری فنی و ذخایر

اینجا هسته به صورت‌های مالی وصل می‌شود.

سازوکار پیشنهادی: هر رویداد فنی (صدور، الحاقیه، ابطال، وصول، ثبت ذخیره، پرداخت خسارت، واگذاری اتکایی) یک رویداد حسابداری تولید می‌کند که از طریق یک جدول نگاشت قابل پیکربندی به سند حسابداری تبدیل می‌شود. کد حساب نباید در کد برنامه hard-code شود.

ذخایر فنی الزامی بر اساس آیین‌نامه شماره ۵۸ شورای‌عالی بیمه — این‌ها خروجی‌های محاسباتی‌اند که هسته باید تولید کند:

پیامد معماری: چون ذخیره حق بیمه عاید نشده به تاریخ شروع و پایان هر بیمه‌نامه و ذخیره خسارت معوق به تاریخچه برآوردها وابسته است، هر دو فقط وقتی درست در می‌آیند که مدل زمانی بخش ۶ رعایت شده باشد. این‌ها گزارش نیستند، خروجی مستقیم مدل داده‌اند.

ارقام و ضرایب بالا از متن آیین‌نامه ۵۸ استخراج شده و باید با آخرین اصلاحیه‌ها راستی‌آزمایی شود.

---

۱۳. بیمه‌های زندگی — یک موتور جداگانه

بیمه زندگی حالت خاصی از بیمه غیرزندگی نیست؛ منطق مالی متفاوتی دارد و تلاش برای جا دادنش در همان موتور، معمولاً هر دو را خراب می‌کند:

• اندوخته و ارزش بازخرید در طول عمر قرارداد
• جدول مرگ‌ومیر و محاسبات اکچوئری
• سود مشارکت در منافع و تخصیص سالانه
• وام روی بیمه‌نامه
• قراردادهای بلندمدت با اقساط چندساله و امکان تعلیق و احیا

اگر رشته زندگی جزو دامنه است، بهتر است از ابتدا به‌عنوان موتور دوم با مدل داده مشترک در سطح شخص و قرارداد دیده شود.

---

۱۴. لایه‌های عرضی

این‌ها زیرسیستم نیستند اما اگر دیر به آن‌ها فکر شود، بازنویسی گسترده لازم می‌شود:

• تقویم جلالی. همه تاریخ‌های کسب‌وکار شمسی‌اند. ذخیره‌سازی باید یکنواخت باشد و تبدیل در لبه انجام شود. محاسبه روزشمار برای تسهیم حق بیمه باید بر مبنای تقویم شمسی و سال کبیسه درست باشد؛ خطای یک‌روزه اینجا مستقیماً به عدد پول تبدیل می‌شود.
• پول. ریال، عدد صحیح یا decimal — هرگز float. واحد نمایش (تومان) از واحد ذخیره‌سازی جدا باشد. قاعده گرد کردن واحد و مستند.
• همزمانی. شماره بیمه‌نامه، ظرفیت اتکایی و تخصیص وجه، همگی نقاط رقابت‌اند و به قفل یا دنباله اتمی نیاز دارند.
• ردپای ممیزی. هر تغییر: چه کسی، چه زمانی، چه مقداری از چه به چه. این الزام نظارتی است نه امکان رفاهی.
• دسترسی و تفکیک سازمانی. شعبه، نمایندگی و ستاد نباید داده هم را ببینند؛ این باید در لایه داده اعمال شود نه فقط در رابط کاربری.
• گزارش‌های نظارتی. فرم‌های ادواری بیمه مرکزی و الزامات افشا (آیین‌نامه ۸۸) باید از ابتدا به‌عنوان خروجی رسمی دیده شوند، نه گزارش موردی.

---

۱۵. یکپارچه‌سازی‌های بیرونی

قاعده طراحی: هیچ فراخوانی بیرونی نباید داخل تراکنش صدور باشد. استعلام‌ها قبل از تراکنش انجام و نتیجه‌شان روی پیش‌نویس ذخیره می‌شود؛ ثبت‌های پس از صدور به‌صورت ناهمگام با صف و تلاش مجدد. در غیر این صورت، کندی یک سرویس بیرونی کل صدور را قفل می‌کند.

---

۱۶. نقشه راه ساخت

ترتیبی که ریسک را زودتر آشکار می‌کند:

۱. ستون فقرات، نه یک رشته کامل. اول مدل زمانی، مدل دامنه، موتور نرخ و چرخه نسخه بیمه‌نامه — روی یک رشته ساده (حوادث انفرادی یا آتش‌سوزی مسکونی، نه شخص ثالث). ۲. الحاقیه و ابطال قبل از رشته دوم. اگر معماری اینجا نمی‌کشد، بهتر است با یک رشته بازنویسی شود نه با پنج رشته. ۳. رویدادهای حسابداری و ذخیره حق بیمه عاید نشده. اولین لحظه‌ای که می‌فهمید مدل داده درست است یا نه. ۴. خسارت با تاریخچه ذخیره. ۵. اتصال سنهاب با همه حالت‌های خرابی. ۶. اتکایی نسبی، بعد غیرنسبی. ۷. رشته‌های پرتیراژ و شبکه فروش. ۸. زندگی، اگر لازم است — به‌عنوان موتور جدا.

معماری پیشنهادی برای شروع: مونولیت ماژولار با مرزهای صریح بین زیرسیستم‌ها و ارتباط رویدادمحور داخلی. ریزسرویس از روز اول، در سیستمی که تراکنش‌های مالی چندموجودیتی دارد، هزینه‌اش را زودتر از فایده‌اش نشان می‌دهد.

---

۱۷. تله‌های شناخته‌شده

• ذخیره حق بیمه به‌صورت یک عدد واحد → اتکایی و کارمزد و گزارش نظارتی برای همیشه ناقص
• ویرایش درجای بیمه‌نامه صادرشده → الحاقیه عطف‌به‌ماسبق غیرممکن، حسابرسی غیرممکن
• وابستگی موتور نرخ به «تاریخ امروز» → محاسبه غیرقابل بازتولید
• ورود عوارض و مالیات به مبنای کارمزد و اتکایی
• نگهداری فقط آخرین برآورد ذخیره خسارت → از دست رفتن دائمی داده توسعه خسارت و IBNR
• فراخوانی همگام سنهاب داخل تراکنش صدور → توقف سراسری فروش با کندی یک سرویس بیرونی
• گرد کردن دولایه (پوشش و بیمه‌نامه) بدون قاعده صریح → مغایرت ریالی انباشته
• جا دادن بیمه زندگی در موتور غیرزندگی
• کد حساب و سقف اختیارات به‌صورت hard-code

---

پرسش‌های باز این یادداشت

• اقلام و درصدهای دقیق عوارض قانونی شخص ثالث و مبنای محاسبه کارمزد و اتکایی روی آن‌ها
• الزامات دقیق فرم‌های نظارتی ادواری بیمه مرکزی و دوره‌های ارسال
• مکانیزم رسمی استعلام سابقه و تخفیف عدم خسارت و شرایط دسترسی
• آیا آیین‌نامه ۵۸ اصلاحیه جدیدتری دارد که ضرایب بالا را تغییر داده باشد
• الزامات آیین‌نامه ۶۹ (توانگری مالی) که مستقیماً از خروجی هسته تغذیه می‌شود

---

منابع

• آیین‌نامه شماره ۵۸ — ذخایر فنی مؤسسات بیمه
• آیین‌نامه شماره ۶۹ — توانگری مالی مؤسسات بیمه
• آیین‌نامه شماره ۸۸ — گزارشگری و افشای اطلاعات
• آیین‌نامه شماره ۶۸ — بیمه‌های زندگی و مستمری
• فناوران اطلاعات خبره — سامانه جامع بیمه‌گری بنیان
• داتین — سامانه جامع بیمه‌گری چیست؟
• مصوبات شورای‌عالی بیمه