A centralized loan system that shares data smoothly across surfaces, configures to any lender, and unifies applications, underwriting, payments, and reporting in one place.
Product Surfaces
+
Screens Designed
To lend money, you had to assemble the system yourself.
A small business or private lender that wants to offer financing buys its stack in pieces: one vendor for the application, another for underwriting, payments, reporting, email for anything the borrower needs told. Borrowers see the cracks this creates: inconsistent portals, unclear balances, and no dependable answer to what they owe.
What the platform had to do
1.
Unify the lending stack into one configurable system.
2.
Ship as any lender's product, under their brand.
3.
Quickly configure new lenders with their underwriting and servicing rules.
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.
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.
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.
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.
