I Built a Fintech Product in 48 Hours, Got Rejected, and Finished It Anyway

Developer Suchita Yerramsetty built Collatiq, an AI-powered collateral intelligence engine for Indian lenders that generates property valuation reports in 30 seconds using OpenStreetMap data. After submitting the project to the TenzorX 2026 national AI hackathon and being rejected from the finals, Yerramsetty continued development, adding fraud detection, sensitivity analysis sliders, lender-grade PDF export, and expanding micromarket zone coverage from 8 to 34 zones.

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built Ten million property transactions happen in India every year. Every single one of them that involves a loan requires a physical broker to visit the site, write a report by hand, and deliver it to the lender. That process takes three days minimum. Sometimes a week. The loan waits. The business waits. The owner waits. Nobody has questioned this workflow in decades because nobody built an alternative. I built the alternative. Collatiq is an AI-powered collateral intelligence engine for Indian NBFCs and lenders. You enter a property address. In 30 seconds you get a lender-grade valuation report with fraud signals, confidence scoring, sensitivity analysis, and a one-click PDF export. No broker. No site visit. No waiting. Zero paid APIs. The entire system runs on OpenStreetMap and Nominatim. I submitted it to TenzorX 2026, a national AI hackathon by Poonawalla Fincorp with thousands of competing teams. I did not make the finals. Most people would close the laptop and move on. I opened a new branch instead. Demo 🔗 Live App: collatiq.vercel.app https://collatiq.vercel.app 💻 GitHub: github.com/yerramsettysuchita/Collatiq https://github.com/yerramsettysuchita/Collatiq 🎥 Demo Video: youtu.be/3BJnMP33e6M https://youtu.be/3BJnMP33e6M Here is what Collatiq does the moment you submit an address: The Geo Engine fires first. It geocodes the address via Nominatim, matches it against one of 34 Bengaluru micromarket zones, and scores infrastructure proximity within a 2km radius using live Overpass API queries against schools, hospitals, metro stations, and major roads. The Valuation Engine then applies 12 adjustment factors on top of live government circle rates. Floor premium, age depreciation, construction quality index, road width multiplier, amenity score, FSI utilization, corner plot bonus, and five more. Every factor is derived from real lending practice, not guesswork. The Confidence Engine measures how much the system trusts its own output. It scores data completeness, detects anomalies by cross-referencing reported built-up area against zone averages, and surfaces fraud signals with severity classification ranging from critical to informational with human-readable explanations for each flag. The Decision Engine produces the final LTV recommendation with sensitivity analysis sliders that let a credit officer model what happens to the valuation if the road width changes, if the property age is different, or if the amenity index shifts. Every slider reruns the full engine in real time with no API call and no page reload. The output is a structured PDF report that looks like something a credit officer would actually read and file. The Comeback Story Here is the honest before and after. When I submitted to TenzorX, the four engines existed and the core pipeline ran. But the fraud detection was a placeholder. The sensitivity sliders did not exist. The PDF export printed raw text to the screen. The micromarket data covered 8 zones out of 34. There was no onboarding flow so a first-time user had no idea what to enter or what any of the output meant. The 3D landing page was visually impressive and completely disconnected from the actual application underneath it. It was a proof of concept wearing a product's clothes. | What existed at submission | What was missing | |---|---| | Four-engine pipeline | Explainability on every output | | Basic map view | Interactive zone visualization | | Raw valuation output | Downloadable lender-grade PDF | | 8 micromarket zones | 34 verified zones with real data | | No onboarding | Guided first-use experience | | Placeholder fraud flags | Real signal-based anomaly engine | | No sensitivity controls | Live recalculation sliders | After the rejection I rebuilt every one of those gaps. The fraud detection engine now cross-references six signal types. Price-to-infrastructure mismatches. Reported area deviations from zone averages. Age versus condition contradictions. Unreported encumbrances inferred from OSM data. Each signal is weighted, classified by severity, and explained in plain language that a loan officer without a technical background can understand and act on. The sensitivity sliders were the most technically interesting problem. The naive approach reruns the entire valuation pipeline on every slider change which introduces visible lag. The correct approach memorizes the base valuation, isolates each adjustment factor as an independent multiplier, and recomputes only the delta for the changed factor. The sliders now feel instant because they are instant. The full recalculation takes under 4 milliseconds on a mid-range device. The PDF export generates a structured multi-section report using jsPDF with dynamic content layout that handles variable-length fraud flag lists, adjusts section spacing automatically, and produces output that is indistinguishable from a professionally typeset document. The micromarket data expansion from 8 to 34 zones required sourcing, verifying, and structuring government circle rate data, infrastructure density measurements, and historical transaction signals for every zone. That is not glamorous work. It is the work that makes the difference between a demo and a product. Here is what the numbers look like after the finish-up: | Metric | Hackathon submission | Finished product | |---|---|---| | Micromarket zones | 8 | 34 | | Valuation adjustment factors | 7 | 12 | | Fraud signal types | 1 placeholder | 6 real signals | | Report export | None | Full structured PDF | | Sensitivity controls | None | 5 live real-time sliders | | First-use onboarding | None | Fully guided flow | My Experience with GitHub Copilot I want to be specific about this because most write-ups about AI tools are vague in a way that helps nobody. The fraud detection rewrite was the hardest part of the finish-up. The original placeholder was four lines. The real engine needed to reason across six signal types with weighted severity classification and produce explanations that are accurate enough for a credit officer to act on. I knew the architecture I wanted. I wrote a detailed comment block describing the input schema, the signal types, the severity weights, and the expected output format. Copilot read that comment and suggested separating signal detection from signal classification into two distinct layers. I had been about to collapse them into a single function. The suggestion was architecturally correct. The separation made the fraud engine testable in isolation, extensible without touching existing logic, and dramatically easier to reason about when the output looked wrong. That one suggestion saved me an entire debugging session that I would have had if I had built it my original way. For the jsPDF layout I described the target document structure in a comment and Copilot drafted the coordinate arithmetic for the multi-section layout. PDF generation with dynamic content lengths requires precise y-coordinate tracking across sections and Copilot handled that mechanical complexity while I focused on the content logic and the output formatting. For the micromarket data structure I gave Copilot the schema for three zones and asked it to infer the pattern and generate a consistent template for the remaining 31. It produced a starter template that I could verify against government sources and populate. A task that would have taken four hours of repetitive data structuring took 40 minutes of verification and correction. The most important thing Copilot did was never let me write boilerplate when I should have been thinking. Every time I started typing something mechanical it finished it. Every time I wrote a comment describing intent it translated intent into structure. That left my cognitive budget entirely available for the decisions that actually mattered. Collatiq got rejected from TenzorX. Looking at what it is now versus what I submitted under the deadline I am genuinely glad it happened. The rejection forced me to separate what I had shipped from what I had actually built. They were not the same thing. Hackathons teach you to ship under pressure. Finish-up-a-thons teach you what shipping under pressure costs you. This challenge gave me the reason to pay that debt back. The product is live. The code is open. The report takes 30 seconds. Go try it: collatiq.vercel.app https://collatiq.vercel.app Yerramsetty Sai Venkata Suchita R&D Intern at Siemens · Indian Patent Filed · IEEE Paper Under Review