Set Up Additional Reports

Open

Load Entity Data

To provide entity-related text in a non-English language, you have to use a table in the Eagle warehouse using the name in which your required text field is normally found, with the extension “_ML”. This table contains an additional key field L_ID, which is the language instance number from EGL_LANGUAGES. You then use Eagle Message Center (as of V11.1) to populate local-language text to that table for any language you have set up in EGL_LANGUAGES. Eagle ships tables ENTITY_ML and ENTITY_ML_HIST, containing the field ENTITY_NAME, as a “starter”. Your database administrator may add any other text field normally found in ENTITY and ENTITY_HIST to their “_ML” companion tables and upload local-language text. The data type is nvarchar in SQL Server or nvarchar2 in Oracle. The following example shows ENTITY_ML with ENTITY_NAME loaded in four languages for one entity.

Open

Loading Security Data

You can load security text fields the same as you load entity text fields. Eagle ships SECURITY_MASTER_ML and SECURITY_MASTER_ML_HIST, having key field L_ID, and includes field ISSUE_NAME. You can add and load other security fields using the same Message Center approach as for entity tables. The following example shows SECURITY_MASTER_ML.

Loading Meta Data Text and Code Values

In the PACE_MASTER database, you can load table EGL_GENERIC_XLATION_ML with local-language text contained in your meta data and code values of Entity and Security fields. You may want to localize this text, since it appears on reports in items such as column headings and group names. Translating this text is essential to a full localization of the Eagle Portal. To enter this data, use the Eagle Translation Center tool, available on the Eagle Portal platform V11.1 or later.

The following example shows an example of rows of this table loaded with the name of a field attribute, “Issue Name”.

The following example shows the same table loaded with code values for an industry, “Advertising”, and an investment type, “Common Stock”.

Field Attributes for Multilingual Text

Multilingual entity and security text can be reported with the same field attributes used when reporting English text from the same fields. You do not have to develop a separate set of field attributes for each language you support. However, you must make the Field Type Wide Character. Select Wide Character from the Field type drop down menu as shown below.

A Wide Character field, when reported using a non-English language selection in an OLAP report profile or a Data Mart model, looks to the appropriate _ML table for its data. The following example shows a field attribute against INVESTMENT_TYPE that looks for data from SECURITY_MASTER_ML or SECURITY_MASTER_ML_HIST, as appropriate, when local-language reporting is enabled.

This Wide Character field type is also required for an entity or security field attribute that has a local-language translation of a code value, or is a rollup or inference field based upon such a field.

The following example shows the Editing Inference Field dialog box. This example shows how the Wide Character Value is set on the derived field.

Special Considerations for Eagle Data Mart

If you use Eagle Data Mart, you may want to create a separate set of field attributes for multibyte data instead of simply resetting the data type of your existing text field attributes for entity, security and reference code fields. Suppose you use Data Mart to support non-English text fields in an "internationalized" mart. If you have a common set of field attributes for text fields that you use for regular and multibyte text, Data Mart automatically widens those fields in all tables where they are present, even in tables of non-internationalized marts. This occurs when you save a model in a mart with such fields. The widening process applied to a table containing many rows could be a time-consuming database operation, and could cause a database timeout if volumes are high. For this reason, you may prefer to maintain a separate set of text field attributes for multibyte fields, so that existing text fields in non-internationalized marts are not automatically widened.

Language Translation Center

The Language Translation Center supports multilingual deployments from a single Eagle installation. This component allows you to translate specific data elements into a language other than English.

You can enter and edit code values and meta data, upload and export data using XLS and XLM. The data and code values for entity and security codes resides in the warehouse table EGL_GENERIC_XLATION_ML. Usually, your System Administrator or Language Specialist is responsible for working with the Language Translation Center. The Language Translation Center is shown below.

Create a Multilingual OLAP Report

When creating a multilingual OLAP report for any field attribute that reports multibyte text, you must set Field Type to Wide Character as shown below. When Field Type is set to Wide Character, PACE looks at the multilingual tables for report data. This applies to entity and security tables that have composite and history tables.

In addition to setting Field Type to Wide Character, you select the language for the report on the Report Profile dialog box, in the Use this language for the report dropdown.

Submit Reports with a Language Override

You can submit a report with an override for a different language. This allows you to configure and submit one report for multiple languages. If you do not submit with overrides, you will need to copy the report and make a language setting for each report variation.

To submit the selected report with a language override, select the language in which you want the report to appear from the 3. Use this language for the Report drop down and click OK.

Look Through Analysis Reports

Investment managers are increasingly investing in securities that are actually funds, such as exchange-traded funds, institutional mutual funds, futures contracts against market indexes, internal pooled funds and total return swaps involving baskets of assets. These investment types are sometimes called securitized funds.

Portfolio analysis is more difficult when a portfolio contains securitized funds. This is because most analysis relies upon descriptors like beta and bond yield that are available for securities, but not for securitized funds. So, securitized funds are often excluded from analyses and placed into categories such as Other or Unclassified.

Look through analysis solves this problem by looking through the shell of a securitized fund to the individual securities it holds, which are indirect holdings of the original portfolio. It then enumerates all direct and indirect holdings of the individual securities. Once this is done, all indirect holdings can be analyzed like direct fund holdings.

Another benefit of look through is to identify and quantify indirect holdings of problem assets that would otherwise be hidden from view.

Portfolio Simplified Look Through

The portfolio look through eyeglass icon is displayed in a report that does not have look through field attributes only if the look through entity is available to you through your business group security. This is the Portfolio Simplified Look Through approach discussed in the Look Through Processing Notes section of the Look Through Analysis section above.

If you have access to the look through entity, then this feature functions normally. If you do not have access to the look through entity, then the look through icon does not appear in the report results.

How Does Look Through Work?

Look through analysis computes the value of every indirect and direct holding of a portfolio that contains securitized funds. This requires the calculation shown in the following table. The table shows that Portfolio XYZ holds two regular securities, A and B, and a securitized fund ETF.

The following table shows holdings of the exchange-traded fund, which also holds Security A, as well as C and D that are not in the original portfolio.

Look through holdings are calculated in the following table. Each indirect holding is computed as the weight of the holding in the securitized fund, times the value of the original portfolio's holding of the securitized fund.

Look Through Processing Notes

The following list contains some notes about look through processing.

• Look through processing can deal with cases where a securitized fund owns one or more other securitized funds, for any number of levels of nesting.

• It is expected that particular securities, like Security A in the example, will be held both directly and indirectly, so that a complete enumeration of holdings can be made.

Look through processing is primarily used to find indirect holdings in terms of market values, but the same principle applies to other value fields like book value. A look through perspective of holdings may also need to include non-value fields such as dates or text-based descriptors. In some cases, those non-value fields should be inherited by indirect holdings from the direct holding, for example: portfolio strategy. In other cases they should repeat the value of the indirect holding itself, for example, manager, in a pooled funds scenario.

Set Up Look Through

Map Securities

Map all securitized funds to entities that hold their contents according to the data load.

To do this, load two fields in the SECURITYDBO.SECURITY_MASTER_DETAILS table for each securitized fund:

• LOOK_THRU_IND. Set to P.

• LOOK_THRU_VALUE. Set to the ENTITY_ID of the entity that owns the contents of the securitized fund.

Load Data to POSITION_DETAIL Table

There is an internal field attribute, i Look Thru Field for Value, where the system looks for values to use in computing weights for all securitized funds. By default this mapped field is market value (in base currency), but you may choose another field if appropriate. For any securitized fund, the system takes what is loaded to this field and uses it to compute weights by summing all values and dividing each value by the sum. If the securitized fund's weights are not based upon a loadable value like market value or market capitalization, you should load official weights themselves, since they are not changed in the weight computation part of the calculation.

Set Up Holdings Field Attributes with Look Through Property

The presence of a securitized fund in a portfolio holdings OLAP report or Data Mart does not start look through processing. Enumeration of direct plus indirect holdings and calculation of all their values requires the presence of special holdings field attributes with a look through property.

Look Thru Processing Field Value

When setting up a report for Look Thru processing, complete the following options in reporting.

On the Edit Field dialog box select an option in the Look Thru Processing field. This option only appears for certain appropriate position tables. You can select one of three settings:

Compute Look Thru. Option for number fields. If selected, it causes the standard Look Thru algorithm to be applied. First, the child fund's values are used to compute a percentage breakdown (weights). Then, each child fund weight is then multiplied by the value of the parent fund's total holding value of the holding of the child fund. This produces the parent’s look-through values of child fund’s securities. The calculations are performed recursively for all parent holdings of securitized funds until no more securitized funds are among the holdings.

Take Child Value. Option for text values. If selected, it causes direct and indirect holdings to take the value shown by the security or position at the last value of nesting after look through is performed.

Take Parent Value. Option for text values. If selected, it causes direct and indirect holdings to take the value shown by the security or position of the original portfolio, before look through is performed.

Look Thru Rollup Field

The following example shows the values in the Look Thru Rollup field. In this example, calculations are based on a percentage of the Look Thru Book Value field.

Sample Look Through Analysis Report

The following example shows a sample Look Through Analysis report.

Issuer Reports

The following features simplify using two popular issuer data services:

As shown in the example below, the system parameter, #153, Minimize Rows in Issuer Report, allows you to minimize the number of Issuer Details rows that result from multiple issuer relationships in your Bloomberg Credit Risk module data. Settings for the Minimize Rows in Issuer Report parameter are:

• 0. Select 0 to produce the multiple-rows results. If you set up your issuer reporting prior to V11.0 and want to keep it unchanged, select 0.

• 1. Select 1 to minimize rows in OLAP reports and in the Data Mart Issuer Details table:

  • For any security's issuer in a given role, only one row is created for the entire company ownership path, from parent through ultimate parent.

  • The From Issuer Alias refers to the lowest-level issuer, the direct issuer. The To Issuer Alias refers to the highest-level issuer, the ultimate parent. Data for any other issuer level can appear on this row if it is reported by Issuer Relationship Summary field attributes.

In case of shared ownership in the ownership path, an additional Issuer Details row is created to identify the two unique paths of the company ownership hierarchy.

The field attribute property, Role Type, can report data for a direct issuer in any role. This is especially useful if you use S&P CrossWalk and you load the four CrossWalk Issuer types as different roles. Data for the four CrossWalk issuer types can then appear on the same row for easy reporting.

The next example shows how to set up a Role Type field attribute for use in Data Mart Issuer Details or an OLAP report.

This example shows how the Role Type field simplifies issuer reporting when using the S&P Crosswalk data service. You can load CrossWalk data to the Issuer Role Details table in the SECURITY database, defining each of CrossWalk's four relationship levels as a role. This method creates a single row in an OLAP report or Data Mart Issuer Details for each security that CrossWalk covers when you use Role Type field attribute. If you use this approach, you should not load CrossWalk data to the Issuer Relationship table, and you need not run the Issuer Relationship Builder Engine to produce the Issuer Relationship Summary table.

When using Bloomberg, putting a Role Type field attribute in an OLAP report or Data Mart Issuer Details returns the same data in that field's column for direct issuers of the security in all roles. For example, if a security has both an issuer and a guarantor, a Guarantor Name Role Type field would show that name on both the issuer row and the guarantor row. This facilitates reporting that selects just one row per security (for example, the issuer row) and needs all information to be on that row.

However, in a Bloomberg application, even if you select Minimize Rows you may see more than one row of data per issuer, if:

At some level of issuer parentage there is joint ownership, for example, two grandparent companies for the same parent company, causing the ownership tree to "branch".

There are multiple issuer roles for a single security, for example, both an Issuer and a Guarantor for a given security.

Sample Bloomberg Issuer Reports

The following example shows an issuer report without rows minimized. Note that Issuer 1 and Issuer 2 show joint ownership at some level of parentage, leading to two rows of issuer data, even with rows minimized. The second example shows a report with rows minimized.

Peer Group Reporting

To fairly rate a fund among its competitors, rating agencies use the concept of the mutual fund peer group. A peer group is a statistically meaningfully large set of funds adopting basically the same sector concentration strategy. Any member of the peer group may be meaningfully compared to other group members.

Using the Peer Group Reporting functionality in Eagle, you can store and report analytic data at the portfolio level via the Eagle data warehouse and the Data Mart. For example, you may want to report returns and analytics provided by peer group ratings agencies such as Lipper and Morningstar. Eagle provides a new type of warehouse data table, the Entity Analytics table, for this purpose. An Entity Analytics table is used to store external entity level information that must be reported as it is loaded, without change, rather than being calculated by Eagle engines in a rollup process. This is true for Peer Group data. New field attributes are available to enable reporting of Entity Analytics data in OLAP reports and Data Mart. Peer group reporting can only be used in a Range Report and Fund Summary model is Data Mart.