Your Loan Origination Data Template
Your Loan Origination Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Loan Origination Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity Name
ActivityName
|
The name of the specific business event or task that occurred at a point in time for a loan application. | ||
|
Description
This attribute describes a single step or milestone in the loan origination process, such as 'Application Submitted', 'Credit Check Completed', or 'Funds Disbursed'. Each activity represents a distinct event in the process lifecycle. Analyzing the sequence and duration of these activities allows for the creation of a detailed process map. This map is used to identify common process paths, deviations from the standard procedure, and bottlenecks where applications are delayed. Understanding the flow of activities is the first step in any process improvement initiative.
Why it matters
This attribute forms the backbone of the process map, defining the steps and milestones that constitute the loan origination journey.
Where to get
This information is typically generated from event logs, status change records, or audit trails within Blend, corresponding to key milestones in the loan workflow.
Examples
Application SubmittedUnderwriting CommencedFunds DisbursedApplication Denied
|
|||
|
Loan Application ID
LoanApplicationId
|
The unique identifier for each individual loan application submitted through the Blend platform. | ||
|
Description
The Loan Application ID uniquely identifies each individual loan request throughout its entire lifecycle. It serves as the central entity to group all associated activities and data, allowing for a complete trace of the origination journey for a specific loan. In process mining, this ID is fundamental for constructing the end-to-end process map, as every event recorded must be linked back to a specific application. This allows for the analysis of individual application journeys, comparison of different paths, and aggregation of metrics at the case level, such as total cycle time or rework frequency.
Why it matters
This is the essential Case ID that connects all process steps, enabling the reconstruction and analysis of the entire loan origination journey for each applicant.
Where to get
This is a primary key within Blend's core loan application data entities. It is typically available in all loan-related data exports and API endpoints.
Examples
APP-2024-10583BLND-0034981-A1800123987
|
|||
|
Start Time
EventStartTime
|
The timestamp indicating when a specific activity or event officially began. | ||
|
Description
The Event Start Time is the precise date and time that a process step was initiated. This timestamp is critical for sequencing events correctly and for calculating the duration of activities and the waiting times between them. In analysis, this timestamp is used to order the activities for each loan application, creating a chronological event log. It is the basis for all time-based calculations, including cycle times, processing times, and wait times, which are essential for identifying delays and evaluating performance against service level agreements (SLAs).
Why it matters
This timestamp is crucial for ordering events, calculating process durations, and identifying bottlenecks and delays in the loan origination workflow.
Where to get
This corresponds to the creation or start timestamp of an event record in Blend's event logs or audit trail tables.
Examples
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z
|
|||
|
Last Data Update
LastDataUpdateTime
|
Timestamp indicating when the data for this event was last refreshed or extracted from the source system. | ||
|
Description
This timestamp shows the last time the data was pulled from Blend. It does not represent when the event happened, but rather when the record was updated in the dataset used for analysis. This is a critical metadata attribute for data governance and quality assurance. It helps users understand the freshness of the data they are analyzing and is essential for validating the reliability of dashboards and reports, especially in near-real-time monitoring scenarios.
Why it matters
Ensures data transparency by showing how current the information is, which is vital for trusting the accuracy of the process analysis.
Where to get
This timestamp is added by the data ingestion pipeline at the moment the data is queried and extracted from the Blend source system.
Examples
2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z
|
|||
|
Source System
SourceSystemName
|
Identifies the source system from which the event data was extracted, which is 'Blend'. | ||
|
Description
This attribute specifies the system of record where the data originated. For this process view, the value will consistently be 'Blend'. While it may seem redundant if all data comes from one system, it is a best practice to include it. This becomes invaluable when integrating data from other systems, such as a core banking platform or a CRM, allowing analysts to trace data lineage and troubleshoot integration issues.
Why it matters
Provides crucial data lineage, ensuring clarity on the origin of process data, which is especially important in integrated environments.
Where to get
This is typically a static value ('Blend') added during the data extraction and transformation process to label the origin of the records.
Examples
BlendBlend_ProductionBlend_US
|
|||
|
Application Channel
ApplicationChannel
|
The channel through which the loan application was initially submitted. | ||
|
Description
This attribute specifies the origin or submission channel of the application, for example, 'Online Portal', 'Mobile App', 'Branch', or 'Broker'. Each channel may have a different process flow or efficiency level. By analyzing performance across different channels, organizations can identify which ones are most efficient, have the highest approval rates, or experience the most rework. The 'Application Channel Performance Overview' dashboard uses this attribute to provide a comparative analysis, helping to guide strategic decisions on where to invest resources for process improvement.
Why it matters
Enables performance comparison across different submission channels, helping to identify the most effective and efficient ways to acquire applications.
Where to get
Consult Blend documentation. This may be captured as part of the initial application metadata.
Examples
Online PortalMobile AppIn-BranchBroker
|
|||
|
Assigned Loan Officer
AssignedLoanOfficer
|
The name or ID of the loan officer or underwriter responsible for handling the activity. | ||
|
Description
This attribute identifies the specific employee, such as a loan officer or underwriter, who performed a particular task or is assigned to the loan application. This is essential for understanding workload distribution and individual performance. In analysis, this allows for filtering the process map by user or team, comparing performance, and identifying training opportunities. The 'Loan Officer Workload & Performance' dashboard relies directly on this attribute to visualize case distribution and average handling times per officer, helping to ensure workloads are balanced and efficient.
Why it matters
Links process activities to specific individuals, enabling workload analysis, performance monitoring, and resource optimization.
Where to get
Consult Blend documentation. This is likely stored in user assignment fields associated with loan application records or specific tasks.
Examples
John SmithJane Doej.smith@lender.comuser_1024
|
|||
|
Decision Outcome
DecisionOutcome
|
The final outcome of the loan application, such as Approved, Rejected, or Withdrawn. | ||
|
Description
This case-level attribute records the final status or decision for a loan application. It indicates whether the loan was ultimately approved and funded, denied by the lender, or withdrawn by the applicant. This is a critical attribute for outcome analysis. It allows for comparing the process paths of approved versus rejected applications to identify factors that lead to success or failure. The 'Loan Decision Outcomes Analysis' dashboard and the 'Loan Application Rejection Rate' KPI are directly powered by this data, helping to understand and improve approval rates.
Why it matters
This is essential for outcome-based analysis, enabling comparisons between successful and unsuccessful process instances to improve approval rates.
Where to get
Consult Blend documentation. This is typically the final status field on a closed loan application record.
Examples
ApprovedRejectedWithdrawn
|
|||
|
End Time
EventEndTime
|
The timestamp indicating when an activity was completed. This is often the same as the start time for milestone events. | ||
|
Description
This attribute marks the precise date and time an activity concluded. For milestone events like 'Application Submitted', the end time may be identical to the start time. For activities with a duration, such as 'Underwriting Commenced' to 'Underwriting Decision Rendered', this marks the completion. Having both a start and end time allows for precise calculation of activity processing time. This helps differentiate between the time spent actively working on a task versus the time spent waiting for the task to begin, which is crucial for accurate bottleneck analysis.
Why it matters
Enables the calculation of precise processing times for activities, helping to distinguish active work time from idle wait time.
Where to get
This corresponds to the completion or end timestamp of an event record in Blend's event logs or audit trail tables.
Examples
2023-10-26T10:00:00Z2023-11-15T18:02:15Z2024-01-05T09:12:45Z
|
|||
|
Loan Product
LoanProduct
|
The specific type of loan product being applied for, such as a mortgage or personal loan. | ||
|
Description
This attribute categorizes the loan application by the type of financial product requested by the applicant. Examples include '30-Year Fixed Mortgage', 'Home Equity Line of Credit', or 'Auto Loan'. Analyzing the process by loan product is crucial for identifying variations in cycle time, approval rates, or process paths that are specific to certain products. This enables targeted improvements, as the process for a simple personal loan may be very different from that of a complex mortgage. Dashboards often use this attribute to segment KPIs and compare performance across different business lines.
Why it matters
Allows for segmentation of the process analysis, revealing how performance and process flows differ across various loan products.
Where to get
Consult Blend documentation. This information is typically a core field on the loan application record.
Examples
30-Year Fixed Mortgage15-Year Fixed MortgageHELOCAuto Loan
|
|||
|
Activity Processing Time
ActivityProcessingTime
|
The calculated duration of time spent actively working on an activity. | ||
|
Description
This metric represents the actual time an activity was being processed, calculated as the difference between its End Time and Start Time. It isolates the active work period from any preceding wait time. Distinguishing processing time from the total cycle time is essential for precise bottleneck analysis. A long cycle time for a step might be due to a long queue, not inefficient processing. This metric allows analysts to focus improvement efforts on either reducing queues or speeding up the activity itself, as needed.
Why it matters
Measures the active work duration of a task, helping to differentiate between processing bottlenecks and waiting time or queueing issues.
Where to get
This is calculated during data transformation by subtracting the 'EventStartTime' from the 'EventEndTime'. (EndTime - StartTime).
Examples
3 hours 15 minutes2 days 4 hours45 minutes
|
|||
|
Applicant Type
ApplicantType
|
Categorization of the applicant, such as 'New Customer' or 'Existing Customer'. | ||
|
Description
This attribute segments applicants into categories based on their relationship with the lending institution. This could include classifications like 'New Customer', 'Existing Customer', 'Internal Employee', or 'Partner Referral'. Different applicant types may be subject to different process rules or benefit from pre-existing data, which can affect processing times and approval rates. Analyzing process variations by applicant type can uncover opportunities to streamline the journey for existing customers or identify friction points for new ones.
Why it matters
Allows for analyzing process differences based on customer relationship, which can impact data availability, risk assessment, and overall speed.
Where to get
Consult Blend documentation. This may be derived by cross-referencing the applicant's information with a customer master database or captured directly.
Examples
New CustomerExisting CustomerPreferred Partner
|
|||
|
Case Duration
CaseDuration
|
The total calculated time from the first event to the last event for a loan application. | ||
|
Description
This metric measures the total end-to-end cycle time for each loan application. It is calculated by taking the timestamp of the very last recorded event and subtracting the timestamp of the very first event for a given 'LoanApplicationId'. Case duration is a primary key performance indicator (KPI) for overall process efficiency. It is used in the 'Loan Approval End-to-End Cycle Time' dashboard to provide a high-level view of performance. Analyzing this metric, and how it varies by attributes like loan product or channel, is fundamental to understanding and improving the speed of the entire loan origination process.
Why it matters
Represents the total end-to-end cycle time of a loan application, a critical KPI for measuring overall process velocity and efficiency.
Where to get
This is calculated in the process mining tool by subtracting the timestamp of the first event from the timestamp of the last event for each case.
Examples
25 days 8 hours42 days 3 hours15 days 12 hours
|
|||
|
Credit Score
CreditScore
|
The applicant's credit score at the time of the credit check. | ||
|
Description
This attribute stores the numerical credit score returned from a credit bureau during the 'Credit Check Completed' activity. The credit score is a key factor in assessing the applicant's creditworthiness and making a lending decision. In process analysis, the credit score can be used to segment applications and understand how this critical data point influences process outcomes. For example, analysts can explore whether lower credit scores correlate with longer underwriting times or higher rejection rates. This provides deep insight into how risk assessment impacts process efficiency.
Why it matters
A key decision-making factor that can be used to analyze how applicant risk profile impacts process flow, duration, and outcomes.
Where to get
Consult Blend documentation. This information is typically retrieved from a third-party credit bureau via an integration and stored on the applicant's profile.
Examples
780650815
|
|||
|
Document Type
DocumentType
|
The type of document being requested or received, such as 'Pay Stub' or 'Bank Statement'. | ||
|
Description
This attribute specifies the exact type of supporting document involved in activities like 'Documents Requested' or 'Documents Received'. This level of detail is crucial for understanding the document management portion of the loan process. Analyzing by document type helps to answer questions like, 'Which documents are most frequently re-requested?' or 'Which documents take the longest for applicants to provide?'. The 'Document Request Efficiency Analysis' dashboard relies on this attribute to identify patterns and inefficiencies in the document collection process, aiming to reduce rework and delays.
Why it matters
Provides granular detail on document-related activities, helping to pinpoint inefficiencies and repeated requests for specific types of documents.
Where to get
Consult Blend documentation. This should be available in the details of document management tasks or events.
Examples
Pay StubW-2 FormBank StatementTax Return
|
|||
|
Is Rework
IsRework
|
A calculated flag indicating if an activity is a repetition of a previous step within the same case. | ||
|
Description
This boolean flag is set to True if the same activity has already occurred earlier in the same loan application case. For example, if 'Documents Requested' appears a second time for the same loan, the second occurrence would be flagged as rework. Identifying rework is crucial for pinpointing process inefficiencies, friction, and loops. The 'Rework and Re-submission Analysis' dashboard and the 'Rework Rate per Loan Application' KPI depend on this attribute to quantify the frequency and impact of repeated work. Highlighting these instances helps focus improvement efforts on getting things right the first time.
Why it matters
Directly flags process inefficiencies and loops, making it easy to quantify and analyze the impact of repeated work.
Where to get
This is typically calculated by the process mining tool, which can detect repeated activities within a case trace. It can also be calculated during data preparation.
Examples
truefalse
|
|||
|
Is Underwriting SLA Breached
IsUnderwritingSlaBreached
|
A calculated flag that indicates whether the underwriting stage exceeded its defined SLA target. | ||
|
Description
This is a boolean (True/False) attribute that is derived by comparing the actual duration of the underwriting process against the 'UnderwritingSlaTarget'. If the actual duration is greater than the target, this flag is set to True. This flag simplifies analysis and dashboarding by turning a complex time comparison into a simple binary indicator. It is used directly in the 'Underwriting Service Level Adherence' dashboard to count the number of breaches and calculate the 'Underwriting SLA Adherence Rate' KPI. This allows for quick identification of all cases that failed to meet service standards.
Why it matters
Provides a clear, binary indicator of SLA failure, simplifying reporting and enabling quick filtering to analyze all breached applications.
Where to get
This is a calculated field. The logic is: (UnderwritingDecisionRendered.Timestamp - UnderwritingCommenced.Timestamp) > UnderwritingSlaTarget.
Examples
truefalse
|
|||
|
Loan Amount
LoanAmount
|
The total monetary value of the loan requested by the applicant. | ||
|
Description
This attribute contains the principal amount of the loan being applied for. The loan amount can significantly influence the complexity and rigor of the underwriting process. Analyzing the process based on loan amount allows for valuable segmentation. For example, very large loans might follow a different, more stringent process path compared to smaller loans. This can help explain variations in cycle times and approval rates and is often used to categorize cases into different value bands for analysis.
Why it matters
Provides critical business context, allowing for analysis based on the financial value of the application, which often correlates with process complexity.
Where to get
Consult Blend documentation. This is a standard and essential field on any loan application form.
Examples
350000.0050000.001250000.00
|
|||
|
Property State
PropertyState
|
The US state where the property associated with the loan is located. | ||
|
Description
This attribute identifies the state for the property being financed, which is particularly relevant for mortgage applications. Lending regulations and market conditions can vary significantly by state. This provides a geographic dimension for analysis. It allows for comparing process performance, such as cycle times and approval rates, across different regions. This can help identify regional bottlenecks, understand the impact of local regulations on the process, and allocate resources more effectively.
Why it matters
Enables geographical analysis of the loan origination process, which can reveal regional performance differences and regulatory impacts.
Where to get
Consult Blend documentation. This is a standard field collected as part of the property information on a mortgage application.
Examples
CANYTXFL
|
|||
|
Rejection Reason
RejectionReason
|
The specific reason provided when a loan application is denied. | ||
|
Description
When a loan application's 'Decision Outcome' is 'Rejected', this attribute provides the underlying reason for the denial. Common reasons include 'Insufficient Credit Score', 'High Debt-to-Income Ratio', or 'Incomplete Documentation'. This data is invaluable for root cause analysis. By analyzing the most common rejection reasons, the business can identify systemic issues in the application process, applicant quality, or lending criteria. The 'Loan Decision Outcomes Analysis' dashboard uses this information to provide actionable insights for improving the overall approval rate.
Why it matters
Provides the 'why' behind loan rejections, enabling targeted actions to address common issues and improve application success rates.
Where to get
Consult Blend documentation. This is likely available in the decision or status history of a rejected application.
Examples
Debt-to-income ratio too highLow credit scoreIncomplete application
|
|||
|
Underwriting SLA Target
UnderwritingSlaTarget
|
The target duration, in hours or days, for completing the underwriting stage. | ||
|
Description
This attribute defines the service level agreement (SLA) target for the underwriting phase of the loan origination process. It represents the maximum acceptable time from when underwriting begins to when a decision is rendered. This target is used as a benchmark to evaluate performance. By comparing the actual underwriting duration against this SLA target, it's possible to calculate the 'Underwriting SLA Adherence Rate' KPI and identify breaches. This is fundamental for the 'Underwriting Service Level Adherence' dashboard, which monitors compliance and helps prioritize applications at risk of breaching their SLA.
Why it matters
Provides a clear benchmark for performance, enabling the measurement of SLA adherence and the identification of underwriting delays.
Where to get
Consult Blend documentation or business rule configurations. This may be a configurable setting based on loan product or other factors.
Examples
48 hours3 days24 hours
|
|||
Loan Origination Activities
| Activity | Description | ||
|---|---|---|---|
|
Application Denied
|
This activity signifies that the loan application has been officially declined following the underwriting review. This is an alternative, unsuccessful end to the process. | ||
|
Why it matters
This is a critical 'unhappy path' end event. Analyzing the volume and reasons for denials is essential for refining lending criteria and improving the Loan Application Rejection Rate KPI.
Where to get
This event corresponds to the 'Denied' decision rendered by the underwriter. It is captured as a final status update in Blend with an associated timestamp and reason code.
Capture
Use the timestamp of the final status change to 'Denied' or 'Rejected'.
Event type
explicit
|
|||
|
Application Started
|
Marks the moment a loan officer or applicant begins creating a new loan application in the Blend system. This is often the first record created, even before all required information is gathered and formally submitted. | ||
|
Why it matters
This activity serves as the initial trigger for the loan origination process, helping to measure the time applicants take to complete and submit their application and analyze application drop-off rates.
Where to get
This event is likely captured as the creation timestamp of the loan application record in Blend's primary application table. It can be inferred from the earliest timestamp associated with the Loan Application ID.
Capture
Use the creation timestamp of the main loan application record.
Event type
inferred
|
|||
|
Application Submitted
|
Represents the formal submission of the completed loan application by the applicant or loan officer for processing. This is a critical event that officially begins the processing and underwriting timeline. | ||
|
Why it matters
This is the official starting point for measuring end-to-end processing time and service level agreements (SLAs). It helps differentiate between the application drafting phase and the active processing phase.
Where to get
Blend likely captures this as an explicit event or a status change within the loan application's audit trail, for example, a status moving from 'Draft' to 'Submitted'.
Capture
Identify the event log or status change timestamp for application submission.
Event type
explicit
|
|||
|
Funds Disbursed
|
Represents the successful completion of the loan origination process, where the loan amount is transferred to the applicant or relevant party. This event marks the end of a successful loan application journey. | ||
|
Why it matters
This is the primary 'happy path' end event for the process. Measuring the time to this activity provides the overall loan origination cycle time, a critical KPI.
Where to get
This is likely recorded when a loan officer updates the application status to 'Funded' or 'Closed' in Blend after receiving confirmation from the funding department. It may also come from an integration with a core banking system.
Capture
Use the timestamp of the status change to 'Funded', 'Disbursed', or 'Completed'.
Event type
inferred
|
|||
|
Loan Offer Accepted
|
Represents the applicant's formal acceptance of the loan offer and its terms. This is a critical milestone indicating the applicant's intent to proceed with the loan. | ||
|
Why it matters
This activity is a key indicator of successful conversion from approval to closing. Analyzing the time taken for acceptance can provide insights into the competitiveness of the offer.
Where to get
This event is captured when the applicant electronically signs or otherwise indicates their acceptance in the Blend portal, triggering a status update with a timestamp.
Capture
Use the timestamp from the applicant's e-signature or acceptance action in the system.
Event type
explicit
|
|||
|
Underwriting Commenced
|
Represents the start of the underwriting process, where an underwriter begins their detailed review of the loan application and supporting documents. This is typically captured when an underwriter assigns the case to themselves or the case status changes to 'In Underwriting'. | ||
|
Why it matters
This is a major milestone that marks the beginning of the most critical decision-making phase. It is the starting point for measuring the Underwriting SLA Adherence Rate KPI and identifying pre-underwriting bottlenecks.
Where to get
This can be inferred from a status change of the application to 'Underwriting in Progress' or 'Assigned to Underwriter', along with a corresponding timestamp.
Capture
Identify timestamp when loan status changes to an underwriting state.
Event type
inferred
|
|||
|
Underwriting Decision Rendered
|
Marks the completion of the underwriter's review, resulting in a decision such as 'Approved', 'Approved with Conditions', or 'Denied'. This event concludes the core underwriting analysis. | ||
|
Why it matters
This activity is the endpoint for measuring underwriting cycle time and SLA adherence. The decision outcome is a critical attribute for analyzing approval rates and reasons for rejection.
Where to get
This is often an explicit event captured when the underwriter submits their decision in the system. It can also be inferred from a status change out of underwriting, such as to 'Approved' or 'Denied'.
Capture
Use the timestamp of the underwriter's decision submission event or the subsequent status change.
Event type
explicit
|
|||
|
Application Withdrawn
|
Indicates that the applicant has chosen to withdraw their application before a final decision was made or before funding. This represents an unsuccessful outcome for the process. | ||
|
Why it matters
This is a key 'unhappy path' end event. Analyzing when and why applications are withdrawn can provide insights into customer experience, competition, and process friction.
Where to get
This is captured by a status change to 'Withdrawn' in Blend, which can be triggered by the applicant via the portal or manually by a loan officer.
Capture
Use the timestamp of the event or status change to 'Withdrawn'.
Event type
explicit
|
|||
|
Closing Disclosures Sent
|
Indicates that the final set of legally required closing documents has been sent to the applicant for review before signing. This is a time-sensitive compliance step that must precede the final closing. | ||
|
Why it matters
Tracking this event is crucial for ensuring compliance with mandatory waiting periods, such as the TILA-RESPA Integrated Disclosure (TRID) rule's three-day review period.
Where to get
This is likely recorded in Blend's communication or document management logs with a precise timestamp of when the closing disclosure package was sent.
Capture
Look for a timestamped event log related to sending the 'Closing Disclosure' package.
Event type
explicit
|
|||
|
Credit Check Completed
|
Marks the moment the applicant's credit report and score have been successfully received from the credit bureau and attached to the loan file. This event signifies that the credit data is available for review. | ||
|
Why it matters
The duration between credit check initiation and completion measures the efficiency of third-party services. This data is critical for the subsequent underwriting and risk assessment stages.
Where to get
This event is logged upon receiving a successful response from the credit agency's API. It is recorded with a timestamp in Blend's logs or as a status update on the credit check task.
Capture
Find the timestamped log entry for the credit report response or a 'Completed' status update.
Event type
explicit
|
|||
|
Credit Check Initiated
|
This activity signifies that a request to pull the applicant's credit report from a credit bureau has been initiated. It is a key step in assessing the applicant's creditworthiness. | ||
|
Why it matters
This is a crucial data-gathering step. Analyzing the time taken to initiate and complete the credit check helps identify delays with third-party integrations.
Where to get
This event is typically logged as an API call to a credit reporting agency, recorded with a timestamp in Blend's system logs or audit trail.
Capture
Find the timestamped log entry for the credit report request.
Event type
explicit
|
|||
|
Documents Received
|
Marks when the applicant has uploaded or provided all or a subset of the requested supporting documents. This event is often a prerequisite for moving the application to the next stage, such as underwriting. | ||
|
Why it matters
The time between document request and receipt is a common source of delay. Tracking this helps measure applicant responsiveness and the efficiency of the document collection process.
Where to get
Captured via timestamps when documents are uploaded or their status is changed to 'Received' in Blend's document management system.
Capture
Use timestamps from document uploads or status updates in the document checklist.
Event type
explicit
|
|||
|
Documents Requested
|
Indicates that the system or a loan officer has sent a request to the applicant for required supporting documents, such as pay stubs or bank statements. This is often an automated or manual action within the application workflow. | ||
|
Why it matters
Analyzing this activity helps identify bottlenecks related to document collection. Multiple occurrences for the same case highlight rework and process inefficiencies, which can be measured with the Repeated Document Request Rate KPI.
Where to get
This is typically recorded in a document tracking or checklist module within Blend, with a timestamp for each request.
Capture
Use event logs from the document management or applicant communication features.
Event type
explicit
|
|||
|
Initial Disclosures Sent
|
This activity marks the point at which the initial set of legally required disclosure documents is sent to the applicant. This is a critical compliance step that must occur early in the process. | ||
|
Why it matters
Tracking this compliance-driven activity is essential for regulatory audits. Analyzing its timing ensures adherence to regulations like RESPA and TILA.
Where to get
This is likely logged in a communications or document management module within Blend, timestamped when the disclosure package is generated and sent.
Capture
Look for a timestamped event log related to sending the 'Initial Disclosure' package.
Event type
explicit
|
|||
|
Loan Agreement Signed
|
This activity marks the final signing of all closing documents by the applicant, legally binding the loan agreement. It is the final step required from the applicant before funds can be disbursed. | ||
|
Why it matters
This is the final confirmation from the applicant and a prerequisite for funding. Delays at this stage can impact disbursement timelines and customer satisfaction.
Where to get
This is recorded via the e-signature platform integrated with Blend, which logs the timestamp of the final signature completion.
Capture
Capture the timestamp when the e-signature process for the final loan package is completed.
Event type
explicit
|
|||
|
Loan Offer Generated
|
This activity occurs after an 'Approved' underwriting decision, representing the creation of the official loan offer document to be sent to the applicant. It formalizes the terms of the approved loan. | ||
|
Why it matters
The time between the underwriting decision and offer generation can reveal administrative delays. It is a key step in the journey towards loan acceptance.
Where to get
This is likely captured in a document generation log within Blend, with a timestamp indicating when the loan offer document was created.
Capture
Use the creation timestamp of the loan offer document record.
Event type
explicit
|
|||