Euro
Euro
Euro
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Table of Contents
TEMENOS T24........................................................................................................................................ 1
Euro ......................................................................................................................................................... 1
User Guide .............................................................................................................................................. 1
Overview.................................................................................................................................................. 4
Testing the Euro Module ...................................................................................................................... 4
Exchange Rates and Euro Set-up ........................................................................................................... 6
Exchange Rate calculations involving the Euro ................................................................................... 6
Defining the Euro Currency ................................................................................................................. 9
Displaying Euro equivalents .............................................................................................................. 18
Settlement of NCU Contracts ................................................................................................................ 25
Allowing settlement of NCU contracts in EUR ................................................................................... 25
Local Clearing .................................................................................................................................... 34
The Euro and Position Management ..................................................................................................... 36
Converting the system base currency to EUR ...................................................................................... 42
Configuring the system ready for the conversion .............................................................................. 42
Multi-threading of base currency conversion ..................................................................................... 46
Batch Process .................................................................................................................................... 48
Running the Local Currency Conversion ........................................................................................... 50
Re-denomination of Accounts ............................................................................................................... 52
Preparation of the Accounts .............................................................................................................. 56
Re-denomination of Accounts using the Bulk Conversion utility ....................................................... 58
Batch Process .................................................................................................................................... 59
Conversion process ........................................................................................................................... 61
Special Cases .................................................................................................................................... 62
Re-denomination of Contracts............................................................................................................... 64
Initial Configuration for Contract Conversion ..................................................................................... 64
Re-denomination of Money Market Contracts ................................................................................... 75
Re-denomination of Loans and Deposits........................................................................................... 87
Re-denomination of Mortgage Contracts ......................................................................................... 105
Re-denomination of Swap Contracts ............................................................................................... 108
Euro and Securities ............................................................................................................................. 113
Changing the Reference Currency of Portfolios – SC application ................................................... 113
Changing the Reference Currency of Portfolios – AM application .................................................. 117
Re-denomination of Securities – Both SC and AM applications ..................................................... 119
Euro and Derivatives ........................................................................................................................... 140
Overview
On the 1st January 1999 the single European Currency, the EURO comes into existence, which by 31st
December 2002 will replace the existing national currencies of the eleven initial members. Later
phases will include other currencies. The introduction of the Euro will affect members of the banking
community by varying degrees.
This application is now upgraded to cater for further countries converting from national currency units
to euros.
The ‘Euro’ module is a set of additional functionality across all applications and utilities designed to
support the new requirements of the single currency, and to provide a smooth conversion from the
national currency.
Although this module was designed to deal with the introduction of the Single European Currency,
elements of the module may have additional uses. For example where there is a requirement to
perform a conversion of the system base currency. Any reference to Euro in this document could
equally apply to any currency irrevocably fixed to another. (If there is a requirement to change the
base currency to one which is not used as the base for usual exchange quotation rates then a slight
change to the conversion will be required.)
The Euro conversion utilities provided as part of the module involve much of the system, and it is
important to prepare a test plan of exactly how these items are to be tested. For initial tests of some of
the conversion processes, it is recommended that the testing be performed in conjunction with
members of the TEMENOS Client Services department, who can provide expert assistance to
investigate any problems which may arise.
A recommended test plan covering the different areas of functionality of the Euro module is included in
this document.
Terminology
Article 235
The Council Regulation (EC), which governs Conversion and rounding rules
EMU
European Monetary Union
NCU
National Currency Unit – a general term for existing national currencies
In-Currency
A currency which is converting to EUR.
Out-Currency
A currency that is not a member of EMU
Triangulation
The process of converting one In-Currency amount to another via the euro
No Compulsion, No Prohibition
The principle whereby there is no compulsion or to use the Euro. Used for in-currency
transactions in the transition period. A principle was in the original set up of the euro but is not
expected to be followed in further conversions.
Re-denomination
Re-denomination is the process of converting an In-currency transaction to the euro
equivalent of something which is at the fixed conversion rate.
Transition Phase
The phase where both NCU and EUR can be used. ERI ‘Euro Related Information’ added to
SWIFT messages where the amount is converted from NCU to EUR.
The rules for performing calculation and rounding, under Article 235 Regulation can be summarised as
follows.
• The conversion rates shall be adopted as one Euro expressed in terms of each of the national
currency units of the participating countries to six significant figures (note that the number of
decimal places will vary from one national currency to another).
• The conversion rates shall not be rounded or truncated when making conversions.
• When rounding monetary amounts to be paid or accounted for after a conversion, these must be
rounded up or down to the nearest sub-unit (or in the absence of a sub-unit to the nearest unit) or
according to national law or practice to a multiple or fraction of the sub-unit (or unit) of the national
currency unit. If the result is exactly halfway, the result shall be rounded up.
• The conversion rates shall be used for conversions in either direction between the Euro and its
national denominations.
• Inverse rates derived from the conversion rates shall not be used.
• Conversion between one national currency and another must be done via the Euro – referred to
as triangulation.
In T24 the fixed conversion rates are held in the CURRENCY file in the field [Link], the
currency against which the rate is fixed (i.e. EUR) is held in the field [Link], the date the fixed
rate applies from is held in the field [Link]. Any transaction involving an In-currency on
or after the fixed start date will follow the above rules. The details of the calculation methods are
described below.
As mentioned above conversions from one In-Currency to another must always be performed via the
Euro (once the [Link] has passed). This is frequently referred to as triangulation.
• An In-currency amount will be converted to the Euro amount by dividing the In-currency amount by
the [Link] to the Euro.
• The intermediary Euro value is held to six decimal places.
• The intermediary Euro amount is converted to the other In-Currency amount by multiplying by the
[Link].
• The resulting amount is rounded and formatted to the number of decimals of the Currency.
Conversions from an In-currency to the euro always use the fixed conversion rate (once the
[Link] has passed).
• An In-currency amount will be converted to the Euro amount by dividing the In-currency amount by
the [Link] to the euro.
• The resulting euro amount is rounded and formatted to the number of decimals of the Currency.
Conversions from the euro to an In-currency always use the fixed conversion rate (once the
[Link] has passed).
Conversions of In-Currency amounts to Out-Currency amounts are performed via the Euro.
Conversions of Out-Currency amounts to In-Currency amounts are performed via the Euro.
• The Out-currency amount is converted to a Euro amount using the standard rate calculations.
Applications, which allow entry of exchange rates, will allow entry of rates that differ from the fixed rate
or the derived cross-rate (using the fixed rates). In this case an override will generated by the system,
if the rate entered differs from the fixed cross rate by more than 0.001 %.
The T24 CURRENCY table will continue to express exchange rates against the system local currency.
If the local currency is ‘In’ there may no longer be a market rate quoted for the local currency against
out currencies after the Euro starts, a Euro rate will be quoted instead. In order to update the
CURRENCY table correctly in this situation the rates will need to be derived from the quoted Euro rate.
In-Currencies
All In-currencies will be quoted as the value of ‘1’ Euro to ‘n’ NCU. This might result in an exchange
rate of less than 1.
Out-Currencies
Although there is no definitive ruling, it is expected that market practice will also follow the 1 Euro to ‘n’
NCU quotation method. In the UK this is expected to be the practice, which will not follow the standard
UK quotation method (1GBP: n Fcy).
Quotation Code
When defining the EUR CURRENCY it is important that the quotation code is correctly defined in
order to follow the recommended practice.
Where EUR is not the local currency the quotation code should be ‘0’.
Where EUR is the local currency other currencies should be quoted with a code of null.
The usual rule for defaulting the base currency of a deal is to use the currency that will yield a rate
greater than 1. From the rules for quoting Euro rates this may not be the case for certain currencies
against the Euro (e.g. GBP), where the current rule would result in an inverse rate being defaulted.
A further parameter has been introduced, [Link] to resolve this potential problem. The
correct setting of this value can be used to force a CURRENCY to be the base currency instead of the
usual rule where the currency which will yield a rate greater than 1 will be used.
A value in the range 1 to 99 can be specified. Whenever the system attempts to default the base
currency, this value is tested. If a value is present that currency will be the default base currency.
Should both currencies have a value, the currency with the lowest value will be the default base.
Where the Euro is not the local currency it is important to set this value for the EUR CURRENCY to
ensure that Euro is taken as the default. It is recommended that a value greater than 1 (e.g. 5) is used
to allow for additional currencies, which should be the base when dealing with the Euro.
If EUR is the local currency, or the system has been converted to Euro, you may need to set the
[Link] where there are existing exchange rates quoted less than 1 involving the local
currency (for example IEP / GBP). In these cases the rank should additionally be set for the old local
currency.
The most likely requirement is to enforce the sequence of EUR, GBP, USD. This could be done by
setting the values
Currency Base Rank
EUR 5
GBP 10
USD 15
Refer to the HELPTEXT in CURRENCY and [Link] for further details and examples.
The following steps should be followed to define the Euro as a new CURRENCY (code EUR).
Country
Europe must be defined as a COUNTRY before the CURRENCY can be specified. There is probably
already a code XE, used for the XEU, however the Euro will need its own COUNTRY code, EU, to be
defined.
[Link]
The common characteristics of the Euro should be defined in the [Link] application.
A standard interest day basis has been agreed for the EURO, B 366/360.
Currency
The CURRENCY record can now be defined for EUR. Ensure that the correct [Link] is
used. The [Link], [Link] and [Link] fields should not be used for the EUR
currency.
[The Euro will be defined as a CURRENCY before it is due to come into existence, however financial
movements could be generated with Value date before this date (i.e. 01/01/99). The field
[Link] should be set to the start date of the currency. The system will generate an
override message should any entry be posted across an account with a value date prior to the
[Link].]
The euro is an existing currency and does not need an [Link].
Note that the value of [Link] is defaulted to the value in [Link] and cannot
be amended directly. Should a change be required the underlying [Link] record should
be amended. The next amendment to the CURRENCY record will update this field.
Holiday
The HOLIDAY table EU should be defined. Settlement is possible in Euro on all but two working days
– Christmas and New Year.
[Link]
It is recommended that the Periodic Interest table ‘01’ should be defined with the forward Euro interest
rates. The foreign exchange [Link] can be built automatically if required by using the
field [Link].
You should also check the system to see which other rate tables are used for other currencies, and
decide which require Euro interest rates.
[Link]
Where foreign exchange processing is used and the local currency is not an In Currency,
[Link] should be defined in the record EUR1. This table specifies the premium or
discount expected for the exchange rate of the Euro against the local currency.
If required these rates can be built automatically from the [Link] records by setting
[Link] to Y.
Local Currency is In
If the Local currency is an In-currency, there should be no premium or discount specified for the Euro
since after the start of the Euro the exchange rate is fixed irrevocably.
Basic Interest
Check your system for existing base rates for the local currency and each of the In-currencies: a Euro
rate will be required for each base rate used by existing contracts and accounts which may be re-
denominated in Euro.
Account Conditions
Account Conditions should be defined for each condition group that EUR accounts are expected to be
opened in. Account group conditions are defined in the applications [Link] and
[Link].
On the fixing date you must ensure that the rates of fixed IN currencies are set to be equal to the fixed
rate for the currency with zero spread.
[Note that the XEU should be blocked from 01/01/99 as it is officially replaced by EUR on this date.]
'IN' currency
A summary of the currencies linked to a Fixed Currency can be obtained by viewing the
[Link] table.
Once the Euro begins, the conversion rate is fixed. There will therefore be no forward premium or
discount for any of the In-currencies against the Euro. If the local currency of the system is either an
In-Currency or the Euro, the [Link] table should be modified to set the
[Link] to be zero from the Euro start date.
If [Link] are built automatically from the [Link] table, this feature should
be disabled for each of the In-currencies in the above situation.
If the local currency is out, [Link] will be required for EUR in the same way as any other
currency. For the In-currencies the rates will need to be derived from the Euro rates.
Interest Rates
When EMU starts the base interest rates will be the same for each In-currency, since each In-currency
is simply a different expression of the Euro. Currently interest rates will be different for each currency,
however these should converge towards a common rate towards the end of 1998. The interest rate
tables ([Link], [Link]) are used to record the rates.
Interest rates used for accounts ([Link] and [Link]) will need to be
reviewed for each product.
• Display of all amounts in all applications. An additional ENQUIRY CONVERSION option to display
the amount in Enquiries
• An additional CONVERSION option to display the amount in [Link] and
[Link] applications.
Euro equivalents will be displayed whenever a [Link] is specified for a CURRENCY regardless
of whether the [Link] has been reached. This will allow the Euro equivalent to be
shown on customer output for information purposes prior to the start date.
Once the [Link] is specified on a CURRENCY record the system will automatically display the
Euro equivalent as an enrichment wherever possible.
If existing versions do not show the enrichment against an amount field, the version should be
amended accordingly.
Foreign currency amount fields where the related currency is an In-currency will display the equivalent,
similarly local currency fields where the local currency is ‘In’.
In order to display the Euro equivalent of an amount in an enquiry, the currency of the amount must be
identified. In the enquiry a field should already hold the value of the currency, if not a field should be
added.
A new field should be added to display the possible Euro equivalent. The OPERATION should either a
contain amount field or a field containing the amount value. The above CONVERSION should be
specified with the field containing the currency value.
If you wish to apply the standard amount format, use the TYPE field with a value of CCY as usual, the
currency to format to should be field containing the fixed currency (see below).
Fixed Currency
Input Not required
Format UTIL FIXCCY, ccy name
Where Ccy name is the name of the enquiry field containing the value of the currency
Result If Ccy name is an In-currency the fixed currency i.e. EUR
If Ccy name is an Out-currency a null value is returned
In order to extract the fixed currency, the value of the currency must be identified. In the enquiry a field
should already hold the value of the currency, if not a field should be added.
A new field will be required to hold the value of the fixed currency. The content of the related
OPERATION field is not important. The above CONVERSION should be specified with the field
containing the currency value.
In order to extract the fixed conversion rate the value of the currency must be identified. In the enquiry
a field should already hold the value of the currency, if not a field should be added.
A new field will be required to hold the value of the fixed conversion rate. The content of the related
OPERATION field is not important. The above CONVERSION should be specified with the field
containing the currency value.
In order to display the Euro equivalent of an amount in a formatted message, the currency of the
amount must be identified. In the [Link] record a field should already hold the value of the
currency; if not a field should be added.
A new item should be added to display the possible Euro equivalent. The FIELD/”TEXT” should
contain an amount field (or possibly a total). The above CONVERSION should be specified with the field
containing the currency value.
Fixed Currency
Input Not required
Format FIXCCY*ccy name
Where Ccy name is the name of the [Link] field containing the value of the
currency
Result If Ccy name is an In-currency the fixed currency i.e. EUR
If Ccy name is an out-currency a null value is returned
In order to extract the fixed currency the value of the currency must be identified. In the [Link]
record a field should already hold the value of the currency; if not a field should be added.
A new field will be required to hold the value of the fixed currency. The content of the related
FIELD/”TEXT” field is not important. The above CONVERSION should be specified with the field
containing the currency value.
In order to extract the fixed conversion rate the value of the currency must be identified. In the
[Link] record a field should already hold the value of the currency; if not a field should be
added.
A new field will be required to hold the value of the fixed conversion rate. The content of the related
[Link] field is not important. The above CONVERSION should be specified with the field
containing the currency value.
Most applications in T24 insist that settlement accounts are in the same currency as the contract. As
settlement of NCU amounts may now be made in EUR or NCU, this restriction would require a manual
process to settle via a suspense account on the underlying contract, and create a [Link]
(or similar) from the NCU suspense to the correct EUR account.
Whilst this practice may be acceptable for small numbers of Euro settlements, it would obviously be a
large operational overhead and also prone to operator error in any site with a reasonable volume of
transactions.
The Euro module allows automatic conversion of NCU amounts to EUR for any nominated ACCOUNT.
This can be processed in one of two ways:
• Auto Payment Account – An existing NCU account is linked to a EUR account. Many NCU
accounts can be linked to the same EUR account, all transactions across the linked NCU
accounts are converted to EUR and posted to the EUR account. Any related payments are
converted to EUR.
• General Suspense Account – A suspense account of specific category is used for settlement
from the contract. A customer who has only a EUR account nominates that any deal in a
specific NCU should be settled to the EUR account. The system will check any posting made
across the general suspense account to see if the customer has a nominated EUR account, if
so the entry will be converted and posted to the EUR account.
In Order to illustrate the use of the auto pay account the scenario of the bank deciding to settle NCU
through the Euro will be used an example.
Settlement in IEP is to be made through a EUR Nostro maintained with the same bank. The EUR
Nostro account has been opened in the usual manner:
The IEP ACCOUNT record needs to be linked to the Euro Nostro using the [Link]:
• Accounting Entries Raised to the IEP Nostro (with the exception of certain entries through the
[Link] application – see later this section) will be converted to EUR and posted to
the EUR Nostro.
• Forward Accounting Entries to the IEP Nostro will be converted to EUR and posted to the EUR
Nostro. Any Forward entries, which exist prior to establishing the link with the auto pay account,
will be converted to EUR entries in the Close of Business processing. For this reason it is
recommended that the Nostro be linked at the end of the working day.
Any payment message (e.g. MT100 / 202) for the IEP Nostro will also be converted to EUR, the
original IEP amount will appear in the message as ERI information if the payment is sent via SWIFT.
If there is a requirement that the payments must still be sent in the original currency and not converted,
the field [Link] of the account should be set to YES. In this case the payment will
remain in NCU and no ERI information will be displayed.
The NCU account should continue to be used for deals in NCU, if defined as a default Nostro the
account will continue to default where appropriate, any further postings and payments to the account
will be converted automatically as described above.
As mentioned once the link is established, all further postings are directed to the EUR
[Link]. If an adjustment needs to be posted to the NCU account this must be posted
through the [Link] application, which can be used to force the entry to the NCU account.
When entry is forced to the NCU account an override is required.
By default the [Link] application will post entries to the specified account, so that when an
NCU account that is linked to an [Link] is used, the posting is made to the NCU account
and is not converted.
The [Link] application has many uses and this rule may not always be appropriate, there
may be a requirement to post to the [Link] in the same way as the other applications. For
example you may use the application to post transactions raised in another system and any postings
should be converted to a linked Euro account.
The automatic posting to the auto pay account can be controlled by setting the fields
[Link] and [Link] in the [Link] application, which is defined
at company level. Individual TRANSACTION codes, which should, or should not be posted to a linked
auto pay account should be specified in the [Link] field. The field
[Link] denotes whether the TRANSACTION codes specified should or should not
convert.
Using the screenshot example below, any transactions raised using only codes 1 and 51 will be
posted to the [Link] if defined.
The following setting will result in all transactions except for 1 and 51 being posted to the
[Link] if defined:
This method does not require the customer to have an NCU account. Instead the EUR account record
defines which NCU currencies can post to the account. NCU contracts should use a general suspense
account for settlement.
A new CATEGORY in the range 10-000 to 19-999 should be allocated for the general suspense
account.
An internal account should be opened for each In-currency. The general suspense account will have
an ID in the format:
NCU nnnnn 0001 where nnnnn is the category defined in the previous step.
The general suspense category must be added to the [Link] application (ID of
SYSTEM) before it can be used.
Note that once the [Link] record is authorised, users must re-sign on to T24 in
order to use the updated setting.
The customer Euro account needs to be linked to the general suspense account to be used for
settlement of contracts. In order to do this, the NCU currencies that can be settled by the account,
should be specified in the field [Link].
The application [Link] shows for a particular customer which accounts should receive
NCU payments.
The general suspense account will default as the settlement account if the customer has specified that
Euro should be used to settle the particular currency of the deal. Entering the general suspense
account for that particular NCU can also specify the account.
Care should be taken if the suspense is specified for a customer who does not have a EUR account,
which can receive NCU. The movement will not be posted to the EUR account and will remain in
suspense in this situation.
• Accounting Entries Raised to the IEP and DEM suspense accounts for the customer will be
converted to EUR and posted to the EUR current account.
• Forward Accounting Entries to the IEP and DEM suspense accounts for the customer will be
converted to EUR and posted to the EUR current account. Any Forward entries, which exist
prior to establishing the link, will be converted to EUR entries in the Close of Business
processing.
The NCU amount and currency is added to the narrative fields (for example field 72) in the format:
/xxxx/CCYnnnnnnn,nn
Where xxxx is a keyword, which can be OCMT (original amount) or CHGS (charge details):
T24 will add ERI to the following messages in the following narrative fields whenever the underlying
transaction settles through an NCU account in EUR. All ERI values are added with the keyword OCMT.
Details of charges can be entered in the relevant narrative/Bank to Bank info fields in the underlying
transaction.
Local Clearing
Many In-country local clearing systems will allow payments to be made in Euro as well as in the local
currency. During the transition period payments may well be sent in both EUR and NCU.
In order to allow a non-local currency account to be debited when sending an outgoing payment, the
field [Link] should be set to YES.
The field [Link] is used to control in which currencies payment can be sent the clearing
institution. If there is no value specified the system will assume that only the local currency is valid.
Payment will only be allowed in the currencies defined in this field if defined.
[Link]
Additional clearing accounts will be required for each additional currency specified in the
[Link] field. Each additional account should be added to the [Link] record
SYSTEM, in the fields [Link], [Link], [Link], before they
can be used in a local clearing [Link] transaction.
The field [Link] allows the specific COUNTRY or REGION to be defined. Combinations may
be specified by expanding the multi-value, if a combination is used a common working day and will be
obtained when calculating the calendar dates. Existing [Link] definitions may be modified,
or you may wish to create new calendars.
[Link]
There is therefore an option to allow In-Currency positions to be grouped under the EUR position. The
option to group In-currencies is provided in the application [Link], in the field
[Link]. When this field is set to Y, any in-currency amount is converted at the fixed
rate and displayed as the EUR equivalent when the EUR currency is selected.
This option can be used prior to the start date of the fixed rate, the [Link] entered in the
relevant CURRENCY record will be used for the conversion.
Note that when this option is used you will still be able to enquire on a specific In-Currency position by
specifying the currency in the selection.
[Link]
[Link].1
[Link].1
[Link].2
[Link].2
[Link].3
A new selection item, [Link] in the [Link] enquiry should be set to Y to show In-
currency items as EUR converted at the fixed rate. If you specify this option you will not be able to
view the individual In-Currency positions. If not specified the enquiry will show each currency
separately.
This facility is available prior to the fixed start date, the projected [Link] held on the relevant
CURRENCY record will always be used.
When merged positions are displayed the original currency is shown in the second column.
[Link]
The Euro module provides a utility that will allow this conversion to take place.
The Close of Business process will halt just prior to the start of the actual conversion, which is at the
point the normal Close of Business processing is complete. At this point a backup should be taken, as
this will be the last point that the system will be in NCU. If the conversion is run at a financial period
end – which is likely to be the case, the backup taken at this point can be restored in another area to
allow additional reports and enquiries to take place on the old base currency.
The conversion process is likely to result in rounding errors, which will be corrected by posting any
difference to a difference suspense account. In order to define the difference account, an internal
account CATEGORY in the range 10000 – 19999 should be created.
When contracts are converted, the early maturity of the NCU contract and drawdown of the EUR
contract are made through suspense accounts. A new CATEGORY should be created for this
suspense in the range 10000 – 19999.
A different suspense account should be opened in EUR for the CATEGORY created in the above
steps. You must open an account in each company, which shares the CURRENCY file.
A TRANSACTION code should be created for any movement created to adjust conversion differences.
Define [Link]
The [Link] file contains details for each company that is to be converted. You must convert
each COMPANY sharing a CURRENCY file at the same time; one record is required for each
company.
The file is keyed by the company code - you must be in the correct company to Input the record.
[Link]
[Link]
The date the conversion is to be run on. This cannot be before the [Link] for
the [Link]. The date can be entered prior to the start date of the currency providing
it is the working day before the start date, so if you wish to convert on 1st January 1999, the
[Link] would be 01/01/99, the system date would be 31/12/98.
[Link]
The category created for the difference entry should be added in this field.
[Link]
The category opened for contract suspense accounts should be defined in this field.
[Link]
The transaction code created in the previous steps should be defined in this field.
[Link]
The record id to the [Link] file should be specified here. The released
records [Link].1 and [Link].2 should be defined here. Do not add additional
records without prior consultation with TEMENOS.
[Link] record
[Link]
Once the batch base currency conversion record is set to run in Multi-thread, it is necessary to specify
which records are to be converted, and by which conversion thread. There are three stages to this:
firstly, the records which are to be converted need to be identified on the [Link]
table and where necessary these may need to be amended to suit local requirements. These are then
divided into sets on the [Link] file, and these sets must then be applied to the
overall [Link] record.
The records which need to be converted for the base currency conversion have been provided by
TEMENOS through released [Link] records. Each record specifies the field
names, which need to be converted for that application. In many cases it may be that no further
intervention by the user is required. However, it may be that some files have been changed to suit
local requirements. For example, if particularly large files have been split up into distributed files (for
example, perhaps the [Link] file) then in the [Link] field of the
[Link], the VOC name for that each file should be specified.
Once all [Link] files have been set up, they need to be put into
[Link] groups. There are already two records that have been released,
[Link].1 and [Link].2, which contain all the records that need to be converted for the EU
base conversion process. However, to enable multithreading, new [Link]
records should be set up, to split out the number of these records evenly across each process. These
records should then be included in [Link].
Note: it is important that there are at least as many [Link] records listed in
[Link] as there are batch sessions to be run during the Close of Business (as specified
in the [Link] field on the SPF SYSTEM record). If there are fewer records in the
[Link] field than the number of batch sessions then the system will automatically assume
that it must run in single-thread mode.
Batch Process
Run Dates
The run date should be set for the ad hoc jobs following BATCH records:
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link].REPORTS2
In a multi company environment these jobs run for each Currency level company - the dates should be
set only for those companies to be converted.
The [Link] job will set the run dates for the remaining EU batches.
Reports
The BATCH jobs [Link] and [Link].REPORTS2 should be
configured to reproduce any reports required after the conversion of the system.
[Link]
Runs after the conversion process. Recommended reports to include are:
[Link]
Reproduce the transaction journal in EUR
[Link]
Produce the mismatch report for the GL (a record should be defined in [Link]
whose key is held in the DATA field).
[Link]
Detailed CRB report for the G/L – The report name should be specified in the DATA field.
[Link].REPORTS2
Runs after the CRB reports have been recalculated. Recommended reports to be produced
are:
[Link]
Detailed CRB report for the G/L – The report name should be specified in the DATA field.
[Link]
Reproduce the currency positions with a EUR local currency.
Enquiries
There are two enquiries that should be checked after the conversion process has been run:
[Link] shows the before and after totals of the asset and liability CRB base in foreign and
local currency, to confirm that the system remains in balance after the local currency conversion.
Conversion summary
[Link] shows the posted adjustment transactions raised for transactions that have taken
place in EUR on the day of Local Currency Conversion. Entries to this file are only raised if there is a
difference between the deal rate and the fixed rate.
Revaluation of FX deals
Where the quotation method of the rate for a (OUT) currency against euro differs from the quotation
method against the NCU then a small difference of revaluation can occur. This is because the
arithmetic mean of buy and sell rates is not exactly equivalent to the arithmetic mean of their inverses.
The difference in revaluation between the two mid rates depends on the percentage spread. It is of the
order of the square of the fractional spread.
Percentage spread Percentage difference in mid rate
5% 0.225%
.5% 0.0025%
0.05% 0.000025%
The difference is in the revalued local currency equivalents and thus is posted in Profit and Loss. This
changes when the rates change. It makes no difference to the P/L in the end.
If you want the revaluation rate to be exactly equivalent then you should set the [Link] in the
CURRENCY record(s) before the conversion EOD. Remember to clear it the following day.
Batch Halt
The batch can be restarted by taking the AUTO BATCH option. The batch will then continue as normal.
Re-denomination of Accounts
Anybody using T24, who has accounts in one of the In-currencies, will need to convert the account’s
currency to EUR at some point during the transition phase. The Euro module provides a utility that will
allow this conversion to take place.
[Link] is [Link]
This will allow for the contracts to be converted during the online that day and thus
both the accounts and contracts can be shown in the balance sheet under the new
currency.
The decision is entirely with the bank at which stage of the processing during the batch that they
require the accounts to be converted.
NB Once the conversion process has begun and an account has been converted, it will not be
possible to switch between the 2 options.
BATCH XXX/[Link]
And ensure that the BATCH XXX/[Link] is set to Adhoc
BATCH XXX/[Link]
Ensure that the BATCH XXX/[Link] is set to Adhoc
• The account number to be used for the In-currency account when it is renumbered
([Link])
• If closure is required, the date of closure (default next interest payment) and posting restriction
code to be used ([Link] and [Link])
• Whether the mnemonic for the account is to stay with the converted EUR account or with the
renumbered In-currency account ([Link])
• The type of ‘AC’ Funds Transfer to be used to transfer the balance between the In-currency and
EUR account ([Link])
• Whether the standing orders are to be converted to the EUR ccy account or to be renumbered
to the new account number ([Link])
Before the conversion request can be entered, a structure for allocating a new account number for the
national currency account must be decided upon. This account number does NOT have to meet
existing CHECKDIGIT requirements, so a simple structure could be adopted such as, replacing the
leading 0 of the number with a 9 or adding a ‘1’ to the number. A renumbering subroutine is available
with this module for adding ‘1’ to the existing number, [Link].
In the case of multi-company installations, the [Link] record will need adjustment to
include the new range of numbers as valid for each company if the above first structure is adopted.
For example if accounts beginning ‘001’ are valid for company A, this should now additionally allow
accounts beginning ‘901’
Individual records may be entered in this application for an account, or may be created automatically
via the bulk conversion [Link] application. This application will allow a selection
criteria to be specified (i.e. all accounts in DEM for a particular customer), with a general set of
conversion conditions. When ‘verified’, this application will create individual [Link]
records for accounts.
• The account cannot have [Link] set to pass accounting entries to another account.
• The CURRENCY of the account must be one of the ‘In-Currencies’. (This will be denoted by a
[Link] defined in the CURRENCY record for the existing currency of the account)
• Interest and charge conditions must be defined from the start of the current capitalisation period of
the EUR currency.
• The account cannot be a PASSBOOK account. PASSBOOK accounts must be opened under a new
key for EUR.
• The new Renumbered account number must be valid and consistent with the existing old account
number. Hence internal accounts must follow internal account number formats and for external
accounts, the [Link] must be crosschecked if it exists.
• The [Link] must be of type beginning ‘AC’.
• [Link] must be in the range 90-99 for account closure.
• No unauthorised [Link] records may exist for the account.
• The account cannot be set for NOSTRO RECONCILATION.
• If the account is set for closure after the conversion then the following checks will be verified:
o The account is not an INTEREST LIQUIDATION ACCOUNT.
o The account is not an INTEREST COMPENSATION ACCOUNT.
o The account does not have any DIRECT DEBIT MANDATES.
o The account is not part of securities portfolio.
• Renumber routine, the routine to return the account number to be used for the national currency
account
• Keep mnemonic
• Conversion date
In the screenshot below, once the record has been verified, the bulk utility will select all accounts
denominated in DEM and set them for re-denomination into EUR. This is achieved by creating a
record in [Link] for each account selected, hence preparing the account for
conversion. In essence, the bulk utility enables the creation of [Link] records
without the user having to enter each one individually.
Batch Process
Run Dates
The batch record [Link] is run on a daily basis. In a multi company environment
this job is run for each financial level company.
In order to enable multi-threading of account conversions, the BATCH [Link]
should run the routine [Link].
BATCH [Link]
Report
Conversion process
When an account is converted automatically, the account number will be maintained and the account
converted to EUR. The original account in the national currency will be re-numbered as stated in the
[Link] record, thereby ensuring that the full history is maintained. The fields
[Link] and [Link] in the account records will maintain a link between the two
accounts.
The conversion of the account balance to EUR from the existing currency will be performed by the
automatic creation of a Funds Transfer between the renumbered original account, and the existing
(now EUR) account number. A special account transfer transaction type can be created for the
account, which will allow creation of a specific advice, and charges to be taken if required using
standard functionality. This will be retrieved from the [Link] field in the
[Link] record.
However, if the company does not have the Funds Transfer module installed then accounting entries
will be created to transfer the funds from the renumbered original account to the existing (now EUR)
account. A special account transfer transaction type can be created and set in field [Link] in
the relevant company record, in application [Link], to be used for any accounting entries
that are raised during the transfer of balance.
Special Cases
Account Conversion and Cash Pooling
Cashpooling operates on a single currency basis; whether foreign or local, all the accounts in a group
must be of the same currency. When one of the accounts in the group is subject to an account
conversion to change the account to EUR currency (and at the same time renumbering the original
account) this can complicate the cashpooling operation.
In order to prevent any cross-currency complications of having mixed currencies in a group, which has
values, based on the group currency it is essential that the integrity of the group be maintained.
As part of the EU conversion any client who has cashpooling records in the currency being converted
to EUR will need to activate the BATCH record [Link] and set the run date to
today.
EU conversion of cashpooling is closely tied to the account conversion process; once an account is
converted the cashpool COB procedures will check whether the account is part of a cashpool group. If
it is then the group may be flagged as inactive as a precaution. This is done by setting the field
[Link] to Yes, this will prevent any records in the group being modified and will exclude the
group from the cashpool processing until it is made active again.
Once all the accounts in the group are converted the cashpool records ([Link]) which
have been placed on hold, can be amended (for example to use more logical rounded Euro amounts,
rather than the unrounded exact equivalents) and authorised for the cashpool processing for the group
can resume.
Return Sweeps
Certain sweeps are configured to make sweep during the COB and return the funds the next morning,
an example would perhaps be where all surplus funds on a current account are swept up to a savings
account each night to attract interest but the balance is returned the next morning to provide a working
balance. In this scenario the return of the funds will be redirected to the new EUR account.
Re-denomination of Contracts
After the fixing of currency exchange rates it may be necessary to convert any contracts which have a
maturity beyond the end of the life of the NCU.
In T24 the following modules are supported for contract conversion subject to certain restrictions:
• LD Loans and Deposits
• MM Money Markets
• MG Mortgages
• SW Interest Rate Swaps
To achieve conversion we essentially early mature the NCU contract to suspense, and raise a new
contract in EUR through the following process:
Ensure that the [Link] file contains details of the following records for contract conversion:
[Link]
[Link]
[Link]
[Link]
For example:
Suspense Accounts
Although it can be changed at the group or individual contract level, it is necessary to set-up a default
suspense category and accounts for the balance transfer.
A new CATEGORY for the suspense accounts used in the contract conversion process should be
created. This should be a standard internal account category in the range 10000 to 19999.
A Euro suspense account should be opened for the category created earlier. The last four digits
should be ‘0001’.
Similar accounts should be opened for each of the In-Currencies where conversions will take place.
There are two accounting options for these accounts:
Auto Pay
If the [Link] for each In-Currency accounts is defined as the EUR suspense account above,
all entries raised from the conversion process wash through the same account; the net result being a
zero balance.
Manual
If the auto-pay is not set then the total value of the early matured contracts of the NCU will be held in
each of the NCU suspense accounts, and the total value of the new EUR contracts will be held in the
EUR suspense accounts. This option may be required if a check on these totals is deemed necessary.
The amounts could then be transferred manually to net off the balances as required.
If different suspense categories and accounts are required for different contract types, or for the
suspension of interest where conversion takes place on a non-interest date, these should be set-up in
a similar manner, however they do not require specification on the [Link] record.
A minimum of one [Link] should be created. This should be a non-reducing type and
not require overrides, specified by defining the [Link] field as NO.
When the contracts are converted the necessary dummy LIMIT records will be automatically created.
The settings for conversion of contracts is held in the [Link] file, each
record being keyed by the individual contract ID. However, to assist in the creation of these records
where sizeable volumes of contracts are being converted under the same conditions, there is a bulk
conversion utility, namely [Link].
The utility allows the user make selections from the contract files, based on any criteria on those files,
and set the conversion conditions. When the record is Verified, the related
[Link] records are created. If there are no errors or overrides, the
records are created fully authorised, otherwise they are created in HLD status to allow the user to
correct the settings prior to conversion. N.B. Neither this utility, nor [Link]
actually execute the contract conversion, they just set the parameters.
This utility is also used for bulk selection of accounts for conversion, but the fields in terms of contract
conversion are as follows:
The [Link] record holds all the settings for the conversion of an individual
contract, and also records the results of the conversion for any post-conversion reconciliation and
checking. N.B. It does not execute the conversion itself.
It can be input directly for an individual contract or created via the [Link] utility.
The fields are as follows:
ID The transaction reference number of the contract to be converted.
APPLICATION System field holding the application of the contract to be converted.
[Link] The value date at which the NCU contract will be matured, and the new
EUR contract starts.
The [Link] will default to the next interest settlement date,
unless the [Link] flag has been set to Yes either from the
[Link] record or through use of a version to pre-
populate it, in which case the [Link] will default to today.
If the [Link] flag on this record is set to Yes via direct user
input, the [Link] will not be automatically updated from its
initial default value, but it can be updated manually.
[Link] No input field recording the NCU currency.
[Link] Automatically populated with the fixed currency (i.e. EUR)
[Link] System field recording the original [Link] from the NCU
contract. This will then be used on the new EUR contract.
[Link] The maturing NCU contract will be updated to use this
[Link], and so this should contain the dummy
[Link].
Loans under commitment use different functionality in this regard,
explained in the relevant section of this user guide.
[Link] The suspense category to be used for the early maturity of the NCU
contract and the creation of the new EUR contract. This will default from
the [Link] field, if this record is created from
[Link], or else the [Link] on
[Link], but it can be updated to an alternative valid category
if required.
[Link] After conversion has been run, this system field is updated with the
transaction id of the new EUR contract.
[Link] This system field records when the conversion was executed. Where
conversion is taking place on an interest date, this can be before the
[Link] (value date).
[Link] System field recording the principal of the NCU contract prior to
conversion.
[Link] System field recording the principal of the new EUR contract. If there has
been a principal payment on the conversion date, then this will not be the
EUR equivalent of the [Link].
[Link] The internal and external [Link] to be used for
[Link] any Funds Transfers that are created to account for principal schedules
taking place on the conversion date.
[Link] The ID and amount of any Funds Transfer raised to account for a principal
[Link] schedule taking pace on conversion date.
[Link] This field holds any error message encountered during the creation of this
record from [Link], or during the execution of the
conversion.
[Link] Standard system local reference field.
[Link] When a LD drawdown under commitment is being converted, this field is
updated with the original commitment number.
[Link] When a LD drawdown under commitment is being converted, this field
holds the principal of the drawdown in the currency of the commitment.
[Link] If this flag is set to yes, then [Link] can be set to any
working day, not just the next interest settlement date.
Currently, this flag can only be set for LDs and MMs.
[Link] The [Link] for the future dated FT created to post
the suspended interest, if the [Link] is not an interest
settlement date.
[Link] The CATEGORY of the suspense account to be used for the suspension
of interest, if the [Link] is not an interest settlement date.
[Link] System fields updated with the ID, amount and value date of the Funds
[Link] Transfer created to post the suspended interest, if the [Link]
[Link] is not an interest settlement date.
to the next interest settlement date, so will need to be updated manually to the required conversion
date.
Because of the processing for the interest accrual, conversions set to take on a non-interest date,
must be executed on the [Link] itself.
• Set the maturity date to be the next interest payment date to flag the contract for conversion.
This will, in effect, be the conversion date.
• The principal liquidation account will be set a suspense account (this may be an internal
account with a category of [Link]).
• Care must be taken to ensure that any principal repayment on the conversion date still takes
place.
When conversion is taking place on a non-interest date, the conversion will also:
• Set the [Link] on the NCU contract to the suspense account in the NCU currency
based on the category defined in [Link] on the
[Link] record.
• The original contract will be used as the basis for the creation of the new EUR denominated
contract.
• The outstanding balance at the conversion date will be converted to EUR to become the
principal on new EUR contract.
• The value date of the new contract will be the conversion date.
• The drawdown account will be set to the suspense account (i.e. the internal account created
from [Link] in [Link]).
• The limit reference will be set to the Limit reference of the original contract (i.e. the limit
reference held in [Link] in [Link]).
• The reference number of the new contract will be held in the [Link] field of the
original contract and vice versa.
FT for repayment
Once the new contract and Funds Transfer transactions have been created, the associated
[Link] record is updated with [Link], [Link],
[Link], [Link], [Link] and [Link] as demonstrated
below:
Essentially, this process allows the NCU contract to fully mature, posting its interest to the suspense
account, where it is held until the next interest date and the FT posts it to the customer account. The
new EUR loan will start accruing interest normally from the conversion date. Any subsequent changes
to the interest conditions of the loan will take effect on the EUR contract as normal, but will not
automatically make any adjustment to the raised FT for the interest on the NCU contract.
On the interest settlement date, the interest posted to the customer will be in 2 entries: via FT for the
NCU contract, and via normal MM processing for the EUR contract.
[Link] record.
The committed interest for the period up to the next interest payment (scheduled for 26th April 2004) is
388.89, with the accrual on set at 250.00.
After conversion the NCU contract is matured on 21st April, with the interest to date as 250.00 being
posted to the PLN interest suspense account
The new EUR contract is raised starting from 21st April with a call maturity date. The committed
interest of 36.17 EUR is for the 5 days period until the interest settlement date.
The funds transfer raised to credit the customer account the suspended 250.00 PLN for the period up
to 21st April, posted for value 26th April.
As it is not possible to input rollover information on initial input of a contract, this information will not be
carried over to the EUR deal. This information will be lost in the conversion.
CAPITALISATION (for fixed maturity contracts)
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
If the contract has the [Link] and associated fields set then these will be maintained
correctly, and will populate the above fields as normal during COB processing.
Deferred Interest
We are assuming that the [Link] field is not set to D. If interest should be deferred,
then this will require manual adjustment of the FT.
Capitalisation
For fixed maturity contracts capitalisation is only applicable on a rollover, so as mentioned above the
setting with be lost along with the other rollover information. The interest accrual will be processed on
the assumption of settling the interest to the customer account on the next interest date.
For Call / Notice contracts, we will maintain the setting in capitalisation for future interest events,
however the processing of the interest accrual will not be strictly correct. The interest accrual FT will
be raised with the posting to the customer account, rather than capitalising the interest onto the
contract. We will recommend that clients follow the procedure of removing these FTs and manually
inputting the EUR equivalent onto the contract as a principal increase, scheduled for the next interest
date.
• Input the early maturity of the NCU contract (this will create the EUR contract in HLD status).
• Authorise the early maturity of the NCU contract.
• Input and authorise the new EUR contract.
• Input and authorise any resulting FTs relating to principal schedules and suspended interest.
N.B. The workflow for LD commitments and their drawdowns is a little more complex. Please refer to
the relevant section of this user guide.
Warning: Any changes made to the NCU contract made after this time will not affect the new EUR
contract, so should be made with careful consideration. In particular changes should not be made
again through the [Link],EUCC version, as this could have intended results.
The NCU contract set to early mature should now be authorised. For standard contracts this can be
done through any version (or none), however for commitments and loans under commitment the
[Link],EUCC version must be used.
The new EUR contracts have been created in HLD status, they will need to be input and authorised to
make them live. With the exception of drawdowns under commitment (see below), no particular
version is required for this.
If the conversion created any Funds Transfer records for principal repayments, or suspended interest,
these will also require input and authorisation. No particular versions are required.
Principal Repayments
If a principal repayment is scheduled to take place on the conversion date, it is not possible to transfer
this schedule to the new contract. Therefore, upon committing the conversion through
[Link],EUCC the system raises a Funds Transfer for the principal. The
Funds Transfer will debit the original principal liquidation account (for a loan) and credit the suspense
account used for early maturity (i.e. based on the category in the [Link] on the
[Link] record). Entries will be vice versa for deposits.
The transaction codes and other settings for the FT are taken from the [Link]
specified in the [Link] field for internal transfers, or the [Link] field for
external transfers.
The FT is created in HLD status, so will require input and authorisation to complete the transaction.
It is possible to convert loans and deposits on a non-interest settlement date. If the [Link]
flag is set to Yes, then the [Link] specified on the [Link]
record can be any working day. If this flag is set through [Link] or via a version
used to input the [Link], then the [Link] will default to
today. However, if the flag is set by direct user input to the [Link] record,
then the [Link] will have already defaulted to the next interest settlement date, so will
need to be updated manually to the required conversion date.
Because of the processing for the interest accrual, conversions set to take on a non-interest date,
must be executed on the [Link] itself.
• Set the value date on the FT to the next scheduled interest settlement date, as held in the
[Link] record for the NCU contract.
• Set the transaction codes
and other settings on the FT, based on the
[Link] specified in the [Link] field on the
[Link] record.
• Update the [Link] record with the transaction id, amount and
date of the FT in the [Link], [Link] and [Link] fields
respectively.
Essentially, this process allows the NCU contract to fully mature, posting its interest to the suspense
account, where it is held until the next interest date and the FT posts it to the customer account. The
new EUR loan will start accruing interest normally from the conversion date. Any subsequent changes
to the interest conditions of the loan will take effect on the EUR contract as normal, but will not
automatically make any adjustment to the raised FT for the interest on the NCU contract.
On the interest settlement date, the interest posted to the customer will be in 2 entries: via FT for the
NCU contract, and via normal LD processing for the EUR contract.
The FT for suspended interest could be value dated further forward than normally permitted by the
settings on the relevant [Link] record. If this is the case, the [Link] settings should be
temporarily changed to allow these transactions to be input and authorised, before returning it to its
normal settings.
If the contract is a call/notice contract without an [Link] set, then it is not possible to fully
complete the FT at conversion. The FT will be raised for the suspended interest amount, but should be
left in HLD status until the next interest payment date is known and the dates (and possibly accounts)
on the FT should be manually adjusted at that time.
Please note restrictions mentioned later in this document regarding deposits with interest capitalisation
set.
Worked Example
The example detailed below is for a CHF (assumed to be an in-currency fixed at 1 EUR = 1.75 CHF in
this case) deposit, running from 01st June 2001 until the 30th September 2001. Its next interest
payment is scheduled for 22nd August, however the contract is being converted on 21st August.
The committed interest for the period up to the next interest payment (scheduled for 22nd Aug) is
6974.10, with the accrual on 21st August at 6889.05.
After conversion the NCU contract is matured on 21st August, with the interest to date as 6889.05
being posted to the CHF LD interest suspense account
The new EUR contract is raised starting from 21st August and maturing on the original maturity date of
30th September. The committed interest of 48.60 EUR is for the 1 day period until the interest
settlement date.
The funds transfer raised to credit the customer account the suspended 6889.05 CHF for the period
up to 21st Aug, posted for value 22nd Aug.
Note that the following workflow is for the conversion of commitment and drawdown contracts which
are held in the same currency. For mixed currency contract structures refer to the later section.
• Create [Link] records
• Execute the conversion for all drawdown contracts.
• Execute the conversion for all commitment contracts.
• Input and authorise the new EUR commitment contracts
• Input and authorise the new EUR drawdown contracts
Conversion Parameters
Using the version [Link],EUCC input the conversion for the drawdown contracts.
This will early mature the NCU contracts, and raise the EUR drawdown contracts in HLD status.
Using the version [Link],EUCC authorise the conversion for the drawdown
contracts. This will store the associated commitment number and the NCU contract amount on the
[Link] record. It will also execute a limit increase for the NCU contract
amount for non-revolving deals, to address the double exposure created by the necessity of keeping
the same limit reference rather than using a dummy limit for the maturing NCU contract.
At this point leave the created EUR drawdown contracts in the HLD status. Convert all related
drawdown contracts before converting the associated commitment contract.
Using the version [Link],EUCC input the conversion for the commitment
contracts. This will early mature the NCU contracts, and raise the EUR commitment contracts in HLD
status. For a non-revolving commitment, the new principal will be the EUR equivalent of the old
principal plus the active drawdown amounts as stored on the [Link] record
of the drawdown. (This is so that when the EUR drawdowns are attached onto the EUR commitment
the available amount is returned to the correct EUR equivalent for the pre-conversion NCU available
amount.)
Using the version [Link],EUCC authorise the conversion for the commitment
contracts.
Input and authorise the new EUR commitment contracts from HLD status. No particular version is
required.
Using version [Link],EUDD (N.B. different version used) input the HLD EUR
drawdown contracts. This will update the commitment number on the contract from the NCU
commitment number to the new EUR commitment number, and execute the drawdown from the
commitment (thus for non-revolving commitments returning the available amount to the correct level).
Authorise the new EUR drawdown contracts. No particular version is required.
In this example a 10M SIT Non-revolving Commitment, has 2 live drawdowns and one fully matured
drawdown. The assumed fixed rate is 1 EUR = 264 SIT.
Initial structure
The drawdowns are converted i.e. the SIT contracts are early matured, and new EUR contracts raised
in HLD status, whilst recording the drawdown amount in SIT on the
[Link] record.
Conversion of Drawdowns
When the commitment is converted, initially it has no drawdowns associated with it. The principal and
available amount are both 26515.15 EUR, being the equivalent of 7M SIT.
Conversion of Commitment
When the drawdown contracts are linked to the EUR commitment contract the available amount is
reduced to 18939.39 EUR, i.e. the equivalent of the original available amount of 5M SIT.
Re-linked drawdowns
Where there are NCU drawdowns from an existing EUR commitment, an amended procedure is
required, as there will obviously be no conversion of the commitment itself.
In this example a non-revolving EUR commitment has a live EUR drawdown, a live SIT drawdown and
a fully matured drawdown.
Initial Structure
Conversion of Drawdown
In order to take account of the new EUR drawdown without ultimately affecting the available amount, a
principal increase for the amount stored on [Link]. This is facilitated by
using the [Link],EUPRINC version supplied.
When the new EUR drawdown is re-linked to the commitment the available amount returns to its initial
value.
Re-linking of drawdown
Automation of LD conversions
As well as using the [Link] utility to aid in the set-up of the required
[Link] records, it is also possible to semi-automate the execution of the
conversions. Because of the structure of the conversions it is necessary for each contract to go
through the process of being opened through the version and committed. The use of the
[Link] tool is therefore recommended to assist with volume conversions, as this
will emulate the required keystrokes with minimal user interface. The same workflow must, however
be adhered to so this does need to be used with care, particularly with commitments and drawdowns.
Ineligible Contracts
When converting contracts on a non-interest date, the FT raised to debit the suspense account and
credit the customer account (for a deposit, vice versa for loan) with the accrued interest is
inappropriate. For these contracts, the user should manually remove the FT, and input a principal
increase schedule to the EUR loan for the equivalent amount on the future interest capitalisation date.
The processing of the Funds Transfer for suspended interest from the NCU loan, will take place during
the start-of-day phase of the COB on the interest settlement date. The payment will be processed
regardless of whether there is sufficient funds on the account. If this occurs the override is recorded on
the FT record and the exception will be highlighted in standard reports, and the issue dealt with
manually, raising a PD through [Link] record if necessary.
The interest from the new EUR contract will be processed as per normal LD functionality at the end of
day, and will automatically raise a PD if settings require it.
The two events are independent, and will be processed separately.
Past Due
It is not possible to convert loans with past due items associated with them. It is necessary to manually
pay off the PD item linked to the loan to a suspense account and raise a fresh [Link] item for
the payment.
Collateral
There is no automatic update of Collateral during the conversion of LDs. Any updates would need to
be handled manually.
• Mortgage contract are early matured by the creation of an [Link] record for the
outstanding principal
• Set the value date and the transaction date to the required next interest payment date to flag
the contract for conversion. This will be, in effect, the conversion date.
• The Payment account will be set a suspense account (this may be an internal account with a
category of [Link]).
Care must be taken to ensure that any principal repayment on the conversion date still takes place.
• The original contract will be used as the basis for the creation of the new EUR denominated
contract
• The outstanding balance at the conversion date will be converted to EUR to become the
principal on new EUR contract
• The VALUE DATE of the new contract will be the conversion date
• The DRAWDOWN ACCOUNT will be set to the suspense account (i.e. the internal account created
from [Link] in [Link])
• The limit reference will be set to the limit reference of the original contract (i.e. the limit
reference held in [Link] in [Link])
• The reference number of the new contract will be held in the [Link] field of the
original contract and vice versa
FT for repayment
Once the new contract and Funds Transfer transactions have been created, the associated
[Link] record is updated with [Link], [Link],
[Link], [Link], [Link] and [Link] as demonstrated
below.
Currency IRS contracts will not be converted automatically. However all other types of contract will be
converted. Listed below is a more detailed explanation of each of the conversion processes.
• Set the maturity date, asset frequency and liability frequency for maturity date schedules to the
required conversion date.
• The account number for a principal repayment will be set a suspense account (this may be an
internal account with a category of [Link]).
• Care must be taken to ensure that any principal repayment on the conversion date still takes
place.
• The original contract will be used as the basis for the creation of the new EUR denominated
contract.
• The outstanding asset and liability principal amounts the conversion date will be converted to
EUR to become the respective principal amounts on new EUR contract.
• The value date of the new contract will be set to the early closure date and the Maturity date will
be set to the original maturity date.
• The drawdown account will be set to the suspense account (i.e. the internal account created
from [Link] in [Link]).
• The limit reference will be set to the limit reference of the original contract (i.e. the limit
reference held in [Link] in [Link]).
• The reference number of the new contract will be held in the [Link] of the
original contract and vice versa.
FT for repayment
Once the new contract and Funds Transfer transactions have been created, the associated
[Link] record is updated with [Link], [Link],
[Link], [Link], [Link] and [Link] as demonstrated
below:
When the portfolio reference currency is changed, there will still be a requirement to reprint historical
valuation reports in the original portfolio reference currency. Therefore the original reference currency
will be stored. Also, as the historical values of the portfolio will be required, the historical valuation
totals, contributions, withdrawals and invested capital amounts will have to be recorded in the original
reference currency as well as the converted values in the new reference currency. New fields will be
added to store the values in the original reference currency with the existing fields for contributions,
withdrawals etc. containing amounts that have been converted at the fixed exchange rate to the new
reference currency (i.e. the Euro).
The details of individual items for historical portfolio reports are held internally on T24 on twelve files
called [Link].FLOW01, [Link].FLOW02, [Link].FLOW12 (where the number at the end
signifies the month number). These files will not be converted to the new reference currency but
instead will be populated with new historical data over the year following the conversion of the
reference currency, thus facilitating the production of historical valuation reports.
As the value of a portfolio can be re-calculated online, the portfolio can be valued in the new reference
currency immediately when the conversion takes place. However in addition to the portfolio data, T24
uses the reference currency of the portfolio to calculate the cost of position. The cost of a security
position is held on the [Link] file. The individual security movements that gave rise to
that position are contained in the [Link] file. Both these files contain a cost amount in the
portfolio reference currency, the [Link] figure being calculated from the figure
contained in [Link]. Therefore as part of the process of converting the portfolio reference
currency, T24 will need to convert the cost amounts to the new reference currency on all the individual
[Link] records and then rebuild the [Link] figure from them using the
recalculation of cost of position functionality, which already exists in T24. If the [Link]
records are converted and then the [Link] record rebuilt, this will eliminate the
possibility of rounding errors between the [Link] record and the total of the
[Link] records.
The conversion of the reference currency will take place during the Close of Business. It will be done
by the [Link] process that will normally run in the application Close of Business. It
is suggested that a portfolio be converted to Euro immediately after the production of a portfolio
valuation report that has been sent to the customer informing them of the change. This program will
use a list of those portfolios that have been flagged to change reference currency and process each
portfolio in turn. First it will copy across all the historical figures on the [Link] record,
then it will convert all the [Link] records for that portfolio and rebuild the cost of position
in the Reference Currency on each [Link] record of that portfolio. Once this has been
done the [Link] file will be converted (which contains details of all contributions and
withdrawals for the portfolio) and the contributions and withdrawals figures on the [Link]
record will be recalculated. The other total figures on the [Link] file will be converted at
the fixed rate and finally the current value of the portfolio recalculated using the on-line portfolio
revaluation that already exists in T24.
The screenshot below shows a [Link] record for which a request is being made to
change the reference currency to EUR. Note that the field [Link] is set to ITL in this
screen:
Note that the [Link] field has been set to EUR on this screen with an effective date of
1st Jan1999 set in the [Link] field.
The following screen shows the [Link] record after conversion of the reference currency:
Note that the [Link] field for this portfolio has been changed to EUR and the
[Link] field has been set to ITL.
Note that here we have requested that all portfolios with a [Link] of DEM change
their [Link] to EUR.
Before performing the COB, the [Link] file should have the field, [Link], set to
“Y” to indicate that historical valuation data should undergo conversion to the new reference currency
where appropriate.
In much the same way as the SC application, the running of a COB will now perform the necessary
updates.
After the COB, various enquiries can be checked to ensure the integrity of the newly reported EUR
reference currency.
The changing of the reference currency will affect certain enquiries and reports that detail the current
reference currency equivalents.
The following extracts show a number of example enquiries after the setting of the change of
reference currency.
The term "re-denomination" means the change of the unit in which the amount of outstanding debt is
stated from a national currency unit to the Euro unit. It does not mean the altering of any other term of
the debt.
T24 Approach
Re-denomination of debt instruments will be done using the corporate actions functionality. A selection
of [Link] records are supplied in the data library item [Link] as example re-
denomination conversion records. These records cover the range of options for re-denomination of
debt instruments at both bond and holding levels with various rounding rules.
The rate of conversion of the bonds will be at the fixed exchange rate between the national currency
and the Euro. However for any currency where 1 of the national currency is worth less than 1 Euro
(which is the case for most ‘in’ currencies) there will be residual cash amounts to be dealt with. This
problem will be exacerbated where the trading unit of the security is more than one. T24 can deal with
this problem by using another corporate action for the cash compensatory amount. Where the RE-
DENOMINATION flag on the DIARY record is set to ‘YES’, T24 will perform some additional updates.
The first of this will be to take the information on the [Link] file record on the national
currency security and update the [Link] record of the new EURO security. Any yield and
dividend information will be converted at the fixed rate between the old and new security currencies.
At present it is not possible to re-denominate discount bonds within T24. All other forms of securities
are supported for re-denomination.
Running the corporate action will automatically update the [Link] and [Link] fields
on the old and new [Link] records.
Re-denomination Methods
Re-denomination can be achieved by two main methods, in combination with alternative rounding
rules.
Securities are converted at a bond level (minimum trading unit) using fixed conversion factors.
After conversion, Euro nominal amounts would need to be rounded to the new minimum
trading unit. This minimum trading unit would typically be 1 Euro cent or 1 Euro but could in
practice be any value. The issuer will also decide whether the new nominal amounts will be
rounded down, up or to the nearest minimum trading unit.
The sum of all individual bonds would then be calculated by the financial institutions and
matched against the total held at the central depository. Any difference between the totals
would then have to be accommodated by adjustments in the financial institutions trading
accounts, adjustments in individual holdings (possibly with cash settlement) or adjustment via
a correspondent bank. The adjustments would then ensure the sum of individual holdings
equals the converted total at the central depository.
Example - Bond Issue re-denominated at bond level with rounding to the nearest Euro cent:
An issue consisting of ten bonds each with a nominal value in national currency units ("ND") of ND
1,000 is split in three holdings:
Each bond is converted from 1000 ND to 156.3025079 EUR. This value is then rounded to the nearest
minimum trading unit (1 Euro cent) - 156.30 EUR.
Clearly the larger the holding, the larger the loss (or gain) could be. The total amount of the issue after
conversion is 1563.00 EUR
In order to achieve this in T24 the user will need to do the following:
[Link] for Bonds using the Unit calculation method and legal rounding
• Set up a new [Link] record with the new details for the securities. Make sure that
the [Link] on the new [Link] is set to 0.01. This will allow the minimum
nominal value of the security to be set to 1 Euro Cent.
• Create a corporate action to convert the old security into the new security with a conversion ratio
specified as [Link] : [Link], e.g. 177.6 : 1.
• Any cash compensation will be distributed by the issuer as another corporate action.
Securities are converted at a holding level using fixed conversion factors. After conversion,
Euro nominal amounts would need to be rounded to the new minimum trading unit. This
minimum trading unit would typically be 1 Euro cent or 1 Euro but could in practice be any
value. The issuer will also decide whether the new nominal amounts will be rounded down, up
or to the nearest minimum trading unit.
The sum of all individual holdings would then be calculated by the financial institutions and
matched against the total held at the central depository. Any difference between the totals
would then have to be accommodated by adjustments in the financial institutions trading
accounts, adjustments in individual holdings (possibly with cash settlement) or adjustment via
a correspondent bank. The adjustments would then ensure the sum of individual holdings
equals the converted total at the central depository.
Example: Bond re-denominated at holding level with rounding to the nearest Euro cent:
An issue consisting of ten bonds each with a nominal value in national currency units ("ND") of ND
1,000 is split in three holdings:
The new total amount for the issue is therefore 1,563.03 EUR, equalling ND 10,000.03, and compared
with 1563.02510 EUR for a simple conversion of the original total amount. The rounding error is
clearly very small.
In order to achieve this in T24 the user will need to do the following:
• Set up a new [Link] record with the new details for the securities. Make sure that
the [Link] on the new [Link] is set to 0.01. This will allow the minimum
nominal value of the security to be set to 1 Euro Cent.
• Create a corporate action to convert the old security into the new security with a conversion ratio
specified as [Link] : [Link], e.g. 6.619 : 1.
• Any cash compensation will be distributed by the issuer as another corporate action.
Example: Bond re-denominated at holding level rounded down to a minimum trading unit of 1 Euro.
Step 1
Convert the nominal value from ND to EUR 1,000/1.36 = 735.2941176.
Step 2
Round down to units of 1 Euro = 735.00
Step 3
Use the amount as new EUR nominal value therefore total issue size in EUR is =
(1,000,000,000/1,000)*735.00 = 735,000,000.00
Step 4
Calculate the EUR size from the ND issue size = 1,000,000,000/1.36 =- 735,294,117.65.
Step 5
Therefore the difference because of rounding = 735,294,117.65 – 735,000,000.00 = 294,117.65.
Step 6
294,117.65 EUR will be paid out as cash compensation.
In order to achieve this in T24 the user will need to do the following:
[Link] for Bonds using the holding method and downward rounding
• Set up a new [Link] record with the new details for the securities. Make sure that
the [Link] on the new [Link] is set to 1. This will allow the minimum
nominal value of the security to be set to 1 Euro.
• Create a corporate action to convert the old security into the new security with a conversion ratio
specified as [Link] : [Link], e.g. 1.36 : 1.
• The cash compensation will be distributed by the issuer as another corporate action.
Re-denomination of equities
In the context of the equity markets, re-denomination is the conversion of the par value of the shares
into Euro. Such simple conversion may be combined with a change of the nominal value.
There are four main options available to a company that wishes to re-denominate its equity:
These methods should be applied to avoid mismatching between the converted nominal capital and
the total of converted par values.
T24 Approach
For equities, T24 is already capable of converting from one security position to another whilst retaining
the book cost of the security position. However where the RE-DENOMINATION flag on the DIARY
record is set to ‘YES’, T24 will perform some additional updates. The first of this will be to take the
dividend information on the [Link] file record on the national currency security and update
the [Link] record of the new EURO security. Any yield and dividend information will be
converted at the fixed rate between the old and new security currencies.
Running the corporate action will automatically update the [Link] and [Link] fields
on the old and new [Link] records.
1. Leave shares with an un-rounded par value in Euro. This method is to convert the
share capital into Euro at the fixed conversion rate (rounding up or down to the nearest cent)
and then to divide by the number of issued shares keeping the share par value in Euro un-
rounded.
This method would avoid mismatching between the converted nominal capital and the total of
converted par values. No action would be needed on the part of the company apart from a
shareholders' resolution. The shares could be rounded up on some future occasion when the
company wishes to make a capitalisation issue. In order to avoid rounding errors it might be
necessary to have shares with par value specified to several decimal places. At first sight, that
does not seem to have any implication.
However, un-rounded par value might not be practicable, as the number of decimals will need
to be limited at least for reporting purposes (i.e. in the company's statutes). If a rounding takes
place, it would result in a change in the total share capital, which should require additional
action on the part of the company.
2. Convert the par value of each share into Euro, rounding to the nearest cent. This
method is to convert the share par value into Euro by applying the fixed conversion rates and
the rounding rules foreseen in the "235" EC Regulation, the nominal share capital being the
sum of the par value of the shares in the issue. If no specific action has been taken by a
company at the end of the transitional period, shares par value will be deemed to be
converted into Euro according to this method.
As a result of this method, the sum of the rounding adjustments on each individual share will
alter the nominal share capital of the company up or down. In order to correct this mismatch,
two options are available to a company:
The amount of capital increase or decrease required will depend on the conversion rate and on
the nominal value of the shares and their number. The effect will be greater for low value
shares issued in large number.
3. Change the par value to a round number of Euro in order to have a common par
value (Re-nominalization). Following this method the share capital is converted into Euro
at the fixed conversion rates (rounding up or down to the nearest unit). The share capital is
divided into shares with a par value of 1 Euro each. In order to retain the original share of the
shareholder in the share capital, the Euro share capital and thus the number of shares will
have to be adjusted accordingly. This could be achieved either by a capital increase or a
capital decrease. The effect on capital will be even greater than for simple re-denomination by
rounding to the nearest cent.
Given that the price of a share bears no relation to its nominal value, there seems to be no
advantage in having a common par value across Europe. Moreover such harmonisation would
be very difficult to achieve given the differences in par values across Europe.
4. Move to Non Par Value shares. In an NPV system, shares are simply a fraction of the capital
stock. NPV shares make the conversion to Euro very easy. Once the company’s articles
have been modified to provide for NPV shares, indicating the share capital, the number of
shares issues and the minimum issuing amount, no further action is required to convert to the
Euro. With NPV shares there is no need for a physical exchange of share certificates, if any.
The share prices can be lowered by simply splitting and there is no need for a capital increase
or descrease.
Moving to NPV shares allows a company to avoid capital and cost intensive measures. NPV
shares are allowed by the second Community Company Law Directive, but in many countries
the relevant national legislation has not yet been put in place. In the short term, an amendment
to national legislation would be required to allow the NPV solution to be implemented.
EXAMPLES
The conversion of the share nominal value into Euro by applying the fixed conversion factor would
result in a nominal value expressed in Euro with several decimals. The examples below illustrate the
different effects according to the method used.
Company's share capital: 250,000,000 (expressed in national denomination "ND") divided into
50,000,000 shares with a par value of 5 ND assuming a conversion rate of 1.95591.
▪ Share nominal value in Euro: 5 / 1.95591 = 2.556354842503 (rounded to the nearest cent) = 2.56
▪ Share capital: 2.56 x 50,000,000 = 128,000,000 EUR
▪ Capital increase required = 182,257.87 EUR
Share capital: 250,000,000/1.95591= 127,817,742 (rounded to the nearest unit) divided into
127,817,742 shares of 1 Euro, previous share nominal value 5 ND = 2.56 EUR.
Share capital 250,000,000 ND represented by 50,000,000 shares each share represents 1/50,000,000
of the share capital after conversion:
▪ Share capital = 127,817,742.13 Euro
▪ Each share still represents 1/50,000,000 of the capital
• Set up a new [Link] record with the new details for the securities with a new par
value of the EUR equivalent of the old par value. In this example the old par value of 50 DEM has
been converted to 25.32 EUR.
• Create a corporate action to convert the old security into the new security with a conversion ratio
specified as 1 : 1 and by setting up an appropriate par value set by the issuers.
• If there is any cash compensation, capital increase or capital decrease then these will be new
corporate actions.
• The creation of the [Link] record will be the same as in the earlier example.
• Set up a new [Link] record with the new details for the securities.
• Create a corporate action to convert the old security into the new security with a conversion ratio
specified as the ratio between the converted old par value and the new par value, in this example
1 : .769625.
The application [Link] will allow the user to select on the [Link] file
(using any field on the [Link] [Link] record).
The usage of this application has been described in the next section ‘Re-denomination Process
Guidelines’.
Cash settlement for the purpose of this functionality has been defined as:
For futures contracts the effective realisation of any profit and loss due to involved parties
For options contracts the payment of any outstanding option premium.
Conversion will not occur to individual transactions where any of the following conditions exist:
• Unauthorised Deals
• Unauthorised Closeouts
• Diary Events Pending
• Open Orders
• Partially Filled Orders
• Unauthorised Orders
• Unauthorised records in any DX application
• Partial Closeout
The COB process [Link] has been created in BATCH, which will run daily to convert
derivatives contracts and customers as per settings in the [Link] file.
The dates, on which particular exchanges are to convert, along with the conversion date for the
customer reporting currency are set up in the new [Link] file. The related fields
[Link], [Link] and [Link] correspond to derivatives contract conversion,
and the related fields [Link] and [Link] correspond to the customer reporting
currency conversion. Note that for both sets of fields, more than one currency can be specified for
each run date.
However, it should be noted that by utilising this methodology ALL contracts registered against the
selected exchanges WILL be converted and any associated open [Link](s) cash settled unless
the user exempts the contract from conversion by setting [Link] to “NO” in the
relevant [Link] record.
Should it be required that only particular trades that relate to the same contract be converted i.e. NOT
all trades, the user will need to “select” specific trades for conversion by utilising the on-line enquiries
provided (see later). Care is needed to ensure that trades that are NOT to be converted are not
subsequently captured by the close of business conversion.
Any derivatives contracts where either or both the CURRENCY and [Link] are in the
converting currency will be made inactive by setting the [Link] to the conversion date
subsequent to performing the conversion it will no longer be possible to enter into any new transaction
in the converted contracts.
However, where new contract definitions are required, which are based on existing terminated
contracts (e.g. where an exchange provides a newly denominated equivalent contract to aid the
conversion process), the user may copy the [Link] record of the originating
contract definition and substitute new field definitions where required e.g. CURRENCY. Any
[Link] records where the [Link] is in the converting currency will be
converted such that the [Link] becomes the new currency.
Having run the converting close of business all transactions meeting the selection will have their status
marked as CLOSED, the corresponding [Link] records will be reversed, futures
profits/losses realised and/or outstanding option premiums paid and updates passed to all other
relevant DX records.
ENQ [Link]
Following the ECD (Euro Conversion Date), the account balances for the converted accounts are
maintained in EUR, and recorded as such in the AM Valuation and Performance files.
Historic valuation and performance data continue to have the old currency accounts. E.g. if a DEM
account is converted to EUR, the historic valuation and performance files [Link],
[Link] and [Link] will continue to hold DEM account balances.
The procedure for converting accounts is described in the section ‘Re-denomination of Accounts’ in
this document.
[Link]
[Link]
[Link] cont’d
The valuation for Portfolio 1006-1 (Account no. 21733) prior to conversion is as follows: -
Enquiry [Link]
[Link]
After the account has been converted the valuation for 12/6/03 is recorded in DEM, under the
renumbered account number. The valuation after the account conversion is recorded in EUR under
the pre-existing account number: -
Enquiry [Link]
Introduction
Cashpooling operates on a single currency basis; whether foreign or local, all the accounts in a group
must be of the same currency. When one of the accounts in the group is subject to an account
conversion to change the account to EUR currency (and at the same time renumbering the original
account) this can complicate the cashpooling operation.
In order to prevent any cross-currency complications of having mixed currencies in a group, which has
values, based on the group currency it is essential that the integrity of the group be maintained.
As part of the EU conversion any client who has cashpooling records in the currency being converted
to EUR will need to activate the BATCH record [Link] and set the run date to
today.
EU conversion of cashpooling is closely tied to the account conversion process; once an account is
converted the cashpool eod procedures will check whether the account is part of a cashpool group. If
it is then the group may be flagged as inactive as a precaution. This is done by setting the field
[Link] to Yes, this will prevent any records in the group being modified and will exclude the
group from the cashpool processing until it is made active again. Once all the accounts in the group
are converted the cashpool records ([Link]) that had been placed on hold can be
amended/authorised and the cashpool processing for the group can resume.
Full Conversion
Full conversion would mean that either all the accounts are converted en masse or in respect to
cashpooling all the accounts in a cashpool group are done at the same time. Depending on volumes
of cashpool records in use a full selection of the cashpool accounts may be the best option, in larger
volumes it may be desirable to convert group by group.
Example
We selected a group called SRP2, note the currency was ‘old’ currency CHF and was a working
sweep.
Group SRP1
Checked the accounts used in the group including those such as the [Link], which may not be
on any sweep record.
Note the [Link] record has been changed to EUR but the field [Link]
is not marked as YES, meaning the group can be input to, modified and authorised.
Checking on the [Link] records that exist in the SRP2 group we have three on hold, as
expected we can amend these records adjusting the new sweep amounts to more sensible rounded
amounts.
As can be seen on the above screen the sweep is now EUR based (even though the account titles
were not changed in the conversion these are EUR accounts). The amounts would usually be made
more sensible as a client is not expecting a balance limit of EUR 57.14 but would be more likely to
choose EUR 50.00 as a check.
All the groups [Link] records were then amended and authorized ready for the next cob.
Doing a whole group at once reduces the impact and can have the group up and running in less time.
Since the records are effectively new the work files will be checked after the next cob.
As can be seen now on the updated sweep record updated EUR sweep record screen above the
[Link] is set to the conversion date so effectively no adjustments caused by back valued
entries will be catered for prior to that.
The account before conversion and after conversion is checked using ENQUIRY [Link],
WHICH shows the entries and correct conversion.
Here the evidence shows the account was performing sweeps until the conversion where the balance
was transferred to the new account.
The account number for the EUR account is the existing number, the balance transferred is shown
and the change in the sweep limits has itself forced a sweep to reduce the balance as required.
Partial Conversion
Partial account conversion relates to the actions where one or more accounts are converted by in so
doing this creates a group, which has both old currency and EUR accounts. Since the group is
suspended when this condition occurs and no sweeps are made until the group is re-activated the
conversion of the remaining accounts would need to be prioritised.
Selected group called SRP1, noted the currency was set to ‘old’ currency of CHF and was working.
Took one of the accounts used in the group as a conversion candidate and entered the account
conversion details.
This group has several accounts in and is in the old currency ‘CHF’. Checked on the accounts used in
the group and selected one for conversion.
After running the cob the [Link] record is checked and noted that it has been
flagged as being converted by using the field [Link] set as YES. Also, note the audit fields
reflect the update by the conversion process.
Note the field [Link] is flagged YES; this means the group is inactive until all accounts are
converted.
Until all the accounts in the SRP1 group are converted any updates to the sweep records is blocked
as shown above.
The previous CHF record is now on the history file of [Link] with the alternate account
number 941807
Return Sweeps
Certain sweeps are configured to make sweep during the cob and return the funds the next morning,
an example would perhaps be where all surplus funds on a current account are swept up to a savings
account each night to attract interest but the balance is returned the next morning to provide a working
balance.
In the example below we selected a cashpool group where the funds are returned each morning after
the sweep.
Checked the ENQUIRY [Link] on an account in the group, as it was before conversion to
show the sweeps were processed and returned.
The above screenshot shows the ‘old’ renumbered account. We can see evidence of the correct
working as follows:
Typical process
27 Aug 01 CHF 25,000 credited to account to give working balance
27 Aug 01 CHF 24,900 surplus swept to a/c 41912
28 Aug 01 CHF 24,900 returned
New account:
We can see from above that the following has correctly been processed:
Note the old sweep amount was CHF 24,900 / EUR 14,228.57 based on a maximum balance check of
CHF 100.00/; the converted record changed the check to EUR 57.14 which has been manually
amended to EUR 60.00 for simplicity.
We can see here that the group is now a EUR group and the audit details confirm the conversion.
Confirmation that the sweeps are now in EUR, are continuing to cycle and the [Link]
reflecting the changes made, note the amounts have been changed to rounded EUR amounts instead
of the system calculated equivalents.
The original [Link] record, saved using the renumbered account, is in history.
Testing Onsite
If testing onsite then be aware that the group field [Link] is set if one or most of the
accounts are converted. If all accounts are converted the cashpool records will be on hold and need
amending & authorising and the field will be empty.
The presence of the field makes the group inactive.
Before 31/12/1998
IT Preparation
The IT department will need to do the following in order to use the guidelines explained here.
1. Set up Local Reference fields on the [Link] file. Sample records for these have been
provided in the data library ‘[Link]’. The screenshots shown give instructions for
setting up these records (all instructions are for amending the [Link] field):
2. Link the local reference fields into the [Link] file layout using the
[Link] record. This has been illustrated in the screen shot shown below:
3. Set up the addresses for the local reference fields added in step 2 above into the
[Link] record. This has been illustrated with a screen shot shown below:
The back office will need to do the following in order to use the guidelines explained here.
1. Use [Link] in ‘TEST’ stage. This has been illustrated with a screen shot shown
below.
TEST of [Link]
TEST results
(Note that the user may use the sample routine [Link] for the purposes of generating the
new security master id. Refer to the helptext for [Link] for further details; this program has been
provided in the Data library ‘[Link]’).
2. Use [Link] in ‘PREPARE’ stage. This phase allows the user to populate NCU
security record’s local reference fields with the values specified in the corresponding fields on the
[Link] record. This has been illustrated in the screenshot below:
PREPARE phase
On authorising the above record the T24 system will return the following:
If the above is replied with an ‘OK’ the result will be that all the selected security master id records will
be changed and put on a hold status as shown below:
3. The above step 2 will result in the update of the selected security master records. An example of
this has been shown below:
4. The final step in this stage of events is to input and authorise the NCU securities put on hold as
shown above. This step would therefore have captured the required rules for re-denomination of
the security on the security master record itself setting a stage for further automation.
Starting 1/1/99
IT Preparation
In order to continue with the process of re-denomination the user will need to set up the [Link]
records that will be used by the process. (Note these records have been included in the data library
‘[Link]’).
[Link] record
[Link] record
[Link] record
[Link] record
[Link] record
[Link] record
[Link] record
[Link] record
Starting the 1st of Jan 1999 the new security master records for the security denominated in the EUR
currency can be set up. This has been entailed as below.
1. Creation of EUR security master records. In order to achieve this the user needs to input and
authorise the [Link] record with the process stage set to ‘CREATE’ this time.
This has been illustrated in the screenshot below.
CREATE phase
2. On authorisation of the above record the application [Link] would result in the
following security master records in IHLD status as shown below.
3. The user now needs to input and authorise each of the records created in the step above. This
may be achieved with the help of an [Link].
4. Once the NCU and EUR securities are in place, the user would be ready to now perform the
actual process of re-denomination.
5. In order to perform the re-denomination the user will need to perform a corporate action on the
NCU security as shown in the screen shot below. Note that using this version DIARY, EURO
(provided in the data library item [Link]) in combination with the set-up described
above, only the security number and the date of the event need to be input by the user. The
version initially defaults the value of [Link] into the EVENT field, but upon validation this
is replaced by the appropriate [Link] name for this security's re-denomination. This is
driven from the local reference fields on the [Link], when set-up as described
above.
6. On having authorised the DIARY record and selected the creation of the ENTITLEMENT
records on-line the user would need to authorise each of the ENTITLEMENT records.
7. Finally the user will need to perform a rebuild of the valuation records.
In T24 the facility to realise the profit/loss due is available on an individual contract basis, depending
on the type and use of contract.
[Link]
Fixed profit and loss categories should be specified for the [Link] of FX, [Link] and [Link].
The field [Link] on the FOREX application is used to denote whether or not the profit or
loss should be reported as realised when the deal involves two in-currencies. The date of this
realisation is recorded in the new [Link] field.
Each contract to be realised should be updated with a Y in this field. The selection of contracts to be
realised can be performed prior to the start of the transition period.
Realisation of FX contract
Realisation Process
The Close of Business revaluation process will perform the realisation of profit and loss for those
contracts flagged. Realisation will only take place when both currencies of the contract are fixed, and
the system is either the working day immediately prior to the [Link] or after this date.
If realisation is to take place, existing unrealised profit and loss is posted to the FIX P&L categories. If
the contract performs accruals (for [Link] SL, IN, IH, SF), the accruals are completed
for the life of the contract.
No further accrual or revaluation takes place for these contracts until maturity is reached.