Your Loan Origination Data Template

The Activity Name describes a specific step or milestone within the loan origination workflow, such as 'Application Submitted', 'Credit Check Completed', or 'Loan Offer Generated'. Each activity represents a distinct point in the process that consumes time and resources.

Analyzing the sequence and frequency of these activities is core to process mining. It helps uncover the actual process flow, identify common pathways, detect bottlenecks, and measure the duration of different stages. Clear and consistent activity naming is crucial for creating an understandable and accurate process map.

It defines the steps of the process, allowing for the visualization and analysis of the process flow, identification of bottlenecks, and measurement of stage durations.

Found in event logs or transaction tables that record business process steps.

The Event Start Time is a precise timestamp that marks the beginning of an activity. It is a fundamental component of the event log and is essential for ordering events chronologically to reconstruct the process flow for each case.

In process analysis, the start time is used to calculate the overall case duration, the time spent between activities, and the active processing time of each step when an end time is also available. It is the primary temporal attribute used to understand process timing, identify delays, and evaluate performance against service level agreements.

This timestamp is critical for ordering events, calculating process cycle times, and identifying delays between activities.

A required field in any system's event log or transaction history table.

The Loan Application ID is a unique key assigned to every loan request upon its creation. It serves as the primary case identifier, linking all related activities, documents, and decisions from initial submission to final disbursement or closure. This consistency is essential for reconstructing the end-to-end journey of each application.

In process mining, this attribute is used to group all related events into a single case, allowing for the analysis of process flows, cycle times, and variations on a per-application basis. Without a consistent and unique case identifier, it is impossible to accurately map the process or analyze its performance.

It is the fundamental key for process mining, as it groups all related events into a single case, enabling the analysis of the entire loan origination journey.

Typically found in the header or main transaction table for loan applications.

This attribute records the timestamp of the most recent data extraction or refresh from the source system. It is a metadata field that is essential for data governance and quality assurance.

Knowing when the data was last updated helps analysts understand the freshness of their dataset and ensures that analyses are based on current information. It is particularly important for monitoring ongoing processes, as it indicates how up-to-date the process view is. This timestamp is also valuable for debugging data pipelines and identifying potential issues with data ingestion schedules.

It confirms the freshness of the data, ensuring that analyses are based on timely information and helping to manage data quality.

Usually generated and stored during the data extraction, transformation, and loading (ETL) process.

The Source System Name specifies the originating application or platform that generated the event data, such as a Loan Origination System (LOS), CRM, or a document management system. In modern enterprises, a single business process like loan origination often spans multiple interconnected systems.

Identifying the source system for each event is crucial for data validation, troubleshooting, and understanding the technological landscape of the process. It allows analysts to trace data back to its origin and assess how different systems contribute to the overall process flow and potential delays.

It helps trace data back to its origin, which is crucial for data validation and for understanding process flows that span multiple IT systems.

Often available as a standard field in data extracts or can be added during the data engineering process.

The Application Channel identifies the initial point of contact or submission method used by the applicant. Examples include 'Online Portal', 'Mobile App', 'In-Branch', or 'Third-Party Broker'.

Different channels can have significantly different customer experiences and internal processing workflows. Analyzing the process by channel helps organizations understand the efficiency and effectiveness of each submission path. It can reveal which channels have faster processing times, higher customer satisfaction, or better data quality, providing insights for strategic investments in technology and operations.

It allows for analysis of process performance and customer experience across different submission channels, such as online, in-branch, or mobile.

Captured at the beginning of the application process and stored in the main loan application table.

The Assigned User identifies the individual employee or system user who performed or is responsible for a particular activity. This could be a loan officer, processor, underwriter, or closing agent.

This attribute is fundamental for analyzing team and individual performance, workload distribution, and resource allocation. By tracking activities by user, organizations can identify high-performing individuals, pinpoint training needs, and rebalance workloads to optimize efficiency. It also enables analysis of how different users or teams impact process outcomes and cycle times.

It is essential for analyzing workload distribution, team performance, and identifying resource-related bottlenecks in the process.

Typically found in transaction or event logs that record user actions within the system.

The Decision Outcome indicates the final status of a loan application after it has been fully processed. Common outcomes include 'Approved', 'Denied', 'Withdrawn by Applicant', or 'Counter-Offered'.

This attribute is essential for outcome analysis, which seeks to understand which process paths lead to successful versus unsuccessful results. By correlating process variations with decision outcomes, organizations can identify best practices that lead to higher approval rates or behaviors that result in denials. This analysis is critical for improving process efficiency and business outcomes.

It is essential for outcome analysis, helping to identify which process behaviors and paths correlate with successful or unsuccessful loan applications.

Usually recorded in the loan application status field or as a specific decision event in the transaction history.

The Event End Time marks the precise moment an activity was concluded. While some events are milestones with only a start time, many activities have a distinct duration. The end time allows for the direct calculation of this active processing time.

Analyzing active processing time is critical for understanding resource utilization, identifying inefficiencies within specific tasks, and differentiating between time spent actively working on a case versus waiting time. For example, it helps determine how long underwriting actually took, separate from the time the application was waiting in the underwriter's queue.

It enables the calculation of active processing time for activities, which is key to distinguishing between value-added work and waiting time.

Often found alongside the start time in event logs or transaction tables for systems that track activity duration.

This boolean attribute distinguishes between activities executed automatically by a system, such as an automated credit check or initial document validation, and those performed manually by a human user.

This distinction is critical for understanding the level of automation within a process and its impact on efficiency. Analyzing automated versus manual steps helps identify opportunities for further automation, quantify the time savings from existing automation, and understand the workload of human resources. It provides a clear view of the human-system interaction throughout the loan origination journey.

It helps distinguish between system-driven and human-driven activities, which is key for automation analysis and understanding resource workload.

Can be a field in the event log or derived based on the activity name or the user associated with the event (e.g., 'system' user).

The Loan Amount represents the principal sum of money requested by the applicant. This is a critical financial attribute that often influences the complexity and risk associated with a loan application.

Larger loan amounts may trigger more rigorous underwriting procedures, require additional levels of approval, or involve different fee structures. Analyzing the process based on loan amount can reveal how value affects processing times, approval rates, and the level of scrutiny applied. It is also a key input for financial analyses, such as calculating the total value of the loan pipeline or the cost per dollar loaned.

This attribute is a key driver of process complexity and risk, allowing for analysis of how loan value impacts cycle time and approval rates.

A core field from the loan application data, typically stored in the primary loan information table.

The Loan Product Type categorizes the loan application based on the financial product being requested. Examples include 'Conventional Mortgage', 'FHA Loan', 'Auto Loan', or 'Personal Line of Credit'.

Different loan products often have distinct processes, compliance requirements, and risk profiles. Analyzing the process by product type is crucial for identifying variations and optimizing workflows for specific product lines. This segmentation allows for more targeted improvements and helps explain differences in cycle times, approval rates, and rework across the loan portfolio.

It allows for segmentation of the process to compare performance and identify variations in workflows for different types of loans.

A standard field on the loan application form, stored in the main application data table.

When a loan application's final outcome is 'Denied', the Rejection Reason provides a code or text description explaining why. Common reasons include 'Insufficient Credit History', 'High Debt-to-Income Ratio', or 'Incomplete Application'.

This attribute is invaluable for root cause analysis of application failures. By analyzing the most frequent rejection reasons, organizations can identify systemic issues in the applicant pool, underwriting criteria, or the application process itself. These insights can inform marketing strategies, product development, and process improvements designed to reduce denial rates.

It provides critical insights for root cause analysis, helping to understand why applications are denied and enabling targeted process improvements.

Recorded as part of the final decision event, often linked to the 'Denied' decision outcome.

The Applicant Type classifies the loan applicant based on their relationship with the financial institution, for example, as a 'New Customer' or an 'Existing Customer'.

This segmentation is important because the process may differ based on this attribute. Existing customers might have a more streamlined process due to pre-existing data, while new customers may require more extensive identity and information verification. Analyzing the process by applicant type can highlight these differences and help organizations tailor and optimize the customer journey for each segment.

It allows for process comparison between different customer segments, which may have different workflows and service level expectations.

Derived from customer relationship management (CRM) data or specified on the application form.

This attribute identifies the specific department or functional team, such as 'Loan Processing', 'Underwriting', or 'Closing', that is responsible for an activity or owns the case at a certain point in time.

Tracking handoffs between departments is crucial for understanding organizational workflows and identifying cross-functional delays. Analyzing the process by department helps to measure the performance of different teams, understand their workloads, and optimize collaboration and handoff procedures between them.

It enables analysis of process handoffs and performance by functional team, highlighting cross-departmental bottlenecks and inefficiencies.

Can be found in workflow management systems or derived from the user or role assigned to the task.

The Credit Score is a numerical representation of an applicant's creditworthiness, obtained from a credit bureau during the application process. It is a primary factor in risk assessment and underwriting decisions.

Higher credit scores generally indicate lower risk and may lead to more favorable loan terms or a faster approval process. In process mining, analyzing how credit score influences the process can reveal different treatment paths for applicants with varying risk profiles. For example, applications with lower scores might undergo more manual reviews or require additional documentation, leading to longer cycle times.

It's a key factor in risk assessment that can significantly influence the process path, decision outcomes, and overall cycle time.

Sourced from an external credit bureau and stored with the applicant's profile data.

The Geographic Location specifies a location relevant to the loan, which could be the property's state, the processing branch, or the applicant's region.

This attribute is useful for analyzing regional variations in the process. For example, different states may have unique compliance requirements that add steps to the process, or certain branches may be more efficient than others. This geographical segmentation can reveal performance differences, resource needs, and market-specific trends that impact the loan origination process.

Allows for geographical analysis to uncover regional variations in process performance, compliance requirements, and business outcomes.

Found in application data, such as property address or the branch where the application was submitted.

The Underwriting SLA Target defines the expected timeframe within which the underwriting phase of the loan application should be completed. This target is a key performance indicator (KPI) benchmark set by the business to ensure timely processing.

By comparing the actual duration of the underwriting stage, calculated from timestamps, against this target, organizations can measure SLA adherence. This analysis helps identify bottlenecks in underwriting, assess team performance, and manage customer expectations effectively.

It serves as a benchmark to measure performance against service level agreements, helping to identify delays and manage operational targets.

Typically defined in business rule configurations or service level agreement documentation and may be stored with the case data.