Policy Transactions
The Policy Transaction is the structure that the policy module uses to track policy changes, starting with issuance and any subsequent modifications, such as endorsement, renewal, cancellation, and reinstatement.
Structure
Policy transactions are independent. After validation, most of the important data on a transaction is immutable. This offers the following capabilities:
The state of the policy (including data, pricing, coverages, etc) as of a moment in time can be easily assessed: start at the most recently issued transaction and proceed down the transaction stack until you find the first transaction issued on or before the given time.
The state of the policy as of a certain effective time can be easily found: start at the most recently issued transaction and find the policy segment that spans the given effective time.
It is easy to answer questions like “what would the policy look like if this transaction were to be issued?”
The pricing “caused” by a transaction is easy to find: it’s stored in the transaction itself, for premium and any other relevant charge.
When reverting transactions (such as in reinstatements and transaction reversals), the data and prices for the policy will be restored to the exact values immediately before the reversed transaction, even in complex out-of-sequence cases.
See the Policy Transaction Stack topic for details about these and other cases.
Provisional Transactions
Like policy quotes, transactions are created in a provisional state starting with draft and advancing through intermediate steps for validation, pricing, underwriting, and other processes, and ultimately proceeding through issuance (or, potentially, invalidation and/or discard.)
Provisional transactions can be chained (for example, one prospective transaction can be based on an earlier transaction that hasn’t been issued yet.) Any number of transactions may be stacked in this way, provided that no transaction is based on a transaction with an earlier state. For example, a validated transaction can’t be based on a draft transaction.
Transactions can also be branched, allowing convenient side-by-side comparisons while ensuring only one branch can go on to be issued.
Basic Transactions
The following transactions are fundamental and will be included in the initial release of Socotra Enterprise Core:
Issuance
Policy Change
Renewal
Cancellation
Reinstatement
Advanced Transactions
These transactions implement advanced capabilities and will be delivered after the first release:
Reversal
Reinstatement with a Gap in Coverage
Re-Cancellation
Installment Plan Change
Withdrawal
Cancel-Rewrite
Withdraw-Rewrite
Temporary Coverage
Custom Aggregates
Coverage Pause / Restore
Non-Renew
Policy Start / End Time Adjustment
Process
Policy transactions exhibit a workflow identical to the policy quotation Process.