Before a bank or NBFC approves a loan, someone often has to go and look. An agent visits the applicant's home or business and confirms the details: does this person live here, does this business exist, is the information on the application true?
The whole decision rests on that visit. And for a long time, the evidence for it was a paper form.
High Tech Credit Analysis, an agency that carries out these checks for banks across Tamil Nadu, ran on exactly that. We replaced it with a connected platform: a portal for bank staff, a console for the agency's admins, and a mobile app for agents in the field. This post is about the design choices that matter most when the whole product is, at heart, about trust.
Start from the paper forms, not from a blank screen
It's tempting to redesign everything when you digitise a process. We deliberately didn't.
The agency's paper forms encoded years of experience about which questions to ask and in what order. So the mobile app's guided interview is based directly on those forms. Agents move through the same questions they already knew, now with conditional logic — follow-up questions appear only when an earlier answer calls for them — and acknowledge steps where the agent confirms they've checked something specific.
Admins can build and change these question sets in the console without a developer.
Every report carries its own evidence
A paper form says what the agent wrote. A digital visit can show what the agent saw.
During each visit, the app captures:
- photos of the premises
- audio, where the process calls for it
- the applicant's signature on the screen
- the agent's GPS location at the time of the visit
When a report reaches the bank, it isn't just a set of answers. It's a record of the visit itself.
Let suspicious visits flag themselves
The hardest problem in field verification is the visit that never happened — the report filled in from a tea shop, or from memory, or from home.
We can't prevent every bad actor, but we can make dishonesty visible. When an agent submits a visit, the system measures two things:
- How far the agent was from the address being verified.
- Whether the agent was inside the agency's configured service areas.
If either looks wrong, the visit is automatically flagged as suspicious or as a likely no-show. Admins see it straight away, before anything goes to the bank.
Two design details made this work in practice:
- Flag, don't block. GPS isn't perfect. Signals drift inside buildings and addresses aren't always mapped accurately. If the app refused to submit, agents would be stuck on the doorstep. Instead, every visit is accepted and questionable ones are routed to a human for review.
- Let admins correct the target. Sometimes the coordinates for an address are simply wrong. Admins can edit the GPS coordinates of a target address, so the distance check stays fair to agents and still useful for the agency.
Security in two layers, not one
A shared platform means many banks' data lives in the same system. A bank must only ever see its own requests and reports. Getting that wrong even once would end the business relationship.
So permissions are enforced twice:
- In the application, every page checks the user's role: super admin, company admin, bank representative or field agent.
- In the database, Supabase's row-level security is enabled on every table. Even if a bug in the app tried to fetch another bank's data, the database would refuse.
The second layer is the one that lets you sleep at night. Application code changes constantly; database policies are a fixed boundary underneath it.
Sensitive actions happen in one protected step
Some actions involve several pieces of data changing together. Creating a request with three addresses, or submitting a visit with its answers, photos and location, should either happen completely or not at all.
Each of these runs as a single protected database function. The app calls the function; the function does the work in one transaction and decides which fields can be set. Users can't reach around it to edit fields they shouldn't through direct table access — for example, changing a visit's status or its recorded location.
From approved visit to branded report
Once an admin has reviewed a visit, and edited an answer if needed, they approve it. The approved job becomes a professional, branded PDF report, generated with React-PDF, that the bank downloads from its portal. Bank staff can follow every job from request to report without a single phone call.
A schema that grew with the business
The database didn't arrive fully formed. It evolved through more than 30 versioned SQL migrations as real usage showed what was needed: automatic reference numbers for every job, editable GPS coordinates, and storage rules for photos and audio. Each change is recorded, repeatable and reviewable, which matters when you're handling banks' data.
The lesson for any field-operations app
Whether you're verifying loan applicants, inspecting properties or servicing equipment, the pattern is the same. Digitise the process people already trust, capture evidence at the moment of the visit, let the system highlight what looks wrong, and enforce data boundaries where they can't be bypassed.
The full project — including the bank portal, admin console, field app and the agency's public website — is on the Hightech Verification project page. If your business runs on field visits and paper forms, book a discovery call.