Is there a standard or best practice for establishing a Policy Number?

Brian W. Frazier

Is there a standard or best practice for establishing a Policy Number?

Historically, I have been restricted in the creation of a policy number by the system of records data model established by the vendor or the warehouses it resides in.  

I have searched high and low, with no luck of seeing established standards... So I ask the Data Community - what are people's best practices or company standards around Policy Numbers?  In addition, do people use the same ID from when a quote (case) is made and the policy after the sale? 

Thanks in advance for your help. 

Charles Harbour

RE: Is there a standard or best practice for establishing a Policy Number?
(in response to Brian W. Frazier)

I'll get you started.  The assumption is that you want to build a smart key for indexing and easier categorization (without having to do a deep dive into the details).  Think about the use cases for this - the cautionary tale is that your business is going to continue to evolve and your policy numbers will not have that ability.  For all sorts of reasons (some of them legal), you can't swap out policy numbers in mid-flight.  But you can do some fundamental sorting...

 

Things to consider/practices I have seen used at various companies:

1) The first two digits are the origination year.  Be careful to make it character, not numeric!

2) The next two digits (maybe 3) are the product number, with maybe even a family of products as the first digit (is this a life insurance policy, or an annuity - then, a term policy or universal life).

3) A suffix that helps document how many policies exist for this particular customer.  

 

All of these need to be considered with the business rules that will go along with them.  For example, if you have a term life policy that lapses and then is reinstated - how do you handle that?  Can you pass ownership from the original policyholder to a subsequent owner?  Do you cancel and rewrite every time, or are there instances where you would need to retain the original policy number (and how will that mess up your smart key)?  If you assume that a customer's newest policy ends in 'D', that doesn't necessarily mean there are/were 4 policies for this customer (maybe some of them never made it out of underwriting).

 

There are other ways you could embed additional information (underwriting method (was it autoscored or was it done manually), group vs individual policy, parent/child relationships) - but think hard about what this will look like in the future (consider history and how well your strategy would have held up over the years and what events happened to cause the strategy to evolve).

I'm sure others have their experiences to add.

Good luck!

CH

Merrill Albert

RE: Is there a standard or best practice for establishing a Policy Number?
(in response to Brian W. Frazier)

Having started my career as a logical data modeller, you don't embed logic into a key.  (Those are separate fields.)  It might make sense at first, but business changes and then the embedded logic needs to change too.  It will eventually come back to bite you.  (Changing keys gets messy.)  Just start at 1 and keep going.