The institution already had a 15-minute personal loan processing proposition. The friction existed in the activities surrounding those 15 minutes. Customer verification, employment checks, company validation, document review, and financial assessment involved multiple sources, stakeholders, and manual interventions. Information could exist digitally without being available to the person making the lending decision when it mattered.

Crizzen was brought in to redesign this verification layer around a clear objective to make background verification and pre-screening as fast and seamless as the lending journey it supports. Over approximately six weeks, Crizzen worked with the institution’s business and technology stakeholders to understand the existing operating model, define the future-state solution, identify appropriate AI capabilities, design the architecture, and create an implementation roadmap. This was a strategy and solution-design engagement, meaning Crizzen did not implement or deploy the proposed platform.

Download the case study

01 | The business challenge

A 15-minute loan journey needs a verification layer that can keep up

The institution’s personal lending proposition was built around speed. The loan journey was designed to move quickly from application to disbursement. The verification activities supporting that decision still depended on information being manually collected, interpreted, and reconciled across different sources. The primary hurdle centered on the effort required to establish whether the information was complete, consistent, and sufficiently reliable for the next decision.

An applicant could declare active employment while already serving notice. A salary slip could show one employer while tax records or bank transactions suggested an alternative scenario. An applicant’s salary could appear consistent while the bank account contained recurring obligations, additional EMIs, unusual deposits, or other signals requiring review. Company information could also change after being added to an internal database.

These situations created a verification layer that could become a bottleneck around an otherwise fast lending journey. The client’s business requirements identified manual company classification, employment validation, and salary-credit validation as important sources of inconsistency, delay, and error. The opportunity involved redesigning the process around automated verification, structured evidence, and exception-led human review.

02 | Understanding the operating model

Crizzen started with the process before evaluating the technology

The engagement came through a personal reference from an existing vendor of the institution. Over approximately six weeks, Crizzen worked with the relevant business and technology stakeholders through regular weekly calls and working sessions. The Crizzen team included two members spanning business and technology.

The first step was to understand the current operating environment by examining how verification worked today. We mapped where information was generated, where it was stored, which checks were already automated, and which checks required human intervention. The analysis also covered which external sources were involved, where information could become stale, and which decisions ultimately required human judgement.

The team received a detailed debrief of the existing systems, workflows, and architecture. That led to an important design principle to ensure the future solution worked with the existing technology environment wherever possible, rather than requiring the institution to replace its existing architecture. The proposed approach therefore focused on adding intelligence around the existing lending process.

03 | Reframing the verification problem

From fragmented evidence to a connected decision-support layer

The existing process could require an officer or analyst to gather information from several sources including applicant inputs, employer information, government records, credit bureau information, banking information, tax records, and supporting documents. The information itself was generally available, but the difficulty lay in bringing it together, validating it, and interpreting it quickly enough.

Crizzen proposed a central verification intelligence layer between the existing data sources and the institution’s Loan Origination System. The conceptual flow initiated with applicant inputs and data acquisition, progressing to document extraction and data normalization. The process then moved through identity and entity matching, company intelligence, employment verification, and financial analysis. Finally, the system conducted risk and exception detection before presenting the data in the LOS decision-support interface for human approval or rejection.

Verification outcomes would also be stored within the LOS to support downstream reporting and audit requirements. The architecture was designed to make the evidence available in a structured form before the officer reached the final decision.

04 | Designing around exceptions

Automation where the evidence is clear alongside human attention where judgement is required

One of the central design decisions was to avoid treating complete automation as the objective. Instead, applications would move through three operating paths.

Straight-through cases involve consistent information where required checks are completed successfully and no material exceptions are identified. The application continues through the process without requiring analyst intervention.

Automated exception cases occur when the system identifies a known discrepancy that can be handled through an existing automated workflow. Examples could include a KYC mismatch, a data inconsistency, a missing validation response, or an employment field requiring a predefined secondary check. The system flags the exception and triggers the appropriate workflow.

Human review cases apply when the system cannot confidently resolve the issue, the required workflow does not exist, verification repeatedly fails, or the case requires judgement beyond the defined decision framework. The case is routed to an analyst or authorized loan officer. This creates an exception-led operating model where the human team can spend more of its time evaluating cases that require judgement rather than repeating standard verification activities across every application.

05 | Building a living company intelligence layer

Company verification needed to move beyond a static database

Company categorization was one of the first major components of the proposed architecture. The objective was to establish what type of organization an applicant worked for, with proposed categories including Private Limited, Public Limited, LLP, Partnership, Proprietorship, OPC, Government entities, and startups. The service would use identifiers such as PAN, CIN, and GST information to validate company identity and retrieve relevant corporate information from appropriate external sources. The solution design proposed cross-verification across multiple government data sources rather than relying on a single source. This would allow the institution to progressively build a centralized company intelligence database.

The design also considered data freshness, recognizing that a company database can be accurate when created and become less useful as information changes. Because the existing company master was refreshed periodically rather than continuously, Crizzen proposed progressively increasing validation frequency. The roadmap moved from periodic database refreshes to weekly validation, advancing to higher-frequency validation for high-volume employers. The long-term vision included daily or near-real-time refreshes where data availability and economics supported it.

The intention was not to refresh every company every day regardless of cost. Crizzen explored a Pareto-based approach in which a relatively small subset of employers could potentially represent a significant proportion of applicant verification activity. This created a way to balance data freshness, integration cost, and operational practicality.

06 | From company identity to company intelligence

Formal records provide the foundation while external signals add context

The first layer focused on objective corporate information. This involved ensuring the entity was correctly identified, PAN, CIN, and GST information corresponded, relevant registrations and filings were consistent, and there were no discrepancies across government records.

Crizzen then explored extending the company intelligence layer with external signals. The proposed semantic intelligence layer could monitor signals such as changes in company-related market indicators, major defaults, financial stress signals, regulatory developments, and investigations. It would also track significant negative news, business closure signals, mass layoffs, industry disruption, major corporate events, and public reputation signals.

The intention was to create a dynamic company-risk view rather than treat the company master as a static lookup table. The proposed output could include a company risk score, a qualitative risk band, risk triggers, and an explanation of contributing factors. These signals could then become an additional input into the institution’s existing eligibility and underwriting framework. Public information was designed as an additional intelligence signal rather than a replacement for formal company records or established credit rules.

07 | Employment verification

Employment status had to be established through evidence

Employment verification represented one of the strongest opportunities for automation. The proposed system would compare information supplied by the applicant against multiple independent signals including date of joining, current employment status, notice-period status, and last working day. It would also evaluate employer name, designation, salary information, tax data, PF information, and salary-credit patterns. The requirements specifically identified active versus serving-notice status, last working day, and salary-credit validation as important verification fields.

The objective was to transition from a single declared employment status towards a multi-source view of whether the applicant’s employment profile was consistent. For example, if an applicant declares active employment while HR evidence indicates possible notice-period status, and tax and banking information provide additional signals, the system cross-checks the available evidence. Once a discrepancy is identified, the officer sees the exception before making the lending decision. The officer therefore receives an assembled evidence picture rather than having to build that picture manually.

08 | Document intelligence

Documents contain the evidence while AI makes the evidence usable

Bank statements, tax documents, Form 16, Form 26AS, and credit information can contain significant information relevant to loan eligibility. The proposed document intelligence layer would extract, structure, and analyze these inputs rather than requiring analysts to manually inspect every document.

For bank statements, the solution was designed to identify signals such as salary deposits, salary frequency, salary consistency, and employer names. It also tracked recurring liabilities, existing EMI payments, loan obligations, cash deposits, unexplained credits, spending patterns, and other anomalous transactions. The proposed architecture also included credit information obtained through API integration and financial analysis based on the combined information.

The processing chain moved from document ingestion to extraction, data normalization, transaction categorization, pattern recognition, and anomaly detection. It then generated financial risk signals for underwriter decision support. The business requirements identified a proposed target of a 70 to 80 percent reduction in manual document-review effort, functioning as a proposed target rather than an achieved project result.

09 | The intelligence stack

Different problems require different forms of intelligence

Crizzen did not approach the solution as a single AI model. The proposed architecture combined several forms of automation and intelligence, with each capability serving a specific role.

A rules engine managed deterministic checks such as PAN validity, mandatory fields, defined eligibility conditions, required document checks, and predefined exception conditions. Machine learning was incorporated where sufficient historical or labelled data could support model-based classification, prediction, matching, or anomaly detection. Document intelligence was applied for extracting structured information from semi-structured and unstructured documents. Entity resolution determined whether information from different sources referred to the same applicant, employer, or entity.

Anomaly detection identified unusual salary, transaction, or financial behavior, while risk scoring combined multiple signals into an interpretable risk output. Generative AI handled semantic analysis, explanations, natural-language summaries, and interaction with the underlying verification intelligence. AI orchestration coordinated these capabilities and determined how information should move through the verification process. The distinction between these layers was deliberate, ensuring rules remained appropriate for deterministic requirements while advanced models handled pattern recognition and semantic explanations, with orchestration connecting everything into a coherent workflow.

10 | From verification engine to officer copilot

The interface was designed around the person making the decision

The proposed system was not intended to make the final lending decision autonomously. The officer would enter a limited set of required identifiers, such as applicant and employment information, and the system would assemble the available verification information into a consolidated view.

Instead of navigating multiple sources, the officer could review identity and KYC status alongside company category, corporate validation status, company risk scores, and risk triggers. The interface also presented employment status, date of joining, notice-period status, last working day, and salary validation. Financial indicators covered salary-credit consistency, existing liabilities, recurring obligations, unusual transactions, and financial risk signals. Credit information and relevant risk indicators were provided, alongside a clear view of issues requiring attention and the underlying source evidence trail.

The proposed LOS interface included status indicators such as Verified, Mismatch, and Pending. The decision remained with the authorized officer, while the technology was designed to make the supporting evidence available faster and in a more consistent format.

11 | An AI assistant for the verification desk

Making the verification layer easier to interact with

Crizzen also explored an AI assistant sitting above the verification engine to answer questions using the underlying verified data. Officers could ask why a specific applicant was flagged, request a comparison between the declared salary and the last six months of salary credits, or ask for a summary of all verification exceptions for the applicant. Other interactions could include generating a verification summary, explaining a risk trigger, retrieving supporting evidence, and initiating simple operational workflows.

This created a conversational layer over the structured verification engine. The AI assistant would not be the source of truth, operating instead as an interaction layer over the underlying data, verification services, rules, models, and audit trail.

12 | Explainability was part of the architecture

Automated verification needs to remain traceable

A financial decision-support system cannot simply return a risk outcome without showing the evidence behind it. The proposed architecture therefore included an audit layer for automated verification responses and downstream reporting, targeting complete traceability of verification responses.

A verification event would record what was checked, the source used, the time of the check, and the returned information. It also logged which rule or model identified the issue, the generated risk trigger, whether the case was automatically cleared or escalated, and if a human override was applied. This creates a foundation for operational review, audit, and continuous improvement, supporting the broader requirement for financial institutions to maintain appropriate control over customer verification and technology-enabled lending processes.

13 | Designing around the existing technology stack

Adding intelligence without rebuilding the lending architecture

The institution already had a working LOS and an established technology environment, so Crizzen designed the proposed architecture to minimize disruption to the existing core architecture. The approach added intelligence around the existing process by flowing external data sources into verification services, which were managed by an intelligence and orchestration layer connected to the existing LOS. This allowed the institution to introduce additional automation progressively rather than requiring a wholesale technology replacement. The proposed architecture anticipated integration of company master information, validation APIs, and verification outputs into the existing LOS.

14 | From strategy to production

A six-stage implementation roadmap

Although Crizzen did not implement the solution, the engagement included an implementation roadmap showing how the proposed architecture could move towards production.

Phase one focused on discovery and requirement finalization through stakeholder workshops, as-is assessment, gap analysis, requirement finalization, UI mockups, and API specifications with an indicative duration of three weeks. Phase two detailed high-level and low-level design, covering final architecture, component diagrams, sequence diagrams, rule-engine design, data model extensions, and reporting design over a two-week indicative period. Phase three involved a four-week block to build and unit test the company categorization service, employment verification orchestration, bank statement parser integration, rule engine, LOS UI changes, and the audit database.

Phase four mapped system integration testing across end-to-end workflows, HR and vendor integrations, bank-parser integration, performance testing, and regression preparation over three weeks. Phase five covered user acceptance testing, test-case execution, rule validation, exception testing, user training, and business sign-off spanning three weeks. The final phase outlined production deployment, smoke testing, monitoring, issue resolution, stabilization, and handover requiring one week for deployment and three weeks for hyper-care. These were indicative implementation durations from the solution design and were subject to the client’s detailed current-state assessment.

15 | Defining success before implementation

The proposed solution had measurable success criteria

The exercise was not framed purely as a technology project, as the business requirements defined measurable targets for the future solution. Proposed targets included company categorization accuracy above 98 percent, resolving more than 95 percent of employment verification cases without manual intervention, and maintaining salary-credit matching accuracy above 90 percent. The criteria also targeted a 20 percent reduction in employment verification turnaround time, an exception rate kept below 2 percent, complete verification traceability, and user adoption of the automated views exceeding 85 percent.

These figures represent proposed success criteria from the solution design rather than measured outcomes from a production implementation. The business requirements also identified expected benefits around processing efficiency, reduced manual verification effort, improved applicant profiling, and audit readiness. The proposed business case included an estimated 15 to 20 percent processing-efficiency improvement and approximately a 10 percent operational cost reduction. These were expected benefits, not achieved project results.

16 | What Crizzen delivered

Six weeks of strategy, architecture, and solution design

The engagement resulted in a production-oriented solution blueprint covering the business, technology, and implementation dimensions of the proposed platform.

Business and process deliverables included the business problem assessment, process understanding, stakeholder interviews, AI use-case definitions, business case, and future-state operating model. The solution design detailed the verification workflow, company intelligence architecture, employment verification architecture, document intelligence architecture, exception management, and human-in-the-loop design.

Technical deliverables covered technical architecture, data-source mapping, API and integration approach, AI and ML capability mapping, LOS integration approach, and the audit and traceability architecture. Execution planning provided implementation phases, indicative timelines, testing strategy, UAT approach, and the deployment and hyper-care roadmap. Crizzen’s role ended at strategy and solution design for this engagement, with no production implementation or deployment undertaken by Crizzen.

17 | The larger opportunity

From automating checks to building verification intelligence

The initial requirement was specific, aiming to automate company and employment verification for personal loan processing. As the solution was designed, the opportunity became broader. The proposed architecture could create a continuously refreshed intelligence layer for loan applicants, bringing together identity, employment, company intelligence, financial behaviour, credit information, external signals, rules, AI models, and human judgement into a single decision-support experience.

The value extends beyond removing individual manual checks to reducing the amount of fragmented information an officer has to assemble before making a decision. That creates a different operating model for verification where standard cases can move with greater automation, known exceptions can trigger defined workflows, and complex cases can reach the appropriate human reviewer with the relevant evidence already assembled. The underlying verification process becomes more structured, traceable, and easier to improve over time.

From information gathering to decision intelligence

A fast lending journey needs a verification layer that can operate at the same pace, and Crizzen’s role in this engagement was to design what that could look like. The architecture mapped a transition from static company information to continuously refreshed company intelligence, and from individual documents to structured financial signals. The blueprint moved operations from manual employment checks to multi-source verification, and from every application requiring manual attention to exception-led operations.

By migrating from scattered evidence to a decision-support layer inside the existing LOS, the platform transitioned AI from a standalone capability to an embedded asset within the lending workflow. The result was a detailed blueprint for an AI-enabled verification capability designed around speed, traceability, human judgement, and the institution’s existing technology environment. The proposed architecture gives the lending team a clearer path from information gathering to decision support, while keeping the final decision with the people accountable for it. That is the practical role of enterprise AI in a process like lending, reducing the distance between the information a business already has and the decision it needs to make.

For inquiries regarding enterprise verification architecture and AI strategy mapping, reach out via email to info@crizzen.com.