The challenge
A lending business was processing credit applications through a chain of email threads and shared folders. An application arrived with documents attached, moved between an intake officer, a credit reviewer, and an approver as forwarded messages, and the record of a decision was whichever email happened to contain it. Applicants were asked for the same document more than once because nobody could see what had already been collected.
The lending policy itself lived in a document that reviewers were expected to remember. When a threshold or a required document changed, there was no way to know which applications had been assessed under the old rules and which under the new — a serious problem for a business that has to be able to explain, months later, exactly why a specific application was declined.
Approval controls were informal. Nothing in the process structurally prevented the same person from both preparing and approving an application, and there was no complete, tamper-evident record of who did what and when.
Our approach
We built an internal loan origination system that models an application as a case moving through explicit stages, each with its own required inputs, its own permitted actions, and its own set of reviewers. Documents are collected against a checklist attached to the product being applied for, so what has been received and what is still outstanding is visible to everyone touching the file — including the applicant, who is asked for a specific missing item rather than a general resubmission.
Lending policy was moved out of a written document and into versioned, configurable rule sets. Each application records which policy version it was assessed against, so a decision can be re-examined later under exactly the rules that applied at the time rather than the rules in force today. Rules are editable by authorized staff through the system, which means adjusting a threshold is a controlled, logged change rather than a development task and an email announcement.
Segregation of duties is enforced by the system, not by convention: preparation and approval are distinct permissions, and an application above a configured limit requires a second, independent approver before it can proceed. Every state transition, document upload, rule evaluation, and comment is written to an append-only audit log with the acting user and timestamp, giving the business a complete reconstruction of any file long after the decision was made.
Outcome
An application is now a single case with a visible stage, a document checklist, and an assigned reviewer, rather than a thread of forwarded email. Each decision carries the policy version it was made under and a complete audit trail of every action taken on it, and approval limits are enforced by the system instead of relying on staff to observe them.