Everything eqLend does is driven by rules. Which rules, in what language, and who is allowed to change them is the most consequential thing about the platform — more consequential than any individual feature.
The four rule sets
| Rule set | Determines | Owned by |
|---|---|---|
| Processing task rules | What has to happen on a file, and in what order. | The lender |
| Needs list rules | What is asked of a borrower, and when. | The lender |
| Underwriting condition rules | What the shop conditions for, in the shop’s own wording. | The lender |
| Quality control rules | What post-closing review checks, and what it feeds back upstream. | The lender |
Together these are more than configuration. They are the operating knowledge of the institution — the accumulated judgment of processors, underwriters and auditors, written down in executable form. For most lenders it is the first time that knowledge has existed in one place rather than in checklists, training binders and the heads of senior staff.
Authoring
Workflows are modelled in a visual Business Process Model and Notation (BPMN) designer, so a process is something an operations leader can read rather than something only an engineer can interpret. Rules are expressed in your language — the way your shop words a condition — not vendor boilerplate.
Portability
Rules are yours. The design intent is that the operating knowledge encoded in them is a lender asset rather than a switching cost — that a decision to change LOS, extraction provider or automation vendor is a business decision, not a hostage negotiation.
Why this framing
A vendor whose model depends on holding your rules is retained by custody. A vendor whose rules you own has to be retained by performance. eqLend is built for the second relationship, which is also the one that survives a procurement review.