EU Savings

EU Savings Directive
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.
EU Savings Directive- Release R13.00 -Page 2 of 121 - (c) Temenos Systems 2013 7/19/2013
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
directive 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 clien-
t’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
(c) Temenos Systems 2011
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)
N.B. 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
Configuration Overview
The following sections detail the configuration for EU Savings
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
listed 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 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. The average option is available only at Security/Sub-Asset-type level. Since bonds can be proc-
essed only using LIFO/FIFO method, the AVERAGE option is available only for Units of funds (set-up as Shares). N.B. 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.
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
V.SC.EU.TAXBASIS.CHECK - Input routine – Change allowed only if there is no EU.TAX.LINK record.
SECURITY.MASTER
V.SC.EU.TAXBASIS.CHECK - Input routine – Change allowed only if there is no EU.TAX.LINK record.
V.SC.EU.ORIGYIELD.CHECK – Input routine – Routine to calculate and populate yield.
V.SC.EU.PRICE.CHECK – Validation routine for ISSUE.PRICE and/or REDEEM.PRICE - Input only allowed for Bonds.
V.SC.EU.PRICE.CHECK – Input routine – If EU retention tax is included in SC.TAX.CODE then ISSUE.PRICE is mandatory.
V.SC.EU.INTCTR.CHECK – Validation routine for INT.CTR – Input allowed only for shares.
SEC.OPEN.ORDER
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
SEC.TRADE
SECURITY.TRANSFER
V.SC.EU.TRFRDATE.CHECK – Validation routine for TRFR.EFF.DATE – Should not be a future date
POSITION.TRANSFER
V.SC.EU.INTCTR.CHECK – Validation routine for INT.CTR – Input allowed only for shares.
V.SC.EU.TRFRDATE.CHECK – Validation routine for TRFR.EFF.DATE – Should not be a future date
DIARY
V.SC.EU.INTCTR.CHECK - Validation routine for INT.CTR – Input allowed only for shares, and defaulted from SECURITY.MASTER.
V.SC.EU.INTDIST.CHECK - Validation routine for INT.DIST.FACTOR – Input allowed only for shares.
ENTITLEMENT
V.SC.EU.INTCTR.CHECK - Validation routine for INT.CTR – Input allowed only for shares, and defaulted from SECURITY.MASTER.
V.SC.EU.INTDIST.CHECK - Validation routine for INT.DIST.FACTOR – Input allowed only for shares.
Services Overview
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 SECU-
RITY . 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.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. 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
directly, 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.NA-
RRATIVE in cases of release G13.2), committing it and authorising it again. This will rework the Tax amount and pass the necessary adjust-
ment 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 Overview
The following section detail the trade process for EU Savings Directive
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 Man-
ual 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 Direc-
tive 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.A-
LLOCATION.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 Euro-
pean Savings Tax. For cash events the allocation is performed along with the rework process at the initial stage to enable the tax calculation.
Please see the Rework section of this guide for further information.
Manual Tax recorded on ENTITLEMENT
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

EU Savings

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

EU Savings

Hochgeladen von

Copyright:

Verfügbare Formate

EU Savings Directive

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

(c) Temenos Systems 2011

The initial installation sequence is as follows:

(c) Temenos Systems 2013

Customer based parameters

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

TAX.TYPE record for EUTAX

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

Example TAX record

Tax Type Condition

(c) Temenos Systems 2013

The fields are used as follows:

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

(c) Temenos Systems 2013

Appendix 1 – Local Reference Set-up

The following LOCAL.TABLE records are optional:

Local Ref Table

Recording of NAV net of charges in EU.TXN.BASE

Appendix 2 – Version Routines

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

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

V.SC.EU.ORIGYIELD.CHECK – Input routine – Routine to calculate and populate yield.

V.SC.EU.TRFRDATE.CHECK – Validation routine for TRFR.EFF.DATE – Should not be a future date

V.SC.EU.TRFRDATE.CHECK – Validation routine for TRFR.EFF.DATE – Should not be a future date

(c) Temenos Systems 2013

Initial Data Build

There is no specific information relating to Services for this product

Close of Business Processing

The flow is illustrated below:

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

Security based parameters

Sub Asset Type

Example SUB.ASSET.TYPE record

Txn Tax Code

HPI-Holding Period Interest

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

TXN.TAX.CODE - Coupon Paying Discount Bond redeemed at par

(c) Temenos Systems 2013

Tx Txn Base Parms

TX Set up for EU.TXN.BASE:

Tx Txn Base Mapping

TX.TXN.BASE.MAPPING for ENTITLEMENT part 1

TX.CONDITION for ENTITLEMENT

(c) Temenos Systems 2013

Cross-reference for allocation of various sell deals against buy deals:

Amendments and Rework

POSITION.TRANSFER and ENTITLEMENT

EU.TAX.LINK record before amendment: -

(c) Temenos Systems 2013

Tax recorded on SEC.TRADE

Manual Tax recorded on SEC.TRADE

Tax recorded on SECURITY.TRANSFER

EU.FEES.DEDUCTION for SEC.TRADE

Example calculations are as follows:

CU.BRK.COMM – 2.5 EUR

On Rounding = .02% (Rounded to 2 decimal places)

On Rounding = .01 (Rounded to 2 decimal places)

NEW.INT.CTR = 6 - .018 = 5.982

The original acquisition dates could be entered as below:

POSITION.TRANSFER EU Savings fields

(c) Temenos Systems 2013

Resetting of Interest Counter after Distribution

(c) Temenos Systems 2013