FX Revaluation and FX Translation

The FX Revaluation process takes the current day’s postings in foreign currency, and creates duplicate postings in a user-defined Function Currency, provided their account is eligible for FX Revaluation.

The FX Translation process accounts for the change in exchange rates from one day to the next for balances in foreign currency, provided their account is eligible for FX Translation. The process is dependent on the account balance, and functions by converting the previous day’s foreign currency balance amounts into a user-defined Function Currency, and dispersing these amounts into translation accounts.

The FX Translation process requires up-to-date balances. They are computed using the BALANCE scheduled task.

These processes are performed by the scheduled task ACCOUNTING_CONVERSION, based on the accounting setup described below. Both processes can be applied to the same accounts or to different accounts.

1. Accounts Setup

Note that the same accounts can be setup for FX Revaluation and for FX Translation.

1.1 Domain

You need to add the FX_TRANSLATION and FX_REVALUATION values to the "accEventType" domain.

1.2 FX Revaluation

From the Calypso Navigator, navigate to Configuration > Accounting > Accounts (menu action refdata.AccountFrame) to setup the accounts eligible for FX Revaluation.

Each account to be revalued should be set as follows:

In this example, we are setting up CONTINGENT_ASSET_FX and CONTINGENT_LIABILITY_FX for FX Revaluation. Postings on these accounts will be revalued into Euro.

Select the Translation/Revaluation panel, and set the following parameters:

There are no subsidiary accounts for FX Revaluation.

–

FunctionCurrency — Enter the currency in which you want to revalue the account.

–

PerformFXRevaluation — Check to perform FX Revaluation.

Click Save to save your changes.

1.3 FX Translation

From the Calypso Navigator, navigate to Configuration > Accounting > Accounts (menu action refdata.AccountFrame) to setup the accounts eligible for FX Translation.

Each account to be converted must be setup with balance generation, and should be set as follows

The balance on this account will be converted into Euro, through the generation of postings in the translation accounts defined below.

Check the Balance checkbox and select the DLY frequency.

Select the Translation/Revaluation panel, and set the following parameters:

–

FunctionCurrency — Enter the currency in which you want to convert the account.

–

FXTranslation(+/-)CREDIT/DEBIT — Select the accounts that should be credited / debited with the conversion amount.

–

PerformFXTranslation — Check to perform FX Translation.

If the account to be converted is an automatic account (main account), and if the attribute “Propagate” is set to true, we will look at the automatic attributes that exist on this account and based on those automatic attributes generate an auto account (sub account) where the postings will be held. Those automatic attributes will be set as account properties in the sub accounts, including the FX Translation account names.

Example: If the main accounts automatic attributes are constant and trader, then the sub account will be generated using the constant and the trader’s name. The "Trader" property will be added to the sub account.

If the account to be converted is an automatic account, you can set the account attribute FunctionCurrencySource=TradingBook. In this case, the FunctionCurrency attribute of the sub account will be set to the book’s FunctionCurrency attribute.

Click Save to save your changes.

1.4 Accounting Rules

Make sure that your accounting rules for trades in foreign currency impact the FX Revaluation account and the FX Translation account (main account).

Sample rule:

2. Generating Postings in Foreign Currency

Make sure that the Transfer engine and Accounting engine are running, and enter trades for generating postings as shown in the example below.

Choose from the drop-down menu, and select the Postings panel to display the postings as shown below.

3. FX Revaluation Process

The FX revaluation process requires current FX rates for the currencies to be revalued. They can be specified using Market Data > Market Quotes > Quotes.

The quote name is FX.<base currency>.<quoting currency> for the currency pairs to be revalued.

For a cross currency trade such as USD/CAD for example, that you want to revalue to Euro, you would enter quotes for CAD/EUR and EUR/USD.

The FX revaluation is done using the ACCOUNTING_CONVERSION scheduled task.

From the Calypso Navigator, navigate to Configuration > Scheduled Tasks (menu action scheduling.ScheduledTaskListWindow), and select the type ACCOUNTING_CONVERSION.

Select a trade filter, user and pricing env.

Set the attribute “FX Revaluation” to True.

Then execute the scheduled task on the current date.

You can see the FX_REVALUATION posting on the trade. The posting type is set to FX_CONVERSION.

The Linked Id contains the id of the posting that has been revalued.

The FX Revaluation process takes the current day’s postings in foreign currency and creates duplicate postings in the Function Currency specified in the account eligible for FX Revaluation.

For info, when the PO is set, filtering postings where debit and credit account have specified PO, or specified PO and ALL:

•

Debit Account PO = specified PO and Credit Account PO = specified PO

•

Debit Account PO = specified PO and Credit Account PO = ALL

•

Debit Account PO = ALL and Credit Account PO = specified PO

3.1 Reversal Process

The system automatically handles the reversal of FX Revaluation postings if past trades are modified, and new FX Revaluation postings are created when the scheduled task for FX Revaluation is run again.

If market data change in the past but the trades are not modified, you need to run the scheduled task ACCOUNTING_CONVERSION on the day the market data was modified, with the attribute "Reverse FX Revaluation" set to true.

From the Calypso Navigator, navigate to Configuration > Scheduled Tasks (menu action scheduling.ScheduledTaskListWindow), and select the type ACCOUNTING_CONVERSION.

Select a trade filter, user and pricing env.

Set the “Reverse FX Revaluation” attribute to True.

Then execute the scheduled task on the date the market data was modified.

FX Revaluation postings of type REVERSAL are created to cancel previous FX Revaluation postings, and new ones of type FX_CONVERSION are created.

The scheduled task uses the book’s holiday to check if the posting’s date is a business day or not.

3.2 Business Date

You can set "FX Translation Use Business Date" to true set the booking date to the business date.

The notion of "Business Date" is defined for each Processing Org. To activate the notion of "Business Date", you need to set the legal entity attributes "ACC_USE_BUSINESS" and "ACC_ BUSINESS_DATE" on the processing org as described in Calypso Accounting Postings documentation.

For reverse posting having the INVENTORY rule, the booking date is calculated as follows:

If (effective date of original event + rule adjustment days > legal entity attribute ACC_BUSINESS_DATE): Booking Date = effective date of original event

Else: Booking Date = legal entity attribute ACC_BUSINESS_DATE

This logic may be deactivated by setting environment property ReverseINVENTORYPostingOnEffectiveDate = false.

In this case:

If (booking date of original event > legal entity attribute ACC_BUSINESS_DATE): Booking Date = booking date of original event

Else: Booking Date = legal entity attribute ACC_BUSINESS_DATE

4. FX Decomposition Process

The FX Decomposition process is only available if environment property FX_AVG_REVALUATION = True (Default is False).

Account Definition

Define the following subsidiaries accounts in the Translation/Revaluation panel:

•

InterestFXPL Debit+

•

InterestFXPL Credit+

•

InterestFXPL Debit-

•

InterestFXPL Credit-

These values make sense only if PerformFXRevaluation is selected too.

Scheduled Task ACCOUNTING_CONVERSION

Attributes:

•

FX Revaluation Decomposition = True

•

DateType = EffectiveDate

•

FX Revaluation Decomposition = True (only applies if FX Revaluation = True, and is only compatible with DateType = Effective Date)

When FX Revaluation Decomposition = True, the scheduled task will generate CONVERSION postings (as described above) and FX_REVAL_DECOMP postings.

FX_REVAL_DECOMP posting amount is calculated like as: Original Posting Amount x FX Average Rate - Converted Posting Amount

with FX Average Rate = average FX rate from posting CF_START_DATE until Posting Effective Date. (If no quote found at a date, then this date is not used in the average).

FX_REVAL_DECOMP postings have an attribute FX_RATE containing the FX Average Rate.

FX_REVAL_DECOMP posting Debit/Credit accounts are defined by InterestFXPL subsidiaries accounts set on the account definition of the original posting.

Interest postings are generated with additional attribute CF_START_DATE containing the cashflow start date.

When you add Value = true to the domain "FXConversionSpecialDecomp", FX_REVAL_DECOMP reversal postings use the posting amount of the original posting. It is the posting amount of the FX_REVAL_DECOMP posting otherwise.

5. FX Translation Process

The FX translation process is a two-step process:

•

Computing balances in foreign currencies

•

Converting the balances into the Function Currency specified in the account eligible for FX Translation

5.1 Computing FX Balances

The BALANCE scheduled task will take care of computing the balances to be converted on the current date.

From the Calypso Navigator, navigate to Configuration > Scheduled Tasks > Scheduled Tasks (menu action refdata.ScheduledTaskWindow), and select the scheduled task type "BALANCE".

Select a trade filter and a pricing env.

Then execute the scheduled task.

The BALANCE scheduled task will create FX balance positions in a date range spanning a week behind.

Example - The following balances can be converted to Euro using the FX Translation process.

5.2 Generating Converted Postings

The FX Translation process requires current FX rates for the currencies to be converted, as well as FX rates in a date range spanning a week behind (because of the balance calculations). They can be specified using Market Data > Market Quotes > Quotes.

The quote name is FX.<base currency>.<quoting currency> for the currency pairs to be converted.

For a cross currency balances such as USD/CAD for example, that you want to convert to Euro, you would enter quotes for CAD/EUR and EUR/USD.

The FX Translation is done using the ACCOUNTING_CONVERSION scheduled task.

Multi-threading is added to ACCOUNTING_CONVERSION scheduled task to process accounts in multiple threads. The attributes “THREAD COUNT” and “Nb Accounts Per Thread” have been added to set the number of threads and the number of accounts per thread.

From the Calypso Navigator, navigate to Configuration > Scheduled Tasks (menu action scheduling.ScheduledTaskListWindow), and select the type ACCOUNTING_CONVERSION.

Select a trade filter, user and pricing env.

Set the “FX Translation” attribute to True.

You can run the scheduled task for a single trade and/or a single account.

Then execute the scheduled task on the current date.

You can view the FX_TRANSLATION postings using the Posting Report as shown below. The posting type is set to FX_CONVERSION.

The FX Translation process takes the previous day’s balance in foreign currency and computes the difference between yesterday’s FX rate, and the current FX rate. The posting reflects that profit and loss. The Trade Id is null because the posting is related to a balance and not a trade.

5.3 Reversal Process

The system handles the reversal of FX Translation postings. If the balances in the past are changed due to a back-valued trade, or amending of an old trade, the scheduled task BALANCE correctly calculates the old balances and updates their amounts.

In that case, the reversal process finds all the FX Translation postings that were posted for the old balances and reverses them. After reversing the old FX Translation postings, it creates new FX Translation postings with the new balance amounts.

•

Reversal and new FX Translation postings that are created for old balances have their effective date in the past, and their booking date set to the valuation date of the scheduled task.

•

Reversal amounts are the same as the old FX Translation postings, and the new amounts are calculated with the updated balance amount.

•

If the balance is changed on the current date and it had already created an FX Translation posting, it will delete the current date posting instead of reversing it. The BALANCE scheduled task will only reverse the old FX Translation postings. To delete the current FX Translation postings and create new ones, you need to run the ACCOUNTING_CONVERSION scheduled task. That should delete all the current FX Translation postings that were created during the same day, and create new ones with the latest balance.

5.4 Special Logic

A special logic can be triggered for product types defined in domain "FXConversionSpecial" (for example: FX,Forward,FXNDF,FXSwap), and accounting events defined in domain "FXConversionEvents" (for example: COT,COT_REV,NOM_FULL,CST).

If the FunctionCurrency is part of the FX trade, then for the accounting events defined in "FXConversionEvents", FX Revaluation postings use the trade rate and NOT end of day market quotes.

For the currency that is set as the PL Display Ccy (in the Currency pair definition), FX Revaluation postings always take the end of day market quote. For the other Ccy, always duplicate the amount retrieved for the PL Display Ccy.

Reversal Postings - Default Logic

For the reversal postings, (accounting event contains the suffix "_REV" in the domain "FXConversionEvents"), it uses the same conversion amounts as the initial posting. To do so, we search for the initial postings (for example for COT_REV, we would look for COT and then for the related conversion posting). If none is found, we issue an error.

Reversal Postings - Market Rate Logic

For the accounting events defined in the domain "FXConversionReversal", reversal postings use the Market Rate of the initial posting instead of the conversion amount (If Posting Amount of the entry to be revalued is different from Posting Amount of the initial posting).

If scheduled task attribute “Invert FX Conversion Special” = false or empty, FX conversion is done using the PLDisplay Currency “Primary” trade rate (default).

If scheduled task attribute “Invert FX Conversion Special” = true, FX conversion is done using the PLDisplay Currency “Secondary” trade rate.

Accounting events must be added to the domain "FXConversionReversal" in the form:

<original accounting event>#_<reversal accounting event>

Example:

•

COT_#_COT_REV

•

SPLIT_VAL_#_SPLIT_VAL_REV

•

COT_NEAR_LEG_#_COT_REV_NEAR_LEG

•

COT_FAR_LEG_#_COT_REV_FAR_LEG

•

SPLIT_VAL_NEAR_LEG_#_SPLIT_VAL_REV_NEAR_LEG

•

SPLIT_VAL_FAR_LEG_#_SPLIT_VAL_REV_FAR_LEG

Ⓘ [NOTE: The logic associated with the domain “FXConversionEvents” takes precedence if the same accounting event is defined in both domains “FXConversionEvents” and “FXConversionReversal”]

Reversal Postings for INVENTORY Events

You can use the PO legal entity attribute "AccountingConversionIncremental".

If true, reversal postings use the FX rate of the effective date. They use the original FX rate otherwise.

By default, it applies to all reversal postings. You can limit the reversal posting using the domain “AccountingConversionIncremental”. It should contain reversal accounting events for which reversal postings use the FX rate of the effective date when AccountingConversionIncremental=true. Example: ACCRUAL.

This option can also be set at the book level using the book attribute AccountingConversionIncremental. The value of the book attribute has priority over the value of the PO legal entity attribute.

Reversal Postings for FX Flexi Foward Takeup

If a take-up process is executed on FX Flexi Forward trades, the Revaluation entries for the offset trades use the FX rate of the take-up date.

If you want to use the FX rate of the PRIMARY_ORIG trade instead, you need to setup the following.

The accounting events for which you want to use the FX rate of the PRIMARY_ORIG trade need to be added to the domains:

•

FXFlexiForward.FXConversionEvents

•

FXConversionEvents

The following posting attributes are populated for the accounting events added to the domain "FXFlexiForward.FXConversionEvents":

FXFLEXIFORWARD_PRIMARY_ORIG - Trade ID of the PRIMARY_ORIG trade

MERCHANTFX_TYPE - OFFSET or PRIMARY

Add FXFlexiForward to the domain "FXConversionSpecial".

If the accounting event to be revalued is configured in domain “FXFlexiForward.FXConversionEvents” and if MERCHANTFX_TYPE = OFFSET, the FX rate of the PRIMARY_ORIG trade is used for the revaluation.

In addition:

If the FunctionCurrency is part of the currency pair, use the posting amount of the non-converted posting on FunctionCurrency of the Offset trade for the conversion posting.

Otherwise, look for the PL Display currency of the Currency pair and get the market quote for the PL Display currency and convert the posting in PL Display Currency based on this rate. Use the Posting Amount from the above step as posting amount for the converted posting in Non PL Display Currency at PRIMARY_ORIG posting EffectiveDate/BookingDate.

5.5 Business Date

You can set "FX Translation Use Business Date" to true to set the booking date to the business date.

The notion of "Business Date" is defined for each Processing Org. To activate the notion of "Business Date", you need to set the legal entity attributes "ACC_USE_BUSINESS" and "ACC_BUSINESS_DATE" on the processing org as described in Calypso Accounting Postings documentation.

For reverse posting having the INVENTORY rule, the booking date is calculated as follows:

If (effective date of original event + rule adjustment days > legal entity attribute ACC_BUSINESS_DATE): Booking Date = effective date of original event

Else: Booking Date = legal entity attribute ACC_BUSINESS_DATE

This logic may be deactivated by setting environment property ReverseINVENTORYPostingOnEffectiveDate = false.

In this case:

If (booking date of original event > legal entity attribute ACC_BUSINESS_DATE): Booking Date = booking date of original event

Else: Booking Date = legal entity attribute ACC_BUSINESS_DATE