Most abandoned loan applications are not rejections. They are people who ran out of time, lost a signal, or could not find a document while standing in a queue. The client's journey demanded everything in one uninterrupted session and discarded the rest. ELIVTECH rebuilt onboarding as a resumable pipeline where each stage is durable, extraction happens in the background, and an applicant can stop and return without losing what they had already provided.
The client offers unsecured personal lending through a digital journey that had been built as a single long form ending in a manual review queue. Applicants uploaded photographs of documents that a reviewer transcribed by hand, bureau checks were requested individually by an operator, and underwriting decisions applied policy that lived in staff knowledge rather than in the system. Applications routinely took days and produced inconsistent outcomes. ELIVTECH rebuilt the journey as a resumable, stage-based pipeline on Laravel, added a Python extraction service that reads uploaded documents and returns structured fields with confidence, and replaced discretionary review with a configurable rules engine that decides automatically where policy is clear and refers only genuine edge cases.
At a glance
The challenge
A journey that demanded perfect conditions and treated any interruption as an abandonment.
One session or nothing
The application held its state in the browser session. An applicant who lost connectivity, closed the tab or went to find a document returned to an empty form. Most of the drop-off was people who intended to continue and had no way back to the point they had reached.
Documents transcribed by hand
Uploaded identity and income documents were read by a reviewer who typed the values into the system. The work was slow, arrived in batches, and introduced transcription errors into exactly the fields that decisions depended on. Applicants waited on a queue rather than on a check.
Bureau checks requested one at a time
An operator initiated each bureau enquiry individually, in office hours, after the manual document review had completed. Checks that could have run concurrently ran in sequence behind a human step, so most of the elapsed time in an application was waiting rather than processing.
Policy held in individual judgement
Underwriting rules existed as guidance documents interpreted by reviewers. Two similar applications could receive different outcomes depending on who assessed them, and when policy changed there was no reliable way to confirm it had been applied consistently from a given point onward.
No visibility for the applicant
Once submitted, an application disappeared. Applicants had no view of which stage they had reached or what was outstanding, so they called to ask, and the support volume that generated was itself a consequence of a missing status view.
Sensitive documents held loosely
Identity and income documents accumulated in general-purpose storage with broad access and no retention rule. The material was among the most sensitive the business handled and was governed by the least deliberate controls in the platform.
Our solution
Durable stages, background extraction, and policy expressed as configuration rather than judgement.
Journey Decomposition and Policy Capture
Four weeks decomposing the application into stages that can each complete independently, and working with the credit team to express underwriting policy as explicit, testable rules. Establishing which decisions genuinely require human judgement and which only required it because the system could not decide was the distinction that determined how much of the journey could be automated.
Resumable Pipeline on Laravel
Each stage persists on completion and the application carries an explicit state, so an applicant returning on a different device resumes exactly where they stopped. Stages that do not depend on each other run concurrently as queued jobs, and a failed external call retries in the background rather than presenting the applicant with an error they can do nothing about. Bureau responses and verification results are stored against the stage that requested them, so a resumed application does not repeat a check that has already been paid for and answered.
Python Document Extraction with Confidence
A Python service performs optical character recognition and field extraction on uploaded documents, returning structured values with a confidence score for each. High-confidence fields populate the application directly, low-confidence fields are presented to the applicant for confirmation while they are still present, and only genuinely unreadable documents reach an operator. Capture guidance runs on the device before upload, prompting for glare, cropping and focus problems at the point they can still be corrected rather than after a reviewer rejects the image.
Rules Engine, Consent and Data Protection
Underwriting policy runs as a versioned rules engine that records which version decided each application, so an outcome can be explained after the fact. Documents are encrypted with managed keys in isolated storage with scoped access and enforced retention, and consent for each bureau check is captured explicitly and recorded against the application. Access to a stored document is logged with the operator and the reason, so the audit trail covers who looked at sensitive material as well as who decided the case.
Technology stack
Results
Measured once the full journey was live and the rules engine was deciding clear-policy cases.
Before and after: platform engineering measures
- Application state held in the browser session only
- An interruption discarded everything already entered
- Documents transcribed manually by a reviewer
- Bureau checks initiated one at a time in office hours
- Underwriting policy interpreted from guidance documents
- No applicant view of progress after submission
- Sensitive documents in general storage without retention rules
- Each stage persisted, with explicit application state
- Applicants resume on any device from where they stopped
- Fields extracted automatically with per-field confidence
- Independent checks run concurrently as queued jobs
- Policy executed by a versioned rules engine
- Live status view showing stage and outstanding items
- Encrypted isolated storage with scoped access and retention
Project timeline
Journey Decomposition and Policy Capture
Stage boundary definition, drop-off analysis from existing journey data, underwriting policy expressed as testable rules with the credit team, and data protection and consent requirements documented per integration.
Pipeline Foundation
Laravel application state machine with per-stage persistence, cross-device resume, queued concurrent execution of independent stages, retry and backoff on external calls, and the deployment pipeline on containerised AWS infrastructure.
Document Extraction Service
Python extraction service with per-field confidence, in-journey confirmation for low-confidence values, image quality guidance at capture time, operator fallback for unreadable documents, and evaluation against a labelled document set.
Bureau Integration and Rules Engine
Concurrent bureau and verification integrations with explicit consent capture, versioned underwriting rules engine with decision recording, referral routing for genuine edge cases, and the applicant status view.
Assurance and Controlled Launch
Shadow running the rules engine against historical applications to compare outcomes, security review of document handling and key management, monitoring on stage completion and extraction confidence, then a controlled launch by product.
Key takeaways
What shaped the engineering decisions
- Persist per stage, not per submission: Saving a draft at the end was rejected because it still loses everything on interruption. Committing each stage as it completes means the applicant's effort survives whatever happens next.
- Return confidence with extracted fields: Accepting extraction output silently would put unverified values into a credit decision. Per-field confidence lets high-certainty fields populate directly while uncertain ones are confirmed by the applicant, who is the cheapest and fastest verifier available.
- Run independent checks concurrently: Sequencing bureau enquiries behind a manual review meant most elapsed time was queueing. Modelling stage dependencies explicitly showed which checks never needed to wait for each other.
- Version the policy, record the version: A rules engine without versioning cannot explain a past decision once policy has moved on. Recording the deciding version made outcomes reconstructable, which is what the automation had to satisfy before it could be trusted.
- Shadow run before switching: The rules engine was run against historical applications and its outcomes compared with the decisions reviewers had made, so disagreements were examined while they were still hypothetical.
- Isolate sensitive documents from the start: Encryption with managed keys, scoped access and enforced retention were built into the first version of document handling, because these controls are far harder to retrofit once material has accumulated.
Want results like these?
Let's discuss how ELIVTECH can drive measurable outcomes for your business.
Start your project