Clients and Participants

What are Clients and Participants?

TimveroOS separates customer information into two entities to eliminate data redundancy while maintaining flexibility:

• Client: Master record storing reusable personal information

• Participant: Role-specific instance of a Client within a specific Application

Client Entity

What Clients Store

Personal Information:

• Full name (first, middle, last)

• Date of birth

• National identification number (SSN, passport, ID)

• Contact information (phone, email, address)

Consent and Limits:

• Data processing consent

• Maximum credit limits across all loans

• Communication preferences

Reusable Attributes:

• Parameters that apply across all applications

• Information that doesn't change per application

Client Characteristics

• Persistent: Exists independently of applications

• Reusable: One Client can spawn multiple Participants

• Master Record: Single source of truth for personal data

• Cross-Application: Visible across all Applications where Client participates

Participant Entity

What Participants Store

Role Information:

• Participant role (Borrower, Co-borrower, Guarantor, Collateral Provider)

• Application-specific attributes

• Role-specific documents

• Workflow assessment results

Status Information:

• Current position in Business Process

• Assessment outcomes

• Approval/rejection decisions

Application Context:

• Link to specific Application

• Link to parent Client

• Relationship to other Participants in same Application

Participant Characteristics

• Application-Specific: Exists only within one Application

• Role-Based: Has defined role (Borrower, Guarantor, etc.)

• Inherits Data: Gets basic information from parent Client

• Temporary: Created for Application, may not persist after

How Client-Participant Model Works

Data Flow

Client (Master Record)
  │
  ├── Personal Info: John Smith, DOB: 1985-01-15, SSN: 123-45-6789
  │
  └── Creates Participants:
        │
        ├── Participant 1 (Application A - Borrower Role)
        │     ├── Inherits: Name, DOB, SSN from Client
        │     ├── Adds: Income, employment, borrower-specific documents
        │     └── Status: APPROVED
        │
        └── Participant 2 (Application B - Guarantor Role)
              ├── Inherits: Name, DOB, SSN from Client
              ├── Adds: Guarantor-specific documents
              └── Status: ASSESSMENT

Benefits

1. Eliminate Redundant Data Entry

When John Smith applies for a second loan:

• Client data already exists

• System creates new Participant automatically

• Inherits personal information from Client

• Only new application-specific data needed

2. Enable Multiple Roles

Same Client can participate in different Applications with different roles:

• Borrower in Application A

• Guarantor in Application B

• Co-borrower in Application C

3. Maintain Relationship View

View all of a Client's relationships across the institution:

• All Applications where they're Borrower

• All Applications where they're Guarantor

• Total exposure across all roles

• Complete credit history

Participant Roles

Common Roles

Borrower:

• Primary applicant

• Receives loan proceeds

• Primary repayment responsibility

• Undergoes full credit assessment

Co-borrower:

• Shared responsibility with Borrower

• May or may not receive proceeds

• Joint credit assessment

• Appears on loan documents

Guarantor:

• Provides credit enhancement

• No direct loan proceeds

• Secondary repayment responsibility

• Credit assessment for guarantee capacity

Collateral Provider:

• Provides asset security

• May or may not be Borrower

• Asset ownership verification

• Asset assessment workflow

Practical Examples

Example 1: Online Single-Borrower Application

Scenario: Customer applies for personal loan online

1. Client Check:

   • System searches for existing Client by SSN

   • IF EXISTS: Retrieve Client data

   • IF NOT EXISTS: Create new Client with submitted data

2. Participant Creation:

   • Create Participant with role=Borrower

   • Link Participant to Client

   • Link Participant to new Application

   • Inherit Client personal data

   • Add borrower-specific information (income, employment)

3. Processing:

   • Single Participant workflow executes

   • Application status = Participant status

   • Simple, fast processing

Example 2: Offline Multi-Participant Application

Scenario: Branch staff processes loan with borrower and guarantor

1. Borrower Setup:

   • Staff enters Borrower SSN

   • System looks up Client (creates if new)

   • Creates Borrower Participant

   • Links to Application

2. Guarantor Setup:

   • Staff enters Guarantor SSN

   • System looks up Client (creates if new)

   • Creates Guarantor Participant

   • Links to same Application

3. Processing:

   • Borrower workflow executes (credit assessment)

   • Guarantor workflow executes (guarantee capacity check)

   • Application status reflects least-progressed Participant

Example 3: Pre-approved Application for Existing Client

Scenario: Marketing campaign targets existing customers

1. Client Selection:

   • System identifies eligible Clients

   • Clients must meet campaign criteria

2. Automatic Application Creation:

   • System creates Application

   • System creates Participant (role=Borrower)

   • Links Participant to existing Client

   • Pre-populated with Client data

3. Offer Generation:

   • Offer Engine calculates terms using Client history

   • Multiple offers generated

   • Customer notified of pre-approval

Data Integration

For Offline Processes

SSN Lookup Workflow:

1. Staff enters SSN in application form

2. System queries Core Banking System

3. If found: Pre-fills form fields with banking data

4. If not found in banking: Searches internal Clients

5. If found in Clients: Pre-fills from Client data

6. If not found anywhere: Staff enters manually

7. New Client created with entered data

For Online Processes

API Integration:

1. External system sends application data via API

2. Includes Client identification (SSN, email, etc.)

3. TimveroOS searches for existing Client

4. Creates or retrieves Client

5. Creates Participant linked to Client

6. Creates Application

7. Returns Application ID and status

Configuration

Framework Level (SDK)

• Client entity structure and attributes

• Participant entity structure and attributes

• Role definitions

• Inheritance rules (which fields copy from Client to Participant)

• Validation rules

Admin Panel Level

• Form design for data entry (Form Builder)

• Role-specific document requirements

• Participant workflow triggers by role

Operational Level

• Client search and selection

• Participant role assignment

• Data entry and verification

Implementation Resources

Through SDK (Development team)

Entity Configuration:

• Data Model Setup - Client and Participant structure

• Form Classes Setup - Custom data entry forms

• HTML Template Integration - Form templates

Through Admin Panel

Form Configuration:

• Form Builder - Design Client and Participant data entry forms

Product Configuration:

• Credit Products and Pricing - Define role-specific document requirements

Related Topics

• Applications - How Participants work within Applications

• Business Process vs Workflow - How Participants flow through processes

• Status Management - Tracking Participant progress

• Loan Origination - Participant role in origination

---

TimveroOS: Intelligent customer data management