Writing / October 10, 2026
One customer, many roles: modelling people in lending software
Why replacing a fixed "borrower" type with customers who hold roles makes lending software simpler to extend.
Early in a lending product, the word borrower feels obvious. A loan has a borrower. The borrower has a name, a phone number and some repayments.
Then reality adds people. Someone guarantees a loan. Someone else collects repayments. The borrower on last year’s loan is a guarantor on this year’s. Soon the same person exists as three separate records, and no one is sure which phone number is current.
The problem with a type
Treating “borrower” as a kind of person bakes a role into the data model. Roles change, overlap and multiply, but people do not. When the model says a person is a borrower, every new situation becomes a new table, a new screen and a new set of exceptions.
Customers hold roles
The alternative is to model the customer once, and let roles describe how that customer relates to a loan: borrower, guarantor, co-applicant, agent, and so on.
- One record per person, with one current set of contact details.
- Roles attach to loans, not to people, so the same customer can hold different roles at once.
- Permissions and screens follow roles, which keeps access rules in one place.
Terminology is part of the design
We made this change in PaisePath as a deliberate makeover: replacing “borrower” throughout the product with a customer-and-role model. Changing the word forced us to re-examine every screen and every report that had assumed a single kind of person.
That is why I treat naming as architecture. If the language in the product is wrong, the model underneath usually is too, and changing the language first is a cheap way to find out.