Skip to content

Developers · Data standard

PolicyBlockchain Data Standard

An open data model for insurance, published under Apache-2.0.

Draft v0.1 · request for comment

This page describes the draft. The schemas will be published after the comment period and legal review. Field names and structure can change before 1.0.

What it is

The record format the PolicyBlockchain network uses for insurance data: parties, policies, coverages, forms, claims, billing, regulatory reporting, reinsurance and capital, plus an experimental model for underwriting reputation and track record.

It is our own model, written as JSON Schema 2020-12. It is compatible with the formats the industry already uses, so carrier, MGA and agency data maps in and out by identifier.

Why adopt

  • Open licence. Apache-2.0 for the whole standard: schemas, code sets, examples, tooling and documentation.
  • Free tooling. A validator and conformance checker anyone can run, and free converters planned for common formats.
  • Compatibility mappings. Existing data maps in by identifier, without republishing anyone's proprietary content.
  • Conformance. A clear Core, Line and Full test, and a “PolicyBlockchain Compatible” mark defined by passing it.
  • A path to neutral governance. An open comment process, a steering group, and a stated plan to move the standard to a neutral foundation.

Principles

  1. Our own names. Plain camelCase fields owned by the standard.
  2. Identifiers, not content. External codes travel as qualified values, e.g. { "system": "ncci.class", "code": "8810" }. Forms are cited by number and edition.
  3. Transactions are the record. A policy term, a claim and a loss run are projections of append-only transactions, with both business time and recorded time.
  4. One party key. Parties are keyed by their InsureBio identity; insured, carrier, wholesaler and claimant are roles.
  5. Money is exact. Integer minor units plus an ISO 4217 currency.
  6. Premium is typed charges. Each charge says who ultimately receives it, so a payment splits cleanly.
  7. No personal data on chain. Events carry hashes or tokens; personal fields move only under a data access grant.
  8. Corrections are new records. Nothing is edited in place or deleted.

Object map

AreaObjects
CoreParty, PartyRole, Identifier, Policy, PolicyTerm, PolicyTransaction (new, renew, endorse, cancel, reinstate, rewrite, audit), Coverage, CoverageTerm (limit, deductible, SIR, sublimit), FormReference, Exposure, Location, Charge, Premium, Submission, Quote (immutable versions), Bind, Document, Money, Jurisdiction, LineOfBusiness
ClaimsFNOL, Claim, ClaimTransaction, Reserve, Payment, Recovery, LossRun (a projection at a valued-as date)
BillingInvoice, Installment, PremiumFinanceAgreement, Commission, trust account movements
RegulatoryRegulatoryFiling (including surplus lines tax and stamping), DataCall, DataCallConsent
ReinsuranceTreaty, Cession, Bordereau
CapitalCell, CapitalUnit, Collateral, SecurityAttestation
Identity and ledgerDataAccessGrant, Checkpoint, TokenReference
Reputation (experimental)Season, Row, Seat, Contest, Forecast, VerifiedBook

Lines covered

Every line follows one pattern, { lineCode, exposures[], coverages[], ratingBasis[] }, and has an end-to-end example from submission to loss run.

PersonalCommercial
Personal autoGeneral liability
HomeownersWorkers compensation and employers liability
Dwelling fireCommercial property
Personal umbrellaCommercial auto and trucking
Flood: NFIP and privateBusinessowners
EarthquakeCommercial umbrella and excess
Wildfire and quake hazard attributesProfessional (E&O, D&O, EPL), cyber, inland marine

An excess and surplus lines overlay applies to any line: placement, home state, diligent search, licensed broker, affidavit, stamping and tax allocation.

Events

Events are named domain.object.action (for example claim.reserve.changed) across policy, claim, billing, trust, reinsurance, capital, regulatory, identity and ledger domains. Each has a payload schema and a version. Payloads carry no personal data.

Open Coverage Forms

A proposal: original, plainly worded coverage forms published under Apache-2.0, each with a stable id and edition, with every clause individually addressable. Coverages can cite them directly. State form-filing rules still apply, so a carrier files an Open Coverage Form before using it.

Reputation and track record

An experimental, open model for underwriting reputation: seasons, listed programs and books (rows), seats, free-entry contests of skill scored on chain data, forecasts, and verified books of business. A seat is never an underwriting decision, and contests never take an entry fee.

Compatibility and licence

StandardRelationship
ACORD formsCompatible: form numbers and editions map to standard objects
ISO and NCCICompatible: forms cited by number and edition; class codes carried as pass-through values
NAIC Product Coding MatrixMaps to: every line code has its Type of Insurance code
FEMA OpenFEMA (NFIP)Maps to: field-level mapping for the flood line
openIDS and openIDLCompatible with openIDS; data calls interoperate with the openIDL workflow

Licensed under Apache-2.0. Third-party form numbers and codes appear only as identifiers, for compatibility. The standard does not reproduce third-party form wording, element dictionaries, class descriptions or code lists.

Conformance

LevelA conformant bundle
CoreValidates, and holds linked parties, policies, terms and transactions
LineCore, plus lines that validate against their line schema and a lifecycle beyond new business
FullLine, plus submission, quote, bind, claim, loss run and events

The validator will be published with the schemas, runnable with npx or Docker.

Comment on the draft

Questions, objections and proposals go to the community forum, in the Developers category. Changes to the standard follow a public request-for-comment process there.

Read the draft, then tell us what is missing for your line, your system or your regulator.

Forum: community.policyblockchain.com, Developers category.