A community credit union with about 40,000 members was losing loan applicants to the wait. Personal and auto loan applications arrived as PDF attachments, were keyed into the core system by hand, and took a median of four days to decide. Twenty weeks later, members apply through a guided flow in new loan origination software, most decisions arrive in about forty minutes, and loan officers spend their time on the applications that need a human.

This is how that happened: what was built, the one decision that mattered most, and what we would change.

The situation

The credit union's online banking vendor offered a loan application module, but it was a form that emailed a PDF. Staff re-entered every field, requested documents by phone, and ran identity and credit checks manually in three separate systems. Applicants who could get a decision from a fintech lender in minutes often did.

When we walked through the process with the lending team, most of the four days was not work. It was waiting. A PDF sat in a shared inbox until someone picked it up. A missing pay stub meant a phone call, then a voicemail, then a second call the next day. Each of the three checks needed its own login and its own copy of the applicant's details. The actual review on a clean application took an experienced officer well under an hour. The rest was queue time and handoffs.

That diagnosis shaped the project. The problem was not slow decisions. It was a process with too many places for an application to stall.

The goal and the constraint

The goal was a same-day decision for most applications and a complete, auditable file for every one. The constraints were the core banking system, which had to remain the system of record; the compliance programme, which required every identity check and adverse-action notice to be logged; and a board-approved budget with no room for a second phase before the next fiscal year.

Each constraint ruled something out. Keeping the core as the system of record meant no parallel loan database that could drift from it. The logging requirement meant decisions could not live in someone's head or an email thread. The fixed budget meant one release had to deliver the whole value. A "phase one" that still required manual entry into the core would have been a failure, because no phase two was funded to finish it.

The loan origination software we built

A member-facing application flow and an officer console, with the core system integrated on both sides.

  • Application flow: a Next.js app that asks only the questions the loan type needs, captures identity documents and pay stubs by phone camera, and links the applicant's external bank account through Plaid for income verification.
  • Decisioning: identity verification and fraud screening through Alloy, a soft credit pull, and a rules engine the lending team maintains in configuration. Applications that pass every rule are approved automatically within policy limits; the rest queue for an officer with the reasons highlighted.
  • Officer console: a queue, the full file, the rule outcomes, counter-offer tools and the adverse-action notice generator, with every action written to an append-only log.
  • Core integration: member lookup and existing-relationship data read from the core's API; the funded loan, its schedule and documents written back on approval.
  • Team and timeline: four engineers and a designer across ten sprints, with the compliance officer in the sprint review from sprint two.

A few choices are worth explaining. The application flow pre-fills what the core already knows about existing members, so a returning member answering questions about an auto loan sees a short form, not a long one. Asking fewer questions is the cheapest way to cut abandonment.

The rules live in configuration rather than code because policy changes more often than software releases. When the lending team adjusts a debt-to-income threshold, they should not need a developer, a pull request and a deploy. They do need a review step and a record of who changed what, so rule changes go through the same append-only log as decisions.

We sequenced the build around risk. The core write-back was the least certain piece, so it started in sprint two, not sprint eight. The member flow, which we had built variations of before, came later. That ordering is why the sandbox problem described below cost one sprint instead of the launch date.

We did look at off-the-shelf loan origination software. Packaged suites are a reasonable choice for many lenders. Here, the options we reviewed either duplicated data the core already held or needed configuration work comparable to a focused build, and none matched the member experience the credit union wanted inside the fixed budget.

The hard decision

Automatic approval. The lending team wanted every application to pass through an officer, which would have left the median wait at hours rather than minutes. We proposed a narrow auto-approve band: existing members, within policy limits, every rule passed, with a daily report of every automatic decision for the first ninety days. The board agreed to the pilot. After ninety days without an exception the band was widened. The decision was about trust, and the daily report was what earned it.

The objection was reasonable. A bad automatic approval is a loss, and it is a loss with no person to explain it. Our answer was to make every automatic decision as reviewable as a manual one. The daily report listed each approval with the rules it passed and the data each rule used. An officer could read the day's automatic decisions in minutes and flag anything that looked wrong. Nothing did. That record, not our argument, is what moved the board.

The bad version of this decision is common: automate everything at launch and hope, or automate nothing and keep the queue. Starting narrow, measuring and widening is slower, but it leaves the institution in control of its own risk appetite.

Results

Median time from submitted application to decision fell from about four days to about forty minutes, measured on the credit union's own loan data over the first two quarters. Roughly half of applications were decided automatically within policy. Manual data entry ended; the core system's loan records were created by the integration. Application abandonment, which had never been measured before, became a number the team watches weekly.

Applications that go to an officer still take longer than forty minutes, and they should. Those are the files with a thin credit history, a mismatch in income or a request outside policy. The difference is that officers now open them with the documents attached, the checks complete and the failing rules highlighted. They are reviewing, not assembling.

What we would do differently

Involve the core banking vendor's professional services earlier. Their API documentation was accurate but their sandbox lagged production by a version, which cost us a sprint of rework on the write-back. A paid half-day with their team in discovery would have found it.

We would also instrument the old process before replacing it. Because abandonment had never been measured, we can say it is now tracked but not how much it improved. A few weeks of baseline data, even rough, would have made that result something we could state.

How a project like this starts

With discovery that maps the current application end to end, names every system it touches and every rule that applies, and ends in a scope with a fixed price and the integration order. If your institution's loan process still runs on PDFs and patience, tell us about it.

Typically that discovery takes two to four weeks. It includes sessions with lending, compliance and IT, access to the core vendor's API documentation and sandbox, and a written list of every decision rule in current policy. Bring your compliance officer from the first meeting. Their requirements shape the data model, and finding them late is expensive.

Frequently asked questions

Did the credit union need a new core system?

No. The core stayed as the system of record; the new flow reads from it and writes the funded loan back through its API. If your core exposes member lookup and loan creation through an API, the same pattern usually applies. If it does not, that is the first thing discovery has to resolve.

How were fair-lending and adverse-action rules handled?

The rules engine is configuration the lending and compliance teams own, every decision is logged with its reasons, and adverse-action notices are generated from those reasons automatically. Examiners can trace any decision from the application data to the rule outcomes to the notice the member received.

What did it cost?

We do not publish client figures. Twenty weeks of four engineers and a designer at typical US agency rates will put you in the right range; identity and verification vendors are billed separately at usage.