2 IRIS and Your Business 5

IRIS Operating Procedures IRIS OPERATING PROCEDURES

CONTENTS

1 INTRODUCTION...... 4

2 IRIS AND YOUR BUSINESS...... 5

2.1 UNDERWRITING...... 5 2.2 INWARDS RISKS...... 5 2.3 OUTWARDS POLICIES...... 5 2.4 CLOSINGS...... 6 2.4.1 Bureau closings...... 6 2.4.2 Non-Bureau closings...... 6 2.5 CLAIMS...... 6 2.5.1 Bureau Claims...... 6 2.5.2 Non-Bureau Claims...... 7 2.6 SETTLEMENT AND ACCOUNTING...... 7 2.6.1 Bureau Settlements...... 8 2.6.2 Non-Bureau Settlements...... 8 2.7 MANAGEMENT REPORTING...... 8 2.8 PERIOD ROUTINES...... 8 3 JOB SCHEDULER...... 9

3.1 ACCESSING JOB SCHEDULER...... 9 3.2 JOB SCHEDULE DETAILS...... 11 3.2.1 Frequency...... 11 3.2.2 Schedule Date...... 11 3.2.3 Schedule Time...... 13 3.3 ADDITIONAL PARAMETERS...... 13 3.3.1 Omit Date...... 13 3.4 ADMINISTRATORS GUIDE...... 14 4 DAY END SUMMARY...... 15

4.1 SUGGESTED DAILY PROCEDURE...... 15 5 MONTH END SUMMARY...... 16 5.1.1 Suggested Monthly Procedure...... 16 6 YEAR END SUMMARY...... 18

6.1 SUGGESTED YEARLY PROCEDURE...... 18 7 BACK-UP PROCEDURE...... 20

7.1 DAILY...... 20 7.2 EVERY 4 - 8 WEEKS...... 20 7.3 HOUSEKEEPING ROUTINES...... 21 7.3.1 Update Rates of Exchange...... 21 7.3.2 Change Journal Receivers...... 21 7.3.3 Cleardown Bureau Status Files...... 21 7.3.4 Reorganise Files...... 21 7.3.5 Closings Log Rationalisation...... 21 7.3.6 Check IRIS File Sizes...... 22 7.3.7 Remove Released Zero Reserves...... 22 7.4 PROBLEM SOLVING...... 22 7.4.1 How do I know an error has occurred?...... 22 7.4.2 Audit reports...... 22 7.4.3 Statements...... 23 7.4.4 Reconciliation Reports...... 23 7.4.5 Cash Reconciliation...... 23 . Page 2 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

7.4.6 Statistics/Ledger Reconciliation...... 23 7.4.7 Reserves Reconciliation...... 24 7.4.8 Statistics/History Reconciliation...... 24 7.4.9 Trial Balance...... 24 7.4.10 Error Reports...... 24 7.4.11 Job logs...... 25 7.4.12 Job Status Screens...... 25 7.4.13 Accounts Update Status...... 25 7.4.14 Allocations Control...... 25 7.4.15 Restarts...... 26 8 APPENDIX A...... 27

8.1 ROUTINE JOB DESCRIPTIONS...... 27 8.1.1 Aged Debt List...... 27 8.1.2 Analysis Reports...... 27 8.1.3 Broker Statements...... 27 8.1.4 Cash Book...... 27 8.1.5 Cash Reconciliation...... 28 8.1.6 Cash Update...... 28 8.1.7 Change Flags...... 28 8.1.8 Closings Update...... 28 8.1.9 Diary Reports...... 29 8.1.10 Ledger List...... 29 8.1.11 Ledger Reorganisation...... 29 8.1.12 Outwards Broker Statements...... 29 8.1.13 Post Cash...... 29 8.1.14 Post Closings...... 30 8.1.15 Post Journals...... 30 8.1.16 Progression Statistics Enquiry...... 30 8.1.17 Progression Statistics Update...... 30 8.1.18 Reorganise Files...... 30 8.1.19 Reserves Reconciliation...... 30 8.1.20 Statistics/History Reconciliation...... 30 8.1.21 Statistics/Ledger Reconciliation...... 31 8.1.22 Trial Balance...... 31 8.1.23 Transfer Deferred Items...... 31 8.1.24 Unallocated Cash & Journals List...... 31 8.1.25 Update Accounts MM/YY...... 32 8.1.26 Update U/W Control MMYY...... 32 8.1.27 Year End Transfer...... 32 9 APPENDIX B...... 33

9.1 YEAR END TRANSFER PROCEDURES...... 33 Revenue account transfers...... 33 9.1.2 Nominal account transfers...... 35 10 APPENDIX C...... 36

. Page 3 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

1 Introduction

The procedures outlined in this manual are designed to help you in the day-to- day running of the IRIS system. The manual should be read and understood by management and departmental supervisors in order to give them a working overview of the system. The first section of the manual describes the way in which IRIS has been designed to best match your business. The next section lists the periodic jobs to be run daily, weekly and monthly. Appendix A holds a brief description of each of these jobs. Appendix B is a detailed description of the Year End Transfer function and describes the options available when running this routine. Appendix C holds flowcharts of the processes and movement of data through both the IRIS and the Insurance Accounts systems. Further details of all the processes described herein can be obtained from the IRIS user manuals. In addition, education courses are available in all areas of the system, as well as an overview course that gives a view of the system as a whole

2 IRIS and your Business

2.1 Underwriting When accepting business, whether new or renewal, it is important to have up- to-date information to assist you in the decision process. IRIS gives you such decision support tools and enables you to record risks, quotes, promises and declinatures directly on the database.

2.2 Inwards Risks When quoting for and accepting or declining business, IRIS allows you to record the basic details of the policy, including a unique policy reference, whilst the broker is still present. The following procedure is recommended: When the broker arrives with the slip, the underwriter checks if the business is of interest by accessing various enquiries such as the Company Involvement Enquiry, Aggregates Enquiry, Declinatures Enquiry and, for renewals, Policy History, Progression Stats and Claims enquiries. If the decision is to decline the risk, the underwriter should enter a declinature. This updates the database so that other underwriters are able to see the basic details and the reason for declining, should they be offered similar business. If a quote or promise is given, the details should be entered at this stage and a hard copy provided to the broker. If the quote or promise is subsequently taken up, the data can be transferred directly to the policy file. On deciding to write the business, the underwriter enters a skeleton policy. This registers the risk on the system and provides the broker with a unique policy reference. The skeleton consists of limited policy details that will form the basis for the risk. The actual level of data entered on a skeleton is, to a certain extent, controlled by the user. The amount of information the underwriter enters can vary from simply entering a line of text and allocating a risk number to registering of the full policy. The policy number can be entered manually or automatically generated. Entry of a skeleton is not mandatory, but it provides a fast and efficient way of registering the risk on the database for subsequent analysis. Typically a member of the Underwriting Administration department will subsequently enter the full risk details onto the system.

2.3 Outwards Policies Full outwards policy details for facultative and treaty protections should be recorded on the database as soon as possible after they have been set up. Included in the policy record is a detailed definition of the underlying participants. Outwards covers may be specifically attached to underlying inwards contracts. Standard outwards cessions can be attached to policies by the use of a standard reinsurance code.

IRIS is able automatically to calculate the cession of premium and claim amounts to specifically attached proportional outwards policies and will prompt the user to enter closings amounts for non-proportional protections. By using the enquiry and reporting subsystems, it is possible to check the progress of these policies at any time. The Outwards Statements module is capable of accumulating this information for subsequent production of statements to reinsurers. The analysis codes on the system can be used to identify where inwards contracts are protected by whole account policies. Reporting facilities are used to carry out aggregations of claims and identify recoveries that can be made. Transactions can then be processed directly against the outwards policy.

2.4 Closings Closings in IRIS can either be downloaded automatically from the LPC bureau or entered manually onto the database.

2.4.1 Bureau closings Closing transactions from the bureau are normally downloaded on a daily basis to IRIS. In the London market, data is downloaded via LIMNET on demand. Captured data is immediately decoded and directed to the relevant IRIS processing routines. This data is validated to ensure integrity. You are able to define, within certain limits, the amount of manual intervention required to complete processing. An on-line utility is used to amend transactions that contain errors, whilst those that meet the validation criteria are processed automatically.

2.4.2 Non-Bureau closings You should manually record transactions and claims information for risks not linked with the bureau, or that you specifically wish to enter by hand. Transactions and revenue types are all user-defined. Once transactions have been recorded on the closings log, the Closings Update routine should be run daily in order to update the statistics and history files. Subsequently the Post Closings routine posts the amounts to the ledgers.

2.5 Claims As with the closings it is possible to download claims advices directly from the LPC CLASS (ELASS) system or to enter the details of outstanding claims manually

2.5.1 Bureau Claims Loss advice transactions from LPC (LIRMA) should be downloaded daily from the network and processed by the IRIS ELASS system. As with the capture of closings, the claims data is downloaded via LIMNET. Captured data is immediately decoded and subjected to validation, as with closings. You are able to define, within certain limits, the volume of manual intervention required

to complete processing. An on-line utility is used to amend claims advices that contain errors. Loss advice messages that meet the validation criteria are processed automatically. First advices will, however, always require user intervention to convert the advice to an outstanding

2.5.2 Non-Bureau Claims Non bureau claims should be entered manually onto the system as they are received. Details of outstandings are set up and the progress of the claim monitored as with the bureau claims. Where significant claims exist on treaties normally settled on a periodic basis you are able to enter details using the claims memo facility. This records complete claims information, including paid and outstanding amounts and allows the details to appear in aggregations when calculating your outwards recoveries. In addition, outstanding claim reserves, as reported by the broker in the periodic statements, can be recorded on the system.

2.6 Settlement and accounting The IRIS Insurance Accounts module provides the brokers ledger function and has been designed specifically for insurance underwriting. It is a multi- currency system. All transactions processed record original and accounting currencies and can be converted to a system base currency. Upon allocation, the settlement currency and exchange rates are also recorded. Exchange differences are calculated on all conversions and figures may be revalued at year end. The Insurance Accounts module provides on-line account enquiry and on- demand or period end reporting functions. Reports produced include Broker Statements, Aged Debt, Ledger Lists and Trial Balance. These reports, supplemented by the IRIS Report Generator, Underwriting Analysis Reports and the Enquiries module, will provide the necessary data for the efficient running of the accounts department. The frequency of running the reports is optional and dependent on your business needs. Recommendations as to those reports that should be run on a regular basis are in Section 4 and 5 of this document. The Post Closings routine, which posts insurance transactions from the underwriting modules to the accounts, should be run daily as an overnight job, since it requires a dedicated system. Centrally settled bureau insurance items are posted to weekly settlement accounts, which are reconciled when settlements are received. Non-bureau insurance items are posted to the source and revenue accounts defined during closings input. Once entered, cash and journal items should be immediately posted to the ledger by running their respective posting routines. A powerful pre-allocation facility, with multiple transaction sort orders, assists in the cash allocation process. The individual tracking of participants on an outwards reinsurance is possible. It is also possible to identify and flag companies considered as potential bad debt risks. For these companies, their share of the outwards transaction is split from the main transaction and administered separately. If a company that had . Page 7 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

previously been considered ‘sound’ becomes a bad debt risk, retrospective unblocking of their unallocated transactions is possible. The system also has a partial allocation function, which allows the splitting of a participant’s share from the insurance transaction in the case of late payment.

2.6.1 Bureau Settlements Bureau items are automatically posted to the correct weekly settlement account on the IRIS ledger. The balance in the current weekly account due for settlement is reconciled against the control totals provided by the bureaux. When the cash has been received, it is entered and posted to the appropriate weekly settlement account. Whole account allocation is possible, allocating the cash items against the insurance items.

2.6.2 Non-Bureau Settlements Comprehensive routines exist for the manual entry of cash amounts and their reconciliation within the system.

2.7 Management reporting The system has an extensive range of reports, including Business Analysis, Claims Analysis and Progression Statistics available on demand from various menu options. The ability to direct output to local or central printers means that prints will appear when and where they are required. The vast majority of reports allow a high degree of specification of both the level of detail and scope of the output. Recommendations as to the frequency with which these reports should be run are given in Section 4 and 5 of this document. For period end processing, separate menus can be set up to automatically produce reports thereby minimising manual intervention. A powerful and flexible report generator facility, the IBM Query utility, is available with the AS/400. This is a menu driven file access utility enabling access to all IRIS file definitions. It is especially useful in the production of audit trails and ad hoc reports and is capable of satisfying quite complex reporting requirements. The on-line enquiries allow access to summary or detail information. The definition of the analysis codes plays a key role in the summarisation process.

2.8 Period Routines This section of the manual deals with the routines that should be run on a daily, monthly, and yearly basis. The list is meant as a means for establishing the best procedure for your company. At Appendix A is a brief description of all the procedures in alphabetical order. For more details of how the procedures work, consult your user manuals. NB: In the list of routines, menu names are referred to from the jobs that are to be run. Since users are able to design their own menus in IRIS, discrepancies may occur with menu names.

3 Job Scheduler

If you run jobs on a regular basis, i.e. daily or monthly, then these can be scheduled using the Job Scheduler. This allows the same job to be run at regular intervals without user intervention.

3.1 Accessing Job Scheduler Job scheduler can be accessed after requesting a job at the Select Submit Options screen as displayed below:

 Select F22 and the following screen is displayed:

 Type in the Schedule Job Name and Description as required. If this Job Name is replacing an existing name, then type a 'Y' in the Replace Entry field.  Press F6 and the following screen is displayed:

3.2 Job Schedule Details

3.2.1 Frequency Navigate to the Frequency Field.  Enter the frequency that you require the job generated. The option available are: - '*weekly', for weekly jobs - '*monthly' for monthly jobs - '*once' for a one off job. Note: The *asterisk before the frequency type is essential.  If the job is required daily or for a particular day of the week, then enter '*weekly' in the Frequency Field  Navigate to 'Schedule Day + for more values' field  Type '+' in the field  Press Enter. The following screen is displayed:

 Type in the first three letters of the required day, with an asterisk before the day, e.g. *mon, *thu etc.  Press Enter.

3.2.2 Schedule Date If the job is required to run at a particular time of the month, then:  Navigate to the 'Frequency ' field

 Type '*monthly'.  Navigate to 'Schedule Date' field and enter the required date.  Your options are either: - '*Current', which will use the current date - '*Monthstr', which will use the first day of the month - '*monthend', which will use the last day of the month - enter the day of the month required i.e. 150600 (ddmmyy). Note: The date format is depends on your AS400 system settings.  Press Enter Note: This will need to altered each month.  If the job is required on the first Monday of the month, then type - '*monthly' in the 'Frequency' field - '*monthstr' in the 'Schedule Date' field - '*mon' in the 'Schedule Day' field. Other options are other days of the week written as the first three letters of that day.  the following screen is displayed:

 Navigate to the 'Relative Day of Month' field and type '1'. Other options are either '*Last' for the last day of the month or enter a relevant number i.e. 1 for first, 2 for second etc.  Press Enter

3.2.3 Schedule Time It is recommended that the jobs are scheduled to run outside of normal business hours and not while other jobs are running on the AS400 such as back up etc. To schedule a time:  Navigate to the 'Schedule Time' field  Enter the time required, e.g. 0300 for 3am. It is also possible to enter the time in hours, minutes and seconds and would be entered as hhmmss, e.g. 033015 for 3.30am and 15 seconds.  Press Enter

3.3 Additional parameters

Extra parameters can be added by pressing F10. The following screen is presented:

3.3.1 Omit Date To omit certain dates, such as Christmas Day and other public holidays, the Omit Date function is used.  Navigate to the 'Omit Date' field  Type the date required in a ddmmyy format, i.e. 251200 Note: The date format is depends on your AS400 system settings.  To add more dates, navigate to the 'Omit Date + for more values' field  Press Enter and the following screen is displayed:

 Enter dates required  Press Enter Note: The date must altered each year.

3.4 Administrators Guide

It is recommended that the last four fields on this screen, that is Job queue, Library, Message queue and Library, are not altered and remain as default settings. If you need to alter these fields, please contact the Helpdesk or your Account Manager at the Rebus Group.

The Job scheduler screens are IBM screens and therefore are not Rebus controlled. You may need to contact IBM if you are experiencing problems with these screens.

In order to use this functionality, you need *CHANGE authority to object QDFTJOBSCD type *JOBSCD, and *USE authority to objects ADDJOBSCDE and CHGJOBSCDE type *CMD. You need to use the EDTOBJAUT or the GRTOBJAUT commend to grant authority to these objects.

4 Day End Summary

The daily routines can be run at any time of the day, with the exception of the post closings routine, which requires a dedicated system (i.e. no-one else must be using the system whilst it is running). The main daily file updates are performed as below: Closings Update, which adds closings entered during the day to the statistics and other files. Post Closings, which posts the transactions to the ledger to update the brokers and revenue accounts. Post Cash that adds cash transactions entered during the day to the ledger Post Journals that adds journals entered during the day to the ledger. Cash Update that updates the statistics and other risk records to reflect the allocations of cash and closings that have occurred during the day. The purpose of running the reconciliation and trial balance reports is to ensure that the file updates have been correctly processed. Further explanation of all routines is given later in this manual as well as in the User Manuals supplied with the system.

4.1 Suggested Daily Procedure Procedure Menu Note Daily Data file backups and journal change. Closings Update CLOSIN Post Cash INCASC Post Journals INCASJ Post Closings CLOSIN Cash Update CLOSIN Statistics/Ledger Reconciliation CLOSIN L Statistics/History Reconciliation CLOSIN L Trial Balance INCASR Cash Reconciliation CLOSIN L Reserves Reconciliation CLOSIN L

Notes:- W = Could be included in weekly procedure L = Visually check that report reconciles

5 Month End Summary

The month end routine consists of printing various analysis and audit reports before running the ledger reorganisation to update the accounts. Some reports are included in the list as a guideline rather than an essential element and can therefore be excluded if not required. The daily jobs should be run and a complete backup taken before commencing the month end routine. The Insurance Accounts control date (month/year) is updated automatically if the Ledger Reorganisation is run. However the control dates in the underwriting system need to be manually updated separately. This is done in the Company Control section of the Housekeeping routines. Usually this would be done at the same time as the Insurance Accounts month end, however, it is possible that the accounting department are not ready to close off the month when the U/W department are wanting to process closings for the next month. In such a case, the control dates on the U/W system can be updated and closings entered. NB Control dates are defined per accepting company per underwriting type hence there are 4 per accepting company.

5.1.1 Suggested Monthly Procedure Procedure Menu Compulsory? Note Closings Update CLOSIN Y D Post Cash INCASC Y D Post Journals INCASJ Y D Post Closings CLOSIN Y D Cash Update CLOSIN Y Trial Balance INCASM Y DL Cash Reconciliation INCASM Y DL Analysis Reports REPORT N Diary Reports DIARY N Aged Debt List INCASM N Cash Book INCASM N Unallocated Cash/Journal List INCASM N Statements (Broker) INCASM N Statistics/Ledger Reconciliation CLOSIN Y L Statistics/History Reconciliation CLOSIN Y L Reserves Reconciliation CLOSIN Y L Transfer Deferred Items INCASX Y

Change report flags (if applicable) INCASC Y Ledger Reorganisation INCASX N T Trial Balance INCASM N C/L Cash Reconciliation INCASM N C/L Ledger List INCASM N Update U/W Control MMYY HOUSEK Y A Update Accounts Control MMYY INCASC Y B Progression Statistics Update CLOSIN N Run Outwards Statements STATEM (if period end)

Notes: - C = Compulsory if Ledger reorganisation run L = Visual check report reconciles T = Reorganisation will not run if TB does not balance A = Check control dates are correct, if not update B = Control date is automatically incremented if the ledger reorganisation has been run. Check control date. D = As part of daily routines

6 Year End Summary

The year end routine will include the Year End Transfer routine prior to the Reorganisation routine of the Month End Routine. Note: - Year End procedures are run instead of the December Month End.

6.1 Suggested Yearly Procedure Procedure Menu Compulsory Note Back up all system files Y Closings Update CLOSIN Y D Post Cash INCASC Y D Post Journals INCASJ Y D Post Closings CLOSIN Y D Cash Update CLOSIN Y Trial Balance INCASM Y DL Cash Reconciliation INCASM Y DL Analysis Reports REPORT N Diary Reports DIARY N Aged Debt List INCASM N Cash Book INCASM N Unallocated Cash/Journal List INCASM Y Statements (Broker) INCASM N Statistics/Ledger Reconciliation CLOSIN Y L Statistics/History Reconciliation CLOSIN Y L Reserves Reconciliation CLOSIN Y L Transfer Deferred Items INCASX Y Ledger List INCASM Y Year End Transfer INCASX Y Trial Balance INCASM Y L Change report flags (if applicable) INCASC Y Ledger Reorganisation INCASX Y T Trial Balance INCASM Y L Cash Reconciliation INCASM Y L Ledger List INCASM N Update U/W Control MMYY HOUSEK Y A

Update Accounts Control MMYY INCASC Y B Progression Statistics Update REPORT N Run Outwards Statements STATEM N Notes: - L = Visual check report reconciles T = Reorganisation will not run if TB does not balance A = Check control dates are correct, if not update D = As part of daily routines B = Control date is automatically incremented if the ledger reorganisation has been run. Check control date.

7 Back-Up Procedure

All major files are journalled and this will have been started during installation. They should be backed-up on a regular basis depending on machine usage and corporate disaster recovery procedure. The following is the recommended backup routine. NB: Library names may vary by customer.

7.1 Daily A daily backup (SAVLIB, SAVCHGOBJ) of all data files is recommended Libraries to be updated are: XUNMDTA Underwriting data library XUNMDTT Underwriting test library XUNMDTR Underwriting training library XUDIDTA DTI data library XUDIDTT DTI test library XUDIDTR DTI training library XXOSDTA Outwards statements data library XXOSDTT Outwards statements test library XXOSDTR Outwards statements training library

7.2 Every 4 - 8 weeks A complete SAVSYS can be run monthly and should be run after loading PTFs. In addition a SAVLIB (*NONSYS) and SAVDLO should be run monthly, though this will take some time depending on the size of your system. Remember that these routines require a dedicated system and are best run on weekends when sufficient time is available. Libraries to be backed up are: XUNMSYS Underwriting system library XUNMSRC Underwriting source library XUNMDTA Underwriting data library XUNMDTT Underwriting test library XUNMDTR Underwriting training library XUDISYS DTI system library XUDISRC DTI source library XUDIDTA DTI data library XUDIDTT DTI test library XUDIDTR DTI training library XXOSSYS Outwards statements system library . Page 20 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

XXOSSRC Outwards statements source library XXOSDTA Outwards statements data library XXOSDTT Outwards statements test library XXOSDTR Outwards statements training library Finally the physical files should be reorganised.

7.3 Housekeeping Routines The following routines should also be run on a regular basis.

7.3.1 Update Rates of Exchange. This is carried out in the INCAS codes module. Before amending the rates of exchange on the file, you should go to the Copy Exchange Rates function in order to save the current exchange rates with a meaningful name. This will allow you to use these rates in the subsequent running of reports and queries.

7.3.2 Change Journal Receivers. The journals in IRIS monitor the updates carried out to the files and will allow you to restore your files in the event of a major system failure. Journals do, however, use up disk space and should be changed and backed up at regular intervals, generally weekly. You should run the Change Journal Receivers routine from the System Environment menu, then back up the previous journal to tape. NB: If Post Closings fails for any reason, details will appear on the restart screen on the closings menu. If this occurs, on no account should you change your journal receivers until the problem is put right. Failure to observe this may cause major data corruptions.

7.3.3 Cleardown Bureau Status Files. The journal status files in LIRMA, ELASS and ILU hold information on the bureau members processed. Clearing down this file is carried out from the various bureau menus. Not only is the status file cleared down, but also the corresponding bureau records in the associated member, so that quite a lot of disk space is subsequently freed.

7.3.4 Reorganise Files. Reorganising your files allows you to “tidy up” the disk space used by the file and recover space freed by the deletion of records. It is initiated from the System Environment menu and should be run on a weekly or monthly basis.

7.3.5 Closings Log Rationalisation. The Closings Log Rationalisation process is used to tidy up files that may contain unwanted records. Such records can be created if the user takes F3/F12 escape functions during Closings Input. It is initiated from the Closings menu and should be run monthly or quarterly. Do not attempt to run Closings Log Rationalisation whilst Closings Input is in progress.

7.3.6 Check IRIS File Sizes. This function is run from the System Environment menu and produces a report showing files more than 70% full. It should be run regularly to monitor any files that are getting too large.

7.3.7 Remove Released Zero Reserves. This program removes reserves records from the system once they have been reduced to zero. If it is not run, then the zero records will continue to be displayed on the reserves screen. It is initiated from the System Environment menu and should be run whenever zero reserve records become a problem.

7.4 Problem Solving Generally the day-to-day running of the system should produce few errors. When errors are encountered they are often caused by minor problems such as codes being incorrectly defined. Some errors are, however, potentially more damaging. Any loss of power to the machine, or serious hardware failure should be followed by a thorough check of your system data, particularly if a batch update job was in progress at the time.

7.4.1 How do I know an error has occurred? IRIS has a number of functions that help us to recognise that an error has occurred. As well as the familiar on-screen error and warning messages, the following are also available: Audit reports Reconciliation reports Error reports Job logs Job status screens Restarts System dumps

7.4.2 Audit reports A number of the standard update routines produce audit reports showing, amongst other information, transactions that failed to process correctly. These include: Closings Update Post Closings Post Cash Journal Update Bureau functions Allocations DTI Return functions . Page 22 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

7.4.3 Statements In each case, where an error has occurred, this will show clearly on the report. These errors must be investigated as soon as possible, in case data has been damaged.

7.4.4 Reconciliation Reports The various reconciliation reports are provided as a check on the integrity of your data and should be run on a regular basis. The following is a guide to the main reconciliation reports and what the errors may mean.

7.4.5 Cash Reconciliation This program reconciles the values on the ledger files to those on the allocations history records. These are both updated by the allocations routine. If the files fail to reconcile it will usually be because the allocations run has not yet been run, or has not yet finished. 1. Allocations routine not complete. When you allocate cash, the ledger files are updated immediately on completion of the run. In order to update the history files, however, a batch job is automatically submitted. If, at the time of running the reconciliation, the update has yet to run, has been removed from the job queue, or has started but not yet completed, the files will not reconcile. Check the Allocations Control screen. If the job has not yet run, or is running but not yet complete, you must wait until it has completed, then re-run the reconcile. If the job has been removed, wait until you next use the allocations function, at which time the job will be resubmitted. 2. Data Error The only other possible cause of the files failing to reconcile will be if an error has occurred with the data. In this case you must have the fault investigated immediately.

7.4.6 Statistics/Ledger Reconciliation This report reconciles the amounts on the statistics files with those on the ledger. There may be a number of reasons for this failing to balance, the most probable of which are: 1. Post Closings Not Run There are two stages in posting data to the ledgers, Closings Update sets up the records on the statistics file and creates a file for posting to the ledger. Post Closings subsequently posts the amounts to the ledger files. If you have run Closings Update but not yet run Post Closings, your ledger and statistics files will not reconcile. Run the Post Closings routine before re-running the reconciliation. 2. Data Error

If, having run Post Closings, the files still do not reconcile, there is an error in your data, and you must have this investigated immediately.

7.4.7 Reserves Reconciliation. This report reconciles the reserve amounts entered at the closings stage (“Shadow” reserves) with those shown on the statistics files. There are two possible causes of the report failing to reconcile: 1. Closings Update not run When you enter closings data for reserves online, you initially create “Shadow” records. At this stage the summary file will show two figures “Shadow” and “Updated”. It is necessary to run Closings Update in order to update the reserves on the statistics files and complete the routine. Thus, if you run the Reserves Reconciliation prior to Closings Update, the files will not reconcile. Run Closings Update, then re-run the Reserves Reconciliation. 2. Data Error If, having run the Reserves Reconciliation, the files still fails to reconcile, you may have a data error. You must have this investigated immediately.

7.4.8 Statistics/History Reconciliation The statistics and history files are both updated together at the time of running Closings Update or during a statements data extract. Any discrepancy found when running this report, therefore, may be due to a data error and should be investigated immediately.

7.4.9 Trial Balance The Trial Balance is a check to see that all your ledger accounts balance to zero. There are a number of possible reasons why the report may not show a balance: 1. Allocations are pending on the job queue (see Cash Reconciliation) 2. Some other update routine, such as Post Cash, is running. Any other failure to balance indicates a data error and should be investigated at once.

7.4.10 Error Reports When a serious error occurs and a job fails for some reason, an error report will be automatically generated. An example of one of these is shown.

The report shows the following: a. The job name b. The identity of the user who submitted the job c The job number

d The name of the routine e A message to the effect that the job has aborted f A list of messages sent by the job since it started running If you receive such a report it is essential that you pass it on to your system supervisor at once so that any remedial action can be taken.

7.4.11 Job logs Whilst you are running jobs on the system, you are able to set the machine so that it is constantly logging all activity. When a serious error occurs, a message is transmitted to your screen giving the basic details. You are then able to investigate the problem by viewing the job log.

7.4.12 Job Status Screens For certain functions, where updates to files are carried out by batch jobs, status screens are provided to allow you to monitor the progress of such jobs after they have been submitted.

7.4.13 Accounts Update Status This screen shows both Closings Update and Post Closings jobs submitted to the system but not yet completed. The status field can have three values: JOBQ means that the job has been submitted to the job queue but has not yet run. Normally the job will run as soon as the system has the resources. However, if it remains on the queue for an excessive time you should contact your system supervisor. ACTIVE means that the job is currently running. RESTART means that the job has failed for some reason. You must determine why this happened before attempting to re-run the job. You have two options from this screen. Entering ‘4’ next to the job will remove it from the screen. You are then able to re-run the job from scratch. This option cannot be used with jobs that are ACTIVE or have spool files still awaiting printing. Entering ‘7’ next to the job will resubmit it in its original form. The option will only work for RESTART jobs. Ensure that you know why the job failed in the first place before using this option.

7.4.14 Allocations Control This screen shows you the status of allocations jobs that have been submitted. When you complete the allocations routine, the system automatically submits a batch job to the system that updates the ledger files. Until this job has completed, you are unable to enter the allocations routine, though users with a different sign-on are still able to allocate The current status of each job is shown on the screen, along with the program and user names and the workstation number.

7.4.15 Restarts During certain processes, the system has a built-in function to prevent data corruption if an error occurs. The AS/400 has a journalling system designed to cope with major hardware failures or power cuts. In addition to this the restart function provides you with a means of highlighting where data may have been lost during an operation on a specific policy so that you can be sure of what has and has not been safely recorded. It is important that journal receivers are not changed if an error of any description has been detected as a number of the restart routines use them. The restart facility is available in a number of routines including: Policy Input Claims Input Closings Input Cash Update Bureau Online Edit Change Policy Status Change Commutation Status Statement Runs When you enter the routine, the system checks that no previous errors have occurred. If it finds any the details of the affected data are displayed. The record remains locked until released by running the restart routine. It is likely that data changes made at the time of the failure will be lost.

8 Appendix A

8.1 Routine Job Descriptions The following is a brief description of the function and relevance of the routines listed in the previous section.

8.1.1 Aged Debt List This report shows the unallocated cash/journal balance, the underwriting transactions balance analysed by age and the overall balance of each open item account. The report is split by Company and Accounting currency. The Operator is able to change the ageing periods at run time. This report is not essential to the audit trail but may be useful to the Accounting or Underwriting departments. If you do not wish to run it, you must remember to change the flag in the Control file from 0 to 1. This flag is accessed in the control file function on the Housekeeping menu.

8.1.2 Analysis Reports These are all to be found on the Reports menu and should be run on an as required basis. Because of their complex nature and the variations available at run time, it is not possible to precisely define which reports should be run at this stage. See the IRIS Reports Manual for further details

8.1.3 Broker Statements The Broker Statements show, for each broker, the unallocated transactions on the account. When the Broker Statements job is run, the operator can select to just print underwriting transactions, i.e. exclude Cash/Journal transactions, and can print active items only, cleared items only, or both active and cleared, and also exclude flagged items. See the Insurance Accounts User Manual for more information on this. These statements can be printed on pre-printed stationery. If not run, remember to change the flag in the Control file.

8.1.4 Cash Book This report, printed by bank account in the currency of the bank account, lists the postings made to the bank account during the past month. When running the report it is possible to request the reports for combined companies (i.e. if the same bank account is used for more than one company on the system), or print the reports for each company individually. The receipts and payments columns are formatted in a similar way to the statement received from the bank. This is designed to make bank reconciliation easier. Each payment is individually listed in the payments column, whilst receipt totals are batched together, as on the paying-in slip. Items that have already been reconciled with the Bank Statements are flagged. This report should be run at month end to provide a listing of receipts/payments to reconcile with the statement received from the bank. If you do not wish to

run it, you must remember to change the flag in the Control file from 0 to 1. This flag is accessed in the control file function on the Housekeeping menu.

8.1.5 Cash Reconciliation This report lists, for each account and accounting currency, all cash and journals input and allocations made since the last reorganisation was run. This report is of interest to the auditors and should always be run at month end. The system also does a check that the accounts are in order and if this is not the case an error listing will be printed showing the accounts in error.

8.1.6 Cash Update This routine updates the statistics and history files with the details of payments made against underwriting transactions in the Insurance Accounts module (date paid, paid balance, paid exchange rate, etc). This allows paid as well as closed amounts to appear on the underwriting reports and enquiries. A report showing statistics records that have been updated is produced, as well as an error report listing any records that have not been found on the statistics file. This job should be run daily.

8.1.7 Change Flags The Reorganisation job checks that all month end reports have been run and will not run if any have not. If, therefore, you have chosen not to run any of the jobs, the Update INCAS Control option should be taken to change the flags of the unprinted reports. Unprinted reports will have a value of 0. This must be changed to 1 in order for the reorganisation to run. Flags are held for the Ledger List, Statements, Aged Debt and Cash Book.

8.1.8 Closings Update When the batch of transactions has been accepted, the Closings Update routine is run to send the information to the statistics files and create the ledger file to be posted into the INCAS accounts module. Prior to update, options are available to delete, reinstate or add further transactions. After update, the information is available for both statistical and accounting analysis via enquiries or reports. Instalments can be retained on the closings log and automatically posted when due, or posted to a deferred account in INCAS and posted on to the relevant account by means of a program in the month end routine. Instalments held back on the closings log are brought forward by selecting the option from the Closings update menu. It is possible to control the updates by use of an authorisation function that will prevent transactions being processed unless they have been authorised. This is optional. Audit control is available in the form of daybook listings, the extent of which can be defined at run time. If deferred items are being held on the closings log, the option to transfer them should be taken at month end. . Page 28 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

8.1.9 Diary Reports The diary reports in IRIS are run against a number of dates set up on policies, claims etc. They are used to generate reminders, e.g. of renewals due, reviews of policies and claims etc. See the IRIS Diary Reports manual for further details.

8.1.10 Ledger List This report provides a listing of all transactions within an account, and can be used for planning allocations. The sequence numbers on the report are the same as those that will appear on the screen when performing allocations. It is, however, important that if this report is to be used for planning allocations, it is run after the Reorganise Ledger job since that will resequence the transactions. If it is not run, remember to change the flag on the Control file. At year end it is sensible to print the Ledger List prior to reorganisation and Year End Transfer so that the transactions appear in the appropriate year end account on the listing (for audit purposes).

8.1.11 Ledger Reorganisation This job does two main operations: - Removes cleared items (allocated open item entries and/or entries in balance forward accounts which are included in the balance forward total). - Updates the B/F balances of those B/F accounts which are cleared down to one transaction (B/F accounts can be cleared down monthly or at year end). The job will only be allowed to be run if the ledger balances to zero and relevant reports have been run. At the end of the routine it will increase the INCAS reporting month by 1 month.

8.1.12 Outwards Broker Statements The Outwards Statements system allows statements of accounts to reinsurers to be produced periodically for any outwards policy, at a level of detail defined by the user. This should be the standard processing for Outwards Proportional Treaties within IRIS. All closings to Outwards policies that have been set up for processing by the Statements system are held on the Closings Log until the system is run.

8.1.13 Post Cash The Cash Input function sets up a series of transaction records. In order for these to appear on the ledger files, the Post Cash routine must be run. This can be run at any time, and does not require a dedicated system. It is possible to control the cash posting routine using the Authorise function. All batches entered but not posted will be displayed for authorisation. This is, however, optional and is controlled by data area ILKKRZA0.

8.1.14 Post Closings This routine takes the ledger entries (broker and revenue transactions) from the Closings Transaction file and adds them to the INCAS ledger file. This job requires a dedicated system, i.e. no-one may use the on-line system at the time of running the post closings routine. The job first checks that the transactions for each company account currency and month/year balance to zero and that each account referenced is an active account. If this is not the case, an error listing is produced, the job is cancelled, and intervention is required (e.g. to set up the missing accounts) before rerunning the job. A report is printed listing each transaction that is added to the ledger.

8.1.15 Post Journals As with cash, once journals have been set up on the system, they must be posted to the accounts using the Post Journals routine. Authorisation can be used to control this depending on the value of data area ILJARZA0.

8.1.16 Progression Statistics Enquiry The progression stats enquiry in IRIS allows you to view on line the progress of a policy. For each underwriting year, the progression of premiums and claims over the 6 years after the policy first incepted can be presented. The figure shown for the sixth year will also include any amounts that occurred more than 6 years after inception.

8.1.17 Progression Statistics Update In order to make use of the progression statistics enquiry within IRIS, it is necessary that the Update Progression Statistics routine is run from the closings menu on a regular basis. Until this has been run, the progression stats information will not be up-to-date.

8.1.18 Reorganise Files This is a tidying up exercise to clear out any deleted records from files, thereby freeing unused disk space. The files to be reorganised are those which have large number of deleted records in them, e.g. closings logs, posting files, account terms.

8.1.19 Reserves Reconciliation This report shows any differences between the shadow and updated figures on the reserves files. When entering reserves the shadow figure is updated on line. The data figure is subsequently adjusted by Closings Update.

8.1.20 Statistics/History Reconciliation Two reports are produced when this job is run. One is the Statistics to History reconciliation report which details any inconsistencies on the history file compared to the statistics files. The other report is the History to Statistics reconciliation report that lists any records on the history file for which either no

statistics records exist or for which the amounts in the history record do not match those on the statistics.

8.1.21 Statistics/Ledger Reconciliation This routine checks that the revenue figures in the ledger are the same as the revenue figures in the Statistics file on the Underwriting System. This is an essential control function because the statistics are used as an extension of the accounts as well as to produce statements to reinsurers, and to form the basis for many reports. The operator is asked when the last Reorganisation/Balance Forward process was run - i.e. when were the revenue figures last cleared down to a B/F total. This is either at year end or monthly, depending on how your accounts are set up. The system will only look at the entries added to the ledger since the last B/F figure and likewise, will only look at the records in the Statistics since the specified reporting month/year. The report printed shows the revenue figures in each accounting currency with a Sterling equivalent. If the figures on the ledger are not the same as those on the statistics file, an error is printed which should be investigated. There is also an option to reconcile the Statistics and History files.

8.1.22 Trial Balance This report is a listing of account balances in each accounting currency ordered by company, ledger and account. The company totals should balance to zero and if this is not the case a warning report is printed and investigation is urgently required. This report is of interest to the auditors and should always be run at month end. It is also a good check that all is in order in the ledger.

8.1.23 Transfer Deferred Items This function will transfer items from deferred sub-accounts to current sub- accounts for all items that become due next month. This routine is only applicable for those users who post the deferred instalments to the Ledger. Some users choose to hold the instalments transactions on the closings log and do not release them to the Statistics or accounts files until they are due. A listing of transactions moved from deferred to current accounts will be printed, if applicable. If transactions cannot be moved, (e.g. if the new account does not exist), an error listing will be printed so that corrections can be made prior to the next month end.

8.1.24 Unallocated Cash & Journals List This report lists the unallocated cash and journal items in date order by open item account within ledger. It can be used to plan which accounts need to be worked on most urgently. It is not essential to the audit trail and therefore does not have to be run at month end. If not run you must remember to change the flag in the Control file.

8.1.25 Update Accounts MM/YY This is found on the accounts codes menu, Maintain INCAS Control. The processing date is at the top of the screen and is shown in the format MMYY.

8.1.26 Update U/W Control MMYY As part of the month and year end routines, the Underwriting System’s control record should be updated with the new reporting month/year so that it is the same as the control month/year in the INCAS system. It is possible, however, that the U/W system date has already been manually changed to the new reporting period because closings for the new period have already been entered.

8.1.27 Year End Transfer This function is run at year end. It will transfer the balance on each Revenue account to the required fund account for that year or roll back the amounts within the sub accounts as appropriate. Any nominal accounts set up on the codes file to be transferred to fund will have their balance transferred to the appropriate nominal fund account. Fund account reorganisation is also processed by this routine.

Appendix B explains the function of the year end transfer in greater detail.

9 Appendix B

9.1 Year End Transfer Procedures This appendix describes the way in which the IRIS system handles the accounts at year end to assist you in configuring the codes to best suit your business. NB The year end transfers should be run BEFORE the month end run at the end of the financial year. This is because the month end reorganisation brings forward balances for balance forward type accounts and dates the balances 1/1 of the following year. The program will subsequently ignore these items, assuming them to be next year's figures. The Year End Transfer is designed to journal the balances from the revenue accounts to the specified fund accounts automatically. Each revenue account is flagged when set up to say whether the balance is to be transferred at year end. This is done in the Revenue Accounts Details function in the Insurance Accounts codes module. If the flag is set to “N” the items in this sub account are rolled back to the sub account for the next year. There are two steps to the transfers: - Transfer of revenue account balances - Transfer of nominal account balances

9.1.1 Revenue account transfers For each company on the IRIS Insurance Accounts module, the “Financial Year End” field on the company code file is checked. If the month is the same as the current processing month, the transfers are performed.

A typical Revenue Accounts setup might look like the screens above The system holds information as to the number of accounting years being used for each underwriting type (and branch if required), and which sub account of the revenue account corresponds to each underwriting year (1, 2, 3, 4 etc). The number of sub accounts defined is the number of accounting years plus one, as a forward year sub account is kept open. The fund accounts to which the various balances are posted are defined in the “Fund Account” option on the codes menu. A typical screen is shown above. The function is accessed using the company, revenue ledger, underwriting type, and branch, (optional) with one set of data being set up for inwards, and another for outwards. For each sub account a year is shown, beside which the fund account code can be entered. When you run the year end, the following occurs: For all sub accounts EXCEPT the year to close sub account: If transfer to fund = ‘Y’ The total for each currency in each sub account as at year end is calculated, and that amount is journaled out of the revenue account and into the fund account defined for that specific company, underwriting type and (optionally) branch. If transfer to fund = ‘N’ If the balance is not to be transferred to fund, it must be ‘rolled back’ a year, so that if the current year sub account is defined as 2, the transactions in that sub account are moved to sub account 3, the previous year. A journal is written between the two sub accounts for the balance as at year end. Items dated past the year end date are left as they were. For the year to close sub account: If transfer to fund = ‘Y’

If the item has in its description ‘19xx’ where xx is a year, the transfer routine will attempt to transfer the balance to the appropriate fund account for this year. If not the items are transferred to the default defined. If transfer to fund = ‘N’ The items are left in the closed year sub account, thus this account contains items for all past years beyond the number of open years.

9.1.2 Nominal account transfers Nominal accounts to be transferred to fund are defined in a separate codes function, the screen for which is shown above. The balances of these accounts are transferred to the fund account nominated. They can be transferred in 3 ways: - By account, in which case one journal is written between the account and the fund account for each account. - By Sub Account, in which case one journal is written between the sub account and the fund account for each sub account. - By ledger, in which case one journal entry is written to each account, and a journal is written to the fund account for the total of all the accounts on this ledger. The fund account file also contains a transfer currency. Balances are converted to this currency when journalled into the fund account, the balancing entries for this conversion being written to the year end currency transfer account.

10 Appendix C

See attached for IRIS flowcharts:

1. IRIS System Flowchart

2. Ledger System Flowchart

3. Outwards Processing

IRIS System Flowchart

Quotes & Promises Input Skeleton Input Policy Files

Declinatures

Policy Input Closings Closings Input Closings Update Log

Skeleton Quotes & LPC Lloyds O/S Claims Promises Entry CLASS/ Lloyds Ledger Stats Trans- actions

Claims Memos

Auto Claims Auto Trans Claims Closings Online Edit Post ClosingsOnline Edit Cash Update

Closings Allocations Allocations Log Ledger Log

Closings Update STATS

Cash Input Journal Input

INCAS O/W Ledgers Statements

IRIS Ledger System Flowchart . Page 37 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc IRIS OPERATING PROCEDURES

IRIS Outwards Processing

MAIN STATS FILES PARTICIPANT STATS

FAC/XSL Specific Participant I/W Gross Immediate R/I Stats Part.Split

Post to Stats Accumulate

Accumulated Separate Separate Adjustments Auto Adjust Postings PostingsSeparate PostingsSeparate Postings Postings

O/W Statements

Manual Adjust

INCAS SYSTEM Finished Statements File

. Statements Statements Statements Statements Page 38 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc

OUTWARD STATEMENTS SYSTEM IRIS OPERATING PROCEDURES

. Page 39 of 39 D:\Docs\2018-04-21\0b4f793ed0919fddee062353834e15aa.doc