Subsidy Duplicate Receipt Detection Bot

3.05

Derivation Chain

Step 1 Public livelihood subsidy policy controversy

→

Step 2 Strengthened local government duplicate-receipt prevention mandates

→

Step 3 Automated rule updates for duplicate-receipt detection rule engines

Problem

As local governments create 50-100 new subsidy programs annually, existing duplicate-receipt prevention systems fail to update their rules fast enough, causing detection gaps. The number of cases flagged by the Board of Audit and Inspection increases year over year, and manual rule updates take an average of 3-5 days per program.

Solution

Analyzes new subsidy program announcements and implementation rules using LLM to automatically extract eligibility requirements, income criteria, and duplicate-restriction conditions, then generates rule sets compatible with existing rule engines. Cross-validates against the current recipient database and reports a list of potential duplicate-receipt risks.

Target: Municipal and metropolitan local government welfare information and audit departments (260+ local governments nationwide), Ministry of the Interior and Safety integrated subsidy management system operations team

Revenue Model: B2G SaaS annual contract 6-18 million KRW (~$4,500-$13,500)/municipality (3 tiers based on program count). Special audit preparation diagnosis at 3 million KRW (~$2,250) Per Transaction.

Ecosystem Role: Regulation

MVP Estimate: 2_weeks

NUMR-V Scores

N Novelty

4.0/5

U Urgency

3.0/5

M Market

3.0/5

R Realizability

2.0/5

V Validation

4.0/5

NUMR-V Scoring System

N Novelty	1-5	How uncommon the service is in market context.
U Urgency	1-5	How urgently users need this problem solved now.
M Market	1-5	Market size and growth potential from proxy indicators.
R Realizability	1-5	Buildability for a small team with realistic constraints.
V Validation	1-5	Validation signal quality from competition and demand data.

SaaS N=.15 U=.20 M=.15 R=.30 V=.20 Senior N=.25 U=.25 M=.05 R=.30 V=.15

Feasibility (73%)

Tech Complexity

29.3/40

Data Availability

23.3/25

MVP Timeline

20.0/20

API Bonus

0.0/15

Feasibility Breakdown

Tech Complexity	/ 40	Difficulty of core implementation stack.
Data Availability	/ 25	Practical availability and cost of required data.
MVP Timeline	/ 20	Expected time to ship a usable MVP.
API Bonus	/ 15	Bonus for viable public API leverage.

Market Validation (59/100)

Competition

8.0/20

Market Demand

9.4/20

Timing

16.0/20

Revenue Signals

10.5/15

Pick-Axe Fit

12.0/15

Solo Buildability

3.0/10

Validation Breakdown

Competition	/ 20	Signal quality from competitor landscape.
Market Demand	/ 20	Demand proxies from search and mention patterns.
Timing	/ 20	Fit with current shifts in tech, behavior, and regulation.
Revenue Signals	/ 15	Reference evidence for monetization viability.
Pick-Axe Fit	/ 15	How well the concept serves participants in a trend.
Solo Buildability	/ 10	Practicality for lean-team implementation.

Technical Requirements

AI/ML [medium] Backend [medium] Frontend [low]

Dashboard