System Architecture Documentation

Executive Summary

The Insurance Management System (INSMASTR) is a comprehensive, enterprise-grade mainframe application built for IBM z/OS environments. It implements a batch processing architecture that handles three core insurance operations: policy creation, policy renewal, and claims management with integrated fraud detection capabilities.

Key Architectural Characteristics

Business Capabilities

The system provides the following core capabilities:

1. New Policy Creation - Customer onboarding and policy setup with risk assessment
2. Policy Renewal Processing - Automated renewal calculations with loyalty and no-claims discounts
3. Claims Management - Claims adjudication with sophisticated fraud detection
4. Regulatory Compliance - Audit trails, error logging, and comprehensive reporting

System Overview

Purpose and Scope

The Insurance Management System serves as the primary batch processing engine for insurance operations, handling end-to-end processing workflows for policies, renewals, and claims.

In Scope

• Sequential file processing for policy, renewal, and claims data
• DB2 database operations for persistent storage
• Risk scoring and premium calculation
• Fraud detection and investigation flagging
• Error handling and reporting
• Transaction management with commit/rollback
• Customer record management (create/update)
• Policy lifecycle management
• Claims payment calculation

Out of Scope

• Real-time online processing
• Customer self-service interfaces
• Payment processing and collections
• Document management
• Email/notification services
• Interactive web services or APIs

Processing Modes

The program supports four operational modes controlled via JCL PARM parameter:

Technology Stack

Core Technologies

Programming Language

Database Technology

Platform Technology

Development and Compilation Tools

Technology Stack Inventory

System Context and Boundaries

System Context Diagram

The following diagram illustrates the INSMASTR program within its operational environment, showing all external interfaces:

File Inventory

Input Files

Output Files

Component Architecture

High-Level Component View

The INSMASTR program follows a modular, section-based architecture typical of structured COBOL programs:

Component Description Table

Deployment Architecture

z/OS Deployment View

Runtime Configuration

System Parameters

DB2 Connection Settings

File Organizations

Data Architecture

Database Schema

The system uses five primary DB2 tables with relationships maintained through foreign keys:

Database Table Descriptions

Database Operations Summary

Data Flow Architecture

Processing Architecture

Batch Processing Model

The system implements a classic batch processing architecture with the following characteristics:

Sequential Processing Pattern

• Records processed one at a time in sequential order
• No parallel processing within a single program instance
• Multiple job instances can run concurrently with different processing modes
• Read-Process-Write loop pattern applied uniformly

Commit Strategy

Error Handling Strategy

Processing Flow Diagram

Performance Characteristics

Record Processing Rates

Resource Utilization

Component Interactions

Transaction Management

Commit Point Pattern

The system implements a configurable commit strategy:

Transaction Boundaries

Error Handling Flow

Database Access Patterns

Customer Management (MERGE Pattern)

Policy Renewal Chain

Design Patterns

Architectural Patterns Applied

1. Batch Processing Pattern

Implementation:

• Sequential file processing with commit points
• Read-Process-Write loop for each record type
• Periodic commits based on record count

Rationale:

• Mainframe-standard approach
• Efficient for bulk operations
• Enables restart/recovery from checkpoints

Trade-offs:

• No real-time processing capability
• Recovery requires restart from last checkpoint
• All-or-nothing at commit boundaries

2. Three-Tier Separation of Concerns

Benefits:

• Clear module boundaries
• Testable components
• Maintainable code structure

3. Centralized Error Handling Pattern

Implementation:

• Single error handler section (8000-ERROR-HANDLER)
• Invoked via PERFORM from any error condition
• Consistent error logging and severity classification

Benefits:

• Consistent error format across all processing
• Single point for rollback logic
• Simplified maintenance of error handling

Code Pattern:

IF error-condition
    MOVE error-code TO WS-ERROR-CODE
    MOVE error-message TO WS-ERROR-MESSAGE
    PERFORM 8000-ERROR-HANDLER
END-IF

4. Table-Driven Configuration

Implementation:

• Rate tables loaded at initialization
• Indexed table searches for efficient lookups
• No hardcoded business rules in logic

Examples:

• Age-based rate factors (10 entries)
• State-based rates and taxes (50 entries)
• Occupation risk factors (20 entries)

Benefits:

• Separation of data from logic
• Easier maintenance of rate structures
• Performance optimization via indexing

5. Transaction Boundary Pattern

Implementation:

• Explicit commit frequency (500 records)
• Automatic rollback on errors
• Final commit before program termination

Design Decision:

Record count-based commits chosen over time-based
Rationale: Predictable recovery points
Alternative considered: Time-based (rejected due to unpredictability)

Design Decisions and Rationale

Commit Frequency: 500 Records

Customer MERGE vs. Separate INSERT/UPDATE

Embedded Rate Tables

Multi-Factor Fraud Detection

Rationale: Composite scoring reduces false positives while maintaining detection effectiveness

Record-Level Error Recovery

Scalability Considerations

Current Scalability Profile

Processing Capacity

Scalability Patterns

Horizontal Scaling

Capability:

• Multiple job instances run concurrently
• Process different file types simultaneously (POLICY/RENEWAL/CLAIM modes)
• Separate jobs for different regions or lines of business

Implementation:

Job Instance 1: PARM='POLICY'  - Process new policies
Job Instance 2: PARM='RENEWAL' - Process renewals
Job Instance 3: PARM='CLAIM'   - Process claims

Constraints:

• No shared state between instances
• Each instance requires separate input files
• DB2 concurrency controlled by isolation level (CS)

Vertical Scaling

Options:

Database Scaling

Indexing Strategy:

Partitioning Strategy:

Query Optimization:

Current bottleneck: Fraud detection requires 6-8 DB2 queries per claim

Optimization Options:

1. Single complex JOIN query vs. multiple SELECTs
2. Stored procedure for fraud calculation
3. Materialized view for frequency analysis
4. Cache provider fraud scores in memory

Performance Optimization Opportunities

1. Reduce DB2 Round Trips (Fraud Detection)

Current State:

SELECT COUNT(*) - Claim frequency check
SELECT COUNT(*) - Provider fraud score
SELECT COUNT(*) - Pattern detection
SELECT COUNT(*) - Similar claims analysis
(4 separate queries per claim)

Proposed Optimization:

-- Single query with subqueries or CTEs
WITH claim_stats AS (
    SELECT customer_number,
           COUNT(*) as claim_count_30d,
           COUNT(CASE WHEN similar conditions END) as pattern_count
    FROM claim_table
    WHERE ...
),
provider_stats AS (
    SELECT provider_code, fraud_score
    FROM provider_table
)
SELECT * FROM claim_stats JOIN provider_stats ...

Expected Impact: 50-70% reduction in claims processing time

2. Parallel Processing

Current: Single-threaded sequential

Proposed: Multi-threading or parallel job instances

Implementation Approach:

• Split input files by record ranges
• Process each range in separate job
• Merge output files

Expected Impact: Linear throughput improvement (2x jobs = 2x throughput)

3. Caching Strategy

4. Bulk Operations

Current: Individual INSERT/UPDATE statements

Proposed: Multi-row inserts where supported

DB2 Compatibility: Check DB2 version for multi-row INSERT support

Expected Impact: 15-25% reduction in commit overhead

5. Adaptive Commit Frequency

Current: Fixed 500 records

Proposed: Adaptive based on record complexity

Algorithm:

IF claims processing (complex):
    Commit every 250 records
ELSE IF policy processing (moderate):
    Commit every 500 records
ELSE IF renewal processing (simple):
    Commit every 1000 records

Expected Impact: Better balance of throughput vs. risk

Capacity Planning Guidelines

Volume Projections

Resource Requirements

Security Considerations

Data Security

Access Control

Data Protection

Encryption Status: No explicit encryption mentioned in code

Audit Trail Coverage

All database tables include comprehensive audit fields:

Additional Audit:

• Error log with timestamps (ERRFILE)
• Processing report with statistics (RPTFILE)
• Database AUDIT_TABLE for change tracking

Compliance Considerations

Regulatory Requirements

HIPAA (Health Insurance Portability and Accountability Act)

Critical Gap: No evidence of encryption for PHI (Protected Health Information)

SOX (Sarbanes-Oxley)

PCI DSS (Payment Card Industry - if applicable)

Data Retention and Purge

Current State:

• All records persist in database indefinitely
• No explicit purge/archive logic in code
• File retention policy not defined

Recommendations:

1. Define retention periods by data type
2. Implement automated archival process
3. Secure deletion procedures for expired data
4. Legal hold capabilities

Security Recommendations

Critical (Implement Immediately)

1. Encrypt Sensitive Data at Rest

   • SSN, medical data, diagnosis codes
   • DB2 native encryption or application-level encryption
   • Key management strategy required

2. Implement Data Masking

   • Mask SSN in logs and reports (show last 4 digits only)
   • Redact medical data from error logs
   • Sanitize console output

3. Enhanced Authentication

   • Role-based access control (RBAC)
   • Separate read/write privileges
   • Audit administrative access

Important (Plan and Implement)

4. Data Retention Policies

   • Define retention periods (e.g., 7 years for claims)
   • Automated archival to tape/cloud
   • Secure purge procedures

5. Enhanced Audit Logging

   • Include user context beyond program name
   • Log data access (SELECT operations)
   • Implement log integrity checks

6. Digital Signatures

   • Non-repudiation for critical transactions
   • Signed output files
   • Tamper detection

Recommended (Future Enhancement)

7. Network Security

   • Encrypt data in transit (DB2 SSL/TLS)
   • Secure file transfer protocols
   • VPN for remote access

8. Intrusion Detection

   • Monitor for unusual access patterns
   • Alert on bulk data exports
   • Fraud detection for system users

9. Disaster Recovery

   • Regular backups with encryption
   • Offsite backup storage
   • Documented recovery procedures

Security Architecture Diagram

Appendix: Technical Reference

Program Constants Reference

Return Code Reference

Database Operation Summary

Processing Mode Matrix

Critical Code Section Reference