Computerisation of Registration and Stamps.

Department-SAMPADA, Madhya Pradesh

Dipali Rastogi Inspector General, Registration and Superintendent of Stamps (IGRS), of the
Department of Registration and Stamps (DR5), Madhya Pradesh (MP), India, and Manoj
Shrivastav, Principal Secretary, Commercial Tax Department, Government of MP, were
reviewing their key initiative-the fully consputazised property registration system named the
Stamps and Management of Property and Documents Application (SAMPADA) in 2019. It had
been picted in December 2014 and rolled out state wide is July 2015.

The DRS was one of the largest sources of revanus. Since the state government levied
stamp duty based on the value of the property being transacted, there was rampant
understatement of the same for registration. The buyer/seller thus began to informally
receive/pay the difference in actual and transacted value, usually in cash. This led to an
absence of a formal accounting trail and became a major source of loss for the government.
Corruption was widespread as several concerned stakeholders in the registration procavs
started adopting ill practices to get their "share" of the informal transaction

By taking a concerted lead in fully computerising the property registration process through
SAMPADA in 2015, the BGRS brought in transparency and ease of transactions for citizens.
The system would n complete four successful years after implementation. Since the system
had. been in the process of design and implementation from 2006, and given the fast pace
of technological changes, Rastogi expected that soon it would require upgradation/changes.
What challenges would the next steps bring? How should the DRS organise itself to face
those challenges?

DEPARTMENT OF REGISTRATIONS AND STAMPS

The DRS came under the purview of the Department of Commercial Taxes. It was headed by
the IGRS and had four zonal offices in Bhopal, Gwalior, Jabalpur and Indore. These wer
serviced through 51 district registrar and 234 sub-registrar offices across MP. Exhibit 1
presents the ma map and basic demographic mographic information on MP, along with the
location of the DRS.

The DRS registered deeds related to the transaction of property under the Registration Act
1908, and the Indian Stamp Act, 1999, epplicable in the state. Approximately 700,000
documents were registered by the DRS annually. These were related to movable and
immovable property such as plots, agricultural lands, flats, etc. Government functions stamp
vendors, lawyers/advocates, service providers and citizens of the DRS

THE MANUAL SYSTEM Befora computarisation, property registration consisted of the

following she steps: 1. Valuation Valuation of the property was guided by "circle/guideline
rates or guidelines published by govemment. This done to ensure that the transacting
parties did not value the property at rates lower than the prevalent ones to reduce the
payable stamp duty. Aftse discussions that went on for four to five months, circle/guidelane
zates were decided by a comuuttee with representatives from the departments of of
Irrigation, Public Works, Water Resource urce, Municipal Council, Forest, Forest, Housing
Board and Development Authority. (Exhibit 2 briefly explains the process of guideline
creation by the state government.) The committee took into account more than 200 criteria
such as location (corner plot, distance from a highway, etc.), quality of construction and type
of property (commancial, warehouse, residence, independent housing). 2. Determining
Market Rate. Once the valuation complete, the seller and buver mutually agreed on a selling
price for the propesty known as the market rate. The market rate corald be higher or lower
than the government-specified circle/guideline rates. Calculation of Stamp Duty: The
market and circle/guideline rates were used to calculate stamp duty, a tac forming a
significant component of the property transaction. The stamp duty was calculated as a
percentage of circle/guideline rate or market rate, whichever was higher. Owing to the
complexity and inadequate documentation regarding the valuation process, citizens were
dependent on lawyers or document writers for valuation and stamp duty calculation. Often
they would calculate a high circle/guideline rate for the citizens and then aak interpretation
of the rules fot bribes to bring it down by using flexibility in the Procuring Stamp Papers.
Stamp papers were available only in pre specified denominations and could be bought from
any licenced stamp vendors who were private entities by paying cash. These were printed
and issued by the government and available at treasury offices located in each district
headquarters and some sub districts. Stamp vendors made payments for stamp papers at
nationalised banks. The receipt of the payment was necessary to get the papers tsued from
the treasury officer (TO) In return, stamp vendors eamed a commission of 1.5% on the value
of each stamp paper A Treasury Office was headed by the TO who had exclusive rights
access the safaty vaults in which stamp papers ware stored. Stamp vunders or citizens
usually had difficulties in a acquiring stamp papers without delay and usually had to make
multiple trips to the office. The limited locations from where these could be issued, the
several steps involved in the process, the uncertainty of the availability of the TO

and malpractices of some officials at times led the citizans to be largely dependent on stamp
vendors

Stamp vendors usually kept stamp papers whose total valise low. These usually lower
denomination as there there was gap between between the time parments for them and the
citizen's purchase. they made they mad large value transactions, the number of stamp
papers required was more not only because of the greater value of the stamp duty, but also
to limited or non-availability of relatively hugher denomination stamp papers with statup
vendors. Even considering the highest denominated stamp paper of of INR 25,000, greater
numbers were required for any small-or medium-sized deals, say of around INR 1,000,000
Just getting the required. stamp papers could sanily take 5-10 days.

5. Deed Creation. The next step in the process was deed creation. A deed is a recital
between na frayer and seller executed on the stamp paper and notes the nature of the
transaction and details of the property and transacting parties. Due to a lack of know-how,
difficult for a layperson to create a deed without the help of document writers or lawyers.

Property Registration. Once the deed was created, the transacting parties along with two
witnesses visited the local sub registrar office for registration of their property The original
deed, a copy of the deed on yellow coloured paper (called office copy), stamp papers,
passport size photographs of the buyes, seller and witnesses, and their identification
documents were submitted

The sub-registrar verified deed and identification documents of transacting parties and
witnesses. The stamp papers attached with the deed were counted by registration clerks
known as the registration moharris The stamp paper denominations were handwritten in red
ink the yellow copy of the deed for official records. Subsequently, the sub-registrar verified
the documents and obtained thumb impremons and photographs of buyer, seller and
witnesses, physically stamped the documents for the transacting parties and the yellow
copy was stored for official records

Under ideal conditione, a sale deed could be obtained from the sub-registrar office 4-5 days
after registration. However, in reality, the process could easily take weeks or even months
departmental mocesses manual, error-prone and time-consuming Citizers thus had to make
multiple trips to the sub-registrar office to obtain the official sale deed.
The detailed process of property registration is presented in Exhibet 3.

CHALLENGES IN THE OLD SYSTEM

Besides the process issues highlighted above, the challenges in the old system included the
following

Infrastructure Apart from the cumbersome and opaque systems mentioned in the earlies
section, the infrastructure of the office and sturerooms for keeping physical records was
decrepit and made worse by tha chemicals such as anhydrous silical gal (to maintain proper
bumidity) used in record rooms and stored in the vicinity. There was also no electronic
connectivity between offices.

Storage and Management of Physical Stamps: There was a huge cost involved in printing
storage, distribution, accounting and security of stamp papers as these needed to be
accounted for at each stage

Management of Old Records: The record rooms were old, strewn with documents and
infested with microbes with a probability of rats, lermiles, ele, infesting them as shown in
Figure 1. The indexes were created manually and poorly maintained, causing delays in the
search, and often a reason for demanding bribes by unscrupulous employees.

EARLY ATTEMPTS AT COMPUTERIZATION

Given the scope for streamlining the processes and gaps in data availability, the DRS
considered the property registration process for computerisation several times. An initial
conceptualisation was made in 2006 and the DRS floated separate tenders for application
development, deployment of servers, hardware, setting up data centre and so on.
Recognising the complexity wack of inhoudspertise for implementing state-soide vystem,
Infotech was onboarded as project management consultant (PMC), which combined the
tender requirements into two request for proposals (RFP)-application development and
system integration. As a result, two tenders were floated by the DRS. Exhibit & briefly
provides information on the selected vendors-31 Infotech and Wipro. The software
requirement specification (SRS) was developed by 2008. However, engaging a system
integrator (51) toolk considerable time as project had earlier gone through gh several
several unsuccessful bidding processes. Vendors quoted low prices to get shortlisted and
were unable to execute, and thus abandoned the project. The RFP was floated again in
2011, but participation was highly unsatisfactory. Bidders did not meet the technical criteria
and hence the tender was scrapped once again. Due to significant delays in engaging an 51,
the computerisation project was deadlocked for the PMC as they we were still bound to work
on the fin financials agreed upon at the beginning of the project in 2005/6. Further, frequent
changes at the IGRS laval, poor badding outcomes and a lack of vision for manual vvuteen
until 2014 end-to-end solution resulted in the continuation of the Готазар

STAMPS AND MANAGEMENT OF PROPERTY AND DOCUMENTS APPLICATION

In order to address the gaps in the existing system and develop a state-of-the-art system in
the DRS, the SAMPADA was designed to streamline the property registration process. It was
conceptualised as a cashless, end-to-end integrated web-based solution connecting all
offices of the DRS, citizent, simplify banks and other stakeholders to the state government.
emment. It was envisaged all departmental processes providing online facility for document
preparation, property valuation, duty calculation, fee payment, e-stamping, slot booking,
document searching and certification across the state, accessible from any location the
DIRS,
It simplified the comples part of part of deed creation by standardising the types of deeds
and making editable model deeds available online. A urer could search for a registered
deed, possibly with a similar context, view a modal deed and create a naw one. This
reduced, or even eliminated, the need for document writers or lawyers for writing the deed.
For citizens who needed assistance, a service provider (5P) was instituted whom they could
approach for creating a deed and payment of stamp duty.

The SAMPADA designed to generate online e-stamps and completely removed stamp papers
from the system. E-stamps solved the problems of counterfeiting, artificial scarcity and
reuse which were prevalent in the manual system. Besides this, the DRS ensured that e-
stamp codes were easily searchable online so t that data could I be validated easily. Exhibits
Ja and 56 sumanarise the process flow and changes introduced by the SAMPADA The The
system would also provide a tracking facility to citizens through 515 and email. It was
proposed by the IGRS in 2005 with an implementation timeline of 12 months. Exhibit 6
provides the timeline and value of SAMPADA tenders.

The SAMPADA implementation had the following features:

Changes in Roles and Responsibilities

Service Providers. To ovenme the resistance by stamp vendors, their role was re-defined as
that of 5Ps and retained in the new system. It was envisaged that the SP would facilitate
document registration and e-stamping. E-stamps were designed to be issued by the SP
against a credit lumut that they established with the cyber treasury (no upper bound on the
lumits was stated). Since e-stamps were generated by the software, these were not
designed for specified. fied denominations, unlike in the manual system. E-stamping allowed
an SP to be anywhere in the state and and transact business The flexibility on denomination
limits and geographical location facilitated 5Ps to increase the number of citizens they could
serve.

Licences for becoming an 5P were given to those who met the specified eligibility criteria,
underwent a training programme and pass a test. There were many new applicants for this
role. Since the SP got 1.5 of the stamp duty as commission. it was a new source of s rurce of
revenue for the new applicants. An SP needed to have passed Class 12, be computer
literate, have sound knowledge of the registration and stamping act and have the promises
to install a computer and printer

In order to standardise pro встояя SP a comprehensive list tof empanelled printers priced
between INR 5,000 and d INR 275,000 was provided on the DRS website. Depending on their
financial capability and volume of transactions, 5Ps could buy any one of the listed paintars.
For example, banks usually preferred high-end printers due to the greater volume of
transactions, whereas individual SPs preferred a lower priced printer. The list of empanelled
printers was updated as and when the watermark stamping agency updated original
equipment marmufacturers (OEMs) or printer requirements

More than 6,000 SPs and 34 banks, including the largest ones like the State Bank of India,
ICICI Bark, Bank of Baroda, Oriental Bank and Punjab National Bank, and post offices were
also engaged for deliver dalivery of services to Bank officials were given the privileges of
public citizens. Bank officers, and could validate e-stamps and provide document verification
services. This reduced the length of queues and workload at the registrar and sub-registrar
offices

Makers: To enhance the speed of operation, activities such as verification of registration

details, capturing photographs of transacting tran parties through a vo ebcam, cam,
checking IDs of the e consenters, witnesses and printing documents post verification, which
were essential, but not core to the registration process, were outsourced agency called UST
Global. The agency was responsible for hang computer operators known as "makers".
Makers could also be the document writers of the manual system. Payment from the DRS for
such services was based on meeting service level vel agreements (SLAs) For example, if a
delivered within 15 minutes, a penalty was impo posed on document not printed and the
vendor, Introduction of makers increased the efficiency of sub-registrars, acted as checkers
such as verifying applications, approving registrations and taking necessary action in case of
ambiguity and frauds. Departmental employees, however, were also trained in this sole for
various offices with the

view to catch up with the digital transformation and for them to completely own the roles
and zesponsibilities

In-charge Sub-registrar. The sole of the registration mohanis became radundant after
computerisation. However, as they had sound knowledge of the departmental processes,
their cole was re-defined. They were retained 1 in the new system as in-charge sub-
registrars, who took over the role of the sub-registrar in the latter's absence. In addition, the
l lack of m manpower in the sub-registrar offices was overcome by deputing in-charge sub-
registrars on a need basis

Other Roles: District registrars and sub-registrars were designated as e-governancs

managers, assistant e managers in every district provided training to the department and
users the role of lead trainers for smooth adoption of the new system

Document Security

Since the DRS wanted to eliminate any chances of fraud, it was decided to implement a
security Feature in the form of an optical wa mark. Specifications of the optical watermark
engine were provided in the RFP of 51. Thus included the state emblem of a banyan tree in
the centre of the page, the watermark with the inscription "MP-IGRS" at the bottom of every
page, microprint bearing registration number and a cryptomark bearing the stamp code e-
registered document number in an encrypted format. Crimson Logic was hired by the SI
team as the OEM to provide this service. After vanfication, thay digitally signed and optically
watermarked the a lamps in Itime. It took approximately 15 minutes to generate an e-
stamp. The e-stamp code is unique and can be used only once.

The system was designed in a way that there would not be any dependence on any type of
proprietary stationery onery. Using proprietary stationery would d lead to problems
problems of distribution and storage causing malpractices and problems in accounting and
increasing the overall cost of implementation. The DRS decided to us widely available plain
100 GSM papers for printing the documents.

Other features like CAPTCHA and password encryption implemented to secure the system.
The SAMPADA integrated multiple technologies as mentioned in Exhibit 7. The State Data
Centre (SDC) hosted certified applications ensure compliance with international security
standards. To ensure security compliance, the Indian Computer Emergency Response Team
(CERT-In) conducted the

voare also done by Standardisation Testing and Quality Certification (STQC) to ensure
quality

and secunty of the system.

Queue Management System

To redu reduce the length of queues and wrast time and also enhance citizen experience,
automated queue management system was propo posed to be e implemented across MP.
The system included having a counter for issuing tokans to the citizens wiuch would
automatically be read by the tokken reader attached at the entrance. Alongside, the token
number and the counter number would be displayed on a screen in the waiting area

Implementation Process

Delays in the Project

Even though the application development started in 2008, there was little progress until
2012 because be of of a lack k of focus resulting from frequent changes in leadership. Me
Mossover, tender fos infrastructure supply took many years to conclude and lack hardware
availability hampered application development. In addition, new requirements emerged at
every stage of the project and thus the modules had to be re-worked multiple times. As a
result, the application developer had no incentive to speed up development and the project
was halted.

Coming Back on Track

With the change in the top management of the DSS again in June 2012, and with Rastogi
taking charge, the project was revived with an aim to make it a success. The DRS repeated
the 51 tandering process and selected NIIT Technologies Limited as the 51 in January 2013

The NIIT deployed hardware-related software, integration with Madhya Pradesh Stats Wide
Area Network or MPSWAN (Edhibet 8) and help-desk support for the smooth functioning of
the systan. Additionally, it provided support and maintenance for five years from the date of
go live. It was also responsible for site inspections, updating the hardware and software as
per system requirements

Exhubut 9 specifies the role of vasous extemal stakeholders workang for the SAMPADA
Forming a Core Team

To streamline the activities and communication across the department, Srikant Pandey,
Deputy Inspector General (DBG) Registration, appointed as the nodal officer and Swapnesh
Sharma, District Registrat, Bhopal, as the project officer (PO), SAMPADA A strong comes-
functional coss team comprising the IGRS, jount IG, DIG, ona district registrar, four sensor
sub registrars, PO and PMC was formed to undertake the requirements analysis of the DRS

Active Involvement of the Care Team

Under Rastogi, the core team did a detailed study of the tedious and complex techno-legal
requirements and worked on an improved design for all major modules for about six months.
The team also visited other states which had computerised were the process of
computerising property registration to study their systems and compare their designs with
the proposed solution. The SRS fm application development once again underwent multiple
iterations before the requirements were frozen

The PO actively managed the taam of application programmars and vendors, which included
a Seam from rom 3i Infotech, Wipro and NIIT. He deployed a dedicated of application
developers at the DRS head office. All activities at all levels were reported and monitored
daily.

IT Technologies was a global IT solutioru orgaruastion providing application development

truturad 17 operations management and cloud servic mosanduty verticala. The company
also provided data centre service
Moreover, weekly demo sessions ensured that the requirements were clear at all levels
aliminating chances of masinterpretation and ambiguities.

The core team, anvolved at all levels throughout the project lifecycle, worked to identify
partners for different roles and provided support the government functionaries. They
brainstormed on the aspects involving infrastructure, process and data design, various
modules and training schedules

Managing Conflicts

The initial development period was quite challenging for the DRS. During the initial phase,
the application development team had started development on the Oracle 10g platform. But
by the time the 51 aged the present platform. had reached its end-of-life and the system
had to be upgraded to Oracle 11g.

With the progress of the project, it became difficult for the PO manage three different
vendors, each vendor worked in its silo leading to frequent disagreements between the
application developer and SI team regarding responsibility for correct functioning. Conflict of
responsibilities also emerged, for example, each vendor believed that a version upgrade in
toxins of application or operating system was the responsibility of the other party. In the
autial stages of development, the PO and his team of assistant programmers (AP) and the
PMC spent around 14 hours each day in resolving such conflicts, to ensure teams were
coordinating with each other and an development was not stalled due insistence on tight
adherence to SLAs as as defined in the when vendors realised that unnecessary delays due
performance. disagreements Ultimately, the PO's RFP helped manage vendor conflicts
conflicts were detrimental to their

Managing the field infrastructure delivery milestones, it had challenging for the 51 As
payments to SI was based on that any technical problem resolved within the deadline as
defined in the SLA, any deviation from which attracted a heavy penalty for the Si

User Acceptance Testing

The application was was largely completed by 2013 and the user acce acceptance testing
(UAT) acceptance teso completed over the next n two months across districts. A team was f
formed to test each of the 30 modules. Each team consisted of seven to eight members and
included a DIG, two to three senior district registrars/district registrars, and three sub-
registrars. Modules and test were allocated to each team for exhaustive testing of the
application.

Each UAT schedule lasted thuse to four days. Regular meetings between the UAT, core
team, DIG and IGRS were held to review the cutromes and decide the way forward, and the
suggested changes were shared with the application developer for further action. Manor
changes were implemented immediately and any major modifications in scope or modules
were discussed and negotiated.

Many process sumplification changes were identified during the UAT. A lot of these changes
required legislative approvals which used implementation delays. Henos, legislative

amandments was proposed in parallel to the testing to speed up processes. The

development/upgradation dation of of the 5DC, disaster recovery sites, user training and
selection of pilot sites also initiated parallel to the UAT.

Legislative Changes
The computerised system was developed under the provisions of the Indian Stamp Act,
1899, Registration n Act 1908 and Transfer of Property Act 1582. Many departmental func
nctionaries claimed that since the did not specify e-stamps and authentication through
biometric thumb impremons, the proposed system was in violation of the legal framework.
On than ground, several functionaries refused to this application.

Consequently, amendments to the Registration Act, 1905, www implemented that ensured
the presence of all the transacting parties at the time of registration and electronic storage
of presentation, endorsement, filing, certification and signature. The role of stamp vendors
was re defined as an 50P, and banks and other non-banking financial iretitubors were
authorised to provide e-stamps and documentation services.

PREPARATION FOR ROLL-OUT

The core team brainstormed on the layout of registration offices, hardware and other
infrastructural requirements. Inputs from other goverrument functionaries were also
incorporated in decision-making Offices were equi equipped ipped with computers, printers,
scanners, biometric devices and electronic pens. Generators and air conditioners were also
installed in all major rural districts to ensure a comfortable environment for government
officials and citizens, and to avoid breakdown of systems due to heating.

The PO considered the business continuity plan plan while deciding on the storage and
connectrrity of the SAMPADA To take advantage of the shared resources prov ided by the
Government of India, the storage infrastructure of the SAMPADA was horted and managed
by the SDC. Dell storage infrastructure was used for DRS transactions as it had the
capability to support fast read/write. As the volume of the transactions was quite high and
response time had to be managed effectively, it was decided to have premise-based storage
and not host it on the cloud as there ame of bandwidth requirements not being compatible
with cloud hosting

TRAINING

The trainung began in 2014 even when the application was partly developed 1 for a quicker
quicker roll in batches to become master trainers over ra period of out. Kay SAMPADA
officials were trained one year. They then helped train the subordinate and clerical staff by
providing troubleshooting and handholding support at tahsil/taluka levels. In addition, 4,000
SPs were also trained in various areas

Twenty-five regional capacity building centres tres a of the state were used for providing
30.000 hours of training at a cost of approximately IVR 5,000,000. For training, tutorials in
Hindi and English were prepared both in soft and hard copy. There were 30 government
functionaries per batch and aach workshop lasted about three days. The training modules
varied fro asic computer

skills conducted by the NIIT Technologies to networlang sess sessions by the MPSWAN.
Exams conducted pos post training tr and the results were we published on the DRS website
(www.mpigs.gov.in). Names of top performing officials and SP were also published to
motivats others. Those who failed the e were given a chance to repeat the training module.

As the system was perceived to break any kind of nevus that government functionaries had
with external stakeholders, the latter strongly resisted the new system at the UAT and
during training. They were also not comfortable wit with using technology With time and
sweing the persistence ce of of the the top management ment level in implementing the
system. there was a change in the mindset. The officials who were quick learners
encouraged others. Training also helped to overcome the fear of using technology. Soon
they began to realise and appreciate the benefits of a better systum

PILOT IMPLEMENTATION

Post completion of the training, the DRS decided to pilot test the application in five districts
across MP. On December 13, 2014, the project was rolled out an Ujjain, Sehore, Tikamgarh,
Balaghat and Anuppur. Usban, rural and tribal districts were selected as pilot sites in which a
commercial district like Ugan Anuppur on the other the one end of the le continuum and a
tribal distract like

The DRS employees in pilot districts disected to not touch the old recoeds and start
electroenc registrations. Manual registrations were stopped at the issuance of a gazette
notification and physical stamp papers s were discouraged. The core n team visited the pilot
sites at regular intervals to assess the situation. Sub-registrars of the nearby districts were
encouraged visit these sites to learn about the system. A help desk was created at the state
headquarter for handling customerqueries.

Managing Bandwidth and Connectivity Issues

The challenging pilot phase continued for five months. At the initial stages, connectivity of
the MPSWAN was intermittent to poor. Bandwidth requirements were huge and the MPSWAN
was not found to be reliable. Often transactions failed due to slow connectivity, frequent
deadlocks were experienced and the server had to be restarted several times.

This situation continued for around three to four months during the pilot phase. The system
unable to handle the sudden surge in transactions as it increased the server load
tremendously. As a result, documents were corrupted during registration and operations
were delayed significantly. Foor connectivity, particularly F in remote locations, farther
added to woes Concurrency of transactions the around 3,000 users par millisecond. This also
caused server congestion at the banks and the MP Cyber Treasury. The SP suffered
financially as challans could not be saued by the Cyber Treasury due to the connectivity
problems mentioned above. This delayed payments. More than 40,000 grievances were
registered in the first year of the roll-out of the SAMPADA, which gained the DBS negative
publicity.

To avoid a similar situation in the future, the MPSWAN administration provided a dedicated
technical team to handle connectivity issues. Engineers were available at around 400
locations

with a district e-governance manager and an assistant operational issues. Any technical
glitch was resolved bet between 30-45 a district governan manager to resolve minutes, but
if it required more time, alternate methods were used to provide dedicated connectivity to
all 31 districts to complete the departmental transactions

All IGRS systems sacured with the latest anti-virus software which also helped in managing
the network traffic. Average load on all servers and the number of registrations was
monitored continuously. Access to external sites and social media was blocked between 11
am to 5.30 p.m. As a result, network traffic and latency reduced, reducing problems of
corrupt documents and allowing for a surge in volumes to be handled smoothly. In addition,
wireless intranet connectivity provided b by the MPSWAN enabled the DRS to provide
doorstep service to citizens who were unable to vait the sub-registrar office due to grave
reasons

Managing Issues in the Application

During the plot phase, all sites required constant coordination with the state headquarter to
resolve issues encountered during the working of f the application For example in ose such
Incident the application font was corrupted and around 154 documents had to be created
manually in a single day. Another aspect was the inability of the rystem to capture the
signature and thumb impressions. The application development team behaved that slow
connectivity was causing prohlents, whereas the MPSWAN team indicated that the capturing
time of 10 seconds as coded in the application was insufficient for this operation. Finally, the
suggestion to τονίσο cepharing time was accepted, the limit was increased to 30 seconds
and the issue was resolved.

CREATING AWARENESS

The system was advertised extensiv was advertised extensively through print, audio and
visual media, uning educative posters, jingles and video tutorials, to create awareness.
Information about the online property registration process, payment and redressal of issues
was disseminated throughout the state

STATE-WIDE ROLL-OUT

By July 2015, the state-wide roll-out of the SAMPADA approved by the IGRS An automated
ticketing system for queuing based on the BMIC tool was implemented four months after
this. The tool served 6,000 SP and government functionaries of the system.

Creating a Project Management Unit

As soon as the state-wide roll-out was approved, the application development team
suggested the creation of a project management unit (PMU) to act as a single point of
contact for all stakeholders. It would monitor all activities of the roll-out as well as handie
queries across the 31 districts. The PMU headed by the IGRS was created on April 1, 2015.
The PO, nodal officer, PMC and assistant programmers deployed at the head office were the
internal partners and team members from the SI and application developer soere the
sectemal partners of the PMU The core team was now a special invitee on an as-and-when-
required baris. Exhibit 10 details of the PMU

The state-wide roll-out of the SAMPADA was initiated on July 1, 2015. Within a month, the
system was successfully implemented across all districts. To automate the valuation and
stamp duty calculation, all possible permutations and combinations of valuation criteria
were fed into the system. The Directorate of Treasury, through a network of its 13 associate
banks, provided the facility for online transactions. Exhibit 11 provides a synopsis of the
benefits o computerisation to the stakeholders of the system. The system was successfully
deployed at 31 district registrar and 234 sub-registrar offices across the state.

Initially, both online and offline modes of payments were allowed in the state. On January
26, 2017, the system was made cashless and all SAMPADA payments were routed through
the state cyber b treasury. The SPs were also authorised to do online payments y nents on
behalf of the customers using the credit facility provided by the state cyber treasury

As of July 2017, more than 4,000,000 e-stamps were issued, which generated a revenue of
approximately INR 50.4 billion for the state exchequse. More than 56,000 documents were
registered by users without any external help and more than 1,300,000 documents
registered since the launch of the SAMPADA. After the implementation, although som
employees felt the loss of unlawful pecuniary gains, they also realised and indicated that
they were in a mora peaceful state of mand. Exhibit 12 provides some statistics which
substantiates the successful adoption of the SAMPADA
MONITORING AND CONTROL

For effective monitoring, timestamp of every click and activity performed by a government
functionary, as also time spent by an officer in verifying a document, was saved for analysis.
All documents verified by the sub-registrar and senior sub-registrar (557) before approval

As it was mandatory to provide the property map in the deed, earlier a handmade map,
known. as "Nasari Nakaka", was included for registration. With the coming of the SAMPADA,
satellite data was integrated for major cities and digital maps were included. This increased
the accuracy of maps and made it easy to conduct spot inspections. Flowever, as satellite
data supdated only every six months, real-time data available and the SAMPADA could not
completaly zaly on these maps for assessment. In case a fraud was suspected, the
concerned 55R initiated spot inspection for physical verification of property. Random spot
inspections also done for registured properties to reveal revenue leakages

A queue automatically created in the system for all pending tasks at the end of the maker
and 55R. Any delay in task completion could be identified easily and action could be taken.
The system increased accountability as move it was easy to identify officials performing
transactions and hold them responsible in case of an anomaly.

At the district level, district registrars could monitor activities and transaction date. Earlier,
in the manual system, only four to five offices could be inspected yearly as real time
transaction data was not available. Computerisation made it possible to view and assess
everyday activities prompting quick decision-making.

CHALLENGES FACED BY THE IGRS POST SAMPADA

Going forward, there were several challenges that the DRS faced.

Outdated Technology

The SAMPADA application developed on Java Struts 11 application framework in 2008, then
a stable version. But as per the Network Intrusion Prevention System of the 5DC, by 2017,
thas became obsolete and vulnerable to secunty attacks. Since engaging an 151 took a lot
of time, Wipen claimed that it had started developing the application as soon as the SRS was
approved in 2005. The old version of the code was a legacy which was camed forward
because the part experiences of failed tender generated pressure, but it had to be upgraded
at the earliest They wanted to implement a dynamic framework that would also ease the
integration of the SAMPADA with othar applications

In addition, outdated technology made the system lass acceptable for integration with the
latest frameworks. The DRS wanted to get a detailed mew of vulnerabilities and threats as
that would help in protecting the system from malicious attacks,

Legacy Data

Another area of concern was the huge zepository of legacy records which had to be
digitised. The records were as old as 1588 and were in Hindi, Urdu and even in ancient
saipts. Property transaction data data of only the past two years was available in the
system. A large number records related to agricultural property was digitised, but the extent
of digitisation was not the same across districts. For example, in Bhopal agricultural records
of the last 13 years were digitised, but other distracts were still lagging behind. The DRS
wanted to digstise the records of the last 15 years acrous 31 districts in the first phase

Lack of Integration
As land title verification, checking for disputes or pending charges did not fall within the
scope of functions of the DRS, and such data was available to it, it was difficult to determine
the actual ownership and status of land d at the time of registration. The sub-registrare used
their experiancs and judgement to verify the details. Thus, the probability of errors and
frauds was significantly high. Any change in property ownership required citizens to go
through a "mutation" process, but as the land records system was not updated in real time,
there inconsistency in data zelated to land titling

Aadhaar Integration and Mobile Interface

The IGRS also aimed to explore the possibility of using Aadhaar-based authentication in the
system. The issues that arose were what benefit it would serve and at what levels the

property registration process it should be incorporated. The prospect of using mobile phones
to improve service delivery was also discussed att the DRS.

Data Analytics

Nearly 10,000,000 documents had been registered and stored across different zones
between. Apeil 1, 2000 and July 31, 2015. As of July 2017, around 60 TB of data was being
transmitted to a disaster recovery centre in a batch mode. With the fart increase in
accumulation of data, it was evident that the available storage would requirements of the
DRS. prove insufficient handle the future

The DFS had also to come up with an archiving policy for data management, but the
question wes on what parameters this should be decided

Additionally, the IGRS was wondering if they could use the vast amount of data that was
being generated for decision support. What kind of decisions would it support? Were the
departmental functionaries sufficiently trained to analyse data?

Operational Issues

There were several operational issues that needed to be addressed in the SAMPADA For
example, it had repeatedly failed to display thumb impression and photograph at the time of
capturing these, but the s sam was successfally stored in the database, possibly a result of
fluctuation in network bandwidth. It was believed that the server was not supporting the
application and required immediate attention

Integrated Solution for the DRS

The IGRS wanted Integrated of the DRS to monitor its network infrastructure and services,
but lacked clarity on the solution that would serve this purpose

The changes proposed seemed overwhelming. The IGRS contemplated whether and how
implementing new technologies and such changes would bring about a further change in the
existing roles, responsibilities and organisational structure. Alongside, what could be done
ensure a smooth transition? Rastogi requested the team under her to prepare a report that
addressed these concerns. She planned to use i a basis for discussion with the minister of
the Commercial Tax Department, MP.