Many people confuse the NIPR with the PDB. They think the terms are interchangeable.
In fact, though, one, the NIPR, is an industry organization. The other, the PDB, is a database of producer information.
How can companies navigate these increasingly complex entities, and simplify the process of submitting and retrieving producer information?
Recently, a major change occurred in New Mexico. That state changed its back-office system to State Based Systems (SBS). Regulators there also changed license numbers and lines of authority. The shift took several months to implement and test, before moving to production. Without these changes, transactions would not move through the NIPR Gateway. The system would produce no licenses and no appointments.
This got me thinking: Managing licensing and compliance for agents and producers has become one of the most complex aspects of the already highly technical information-gathering demands facing the insurance industry.
While I was thinking about how to tell producers how to keep up to date on agent data management, I ran into no less than five acronyms, along with a web of changing relationships and requirements. The purpose of this article is to explain the complicated workings of intrastate regulations, and to point to some ways insurance carriers and agencies can keep on top of it all.
The Birth of the NIPR
The NIPR, or National Insurance Producer Registry, was incorporated in October 1996 as a nonprofit affiliate of the National Association of Insurance Commissioners (NAIC).
One of the main purposes of creating the NIPR was to give states and territories a central repository they could use to put the demographics for the individuals and business entities that act as producers, licensing information, appointment information, and information about the actions recorded in RIRS (Regulatory Information Retrieval System) in a single database.
Before the NIPR came along, you’d have to go to each state’s website to search for a producer’s licensing and appointing data. You’d have to apply for licensure by paper. Each producer had a different license number for each state in which the producer was licensed.
Thanks to the NIPR, the licensing arena has come a long way: No more paper. No more mailing forms to the states and waiting weeks (or, sometimes, months) to receive a license or appointment.
The Rise of the NPN
Once the NIPR was created, each producer needed to have a producer number that was unique, no matter the jurisdiction. Some states tried to use the Social Security number of the individual producer as the NPN, but that created security issues. Thus the National Producer Number, or NPN, was developed.
The NIPR assigns the NPN. The NPN is the single most unique identifier an individual or business entity that acts as a producer will maintain. An NPN will never be reused, no matter how long it has been inactive. Some states have even chosen to use the NPN as their state-specific license number.
The database for NPNs is the Producer Database — the PDB.
A PDB user can generate a PDB report that gives all states’ information for a producer. This saves the licensing administrator from having to go to each state’s or territory’s website to search for an individual or business entity.
Obtaining a PDB report carries a minimal cost, and the report provides comprehensive information about the producer. This holds true for business entities as well. If you go to a state website and look up a producer, you will only see that state’s information. If the producer has a revoked license or an RIRS action in another state, you would never know. But the PDB report gives you the entire record for that producer.
Moreover, holding producer data in the PDB is more cost-effective than holding it at the state level in the long run, especially if the producer is licensed in many states.
The NIPR Gateway
The NIPR Gateway is the system that moves the data on transactions — such as appointments, terminations of appointments, licensing, and license renewals — between a state and the NIPR.
The NIPR does not do a license check before sending a transaction. The insurer is responsible for verifying a producer’s licensure by either checking the state website or PDB before sending a transaction. The NIPR is the mover of data, not the verifier of data, when it comes to sending a transaction.
But the NIPR follows a state’s business rules for the data related to a specific type of transaction when it collects data on behalf of a state. If a transaction fails to meet a state’s business rules, the NIPR can reject the transaction before it is even sent to the state.
If the NIPR blocks a transaction, that can help a state avoid having to pay a transaction fee.
Or, the transaction could be sent to the state for a state review. A rejection could occur, for example, if all of the information required for a transaction is submitted, but the producer no longer has an active license. In that situation, the state would reject the request to appoint.
The NIPR is, in effect, the repository for the states’ business rules. The workers at NIPR are not the decision makers, and the NIPR is not a regulatory body. NIPR is only as good as the business rules provided by the states and territories. The jurisdictions themselves have a responsibility to submit requirements, changes, and updates to the NIPR, so the NIPR can implement the business rules and rule changes.
The NIPR sends email notifications to let users know when changes or updates are going to occur. Some days, they send several notifications about multiple states. Insurers with their own processing systems have to implement these state-by-state changes. In many cases, insurers must implement the changes within a short window of time.
The obvious question about the NIPR system is: How is it possible for a company to keep up with all of this? There is clearly too much information to keep track of all of it manually.
A company needs an automated data approach to remain in compliance with all jurisdictions and the NIPR.
Having a system that lets carriers and agencies test changes in a NIPR beta environment before implementing the changes can save companies a great deal of hassle, and money.
Carriers also need a dedicated advocate or liaison with the NIPR who can address the technical and subject-matter details involved with ensuring that updates and changes are made to meet exact specifications and timelines.