The novel coronavirus pandemic has forced the Department of Personnel and Training (DoPT) to suspend all Aadhaar-based attendance systems inside government offices. While this has come a relief for government employees, that same courtesy has not been extended to the beneficiaries of India’s welfare schemes. Some state governments have taken a proactive approach, stopping biometric authentication for pensions and PDS, but others have still continued with the same.
While the belief that COVID-19 could spread through the use of Aadhaar biometric machines is not unfounded, the real problem with India’s direct benefit transfer (DBT) model is actually the failure rates.
DBT transactions do not always succeed, and the government has not done enough to solve these transactional failures over the past few years.
UIDAI itself publishes around 95 types of errors with the Aadhaar authentication system on its website. Everything from biometrics not matching to duplicate iris to invalid Aadhaar number to even an unknown error with the code “999” are mentioned. While these have been defined in UIDAI’s own documents, there is a severe lack of information on transaction failure rates and what happens during a failure of authentication.
The UIDAI has always argued their failure rates are very minimal, but at the same time never supplying data that allows a full independent check.
Any possible errors are not limited to UIDAI in the ecosystem, since the Direct Benefit Transfer (DBT) model involves multiple entities and departments. The first step in electronic delivery of subsidy is Aadhaar – and an error there can halt everything. The second phase of errors that are quite often seen are with the Point of Sale (POS) machines not functioning properly. A Department of Fertilisers DBT manual shows how their PoS systems have potential problems related to battery, software, and network issues. If everything works in these two stages of authenticating oneself at the PoS machines, with the Aadhaar gods also in favour, the table then belongs in the court of banks.
Banking systems are not simple transactions where money is transferred from the Consolidated Fund of India to the bank account of an individual beneficiary. The Aadhaar-based DBT architecture created additional layers than did not previously exist. DBT using NEFT has one middle layer between banks with the RBI.
However, with Aadhaar, an extra layer was introduced where NPCI was required to create an NPCI-Aadhaar mapper in order to facilitate the transfer of funds. This mapper is the backbone of Aadhaar Payments Bridge (APB) and Aadhaar-enabled Payment System (AePS).
Aadhaar Payments Bridge manual records that the NPCI-Aadhaar mapper has 20 odd error codes. Withdrawing the DBT money using AePS is not straightforward either with around 200 errors as mentioned in an NPCI circular. There are more errors in case of National Automated Clearing House when transactions fail and the amount is returned back. While there are many of these errors and their codes, standardisation of error codes is not yet complete, and we don’t know the various numbers or types of sub-errors of each individual system.
In all, the different permutations of errors that can result in failures of DBT is unknown and it won’t be easy to map this out for an outsider with the number of blackbox institutions involved. The Reserve Bank of India, which collects large scale data on payments within the country won’t tell us what is happening with general payments failure rates like say UPI. These systems are complex and are blackboxes by design. A typical error every beneficiary is facing is with regard to the bank account to which their funds are being credited.
This issue became apparent when DBT money started getting credited into Airtel payments bank accounts created without the knowledge and consent of over 31 crore individuals. NPCI and UIDAI had to scramble to fix a design problem with the NPCI-Aadhaar mapper by bringing in ‘offline consent’ into their architecture. The fragility of these banking systems got exposed with the Airtel payments banks case.
Errors in DBT are reported to DBT mission using DBT-09 reports which include failure details of every transaction. This data is, unfortunately, not public. While one can file a Right to Information request to obtain it, it is not easy to navigate our RTI machinery.
To understand the scale of errors, the DBT mission carried out an internal study using raw data from the Public Financial Management System (PFMS) portal which is used to manage DBT transactions. The raw data of 6.85 crore transactions from November 1 to December 13, 2018 was analysed.
According to the mission, 0.91% transactions (i.e. 6.2 lakh) resulted in failure. A further analysis of these 6.2 lakh failures showed that 17,375 transactions (2.9%) were due to payment limits on small accounts; or accounts being inoperative/inactive/dormant, pending verification of KYC. 52,529 transactions had an unknown error code of “R11” being returned by the RBI.
The summary of the data analysis gives us the following sub issues encountered with DBT failures:
- 53,270 (8.6%) transactions of 6.2 lakh failures were because of accounts being blocked by banks.
- 52,529 (8.5%) transactions of 6.2 lakh failures were because of unknown error of R11 in NEFT.
- 15,505 (2.5%) transactions of 6.2 lakh failures were because of limits on small accounts
- 1554 (0.3%) transactions of 6.2 lakh failures were because of inoperative/dormant accounts.
- 316 (0.1%) transactions of 6.2 lakh failures were because of first transactions pending by account holders
- 271 (0.1%) transactions of 6.2 lakh failures were because of KYC pending
- 6 0.0% transactions of 6.2 lakh failures did not have a return code for credit transactions
- 4,97,593 (80.2%) transactions of 6.2 lakh failures were because of other issues not listed above. The statistical details of these error codes were not available in concerned files inspected under RTI.
But with the errors in this complex ecosystem causing failures, the department of financial services identified 12 types of failures for DBT payments that could be fixed. DBT Mission asked banks to follow the NPCI’s Standard Operating Procedure on Aadhaar Payments Bridge to eliminate these six types of errors: these include
i) Aadhaar number not mapped to the Account number,
ii) Account closed/transferred,
iii) Account Holder expired,
iv) Invalid Account
v) Account under litigation, and
vi) Documents pending for Account holder turning major.
The banks were also asked to follow the instructions from RBI, NPCI and the Department of Financial Services to fix the six other types of DBT return failures. These six are i) Account reached maximum credit limit set on account by bank ii)Amount exceeds limit set on Account by Bank for Credit per Transaction iii) Customer to refer to branch iv) Dormant Account v) Account inoperative and vi) Network failure.
Explaining these errors to the normal public is nearly impossible when all institutions claim that there are no problems with their systems and processes. Furthermore, holding any one particular institution responsible for a DBT failure transaction is near impossible when we don’t know at which exact stage the transactions failed.
It is unfortunate that the statistical data does not tell us exactly who is not receiving their benefits — but the ministries and other departments have this information. Even with all the information, the errors in DBT transactions could mean that people are starving, suffering because of poor healthcare, or even dying.
No amount of technology or data can stop that, we must audit these systems to make them accountable to the people. The current mechanisms have been reduced to a black-box full of errors. RTI requests filed with ministries have so far resulted in some information being shared, which is currently being collated and archived for public consumption.
Srinivas Kodali is an independent researcher and studies the effect of technology on society. This article was first published on Kaarana. The DBT 09 failure data obtained under RTI, mentioned in the article is available here.