EU Savings Directive - User Guide: Release R15.000

EU Savings Directive - User Guide
Release R15.000
June 2015
©2015 Temenos Headquarters SA - all rights reserved.
Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may
result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Overview 4
Directive scope 4
Affected countries 4
Installation Overview 5
Installation instructions 5
Architecture / Design 6
Configuration 7
Customer based parameters 8
EU Tax Param 13
Appendix 16
Appendix 1 – Local Reference Set-up 16
Appendix 2 – Version Routines 31
Services 32
Online Services 32
Close of Business Processing 33
SC.EU.PAST 33
Security based parameters 35
Tax Engine 45
EU Tax Base 96
Deal Processing 104
Transaction Input 105
Resetting of Interest Counter after Distribution 115
Holding Period Interest for Mutual Funds 116
Recording of NAV 130
Tax on Interest earned on Debt Instruments 133
Taxation of Premium and Discount 133
EU Savings Directive - User Guide - Release R15.000 - Page 2 of 143

Introduction
Purpose of this Guide

This document details how EU Savings Directive module is integrated with T24 Wealth Management. It details the installation, configuration,
the services involved and the workflow of how EU taxation on savings income is applied in T24
Intended Audience
This User Guide is intended for the use of Internal Temenos users and Clients.

Overview
The EU COUNCIL DIRECTIVE 2003/48/EC dated 3rd June 2003 on taxation of savings income in the form of interest
payments (known as the EU Savings Directive) comes into force on 1st July 2005. Its stated aim:
“The ultimate aim of the Directive is to enable savings income in the form of interest payments made in one Member State to beneficial
owners who are individuals resident for tax purposes in another Member State to be made subject to effective taxation in accordance with
the laws of the latter Member State.”
The EU taxation on savings income is the introduction of a system of tax retention initially of 15%, rising to 20% and then of 35% from 2011.
The system of tax retention applies to all interest payments which a paying agent makes to an individual resident for tax purposes in an EU
Member State. It also allows for foreign bank customers themselves to be able to choose between a system of tax retention and a declaration to
the tax authorities (voluntary declaration).
The directive includes detailed descriptions regarding to whom this applies and where, as well as exceptions and special cases.
Directive scope
All banks resident within the European Union or in countries intending to comply with the directive (i.e. Switzerland and other off-shore bank-
ing centres) will be obliged to report the interest earned on all debt instruments and certain specified funds that fall within the scope of the dir-
ective or to calculate retention tax on such instruments held by EU citizens who are resident in another member state according to new rules
as stated in the directive.
In all cases the new calculation rules must be used to calculate the amount of taxable income which should then be either reported to the cli-
ent’s home country or in the case of certain countries used to deduct retention tax. Where retention tax is deducted this will then be split
between the countries of residence of the bank and the beneficial owner.
It is important to note that these new rules only apply where the residency of the bank and the client differ. All existing retention tax rules for
dealing with residents of the same country as the bank remain in force and are unaffected by this directive.
Affected countries
The EU Savings Directive will have an impact for the following countries:
l All member states of The European Union (including new joiners)

l Austria, Belgium and Luxembourg will be allowed to charge Withholding Tax; all other EU countries will report tax earnings.
l Andorra
l Cayman Islands
l Caribbean Territories
l Gibraltar
l Guernsey
l Isle of Man
l Jersey
l Liechtenstein
l Monaco
l Netherlands Antilles
l Switzerland

Installation Overview
Installation instructions
The pre-requisite release for the EU Savings Directive is G13.2.
The initial installation sequence is as follows:
1. Install the latest appropriate Service Pack and any subsequent patches.
2. Add the ET (European Tax) and TX (Tax Engine) products to the SPF, together with the required license codes.
3. Add the ET and TX product codes to the required COMPANY records.
4. Run GLOBUS.RELEASE to install the TX module
5. Run GLOBUS.RELEASE to install the ET module
6. Authorise the following released records:
l STANDARD.SELECTION
l BATCH
l TSA.WORKLOAD.PROFILE (for users of G14.0 and above)
l TSA.SERVICE (for users of G14.0 and above)
Note: Released TX.TXN.BASE.PARMS and TX.TXN.BASE.MAPPING records are examples only, and should only be authorised after
ensuring that the structure of the base is satisfactory. More details on these parameters can be found below.
7. For T24 users prior to R07, the required EU Savings Directive fields must be set-up via local reference. See Appendix 1 for full instruc-
tions. From R07 onwards these fields become core fields.

Architecture / Design
(c) Temenos Systems 2015

Configuration
The following sections detail the configuration for EU Savings.
l Customer based parameters

l EU Tax Param
l Appendix

Customer based parameters
Customer
The recording of the effective date for ‘in-scope’ customers is mandatory. ‘In-scope’ customers need to be further classified as those who will be
subject to retention tax and those who will only be reporting (“info” customers). The classification of customers can be based on any of the
existing core or local reference fields in customer or a new local reference field to be created for this purpose.
Ensure the fields created for customer grouping are populated for existing customers before the initial base is built. This can be done either
manually or through local routines. When new customers are created, ensure these details are populated for ‘in-scope’ customers. Version level
checks can be put in place for this.
Condition Priority
CONDITION.PRIORITY is used to detail which factors are to be used in the calculation of customer groups.
The CONDITION.PRIORITY record for tax needs to be amended if the bank requires the adding of new conditions on which the grouping of
customers will be based. If the existing grouping conditions are sufficient then no amendment will be required.
For users on release R05 and above, the CONDITION.PRIORITY record can be updated directly. For users on earlier releases the
EU.SAVING.COND.PRIORITY.TAX application should be run with the Verify function to add the required field(s).
Typically, a combination of the RESIDENCE field and EU.STATUS local reference (used to record the customer’s status with regard to EU
retention tax – WHT, INFO, EXEMPT) is used to define the customer groups and route tax postings to separate accounts per EU member
state. The two fields would therefore need to be added to the CONDITION.PRIORITY appropriate TAX record.
Tax Type
There are three fields on the TAX.TYPE file relating to the EU Savings Directive:
EFFECTIVE.DATE – This will hold the effective date from which Tax is applicable. During testing an appropriate back-date may be set-up.
LOCAL.TAX.PARAM – This will need the special parameter file configured for this tax. In this case it is ‘EU.TAX.PARAM”. The name of this
file cannot be changed and is hard-coded in the system. If any value other than ‘EU.TAX.PARAM’ is set-up EU tax will not be calculated.
CUST.CHK.RTN – This field will contain the routine which will return whether the Customer is liable for this tax or not. The routine
SC.EU.SCOPE.CHECK is provided as part of the ET module.
A TAX.TYPE record for the EU Savings Directive should be set-up as follows:
TAX.TYPE record for EUTAX

Tax Gen Condition
The TAX.GEN.CONDITION application is used to define the customer groups for each type of tax. The groups are defined using the factors lis-
ted on the appropriate TAX CONDITION.PRIORITY record. A record will need to be input for each customer group for EU Retention Tax.
The CUSTOMER.CHARGE record for each customer will confirm which group is being applied for a specific customer. N.B. this file is updated
as part of the close-of-business unless specifically adjusted for a particular customer.
Tax
The tax records define the specific characteristics of the tax itself, including the rate, category and transaction codes.
For EU Savings the BASE.AMT.ROUTINE field must be populated with SC.EU.CALC.TAX.
Example TAX record
Tax Type Condition

The TAX.TYPE.CONDITION record establishes which TAX record is to be used for the customer groups for this specific type of tax.
EU Tax Split among Joint Holders of a Portfolio

When there are joint holders in a Portfolio, the EU Tax will be split between the holders in the ratio of their holdings.
To achieve this, in the CUSTOMER.RELATIONSHIP application, the Joint relationships are specified and the field Relation Type is set
to TAX.

Customer Relationship
The CUSTOMER.RELATIONSHIP record is then linked to portfolio using the CUS.RELATIONSHIP field in SEC.ACC.MASTER .
The CUSTOMER.RELATIONSHIP record will have the effective date as part of the ID so that the underlying application can do the tax pro-
cessing considering the latest record and also to ensure that the existing record is not changed even if there were any amendments in the cus-
tomer relationship record. The amendments are done through a new CUSTOMER.RELATIONSHIP record so that the historical information
are retained in the system.
System splits the EU Taxes in the ratio of holdings specified in the CUSTOMER.RELATIONSHIP record.
Sample screen shot of CUS.RELATIONSHIP id linked to the SEC.ACC.MASTERrecord, to determine the joint holders of a portfolio and
the percentage of holding.

SEC.ACC.MASTER

EU Tax Param
The EU.TAX.PARAM file is used for company level settings in relation to EU Retention Tax. If identical settings are to be used across a multi-
company environment an ID of SYSTEM can be used, instead of inputting a record for every company.
Example EU.TAX.PARAM record
The fields are used as follows:
l TAX.OPTION---Field to define the Company level setting on the levy of EU tax or exchange of information. Allowed values are WHT or
INFO
l SC.HOLD.PERIOD—allowed values are ‘BUY.DATE’, ‘EU.DATE’, or ‘STATUS.DATE’. N.B. This is a no change field once the trans-
action base has been built.
l TAX.BASIS—FIFO/LIFO/AVERAGE - Defines the Method used to build the base amount for Tax calculation.This is a no change field
once the transaction base has been built.
l CU.EFF.DATE.FLD—The local reference field which holds the effective date for the customer in CUSTOMER record.
l SM.EFF.DATE.FLD—The local reference field which holds the effective date for the security in SECURITY.MASTER record.
l CU.TAX.GRP—The Customer group based on the revised Condition priority which will come under EU tax. For these customers WHT
will be deducted. Customers falling under this group will have the EU.TXN.BASE updated to facilitate generation of reports. Tax cal-
culated will also be updated in the base.
l TAX.UPD.MODE—Whether tax needs to be updated ‘online’ or during ‘batch’. Currently only online mode is supported.

l CU.INFO.GRP—The customer group based on the revised Condition Priority which will come under exchange of Information. These
are customers who have opted to report instead of having tax withheld. This will override the default setting in the TAX.OPTION field.
Customers falling under this group will have the EU.TXN.BASE updated to facilitate generation of reports. However, no tax will be cal-
culated and only allocation details of each buy against a specific sale will be updated in the base.
l INFO.UPD.MODE—Whether EU.TXN.BASE needs to be updated on-line or in batch for info customers. Currently updates in batch
mode only are supported.
l CU.EXEMPT.GROUP—The customer group which is exempt from EU tax. No update will take place in EU.TXN.BASE for this group.
l UPDATE.LOG – Yes/No field to set if a log needs to be maintained for the sequence of updates to a specific holding. The log can be
viewed in the EU.UPDATE.LOG file.
l TOTAL.DISC.PREM - Holds the Threshold percentage below which no Tax needs to be deducted for Interest earned on Debt Instru-
ments.
l PERIOD.DISC.PREM - Holds the threshold Discount or Premium percentage per Period below which no Tax needs to be deducted for
Interest earned on Debt Instruments.
Note: If different countries, have different exemption percentages, then the EU.TAX.PARAM record must be set Company wise
with respective values.
l INC.SOURCE.TAX - To determine if Source tax already deducted on Interest needs to be included or excluded for tax calculation.
The EU.PURGE.DATE field on the EU.TAX.PARAM file provides the user with the ability to purge transactions from the EU.TAX.LINK file
and move them to the EU.TAX.LINK.PAST file.
All transactions prior to the purge date that have an Available Nominal of zero are purged and moved during the course of the next COB run.
EU.TAX.PARAM showing EU.PURGE.DATE

EU.TAX.LINK record showing EU.PURGE.DATE
EU.TAX.LINK.PAST record showing EU.PURGE.DATE

Appendix
Appendix 1 – Local Reference Set-up
Local Table
The following LOCAL.TABLE records are mandatory:
SC.TAX.CODE
TAX.BASIS

ISSUE.PRICE
REDEM.PRICE
INT.CTR

INT.CTR.DATE
ORIGINAL.YIELD
SEC.EFF.DATE

CU.EFF.DATE
CU.TAX.CODE
CU.TAX.TYPE

CU.TAX.TCY
CU.TAX.LCY
CU.PORTFOLIO

TRFR.EFF.DATE
SC.TAX.TYPE
INT.DIST.FACTOR

SC.AMT.ACY
SC.AMT.LCY
EU.SEC.ACCT

EU.SECURITY.NO
INT.RATE
The following LOCAL.TABLE records are optional:

EU.STATUS
EU.EXEMPT.DATE
Local Ref Table

The LOCAL.TABLE records should be linked to the applications, by adding them to the LOCAL.REF.TABLE records, as shown below.

CUSTOMER
SECURITY.MASTER

SEC.TRADE
SECURITY.TRANSFER

POSITION.TRANSFER
DIARY

ENTITLEMENT
SUB.ASSET.TYPE
SC.EXE.SEC.ORDERS

Recording of NAV net of charges in EU.TXN.BASE
LOCAL.TABLE:
NAV.TYPE
CU.NAV.TYPE
LOCAL.REF.TABLE:

SEC.TRADE
SECURITY.TRANSFER
SC.PARAMETER

Appendix 2 – Version Routines
The following version routines are available for use as required.
SUB.ASSET.TYPE
l V.SC.EU.TAXBASIS.CHECK - Input routine – Change allowed only if there is no EU.TAX.LINK record.
SECURITY.MASTER
l V.SC.EU.TAXBASIS.CHECK - Input routine – Change allowed only if there is no EU.TAX.LINK record.

l V.SC.EU.ORIGYIELD.CHECK – Input routine – Routine to calculate and populate yield.
l V.SC.EU.PRICE.CHECK – Validation routine for ISSUE.PRICE and/or REDEEM.PRICE - Input only allowed for Bonds.
l V.SC.EU.PRICE.CHECK – Input routine – If EU retention tax is included in SC.TAX.CODE then ISSUE.PRICE is mandatory.
l V.SC.EU.INTCTR.CHECK – Validation routine for INT.CTR – Input allowed only for shares.
SEC.OPEN.ORDER
l V.SC.EU.INTCTR.CHECK – Validation routine for CU.INT.CTR – Input allowed only for shares, and defaulted from
SECURITY.MASTER.
SC.EXE.SEC.ORDERS
SECURITY.MASTER.
SEC.TRADE
SECURITY.MASTER.
SECURITY.TRANSFER
SECURITY.MASTER.
l V.SC.EU.TRFRDATE.CHECK – Validation routine for TRFR.EFF.DATE – Should not be a future date
POSITION.TRANSFER
l V.SC.EU.INTCTR.CHECK – Validation routine for INT.CTR – Input allowed only for shares.
l V.SC.EU.TRFRDATE.CHECK – Validation routine for TRFR.EFF.DATE – Should not be a future date
DIARY
l V.SC.EU.INTCTR.CHECK - Validation routine for INT.CTR – Input allowed only for shares, and defaulted from SECURITY.MASTER.
l V.SC.EU.INTDIST.CHECK - Validation routine for INT.DIST.FACTOR – Input allowed only for shares.
ENTITLEMENT
l V.SC.EU.INTCTR.CHECK - Validation routine for INT.CTR – Input allowed only for shares, and defaulted from SECURITY.MASTER.
l V.SC.EU.INTDIST.CHECK - Validation routine for INT.DIST.FACTOR – Input allowed only for shares.

Services
Online Services
Initial Data Build

It is vitally important that the set-up for all customers and securities ‘in scope’ as well as the EU.TXN.BASE definitions and mapping is com-
plete prior to initiating the data build.
The EU.DATA. BUILD application is used for the build of data into the EU tax transaction database. This can be run for a specific customer,
portfolio, security or for ALL. It is also possible to define specific start and end dates for transactions to be included in the build.
The build will take place either as part of the close-of-business, or can be run via TSA.SERVICE.MANAGER for users on release G14.0 or
above.
Prior to building the base, it must be ensured that the Interest counter (in case of funds) and TRFR.EFF.DATE (in case of security Trans-
fers/Position transfers) are updated in the underlying transactions. This will ensure that these details are included in the base built for sub-
sequent transactions. If not, the base (EU.TXN.BASE) then needs to be subsequently amended to include these values. Position Transfers
cannot be amended subsequent to authorisation. So if, TRFR.EFF.DATE needs to be updated in existing transfers, the same can be done only
through a local routine.
If Interest counter information is not available in historic transactions, this will be considered to be zero and if TRFR.EFF.DATE is not avail-
able, then the Trade date will be considered the TRFR.EFF.DATE.
There is no specific information relating to Services for this product

Close of Business Processing
SC.EU.PAST
A batch job, SC.EU.PAST will be attached to the ET.END.OF.DAY process, which will examine a work file (SC.EU.PAST.WORK) as the basis
for processing.
The flow is illustrated below:
After the above process a POST job will clear the work file.
If the EU.TAX.PARAM purge date is amended a check is made before writing the date to the work file.

BATCH record ET.END.OF.DAY showing jobs to be processed

Security based parameters
Sub Asset Type

The TAX.BASIS field defines the LIFO/FIFO method for securities within this sub asset type that do not have the setting defined on the
SECURITY . MASTER. If there is also no setting on SUB. ASSET . TYPE then the default designation from the TAX.BASIS field on the
EU.TAX.PARAM will be used.
Example SUB.ASSET.TYPE record
Security Master
There are eight fields on the SECURITY. MASTER which are required for EU Savings. For back patch versions of the module they will need to
be set-up as local fields as described in Appendix 1.
l SEC.EFF.DATE gives the date on which the security comes into scope. It is mandatory for all securities in scope, and should be input
prior to the initial base build for all securities that will be in scope on 1st July 2005.
l SC.TAX.CODE points to the TXN.TAX.CODE ID. This should be input prior to the initial base build for all securities that will be in
scope on 1st July 2005.
l TAX.BASIS - This can be modified at Security level and will override the settings in EU.TAX.PARAM.
l ISSUE.PRICE, REDEM.PRICE, INT.CTR, INT.CTR.COUNTRY, INT.CTR.DATE are used in processing the base amount and need to
be manually updated for Bonds and Shares (Units of funds) as the case may be. The INT.CTR and INT.CTR.COUNTRY are associated
Multi-value fields to set different Counters for different countries. If ISSUE.PRICE and/or REDEM.PRICE are not populated they will
be assumed to be at par.
l ORIGINAL.YIELD is a system generated field which updates the yield for Bonds based on Issue price and Redemption Price for the
period between Issue date and Maturity date.

EU Savings fields on the SECURITY.MASTER
Txn Tax Code

TXN.TAX.CODE is the application which determines Security based tax. The tax set-up at the security level is further filtered at the Customer
level (for each portfolio) based on settings in TAX.TYPE and related Core files.
l TXN.APPLIC is the application in which the transaction is input. Valid applications are SEC.TRADE, SECURITY.TRANSFER or any
DIARY.TYPE.
l TRANS.TYPE specifies the transaction types for which Tax is applicable. It accepts ALL.DEBIT for cases where all debits (sales) are to
be taxed.
l BONDS.TAX and SHARES.TAX specify the TAX.TYPE.CONDITION that needs to be applied for Tax linkages. An “*” is needed to dif-
ferentiate between linkage to TAX. TYPE. CONDITION and a direct linkage to the appropriate TAX record. No direct linkage to the
TAX record is possible for EU Retention Tax and all linkages should take the route of TAX.TYPE.CONDITION. The SHARE.TAX field
should be used for funds set-up as shares.
l BD.AMT.BASE and SH.AMT.BASE specify the characteristics of the base. The following are the allowed values:
HPI-Holding Period Interest
DL-Discount Linear
DC-Discount compound
RP-Redemption Premium
ID-Interest Distribution
IC-Interest Counter
CG-Capital Gains
Ensure that conflicting base amount components are not defined - for example, if DL is defined, DC and RP should not be defined and vice
versa. Similarly, either CG or IC can be defined for funds but not both. For coupons, only HPI should be defined. For redemptions, only DL,
DC or RP should be defined and for Distributions, only ID or HPI should be defined.

l AMT.BASE is not relevant for EU Retention Tax.
l TAX.CUST reflects if the tax is applied on ‘Customer’ rather than on Broker, Counterparty or Depository
l TAX.PARAM.FILE is a system updated field to define if the tax is indeed an EU tax. The value ‘EU.TAX.PARAM’ will specify to the sys-
tem that this is indeed an EU tax. This is defaulted from TAX.TYPE.
Note: The tax type for all applications in one record should be similar (i.e. related to EU TAX PARAM and have the same effective date
and customer grouping conditions).
TXN.TAX.CODE - Coupon Paying Bond redeemed at par

TXN.TAX.CODE - Coupon Paying Bond redeemed at premium

TXN.TAX.CODE Discounted Bonds - Linear Basis

TXN.TAX.CODE - Discounted Bonds - Compounding Basis
TXN.TAX.CODE - Coupon Paying Discount Bond redeemed at par

TXN.TAX.CODE - Funds - Sale/Redemption Interest Counter

TXN.TAX.CODE - Funds - Interest Distribution and Sale Interest Counter

TXN.TAX.CODE - Funds - Sale/Redemption Capital Gain

TXN.TAX.CODE - Funds - Interest Distribution and Sale Capital Gai

Tax Engine
For a detailed understanding of Tax Engine flow, please refer to the User guide for Tax Engine.
Tx Txn Base Parms

This application defines the required fields for the tax transaction database, in this case EU.TXN.BASE.
TX Set up for EU.TXN.BASE:
TX.TXN.BASE.PARMS part 1










N.B. it is important that the REV.ACTION field is set to DELETE and the MAINT.HIST field is set to YES, to record a full history of the
EU.TXN.BASE whilst maintaining its clarity for reporting purposes.
Tx Txn Base Mapping

TX.TXN.BASE.MAPPING gives the field mapping of data from different applications to the base defined in TX.TXN.BASE.PARMS.

TX.TXN.BASE.MAPPING
TX.TXN.BASE.MAPPING for ENTITLEMENT part 1









TX.TXN.BASE.MAPPING for POSITION.TRANSFER part 1

TX.TXN.BASE.MAPPING for POSITION.TRANMSFER part 2








TX.TXN.BASE.MAPPING for SEC.TRADE part 1









TX.TXN.BASE.MAPPING for SECURITY.TRANSFER part 1









TX.CONDITION
TX.CONDITION for ENTITLEMENT

TX.CONDITION for POSITION.TRANSFER

TX.CONDITION for SEC.TRADE

TX.CONDITION for SECURITY.TRANSFER

EU Tax Base
The EU Tax Base consists of three files, which can be used for look-up purposes, but are non-input. For reporting customers, these files are
only updated as part of the close-of-business.
EU Tax Link
EU.TAX.LINK maintains the FIFO/LIFO sequence of transactions for a particular holding.
Example EU.TAX.LINK record
The ACTUAL.NOM field gives the Transaction nominal and the AVAIL.NOM field gives the available nominal for each buy after a sell trans-
action has been allocated against this buy. LATEST.TXN (for LIFO) and EARLIEST.TXN (for FIFO) are the pointers used by the system to
start LIFO/FIFO allocations.
In the above example, there are two buy deals on April 1 and 4 respectively and a sell deal on April 6. The sell of 1.4 Million has been allocated
against a) the buy of 1 million on April 4 and the balance of 400 thousand allocated against the buy of 1 million on April 1, based on LIFO
basis. The LATEST.TXN has been updated with the buy on April 1, indicating that when the next Sell happens, this will be the first allocation.
EU Txn Base
EU.TXN.BASE contains all the basic details of the transaction, as defined through the TX.TXN.BASE.PARMS. This file can not be accessed dir-
ectly, so a suitable enquiry should be developed if necessary.

EU Allocation Dets
EU.ALLOCATION. DETS is updated when a sale transaction is input for a customer and security that is ‘in scope’. The record gives details of
purchase transactions that have been allocated to this particular sale, the nominal that has been allocated out of each purchase, the base
amount for tax and tax calculated.
Taking the above EU.TAX.LINK example, here are the related EU.ALLOCATION.DETS records.
Allocation of a buy deal on April 1st, against a sell deal on April 6th:
EU.ALLOCATION.DETS
Allocation of buy deal on April 4th against sell deal on April 6th

EU.ALLOCATION.DETS
Cross-reference for allocation of various sell deals against buy deals:
EU.ALLOCATION.DETS

Amendments and Rework
Back dated transactions, reversals and deletions of existing transactions could have an impact on the tax calculated for subsequent sale trades.
The reworking of taxes becomes necessary under such circumstances.
The REWORK.FLAG field on the EU.TXN.BASE file for each trade that needs to be reworked is set to “YES”, and the FIRST.REWORK.TXN
field will hold the ID of the first Sell trade which needs to be reworked. All subsequent sell trades will need to be reworked in sequence.
Rework of a transaction is done by simply opening the deal, re- entering the CUST.PRICE and adding comments in CU.NOTES
(CU.NARRATIVE in cases of release G13.2), committing it and authorising it again. This will rework the Tax amount and pass the necessary
adjustment entries.
Worked Example:
EU.TXN.BASE prior to amendment
Two sales have already taken place and they have been allocated and tax computed. Now a back dated purchase is input for this portfolio (pur-
chase of 200,000, trade dated 1st March).

EU.TXN.BASE after back-dated transaction
As seen above, all the earlier allocations have been removed (AVAIL.NOM has been reset for all purchases) and the Rework flag has been set for
both the sales. The FIRST.REWORK.TXN has been populated and LATEST.TXN details have been updated.
The transactions with the REWORK.FLAG set need to be reworked. This is done by reopening the deals and re-entering the CUST.PRICE field
to trigger the recalculation of the tax, and adding comments to the CU.NOTES field.
If more than one trade has been flagged for rework (as is the case here), the transactions have to be reworked in the same order in which they
appear in the base.
Once the rework is done, EU.TAX.LINK and EU.ALLOCATION.DETS will reflect the amended allocations.

EU.TXN.BASE after reworking the affected transactions
POSITION.TRANSFER and ENTITLEMENT
Updates are not allowed to POSITION.TRANSFER and ENTITLEMENT once they have been authorised. Therefore, in the event that a back-
dated transaction or reversal results in the rework of a POSITION.TRANSFER (PTO) or ENTITLEMENT (stock movement events), the rework
flag is not set. In this instance they are automatically allocated by the system.
In the case of POSITION.TRANSFER there is no tax calculation involved, whereas for an ENTITLEMENT (e.g. Redemption) there may be
related tax. In this instance, the incremental tax is posted to the INCREMENTAL.TAX fields in EU.ALLOCATION.DETS.
Example: -
EU.TAX.LINK record before amendment: -

EU.TAX.LINK
Input a backdated purchase transaction prior to the Position Transfer (purchase of 200,000, trade dated 7th May).

EU.TAX.LINK
As seen above, the POSITION.TRANSFER is automatically allocated. The rework flag is set for the sale transaction only.

Deal Processing
The following section details the trade process for EU Savings Directive.
l Transaction Input
l Resetting of Interest Counter after Distribution
l Holding Period Interest for Mutual Funds
l Recording of NAV
l Tax on Interest earned on Debt Instruments

Transaction Input
Sec Trade
The tax calculation in SEC .TRADE is triggered on entry of CUST.PRICE; when enteredin a SEC. TRADE (sale trade) involving customers and
securities in scope of the Directive. The tax is calculated and the details regarding Tax code, tax amount in Trade Currency and tax amount in
local currency are populated in the fields in SEC.TRADE, namely CU.TAX.CODE, CU.TAX.TCY and CU.TAX.LCY.
Tax recorded on SEC.TRADE
In the course of transaction input, if there are any changes to the transaction details like Customer, Security, Trade Date, Value date or Nom-
inal, the tax calculation has to be triggered again by re-entry in the CUST.PRICE field.
While entering a trade involving funds (where the base amount option is set to ‘IC’), the Interest Counter needs to be entered prior to entry of
CUST.PRICE. This is because when the option is set to ‘IC’, the base amount is the lesser of capital or Interest Counter gain. As a result, the
Interest Counter needs to be input prior to input of CUST.PRICE for the system to calculate the correct tax.
The field CU.MANTAXTCY enables a Manual Tax to be applied to a SEC.TRADE transaction. When a manual tax is input, accounting entries
are raised based upon this value and not the system calculated tax. The total in the NET.AMOUNT field on the transaction has only the
Manual Tax amount deducted.
Both the system calculated tax and Manual Tax are recorded on the transaction, EU.ALLOCATION.DETS and EU.TXN.BASE.
Manual Tax recorded on SEC.TRADE
Security Transfer
If TXN.TAX. CODE has been set to compute tax on specific transfers while using the SECURITY.TRANSFER application, the tax will be com-
puted here.

TXN.TAX.CODE for SECURITY.TRANSFER TRO
The above TXN.TAX.CODE is set to compute on Security Transfers involving transaction code TRO.
When a transfer with this transaction code is input, the tax calculation will be triggered on entry of either PRICE or COST:
Tax recorded on SECURITY.TRANSFER
If the acquisition date of the security is not the same as the Transfer date, the acquisition date should be entered in TRFR.EFF.DATE. The hold-
ing period will then be computed from the TRFR.EFF.DATE as this will be considered the purchase date.
For transfers in, if the TRFR.EFF.DATE is not available, the acquisition date will be considered to be the latest of EU tax, Customer or Security
Effective dates. For transfers out, if the TRFR.EFF.DATE is not available, the trade date will be considered the acquisition date.
The field CU.TAX.TCY enables a Manual Tax to be applied to a SECURITY.TRANSFER transaction. When a manual tax is input, accounting
entries are raised based upon this value and not the system calculated tax. The total in the NET.AMOUNT field on the transaction has only the
Manual Tax amount deducted.

Manual Tax recorded on SECURITY.TRANSER
Fees Deduction
Where agreements allow it is possible to deduct charges for funds owned by customers who fall within the scope of the European Savings Dir-
ective before the application of the European Savings Tax.
When a customer is selling funds that fall within the European Savings Directive it is possible to deduct commissions and charges in
SEC.TRADE and SECURITY.TRANSFER processing.
Such deductions will only apply to the Interest Counter element of the calculation and not to the Capital Gains calculation.
If this deduction results in a negative calculation then the Interest Counter will be regarded as zero and no tax will be applied.
The existing functionality of taking the lower of either the Capital Gain or the Interest Counter calculation will remain in place.
To initiate the process of taxing funds that fall within the scope of the European Savings Directive net of charges the EU.FEES.DEDUCTION
needs to be set up.
EU.FEES.DEDUCTION for SEC.TRADE
The above example shows a general record for all SEC.TRADE transaction types.

EU.FES.DEDUCTION for SEC.TRADE
This example shows a more specific set up for SEC.TRADE processing. The same may be set up for SECURITY.TRANSFER.
Based on the above settings T24 will check the related CUST.TRANS.CODE and sum the related values of the above field names. The per-
centage value will then be calculated from the GROSS.AMT.SEC.CCY field for SECURITY.TRANSFER and from the CU.GROSS.AM.SEC field
for SEC.TRADE.
The calculated value will be populated in the INT.CTR.CHGS field of the EU.TXN.BASE.
Example calculations are as follows:
BUY
Nominals – 10000
CU.BRK.COMM – 2.5 EUR
CU.INT.CTR – 5 EUR
NAV – 96.8955
CU.GROSS.SEC.AMT – 9689.55
Commission on % BUY = (2.5 / 9689.55) * 100 = .025800% (Should not be rounded here)
Deductible Commission from Interest Counter for BUY = .025800% of 96.8955 = .02499
On Rounding = .02% (Rounded to 2 decimal places)
INT.CTR.CHGS = .02
INT.CTR = 5
NEW.INT.CTR = 5 - .025 = 4.975

SELL
Nominals = 5000
CU.BRK.COMM = 1.8EUR
CU.INT.CTR = 6 EUR
NAV = 98.55
CU.GROSS.SEC.AMT = 9855.00
Commission on % SELL = (1.8 / 9855) * 100 = .0182648% (Should not be rounded here)
Deductible Commission from Interest Counter for SELL = .0182648 % of 98.55 = .0179999
On Rounding = .01 (Rounded to 2 decimal places)
INT.CTR.CHGS = .01
INT.CTR = 6
NEW.INT.CTR = 6 - .018 = 5.982
In order to reconcile the modified IC calculation the original Interest Counter and the deductible amount will be stored in the appropriate
EU.ALLOCATION.DETS record.
If nothing is populated in these fields then charges will not be deducted from the Interest Counter and standard processing for the IC cal-
culation will take place.
Position Transfer
The POSITION.TRANSFER application does not involve any calculation of Tax but the Position Transfer involving transfer of positions from
one portfolio to another (where both portfolio customers are “in scope”) and involving securities that are “in scope” will update the
EU.TAX.LINK file to reflect the actual holdings.

POSITION.TRANSFER
In this example, there is a transfer of positions from portfolio 50060-1 to 50048-1. The holding of 100,000 in security 000401-000 was
acquired on two different dates. As a result, they have been entered in two separate multi-value sets (40,000 in MV1 and 60,000 in MV2).
This was manually input as the automatic selection by the system will consider it as one single holding and will reflect the entire holding in a
single MV.
The original acquisition dates could be entered as below:
POSITION.TRANSFER EU Savings fields
These details need to be input manually and the multi-value details here should correspond to the multi-values in the fields SECURITY.ACCT
to PRICE above. For example, in this transfer, the 3rd multi-value corresponds to security 000417-000, so the 3rd Multi value set in the EU
savings fields should hold the acquisition details of this security.
It must be noted that the link files will not be updated for depository-to-depository transfers
Corporate Actions
The tax will be computed in these applications while processing Coupons, Redemptions and Distributions (for funds). For distributions, the
Interest Distribution factor needs to be furnished in DIARY (INT.DIST.FACTOR) if only a portion of the Distribution pertains to Interest. If
not input, the entire Distribution will be considered interest distribution and taxed accordingly. The tax calculated will be reflected in the
ENTITLEMENT record.
The field MAN.TAX.ACY enables a Manual Tax to be applied to an ENTITLEMENT record. When a manual tax is input, accounting entries are
raised based upon this value and not the system calculated tax. The total in the NET.AMOUNT field on the transaction has only the Manual
Tax amount deducted.
Whenever a back-dated Corporate Action event is input, even though the sale may have already taken place, the system will calculate the
European Savings Tax. For cash events the allocation is performed along with the rework process at the initial stage to enable the tax cal-
culation. Please see the Rework section of this guide for further information.

Manual Tax recorded on ENTITLEMENT
EU Tax Split on Joint Holdings

When a transaction is processed for a portfolio with joint holdings, the EU Tax ,that is calculated, will be split among the Joint Holders. To
achieve this, the SEC.ACC.MASTER record is linked to a CUSTOMER.RELATIONSHIP record with Relation Type set as TAX.
On entering a trade for a portfolio with joint holdings, the cumulative tax gets calculated.

Trade
On authorising the Trade, the ST.TAX.REPORT.DETAILS and EU.ALLOCATION.DETS records are generated with the breakup of indi-
vidual tax amount. The individual tax amounts are stored in the fields Joint Cust Taxi and Tax Amt Split in ST.TAX.REPORT.DETAILS
and EU.ALLOCATION.DETS records.
Sample screen of ST.TAX.REPORT.DETAILS record.
ST Tax Report Details

Sample screen of EU.ALLOCATION.DETS record.
EU Allocation Details
The Accounting entries of Trade will split the EU Tax among the Joint holders in the ratio of their holdings.
STMT.ENTRY.DETAIL

Resetting of Interest Counter after Distribution
For Corporate Actions it should be noted that the interest counter will be reset when a fund that is set up for Interest Counter tax calculation
distributes its earnings. The interest distribution by funds is subject to tax. The interest counter in all underlying transactions covered by the
Distribution will be reset to zero, so that when a subsequent sale is made, the base amount is based upon the interest counter prevailing at the
time of sale.

Holding Period Interest for Mutual Funds
The SH.AMT.BASE field in TXN.TAX.CODE will accept a value of ‘HPI’ (Holding period interest) for Distribution type events.
If HPI is specified for Distribution, the holding period of each individual transaction that make up the Qualifying Holding for the event will be
taken and the base amount for tax will be computed taking into account this Holding Period.
Example:
Purchase Date 1st July 2005
Distribution Date 31st July 2005
Holding Period 30 days
Nominal 5,000
Distribution rate 0.50
Published % relating to interest 100 % (as this event is Interest Distribution)
Gross distribution 2,500
Taxable amount 2500*30/365 = 205.48
Withholding tax 30.82 (@15%)
The holding period will be from the value date of the transaction (purchase) to the Ex date of the Corporate Event. If there is an interim dis-
tribution, the holding periods for subsequent distributions will be from the Ex date of the earlier distribution.
The generic formula will be:
Nominal (qualifying) * Distribution Rate * Int Distribution Factor *
(Holding period/(Distribution date (ex date) – Last distribution date (ex date))) * Tax rate
If the last distribution date is not known the entire distribution will be taxed. The holding period computation logic will be based on the exist-
ing Holding period options – Buy date or Status date or EU Date.
SH.AMT.BASE will still accept a value of “ID’ for Distribution. If ID is specified, the tax calculation for the above example will be as under:
Gross distribution 2,500
Taxable amount 2500 (no adjustment for holding period)
Withholding tax 375
This will be in line with the existing functionality. However, ID and HPI cannot be specified together.
It must be noted that SH.AMT.BASE will allow a value of ID only for Distribution (DIARY.TYPE) and not for SEC.TRADE or
SECURITY.TRANSFER.
Set up and Workflow
If SH.AMT.BASE is ‘HPI’ for distribution events, then the interest distribution pertaining to the holding period will be computed and this will
form the base amount for the computation of tax.
For a Mutual Fund, set up some positions for INFO customers and customers who are in Scope with the Value Date the same as the Trade
Date.
Set up TXN.TAX.CODE as Distribution and HPI for calculating tax.
Also set up TXN.TAX.CODE as Distribution and ID for calculating tax.
Input a DIARY for a full Distribution event with the RATE.TYPE set to GROSS.

After ENTITLEMENT authorisation check the ‘ET’ files EU.TAX.LINK and EU.ALLOCATION.DETS for the tax calculations for Holding Period
Interest.
TXN.TAX.CODE FOR HPI:
TXN.TAX.CODE for HPI
SECURITY.POSITION

SECURITY.POSITION
DIARY:

DIARY EU Savings fields
ENTITLEMENT:

ENTITLEMENT EU Savings fields
EU.TAX.LINK:

EU.TAX.LINK
EU.ALLOCATION.DETS:

EU.ALLOCATION.DETS
For a Mutual Fund, set up some positions for INFO customers and customers who are in Scope with the Value Date the same as the Trade
Date.
Set up TXN.TAX.CODE as Distribution and HPI for calculating tax.
Also set up TXN.TAX.CODE as Distribution and ID for calculating tax.
Input a DIARY for an Interim Distribution event with the RATE.TYPE set to GROSS.
After ENTITLEMENT authorisation check the ‘ET’ files EU.TAX.LINK and EU.ALLOCATION.DETS for the tax calculations for Holding Period
Interest.
TXN.TAX.CODE FOR HPI :

TXN.TAX.CODE for HPI
SECURITY.POSITION
SECURITY.POSITION
DIARY :

DIARY Interim Distribution EU Tax Fields
ENTITLEMENT:

ENTITLEMENT Interim Distribution EU Tax Fields
ENTITLEMENT Distribution EU Tax Fields
EU.TAX.LINK :

EU.TAX.LINK
EU.ALLOCATION.DETS:
EU.ALLOCATION.DETS

EU.ALLOCATION.DETS

EU.ALLOCATION.DETS

EU.ALLOCATION.DETS
EU.ALLOCATION.DETS

Recording of NAV
The NAV can be recorded net of transaction costs (or gross). The cost of the acquisition is NAV plus all charges and commissions, and the sale
consideration is NAV minus charges and commissions. The difference between the cost of acquisition and sale consideration is considered as
the capital gain and taxed accordingly.
Capital Gains Tax

When processing SEC.TRADE and SECURITY .TRANSFER records, it is possible to record the NAV either Net or Gross of transaction costs.
The field CU.NAV.TYPE controls this.
If ‘NET’ is selected then the cost of the acquisition is the NAV plus all charges and commissions, and the sale consideration is the NAV less
charges and commissions. If ‘GROSS’ is selected then charges and commissions are ignored.
The difference between the cost of the acquisition and the sale consideration are considered as the Capital Gain, and taxed accordingly.
Records for TXN.TAX.CODE and a SEC.TRADE example are given below. See Appendix 1 for Local Reference setup.
TXN.TAX.CODE:
TXN.TAX.CODE - IC

TXN.TAX.CODE - CG

SEC.TRADE

Tax on Interest earned on Debt Instruments
All banks within the European Union or in countries complying with the EUSD directive (Switzerland and other off-shore banking centres) are
now obliged to tax at source or to report the interest earned on all debt instruments and certain mutual funds that fall within the scope of the
directive.
However, in the EU Directive the determination of taxable interest is sometimes open to discussions and this has led to national specifics or
deviations
Taxation of Premium and Discount

When a bond issued is redeemed below par, if any excess ( against the initial amount subscribed) paid by the borrower to the lender, con-
stitutes taxable interest.
When a bond issued is redeemed above par, if any excess (against the redemption amount) paid to the borrower by the lender at the time of sub-
scription, constitutes negative interest and it must be deducted from any taxable interest. The taxable interest remaining will then be subject to
EUSD taxation.
The banks are required to take the premium or discount into account at the point when the individual investor sells the security or when the
security is redeemed.
Further, in some countries, the Taxable interest is exempted from Tax if certain conditions are met.
For example, in Luxembourg, the Luxembourgish Bankers Association suggests exempting such taxable interest if following conditions (both)
are met:
1. The total premium or discount on the security must not exceed 3% for the whole duration and
2. The life of the bond is not than 0.5% per year. The total premium or discount that is; Redemption/Issue price must not exceed 3%
A bond issued at 95% and redeemed at 100%, over five years would have 1% discount per year and 5% over the whole duration. This
bond is liable because, both conditions are fulfilled.
Another bond issued at 98% and redeemed at 100%, over two years would have 2% discount in total and 1% per year. This condition,
meets the first criteria of less than 3% but it is taxable because it is over 0.25% at 1% per year.
Following set-up must done in T24, to handle all the above.
EU.TAX.PARAM
The TOTAL.DISC.PREM field holds the percentage for Condition 1 and the field PERIOD.DISC.PREM holds the percentage period value that
is; as mentioned in above Condition 2.
Note: If different countries, have different exemption percentages, then the EU.TAX.PARAM record must be set Company wise with
respective values.

TXN.TAX.CODE
The BD.AMT.BASE field must be set to AP. This works similar to HPI, also computes the Discount amount and deducts this from the HPI.
This deduction of the discount is to the extent of the holding period interest.
Note: The discount computation and deduction will be done at the time of Sale of the Security i.e for all Sell Transactions. However, in
the case of a Coupon Payment via ENTITLEMENT, deduction will be done only on the last interest payment. For all other Coupons, the
standard HPI calculation without any deductions will apply.
Please refer the below mentioned screen shots for the calculation process.
TAX.TYPE and TAX.TYPE.CONDITION – These are as per the regular setup

TXN.TAX.CODE – Tax details for Redemption is set here.

SECURITY.MASTER – Attach the above Tax to the SECURITY.MASTER.
Note: The Tax Basis is set to AVERAGE. Also, the Issue Price and Redemption Price are set. In this example, the Redemption price is
higher than the Issue price.

DIARY – The Redemption Diary is shown below. The SC Tax code and tax type have been defaulted.

ENTITLEMENT – The EU Tax has been calculated in the ENTITLEMENT. The calculations are also explained below.

EU.TAX.LINK – The Average discount is updated.

The details are updated in EU.TAX.LINK in the fields
TOTAL.HPI - This field will hold the average total interest of the outstanding nominal.
AVG.HPI - This field will hold the average interest of the position.
TOTAL.DISCOUNT - This field will hold the average total discount of the outstanding nominal.
AVG.DISC - This field will hold the average discount of the position.

EU Savings Directive - User Guide: Release R15.000

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EU Savings Directive - User Guide: Release R15.000

Uploaded by

Copyright:

Available Formats

EU Savings Directive - User Guide

©2015 Temenos Headquarters SA - all rights reserved.

EU Savings Directive - User Guide - Release R15.000 - Page 2 of 143

Purpose of this Guide

EU Savings Directive - User Guide - Release R15.000 - Page 3 of 143

l All member states of The European Union (including new joiners)

EU Savings Directive - User Guide - Release R15.000 - Page 4 of 143

The initial installation sequence is as follows:

EU Savings Directive - User Guide - Release R15.000 - Page 5 of 143

(c) Temenos Systems 2015

EU Savings Directive - User Guide - Release R15.000 - Page 6 of 143

The following sections detail the configuration for EU Savings.

l Customer based parameters

EU Savings Directive - User Guide - Release R15.000 - Page 7 of 143

A TAX.TYPE record for the EU Savings Directive should be set-up as follows:

TAX.TYPE record for EUTAX

EU Savings Directive - User Guide - Release R15.000 - Page 8 of 143

For EU Savings the BASE.AMT.ROUTINE field must be populated with SC.EU.CALC.TAX.

Example TAX record

Tax Type Condition

EU Tax Split among Joint Holders of a Portfolio

EU Savings Directive - User Guide - Release R15.000 - Page 9 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 10 of 143

(c) Temenos Systems 2015

EU Savings Directive - User Guide - Release R15.000 - Page 12 of 143

Example EU.TAX.PARAM record

The fields are used as follows:

EU Savings Directive - User Guide - Release R15.000 - Page 13 of 143

EU.TAX.PARAM showing EU.PURGE.DATE

EU Savings Directive - User Guide - Release R15.000 - Page 14 of 143

EU.TAX.LINK.PAST record showing EU.PURGE.DATE

(c) Temenos Systems 2015

EU Savings Directive - User Guide - Release R15.000 - Page 15 of 143

Appendix 1 – Local Reference Set-up

EU Savings Directive - User Guide - Release R15.000 - Page 16 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 17 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 18 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 19 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 20 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 21 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 22 of 143

The following LOCAL.TABLE records are optional:

EU Savings Directive - User Guide - Release R15.000 - Page 23 of 143

Local Ref Table

EU Savings Directive - User Guide - Release R15.000 - Page 24 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 25 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 26 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 27 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 28 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 29 of 143

EU Savings Directive - User Guide - Release R15.000 - Page 30 of 143

l V.SC.EU.TAXBASIS.CHECK - Input routine – Change allowed only if there is no EU.TAX.LINK record.

l V.SC.EU.TAXBASIS.CHECK - Input routine – Change allowed only if there is no EU.TAX.LINK record.

(c) Temenos Systems 2015

EU Savings Directive - User Guide - Release R15.000 - Page 31 of 143

Initial Data Build

There is no specific information relating to Services for this product

EU Savings Directive - User Guide - Release R15.000 - Page 32 of 143

The flow is illustrated below:

EU Savings Directive - User Guide - Release R15.000 - Page 33 of 143

(c) Temenos Systems 2015

EU Savings Directive - User Guide - Release R15.000 - Page 34 of 143

Sub Asset Type