Thomas Kalil interviews Reshma Khilnani on Unemployment Insurance Modernization
This is a Q&A Session from June 27, 2020, where Thomas Kalil Chief Innovation Officer of Schmidt Futures interviews USDR UI Lead Reshma Khilnani.
Q. Tell me a bit about your background, and why you decided to join the U.S. Digital Response.
I’m Reshma — a software engineer and entrepreneur who lives in San Francisco. I’ve built and sold two companies, and have worked in big tech at Facebook, Microsoft, and Box. At the end of 2019, I sold a company and my son was born, so I decided to take some time off. My friend and former colleague who is now the CEO of USDR, Raylene Yung, mentioned she needed volunteers to help state and local governments deal with the COVID-19 crisis. Seeing the extreme need, I decided to volunteer. Our team spent April to June 2020 helping state Departments of Labor improve and grow their unemployment insurance systems in the wake of COVID-19 and the CARES Act.
Q. What are some of the common challenges that states who are running Unemployment Insurance face? What’s the experience from the point of view of the citizen that is filing for UI?
State Departments of Labor struggle to determine whether applicants for UI are eligible to receive benefits. This was not a problem before the pandemic because unemployment was low and there were very few applicants. State employees were able to manually verify documents and interview applicants as needed to determine eligibility. COVID-19 brought three big changes to the UI system that left it broken:
- The crisis brought over 35 million new applicants who lost their jobs nationwide. At peak, there were 10 to 50 times more claims than ordinarily seen by a state’s UI system, with the wave of users starting practically overnight.
- The CARES Act made applicants eligible for 13 more weeks of unemployment insurance funded by the federal government through a program called Pandemic Emergency Unemployment Compensation (PEUC).
- The CARES Act expanded UI to those who were self-employed through a program called Pandemic Unemployment Assistance (PUA). This population had never been eligible for UI before.
These changes drastically impacted the applicant experience in three ways:
- What should I apply for? Applicants don’t understand which program they are eligible for, leaving them confused about how to apply. Many states do not have a unified application and require self-selection into the UI, PEUC, and PUA programs. Because they struggled to do eligibility checks, many states required applicants to submit a regular UI application, be rejected, and then apply for PUA. This process often took many weeks and caused great confusion. Phone lines were jammed and applicants were left to apply and reapply through trial and error. Some states, like New York and California, invested in a unified application, which helped reduce confusion, but most continue to use a separate application process.
- What’s taking so long? Once an application is submitted, approximately ⅓ to ½ are flagged for manual review for reasons related to eligibility. Manual review includes answering questions like:
- Is this person who they say they are?
- Are they a citizen or qualified alien?
- Did they actually lose their job due to a layoff?
- Did they receive any kind of wages?
- Did they have wages in another state?
A customer service representative must compile additional documentation for all of these cases. With such a large amount, the follow-up process often takes 3 weeks or more. The wait times are especially bad for people who have to apply twice: once for regular UI, for which they were rejected (and often expected to be rejected), and then for PUA. Many applications in manual review have to submit extra documentation (like a driver’s license or paystub) by mail or fax, which takes even longer to collect and process.
3. Certification… what? When you apply for UI (regular UI or PUA), you don’t actually receive payment immediately. Applicants must fill out and submit a special form, weekly or bi-weekly, on a state Department of Labor website to receive payment. Many applicants didn’t know about this requirement and were confused when they didn’t receive payments despite being approved for UI. Due to the increased load, many certification websites went down. For example, in New Jersey and DC, they started to limit certification so that only users with SSNs in a certain range could apply on a given day. This can cause people to miss their designated certification window, and miss their payments.
Q. When a state decides that they want to modernize their UI system — what does that typically look like?
Most state UI systems have two parts:
- “The Mainframe” or system of record: a mainframe computer (e.g. AS400) that stores applicant and transaction data. This serves as the source of truth about applicants and their payments and determines eligibility and benefit amounts. (Not all states have mainframes, but many do.)
- Data capture systems: web applications or call center applications that allow various users to update and input data into the system of record.
When it comes to modernization, the focus is often on upgrading or replacing “the mainframe.” The mainframe upgrade is a huge project, as it requires migrating over all user accounts and historical data, as well as replacing and re-writing business logic for eligibility that has been developed over time.
Modernization of data capture systems, like web applications and call center applications, is an afterthought. It’s assumed that if you replace the mainframe, your web application and call center app upgrade will be simple. However, the truth regarding website replacement is more complex. Web and call center applications begin to develop business logic on their own, making them hard to uncouple from the system of record and replace.
Q. What are the limitations of the current approach, in terms of time, cost, and the quality of the service that states can provide to the public?
The current approach has one major limitation. Mainframe replacement has enormous scope and requires a lot of detailed planning and diligence to get a new system of record to match the business logic and history of the old one.
Projects like these often fail because they take too long and the old system evolves while the new one is being developed. As time passes, the risk of outages or incorrect data migration increases, and appetite to cut over to the new system is reduced. In addition, many of the “modern legacy systems” recreated the dependencies and workflows of the original mainframes rather than using more modern API-based approaches.
Modern software development practices no longer replace a legacy system in its entirety. Instead, its standard practice to incrementally peel off functionality and move the system piece by piece to a better state, testing and improving the user experience daily. This is a dramatically new approach for many government teams and making this transition is crucial to creating modern flexible systems that serve changing user needs.
The cost and failure rates of wholesale replacement of legacy UI systems are also too high. Yet replacing them piece-by-piece requires rethinking the way states and federal agencies budget for and procure these systems. Instead of treating these costs as “capital” expenses and spending $200m+ to rebuild their UI systems over the course of 5 years, states could treat these improvements as operating costs and spend $5–10m/year.
This article outlines some of the limitations of the current model.
Q. You have been working on developing a new strategy that would streamline the process of determining whether someone is eligible. What’s the goal, and what approach could we pursue to achieve this goal?
We propose building a new eligibility service that will fix the call center first.
A little background: the mainframe, in theory, has two primary functions:
- Determine benefit eligibility and benefit $ amount
- Store transaction history and interface with the bank for payouts
In practice, however, the eligibility and amount are only being calculated by the mainframe in 30–50% of cases, depending on the state. Many cases go to a manual queue, where the eligibility and amounts are determined by a human customer service representative, who reviews materials and/or interviews applicants.
In our proposal, we provide a suite of tools to upgrade and automate manual work done by call center employees. This toolkit is an eligibility service that includes automated identity verification, fraud, and risk assessment, and gathers wage data at scale for applicants.
The goal is to move applicants through the system as quickly as possible, while ensuring that fraud is under control, without needing to replace the mainframe. This would allow us to greatly reduce the technical complexity and risk of failure of the upgrade.
Over time, the eligibility checks would transition from relying on the mainframe to instead only using the new automated eligibility checker. This change would decrease maintenance costs for the overall system and make it easier to replace the mainframe in the long run.
