3000107457- Risk Code Entry (Functional Specification)

3000107457- Risk Code Entry (Functional Specification)

IRIS User Group Development

IRIS-ENH

Risk Code Entry

IUG-0983, SN-300107457

Current Location & Status

File Location / Q:\Lmd\Development\300107457-Risk Code Entry-IUG\02 Specification\IUG-300107457-Risk Code Entry-Functional.01.doc
Document Owner / Xchanging Global Insurance Solutions Limited
Status / Agreed by XGIS

Authorised by

Name / Authorising Role / Date / Signature
Alan Chisham / Development Project Manager / 17/05/07 / Signed copy on file
Daryl Yeats / Project Manager / 23/05/07 / e-mail in folder
Mick Hobbs / Director / 24/05/07 / e-mail in folder
John Colwell / Financial Director / 24/05/07 / e-mail in folder
IRIS User Group / Client

Prepared by: Ashima Sardana

Project ManagerAlan Chisham

Office:34 Leadenhall Street

London EC3A 1AX

Issue Date:25th May 2007

© Xchanging Global Insurance Systems Ltd. 2007

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of Xchanging Global Insurance Systems Limited (Xchanging).

This document contains information which is confidential and of value to Xchanging. It may be used only for the agreed purpose for which it has been provided. Written consent is required before any part is reproduced.

Trademark Information

Company, product, or brand names mentioned in this document, may be the trademarks of their owners.

Document Control

Revision History

Version / Description/Reason for Change / Date
Draft01a / Functional Specifications / 04/04/2007
Draft01b / Incorporated Review Comments / 03/05/2007
01 / Incorporated Review Comments / 14/05/2007

Circulation List

Name / Business Area / For Review / For Sign-off / Agreement to proceed
Alan Chisham / Development Project Manager / X / X / X
Daryl Yeats / IS / X / X
Mick Hobbs / IS / X / X / X
John Colwell / IS / X / X / X
IRIS User Group / Client / X / X / X

Document Purpose

This document is the Functional Specification for the IUG development300107457-Risk Code Entry in IRIS in IRIS-ENH[1].It has been compiled in accordance with the Xchanging XPERT package Implementation Methodology.

Contents Page

1Introduction

1.1Background to Requirement

1.1.1Summary

1.1.2Business Requirement Definition

1.1.3Business Justification

1.2Business Requirement

1.2.1Requirements

1.3Scope

1.3.1Outside Scope

1.4Assumptions and Limitations

1.5Impact Analysis and Implementation

2Summary of Functional Changes

2.1Business and Functional Requirements Matrix

3Detailed Functional Specifications

3.1Capturing new Risk Code Criteria (FS01)

3.2Enhance Business Customisation to define client rules for System Reference Files (FS02)

3.3Enhance Business Customisation for Client Code Configuration (FS03)

3.4Risk Code Split validation (FS04)

3.5Underwriting Signing Message Validation (FS06)

3.6Define rule in Business Customisation to ignore the Product level code validation for a code type (FS05)

4Example Setups

4.1Abacus Configuration

4.2Limit Configuration

4.3LSML Configuration

4.4Novae Configuration

5Acceptance Criteria

5.1Test Plan

6Costs

7Appendix

7.1Database Additions/Changes

7.1.1New File

1Introduction

1.1Background to Requirement

The IUG has requested an enhancement – specifically for Lloyd’s insurers - to ‘Control Entry of Risk Codes’ within the IRIS Policy Input application. The Entry of Risk codes on a policy should be validated against a list of appropriate Risk codes for a business Unit. This is intended to allow Syndicates to monitor their performance against the business plan submitted to Lloyd’s.

The original wording of the requirement as submitted by the IRIS User Group was as follows:

1.1.1Summary

Entry of Risk codes on a policy should be validated against a list of appropriate risk codes for a Business Unit.

1.1.2Business Requirement Definition

When entering a policy there should be validation such that Lloyd’s Risk codes can only be entered when the code is valid for the Business Unit and Year of Account, as defined within the business plan which was submitted to Lloyd’s.

There is already a file in IRIS called “Risk Code Validation X-Ref” (UCRCREP) that stores a list of valid values for Syndicate, Year of Account, Unit and Risk code. This file should be used when validating the Risk code on a policy so that the entered value must be compatible for that combination of Syndicate, Year of Account and Unit.

A method is required to allow the configuration of a system rule that can be set to limit the period over which this validation is to take place, based on the Year of Account. This is because validation data may not be present for old years. E.g. at Novae the UCRCREP file only contains data for Years of Account of 2002 and onwards, therefore the validation should not be enforced for Risk codes on policies with a Year of Account of 2001 or prior.

The other constraint that must be considered:

Customer Configurations: The relevant database fields are held on the Syndicate Line, but are not populated in all customer configurations of IRIS. Where they are not currently populated, it will be necessary to enable the fields or map them through configuration. The distribution of the relevant fields across different customers is as follows:

Client / Syndicate / Year of Account / Unit / Risk Code
Abacus / SYZMCD / SYZMYR / N/A / POPC01
Limit / SYZMCD / POUGYR / N/A / POPC04
AXRSCD (many per risk)
LSML / POZMCD / From POICDT / N/A / POPC04
Novae / SYZMCD / POYOAC / SYUNCD / SYRS01
Illium Liability / None / POYOAC / None / None

1.1.3Business Justification

Risk codes for business units are advised to Lloyd’s each year within a Syndicate’s business plan. If IRIS prevented incorrect Risk codes being entered on policies then there would be no need to run exception reports to find the erroneous policies.

1.2Business Requirement

The detailed business requirements document is available at

Q:\lmd\Development\300107457-Risk Code Entry-IUG\01 Business Requirements\IUG-300107457-Risk Code Entry-Requirements.02.doc

1.2.1Requirements

There are four main business requirements as follows:

BR1) The client will determine whether this new Risk code validation is required, and the types of policy to which it will apply. The client may specify a starting Year of Account, before which the validation will not apply.

BR2) The client will specify valid combinations of: Syndicate, Year of Account, Business Unit and Risk code. Any number of Risk codes can be entered for each combination of Syndicate/Year of Account/Business Unit.

BR3) Within Policy Input, the Risk code – on the Policy, the Syndicate Line or the Risk Code Split table - will be validated against the list of valid combinations.

BR4) This enhancement will not prevent Syndicates entering any ‘dummy’ Risk Code Splits[2] that are needed to accept USM transactions.

1.3Scope

This enhancement will allow Risk codes to be validated against a table of Syndicate/Year of Account/Unit code/Risk codes. The Risk code to be validated may be on the Syndicate Line, on configured code fields and on the Risk Code Split function.

1.3.1OutsideScope

Only the IRIS GUI programs will be enhanced. There will be no program updates to any IRIS character-based system programs or reports.

1.4Assumptions and Limitations

The enhancement will not allow validation by analysis codes (e.g. Class of Business code or Branch code), other than Unit code.

No changes to IRIS Reports and Enquiries will be made to implement product level code lookup. Code lookup functionality will continue to work as currently within reports and enquiries.

The enhancement will be implemented such that the administrator will be able to set up the Mandatory and/or Default rules for all the fields in System Reference files from Business Customisation. Other rule types – Constraint, List Constraint, Field Change Actions, Expression Field, Conditional Rule Group, Copy Actions will not be supported for reference files.

1.5Impact Analysis and Implementation

The new Risk Code validation criteriawill be stored in a separate file -Risk Code Validation (UCAVREP), hence there will be no impact on the reports and functions using the Risk/Audit code file (UCAXREP).

The enhancement will be implemented such that the administratorswill be able to customize the input/output criteria for validating acode type field.There will be no impact on the customers using different fields for the same purpose, thereby allowing customersto utilise this functionality for whichever field they use for risk codes.

The administrator will be given the functionality to specify valid combinations of: Syndicate, Year of Account, Business Unit and Risk code. It will not affect the customers not using the Syndicates or any other criteria which is not applicable in their case, as all these validation fields can be left blank.

After this enhancement, the new risk code validation will be controlled via business customization rulesat product level. Using rules set up in business customisation it will be possible to allow the new validation to only be applied to rules after a certain year enabling older policies to be left unaffected.

2Summary of Functional Changes

There are six functional changes that are required as listed below:

FS01)Allow administrators to define the additionalcriteria - Syndicate, Year of Account and Business Unit to validate a Risk Code within Policy Input, Syndicates and Risk Code Split ancillary, through System Reference File Maintenance.

FS02)IRIS Business Customisation is to be modified so that it allows the administrators to define their own business rules for code tables in Reference File Maintenance.
Since different clients will have different requirements as to whether the new validation criteria fields are mandatory or not when setting up new Risk Codes via System Reference File Maintenance. Using this new functionality the administrator can configure System Reference File rules within Business Customisation.

FS03)IRIS Business Customisation is to be modified to allow the administrators to define fields as code controlled and also configure applicable code-criteria, how it is to be applied and from where the data is sourced.

Thus the administrators will have the options:

a)To mapafieldto an existing code type defined in the system. This code configuration can be done for each product.

b)To define the applicable code criteria – input and output, for that code field.

FS04)The Audit RiskCodes entered within the Risk Code Splits ancillary, Policy Input and Syndicates is to be validated against the new criteria.

FS05)A new script rule – “AllowProductCodeValidation” is to be added in Business Customisation which will allow the administrators to disable the validation criteria being applied to the risk code field at the product code level. As a result old policies will not be impacted upon setting up a Year Limit on the rule, thereby allowing the additional validation to only be applied to policies after a specified year.

FS06)A rule to be added in Business Customisation,such that depending on whether thesplit percentage enterediszero or not, then execute the new script function - “AllowProductCodeValidation” to enable or disable the new product level code validation.
This will allow the users to enter dummy (0%) splits for any missing Risk Codes in the table, in order to provide data for the USM to match against and accept the closing without being prevented from doing so as a result of the risk code technically being defined as invalid for that policy..

2.1Business and Functional Requirements Matrix

The following matrix shows the relationships between the business and functional requirements listed.

Business Requirements
BR1 / BR2 / BR3 / BR4
Functional Requirements / FS01 / 
FS02 / 
FS03 / 
FS04 / 
FS05 / 
FS06 / 

3Detailed Functional Specifications

3.1Capturing new Risk Code Criteria (FS01)

Currently, Risk Codes in IRIS are stored in Audit/Risk Codes file (i.e. UCAXREP). All the Risk Codes that are entered on a Policy, Risk Code Split ancillary and Policy/Claim Syndicates are referenced from this table.

The requirement is to validate the Risk Code entered within Policy Input, Risk Code Split function and Syndicate Line against the valid combination of:

• Syndicate
• Year of Account
• Business Unit.

For this purpose,

1. A new file UCAVREP named as “Risk Code Validation” file will be created, which will hold theadditional validation criteria that will be applicable to a Risk Code.

1. The Risk Code Validation file (UCAVREP) will store the following fields:

i)Risk Code (AVAXCD) – Based on RiskCode (AXAXCD) entered on the Risk Code file UCAXREP.

ii)Syndicate (AVZMCD) – Based on Syndicate Code (ZMCD)

iii)Year of Account (AVYOAC)

iv)Business Unit (AVUNCD) – Based on Unit Code type (UNUNCD)

1. All the risk codes that are required will be maintained in the existing Audit/Risk Code file (UCAXREP) i.e. Audit/Risk Code file (UCAXREP) will store the unique risk codes.

1. For each risk code, the administrator will be allowed to enter the extra data for the purpose of validation in Risk Code Validation File (UCAVREP). Any number of Risk Codes can be entered for each combination of Syndicate/Year of Account/Business Unit.

1. The new Risk Code Validation file will be maintained from System Reference File Maintenance.
   Currently under the Underwriting tree, the Audit/Risk Code file is listed. Below the Audit/Risk Code (UCAXREP) (Figure 1on page 11), the Risk Code Validation file (UCAVREP) link will also be provided allowing the administrator to define additional validations applicable to a given risk code. The Validation file(UCAVREP) will be defined as a child file for the Audit/Risk Code file (UCAXREP), so that the user can also define validations by selecting a Risk Code in the Audit/Risk Code file (UCAXREP) and from the context menu selecting the Risk Code validation file (UCAVREP).

Figure 1

On editing the Risk Code Validation File (UCAVREP), the IRIS will be enhanced to enter the Risk Code criteria (Figure 2).

Figure 2

The administrator will be able to select the Risk Codes that were entered on the Audit/Risk Code file and can add Syndicate/Year of Account/Business Unit data.

Since the Risk Code Validation file (UCAVREP) will be a child to the Audit/Risk Code file (UCAXREP), validation details can be added from the Audit/Risk Code file as shown in the below screen shot (Figure 3).

Figure 3

In addition to adding the validation criteria, a new feature will be given in IRIS to configure the mandatory fields on the Risk Code criteria screen. Using this functionality, the administrator will be able to set up the mandatory constraint not just for Risk Code Criteria, but for all the reference files available in the system. Please refer tosection3.2on page 13for more details on this.

3.2Enhance Business Customisation to define client rules for System Reference Files (FS02)

The distribution of the relevant fields across different customers is as follows:

Client / Syndicate / Year of Account / Unit / Risk Code
Abacus / SYZMCD / SYZMYR / N/A / POPC01
Limit / SYZMCD / POUGYR / N/A / POPC04
AXRSCD (many per risk)
LSML / POZMCD / From POICDT / N/A / POPC04
Novae / SYZMCD / POYOAC / SYUNCD / SYRS01
Illium Liability / None / POYOAC / None / None

For Example- Unit Code is not applicable to validate the risk code in case of Abacus. So while entering the validation criteria, Unit Code should not be a compulsory requirement.

For this purpose, the IRIS functionality will be enhanced to allow the administrators to define their own client configuration.

From Business Customisation, administrators will be allowed to create their own rules for System Reference Files as shown below (Figure 4):

Figure 4

This new function will list all the System Reference Files that are currently available in the system. The administrator will then be able to set up the Mandatory and Default rules for all the fields in System Reference files. Other rule types – Constraint, List Constraint, Field Change Actions, Expression Field, Conditional Rule Group, Copy Actions will not be supported for reference files.

This limitation on which rule types can be applied will be controlled via the meta-data level so that the option to make other rule types available on reference files will be available in the future should such an additional requirement be raised in the future.

This will be similar to choosing a product code from the product codes list in Business Customisation.

For each reference file, the administratorwill be able to add a rule on any existing field in that reference file in IRIS. These rules will be defined and applied at the system/reference file level.

Using Business Customisation, Abacus wouldadd a mandatory rule on the Syndicate and Year of Account fields for the Risk Code Validation Reference file (UCAVREP). Then when Risk Code Criteria is entered using System Reference File Maintenance, the Business Unit will not be a necessary option,but Syndicate and Accounting Year will be.

3.3Enhance Business Customisation for Client Code Configuration (FS03)

At the moment, different clients have configured different fields to store the same kind of data that are relevant to them.

e.g. Abacus uses SYZMYR for Year of Account,whereas Limit has defined POUGYR for accounting year.

Currently in IRIS, theadministrator cannot define which field is dependant on what code type. Neither is it possible to configure additional criteria that are applicable to the Code-type.

Similar functionality has recently been introduced into Business Items to allow clients to define fields as code controlled and also configure applicable code-criteria.That is how it is to be applied and from where the data is sourced. As was previously done specifically just for the business items, the IRIS system will now be enhanced to allow administrators to configure the code definitions at a product level (sample screens are given below).

These screens will be made available within the Product configuration section of Business Customisation and accessed via the “Properties” button of a field.

I).Below is the ‘Field Properties’ screen (Figure 5) from within Business Customisation, where the administrator can define the Code Type (“Reference”) that a field is to be validated against at the product level.