A Smart Property Finder and In-Person Verification System for Transparent Real Estate Transactions
Research Article • Article ID: IJREK-2026-00136
Abstract
Real estate searches are often complicated by incomplete property information, duplicate advertisements, misleading photographs, uncertain ownership claims, and difficulty arranging physical visits. These issues can reduce trust between buyers, tenants, property owners, and intermediaries. This paper proposes a Smart Property Finder and In-Person Verification System designed to make property discovery more transparent by combining structured listings, search filters, owner or agent details, visit scheduling, and an auditable verification-status workflow. The proposed system allows users to compare properties using location, budget, property type, area, amenities, and availability. A verification module supports scheduled in-person inspection and records the outcome, observations, and status of each listing. The system is intended to distinguish information that is merely submitted by a user from information checked through a defined process. A modular web-based architecture can support user authentication, listing management, search, appointment booking, document review, feedback, and administrative oversight. The paper presents the system design, workflow, data model, security considerations, and an evaluation plan. Since the work describes a proposed system, performance values are not claimed as measured results. The approach aims to improve clarity, reduce avoidable visits, support informed decisions, and create a more accountable digital property-search experience.
Keywords
2. Problem Statement and Objectives
| Stakeholder | Primary Need | System Support |
|---|---|---|
| Buyer / Tenant | Reliable details and visit planning | Search, shortlist, appointment, feedback |
| Owner / Agent | Manage accurate listings | Submit, edit, and update property details |
| Verifier / Field Staff | Consistent inspection procedure | Checklist, visit record, evidence and status |
| Administrator | Trust and platform quality | Review reports, moderate listings, audit changes |
3. Related Work and Research Gap
Existing property portals commonly emphasize listing discovery, location filters, photographs, and direct contact. Mapping services can support location-based exploration, while appointment tools help coordinate visits. Identity and document-management functions can add another layer of review. However, these functions are not always presented as a single, user-visible lifecycle that clearly separates a self-declared listing from a listing checked through a documented process. The proposed design focuses on the connection between search, visit scheduling, verification evidence, and status history. Its main contribution is a workflow-oriented model: the system should show what was checked, when it was checked, and what remains unverified. This framing avoids using a single ambiguous “verified” label without explanation.
4. Proposed System Architecture
The architecture separates the user interface, application services, and persistent data. The user interface supports search and listing management. Application services validate requests, enforce role permissions, schedule visits, and maintain verification records. The database stores structured listing data and status history. File storage may hold listing images and permitted verification documents, subject to access controls and retention rules. Search need Property Portal Filters & listings Property Records Owner / details Verification Visit & confirm Booking Module Schedule visit Feedback & Status Verified / issue
Figure 1. High-level flow between users, listing services, property records, visit scheduling, and verification status.
4.1 Core Modules
| Module | Inputs | Outputs / Responsibility |
|---|---|---|
| User Management | Registration, login, role | Authenticated sessions and role-based access |
| Listing Management | Address, price, type, images, amenities | Validated, searchable property records |
| Search & Match | Filters, map area, budget | Ranked list of matching properties |
| Visit Scheduler | Preferred date/time, listing ID | Appointment request and visit status |
| Verification | Checklist, observations, permitted evidence | Timestamped status and reviewer notes |
| Moderation | Reports, flags, stale listing signals | Review queue and action history |
5. Methodology and Workflow
The methodology begins with requirements analysis, followed by data modelling, interface design, service implementation, and scenario-based testing. A listing moves through distinct states so that users can distinguish a newly submitted property from one reviewed by the platform or inspected in person. Each transition should be timestamped and linked to the responsible role. 1. Submit Property listing 2. Review Document checks 3. Visit In-person inspection 4. Resolve Confirm / flag Status log records evidence, date, responsible party and outcome
5.1 Verification Procedure
A proposed verification procedure can include the following steps: (1) confirm that required listing fields are present; (2) review contact and supporting information provided by the submitter; (3) schedule an in-person visit with the relevant parties; (4) record the date, checklist items, and observations; (5) allow discrepancies to be reported; and (6) update the listing status after review. The interface should display the scope and date of verification so that users do not interpret it as a universal legal certification.
5.2 Example Status Model
| Status | Meaning | Allowed Next Step |
|---|---|---|
| Draft | Listing is being prepared | Submit for review |
| Submitted | Awaiting initial checks | Approve for listing or request correction |
| Listed | Visible in search; not yet visit-verified | Request an in-person visit |
| Visit Scheduled | Appointment time agreed | Record visit outcome |
| Visit Recorded | Inspection observations saved | Confirm, flag, or request follow-up |
| Flagged / Inactive | Discrepancy or stale status needs action | Admin review and resolution |
6. Data Model and Functional Requirements
| Entity | Representative Fields | Purpose |
|---|---|---|
| User | user_id, name, email, phone, role | Manage accounts and access rights |
| Property | property_id, address, price, type, area, status, owner_id | Store searchable listing details |
| Appointment | appointment_id, property_id, requester_id, date_time, status | Coordinate physical visits |
| VerificationRecord | record_id, property_id, verifier_id, visit_date, checklist, outcome | Preserve inspection observations |
| Report | report_id, reporter_id, property_id, reason, resolution | Track user-reported issues |
| StatusHistory | history_id, entity_id, old_status, new_status, actor_id, timestamp | Provide an audit trail |
6.1 Functional Requirements
The platform should allow users to register and sign in securely, search by location and price range, filter by property type and features, view listing details, save shortlisted properties, and request visits. Owners or agents should be able to submit and update listings. Authorized verifiers should record checklists and visit outcomes. Administrators should review reports, handle duplicate or stale listings, and maintain a history of decisions.
6.2 Non-Functional Requirements
| Quality Attribute | Design Requirement |
|---|---|
| Usability | Simple forms, clear status labels, mobile-friendly pages |
| Security | Password hashing, session protection, access control |
| Privacy | Collect minimum data and restrict document visibility |
| Reliability | Validate inputs, handle errors, back up important records |
| Maintainability | Modular services, documented APIs, consistent data rules |
7. Search, Ranking, and User Interaction
| Criterion | Example Interpretation | Possible User Control |
|---|---|---|
| Location fit | Distance to preferred area or landmark | Set preferred locality / radius |
| Budget fit | Difference between budget and asking price | Minimum and maximum budget |
| Area fit | Match to required carpet/built-up area | Set minimum area |
| Amenities | Presence of selected facilities | Choose required amenities |
| Listing freshness | How recently availability was confirmed | Prefer recently updated listings |
7.1 Interface Design Principles
Each property card should show the asking price, approximate location, property type, area, key amenities, availability update date, owner or agent contact pathway, and the precise verification status. Labels such as “listing details reviewed” and “in-person visit recorded” are more informative than a generic badge. Users should be able to open the status explanation and understand the date and scope of the checks performed. The visit request interface should present available time slots, confirmation state, and cancellation or rescheduling options. After a visit, users should be able to submit structured feedback and report a mismatch. A clear process for resolving reports is important to avoid allowing unsupported accusations to become public statements without review.
8. Security, Privacy, and Risk Management
| Risk | Potential Effect | Mitigation |
|---|---|---|
| False or outdated listing | Wasted visits and poor decisions | Expiry reminders, reports, date-stamped status |
| Impersonation | Misleading contact or ownership claims | Account checks and careful wording of verification scope |
| Data exposure | Privacy or safety harm | Least privilege, secure storage, access logs |
| Fraudulent documents | False confidence in listing | Manual review and clear limits on claims |
| Biased ranking | Relevant options may be hidden | Explainable criteria and user-controlled filters |
| Missed appointment | Time loss for participants | Confirmation, reminders, cancellation workflow |
9. Evaluation Plan and Discussion
| Measure | How to Assess | Purpose |
|---|---|---|
| Search task completion | Percentage of users finding a suitable listing | Assess discoverability |
| Visit scheduling success | Completed appointment requests / attempts | Assess booking flow |
| Status comprehension | Ask users to explain each status label | Check transparency |
| Data completeness | Count listings missing required fields | Assess listing quality |
| Report resolution time | Time from report submission to outcome | Assess moderation workflow |
10. Future Enhancements
Future work may add map-based search, duplicate-listing detection, multilingual interfaces, accessibility improvements, appointment reminders, verified feedback moderation, and integration with authorized public-record sources where legally and technically feasible. Automated image or text checks could flag potential duplicates or incomplete descriptions, but human review should remain available for consequential decisions. A mobile application and notification service may improve coordination between users, owners, and field staff. 11. Conclusion The proposed Smart Property Finder and In-Person Verification System integrates property search with visit scheduling, structured inspection records, discrepancy reporting, and transparent status history. Its central design principle is to make the scope of verification visible instead of treating a single label as proof of every aspect of a property. By separating submitted details, reviewed information, and recorded in-person visits, the system can help users make better-informed comparisons and support more accountable listing management. Future implementation and user testing are required to assess usability, operational feasibility, and measurable impact.
References
How to Cite this Contribution
Supriya Waghmode et al. (2026). A Smart Property Finder and In-Person Verification System for Transparent Real Estate Transactions. International Journal of Research, Exploration & Knowledge (IJREK), 1(1).
Distributed under Creative Commons Attribution 4.0 International (CC BY 4.0).
