Master data management in insurance agencies: one client, two systems

Master data management in insurance is the discipline of keeping one agreed record for each client, carrier, producer and product, and making every system that holds a copy agree with it. For an insurance agency the master data that matters most is the client: the named insured, its tax ID, its locations and its contacts, to which every policy, note, claim and commission is attached. An acquisition breaks that overnight. The same insured can now sit in the seller's agency management system, the buyer's, the carriers' systems and a document store, each with a different spelling, a different client number and a different set of codes. Deciding which record is true, once, and making the others point to it, is master data management in its plainest form. Botminds' Agency Acquisition Data Migration does that decision for an acquired book: a client matcher agent groups the records of each insured within and across both books and explains each match, a person approves every merge, and the result loads into the buyer's system as one client with every original value kept.

What is master data management in insurance?

It is deciding which version of each core record is authoritative, writing down the rules that decide it, and linking every other copy to that version. In an insurer, master data covers policyholders, products, agents and reference codes; in an agency it is mostly clients, carriers, producers and the code lists that describe lines and statuses. The techniques are the same in both: standardise, match, decide, keep a crosswalk of identifiers, and record every change.

What makes it hard in insurance is that the authoritative values live in different places. The client's legal identity is set by its tax registration; the coverage is set by the carrier's declarations page; the relationship history is in the agency's notes. No single system owns all three, so master data management in an agency is less about buying one more system than about deciding, field by field, which source wins.

Why do agencies have duplicate client data?

Because clients are set up by whoever first needs them, and agencies are organised by line. A commercial desk sets up a contractor for its package policy; years later the workers' comp desk sets it up again for comp; a surety team sets it up a third time for a bond. Each record is correct for its desk, and together they describe one insured three ways. Acquisitions add a second book with its own history of the same habit.

The sample acquisition in the solution shows the result: one roofing contractor appeared as a seller record created by the commercial desk in 2009, another created by the comp desk in 2016, and a buyer record created by its surety team in 2023. Across the whole sample book, 3,412 client records became 3,198 clients after 214 records were merged in 187 clusters, and 38 of those clusters reached across both books.

One client, four systems: the map after an acquisition

After an acquisition the client lives in at least four places: the seller's agency system, the buyer's agency system, each carrier's policy system, and the document store that holds applications, declarations pages and signed forms. Each holds a copy for a different purpose, and each uses a different key.

The NAIC's data security model has a useful definition for this map. An information system is "a discrete set of electronic information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of electronic information" (NAIC Model #668, §3). Every box on the map is one, each holds nonpublic information about the same client, and after an acquisition the licensee is answerable for all of them.

Three levels of client: the group, the named insured, the location

Most client-record arguments are arguments about level. A business group, the legal entity that is the named insured, and the locations where it operates are three different things, and an agency system that has only one "client" field forces people to pick one.

Federal statistical agencies faced the same problem and solved it with levels. The Census Bureau's Business Register links "records of enterprises, tax reporting entities based on Internal Revenue Service Employer Identification Numbers (EINs), and establishments", and notes that its "information is maintained separately for each establishment and company" (U.S. Census Bureau, Business Register). The Bureau of Labor Statistics counts establishments, not companies, and requires eligible multiple-establishment employers to report "via the Multiple Worksite Report" so each workplace is counted separately (BLS QCEW overview).

The practical rule follows: merge at the named-insured level, link at the other two. Two locations of one insured are one client with two locations. Two entities under one owner are two clients in one account. A name or address change does not create a new insured, and the IRS agrees: "You don't need a new EIN if you just change your business name or address" (IRS, When to get a new EIN).

What is a golden record, for an insured?

A golden record is the single, decided version of a client that every system treats as true, built from the best value for each field across all the copies. For an insured it holds the tax ID, the legal name and any trade names, the locations, the mailing address, the contacts, the account manager and producer, and a crosswalk of every system's key for that client.

The important word is "decided". A golden record is not the newest record or the longest one; each field comes from the source that is most likely to be right for that field, under a rule written down in advance. In the sample merge, the legal name came from one seller record, the mailing address from the buyer's record and the office phone from the first seller record, and the merge record says so, with every original value kept in an archive. That record is what makes the golden record auditable, and reversible if a merge was wrong.

A golden record for one insured: every policy, the exposure, and the merge record

How do you keep one client record across systems?

Decide the record once, give every system a link to it, and route every later change through the same rules. In practice that means a short sequence that the migration runs for the acquired book, and that the buyer's own processes then keep running for new clients.

How do carrier portals sync with agency systems?

Through the policy, not the client. A carrier keeps its own record of each policy under its policy number, with the named insured as it appears on the declarations page; the agency system holds the same policy linked to its own client record. Where a carrier sends policy and billing changes to the agency system electronically, those changes land on whichever client the policy is attached to; where it does not, staff copy them from the carrier's portal.

Either way, a duplicate client in the agency system splits the carrier's view across two records. That is why the policy link is part of the golden record: each policy carries its carrier policy number and the insurer that issued it, identified by the NAIC company code rather than a carrier name the seller typed. In the sample, one seller carrier code turned out to cover two companies in the same group, 119 policies with one and 8 with the other; linking those eight policies to the wrong insurer would have broken every later update from it. The data mapping template shows how carrier codes are mapped value by value.

Who owns client data after an acquisition?

The buyer holds it and answers for it, under the purchase agreement and the privacy and security rules that apply to licensees. The NAIC's privacy model regulation defines a licensee to include "all licensed insurers, producers and other persons licensed or required to be licensed" (NAIC Model #672, §4), so an agency that acquires a book acquires privacy duties with it, and the federal privacy law's exception for a sale or merger is what lets the data move in the first place (15 U.S.C. §6802(e)(7)).

Ownership inside the buyer is a separate, practical question: who may change the golden record. The simplest answer is that the data migration analyst owns merges during the integration, and the account manager owns the servicing fields afterwards, with the tax ID and legal name changed only on a document. Carriers keep their own records of the same insured; they own their policy data, and the agency's job is to link to it correctly, not to overwrite it.

What is the difference between data migration and data integration?

Migration moves data from one system to another once; integration makes data from several sources work as one, continuously. An acquisition needs both: the seller's book is migrated into the buyer's system, and the combined book is integrated, so a client who was in both is one client and every carrier update lands on the right record.

Master data management is the part of integration that survives the project. The migration ends on day one; the rules that decide which client record is true, who may change it and how new clients are set up have to keep running, or the next acquisition starts from a book that has drifted again. Policy Servicing's guide to data conversion vs data migration covers the related distinction for carrier policy systems, and the guide to merging duplicate clients covers the matching rules in detail.

The combined book, one row per decided client

Do agencies need master data management?

Every agency that grows by acquisition needs its discipline, even if it never buys a product with that name. The work is the same at any size: one named insured per tax ID, a crosswalk of every system's key, written rules for which source wins each field, and a person who approves merges. A single-office agency can run those rules in its agency system; an acquirer running several books needs them written down, because each new seller arrives with its own habits.

The cost of not having them shows up at the next acquisition and at every renewal in between: duplicate mailings, split loss histories, policies updated on the wrong client, and appointment and commission errors that trace back to a producer code attached to the wrong record. The integration team is usually where an acquirer first discovers it needs these rules, and the natural owner of them afterwards.

Questions people ask

What is a golden record in insurance?

The single decided version of a client, policyholder or other core entity that every system treats as true. For an agency's insured it holds the tax ID, legal and trade names, locations, contacts and a crosswalk of every system's key, with the source of each value recorded.

Is master data management the same as a CRM?

No. A CRM is one more system holding a copy of the client. Master data management is the set of rules that decide which copy is true and keep the others linked to it; a CRM can follow those rules or break them.

Should an agency keep the seller's client numbers after an acquisition?

Keep them as cross-references, not as the client's identity. The buyer's client number becomes the key, and the seller's number is stored on the client so that old documents, carrier records and the archive can still be traced to it.

How often should client records be checked for duplicates?

Before every load from another source, and periodically after that, because desks keep setting up clients. A search for the tax ID and standardised address before any new client is created prevents most new duplicates.

Can master data rules be applied to carriers and producers too?

Yes, and they should be. Carriers are best keyed to the NAIC company code, and producers to their national producer number and licences, so that commissions, appointments and downloads all point to the right company and person.