Surety Data Standards: Why are they needed?
Surety Data Standards White Paper, Robert Coon, Scott Insurance
Currently, each surety software program defines a field in its own way. For example, the principal’s name may be identified by the program as “principal”, “principalname”, “principal_name”, “princ_name”, or a myriad of other variations. As a result, there is no common language or interoperability between systems. An agency must have people adept at using each surety’s system, in addition to its own surety processing system and/or agency accounting system. While this is acceptable to agencies with limited surety business, the typical NASBP agency, which represents a greater number of sureties, becomes less efficient, and productivity drops significantly when processing bonds using a multitude of systems. The likelihood of data entry errors increases as well as the potential for other processing errors.
The use of Surety Data Standards defines the data field. When a computer program sees that a data field is labeled as “princ_name” then it knows that the variable is the principal on the bond, regardless of what it wants to do with that data. Common data definitions create the ability for programs to communicate with each other. This interoperability will promote efficiency and accuracy through the reduction in keystrokes and seamless data transmission. It will also speed accounting reconciliation between the carrier and agency systems. [Click here to download the White Paper and read more…]
AUGIE: ACORD User Groups Information Exchange
General Reference Document, Cal Durland