Kita 的 VLM 信贷审核：在没有征信机构的市场用视觉模型解析银行流水

Emerging markets run on paper. In the Philippines and Mexico, credit bureaus are unreliable, open banking APIs barely exist, and loan applications arrive as smartphone photos of bank statements printed on thermal paper. Traditional OCR tools break on these documents. Template-based parsers assume consistency that does not exist. Kita uses vision-language models to extract structured financial data from this chaos, turning document review into an automated pipeline. The company launched in YC W26 targeting lenders who manually review thousands of PDFs, images, and screenshots per month. The technical challenge is not just extraction. It is validation, fraud detection, and confidence scoring when the ground truth is a blurry photo of a payslip from a regional bank with no standard format. The Document Problem in Low-Infrastructure Markets Credit underwriting in these regions depends on borrower-submitted documents because alternative data sources do not exist. A typical loan application includes: Bank statements (PDF exports, printed and scanned, or screenshots from mobile banking apps) Payslips (employer-issued PDFs, handwritten receipts, or photos of physical documents) Tax forms, utility bills, and business invoices in dozens of formats Each document type varies by institution. One bank's statement might be a clean table. Another's is a scanned image with watermarks, stamps, and handwritten notes. Generic OCR tools extract text but cannot infer structure. Template-based systems fail when the next document does not match the template. The manual fallback is expensive. Credit analysts spend hours per application cross-referencing transactions, calculating income stability, and checking for signs of fraud. This bottleneck limits lending volume and increases cost per loan. VLM-Based Extraction Architecture Kita's pipeline uses vision-language models as the primary parser. The architecture has four stages: Document ingestion and enhancement: Accepts PDFs, images, and screenshots. Preprocessing includes deskewing, contrast adjustment, and resolution upscaling for low-quality inputs. VLM extraction: The model receives the enhanced document and a structured prompt describing the expected financial data. Output is JSON with fields like transaction dates, amounts, account balances, and employer names. Cross-document validation: Extracted data is checked against other documents in the application. If a payslip shows monthly income of $2,000 but bank deposits average $500, the system flags the discrepancy. Fraud detection layer: Looks for digital manipulation artifacts, inconsistent fonts, duplicate transaction patterns, and mismatched metadata (e.g., a PDF creation date that predates the statement period). The VLM does not run in isolation. A secondary rules engine validates extracted amounts against expected ranges, checks for missing required fields, and assigns confidence scores to each data point. Handling Multi-Page PDFs and Rate Limits Bank statements often span 10 to 20 pages. Sending each page as a separate VLM call is slow and expensive. Kita batches pages into logical chunks (e.g., one month of transactions) and uses a sliding context window to maintain continuity across pages. Rate limits and cost control matter at scale. Processing 1,000 loan applications with an average of 15 document pages each means 15,000 VLM calls. The system uses: Tiered retry logic: Failed calls retry with exponential backoff. After three failures, the document routes to a human review queue. Cost-based routing: High-confidence documents use cheaper, faster models. Low-confidence or fraud-flagged documents escalate to more capable (and expensive) models or human reviewers. Batch processing windows: Non-urgent applications are queued and processed during off-peak API hours to reduce costs. Confidence Scoring and Fallback Paths Not every extraction succeeds. The VLM might hallucinate a transaction amount, misread a date, or fail to parse a heavily degraded image. Kita assigns a confidence score to each extracted field based on: Model output probability Cross-document consistency Presence of expected patterns (e.g., transaction amounts that sum to the closing balance) When confidence drops below a threshold, the system has three fallback options: Confidence Level Action Latency Impact High (>90%) Auto-approve extraction None Medium (70-90%) Secondary model review +30 seconds Low (<70%) Human review queue +2-24 hours The human review queue is not a failure state. It is a deliberate design choice. Lenders care more about accuracy than speed, and a 95% automation rate with high precision is better than 100% automation with frequent errors. Fraud Detection Without Ground Truth Traditional fraud detection relies on historical patterns and labeled datasets. Kita operates in markets where labeled fraud data is scarce. The system uses heuristic checks instead: Metadata inconsistencies: A PDF claiming to be from January 2026 but with a file creation date of March 2026. Font mismatches: A single document with three different fonts in the transaction table. Duplicate patterns: Identical transaction sequences across multiple applicants. Image forensics: JPEG compression artifacts that suggest copy-paste manipulation. These checks run in parallel with VLM extraction. A document can have perfect extraction but still fail fraud checks. The two layers are independent. State Management and Observability Each loan application is a stateful workflow. The system tracks: Document upload timestamps Extraction attempts and retries Validation results and confidence scores Fraud flags and manual review decisions State is stored in a relational database with an event log for auditability. Lenders need to explain why a loan was approved or rejected, so every decision point is logged. Observability focuses on extraction accuracy and cost per document. Key metrics: Field-level accuracy: Percentage of extracted fields that match manual review (measured on a holdout set). Cost per application: Total API spend divided by number of processed applications. Queue depth: Number of documents waiting for human review. When queue depth spikes, it signals either a model degradation or an influx of unusually difficult documents. The operations team investigates and adjusts routing thresholds. Deployment Shape Kita runs as a multi-tenant SaaS. Each lender gets an isolated workspace with custom validation rules and fraud thresholds. The backend is a Python service orchestrating VLM calls, validation logic, and database writes. Document processing is asynchronous. Borrowers upload files through a web form or API. The system returns a job ID immediately and processes documents in the background. Lenders poll for results or receive webhook notifications when processing completes. The VLM layer is vendor-agnostic. Kita currently uses a mix of OpenAI and Anthropic models but can swap providers based on cost, latency, or accuracy requirements. This flexibility is critical in a market where model performance and pricing change frequently. Likely Failure Modes Model drift: VLMs improve over time, but they also change behavior. A model update might improve accuracy on one document type while degrading performance on another. Continuous validation against a holdout set is required. Regional bank format changes: Banks redesign statements without notice. A template that worked last month might fail next month. The system needs a feedback loop where failed extractions are flagged, reviewed, and used to retrain or adjust prompts. Adversarial inputs: Borrowers might submit fake documents. As fraud detection improves, attackers adapt. The arms race is ongoing. API outages: VLM providers have downtime. The system needs graceful degradation, either by queuing documents for later processing or routing to a backup provider. Cost blowup: A misconfigured retry loop or a sudden spike in low-quality documents can drive API costs through the roof. Rate limiting and cost alerts are not optional. Technical Verdict Use Kita's approach when you need to extract structured data from highly variable documents in markets where traditional data pipelines do not exist. The VLM-based architecture works because it handles format inconsistencies that break template-based systems. Avoid this pattern if you have access to clean, structured data sources (open banking APIs, standardized credit bureaus). VLMs are slower and more expensive than direct API calls. Also avoid if you cannot tolerate a human review fallback. Full automation is not realistic when document quality varies this much. The real innovation here is not the VLM itself. It is the orchestration layer that routes documents based on confidence scores, validates extractions across multiple sources, and maintains auditability for regulated lending decisions. That plumbing is harder to build than the model call. Source Links Hacker News Discussion Kita Website