Understand Multicurrency Builds

The system facilitates an Entity Build across underlying entities of varying base currencies.

At a high level, when a build is initiated, the engine determines the base currency of the entity submitted and the sources used to find FX rates for currency conversion. The engine reads the holdings data for the underlying constituent entities and converts it to the base currency of the submitted entity as needed.

Define an Entity for Multicurrency Builds

Multicurrency builds use the value you define in the FX Source Rule field and the FX Date field when you define the entity. 

The Entity Build engine performs a multicurrency build only when the entity has an FX source rule assigned to it. When you define an entity, the FX source rule is accessible in the Entity Build Settings section of the tab which defines the entities' underlying constituents. This varies by entity type:

• Composites. For composites, it is the Composite tab for the entity.

• Aggregates. For aggregates, it is the Aggregate tab for the entity.

• Sub-portfolios. for sub-portfolios, it is the Sub-Portfolio tab.

From these tabs, you can create, edit, and delete FX source rules as well as assign them to an entity.

The FX source rules can contain one or more sources that are used to find the FX rate. The order of the sources determines the hierarchy.

Using the effective date and FX source rule, the Entity Build engine attempts to find FX rates by date and then source. In other words, the engine tries to find the FX rates against the first source in the rule in which the effective date equals the build date. If not found, the engine tries to find the rate against the second source in which the effective date equals the build date. If it is still not found, the engine repeats the process using the prior date (effective date – 1). This continues until the engine exhausts all combinations of date and sources as dictated by the FX Date or as configured in the system parameters.

In addition you can use the FX Date option to define the fetch FX rates offset. The FX Date field label includes, Go back maximum <X > number of days for FX Rates. You can use this value to determine the number of days back in time the engine searches for FX rates from the effective date submitted. 

Open

Entity Build FX Converter

The Entity Build engine utilizes the PACE FX converter, which is the module used in performance and PACE reporting to perform FX conversion. The following sections describe the components of the converter and its relevance to the Entity Build engine when resolving FX spot rates.

For information about configuring the FX Rate quotation method, see FX Rate Quotation Method System Parameter.

Resolve FX Spot Rate

The FX rate (spot rate) is resolved based on security alias, from security alias, source, and effective date, which are the keys to the table. To be consistent with other Eagle Data Management solution functionality, FX rates are expected in the SECURITYDBO.FX_RATES table stored as a spot rate in the SPOT_RATE field.

The security record stored in the FX_RATES table must link back its specific security master records where SECURITY_MASTER.PRIMARY_ASSET_ID equals CASH + ISO currency code (that is, CASHGBP). This is how the Entity Build engine resolves the currency security record.

To resolve an FX spot rate, the engine must be told which sources to use. This is accomplished by enabling you to define an FX source rule on each entity. The FX source rule (shown in the following figure) contains only those sources that are assigned to the foreign exchange (FXG) feed type and are available to the user's business group. The sequence of the sources tells the engine the priority. The source rule is stored in a field, called FX_SOURCE_RULE_ID, which exists on the ENTITY and ENTITY_HIST tables.

Open

Fetch FX Rates Offset Interpretation

The engine also needs which effective date to use to resolve an FX rate. By default, it first looks for data where the effective date is equal to the date the entity build was submitted. If no record is found, the engine goes back n number of days.

The default is three days, however the FX Date option, or Go back maximum <N> number of days for FX Rates option in the entity setup window, allows you to increase or decrease this amount as needed. The fetch FX rates offset also is stored on each entity in the field called FX_DAYS_OFFSET, which exists on the ENTITY and ENTITY_HIST tables. For information about configuring this function, see Number of Days to Go Back to Look for FX Rates System Parameter.

The engine interprets the FX rates days offset as follows:

• If the ENTITY.FX_DAYS_OFFSET field value is NULL, the engine uses the FX rates offset configured for your installation (see Number of Days to Go Back to Look for FX Rates System Parameter). If the system setting is not configured, the offset is assumed to be 0 and the FX rates is queried only for the effective date on which the build was submitted.

• If the field value is 0, the FX rate is queried for the effective date on which the build was submitted only.

• If the field value is 1 or greater, the FX rate is queried starting from the effective date on which the build was submitted through the value (effective date – x days).

Source Rule and Fetch FX Rates Offset Example

Using the effective date and source rule, the Entity Build engine attempts to find FX rates by date then source. In other words, the engine tries to find the FX rates against the first source in the rule in which the effective date equals the build date. If not found, the engine tries to find the rate against the second source in which the effective date equals the build date. If it is still not found, the engine repeats the process using the prior date (effective date – 1). This continues until the engine exhausts all combinations of date and sources as dictated by the fetch FX rates offset or as configured in the system parameters (see Number of Days to Go Back to Look for FX Rates System Parameter).

For this example assume the following:

• FX rate source rule is Source A then Source B

• Days offset is three days

• Build was submitted for 4/5/2005

• FX rates per source and effective date exist as described in the following table

The engine resolves the rate using the most recent effective date of rates across all sources in the source rule per combination for from and to security.

• USD to GBP using Source B for 4/4/2005 with a rate of .5300

• USD to JPY using Source A for 4/5/2005 with a rate of 107.67

Entity Base Currency Identification

The Entity Build engine must identify the base currency of the entity being built. This is considered the target currency to which all underlying position data is converted. To be consistent with other Eagle Data Management functionality, the base currency is expected in BASE_CURRENCY field of the RULESDBO.ENTITY and RULESDBO.ENTITY_HIST tables.

Composite Entity Build Example

The base currency of COMP A is USD. Therefore, the engine converts all underlying position data into USD. The following table provides an example of a composite entity build for base currency. 

Local and Base Position Fields

The Eagle Data Model supports holding-related fields that represent values reported in a security's local currency compared with those reported in the entity's base currency. Some examples in the POSITION_DETAIL table are LOCAL_MARKET_VALUE compared with MARKET_VALUE, and ACCRUED_INCOME_LOCAL compared with ACCRUED_INCOME. In addition, you can store the same fund's holdings in different currencies by using various sources to differentiate each.

Sample Position and Position Details

In the example shown in the following table, the holdings for PORT 1 are stored under two different sources. The Src =1 represents the values stored in a base currency of USD while Src = 2 represents the values stored in a base currency of GBP.

The entity build leverages two internal field attributes to determine the holding fields that contain the currency used to store the local and base holding values. These values tell the entity build engine in what denomination the local and base field values are stored to convert successfully the values from the existing from currency to the entity's base currency (target currency).

Two internal field attributes are used to define the position related fields that communicate the holding's local and base currency. However, you can change these manually to point to other position and position detail fields as needed.

The POSITION and POSITION_DETAIL fields defined in the internal field attributes fields must be populated to take advantage of the multicurrency entity build feature. See the following table. 

Use Entity Build Field Attributes to Identify Currency Type

If a client stored position detail holding data in local and base currency fields, the Currency Type option is available in entity build field attributes to direct the engine processing. The Currency Type field supports the values of local currency or base currency. You must select local currency or base currency depending on the data that is stored in the given position detail-level field. The engine uses the value to determine what currency is used to convert the existing data when performing a multicurrency build.

By default, the window displays base currency as the value when you create new position detail-level entity build field attributes. Likewise, the engine assumes base currency if any entity build field attribute does not have the currency type defined.

For entity build field attributes defined at the position table level, no currency type must be defined. The engine ignores what is defined in that field and assumes the base currency, because the values on the Position table can only reflect values in the base currency for that position instance.

The following figures show shows an entity build for Position Detail for local and base currency.

In this section

On this page