Product-Driven Process

Understanding Product Templates

Credit products in timveroOS are configured using product templates that define the lending parameters and required entity structure for specific loan types.

Product Template Components:

• Loan parameters (amount ranges, term lengths, interest rates)

• Required participants (borrowers, co-borrowers, guarantors)

• Required assets (collateral, vehicles, real estate)

• Pricing and fee structures

Key Architectural Point: Products define the structure of participants and assets. Business flows and workflows are part of the participant and asset entities themselves. By selecting which participants and assets are required, the product indirectly determines which business flows and workflows will be active for an application.

Entity-Based Data Collection

Data Collection Architecture

Data collection in timveroOS is entity-centric, meaning data collection steps are assigned to specific entity types (participants, assets), not directly to products.

Entity Types:

• Participants: Borrowers, co-borrowers, guarantors

• Assets: Collateral, vehicles, real estate, equipment

Business Process Flows vs Workflow Engine

Understanding the Two Systems:

timveroOS uses two complementary systems that work together:

Business Process Flows (SDK - Stability)

What They Are:

• Complete journey of an entity through the system

• Defined states/statuses from creation to completion

• Configured in SDK

What They Provide:

• Entity lifecycle stages (e.g., Draft → Submitted → Verified → Approved)

• State transition rules and control

• Structural stability

• Foundation for process orchestration

Why This Matters: Business processes (states) provide stable structure where changes are testable and data transitions can be managed with proper care. This architecture ensures that modifications to core process flows are deliberate, validated, and safely deployed.

Example - Borrower Business Process:

Borrower States (SDK-defined):
Draft → KYC Pending → KYC Verified → Income Verified → Approved → Active

Workflow Engine Workflows (Admin Panel - Flexibility)

What They Are:

• Automated evaluation and decision-making logic

• Created using visual Workflow Designer in Admin Panel

• Tied to participant and asset entities

• Execute at specific points within business processes

What They Provide:

• Data evaluation and scoring

• External data integration (via Feature Store)

• Business rule application

• Decision generation (approve/decline/review)

• Flexibility to adjust logic without SDK changes

Example - Credit Scoring Workflow (tied to Borrower participant):

Workflow: Credit Assessment
1. Fetch credit bureau data (Feature Store)
2. Calculate credit score
3. Apply minimum score rules
4. Generate decision or warning fact

How They Work Together

The Best Distribution: Stability + Flexibility

Business Process (SDK - Stable Structure):
[Borrower: KYC Pending] → [Borrower: KYC Verified] → [Borrower: Income Verified]
                ↓                                              ↓
          Workflow Executes                              Workflow Executes
          (Flexible Logic)                               (Flexible Logic)

Key Principle:

• States/Statuses = Business Process Flow (SDK) = Stability

• Decision Logic = Workflow Engine (Admin Panel) = Flexibility

When you need to change business rules or scoring logic, you modify workflows in the Admin Panel. When you need to change the fundamental process structure or add new states, you work with SDK.

How It Works in Practice

Product Impact on Entity Processes:

1. Product defines required entity structure (which participants/assets needed)

2. Each participant and asset has business flows and workflows (these are part of the entity, not the product)

3. By selecting entity structure, product determines which flows execute (indirectly)

4. Business processes orchestrate workflow execution (when to evaluate)

5. Workflows provide flexible decision logic (how to evaluate)

Example: Auto Loan Product

Product: Auto Loan
↓
Defines Entity Structure:
- Primary Borrower (participant) - required
- Vehicle (asset) - required
↓
Each Entity Brings Its Own Flows:

Borrower (participant) has:
  Business Process: [Created] → [KYC Pending] → [KYC Verified] → [Income Pending] → [Income Verified] → [Approved]
  Workflows: KYC Workflow, Income Workflow (tied to Borrower)

Vehicle (asset) has:
  Business Process: [Created] → [Valuation Pending] → [Valued] → [Inspected] → [Approved]
  Workflows: Valuation Workflow, Inspection Workflow (tied to Vehicle)

Application has:
  Business Process: [Draft] → [Entities Pending] → [Underwriting] → [Decision] → [Approved] → [Funded]
  Workflows: Credit Decision Workflow, Approval Workflow (tied to Application)

State Transition Triggers Workflow: When Borrower moves to "KYC Pending" state → KYC Workflow (tied to Borrower) executes → Workflow makes decision → Moves Borrower to "KYC Verified" or creates Warning Fact

Why This Matters:

• Products select entity structure (participants, assets)

• Participants and assets own their business processes and workflows

• Changes to business processes are testable with proper data transition management

• Workflows provide flexible logic that business users can adjust

• Best practice: Products define "what" (entity structure), entities define "how" (flows and workflows)

Product Impact on Data Collection

Indirect Data Collection Through Entity Requirements:

Product: Auto Loan
↓
Requires Entities:
- Primary Borrower (participant)
- Vehicle (asset)
↓
Activates Entity Business Processes:
- Borrower business process (KYC → Income Verification → Approval)
- Vehicle business process (Valuation → Inspection → Approval)
↓
Business Processes Execute at State Transitions:
- Borrower moves to "KYC Pending" → KYC Workflow executes
- Vehicle moves to "Valuation Pending" → Valuation Workflow executes
↓
Data Collection Forms Associated with Entities:
- Primary Borrower Form (income verification, employment, credit history)
- Vehicle Form (VIN, make, model, valuation)
- Required Documents: Proof of income, vehicle registration

Example:

Product Template: "Secured Personal Loan - $10k-$50k"

Entity Requirements:
✓ Primary Borrower (mandatory)
✓ Collateral Asset (mandatory)
□ Co-Borrower (optional)

Result:
→ Primary Borrower entity created
→ Borrower business process starts (SDK-defined states)
→ Borrower data collection forms activate (entity-specific)
→ Borrower state transitions trigger workflows (flexible decision logic)

→ Collateral Asset entity created  
→ Asset business process starts (SDK-defined states)
→ Asset data collection forms activate (entity-specific)
→ Asset state transitions trigger workflows (flexible decision logic)

→ Co-Borrower data collection remains inactive unless user adds co-borrower

Participant and Asset Requirement Definition

How Product Selection Works

The product selection process establishes the framework for application processing through entity requirements:

Step 1: Product Selection User selects credit product (e.g., Personal Loan, Auto Loan, Mortgage) during application creation.

Step 2: Requirement Determination The system evaluates product template configuration and:

• Identifies required participant types (e.g., Primary Borrower, Co-Borrower, Guarantor)

• Identifies required asset categories (e.g., Vehicle for Auto Loan, Property for Mortgage)

• Determines which entity data collection steps will be needed

• Establishes entity-based workflow paths

Step 3: Entity Validation and Prompts Based on requirements:

• Validates if necessary entities already exist in the application

• Prompts user to create missing entities if required

• Does NOT automatically create entities; user must explicitly add them

Step 4: Entity Data Collection Activation Once required entities are added:

• Entity-specific data collection forms become accessible

• Required documents for that entity type are requested

• Entity-based workflows initiate

Step 5: Workflow Execution

• Workflows execute based on entity states (e.g., Borrower moves to "Verified" state)

• Workflows are tied to entities, not products directly

• Product template defines which entity workflows must complete

Implementation Resources

Through the Admin Panel

• Credit Product Configuration - Setting up product requirements

• Participant Types - Defining participant categories

• Asset Types - Configuring collateral and asset categories

• Workflow Designer - Creating flexible decision logic

Through the SDK

• Product Requirements API - Programmatic requirement management

• Entity Validation - Checking application completeness

• Dynamic Requirements - Runtime requirement evaluation

• Business Process Configuration - Defining entity states and transitions

Related Topics

• Product Architecture - Understanding product templates

• Workflow Fundamentals - Understanding workflow design and execution

• Workflow vs Business Process - Detailed architectural explanation

---

For additional support, consult implementation team.