Remote Aadhaar Seeding Framework

Introduction
As the number of Aadhaars generated has increased, the focus at many States has
shifted to Aadhaar enablement of service delivery applications. Service providers
who integrate with UIDAI’s platform have to overcome the challenge of linking their
database records of customers and beneficiaries with the 12-digit Aadhaar numbers.
Currently most seeding initiatives are organic and limited in scale because of some
of the challenges listed in the previous section. Further since service delivery
databases are owned by various departments, organic seeding initiatives at a
scheme or department level leads to inconvenience for the resident who is a
beneficiary of multiple services from various departments. Finally there are different
levels of infrastructure/ personnel availability at different states as well as differing
channels and processes being used.
UIDAI has been closely involved in enabling States in implementing Aadhaar
enabled service delivery through a variety of initiatives such as the ICT assistance,
coordinated pilot programs, SRDH software and support etc. Along the same lines,
UIDAI currently proposes to enable service delivery owners in expediting seeding of
their databases by developing and hosting an online platform called the Remote
Aadhaar Seeding Framework (RASF) application.
The RASF application is a central platform that enables converging various seeding
channels into one
central staging area
which is then
accessible to
operators at various
departments (service
delivery owners) for
verification of the
seeding and inclusion
into their service
delivery databases.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 15 of 19
The RASF application aims to provide:
1. Online convergence platform for multiple seeding channels and a ready-made
SMS/ online resident self-service channel for the States usage.
2. Controlled access for department operators to verify seeding by comparing
beneficiary record at the department with the UIDAI resident KYR data from
SRDH web services.
3. MIS, fine grained user access management, audit trails and data
import/export features to enable states to adopt a consistent effective and
efficient approach to multi-channel seeding.
3.2 High Level Features
The key high level features of RASF are:
1. Support multiple Seeding Input Channels
a. SMS-Based seeding
b. Online/ Web-Based seeding
c. CSV maps (SRDH compliant formats from camps/ CSCs/ third party seeders/
state SRDH etc.)
d. All seeding requests irrespective of channel would validate availability of all
mandatory inputs, reject duplicate requests and ensure validity of UID number
through Verhoeff algorithm.
2. Verification Utility
a. Plain vanilla Input Viewer
b. Service Delivery data and/ or SRDH Integrated Viewer
3. Fine grained user access management
4. Audit Trails
5. MIS Reports
a. By service domain or scheme (e.g.: PDS)
b. By Geographic area (e.g.: State or Pincode or District)
c. By User (e.g.: Seeder or Verifier or Admin etc.)
d. By any combination of above
*The RASF will utilize the same pincode master database as the enrolment client does for
geographical master data such as states/ districts/ pincodes/ vtc etc.
*RASF will use HTTPS during data transfer as well as use captcha, OTP and
username/password based access control other than auditing all transactions in order to
appropriately handle security considerations.
3.3 Users and Roles
Fine grained access control is expected to be available wherein access can be restricted by
any combination of (a) application feature, (b) geographic area data constraint (state), (c)
service/ scheme domain (PDS/ MNREGA/ JSY etc.) and (d) read/ write access.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 16 of 19
Five primary types of users are envisaged for the RASF application framework, namely
RASF administrator, State administrators, Seeders, Residents and Verifiers. A brief
overview of the typical user types is as below:
3.3.1 RASF Administrator
The RASF administrator at UIDAI can
1. Create/ Modify/ Delete
a. State Administrators (restricted by State)
b. New service domains (Department-Scheme Master)
2. Generate MIS reports
3. Add/ Remove the State SRDH web service integration detail
3.3.2 State Administrators
The State administrator is typically from the State nodal agency and is the administrator for
the State and can
1. Create/ Modify/ Delete
a. Department Administrators (restricted by Department)
2. Generate MIS reports (for the particular State only)
3.3.3 Department Administrators
The Department administrator is typically from any department in the state and is the
administrator for the Department and can
1. Create/ Modify/ Delete
a. Seeders (can be restricted by service domains and geographical areas)
b. Verifiers (can be restricted by service domains)
2. Upload Department KYR data as CSV
3. Generate MIS reports (for the particular Department only)
3.3.4 Seeders
Seeders are approved for access by the Department administrator and can
1. Upload seeding records in single mode through SMS and Online channels
2. Upload seeding records in batch mode through Excel upload channel
3.3.5 Verifiers
Verifiers are approved for access by the Department administrator and can
1. Accept or reject seeding requests from residents and seeders.
2. See MIS reports of their own usage
3.3.6 Residents
Residents can access RASF only after OTP (one time password) authentication and can
place their KYR+ seeding requests either through the SMS or Online channels only.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 17 of 19
3.4 Business Architecture &Process Flow
RASF is to be hosted at UIDAI. The deployment overview of RASF is as shown below:
The primary process flow as expected for RASF is shown below:
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 18 of 19
Some of the key points to note corresponding to the process flow as shown above are:
1. The RASF admin is from UIDAI and primarily creates the State administrators (step
1) and the master data (step 2). Other than these two activities, UIDAI uses RASF
only for MIS reports. RASF is managed and used by the State administrators
and other users.
2. States can onboard third party seeders (step 4) to conduct camps/ door to door
campaigns etc. The seeders can then upload seeding requests to RASF. This is
similar to registrars using enrolment agencies for Aadhaar enrolments.
3. SRDH enables verifiers to view UID KYR record for a given seeding request. SRDH
is typically deployed at the State and not by UIDAI. Hence it is the State
administrators’ responsibility to provide the web service details of SRDH as
configuration details to the RASF administrator. Note that SRDH is not necessary
(i.e. verification screen will work without SRDH; this is allowed since verifier might
have access to UID KYR data through some other application outside RASF) but is
highly recommended.
4. A seeding request can come from any channel and consists of a mapping of
Aadhaar number and beneficiary ID (steps 5a or 5b). Seeding requests can be in
single mode (SMS or online request) or batch mode (CSV upload by seeder).
RASF will have pre-determined CSV input format which will be aligned with the
SRDH manual and batch seeding CSV formats. This enables the SRDH user at
the State to upload the CSV to RASF for verification as a seeder.
5. RASF will also highlight to the seeder at the time of seeding request itself (steps
5a and 5b) if one or more of the requests are already accepted valid seeding
from other requests. This requires that RASF always stores the basic request map
even after acceptance by verifiers.
6. Verifiers can compare the UID KYR record to the department KYR record for
verification. Note that SRDH view is available within RASF if the web service is
configured by state admin. It is also possible that the verifier uses SRDH outside
RASF. Similarly the department KYR view is available within RASF if the department
admin has uploaded the department data as CSV. It is again possible that the
verifier uses some other application outside RASF to access and view
department KYR records.
7. Note that after verification, verifiers can export the valid accepted maps as CSV. This
ensures that RASF requires no integration to various service delivery
databases.
8. It is recommended that verifiers are from the service departments (or trusted
third parties chosen by the respective departments) since this creates ownership
of the seeding.
9. It needs to be noted that most of the current challenges faced by seeding initiatives
can be overcome by careful choice of seeding channels. However each seeding
channel has its own pros and cons. For example departmental data in local language
data is a significant issue in inorganic seeding but however is not a hurdle for organic
seeding where the verifier is competent in the local language.
10. UIDAI provides RASF only as an enabling tool for seeding efforts and it is not meant
to replace any existing or envisaged efforts. UIDAI intends to improve RASF and
provide iterations in the near future.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 19 of 19
3.5 Conclusion
A multi-channel convergence approach to seeding can help overcome current
challenges and importantly scale seeding efforts significantly where each channels’
weakness is compensated by usage of other channels. Further since seeding inherently
requires manual comparison of data is most cases, it is important to enable a large
number of verifiers in the ecosystem to be able to work in a coordinated fashion to
effectively scale operations. RASF aims to provide a consistent process oriented
approach to large scale multichannel seeding and hopes to expedite Aadhaar seeding
across the nation.

AAdhar Challenges in Seeding

It is important to understand the common challenges in seeding so that appropriate
approach can be planned and necessary guidelines and processes be put in place. It is
important to note that the challenges being described in this section cover the overall picture
comprising of various service delivery databases across many states as well as multiple
seeding initiatives using varied channels being undertaken and so some of those are generic
while others are specific to a particular channel. Below are the some of the challenges that
seeding initiatives have been faced with:

1. Quality& Availability of Beneficiary data in Service Delivery databases:
Beneficiary databases have multiple data quality issues. Some of the most common
data quality issues are: errors in the data such as misspelt names/ wrong date of
births, out of date addresses etc. Beneficiary databases are yet to be digitized in
some cases, are distributed across multiple sources (such as district-wise etc.) with
duplication within and across sources, missing fields of KYR or photo data which is
very often because the particular service scheme does not mandate those fields etc.
 
2. Quality of UIDAI Enrolment KYR Data: Considerable improvements in the quality of
the master pincode database (address master which the enrolment client uses),
multiple versions of the enrolment client with improved features to ensure data quality
and transliteration have evolved since enrolments began. This has resulted in
significantly improved quality of enrolment KYR data in later phases of enrolments. In
earlier enrolments however there are cases of misspelt district names, wrongly
mapped pincode to VTC, redundant address fields, poor transliteration etc. Many
seeding initiatives currently are focused on geographic areas where high percentage
of enrolments have been done which naturally uses early enrolment data (early
enrolments = higher percentage of enrolments).
 
3. Availability of UIDAI Enrolment KYR Data: Availability of the UIDAI KYR resident
database (SRDH or equivalent) is critical to seeding initiatives especially for the
inorganic seeding channels and is also critical for verification of seeding irrespective
of channel. Currently very few States have a production quality (accessibility &
performance) resident KYR database with most available enrolment KYR data
available.
 
4. Quality& Availability of UIDAI Enrolment KYR+ Data: KYR+ data is not collected
in all States and among States that do collect KYR+ fields, different States collect
different sets of fields. In all cases, KYR+ data fields are optional during enrolments.
Even in States where KYR+ data is collected, very often residents have opted not to
provide the information and when provided the data is often found unreliable
(erroneous).
 
5. Language of Beneficiary data in Service Delivery databases: Many service
delivery databases in States are in the local language. However the software tools
that compare the SRDH KYR data to beneficiary KYR data are usable only for
English data.
 
6. Mobilization of Residents: Many organic seeding channels require the mobilization
of residents. Mobilization of residents is difficult, tedious and causes inconvenience
to residents.
 
7. Software & Hardware Infrastructure: Large scale seeding initiatives across multiple
service delivery databases is the need of the hour to expedite Aadhaar enabled
service delivery. This requires fairly significant hardware and scalable high
performing software. Most importantly it requires easy to use tools and availability of
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 12 of 19
the data through the software for both seeding and seeding verification efforts in the
field to multiple stakeholders.
 
8. Change Management: One of the most significant hurdles in seeding initiatives
currently is many misunderstandings around the concept of seeding and lack of
clarity in the way forward. Some of the common clichés include:
• “Tool ‘X’ does 65% seeding, how much does tool ‘Y’ do?”
– Comparisons between tools is valid only if both tool ‘X’ and ‘Y’ is being used
on
- Same set of UIDAI KYR data (because % seedable is a factor of
availability)
- Same department data (because % seedable is a factor of
quality/quantity of department data which varies state to state and
among departments in state)
• “Accuracy cannot be guaranteed by seeding algorithm ‘X’”
– Accuracy cannot be guaranteed by any seeding algorithm. Our recommended
strategy is to bring Aadhaar numbers into department data marking them as
unverified and putting in place appropriate process to verify through operators
or at transaction point with beneficiary.
– This additionally allows resident to check Aadhaar KYR data and update at
CIDR if necessary (using update channels). If resident verifies seeding and
confirms Aadhaar data correctness, department can over-ride existing
department KYR data (cleaning)
• “Residence presence is required for seeding verification, so algorithmic seeding is
useless”
– Mobilizing residents for seeding is not an easy exercise (note KYR+ collection
success/ failure where mobilization was due to enrolment)
– Is 100% accuracy of seeding a must? Answer should depend on particular
transaction with department for a given scheme. 80% seeding with 1% errors
vs. 20% seeding with 0.1% errors argument.
– Resident presence just for seeding might not be resident-centric, should at
least be for all departments in one visit
– Resident presence although helpful is not necessary. Resident self-service
channels such as SMS and Online portal can be leveraged.
• “So how many duplicates/ bogus records have seeding removed?”
– It should be noted that only when Aadhaar is mandated for a scheme within a
geographical area can there be removal of duplicates/ bogus etc. If a
database has beneficiary records without Aadhaar numbers, there could be
duplicates among themselves or a duplicate of a record with Aadhaar
number. They could also be bogus records. Seeding searches can indicate
duplicates but department will have to reach out and check before removing
• “We should be using bio-auth to ensure seeding accuracy”
– Bio-auth can only tie the Aadhaar number to the person. Seeding is trying to
tie the Aadhaar record to the department record. You could very well tie an
authenticated Aadhaar record to the wrong department record (where KYR
data looks similar).

Channels for Seeding & KYR Plus

Seeding initiatives could be of many types referred to here as ‘channels’ which provide the
source of seeding such as KYR+, SMS or Online based resident/ assisted self-seeding,
manual seeding at point of service, algorithmic seeding etc. Below is a brief overview of the
most prevalent channels:

KYR Plus
Many States have collected various other IDs (such as passport number, PAN number,
Voter ID, Ration Card number etc.) along with the Aadhaar enrollment data. This data is
collectively known as KYR+. Hence at enrolment, few other IDs are already mapped to EIDs.
With the EID-UID map and KYR data available in the State resident database, seeding of the
service delivery database using the EID to beneficiary ID available in KYR+ can be used.
It is important to note in this context that
 not all States collect any KYR+ IDs,
 different States collect different IDs as part of KYR+,
 where collected, it is optional and most residents have not provided the data
 And finally very often the quality of KYR+ data collected is found to be unreliable

AAdhar Seeding Concept

Aadhaar seeding is a process by which UIDs of residents are included in the service delivery
database of service providers for enabling Aadhaar based authentication during service
delivery, linking of UID to beneficiary ID.
As an example, MNREGA will require authentication before payout therefore in such a
scenario, it will be essential to map UID of the resident with MNREGA Job Card number and
other demographic information. Similarly, banks and insurance carriers may want to map
Aadhaar numbers of all their customers. The objective is not to replace the currently used
unique identifier of the customers/ residents/ beneficiaries with Aadhaar but the objective is
to seamlessly enable Aadhaar authentication without impacting any other interface that the
service providers maintain with their customers.
Aadhaar enrolment involves collection of basic demographic details (called Know Your
Resident (KYR) data) along with biometrics and photograph and generation of EID
(Enrollment ID) which is a transaction reference number. After due processing, UIDAI
generated UID numbers for enrollments that are accepted (based on de-duplication and
quality). The KYR data and photo along with EID and UID numbers are published by UIDAI
back to the registrars as EID-UID XML files.

Aadhaar Enabled Service Delivery

Aadhaar aims to provide an identity infrastructure for delivery of various social welfare
programs and for effective targeting of these services. While welfare is the prime focus of
Aadhaar, it can also be utilized by other enterprises and service providers such as banks,
telcos and others for improving their service delivery.
Applications that use Aadhaar authentication to identify and authenticate the resident as part
of their service delivery are referred to as Aadhaar-enabled applications. The usage of
Aadhaar enabled applications for service delivery is broadly referred to here as “Aadhaar
Enabled Service Delivery”.
Government to Citizen (G2C) Service delivery is currently carried out independently for
various schemes by government departments and in most cases, the required data,
systems, processes and infrastructure is all owned and managed by the departments as
separate initiatives. In the recent past, consolidation at various levels with a view of providing
more effective and efficient resident-friendly service delivery has taken place. For example
there has been consolidation of the service delivery front end (primarily through citizen
service centers).

Aadhaar in service delivery is primarily aimed at revolutionizing identity authentication and
also financial payments. The business architecture of such a service delivery infrastructure
can be visualized