Oracle Quantitative Management and Reporting for Solvency ......Implementation Guide – 2.0.0 Page 1 ... Management (FDM), Hyperion Financial Management (HFM) and Financial Reports

Oracle Quantitative Management and Reporting for Solvency II

Implementation Guide – 2.0.0 Page 1


Implementation Guide

Release 2.0.0 (updated 2012-12-06)

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

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

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

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

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

HFM Format ......................................................................................................................... 2

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

Implementing QMR for FCM .................................................................................................. 4

General Considerations ....................................................................................................... 4

Load Procedure ................................................................................................................... 4

Implementing QMR for FDM .................................................................................................. 5

General Considerations ....................................................................................................... 5

Load Procedure ................................................................................................................... 5

Implementing QMR for HFM ................................................................................................ 15

General Considerations ..................................................................................................... 15

Calendar/Profile ................................................................................................................ 15

Metadata ........................................................................................................................... 16

Member Lists ..................................................................................................................... 31

Rules ................................................................................................................................. 32

Data Entry Forms .............................................................................................................. 44

Financial Reports .............................................................................................................. 45

Working with Data ............................................................................................................ 46

Glossary .............................................................................................................................. 48

General Terms ................................................................................................................... 48

Technical Terms ................................................................................................................ 49



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.0.0 is based on the November / December 2011 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 and Financial Close

Suite 11.1.2.2. 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 Financial Reporting PSU must be applied:

- FR 11.1.2.1: PSU: 11.1.2.1.124

- FR 11.1.2.2: PSU: 11.1.2.2.300

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

- HFM 11.1.2.1: PSU: 11.1.2.1.104

- HFM 11.1.2.2: PSU: 11.1.2.2.301 plus PSE 14593265, or PSU 11.1.2.2.302

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 One file with descriptions in English only (EN)

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

• HFM Metadata (XML format)

o One file with descriptions in English only (EN)

o One file 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

• 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.1.2.600, patch number 14361678 is

available for download on the Oracle Support web site.

• Documentation

o QMR Implementation Guide

o QMR Admin / 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.



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, Technical Provisions schedule

F3, F3A and F3B, IGT and RC schedules. These schedules are reported for solo undertakings, and

where required for group, are the same as the reports of the holding company.

Load Procedure

Once QMR application is set up in FDM, the following 16 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-D3 - Return on investment assets (by asset category)

• 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

Additionally aggregated Assets information can be pushed in HFM.

Prerequisites

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

against the created FDM application.

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

FDM application. All locations will support import into FDM for validation and QRT schedule

reporting. However the Assets D1 data will also need to be pushed into HFM 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.

• 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 16), create a location for each reporting entity (e.g. QMR-

Assets-D1-LE01, QMR-RC-LE01).

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 select 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.

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 correct QRT (e.g.

FM11X-G6-A).

� 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:

"MKTMK", "MKTMD"

• 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"

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 D3 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

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 X 24 DerivativeUse QMR_Assets_UseDerivative

X X

25 DetachmentPoint QMR_Rate

X 26 Duration QMR_Numeric X

X

27 ExposuresWeight QMR_Rate

X 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

35 IssuerCountry QMR_Country X

X

36 IssuerGroup 37 IssuerName 38 IssuerSector 39 IsUnitIndexLinked QMR_Boolean X

X X X

X

40 LongShort QMR_Assets_LongShort

X X 41 LookThrough QMR_Assets_LookThrough

X

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

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 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

X

77 Interest QMR_Numeric

X 78 Rent QMR_Numeric

X

79 GainsLosses (numeric) QMR_Numeric

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 5 HRGCommon QMR_Boolean X 6 RFF

7 Commercialized QMR_Boolean X 8 ProductType

9 ProdClassID 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



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

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

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 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 X X 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



Col IGT Field Name Validation IGT1 IGT2 IGT3 IGT4

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

X

35 ContractStartDate QMR_Date

X

36 ContractExpiryDate QMR_Date

X

37 TriggerEvent 38 MaxContingentLiabInSIIBS QMR_Numeric

X

39 MaxContingentLiabNotInSIIBS 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. Turkish) 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 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 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 file defines five time periods within a year.

• Quarters labeled Q1, Q2, Q3, 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. 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 final metadata file.

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. 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:

1. 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.

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.

Keyword: QIS5Ref

UD Field: ALL

Remark: These entries are no longer applied.

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.0.0 includes a sample entity structure. There are two group

entities, ten solo entities and six Ring Fenced Fund (RFF) entities. 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 multiple top entities can be created with different or overlapping

combinations of base–level children to provide this reporting. The entity structures must be flat (each

solo entity must be a child, an immediate descendant of the group entity, not a second or third level

descendant). Only RFF entities reside in multi-level hierarchies.

Solo Undertakings

Solo Undertakings are assumed to be all base entities except those defined as RFF entities. Insurance

company entities and other non-insurance company entities for which data must be reported at group

can be created as base entities.

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.

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.

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.



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. In order to link

the RFF entities to the relevant solo entity, a UD field entry is added to the group parent specifying the

related RFF parent and to each solo entity, specifying the name of the related solo RFF parent. For

further details, see the User Defined Fields section below.

Based on this structure and the UD field entries, results of the SCR calculations in the RFF entities are

copied to the related solo entities. No other consolidation of data in the RFF entities is carried out.

Inter-company Partners

All base entities should be flagged as IsICP. Only solo entities should be used as I/C partners but RFF

entities must also be flagged as ICP. At group, reporting by solo and by RFF requires that the ICP

dimension be used at group to identify one base entity from another. Data entry forms that provide for

I/C data entry will be restricted to solo or RFF entities appropriately through the use of a Legal

Entities or RFF member list.

Allow Adjustments

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

each entity (AllowAdjs, AllowAdjFromChildren). QMR version 2.0.0 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: 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: 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: 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

Used By: Sub Calculate_GroupG01

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



Keyword: Ref

UD Field: ALL

Valid Entry: Valid EIOPA reference for the entity

Example:


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

Keyword: IDCode

UD Field: ALL

Valid Entry: Valid international ID code of the entity.

Example:


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

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: 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.

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: 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: 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: IncDate

UD Field: ALL

Valid Entry: ISO 8061 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: 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: 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.0.0 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.

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 Assets schedules are reported from FDM. Accounts are provided in HFM to collect the

aggregation of the details in FDM for validation against the Balance Sheet.

• BS (Balance Sheet)

• Cover

o Country and Cover schedules

• FS (Financial Stability)

o Much of the FS schedule is a replication of information from other schedules. The additional

information not provided elsewhere is included in this section.

• Group

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

schedules are reported from FDM.

• MCR (Minimum Capital Requirements)

• OF (Own Funds)

• 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.

Account User Defined Fields

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

Used By: SCR calculations

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 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: SMSource1: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 SMSource1 source entry.

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: CalcSeq1

UD Field: ALL

Valid Entry: Numeric value

Example: 110




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


Keyword: ConsRule

UD Field: ALL

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

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: 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 Model

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

specific to models other than Standard Model.

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).

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".

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 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 data

source hierarchy can otherwise be modified as required but must include the [None] member.



User Defined Fields

User Defined Fields are used to reduce the maintenance on 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: 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

• ListItems

o Used for sequence numbering of lists of entries

• BSC1B (Balance Sheet)

• Cover



o Country and Cover schedules

• 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

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

• BS (Balance Sheet)


• OF (Own Funds)




• Validations


Keyword: ConsMCR

UD Field: ALL

Valid Entry: Valid custom2 base label

Example: SIIP

Used By: Function GetC2_ConsMCR (used in Sub Consolidate)

Description: This entry is assigned to a balance sheet custom2 (for example SII), to define an

alternative custom2 to which consolidation should be also performed, using MCR rule

(for more detail, see consolidation rules BS, EQUI, INVS below).

Keyword: ConsSCR

UD Field: ALL

Valid Entry: Valid custom2 base label

Example: SIIS

Used By: Function GetC2_ConsSCR (used in Sub Consolidate)



Description: This entry is assigned to a balance sheet custom2 (for example SII), to define an

alternative custom2 where consolidation should be also performed to, using SCR rule

(for more detail, see consolidation rules BS, EQUI, INVS below).

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

• Cover

• Models (SCR models)



• Validations


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 Model (SM), Standard Model 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



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



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 hierarchy can be customized as required but must retain the [None] member.


• Validations


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



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 DataTypeLists(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 DataTypeLists(15) Dim DataTypeLists(16)



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 JSK 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 contains the following sections which should be reviewed during implementation:

• Client configuration settings

• Settings for rules logic

• 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 Model correlation table, a NoData cell in that table will be populated with the value from

the Global Standard Model 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 Model 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 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 WRITE_CELLTEXT_ON = True

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

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_BS_QUARTERLY = False

• Set INPUT_BS_QUARTERLY to True to enter Balance Sheet data quarterly.

• Set INPUT_BS_QUARTERLY to False to enter Balance Sheet data only annually.

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.0.0 provides EN, DE, ES, FR and NL translations. The default language specified



here will be used only is 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

Data Entry

• INPUT_STAT_AT_GROUP TRUE/FALSE (FALSE)

o Allow data entry of Balance Sheet, C2=Stat, at Group Level

Calculation Rules

• INPUT_BS_QUARTERLY TRUE/FALSE (FALSE)

o Execute selected own funds calculations quarterly instead of yearly, when Balance Sheet is

entered quarterly

Consolidation Rules

• CONSOLIDATE_TOTC4_TO_NONE TRUE/FALSE (TRUE)



o Allow mapping of C4 data sources details to C4 [None] when consolidating

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

• Equity rule

o CONSRULE_EQUI EQUI

• Investments rule

o CONSRULE_INVS INVS

• 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

Custom2 Dimension

• Alternative custom2 for balance sheet consolidation, using MCR rule

o UDFIELD_C2_CONSMCR ALL

o KEYWORD_C2_ CONSMCR ConsMCR

• Alternative custom2 for balance sheet consolidation, using SCR rule

o UDFIELD_C2_CONSSCR ALL

o KEYWORD_C2_ CONSSCR ConsSCR



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 25):

� 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 17):



� 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.

� If ConsMCR keyword has been assigned to the processed Custom2, consolidates/eliminates

also, with MCR rule (see below), to the alternative Custom2 set in the keyword.

� If ConsSCR keyword has been assigned to the processed Custom2, consolidates/eliminates

also, with SCR rule (see below), to the alternative Custom2 set in the keyword.

• 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.

o Special cases:

� If ConsMCR keyword has been assigned to the processed Custom2, consolidates also to the

alternative Custom2 set in the keyword, using POwn, and eliminates, when the method is

different from HOLDING, using the same percentage, to account A_BS_CONS_RES.



� If ConsSCR keyword has been assigned to the processed Custom2, behaves like ConsMCR

case. Additionally, when the method is different from HOLDING, SUBS, SUBS_FR, balance

sheet is balanced to A_BS_PART_SIG

• 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.

o Special cases:

� If ConsMCR keyword has been assigned to the processed Custom2, consolidates also to the

alternative Custom2 set in the keyword, using POwn, and eliminates, using the same

percentage, to the partner account A_BS_CONS_RES, via account A_BS_CONTRA_INV.

� If ConsSCR keyword has been assigned to the processed Custom2, behaves like ConsMCR

case, with the only difference that when the method is different from HOLDING, SUBS,

SUBS_FR the elimination entry is balanced to the account A_BS_PART_SIG (Significant

Participations).

• 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.

For further details on the forms provided with QMR, please refer to the QMR Admin / 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 financial report files are saved as *.wdf files but are also included in an LCM

QMR200Forms.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

o Log on to Shared Services and expand the File System directory

o Select the QMR200Forms item

� If QMR200Forms item is not displayed, the unzipped 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.



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 is also one CompLogo.roi file that contains the Oracle logo. This logo is embedded in each report

and can be replaced by the required logo.

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.0.0

folder in Workspace.

• The database connection may be different than that used to create the reports so this must be

updated either while importing or after importing.

To install the reports files individually:

• From the Workspace, Explore screen, create folders as required for organizing the reports.

• Import the CompLogo.roi file into the root folder.

o If the CompLogo.roi file is renamed or placed elsewhere, 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="/CompLogo"" and replace with the required location/filename.

• Import each of the report *.des files to the appropriate folder.

• The database connection may be different than that used to create the reports so this must be

updated either while importing or after importing.

To change the logo used in the reports:

• Using the Financial Reporting Studio client application, create a new 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 CompLogo.roi, overwriting the original CompLogo.roi file (in

the root folder, or alternative folder if the location was edited in the *,des files).



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.

Data file “QMR_200_EIOPAData2011QA.dat” provides the EIOPA data.

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 and periods by changing the header

rows:

!Scenario = Actual !Year = 2011 !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.

• QMR_200_GlobalData2011QA.dat

o Exchange Rates

o Correlation table factors for Partial Internal Model

o Inflation rates

• QMR_200_TestData2011QA_Group.dat

o Ownership information

o Group reporting percentages

o Group SCR capital add-ons

• QMR_200_TestData2011QA_LE01.dat

o Data set for all schedules processed in HFM

o MCR Undertaking type and category

o Local override for Partial Internal Model correlation factors

• QMR_200_TestData2011QA_LE01_RFF1.dat

o Data set for Balance Sheet, Own Funds and SCR

o MCR Undertaking Type and category

o RFF type

• QMR_200_TestData2011QA_LE01_RFF2.dat

o Data set for Balance Sheet, Own Funds and SCR



o MCR Undertaking Type and category

o RFF type





o Consolidated as a D&A entity


o Non insurance entity MCR, SCR and OF equivalent data only





o Consolidated as a 100% owned subsidiary entity





o Consolidated as a 100% owned subsidiary entity from outside of the EEA


o Insurance entity MCR, SCR and OF equivalent data only from outside of the EEA



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.


Implementation Guide – 2.0.0

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) 2012, 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.

Page 52

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


Documents

Oracle Quantitative Management and Reporting for Solvency ......Implementation Guide – 2.0.0 Page 1 ... Management (FDM), Hyperion Financial Management (HFM) and Financial Reports