Case Study · Loan Deboarding Portal
Designing One Release Pipeline for Many Operational Shapes
The Challenge
Clients on the platform prepare release packages in their own way — different LOS systems, different report formats, different investor mixes. The receiving team absorbs that variation as exceptions and side conversations. There’s no shared structure for validation, ownership, or reconciliation.
The Solution
A portal designed to absorb upstream variation and enforce shared structure downstream. Submissions are validated at the door, exceptions move through a defined lane with audit trail, and reconciliation is stitched to the release record — informed by deep research with three representative client orgs.
1 record
Per submission, regardless of how a client prepared its data
documents, status, exceptions, and reconciliation all stitched to one release
9/9
Prototype users found release status unaided
across walkthroughs with three representative client orgs
~6 hrs
Projected weekly time saved per analyst
interview baseline: status follow-ups + parallel reconciliation sheets
A release record — milestone timeline with per-loan progress at every stage
WHAT
A submission and tracking portal for loan deboarding — secure upload, live milestones, structured exception handling, and reconciliation, all in one place.
WHY
Clients send release packages by email and then go silent for days. Errors surface late, status lives in scattered threads, and accounting can’t tell what funds belong to what.
WHO
Mortgage clients submitting interim servicing releases — release analysts, client operations leads, and accounting teams handling post-release reconciliation.
WHERE
A new module inside an existing client portal — a secure submission and pipeline workspace replacing today’s email + Excel workflow.
Details, such as names, workflows, and interfaces, have been modified to maintain confidentiality.
Problem area
What’s missing isn’t visibility — it’s structure
Clients on the platform have each invested in their own internal preparation tools, so submissions land in different shapes from different systems. The receiving team absorbs that variation as exceptions, escalations, and side conversations. The design problem isn’t “show me what’s happening” — it’s “give the workflow a shared structure so many different operational realities can coexist.”
Submissions arrive in different shapes
Even within the three orgs we interviewed, the patterns varied widely — Encompass plus an Access database for one, a custom LOS report for another, an aggregator matrix for a third. Across the rest of the platform’s clients, that variation only widens. There’s no shared validation layer, so formatting issues are caught downstream, not at the door.
Exceptions handled by escalation, not workflow
Formatting kickbacks, MERS updates, missing scheduled dates, and investor approval delays all turn into email threads routed through a single escalation contact. There’s no structured exception lane — no SLA, no owner, no audit trail.
Reconciliation reconstructed by hand
After release, manifests, escrow returns, and unfunding adjustments arrive across separate systems. Accounting teams cross-reference by hand because nothing ties post-release activity back to the release record.
"This should work like a workflow or ticketing system. One record per submission, with assignment and history."
— Client Ops Lead, Investor Servicing Group
"Email is risky. We want secure upload and a dashboard — not a chain of forwards."
— Director of Client Operations, Mortgage Lender
A clear theme surfaced from the synthesis: clients didn’t just want notifications, they wanted ownership of the pipeline. They wanted to see where each loan was, who held it, and what — if anything — was blocking it. They wanted email to step back and become a fallback, not the system of record.
DESIGN GOALS
What I aimed to achieve
Move validation upstream
Catch formatting issues, missing fields, and duplicates at the moment of submission — not three days later, downstream of the receiving team. The sender should see the error first.
Give exceptions a workflow
Replace escalation-by-email with a structured exception lane: type, owner, SLA, resolution log. Make exceptions a first-class state, not a side conversation.
Absorb client variation into one record
Design a release record that takes each client’s upstream shape and presents one shared structure downstream — so the receiving team isn’t doing manual reconciliation across many different operational realities.
Solution
One structured pipeline that holds the platform’s variation
A release record that absorbs how each client prepares its data, different LOS systems, different reports, different investor mixesand gives the receiving team one shared structure downstream.
A confirmed submission
Every package gets a receipt and a record
Today, clients send Excel + Purchase Advices to a shared inbox and wait. I designed the submission flow so that within seconds of upload, clients see what was accepted, what needs fixing, and the record ID created on the receiving side.
1
Validation · Error Prevention
Bulk upload with inline validation
Why: Formatting kickbacks were one of the top sources of rework — wrong report version, missing date, mismatched investor codes. I moved validation to the front of the workflow so common mistakes get flagged the moment a file is uploaded.
Clients see field-level errors in plain language, fix them in place, and submit cleanly the first time — instead of finding out three days later through a forwarded email.
2
System Status · Confirmation
Acceptance receipt + release record
Why: Without a confirmation, clients didn’t know if their package was received, queued, or stuck in spam. I made the system create a release record with a unique ID the moment a submission is accepted.
Every accepted submission shows up immediately on the client’s dashboard with a record ID, owner, and starting status — making “Did you get it?” emails unnecessary.
🚨 MVP scoping decision
Bulk PA upload was prioritized for launch to mirror today’s mental model. Phase two reduces PA dependency by collecting the exact fields the receiving team needs directly inside the form — documents become required only for audit and exceptions.
A tracked pipeline
One record, every milestone, no inbox digging
Once a release record exists, clients see it move. The dashboard surfaces aging up top; each record opens to a full timeline plus reconciliation.
1
Visual Hierarchy · Aging Signals
Pipeline dashboard with aging
Why: Clients told me they didn’t just want a list — they wanted to know which loans were at risk. So the dashboard surfaces aging records, SLA breaches, and “waiting on investor” states up top, before anything else.
A release analyst can land on the dashboard in the morning, see the three loans aging out, and know exactly where to spend the next thirty minutes — instead of triaging a 200-message inbox.
2
Timeline · Blockers · Audit Trail
Live milestone timeline per release
Why: Status today is reconstructed from email threads and reports. I built a timeline that shows each milestone — Received, Tagged, Goodbye letter, Scheduled, Released — with timestamps and a visible “waiting on investor” state when the ball is in someone else’s court.
When a release is delayed, clients can see exactly where it’s sitting and why. Exception handling — holds, fixes, escalations — happens inside the record with a full audit trail.
3
Reconciliation · Accounting Handoff
Post-release reconciliation snapshot
Why: Accounting teams kept asking ops “what is this money?” because escrow returns, manifests, and unfundings showed up days after the release with no clear context. I added a reconciliation view that ties amounts, dates, and references back to each release record.
Accounting and ops finally share one source of truth for what happened after release — fewer detective tickets, faster month-end, and a clean handoff between teams.
Validation
Did it work?
The portal is in early build, scoped down to a focused MVP: secure submission + reliable status tracking. To pressure-test the design before development, I ran prototype walkthroughs with release analysts and client operations leads from three client organizations. The signal was strong.
9/9
Participants found their submission
Every interviewee located a tracked release on the dashboard within seconds — no instructions needed.
100%
Validation errors fixed inline
In the prototype, every formatting error was caught and corrected during submission instead of post-send.
3/3
Client orgs aligned on MVP scope
All three client groups confirmed that secure submission + pipeline status would replace their current spreadsheet-and-email workflow.
Post-launch
What I’ll monitor after launch
Once the MVP is live, I’ll watch for three signals to confirm the portal is doing its job — and to surface where phase two should focus.
📩
Drop in inbound status emails
I’ll track the volume of “did you get it?” and “where are we?” emails. A drop signals clients trust the portal as the source of truth.
⚠️
Submission errors caught at the door
I’ll measure how many formatting issues get flagged during upload vs. downstream. Higher catch-rate means less rework and fewer kickbacks.
📊
Reconciliation cycle time
I’ll track how long it takes accounting to close out a release after funds move. A shorter cycle confirms the reconciliation snapshot is doing its job.
Case study · Dinesh Kumar · Loan Deboarding Portal · 2026