Premium vocabulary — the words a premium request arrives in, and the column each one means

What this page is. A configuration or pricing request arrives in premium words — „минимална премия", „вдигни отстъпката", „защо е тази премия", „възстановяване при прекратяване", „вноските да са 4" — and the estate answers in columns. This page is the mapping, taken from the premium specification the Product Configurator is built against: Premium P&C V1.1 (the source .docx lives in the untracked tmp/; the tracked extract is the citable copy). It is the premium counterpart of Shared vocabulary, which governs the code space; this page governs the premium terms.

How to read the F here. Every F states what the specification says. The specification is design intent and is known to contradict the live database — Schema Quirks § 8 records two such places and states the rule this page inherits: take the words from it, and verify every column, flag value and default with one read before configuring or writing. The short business definitions also live in Glossary § Premium vocabulary; this page carries the whole set with what decides each one.

1. The words

F The document defines the terms below. The amount the policy administration system computes is the gross written premium — net written premium is a reinsurance-side figure the module never produces.

F NCB combines with payment frequency and cross-selling discounts only — the specification excludes every other discount when the policy holder takes NCB.

2. Base premium — the rate, its kind, and what it is applied to

F Premium is calculated per cover, because the factors differ per cover. Which factors sit inside the base premium and which are discounts or loadings on top of it differs per company for the same cover — the split is a product decision, not a platform one. The document's own example: the base premium may absorb annual mileage and engine size, while driver age, driving record and location stay as loadings.

F The worked Casco example. A grid on annual mileage × engine power gives 6.5 % for a 306 HP car doing 20 000 km; the market value of 20 000 EUR is the insured value; base premium = 20 000 × 6.5 / 100 = 1 300 EUR. Appendix A of the extract carries Bulstrad's own bonus-Casco grids — car type, age, seats, tonnage — which is the shape CF-04 refreshes.

F What the rating service writes for a base premium: one row per cover in POL_PREM_RATE, with PREM_TYPE='BASEPREM', PREM_CODE='BP', RATE, RATE_DIM, AMNT, CURRENCY, VALID_FROM/VALID_TO taken from the cover, and CURRENCY_RATE read at the valid-from date. Policy currency is the currency of the object's insured value (POL_OBJECT_VALUES, PRM_CODE='IV'); a lump-sum rate keeps the rate's own currency. Its defaults are SELECTED='Y', CHANGEABLE='N', SEPARATE_ACCOUNT='N', NCB='N', FINST='N' — FINST marks an item payable with the first instalment.

3. Loadings, discounts, taxes and fees

F All of them are held as separate rows, never folded into the base premium, and the way and the order of application are defined per product. The forms the specification allows:

F The worked example applies them multiplicatively, then adds the fixed items: written premium = 1 300 × 0.9 (driving record) × 1.05 (driver age) × 1.3 (driving area) × 0.9 (parking) = 1 437; then 10 EUR stamp tax (non-refundable, first instalment) + 20 EUR policy fee (refundable, first instalment) + 2 % premium tax on the policy premium (spread) → 1 495.74. Every non-BASEPREM row in POL_PREM_RATE is inserted by the Offering service.

P So a request that says „add a discount" is under-specified until four things are known: its form, its base, its place in the order, and whether it is refundable. Stage S2 — Abacus owns the first three through the specification's ld section; the fourth belongs with the tax and fee rows, which is CF-06's recurring hole — the same rule lives in three systems.

4. Cancellation: the write-off and the refund are two different numbers

F On termination the insurer keeps the earned premium and returns the unearned. Two values are calculated from two different bases — this is the most consequential distinction on the page:

F The worked example — a 1 495.74 annual premium, cancelled after five of twelve months, two of four instalments paid, 10 EUR non-refundable stamp tax, 20 EUR refundable policy fee: proportional-daily gives a write-off of 868.71 and a refund of 132.50 (120.80 on the paid premium over its 30 unearned paid days, plus 11.70 of the fee over 214 unearned days); proportional-monthly gives 866.68 and 133.81; short rates give a write-off of 585.74 and a refund of nothing at all.

F The methods. A whole-policy cancellation uses proportional monthly, proportional daily, or short rates; a mid-term policy change uses proportional monthly or daily only. Each method needs the same five periods: earned, unearned, policy duration, unearned paid, and paid — the last two measured to the next due date, which is why an unpaid instalment changes a refund but not a write-off.

F Short rates always cut the refund on early cancellation and raise the premium for a sub-annual purchase. Two forms: a table method (a premium per period — 1 month 200, 3 months 600, 6 months 800, 12 months 1 200 — used where products are sold for short periods: travel, short-period MTPL) and a pro-rata method (proportional, reduced by a set proportion such as 10 %).

F Seasonal premium is used where the risk differs by season — boats, snowboards, holiday homes. Two approaches: different rates per period, or a flat premium that is not earned proportionally. The periods sit on the object (POL_OBJECT_VALUES) and may affect all covers or some; seasonal periods are predefined and can load automatically, while a "not using the vehicle" declaration is entered by the policy holder. Both change the write-off in later annexes.

F Renewal premium is normally higher because rates change annually. A jurisdiction may cap the increase — a percentage and an absolute cap — but the cap does not apply when the increase comes from a risk change the customer caused. So the algorithm must establish why the premium rose before it applies any cap.

5. The four services, the three tables, and the annex words

F The specification names one service per artefact, and one that prepares an annex:

F The annex vocabulary is read off POL_COVERS: a new cover has SELECTED='Y' and no PREV_COVER_ID; a discontinued cover has SELECTED='N' with a selected predecessor; a changed cover has SELECTED='Y', a predecessor, and COVER_SUBSTATUS='CHANGED' — set by any update to the object's values, the cover definition or its benefits. A new cover is priced like a policy premium from the annex's begin date; a discontinued one is written off row by row except the non-refundable rows.

F Rounding is a choice, not a rule: a calculation may be kept unrounded (for items that never reach the policy), or rounded at the end of a phase — base premium, loadings and discounts, taxes — with the rounding difference pushed into one of the premium items, never into a tax or fee. In the payment plan the difference goes to the first or the last instalment.

6. What this leaves open — and who has to decide it

F The specification itself names six choices as customisable plugins, with the options it expects:

P Read against this module, the six split in two. The first three and the fourth are per-product settings a configuration request can carry, and they belong to the specification S1 normalises — an ld section that does not say sum or multiply is incomplete, and S2 cannot prove a premium without it. The last two are code: a tax rule or a post-annex plan that the out-of-the-box one does not cover is a Development item at the plugin seam (Development module § PL-1, the shape of DV-04), not a row anyone can configure.

C The premium-algorithm choices have no owner in the twelve parts. Part 5 carries the tariff and the LD rows and part 8 the INSIS conditions and taxes (Configuration Module § 7.1), but nothing in the parts menu or in the ownership table names the write-off method, the short-rate table, the rounding policy, the loading/discount application order, or the payment-plan rule after an annex — and a product configured without them prices correctly on day one and refunds wrongly on the first cancellation. Suggested rule: make the four settable choices an explicit part — a premium_rules section of the specification with a value per product, asserted by S2's quote verification against a cancellation and a mid-term change, not only against a new-business quote.

F The two defects recorded on 02.09.2026 survive in V1.1. The base-premium default is still CHANGEABLE='N', where every base-premium row the estate has written is changeable — the property the manual-premium path depends on; and the field mapping still omits REFUNDABLE and MANUALLY_CORRECTED, the two columns the manual-premium rule reads (Schema Quirks § 8).

P Which is why the vocabulary is adopted and the mapping is not: a term from this page can be used in a plan, a customer reply or a specification; a column, a default or a flag value from it is a claim to confirm with one read against the target environment first — and where the estate disagrees, the estate wins and the disagreement is recorded in Schema Quirks.