Clients and Participants
Understanding Customer Data Organization
timveroOS separates customer information into two key concepts that work together to eliminate redundancy while maintaining flexibility: Clients and Participants.
Client: The Master Record
According to the system design, a Client is a high-level entity that stores fundamental personal information and serves as a parent container for participants. This master record contains reusable data including:
Personal details (name, date of birth, SSN)
Consent for data processing
Overall credit limits
Phone numbers and contact information
One client can spawn multiple participants across different applications and roles, ensuring information is entered once and reused across all interactions.
Participant: Role-Specific Instances
A Participant represents a specific instance of a client acting in a defined role within a particular application. Participants:
Are application-specific entities
Inherit basic information from their parent client
Have role-specific attributes, documents, and workflows
Exist only within the context of a single application
Common participant roles include borrower, co-borrower, guarantor, and collateral provider.
How This Structure Benefits Your Operations
Eliminate Redundant Data Entry
When a client applies for multiple products or participates in different applications, their fundamental information is already available. The system automatically populates participant records from the client master data, significantly reducing manual data entry.
Enable Flexible Role Management
The same client can participate in different applications with different roles. For example:
In one application as a borrower
In another application as a guarantor
In a third application as both borrower and collateral provider
Maintain Complete Relationship Views
The framework provides visibility into all relationships and commitments for each client across your institution, supporting comprehensive risk assessment and relationship management.
System Capabilities
Data Storage and Management
Client-Level Data (stored once, reused many times):
Personal information: last name, first name, date of birth, SSN, phone number
Client maximum credit limits for all their loans
Client consent for personal data processing (can be reusable in all applications)
Reusable participant parameters
Participant-Level Data (specific to each application and role):
Role-specific attributes
Application-specific documents
Status within the business process
Role-based workflow progression
Practical Application Examples
Based on the system documentation, here are typical usage patterns:
Online Applications: Generally have one participant with the borrower role, created from client data via API integration.
Offline Applications: May contain multiple participants such as:
Borrower (primary applicant)
Guarantor (risk mitigation)
Co-borrower (shared responsibility)
Collateral provider (asset security)
Pre-approved Applications: System automatically creates applications for selected clients who meet specified criteria, demonstrating the reusability of client data.
Configuration and Implementation
Setting Up Client and Participant Management
The system provides comprehensive configuration options:
Entity Structure Configuration Define the complete set of attributes for:
Client records (universal data)
Participant records by role (role-specific data)
Validation rules and data retention policies
Data Flow Configuration Establish how information moves from clients to participants:
Automatic field population rules
Override permissions for exceptions
Historical data preservation settings
Integration Capabilities
For Offline Processes: The system supports SSN lookup functionality where:
User specifies participant identifier (SSN)
System queries Core Banking System and pre-fills form fields
If not found in Core Banking, system searches internal clients
Remaining fields can be completed manually
For Online Processes: System receives participant data via API or message broker integrations.
Implementation Resources
Through the Admin Panel
(No settings in the Admin Panel)
Through the SDK (Step 1)
When standard configuration needs extension:
Data Model Setup - Custom entity structures
Form Classes and HTML templates - Custom data entry forms
Important Distinctions
It's crucial to understand the difference between a Client and a Participant:
Client: Persistent, reusable entity across multiple applications
Participant: Application-specific, role-based instance of a client
Relationship: One-to-many (one client can have multiple participants)
Data scope: Client stores universal data, participant stores role-specific data
Lifecycle: Client persists across applications, participant exists only within one application
Related Topics
Applications - How participants work within applications
Business Process vs Workflow - How participants flow through processes
Status Management - Tracking participant progress
timveroOS: Intelligent customer data management for modern lending
Last updated
Was this helpful?