eBaoTech InsureMO

Vendor: eBaoTech · Enterprise

eBaoTech is a Shanghai-based insurance software vendor, founded in 2000, that reports business in more than 30 countries and over 300 insurance carriers as clients. It has two generations of product. The older generation is installed core systems - LifeSystem for life insurance, GeneralSystem for property and casualty, and GroupLife. The current generation is eBaoCloud InsureMO, launched globally in late 2017: a cloud insurance 'middle office' of more than 1,000 insurance APIs across policy, claims, billing, sales channel, party and other domains, on which insurers and partners build their own front ends and core systems. Life insurance on InsureMO is called Gemini. This entry documents InsureMO general insurance - new business and underwriting, policy servicing (endorsements), renewals, claims, and billing and collection - because that is the part with a public data model. On InsureMO there is no database to connect to: the vendor states that business object data can only be accessed through APIs, so every object and field named here is an API / JSON name, not a database table or column. The event history comes from policy revisions (a new revision on every save), the underwriting history records, the Activiti-based workflow tasks, and the billing, collection and payment objects, which carry the best timestamps. The installed LifeSystem and GeneralSystem suites and the Gemini life data model have no public data model, so they are NOT covered by the processes here; for those, ask the insurer for its data dictionary.

Change Management (CHANGE)

Change requests, approvals, implementation

Activities

Apply for Endorsement - Endorsement created on an issued policy: ApplyDate, EntryOperId, EndoType. Only one pending endorsement per policy.
Change Basic Information - EndoType basic information - usually IsAdminChange true (no premium effect).
Change Policy Period - EndoType period extend, shorten or move.
Cancel Policy - Cancellation endorsement; PolicyStatus becomes 3 Cancelled once issued.
Reinstate Policy - Reinstatement endorsement of a cancelled policy.
Save Endorsement Draft - EndoStatus 120 / 240 Issuing while the change is in progress; each save writes a Policy revision.
Issue Endorsement - EndoStatus 300 Issued; IssueDate; AfterRevisionId points to the new Policy revision.
Raise Endorsement Billing - BcpBizTransaction with BizTransType ENDORSEMENT for a financial change (BizTransTime).
Endorsement Takes Effect - EndoEffectiveDate - the date the change applies to cover. Can be before ApplyDate (back-dated).
Undo Endorsement - EndoStatus 401 Undo - an issued change reversed.

Case attributes

Endorsement Sub-Type (string) - SubEndoType.
Endorsement Type (string) - EndoType.
Is Admin Change (boolean) - IsAdminChange - administrative (non-financial) change.
Endorsement Effective Date (date) - EndoEffectiveDate.
Endorsement Id (string) - EndoId - the case id when the case is one endorsement.
Endorsement No (string) - EndoNo.
Policy No (string) - PolicyNo of the policy being changed.
Product Code (string) - ProductCode of the policy.
Entered By (string) - EntryOperId - who entered the endorsement.
After Revision Id (string) - AfterRevisionId.
Before Revision Id (string) - BeforeRevisionId.
Endorsement Status (string) - EndoStatus; labels may be overridden per insurer.

Process-mining benefits (historical)

Which changes customers actually ask for [Efficiency]: Count endorsements per policy by type and product. A few change types usually drive most of the servicing work, and they are the ones to simplify or move to self-service.
Changes issued and then undone [Efficiency]: Measure how often an issued endorsement is undone, by type and by who entered it. Every undo is a change done twice and often a premium re-billed.
Real time from request to issued change [Service]: Measure apply-to-issue time per endorsement type. Because only one endorsement can be pending per policy, a slow one blocks every other change on that policy.
How much is back-dated [Compliance]: Find changes whose effective date is earlier than the date they were requested, by type and channel. Back-dated cancellations and period changes carry refund and claims exposure.
Administrative versus financial servicing load [Cost]: Split servicing volume into administrative changes and changes that move premium, to size where staff time goes and what could be automated.
Why and when policies are cancelled [Cash]: Look at cancellations by product, channel and time since issue. Early cancellations point to sales or pricing problems; they also return premium.

Process-mining benefits (action)

Clear pending endorsements before they block others [Service]: Alert when an endorsement has been applied for but not issued within the target days, since it blocks any other change on that policy.
Review every undo [Compliance]: Send each undone endorsement to a short review queue to fix the cause - wrong type chosen, missing information, or a training gap.
Approve back-dated cancellations explicitly [Cash]: Route cancellations whose effective date is before the request date to an approver before issue, because they create refunds.
Catch cancel-and-reinstate churn [Service]: Flag policies reinstated soon after cancellation; they usually mean a missed payment or a wrong cancellation that could have been avoided.
Make sure financial changes are billed [Cash]: Flag non-administrative endorsements issued with no billing transaction, which is premium the insurer is owed and not collecting.
Move simple changes to self-service [Cost]: Use the volume and handling time of basic information changes to justify a portal or agent self-service flow.

Data tables

BcpBizTransaction - Root of every money movement, immutable. One row per business transaction from policy administration, claims or finance. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Endorsement - A change to a policy after issue. Only one pending endorsement per policy at a time. Types seen in the docs: basic information, cancellation, reinstatement, period extend / shorten / move, undo. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy - The InsureMO general insurance policy object. Quotation, proposal and policy are ONE object that moves from quote to issued policy; PolicyStatus also sits on each risk and cover. Read with the policy query and load APIs. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy revision - A new revision is written on every save of a policy, 'meeting the Audit Trail requirements'. getPolicyRevisions lists them and loadPolicyAtRevision returns the policy as it was; compare two revisions with a JSON diff. The policy record itself keeps no status history, so THIS is where status changes over time come from. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Workflow task - Tasks of the InsureMO workflow engine (Activiti 8, BPMN 2.0, run as a microservice). Process instances are started and tasks completed by API; /workflow/v1/tasks and /workflow/v1/tasks/byBusinessKey find them per case. Sample BPMN exists for proposal and endorsement workflows. Whether an insurer can read completed-task history (not only open tasks) on InsureMO is not stated publicly - confirm. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy export - /proposal/core/proposal/v1/exportPolicy (real time) and asyncExport (large volumes): Excel export of indexed policy fields. No revision history.
Policy other info - Non-versioned extras kept beside the policy, such as print history. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
EndorsementStatus (code table) - EndoStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns. An insurer may override them; only Issued is fixed.
PolicyStatus (code table) - PolicyStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns. 'Expired' is deprecated and not set automatically - a policy past its expiry date still shows Effective.

Insurance Claims (CLAIMS-INS)

Insurance claim processing. Covers FNOL, investigation, adjustment, and settlement.

Activities

Report FNOL - First notice of loss - always present; FNOL submit webhook event.
Register Claim - Registration task - always present; registration webhook event.
Assign Claim Task - Task assigned from a pool, manually or automatically (workload, authority, work time); task assigned webhook event.
Investigate Claim - Investigation task - optional per product.
Appraise Loss - Appraisal task - optional per product.
Approve Appraisal - Appraisal approval task.
Collect Claim Documents - Document task - optional per product.
Calculate Claim - Calculation task - optional per product.
Approve Calculation - Calculation approval task.
Settle Claim - Settlement task - always present; settlement webhook event. Creates a payable in BcpArap.
Approve Settlement - Settlement approval task, within claim authority limits.
Approve Claim Payment - BcpPayment PaymentStatus 2 Approved; ApproveTime, ApproveBy.
Pay Claim - BcpPayment PaymentStatus 3 Paid; CompleteTime.
Reverse Claim Payment - BcpPayment PaymentStatus 5 Reversed; BcpReverse ReverseTime and ReverseReason.
Flag Task Overdue - Task overdue webhook event / trigger - a task passed its due time.
Create Diary Task - Diary (follow-up) task on the claim.
Reopen Claim - A closed claim reopened.
Close Claim - Claim closed after final payment.

Case attributes

Catastrophe Code (string) - Catastrophe code. Screen label; confirm the API name.
Claim Mode (string) - 'Claim' or 'Subclaim'.
Task Saved At (datetime) - SaveTime on the Workflow task result.
Payable Amount (decimal) - Amount on the claim payable in BcpArap.
Claim Number (string) - Claim number. Screen label; the Claim API field name is behind the portal login - confirm in the customer's tenant.
Payment Id (string) - PaymentId on BcpPayment.
Policy No (string) - PolicyNo on the claim's BcpBizTransaction (BizTransType CLAIM).
Payee (string) - PayerPayeeCode on BcpPayment.
Assignment Method (string) - Pool, manual or automatic. Screen label; confirm the API name.
Product Code (string) - ProductCode of the policy - decides which optional claim tasks are on.
Approved By (string) - ApproveBy on BcpPayment.
Payment Status (string) - PaymentStatus 2 Approved, 3 Paid, 5 Reversed.

Process-mining benefits (historical)

True claim cycle time from first notice to payment [Service]: Measure every claim from first notice to money paid, by product and claim mode, and see which step holds the long tail.
Time spent waiting for approvals [Efficiency]: Separate time spent doing work from time spent waiting for appraisal, calculation and settlement approvals.
Delay between settlement and payment [Cash]: Measure how long an agreed settlement takes to become money in the claimant's account.
Reopened claims [Cost]: Count reopened claims and what they cost in extra payments and handling, by product and handler.
Payments approved inside authority [Compliance]: Check each payment's approver against the claim authority limits configured for the product.
Reversed payments [Cost]: Count and value reversed claim payments and their reasons - each is rework and a possible leakage or fraud signal.

Process-mining benefits (action)

Add history to the overdue alert [Service]: InsureMO already triggers 'task overdue'. Add the case history so the handler sees how long the claim has waited in total and where.
Pay what has been approved [Cash]: Alert finance when a claim payment is approved but not paid after N days.
Balance assignment on real workload [Efficiency]: Use observed handling time per task type to set automatic assignment rules, rather than counting open tasks only.
Fast-track simple claims [Efficiency]: Identify claim types that settle without investigation or appraisal and route new ones straight to calculation.
Review reopen-and-pay cases [Cost]: Send claims that are reopened and paid again to a second review before the second payment.
Review every payment reversal [Compliance]: Route each reversed claim payment to a review queue to fix the cause and check for fraud.

Data tables

BcpArap - Receivable or payable. The case for premium collection (receivable) and for claim payment (payable). API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpBizTransaction - Root of every money movement, immutable. One row per business transaction from policy administration, claims or finance. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpPayment - Money out: claim payments and refunds. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Claim - The InsureMO claim, in claim mode 'Claim' or 'Subclaim'. Its tasks (FNOL, Registration, Investigation, Appraisal, Document, Calculation, Settlement and their approvals) are documented, but its FIELD names (report time, loss time, claim status) are behind the InsureMO portal login and are not public - confirm the API names in the customer's tenant. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Workflow task - Tasks of the InsureMO workflow engine (Activiti 8, BPMN 2.0, run as a microservice). Process instances are started and tasks completed by API; /workflow/v1/tasks and /workflow/v1/tasks/byBusinessKey find them per case. Sample BPMN exists for proposal and endorsement workflows. Whether an insurer can read completed-task history (not only open tasks) on InsureMO is not stated publicly - confirm. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BCP export - /bcp-core/core/export/v1/exportArap, exportReceipt, exportPayment, exportAppOffset and asyncExport: Excel exports of receivables, receipts, payments and offsets, backed by the bcp_arap search index.
BcpReverse - Reversal record for a collection, offset or payment. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Claim webhook events - Events InsureMO can push for claims: FNOL submit, registration, settlement, task assigned, task overdue. Event names are screen labels from the Claim API guide.
BCP status codes (code table) - Billing status code values printed in the BCP Core Data Model. The 'columns' below are CODE VALUES, named field.code, not database columns.

Invoice-to-Cash (I2C)

The billing and collections process focused on converting invoices to cash. Emphasizes invoice delivery, payment collection, and cash application.

Activities

Record Business Transaction - BcpBizTransaction created (NEWBIZ, ENDORSEMENT, CLAIM...): BizTransTime. Immutable root of the money trail.
Raise Receivable - BcpArap with ArapCate 1 receivable, ArapStatus 1 Outstanding, DueDate.
Receive Premium - BcpCollection CollectionStatus 1 Collected; ReceiveTime (business, can be back-dated) and SystemReceiveTime.
Confirm Receipt - BcpCollection CollectionStatus 2 Confirmed; ConfirmTime.
Park in Suspense - Money not matched to a receivable is held in BcpSuspense.
Apply Receipt to Receivable - BcpOffset OffsetType 2 application; OffsetTime.
Offset Receivable and Payable - BcpOffset OffsetType 1 offset - a receivable netted against a payable.
Apply Tolerance - BcpOffset OffsetType 3 tolerance - a small difference accepted.
Write Off Balance - BcpOffset OffsetType 4 write-off.
Settle Receivable - BcpArap ArapStatus 2 Settled.
Cancel Receivable - BcpArap ArapStatus 7 Cancelled.
Reverse Collection - BcpCollection CollectionStatus 3 Reversed; ReverseTime; BcpReverse with ReverseReason and ReverseBy.
Reverse Offset - BcpOffset OffsetStatus 2 Reversed.
Refund Premium - BcpCollection CollectionStatus 4 Refund, paid out through BcpPayment.

Case attributes

Channel Code (string) - ChannelCode.
Due Date (date) - DueDate on BcpArap.
System Receive Time (datetime) - SystemReceiveTime - the system clock copy of ReceiveTime.
Amount (decimal) - Amount on BcpArap.
Balance (decimal) - Balance on BcpArap.
Arap Id (string) - ArapId - the case id: one receivable from due to settled.
Biz Trans Id (string) - BizTransId.
Policy No (string) - PolicyNo on BcpBizTransaction - the link to the policy.
Receipt No (string) - ReceiptNo on BcpCollection.
Payment Method (string) - PaymentMethod on BcpCollection.
Last Operated By (string) - LastOperateBy on BcpCollection.
Arap Category (string) - ArapCate: 1 receivable, 2 payable.
Biz Module (string) - BizModule: PA, Claim, Finance.
Biz Trans Type (string) - BizTransType: NEWBIZ, ENDORSEMENT, CLAIM ...

Process-mining benefits (historical)

Days premium outstanding, per receivable [Cash]: Measure due date to money received for every receivable, by channel, product and payment method, instead of an aged-debt snapshot.
Back-dated receipts [Compliance]: Compare the business receive time with the system clock time. The InsureMO docs themselves point at this; clusters near month end are a control finding.
Money parked in suspense [Cash]: Measure how much cash sits unapplied and for how long before it is matched to a receivable.
Leakage through write-offs and tolerances [Cost]: Total the premium written off or accepted as tolerance, by channel and product, and see which ones generate it.
Reversal rework [Efficiency]: Count collections and offsets reversed and redone, and who did them, to find where cash application goes wrong.
Receipt to confirmation lag [Efficiency]: Measure how long received money waits before it is confirmed, which delays settlement and reporting.

Process-mining benefits (action)

Chase overdue premium early [Cash]: Alert collections when a receivable passes its due date with nothing received, ranked by amount.
Flag back-dated receipts as they happen [Compliance]: Alert finance control when a receipt is back-dated by more than N days, especially near period end.
Clear old suspense [Cash]: List suspense items older than N days for matching or refund.
Approve large write-offs first [Cost]: Route write-offs above a threshold to an approver before they are posted.
Coach the operators behind repeat reversals [Compliance]: Flag operators with a high reversal rate for coaching or a process fix.
Steer customers to the payment methods that pay on time [Service]: Use observed due-to-received time per payment method and channel to push slow segments to direct debit or auto-pay.

Data tables

BcpArap - Receivable or payable. The case for premium collection (receivable) and for claim payment (payable). API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpBizTransaction - Root of every money movement, immutable. One row per business transaction from policy administration, claims or finance. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpCollection - Money in. Carries business times AND separate system-clock copies, so back-dating can be measured. The docs advise using LastOperateTime, not UpdateTime, for business activity. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpOffset - Matching of receivables and payables: offset, application of a receipt, tolerance or write-off. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpPayment - Money out: claim payments and refunds. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BCP export - /bcp-core/core/export/v1/exportArap, exportReceipt, exportPayment, exportAppOffset and asyncExport: Excel exports of receivables, receipts, payments and offsets, backed by the bcp_arap search index.
BcpFee - Fee lines of a business transaction; feeds the general ledger. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpReverse - Reversal record for a collection, offset or payment. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BcpSuspense - Money received but not yet applied (parked). API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
BCP status codes (code table) - Billing status code values printed in the BCP Core Data Model. The 'columns' below are CODE VALUES, named field.code, not database columns.

Renewal Management (RENEWAL)

Subscription and contract renewal process. Covers renewal identification, outreach, negotiation, and processing.

Activities

Select Policies Due for Renewal - queryPolicyForRenewal returns policies by ExpiryDate range - the start of a renewal run.
Create Renewal Proposal - Renewal proposal created from the expiring policy, manually or in batch; new ProposalNo.
Quote Renewal Terms - QuotationDate on the renewal proposal.
Issue Renewal Policy - Renewal proposal reaches ProposalStatus 3 Issued.
Policy Expires - ExpiryDate passes. NOT a status - InsureMO leaves PolicyStatus at 2 Effective, so derive it from the date.
Renewal Lapsed - Derived: the policy expired with no issued renewal.

Case attributes

Channel Code (string) - ChannelCode from BcpBizTransaction - the sales channel.
Effective Date (date) - EffectiveDate of the renewal.
Expiry Date (date) - ExpiryDate of the expiring policy.
Terminate Date (date) - TerminateDate.
Policy No (string) - PolicyNo of the expiring policy - the case id.
Renewal Proposal No (string) - ProposalNo of the renewal proposal.
Renewal Creation Mode (string) - Manual or batch. Screen label in the renewal guide; confirm the API field in the customer's tenant.
Product Code (string) - ProductCode.
Policy Status (string) - PolicyStatus of the expiring policy (stays Effective past expiry).
Proposal Status (string) - ProposalStatus of the renewal proposal.

Process-mining benefits (historical)

True renewal retention by product and channel [Cash]: Count renewals issued against policies that lapsed, by product and channel, from the policies themselves rather than a sales report.
How early renewals are prepared [Service]: Measure how many days before expiry the renewal proposal is created. Late renewal offers lose customers who have already shopped around.
Policies that lapsed without ever being offered a renewal [Cash]: Find expired policies with no renewal proposal at all. They were lost by the process, not by the customer.
Gaps in cover [Compliance]: Find renewals issued after the old policy expired - the customer had no cover in between.
Batch versus manual renewal speed [Efficiency]: Compare the time from selection to issue for batch and manual renewals, to see what the batch run saves and where it falls back to people.
Policies that look live but are not [Compliance]: Count policies past their expiry date still shown as Effective, because InsureMO does not set Expired automatically. Reports that count 'active' policies overstate the book.

Process-mining benefits (action)

Offer a renewal before it is too late [Cash]: Alert when a policy is within N days of expiry and has no renewal proposal.
Follow up on unanswered renewal quotes [Service]: Alert the agent when a renewal quote has had no response within N days of expiry.
Prevent gaps in cover [Compliance]: Flag renewals that cannot be issued before the expiry date so they are handled first.
Target retention work where it pays [Service]: Put retention effort into the channels and products with the lowest renewal rate.
Fix the batch run's misses [Efficiency]: List policies the batch selected but never turned into a renewal proposal, and fix the rule or data that dropped them.
Report expiry from the date, not the status [Compliance]: Derive expiry from ExpiryDate in every report and dashboard so the in-force count is right.

Data tables

Policy - The InsureMO general insurance policy object. Quotation, proposal and policy are ONE object that moves from quote to issued policy; PolicyStatus also sits on each risk and cover. Read with the policy query and load APIs. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy revision - A new revision is written on every save of a policy, 'meeting the Audit Trail requirements'. getPolicyRevisions lists them and loadPolicyAtRevision returns the policy as it was; compare two revisions with a JSON diff. The policy record itself keeps no status history, so THIS is where status changes over time come from. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy export - /proposal/core/proposal/v1/exportPolicy (real time) and asyncExport (large volumes): Excel export of indexed policy fields. No revision history.
Renewal policy query - queryPolicyForRenewal: returns policies by expiry date range, the starting set for manual or batch renewal. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
PolicyStatus (code table) - PolicyStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns. 'Expired' is deprecated and not set automatically - a policy past its expiry date still shows Effective.
ProposalStatus (code table) - ProposalStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns. An insurer may override these values; only Issued (3) is fixed.
PaaS query export - The PaaS query screen's 'Export All' to Excel - the no-code, business-user route to a policy list today. The same area shows 'average issuance efficiency from creation to insurance'.

Underwriting (UNDERWRITING)

Risk assessment and pricing. Covers application review, risk analysis, and quote generation.

Activities

Create Quotation - Policy object created in ProposalStatus 10 Quotation In Progress. Timestamp: QuotationDate / FirstDataEntryDate on Policy.
Enter Proposal - ProposalStatus 1 Entry; ProposalDate on Policy. Each save writes a Policy revision.
Run Automatic Underwriting - Automatic underwriting rules run: UwStatus 3 pass or 6 fail, UwTime in Underwriting history.
Refer to Manual Underwriting - Automatic underwriting did not pass; ProposalStatus 5 Underwriting and a manual record opens (StartTime).
Send to Higher Underwriting Level - Manual decision 2 - escalated up the approval track (CurUwLevelCode / MaxUwLevelCode).
Send Back for Modification - Manual decision 3 - returned to the proposal for changes. A rework loop.
Approve Underwriting - Manual decision 1 pass; CompleteTime on the Underwriting history record.
Decline for Issuance - Manual decision 4 - the proposal will not be issued.
Wait for Payment - ProposalStatus 6 Waiting For Payment, read from the Policy revision history.
Bind Policy - ProposalStatus 2 Bound.
Issue Policy - ProposalStatus 3 Issued (the one value an insurer cannot override); PolicyNo assigned, PolicyStatus set.
Reject Proposal - ProposalStatus 4 Rejected - end of a lost case.
Print Policy Document - Policy other info LastPrintDate and PrintCount.

Case attributes

Channel Code (string) - ChannelCode from BcpBizTransaction (NEWBIZ) for the policy - the sales channel.
Effective Date (date) - EffectiveDate - cover start.
Expiry Date (date) - ExpiryDate - cover end.
Policy Id (string) - PolicyId - the case id from quote to issued policy.
Policy No (string) - PolicyNo, set at issue; links to the BCP billing objects.
Proposal No (string) - ProposalNo.
Quotation No (string) - QuotationNo.
Product Code (string) - ProductCode - the insurance product.
Proposal Status (string) - ProposalStatus at the latest revision; read labels from the customer's dictionary.
Current UW Level (string) - CurUwLevelCode.
Max UW Level (string) - MaxUwLevelCode.
Underwriting Decision (string) - UwDecisionType of the last manual decision.

Process-mining benefits (historical)

True quote-to-issue time, not one average [Efficiency]: InsureMO's own dashboard shows a single 'average issuance efficiency'. Rebuilding every case from its revisions shows the full distribution per product and channel, and where the long tail waits.
How much business is really straight-through [Cost]: Measure the share of proposals that pass automatic underwriting and go straight to bind, against those that need a person. That is the baseline for any automation case.
Underwriting send-back loops [Efficiency]: Find proposals returned for modification more than once and which products and channels cause them. A status report shows 'Underwriting' either way; the event log shows the loops.
How far cases climb the authority ladder [Compliance]: See how often cases escalate and how many levels they climb, by product and size, to judge whether authority limits are set where the risk actually is.
Time lost waiting for the first premium [Cash]: Measure how long underwritten proposals sit before payment arrives and the policy binds. This is cash and conversion lost after the hard work is done.
Where declined and rejected business comes from [Service]: Rank declines and rejections by channel and product, and how long each case ran before it ended, to stop spending underwriting time on business that will not issue.

Process-mining benefits (action)

Chase proposals stuck waiting for payment [Cash]: Alert the channel when an approved proposal has waited for payment longer than the agreed number of days, before the customer buys elsewhere.
Flag manual underwriting that has gone quiet [Service]: Alert a team lead when a referred case has no decision after the target time, so service levels are kept before the broker calls.
Stop the second send-back [Efficiency]: When a proposal comes back a second time, route it to a checklist or a senior underwriter instead of another round trip.
Tune the automatic underwriting rules [Cost]: Cases that are referred and then approved at the first level without change are candidates for an automatic pass; feed them back to the rule owners.
Check that bound policies are issued [Compliance]: Flag policies bound but not issued within the agreed days - cover may be promised without a policy document.
Confirm approvals sit at the right authority level [Compliance]: Compare the level that approved with the level the track required, and flag approvals below it. Confirm what the level codes mean in the customer's configuration first.

Data tables

Policy - The InsureMO general insurance policy object. Quotation, proposal and policy are ONE object that moves from quote to issued policy; PolicyStatus also sits on each risk and cover. Read with the policy query and load APIs. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy revision - A new revision is written on every save of a policy, 'meeting the Audit Trail requirements'. getPolicyRevisions lists them and loadPolicyAtRevision returns the policy as it was; compare two revisions with a JSON diff. The policy record itself keeps no status history, so THIS is where status changes over time come from. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Underwriting history - Automatic and manual underwriting records with an approval track per level, returned by /proposal/v1/underwriting/queryByPage. The object name is not printed in the public docs; the fields are. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Workflow task - Tasks of the InsureMO workflow engine (Activiti 8, BPMN 2.0, run as a microservice). Process instances are started and tasks completed by API; /workflow/v1/tasks and /workflow/v1/tasks/byBusinessKey find them per case. Sample BPMN exists for proposal and endorsement workflows. Whether an insurer can read completed-task history (not only open tasks) on InsureMO is not stated publicly - confirm. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
Policy export - /proposal/core/proposal/v1/exportPolicy (real time) and asyncExport (large volumes): Excel export of indexed policy fields. No revision history.
Policy other info - Non-versioned extras kept beside the policy, such as print history. API / JSON name from the InsureMO developer docs, NOT a database table - InsureMO business data is reachable only through APIs.
ManualUnderwritingResult (code table) - Manual underwriting decision code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns.
PolicyStatus (code table) - PolicyStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns. 'Expired' is deprecated and not set automatically - a policy past its expiry date still shows Effective.
ProposalStatus (code table) - ProposalStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns. An insurer may override these values; only Issued (3) is fixed.
UnderwritingStatus (code table) - UwStatus code values printed in the InsureMO docs. The 'columns' below are CODE VALUES, not database columns.
PaaS query export - The PaaS query screen's 'Export All' to Excel - the no-code, business-user route to a policy list today. The same area shows 'average issuance efficiency from creation to insurance'.

Explore this interactively in the mindzie Knowledge Base.