A centralized loan system that shares data smoothly across surfaces, configures to any lender, and unifies applications, underwriting, payments, and reporting in one place.
Client
Business Warrior
Founding Designer
TEAM
Sole Designer, Head Of Product, 10 Engineers
Everything an underwriter needs, in one place.
An underwriter opens an application and finds everything the decision requires: submitted data, uploaded documents, verified banking activity, and the signals behind the score. From that same file they approve, deny, or request more information. Each lender configures the rules the hub runs on.
The underwriting dashboard displays all decisioning results and data from any API’s integrated into a lenders platform. From here approval, rejection, or asking the applicant for more info can be triggered.
A side by side verification interface was designed to display OCR results for documents uploaded by customers. Allowing underwriters to quickly verify bank statements, tax documents, and more.
What's owed, what's been paid, and what to do next.
A centralized hub for servicing. One account view shows what's coming due, what the borrower owes, and every payment. Admins can log a promise to pay, issue a refund, and more. Every payment shows its split between interest and principal, with lifetime totals for both, as well as additional reporting dashboards.
The servicing center clearly displays loan and payment data associated with a borrower’s account in collapsable accordions, as well as transaction tables and multiple servicing dialogs shown in modals.
Multiple dashboards were created to show all loan portfolio data clearly to admins and business owners.
How a borrower applies, decided by the lender.
Lenders choose an application flow from our screen library. They have options like pulling income data straight from Plaid. Fifty step options are a burden if you don't know which to pick, so lenders can take a recommended flow we've drawn from research and best practice.
The customer application is fully responsive and can be configured to use open banking APIs like Plaid.
Contracts and compliance handled as content, not code.
A lender uploads a document once, then decides how it behaves: a disclosure shown inline, a contract requiring a signature, or an email or SMS fired at a chosen point in the application. All in PayPlan's document center.
The document center and how uploaded disclosures are displayed in a customer application flow.
A customer portal for any loan type.
Payment tables and account headers reformat to the loan type, so the right portal is a switch rather than a build. I designed the customer portal to show all the data a borrower wants to see without overwhelming them. And for the lender, the portal can quickly be configured to show or hide any of the data they choose.
The customer portal features an account header and payment tables with different UI for each loan type.
K
Loans Funded
K
Unique Users
Every yes to a client had a cost.
Every lender wanted something bespoke, and every yes made the platform slower to deploy and harder to trust. Since we were starting from scratch, every new feature requested added to our libraries to help configure another client in the future. The downside was this strayed away from the product's goal of simplicity and efficiency and at times it felt like we were just building custom products.
With more time I'd push for more research done at the borrower level, rather than primarily lenders. Also I would want to look more into whether configurability shortened launches or just moved the work further down the line with incompatible configurations or something being overlooked for the sake of speed.
