Designing a loan audit and rebuttal platform from zero
Mortgage lenders face mandatory quality-control audits where every defect found in a closed loan can trigger a financial penalty or buyback. The rebuttal process, where analysts dispute those findings, was handled entirely over email, PDFs, and spreadsheets. I designed the 0→1 platform that replaced it.
- Role
- Lead Product Designer
- Team
- 1 Designer · 2 PMs · 4 Devs · 1 QA · 1 BA
- Timeline
- 6–8 months
- Platform
- Web · Internal Tool
- Outcome
- Full rebuttal workflow moved off email and spreadsheets
What a loan audit actually is
After a mortgage closes, the lender is required to submit a sample of loans for quality-control audit. An external auditor reviews each loan file against compliance checklists and flags defects: anything from a missing signature to an incorrect income calculation. Defects are graded by severity: Minor, Significant, or Critical.
The lender then has a fixed window, typically 14 days, to respond to each defect. They can Accept it (acknowledge the error) or Respond with a rebuttal (dispute the finding with evidence). If a Critical defect is not successfully rebutted, the lender may be required to repurchase the loan. The financial stakes are real and the deadlines are hard.
The people doing this work, compliance analysts and underwriters, are expert users. They understand the domain deeply. What they lacked was a system that matched that expertise: a structured workspace instead of an inbox.
Email, spreadsheets, and missed deadlines
Before this platform existed, the entire rebuttal process lived across three tools that were never designed to work together: email threads for communication, spreadsheets for tracking status, and PDFs for the actual audit findings. There was no single view of where any audit stood. Managers had no visibility into which rebuttals were pending, which were overdue, or which analysts were overloaded.
The consequences of a missed deadline were not recoverable. A rebuttal not submitted in time was treated as accepted, meaning the lender absorbed the defect and its financial implications. The system needed to make deadlines impossible to miss and status impossible to misread.
What we were working within
Compliance audit trail
Every action in the system needed to be logged and timestamped. Regulators can request records of who responded to what defect, when, and with what evidence.
Hard deadlines, no extensions
Rebuttal windows are set by the auditor and cannot be moved inside the platform. The UI had to make deadline proximity clear without creating anxiety on every row.
Expert users, not casual ones
Analysts reviewing defects understand mortgage compliance. The interface could be dense. They did not need tooltips explaining what a DTI ratio is. Clarity over simplification.
Solo designer on a 9-person team
One designer across discovery, all design, QA support, and stakeholder reviews. Decisions had to be defensible and documentation thorough enough for 4 developers to build from.
Understanding the workflow before designing it
The first weeks were spent mapping the existing process end to end, not by reading documentation, but by sitting with the analysts who did the work. The audit lifecycle had five distinct stages that needed to be visible at all times: a loan enters as New, moves through Initial Review where the auditor selects and reviews loans, enters Rebuttal when defects are flagged, goes to Final Review after responses are submitted, and closes as Completed.
Three insights from these sessions shaped the information architecture. First: analysts needed to see all their audits at once, not one at a time: the queue view was more important than any individual case view. Second: the most anxiety-producing moment was not knowing whether a submitted rebuttal had been received. The old system had no acknowledgment state. Third: managers and analysts needed completely different views of the same data: managers needed roll-up numbers; analysts needed their specific queue.
Four decisions that defined the system
The audit data had three levels: audits containing loans containing defects. Flat tables would lose the hierarchy; separate pages for each level would lose context.
A single expandable table where audit rows expand to show loans, which expand to show defects, all within one scrollable view.
Why: Analysts needed to move fast across multiple loans in one audit. Navigating to separate pages for each level added friction to a time-pressured workflow. The expand-in-place pattern kept context visible while allowing depth.
The rebuttal action, Accept or Respond, is consequential and irreversible. But it needed to be fast. A modal for every defect would slow down analysts working through 20+ defects in a session.
A slide-in panel from the right, triggered per defect row, showing full defect context alongside the response interface, without leaving the defects table.
Why: The panel kept the defects list visible in the background so analysts could see what was next. Showing the auditor's comment, severity, and category in the panel header meant analysts had everything needed to decide before writing a single word.
Status needed to be visible at every level: audit status, loan status, defect status. Using different visual systems for each level would create cognitive load.
A unified status tag system with consistent color-meaning across all three levels: yellow for pending action, blue for submitted/in-progress, green for resolved.
Why: A compliance analyst scanning 10 audits, 30 loans, and 90 defects needs to pattern-match status instantly. Consistent color semantics meant the visual grammar was learned once and applied everywhere.
The Trending section needed powerful filtering across time, category, severity, loan type, but filter-heavy interfaces are notoriously hard to use without overwhelming.
A filter bar with dropdowns for each dimension, a single Generate Graph action, and a reset that clears all at once. No auto-update on filter change. The analyst sets all filters then commits.
Why: Auto-updating on every filter change created jarring visual redraws while analysts were mid-configuration. The explicit Generate action gave users a sense of control and made cause and effect clear.
The assumption that didn't survive contact with users
My first version of the rebuttal flow put the Accept and Respond options on the defects table row itself: two small buttons inline with each defect. The assumption was that analysts would want to act quickly without opening anything.
User testing showed the opposite. Analysts felt uncomfortable making an Accept decision, which is legally consequential, from a button in a table row with no surrounding context. They wanted to see the full auditor comment, the defect category, and the significance level before committing. The inline buttons felt too casual for a high-stakes action.
The panel design came directly from that feedback. Moving the action into a dedicated panel that surfaces all context first added one interaction step and significantly reduced analyst hesitation. It also created the right mental model: you are entering a review mode, not clicking a button.
From inbox to platform
The platform gave compliance teams a structured workspace that matched the seriousness of the work. Managers gained real-time visibility into audit status across all open cycles. Analysts gained a clear queue, deadline awareness, and confirmation that their submissions were received. The rebuttal tracker, showing Submitted → Under Review → Final Decision, addressed the single most anxiety-producing gap in the old process: not knowing if your email was seen.
Where AI fits in this workflow
The rebuttal process is a strong candidate for AI assistance, not to make decisions, but to reduce the time analysts spend preparing responses. The pattern mirrors what leading insurers now describe for their claims operations: agentic AI supporting human reviewers through document review and response drafting, while licensed professionals retain the final judgment.
Concretely: an AI layer could pre-read the auditor's defect finding, locate the relevant document in the loan file, and draft a rebuttal response for the analyst to review and edit, rather than requiring the analyst to write from scratch. The design challenge is not the AI capability; it's the interface for human review of AI-generated content: confidence indicators, evidence citations that link claims to source documents, and a clear gate where the human approves before submission.
The Respond to Defect panel already has the right bones for this. The evidence upload becomes an AI citation panel. The comment field becomes a reviewed and edited draft. The Submit button stays exactly where it is. The human still signs off.