Case files / PAN-119
Loan intake that questions the photo
A lending proof of concept for the housing sector: small loans to build on a stand, finish a foundation or add a roof, applied for from a cheap phone with no app. The server reads location and capture time from the photo itself and ignores what the browser claims. An application ends in one of two states: submitted, or sent to manual review.
Control flow
- Invite: a single-use chat link
- Identity: a mocked check, for now
- Capture: the applicant photographs the stand
- Re-read: location and time from the bytes
- Flag: old or blank photos go to review
- Notify: a masked summary to an officer
Industry: Housing · Stack: Node.js · Express · exifr · PostgreSQL (schema only) · Seed species: Brick
Problem
Small building loans are made against a stand, a foundation or a half-built house. The lender needs to know that the photo of the property is of this property, taken now, by the person applying. The applicant has a cheap phone, data that costs money, and no wish to install anything.
How it works
A loan officer sends a single-use link over a chat app. The applicant opens it in the phone’s browser, passes an identity check, and photographs the stand.
The server does not trust what the browser says. It re-reads the GPS position and capture time from the uploaded bytes, flags photos older than 48 hours, rejects photos with no position, and hashes every file. The officer receives a masked summary.
An application ends in one of two states: submitted, or sent to manual review. Credit scoring, affordability, pricing and payout are out of scope. No lending decision is made here, by code or by a person.
Method
The documentation keeps an honest status table with three labels: verified, written but not run, and design only. Only the zero-credential mock harness ran end to end. The design calls its own photo checks “deterrence and triage”, not proof, because metadata can be stripped or rewritten by any tool.
What broke
The phone compresses photos before upload, and compression strips the very metadata the fraud check reads. Once the real submit is wired up, the check would see nothing. The docs also claim an upload library upgrade the manifest never received.
Limitations
The identity check is a mock that returns a fixed face-match score. The chat notification only logs. The database schema exists but has not been applied; applications live in memory. The design says “flag, don’t silently reject”, and the backend hard-rejects photos with no position. The documentation keeps its own list of known issues and the hardening a pilot would need first.
Next
Pilot hardening: real storage, the original photo, a reused-photo check, and an audit log on the admin view.