UDS 3.0
Modern JSON-Based Data Transfer for Insurance Claims
| 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”         }        ]       }      }     }    ]   }  ] }}
Key Design Elements
1. JavaScript Object Notation (JSON)
- JSON is the most popular data format when integrating with web services. As the world becomes more tightly connected, sharing the same data format prepares UDS 3.0 for the future.
- JSON has endless free and open source software that can read it, display it, and make editing easy for even non-technical users.
- JSON has a ‘schema’ file that can be publicly hosted and who’s link can be embedded directly into the data file so third party tools can recognize UDS 3.0 and provide feedback if changes to the file do not meet the public specification.
- JSON has data heirachy where nouns like “Policy” and “Claim” can be described by its parts in one single object (One Policy, List of Claims, List of Documents in Claims).
- Combining A, F, G, I, M, and B Records into one Policy object removes the confusion of having to load an A Record first, then finding the related child record files of the same batch. Importing a batch just involves selecting ONE file, and archiving it for later is easier than keeping 6 potential files together per batch number.
2. More fields that preserve original state of claim data
UDS 2.0 is missing certain fields like Claim Status under the assemption the original value doesn’t matter – they’ll be open once they get to the Fund – or this information is shared via spreadsheets outside of UDS. UDS 3.0 aims to expose and preserve these fields to give each organization the freedom to choose if the field matters or not. Expected new fields:
- Policy, Claim, Payment Status
- Policy, Claim, Claimant level for Notes and Documents
- Note and Payment Type
- Suit Contact Information
- Insured and Claimant Middle Name
- Multiple Addresses, Emails, Phone Numbers
- Supplementary messages related to batch as whole
3. Flexibility in how to collect Images besides from a ZIP
UDS 3.0 offers a way to disconnect the metadata about documents from the source document import process by letting organizations choose how they want to retrieve their documents (Locally via a ZIP, or Remotely via SFTP or HTTPS). By not delivering the documents right away, organizations aren’t bogged down by a full warehouse if they only have space for a mailbox of data. Software can be adjusted to download Images by your criteria (priority, coverage, size) completely eliminating the stress of batch Image processing.
[
  {  // HTTPS protocol using SAS token
    “DocumentName”: “test.txt”,
    “Description”: “Some file”,
    “DateCreated”: “2025-04-28T16:34:56+00:00”, // ISO8601
    “DateLastModified”: “2025-04-28T16:34:56+00:00”,// ISO8601
    “Size”: 239024903, // In bytes
    “Hash”: “cf2238f43a01c4bd4651f00a9b7e255fc827b6b22dda277e38f392e7660ef4f5”,
    “Algorithm”: “SHA256”,
    “Source”: “https://suds.blob.core.windows.net/testgf/test.txt?{SAS_TOKEN…}”,
    “Type”: “text/plain” // https://www.iana.org/assignments/media-types/media-types.xhtml
  },
  {  // SFTP protocol using secret credentials
    “DocumentName”: “test.txt”,
    “Description”: “Some file”,
    “DateCreated”: “2025-04-28T16:34:56+00:00”, // ISO8601
    “DateLastModified”: “2025-04-28T16:34:56+00:00”,// ISO8601
    “Size”: 239024903, // In bytes
    “Hash”: “cf2238f43a01c4bd4651f00a9b7e255fc827b6b22dda277e38f392e7660ef4f5”,
    “Algorithm”: “SHA256”,
    “Source”: “sftp://suds.blob.core.windows.net/testgf/test.txt”,
    “Type”: “text/plain” // https://www.iana.org/assignments/media-types/media-types.xhtml
  },
  {  // FTPS protocol using secret credentials
    “DocumentName”: “test.txt”,
    “Description”: “Some file”,
    “DateCreated”: “2025-04-28T16:34:56+00:00”, // ISO8601
    “DateLastModified”: “2025-04-28T16:34:56+00:00”,// ISO8601
    “Size”: 239024903, // In bytes
    “Hash”: “cf2238f43a01c4bd4651f00a9b7e255fc827b6b22dda277e38f392e7660ef4f5”,
    “Algorithm”: “SHA256”,
    “Source”: “ftps://suds.blob.core.windows.net/testgf/test.txt”,
    “Type”: “text/plain” // https://www.iana.org/assignments/media-types/media-types.xhtml
  },
  {  // Local file
    “DocumentName”: “test.txt”,
    “Description”: “Some file”,
    “DateCreated”: “2025-04-28T16:34:56+00:00”, // ISO8601
    “DateLastModified”: “2025-04-28T16:34:56+00:00”,// ISO8601
    “Size”: 239024903, // In bytes
    “Hash”: “cf2238f43a01c4bd4651f00a9b7e255fc827b6b22dda277e38f392e7660ef4f5”,
    “Algorithm”: “SHA256”,
    “Source”: “file://some_folder/test.txt”,
    “Type”: “text/plain” // https://www.iana.org/assignments/media-types/media-types.xhtml
  }
]
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 |
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
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