Table of Contents

Document History..................................................................................................................... 3
Executive Summary.................................................................................................................. 4
Support..................................................................................................................................... 4
Application Overview - Existing Functionality............................................................................5
Account Conversion.............................................................................................................. 5
Conversion of Contracts, Deals and related information.......................................................5
Setting up the System............................................................................................................... 6
Assumptions.......................................................................................................................... 6
Fixing the Converting Currency against the Euro..................................................................7
Defining Base Currency Conversion.....................................................................................7
Account Conversion.............................................................................................................. 9
Multi-company..................................................................................................................... 11
Implementing Euro Conversions for T24 Modules..................................................................12
Implications and Impact on other modules..........................................................................12
Future proofing.................................................................................................................... 12
Account Conversion............................................................................................................ 13
Conversion of other data - Considerations..........................................................................15
Testing Considerations............................................................................................................ 17
Minimum coverage of testing............................................................................................... 17
Testing for different scenarios.............................................................................................. 17
Multi-Book........................................................................................................................... 17
Non-stop.............................................................................................................................. 17
Manual Adjustments............................................................................................................ 17
Backup Procedures............................................................................................................. 17

Alex Leggett| T24 Development

Document History
Author

Version

Date

Alex Leggett

1.0

07/12/2007

Comments:
{Add any comments here}

Alex Leggett| T24 Development

Executive Summary
The EURO module is designed to allow conversion from a National Currency Unit to the Euro.
It can also be used to re-denominate currencies to a new NCU.
The usual requirements are that the converting NCU is first fixed against the Euro, i.e. from a
set date, the exchange rate of that currency against the Euro is fixed in place and therefore
the NCU becomes in essence another way of expressing the Euro. The NCU is then said to
be in the transition phase. At the end of this phase, the NCU effectively ceases to exist.
Therefore, conversions of accounts and contracts (where amounts are held in the converting
NCU) should occur within this transition phase.
It is, of course, worth noting that this will not only affect companies where the base currency is
being converted, but also any company where any customer has accounts in the converting
currency or contracts where any aspect of those contracts (e.g. reference currency, delivery
currency, trading currency etc) is expressed in the converting currency.
This document covers the basic setup required in order to perform EU conversions, and the
issues to be considered when implementing and testing solutions to convert accounts or
contracts.
When designing an implementation, careful consideration will need to be given to the
particular circumstances concerning conversion of static data (e.g. accounts) and dynamic
data (e.g. contracts, deals). Conversion dates may be dictated by, for example, exchanges
on which instruments are traded, and these may vary by exchange or groupings of
instruments within the exchange. There are also considerations concerning choice of method
as per exchange recommendations. For example, should deals be matured or should they be
closed and rebooked?

Support
The EURO user guide, together with help text against the individual applications should
additionally be used in conjunction with this document.

Alex Leggett| T24 Development

Application Overview - Existing Functionality

It is worth noting that account conversion can be extended to cover other applications and
modules beyond those currently specified. However, the existing EU infrastructure only
covers specific deals to be converted, and for some modules, this is online via versions, and
for other modules, during the COB. The type of deal will dictate the approach taken when
implementing new solutions. The following two sections briefly summarise the EU
conversions in place at the time of production of this document.

Account Conversion
Accounts can be specified for conversion within AC.CCY.CONVERSION. This can be done
individually by creating records directly within the application, or as a bulk process via
EU.CCY.CONVERSION. The conversion of accounts occurs within the COB and renumbers
the account for the converting currency, creating a new Euro account with the same number
as the old account, and converting the amount held in the old account to a new Euro amount.
Thus, for example, account 12345, which held an amount in the old currency, holds the
equivalent amount in Euros after conversion, and a new account 92345 has been created in
the old currency. The new account is created so that dealing in the converting currency can
continue during the transition phase even though the principal accounts have been converted.

Conversion of Contracts, Deals and related

information
At present, the EU module caters for conversion of:
AM (Asset Management valuation and performance data)
DX (Derivatives)
LD (Loans and Deposits)
MM (Money Markets)
MG (Mortgages)
SC (Securities)
SW (Interest Rate Swaps)
LD, MG, MM and SW can be specified for conversion within EU.CONTRACT.CONVERSION,
either individually by creating records directly within the application, or as a bulk process via
EU.CCY.CONVERSION. The conversion is then performed using specific versions of the
applications holding the contracts, e.g. MM.MONEY.MARKET,EUCC,
LD.LOANS.AND.DEPOSITS,EUCC, MG.MORTGAGE,EUCC.
The Euro manual provides more information on the versions to be used.
The other modules each have different methods and applications for specifying conversion of
accounts. The infrastructure in the EU module for contract conversion as used by LD, MG,
MM and SW is not applicable to other modules, and therefore the EU.CCY.CONVERSION
application has no effect on them.

Alex Leggett| T24 Development

The Euro manual provides details on how conversion is to be performed within these other
modules.

Alex Leggett| T24 Development

Setting up the System

This section describes the changes to the system required to be able to perform account
conversion and conversion of the system base currency or local currencies (does not cover
setup for conversion of records in individual modules).

Assumptions
The following assumptions have been made:
1. The Euro has already been set up as a currency (including the base currency rank)
2. The holiday table for Europe has already been set up
3. Suspense categories, accounts and transaction for Euro conversion have already been
set up
The categories should be in the range 10000 to 19999 and should be set up as:
1. Euro Contract Conversion Suspense this should also have been defined as
the auto pay category within the Account Parameter file.
2. Euro Settlement Suspense
The accounts should be set up as:
1. Euro Contract Conversion Suspense Account (using category 1 defined
above)
2. A general Euro Suspense Account for each converting currency (using
category 2 defined above).
The transaction should be set up as Euro Conversion Adjustment
These records must be in place before continuing with EU Conversion set up and processing.
See the Euro user guide for more information.

Alex Leggett| T24 Development

Fixing the Converting Currency against the Euro

The converting currency must be fixed against the Euro within the CURRENCY application.

Figure 1 - setting the expiry date for the converting currency

Once set up correctly the converting currencies will be viewable in EU.FIXED.CURRENCY.

Defining Base Currency Conversion

If the currency being converted is also the system base currency, this should be set up in the
EU.PARAMETER record for each company that has that base currency.

Figure 2 - creating the EU.PARAMETER record

Alex Leggett| T24 Development

Note that the categories and transaction code referred to in the previous section will need to
be declared here.
Additionally, the LCCY.CONV.REC field within EU.PARAMETER needs to be completed as
shown below:

Figure 3 - completing the EU.PARAMETER record

The run date should be set for the ad hoc jobs in the following BATCH records (where XXX is
the financial mnemonic for the company in which the base currency is being converted). :
XXX/EU.BASE.CONV.CRB.RECALC
XXX/EU.BASE.CONV.REPORTING
XXX/EU.BASE.CONV.REPORTS2
XXX/EU.BASE.VERIFY
XXX/EU.BATCH.INTERRUPT
XXX/EU.PL.REALISED.REPORT
XXX/EU.POST.BASE.CONVERT
XXX/EU.PRE.BASE.CONVERT
XXX/EU.RUN.BASE.CONVERT

Alex Leggett| T24 Development

Account Conversion
Conversion of accounts is performed during the COB. This may be either after the EOD
processes, just before the reports processing, or at the beginning of the SOD processing.
The difference in these two approaches is in terms of reporting, and the approach taken will
depend on the strategy for conversion dates adopted by the Bank.
If converting during Start of Day processing, the contracts should all be converted on the
business day following that COB run (i.e. after the SOD that contains the conversion).
Therefore the accounts and contracts are all shown on the previous balance sheet as under
the old currency and on the next balance sheet as under the new currency.
If converted during End of Day processing, the contracts can be converted on any business
day(s) following the account conversion. Therefore the accounts and contracts are all shown
on the previous balance sheet as under the old currency, and on subsequent balance sheets
as having amounts shown in the new currency although contracts still traded under the old
currency (and will continue to do so until converted).
The field ACCT.CONV.TIME will need to be set accordingly in EU.PARAMETER.

Figure 4 - setting the time of the account conversion

The frequency of each job within the account conversion batch records should be set as
follows (where XXX is the financial mnemonic for the company) :

Batch Job

Acct Conv Time = EOD

Acct Conv Time = SOD

XXX/SOD.EU.ACCT.CONVERSION

Frequency = Adhoc

Frequency = Daily

XXX/EU.ACCT.CONVERSION

Frequency = Daily

Frequency = Adhoc

Table 1 - Frequency settings for all jobs within Account Conversion Batch records

Alex Leggett| T24 Development

 The accounts are specified for conversion within AC.CCY.CONVERSION either

individually (by creating records directly within the application), or as a bulk process via
EU.CCY.CONVERSION.

Figure 5 - bulk account conversion

Alex Leggett| T24 Development

Multi-company
If operating in a multi-company environment, the INTERCO.PARAMETER file will need to
point to both the current range of accounts and the new range of renumbered accounts of the
old converted currency. For example if converting in company EU0010001 in the example
below, the accounts starting with 3 are converted to Euro and renumbered accounts starting
with 9 provided in each case in the converted currency.

Figure 6 - defining the new range of renumbered accounts

The accounts thus selected will then be converted automatically during the next COB run (at
end of day or start of day as previously set).

Alex Leggett| T24 Development

Implementing Euro Conversions for T24

Modules
This section covers the issues to be considered when designing Euro conversions for
applications or whole modules within T24.

Implications and Impact on other modules

Initial consideration will need to be given to interfaces with other modules:
Has the Euro already been implemented in the other module?
Are there shared files between the modules? Do any of the proposed changes come
under the scope of the other module?
Can Euro conversion be run independently within this module?
Should this module be converted before, after or at the same time as the other?
What impact will the conversion being planned for this module have on the other?
While looking at this other module, are there similar business cases within this module that
suggest similar approaches to EU conversion?

Future proofing
It will also be worth considering whether future planned developments within the module will
need conversion i.e. will any planned work include references to accounts or currencies?
Clearly, it will be worth bearing in mind impact on EU conversion whenever designing any new
changes to the module.

Alex Leggett| T24 Development

Account Conversion
Conversion of accounts is the relatively easy part of the whole design process. Essentially,
the system is provided with a list of applications, against which are given all field names
holding account numbers. The EU infrastructure will then convert accounts and process all
records in each file changing any account numbers requested by the user (as described in the
Setup section earlier).
When processing, the old account will be copied to a new account number and then the
original account converted to the new currency. Applications listed are converted with respect
to their account numbers.
For example, account 39522 (acme DEM account) would be converted to become 99522
(acme DEM account) and 39522 acme EUR account). Additionally, any applications set to
change the account number will now reference the 99522 account rather than the 39522
account, so that they still reference DEM rather than EUR. Any applications not listed (such
as files which reference the principal trading account or similar) will now point to the EUR
account.
Transactional files will need to continue to refer to the converting currency after account
conversion. The account numbers for the converting currency will have changed during
the account conversion, therefore the account fields in these files will need to be
converted.
Standing data files, such as those holding margin accounts or similar will need to refer to
the new currency after account conversion. The account numbers for the new currency
after conversion will be the same as the converting currency was before conversion,
therefore the account fields in these fields will not need to be converted.
The application EU.CONVERSION.PARAM is used to define the files to be converted in this
way. One record contains all fields to be converted for one application. The following should
be noted:
The key to the record should be application_name.ACCOUNT.
CONVERSION.TYPE should be set to Application.
FILE.NAME should be set to the name of the file being converted.
SELECTION should be set to @EU.ACCT.FILE.SELECT.
STD.CONV.TYPE for each field should be set to ACCOUNT.D
See the help text and the Euro manual for further information on this.
Each record defined here needs to be added into the EU.CONVERSION.PROCESS
AC.FILES.CONVERT record.

Alex Leggett| T24 Development

Figure 7 Defining the ACCOUNT fields to be converted

Figure 8 Adding the application to EU.CONVERSION.PROCESS

Alex Leggett| T24 Development

Conversion of other data - Considerations

IMPORTANT NOTE: Only the EU Account conversion can be extended to cover new
applications.
While it may appear that this functionality might cover definition of other
conversions besides Account conversion, the rest of the functionality
cannot be extended to cover other modules just by creating the records.
Conversion of data other than account numbers must be performed
programmatically, either during COB or online (this is usually performed
via appropriate VERSION records with attached routines).

Firstly, consideration will need to be given to the business cases which will apply when an incurrency (currency converting to EUR) or re-denominating currency is converted. It may be
that some of the deals or positions cannot be automatically converted by their nature and will
have to be manually matured, closed, sold or bought out, expired, exercised etc. Similarly,
standing data such as instrument definitions may need to be set as untradable after a specific
date and new instruments created in their stead. Such actions may need to be done
manually for valid business reasons, and therefore not require an enhancement to do so.
However, this being said, there will always be the issue of potential deals or standing data
being left in place after the currency has been blocked or the accounts have been converted,
thereby potentially causing problems dealing with these positions or reversing out/amending
the standing data.
Some particular issues which need thinking about are:
Instrument Definitions & Deals
How should orders or forward agreements be handled?
If the instruments are exchange-traded, what conditions might be dictated by the
exchanges and might they differ? Conditions put on conversion might be in terms of:
-

The date of conversion.

Whether the instrument simply changes its currency overnight or ceases trading.

Whether the instrument is to be replaced by another similar instrument, and if so, when
that becomes available.

Conditions under which the position can be traded out of in order to enter a similar
position in the new currency.

If OTC deals (by agreement between the two parties), similar conditions may be dictated.
Additionally, will the system need to stop new positions being created against the
instruments after a certain date? Will this allow trading out of those positions?
Are there some deals that will need to stay in place until after the official conversion date,
due to legal requirements?
Some instruments cannot be converted until maturity how will these be handled?
Finally, how should valuation, back-valuation, performance, positional, or other data (for
instance, dividends) be handled by the system?

Alex Leggett| T24 Development

 Single vs. Multiple Customers

Some deals concern a single customer; others concern multiple customers, either as
counterparties to each other or as partners in the same position/beneficiaries. This may
affect design of the conversion processing.
Online vs. Offline
Some of the conversions on the system may need to be transparent to the user, for
example, fields holding the local currency. These are best converted offline during COB
processing. Additionally, some deals may be more efficiently converted offline during the
COB, even if as a back-stop in case the processing has not been completed online by the
conversion date.
Other conversions, due to their complexity may need to be done online using versions or
via enquiries for the user to select deals requiring conversion and process them
accordingly. For instance, in the LD module, commitments are converted manually using
versions in several steps requiring user intervention, as the types of commitment and
draw-downs against them vary widely and cannot be easily automated to cover all possible
scenarios.
Finally, if processing offline (during COB), if the processing needs to run on more than one
particular day, what is its impact on the COB time/efficiency if it is running daily during the
transition phase?
Multi-Book
What impact will shared files (such as the Customer file) have on the design of the
conversion processing?
Non-Stop
The non-stop module allows for input of data during COB processing. How will this affect
the Euro conversion? Can this continue even if EU processing is taking place (either for
account conversion or for any other records) or should it be suspended while this is taking
place?
Manual Adjustments
After the conversion has been run, how are any adjustments to be made?

Alex Leggett| T24 Development

Testing Considerations
Minimum coverage of testing
Test plans must cover at the very least the conversion of existing deals, both via online and
offline processing (as applicable).
Additionally, special care must be given to circumstances surrounding the nature of the deals,
for instance, cases where the deal may need to remain in place until after the conversion.
Testing should cover final maturity of the deal as well.
The test plan must naturally also cover the accounting expected on conversion of deals and
accounts as well as blocking of future deals/conversion of static data as appropriate.

Testing for different scenarios

Multiple scenarios will occur in the usage of T24 Euro conversion in banks across the world,
and therefore this must be taken into account in the test plan. Consideration should be given
to the following factors:
Timing of account conversion relative to deal conversion
Conversion of more than one in-currency
Different conversion dates for different exchanges

Multi-Book
Is there a shared customer file? What other files are shared, and does this affect the
conversion?

Non-stop
If the Non-Stop product is installed, how does the module handle deal/instrument definition
input before, during and after account conversion, base currency conversion and/or deal
conversion?

Manual Adjustments
How are adjustments to the figures to be made post-conversion, in the case of rounding
errors etc?

Backup Procedures
Test plan should include strategy for account backups e.g. before running conversion, at
batch-halt etc.

Alex Leggett| T24 Development