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 process it correctly for each claim system. It wasn’t meant to be read or edited except with special programs; the specification depends on all data being stored and delivered as a file, and the specification will remain relatively static because the burden of updating it would propagate to all automation relying on the schema. Still, those sacrifices were worth it for speed. UDS 2.0 has solved the Problem and continues to do so, albeit with some growing pains in its use as insolvencies and technologies have evolved. Some growing pains include:

• Some Guaranty Associations have batch size limitations at the network level OR claim system level, requiring multiple batch numbers be spent on a single job.
• The Batch Number limit of 999 can be easily overrun, necessitating the use of wrapping for long tail insolvencies.
• 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.
• Some data is delivered to Guaranty Associations in Excel, which should be incorporated into UDS.
• 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.
• UDS 2.0 requires the ASCII character set, which only supports characters familiar in the English language
• UDS 2.0 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
• UDS 2.0 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
• UDS 2.0 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, where large insolvencies produce a considerable amount of UDS files, which all depend on email communications to describe their contents and purpose
• Non-technical users are unable to read or edit UDS files without specialized software, which hinders their ability to assist themselves.

Solution

UDS 3.0 is a new version of the specification that aims to give UDS a new set of legs and benefits that take better advantage of new technologies and the way claim systems operate. The primary change to UDS involves transitioning from fixed-length text data files to the more modern JSON data file format. This change inherently requires UTF-8 encoding, allows for the creation of relational data without key duplication, and facilitates easier reading and editing with standard, free software that can interpret JSON, rather than UDS. The details of the new specification will be described below. Still, the broader themes include reducing the cost to transform source data to UDS, improving metadata available to entities like Documents and Notes, and adding quality-of-life features that future Claim Systems can build around.

Implementation Details

(Schema, Example)

UDS 3.0 will utilize the JSON data format, as described above, with UTF-8 encoding for enhanced language support. JSON supports lists, complex objects, nesting, datatypes, and public schema definitions which can be used to verify UDS structure upon receiving UDS files.

Record Types in UDS 2.0 will be consolidated to a single file with a list of Claim objects represented in JSON. Those Claim objects will use the same key relationships as represented in most databases, where a Policy has Claims, Claims have Claimants, Claimants have Notes, all described in one place. This focus on describing a JSON Claim using a composite of Nouns is identical to how Claim Systems organize their data, which can mean LESS time spent transforming data and less time spent consulting with a UDS expert.

Rollout

UDS 3.0 is planned to be rolled out by NCIGF’s subsidiary GSI as the first users of the UDS 3.0 pipeline. While the schema is in its infancy and changes are common, GSI will bear the burden of prototyping the latest version of the schema and attempting to use it in new insolvencies that GSI is involved in. A UDS 3.0 to 2.0 conversion pipeline will be transparently added in those circumstances so this prototyping does not impact Guaranty Funds.

The UDS Data Mapper will also include a new UDS 3.0 version of every UDS-related link to represent the prototype UDS 3.0 pipeline. It will also focus on ingesting CSV files, but likely focus on importing CSV’s from every Claim System table that mimics the Nouns in the schema like Note and Claimant. This means minimal data transformation and a larger focus on establishing the foreign key relationships so the JSON can form correctly.

Impact on Guaranty Funds:

For Guaranty Funds that opt-in to receive UDS 3.0 prototype files, expect to receive the regular UDS 2.0 file AND the UDS 3.0 file in parallel. The intention is to send BOTH versions of UDS if applicable so Guaranty Funds can observe the prototyping stage over time. Implementing any version of UDS 3.0 before its been approved by the greater community (and the NAIC potentially) can be attempted at the Guaranty Fund’s own risk.

A desktop conversion utility may be provided by GSI independently from the UDS Data Mapper which can assist in converting UDS 3.0 files to UDS 2.0 and vice versa, but as of 06/13/2024 these are not implemented.

Impact on Receivers:

Since GSI is undertaking the initial prototyping of UDS 3.0, Receivers will not be impacted by the UDS 3.0 process unless they are specifically requested to provide feedback on its implementation on the UDS Data Mapper. Financial records (C/D) may follow the same changes as the claim records and be provided as a UDS 2.0 and 3.0 file in parallel, but that is yet to be implemented.