Product Architecture

Overview

timveroOS implements a two-tier product architecture that provides flexibility in lending product design while maintaining standardization and control. This architecture separates general product definitions from specific variations, enabling efficient product management and rapid market adaptation.

Two-Tier Product Model

Credit Products

Credit products define the general framework for lending offerings:

• Product Type: Term loans, revolving credit, or hybrid structures

• General Parameters: Overall amount ranges and term limits

• Documentation Framework: Standard templates and requirements

Additives

Additives provide specific implementations within a product framework:

• Targeted Segments: Specific customer criteria and qualifications

• Precise Terms: Exact rates, amounts, and conditions

• Collateral Requirements: Security specifications if applicable

• Unique Features: Special conditions or benefits

Credit product configuration management interface

Product Configuration

Creating Credit Products

Navigate to Settings → Credit Products to configure:

Required Fields:

• Product Name and Code

• Product Type selection

• Currency specification

• Status (Active/Inactive)

Parameter Ranges:

• Minimum and maximum amounts

• Available term options

• Interest rate boundaries

• Fee structures

Product Documentation

The system works with two categories of documents, each configured at different levels:

Required/Uploadable Documents

Documents that the client or employee must upload to the system.

Configuration Level: SDK only

• The list of required documents is defined exclusively at the SDK level

• Conditions for document requirements are configured in SDK

• Specifies which document types are required for which entity states and roles

Example: ID scan is required for a participant with status NEW and role GUARANTOR or BORROWER

SDK Configuration:

• Define document types

• Configure requirement conditions (entity type, state, role)

• Set up validation rules

For SDK configuration, see SDK Guide: Credit Products

Generated Documents

Documents automatically created by the system based on templates.

SDK Configuration:

• List of generated document types

• Generation logic and triggers

• Conditions for generation availability

• Data model for template population

Admin Panel Configuration:

• Create and edit document templates

• Optional linkage to credit product (if applicable)

• Template design and layout

Example: A credit agreement is generated for a participant with role Borrower and status APPROVED when an approved payment schedule exists. The system uses the generation template specified on the credit product within which the client selected the credit offer.

Configuration Flow:

1. SDK defines: Document types, generation logic, data model

2. Admin Panel: Create templates for those document types

3. Admin Panel (optional): Link templates to specific credit products

4. System automatically generates documents based on SDK-defined conditions

Summary

• Required Documents: Fully SDK-configured (what documents, when required, validation)

• Generated Documents: SDK defines logic, Admin Panel creates templates

• Admin Panel Role: Template creation and optional product linkage only

Important Note

Each credit product must have at least one additive to be functional. The system will indicate products without additives as "Empty Additive Products."

Additive Configuration

Purpose of Additives

Additives enable:

• Customer segmentation within products

• Risk-based pricing variations

• Targeted market offerings

• A/B testing capabilities

Creating Additives

Additives are configured in the Admin Panel with the following components:

Configurable in Admin Panel:

• Basic Information: Name, Code, Description, Status

• Eligibility Criteria: Configured via Offer Engine scripts

• Specific Terms: Configured via Offer Engine scripts

• Pricing Parameters: Rates, fees, and conditions

• Participant Requirements: Specify required participant roles

Note: Advanced pricing algorithms and eligibility logic are implemented through Offer Engine scripts, which provide flexible, programmatic control over additive terms.

For each additive, configure:

1. Identification

   • Additive name and description

   • Internal reference code

   • Active/Inactive status

2. Eligibility Criteria

   • Credit score requirements (via Offer Engine script)

   • Income thresholds (via Offer Engine script)

   • Employment criteria (via Offer Engine script)

   • Other qualification rules (via Offer Engine script)

3. Specific Terms

   • Interest rate ranges (via Offer Engine script)

   • Exact amount limits (via Offer Engine script)

   • Available terms

   • Fee specifications

4. Collateral Settings

   • Required security types

   • Loan-to-value ratios

   • Valuation requirements

   • Insurance mandates

5. Participant and Asset Requirements

   • Required participant types (borrower, co-borrower, guarantor)

   • Optional participant roles

   • Collateral/asset requirements

   • Each participant/asset type brings its configured workflows

Offer Engine Integration

Each additive connects to an offer engine script that calculates:

• Applicable interest rates

• Available loan amounts

• Payment schedules

• Total costs

The offer engine uses:

• Customer profile data

• Product parameters

• Market conditions

• Risk assessments

Product States and Lifecycle Management

Credit products in timveroOS can exist in different states that control their availability and behavior in the origination process.

Product States

Draft

• Product is being configured and tested

• Not available for new applications

• Cannot be selected by customers

• Allows safe configuration changes before activation

Active

• Product is live and available for new applications

• Appears in customer-facing interfaces

• Can be selected when creating applications

• Existing configurations remain stable

Inactive

• Product is no longer available for new applications

• Does not appear in customer-facing interfaces

• Existing loans continue under original terms

• Historical data and configurations preserved

State Transitions

Draft → Active (Activation)

Requires complete product configuration:

• At least one additive configured

• All required parameters set

• Pricing rules validated

System validates configuration completeness before allowing activation. Product becomes available for applications immediately upon activation.

Active → Inactive (Deactivation)

• Removes product from new application options

• Does not affect existing loans

• Can be reactivated if needed

• Maintains all configuration data

Note: Products cannot be deleted, only deactivated. This ensures data integrity and maintains historical records for compliance and reporting.

Product Copy Functionality

The platform supports creating new products based on existing ones through the copy feature.

Copy Process:

1. Select source product to copy

2. System creates new product in Draft state

3. All configuration copied:

   • Base product parameters

   • All additives and their settings

   • Pricing rules and calculations

   • Document template associations

4. New product assigned unique product code

5. Modify copied product as needed

6. Activate when ready

Use Cases:

• Product Variations: Create similar products with slight modifications

• Market Testing: Test product changes without affecting existing product

• Version Management: Maintain multiple versions of similar products

• Rapid Deployment: Quickly launch products based on proven templates

What Gets Copied:

• All product parameters (amount ranges, terms, rates)

• All additives with complete configuration

• Pricing engine scripts and rules

• Document template associations

• Participant and collateral requirements

What Doesn't Get Copied:

• Product state (always starts as Draft)

• Product code (assigned new unique code)

• Historical application data

• Usage statistics

Additive Management

Additives within products follow similar lifecycle principles:

Adding Additives:

• Can add new additives to Active products

• New additives available immediately upon creation

• No service interruption for existing applications

Modifying Additives:

• Changes to existing additives affect only new applications

• Existing applications/loans retain original terms

• System maintains configuration versions

Deactivating Additives:

• Removes additive from new application options

• Product remains active if other additives exist

• Cannot deactivate last additive in Active product

Requirement: Every Active product must have at least one Active additive. The system enforces this rule and prevents configurations that violate it.

Best Practices

Product Development Workflow:

1. Create product in Draft state

2. Configure all parameters and additives

3. Test thoroughly in non-production environment

4. Activate when ready for production

5. Monitor performance and user feedback

6. Use Copy feature for variations or improvements

Version Management:

• Use Copy for major product changes

• Keep original product Active during transition

• Gradually migrate customers to new version

• Deactivate old version when migration complete

Naming Conventions:

• Include version indicators in product names (v1, v2, etc.)

• Use descriptive names that indicate product purpose

• Maintain consistent naming across product family

• Document product relationships in descriptions

Product Examples

Example 1: Auto Loan Product

Base Product:

• Name: Vehicle Finance

• Amount Range: $5,000 - $100,000

• Terms: 12-84 months

• Documentation: Standard auto loan package

Additive Examples:

• Prime Auto: 720+ credit score, lowest rates, no down payment required

• Standard Auto: 660-719 credit score, standard rates, 10% down payment

• Subprime Auto: 600-659 credit score, higher rates, 20% down payment

Example 2: Personal Loan Product

Base Product:

• Name: Unsecured Personal Loan

• Amount Range: $1,000 - $50,000

• Terms: 12-60 months

• Documentation: Personal loan agreement set

Additive Examples:

• Existing Customer: Relationship discount, streamlined process

• New Customer Prime: Full underwriting, competitive rates

• Debt Consolidation: Specific purpose, potentially higher amounts

Managing Product Lifecycle

Product Activation

1. Create base product with parameters

2. Configure required additives

3. Assign workflow processes

4. Test configuration

5. Activate for use

Ongoing Management

• Monitor product performance

• Adjust additive parameters

• Add new additives as needed

• Deactivate underperforming options

Product Deactivation

• Set product to inactive status

• Stop new originations

• Continue servicing existing loans

• Maintain records for compliance

Configuration Best Practices

Product Design

• Start with essential products

• Keep initial additives simple

• Test thoroughly before launch

• Document configuration decisions

Additive Strategy

• Create clear segmentation

• Avoid overlapping criteria

• Monitor performance metrics

• Consolidate when appropriate

Documentation

• Maintain consistent templates

• Version control changes

• Document business rationale

• Keep audit trails

Integration Points

System Components

Products integrate with:

• Participant/Asset Requirements: Define required entities for applications

• Document Management: Template selection and generation

• Pricing Engine: Rate and term calculation

• Reporting System: Performance tracking

Note: Workflow Engine evaluations are triggered by the participants and assets required by products, not by products directly.

External Systems

• Core banking product codes

• General ledger mapping

• Regulatory reporting categories

• Third-party integrations

Performance Considerations

Configuration Impact

• Product complexity affects processing speed

• Multiple additives increase decision time

• Clear criteria improve automation rates

• Well-defined products reduce exceptions

Optimization Strategies

• Regular configuration reviews

• Performance monitoring

• Simplification initiatives

• Automated testing

Related Operations

Once configured, see how products are used in operations:

• Product Selection (OPS) - Selecting products during application processing

Next Steps

With products configured, proceed to:

• Pricing Configuration - Set up dynamic pricing algorithms

• Collateral Management - Configure security requirements

• Workflow Fundamentals - Build approval processes

---

For additional product configuration support, consult your implementation team or system documentation.