System Entities

Overview

timveroOS organizes lending data through interconnected entities. The SDK defines entity structures and their relationships. Admin Panel manages operational data within these structures.

Why This Matters

Lending involves the same person in different contexts: a customer applies for a loan (Participant as Borrower), guarantees another loan (Participant as Guarantor), and maintains an ongoing relationship (Client). timveroOS separates these concerns:

  • Client maintains the single customer view across all interactions

  • Participant tracks role-specific data and decisions for each application

  • Application brings together all parties and data for a credit request

This structure enables role-specific processing (different workflows for Borrower vs Guarantor) while maintaining a complete customer relationship view.

The multi-participant model also allows complex business processes to be implemented and maintained simply. Applications can involve multiple borrowers, guarantors, and collateral providers, each processed through their own workflows and assessed independently, while the Application entity orchestrates the overall decision.

Core Entities

Entity
Purpose

Client

Master customer record with personal information, persists across all applications

Participant

Role-specific instance of a Client within an application (Borrower, Co-Borrower, Guarantor)

Application

Credit request that brings together Participants, selected Products, and assessment data

Loan (Credit)

Active loan created from approved Application, tracks balance and payment schedule

Asset

Collateral item linked to Participants and used as security for the loan

Relationships:

Business Process vs Workflow

This distinction is fundamental to understanding timveroOS:

Concept
What It Is
Who Configures
Example

Business Process

The journey stages an entity follows (state machine)

SDK (Development team)

Application → Underwriting → Approval → Funding

Workflow

Decision logic that executes within a stage

Admin Panel (Business team)

Credit scoring workflow that calls bureau data and evaluates risk

Key principle: Business Process controls WHEN workflows execute. Workflows determine WHAT decision is made at that point.

Status Management

Each entity has a status indicating its current Business Process stage. Statuses are SDK-defined; Admin Panel cannot add new statuses but can configure what happens within each status.

Entity
Example Statuses

Application

New, In Progress, In Underwriting, Approved, Declined, Void

Participant

New, In Process, Manual Approval, Approved, Declined

Loan

Active, Past Due, Paid, Closed, Void

User Roles and Permissions

Users access the system through role-based permissions:

Concept
Purpose

Role

Named collection of permissions (e.g., Loan Officer, Underwriter, Administrator)

Permission

Granular action control (view applications, make decisions, configure products)

Department

Organizational unit for routing manual reviews (Warning Facts route to specific departments)

Document Management

Documents attach to entities throughout the lending lifecycle:

Aspect
Description

Document Types

Categories of required documents (ID, income proof, contracts) — SDK-defined

Document Templates

Content templates for generated documents — Admin Panel configured

Document Collection

Upload and verification of required documents — Operations

Where to Configure

Aspect
Layer
Documentation

Entity structures, status definitions

SDK

Business Process stages

SDK

User roles and permissions

Admin Panel Setup

Document templates

Admin Panel Setup

Workflow logic

Admin Panel Setup

Entity operations

Admin Panel OPS


timveroOS: Structured lending data with flexible configuration

Last updated

Was this helpful?