Applications

Understanding Applications in timveroOS

Applications are aggregating entities that bring together participants and assets to complete processes resulting in loan issuance. They serve as containers that orchestrate all elements of a lending transaction through their lifecycle.

Core Application Concepts

According to the system architecture, applications follow a standard pattern where one application can contain multiple participants. This "Application one-to-many Participant" schema provides flexibility to handle various lending scenarios.

Key characteristics:

• Participants are primary to applications

• Application stages are determined by participant/asset states and statuses

• No application can exist without participants

• Business processes are built around participants with various roles

Application Types Supported

The system simultaneously supports several types of processes and corresponding applications:

Online Applications Applications completed outside the system and registered via API:

• All stages typically process without system user involvement (except manual underwriting)

• System architecture supports end-to-end processing through API interactions (see API Integration section for implementation details)

• External systems can initiate, monitor, and complete the entire origination process

• Generally have only one participant with the borrower role

Offline Applications Applications completed by system users when clients visit the institution in person:

• May contain multiple participant types:

  • Borrower

  • Guarantor

  • Co-borrower

  • Collateral provider

  • Collateral assets

• Require system user interaction throughout the process

Pre-approved Applications Applications created automatically by the system:

• Generated for selected pools of clients meeting specified criteria

• Support marketing campaign execution

• Typically involve single participant with borrower role

How Application Status Works

Application status is derived from participant statuses based on underlying business process logic. Each application type has its own set of statuses, but these are determined by the statuses of contained participants.

Status Derivation Example

Consider an application with:

• Borrower status: Approved

• Guarantor 1 status: Approved

• Guarantor 2 status: KYC

The application status would be KYC, following the logic that if at least one active participant has a KYC status, then the application status is also KYC.

This approach ensures that applications accurately reflect the state of all their components and cannot progress until all participants meet requirements.

Configuration Capabilities

Application Parameter Configuration

The framework allows defining:

• Application parameter sets

• Process setup based on state/status

• Flow orchestration rules

• Status derivation logic

Participant Composition

Different application types involve different participant compositions based on:

• Business process requirements

• Credit product characteristics

• Channel-specific needs

• Risk mitigation strategies

Integration and Processing

The platform provides comprehensive support for application processing across channels:

API Integration

• Complete application lifecycle management through programmatic interfaces

• Custom API Development: Process-specific endpoints can be created for each business process, allowing tailored request/response structures that align with institutional requirements

• Flexible Online Flows: Rather than pre-built APIs, the platform enables development of custom endpoint sets that match specific process needs

• Support for external system integration

• Automated data exchange capabilities

• Status monitoring and updates

User Interface Support

• Application creation forms

• Participant management interfaces

• Data entry capabilities

• Status tracking displays

Practical Implementation Patterns

Based on system documentation, common patterns include:

Single Participant Pattern

• Used for: Simple consumer loans, online applications

• Configuration: One borrower participant

• Processing: Largely automated

Multi-Participant Pattern

• Used for: Complex loans requiring additional security

• Configuration: Borrower plus guarantors/co-borrowers

• Processing: Coordinated evaluation of all participants

Collateral-Backed Pattern

• Used for: Secured lending products

• Configuration: Borrower plus collateral provider and assets

• Processing: Parallel evaluation of creditworthiness and collateral

Implementation Resources

Through the Admin Panel

(No settings in the Admin Panel)

Through the SDK (Step 1)

For specialized requirements:

• Data Model Setup - Customize application structures

• Entity Checkers - Implement business rules

Key Considerations

Application Design Principles

• Applications aggregate participants and assets

• Status reflects the state of all components

• Different channels may use different application types

• Flexibility to support various business processes

Operational Benefits

• Unified view of all transaction elements

• Consistent processing across channels

• Clear status visibility

• Comprehensive audit trails

Related Topics

• Clients and Participants - Understanding component entities

• Business Process vs Workflow - How applications flow through processes

• Status Management - Detailed status derivation logic

---

timveroOS: Unified application management for modern lending