MDRM IQ: regulatory intelligence for community banks, built and run solo

[PERMISSION NEEDED: Kevin] — This case study describes a product I co-own with Kevin Whitworth through Unomia Labs LLC. Our names and the company appear on the public site; the architecture and process details below do not. Nothing publishes until Kevin has read and approved it. No customer is named anywhere in this document, and none will be.

The problem

Every FDIC-insured bank files a call report each quarter: thousands of line items, each identified by an eight-character MDRM code. Examiners read those filings against published supervisory criteria. Community banks mostly read them in Excel, after the fact, and learn where they stand when the examiner tells them.

My co-founder’s thesis: the data to answer “what will the examiner find?” is public and complete, and nobody has made it usable for a $300 million bank with a two-person compliance function. The product had to hold every line item for every institution, compute the ratios regulators publish, cite the rule behind every threshold, and never blur the line between what a bank filed, what the FFIEC published, and what we computed.

He had the domain knowledge and the customers. I had to build and operate the entire platform.

Constraints

• Informational, not decisional. The product detects; the human decides. No feature may predict an exam outcome, value an institution, or recommend a transaction. That boundary is attorney-reviewed and pinned sentence by sentence by a test.
• Provenance on every number. Published figures are labeled published; recomputed ones are labeled recomputes; a trimmed peer average is never called a median; a bank that did not report a measure is excluded, never imputed. Product rules, enforced in code.
• Bank-grade access control. Multi-tenant organizations with seats, scoped examiner guest access, a tamper-evident document vault, and hardened, separately authenticated administration.
• Paying customers from mid-2026. Every production change had to be reversible in seconds.
• One engineer. Data loaders, Stripe webhook, deploy script: mine to build, test, run, and fix at 2 a.m.

What I built

MDRM IQ is a Next.js 16 application on PostgreSQL via Drizzle ORM, Redis, Auth.js, Stripe, and the Anthropic Claude API. It ships 277 API route handlers and a public surface where each of 4,296 institutions has a permanent, no-login profile.

The data spine is the foundation: a dedicated PostgreSQL instance holding 41 quarters of call-report filings (about 208,000 filings, roughly 296 million filed values), the full published UBPR ground truth (about 400 million rows), FDIC branch-deposit data, and the MDRM dictionary (87,693 items). A quarterly loader ingests each FFIEC drop; a verification layer recomputes published ratios and flags disagreements.

On the spine sit eight analytical domains (57 signals) with a five-state vocabulary: breach, approaching, drifting, passed, not evaluated. A rules-based audit engine runs 55 rules across 11 categories, each citing its published standard and carrying a declared validation status; a rule not validated to fire renders as a ceiling, never an alarm. The readiness suite adds posture tracking, a mock examiner, a WORM document vault, an inquiry workflow, and Puppeteer-rendered exam binders. Market tools let a banker draw a peer set by county, radius, or hand-drawn shape, read a county deposit map, and model a combination against 1,581 structural precedents.

Proctor is the AI analyst. It plans a query over the spine, runs it, and narrates the result. The doctrine is strict: a result is one object, narration may never introduce a figure the query did not return, Proctor never silently substitutes a different subject bank, and every answer names the MDRM codes it used.

Commercially: Stripe subscriptions with per-customer pricing, a webhook mapping subscription metadata to entitlement, admin-issued invitations and trials, and organization seats that inherit the organization’s plan.

Architecture

A web application in front of two data stores: an application database and a read-only regulatory data spine built from public FFIEC, UBPR, FDIC, and MDRM sources. An AI analyst plans and runs queries against that spine and narrates results without inventing figures. Billing, document rendering, scheduled loaders, and a verification layer sit alongside. The details that matter to a buyer are operational: every change deploys to a dev environment first, the full test suite runs fail-closed before any build, the same artifact is promoted to production, and the previous build stays on disk for a seconds-long rollback.

Results

• In production with paying community-bank customers; V3 (the spine-backed rebuild) promoted 2026-09-01 with no customer-visible downtime.
• 1,176 commits between 2026-03-23 and 2026-09-29. Version 3.67.0 at the time of writing.
• Public site claims, all verifiable: 3,929 call-report items, 4,296 institutions, 41 quarters, 690 enforcement actions, 1,581 combination precedents.
• The deploy gate grew from 2,914 tests / 131 files at v2.39.0 to 14,276 tests / 516 files at v3.49.3. One test exists to prove every test file on disk is actually collected, after I found a guard that had never run once.
• Accuracy verified by rendering production PDFs against published UBPR values line by line; a fallback that misstated three CRE ratios was found this way and removed.

What this proves

• MVP Sprint: first commit to a paying regtech product in under four months, with billing, multi-tenancy, and compliance surfaces, built by one engineer.
• AI Integration: the LLM is bounded by design: it plans over a verified data layer, cannot invent figures, names its sources, and has a one-line kill switch. That is the shape I recommend for any regulated domain.
• Legacy Modernization: same-SHA promotion, fail-closed gates, and verified rollback targets are the discipline I apply when the system being moved is someone else’s.

Similar project?

Building a data-heavy product for a regulated industry? Book a 20-minute call.