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, and other elements) 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
Reversal
Process
Policy transactions exhibit a workflow similar to the policy quotation process:
With underwriting flow:
Compared to quotes, the major difference with policy transactions is the addition of the initialized step. The transaction automatically enters this step when it is advanced, or when it is edited from draft state.
On creation, the transaction is in draft state and contains a set of change instructions, such as add a new coverage, remove an exposure, update data or coverage terms, etc. These are descriptors of how the existing policy data (as of the effective time of the new transaction) should be changed.
When initialized, the transaction will use the change instructions to materialize the segment for the revised coverage period. This includes creation of the new elements and setting the data extensions and coverage terms. At this point the segment data can be modified directly, much like quotes are modified when they are in draft state.
Edits to the segment data will also automatically generate updates or changes to the transaction’s change instructions, such that the collection of change instructions, when applied to the previous segment’s data, is guaranteed to produce the current segment data.
Transaction Reset
Like quotes, policy transactions that have advanced past draft state but are not yet issued, rejected, or discarded can be reset. For transactions, there is a choice between resetting to initialized state, or resetting to draft state.
The default is reset to initialized state, which will remove pricing, documents, and underwriting information (based on the ResetOptions), but will retain the segment data that was created based on its change instructions. This can be helpful if you want to retain the locators of newly created elements, as they won’t change based on the default reset action.
Alternatively, you can set the resetToDraft query parameter to true, and the segment data will be discarded. It will be regenerated when the transaction is edited or revalidated.