UDS 3.0
Modern JSON-Based Data Transfer for Insurance Claims
The Uniform Data Standard (v2.4 April 2019) was created to simplify data exchange between receivers and guaranty funds. Since 1995, the specification has been building on top of fixed-length text files sharing an equal balance of structure and efficiency, but it has some sharp edges that impact the practical usage of UDS.
| Problem | Impact |
|---|---|
| Batch Limit of 999 | Limits are easily reached during big insolvencies increasing the complexity of reporting. |
| ZIP files are temperamental | Delivery of large ZIP files is a time-consuming and temperamental process where the file could be corrupted or incomplete at various stages during delivery, and remediation involves redoing the process. |
| Data outside specification | Any data outside the specification must be delivered as an Excel file that should otherwise just be included in the spec. |
| UDS expertise | A UDS expert is necessary to assist in UDS creation because the UDS specification can differ significantly from the original format of the insolvent company data. |
| Limited character support | UDS requires the ASCII character set, which only supports characters familiar in the English language |
| File Path Separator | UDS requires the use of the Microsoft Windows-specific file path separator ‘’ in all I Record paths, despite ‘/’ being more widely supported on all operating systems. |
| Key Duplication | UDS requires that unique key information be copied from the A Record to all other record types to create the data relationship, which pads other record types’ data files with duplicate information |
| Metadata Truncation | UDS does not fully utilize the metadata properties visible during claims handling, which can be helpful, such as document tagging, distinguishing between system notes and user notes in the source data, and payment statuses like paid/unpaid/canceled in the source data. Making use of these properties currently depends on including custom text in the description/body/memo instead of having a dedicated field. |
| Volume Fatigue | Importing a UDS file relies on communications outside the file itself, and the file names blend together increasing the likelihood of mistakes. |
| Hard to read | Non-technical persons are unable to read or edit UDS files without specialized software. |
| Non-native number format | To represent numbers UDS has an inferred decimal point and sometimes optional sign. This custom format can be confusing to read for the first time. |
Introducing JSON:
Faster implementation and fewer errors. The JSON structure mirrors how modern claim systems organize data internally, reducing transformation time and the need for UDS expertise. Schema validation ensures data integrity before transmission.
{
 “$schema”: “https://gsicdn.blob.core.windows.net/uds/uds3.0-schema.json”, “Batch”: {  “Id”: 1,  “CreatedOn”: “2025-08-13T17:25:31Z”,  “Message”: “”,  “RowCount”: 1,  “InsuranceCompany”: {   “NAIC”: “44725”,   “Name”: “First Auto Insurance Company”,   “DateOfLiquidation”: null,   “DateOfPolicyCancellation”: null,   “LinesOfBusiness”: [    “P&C”   ]  },  “GuarantyFund”: {   “Name”: “Illinois”,   “Address”: {    “Line1”: “150 S. Wacker Drive, Suite 2970”,    “Line2”: “”,    “City”: “Chicago”,    “State”: “IL”,    “ZipCode”: “60606”   },   “Contact”: {    “ClaimQuestions”: “”,    “ClaimSupervisor”: “”   },   “Website”: {    “HomePage”: “https://www.ncigf.org/”,    “InsolvencyPage”: “https://www.ncigf.org/resources/uds/uds-claims-manual/”   }  },  “Receiver”: {   “Address”: {    “Type”: “Primary”,    “Line1”: “1600 Pennsylvania Avenue NW”,    “Line2”: “”,    “City”: “Washington”,    “State”: “DC”,    “ZipCode”: “20500”   },   “Contact”: {    “DataQuestions”: “”   }  },  “Data”: [   {    “PolicyNumber”: “POL123456”,    “EffectiveDate”: “2022-05-07”,    “ExpirationDate”: “2022-11-07”,    “IssuingCompanyCode”: “44725”,    “Insureds”: [     {      “Number”: 1,      “FirstName”: “John”,      “LastName”: “Doe”,      “Addresses”: [       {        “Type”: “Primary”,        “Line1”: “123 Main Street”,        “Line2”: “Apt 4B”,        “City”: “Springfield”,        “State”: “ZZ”,        “ZipCode”: “99999”       }      ],      “Emails”: [       “[email protected]”      ]     }    ],    “Notes”: [],    “Documents”: [],    “ReturnedPremium”: [     {      “Insured”: {       “Number”: 1,       “FirstName”: “John”,       “LastName”: “Doe”,       “Addresses”: [        {         “Type”: “Mailing”,         “Line1”: “123 Main Street”,         “Line2”: “Apt 4B”,         “City”: “Springfield”,         “State”: “ZZ”,         “ZipCode”: “99999”        }       ],       “Emails”: []      },      “Coverage”: {       “Code”: “935005”,       “Name”: “Automobile”      },      “FinalAuditIndicator”: “Y”,      “TransactionCode”: “820”,      “ReturnPremiumAmount”: 200.0,      “UnpaidPremiumAmount”: 0.0,      “Claimant”: {       “Number”: 1,       “FirstName”: “Jane”,       “LastName”: “Smith”,       “Addresses”: [        {         “Type”: “Mailing”,         “Line1”: “456 Oak Avenue”,         “Line2”: “”,         “City”: “Shelbyville”,         “State”: “YY”,         “ZipCode”: “88888”        }       ],       “Emails”: [],       “Notes”: [],       “Documents”: [],       “Payments”: []      }     }    ],    “TotalWrittenPremium”: 0.0,    “TotalInForcePremium”: 0.0,    “Claims”: [     {      “Number”: “CLM987654”,      “ReceiverNumber”: “987654”,      “ServicingOfficeCode”: “1”,      “TransactionAmount”: 25038.95,      “TransactionCode”: “100”,      “Claimants”: [       {        “Number”: 1,        “FirstName”: “Jane”,        “LastName”: “Smith”,        “BirthDate”: “1990-01-01”,        “Coverages”: [         {          “Code”: “785005”,          “Name”: “Liability – Bodily Injury – Combined Single Or Split Limit”         }        ],        “Addresses”: [         {          “Type”: “Primary”,          “Line1”: “789 Pine Road”,          “Line2”: “”,          “City”: “Capital City”,          “State”: “XX”,          “ZipCode”: “77777”         }        ],        “Emails”: [         “[email protected]”        ],        “Notes”: [         {          “OriginalId”: 1,          “Text”: “TaskCompleted: New Claim assignment for John Doe”,          “CreatedOn”: “2022-08-26T00:00:00Z”         },         {          “OriginalId”: 1,          “Text”: “TaskCompleted: 90-day review reminder”,          “CreatedOn”: “2023-01-20T00:00:00Z”         },         {          “OriginalId”: 1,          “Text”: “TaskCompleted: Follow-up for John Doe”,          “CreatedOn”: “2023-03-14T00:00:00Z”         },         {          “OriginalId”: 1,          “Text”: “Transaction Comments – Payment issued to Jane Smith”,          “CreatedOn”: “2023-03-16T00:00:00Z”         },         {          “OriginalId”: 1,          “Text”: “TaskCompleted: Medicare updates needed”,          “CreatedOn”: “2023-08-30T00:00:00Z”         }        ],        “Documents”: [         {          “OriginalId”: 0,          “Path”: “https://www.suds.blob.core.window.net/55555/Images/sample1.pdf”,          “Description”: “Sample Document 1”,          “CreatedOn”: “2023-11-30T00:00:00Z”,          “PageNumber”: 0,          “Tags”: [           “Document”,           “Policy Data”          ],          “Fingerprint”: “a1b2c3d4e5f6g7h8i9j0”         },         {          “OriginalId”: 1,          “Path”: “https://www.suds.blob.core.window.net/55555/Images/sample2.pdf”,          “Description”: “Sample Document 2”,          “CreatedOn”: “2023-12-13T00:00:00Z”,          “PageNumber”: 2,          “Tags”: [           “Declarations Document”          ],          “Fingerprint”: “b1c2d3e4f5g6h7i8j9k0”         }        ],        “Payments”: [         {          “Payee”: {           “NameLine1”: “Mark”,           “NameLine2”: “Johnson”,           “Identification”: {}          },          “CheckNumber”: “CHK123456”,          “CheckDate”: “2023-09-06”,          “CheckAmount”: 47.55,          “InvoiceNumber”: “INV1001”,          “Comment”: “Payment for services”,          “Coverage”: {           “Code”: “785005”,           “Name”: “Liability – Bodily Injury – Combined Single Or Split Limit”          },          “Type”: {           “Code”: “310”,           “Name”: “Loss claim payment”          },          “ServiceOrBenefitFromDate”: “2012-12-20”,          “ServiceOrBenefitToDate”: “2013-12-20”         },         {          “Payee”: {           “NameLine1”: “Alice”,           “NameLine2”: “Brown”,           “Identification”: {            “SSN”: “123-45-6789”           }          },          “CheckNumber”: “CHK987654”,          “CheckDate”: “2023-09-11”,          “CheckAmount”: 111.05,          “InvoiceNumber”: “INV2002”,          “Comment”: “Repair reimbursement”,          “Coverage”: {           “Code”: “785005”,           “Name”: “Liability – Bodily Injury – Combined Single Or Split Limit”          },          “Type”: {           “Code”: “310”,           “Name”: “Loss claim payment”          },          “ServiceOrBenefitFromDate”: “2012-12-20”,          “ServiceOrBenefitToDate”: “2013-12-20”         }        ],        “CMS”: “Some Sample CMS would be found here”       }      ],      “DateOfLoss”: “2022-08-23”,      “ReportDate”: “1901-01-01”,      “Suits”: [       {        “LawFirm”: “Nate Jennings Legal, LLC”,       }      ],      “Catastrophe”: {       “Code”: “42”,       “Name”: “Hurricane Nate”      },      “Notes”: [],      “Documents”: [],      “RecoveryIndicatorCode”: “8”,      “SecondInjuryFundIndicator”: “U”,      “TPAClaimNumber”: “TPA123456”,      “RepetitivePaymentIndicator”: “N”,      “AggregatePolicyIndicator”: “U”,      “DeductiblePolicyIndicator”: “Y”,      “WorkersCompensation”: {       “InjuryCode”: “01”,       “PartOfBody”: “12”,       “NatureOfInjury”: “75”,       “Cause”: “02”,       “Act”: “04”,       “TypeOfLoss”: “02”,       “TypeOfRecovery”: “01”,       “TypeOfCoverage”: “01”,       “TypeOfSettlement”: “00”,       “VocationalRehabIndicator”: “U”,       “DescriptionOfInjury”: “Slip and fall injury to hand”,       “WCABNumber”: “WCAB123”,       “Employer”: {        “PhoneNumber”: “5551234567”,        “Addresses”: [         {          “Type”: “Primary”,          “Line1”: “321 Corporate Blvd”,          “Line2”: “”,          “City”: “Metropolis”,          “State”: “WW”,          “ZipCode”: “66666”         }        ]       }      }     }    ]   }  ] }}
UDS 2.0 vs UDS 3.0: Key Differences
| Feature | UDS 2.0 | UDS 3.0 |
|---|---|---|
| File Format | Fixed-length text files | JSON with flexible field lengths |
| Character Encoding | ASCII only (English characters) | UTF-8 (international support) |
| Data Relationships | Duplicate keys across record types | Nested objects with natural relationships |
| File Structure | Multiple separate record files (A, B, C, D, etc.) | Single JSON file with all related data |
| Editability | Requires specialized UDS tools | Any text editor or JSON viewer |
| Validation | Requires UDS Data Mapper or custom tools | JSON Schema validation available |
| Batch Limitations | 999 batch limit, fixed batch sizes | Flexible batch handling |
| Path Separators | Windows-only backslashes () | Universal forward slashes (/) |
| Image Delivery | ZIP file | ZIP file + remote options |
 Human Readable Format
End the era of specialized tools. UDS 3.0 uses JSON format that can be read and edited with any text editor or spreadsheet application. No more dependency on proprietary software or UDS experts for basic file modifications.
UDS 3.0 Json
 Unicode Support
Variable Length Encoding.
Backward Compatibility with ASCII.
Efficiency
 Nested Relationships
Eliminate data duplication. Related data like notes, payments, and claimants are nested within their parent objects, removing the need to duplicate key information across multiple record types.
 Enhanced Metadata
Capture more detail. Include additional metadata like document tags, note types (system vs. user), payment statuses, and coverage-specific information that gets lost in UDS 2.0’s rigid structure.
 Streamlined Processing
Faster implementation and fewer errors. The JSON structure mirrors how modern claim systems organize data internally, reducing transformation time and the need for UDS expertise. Schema validation ensures data integrity before transmission.
Automatic Validation
JSON Schema validation catches errors before transmission
API-Ready Format
Direct integration with modern web services and APIs
Flexible Updates
Send only changed data, like REST API operations
Real-World Benefits for Your Organization
For Guaranty Funds
✓ Smaller, more manageable files
✓ Easy manual editing for corrections
✓ All claim data consolidated in one place
✓ Simplified archiving and storage
For Receivers
✓ Intuitive schema matching claim systems
✓ Reduced dependency on UDS experts
✓ Easier single-state implementations
✓ Smoother transition from existing processes
UDS 3.0 – JSON Concept Overview
Timeline of UDS 3.0 DevelopmentÂ
UDS 3.0 Survey Results
Code Samples
Coming Soon!
Related Posts
GSI Advances UDS 3.0 Development with JSON Data Format Implementation
GSI is making significant progress on one of the insurance industry's most anticipated technology upgrades: the development of UDS 3.0. Building on extensive community feedback and design work, our team is actively programming updates to the UDS Data Mapper to...
UDS 3.0 Proposal and Implementation
Challenges The specification of UDS 2.0 was focused on efficiently storing common claim and policy information using a simple text file. The idea was to select standard columns that work for everyone, minimize the resulting data file size, and rely on automation to...
Subscribe to the GSI Newsletter to receive periodic updates about UDS 3.0