Vehicle Catalogue Matching Engine

The company's internal vehicle catalogue needed to be reconciled against catalogues from 15+ insurance partners (HDFC, TATA, ICICI, Bajaj, Digit, SBI, and others), each using different naming conventions, so every vehicle could be linked to the right product line for premium generation — previously done by hand in Excel.

Every partner encodes the same vehicle differently: different make spellings, fuel type as text vs. letter codes vs. numeric codes, gross vehicle weight rounded differently, model names sometimes sitting in the wrong column entirely. Naively comparing every internal row against every partner row is quadratic — for a single mid-sized partner file, a full cross-join runs well into the hundreds of millions of comparisons, which is not something you can run repeatedly by hand or brute-force in code. On top of that, this pipeline is not just a reporting tool — it directly feeds the quotation portal, so a bad match means a wrong premium quote.

Rows are first grouped by a normalized make name, which cuts the comparison space by roughly four orders of magnitude before any matching starts. Within each group, candidate pairs pass through multi-field rule gates — vehicle type, fuel, gross vehicle weight, and others — where failing any single gate is an automatic reject regardless of how similar the text looks. Pairs that clear every gate get fuzzy-scored on make, model, and variant text and assigned a cross-field confidence score. Modular, per-insurer matching engines write standardized output into PostgreSQL with a full audit trail.

Matching uses rapidfuzz string similarity — a plain ratio for make names, a token-set ratio for model names so word order and extra tokens do not break a match, and a token-sort ratio for variant text. Partner-specific quirks (numeric type codes, oddly-encoded weight fields, model names in the wrong column) are handled by small, partner-specific preprocessing functions rather than one tangled set of general-purpose rules, which keeps each partner's edge cases isolated and easy to reason about independently.

Each partner runs through its own modular matching engine sharing the same core pipeline, writing to a standardized PostgreSQL schema with an audit trail for every match decision. The same architecture was extended across both GCV and PCV vehicle categories by swapping in a new partner configuration, not by rewriting the matching logic.

One partner recorded a fleet vehicle's actual rated weight, where the internal catalogue used a single standardized weight for that whole vehicle class — which quietly suppressed matches across an entire segment.

Rather than special-casing that one partner, the fix was generalized into a rule applied to any partner showing the same standardization pattern, which recovered matches across several other partners with the identical issue and pushed the match rate for that problem segment from roughly 50% into the high 50s.

Matching quality is validated by inspecting match counts and the unmatched/review sheets after each run against known partner files, backed by the PostgreSQL audit trail for traceability on every decision. An automated regression suite is a documented next step, not something that exists yet.

Parallelizing matching across make-groups, moving partner onboarding from code changes to configuration files, and adding an automated regression test suite are the clearest next steps.