NOVUS Walkthrough Guide
Table of Contents
- 1 1. Introduction to NOVUS
- 1.1 1.1 Starting NOVUS – Login process
- 1.2 1.2 Basic Concepts
- 1.3 1.3 NOVUS
- 1.4 1.4 NOVUS Compatibility
- 2 2. Front End Risk Processing
- 2.1 2.1 Creating Risks
- 2.1.1 2.1.1 Basic Concepts
- 2.1.2 2.1.2 Opening an existing risk
- 2.1.3 2.1.3 Subjectivities
- 2.1.4 2.1.4 Quote to Risk Policy workflow
- 2.1.5 2.1.5 New Quotes (Indications)
- 2.1.6 2.1.6 Querying Risks and Quotes
- 2.1.7 2.1.7 Creating a Quote
- 2.1.8 2.1.8 Direct Quotation
- 2.1.9 2.1.9 Reinsurance Quotation Log
- 2.1.10 2.1.10 Placing a Quotation
- 2.1.11 2.1.11 Covert Quote to Policy/Risk
- 2.1.12 2.1.12 To Convert a Quotation into a Policy
- 2.2 2.2 Setting up Risks
- 2.3 2.3 New Risk
- 2.4 2.4 Renewals
- 2.5 2.5 Risk Record Maintenance
- 2.6 2.6 Policy Compliance
- 2.7 2.7 Automated processing through the Core Data Record (CDR)
- 2.1 2.1 Creating Risks
- 3 3. Documentation
- 3.1 3.1 Documents Preview Panel
- 3.2 3.2 Market screen
- 3.3 3.3 Transaction screen
- 4 4. Claims and Transactions
- 4.1 4.1 Codes used in the claims system
- 4.2 4.2 Claims Processing
- 4.2.1 4.2.1 The Claims Menu
- 4.2.2 4.2.2 Setting up Limits
- 4.2.3 4.2.3 Entering a Claim
- 4.2.4 4.2.4 Claim Status
- 4.2.5 4.2.5 Claim Acknowledgement
- 4.2.6 4.2.6 Claim Summary Sheets
- 4.2.7 4.2.7 Provisional Claim Advice
- 4.2.8 4.2.8 Posting to the Ledger
- 4.2.9 4.2.9 Post to IBA or Process Direct Payment
- 4.2.10 4.2.10 CP13 (Pending)
- 4.2.11 4.2.11 Closings LCCF etc.
- 4.2.12 4.2.12 Post Direct to IBA or Process Direct Payment
- 4.2.13 4.2.13 Posting the Transaction
- 4.2.14 4.2.14 Claim Enquiry
- 4.2.15 4.2.15 Claim Status
- 4.2.16 4.2.16 Reinstatements
- 4.2.17 4.2.17 Earned to Incurred’s (E2I) reports
- 4.3 4.3 Transactions
- 4.4 4.4 LPANs & Closing Instructions
- 5 5. Ancillary Tools and Applications
- 6 6. Bordereau Management
- 7 7. Cash Management & Bookkeeping
- 8 8. Nominal Ledger
- 9 9. Administration
- 9.1 9.1 Program Codes
- 9.2 9.2 New Partners
- 9.3 9.3 Currency Management
- 9.4 9.4 Adding a year to the Calendar
- 9.5 9.5 Bank Accounts
- 9.6 9.6 User Management
- 9.7 9.7 Themes and Skins
- 9.8 9.8 Send Logs
- 9.9 9.9 Outlook Integration
- 9.10 9.10 No Database Connection
- 9.11 9.11 Check for default printer
1. Introduction to NOVUS
NOVUS as an application provides rich functionality for intermediaries in the London and international insurance market. It gives quick access to policies, transactions, claims, and reports, as well as integrates directly with the online user guide. Features such as 'recent tasks' and the global system search functionality allow easy access to information.
The system has been purpose-built with the broker, underwriting agency or insurance company in mind capable of scaling from a couple of users to multi-user sites of several hundred staff. Rather than taking a legacy financial package and bending it to suit a specific market, NOVUS was conceived as a full business solution for the insurance market. From the bottom up all the modules have evolved as a member of the whole product, yet still allowing companies with specific needs to pick and choose the modules most useful to their needs.
A reinsurance broker may select reinsurance module, nominal ledger, proportional treaties, WP and claims together with IBA (insurance broking account) whereas a direct broker may choose the direct, WP, schemes, claims, and internet feed modules.
Companies with mixed interests have the flexibility to add more modules as they require. Oracle is a secure, stable database solution for companies of all sizes, and since Oracle has expressed significant interest in Redhat Linux it has become one of its strategic developing platforms. This now offers an Intel-based solution for small to medium-sized organisations.
This document will give you a basic overview of the main screens, briefly describing the main points of the system. For further detailed information, each program can be found in the online user guide on the Morning Data support site.
See the underwriting page on this wiki for a list of pages related to underwriting functions.
1.1 Starting NOVUS – Login process
From a bookmark, IP address, or shortcut provided, the browser will invoke the remote desktop protocol (RDP) access dialogue box.
Log on to the system using your login credentials; depending on the applications you have been granted access to, the screen may display a range of different icons. Select the NOVUS icon and select the program.
Re-type your password to access the application; there are two standard datasets available (live and test) - select the required icon.
The first time a user logs into the system, the dashboard will show a helpful guide on how to use the dashboard and helpful hints on how to move around the system.
1.2 Basic Concepts
In both the NOVUS and HELIX programs, the parties with whom business is conducted are called partners. There is only one occurrence of a PARTNER listed in the partner table and a list of one or more roles that the partner can engage in business with the system. All entities of any kind in NOVUS are referred to as partners, with their roles of ‘*’(asterisk),’.’(full stop/period), ‘-‘(dash), or NULL.
These roles are:
- Client – the party paying the debit note - Carrier – the receiver of premium or the payer of claims - TPA/Agent – either a co-broker, silent agent or TPA (third-party agent) - Insured – the original insured/assured/policyholder
For convenience, on reports where space is tight, and to remove ambiguity where letters of the alphabet are used to denote a role, these roles are denoted with symbols in the system.
- Client is an asterisk * - Carrier is a dot . - TPA/silent agent is a dash - - Insured [NULL]
The system upholds the principles of double-entry bookkeeping (debits & credits where a client is a debtor and a carrier is a creditor when referring to premium, and the reverse when referring to return premiums or claims). The cashbook expects payments made by clients for the premium to be listed as a credit to their account and hence a positive amount; when reviewing any ledger item thereafter the amount would appear as a negative, as a liability as far as the ledger is concerned.
In addition to the direct roles, there are up to seven positions in the policy chain of the contract of insurance that these parties can nominate:
- The policyholder or original assured - The risk client - The market client(s) - The carrier(s) – insurers, reinsurers or placing brokers - The carrier blocking bureaux or intermediaries - Co-broker or TPA (third-party agent) - The operator of the system (broker/MGA (managing general agent)/cover holder/insurer)
NOVUS and HELIX are both able to handle insurance and reinsurance risk. Both have a dedicated module to handle proportional treaties and the support for parent/child contracts such as binders with their attached off policies, lineslips, and their attached declarations, and facilities with their placed policies.
These placed policies can be placed across multiple master facilities (binders) and open market lines. In all cases, each section of a risk has the potential for different configurations.
The insurance market is renowned for its language and use of terms, and the reuse of terms which mean different things depending on what part of the insurance chain the user is in.
NOVUS and HELIX have a recognised terminology dictionary: however, Morning Data acknowledges that some terms may be subtly different from those used by the reader.
Here follows a list, although not exhaustive, of the most common terms and their definitions found throughout this document:
|Audit Trail||All activity in NOVUS is auditable, all key markets provide automatic audit trails to print or save to file.|
|Binder||A global term for a master insurance policy. Originally, the relationship between the master and other policies was the binder and off-policy arrangement. In this relationship, the master contains the only copy of the market structure, preventing any changes to client discount, order or carrier participation percentages.|
|Bordereau(x)||An accounting tool, comprising rows and columns of data that are attributed to the existence of a transaction, on an account|
|Business class||Each risk has a business class, and each master contract has a primary class and further classes for risks to be attached to. This code allows for a different grouping to that of the policy type. Whilst not directly linked, there may be a requirement to split risks and associated transactions.|
|Can||The system can do this now. This may require a system feature to be enabled or disabled, or a new module may be required for specific functionality.|
|Cancellation codes||This is a list of the reasons that a quote is NTU (‘not taken up’)/not converted into a policy. There is also a cancellation/reinstatement option on some of the NTU codes. This is relevant for the RISKEND program where, if a policy was quoted then the reason for cancellation is visible.
The reserved QU (quotation) code is recommended for all pre firm orders, yet to be accepted risks in the live quotation stage. The code (along with the added firm order date and transaction processed) must be removed from the risk before being deemed to be live, accepted, and in force.
|Carrier||Usually an insurer or reinsurer, but equally the business case may require placing a part or all of a risk with a carrier but through a placing broker. This can be achieved either with a blocking bureau or using the placing broker as the carrier on the market. Denoted as a full stop (period) in the system ('.')|
|Claims bordereau(x)||A transaction report containing one row per transaction per claim in the name of the carrier partner. It contains specific collection criteria such as that for a facility. All previously unreported claims transaction data will be returned in a claims booked bordereau and not reported again. All transactions that have outstanding unsettled values will be returned in a claims paid bordereau.|
|Clauses||NOVUS holds a list of codes and titles of clauses, conditions, exclusions, endorsements and wordings in its CLAUSE program. These are controlled by policy type. The verbose wording of each must be inserted into the master_conditions.doc document with a bookmark around the element that corresponds with the code in the NOVUS list. Setting the clauses as default for a specific policy type will mean all policies of that type will have these default clauses included; additional clauses can be added for specific policies.|
|Client||In the system this is the partner that will pay the premium or additional premium and receive the return premium, This may be an MGA (managing general agent), cover holder, agent broker or the policyholder depending on whether the risk is wholesale or direct, and it may be an insurance company in the case of reinsurance. Denoted as an asterisk in the system (*)|
|Coding held in escrow||Clients can instruct that a copy is placed into escrow on a 6 monthly basis by arrangement with Morning Data. Morning Data has an escrow license with NCC.|
|Consultancy||Time spent with a domain expert. Used for advice, and one to one training, including specific considered advice on how to use the system in the context of addressing a task or action.|
|Contract certainty||A selection of codes to determine what the status of the contract certainty is, as denoted and defined by the FCA (financial conduct authority)|
|Could||It might be possible, with development work, to make the system perform the required task or outcome.|
|Cover note/MRC||The COV program - evidence of cover – which was previously referred to as a cover note. This program contains a front page, inserts the final slip, and adds the market breakdown, signature pages and tail information. This action contributes to the contract certainty exception reporting.|
|Declaration||A declaration is a term used to define a policy attached to a binder. When the binder is set up as a lineslip it behaves in its structure like a lineslip|
|Development||Includes business analysis, documenting requirements, and functional specifications, and coordinating with developers and testers who then implement the change to the software.|
|Direct||Insurance that is placed with an insurer direct and not through an intermediary.|
|Division||Each risk or master contract can have one division. Divisions represent a subset of risks and contracts across the ledger allowing companies to group, at the most basic level, their activities. This includes all associated transactions to those risks, and the ability to assign partners and users to one or more divisions.
NB: cash is divisionalised.
|Document management system||An integrated document management system (DMS) of created or uploaded documents, or full DMS provided by a 3rd party for scanning, indexing, and full enterprise management.
Changes to software due to market initiatives are undertaken automatically and included in the service package.
|Exposure reports||A list of all live, or all risks, on a facility at the location level. It is used to assist carriers with the current exposure of the book of business. This is not a bordereau as it is not an accounting tool.|
|Facility||Within the system a facility behaves like another type of master insurance policy. In this instance policies that attach to the facility may be shared across one or more facility and open market.
It does not prevent a policy from attaching (via the market structure) to only one facility (which must have one or more of the sections the policy wishes to place into), but it affords the underwriter the option to make more complex capacity provisions
|Function Keys||Function keys in NOVUS are used as shortcuts for navigating and processing the forms programs. See the function keys page on this wiki for a list of appropriate keys.|
|Hosting and backups included||Fees for the hosted solution include nightly backup and 10GB of storage space. Additional space and backup options are available.|
|IBA ledger||Insurance broking account (IBA) ledger. The approach of a symmetrical ledger supports multiple methods of accounting with parties on different arrangements who play different roles on different contracts. This works equally for insurance and brokering or intermediary accounting.|
|Included in the fees||Service includes 24x7 user support 8:30 am-5:30 pm UK office hours, or at any other time by arrangement|
|Integrated accounting function||A set of workflows that include automated document generation. Documents are sent from within the system.|
|Lineslip||Within the system a lineslip is a master insurance policy that will share its market structure with its solely attached declarations. The copy of the market is taken by the declaration. Although no new participants can join the market, participation, order, percentage, brokerage, and client discount can be altered on each declaration. Only relevant sections on the master can be utilised by the declarations, but the declaration does not have to utilise all sections.|
|Location deductible basis||The basis on which the deductible is applied; uses ACORD (Association for Cooperative Operations Research and Development) standard options as supported by ER3001 and Lloyd’s premium bordereau(x) reporting standards. A risk item may have its deductibles, and these have a basis on which the amount is expressed/calculated:
Each and every loss
Percentage unit value
Per cent of TIV
|Market||The market set up within the system lists all parties involved in the financial arrangements of the contract. This can be client(s), ceding brokers, retail brokers, and cover holders. insurers, carriers, or co-brokers. It represents the matrix that represents the contractual basis of the agreement defining the written and signed lines, the order percentage (%), and the commissions received by any client or provided by any carrier.|
|Master||There are four types of master contracts taking their names from the most common (but not exclusive) way they tend to work. Please note that a software package may require behaviour patterns that do not entirely correspond with the business use of the word. These contracts are:
• Wholesale binder
The use of a master contract (lineslip binder) allows the user to configure the contractual terms of the delegated authority. Within the markets tab of the risk screen, the user will need to enter the 100% signed line of Lloyd’s syndicate recording that the syndicate is to bear 100% of the risk, be paid 100% of the premium less any commissions and pay 100% of the claims less any excesses or deductibles.
The master contract is created in NOVUS. The single scope of the master contract in terms of country code, location code, business class, division, policy type, state of filing, and others are defined in the master contract set-up. However, if additional territories, currencies, policy types, business classes, country codes, state of filing, etc. are permissible under the terms of the master contract (The scope or additional currencies, territories etc. is specified in the master so that declarations are tested to only fall within the permitted list of each. These are added using the BSCOPE program.
As the attaching risk details are added, their equivalent codes are checked against the BSCOPE program lists and offer users the restrictions accordingly.
Additionally, the policy type code serves two further controlling roles. It allows for the system to be configured with default groups of clauses (warranties, exclusions, conditions, subjectivities, etc) and it controls the offering of permitted templates to the users in the quote production and pro forma schedule PROFSCHED production programs.
|Modes||Controls in the system detail how the risk will be handled. These controls include the masters and other modes:
• L - Lineslip
• F - Facility
• W - Wholesale Binder
• P - Proportional Treaty
• N - Non-Proportional Treaty
• R - Facultative Reinsurance
• O - Open Market/Other
|Partner||NOVUS regards all entities in the contract to be called PARTNERS. These have roles, such as clients, carriers, original assured/policyholders, TPAs, and co-brokers. Each has an IBA (insurance broking account) code with the permitted roles attributed.|
|Peril code||Codes referring to hazards and events that are a source of loss or damage|
|Policy||In NOVUS this is normally referred to as a risk – see risk. The POLISSUE program behaves like the COV program, but inserts the PROFSCHED document and appends any clauses to it.|
|Policy types||This set of codes allows the system to tailor the selection of pre-firm order document templates and the choice of risk level data screens (see risk details). Each risk has one policy type, each master contract has one primary type and further types with which attaching risks can be created. Policy types indicate the exact type of policy that is being detailed. The policy type is not directly linked to the section type and NOVUS provides complete flexibility to mix and match sections under a policy type. However, if the policy is a declaration off a lineslip or in-house binder, then the available policy type(s) and section type(s) are pre-listed for selection.
The policy types control the selection of the pre-firm order templates (slips, schedules or quotes). This can be the same list as a class of business but doesn’t have to be if a long list of template variants is required. Policy types also control the choice of risk level data (risk details) screens.
|Premium bordereau(x)||A one row per section transaction report in the name of the carrier partner for the specific collection criteria such as for a specific facility.
All previously unreported transactions will be returned in a prem booked bordereau and will not be reported again. All transactions that have outstanding unsettled values will be returned for a prem paid bordereau.
|Processing Groups||There are 7 types of processing groups available in NOVUS:
• F - Facultative Reinsurance
• P - Direct Personal Lines
• Q - Quota Share
• R - Stop Loss (XL Ratio)
• S - Surplus
• X - Excess of Loss
|Pro forma schedule||A pre firm order document, similar to a SLIP that takes data from the system and merges it with a template from the templates folder which is controlled by policy type. This document is inserted into the dummy policy document.|
|Program||Within the system there are several programs. these are task-based elements of the system, and are referred to by Morning Data by using capitalisation such as RISKNEW, TRANPT, WHO, and PARTNER. using these shortcuts in the shortcut field on the system desktop will fire that program ready for use. Programs are subject to both permissions utilizing a program group and an authorisation level, mapped to a user's setting. For example, if the program TRANPT is in group "A" and authorisation level 6 (set in the TITLE) program) all users with level 6 or above and have group A in their groups' list (set in the WHO program) will be able to access the program.|
|Query grids||The system allows for information, previously potentially supplied by a report to be provided via the query screens. The resulting screens can be sorted by the query, filtered, and grouped. The output can be downloaded to an Excel spreadsheet.
The columns can be sorted by which columns are to be displayed including additional columns, not in the default view. The layout can be saved as a view per user to suit requirements.
|Quota share||A reinsurance treaty which provides that the reassured shall cede to the reinsurer a specified percentage of all the premiums that it receives in respect of a given section or all of its underwriting accounts for a given period in return for which the reinsurer is obliged to pay the same percentage of any claims and specified expenses arising on the reinsured account.|
|Quote||A record in the database that carries a quote number – not a policy/risk/UMR number.|
|Quote doc||As per slip and pro forma schedules, these are pre firm order documents based on templates situated in the templates folders|
|Quote number||A record in the database that carries a quote number – not a policy/risk/UMR (unique market reference) number.|
|Release||Software release. NOVUS is updated every 8 weeks or so with a new software release. Releases will be deployed automatically and are part of the agreement with the client. Enhancements etc. all form part of these releases.|
|Report Generation||The ability to generate standard reports on income and outgoings by client, facility, policy, specific bordereaux, broker/producer, department, business and type. These reports are available in the REPGEN program|
|REPGEN reports||A library of reports requested by clients to their specifications. Morning Data does not warrant these but make the library available for use in the context of their output. Clients can buy these from the library after confirming the reports meet their needs.|
|Risk||NOVUS regards these terms as interchangeable as records in the system: risk/policy/contract/master. A risk record represents a contract of insurance. This could be a proportional treaty, a declaration on a lineslip, an off-policy on a binder, a placed policy on a facility, or a standalone policy. Equally the master contracts themselves are also ‘risks’ within NOVUS, NOVUS handles 4 different kinds of master contracts.
Using the lineslip, all insured’s policies will be referred to as declarations, and set up using the RISKNEW program.
The master contract details, - The slip should be created or added to the NOVUS master contract record, and the market expressed in the MART program. An FDO (for document purposes only) transaction must be processed in NOVUS to 'lock' the master contract data. Mid-term changes are created using the endorsement route. Any changes to the policy can be processed using the internal endorsement process to change the data (the post firm order will be locked and this process unlocks the record) if the change needs to be notified to the carrier then the ENDORSE program provides the document (templated) to present the carrier for sign off.
|Risk bordereau(x)||Provides additional breakdown using the same criteria to return the records– i.e. due to a transaction within the collection criteria. A risk bordereau will return the data at one row per location per section level.|
|Risk details||The system is generic to class except for collecting risk level data (RLD). A templated structure is available for several classes where data has been identified to relate to locations, depots, insured address, harbour, branch etc.
Several classes have been created within the system. Further classes can be discussed for development if not already covered, or existing screens can be modified if additional data is required by clients.
Below the risk, the system can hold risk level data in a repeatable templated format. These are designed largely in line with a concept of a class of business and are the only part of the system that is not class agnostic. Screens have data fields that are appropriate to that class for example in motor and MTC types it will ask for vehicle details, whereas in forestry it will ask for data connected to a plantation. Each class denotes one or more insurable interests, for example, a property, and at that property one or more insurable items that are covered by the sections on that risk. This forms the schedule of risks.
It is possible for one or more insurable interests to have one or more insurable items covered by relevant sections for example:
Risk # P12345/2019 has 3 sections: MD – Material damage
BI – Business interruption
TR – Terrorism
Each has one risk code and one market configuration, commissions and order %. The risk covered 2 properties; locations A and B.
MDBU – Buildings
MDCO – Contents
BIBI – Business interruption
TRTR – Terrorism
MDBU – Buildings
BIBI – Business interruption
TRTR – Terrorism
Once risk items are deployed as part of a risk the premium must be handled at this level when dealing with MTA’s (mid-term adjustment) and each MTA must have a transaction of some kind including a zero value transaction in the event of no premium change. If no risk details (insurable interest) are deployed then only changes to the risk as far as section/market level is required and no MTA transaction is required if no money is involved.
|Risk header||Both NOVUS and HELIX collect data that is common to the risk or contract which may be referred to as the risk header, elements such as the period of cover, policy type, class of business, risk client and original assured/insured are all specified within the risk header field.|
|Risk items||Each section in a policy must have one or more risk items. Within a policy and controlled by the available sections that the policy has been set up with, the list of available risk items is presented to the user.|
|Sanctions checking||The sanctions checker is a feature that allows clients to have their accounts checked to make sure they have no international or government sanctions against them restricting trade.
Requests can be submitted using NOVUS on an ad-hoc basis as well as automatically once a month by the command console.
The NOVUS sanctions checker works directly with the financial sanctions register and the US Treasury OFAC (Office of Foreign Assets Control) list and enables the check of client accounts on both an ad-hoc and routine basis.
All partners can be sanction checked when they are created, whether new capacity providers, clients, TPAs (third-party administrators), or policyholders.
The entire list will be regularly checked, once per month by default. Any failures against the default OFAC/HMT datasets are returned to the compliance officer – the party defined in the WHO program as role C.
|Section||These are the compartments of a risk (master or attached) that have their market configurations of client, carriers and agents, their fundamental limits and their parts of a transaction. Each risk record (quote/policy/treaty/master/binder) requires one or more sections. A section is a self-contained pot of monetary activity within a transaction. A new section is required if any of the following situations arise: Different London market risk codes – only one risk code per section, different market configuration – including client discount, carrier deductions (brokerage) signed lines, different carriers (Lloyd's Brussels vs Lloyd's London syndicates), order percentage, note taxes and fees are applied per section.
In some contracts, these may align with a class or coverage, and in other cases align with layers, for example in a reinsurance excess of loss contract. The section types used to denote these sections are vital to be set up to support the contract document layout and the money and MI reporting.
In the case of facilities placed policies find if the master facility binder can offer suitable cover using the section type – additional to a suitable period of cover, division, currency and lead.
The SCHTARIFF program displays tariff descriptions for the binder specified.
|Section types||A section type must be unique on any multi-section policy but can be used in any combination on a risk. Master contracts will offer any attaching declaration of the range of section types. Section types are ring-fenced partitions for premiums and claims on the ledger.
Risk details screen selection is controlled by policy type, but the risk items codes that are offered are dependent on section types selected. The bordereau(x) rows are defined by section types.
|Slip record||Pre firm order document produced from an existing pre firm order risk or quote record.|
|Soft configuration||Creating new code or code relationships within the CODES program; may or may not require other elements. These could be a corresponding document or additional “tags” within a document to extract data from the system onto a document.|
|Surplus||Where a contract insures risks that breach the surplus stated value, in the context of reinsurance.|
|System configuration||Components already coded in the system to cater for particular requirements. This will require developers to initiate or create this for the client company.|
|System reports||Reports run from programs in the system that the system validates using the AGED, ACCLIST, TRANLIST,and TRIBAL programs. They are warranted to be correct in terms of the data supplied, changes are considered to be possible when legislation or general practices change.|
|Template||Document templates are housed in the templates folder used in the SLIP, and QUOTE programs. Available templates are controlled by policy type.|
|TIW (The Insurance Workplace) Integration||Interface with ECF (electronic claims filing), de-linking, premium processors, IMR (interest maintenance reserve) document repository.|
|Transaction||A financial entry in the system, entered by the TRANPT, TRANPTN or one of the TREATY programs. Each can have multiple sections and can exist (via the TRANPT program) over multiple Instalments. Transactions will be created for a risk/policy or if an FDO/ADJ (for document only/adjustment), may be set up against the master contract directly.
Transactions could be a financial entry into the system - perhaps an IBA (insurance broking account) ledger templated transactions (consulting the arrangements on the market) including:
Or a non-templated transaction using the TRANPTN program to move defined amounts of money between parties on a contract but not in the market defined apportions.
Or a nominal ledger transaction posted through the NLPOST program for non-IBA items.
|Training||Classroom event for up to 6 people who require similar areas of knowledge. Contains a prior agreed agenda for the session lasting six hours for a one-day training and three hours for half a day training.|
|Trading currencies||The list of currencies that businesses may encounter, for policy premium and limits expression, and a convertible currency transaction.
For example: if quoting in EUR but not running a EUR bank account the transaction would be deemed a convertible currency transaction. Those currencies without a bank account are denoted as source currencies only.
Those currencies that are expressed in the BANK program for the currency of the bank in question are deemed to be converted currencies or destination currencies.
The currencies conversion rates are updated via the CUR program on NOVUS, automatic update feeds are available if required. The client may choose the frequency and source from which the exchange rate is taken. The bank account details are set up in the BANK program
Multiple bank accounts can be stored in NOVUS and it is possible to transact into different bank accounts for different currencies.
|UMR||Unique market reference – frequently used in the London market but is utilised through the system to ensure a single risk can be uniquely identified. It comprises a company identifier or broker number, a risk number and an underwriting year. Every risk has a UMR.|
|WHO||The program to create all users and producing brokers when internal staff are required to act as account managers for a risk. Active users require individual client software licences. No licence sharing is permitted.|
|Wholesale binder||Sometimes referred to as 3rd party binder, this is a master record with no attaching policies held in the system. It is regarded as a structure that may not be appropriate going forward where the policies bound by the 3rd party must be absorbed/imported into the system by the wholesale broker and not just passed through.|
NOVUS is an enterprise solution for insurance and reinsurance brokers that can handle all classes of business. This demo system has been configured for the most common use pattern with Lloyd’s risk codes, common classes of business and policy types, and comes with a selection of templates for documentation. With prior arrangements, it can be possible to have the demo system tailored to use documentation similar to your existing style if you require it.
Please remember documentation can be customised to your specific requirements at installation.
The dashboard screen is the first screen presented to a user once they have logged into the system. It provides different methods of using the software. The menu across the top of the window breaks the programs into separate groups for easy access.
If the program name is known, simply type the shortcut into the NOVUS shortcut box in the top left-hand corner, and access it directly.
The user guide wiki is displayed at the bottom right hand of the screen. As a program is accessed, the relevant user guide page will open dynamically. The user guide can also be accessed from the support website through a browser.
The main panel appears in the centre of the screen; the various panels on the menu screen can be resized by dragging the panel borders and re-positioned using the panel positioning icons.
If a screenshot is taken of the dashboard, the file will be saved to the P drive for future access.
1.3.2 F1 - Help button
To learn more about the program, when using NOVUS programs, position the mouse cursor into the first field and press the F1 key on your keyboard. Clicking this button will launch the user guide directly onto the desktop.
NOVUS provides tailored documentation for disparate environments at the Pro-forma schedule/quotation stage; all documentation is styled for a single company from debit note onwards through the back-office system.
Further datasets can be installed for different legal entities and hosted on the same server. This works well for a sponsor company or a group that needs to use different operations. A new dataset is treated as a new installation.
The system supports several different broking activities (wholesale, retail and MGA):
- Inward bordereaux load - In-house binders - Lineslip - Wholesale binders - Proportional treaties - Facultative
NB: It is essential that the codes in the CODES program are set up to support the activities your company engages in and includes appropriate types, classes, sections, and risk items codes before proceeding, and that the links between items and sections, types, and documents/risk details screens are all configured correctly.
Wiki Guide pages: enquiry programs
At the top of the NOVUS screen is the familiar Office-style ribbon.
Clicking on one of the tabs will change the set of icons and shortcuts displayed. Clicking on a shortcut icon will launch the NOVUS program. Depending on the options available there may be more - or fewer - icons than the screenshot displayed above.
Icons that are displayed with the pink question mark symbol are for enquiry programs.
Above the ribbon, tabs are a set of Office icons. These shortcuts will launch the most common Office applications from the server installations, as well as the calculator application.
The screenshot above shows an example of the purchase ledger tab and icons.
Hovering over any of these icons displays a tooltip explaining the program in more detail, including the shortcut used to launch the NOVUS program.
This screenshot shows the claims tab with the Office theme applied.
For more information on themes please look at the Themes and Skins section of this document.
Other useful functions can be found on the system and utilities tab. Here you can find external web links which display on NOVUS screens. These external web links are managed by Morning Data
1.3.4 NOVUS Menu tab
The NOVUS tab gives access to commonly used features in the software without the user needing to know the shortcut to use. To access the menu, click the NOVUS icon tab and select the menu item needed. Clicking elsewhere in the dashboard changes the focus back to NOVUS.
1.3.5 Search Bar
NOVUS can search the entire system for almost anything. Located just above the ribbon is a text box into which full or part policy numbers, transaction numbers, claim numbers, account codes etc. can be entered.
The system will return a list of possible matches and selecting one of the "possibles" will result in the window expanding to provide extra information.
This example shows a search for accounts beginning with “P001”. The system has returned a list of possible matches and selecting one has caused the window to expand with a list of inception years. Policies attaching to this specific policy, plus any related markets and transactions, are shown in the same window.
In this example, the search for H04559 has found one policy and a selection of available options including a market and transaction.
There are several enquiry programs that can be used to perform detailed searches on aspects of the system.
1.3.6 NOVUS Shortcut bar
The NOVUS shortcut panel allows any original NOVUS program to be launched by entering the original shortcut code for the program. A list of each shortcut and description can be found in this wiki.
The textbox will predict which NOVUS form to open by using the autofill function to complete the text. To change the form suggested by NOVUS, continue to type the command required. Clicking the drop-down arrow will present all options available based on the text entered into the shortcut box. Clicking the launch button or pressing enter on the keyboard will open the chosen form in the main panel.
Users who have access to programs are defined by a combination of authorisation level and program groups list in the user profile (the WHO program). Programs are assigned a group letter in the TITLE program.
See your system administrator if you are not able to access a program that you require. All users should have access to ETITLE to see the full list of all available installed programs).
In the top-right corner of NOVUS is a collection of icons that allow customisation of the look and feel of NOVUS, as well as providing quick links to support functions.
From the left, the icons depict:
- “Send logs” will run the support utility responsible for sending log file information to Morning Data.
- The artists’ palette icon changes the look and feel of the NOVUS application by offering a collection of colour schemes. For more information see the Themes and Skins section of this document.
- The third icon will expand the top-middle panel of NOVUS to the full height and width of the window. This is especially useful for long lists of data.
- The fourth icon will reset the display layout to the default settings.
- The fifth icon will expand the bottom-middle panel to the full height and width of the screen.
- The sixth icon will open the file upload program.
- The seventh icon will launch the PC.CSV viewer application to view the contents of a CSV file. This contains data that is used whilst creating a document such as a slip or debit note for use together with other data in the mail merge document production process. This is sometimes requested by Morning Data support staff.
- Finally, the last icon will take a screenshot of the NOVUS window; sometimes requested by support staff.
1.3.8 Navigation Tree
NOVUS uses a navigation tree to allow quick access to areas of the system which would take several keystrokes to access.
Navigation uses an Outlook-style tree and icons panel which simplifies access to risk, quotes, claims, reports, and accounts information.
In the example showing the reports section: right-clicking on any report listed will give a full breakdown of options available. Double-clicking on any report will open that report.
Changing the section to risk will open risks and view documents, claims, and transactions within each risk.
In the example the year 2019 is open and there are three policies H04101, H14102, and H04105 within this year.
Under each policy, there are further options. Right-clicking on the original premium transaction will offer a user the ability to open the transaction in a variety of enquiry screens.
Right-clicking on the policy allows the user a variety of options as shown. This context menu alters depending on where it is being deployed.
1.3.9 Work Panel
Upon opening NOVUS, the main panel shows the news tab. The tab shows articles and useful insights into functionality within NOVUS.
To change the layout of the panels, manually click and drag using the window grab tool along the window divider, or click the panel minimise/maximise, and reset buttons.
When an initial NOVUS program is launched, this panel will change to show the form requested. Multiple programs can be open at the same time. Tabs across the top of the main panel expand as more windows are opened, as shown in the screenshot.
1.3.10 User Guide Panel
In the screenshot, the bottom-right panel, user guide, shows the specific page for the program shown in the middle panel, ERISK. This panel will change to reflect whatever program is in the main centre panel.
The user guide can be opened separately in a new window by clicking on this link:
1.3.11 Recently Completed Tasks
NOVUS continuously checks which programs and policies are open and from this, it can display a history of what tasks have recently run.
This is useful to check recent policy numbers, and transactions or to check processing or matching anything in the system. The recent tasks viewer returns the most recent 100 tasks.
Additional panels cover activity such as the current status of sanctions submissions.
You must have a user account, and the relevant permissions to use the programs required within the NOVUS system. User ID is configured by the administrator for your system in the WHO program.
The groups of programs you have access to can be created in the security tab.
Programs are grouped to match the task groups your company wishes to operate. Programs and users can also have authorisation levels.
A list of retired programs is detailed on this wiki.
1.4 NOVUS Compatibility
For NOVUS installations Morning Data supports Windows Clients currently in Microsoft Mainstream Support only.
2. Front End Risk Processing
Tasks included in this section relate to setting up policy details and creating quotations, slips and endorsements using Microsoft Word. Those tasks, which relate to setting up markets, are to be found in the market section of this document along with details of cover note production. This section concludes with details of the policy renewal program.
2.1 Creating Risks
2.1.1 Basic Concepts
The system allows slips to be produced against a quotation number using the SLIP program, which can then be converted to a policy or a policy record can be set up first, using the RISKNEW program. A slip can then be produced from the information held in this risk record.
The RISKNEW program combines the DECLARE, RISKNEW, and QUOTENEW programs into one to quickly create policies and quotes. The majority of fields can be completed using drop-down boxes to reduce errors. The fields also indicate information that may have been missed. Field validation ensures that the data that is input into the form is correct and the program can be navigated via the keyboard or mouse for ease of use.
Selecting different routes gives the user different options when creating a new policy or quote. The RISKNEW screen is used for creating or editing existing policies.
Selecting between these will offer different Policy Modes (GID 87):
- Master Contract: Binder (In House) - mode B, Lineslip - mode L, Wholesale - mode W, Facility - mode F
- Policy: Declaration, Off-Policy, Open Market - all mode O.
- Reinsurance: Facultative R/I - mode R, Prop Treaty - mode P, Non-prop Treaty - mode N
- Quote: Facultative R/I - mode R, Open Market - mode O, Prop Treaty - mode P, Non-prop Treaty - mode N
To select a Binder (In House), Lineslip, Facility, or Wholesale binder, the user must first select the Master Contract button. If a Declaration, Off Policy or Open Market, is required, the user must first select the Policy button. If a Facultative R/I or Treaty is required, the user must first select the Reinsurance button. Facultative R/I, Open Market and Treaty quotes can be created by selecting the Quote button.
The policy modes on the main navigation tree in NOVUS are aligned with the policy modes applied to records in the system. The policy mode filter allows the user to filter by Attached, Off Policies, Declarations, Facility binders, In House binders, Lineslips, Other, Placed, Standalone, All Treaties, Proportional Treaties, Non-Proportional Treaties, Facultative Reinsurance, and Wholesale binders
Where a lineslip has more than 50 declarations, the navigation tree will display a truncated list of the first 50 declarations followed by a node indicating the number of additional declarations (e.g. (… 804 more). Clicking on this node will open ERISK with the grid filtered for the lineslip/year to display the lineslip and the full declaration list.
Documents for a declaration can be viewed by opening the declaration in RISKVIEW and using the View Documents option under the Documentation menu.
N.B. The number of declarations displayed can be configurable so if you require a larger number than 50 to be displayed, then please contact Morning Data.
Policy Type selection.When creating a new risk, the list of values offered for Policy Type will depend on the Policy Mode selection made from the above choices.
- Modes B (In House Binder), L (Lineslip), F (Facility), W (Wholesale) and O (Other - Declarations and Off Policies only) will only return Policy Types mapped to Processing Groups D (Direct Commercial), F (Facultative Reinsurance) or P (Direct Personal Lines).
- Mode O (Other - Open Market) will only return Policy Types mapped to Processing Groups D (Direct Commercial) or P (Direct Personal Lines).
- Mode R (Facultative Reinsurance) will only return Policy Types mapped to Processing Group F (Facultative Reinsurance).
- Mode P (Proportional Treaty) will only return Policy Types mapped to Processing Groups Q (Quota Share) or S (Surplus).
- Mode N (Non-proportional Treaty) will only return Policy Types mapped to Processing Groups R (Stop Loss (XL Ratio)) or X (Excess of Loss).
When editing a legacy risk where the originally selected Policy Type is now invalid, the existing Policy Type will be respected - the Policy Type list of values will contain the legacy Policy Type and then the other valid Policy Types as per the structure detailed above. Selecting different routes gives the user different options when creating a new policy or quote. The RISKNEW screen is used for creating or editing existing policies.
Section Selection. This button will only appear when a declaration and off-policy options have been selected and a policy selected from the drop-down list. This additional button will allow a user to specify sections from the master policy to be used during policy creation, see image below, and is now mandated for declarations and off policies.
Use the tab key to use the next sequential policy number, or enter a number of your choosing (advisable only for master contracts).
A prerequisite to creating a new risk is that the codes must be in place to be used throughout the process. These are found in the CODES program and may require a system administrator to set them up. A list of different types of codes can be found on the system codes and groups page on this wiki. The codes required will include:
- CALENDAR: A valid set of periods must be set up for the period the work is to cover.
- Policy type: A valid policy type that has been associated with a processing method must be added. The available processing methods include:
- T = Proportional treaty transactions through the treaty module (must be installed)
- Q = Quota share processed through the treaty module (must be installed)
- S = Surplus processed through the treaty module (must be installed)
- F = Facultative transactions through the TRANPT program
- D = Direct insurance through the TRANPT program
- X = Excess of loss processed through the TRANPT program
Policy type: A valid policy type must exist for all risks and the selection of pre firm order documents can be controlled by policy type. A policy type can be mapped to a valid risk details type and controls the risk level data collection screens which include:
- AH – accident and health
- BW - building warranty
- BL - bloodstock
- CY - cyber
- FL - financial lines
- FT – forestry
- LI - liability
- MA – marine
- MC - motor - commercial auto
- MM - medical malpractice
- PA - US property
- PJ - project
- PR - property
- WC - workers compensation
- YT - yacht
A list of all types of risks can be found on the Risk Elements page on this wiki.
A policy is uniquely defined by the policy number (6 alphanumeric characters), its year and section. Policy numbers can be drawn down sequentially from an internal counter so a numeric numbering system is recommended. Alternatively, a policy number of choice can be used. Policy numbers can be re-used year on year or a fresh policy number can be used for renewals.
The default policy numbering system comprises a specified leading character followed by a sequential 5 character number left padded with zeroes. Hence if the requirement were to start numbering policies from ‘1’ but with a leading ‘A’ then policy numbers would follow the sequence. The letter choice is made during installation and configuration.
A00001, A00002, A00003 etc.
Section type: A valid section type must exist for all sections on a risk and no two sections can have the same type on a risk. For a stand-alone policy (or binder) the new section to be added using the SECTADD program is named consecutively in the alphabetic sequence A, B, C, D etc.
Country code: A valid country code must exist
Optional codes include:
- Producer - See the WHO program to see records with P flag in the job role.
- Location Code - Location of risk (the country code might refer to the origin of the business by country but the location might be of the specific risk in question).
- Department code - The internal department handling this risk
- Occupancy code - Occupancy (for buildings) or occupation for personal lines
- Risk code - London market risk codes
- NTU - Not taken up code. This can be a reason for why the policy is either not take up or for holding back risks from being able to be processed any further - training, erroneous or cancelled.
Currency settings are found in the CUR program.
All risk details are set up in the risk program. Risks can be invoked by typing RISKNEW in the program name or clicking on a new risk, a new quote or a new declaration in the risk management ribbon.
Within the screen, select the type of risk required:
- a master (binder, LINESLIP or FACILITY) - a policy (declaration, off-policy, open market, or TREATY) - a quote
Depending on the initial option chosen the second row of options will reflect the initial choice.
The FACILITY program enables the viewing of an existing facility and its associated policies in list format. Creating a facility requires the master contract and facility buttons to be selected in the RISKNEW program. See the FACILITY page in this wiki for further information on facilities. See the BSCOPE page for more information about binder options.
The CLAUSE program enables the list of clauses to be created, viewed and edited, associating specific clauses to policy types.
The program displays a list of all the created clauses, an associated group number for the clause, and a description. The default incl on column indicates whether the clause has been associated with one or more policy types.
If the clause has not been associated with a policy type, the line is highlighted in grey and the default incl on’ entry displays (unused). Filtering the list by policy type highlights all clauses used for this policy type. Other clauses can then be attached to the specific policy type by checking the default incl? checkbox.
To add or remove clauses from the policy or quote, the RCLAUSE program can be used.
Complete the risk screen with as much data as possible. Fields marked with an asterisk are mandatory and must be completed to proceed. It should be remembered that NOVUS is class or business and policy type independent. All controls to specify the type of business to be processed are done through the use of the CODES program. Risks can be direct broking, reinsurance broking, binding authority, cover holder etc.
There are also now some configurable options available, these are;
- Decimal places – It is possible to control the default number of decimal places used when creating a new risk or quote (the default is 7).
- SL broker – This option controls if the user enters free text in the SL broker field or can choose from a drop-down list of values (the default is free text).
To enable either of these options turned on please contact Morning Data.
The import schedule button on the risk details screen allows repetitive risk level information to be imported from a spreadsheet, rather than having to type the information manually. For more information see the import schedule page on this wiki.
The market can be completed next, without which transactions cannot be processed. See the market section in this guide. If the risk is an off-policy the market will be automatically downloaded from the master/binder policy.
Once the market has been completed with at least one client, one insurer, co-brokers if relevant, and signed down if relevant, a cover note/evidence of cover can be produced using the COV program. See the evidence of cover section in this guide.
Transactions for non-proportional treaties are set up in the TRANPT program. Here, the type of transaction amounts for the policy of by section is entered, and any instalment arrangements and any taxes/fees are configured. See the transaction section in this guide for further details.
Transaction for policies that belong to policy types that are associated with a treaty processing group e.g. T, Q or S will only be able to be processed through the treaty module using the TTYMEN program menu. Only those policies which are proportional treaties can be handled by the proportional treaties module.
As a result of the transaction, a debit note (for a PM (original premium), AP (additional premium) etc.) or a credit note for an RP (return premium) etc. can be produced.
Once cash is received it can be entered onto the cashbook for the bank account it was paid into using the CASHENTRY program. Amounts can be auto-matched if the system finds an exact match. Receipts can be printed if required. Amounts can be entered in batch mode with one batch total for cross-referencing. See the cash entry section in this guide for more details.
If the auto-matching does not take place or is not selected then the MATCH program will allow manual matching of multiple entries against amounts of cash recorded as unmatched on the cashbook. See the cash allocation section in this guide for more details.
2.1.2 Opening an existing risk
There are three ways to open an existing risk:
This will default to the risk view of the risk. Details of a risk can be itemised and edited. Depending on the particular section group, the list might comprise a list of properties, a fleet of vehicles, ships or aircraft. The list will display the appropriate headings for the risk list e.g. licence plate or gross plated weight for a fleet of vehicles.
Click on the edit risk information link to open the risk. The risk notes panel is visible when a risk is open, to add extra information to the risk
2: From the navigation tree, double click to view, or right-hand mouse click, and select open risk to open – if there are transactions on the risk no edits will be possible in the open state unless routed through the RISKEND program.
3: Use the search bar at the top of the screen – then click open.
If there is a transaction on the risk the screen fields will be greyed out and a padlock will be displayed alongside the policy number.
Policies may be contingent on subjectivities that are added to policies by carriers. Customers must prove that the additional evidence meets the requirements for the policy and has been provided to the carrier. For example, to insure a risk against fire, a relevant fire certificate may be required, or to include a classic car, evidence of an agreed value might be needed. Policies and their respective subjectivities can be viewed by the broker along with requested evidence. The subjectivities module has the following features:
- Customers, policies and subjectivities can be imported by brokers and assigned to customer contacts
- Customers can receive notifications and reminders on what evidence is needed to comply with the carrier’s policies
- Relevant communication can be tracked for subjectivities
Subjectivities are initiated from the NOVUS risk screen. To initiate the process from a NOVUS risk open a risk and click the subjectivities hyperlink for the risk. A dialogue box will open indicating that the subjectivities request has been raised within the portal.
This request invokes the subjectivities app which contains the risk data. From this point, the subjectivities app takes control until the subjectivities process is complete. The status of the subjectivities process can be: Pending, Completed, Cancelled, or Rejected. NOVUS is updated with the status. The subjectivities dashboard can also be invoked by clicking the red umbrella icon on the risk management ribbon in NOVUS.
A broker begins the process by generating subjectivities linked to a policy for the customer to provide evidence against. Carriers are attached to subjectivities that are already attached to the policy. When clicking the link the request is raised to the subjectivities portal.
NOVUS performs the following actions:
- If the client company has not previously been used, a new company (CLIENT) record will be created. Any relevant users can then be added to the client record in the portal. Once added the selected client contact will receive an email invitation with a link to take them directly to the subjectivity in the app. Logged-in users can also see other subjectivities assigned to them as "Assigned Broker". They can also see other policies and subjectivities for their organisation that need feedback.
- A policy record (POLNUM\YEAR) will be created if the policy has not previously been used. If a policy has already been created, no new policy will be set up. The list of carriers contained in the market (MART) program will be displayed. The user selects which carrier(s) is responsible for the subjectivity.
- NOVUS will open the subjectivities app so that the new subjectivity for the relevant policy can be added.
Sign in to the subjectivities portal within NOVUS to see the broker subjectivities dashboard.
When subjectivities have been added, checked, and confirmed by the broker, the information can be released to the customer using an email message. The customer can log in and review the information. The customer can then log into the portal and provide evidence or indicate that they are unable to meet the requirements of the subjectivities.
The broker can decide if the process can continue based on the evidence supplied, or the indication that the customer is unable to provide the relevant information. If the broker decides that the subjectivities cannot be met a reason can be noted detailing the rejection of the policy. If the subjectivities are completed to the broker’s satisfaction, the subjectivities can be marked as completed.
Administrators can configure the subjectivities application and can add users, manage insurer records, manage carrier and customer accounts, and add policies to customer accounts.
The user completes the subjectivities details, answering the questions on the popup window. The subjectivities are assigned to a named contact at the client with dates for the client and the user (broker) to ensure timings meet requirements. Subjectivities assigned to users will display on the home screen of the app.
All but Pending complete the process, the user can add the status as a column to ERISK to be able to view risks by subjectivity status. Progress can be regressed and subjectivities details can be changed.
In the event a mid-term change results in a requirement for new subjectivities the user can repeat the process, instigating the routine and adding new subjectivities for the policy in question. The status reverts to Pending again, and updating the same subjectivities with new information will result in completion.
Subjectivities have details about what is required from the client. The broker user or the client (if they are invited to) can satisfy the subjectivities; this may consist of confirming facts or providing evidence, such as a certificate, inspection, or valuation. The green progress panel shows a full history of each stage.
Users can click and drag any document to the policy – evidence may have arrived by email and is to be attached to subjectivities. Alternatively, the client can add evidence using the web portal or phone app. Sections include the ability to add or view the added evidence.
After risk subjectivities have been set up by the broker, the status will show “Pending”. Subjectivities can be Rejected, Cancelled, or Completed. When all requirements have been completed the NOVUS hyperlink will show Completed.
2.1.4 Quote to Risk Policy workflow
This section will take you through a typical standard workflow:
• Quotation system • Risk completion • SLIP production • Schedule policy production • Market set up • EOC production (cover note/certificate) • TRANPT (transaction Processing) • DEBIT production (debit or credit note production) • CLOSE production (closing or silent agent credit notes) • CASHENTRY process • MATCH process • STATEMENT production
It will also cover associated programs such as the WORKFLOW program
Certain assumptions are made in this document:
- The required codes are already configured
- The required partners are already in existence on the system
- The required documentation such as slip templates is already on the system
2.1.5 New Quotes (Indications)
Quotation (QUOTED) and policy records are identified as either reinsurance or direct. This allows quotations, cover notes (COV) and other documentation to be constructed using pre-formed text specific to the type of the policy.
Quotation numbers are generated sequentially by the system. The default quotation numbering system comprises a sequential 5-character number left padded with zeroes followed by a trailing character. If the requirement is to start numbering quotations from ‘10000’ but with a trailing ‘Q’ then quotation numbers would follow the sequence
10001Q, 10002Q, 10003Q etc.
An indication is a skeleton record to place all enquiries onto the system. The expectation is that the client (cl/ins/reins) partner has already been set up, due diligence, sanctions checking must have occurred, and any agreement terms must already be in place. See the indications page on this wiki for more details.
The only available mode is type 'O' (open market) which is the default option in the program. Complete all fields mandated by an asterisk and click the save quote button.
Open the newly created quote in the QUOTENEW program, or double click on its number in the tree and complete the rest of the data required. If there is an email address associated with the client that is in the system, the option to send an email acknowledging the enquiry is provided.
2.1.6 Querying Risks and Quotes
The default setting will display a list of all live policies. If NTU (not taken up), or expired policies are required, deselect the live option from the search criteria checkbox.
Other criteria can be entered into the search bar before instigating the search, such as a policy number, client name or transaction number. Using the contains, any of these, or all of these can narrow the search criteria.
The ELINESLIP program performs a search by leader, member or pool ID. All leaders or members are selected by default.
- The padlock indicates a premium transaction has been processed and so to edit this risk will require an internal endorsement routed through the RISKEND program.
- The green tick in the second column indicates this risk or quote has risk level data on it, by clicking it this data is presented in a grid form.
- The third column, PPL, shows the electronic placing platform status of this risk.
By deselecting the live option and resubmitting the search, lapsed (grey) and NTU (red) risks will also be returned.
Additional information can be shown on the screen by using the column customisation tool.
Click and drag the required column to the grid.
Policies and quotes are all accessible from this program, and there are additional criteria that can be selected to narrow down the initial search.
To open a risk double click the relevant row in the grid.
Using the yellow filter/search bar on the results can provide a simple method of refining the entries to meet relevant criteria:
Dragging any column header to the grouping box allows for grouping, and sub-grouping of entries to be displayed.
2.1.7 Creating a Quote
A quotation is another name for a risk record – but with certain differences. A quotation can be created in the same way as a risk.
Morning Data has modified the set of risk programs to produce a corresponding set of quote programs with appropriate shortcuts:
Users may either start with a quotation (SLIP) using the next number from the quote number index - however, it may be preferable to start with the RISKNEW program. A policy number can be chosen, or supplied by the system, and a slip document can be produced using that policy number with all the additional information available to input into the system using the RISKNEW program.
Furthermore, if a slip is to be created for this policy it should be completed before proceeding with the market. Once a market is in place it is not possible to set up any new slip versions. Existing slips can be viewed (but not edited).
- Open market quotes can be converted into declarations off lineslips, or off-policies from binders when the quote is converted.
- Quote declarations and quote off policies will be linked to their masters.
- The system's insurance and reinsurance quotations differ both in layout and system design. The system provides a quotation tracking system for reinsurance quotes and a client profile system for insurance quotations.
To create a quote use the QUOTE program, followed by 'create a new quotation' or use the QUOTENEW program. The next available quotation number is automatically assigned to the new quotation. The quotation details are completed, including sections, in the same way as a risk record is completed but with the following differences:
- Although the quotation number must have a year assigned, the year has no structural significance. The quotation number alone uniquely defines the quotation record. The year can be changed when the quotation is converted to a policy (using the QUOTEPOL program). Quotations cannot be renewed.
- The division may be left blank
- The lineslip and its year, and the binder number and year are left blank
- The cl/ins/reins. code must be completed. This field is the (re)insured.
The system's insurance and reinsurance quotations differ both in layout and system design. The system provides a quotation tracking system for reinsurance quotes and a client profile system for insurance quotations.
- The period must be entered as this date determines the period of cover you are quoting for and sets the start of the quotation validity period.
- The policy type must be entered.
- The line slip and its year and the binder number and year are left blank
- Number of sections must be entered
There is logic in place to enable the validity period to be set up automatically, this means that as soon as the quote has been created, there is a record indicating how long the quotation is valid. However, this means that when the QUOTER program is first used, it expects the actual quotation to exist.
Completing all the mandatory fields denoted by an asterisk will change the status indicator at the top of the screen from a red X to a green tick. At that point, the system will allow the quote to be saved. The more information entered, the more complete the resulting reportage will be.
Almost all drop-down fields display entries from the CODES program. For example, the list of available policy types will come from the policy types code field, and be subject to the user's authorisation level as denoted in the WHO program for the user profile:
In this example, a user who is given level 8 authorisation in the WHO program would not be given the option of the codes QP or OL but would see all other policy types to select.
The systems admin within your company will have level 9 access to change the codes and user profile settings as required.
This is normally made up of a prefix company identifier or broker number followed by the policy or contract number followed by the year.
The logic enables the validity period to be inserted automatically. When the quote is created, the record indicates how long the quotation is valid. However, this means that when the QUOTER program is initially launched the program expects the actual quotation to exist.
- For the QUOTER program a slip is required. (reinsurance)
- For the QUOTED program a slip is not necessary (direct)
Quotations can be modified at any time because transactions can never be processed against a quotation.
Slips (SLIP) can be produced either against a quotation number or a policy number so care must be taken in setting up the respective counters so they do not overlap.
Slip versions commence at ‘01’. Up to 99 slip versions can be produced. There is no facility to produce different slips for each section of a policy as, in practice, cover details of a sectioned policy would be contained in a monolithic slip possibly divided textually into the various sections.
Quotation slips and their accompanying quotations are logged into a quotation log to provide a tracking system.
2.1.8 Direct Quotation
This program is designed for direct quotations. The screen has been simplified but retains the same functionality.
NB:QUOTED is a weak program. Its only contribution is to keep tabs on the quote i.e., set the period of validity. However, there is a requirement for a ‘stylized quotation’ that has a stronger structure and could be used as the backbone for a certificate. The QUOTED and CERT programs could be regarded as a matched pair. In such cases, the certificate placed in the building/boat/yacht etc. would contain all the information previously contained in the QUOTED program – except the premium would be suppressed. The QUOTED program initially produced direct yacht quotations with the same layout as Lloyd’s certificate.
For QUOTED a slip is not necessary (direct). Once the user is satisfied the details are correct, pressing F10 (COMMIT), or clicking produce quote in this program will produce a direct quotation on the user's default printer.
|quotation/policy no:||Enter the required quote number (see below) or press [F9] to display available quotations.|
|Year:||The quotation/policy number year is used to index the quotation within the WP area. Once entered this cannot be changed although a different year can be specified when converting a quotation to a policy.|
|Type:||Extracted from the QUOTENEW program.|
|Insured:||The name of the insured may optionally be entered if the program is being used for the first time for this quote number.|
|Original Insured:||The name of the original insured may optionally be entered if the program is being used for the first time for this quote number.|
Options are ‘C’, ‘T’, or ‘I’ The ‘C’ option allows a quotation to be created from a blank document. ‘T’ enables a document template to be copied from. ‘I’ is used to import a non-mergeable document such as a scanned or e-mailed document.
2.1.9 Reinsurance Quotation Log
This section describes how the log tracks quotations to produce a reinsurance quotation. When QUOTER is first used the program expects the actual quotation to exist.
The accompanying documentation produced by this program has been designed for a reinsurance situation. A warning is issued if used against a direct pro forma slip.
For QUOTER a slip is required (reinsurance)
On clicking produce docs Microsoft Word creates a reinsurance quotation from the slip. After editing, saving and printing the quotation, close the document or exit MS Word.
Slips are free-text WP documents generated using Microsoft Word and contain details of the risk and cover required. The templates available are policy type based and can be pre-formatted to meet your company's specific requirements. Contact Morning Data for additional assistance.
The SLIP program will accept either a quotation number or a policy number and date. You cannot create a quotation from within the SLIP program – this functionality has been moved to the QUOTENEW program. Multiple slip versions can be produced for a quotation - a risk can only have one slip version.
The slip is discussed with prospective insurers and, after agreement; it is used to record a (re)insurer’s preparedness to underwrite all or part of the risk. Although the content of the slip is entirely left to the user, the system expects a direct pro forma slip to be materially different from a reinsurance slip, both in content and layout.
The direct pro forma slip should be created from a template where the user enters details of the goods insured, typically, in the case of yacht insurance, this includes the hull, masts, outboard motors etc. The pro forma slip would also contain navigational constraints and details of the clauses, which would apply to the cover. This pro forma can be used as a turn-round document for rating purposes with the insurers.
A reinsurance slip sets out the proposed cover in descriptive terms such as period, name of the insured, commission and general details. Most of these details can be taken into the cover note unchanged. It is probably easier to use an existing slip for the previous year or a slip for a similar policy to copy from rather than a standard template.
The slip is usually an underwriter facing document, containing details of the risk and cover required.
QUOTE/SLIP combination. This is required but mainly to produce a rating slip on a lineslip (policy). Such policies are called lineslips because each item covered requires a slip and is regarded as a ‘line’ (attachment) on the policy.
The ground rules of the cover are set out in the scope of the lineslip: territorial limits laid up conditions, clauses, drivers etc., where the underwriters want to set a rate based on minor individual circumstances.
NB: If pasting text from an electronically supplied third party slip, ensure there are no section breaks in the pasted text, and that the paste does not overwrite the section break at the end of the receiving slip.
Pro-forma schedule documents are WP templates generated using Microsoft Word. The templates available are policy type based and can be pre-formatted to meet your company's specific requirements. The Pro-forma schedule document should be built from a template in which the user enters details of the goods insured. In the case of yacht insurance, property, etc., the pro forma schedule would also contain any navigational constraints and details of the clauses, which would apply to the cover.
The pro forma schedule is usually a client facing document - a description of the agreed insurance policy.
Note: If you enter the risk details do not use quotes (") as that will affect the production of the pc.csv file and prevent the production of the profsched document.
To reset flags to produce a new version of the document see the reset flags page in this Wiki.
2.1.10 Placing a Quotation
The QPLACE program accepts a quotation number.
A market cannot be converted based on a quotation.
The qplace.sql script must be placed into the scripts area to print the quotation.
Once you have chosen the market template, it is not possible to change the selection of a template for a given quotation. The structure can be modified by adding further subscribers or effectively deleting lines by setting up declinature codes.
To choose a different market template firstly use the DELETE option and select a new market template.
2.1.11 Covert Quote to Policy/Risk
Once a firm order has been received the quotation can be converted to a policy using the QUOTEPOL program. This involves using the next available policy number or a policy number of your choice (provided it is not already in use) and specifying a year for the policy. The conversion program extracts certain key information from the slip (such as period, insured, type) and writes this information into the risk record. This operation depends to a certain extent on the design and layout of the slip.
This program has considerable intelligence and a wide range of formats that can be used. The quotation slip is reclassified under the new policy number and reference to the slip under its earlier quotation number is removed. You may choose to discard other slip versions at this juncture or use other quotation slip versions to convert to other policy numbers. Whatever slip version is used in the conversion it is converted to slip version ‘01’ for the (new) policy.
Quotations should be issued before converting to a policy. This step may not be necessary to process transactions against a binder in a direct insurance environment. Alternatively, the quotation can be converted to a policy and the policy can be attached to an existing binder. In a reinsurance situation, a policy record will be necessary as the first step in placing the risk in the marketplace.
Whilst in the quotation stage, multiple slip versions can co-exist, however, when converting to a policy only one slip version is possible. Other slip versions can be discarded or left on file to be converted to other policy numbers or used as templates for other slips.
In direct insurance, the slip version facility can be used for different clients, which have similar pro forma details. A more likely scenario is that cover is going to be provided on a master policy under a binding authority. In this case, there may be no need to convert the quotation to a policy. The client profile record can be extracted from the slip to which the cover (binder) can be assigned.
Converting a quotation to a policy brings over WP documents prepared under the quotation number and re-classifies them under the new policy directory. If multiple quotation slip versions apply, the version to convert must be specified (which becomes version 1 under the new policy); other versions can be left on file or discarded. A new risk record is created from the text in the quotation slip, which the user can then amend as required.
WP documents created are reinsurance slips, direct Pro-forma slips, quotations, endorsements and cover note addenda. Any printer set up for normal MS Word printing can be used to print these documents.
The SLIP program supports a replicate option which enables previously created slips to be replicated into the current quotation/policy number. Alternatively, a slip template can be used, which is a pre-formatted document into which the quotation number and other information are merged. A further possibility is to import flat files (such as scanned slips).
To reset flags to produce a new version of the document see the Reset_Flags page in this Wiki.
2.1.12 To Convert a Quotation into a Policy
Once the client has approved the slip and quotation the policy is ready to be set up.
On clicking commit, the policy details are automatically extracted from the slip and entered into the new risk database record. The policy screen as described in the next section will appear which may be used to edit the record as required. The WP interface executable is used by the QUOTEPOL program to transfer the documents between the QUOTE and POLISSUE programs.
Additional fields for the period, lineslip, binder, and division must be completed. All records for risk_details, risk_notes and any pro forma market are copied over to the new policy number.
2.2 Setting up Risks
2.2.1 How to search for an existing risk
Existing risks can be searched for in the search bar, situated above the NOVUS ribbon. Full or part policy numbers can be entered to display a list of existing risks.
A risk can be searched for in the navigation tree by year. Results can be filtered by using the filter button at the top of the navigation tree.
NB: Risks highlighted in grey are expired, risks with premium transactions on them, and thus require the RISKEND program to make changes show a padlock icon, and risks highlighted in orange have been NTU (not taken up).
To refine the results, use the search criteria options at the top of the screen.
For example the contains field returns all risks
Additional criteria show risk details for marine with a risk item code of hull.
Additional information can be shown on the screen by using the column customisation tool button next to the create new risk button at the bottom of the screen.
To open a risk double click the row in the results grid:
The EPOLIST program (policy listing by (re)insured) provides a summary of policies for specific or all reinsureds and/or clients. It shows the user if the policies are attached to a binder, whether the policy is NTU'd (not taken up), how many slip versions there are, how many debit notes, closings, what market version the policy is up to, and what date the cover note was issued (if entered into the COV program).
2.3 New Risk
To directly create a new master or stand-alone policy
Click the risk record overview icon on the risk management ribbon
Type RISKNEW in the NOVUS shortcut bar
click the create new risk button at the bottom right of ERISK
For example, the RISKDETPA program can be used to insert PA (property residential US) details against a risk.
Each property has an address, information and deductibles tab that can be used to store additional information against each property. Risk items can then be added for each property. When a risk item is added, the premium is automatically calculated based on the sums insured, sums insured percentage and rate percentage.
If there has been a transaction on the policy, padlocks will be shown on the screen indicating that the policy is locked and changes cannot be made without running the RISKEND program.
The EPOLIST program lists policy numbers along with brief policy details either by a specific reinsured or client.
A renewal policy is made up of some, if not most, of the information that made up the original policy. The system assumes that all of the original information is included in the renewal.
In renew mode the mode flag should be copied over without change. While in copy mode it is impossible to know whether a binder is being copied to become another binder or a standalone policy. The RISKNEW program checks the POLNUM, BAPOLNUM and MAPOLNUM fields for this information.
2.4.1 To copy an existing Policy
The system will replicate the information from the risk record for the original policy number and year into a new policy record for the new number and year. The default number is the next sequential number available. The copy will create a new policy record with the same number of sections. If the risk record for the policy number already exists, a warning will be issued and you will be prevented from proceeding with policy replicate. The market can be replicated provided that too does not already exist. If policy replicate is not permitted, the system will display an ‘N’ in the replicate policy field.
The task of replicating a market is treated as a separate exercise from replicating a policy. It is possible to use the POLREN program to copy a policy record followed by POLREN to replicate the market from a different policy - provided they are the same policy type and division and have the same number of sections.
The replicate market option will replicate the last (greatest) MVN (market version number) from the policy being copied from, into market version number 1 for the new policy being created.
The new policy will not have slips or quotations. If a slip is required for the new policy number based on, or identical to, a slip used on the original policy use the replicate function in the SLIP program.
From the policy tasks menu select pre firm order processing, policy asks policy copy/renewal or type POLREN into the NOVUS shortcut box.
In the field marked "'C'opy or 'R'enewal:", enter 'C' for copy
Enter the policy number, and year for the policy to be replicated.
All available information will appear in two fields on the page; existing policy details on the left, and new policy details on the right.
Under new policy details, make any necessary changes
Click commit to perform the copy.
To reset flags to produce a new version of the document see the Reset_Flags page in this Wiki.
2.4.2 To renew an existing Policy
Wiki Guide pages: POLREN
From the policy tasks menu select pre firm order processing, policy tasks, then policy copy/renewal or type POLREN in the NOVUS shortcut box.
From the drop-down list, select the policy number and year for the policy to renew. If the policy has lapsed a red warning note will appear under the policy details. If the policy is still in date, a red warning note details the date when the policy expires, and the renew button is disabled.
Select the renew button on a lapsed policy.
Under renew: enter policy details.
Click proceed to perform the renewal.
2.4.3 To renew a declaration
Wiki Guide pages: POLREN
Any new declarations on the following year's binder will start with -0001,-0002 etc.
To reserve the existing declaration numbers for renewals the reset declarations flag should be set to 'N' in the POLREN program
2.5 Risk Record Maintenance
1. The risk record maintenance can be used to create master binders, lineslips, and facilities as well as standalone policies of any type including treaties.
2. On launching the RISKNEW program, tab to obtain the next available risk/policy number off the index (or type a 6-character reference of your choice. This is recommended for repeatedly used master contracts)
NB: This number combined with the year and section defines the unique identifiable item of business. Combined with other information such as policy type and or business class can be presented in whatever order and visual format on documentation as the policy number, it is also formatted correctly as the Lloyd’s UMR where required.
3. Tab or click to accept the current calendar year
4. Enter in the relevant division – for options press F9, or use the drop-down box
5. Tab to and enter the remaining information as required using F9 or the drop-down box for available options where relevant. All fields with an asterisk (*) are mandatory, and help is available by hovering over the relevant field.
NB: Bouquet and binder can be covered in further detail with a member of the Morning Data Team.
6. Complete the client details section including the cl/ins/reins field. The client always pays the debit note.
7. Complete the original assured – optionally without using a code if they are previously unknown and the business has no trading relationship with them.
NB: all original insureds may be subject to sanctions checking and thus it is recommended to set up a suitable record in the PARTNER program to facilitate this.
8. Complete the additional information tab
NB: for risks not being permitted to process transactions against at this stage enter an NTU code (not taken up) of choice. See the CODES program for available options or adding new ones.
9. Complete the sections tab adding information for each section defined in the policy tab.
10. Complete the sections created with a suitable section type, period (sub-period of risk period, laid up (for marine/yacht), limit description for each section (mathematical limits in each relevant currency are configured in the LIMITS program in the claims system), and if required the estimated GWP and sums insured (SI) for each section, or the total of all sections on Section A.
11. For binders the max GWP (gross written premium), SI (sums insured) and SI (Agg.) are created on the binder, and the off-policy amounts are deducted from the totals and warnings/restrictions will apply.
12. Click save. The contract, year, and sections field in the policy tab is now greyed out.
13. If further details are required click the details button at the bottom of the policy tab.
After the risk has been created it may be necessary to record further details in the risk details screen. The risk can be accessed in three ways:
- Enter the policy/quote number into the search bar
- Enter the shortcut RISKDET** into the NOVUS shortcut bar. The asterisks refer to the two-letter code appended to RISKDET such as:
- AH – accident and health
- BL - bloodstock
- BW - building warranty
- CY - cyber
- [RISKDETFL|FL - financial lines]]
- FT – forestry
- LI - liability
- MA – marine
- MC - motor - commercial auto
- MM - medical malpractice
- PA - US property
- PJ - project
- PR - property
- WC - workers compensation
- YT - yacht
A list of all types of risks can be found on the Risk Elements page on this wiki.
The appropriate codes can be found in the policy types section of the CODES program. This will facilitate searching for the risk in the dialogue box.
3. In the risk screen, select edit risk information and then select the risk detail screen button in the centre of the page.
Depending on the type of risk, the right-hand panel of the risk information section will display different tabs. Tabs can include main, construction, additional info, activities, professional business activities, notes, claims etc.
2.5.1 Risk Details
This screen is also available by clicking the edit risk details link in the ERISK program for the chosen policy.
The risk details screen will display as below, with a list of properties in the top panel and tabs for the address, information and deductibles, and risk items in the bottom panel. This example shows details of a property risk:
The information tab expands (as shown below) to allow general details, occupancy and construction details to be added against a property. The view on map button links directly to mapping software to display the location of each element of the risk in a graphical view using the RISKMAP program. If the type of risk is marine (RISKDETMA), NOVUS will invoke the MARVIEWER program instead of RISKMAP.
Other risk types are detailed in the RISKDETS page on this wiki.
A list of wiki pages associated with risks can be found on the risk management page on this wiki.
To view the range of policies for sums insured during a binder year, see the RPROFILE page on this wiki for further information.
2.5.2 Legacy Form Co-existence Feature
Wiki Guide pages: ETRAN
When programs are converted from Oracle FORMS6 to .NET formats, there sometimes are issues that need to be resolved by the team. To continue working with as little disruption as possible whilst any issues are resolved, the FORMS6 version of programs can still be accessed for a limited time after program conversion.
1. The legacy version of a program is accessible by prefixing the NOVUS shortcut command with a hash symbol. For example: ‘#ETRAN’, would launch the legacy version of the ETRAN program. This feature will be removed when issues have been fixed for that program command.
2. Not every program command has the hash symbol functionality
3. NB: In HELIX this information is used to calculate premium from the integrated rating engine. In NOVUS this information can be inserted into the documentation.
4. The risk record is now complete.
2.6 Policy Compliance
2.7 Automated processing through the Core Data Record (CDR)
The Core Data Record (CDR) is a new methodology chosen by the London Market Group’s Data Council and Technical Group which aims to streamline accounting and settlement for brokers. The CDR will align with the ACORD (Association for Cooperative Operations Research and Development) Standard. It is intended that the CDR will speed up and simplify the end-to-end process from placement and claims to settlement whilst reducing the administrative burden on the market. Please visit the Core Data Record page on this wiki for an in-depth explanation of its functions and implementation timescales.
3.1 Documents Preview Panel
The documents preview panel provides functionality to preview the documents related to a specific policy.
To view documents for a particular policy, find the policy in the risk navigation tree on the left-hand side of the screen, right-click on the documents folder and then select the view in documents viewer option.
Once a job has been created using the DOCTRANS program and received an email notification that the document upload has been successful, a work order can now be created. This can be done using the CREATEWO program.
The documents preview panel supports the following file types:
• PDF • Word • Excel • Images • Text files • Web pages
Below shows a Microsoft Word document previewed in the right-hand panel of the screen:
Below is an example of a Microsoft Excel document in the preview pane:
Below is an example of an image file in the preview pane:
To search the document by name, enter a partial or full name of the document into the filter box. The list of files will be filtered automatically.
To open the document, select the document in the list and either double click the name or click on the open button in the bottom right-hand corner of the program.
The LIBLOG program allows tracking of system and manually produced documents concerning a particular policy. It allows easy identification of documents produced by the system or manually entered and whether they are currently with external parties or if responses have been received.
Each time the system produces a document an entry is created to identify the type of document. Entries can also be manually created and the type of document selected from the available list. Once a document is registered it can check out (passed to a third party), or check in (when a response is received). Each of these transactions is logged with a date, user ID, and identification of who the third party was, descriptive text can also be added.
3.1.1 How to Create a Slip
by typing SLIP in the NOVUS shortcut box.
1. Enter the risk number (If the risk has already been created (see opening an existing risk section in this document).
Press tab to accept the next available quote number for the index
NB: up to 99 versions of a slip can be created before the process of creating a risk. However, only one version will be in existence after a quote is converted to a risk or if the risk is created before the slip.
2. If the risk already exists, a slip version needs to be entered. This will default to the last slip number if slips have been created before the risk.
3. Select T in the options box for ‘C’reate, ‘R’eplicate, ‘T’emplate or ‘I’mport.
NB: If a template has been created for the specific policy type selected, it will appear in the middle panel:
4. Press F10 to commit your selection, Type N in slip wrapper, and F10 again to commit the process.
5. The slip will be automatically saved within the Windows filing system under dataset, year, and quote/policy number. The text within the slip will be available for the production of the evidence of the cover document, at which point the slip becomes “read-only”.
At this stage, any alterations to the slip can be made within Microsoft Word.
NB: If the INVU document management system is installed it will automatically file and index the document (a message box may be shown if the slip remains open for some time. If this occurs, exit from the dialogue box, and complete the option when the slip is closed after editing).
6. Before creating evidence of cover please complete the market process. See the market section for more information.
NB: for binder slips inclusion of risk details within a pro forma schedule and the production of evidence of cover with automatic clauses and conditions, rather than a reinsurance slip, please contact Morning Data.
For information about specific codes to add to the slip document template please see the slip documents page on this wiki.
3.1.2 Creating a new Pro forma Schedule
A pro forma schedule and slip are not fundamentally different in NOVUS. They are paired with their final equivalent: SLIP to evidence of cover COV and pro forma schedule PROFSCHED with the policy document POLISSUE.
The difference between them is the way they handle clauses and the access to risk level data from the risk details screens to populate the document. Templates for both pro forma schedules and slips can be formatted by the user to reflect the policy type of the company with images and layout options. These are housed in the w:\wp\XXX\templates folder.
In contrast, every document produced in NOVUS after a transaction i.e. a debit note onwards must have a single legal company image. Additional AR’s (accounts receivable) and subsidiary companies must have their own datasets which can be provided by Morning Data.
Quote documents are single documents that are independent of other documents.
1. PROFSCHED documents are WP templates generated using MS Word. The templates available are policy type based and can be pre-formatted to meet your company's specific requirements. (Contact Morning Data for additional assistance).
The pro forma schedule document can be built from a template in which details of the goods insured, yacht insurance, property, etc. are entered. The pro forma schedule will also contain any navigational constraints and details of the clauses, which applies to the cover. The pro forma schedule is usually the client-facing document, and description of the agreed insurance policy.
by typing PROFSCHED in the options box from the NOVUS shortcut box:
3. Enter the risk number (If the risk has already been created (see the opening an existing risk section in this document).
4. Select T in the options box for ‘C’reate from a dummy, or build from a ‘T’emplate .
NB: If a template has been created for the specific policy type you have selected it will appear in the middle panel listing available templates.
5. The profsched document will be automatically saved within the Windows filing system under dataset, year, quote/policy number. The text within the document will be available for the production of the evidence of cover (EOC).
At this stage, any alterations to the document are made within MS Word.
6. Before creating evidence of cover please complete the market process. See the market section for more information.
NB: for binder slips inclusion of risk details within a pro forma schedule, and the production of evidence of cover with automatic clauses and conditions, rather than a reinsurance slip, please contact Morning Data.
7. Press F10 to commit the selection, F10 again to commit the process.
To reset flags to produce a new version of the document see the reset flags page in this wiki.
3.1.3 How to create an Evidence of Cover
The cover note program COV can create two styles of documents; one for reinsurance risks, and one for direct risks. For more tailored documents for direct insurance broking with specific clauses/conditions and section text added, typically expected in policy documents,PROFSCHED and POLISSUE programs are used.
Once details of the document to create or edit have been added, Microsoft Word automatically starts with the relevant document opened. Once document edits have been made save the document, and close or exit from Microsoft Word.
Contract certainty is achieved by the complete and final agreement of all terms between the insured and insurer by the time that they enter into the contract, with contract documentation provided promptly thereafter. See the contract certainty page on this wiki for more information
- Type COV in the options box in the NOVUS shortcut box.
- Add the checker and auditor system initials or name as required.
- Select Word and click the button cover note.
4. Review, check, print or send the evidence of cover as required then close.
5. The evidence of cover is now completed.
6. The date and method of transmission can be recorded.
NB: All styles, headers, footers and fonts can be configured to meet your specific requirements, printing on pre-printed stationery or including printed logos.
To reset flags to produce a new version of the document see the reset flags page in this wiki.
3.1.4 Creating a Binder Cover
Wiki Guide pages: POLISSUE
Binder cover notes are prepared from the pro forma schedule after the policy has been converted to a firm order and the market added.
The templates available are policy type based and can be pre-formatted to meet your company's specific requirements. Contact Morning Data for additional assistance.
1. Type POLISSUE in the NOVUS shortcut box
Select the policy from the risk details screen
2. Press F10 or click proceed.
3. The policy document is now completed.
3.2 Market screen
The market program MART notes all parties involved: insurers, silent agents, co-brokers, and clients which are all displayed on the same screen to create a complete view of both sides. This means that the market can cater for multiple clients.
The first pass at creating the market for a risk/policy will set up all sections identically. If any changes are required for one or more sections, amendments can be made afterwards. A pool of insurers can be created who will write the risk together.
1. Tab to accept the policy number offered or type in the policy number you require
2. The latest known year will be offered, tab to accept
3. On the first pass all will appear in the section/type Field
4. On the first pass, 01 will appear in the market version number (MVN) field. Subsequent market version numbers can be used to reflect midterm changes after transactions have been processed against the current relevant market. See the market version numbers page on this wiki for more information.
5. The first line is expected to be for the client or the first of the client lines. Select the relevant code using F9 to display a list of values. The total percentage of the client lines should amount to 10% and the total signed lines of the insurers/brokers should amount to 100%.
• A client is denoted with an asterisk, ‘*’, • An insurers/other side is denoted as a full stop (period) ‘.’ • A co-broker is denoted with a dash ‘-’
6. The market can be configured (Lloyd’s/bureau lines will require dates to be entered to confirm with contract certainty regulations). Open markets can leave this blank.
The amount of total 'commission in' (including brokerage and commission) from each part on the insurer side is entered in the in column and the amount of commission offered to the client side is entered in the out column. This matrix will be used for all transactions in both directions during financial processing.
7. For N (net of client discount) market configurations, the 'comm in' field should reflect brokerage amount only.
8. Click commit. The market consolidation screen will appear and an audit trail will print on the local printer.
9. The market is now complete.
For more information on gross markets see the gross markets page on this wiki. For a detailed explanation, with examples of how NOVUS handles cash flow through the system, please see the NOVUS cash flow page.
3.2.1 Market Enquiry
3.2.2 Net markets in NOVUS
Wiki Guide pages: TRANPT
A net market is where the amounts distributed to insurers and silent agents are after deduction of client commission. Such markets often carry various taxes which are based on the order per cent and, like client commission, are deducted from the gross premium before distribution to insurers.
How NOVUS handles a Net market
NOVUS markets support working either on 100% of order or signing the market to the order per cent, then using gross premium figures. The second of these methods is recommended. With a net market, it would be difficult to accommodate client commission within the market, as a provision to recover this commission would need to be applied to all commission sensitive parties including any silent agents linked to insurer lines.
To configure a Net market, the net of the gross field on the MARKET_HEAD field must be set to N. It is possible to alternate between net and gross for a given policy fresh market will need to be configured as the copy from process will not allow this operation to take place.
HELIX market structure
There is a single line for the retained account so it is relatively easy to apply brokerage to this line to cover the client discount.
|MDL (retained account)||100%||10%|
Subscription commission brokerage
CLIENT * 100% 10% MDL (retained account) : 100% 10%
A £100 premium hits the market and is passed to the retained account which then puts £10 to ‘brokerage’ from which the client discount is paid. The net result is that the client pays £90 and the retained account receives £90.
All HELIX markets have been set up as gross. With the advent of the net feature, these can now be set up as net if required – in which case, there will be brokerage on the retained account. Before proceeding with this change remember that the net markets store the client commission in a different location in the database.
General net market solution.
The flag in the MARKET_HEAD field (The net/gross (N/G:) field) should be set to N.
The client commission is still entered into the market in the usual way but the system will make an offset entry into a separate column ‘behind the scenes.’ This means that the consolidated market will have zero client commission but the commission is still known for the TRANPT program to perform the appropriate transformation.
Entries for silent agents and underwriters continue to be made as for a gross market. Note that silent agent commissions work correctly. For a gross market, the figure entered into the MART program will be based on order per cent. In the case of a net market, the figures will be based on the ‘net gross’ figure i.e. then gross figure after deduction of taxes and client commission.
Here is a worked example of a net market:
Gross premium 780,000. 7.5% order. Client commission 20% (of order), 10.5% taxes (in total and of order%)
|Less taxes scaled to gross||81,900||actual taxes are 7.5% of this figure|
|Less client comm. scaled to gross||156,000||actual commission is 7.5% of this figure|
|‘net gross’||= 542,100|
|Order % after deductions||40,657.50|
|If the market comprises a single insurer with 15% brokerage then the transaction will appear in the ledger as:|
3.2.3 Takaful Net markets
If the Takaful system flag has been set to ‘Yes’ in the SYSP program, the PARTNER program can be used to tag records with a Wakala account. The Wakala account is used to collect fees in Takaful i.e Wakala becomes an alternative to brokerage but is analyzed into the nominal ledger as a silent agent because of its dash suffix (‘-’) rather than the brokerage nominal ledger account.
It is perfectly acceptable if required for the Wakala account specified in the PARTNER program to be set to the partner code itself. There is no ambiguity between the two as the subscribing partner code will be configured in the market with a dot (‘.’) suffix whilst the Wakala record will be configured as a silent agent (‘-’) suffix.
If security tagged with a Wakala account is used in a market, the line must be set “to stand”. On completing that security’s subscription line by leaving the PPW field, the MART program will produce a pop-up window containing the Wakala account. Make sure any brokerage has been specified at this stage.
The Wakala window requires a percentage amount to be specified. In the example above, the percentage entered is 8% so the system builds a new record automatically for the Wakala account with (‘-’) suffix with the commission set to the Wakala percentage multiplied by the subscription of the Wakala initiating record divided by the order per cent:-
Wakala_comm = Wakala_percent * :Wakala_initiating_subscription /order percent.
In the worked example, the Wakala_comm is set to 8 i.e. 8 * 25/ 25.
If the user deletes either the Wakala line or the Wakala initiating line, (before any transaction), the system will delete both lines as the Wakala line is dependent on the initiating line.
In the above example, the Wakala originating line must attract a 7% commission-in, but in addition, must cover the 8% commission to the Wakala account. The system achieves this by writing the ‘additional’ commission against the Wakala originating line, held in a separate field, but not visible on the screen. However, it can be seen by navigating to the Comm_In field and pressing KEY-MENU (f5) and shown below.
(Because this market also happens to be a ‘net’ market, there is also a balancing commission adjustment to the client commission of -20% which can be seen by navigating to the client comm_out field and pressing KEY-MENU.) Both these fields can be better seen from within the EMART program as there are certain navigation restrictions within Wakala lines in MART.
The 8% commission-out on the silent agent line will become 2% of the gross in the consolidated market because this market is a 25% order.
Applying the same principle to the Wakala initiating line (called the ‘PRF’ line) the commission-in (7%) becomes 1.75% in the consolidated market but added to this must be the 2% to pay away to the Wakala line making 3.75% in total. Hence for all lines, the amount paid/received is given as:-
Amount paid/received = ‘gross’(*) * per cent of gross for premium where per cent of gross is the signed line less commission
Amount paid/received = gross * signed line for claims.
Note that in a net market the ‘gross’ in this case is the true gross less client commission so the sums for a gross of £100 are carried out on an £80 figure – also called the net gross.
3.3 Transaction screen
Wiki Guide pages: TRANPT
A transaction is processed on the system first before any supporting documentation such as a debit note is produced.
Select the type of transaction required (normal processing, consolidated transaction, or non-templated transaction) dropdown and click the go button from the right-hand side of the risk screen.
2. The following screen will appear:
3. Tab through the entry fields to accept the default policy number, year and insured name. The transaction can, optionally, be tagged with an endorsement number, however, this field should be left blank for an original premium.
A transaction can be for one, or all, sections, but for an original premium type all
One of the following transaction types is required before any other types of transactions can be processed: original premiums, minimum deposit premiums, declarations and first additional premiums.
Entry details can codify a tag to explain the specifics of this transaction such as 01Q09 (first quarter 2009).
4. Enter the premium amount against one or more sections. This will be populated from the estimated GWP (gross written premium) on the section of the risk record if this has already been completed.
5. Select the payment terms, how many instalments 1-99, and frequency ‘Monthly, ‘Quarterly, ‘Four monthly, ‘Half-yearly, ‘Annually, a delay for the first payment if required, all subsequent instalments, or leave blank.
6. The system will calculate all amounts and frequency dates and leave the cursor in the taxes and fees section.
7. Press F9 for a list of the taxes and fees configured in this demo system and select the relevant tax or fee required. NOVUS defines a tax as a percentage applied to all instalments which can be collected with the first instalments, and a fee as an amount of money collected at the start. (see precedence taxes section).
8. Once the transaction has been configured as required click on the proceed button. The transaction processing full breakdown will appear, by section, instalment, and party lines.
9. The transaction can be split into two or more currencies by percentage if required by clicking the currency split button.
10. The transaction is now complete
Additional permutations and effects of precedent taxes co-brokers and Wakala calculations based on net or gross can be found on the Takaful page on this wiki.
3.3.1 Precedence Taxes
NOVUS provides for taxes to be set up to debit a party or role, for example, client '*' or 'JAMESG' (engineering inspectors), these taxes can be based on 'Gross, 'Order per cent, 'Net of client commission or 'S'ums insured. It also allows for the tax to be applied to each instalment or bought forward to be charged with the first instalment.
NOVUS provides for the tax to be deducted from the gross premium along with the client commission before the market apportionment takes place. If a tax of 5% on order on a 50% order was set to precedent and the client enjoyed 20% commission, then the £200 original amount will be factored by order to make £100, £20 to the client commission, and £5 tax. The market then may dictate there was 10% brokerage and so 10% of £75 (£100-£20-£5) will be collected as commission.
This is useful for MGAs (managing general agents) where taxes should be known about but does not display appear, thus are deducted before the market percentages come into force.
3.3.2 Transaction Enquiries
Wiki Guide pages: ETRAN
The order and brokerage per cent are shown in the labels to the right of source/destination currencies in the ETRAN program.
For unconverted transactions, both outstanding amounts in destination currency and converted date would be empty. Once the transaction would be converted/partially converted, the converted date would indicate the date of the last conversion.
3.3.3 Transaction Listing
Wiki Guide pages: TRANLIST
The TRANLIST program allows searching by the same transaction number, the same year, or policy number. The same day date range can be used for the first and last date of the transaction.
The grid with transactions occupies less of the TRANLIST screen space.
The title of the date column 'ins. date indicates the date instalment is due.
Section letter, section type, and title are added to the TRANLIST program grid and reported using the column customisation button in the lower right-hand corner of the screen.
3.3.4 Creating a Debit note
Wiki Guide pages: DEBIT
After the transaction has been confirmed in the transaction screen by clicking OK (see Transaction screen section), NOVUS will display the debit/credit note production program. This screen can also be accessed by typing DEBIT into the NOVUS shortcut box.
1. Tab to accept the policy/risk number
2. Press F10 to commit or click debit/credit note button..
NOVUS will allow debit notes for information only to be processed for the original assured if required and will produce debit notes for each client if there were to be more than one.
3. The debit note will appear, noting the transaction details, the discounts and taxes and fees applied, the instalment details if relevant, and the default banking details for the bank used for the currency in which the transaction is raised.
3.3.5 Producing a Closing
1. Click on the closings button at the bottom of the DEBIT program
Type CLOSE in the options box from the NOVUS shortcut box.
2. Closings can be prepared for bureau and open market partners. The program also allows silent agents and co-brokers credit notes to be produced.
3. Open market partners appear in the first column, bureaus in the second, and silent agents in the third. Each column will produce documents of a similar style, but each column is processed in turn.
4. The bureau closings can be linked or delinked, stage 1, or S&A
5. The closings are now complete
To reset flags to produce a new version of the document see the Reset_Flags page in this wiki.
4. Claims and Transactions
This module shows the workflow of a claim and highlights the main features of each program used in the claims system.
4.1 Codes used in the claims system
All the codes are user-defined, although the category code may use standard codes across the insurance industry.
|Peril Code||level at which limits and excess are attached to a policy. The peril code comes below the section and enables different sets of limits/excess to be used for different types of loss within a section. Can be null.|
|Cat Code||name used to describe the loss|
|Location Code||location of loss|
|Loss Date Qual||date of loss, date of notification, etc.|
|Loss Status Code||confirmation sent, with the insurer, etc.|
|Analysis Code||code that can be used for reports|
4.2 Claims Processing
4.2.1 The Claims Menu
The CLMMEN program displays the main claims system menu for the claims module. The policy must exist on the system, there is a LOV (list of values) on the policy field that lists all claims on the system (this may need some attention to eliminate completed claims from the list). If the policy number is left blank, the next field will take the cursor to the claim reference field. This also has a LOV. For a new claim remove any existing claim reference for the policy, and tab to the required option field.
For more information about claim processing and programs, please see the Claims page on this wiki.
4.2.2 Setting up Limits
The LIMITS program is the starting point of the claims system. It can be accessed from the ERISK screen; the policy tasks drop-down menu or from the claims menu CLMMEN program. Most users wait until they have a claim before they input limits, but the ERISK program will populate the limits table directly for some policy types.
Enter the required peril code (or leave blank) and the limits base currency. Limits in other currencies can be added to cater for multi-currency claims. The user enters the currency and rate of exchange about the limits base currency, NOVUS calculates the limit and excess.
4.2.3 Entering a Claim
The CLMMEN program is at the heart of the claims system. For a new claim entry (option 2), a unique claim reference will be allocated by NOVUS. This will be based on the pattern of previous references but can be replaced with any text string provided that it does not already exist in NOVUS as a claim reference. The claim entry history log (option 4) shows all activities on a claim, items added, modified, and deleted.
Clicking the proceed button will display further details for the entered claim on a second screen.
Page 1 of 2 of the CLMMEN program
Most of the fields on the first page are optional and their use can be determined from the tooltips. The claimant code appears on this screen as it may not necessarily be the market client. All the code fields have LOVs.
The peril code assigns the correct set of limits to this claim. There is a LOV on this field, which shows the peril codes created for this policy/year/section.
In the claim status box, the claim status code has a LOV, it is an optional code (‘O’pen, ‘C’losed, ‘D’enied, ‘R’eopened) that is very useful for later analysis.
Loss detail records of the claim are kept in a history log - even if they are deleted from the claim entry screen.
Incurred period: This field must be formatted thus: 05M19 – meaning fifth month 2019. Further details can be added to the action log if required.
Page 2 of 2 of the CLMMEN program:
Type: RES or INC has the same meaning for the system and is interchangeable, RES is used for direct insurance, INC (total incurred) is used for reinsurance. Other line types are:
- CLM for the claim record
- REC for recovery from a third party
- FEE for any type of fee (surveyor, etc.)
- DED (Deductible), FER (Fees Reserved)
- TPL (Third Party with Limits)
- PAY (Payee)
- REC (Recovery)
- VAT for VAT
If REC, FEE or VAT are entered an IBA (insurance broker account) account code is required, for other codes this field is not entered. A RES or INC record must exist before the claim can be committed.
Account: displays a list of values (LOV) for entry.
Code: this analysis code is suitable for being used in custom reportage at a later date.
Amount: Amount from ground-up in the calculation currency. This is the gross amount of the claim (NOVUS takes care of order per cent and excess) in the currency of the claim.
FGU in USD: shows the calculated amount.
Sp.: Suppress claim processing on this record (Y or N).
On commit, or clicking save, the limits/excess are 'smeared' across the different currencies (for multi-currency transactions) and the settlement lines are calculated.
4.2.4 Claim Status
The claim has been entered into NOVUS, there are records in the claim history table, limit/excess have been spread across multi-currency transactions, the calculator has written the settlement amounts due and the claim confirmation, claim summary sheets and PCA can be produced.
Using the command console reminders can be sent to users if the claim confirmation has not been printed in a specified number of days.
4.2.5 Claim Acknowledgement
A claim acknowledgement is produced by the CLMMEN program option 3. It produces a Word document for the claim reference which can be sent to the claimant, the market client or the insured (from risk). The format and content of this letter can be tailored to the users’ requirements. Click the proceed button to produce the document and save the resulting Word document for future reference.
4.2.6 Claim Summary Sheets
Wiki Guide pages: CLMMEN
CLMMEN option 6 produces summary sheets for the claim. These can now be viewed/printed on a RES/INC or CLM basis (if a CLM record exists).
4.2.7 Provisional Claim Advice
This Word document can be sent to all (re)insurers in the market. The (re)insurers can be selected from the list in the market denoted by an asterisk (*). This could be confusing as the asterisk displays a list of insurers instead of clients.
For further information see the provisional claims advice page on this wiki.
4.2.8 Posting to the Ledger
With the direct payment option, the (insurer sends payment directly to the claimant/insured) If direct payment is selected in either of the posting programs the transaction goes to the direct payment table, not the IBA.
4.2.9 Post to IBA or Process Direct Payment
The transaction will be posted to a pending table that allows documentation such as CP13 and LCCF (Lloyd's claim collection form) to be printed in a draft format to get approval from the insurers/syndicates for the transaction before it is posted to the ledger. Open market closings cannot be produced with the transaction in the pending table
Only one transaction per currency per claim reference can be held in this pending table. To post another transaction in the same currency on the claim reference the original transaction must be posted to the IBA or deleted.
For more information about the IBA ledger, please see the IBA user guide page on this wiki.
REQBUILD and REQPAY allow for division of duties between the person creating the requisition and another person being the requisition payer. This enables the system to create cash entry records and match the transactions selected.
4.2.10 CP13 (Pending)
Wiki Guide pages: CLMMEN
CLMMEN option 8, CP13, lists the transactions for the claim reference that exists in the pending table. The user selects which option documentation is required. CP13 creates a Word document without further user intervention
4.2.11 Closings LCCF etc.
If the transaction is not in the pending IBA table, CLMMEN option 7 must be used., The LCCF option will display goes to three further screens for additional information currently not in the database. For further details, please see the LCCF page on this wiki.
4.2.12 Post Direct to IBA or Process Direct Payment
CLMMEN option 9 enables the insurer to post to the IBA or process direct payment. if not direct payment post to the IBA. If the payment is for the IBA, The transaction will go into the IBA ledger and will appear in all accounting reports.
Entering ‘Y’ into the direct payment box ensures that the payment will be made directly between the insurer and the claimant.
If the direct payment field has a ‘Y’ entry, the payment will be posted to a direct payment table with a ‘D’ prefix transaction flag. This will not appear in the company accounting records or in any accounting reports.
Debit notes and LCCFs are printed from the CLOSE program, not from within the claims module, whether or not direct payment has been selected.
If direct payment is selected in either of the posting programs the transaction ends up in the direct payment table, not the IBA.
Document fields and templates can be customised to produce the desired output document. A full list of applicable fields can be found on the close documents page on this wiki. Other pages associated with accounting functions can be found on the Accounting page.
4.2.13 Posting the Transaction
The two posting screens are very similar. On entering the dates and currencies the outstanding lines appear in the multi-row block. Which lines are settled and how much is at the discretion of the user, e.g. a Fee line may be put on a separate transaction or the claim line may be part-settled, to be fully settled later.
After selecting the item/amounts from the list, the choice of direct payment is offered – see above for implications of choice.
Commit will post the transaction to the selected area. If part-settlement is selected, then return to the claim entry screen page 2 and commit to redo calculations.
To enquire about period summary totals, full details of the end of the period summary, with drill-down for further details of the summary information use the EPERIOD program.
Items can be suppressed from appearing on statements. please see the statement flagging page on this wiki for further information.
Where a transaction is created and the premium is settled directly between the client and the insurer then DIRECTSET can be used to mark the transaction as settled between the two parties. The commission/brokerage (XBK) will either be payable by the client or the insurer. Currently, the only option in DIRECTSET is for the client to settle the brokerage.
4.2.14 Claim Enquiry
Wiki Guide pages: CLMMEN
CLMMEN option 12 displays an enquiry screen that shows all settled lines on the transaction.
4.2.15 Claim Status
The transactions for the claim are either in the IBA or in the direct table. Closings can be produced for all parties with the CLOSE program (outside of CLMMEN) for records in the IBA ledger and the direct table. Transactions posted to the IBA will appear in all accounting reports.
A full history of all records entered in the claim entry screen can be viewed using the CLMHIST program, which includes lines deleted from the screen.
A full history of all settled lines can also be viewed.
Claims summary sheets can be printed on a res/inc or clm basis. It is recommended that the claim is recalculated using the claim entry screen after a settlement has been made.
Some policies have the need reinstatement. This means that once a claim or collection of claims exceeds the primary limit of the risk, a further reinstatement premium is required to establish the original level of cover.
The easiest way to understand reinstatements is to follow a worked example:
The policy has a maximum sum insured of 10,000 with two reinstatements. If a loss of 3,000 occurs then a reinstatement premium must be paid to reinstate the cover back to 10,000).
This situation continues until such time that 20,000 (two total losses) have been paid whereupon the policy continues to pay out a further 10,000 but no reinstatement premiums apply.
Therefore, a policy with two reinstatements has the capacity of 3 total losses – or equivalent value by way of smaller losses. So the policy initially has a capacity of 30,000.
With this in place the reinstatements can be created using the REINSTATE program:
The two reinstatements are different – this is important for the understanding of how they work:
|PwrtT:||Pro rata with respect to time. For example, a claim for a loss incurring exactly mid-term in the policy will be reinstated at 50% of the original pro-rate premium. Unlikely, this could differ between cycles.|
|Prem:||This is the proportion of the reinstatement vis-a-vis the original premium, expressed as a percentage. This could differ between cycles.|
|Brok:||This is the proportion of the brokerage vis-a-vis the original brokerage, expressed as a percentage. This could differ between cycles.|
|SL.||This indicates how the claims should be ranked – by ‘S’ettlement date or date of ‘L’oss. This must be the same for all cycles.|
|Cons %:||Percentage of this reinstatement cycle consumed.|
Calculation: The calculation of the reinstatement premium will look at the date of loss (if PwrtT = ‘Y’) and compare the loss with the original maximum sums insured and then apply a scaling factor to the premium per cent. If the original premium was 150 and the first loss (3,000) was in on the 1st Feb 2015 then the calculation will be:
3000 * 339 * 150/(365 * 10000) i.e. 41.80
Where the proportion of the loss is 3000/10000 and the remaining period of cover is 339 days.
The claim settlement when processed to the ledger will be accompanied by a reinstatement premium for this amount. The maths is slightly different for limits defined in terms of the excess as against a deductible but in both cases, such a deduction will be embedded into the calculation to ascertain the payable.
There are two important issues to consider which are interconnected. If the ranking of reinstatement premiums is by settlement date then the calculations for different losses simply follow each other chronologically – as they are posted.
If, however, the ordering is by loss date then it may well happen that a claim is made for an early DOL (date of loss) but this is processed after a claim for a late DOL which takes priority. This means that the two losses get apportioned differently into the cycles.
It may be that the first processed (but late DOL) claim gets moved into a different cycle which affects the calculation of this claim to the point that it perhaps should not have been settled at all – or only partly so.
As already alluded to, if a claim gets moved into a different cycle then its calculation will need to be re-done.
For example, a typical situation might be as follows:-
1. Previously settled 3,000 (with reinstatement) for a loss on 01-FEB-15. Limits and reinstatements as above apply and priority is by DOL.
2. We now receive notification of a claim for a DOL of 23-JAN-15 for 9,000. This needs to be processed against cycle 1 conditions and take priority over the first claim which now needs to be recalculated.
3. When recalculating the loss for 01-FEB-15, 1,000 of the claim will be processed against the conditions in cycle 1 and the remaining 2,000 will be processed against the conditions in cycle 2.
As the brokerage is different and a strict audit is necessary, a return reinstatement premium for this loss must be raised and a new reinstatement debit note generated.
How NOVUS manages date moves
On entering details of a new claim, a provision is made for settling that claim. This is done when calculating. By inspection of the loss dates of previously entered claims (that may not necessarily have been processed yet), the program may force other claims to be recalculated. Such claims are flagged as in need of recalculation and are prevented from being processed to the ledger if not already done so.
The user is advised which claims references have been shunted and require recalculation and the user should note these and recalculate them. If claims have been processed to the ledger then this may result in having to raise a contra debit note.
NB: By making provision for a claim at the outset means that processing to the ledger or not can proceed without affecting other known claims.
As claims are entered, the consumed percentage (Cons %) REINSTATE is incremented so at any time one can see what proportion of the claim can be processed into the current cycle and what will overspill to the next cycle.
Policy capacity will be consumed as claims continue to be received. Hitting the 100% level in one cycle will cause the remainder of the claim to cascade into the next cycle.
Reinstatements apply for all processing in the first two cycles (on our example) but claims falling into cycle three are settled but no reinstatements apply. Once the 100% consumed level in cycle 3 has been reached the policy is no longer able to payout.
Is it not practical to apply for reinstatements through NOVUS for policies that already have processed claims. Reinstatements have to be configured and applied to the policy before the first claim is processed.
4.2.17 Earned to Incurred’s (E2I) reports
Earned to incurred is the premium that has been earned to the claims incurred. For example: if a policy of £1000 is 6 months through its period, the earned premium is now £500. If there is a claim of £100, the earned to incurred is now £400.
To run earned to incurred figures (E2I)/stats, on the left-hand side of the NOVUS home screen there are 5 option bars: risk, quotes, claims, reports and accounts. Select the reports option bar to show the screen below:
Type E2I into the report name dialogue box and your available options will show in the list. Select the desired report.
Double click the E2I for NOVUS report entry, and fill in each parameter fields shown below.
Choose the relevant years of account, access to data will be available for all years where data has been entered into NOVUS.
i.e. from 2014 to 2019, contract 03266U, cover holder all, section, cut off period 201906. Currently, the system only permits reports by contract number. There are 3 options at bottom of the screen: view the report in Internet Explorer, open the report in Excel, or print the report.
There will be a separate triangulation for each year of account as it all depends on how many years are requested.
The triangulations should look like the screenshot below when running E2Is every month.
There is a running totals section within the E2I, with monthly net premium and monthly running net premiums visible for each month. Claims and fees are also displayed.
The screenshot below shows the presentation sheet - the replacement for the E2I from Brass.
The configuration is similar to the legacy Brass E2I and is split by each separate YOA followed by gross, net prem etc. Compared to Brass E2I, the net earned will be different, as Brass was running so-called triangulations on 12ths but NOVUS E2I calculates 24ths which is the correct way when involving triangles.
There are several new columns like settled claims, and fees, total outstanding, and total incurred. The presentation sheet is split by section type; in this case it is B2 only.
It is important that the integrity of a risk record is maintained once an accounting transaction (TRANPT) has been processed, as a consequence access to the risk record RISK will be restricted to view only. Once this occurs, the user will be warned accordingly and redirected to the RISKEND risk endorsement program.
Amendment to the risk record may simply be required to correct data input errors or where a change to the terms of the policy/contract has arisen. Such changes are tracked as a matter of good housekeeping and/or for compliance using the RISKEND program.
The ENDORSE program enables the creation and editing of endorsement documents; either a London MRC (Honeycomb) endorsement or a similar single design endorsement.
To reset flags to produce a new version of the document see the reset flags page in this wiki.
4.3.1 Incurred month formatting when entering premiums
There must be an existing risk, and market created to create a transaction. After logging into NOVUS type TRANPT into the NOVUS shortcut bar and click the launch button with the mouse.
In the transaction processing screen, enter the relevant details i.e. contract number. year of account, section and the type is always PBX for the first transaction with the original premium displaying on the bordereau. In the entry details dialogue box the details must be entered as shown:
The month number must be in numeric form followed by the letter ‘M’. The quarter number must be numeric followed by the letter ‘Q’. For example, June 2019 should be entered as ‘06M19’. Tab into the next field which displays the year and month (6th month 2019), and enter the currency, instalments, and fees.
With the highlighted section filled out correctly as above, the data will then go into the E2Is under the month entered.
All highlighted boxes and sections in the TRANPT program must be completed. Additionally, if the frequency is denoted as annual, the number of days from inception of the contract through till the date it needs to be paid must be completed.
Incepts on 1st June 19, Oct 19 bdx needs to be paid on Friday 13th February so number of days from inception to 13 Feb 2020 is 257.
In the LPAN close documents (London premium advice notice) and closing instructions amend the SDD on the LPAN another way.
In the taxes & fees area of the TRANPT program, code 'A' for agents bordereau commission should be used instead of 'C' for cover holders commission. This will stop any errors occurring due to lower case character entries. Lower case c is used for profit commission entries.
Bureau signing numbers and dates against transactions on the system can be made using the SND program.
The breakdown of the figures will be correctly calculated and will match the bordereau transaction sheets.
Below shows a copy of the LPAN to show all four sections under one transaction.
Highlighted boxes show AP/RP, T No, gross and net amounts.
Section A gross ($120.00) net ($91.20) net abs ($85.20) RP
Section B gross $474.00 net $360.24 net abs $336.54 AP
Section C gross ($24.00) net ($18.24) net abs ($17.04) RP
Section D gross ($24.00) net ($18.24) net abs ($17.04) RP
If the overall amount is an RP (return premium) enter the transaction as shown below.
Gross premium as: - section A ($888.93), section C $50.00.
As the RP is going to be bigger, ensure the RP amount is positive in the taxes & fees, whilst making the AP (additional premium) amount a minus in the taxes & fees as above.
Here is a copy of the LPAN to show all sections under one transaction as an overall RP.
See highlighted boxes to show RP/AP, T no, gross and net amounts.
Section A gross ($888.93) net ($711.14) net abs ($666.69) RP
Section C gross $50.00 net $40.00 net abs $37.50 AP
See the FUNDALLOC program to modify funds on a transaction.
4.3.2 Incurred month entry for paid and outstanding claims
Wiki Guide pages: CLMMEN
After logging into NOVUS, type CLMMEN into the NOVUS shortcut bar and click the launch button.
The claims entry screen is shown below. Highlighted are the fields that must be completed. Highlighted numbers are the options that are used the most often: 2, 4 and 5.
To enter a claim, enter the policy number and other information required as highlighted, click the required selection and tab to the next field. The relevant number will appear in the required option dialogue box. Click the proceed button.
Type the bordereau month in the loss details column and section type if there is more than one. Then click save/next page.
The claims entry system is incremental. Each month claims and fees are added on top of the last amounts that are shown on the screen.
DO NOT INCLUDE THE OUTSTANDING FEES IN THE INCURRED.
THE INCURRED AMOUNT EACH MONTH IS THIS MONTH'S PAID CLAIMS (CLM), PAID FEES (FEE) AND OUTSTANDING LOSSES ADDED TO THE PREVIOUS AMOUNTS OF CLAIM (CLM) PAID FEES (FEE) TO WHICH THIS FIGURE WILL BECOME THE INCURRED FOR THIS MONTH.
Once this month’s claims have been added, the figures should change.
Tab to the bottom and click the save button.
Once save has been clicked, the calculations completed dialogue box will appear. Click OK exit the claims entry screen until the claims system menu screen is visible.
Select option 9 'Post to IBA and click proceed.
Please ensure that once in the IBA screen (option 9), the date in the details dialogue box is entered in the following format: 06M19. Tabbing to the next field will fill the log form date entered. If there is more than one section ensure that the section type is entered after the contract no. (FIRE, LIAB, HO etc.).
Always type Y at this stage so that the CLM or FEE can be settled. Tab through the fields until the last box and click save.The screen will display a transaction number and confirmation of posting to IBA.
Please note that transaction numbers will only be displayed for amounts that need collecting such as:paids and fees settlements. Transaction numbers will not be displayed for outstanding amounts.
4.3.3 Non-Templated Transactions
In the non-templated transactions program (TRANPTN), amounts for each party can be specified. A non-templated transaction still requires a market – amounts can only be specified for parties that exist in the market. For further details see the non-templated transactions page in this wiki.
4.3.4 PRC Transactions
Wiki Guide pages: PROFCOM
The PROFCOM program allows you to create a PRC (professional regulation commission) transaction comprising an insurer amount, a broker amount and a cover holder amount
The tax must be structured to debit all insurers and credit a 'pot' account. The user enters the split between (all) insurers, (all) clients and the pot account. This entry in the PROFCOM program must sum to zero. This means that the insurers' debit can go entirely to the pot account or some/all of it can be passed to the clients (cover holders).
4.4 LPANs & Closing Instructions
To create LPANs type CLOSE in to the NOVUS shortcut bar, and click launch.
Type the transaction number into the highlighted field. This screen is the same as the TRANPT program screen.
Make sure the relevant boxes in the PAN options section are completed.
The screenshot below shows the resulting LPAN, all information should be correctly entered into the correct areas.
The brokerage box (19) is calculated automatically to 7 decimal places if needed (this has been created in the risk record) so there is no need to alter it.
To run the ancillary bordereau closing type REPGEN into the NOVUS Shortcut bar and click launch.
Scroll down until the CLOSE_INST report is highlighted, then click the go to report button.
The report parameter entry screen will be displayed in the parameter entry field. Enter or select the transaction number.
Enter the transaction number, click on the Excel button at the bottom, to produce the closing report.
The page orientation may need to be altered and column widths adjusted; the >surplus license details should also be added to the closing.
The CONVRPT program supplies the user with a report for a range of transactions that have been converted.
The program asks for a date range for the transactions and the division code required. If the user requires all divisions all can be entered.
5. Ancillary Tools and Applications
5.1 Uploading a file to NOVUS
Wiki Guide pages: file upload
The following explains the procedure to upload a file such as a template document into the test system:
1. Select the file upload wizard at the top right-hand corner of the NOVUS dashboard.
2. Click next and navigate to the drive and source folder required.
3. Click the file, or files, to upload to NOVUS and add the policy number if appropriate.
4. Choose which option if the file with the same name already exists in the destination folder, and click next.
5. Confirm the selection and click next.
6. Click finish when file upload wizard completes.
7. The files will be visible in the navigation tree under the policy number.
For more information please see the file upload page on this wiki.
6. Bordereau Management
NOVUS endeavours to meet changing Lloyd’s standards. The system produces the general all included bordereaux and it is deemed the requirement of the client company to ensure all data fields are populated for the mandatory country requirements. NOVUS will lead the client user to fill out, for example, the NAIS (North American industry classification system) code for US partners, or the fiscale code for Italian clients, but cannot force the user in all circumstances to complete this data.
NOVUS will house the risk data that is entered into the system via the RISKNEW program screen. This program will use the relevant section type and risk items together with the premium, policy limit, section limit and excess.
The risk details (granular data on multiple premises locations for example) will be housed in the risk details screen (the RISKDETAH program in NOVUS).
Here, potential multi-location details are added with individual risk items that each enjoys as coverage which maps, applies, or calls on the correct sections, and carries the rate, premium per item, and excess per item.
This information is stored in tagged fields that populate the bordereau. The bordereau template that NOVUS houses are the v5.1 bordereau which is Lloyd’s compliant and presents the information in the format required.
NOVUS produces premium booked (written), the premium paid (settlement) and risk bordereaux.
Premium booked (PB): Comprises one row of data per section of a transaction. It will collect all risks with a transaction, that satisfies the collection criteria specified by the user.
For example Transactions for all risks incepting between states dates specified for carrier XYZ in USD.
No risk/policy transactions will appear on any subsequent premium booked bordereau, and that group of risks is tagged with a unique bordereaux ID. Currently, bordereaux are one currency at a time.
Premium paid (PP): Comprises one row of data per section of a transaction, whereby the client has paid, and the user has matched that paid cash to the transaction (or part-paid).
The system will collect all transactions, that satisfy the collection criteria the user specifies.
For example Transaction for all risks incepting between states dates specified for carrier XYZ in USD, it will only report those that have had cash movement.
No risk/policy transactions will appear on any subsequent premium paid bordereau (once that bordereau is posted and matched), and that group of risks, is tagged with a unique bordereau ID. Currently, bordereaux are one currency at a time.
Risk level bordereaux are similar to prem booked bordereaux. A transaction must exist to enable them to be reported but the data is expressed from a carrier exposure perspective, i.e. one row per location denoted in the risk details screen. This results in a clear division of what is a financial tool – PB/PP BDX and an exposure tool risk BDX.
The Lloyd's v5.2 Premium Booked (LK), Lloyd's v5.2 Premium Paid (LN) and Lyd Claim Reporting Tool Booked (CB) styles support Hong Kong requirements.
Supplemental information about bordereau can be found on the INBORD page
6.1 CHALIS Coverholder / Agent Spreadsheet Tool
6.1.1 Overview of the Conversion Process
Wiki Guide pages:[[Bordereau_Converter|bordereau converter]
To convert a bordereau to another destination format such as Lloyd's premium reporting template, the following steps need to be followed.
1. A bordereau style template needs to be created containing a list of column headings and data types. The ‘bordereau style’ is essentially a blueprint for a particular bordereau. The Acme Comm will be imported into the style creator, and a title and a type will be given.
The type given decides the direction of the data. If the bordereau contains source data that needs to be exported into the Lloyd's premium style, it will be marked as a source type.
2. When a source and destination style exists within the system, a mapping needs to be created. The mapping directs data from a source column and maps this to a destination column during the conversion process. There are several different column mapping types, each of which performs a different task and is outlined later in this chapter.
3. Finally, the source bordereau can be converted to the destination format and saved as a CSV file. If multiple mappings exist between a source style and destination style, all of these will be available during the conversion process.
The image below shows an example of the bordereau converter. Two columns in the source bordereau (first name and last name) have been combined into one column (cover holder name) during the conversion process. The style mapping has copied data from the source bordereau’s premium column to the gross premium paid this time column in the Lloyd's premium style.
See the bordereau converter page on this wiki for more information.
6.1.2 Creating a New ‘Bordereau Style’
1. Navigate to the CHALIS (Cover holder at Lloyd's insurance software) tab and select the bordereau converter icon:
2. Open the new style icon on the home tab:
3. Click the create style icon on the bordereau converter home screen.
Alternatively, navigate to the create new icon via the styles tab in the bordereau converter ribbon.
4. Click the browse button to locate a source bordereau spreadsheet in ‘.XLS’ or ‘.XLSX’ format.
5. Click the import button to load the spreadsheet into the program
6. Select the worksheet you wish to create a style for in the worksheet dropdown (refer to the errors section for any pop-up window indicating errors)
7. Select a style type from the type dropdown menu. This is used to define whether data comes from or is converted to this style and will be either source or destination:
8. Populate the style title box, this is how the style is referred to during the mapping process.
9. Click the spreadsheet title, to the right of the import button to populate the style title field. Click the column properties tab.
10. Locate the header row(s). To ensure that the header row(s) use the correct format, click the show workings button which will open the chosen Excel spreadsheet.
A copy of the original spreadsheet will open, and the header row should be selected. There may be two rows and only one is selected. To resolve this issue, select both rows by clicking on the top of the header rows and dragging the mouse downwards. Upon releasing the mouse, both rows will be selected.
11. Click the save selection button on the lower right-hand side of the spreadsheet, to return to the new style screen. The screen will look as below. Click the ‘column properties button on the style details tab, or select the column properties tab.
12. The data format, ‘CSV alias’ and ‘required’ dropdown options are used only if the destination is selected in the current style options.
|Data Format||If this is selected, any data that is copied into this column must be entered using the same format. For example, if a number is selected and during the conversion process, the data is text, and the data row will be discarded.|
|CSV Alias||This is used by Morning Data’s internal processing.|
If selected, during the conversion, the source column that is being copied into the column must be populated or else the data will be discarded.
13. Click the save style button to save the style ready for use in mapping.
6.1.3 Creating a Mapping
If there are at least one source and one destination styles in existence, a mapping can be created between them. Choose the two styles to map to each other.
1. Select the manage existing mappings on the mappings tab. This will display a list of existing mappings. Select the mapping title required.
2. To add or edit a mapping use the edit mapping screen to add column mapping and select the source column. The same source columns can be used multiple times for mapping purposes.
Select the destination column from the destination sheet, CHALIS highlights the columns that have already been mapped in the used column. A destination column can only be used once.
4. The mapped columns are added to the list.
Advanced mapping can be achieved which will offer further functionality on top of the basic columns to columns standard column mapping. The three other options available include: calculation column mapping; custom column mapping; multi-column mapping, and cell column mapping.
In the example below: selecting the calculation column mapping, the process would multiply the commission, and gross premium in the source spreadsheet into the commission amount field in the destination row:
The multi-column mapping, transformation shows the concatenation of values from two source columns to give a single value.
The custom column mapping’ option allows the user to specify a default value for the destination column for all rows.
If there is no existing mapping on the system, you can create a new mapping using the create new icon on the mappings tab, give the new mapping a title, and click save mapping.
6.1.4 The Conversion process
Finally, once the above stages are complete, the mappings will be available to export. Click the convert bordereau icon in the bordereau converter tab. Browse to the document you wish to use and select the available mapped sheet to export. Click the export button to complete the conversion.
6.2 Outward Bordereau - Reporting to Lloyd's Underwriters
Wiki Guide pages: OUTBORD
A bordereau is a report containing the data required to report an account to underwriters or insurers informing them how much they expect to receive or remit.
The London market regularly changes procedures in data handling processes. Various standards have been published and NOVUS provides the data for the published Lloyd's standard premium and claims bordereaux in Excel format. The ACORD (Association for Cooperative Operations Research and Development) standard risk level data has not been published for all classes of business but where possible a mapping has been provided.
The crucial difference is that premium bordereau, either booked or paid, contains one row per section. Risk bordereau contains one row per location. It is not feasible to place all risk level data on a premium bordereau, although some basic information is possible.
Premium booked bordereau will capture appropriate records that meet the criteria if they have a transaction, but will not be affected by any cash movement whereas premium paid BDX will show cash movements.
If you do not directly report to Lloyd’s, i.e. are a Lloyd’s cover holder or broker processing to syndicates who have a blocking account of LYD, then the report is as relevant to the entity to which it is reporting.
If reporting to a Lloyd's broker, it will report to the syndicate that the broker represents.
To determine whether a section needs to be reported as a terrorism section (for columns CR0059 Gross Premium paid this time and CR0060 Terrorism Premium), bordereaux scripts query whether the Section Type code (GID 18) is mapped to Section Report Group (GID 60) of TR, rather than where the Section Type code (GID 18) had ‘Is Terrorism’ checked (e.g. Is Terrorism = Y): GB (GPV Premium Booked), GP (GPV Premium Paid), TB (TOW Premium Booked), TP (TOW Premium Paid), LK (Lloyd’s Premium Booked V5.2), LN (Lloyd’s Premium Paid).
The Auto-ID Type field remains visible but read-only after the bordereau is created.
The output is produced in Excel, based on the input spreadsheet. In the 5 column mapping from the received bordereau into Lloyd's premium bordereau, any unmapped columns are left blank.
N.B. Please take note of where the chosen export directory is located. The conversion bordereau will likely be stored in NOVUS if previous files have been uploaded from NOVUS. Therefore ensure files have been saved on the local drive if that is where the files will be used.
The OUTBORD program offers the following bordereau options:
- Risk (exposure) format (if using risk details)
- Premium booked or paid
- Claim booked or paid bordereau to be produced for a given account code.
These options must be configured correctly in the CODES programme.
The NOVUS rules are that an exposure/risk bordereau will report one row per location as entered in the risk details screen. Without risk details, an exposure bordereau using risk details can not be selected. There must be a transaction on the risk, i.e. a firm order, before a record will be available in OUTBORD. If there are no transactions on a risk, the results will show a zero bordereau.
A starting guide for this is based on the London market glossary for the data elements per class that should be reported if possible. This data is collected via class-specific risk details screens. Additional data can be submitted for inclusion in future releases by specific request and will be reviewed in line with the system data structure plans.
A premium (booked or paid) and claims (booked or paid) bordereau will report one row per section of a transaction.
The paid status requires the record to have had cash movement since the last time the transaction was reported.
NOVUS supports several export styles. These are the presentation styles that are either predefined by an industry-standard such as Lloyd's premium reporting standard or may be specifically designed to your company's or one of your underwriters' requirements. These bespoke bordereaux formats will require additional specification and costing, priced on the level of automation and complexity. It should also be noted that bespoke bordereaux may be better considered within the REPGEN reports program.
A bordereau can be created from records that match several criteria. Selection options appear in the top panel of the screen. The grid will report the gross amounts of all relevant records found and will tag those records with the ID the user has provided (consult your internal naming guidelines for this).
A bordereau can be saved, re-run and checked before posting. NOTE: Once posted, the transaction records are not available to other bordereaux for the same combination (save for further cash movements on the same transactions). The posted bordereau will be available in the CASHENTRY program for bulk matching cash.
Note: If the bordereau ID has been posted in error, it will become locked and it will be necessary to contact a member of the Morning Data support staff via the support log.
7. Cash Management & Bookkeeping
The system has a full suite of cash management tools and then allows automatic feeding through period summary totals to the nominal ledger. This can be used in conjunction with Morning Data’s integrated purchase ledger to give a complete single system solution.
Please see the accounting page on this wiki for a full list of programs associated with the cash management tools and programs in NOVUS.
7.1.1 Cash Entry
Also referred to as allocation as cash can only be entered against approved partners per the company’s due diligence procedures. No partners should exist for items such as suspense etc.
Assuming there is no need for conversion – i.e. the cash is received in the currency in which the transaction was raised - the following process is deployed:
Auto-matching is available if payments exactly match the value of the debit note.
Selecting the relevant bank for the currency concerned risk multiple items can be entered for all cash received on that day in that bank.
On pressing F10 commit or clicking save an audited entry is sent to the user’s local printer.
NB: Audit trails can be enabled or disabled per user in the WHO program.
7.1.2 Cash Allocation
Enter MATCH in the shortcut box in the NOVUS main menu. This is an essential part of the accounting function. Following CASHENTRY, all transactions should be matched either to cash or to other transactions. To monitor the amount of unmatched cash the system has run UMCASH, and to have an overview of the longevity of unmatched transactions run AGED. The EMATCH program enables detailed enquiries on an account to be performed. The UNMATCH program enables previously matched items to be unmatched if necessary.
Enter the details for the relevant account, division, suffix (‘*’ for a client, ‘.’ for insurer) and the system will present the available cash and transactions outstanding.
The user selects the amount of cash they wish to match (Y for all) and then places a Y against each of the transactions that cash is to be matched to.
Note the balance on the bottom left is zero and thus the match can be processed.
After saving the cashbook can be viewed per bank account showing NL and IBA ledger items together using the ECASH program:
Reconciliation can be processed in the BANKREC program:
NB: Further examples of the use of these programs can be provided by Morning Data if required.
7.1.3 Bank Reconciliation
To reconcile the bank the BANKREC program must be used.
The bank reconciliation icon is in the accounts tab in NOVUS or type BANKREC into the NOVUS shortcut box.
In the bank reconciliation program, a list of cash entries, transactions and purchase ledger (if applicable) posts will appear in a list for the currency chosen. This shows what has been posted to the bank.
Enter the total of the bank statement, as this is what is to be reconciled.
To choose the items to be reconciled, enter Y in the ‘Rec’l’ column if an entry is not to be reconciled enter N.
The amount in the difference field must be .00 to allow the reconciliation to be processed.
Click the process button. An audit trail will print to the users’ default printer which must be kept for accounts.
A bank reconciliation audit report will be printed showing the start and balance.
The VATREP program reports net brokerage from the IBA (insurance broking account) for VAT. All amounts are reported in GBP.
7.1.4 Bank Charges
Bank charges are entered via the NL (nominal ledger) account.
To amend and view the codes will require the setting up of these codes via the CODES program.
To view the existing codes set up on the nominal ledger refer to the NLACC Program:
The STATEMENT program produces a statement of account for a business partner or range of business partners. This document shows any outstanding transactions that are due to or from the client and is used for credit control purposes. Statements are usually sent to a client monthly or on-demand to clarify why an amount of money is due. Statements can also be created for silent agents to summarise their commission paid and due. Insurer statements are less common as most business is done on a bordereaux basis which replaces that function.
Fields can be added to statement documents to further customise the document output.
7.1.6 Client Money Movement
The TAKEREV program enables revenue items in the IBA to be batched up, settled and matched in a single operation.
The program makes suitable cashbook entries as if cash had been entered through the appropriate IBA cashbook, matched against the revenue records in the IBA and then transferred to the office (target) account for that bank along with the necessary NL journals.
See the debit documents page for information on fields to be added to debit document dummies or templates. See the JNL page for information on inter-client and inter-company journals. The OSALLOC program can adjust outstandings within a transaction i.e. not necessitating a separate transaction followed by a matching operation.
7.1.7 Trial Balance
The trial balance TRIBAL is the sum of the nominal ledger (NL). In the NL every transaction is a double-entry that sums to zero so the sum of the NL must be zero.
The trial balance program has been designed to include all unposted totals as if they had been posted. The trial balance figures for unposted periods are subject to change as further transactions are entered. A trial balance covering the current or future periods must be regarded as projected or provisional".
The NLFINS program produces a report which shows the profit and loss and balance sheet.
7.2 End of Month routine
Entering '<' into the cur per field in the CALENDAR program blocks posting to the IBA and purchase ledgers in previous periods. Assuming that your processing is up to date it is recommended that the current open period is advanced (using the CALENDAR program) at the close of business on the last day of the period. The current open period can be moved back by the user if any items have been missed, although care should be taken that no users post current period transactions into the previous period whist it has been unblocked.
The PERIODEND program closes the period permanently. This prevents posting to the nominal ledger (NL), so once a period is closed the NL cannot be changed. Users cannot un-close a period.
Periods can only be closed in sequence. All periods must be closed before the YEAREND program can be run.
If accounts are to be prepared each month the following reports should be run, renamed, and saved/printed at the close of business on the last day of the period.
As with all grids, the ability to group and filter is enabled using the yellow filter bar and by dragging the column heading by which grouping is required (and subgrouping).
The ACCLIST program can be run in detail or summary mode. Summary mode allows for additional information to be added using the column sorter, as found on the bottom right-hand side of the program (next to the hide grid icon).
The AGED program report can be based on instalment date, accounting date, payable by date, and original accounting date. Output can be for one or all divisions, currencies or suffices (roles).
NB: Write off amount can never be outstanding; it is a debit/credit amount that has been written off - so by definition, it cannot be outstanding.
The unmatched cash report should be run as part of the end of month routine as well as to monitor the amounts of unmatched cash. Having high amounts of unmatched cash is undesirable; this should be processed as soon as possible using the MATCH program.
Each year end is processed using the year-end closing exchange rate for balance sheet items and the journal (booked) rate for profit & loss items.
The universal report generator holds a list of reports for a variety of tasks. After launching the REPGEN program, navigate to one of the reports and fields and click on go to report. The reports are arranged on various tabs. These reports are set in the REPSETUP program, and the tabs are set up in the CODES, and REPGEN tab groups.
The first tab defaults to show reports. This tab will show reports that are available on all other tabs.
The user will then need to enter the parameters for the report. Many of the parameters will be via drop-down lists, but some will need to be typed in.
TB_FRS5_xxx - trial balance to IBA debtor/creditor reconciliation)
REAL_BROK_xxx -(realised brokerage)
UNREAL_BROK_xxx -(unrealised brokerage)
FSA_REC_xxx - (client money reconciliation)
These should be used in conjunction with the TAKEREV program.
Each year-end is processed using the year-end closing exchange rate for balance sheet items and the journal (booked) rate for profit & loss items. Use the YEAREND program to do this, and see EOYCUR for more information on preserving current rates of exchange.
Wiki Guide pages: WORKFLOW
The WORKFLOW program will show the history of a policy over the last three years:
The user can expand one year and get a high-level view of the policy position and run the document tracking log which allows system documents to be tracked together with additional document items added and tracked.
8. Nominal Ledger
Wiki Guide pages: nominal ledger
The nominal ledger is the name given to the list of the nominal codes (accounts) that are set up within the accounting structure. This list of NL codes is known as the ‘chart of accounts'. This details all of the different pots into which transactions can be allocated.
8.1 Purchase Ledger
Wiki Guide pages: purchase ledger
The purchase ledger suite of programs gives NOVUS the ability to enter all purchases into the ledger, enter payments, print remittance advice, aged balances, account listings and VAT reports. It is fully integrated with the NOVUS nominal ledger and cashbook.
8.1.1 Adding Supplier Account Details
The PLACC program allows the user to create purchase ledger accounts or add supplier information to NOVUS.
If the supplier account reference name is not in use on the system, the short name will be created from the supplier A/C field.
The VAT code field has a list of values (F9) which will return the available VAT codes listed in the CODES program.
The default NLACC field list of values (F9) shows the NL accounts which have been created in the nominal ledger account codes program. This can be left blank if the supplier is not fixed on one product.
The EPLACC program enables queries to be carried out for details entered in the PLACC program. Double-clicking on the ‘balance due to date’ field will give an explosion of the outstanding items in the currency selected.
8.1.2 Posting Transactions to the Purchase Ledger
Transactions post directly to the nominal ledger (NL) so the nominal ledger account code in the NLACC program must be correct as the costing will appear on the trial balance and any other subsequent costing reports.
The reference (narrative) will automatically default to the reference for the nominal ledger account, but this can be overwritten with the user’s preferred reference.
The net amount will be calculated automatically from the gross amount if the VAT code appears in the supplier account details.
When the post has been committed using the F10 key, or by clicking the post to PL button, the transaction will be posted and the following message will display:
NB: The cursor must be in the div field to post the transaction.
The NLPOST program is used to enter a new batch into the nominal ledger (NL), or to revisit a batch that will no longer be posted.
Please see the webservices page on this wiki for examples of the XML equivalents inserted into the NOVUS database.
8.1.3 Purchase Ledger Payment and matching
The mandatory account field refers to the supplier account reference. Enter the bank account which will make the payment. If the incorrect bank account is used, reconciliation will not be possible.
Enter information into the remaining fields leaving them blank unless the transaction number is known. A selection of transactions for the account will appear under the Transactions and Journal section.
The dis field enables the user to set the invoice to dispute. Hover over the pay field and a drop-down list of available types is made available: (Y) fully match, (P) part match, and (N) do not match.
The save payment button will take the cursor to the bottom section of the screen. The type of field is either CSH (cash), CHQ (cheque), BACS (bankers’ automated clearing services), or DDE (direct data entry).
Click F10, or the save payment button to save, post the transaction to the ledgers, and produce an audit report.
8.1.4 Purchase Ledger Aged Creditors
Wiki Guide pages: PLAGED
The PLAGED program produces a list of outstanding transactions by either total or detail. The F9 shortcut key returns a list of the suppliers' account codes, the dates can be amended.
The options section of the screen will return a full list of currencies (all) and a report with all available division codes. The F9 key, or double-clicking in this field will return a list of divisions. In the report type section, the total will report the account and the total that is outstanding, showing one line per supplier. The detail option will return the amount outstanding plus the transaction number.
The icons will enable a report to be produced and displayed on the screen, imported to Excel, or sent to the default printer.
Wiki Guide pages:LINEAGE
Lineage is known as a "Canadian facility" or a premium feed that creates a list of all data from a spreadsheet and entries into the system.
Lineage data is not supported by risk information in NOVUS. The premium on the LINEAGE feed on Canadian cover holders goes directly to Lloyd's.
The posting period must be one month after the `period to` for the lineage feed.
For example, if the lineage feed is for January 2019 then the IBA posting period must be February 2019.
The user will be asked to confirm the accounting date as being the actual date the posting is being made.
9.1 Program Codes
Wiki Guide pages: CODES
In the CODES program, click add new code to add a code (caution and company policy should be considered when inventing new codes).
A list of all the codes and their impact can be found in the NOVUS wiki guide when the CODES program is invoked.
NB: Access to the CODES program should be controlled.
Double click to modify a group or description. Codes cannot be deleted by the user.
9.1.1 Program Counters
The COUNTERS program displays sequential numbers and counters. The screen shows how the system controls the numbering of all aspects of the business including policy numbers, quotation numbers etc. The system counters are pre-defined; it is not normally necessary to add a new counter. The database administrator (DBA) will set the counters to the required initial values.
This program contrasts with the COUNTERS program which is advised to be accessed by a system administrator only.
9.2 New Partners
Partners are any legal entity with which/whom business is transacted or on behalf of commercial insurance. Intermediaries will perform due diligence on each business partner they intend to trade with. These may be insurers, other brokers, clients both businesses and individuals, loss adjusters, and assessors, third party agents, MGA’s, cover holders, Government agencies etc.
Each requires a partner record and, in the UK, should be subject to regular sanctions checks. It does not specify the frequency, but at the time of printing, the source lists for OFAC and HMT are updated once per week. It would be appropriate to check the whole partner list against these lists monthly. However, you must consult with your compliance officer for your internal protocol in this area.
- All fields marked with an asterisk (*) are mandatory
- Enter the stopped flag as Y for partners that are no longer permitted to be traded with.
- These partners can be restricted on certain divisions and transactions in certain currencies can be configured in the partner A/C (access control) field.
- An ad-hoc sanctions check can be requested during creation, subsequent checks will be performed at the scheduled time.
NB: If the system is set to Shari'ah-compliant additional fields may be visible. Please consult Morning Data.
Completing the information with as much data as possible will enable more accurate results in the sanctions checker.
Several of the fields on the business information tab are mandatory for some classes of business in some territories for London market reporting. It should be part of the internal procedures to ensure this data is acquired, Morning Data recommend it is always filled out if available – i.e. FCA reg will not apply to non-insurance entities.
The co-broker field will enforce a prompt for that party to be added alongside this one when used on a market.
The client and U/W fields are used for default blocking accounting parties. These fields are most commonly used when a party blocks a bureau, for example, a syndicate to Lloyd's (LYD)
If this partner is a carrier then its ID (pseudonym) and number are added. If a cover holder then its PIN should be entered.
The N/A tax codes field contains a list, separated by commas, of taxes created in the FEES program.
- The program group that the PARTNER has been tagged within the TITLE program must exist in the user’s profile in the WHO program.
- The stop flag can only be set to N by a user of level 8 or above, but all users with access to the PARTNER program can add a partner and request an ad-hoc sanction check.
- A partner with a stop flag set to Y cannot be used on a market in the MART program.
- Both the full name and trading as fields are sent to the sanction checker.
- If no address is included the accuracy of the results may be less useful.
- If trading as, short name, or full name fields are updated, the record is automatically resubmitted to the sanctions checker.
- There is currently no check-in in either the CASHENTRY or CLMMEN programs to recheck parties due to receive funds.
For ad-hoc checks click the sanction check button at the bottom of the window.
When the partner has been sent to the sanctions checker it will go into a queue. Sanctions status panel results will be visible to all users:
Reports can be opened and saved for any failures:
For further information please see the sanctions checker page in this wiki.
9.2.1 False Positives
The user who is denoted as the compliance officer in their user profile in the WHO program, will be able to access failed partner false positives by right-hand mouse clicking on the entry in the sanctions status panel and selecting review.
False positives due to lack of address.
Multiple false positives due to a similar name.
If entries are set as false positives, the partner entry must have its stop flag set to N, manually by a suitable authorised person – Level 8 or above in the WHO program.
Submitting any false positives with the false-positive box checked will prevent them from being flagged again for the partner.
The compliance officer will receive an email once a month with a list of all the reviewed matches.
The full PARTNER table will be rechecked once a month or at the frequency configured for regular and frequent changes against the source Lists in your configuration.
9.2.2 Partner lists
The EPARTLIST program lists all PARTNERS. The screen behaves like all other enquiry screens in the system, allowing filtering and grouping to be performed and new columns to be added from the column sorter.
Information of the current status of the partner's sanctions check is visible as well as their VAT status and if they are stopped, or not, by default.
The suffix column shows all the roles that the partner is authorised to operate within the system.
Null suffix denotes no role, which includes original assured/insureds/policyholders with whom there are no direct financial trading relationships permitted.
Searching for partners using the yellow filter bar.
The column customisation button displays a list of columns not currently on view which can be dragged to the column bar for inclusion. The new column can then be used in the yellow bar filter area.
A new partner (original insured/policyholder only) can be added to a new risk or quote. An ad-hoc sanctions checker can also be requested from the RISKNEW new partner popup.
Double-clicking on a partner in the EPARTLIST program, or a right-hand mouse click from a partner in the account section of the navigation tree will open the record in view mode.
The balances tab shows current balances for the partner acting in either a client capacity or a company capacity. These are shown in each relevant currency that has entries in the ledger.
9.3 Currency Management
A currency is considered by the system to be a destination currency once a bank account has been set up in that currency. The currency for a bank account must first be created in the currency table.
Until a bank account is created in that currency, it is deemed to be convertible. On creating the first bank account in a currency, the system treats it as a banking currency and automatically creates period summary tables for the current period.
9.3.1 To add a currency
Use the add button at the bottom of the screen to create a new currency. It is recommended that the ISO (international standards organisation) code is associated with the currency when creating a new currency. Ensure that the information is completed as accurately as possible. Once a new currency has been added it will display in the currency list providing that the record has been saved.
- Enter the currency table screen
- Click create record to add a record
- Complete the fields described above
- Press [COMMIT] to save the details
- Repeat steps 3 and 4 until all currencies are added
- Click the close button
The CUR program allows the user to enter a currency with its symbol and set up its exchange rate. The base currency is defined in the system parameters table SYSP. The system provides an automatic update program for rates of exchange from data over the internet (see the rate of exchange updates page on this wiki for more information). The ECUR program allows enquiries to be made on currencies.
The CONV program converts instalments on a transaction from a source currency to a destination (banking) currency at a user-defined rate of exchange. All lines on the instalment are converted at the same rate of exchange.
The UNCONV program will unconvert a single instalment in a transaction if an error has been made.
Rates of exchange are used in convertible (non-banking) currency transactions and the rate of exchange stored in the database is that of the convertible currency for the proposed banking currency. If the base currency is set to GBP, a transaction in a non-banking currency, say, ZAR, with a proposed destination currency on the conversion of USD, will carry the compound rate of exchange of ZAR: USD not ZAR: GBP.
By default, the program shows the currencies as of today’s date which means it will display the latest exchange rate for the currencies. This date can be changed to show what an exchange rate was on a particular day.
The other option in the currency section will show rate changes between a specified date range. This will display all rate changes during that period.
To show a particular currency, use the search box to narrow down the selection of results by typing to show the filtered list.
To view the history of a currency, double click on the card to display the history tab. This displays a breakdown of that currency, when it was changed, the old rate and new rate and whether the rate increased or decreased.
The ROX update program enables NOVUS to download the latest currency exchange rates from a third party currency data feed supplier such as Xe.com.
9.3.2 To edit a currency
Once a currency has been created the currency code, and the date changed field can not be edited. All other fields can be edited by clicking on the relevant field. Once a field has been edited switch to another currency or tab to another field to ensure that the program records any changes. Click the save button to commit the changes.
9.3.3 To delete a currency
It is recommended to delete currencies from the system, however, this is permitted when the currency has not been used. If the currency has been used in the ledger, the system will not allow it to be deleted. Checks are carried out to ensure that an active currency is not deleted, if an attempt is made to delete a currency that is in use, a message will appear detailing the problem.
9.4 Adding a year to the Calendar
Wiki Guide pages: CALENDAR
The calendar enables any date to be assigned to a year and period. Normally, the financial year is divided into 12 contiguous (sequential in time but not necessarily consecutive) periods aligned to the Gregorian calendar. The calendar dictates into which period IBA transactions will be aggregated in the period summary totals. Similarly, it is used to determine the appropriate period for NL postings.
To add a year to the calendar:
1. Launch the CALENDAR program to perform maintenance on the calendar
2. Type in the next sequential year.
3. Select Y in the auto-build field to assume monthly intervals.
4. Enter the base date from when the calendar is to begin.
5. Tab to the next field. The calendar will automatically build.
6. Press F10 [COMMIT], or click the save and close button
The calendar enables any date to be assigned to a year and period. Normally, the financial year is divided into 12 contiguous periods.
The calendar dictates into which period IBA transactions will be aggregated in the period summary totals. Similarly, it is used to determine the appropriate period for Nominal Ledger postings.
The current period is shown by a ‘<’ symbol in the current period column. Clicking on a lower line in this column will make the following period current.
Postings are not permitted to periods prior to the current period. To make this clear, the current period is often referred to as the first open period.
9.5 Bank Accounts
A nominal ledger account code NLACC and bank opening balance are required to set up a bank account.
For each of the IBA bank accounts, a corresponding office account must be denoted in the office column. These could all be the same office account. To edit any details click the edit button on the right-hand side of the entry as shown below:
9.6 User Management
The WHO program displays a variety of attributes for each user. The profile tab includes their login details, email address and telephone number, departmental details, job roles such as compliance officer or producer, and whether they are head of the department.
The accounting tab shows the rate of exchange variance, write off maximum allowed, and authorised limits.
The security tab shows the authorisation level for the user and which program group the user can access. Program access operates in partnership with the TITLE program which sets the group level for each program.
The audit trails tab will create audit trail outputs for a variety of reports.
Settings such as department, their role (compliance officer “C” or producer “P”) and which program groups the user can access are all created here. Program access operates in partnership with the TITLE program which sets the group for each program.
The list of programs is divided into groups. For example, accounting query screens may be in a different group than accounting maintenance/processing screens. A user may have access to one or other or both of those groups.
The groups are simply expressed by a chosen letter of the alphabet, NOVUS is configured to start with a group S- known as security to group programs that require specialist knowledge to understand the impact of changes.
The EWHO program allows users' details to be viewed in a read-only manner without the ability to update them.
To add images to the user profiles, please see the photos and signatures page in this wiki.
9.7 Themes and Skins
NOVUS has a collection of skins and themes to change the way it looks and feels. Clicking the artists’ palette icon in the upper-right toolbox will open a list of available skins and themes.
Selecting one of these available themes will change the way NOVUS looks. Built into the list are several standard Office styles. The default theme is Office 2010 Blue.
Office 2010 Black
9.8 Send Logs
The send logs icon allows for a package of the issues and files to be submitted to the support desk for the team to decipher what happened on the system. The send logs icon is accessible from the top right of the NOVUS dashboard.
A large number of support calls to Morning Data involve a request for screenshots being sent by the user.
When a user clicks the send logs icon, a screenshot is taken and included in the log files that are uploaded to the support website. Morning Data will be immediately notified that the files have been uploaded and a member of the support team will contact you as soon as possible.
9.9 Outlook Integration
Wiki Guide pages: Outlook viewer
NOVUS has an email viewer panel, located in the bottom tab section. If the Outlook integration module has been enabled, NOVUS will show a user’s inbox, allowing the user to attach emails to risks, quotes and claims.
Users who sign in via Office 365 will find their email folders available to them inside NOVUS and can be attached to policies, accounts and claims. The folder name at the left of the main grid contains all folders and sub-folders of top-level folders. Users who sign in via the IMAP protocol only have access to the inbox and sent folders.
New emails received by the user appear automatically in the main grid. Users logging in via Office 365 will be able to see the unread/read message status, and if they are opened within NOVUS the read status of the message will be updated on the mail server.
When the user reaches the bottom of the visible list of emails, if there are more messages at the mail server, 10 more messages will be retrieved.
The first time users who have the email integration enabled launch the latest version of NOVUS, they will be greeted with one of two methods of logging in. Once authenticated users will not be prompted for their information again unless NOVUS is unable to authenticate.
Users logging in via Office 365 will be asked to log in to their account during the launching of NOVUS, this includes any prompts for multi-factor authentication. This window can be closed to continue into NOVUS without signing in. If authentication is successful NOVUS will ask for the permissions required to access your mailbox and work with your emails.
To attach/ upload an email to a quote/risk/claim/account
- Select the email to be attached in the Email Viewer panel
- Right-click the email and select attach email.
- If attaching to an account, do not enter a quote/policy number and year, just enter the account code
- If attaching to a quote/policy populate quote/policy number and year
- If attaching to a claim, select a claim number, else skip this step
- Rename email if required
- Click the attach email button
To change email folder focus
Users can change the folder displayed within the email viewer window to any folder they choose. To do this:
- Open NOVUS and click on the tab containing the NOVUS icon.
- Select the System icon
- Select Clear Email Credential Cache from the options available in the system menu.
- Completely exit NOVUS.
- When you next log in NOVUS will prompt you to go through the email setup again, and you can choose which folder you wish to focus on when NOVUS opens.
9.10 No Database Connection
If this is the first time that NOVUS is opened then a popup window may appear requesting details for a database connection. In this instance please call Morning Data support for the information to be entered.
9.11 Check for default printer
1. If there are Windows default printers but not installed printers a message is returned:
" NOVUS could not locate any printers connected to this computer. Without a printer, it will not be possible to print documents or reports from NOVUS. Please contact your IT support team to get access to a printer. You can continue but you may receive further messages relating to this issue."
2. If there is no default printer, but there are printers installed on the PC, a message is returned:
"NOVUS requires the use of a default printer and it appears there is no default printer currently selected. Please select a default printer from the dropdown below."
3. If there is a default printer, the default printer icon in the reports tab shows the default printer.
V 6.4.0 - Updated to the latest version.
Version History V 7.0.0 - Updated to the latest version.