A Policy's State Is Not Written in a Column

In one line

The state of an insurance policy is not a value stored somewhere but a value recomputed every time from the payment history and the as-of date, and so the status column and the facts always drift apart.

Why this was needed

In your first week at an insurer, you get a request like this: "I think this policy was not processed as lapsed. Could you take a look?"

You look at the logs. No errors. The nightly batch also finished successfully. When you open the table, the status column holds 정상 (the Korean word for "normal"). The system is saying it did everything it was told to do, yet the person in charge says it is wrong.

The reason you get stuck here is not technology. It is that you do not know what "lapse" means. If you know what the word means, where to look is settled in five seconds, and if you do not, you spend a day in the logs.

How it works

An insurance policy flows through this sequence.

청약 → 인수(언더라이팅) → 성립 → 유지(납입) → 실효 → 부활 → 해지 / 만기

The first three are events that people decide, and most of the later ones are decided by time. This difference shapes the data.

Application is the state in which the customer has applied to join. It is not yet a policy. Here the customer owes the duty of disclosure — the illnesses they have had so far, the medicines they are taking, their occupation, and so on.

Underwriting is the procedure by which the company decides whether to accept that risk. The result is one of four. Accepted as a standard risk, accepted with a premium surcharge, accepted with an exclusion of particular body parts or diseases, or declined. "Rejected at application underwriting" means it was declined at this stage.

Inception is the point at which the first premium comes in and the company accepts. Coverage starts from this point.

In force is the stretch in which the premium is paid each installment, and two dates matter here. The premium due date and the grace period. Even if you fail to pay on the due date, the policy is not cut off at once; the company waits for a set period.

Lapse is the first trap of this course. Lapse is not an event that happens. No table has a record saying "this policy lapsed." All there is is one unpaid installment and the grace rule, and the lapse date is computed from that.

납입기일        2026-02-10
유예 만료일     2026-03-31   ← 납입 해당월의 다음 달 말일
실효일          2026-04-01   ← 유예 만료일 다음 날

Through the grace period end date itself the policy is still valid. This one day really does create disputes. If an accident happens on March 31, the claim is paid, and if it happens on April 1, it is not.

Reinstatement is also widely misunderstood. It is easy to think that paying the overdue premium into a lapsed policy revives it automatically, but it does not. Reinstatement goes through a reinstatement application + renewed disclosure + review again. If an illness arose in between, an exclusion may be attached or it may be declined. So a payment that comes in after lapse does not revive the policy unless there is a reinstatement event.

Then why is there a status column in the table? Because computing it every time is slow. So the nightly batch computes it and writes it into the column. At that moment, this is how they split.

status 컬럼   어젯밤 배치가 계산한 '의견'
납입 이력      지금 다시 계산할 수 있는 '사실'

If the batch fails, cannot reflect a reinstatement, or cannot keep up with a correction that comes in later, opinion and fact split apart. And batches fail quietly. It is not that no error log is left; even when one is, nobody connects that log to this policy.

What it looks like in the field

First, a claim is not paid on a policy wrongly caught as lapsed. At the counter they answer "it is a lapsed policy, so we cannot pay," and the customer argues for months and then files a complaint with the Financial Supervisory Service. When you investigate, the cause is that the reinstatement batch failed once in March. For a wrongful denial, late-payment interest accrues on the amount paid, and the number of cases itself becomes an inspection finding.

Second, a lapsed policy wrongly left as normal is more dangerous. The customer does not know the coverage has ended. No notice goes out either. If an accident happens in that state, they find out for the first time then, and both the company and the customer lose on the spot.

Third, a policy processed at reinstatement without taking the disclosure again blows up years later at claim time. The review issues a denial for "breach of the pre-contract duty of disclosure," and the customer says "nobody asked me then." If there is no record, the company loses.

What you will do in the lab that follows

First, the next reading covers the as-of date and retroactive corrections, and then you move on to the lab.

You build 40 policies, 480 payment installments, policy events, and payment-receipt corrections that came in later. From that data you compute each policy's state at a particular as-of date from the payment history, and compare it with the system's status column to find the 9 policies that are off. The mismatches split into three directions, and the harm the customer suffers differs by direction.