Why do digital benefit systems deepen exclusion for unemployed and informal workers?

Why digital benefit systems exclude people before they even get to the benefit

Digital delivery changes a welfare system from a service channel into an access gate. When the route in assumes continuous connectivity, a capable device, a stable phone number, a bank account, and repeated verification steps, the system stops behaving like a public support mechanism and starts behaving like a compliance filter. That shift matters most for unemployed and informal workers because their circumstances often make every one of those assumptions less reliable.

The exclusion is usually cumulative rather than caused by one broken step. A person may be able to complete registration but fail at authentication, or pass verification but be unable to receive funds because the payout method is tied to formal banking. The design problem is not digitality itself, but the way multiple prerequisites stack up at the same time and turn a benefit into something that is easier to lose than to obtain.

For systems that rely on repeated identity checks, the burden is also temporal. People who are already under financial pressure are least able to absorb delays, retries, lost messages, or failed resets. That means the system punishes instability, which is exactly the condition unemployment and informal work produce.

Which design choices make the exclusion structural

The main failure is not a single bad form or a single authentication step. It is the composition of requirements that assume a formal labour and financial profile: device ownership, data access, digital literacy, phone continuity, bank-linked identity, and tolerance for multi-step verification. If any one of those is missing, the whole pathway can break.

Identity proofing and repeated verification can be especially harsh when they are treated as neutral controls rather than as frictions with unequal impact. A system that asks users to reprove who they are every time they re-enter the process may look secure on paper, but in practice it increases drop-off among people who cannot easily keep a number, a document trail, or a stable online session. The same is true when disbursement is tied to banking status instead of payment methods that match the population actually being served.

There is also a governance issue. When agencies optimise for fraud reduction without measuring access failure, they may celebrate stronger controls while missing the fact that legitimate applicants are being screened out. A benefit platform can be technically operational and still be socially inaccessible.

Why the problem is worse for unemployed and informal workers

Unemployed people often have weaker digital continuity because they are already managing instability in income, housing, connectivity, and documentation. Informal workers face a different but related issue: their work may be real and regular, yet not captured well by systems built around payroll records, employer references, or formal banking. In both cases, the benefit platform expects proofs and dependencies that do not match lived reality.

This is why “more secure” or “more efficient” digitalisation can deepen exclusion if the control model is not population-aware. A system built around the easiest-to-verify applicant will systematically fit formally employed users better than the people most likely to need support. That is a design bias, not an edge case.

Digital benefit systems also create asymmetric failure. The organisation can recover from a failed login or missed verification with little consequence, but the applicant may lose days, transport money, work opportunities, or even the chance to reapply within a deadline. The cost of failure is therefore transferred downward onto the person with the least capacity to absorb it.

Risk and Threat Considerations

When benefit delivery depends on digital identity checks, connectivity, and banking rails, the risk is not only exclusion, but silent exclusion at scale. The system can appear to function while disproportionately filtering out the very groups it was meant to support, especially when repeated verification and channel dependency create multiple points of failure.

Failure mechanism: Each extra prerequisite, device access, network access, phone continuity, bank linkage, identity re-verification, increases the chance that legitimate users will drop out before completion or be unable to recover from a failed step.

Impact: Eligible people are pushed out of the access path, uptake falls, and the benefit system amplifies existing inequality rather than reducing it.

Practitioner Guidance

What to prioritise: Measure access failure separately from fraud prevention. If a control reduces fraud but also increases abandonment, failed verification, or payout blockage among unemployed or informal workers, it is not neutral, it is redistributing harm.

What to verify: Check whether the benefit can be completed without requiring all of the following at once: persistent smartphone access, live connectivity, bank account ownership, and repeated re-authentication. The more of those that are mandatory, the more likely the system is to exclude the intended population.

Decision rule: If the user can prove eligibility but cannot satisfy the delivery channel, treat that as an access-design failure, not a user failure. The system should adapt the channel to the claimant where possible, not force the claimant to adapt to the system.

Practitioner takeaway: For benefit systems, the real test is not whether the platform is secure or digital, but whether the controls still let the intended recipients complete the journey under realistic conditions of poverty, instability, and intermittent access.

Related resources from NHI Mgmt Group

• How should public service teams design digital identity systems for people who are unemployed or under-employed?
• Why do digital identity systems create different risks for unemployed people, migrants, and other marginalised groups?
• How should organisations govern selective disclosure in digital identity systems?
• Why do digital credentials not replace authorization controls in enterprise systems?