> For the complete documentation index, see [llms.txt](https://docs.timvero.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.timvero.com/timveroos-admin-panel-documentation/v.8.2/setup/03-products/product-architecture.md). # 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 Note: despite two-layered model - Product+Additive - is universal, all their oarameters can be custom.

Credit product configuration management interface

## Product Configuration ### Creating Credit Products Navigate to Settings → Credit Products to configure: **Required Fields or Statuses**: * Product Name and Code * Product Type selection * Currency specification * Status (Draft/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**: Building Platform only * The list of required documents is defined exclusively on the Building Platform * Conditions for document requirements are configured on the Building Platform * 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 **Building Platform Configuration**: * Define document types * Configure requirement conditions (entity type, state, role) * Set up validation rules For Building Platform configuration, see [SDK Guide: Credit Products](https://documentation.timvero.com/#credit-products) and [SDK Guide: Documents](https://documentation.timvero.com/#document-management) ### Generated Documents Documents automatically created by the system based on templates. **Building Platform Configuration (SDK)**: * 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. Building Platform 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 Building Platform conditions ### Summary * **Required Documents**: Fully Building Platform-configured (what documents, when required, validation) * **Generated Documents**: Building Platform defines logic, Admin Panel creates templates * **Admin Panel Role**: Template creation and optional product linkage only

Example of the product template form - NOTE: the actual fields are configurable on the Building platform level

### 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 **participant and asset profile data** as its primary input. Profiles are dynamic data containers attached to each participant and asset, populated by workflow execution and manual data entry during the assessment process. Common profile attributes used by offer scripts include credit scores, verified income, debt-to-income ratios, net disposable income for participants, and market values and LTV ratios for assets. Because the Offer Engine has access to profiles across all participants and assets on an application, scripts can produce highly differentiated offers based on the specific entity combination. For example, adding a guarantor with a strong credit profile or collateral with a high verified market value can unlock additional product offers or improve pricing terms. Beyond profile data, the offer engine also uses: * Product parameters (amount ranges, term limits, rate boundaries) * Reference rates and market conditions (from configured catalogs) * Business rules defined in the script logic For a detailed explanation of how profiles are built and consumed, see [Workflow Fundamentals — Participant and Asset Profiles](/timveroos-admin-panel-documentation/v.8.2/setup/04-workflows/workflow-fundamentals.md#participant-and-asset-profiles).

Example of the additive template form - NOTE: the actual fields are configurable on the Building platform level

## 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 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 (via copiying) 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 products (should be Inactive) * 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 * 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)](/timveroos-admin-panel-documentation/v.8.2/ops/01-origination/product-selection.md) - Selecting products during application processing ## Next Steps With products configured, proceed to: * [Pricing Configuration](/timveroos-admin-panel-documentation/v.8.2/setup/03-products/pricing-configuration.md) - Set up dynamic pricing algorithms * [Collateral Management](/timveroos-admin-panel-documentation/v.8.2/setup/03-products/collateral-management.md) - Configure security requirements * [Workflow Fundamentals](/timveroos-admin-panel-documentation/v.8.2/setup/04-workflows/workflow-fundamentals.md) - Build approval processes *** *For additional product configuration support, consult your implementation team or system documentation.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.timvero.com/timveroos-admin-panel-documentation/v.8.2/setup/03-products/product-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.