oracle quantitative management and reporting for solvency ii

Oracle Quantitative Management and Reporting for Solvency II

Administration Guide – 2.1.1


Administration (Implementation) Guide

Release 2.1.1

Purpose ................................................................................................................................. 2

Introduction .......................................................................................................................... 2

QMR Overview ..................................................................................................................... 2

Installing QMR ...................................................................................................................... 2

Financial Close Suite Version............................................................................................... 2

HFM Format ......................................................................................................................... 3

Installation Guidelines ........................................................................................................ 3

Implementing QMR for FCM .................................................................................................. 6

General Considerations ....................................................................................................... 6

Load Procedure ................................................................................................................... 6

Implementing QMR for FDM .................................................................................................. 7

General Considerations ....................................................................................................... 7

Load Procedure ................................................................................................................... 7

Implementing QMR for HFM ................................................................................................ 19

General Considerations ..................................................................................................... 19

Calendar/Profile ................................................................................................................ 19

Metadata ........................................................................................................................... 20

Member Lists ..................................................................................................................... 38

Rules ................................................................................................................................. 39

Data Entry Forms .............................................................................................................. 51

Financial Reports .............................................................................................................. 53

Working with Data ............................................................................................................ 55

HFM Files for FDM ............................................................................................................. 57

Glossary .............................................................................................................................. 59

General Terms ................................................................................................................... 59

Technical Terms ................................................................................................................ 60



Purpose

This guide is designed for administrators implementing the Oracle Insurance Quantitative Management

and Reporting for Solvency II (QMR) application.

This guide assumes that administrators are already familiar with the structure and usage of the

Hyperion Financial Close Suite products: Financial Close Management (FCM), Financial Data Quality

Management (FDM), Hyperion Financial Management (HFM) and Financial Reports (FR). This guide

focuses on how to implement the QMR application. Please refer to the relevant sections of the

individual product Admin and User Guides for further information related to the Financial Close Suite

products.

Introduction

QMR Overview

The Oracle Insurance Quantitative Management and Reporting for Solvency II (QMR) is designed to

provide a starting point for a new implementation of Hyperion Financial Management (HFM).

The current version of the QMR application is designed to produce validated Quantitative Reporting

Template reports as required by the European Insurance and Occupational Pensions Authority (EIOPA)

for both group and solo reporting. It provides the capability for users across the organization to load or

enter the required data and generate Solo reports. Data required to be reported at Group is

consolidated and reported accordingly.

Note that QMR 2.1.1 is based on the July 2012 QRT Consultation Packs and the associated October

2011 Draft Implementing Measures.

Installing QMR

Financial Close Suite Version

The application has been developed and tested on Financial Close Suite 11.1.2.1, 11.1.2.2 and

11.1.2.3. Other versions of the Close Suite are not supported.

The following or a more recent FCM Patch Set Update (PSU) must be applied:

- FCM 11.1.2.1: PSU: 11.1.2.1.103

The following or a more recent FDM PSU may be applied (but is not mandatory):

- FDM 11.1.2.2: PSU: 11.1.2.1.301

- PSU 301 resolves the issue of Validation reports not opening on completion of the data load.

Reports can still otherwise be opened manually if PSU 301 is not installed.

The following or a more recent Financial Reporting PSU must be applied:

- FR 11.1.2.1: PSU: 11.1.2.1.133

- FR 11.1.2.2: PSU: 11.1.2.2.305

The following or a more recent HFM PSU must be applied:

- HFM 11.1.2.1: PSU: 11.1.2.1.601 plus PSE 16709689

- HFM 11.1.2.2: PSU: 11.1.2.2.304



HFM Format

The current version of QMR is built using the HFM “Classic” files and not using EPMA or Calc Manager.

Installation Guidelines

Components

The QMR application consists of a number of files:

Application Files

• HFM Calendar/Profile

o Two files with descriptions in English only (EN), one for HFM 11.1.2.1, another for 11.1.2.2 and

11.1.2.3

o Two files with descriptions in English, German, Spanish, French, Dutch (EN, DE, ES, FR, NL)

• HFM Metadata (XML format)

o Two files with descriptions in English only (EN), one for HFM 11.1.2.1, another for 11.1.2.2 and

11.1.2.3

o Two files with descriptions in English, German, Spanish, French, Dutch (EN, DE, ES, FR, NL)

• HFM Member Lists

• HFM Rules

• HFM Data Entry Forms

• Financial Reports

• FCM Task Lists

• FDM Import formats, adaptors and reports in a single XML file

o one file is provided for each different version of FCS (11.1.2.1 / 11.1.2.2 / 11.1.2.3)

o one file is provided for use with an Oracle and another for a Microsoft SQL database

• Data

o HFM EIOPA defined correlation and scalar factors

o HFM Sample data

o FDM Sample data

• Localization

o Metadata description localization files for use with the Metadata Localization Utility translating

QMR descriptions from EN to DE, ES, FR, NL

o The HFM Localization Utility that can be used with the localization files is provided as part of an

HFM installation. For implementations earlier than 11.1.2.1.600 or 11.1.2.2.301, patch number

14361678 is available for download on the Oracle Support web site.

• Documentation

o QMR Administration (Implementation) Guide

o QMR Administrator / User Guide

o QMR Readme



A security file for HFM is not provided. It is anticipated that security will be established differently for

each client using QMR and therefore no pre-built standard is deemed to be practical.

When implementing the HFM files provided in the QMR application, the application administrator may

wish to modify existing metadata descriptions, add metadata members, or modify web data entry

forms or reports. It is recommended however that existing metadata labels not be changed or existing

rules / web data entry forms / financial reports may no longer work as expected. The notable

exceptions are the Entity dimension which is expected to be completely customized for each client, and

the Data Source members which can be removed, changed or added to (with the exception of the

[None] member which must be retained).

Implementing QMR 2.1.1 or upgrading from QMR 2.1.0

The functionality provided with QMR 2.1.1 is essentially the same as QMR 2.1.0 and both are based on

the EIOPA July 2012 QRT Consultation Packs. Therefore most of the files used to install QMR 2.1.1 are

the same as (and remain numbered) QMR 2.1.0. Reloading the Financial Reports zip file (not required

for an upgrade) will retain the QMR 2.1.0 folder label.

QMR 2.1.1 incorporates:

• Support for FCS 11.1.2.3:

o HFM Profile (Calendar) and Metadata files for 11.1.2.2 are identical to 11.1.2.3 files – for an

11.1.2.3 implementation, use the files labeled 11.1.2.2

o FDM XML files are specific to the version of FCS installed – use the files labeled for the specific

version required

• Minor functionality updates

o Two updates have been made to the QMR 2.1.1 metadata

� The addition of seven ISC Country Codes not included in QMR 2.1.0, for a total of 249

countries (AQ, BQ, CW, GS, IM, PS, SX)

� The addition of eight base Assets accounts and two parent account, to provide for more

complete validation of Assets-D1 data with Balance Sheet accounts in accordance with the

EIOPA Assets-D1 log file

o Two updates have been made to the QMR 2.1.1 Rules file

� A correction of a mistyped variable, resulting is incorrect triangulated exchange rates being

extracted for FDM schedule translations

� An update of the Assets-D1 to Balance Sheet validations

o One update has been made to the BS-C1 report

� Inconsistent formatting (missing thousands separator) on some rows of data has been

corrected

o One update has been made to the LCM forms zip file

� Incorrect syntax in the OnDemand rules keyword in the Global Admin Extract for FDM form

has been corrected – the individual form did not require updating

• Minor documentation updates

o Updates to the Admin Guide for:

� FSC 11.1.2.3 support

� More clarity on the loading and registering of FDM adaptors



To implement a new QMR 2.1.1 application:

1. Load the FCM and FDM files as described in detail later in this guide.

2. Modify the HFM Profile (Calendar) file if required and create the application.

3. Modify the HFM Metadata file. As a minimum, replace the sample entity dimension with client-

specific entities and structures. Modify other dimensions as required. See further details on what

can and cannot be modified later in this guide. Load the modified metadata file.

4. Load the Member Lists and Rules files.

5. Load the Data Entry Forms, either individually or from the LCM file provided.

6. Load the Financial Reports, either individually or from the ZIP file provided.

To upgrade an existing 2.1.0 application to 2.1.1, the following steps are suggested:

1. Backup the HFM application.

2. Load the QMR 2.1.1 HFM Metadata file using MERGE mode and select ONLY the Account and

Custom2 dimensions. The new Account and Custom2 updates will be merged with any client

specific updates to the 2.1.0 version.

3. Extract metadata from the application and edit the extracted XML file.

4. “Remove from parent” all of the Investment Fund Assets accounts from the original parent (all

“Assets_Inv…” accounts). These will have been placed under two parents by merging the 2.1.1 file.

Make sure that these accounts are removed from the old parent but are NOT deleted from

metadata.

5. Save the updated HFM metadata XML file and reload using REPLACE mode.

6. Reload the 2.1.0 HFM Member Lists file.

7. Load the new 2.1.1 HFM Rules file.

8. Load the individual EntityExchangeRates_Extract form IF the forms LCM zip file was originally used

to load all forms - this will enable the OnDemand rules in the form for HFM 11.1.2.2 / 11.1.2.3

implementations but will have no affect on HFM 11.1.2.1

9. Load the replacement BS-C1.des report file.



Implementing QMR for FCM

General Considerations

QMR provides a guideline for standard best practice to support QRT reporting. These practices /

procedures are documented as tasks in Financial Close Management (FCM). There are over 80 tasks

which are created as part of the application and can be further extended and modified to meet specific

customer requirements.

Load Procedure

The QMR application provides best practices tasks in English (EN) plus German (DE), Spanish (ES),

French (FR) and Dutch (NL). These are provided in separate csv files, one for each language. Three

fields Name, Description and Instructions are translated into the language provided.

EN: QMR_2.0.0_FCM_EN.csv

DE: QMR_2.0.0_FCM_DE.csv

ES: QMR_2.0.0_FCM_ES.csv

FR: QMR_2.0.0_FCM_FR.csv

NL: QMR_2.0.0_FCM_NL.csv

• Open the QMR_2.0.0_FCM_<language code>.csv file in Excel or a text editor.

• Update the following fields:

o Owner

o Approver

o Reviewer

These fields have been documented to default to the admin user and can be changed to a specific user

if required.

• Create an FCM Template. Ensure that the minimum start day is -4 and the minimum end day is 14.

• Click on the Template in the Template Management dialog.

• Select Import Tasks.

• Browse to the CSV file that contains all the tasks. Click OK.

All necessary tasks should be uploaded. Modify the tasks if required using the FCM web interface.

Once the tasks are finalized, they can be executed for a particular period.

• Select the template in the Manage Template dialog.

• Click Create Schedule.

• Select period and map days to actual dates.

• Click OK and then start schedule.

To upload a translated CSV file, ensure that the browser language is set to English (EN) before

importing the alternative language file. After the file is imported, the browser language can be reset to

the required language.



Implementing QMR for FDM


FDM is used for loading, validating and reporting the Assets schedules (except D3), Technical

Provisions schedule F3, F3A and F3B, IGT and RC schedules. These schedules are reported for group

and solo entities.

Load Procedure

Once the QMR application is set up in FDM, the following 15 QRT schedules can be imported, validated

and reported:

• QMR-Assets-D1 - Investments Data - Portfolio list – Annual

• QMR-Assets-D1S - Structured products Data - Portfolio list

• QMR-Assets-D2O - Derivatives data – open positions

• QMR-Assets-D2T - Derivatives data - historical derivatives trades

• QMR-Assets-D4 - Investment funds (look-through approach)

• QMR-Assets-D5 - Securities lending and repos

• QMR-Assets-D6 - Assets held as collateral

• QMR-TP-F3 - Life obligations analysis

• QMR-TP-F3A - Only for Variable Annuities - Description of guarantees

• QMR-TP-F3B - Only for Variable Annuities - Hedging of guarantees

• QMR-RC - Risk Concentration

• QMR-IGT1 - Equity type transactions, debt & asset transfer

• QMR-IGT2 - Derivatives

• QMR-IGT3 - Internal Reinsurance

• QMR-IGT4 - Cost sharing, contingent liabilities, off BS items and other IGT

Prerequisites

• Ensure that an FDM application has been created for QMR. All of the following actions will be

performed against the created FDM application.

• Ensure that the FDM Adaptor to load data to HFM has been created and configured for the FDM

application (as detailed in the relevant Target Adaptor ReadMe document). This step must be

completed BEFORE the QMR XML file is loaded to ensure that a QMR-specific adaptor does not

become the system adaptor.

• All QMR-specific locations will support import into FDM for validation of the load file contents and

for QRT schedule reporting. Note that the validation is completed as part of the file import process

and does not require that the FDM “Validate” step be completed. If the Validate step is carried out

by the user, an error will occur.

• Note that the Assets D1 data will be loaded to FDM QMR-specific location only for reporting. This

Assets D1 data will also need to be loaded to HFM in summary for validation against data reported

for the Balance Sheet.



Setup - Import, Validate and Report QRTs

• Open and log in to FDM Workbench.

o EPM -> FDM -> Workbench -> Workbench Client

• Import QMR FDM artifacts.

o Select File -> Import… and select the QMR FDM xml file from the QMR application zip file:

� Select the appropriate file for the version of FDM installed (11.1.2.1, 11.1.2.2 or 11.1.2.3)

and the database on which FDM has been installed (MS SQL Server or Oracle).

• This would create all the necessary QMR custom adaptors, reports, import formats and validation

scripts.

• Open and log in to FDM Web client.

o EPM -> FDM -> Web Server Components -> Web logon

• Create QRT locations for import and reporting

o For each QRT schedule (total of 15), create one location (e.g. QMR-Assets-D1, QMR-RC).

Multiple entities can be loaded to single location. This is required for reporting across entities.

o For each location, specify the following:

� Child of ControlsReview and select type Data Load.

� Specify name (e.g. QMR-Assets-D1).

� Select Load Type -> Bulk Insert

� Bulk Insert is recommended over SQL Insert for performance reasons. Please refer to the

FDM Administration documentation for the necessary steps to setup the Bulk Insert option,

or to support article: https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1078450.1

� Select Target Adaptor, pick the correct custom adaptor that matches the correct QRT (e.g.

QMR-Assets-D1).

� Select the Workflow Behavior tab and the correct Import Format (e.g. QMR-Assets-D1).

• Set up Periods per QMR adaptor

o Make sure periods are set up for the Global adaptor.

o Open the MetaData -> Control Tables menu.

o For each QMR adaptor in the right drop down.

� Set up Target (M) and Year Target.

o Update Grid.

• Set up Categories per QMR adaptor.

o Make sure categories are set up for the Global adaptor.

o Change the left drop down to Category.

o For each QMR adaptor in the right drop down.

� Set up Target category (e.g. Actual).

o Update Grid.



Consolidation setup in FDM

• All Asset and Technical Provision QRT’s in FDM perform consolidation logic (aggregation,

translation, and elimination).

• For consolidation FDM needs the HFM entity hierarchy, default entity currencies and exchange

rates. In order to load this information to FDM, an ability to create the appropriate files is provided

to the administrator of the QMR application in HFM. For further details, please refer to the HFM

Files for FDM on page 57.

• Once these files are created, the administrator should then make them available on the FDM

environment for consumption.

• First, the entity hierarchy and default entity currencies entries are setup by running script:

webQMR_Setup_Entities

• Before running the webQMR_SetupEntities script, ensure that the QMREntityDefaultCurrency.txt

and QMREntityHierarchy.txt files have been created either manually or from HFM

• Copy QMREntityDefaultCurrency.txt and QMREntityHierarchy.txt under the FDM installation ->

Inbox directory.

• To run webQMR_Setup_Entities

o EPM -> FDM -> Workbench -> Workbench Client

o Click Tools -> Script Editor -> Custom -> Web

o Select webQMR_Setup_Entities and click Run.

• Second, to load currency exchange rates, an adaptor and import format named QMR-EXCH-RATES

should be used. First create and setup location for the adaptor and load the exchanges rates file

generated from HFM (e.g. QMRExchangeRates_Actual_2012_QA.txt)

• Successful run of webQMR_Setup_Entities script and loading of exchange rates data is necessary

for all Asset and Technical Provision QRT’s in FDM.

Asset reference and lookup table

• Many of the assets and risk concentration QRT’s collect similar Assets data that could be referred to

via a lookup table. By using the assets reference table the user can simplify the loads of various

QRT’s by eliminating many of the referenced fields (e.g. Security Title, Issuer Name, External

Rating, etc.)

• QMR_Assets_Ref is an adaptor that is created for load of the Assets reference/lookup table.

• Before loading assets reference data make sure to setup a location as described earlier in this

document.

• NOTE: A user does not have to take advantage of the Assets reference and lookup table. They can

continue to load all asset common reference data as part of the QRT data loads. The Asset

reference and lookup table is provided for convenience and to provide common data integrity.

• The following data elements are included in the Assets reference table

o IDCode

o IDCodeType

o Security Title

o Issuer Name

o Issuer Sector

o Issuer Group Code



o Issuer Country

o Country of Custody

o Currency

o CIC

o External Rating

o Rating Agency

o Maturity Date

• How does the reference and lookup work?

o Asset IDCode is used as a key to match between Asset reference table and the QRT’s.

o During a load a user can choose to load only the IDCode and omit the reference data for an

asset (e.g. Security Title, Issuer Name, etc.) and all omitted data elements will be looked up

from the Assets reference table when running the QRT reports. However if the reference data

element exists in the load file then the value from the Asset reference table will be ignored.

Setup - Load QRT information to HFM

• Open and log in to the FDM Web client.

o EPM -> FDM -> Web Server Components -> Web logon

• Create a location for push to HFM.

o Assets QRT accounts/entities/balances need to be mapped and imported into HFM for all

relevant assets schedules that need to be validated against the balance sheet in HFM.

o Create a location for push to HFM

� Child of ControlsReview and select type Data Load.

� Specify name (e.g. QMR-Assets-HFM).

� Select Load Type -> Bulk Insert.

� Select Target Adaptor, pick the correct custom adaptor that matches the FDM version

(e.g. FM11X-G5-E, FM11X-G6-A, FM11X-G6-B, FM11X-G6-C).

� Make sure the Data Value is set to <Entity Currency>. If you can’t browse for the data

value then the HFM adaptor for FDM is set up incorrectly.

� Select the Workflow Behavior tab and select the correct Import Format (e.g. QMR-Assets-

D1-HFM; note that this format is for all assets schedules that need to be imported to HFM).

• Map Rules

o Create Map rules that Map source data to the target members for each dimension.

o Go to Activities -> Maps.

o Make sure the location is set to be the location that pushes into HFM.

o For each dimension (Entity, Account, ICP, C1..C4):

� Select Type as Like.

� Name the map e.g. EntityMap.

� Enter Rule Definition as *.

� Enter Target as *.



� Click Update Grid.

� Set up Category and Period target per QRT schedule.

o Open the MetaData -> Control Tables menu.

o For each QMR location in the right drop down.

� Map the Period [Target Per (M)] & Year Target for the period you want to load.

� Update Grid.

� Change the left drop down to Category.

� Map the Category to the HFM Scenario you would like to load.

� Update Grid.

Customizing Validation Scripts

Upon load of the QRT files, appropriate validations are performed to ensure correct data is stored in

QMR. These validations are performed by validation scripts. QMR for FDM has prebuilt over 40

validation scripts.

Example of a validation script could be as simple as checking whether the imported data is a valid

date, or checking against a valid list of currencies or checking validity of an ISIN code. All validation

scripts for QMR are prefixed with “QMR_”:

General validation functions:

Each of the following validation functions are applied to the schedule entries as required and defined in

the EIOPA QRT Excel files and Log files.

Function Logic

• QMR_Amount:NZP Any valid number or no entry

• QMR_Boolean Closed list:

"Y", "N"

• QMR_Country ISO Country Code

• QMR_Currency ISO Currency Code

• QMR_Date ISO 8601 date format (YYYYMMDD) or "P"

• QMR_IDCodeType Closed list:

"ISIN", "CUSIP", "Company Specific"

• QMR_IDCode ISIN / CUSIP check digit logic

• QMR_Numeric is numeric

• QMR_Rate is numeric from 0 and 100

• QMR_RatingAgency Closed list:

"MOODY'S", "FITCH"

Schedule-specific validation function:

Function Logic

• QMR_Assets_Accounts Closed list:



"ASSETS_PPEOWNUSE", "ASSETS_PROPERTY", "ASSETS_BONDSCORPORATE", "ASSETS_BONDSGOVERNMENT",

"ASSETS_EQUITIESLISTED", "ASSETS_EQUITIESUNLISTED", "ASSETS_INVFUNDSEQUITIES",

"ASSETS_INVFUNDSCORPBONDS", "ASSETS_INVFUNDSGOVTBONDS", "ASSETS_INVFUNDSPROPERTY",

"ASSETS_INVFUNDSDERIVATIVES", "ASSETS_INVFUNDSOTHER", "ASSETS_STRUCTUREDNOTES"

• QMR_Assets_BuyerSeller Closed list:

"BUYER", "SELLER", "LENDER", "BORROWER"

• QMR_Assets_CallablePuttable Closed list:

"C", "P", "B"

• QMR_Assets_CapitalProtection Closed list:

"Y", "N", "P"

• QMR_Assets_CIC Four character code: <CC><XX>

• Where <CC> is a valid ISO country code or “XL” or “XT”

• And <XX> is from “11” and “99” or a closed list:

"A1", "A2", "A3", "A5", "A7", "A8", "A9"

"B1", "B2", "B3", "B4", "B5", "B6", "B7", "B8", "B9"

"C1", "C2", "C3", "C4", "C5", "C6", "C7", "C8", "C9"

"D1", "D2", "D3", "D5", "D7", "D8", "D9"

"E1", "E2", "E7", "E8", "E9"

"F1", "F2", "F3", "F4", "F9"

• QMR_Assets_CollateralType One character from “1” to “9” or “A” to “F”

• QMR_Assets_CurrencyLocalForeign Closed list:

"L", "F"

• QMR_Assets_GeoZone Closed list:

"EEA", "OECD", "ROW"

• QMR_Assets_LongShort Closed list:

"L", "S", "FX-FX", "FL-FX", "FL-FL", "FX-FL"

• QMR_Assets_LookThrough Closed list:

"S", "O", "M"

• QMR_Assets_Participation Closed list:

"N", "YNGNS", "YNGS", "YGS", "YGNS"

• QMR_Assets_Pledged Closed list:

"CP", "CR", "CB", "R"

• QMR_Assets_Portfolio Closed list:

"L", "NL", "G", "I", "U", "RF"

• QMR_Assets_ProductType Closed list:

"CLN", "CMS", "CDOp", "ABS", "MBS", "CMBS", "CDO", "CLO", "CMO", ”IRLN", "ELN", "FXCLN", "HLN", "MLN", "ILN",

"OTHER"

• QMR_Assets_SecurityRepoLending Closed list:

"R", "L"

• QMR_Assets_UnderlyingCategory Closed list:

"1", "2", "3L", "3NL", "L"



• QMR_Assets_UnderlyingSecurity Closed list:

"EF", "CU", "IR", "CO", "IN", "O", "M"

• QMR_Assets_UnwindTrigger Closed list:

"B", "F", "R", "O"

• QMR_Assets_UseDerivative Closed list:

"MI", "EPM", "MA"

• QMR_Assets_ValuationMethodSII Closed list:

"QMP", "QMPS", “AVM”, “AEM, “IEM”

• QMR_IGT1_TransactionType Closed list:

"EQUITY TYPE - OTHERS", "OTHER ASSET TRANSFER - PROPERTIES", "OTHER ASSET TRANSFER - OTHERS", "BONDS/DEBT

- UNCOLLATERALIZED", "BONDS/DEBT - COLLATERALIZED", "EQUITY TYPE - DIVIDENDS", "EQUITY TYPE -

SHARES/PARTICIPATIONS"


"CONTINGENT LIABILITIES", "DERIVATIVES - FUTURES", "DERIVATIVES - FORWARDS", "DERIVATIVES - OPTIONS",

"DERIVATIVES - OTHERS", "G'TEES - CREDIT PROTECTION", "G'TEES - OTHERS", "SWAPS - CREDIT DEFAULT", "SWAPS -

INTEREST RATE", "SWAPS - CURRENCY", "SWAPS - OTHERS"

• QMR_IGT2_UseDerivatives Closed list:

"EFFICIENT PORTFOLIO MANAGEMENT", "MICRO HEDGE", "MACRO HEDGE", "OTHER"

• QMR_IGT3_ReinsuranceTreaty Closed list:

"FINANCIAL", "QUOTA SHARE", "SURPLUS/STOP LOSS", "XL - AGGREGATE", "XL - CATASTROPHE", "OTHERS"


"CONTINGENT LIABILITIES", "OFF BALANCE SHEET ITEMS", "INTERNAL COST SHARING", "OTHERS"

• QMR_RC_Impact Closed list:

"ASSETS", "LIABILITY", "OFF BALANCE SHEET (CONTINGENT ASSET)", "OFF BALANCE SHEET (CONTINGENT LIABILITY)"

• QMR_TP_F3B_Hedged Closed list:

"Y", "N", "P", "NS"

• QMR_TP_F3B_StrategyType Closed list:

"D", "N", "S", "A"

• QMR_TP_F3_LOB Closed list:

"INSURANCE WITH PROFIT PARTICIPATION", "INDEX LINKED AND UNIT-LINKED INSURANCE", "OTHER LIFE INSURANCE",

"ANNUITIES STEMMING FROM NON-LIFE CONTRACTS", "ACCEPTED REINSURANCE", "HEALTH INSURANCE", "HEALTH

REINSURANCE"

• QMR_TP_F3_PremiumType Closed list:

"R", "S", "NS", "NF", "O"

• QMR_TP_F3_ProdClassification Closed list:

"PS", "PJ", "PC", "PP", "PH", “PO”, "US", "UJ", "UC", "UP", "UH", “UO”, "OS", "OJ", "OC", "OP", "OH", “OO”, "AS", "AJ", "AC",

"AP", "AH", “AO”, "HS", "HJ", "HC", "HP", "HH", “HO”

To customize any of these validations or add to the valid list of values, follow these steps:

• Open the FDM workbench and select the Scripts tab.

• Edit the appropriate script and save.



Any script that validates against a list of values has an array of these values at the top of the script.

e.g. QMR_IGT1_TransType.

Dim transTypeList transTypeList = Array("EQUITY TYPE - OTHERS", _ "OTHER ASSET TRANSFER - PROPERTIES", _ "OTHER ASSET TRANSFER - OTHERS", _ "BONDS/DEBT - UNCOLLATERALIZED", _ "BONDS/DEBT - COLLATERALIZED", _ "EQUITY TYPE - DIVIDENDS", _ "EQUITY TYPE - SHARES/PARTICIPATIONS" _ )

To add/remove the value, simply edit the array. Enter the value in UPPER case as the UPPER case

imported value is compared to the list of values in the array.

The following tables list the validation that is applied to each column of the source data file:

Assets

Col Assets Field Name Validation D1 D1S D2O D2T D4 D5 D6

1 Entity 2 Account QMR_Asset_Accounts X X X X X X X

3 AccruedInterest QMR_Numeric X 3 AccruedInterest QMR_Rate

X

4 AcquisitionCost QMR_Numeric X 5 AttachmentPoint QMR_Rate

X

6 BuyerSeller QMR_Assets_BuyerSellerLender

X 7 CallablePutable QMR_Assets_CallablePuttable

X

8 CapitalProtection QMR_Assets_CapitalProtection

X 9 CIC QMR_Assets_CIC X

X X

X

10 CICCategory QMR_Assets_CollateralType

X 11 Collateral QMR_Numeric

X

12 CollateralAssetType QMR_Assets_CollateralType

X 13 CollateralDebtor

14 CollateralDebtorGroup 15 CollateralType QMR_Assets_CollateralType

X X

16 ContractName 17 CounterpartyGroup 18 CounterpartyID 19 ContractDimension QMR_Numeric

X X

20 Currency QMR_Currency X

X X

X 21 CurrLocalForeign QMR_Assets_CurrencyLocalForeign

X

22 CustodyCountry QMR_Country X

X 23 Delta QMR_Numeric

X

24 DerivativeUse QMR_Assets_UseDerivative

X X 25 DetachmentPoint QMR_Rate

X

26 Duration QMR_Numeric X

X 27 ExposuresWeight QMR_Rate

28 ExternalRating 29 FarLegAmt QMR_Numeric

X

30 FixedAnnualReturn(numeric) QMR_Rate

X 31 FundNumber

32 GeoZone QMR_Assets_GeoZone

X 33 IDCode QMR_IDCode X X X X X

X 34 IDCodeType QMR_IDCodeType X X X X X

X



Col Assets Field Name Validation D1 D1S D2O D2T D4 D5 D6

35 IssuerCountry QMR_Country X

X 36 IssuerGroup

37 IssuerName 38 IssuerSector 39 IsUnitIndexLinked QMR_Boolean X

X X

X

40 LongShort QMR_Assets_LongShort

X X 41 LookThrough QMR_Assets_LookThrough

42 LossGivenDefault QMR_Rate

X 43 MaturityDate QMR_Date X

X X

X X

44 MaximumLoss QMR_Numeric

X X 45 NearLegAmt QMR_Numeric

X

46 NotionalAmt QMR_Numeric

X X 47 NumberOfContracts QMR_Numeric

X X

48 Participation QMR_Assets_Participation X 49 Pledged QMR_Assets_Pledged X 50 Portfolio QMR_Assets_Portfolio X

X X

X 51 PremiumPaidRecd QMR_Numeric

X X

52 PrepaymentStructured QMR_Boolean

X 53 ProductType QMR_Assets_ProductType

X

54 ProfitLoss QMR_Numeric

X 55 Quantity QMR_Numeric X

X

56 RatingAgency QMR_RatingAgency X

X X 57 RepoLending QMR_Assets_SecurityRepoLending

X

58 RiskFactors 59 Security 60 StartDate QMR_Date

X

61 SwapDelCurrency QMR_Currency

X X 62 SwapIn QMR_Numeric

X X

63 SwapOut QMR_Numeric

X X 64 SwapRecdCurrency QMR_Currency

X X

65 SyntheticStructured QMR_Boolean

X 66 TotalSIIAmount QMR_Amount:NZP X X X X X X X

67 TradeDate QMR_Date

X X 68 TriggerValue

69 UnderlyingAssetLiability 70 UnderlyingCIC QMR_Assets_UnderlyingCategory

X

71 UnderlyingSecurity QMR_Assets_UnderlyingSecurity

X 72 UnitSIIPrice QMR_Numeric X

X

73 UnwindTrigger QMR_Assets_UnwindTrigger

X X 74 ValuationMethodSII QMR_Assets_ValuationMethodSII X

X

X

75 VariableAnnualReturn QMR_Rate

X 76 Dividends QMR_Numeric

77 Interest QMR_Numeric 78 Rent QMR_Numeric 79 GainsLosses (numeric) QMR_Numeric 80 ICP X X X X X X X

Technical Provisions

Col TP Field Name Validation TP-F3 TP-F3A TP-F3B

1 Entity 2 ProdDenom 3 LOB QMR_TP_LOB X

4 HRG QMR_Numeric X



Col TP Field Name Validation TP-F3 TP-F3A TP-F3B

5 HRGCommon QMR_Boolean X 6 RFF

7 Commercialized QMR_Boolean X 8 ProductType

9 ProdClassID QMR_TP_F3_ProdClassification X 10 PremiumType QMR_TP_F3_PremiumType X 11 Country QMR_Country X 12 NumContract QMR_Numeric X 13 NewContract QMR_Numeric X 14 PremiumAmt QMR_Amount:NZP X X X

15 BestEst QMR_Numeric X 16 CapRisk QMR_Numeric X 17 SurrVal QMR_Numeric X 18 AnnGuarRate

19 TheoriticalClaims QMR_Numeric X 20 FinInstrUse QMR_Boolean X 21 GeneralDescription

22 CoverTerm 23 GMDBPresent QMR_Boolean

X

24 GMDBLevel QMR_Numeric

X 25 GMDBDesc

26 GMABPresent QMR_Boolean

X 27 GMABLevel QMR_Numeric

X

28 GMABDesc 29 GMIBPresent QMR_Boolean

X

30 GMIBLevel QMR_Numeric

X 31 GMIBDesc

32 GMWBPresent QMR_Boolean

X 33 GMWBLevel QMR_Numeric

X

34 GMWBDesc 35 StrategyType QMR_TP_F3B_StrategyType

X

36 HedgedDelta QMR_TP_F3B_Hedged

X 37 HedgedRho QMR_TP_F3B_Hedged

X

38 HedgedGamma QMR_TP_F3B_Hedged

X 39 HedgedVega QMR_TP_F3B_Hedged

X

40 HedgedFX QMR_TP_F3B_Hedged

X 41 HedgedOther QMR_TP_F3B_Hedged

X

42 ECResultWOHedge QMR_Numeric

X 43 ECResultHedge QMR_Numeric

X

44 ICP X X X 45 IDCode X

Risk Concentration

Col RC Field Name Validation RC

1 Entity 2 CounterPartyName 3 ExposureNature 4 ExposureCountry QMR_Country X

5 IDCode QMR_IDCode X 6 IDCodeType QMR_IDCodeType X 7 ExternalRating

8 RatingAgency 9 IssuerSector



Col RC Field Name Validation RC

10 ExposedEntity 11 ExposedEntityCode 12 Amount QMR_Amount:NZP X

13 Currency QMR_Currency X 14 MaturityValidityDate QMR_Date X 15 MaximumExposure QMR_Numeric X 16 MaximumReinsurerLiab QMR_Numeric X 17 CededTP QMR_Numeric X 18 Impact QMR_RC_Impact X

Intra-Group Transfers

Col IGT Field Name Validation IGT1 IGT2 IGT3 IGT4

1 Entity 2 Transferee 3 TransfereeCode 4 Transferor 5 TransferorCode 6 IDCode QMR_IDCode X X

7 IDCodeType QMR_IDCodeType X X 8 Threshold QMR_Numeric

X

9 TransactionType QMR_IGT1_TransactionType X 9 TransactionType QMR_IGT2_TransactionType

X

9 TransactionType QMR_IGT4_TransactionType

X 10 TransactionDate QMR_Date X X

X

11 MaturityDate QMR_Date X X 12 Currency QMR_Currency X X X X

13 TransactionAmount QMR_Numeric X 14 Amount QMR_Amount:NZP X X X X

15 TransactionInPeriod QMR_Numeric X 16 TopUpsInPeriod QMR_Numeric X 17 BalanceOfContract QMR_Numeric X 18 CouponRate QMR_Rate X 19 ReferenceDocs

20 ValueAtTransDate QMR_Numeric

X 21 ValueAtReportDate QMR_Numeric

X

22 UseOfDerivatives QMR_IGT2_UseDerivatives

X 23 UnderlyingAssetLiability

24 ProtectedCounterPartyName 25 DeliveredInterestRate 26 ReceivedInterestRate QMR_Rate

X

27 DeliveredCurrency QMR_Currency

X 28 ReceivedCurrency QMR_Currency

X

29 ValidityStartDate QMR_Date

X 30 ValidityExpiryDate QMR_Date

X

31 ReinsuranceType QMR_IGT3_ReinsuranceTreaty

X 32 MaximumRecoverable QMR_Numeric

X

33 ReinsuranceClaimsPaid QMR_Numeric

X 34 ReinsuranceResult QMR_Numeric

35 ContractStartDate QMR_Date

X 36 ContractExpiryDate QMR_Date

X

37 TriggerEvent 38 MaxContingentLiabInSIIBS QMR_Numeric

X

39 MaxContingentLiabNotInSIIBS QMR_Numeric

X



Assets Reference

Col RC Field Name Validation Ref

1 IDCode QMR_IDCode X 2 IDCodeType

X

3 Security

X 4 IssuerName

X

5 IssuerSector

X 6 IssuerGroup

X

7 IssuerCountry QMR_Country X 8 CustodyCountry QMR_ Country X 9 Currency QMR_Currency X 10 CIC QMR_Assets_CIC X 11 MaturityDate QMR_Date X 12 ExternalRating

X

13 RatingAgency QMR_RatingAgency X

Exchange Rates

Col RC Field Name Validation Ref

1 Currency_From QMR_Currency X 2 Currency_To QMR_Currency X 3 AvgRate QMR_Numeric X 4 ClosingRate (Amount) QMR_Numeric X

Editing and customizing reports

QMR reports in FDM provide QRT reports in five languages (English, German, French, Dutch and

Spanish). To edit the design (e.g. add new data columns) of any of these reports, follow these steps:

• Open the FDM workbench.

• Select the Reports tab.

• Click on the Report in the QMR folder for the language.

• Right click Design Report.

To create reports for a new language (e.g. Swedish) follow these steps:

• Select the English QMR report group.

• Right click and select Properties.

• Write down the settings for each field.

• Close the properties form.

• Right click the language you want to create a group for and select Add Report Group.

• Enter the same information as the QMR group but leave the language selection alone.

• Go back to the English QMR report group, right click the report you want and choose Copy Report.

• Go back to the new group and select Paste Report.

• Then just right click the new report and design the report.



Implementing QMR for HFM


The QMR HFM components have been created and configured to provide reports for all QRT schedules

except those retained in FDM. There are however dimensions that must be modified to client

requirements and others that can be customized if required.

Calendar/Profile

The Calendar/Profile file defines several of the application dimensions (Year, Period Frequency) and

also defines the languages used for descriptions. The application administrator may wish to modify this

file before creating the application. Changes to the application profile elements cannot be made after

the application is created, a new application must be created.

Languages

The QMR metadata is provided with descriptions in English (EN) and in a second file, with localization

translations to German (DE), Spanish (ES), French (FR) and Dutch (NL). The languages provided are

defined in the Calendar / Profile. Additional descriptions can be added to the application by defining

additional languages in the Calendar/Profile file before creating the application. It is strongly

recommended that the English descriptions not be removed from the application.

If additional languages are added to the application, the descriptions in those languages for all

dimension members will need to be added to the Calendar / Profile file (frequency and period

descriptions) and Metadata file (all metadata dimensions). The HFM Metadata Localization Utility can

be used to insert additional language descriptions to the metadata file based on a translation file,

either provided with the application (currently DE, ES, FR and NL) or created by the administrator.

The HFM Metadata Localization Utility is provided as part of an HFM installation. For implementations

earlier than 11.1.2.1.600 or 11.1.2.2.301, the Metadata Localization utility patch (number 14361678)

is available for download from the Oracle Support web site. Further details describing the use of the

utility are available in the utility documentation.

Frequency

The QMR standard quarterly file defines two frequencies.

• QTD quarter-to-date

• YTD year-to-date

The frequency labels and descriptions can be changed as required. If the labels are changed then the

default frequencies applied to the Scenario members in metadata must also be changed.

Years

The QMR standard file defines the range of years as 2010 to 2025. There are no descriptions for years.

The year range can be changed as required.

Periods

The QMR standard quarterly file defines five base time periods within a year.

• Quarters labeled Q1…Q4, QA

• Year labeled [Year]



QA (Annual) is included as a period due to the separate reporting requirements for Q4 quarterly

reporting and annual reporting.

All labels and descriptions can be changed before loading the file to create a new application except for

[Year] which is a required system member. It is recommended that the quarterly labels not be

changed although the descriptions can be modified.

Metadata

The metadata file defines the application settings and the remaining dimensions not defined in the

Calendar / Profile file. These dimensions are: Currency (Value), Scenario, Entity, Account, Custom1,

Custom2, Custom3 and Custom4.

Application Settings

Application Currency

The Application Currency is set to EUR. This currency is used as the common currency when

triangulation of exchange rates is required. All exchange rates should be entered in terms of the

Application Currency. This Application Currency entry can be changed to any valid currency.

Default Rates

The Default Rates for Balance Accounts (Assets, Liabilities) and the Default Rates for Flows (Revenue,

Expenses) must match accounts of type CurrencyRate. Accounts OpeningRate, AverageRate and

ClosingRate are provided.

PVA For Balance / Flow Accounts

Default translations can be calculated on either a periodic basis (PVA) or on a period-end basis (VAL).

All QMR reporting is currently on a Year-to-date basis. It is recommended that the period-end basis be

used for translations. For further details, please refer to the HFM Administrator’s Guide.

Validation Account

A validation account has not been set. The validation account can be used to prevent "locking" of data

or "promotion" of process units should Process Management be implemented. For further details please

refer to the HFM Administrator’s Guide.

Consolidation Methods

The consolidation rules provide full consolidation. Minority interest, Equity elimination and Proportional

consolidation can be selected on an entity-by-entity basis by selecting the appropriate Method.

Methods can be selected from the Ownership Management screen or loaded via a data file. Calculating

ownership methods from Shares Outstanding / Shares Owned is not supported due to the different

methods that may be required for the same ownership percentage. For further details please refer to

the HFM Administrator’s Guide.

Currency / Value Dimension

The QMR metadata file defines most world currencies using the three-character ISO currency codes.

HFM default translation will be processed based on the default currencies of the entities.

NOTE: It is recommended that only those currencies that are currently required and those that will be

required in the foreseeable future are retained in the currency dimension of the metadata file used to

create the application. Retaining currency codes not required may cause performance degradation.

Note that the currency dimension is used only for the currency of the entities. Currency codes have



also been created in the Custom3 and Custom4 dimensions for recording the currency of assets etc. All

currencies can be retained in these dimensions without performance degradation.

The modification of entities and the required currency for each should be completed before finalizing

the currencies to be retained. Note that by default the currencies will be displayed in the sequence in

which they were created. If any currencies are to be deleted then all entities must be checked to

ensure that a deleted currency is not used as a default currency.

The currencies defined, in addition to a series of predefined system members, are used to create the

Value dimension.

User Defined Fields

The Scenario, Entity, Account and Custom1 to Custom4 dimensions all have three User Defined (UD)

attribute fields for each member.

The QMR application uses these UD fields for various purposes. UD Field entries are used to direct HFM

rules to perform certain actions on specific points-of-view, to tag certain members which share a

common functional property or to provide some other member-specific information.

GetUDEntry Function

In order to make the best use of the UD fields, the QMR Member Lists and Rules files use a function

(GetUDEntry) that allows each UD field to contain more than one reference (note that this function was

written for starter kit applications and is not a generic HFM function).

For example, a UD field might contain the following string:

Keyword1:Entry1|Keyword2:Entry2|Keyword3:Entry3

This user defined entry consists of three separate elements, separated by a “pipe” / vertical line

symbol (“|”). Within each element, there is an identifying “keyword” followed by the entry. So in the

example shown above, there are three entries:

10. Keyword: Keyword1 Entry: Entry1



The GetUDEntry function can be used to access entries in a specific UD field (UD1, UD2, UD3) or in

any UD field (ALL). For the Account dimension only, retrieving an entry from ALL fields will also

retrieve an entry from the XBRLTags field.

EPMA WARNING: The pipe symbol used to separate multiple UD Field entries is not compatible with a

migration from a Classic application to an EPMA application. If a Classic QMR application is to be

migrated to EPMA, the pipe symbol must be replaced by an alternative symbol. Two preparation steps

are required:

1. Modify the classic XML metadata file by searching for and replacing | with ^ in a text file editor.

Then re-load metadata to the Classic application (Merge mode is sufficient).

2. Modify both the Member Lists and Rules files. Search for FieldDelimiter = "|" and replace with

FieldDelimiter = "^". Re-load the Member Lists and Rules files.

The application can now be migrated successfully.



User Defined Fields common to all dimensions

Keyword: CellText

UD Field: ALL

Valid Entry: any valid validation definition

Example: Y,N

Used By: Cell text validation rules

Description: Where cell text needs to be validated, the validation can be applied against:

Entries in a comma-separated list (Y,N)

Labels in a metadata list (C2{Countries.[Base]})

A specific validation ([Date])

A comma-separated list of validation entries (Y,N,[Date],C2{Countries.[Base]})

Keyword: Desc

UD Field: ALL

Valid Entry: any description

Example: an account description

Used By: various rules that write to cell text for textual reporting

Description: HFM rules are unable to read the metadata description so if a description is required to

be written to cell text by rules, a Desc keyword entry can be used.

Keyword: ML_<List name>

UD Field: ALL

Valid Entry: Numeric sequence value

Example: ML_WindstormRisk:1 (example keyword and entry)

Used By: Member Lists

Description: Member Lists have been created using a standard list routine that enumerates list

members based on the keyword. The list is sorted based on the entry.

Scenario Dimension

The QMR standard metadata file defines one scenario:

• Actual

The Actual scenario is defined with a frequency of QTD which will allow quarterly data entry (Q1 to Q4)

plus annual entry (QA). Additional scenarios can be created if required.

Entity Dimension

The metadata file provided with QMR 2.1.1 includes several sample entity structures.

• In the “flat” structures, there are two group entities (Group, SubGroup), ten Legal Entity / Solo

entities and six Ring Fenced Fund (RFF) entities in separate non-consolidated hierarchies.

• In the multi-level hierarchy, there are several Group and Sub-Group entities (MultiGroup,

MultiGroup1, MultiGroup1A, MultiGroup1B and MultiGroup2) and the same 10 Legal Entity / Solo

entities.

• In both the flat and multi-level hierarchies, one of the Solo entities (LE04) is a parent entity with a

consolidated RFF entity and several Branch entities as descendants.

It is expected that all implementations of QMR will require complete modification of the entity

dimension.

Group Companies

Each "top-level" entity is assumed to be a “group” reporting entity. If multiple group reporting is

required within an organization, then two different hierarchy methods can be used. Either multiple top



entities can be created with different or overlapping combinations of Legal Entities / Solos as children,

or multiple levels of group entities can be created.

Solo Undertakings

Base entities are assumed to be Legal Entities / Solos unless defined as RFF or Branch entities by UD

Field entries. Insurance company entities (Solos) and other non-insurance company entities (Legal

Entities) for which data must be reported at group can be created as base entities, or parents of RFFs /

Branches.

Ring Fenced Funds

In order to provide the full reporting capabilities required for Ring Fenced Funds, each RFF is created

as a base entity and linked to the relevant solo undertaking. There are two forms of RFF entities.

The first is a disconnected entity set-up in a non-consolidated hierarchy as shown in the flat sample

hierarchies:

1. For each group hierarchy, an RFF parent is created as a child of the group entity. So if the

group parent is Group, the RFF parent for this hierarchy might be Group_RFF. The RFF parent

for the hierarchy is defined by a UD entry in the group parent:

• GroupRFF:Group_RFF

2. A parent for each solo entity maintaining RFFs is created as a child of the RFF parent. So for

solo entity LE01, the RFF parent for this entity might be LE01_RFF. The RFF parent for the

Solo entity is defined by a UD entry in the Solo:

• LeRFF:LE01_RFF

3. For each RFF related to the solo entity, a base entity is created as a child of the solo RFF

parent. For example, RFFs related to entity LE01 might be named LE01_RFF1 and

LE01_RFF2.

Note that the names of the entities do not need to be related in any way to each other. Also note that

the data entered to a disconnected RFF entity is not consolidated to the related Solo entity. Only the

final calculated SCR results are copied to the Solo. No other consolidation of data in the disconnected

RFF entities is carried out. So any data such as Balance Sheet must be entered to the RFF and also to

the Solo.

The second form of RFF entity is a consolidated RFF. A consolidated RFF is a base entity with a parent

Solo entity and will also have at least one sibling Branch entity. All data from the consolidated RFF will

be fully consolidated to the parent Solo except for SCR data. The final calculated SCR results are

copied to the Solo parent but the SCR detail is not consolidated. The sample entity LE04 incorporates a

Consolidated RFF.

A consolidated RFF entity must be a base entity and is defined by a UD Field entry of:

• EntityType:ConsRFF

Branches

A Legal Entity / Solo can be a consolidation of multiple base and / or parent Branch entities plus

Consolidated base RFF entities. A base entity or parent entity can be defined as a Branch by a UD field

entry of:



• EntityType:Branch

All siblings of any Branch or Consolidated RFF entity must also be Branch or Consolidated RFF entities.

Any siblings not defined by the relevant UD field entry will be assumed to be Branch entities.

All data from the branches will be fully consolidated to the parent Legal Entity / Solo. Inter-company

entries between branches will be eliminated within the Legal Entity / Solo. Inter-company entries

between an RFF entity and a Branch will not be eliminated.

Entity Type Summary

Note that ALL children of a parent Legal Entity / Solo must be Branch or Consolidated RFF. As a

consequence, a Legal Entity / Solo cannot be a child of a Legal Entity / Solo. All parent-child

relationships must be one of:

• Group - Group

• Group - Solo

• Solo – Consolidated RFF

• Solo - Branch

• Branch – Branch

• Group - RFF Dummy Parent*

• RFF Dummy Parent - RFF Dummy Parent*

• RFF Dummy Parent – Non-consolidated (disconnected) RFF*

* These relationships comprise the “disconnected” non-consolidated RFF hierarchy.

Inter-company Partners

At a Group consolidated level, reporting by Legal Entity / Solo and by RFF requires that the ICP

dimension be used at Group to identify one source entity from another. All Branches, RFFs and Legal

Entities / Solos should therefore be flagged as IsICP. Group entities should not be flagged as IsICP.

Allow Adjustments

There are two entity metadata settings that determine whether journal adjustments can be entered for

each entity (AllowAdjs, AllowAdjFromChildren). QMR version 2.1.1 supports the use of journal

entries for all QRT schedules except SCR and MCR schedules.

All data for SCR and MCR schedules is to be entered to <Entity Currency> only of the base entities.

The use of journal entries is not supported for these schedules due to the nature of the cumulative

calculations that are required. For example, a “Maximum” calculation applied to the <Entity

Currency> and <Entity Curr Adjs> dimensions separately might not provide the required result at

<Entity Curr Total>.

Entity User Defined Fields

Keyword: Aggregated

UD Field: ALL

Valid Entry: Y/N

Example: Y

Used By: Sub Calculate_GroupG04

Description: This entry is used to populate reports fields with the entity category.

Keyword: Cat

UD Field: ALL



Valid Entry: Valid category of entity as defined by EIOPA

Example: Mutual, Sub-Mutual


Description: This entry is used to populate reports fields with the entity category.

Keyword: EntityType

UD Field: ALL

Valid Entry: Branch, ConsRFF

Example: Branch

Used By: Sub CreateEntityTypesDictionary

Description: This entry is assigned to Branch and Consolidated RFF entities to define base or parent

entities.

Keyword: Form

UD Field: ALL

Valid Entry: Form of company

Example: PLC, SA, GmBH etc.


Description: This entry is used to populate reports fields with the entity form.

Keyword: GroupRFF

UD Field: ALL

Valid Entry: Valid parent entity label

Example: Group_RFF

Used By: Rules subroutine CreateGroupRFFList

Description: This entry is assigned to consolidated groups to identify the parent of the ring fenced

funds’s (RFF’s) of the group’s legal entities.

Keyword: HomeCountry

UD Field: ALL

Valid Entry: Valid ISO country code from the Custom2 dimension

Example: DE, ES, FR, GB, NL


Description: This entry is used to define the country in which the entity resides.

Keyword: IDCode

UD Field: ALL

Valid Entry: Valid EIOPA or National Registration System ID code of the entity.

Example:


Description: This entry is used to populate reports fields with the entity ID code.

Keyword: IncDate

UD Field: ALL

Valid Entry: ISO 8601 date formatted data (YYYYMMDD)

Example: 20111231


Description: This entry is used to populate reports fields with the date at which the entity was

included in scope for reporting.

Keyword: IncScope

UD Field: ALL

Valid Entry: Yes or No

Example: Yes, No


Description: This entry is used to populate reports fields with an indication of whether the entity is

included in scope for reporting.



Keyword: Language

UD Field: ALL

Valid Entry: Valid ISO language code for which QMR Rules provide translations

Example: DE, ES, EN, FR, NL

Used By: Rules-generated cell text entry such as calculation explanations and validation text

Description: Cell text entries written to the entity will be written in the language entered to this

keyword IF that language has been added to the rules file. QMR 2.1.1 is translated from

English (EN) into German (DE), Spanish (ES), French (FR) and Dutch (NL). If no entry is

found for an entity, the language of the default parent (or the default parent’s default

parent) will be used. If no language entry is found, or a language entry for which

translations are not available is found, the default language defined in the Rules file is

used. The default language in the Rules file is set as EN but this can be changed to DE,

ES, FR or NL.

Keyword: LeName

UD Field: ALL

Valid Entry: Name of legal entity (this might be the same as the description of the entity)

Example: Acme Insurance Company


Description: This entry is used to populate reports fields with the entity legal name.

Keyword: LeRFF

UD Field: ALL

Valid Entry: Valid parent entity label

Example: LE01_RFF

Used By: Rules function GetParentRFF (used in Sub Calculate_SCR and Sub ImpactLeFromRFF)

Description: This entry is assigned to legal entities with ring fenced funds (RFFs) to identify the

parent of the legal entity RFFs.

Keyword: Ref

Used By: This entry is no longer used based on EIOPA July 2012 updates

Description: This entry has been replaced by the IDCode entry in all Group schedules

Keyword: Super

UD Field: ALL

Valid Entry: Supervisor of the entity

Example: FSA etc.


Description: This entry is used to populate reports fields with the supervisor of the entity.

Keyword: Type

UD Field: ALL

Valid Entry: Valid type of entity as defined by EIOPA

Example: Life, Non-Life, Composite, EIORP, Ancillary etc.


Description: This entry is used to populate reports fields with the entity type.

Account Dimension

The account dimension provides accounts for data entry of all data required for QRT reporting other

than the transactional schedules retained in FDM. It is recommended that these account structures and

members not be changed. Additional accounts and account structures can be added should additional

data need to be captured. However, it is anticipated that the existing accounts will be sufficient for

QRT reporting purposes.

Account Groupings

The accounts are grouped by QRT schedule type.



• Assets

o Most Assets schedules are reported from FDM with the exception of Assets-D3. Accounts are

provided in HFM to collect the aggregation of the details in FDM for Assets-D1 for validation

against the Balance Sheet.

• BS (Balance Sheet)

• Cover

o Country and Cover schedules

• FS (Financial Stability)

o Lapse, Liability Duration and Profit/Loss schedule are included under Financial Stability.

• Group

o The group G01, G03, G04 and G14 schedules are included in this section. IGT and RC schedules

are reported from FDM.

• MCR (Minimum Capital Requirements)

• OF (Own Funds)

o Own Funds and Participations schedules are included in this section.

• Re (Reinsurance)

• SCR (Solvency Capital Requirements)

• TP (Technical Provisions)

• VA (Variance Analysis)

o Accounts for Variance Analysis are provided based on the November 2011 Consultation Pack

but no rules, data entry forms or reports have been created based on the expectation that

EIOPA will change the requirements significantly.

• Validation

o Validations are included in the QMR application. One or more of the accounts in this section can

be used as the system validation account for Process Control if required.

• SystemAccounts

o Additional accounts used by the system for calculation or other general use are in this section

including Exchange Rate and Correlation Table accounts.

All existing hierarchies and members must be retained. Additional accounts can be added in separate

hierarchies but existing hierarchies should not be changed. Additional custom dimension members can

be created in separate hierarchies should they be required to be applied to the new accounts but

should not modify existing hierarchies. Existing custom dimension members can be re-used with new

accounts.

Account User Defined Fields

Keyword: CalcSeq1

UD Field: ALL

Valid Entry: Numeric value

Example: 110

Used By: SCR calculations

Description: Creates a sorted Member List used by the SCR routines to calculate the SCR accounts in

the correct sequence.



Keyword: ConditionCIC

UD Field: ALL

Remark: These entries are no longer applied.

Keyword: ConsRule

UD Field: ALL

Valid Entry: BS, DIV, EQUI, INVS, MCR, NAV, OF, SCR, GROUP

Example: BS

Used By: Function GetConsRule (used in Sub Consolidate)

Description: This entry is assigned to accounts to define their consolidation rule (for more detail, see

consolidation rule section below).

Keyword: CorrList

UD Field: ALL

Valid Entry: Valid Member List name

Example: Countries for Hail Risk Correlation

Used By: SCR diversification calculations

Description: A Member List can be used to limit diversification calculations. If a list is used, the

correlation table factor calculation is applied only to the list members and all other valid

intersections use a default factor of 1.

Keyword: <Custom3 Calc prefix><n> (Custom3 valid model calculation type prefix followed by

a sequential integer)

UD Field: ALL

Valid Entry: Pre-defined SCR calculation type – for details of valid entries, refer to the Rules section

Example: SMCalc1:Diversify

where SMCalc is a valid Custom3 CalcPrefix entry


Description: Determines the type of calculation to apply to the account. Multiple calculations can be

defined for an account by entering multiple sequential entries (e.g. SMCalc1, SMCalc2

etc.)

Keyword: <Custom3 Solo><n> (Custom3 valid model calculation limitation entry followed by a

sequential integer)

UD Field: ALL

Valid Entry: Y or N

Example: SMSolo1:Y

where SMSolo is a valid Custom3 CalcSolo entry


Description: Determines whether a matching calculation should be applied to Solo entities, Group

entities or both. The source is matched to the calculation type by the sequence number.

When the SMSolo1 entry is Y, the SMCalc1 calculation is restricted to Solo entities.

When the SMSolo1 entry is N, the SMCalc1 calculation is restricted to Group entities.

The calculation is applied to both Solo and Group entities for other entry, or no keyword.

Keyword: <Custom3 Calc source><n> (Custom3 valid model calculation source followed by a

sequential integer)

UD Field: ALL

Valid Entry: Custom3 valid model calculation source followed by a sequential integer

Example: SMSrc1:MarketRiskTable

where SMSource is a valid Custom3 CalcSource entry


Description: Determines the source for the matching calculation applied to the account if required.

The source is matched to the calculation type by the sequence number. So the SMCalc1

calculation will use the SMSrc1 source entry.



Keyword: DataRange

UD Field: ALL

Valid Entry: Valid numeric range separated by a tilde (~) where an asterisk (*) represents no limit

Example: -1~1

Used By: Data entry validation routines

Description: The QMR application assumes all data entry will be positive values. Where exceptions

are required, the DataRange keyword provides the acceptable data range. So for

Correlation Table data for example, all entries must be in a range from -1 to +1. An

asterisk can be used to represent no limit on the upper or lower limits. A required

negative or zero entry would be represented by *~0.

Keyword: D&A

UD Field: ALL

Valid Entry: Valid base account label

Example: SCRB2A_DedAgg

Used By: Sub Calculate_SCR_Proportional

Description: This entry is assigned to the accounts A_SCRB2A_TOTALSCR, A_SCRB2C_TOTALSCR to

define the SCR account where corresponding amounts should be copied to, in Value

[Proportion], when the entity is consolidated with one of the methods SUBS_DA,

SUBS_DA_FR, PSI_DA, PSI_DA_FR. During the copy, the original amounts are multiplied

by percent ownership (POwn) of the entity; nevertheless when the method is

SUBS_DA_FR or PSI_DA_FR, and A_OF_ELIGIBLESCR < A_OF_TOTALSCR, 100% is used

instead (for more detail, see SCR consolidation rule below).

Keyword: ElimICP

UD Field: ALL

Valid Entry: N

Example: N

Used By: Function EliminateICP (used in Sub Consolidate)

Description: This entry is assigned to accounts to not eliminate intercompany detail. If the keyword

is missing or any value different from “N” is assigned to it, the account will be eliminated

accordingly to the defined elimination criteria (for more detail, see consolidation rules

section below).

Keyword: ElimOF

UD Field: ALL


Example: OFG_OrdinaryShares_Elim

Used By: Sub Consolidate

Description: This entry is assigned to the own funds accounts consolidated with DIV, OF rules, to

define their elimination account (for more detail, see consolidation rules section below).

Keyword: MinOF

UD Field: ALL


Example: OFG_MinorityInt

Used By: Sub Consolidate

Description: This entry is assigned to the accounts consolidated with DIV, INVS, NAV, OF rules, to

define their minority account (for more detail, see consolidation rules section below).

Keyword: NoInputICP

UD Field: ALL

Valid Entry: TRUE (any case)

Example: TRUE

Used By: Sub NoInput_OwnFunds



Description: This entry is assigned to non available own funds accounts to prevent input in [ICP

Entities]. For these accounts, in fact, ICP detail is just used in consolidation to keep

source entity information (for more detail, see consolidation rule NAV below).

Keyword: NoNoInput

UD Field: ALL

Valid Entry: valid POV

Example: C1#SCR_Replace.C3#PartIntModel

Used By: Sub NoInput

Description: This entry is used to allow data entry (to not apply NoInput rules) to Standard Formula

With USP or Partial Internal Model data-points. This allows data entry for data-points

specific to models other than Standard Formula.

Keyword: OFNoInput

UD Field: ALL

Valid Entry: TRUE (any case)

Example: TRUE

Used By: Sub NoInput_OwnFunds

Description: This entry is assigned to own funds accounts to prevent input on a quarterly or yearly

basis, when they are calculated from balance sheet or other own funds detailed

accounts.

Keyword: PartSig

UD Field: ALL


Example: SCRB2A_NonContPartic

Used By: Sub Calculate_SCR_Proportional

Description: This entry is assigned to the accounts A_SCRB2A_TOTALSCR, A_SCRB2C_TOTALSCR to

define the SCR account where corresponding amounts should be copied to, in Value

[Proportion], when the entity is consolidated with one of the methods PSI, PSI_FR.

During the copy, the original amounts are multiplied by percent ownership (POwn) of the

entity; nevertheless when the method is PSI_FR and A_OF_ELIGIBLESCR <

A_OF_TOTALSCR, 100% is used instead (for more detail, see SCR consolidation rule

below).

Keyword: ReverseSI

UD Field: ALL


Keywords: RFF, RFF4, RFFDA (as defined via Custom1 keyword SCRKeyword, see below)

UD Field: ALL


Example: SCRB2A_NotionalRFF

Used By: Sub Calculate_SCR

Description: These entries are assigned to the accounts A_SCRB2A_TOTALSCR, A_SCRB2A_DIVERSE,

A_SCRB2C_TOTALSCR, A_SCRB2C_DIVERSE to define the SCR account of a legal entity

where corresponding RFF’s amounts should be copied to, based on the RFF type.

Keyword: SCRExtended

UD Field: ALL

Valid Entry: valid account label

Example: SCRB2B_MarketRiskExtended


Description: This entry on a “replacement risk” account used by the Partial Internal Model will point

to the “extended risk” account. If the replacement risk account is not used and displayed

on the SCR-B2B schedule, the related extended risk account will be used.



Keyword: SCRStandard

UD Field: ALL


Example: SCRB2A_MarketRisk


Description: This entry on an “extended risk” account used by the Partial Internal Model will point to

the “standard risk” account. If the extended risk account is not used and displayed on

the SCR-B2B schedule, the related standard risk account will be used on the SCR-B2A

schedule.

Keyword: ValidateSII

UD Field: ALL

Valid Entry: valid POV

Example: A#Assets_Property

Used By: Balance Sheet validation routine

Description: When used on a balance sheet account, the entry points to an account against which to

validate the balance sheet account.

ICP Dimension

The ICP dimension will contain the system members [ICP Top], [ICP None] and [ICP Entities] and

all Entity dimension members that have been set as "IsICP".

All Branch, RFF and Solo entities should be set as ICP members but Group entities should not be.

Custom1, Custom2, Custom 3, Custom 4 Dimensions

The Custom 1, 2 and 3 dimensions provide for a more granular breakdown of account detail. It is

recommended that these structures and members not be changed except where specified. Additional

custom members can be added should additional data need to be captured. However, it is anticipated

that the existing members will be sufficient for QRT reporting purposes.

The Custom4 dimension is used for analysis in only a limited number of schedules (TP-E3, TP-E7, TP-

E7B). For all other schedules, the Custom4 dimension can be used for implementation-specific

requirements. The QMR metadata file includes a sample “Data Source” hierarchy. This hierarchy can

be modified as required for each implementation. The [None], TotalCustom4, TotalDataSources,

SystemMembers (and descendants) members must not be removed from this dimension. The

TotaDataSources hierarchy can otherwise be modified as required but must include the [None]

member ([None] must be a descendant of TotalDataSources).

User Defined Fields

User Defined Fields are used to reduce the maintenance of HFM rules. UD Field entries are used to

direct HFM rules to perform certain actions on specific points-of-view or to tag certain members which

share a common functional property.

User Defined Fields common to all custom dimensions

Keyword: Consolidate

UD Field: ALL

Valid Entry: N

Example: N

Used By: Sub CreateCustomsNoConsol (used in Sub Consolidate)

Description: This entry is assigned to customs to not consolidate specific members. If the keyword is

missing or any value different from “N” is assigned to it, a data-point with the specified

custom will be consolidated normally, assuming that the corresponding account is set as

consolidated in metadata and has a consolidation rule assigned.



Keyword: <Country Code>

UD Field: ALL

Valid Entry: any description

Example: an account description

Used By: Sub CalculateSCR_GeoDiversification

Description: HFM rules are unable to read the metadata description so if a description is required to

be written to cell text by rules, a <country code> keyword entry can be used. If a UD

Field entry exists for the language specified for the entity by the Language keyword,

then that description will be used. If not but a UD Field entry exists for the default

language (defined in the Rules file) then that description is used. Due to the size

limitations of the UD Fields care must be taken when deciding to add additional

translations to this keyword entry.

Keyword: Proportionalize

UD Field: ALL

Valid Entry: N

Example: N

Used By: Sub CreateCustomsNoProportionalize (used in Sub Consolidate)

Description: This entry is assigned to customs to not proportionalize specific members. If the

keyword is missing or any value different from “N” is assigned to it, a data-point with

the specified custom will be proportionalized based on the assigned consolidation rule,

assuming that the corresponding account is set as consolidated in metadata and has a

consolidation rule assigned.

Keyword: Translate

UD Field: ALL

Valid Entry: N

Example: N

Used By: Sub CreateCustomListsNoTrans (used in Sub Translate)

Description: This entry is assigned to custom members that are to be translated at a factor of 1. This

keyword is used where an account will be translated but a data-point of that account

with the specified custom member should not be translated. If the keyword is missing or

is assigned any value other than N, the data-point will be translated according to the cell

type (based on the Account Type and custom Switch Type For Flow settings).

Remark: These custom keywords should never be combined on the same account or translations

will be incorrectly aggregated. If two of the custom members of a data-point both have

this keyword setting, the translated result will be the un-translated value translated at a

factor of 2.

Custom1 Dimension

The Custom1 dimension is used for analysis for most schedules. Custom1 members are grouped under

the SystemMembers parent by generic category and QRT schedule type.

• Countries

• Cover

o Country and Cover schedules

• BSC1B

• Group


• OF (Own Funds)






• VA (Variance Analysis)

• Validations

• RFF Types

o To classify RFF entities by type (standard, Article 4, Deduction & Aggregation).

• Input at Group Only

o Members that are to be entered at Group entities only

The descendants of the Custom1 parent Countries may be modified but all other hierarchies and

members must be retained.

Custom1 User Defined Fields

Keyword: BSSource

UD Field: ALL


Example: BSC1_TPIndexUnitLinked

Used By: Group calculations (Sub GroupG14)

Description: Defines the source account from which to copy data to group accounts.

Keyword: CIC

UD Field: ALL


Keyword: ConsPct

UD Field: ALL

Valid Entry: Valid number from 0 to 100

Example: 50

Used By: Group calculations (Sub Group01)

Description: Defines the default Consolidation Percent Threshold for Subsidiary consolidation.

Keyword: DataRange

UD Field: ALL

Valid Entry: Valid numeric range separated by a tilde (~) where an asterisk (*) represents no limit

Example: -1~1

Used By: Data entry validation routines

Description: The QMR application assumes all data entry will be positive values. Where exceptions

are required, the DataRange keyword provides the acceptable data range. So for

Correlation Table data for example, all entries must be in a range from -1 to +1. An

asterisk can be used to represent no limit on the upper or lower limits. A required

negative or zero entry would be represented by *~0.

Keyword: PCTDest

UD Field: ALL

Valid Entry: Valid Custom1 dimension label

Example: Group_TotalContPct

Used By: Group calculations (Sub Group01)

Description: Defines the destination custom member for percentage calculations.

Keyword: SCRKeyword

UD Field: ALL

Valid Entry: Valid RFF keyword (RFF, RFF4, RFFDA)

Example: RFF



Used By: Function GetRFFKeyword (used in Sub Calculate_SCR)

Description: This entry is assigned to the Custom1 base of C1_RFF_TYPES. It is used to return the

keyword assigned to the RFF type of an entity, that is set by period via the flag account

RFF_Type.

Keyword: SMDivRisk

UD Field: ALL

Valid Entry: Valid account label

Example: SCRB3F_Hail

Used By: SCR Diversification calculations

Description: During the diversification calculations, each factor in the correlation table is multiplied by

the related risks on the two axes of the table. This keyword points to the related risk

account for each member on the axes of the correlation table.

Custom2 Dimension

The Custom2 dimension is used for analysis for some Balance Sheet, SCR, Re and TP schedules.

Custom2 members are grouped under the SystemMembers parent by generic category and QRT

schedule type.

• Countries and Regions

• ListItems

o ListItems include ten numbered base members (000001 to 000010) used for transaction-like

entries to Own Funds (OF) and Balance Sheet (BS-C1B) schedules. Add additional members as

required.

• BS (Balance Sheet)


• OF (Own Funds)




o TP Claims Incurred

� The Claims Incurred hierarchy (TP_ClaimsIncurred) comprises 21 “brackets” as required

by EIOPA for the TP-E6 and TP-E7B schedules.

� There are 5 options for the range of each bracket as specified in the EIOPA log files. The

standard QMR metadata provides descriptions for EIOPA option 1 (“20 brackets of 5,000

plus 1 extra bracket for incurred losses > 100,000”).

� If one of the other options is to be used, modify the descriptions to reflect the lower and

upper bounds of each bracket. In all cases, 20 brackets plus one “greater than” bracket are

required.

� Note that the same option must be used for both schedules.

• Validations

The descendants of the Custom2 parents ListItems and Countries may be modified but all other

hierarchies and members must be retained. Note that if additional countries are added, they must also

be added under the relevant region (children of R_RegionsBefore) and EEA region (children of

RegionsEEA) or Non-EEA region (children of RegionsNonEEA).




There are no UD field entries specific to the Custom2 dimension. The previously used ConsMCR and

ConsSCR are no longer used.

Custom3 Dimension

The Custom3 dimension is used for analysis for some SCR and TP schedules. Custom2 members are

grouped under the SystemMembers parent by generic category and QRT schedule type.

• Currencies

o Used for analysis of assets / liabilities / risks etc.

o Note that Currencies used to designate the currency of an entity are in the Value dimension and

are independent of and not related to this dimension hierarchy.

• Flows

o Balance Sheet movements for Own Funds accounts

• ListItems

o ListItems include ten numbered base members (000001 to 000010) used for transaction-like

entries to Own Funds (OF) and Reinsurance (Re) schedules. Add additional members as

required.

• Cover

• Models (SCR models)


o ReJ2 includes ten numbered base members from the ListItems hierarchy. When additional

items are added to ListItems, they can also be added to the ReJ2 hierarchy if required.

� Note that this hierarchy is used in the RE_J2_Group data entry form in conjunction with all

base ICP members and all Non-Life LoB. If the total number of cells available in the form

exceeds 25,000 then the form will not open. So depending on the number of base ICP

entities that exist in the application, the ListItems that are added to ReJ2 should be

limited if possible.


• Validations

The descendants of the Custom3 parents ListItems and Currencies may be modified but all other

hierarchies and members must be retained.


Keyword: CalcPrefix

UD Field: ALL

Valid Entry: Prefix matching Account UD field SCR calculation entry

Example: SMCalc


Description: This entry is assigned to the Standard Formula (SM), Standard Formula With USP

(SMU) and Partial Internal Model (PIM) members to indicate to which models to apply

an SCR calculation. SM calculations are also applied to SMU and to PIM. SMU

calculations are also applied to PIM. PIM calculations do not apply to any other models.

Remark: This entry provides the model-specific prefix for the sequential UD field entries used in

the account dimension to define calculation types.



Keyword: CalcSolo

UD Field: ALL

Valid Entry: Prefix matching Account UD field SCR calculation limitation

Example: SMSolo



(SMU) and Partial Internal Model (PIM) members to indicate whether to limit the

matching CalcPrefix calculation definition to group or solo entities.


the account dimension to define any group or solo entity limitation for the matching

calculation types.

Keyword: CalcSource

UD Field: ALL

Valid Entry: Prefix matching Account UD field SCR calculation source

Example: SMSource



(SMU) and Partial Internal Model (PIM) members to indicate the source data (if

required) for the matching CalcPrefix calculation definition.


the account dimension to define the source data for the matching calculation types.

Custom4 Dimension

The Custom4 dimension is used for analysis for some Technical Provisions (TP) schedules and can

provide for a Data Source or other analysis for other schedules. Custom4 members are grouped under

the SystemMembers parent by generic category and QRT schedule type.

• Currencies

o Used for analysis of TP-E3

o Note that Currencies used to designate the currency of an entity are in the Value dimension and

are independent of and not related to this dimension hierarchy.

• Data Sources

o This descendants of TotalDataSources can be customized as required but the parent member

must be retained and the [None] member must be a descendant of TotalDataSources.


• Validations

The descendants of the Custom4 parents TotalDataSources and Currencies may be modified but all

other hierarchies and members must be retained.


There are no UD field entries specific to the Custom4 dimension.

Cell Text Labels

Several Cell Text Labels are used in the QMR application.

• [Default]

o Used for all user data entry and most reporting



• DataLineage

o Used for all system-created calculation audit trail such as SCR Diversification calculations and

available for viewing in Data Entry Forms

• ICDetail

o Used internally in generating proportional eliminations in a multi-level hierarchy

• SimpleUSPPIM

o Used to gather Simplification, USP and Partial Internal Model usage for Group reporting

• SingleName

o Used to store SCR-B3B transactional data for internal retrieval, review and sorting

• Validation

o Used to present Validation messages



Member Lists

The Member Lists file provides lists of metadata members that are used in Rules, Web Data Entry

Forms and Reports.

Should additional member lists be required, it is strongly recommended that:

• Similar techniques as are currently used also be used to add new lists.

• Any new code added, or existing code removed or changed should be noted in the file.

Example of change documentation

Existing line in Member Lists file:

Dim AccountLists(15)

After replacing the existing line with a new line:

‘ABC Company 2012-07-01 Replaced following line to add an additional member list ‘Dim AccountLists(15) Dim AccountLists(16)

As updated standard QMR Member Lists files are issued, a file-compare utility can be used to identify

any new code in the newly issued file and the additional code in the client file.

The Member Lists file creates some lists based on metadata attributes. In order to maximize

performance at run-time, some of these lists are pre-processed when the Member Lists file is loaded or

the first user logs on. To ensure that all list are based on current metadata, it is recommended that

the Member Lists file always be re-loaded after a Metadata file is loaded.



Rules

The Rules file provides calculation, translation and consolidation logic. Standard calculations and logic

have been provided based on expectations of client requirements.

If changes are made to the Rules file, it is recommended that those changes be documented within the

file so that the changes can be identified and duplicated easily should an updated QMR Rules file be

issued. To change a line in the file, copy the line, comment out the original, change the copy and

precede the change with a left-justified comment:

‘ABC Company 2012-07-01 Replaced following one line to deactivate a rule ‘Const RUN_RULE_CASHFLOW_COPY = TRUE Const RUN_RULE_CASHFLOW_COPY = TRUE

If new rules are to be added to the Rules file, it is recommended that the new code be created in a

separate subroutine at the end of the Rules file, and the call to the new subroutine be noted with a

comment.

‘ABC Company 2012-07-01 Added following one line to call new rule Call CalculateStatisticsABCCompany

As updated standard QMR Rules files are issued, a file-compare utility can be used to identify any new

code in the newly issued file and the additional code in the client file.

The Rules file creates some internal lists based on metadata attributes. In order to maximize

performance at run-time, some of these lists are pre-processed when the Rules file is loaded or the

first user logs on. To ensure that all list are based on current metadata, it is recommended that the

Rules file always be re-loaded after a Metadata and Member Lists file is loaded.

The Rules file contains the following sections which should be reviewed during implementation:

• Client configuration settings

• User-Defined Field Entries for Rules

Client Configuration Settings

The following configuration settings should be reviewed and modified if required.

Const CORRELATION_TABLE_OVERRIDE_BY_CELL = False

• If CORRELATION_TABLE_OVERRIDE_BY_CELL is set to True, then if any data is entered to a non-

Standard Formula correlation table, a NoData cell in that table will be populated with the value

from the Global Standard Formula table - this provides a cell-by-cell override.

• If CORRELATION_TABLE_OVERRIDE_BY_CELL is set to False, then if any data is entered to a non-

Standard Formula correlation table, a NoData cell will be populated as a zero - this provides a

table-by-table override.

Const CLEAR_INVALID_CORRELATION_FACTORS = True

• Data entered to the global or local correlation tables is validated. If entered data is invalid (where

data is not in the range from -1 to +1), a validation entry is made.

• If CLEAR_INVALID_CORRELATION_FACTORS is set to True, invalid correlation table data will be

cleared.



• If CLEAR_INVALID_CORRELATION_FACTORS is set to False, invalid correlation data will not be cleared

Const SUPPRESS_ZERO_DIVERSIFICATION_IMPACT_CELLTEXT_ENTRY = True

• Cell Text Diversification Calculation detail includes each entry as applied by the calculation. To

suppress details that have no impact on the result (e.g. a zero correlation factor), set this entry to

True.

Const CELLTEXT_USE_COUNTRY_DESCRIPTION = False

• ISO Country codes are used in the cell text data lineage for Geographic Diversification calculations.

To add the country description, set this entry to True.

• Note that rules cannot read the metadata description fields so the descriptions must be duplicated

in a UD Field, using the language code as the keyword. The metadata Custom1 UD Fields for

countries includes the EN descriptions only. If descriptions in other languages are required, they

must be added to the standard metadata. The Metadata Localization Utility does not automatically

updated the UD Fields.

Const CELLTEXT_USE_VALIDATION_DESCRIPTION = False

• Some validation errors list the valid metadata member labels that may be used for an entry. To

add the description in addition to the member labels, set this entry to True

• Note that the relevant description must be entered to a UD Field in the relevant dimension.

Const CHECK_NONE_ENTITY_CALC_STATUS = False

• The [None] entity should have a Calculation Status of OK before running calculations for other

entities. The global correlation table data will not be calculated or validated unless the [None]

entity is calculated. So the entry for this option should generally be True unless there is confidence

that no invalid amounts were entered to the global correlation tables.

Const ENABLE_NATURE_FOR_ELIMS = False

• To enable the creation of Source / Destination Transactions for elimination entries, change this

setting to True.

Const WRITE_CELLTEXT_ON = True

• To prevent cell text entries being written, change this setting to False.

Const MAX_CELL_TEXT_SIZE = 20000

• To prevent rules trying to write cell text entries that are too long for the metadata-specified

maximum number of characters, this setting must match the metadata App Settings

"MaxCellTextSize" entry. If the "MaxCellTextSize" is empty, change this setting to 8000.

Const SETUP_UNDERTAKING_TYPE_AT_GROUP = False

• Set SETUP_UNDERTAKING_TYPE_AT_GROUP to True if Group sets up undertaking types.

• Set SETUP_UNDERTAKING_TYPE_AT_GROUP to False if individual entities set up themselves.

Const CONSOLIDATE_TOTC4_TO_NONE = True

• Set CONSOLIDATE_TOTC4_TO_NONE to True if Custom4 details should be mapped to Custom4 [None]

when consolidating.

• Set CONSOLIDATE_TOTC4_TO_NONE to False if Custom4 details should be maintained when

consolidating.



Const INPUT_STAT_AT_GROUP = False

• Set INPUT_STAT_AT_GROUP to True to allow already consolidated Statutory Balance Sheet data to

be entered at group.

• Set INPUT_STAT_AT_GROUP to False to consolidate group Statutory Balance Sheet from solo Balance

Sheet entries.

Const INPUT_SII_AT_GROUP = False

• Set INPUT_SII_AT_GROUP to True to allow already consolidated SII Balance Sheet data to be

entered at group.

• Set INPUT_SII_AT_GROUP to False to consolidate group SII Balance Sheet from Legal Entity / Solo

Balance Sheet entries.

Const VALIDATE_SII_BS_AT_DATA_ENTRY = True

• Set VALIDATE_SII_BS_AT_DATA_ENTRY to True to run Balance Sheet validations at all data entry

points. If INPUT_SII_AT_GROUP = True then the validations will also run at Group. Balance Sheet

Validations match B/S totals against the sum of details entered to other schedules.

• Set VALIDATE_SII_BS_AT_DATA_ENTRY to False to prevent Balance Sheet validations running at all

data entry points.

Const VALIDATE_SII_BS_AT_BRANCH = False

• Set VALIDATE_SII_BS_AT_BRANCH to True to run Balance Sheet validations at all Branch and

Consolidated RFF entities including parent Branch entities.

• Set VALIDATE_SII_BS_AT_BRANCH to False to prevent Balance Sheet validations running at Branch

and Consolidated RFF entities. Note that if Validations are set to run at Data Entry, then Validations

will run at base (data entry) Branch and Consolidated RFF entities regardless of this setting.

Const VALIDATE_SII_BS_AT_LEGAL_ENTITY = False

• Set VALIDATE_SII_BS_AT_LEGAL_ENTITY to True to run Balance Sheet validations at all Legal Entity

/ Solo entities including parent entities.

• Set VALIDATE_SII_BS_AT_LEGAL_ENTITY to False to prevent Balance Sheet validations running at

Legal Entity / Solo entities. Note that if Validations are set to run at Data Entry, then Validations

will run at base (data entry) Legal Entity / Solo entities regardless of this setting.

Const VALIDATE_SII_BS_AT_GROUP = False

• Set VALIDATE_SII_BS_AT_GROUP to True to run Balance Sheet validations at all Group entities.

• Set VALIDATE_SII_BS_AT_GROUP to False to prevent Balance Sheet validations running at Group

entities.

Const DEFAULT_MESSAGE_LANGUAGE = "EN"

• Set DEFAULT_MESSAGE_LANGUAGE to the ISO code for the default language to be used when writing

to cell text. QMR 2.1.1 provides EN, DE, ES, FR and NL translations. The default language specified

here will be used only if a language is not specified for the entity in an Entity dimension User

Defined field, either for the specific entity or for any of its ancestors.



Settings for Rules Logic

Consolidation Methods

Holding company method

• MethodHOLDING HOLDING

Subsidiary (Global) method

• MethodSUBS SUBS

Subsidiary Full Risk method

• MethodSUBS_FR SUBS_FR

Subsidiary Deduction and Aggregation method

• MethodSUBS_DA SUBS_DA

Subsidiary Deduction and Aggregation Full Risk method

• MethodSUBS_DA_FR SUBS_DA_FR

Significant Participations (Equity) method

• MethodPSI PSI

Significant Participations Full Risk method

• MethodPSI_FR PSI_FR

Significant Participations Deduction and Aggregation method

• MethodPSI_DA PSI_DA

Significant Participations Deduction and Aggregation Full Risk method

• MethodPSI_DA_FR PSI_DA_FR

Not consolidated method

• MethodNOTCONSOL NOTCONSOL

User Defined Fields

Entity Dimension

• Parent of the ring fenced funds’s (RFF’s) of group’s legal entities

o UDFIELD_GROUP_RFF ALL

o KEYWORD_GROUP_RFF GroupRFF

• Parent of the ring fenced funds’s (RFF’s) of a legal entity

o UDFIELD_LE_RFF ALL

o KEYWORD_LE_RFF LeRFF

Account Dimension

• SCR account for D&A methods



o UDFIELD_A_DA ALL

o KEYWORD_LE_DA D&A

• Elimination account for own funds

o UDFIELD_A_ELIMOF ALL

o KEYWORD_LE_ELIMOF ElimOF

• Minority account for participations and own funds

o UDFIELD_A_MINOF ALL

o KEYWORD_A_MINOF MinOF

• SCR account for Participation Significant methods

o UDFIELD_A_PSI ALL

o KEYWORD_A_PSI PartSig

• Works with the keywords defined via KEYWORD_C1_RFF, to set the mapping SCR account of RFF’s

o UDFIELD_A_RFF ALL

• Consolidation rule assigned to an account

o UDFIELD_CONSRULE ALL

o KEYWORD_CONSRULE ConsRule

• Disallow intercompany eliminations of an account

o UDFIELD_ELIMICP ALL

o KEYWORD_ELIMICP N

• Disallow input in [ICP Entities] for an account

o UDFIELD_NOINPUT ALL

o KEYWORD_NOINPUT_ICP NoInputICP

• Disallow input for own funds accounts on a quarterly or yearly basis

o UDFIELD_NOINPUT ALL

o KEYWORD_OF_NOINPUT OFNoInput

Consolidation Rules entries (entries returned from the ConsRule UD keyword)

• Balance sheet rule

o CONSRULE_BS BS

• Dividends rule

o CONSRULE_DIV DIV

• Group rule

o CONSRULE_GROUP GROUP

• Equity rule

o CONSRULE_EQUI EQUI

• Investments rule

o CONSRULE_INVS INVS



• Merge rule

o CONSRULE_MERGE MERGE

• Minimum Capital Requirements rule

o CONSRULE_MCR MCR

• Non Available Own Funds rule

o CONSRULE_NAV NAV

• Own Funds rule

o CONSRULE_OF OF

• Solvency Capital Requirements rule

o CONSRULE_SCR SCR

Custom Dimensions (all)

• Disallow consolidation of a custom member

o UDFIELD_CONSCUSTOM ALL

o KEYWORD_CONSCUSTOM Consolidate

• Translate at 1 a custom member

o UDFIELD_TRANSCUSTOM ALL

o KEYWORD_TRANSCUSTOM Translate

Custom1 Dimension

• Keyword assigned to the custom1 base of C1_RFF_TYPES

o UDFIELD_C1_RFF ALL

o KEYWORD_C1_RFF SCRKeyword

Rules Overview

Calculation Rules

• Sub Calculate_BS

o Calculates the account A_BS_EQUITY as difference between assets and liabilities.

o Sub Calculate_BS runs from Sub Calculate, at Value <Entity Currency> base.

• Sub Calculate_OwnFunds

o Execute various calculation for own funds accounts.

o The most significant are:

� Calculate Net Assets and Own Shares from Balance Sheet, when available

� Calculate Opening Balance from Prior Year, when flows are required

� Calculate own funds accounts from flows or detail on a yearly basis

� Calculate ring-fenced fund adjustment and deduction

� Calculate Eligible SCR and MCR

� Calculate SCR and MCR ratios



o Sub Calculate_OwnFunds runs from Sub Calculate, at Value <Entity Currency> and

adjustments

• Sub Calculate_SCR

o Calculates the SCR results at <Entity Currency> of RFF, Solo and Group entities.

o The routine loops through a list of accounts in the sequence defined by the CalcSeq1 member

list at <Entity Currency> of RFF, Solo and Group entities.

o For each account, any rule defined in the UD Field is executed against the account.

o The rules definitions are as follows:

� CatSquared

� CatGrossFactor

� CopyCatToSCR

� CopyGrossToNet

� CopyMember

� CopyTotal

� Diversify

� Formula

� GeoDiversify

� MaximumC1

� Maximum

� Minimum

� OpRiskBasicSCR

� OpRiskPrem

� OpRiskTP

� OpRiskTotal

� RationalizePIM

� ReverseSign

� StdCC

� Volume

� VolumeStdDev

� VolumeTotal

• Sub Calculate_MCR

o Calculates the MCR results

• Sub Calculate_SCR_Proportional

o Calculates the SCR accounts for Participations Significant and Deduction & Aggregation

consolidation methods, from the accounts A_SCRB2A_TOTALSCR, A_SCRB2C_TOTALSCR (for

more detail, see D&A and PartSig keywords above).

o Sub Calculate_SCR_Proportional runs from Sub Calculate, at Value [Proportion]

• Sub ImpactLeFromRFF



o Throws impact status from a ring fenced funds (RFF) entity to its corresponding legal entity,

that needs to be recalculated when changes occur to RFF’s SCR accounts.

o Sub ImpactLeFromRFF runs from Sub Calculate, at Value <Entity Currency> for a base RFF.

• Sub SetExchangeRates

o Calculates account RATE_OPENING from prior year closing rate.

o Sub SetExchangeRates runs from Sub Calculate.

• Sub Validate_BS

o Execute Balance Sheet validations.

o These validations match the balance sheet Solvency II entry to the summary of the Assets

schedules details.

o Each validation is defined in the UD Field of the Balance Sheet account by the keyword entry

“ValidateSII” (also see Keyword: ValidateSII: on page 31):

� ValidateSII:A#Assets_Property

- The Balance Sheet account on which the UD Field entry is made is validated against the

“Assets_Property” account

o Sub Validate_BS runs from Sub Calculate, at Value <Entity Currency> base and adjustments.

• Sub Validate_LocalCellText

o Execute Cell Text entry

o These validations verify that the Cell Text entry matches either:

� A date format (ISO 8601 “YYYYMMDD” format)

� A “closed list” (a list of specific entries)

o Each validation is defined in the UD Field of the Custom dimension member by the keyword

entry “CellText” (also see Keyword: CellText: on page 22):

� CellText:[Date]

- The Cell Text entry is validated against the ISO 8601 date format

� CellText:[Date],P

- The Cell Text entry is validated against the ISO 8601 date format OR the character “P”

� CellText:Y,N

- The Cell Text entry is validated against the closed list of “Y” and “N”

� CellText:C2{Countries.[Base]}

- The Cell Text entry is validated against the label of the base members of member

“Countries” in the C2 dimension

o Sub Validate_LocalCelltext runs from Sub Calculate, at Value <Entity Currency> base.

• Sub Validate_OwnFunds

o Execute own funds validations.

o These validations include:

� Own funds solo validation check

� Own Shares validation Balance Sheet vs. Flows



� Validations Detail vs. Flows (ex.: Preference Shares)

� Validations Detail vs. Transactions (ex.: Preference Shares)

o Sub Validate_OwnFunds runs from Sub Calculate, at Value <Entity Currency> base and

adjustments.

• Sub Validate_RFF

o Validates that one and only one RFF Type has been entered for a RFF entity in the flag account

A_RFF_TYPE. If no values exist, the first Type is set to 1. If only one value exists and it is

different from 1, it is set to 1. If multiple values exist, the first Type found is kept as 1 and the

others are cleared.

o The RFF Type of a RFF entity is used to determine the solo SCR account to which to copy total

RFF’s SCR amounts (for more detail, see RFF, RFF4, RFFDA and SCRKeyword keywords above).

o Sub Validate_RFF runs from Sub Calculate, at Value <Entity Currency> for a base RFF.

Translation Rules

• FX Differences

o When an account is detailed by flows (i.e. own funds), FX differences are calculated in Sub

Translate, using the direct mode.

o C3_OPENING_BALANCE is translated at opening rate, all the other flows are translated at

average rate and C3_FX_DIFF is computed as sum of:

� FX difference on opening => C3_OPENING_BALANCE * (closing rate – opening rate)

� FX difference on flows => (C3_TOT_FLOWS - C3_OPENING_BALANCE) * (closing rate –

average rate)

Consolidation Rules

Accounts to be consolidated must have a consolidation rule assigned via the keyword ConsRule (see

above). If the keyword is missing, it will be retrieved from the ConsRule assigned to the account’s

default parent, continuing to search up to the root level until found. If no ConsRule entry is found, the

account is not consolidated (even if IsConsolidate=Y is set in metadata).

• Balance Sheet rule (BS)

o This rule is used to consolidate balance sheet accounts.

� Methods consolidated: HOLDING, SUBS, SUBS_FR, SUBS_DA, SUBS_DA_FR

� Percent consolidation: PCon

� ICP Methods eliminated: HOLDING, SUBS, SUBS_FR, SUBS_DA, SUBS_DA_FR

� Percent elimination: PCon

o Description: Consolidates accounts of entities with method in the list above (Global), using

percent consolidation (PCon, normally 100%). Eliminates intercompany transactions with

partner’s method in the same list, using the same percentage. The elimination is balanced to

the plug account assigned to the account in metadata.

o Special cases:

� If a plug account is not assigned to the account in metadata, the elimination will be done on

a single-sided basis.

• Dividends rule (DIV)

o This rule is used to consolidate dividends accounts.



o This rule is identical to the Own funds rule (OF, see below), with the exception that no

elimination entry is applied to the account A_OFG_CONS_RES (own funds consolidation

reserve).

• Equity rule (EQUI)

o This rule is used to consolidate balance sheet equity accounts.

� Methods consolidated: All (except NOTCONSOL)


� Percent elimination: POwn, PMin

o Description: Consolidates accounts of entities with method in the list above (all methods), using

percent consolidation (PCon).

o When the method is PSI, PSI_FR, PSI_DA, PSI_DA_FR (Equity), balance sheet is balanced to

the account A_BS_PART_SIG (Significant Participations).

o When the method is different from HOLDING, eliminates the amount to the accounts

A_BS_CONS_RES (consolidation reserve) and A_BS_MINORITY (minority interests), using

percent ownership (POwn) and percent minority (PMin) respectively.

• Group rule (GROUP)

o In order to report “transaction” (Cell Text entries) at a group level for each Solo / Legal entity,

when consolidating from Solo / Legal entity to a Group entity, the Solo / Legal entity label is

inserted to the destination POV as the ICP member. At a Group level, the data / cell text can

then be reported by Solo / Legal entity.


� Percent consolidation: 100% (to retain the full Solo / Legal entity data value)

� ICP Methods eliminated: None

� Percent elimination: N/A

• Investments rule (INVS)

o This rule is used to consolidate balance sheet participations in subsidiaries.



� ICP Methods eliminated: All (except NOTCONSOL)


o Description: Consolidates accounts of entities with method HOLDING, SUBS, SUBS_FR,

SUBS_DA, SUBS_DA_FR (global), using percent consolidation (PCon, normally 100%).

o When the entity and the partner’s method are in the list above (all methods), the investment is

eliminated to the partner’s accounts A_BS_CONS_RES (consolidation reserve) and

A_BS_MINORITY (minority interests), using percent ownership (POwn) and percent minority

(PMin) respectively. Furthermore, to balance contributions, the account A_BS_CONTRA_INV

(contra-account participations) is used. When the method is PSI, PSI_FR, PSI_DA, PSI_DA_FR

(Equity), the elimination entry is balanced to the account A_BS_PART_SIG (Significant

Participations).

o When processing Custom2 C2_BS_SII, the rule is also writing, using POwn, to account

A_OFG_CONS_RES (own funds consolidation reserve) and, using PMin, to the account set with

the keyword MinOF.



• Merge rule (MERGE)

o In order to report “transaction” (Cell Text entries) at a group level for each base entity, when

consolidating from the base entity to the first parent, the base entity label is inserted to the

destination POV as the ICP member. At a parent Solo and Group level, the data / cell text can

then be reported by base (data entry) entity.



� ICP Methods eliminated: None

� Percent elimination: N/A

• Minimum Capital Requirement rule (MCR)

o This rule is used to consolidate MCR accounts.


� Percent consolidation: POwn

� ICP Methods eliminated: All (except NOTCONSOL)

� Percent elimination: Min(POwn,ICPPOwn)


percent ownership (POwn). Eliminates intercompany transactions with partner’s method in the

same list, using the minimum between the entity (POwn) and the partner (ICPPOwn) percent

ownership. The elimination is balanced to the plug account assigned to the account in

metadata.

o Special case:



• Non Available Own Funds rule (NAV)

o This rule is used to consolidate non available own funds accounts.



� Percent elimination: PMin


percent consolidation (PCon). The entry is done to the ICP corresponding to the entity

processed, to keep track of the source entity at consolidated level.

o When the method is different from HOLDING, eliminates, using percent minority (PMin), from

the account to the account set with the keyword MinOF.

o Special case:

� If the keyword MinOF is missing, only eliminates the account.

• Own Funds rule (OF)

o This rule is used to consolidate own funds accounts.







percent consolidation (PCon).

o When the method is different from HOLDING:

� eliminates, using percent minority (PMin), from the own funds account to the account set

with the keyword MinOF.

� eliminates, using percent ownership (POwn), from the account set with the keyword ElimOF

to the account A_OFG_CONS_RES (own funds consolidation reserve).

o Special case:

� If the keyword ElimOF is missing, the two entries above are not done.

• Solvency Capital Requirement rule (SCR)

o This rule is used to consolidate SCR accounts.

� Methods consolidated: HOLDING, SUBS, SUBS_FR

� Percent consolidation: POwnSCR

� ICP Methods eliminated: HOLDING, SUBS , SUBS_FR

� Percent elimination: Min(POwnSCR,ICPPOwnSCR)

o Description: Consolidates accounts of entities with method in the list above (global, with the

exception of D&A), using percent ownership (POwn). Nevertheless, when the method is

SUBS_FR and the amount of the account A_OF_ELIGIBLESCR (Total eligible own funds to meet

the SCR) is less than the account A_OF_TOTALSCR (Total Solvency Capital Requirement),

100% is used instead (full risk concept).

o Eliminates intercompany transactions with partner’s method in the same list, using the

minimum between the entity (POwn) and the partner (ICPPOwn) percent ownership. 100% will

be used instead for entity or partner percentage when method or partner method is SUBS_FR

and A_OF_ELIGIBLESCR < A_OF_TOTALSCR, as explained above. The elimination is balanced

to the plug account assigned to the account in metadata.

o Special case:





Data Entry Forms

Data Entry Forms provide data entry and review capabilities. The forms provided with QMR are

designed to meet normal anticipated requirements but clients may create their own additional forms if

required.

One set of Data Entry Form files are provided, catering for both HFM 11.1.2.1 and 11.1.2.2. Two

optional forms are also provided and can be loaded individually. These forms are not loaded as part of

the LCM load process. For further details on these optional forms, see the Optional Forms section

(below).

For further details on the forms provided with QMR, please refer to the QMR Administrator / User

Guide. For further details on developing Web Data Entry Forms, please refer to the HFM

Administrator’s Guide.

Loading Data Entry Forms

The individual data entry form files are saved as *.wdf files but are also included in an LCM

QMR210Forms.zip file.

To install the forms as a batch:

• Prerequisites

o Create the application

o Load the QMR metadata

o Load the QMR Member Lists

• To load the file using EPM Shared Services

o Unzip the LCM zip file to the following server directory:

o HFM 11.1.2.1

<oracle middleware directory>\user_projects\epmsystem1\import_export\admin@Native

o HFM 11.1.2.2

<oracle middleware directory>\user_projects\epmsystem1\import_export\<user directory>

� In order to suppress a warning message, open file \info\sourceInfo.xml:

Replace: <ProductVersion>11.1.2.1</ProductVersion>

With: <ProductVersion>11.1.2.2</ProductVersion>

o Log on to Shared Services and expand the File System directory

o Select the QMR210Forms item

� If QMR210Forms is not displayed, the files have not been placed in the correct directory

o Select the Forms check box

o Select Define Migration

o Select Next and the select the new application as the destination

o Select Next and review the source and destination

o Select Next and then select Execute Migration

o All forms will be loaded to the selected application in the pre-defined folder structure



To install the forms files individually:

• From the Document Management screen, create folders as required for organizing the reports.

• Import each of the forms *.wdf files to the appropriate folder.

• Note that no specific folder organization is required.

Optional Forms:

There are two linked forms providing details of BS-C1B analysis. These forms are included in the LCM

forms file:

• BS_C1B_Details_Contingencies.wdf

• BS_C1B_Details_Guarantees.wdf

These forms are sparse data entry forms and contain only cell text entries, no numeric data. A sparse

data entry form suppresses all rows that have no data, and allow the user to add new rows by opening

a Member Selector window. However, after entering the cell text, the row will remain suppressed

instead of displaying because suppression works on data, not cell text. So it necessary to run a rule to

populate a data value related to the cell text in order to prevent suppression. For HFM 11.1.2.1,

Calculate (or Force Calculate) must be run and the cell-text-only rows will then be displayed. For

HFM 11.1.2.2, an OnDemand rule (BSC1B_UpdateTextEntry) can be run instead of Calculate after

which the rows will be displayed.

Alternatively, linked forms that do not suppress any rows without data can be used instead of the

sparse data entry forms. These forms will display all possible rows and therefore do not require a

Calculate in order to display the cell text entered.

If the forms without row suppression are preferred, load the following forms:

• BS_C1B_Details_Contingencies_NoSuppress.wdf

• BS_C1B_Details_Guarantees_NoSuppress.wdf

Note that loading these forms will overwrite the sparse data entry forms (the file name is different but

the form name is the same). There is no option to use both types of forms concurrently because they

are linked from the main BS-C1B form.

Either set of forms can be reloaded at any time because there is no impact on the data or cell text

stored.



Financial Reports

Financial Reports (FR) provide review and printing capabilities. The Financial Reports provided with

QMR are designed to meet normal anticipated requirements but clients may create their own additional

reports if required.

For further details on developing Financial Reports, please refer to the Financial Reports

Administrator’s Guide.

Loading Financial Reports

The individual financial report files are saved as *.des files but are also included in a *.zip file.

There are also a series of linked objects (*.rog, *.rot and *.roi files). These linked objects are

embedded in each report. If the linked objects are modified, the changes apply to all reports when re-

imported.

To install the reports files as a batch:

• From the Workspace, Explore screen, import the QMR Reports.zip file to the root directory.

• Installing the Financial Reports by importing the zip file will automatically create a QMR 2.1.0

folder in Workspace. All linked objects are placed into a System directory (QMR 2.1.0/99_System).

• The required database connection will be different than that used to create the reports so this must

be updated either while importing or after importing. It is suggested that the database connection

be updated using the following steps:

o From the Explore root directory, select File > Import then browse to and select the

“QMR211FinancialReports.zip” file

o When the Database Connection warning message appears, select Create New Connection

o The connection details originally used to create the reports will be displayed:

� Either accept or overtype the QMR210 connection name

� Overtype the server name with the required server name, then enter the administrator User

ID and Password used to connect to the application

� Browse to the required application (drill down to the lowest level available)

• If after importing all files, the headers and footers do not display in the reports, double-check that

the linked objects are in the appropriate folder and re-import the *.des files

To install the reports files individually:

• From the Workspace, Explore screen, create folders as required for organizing the reports.

• Create the folder for the linked objects.

• Import the linked objects files into the created folder.

o If the linked objects are renamed or placed other than in the QMR 2.1.0\99_System folder,

each report *.des file must be edited before being imported and the new location must be

entered.

o To edit, open the *.des file with a text editor and search for:

� "OBJECT_LINKNAME="/QMR 2.1.0/99_System/<filename>""

Replace with the required location/filename.

• Import each of the report *.des files to the appropriate folder.



• The database connection will be different than that used to create the reports so this must be

updated either while importing or after importing. It is recommended that the 99_System objects

be imported first and the Database Connection changed on the QMRHeaderDescription.rog

object before importing any other reports.

To change the logo used in the reports:

• Using the Financial Reporting Studio client application, create a new blank report and insert the

required logo as an image (for further details, please refer to the Financial Reports User Guide).

• Save the image as an object named QMRLogo.roi, overwriting the original QMRLogo.roi file (in the

QMR 2.1.0/99_System folder, or alternative folder if the location was edited in the *,des files).

To change other objects used in the reports:

• Header Entity

o Two Entity objects have been created:

� QMRHeaderEntityDesc.rot / QMRHeaderEntityLabelDesc.rot

o To display the entity description only in the report headers, copy QMRHeaderEntityDesc.rot to

file QMRHeaderEntity.rot and import before importing the reports *.des files

o To display the entity label and description, copy QMRHeaderEntityLabelDesc.rot to file

QMRHeaderEntity.rot and import before importing the reports *.des files

o Note that QMRHeaderEntity.rot is by default the same as QMRHeaderEntityLabelDesc.rot

• Other objects

o Using the Financial Reporting Studio client application:

� create a new blank report

� insert the saved object to be changed

- For example, to change the date format in the footer, insert object QMRFooterRight

� adjust the object contents as required in the text object

� save the text object

� re-import the *.des files

For further details, please refer to the Financial Reports User Guide.

List of linked objects

• QMRFooterCenter.rot text - footer page number

• QMRFooterCenterSection.rot text - footer section number

• QMRFooterLeft.rot text - footer report label

• QMRFooterRight.rot text - footer date

• QMRHeaderContextLabels.rot text - header context labels (Scenario, Year etc.)

• QMRHeaderContextMembers.rot text - header context members

• QMRHeaderDescription.rog grid - hidden grid containing header references

• QMRHeaderEntity.rot text - header entity

• QMRHeaderEntityDesc.rot text - header entity (description only)

• QMRHeaderEntityLabelDesc.rot text - header entity (label and description)

• QMRHeaderLoB.rot text - header Line of Business

• QMRHeaderModel.rot text - header SCR Model

• QMRHeaderReportDesc.rot text - header Report description

• QMRLogo.roi image - header logo



Working with Data

Data files are provided for SCR Correlation Factors, SCR Standard Deviation Factors, SCR and MCR

Scalar Factors as specified by EIOPA in the Level II documents.

EIOPA Standard Data

Data files are provided for SCR Correlation Factors, SCR Standard Deviation Factors, SCR and MCR

Scalar Factors as specified by EIOPA in the Level II documents.

• QMR_2.1.0_EIOPAData2012QA.dat

o EIOPA-defined Scalar and Correlation table factors

This data is loaded to each reporting period to support the SCR and MCR calculations.

The file can be copied and modified for other scenarios / years / periods by changing the header rows:

!Scenario = Actual !Year = 2012 !Period = QA

Sample Data

Sample data files are provided that can be loaded to the sample organization structure. These files

provide a template of the data-point dimension member definitions.

Data is provided for several solo entities to cover a variety of scenarios.

Annual data (period QA):

• QMR_2.1.0_ExchangeRates2012QA.dat

o Sample Exchange Rates

• QMR_2.1.0_GlobalData2012QA.dat

o Other global configuration and inflation rate data

• QMR_2.1.0_TestData2012QA_Group.dat

o Ownership information, Group reporting percentages, Group SCR capital add-ons

• QMR_2.1.0_TestData2012QA_LE01.dat

o Data set for all schedules processed in HFM, MCR Undertaking type and category, Local override

for Partial Internal Model correlation factors

• QMR_2.1.0_TestData2012QA_LE01_RFF1.dat

o Data set for Balance Sheet, Own Funds and SCR, MCR Undertaking Type and category, RFF

type

• QMR_2.1.0_TestData2012QA_LE01_RFF2.dat

o Data set for Balance Sheet, Own Funds and SCR, MCR Undertaking Type and category, RFF

type



for Partial Internal Model correlation factors, Consolidated as a D&A entity




o Non insurance entity MCR, SCR and OF equivalent data only

• QMR_2.1.0_TestData2012QA_LE04_Branch1.dat


for Partial Internal Model correlation factors, Consolidated as a 100% owned subsidiary entity

from outside of the EEA

• QMR_2.1.0_TestData2012QA_LE04_Branch11.dat

o Limited data set for Re-J1 parent Solo level (LE04) testing

















o Insurance entity MCR, SCR and OF equivalent data only from outside of the EEA


o Insurance entity MCR, SCR and OF equivalent data only from outside of the EEA

• QMR_2.1.0_TestData2012QA_Ownership.dat

o Entity ownership (Method, [PCon], [POwn]) data

Quarterly data (period Q1):

• QMR_2.1.0_ExchangeRates2012Q1.dat

o Sample Exchange Rates

• QMR_2.1.0_GlobalData2012Q1.dat

o Other global configuration and inflation rate data

• QMR_2.1.0_TestData2012Q1_LE01.dat


for Partial Internal Model correlation factors

• QMR_2.1.0_TestData2012Q1_Ownership.dat

o Entity ownership (Method, [PCon], [POwn]) data



HFM Files for FDM

Two files are required to load the entity hierarchy / default currencies to FDM. These files must be

named:

• QMREntityHierarchy.txt

• QMREntityDefaultCurrency.txt

These files must be loaded to FDM before loading any data. The files only need to be re-loaded if /

when changes occur to the entity structure.

One file per reporting period is required to load the exchange rates to FDM. The file is required for

each reporting period and is loaded to FDM in the same manner as a regular data file. The file is

selected by browsing to the FDM inbox and the name of the file is therefore not fixed.

The files can be created manually or can be extracted from the QMR HFM application.

Entity Hierarchy

The Entity Hierarchy file is a two-column tilde (~) delimited file. The first column is the label of every

entity (base and parent) in the organization structure to which data will be loaded and from which

reports are required. The second column is every ancestor of each of the entities in the first column

plus the entity and itself. This format provides a descendant~ancestor entry for every combination

required.

LE01~LE01

LE01~Group

LE01~MultiGroup

LE01~MultiGroup1A

An example of the file is provided with the FDM test data, based on the sample entity structure in HFM.

Entity Default Currency

The entity Default Currency file is a three-column tilde delimited file. The first column is the label of

every entity in the organization structure (all entities included in the Entity Hierarchy file). The second

column is the currency code of the default currency for the entity. The third column is a Boolean entry

indicating whether the entity is a base entity (Y = base, N = parent). This entry determines whether

data can be loaded to the entity.

Group~EUR~N

LE01~EUR~Y

LE01_RFF~EUR~N

LE01_RFF1~EUR~Y

LE01_RFF2~EUR~Y

LE02~EUR~Y

An example of the file is provided with the FDM test data, based on the sample entity structure in HFM.

Exchange Rates

The exchange rate file is a four-column tilde delimited file. The first column is the “from” currency

code, the second column is the “to” currency code, the third column is the Average Exchange Rate and

the fourth column is the Closing Exchange Rate.

A header row can optionally be included but the first column entry must be “Currency_From”.



Note that the exchange rate entered is the value by which the “from” currency value is multiplied to

translate to the “to” currency (e.g. a rate of 1.6 might be entered to translate “from” GBP “to” USD).

Every combination of rates is required in the exchange rate file. This includes the currency code with

itself (at a rate of 1) and every other combination. For example, for two currencies a total of four

entries are required:

Currency_From~Currency_To~Avg_Rate~Closing_Rate

Currency1~Currency1~1~1

Currency1~Currency2~<rate>~<rate>

Currency2~Currency1~<rate>~<rate>

Currency2~Currency2~1~1

An example of the file is provided with the FDM test data, based on the sample HFM 2012 QA data.

Extracting the data files from HFM

In order to extract the required data files from HFM, the HFM Server user created when HFM was

installed must have Write access to a folder accessible to the administrator. A rule run from a data

entry form will write the required file(s) to the folder specified in the Rules file:

Const WRITE_TO_FILE_PATH = "C:\Temp\DebugLogs"

' Const WRITE_TO_FILE_PATH = "\\unc label"

To extract the files, open the EntityExchangeRates_Extract data entry form in the

03_Admin_Global folder.

HFM 11.1.2.1:

Enter a non-zero value to the first data cell in order to extract the Entity Hierarchy / Entity Default

Currency files. The selected POV is not relevant to this file extract. Select Calculate from the form

menu or right-click menu and the two required files will be written to the specified folder. Transfer

these files to the FDM Inbox folder.

Enter a non-zero value to the second data cell in order to extract the Exchange Rates file. Ensure that

the correct Scenario, Year and Period have been selected in the POV bar. Select Calculate from the

form menu or right-click menu and the required file will be written to the specified folder. The file

name will be “QMRExchangeRates_<scenario>_<year>_<period>”.

All files can be extracted at one time if required. After the file extract has been completed, the non-

zero entries will be cleared from the data cells. Transfer the files to the FDM Inbox folder.

HFM 11.1.2.2:

The same process can be completed as described above for HFM 11.1.2.1. In addition, the files can be

extracted without requiring data entry.

From the menu bar or from the right-click menu, select the OnDemand rules options:

• ExtractEntityDetailsForFDM

• ExtractExchangeRatesForFDM

The required file(s) will be written to the specified folder. Transfer the files to the FDM Inbox folder.



Glossary

General Terms

Term Definition

BTS Binding Technical Standards

CEIOPS Committee of European Insurance and Occupational Pensions Supervisors.

EIOPA

European Insurance and Occupational Pensions Authority: EIOPA is the new

European authority replacing CEIOPS. The proposals over EIOPA’s powers are

being debated, but in general EIOPA will be given more power to enforce

prudential standards through the development of Binding Technical

Standards.

EPIFP Expected profit in future premiums

IFRS International Financial Reporting Standards: principles-based standards,

interpretations and the framework adopted by the International Accounting

Standards Board (IASB).

IORP Institutions for Occupational Retirement Provision.

MCR

Minimum Capital Requirement: Key quantitative capital requirement defined

in the Solvency II Directive. The MCR is the lower of the two capital levels

required in Solvency II and provides an approximate 1 in 6 year level of

protection.

QRT Quarterly Reporting Template.

RSR

Report to Supervisors: A report submitted solely to the supervisor and

contains the information considered necessary for the purposes of

supervision.

SCR

Solvency Capital Requirement: Key quantitative capital requirement defined in

the Solvency II Directive. The SCR is the higher of the two capital levels

required in Solvency II and provides an approximate 1 in 200 year level of

protection.

SFCR

Solvency and Financial Condition Report: This is the public disclosure report

which is required to be published annually by all undertakings and will contain

detailed quantitative and qualitative elements.

SI Solvency I.

SII Solvency II.

SLT Similar to life.

SPV Special Purpose Vehicle.



Technical Terms

Term Definition

Best estimate

The probability-weighted average also referred to the mean. The estimation

process is unbiased and based on all currently available information including

information of currently observable trends, but excluding effects from events

not yet occurred.

Best estimate

liability

The expected or mean value (probability weighted average) of the present

value of future cash flows for current obligations, projected over the

contract’s run-off period, taking into account all up-to-date financial market

and actuarial information.

Business risk

Unexpected changes to the legal conditions to which insurers are subject,

changes in the economic and social environment, as well as changes in

business profile and the general business cycle.

Catastrophe risk

The risk that a single event, or series of events, of major magnitude, usually

over a short period (often 72 hours), leads to a significant deviation in actual

claims from the total expected claims.

Claims risk An underwriting risk. A change in value caused by ultimate costs for full

contractual obligations (claims without administration costs) varying from

those assumed when these obligations were estimated.

Compliance risk The risk of legal or regulatory sanctions resulting in a financial loss, or loss of

reputation as a result of an insurer’s failure to comply with laws, regulations,

rules, related self-regulatory organisation standards, and codes of conduct.

Concentration risk The exposure to increased losses associated with inadequately diversified

portfolios of assets and/or obligations

Cost of capital

approach

An approximation through which a risk margin is determined based on the

present value of the cost of capital charge for all future capital requirements

until run-off.

Credit risk The risk of a change in value due to actual credit losses deviating from

expected credit losses due to the failure to meet contractual debt obligations.

Default risk The risk of a change in value caused by the fact that actual default rates

deviate from expected default rates with respect to non-payment of interest

or principle.

Diversification Reduction in risks among assets and/or obligations of an institution by

accumulating risks that are not fully correlated in an aggregated risk position,

for example, the aggregated amount of risks within a product portfolio or at a

company level is smaller compared to the simple addition of the individual

risks.

Economic balance

sheet

Balance sheet statement based on one of those accounting approaches using

market-consistent values for all current assets and current obligations relating

to in-force business, including off-balance sheet items.

Equity risk The risk of a change in value caused by deviations of the actual market values

of equities and/or income from equities from their expected values.

European embedded

value

A method for calculating the embedded value according to the principles and

guidelines set by the CFO Forum.



Term Definition

Financial group A group of undertakings deploying financial activities, which consists of a

parent undertaking, its subsidiaries, and the entities in which the parent

undertaking or its subsidiaries hold a significant participation. Or,

undertakings linked to each other by a relationship subject to conditions

defined in EU law.

Foreign exchange

risk

The risk of a change in value caused by the fact that actual foreign currency

exchange rates differ from those expected.

Fungible capital That part of the capital of a group which can be transferred between different

legal entities of the group.

Health insurance Generic term applying to all types of insurance indemnifying or reimbursing

for losses (e.g.. loss of income) caused by illness or disability, or for expenses

of medical treatment necessitated by illness or disability.

Hedgeable risk A risk associated with an asset or an obligation that can be effectively

neutralised by buying or selling a market instrument (or engaging in a

contract with a third party in an arms length transaction under normal

business conditions), whose value is expected to change so as to offset the

change in value of the asset or liability caused by the presence of the risk.

Inflation risk The risk of a change in value caused by a deviation of the actual market-

consistent value of assets and/or liabilities from their expected value, due to

inflation, for example, price inflation, wage inflation, etc., leading to an

unanticipated change in insurance cost and/or impact of an insurance

contract, for example, with respect to contract limits.

Internal model

Risk management system of an insurer for the analysis of the overall risk

situation of the insurance undertaking, to quantify risks and/or to determine

the capital requirement on the basis of the company specific risk profile.

Liquidity risk The risk stemming from the lack of marketability of an investment that cannot

be bought or sold quickly enough to prevent or minimize a loss

Longevity risk Type of biometric risk. A change in value caused by the actual mortality rate

being lower than the one expected.

Market risk The risk of changes in values caused by market prices or volatilities of market

prices differing from their expected values.

Market-consistent

valuation

The practise of valuing assets and liabilities on market values where

observable with a given quality (mark-to-market), where not, on market-

consistent valuation techniques (mark-to-model).

Mark-to-market

valuation

The practice of valuing insurance rights and obligations, or more broadly

security and financial instruments, using current market prices.

Morbidity risk

Type of biometric risk. A change of value caused by the actual disability and

illness rates of the persons insured deviating from the ones expected.

Mortality risk Type of biometric risk. A change in value caused by the actual mortality rate

being higher than the one expected.

Non-SLT Health type business which is not treated as life business.



Term Definition

Operational risk Risk of a change in value caused by the fact that actual losses, incurred for

inadequate or failed internal processes, people and systems, or from external

events (including legal risk), differ from the expected losses.

Performance linked

benefit (with-profit

contracts)

A contractual benefit sharing the policyholder in the performance of the

insurer, i.e. the surplus under a group of contracts or the surplus of the entire

entity; achieved after providing the guaranteed benefits, after making the

related internal expenses as a result of received guaranteed premiums, and

taking into account the investment income.

Procyclicality

The cumulative pressure on a larger number of institutions to sell assets or

raise capital at the same time, due to the ‘Solvency Capital Requirements’ and

thereby potentially causing more extreme market movements than would

otherwise be the case.

Provision The amount needed under a certain measurement of a present obligation to

meet that obligation adequately.

Required economic

capital

The total of assets measured at market-consistent value, internally required

by an insurer above the market consistent value of obligations, in order to

reduce the risk of not meeting the obligations to a defined risk measure.

For example, VaR, TVaR, EPD, and within a defined time period (for example,

one year).

Risk margin A generic term, representing the value of the deviation risk of the actual

outcome compared with the best estimate, expressed in terms of a defined

risk measure.

SLT Similar to life which is P&C business which is treated as life business for

Solvency Purposes.

Standard Formula Standard Formula: a non-entity-specific risk-based mathematical formula

used by insurers to calculate their Solvency Capital Requirement under

Solvency II.

Systemic risk The risk of experiencing systemic events which may lead to the failure of

institutions, markets or financial systems.

Tail-Value-at-Risk A coherent risk measure. For a given confidence level 1- it measures the

average losses over the defined threshold (typically set as the VaR for a given

quantile), i.e. the conditioned mean value, given that the loss exceeds the 1-

percentile.

Technical Provisions Technical Provisions are the amount that an insurer needs to hold in order to

meet its expected future obligations on insurance contracts.



Term Definition

Tier 1, Tier 2, Tier 3 Tier 1 is the dominant form of capital under So

instruments to be included are:

- Permanently available (available, callable on demand, fully absorbed

losses, going concern)

- Subordination (in the event of winding up, absorbed losses and

repayment is subordinate to all reinsurance

Tier 2 includes:

- Subordination to policy holders and other subordinate creditors

- A minimum duration of 5 years

- Coupon dividends to be deferrable (in case of breach)

- No loss absorption

Tier 3 includes all other financial instruments.

Total balance sheet

approach

Principle which states that the determination of an insurer’s capital that is

available and needed for solvency purposes should be based upon all assets

and liabilities, as measured in the regulatory balance sheet of the insurer, and

the way they interact

Underwriting risk The risk of a change in value due to a deviation of the actual claims payments

from the expected amount of claims payments (including expenses).

Copyright (c) 2013, Oracle and / or its affiliates. All rights reserved. http://www.oracle.com

t and Reporting for Solvency II

Definition

Tier 1 is the dominant form of capital under Solvency II. The financial

instruments to be included are:

Permanently available (available, callable on demand, fully absorbed

losses, going concern)

Subordination (in the event of winding up, absorbed losses and

repayment is subordinate to all reinsurance obligations)

Tier 2 includes:

Subordination to policy holders and other subordinate creditors

A minimum duration of 5 years

Coupon dividends to be deferrable (in case of breach)

No loss absorption

Tier 3 includes all other financial instruments.




e way they interact

The risk of a change in value due to a deviation of the actual claims payments


, Oracle and / or its affiliates. All rights reserved.

lvency II. The financial

Permanently available (available, callable on demand, fully absorbed

Subordination (in the event of winding up, absorbed losses and

obligations)

Subordination to policy holders and other subordinate creditors

Coupon dividends to be deferrable (in case of breach)




The risk of a change in value due to a deviation of the actual claims payments


oracle quantitative management and reporting for solvency ii

Documents