Commission Staff Working Document:Taxation of Savings - Functional Specifications (FITSDEV-FS-TaxSavings) - Hoofdinhoud

COUNCIL OF Brussels, 22 May 2007

THE EUROPEAN UNION

9786/07

FISC 80

COVER NOTE

from: Secretary-General of the European Commission,

signed by Mr Jordi AYET PUIGARNAU, Director

date of receipt: 22 May 2007

to: Mr Javier SOLANA, Secretary-General/High Representative

Subject: Commission Staff Working Document: Taxation of Savings - Functional Specifications (FITSDEV-FS-TaxSavings)

Delegations will find attached Commission document SEC(2007) 696.

________________________

Encl.: SEC(2007) 696

COMMISSION OF THE EUROPEAN COMMUNITIES

Brussels, 16.5.2007 SEC(2007) 696

COMMISSION STAFF WORKING DOCUMENT

Taxation of Savings - Functional Specifications

(FITSDEV-FS-TaxSavings)

EN EN

OWNER: ISSUE DATE: VERSION:

DG TAXUD 15/05/2007 2.3

Taxation and Customs Union DG

FITSDEV Project

Specifications, Development, Maintenance and Support for communication and information exchange systems in the taxation and excise area

Subject:

Taxation of Savings - Functional Specifications

(FITSDEV-FS-TaxSavings)

Document History

Version Release Date Author Description

V1.00 04/05/2006 Peter Macfarlane Initial Version

Jean-François Noël

V1.02 07/06/2006 Jean-François Noël Updated according to decisions of DG TAXUD

Peter Macfarlane review meeting.

V1.03 12/06/2006 Jean-François Noël Updated according to Implementation Verification from QA and to feedback from DG TAXUD

regarding Non-Functional Requirements.

V1.05 04/10/2006 Peter Macfarlane Update to include decisions from review meeting.

Update to include comments from DG TAXUD and internal quality review.

V1.06 09/11/2006 Peter Macfarlane Implement comments from DG TAXUD

V2.00 14/11/2006 Peter Macfarlane Correct document history.

Include note in section 4.3 to explain that some processes will be managed by operational procedures.

V2.01 01/02/2007 Peter Macfarlane Implement amendments agreed during 24-26 January MS Workshop.

V2.02 08/03/2007 Peter Macfarlane Update Definition of Beneficial Owner

Update Use Cases related to Correction Mechanism

Rename Messages

Amend description of Year Of Payment

Update Territorial Features table

V2.03 15/05/2007 Peter Macfarlane Conversion to Legiswrite format

Amend definitions of “Automatic Exchange” and “FISC153”

Add “Cancels Interest Payment Transmission” and “Receives Notification of Interest Payment Transmission Cancellation” business use cases

Correct Figure 17

Remove notion of “any format” for exchanges from Third Countries/Dependent/Associated Territories in BUC-CA-RIR-020 and BUC-CA-PA-030

Correct Figure 18

Correct Figure 19

Remove reference to correction period in BUC-CA- RIR-150

Add constraint to BUC-CA-RIR-150

Add functional requirements F.09 and F.10 relating to

cancellation of transmissions/requests for correction

Correct bookmark cross-references in table 6

Correct Figure 27

Refer to section 4.5 for declaration period in table 7

Rejection process applies to cancellations of correction requests

Section 4.5 – Clarify that timescales not in the Council Directive are based in goodwill between the MS.

Correct SUC-CA-040 – process applies to cancellation of request for correction

Clarify the grouping of requests/responses for corrections in SUC-CA-PA-060

SUC-CA-PA-080 – refer to the list of reasons for rejecting a request for correction

SUC-CA-RIR-040 – refer to section 4.5 for the declaration period

Table 13 – Change YearOfPayment datatype to year, monAmount to INTEGER (and say that zero amounts do not have to be sent but CA of PA may choose to send), clarify that account involved is the one for which interest is generated

Table 16 – secNoQlf and othQlf changed to allow empty value

Table 27 – empty values allowed for issuedBy

Table 32, 34, 36, 37, 40 – add ID

Change valid values for all ID types in section 4.8 to “text”

Table 33 Change CorrectionValue to conditional – only provided for Add or Update

Table 33 – Link ID extended to link Beneficial Owner

to a Paying Agent

Table 35, 40 – add Error Type

Table 40 – add Rejection ID

Table 43 –Add ErrorType

Delete Table 47 and associated text

Table of Member States – Add RO, BG

Table 53 – clarify that values where x is put in positions 2 to 4 are not presented

Reviews

Version Name Position Review Date

V1.00 Pierre Noël Project Manager 04/05/2006

Sébastien Quality Reviewer 04/05/2006

Vandenbergh Quality Reviewer 28/04/2006

Paul Newton

V1.02 - - -

V1.03 - - -

V1.05 Timo Schmitt Quality Reviewer 03/10/2006

Jean-François Quality Reviewer / 03/10/2006 Noël Delivery Manager

V1.06 Jean-François Quality Reviewer / 08/11/2006 Noël Delivery Manager

V2.00 Jean-François Quality Reviewer / 14/11/2006 Noël Delivery Manager

V2.01 - - -

V2.02 Timo Schmitt Quality Reviewer 08/03/2007

V2.03 Timo Schmitt Quality Reviewer 15/05/2007

Table of Contents

• 1. 

  Introduction ................................................................................................................ 10

1.1. Objective of this Document ....................................................................................... 10

1.2. Intended Audience ..................................................................................................... 10

1.3. Structure of this Document ........................................................................................ 10

1.4. Related Documents .................................................................................................... 11

1.4.1. Applicable Documents ............................................................................................... 11

1.4.2. Reference Documents ................................................................................................ 11

1.5. Document Conventions.............................................................................................. 12

1.6. Terminology............................................................................................................... 13

1.6.1. Abbreviations and Acronyms..................................................................................... 13

1.6.2. Definitions.................................................................................................................. 13

1.7. Review of the Document............................................................................................ 15

• 2. 

  Business Scope........................................................................................................... 16

2.1. History of Key Events within DG TAXUD and the MS ........................................... 16

2.2. Rationale .................................................................................................................... 16

2.3. Scope of this Document ............................................................................................. 17

• 3. 

  Overall Business Model ............................................................................................. 18

3.1. Overall Domain Model .............................................................................................. 18

3.1.1. National Private Domain............................................................................................ 19

3.1.2. National Public Domain............................................................................................. 19

3.1.3. Common Domain ....................................................................................................... 20

3.1.4. Domains Interactions ................................................................................................. 20

3.2. Business Actors .......................................................................................................... 21

3.3. Business Architecture................................................................................................. 23

3.3.1. Exchange of Information Mechanism for Beneficial Owner ..................................... 24

3.3.2. Exchange of Information Mechanism for Residual Entity ........................................ 25

3.3.3. Withholding Tax Mechanism for Beneficial Owner.................................................. 26

3.3.4. Withholding Tax Mechanism for Residual Entity ..................................................... 28 3.3.5. Withholding Tax Mechanism with Certificate of Non-Deduction for Beneficial

Owner ......................................................................................................................... 30

3.4. Business Use Case Model .......................................................................................... 31

3.5. Business Use Cases Description ................................................................................ 33

3.5.1. Paying Agent Use Cases ............................................................................................ 34

3.5.2. Paying Agent – Residual Entity Use Cases................................................................ 41

3.5.3. Economic Operator Use Cases................................................................................... 43

3.5.4. Relevant Interest Recipient Use Cases....................................................................... 46

3.5.5. Relevant Interest Recipient – Beneficial Owner Use Cases ...................................... 48

3.5.6. Relevant Interest Recipient – Residual Entity ........................................................... 53

3.5.7. Competent Authority of Paying Agent Use Cases ..................................................... 55

3.5.8. Competent Authority of Economic Operator Use Cases ........................................... 67

3.5.9. Competent Authority of Relevant Interest Recipient Use Cases ............................... 71

3.6. Conceptual Data Model.............................................................................................. 82

3.6.1. Main Entities .............................................................................................................. 82

3.6.2. Beneficial Owner Payment ........................................................................................ 82

3.6.3. Residual Entity Payment ............................................................................................ 83

3.6.4. RIR Withholding Tax................................................................................................. 84

3.6.5. Residual Entity Withholding Tax............................................................................... 85

• 4. 

  System Model............................................................................................................. 86

4.1. Functional Requirements ........................................................................................... 86

4.2. Mapping of Business Use Cases to System Use Cases.............................................. 87

4.2.1. Triggering Events....................................................................................................... 89

4.3. Process / Data Flow Diagrams ................................................................................... 90

4.3.1. PDFD – Transmission of Interest payment Information............................................ 90

4.3.2. PDFD – Correction of Interest Payment Information ................................................ 91

4.3.3. Operational Procedures .............................................................................................. 93

4.4. Sequence Diagrams .................................................................................................... 93

4.4.1. Rejection Process ....................................................................................................... 93

4.4.2. Initial Transmission Process ...................................................................................... 94

4.4.3. Correction Process ..................................................................................................... 94 4.5. Process Timescales..................................................................................................... 98

4.5.1. Process Timeline ........................................................................................................ 98

4.5.2. Process Timescale Provisions .................................................................................... 99

4.6. System Use Cases Model ......................................................................................... 100

4.6.1. Use Cases Common to CA of PA and CA of RIR ................................................... 100

4.6.2 Use Cases Specific to CA of PA .............................................................................. 102

4.6.3. Use Cases Specific to CA of RIR ............................................................................ 107

4.7. Logical Data Model.................................................................................................. 110

4.7.1. Entity-Attribute Model Template............................................................................. 110

4.7.2 Entity-Attribute Models ........................................................................................... 111

4.8. Messages .................................................................................................................. 123

4.8.1. Initial Exchange Message ........................................................................................ 124

4.8.2. Correction Management Messages .......................................................................... 125

4.8.3. Exception Management............................................................................................ 129

4.8.4. Examples of Messages ............................................................................................. 130

4.9. Logical Error Codes and Reason Codes................................................................... 133

• 5. 

  Non-Functional Requirements ................................................................................. 135

5.1. Usability ................................................................................................................... 135

5.2. Security .................................................................................................................... 136

5.3. Business Continuity ................................................................................................. 137

5.4. Quality of Service .................................................................................................... 138

5.5. Legal......................................................................................................................... 140

5.6. Development Qualities............................................................................................. 142

• 6. 

  Assumptions / Constraints / Risks............................................................................ 142

6.1. Assumptions and Constraints................................................................................... 142

6.1.1. Legal Assumptions................................................................................................... 142

6.1.2. Business Assumptions.............................................................................................. 143

6.1.3. Technical Constraints............................................................................................... 143

6.2. Risks......................................................................................................................... 143

• 7. 

  Appendices ............................................................................................................... 144 7.1. Reference Data ......................................................................................................... 144

7.1.1. ISO-3166 Alpha 2 Country Codes ........................................................................... 144

7.1.2. Selected ISO-4217 Alpha-3 Currency Codes .......................................................... 145

7.2. Territorial Features................................................................................................... 147

7.3. Allowed Values for Specific Payment Type ............................................................ 148

7.4. Notation Catalogue................................................................................................... 149

7.4.1. Entity Relationship Diagram.................................................................................... 149

7.4.2. Process Flow Diagram ............................................................................................. 150

7.4.3. Sequence Diagrams .................................................................................................. 153

7.4.4. Element Definition Templates ................................................................................. 154 1. I NTRODUCTION

1.1. Objective of this Document

The objective of this document is to translate the Council Directive 2003/48/EC i on taxation of savings income in the form of interest payment [A01], where it concerns exchange of information on interest on savings, to a consistent business process and business information model, and to present a functional solution for implementing the requirements of the Council Directive regarding the exchange of information on interest on savings. This document also aims to present a solution for specific areas not covered by the Council Directive but which are required for its good functioning, in particular, correction processes.

1.2. Intended Audience

The document addresses the representatives of the administrations of the Member States (MS) who are responsible for information systems and processes affected by the Council Directive.

The document also constitutes a basis for the development teams who will be in charge of writing technical specifications.

1.3. Structure of this Document

This document is structured into the following set of Chapters and Appendices.

Chapter 1 is this introduction, and includes the standard sections for References and Terminology.

Chapter 2 describes the business scope of the project

Chapter 3 covers the whole Council Directive and therefore constitutes a complete business modelling of the Directive. This chapter is informative only, and is included for better understanding of the processes and requirements described in chapters 4 and 5.

Chapter 4 concentrates on the system modelling of Articles 4.2, 8 and 9 of the Council Directive, and of related articles 3, 4.1 and 6. It focuses only on the exchanges of information on interest on savings between the Competent Authorities.

Chapter 5 describes the non-functional requirements to be met by whatever technical architecture is put in place to support the exchange of information on interest on savings.

Chapter 6 presents the assumptions, constraints and resulting risks of the project.

Chapter 7 presents the different appendices to this document, in particular the set of reference data and an explanation of the annotation used in this document.

Chapters 4, 5 and 6 are part of the formal review process by the MS, as part of the obligations of the MS regarding Articles 4.2 and 9 of the Council Directive 2003/48/EC i of 3 June 2003 on taxation of savings income in the form of interest payments.

1.4. Related Documents

1.4.1. Applicable Documents

Ref. Title Reference Version Date

A01 Council Directive 2003/48/EC i on taxation of 2003/48/EC NA 03/06/2003 savings income in the form of interest

payments

A02 Council Directive 77/799/EEC i concerning 77/799/EEC NA 19/12/1977 mutual assistance by the competent

authorities of the Member States in the field of direct and indirect taxation

A03 Council Decision on the Date of Application 2004/587/EC NA 19/07/2004 of Directive 2003/48/EC i

A04 Taxation of Savings (Directive 2003/48 i/CE) - 4.04 08/03/2007 Standard Format for the Exchange of

Information Revised FISC153

Table 1: Applicable Documents

1.4.2. Reference Documents

Ref. Title Reference Version Date

R01 Council Directive 91/308/EEC i on 91/308/EEC NA 10/06/1991 prevention of the use of the financial system

for the purpose of money laundering

R02 Council Directive 85/611/EEC i on the 85/611/EEC NA 20/12/1985 coordination of laws, regulations and

administrative provisions relating to undertakings for collective investment in transferable securities (UCITS)

R03 Council Directive 80/390/EEC i coordinating 80/390/EEC NA 17/03/1980 the requirements for the drawing up,

scrutiny and distribution of the listing particulars to be published for the admission of securities to official stockexchange listing, with regard to the obligation to publish listing particulars

R04 Recommended Procedures for a new OECD CTPA/CFA(2005)26 NA 31/03/2005 Standardised Transmission Format for /REV1

Automatic Exchanges – Proposal for a New OECD Standardised Format for Automatic Exchange of Information for Tax Purposes

R05 OECD Model Agreement on Exchange of NA NA 18/04/2002 Information on Tax Matters

R06 Outcome of Proceedings of Working Party FISC39 NA 11/02/2002 on Tax Questions – Direct Taxation

(Savings) – Taxation of Savings – 5986/02

Exchange of Information (standard format) Ref. Title Reference Version Date

R07 Taxation of Savings – MS Workshop – FITSDEV-SC04- 1.01 11/04/2006 Report of 28-29 March 2006 Meeting REP-TaxSavings

Workshop 20060329

R08 Codes for the representation of names of ISO 3166-1:1997 90.92 23/09/2003 countries and their subdivisions -- Part 1:

Country codes

R09 Codes for the representation of currencies ISO 60.60 10/11/2004 and funds 4217:2001/Cor

1:2004

R10 European Committee for Banking EBS204 3.2 08/2003 Standards

IBAN: International Bank Account Number

R11 Savings Directive N° 2003/48/EC – Report TAXUD.D4(2005) NA 16/11/2005 of Technical Workshop of 21 November DOC 2135

2005 - FISC39 - Technical Questions from Member States

R12 Savings Directive N° 2003/48/EC – Report TAXUD.D4(2006) NA 14/02/2006 of Technical Workshop of 27 January 2006 DOC 2411-

• - 

  FISC39 - Technical Questions from ACDT005 Member States

R13 Securities and related financial instruments ISO 6166:2001 90.20 15/11/2005 – International securities identification

numbering system

R14 Banking – Banking Telecommunication ISO 9362:1987 95.99 22/12/1994 messages – Bank Identifier Codes

R15 Taxation of Savings – Operational - - - Procedures and Responsibilities

Table 2: Reference Documents

1.5. Document Conventions

Reference documents are shown in brackets [].

In this document, the requirements levels will be categorised according to the following terminology:

• “Must Do”: This is an absolute requirement needed for the good working of the Council

Directive, from a process and/or a data perspective;

• “Should Do”: This means that there may exist valid reasons in particular circumstances to

ignore the requirement, but the full implications for the good working of the Council Directive must be understood and carefully weighed before choosing a different course. In

this document, “Nice to Have” requirement will stand for “Should Do” requirement.

1.6. Terminology

1.6.1. Abbreviations and Acronyms

Acronym Meaning

Art. Article

BO Beneficial Owner

CA Competent Authority

CA of EO Competent Authority of the Economic Operator

CA of PA Competent Authority of the Paying Agent

CA of RIR Competent Authority of the Relevant Interest Recipient

CCN Common Communication Network

CD Compact Disc

dp Decimal Places

EC European Community

ECOFIN Economic and Financial Affairs Council

EO Economic Operator

IBAN International Bank Account Number

ISIN International Securities Identifying Number

ISO International Organization for Standardization

MS Member State

MSA Member State Administration

NA Not Applicable

OBAN Other Bank Account Number

OECD Organisation for Economic Cooperation and Development

OSIN Other Securities Identifying Number

PA Paying Agent

PDFD Process Data Flow Diagram

RE Residual Entity

RIR Relevant Interest Recipient

SWIFT Society for Worldwide Interbank Financial Telecommunication

TIN Tax Identification Number

UCITS Undertaking for Collective Investment in Transferable Securities

Table 3: Taxation of Savings – List of Abbreviations and Acronyms

1.6.2. Definitions

Definition Meaning

Automatic Exchange In the context of this document, a message containing piece of information sent by the Competent Authority of a Member State to the Competent Authority of any other Member State concerned by the information, without prior request, on a regular basis, under the conditions laid down by Article 9 of Directive 2004/48/EC i.

Beneficial Owner The Beneficial Owner is defined in Art. 2 of [A01].

Any individual who receives an interest payment or any individual for whom an interest payment is secured, unless he provides evidence that it was not received or secured for

Definition Meaning

his own benefit, for one of the following reasons:

– He acts as a paying agent;

– He acts on behalf of a legal person, an entity which is taxed on its profits under the

general arrangements for business taxation;

– He acts on behalf of an UCITS authorised in accordance with Directive 85/611/EEC i;

– He acts on behalf of a Residual Entity and discloses the name and address of that Residual Entity to the economic operator making the interest payment and the latter communicates such information to its Member State of establishment;

– He acts on behalf of another individual who is the beneficial owner and discloses to the paying agent the identity of that beneficial owner.

Competent Authority For the purpose of modelling the Council Directive, this term covers the four following roles:

– According to Art. 5 of the Council Directive, any authority notified by the MS to the Commission, or, for Third Countries, any authority with the purposes of bilateral or multilateral tax conventions or, failing that, such other authority as is competent to issue certificates of residence for tax purposes;

– The “Fiscal Authority” of the MS;

– The authority receiving and distributing the withholding tax.

Correction Period For the purpose of the current document, the period allowed for the MS to exchange corrected information regarding interest payments on savings.

Council Directive When used without further qualification, this means Council Directive 2003/48/EC i [A01] together with the agreements signed with ten Dependent and Associated Territories and five Third Countries.

Declaration Period For the purpose of the current document, the period allowed for the MS to exchange initial information regarding interest payments on savings.

Economic Actor For the purpose of modelling the Council Directive, the most generic business actor representing any kind of economic entity, whether a physical or a legal person, involved in the processes related to the Council Directive 2003/48/EC i on taxation of savings income in the form of interest payments.

FISC153 Schema A schema developed by the Council of the European Union – Financial Questions Group to serve as the standard format for the automatic exchange of interest payment information between MS.

FISC153 In this document, FISC153 refers to the standard format used for the exchange of interest payment information, or any evolution of this standard format, being well understood that this format has been extended to cover correction process.

Fiscal Period A financial reporting period covering either years or quarters for taxation purpose. In this document, the fiscal period covers one year for the exchanges between the Competent Authorities, but may be less for exchanges from the Paying Agent and its Competent Authority.

Gross Interest The interest before deduction of the withholding tax, in the context of the Council Directive. Other deductions applying to the interests on savings are not considered in the scope of the current document.

Interest The value of the interest payment.

Interest Payment An Interest Payment is defined in Art. 6 of [A01]

Any of the following cases:

– Interest paid or credited to an account, relating to debt claims of every kind, whether or not secured by mortgage and whether or not carrying a right to participate in the debtor’s profits;

– Interest accrued or capitalised at the sale, refund, or redemption of the debt claims referred to above;

– Income deriving from interest payments either directly or through an entity established in a Member State to which interest is paid or for which interest is secured for the benefit of the beneficial owner;

– Income realised upon the sale, refund or redemption of shares of units in the Definition Meaning

following undertakings and entities in specific investment circumstances;

– an UCITS authorised in accordance with Directive 85/611/EEC i;

– entities which qualify for the option under Article 4(3);

– undertakings for collective investment established outside the territory referred to in Article 7.

Interest Period The period of time for which a saving produces an interest.

Net Interest The interest after deduction of the withholding tax, in the context of the Council Directive. Other deductions applying to the interests on savings are not considered in the scope of the current document.

Paying Agent The Paying Agent is defined in Art. 4 of [A01]

Any economic operator who pays interest to or secures the payment of interest for the immediate benefit of the beneficial owner, whether the operator is the debtor of the debt

claim which produces the interest or the operator charged by the debtor or the beneficial owner with paying interest or securing the payment of interest.

Any entity established in a Member State to which interest is paid or for which interest is secured for the benefit of the beneficial owner is also considered a paying agent upon

such payment or securing of such payment except if it is a legal person (excluding legal persons defined in paragraph 5 of Art. 4), or its profits are taxed under the general

arrangements for business taxation or it is an UCITS recognised in accordance with Council Directive 85/611/EEC i.

Payment Currency The currency in which an interest payment is reported by a paying agent to a Competent Authority.

Relevant Interest Recipient For the purpose of modelling the Council Directive, generic business actor representing either the Beneficial Owner or the Residual Entity in its role of Recipient of interest.

Residual Entity An entity established in a Member State, to which interest is paid or for which interest is secured for the benefit of the beneficial owner, but which is neither legal person, nor entity subject to business taxation nor a UCITS recognised according to Directive 85/611 i/CEE nor has opted to be treated as such.

Payment of interest by Paying Agent to such entity must be reported and that information exchanged with the member state of establishment of the Residual Entity.

The Residual Entity is not required to comply with the provisions of the Council Directive when it makes a payment of interest. Such entity can however opt to be treated

as a UCITS, with the results that payments to the entity are not reportable, but payments by the entity, if made to individuals, are reportable.

Spontaneous message In the context of this document, a message containing a piece of information sent by the Competent Authority of a Member State to the Competent Authority of any other Member State concerned by the information, without prior request, although within an agreed timeframe, under the conditions laid down by Article 4 of Directive 77/799/EEC i.

Syntactically Correct A structured message exchanged by automated means is syntactically correct when it is conformable to the technical specification; a non-structured message exchanged manually is syntactically correct when it is conformable to the operational procedure.

Tax Year A Fiscal Period of one year.

Table 4: Taxation of Savings – List of Definitions

1.7. Review of the Document

This document will be submitted to the Council for approval. Further technical alterations may be decided by the Working Group on Administrative Cooperation in the Field of Direct

Taxation at a subsequent stage.

• 2. 

  B USINESS S COPE

2.1. History of Key Events within DG TAXUD and the MS

Issued in 1989, the first Proposal for Directive on savings envisioned a general principle of withholding tax applicable to all Member States.

Created by the Verona informal ECOFIN in 1996, the Taxation Policy High Level Group provided some recommendations in the area of direct taxation. The ECOFIN Council adopted these recommendations on 01/12/1997, in the form of a taxation package with three components:

• Interest / Royalties (Withholding tax exemption);

• Code of conduct regarding the taxation of business companies;

• Taxation of Savings.

The third part was the subject of the Proposals for Directives of 1998 and 2001.

The principle of tax withholding was discussed and gave rise to the 1998 Proposal for Directive, based on a harmonised withholding tax at a rate of 15% and on the "coexistence model", allowing an option between applying withholding tax or exchanging information on interests on savings.

2.2. Rationale

In 2000, the Member States came to the agreement that taxation of savings must be aimed, as an ultimate objective, to the exchange of information from the country of the Paying Agent to the country of residence of the Beneficial Owner.

Until Switzerland, Liechtenstein, San Marino, Monaco and Andorra move to an exchange of information upon request, as defined in the OECD Model Agreement [R05], by entry into force of an agreement between these countries and the European Community, three Member States (Belgium, Luxemburg, Austria) were allowed to adopt, as a transitory measure, the mechanism of withholding tax accompanied by the sharing of tax revenue with the country of fiscal residence of the Beneficial Owner. The Beneficial Owner could be exempted from withholding tax if it accepted voluntary disclosure of information to its tax authority.

On the basis of the 2001 proposal, the Council Directive 2003/48/EC i on taxation of savings income in the form of interest payment [A01] was adopted on 03/06/2003 [A03]. The application of the legislation was agreed to commence on 01/07/2005 and applies to all interest payments made from 1 July onwards, excluding the proportion of that interest which has accrued before that date (reported during the first semester of 2006, except for UK where

the tax year ends on 5 th April).

The Council on General Affairs of 12 December 2005 agreed that this Council Directive will be applied in two steps:

• Use of the FISC39 format for the exchange of information related to the tax years 2006

and 2007;

• As from 01/01/2008, use of the FISC153 standard format.

2.3. Scope of this Document

This document comes within the context of the second step of the application of the Council Directive. Its first objective is to specify the processes to be put in place between the taxation authorities of the MS to support good working of the Council Directive.

The scope of this document is to define the business and system processes needed to support exchanges of information on interest payments under articles 4.2, 8 and 9 of the Council Directive between the Competent Authorities of the MS, where it is understood that those articles also refer to articles 3, 4.1 and 6.

Consequently, the mechanisms related to the application of the withholding tax transitional measures (articles 11, 12, and 13 of the Council Directive) are left outside the scope of the document. Similarly, the organisation and procedures that could be required between the Competent Authority of any MS and its national Economic Operators, Paying Agents and Beneficial owners are not within the scope of this document.

However, in order to have a good understanding of the mechanisms to be defined for exchanges between the tax authorities, this document first provides a high-level vision of the overall business mechanisms covered by the Council Directive involving all business actors – such as the Paying Agent and the Beneficial Owner. Although these actors are outside the scope of this document, they can have an impact on processes or information exchanges that are inside the scope. This approach will ensure a thorough analysis of the mechanisms to be introduced for the proper functioning of the Council Directive.

• 3. 

  O VERALL B USINESS M ODEL

This chapter aims to present wide overview of the business processes that are involved in the working of the Council Directive. The chapter is purely informative and serves as an introduction and backdrop to chapters 4 and 5, which describe the functionality that MS must or should implement to support the Council Directive.

The chapter begins by identifying domains to which business actors can be confined and the broad interactions between these. Section 3.2 defines the business actors and explains their roles. Section 3.3 describes the interactions between the actors for different scenarios. Sections 3.4 and 3.5 list business use cases that describe key processes in the business model. The chapter ends with a high- level conceptual data model of the information that is processed.

The processes described in this chapter are generic and there may be slight differences in the MS due to the transposition of the Council Directive into national legislation.

3.1. Overall Domain Model

The Council Directive 2003/48/EC i on taxation of savings income in the form of interest payment [A01] is depicted by the Domain Model illustrated in Figure 1.

National Public Domain National Private Domain

Competent Authority of Paying Agent Paying Agent ◊ Member State ◊ Effective Paying Agent ◊ Dependent / Associated Territory ◊ Residual Entity ◊ Third Country

Competent Authority of Relevant Interest Recipient Relevant Interest Recipient ◊ Member State ◊ Effective Beneficial Owner ◊ Dependent / Associated Territory ◊ Residual Entity

Competent Authority of Economic Operator Economic Operator ◊ Member State ◊ Payer to Residual Entity ◊ Dependent / Associated Territory

Business Support ◊ Business analysts ◊ EU Legal experts

Technical Support ◊ Common Application Support ◊ Help Desk & Support ◊ Common Infrastructure ◊ Statistical Reporting

Common Domain

Figure 1: Taxation of Savings: Domain Model

This Domain Model is composed of the following domains:

• National Private Domain;

• National Public Domain;

• Common Domain.

The following sections describe each of those domains, and then describe the interactions between the constituent business actors.

3.1.1. National Private Domain

The National Private Domain makes the distinction between the different economic actors of the Member States:

• Economic actors that enjoy the revenues of the savings referred to in the Council

Directive. These are the Beneficial Owners, as defined in Art.2 of the Council Directive

[A01].

• Economic actors that manage and remunerate the savings of the persons referred to in this

Council Directive. These are the Paying Agents as defined in Art.4 of the Council

Directive [A01].

• Economic actors that play the role of an intermediary between the Paying Agents and the

Beneficial Owners, acting sometimes as a recipient of interest from the Paying Agent, and sometimes as the Paying Agent for the Beneficial Owner. This is typically the role of the

Residual Entity, as defined in Art.4.2 of the Council Directive [A01].

• Economic actors, named Economic Operators, who put funds at the disposal of other

economic actors in order for them to play their role of Paying Agent.

3.1.2. National Public Domain

This domain is constituted by business actors resulting directly from the definition of the business actors of the National Private Domain. These actors are the Competent Authorities, as defined in Art.5 of the Council Directive [A01], for the different actors of the National Private Domain. The depiction includes the status of the country to which the Competent Authority pertains in the sense of the Council Directive, i.e. the country is either a Member State, an Associated or Dependent Territory, or a Third Country. This characteristic does not represent a further specialisation of the actors in the National Public Domain: they do not play a specific role, or have specific business processes according to their status. The characteristic only provides an indication of the impact of the Council Directive on each of the countries, according to its status.

For instance, the figure shows that the Competent Authority of a Paying Agent may concern either a Member State, an Associated or Dependent Territory, or a Third Country, whereas the Competent Authority of a Beneficial Owner may concern only a Member State, or an Associated or Dependent Territory. This feature is just the result of the principle of reciprocity, which does not apply to Third Countries.

An exhaustive list of the Third Countries and of the Associated or Dependent Territories is presented for information in section 7.1.1.

3.1.3. Common Domain

This domain is constituted of the following business actors:

• Legal, functional and technical experts supporting the community of Member States by

producing functional and technical documents, or elaborating legal texts;

• Operational actors for the support of the common technical infrastructure, the support of

the MS in their day-to-day operation (Help-Desk), or the production of operational or

statistical reports.

These business actors have no business role from the perspective of the Council Directive, so this domain will not be considered in the modelling exercise in the present document.

3.1.4. Domains Interactions

Figure 1 also presents the interactions existing between the different Domains defined in the context of the Council Directive [A01]:

• Interactions between the Common Domain and the National Public Domain are limited.

There is no interaction between the Common Domain and the National Private Domain;

• Interactions between the National Public Domain and the National Private Domain

represent an important part of the modelled Council Directive;

• It must be noted that the major objective of the modelling of the Council Directive

concerns the interactions existing between the business actors in the National Public

Domain, which constitutes the scope of the present document.

3.2. Business Actors

Resulting from the Domain Model described in the previous section, Figure 2 and Figure 3 present the Business Actors to be defined for a full coverage of the business processes concerned by the Council Directive. These business actors are presented in a hierarchical diagram, depicting the level of specialisation of the role of a given business actor and of the associated business processes. Business processes associated with a business actor defined on a certain level apply to this business actor and to the full hierarchy of business actors situated on lower levels of the same branch. In particular, business processes associated with the business actor of the first level of the hierarchy apply to all the hierarchy of business actors, whereas business processes associated with a business actor on the lowest level only apply to this specific business actor.

Figure 2 presents the business actors defined in the National Private Domain:

National Private Domain

Economic Actor

Paying Agent (PA) Economic Operator Relevant Interest Recipient (RIR)

Effective Paying Agent PA - Residual Entity Beneficial Owner RIR - Residual Entity

Effective Beneficial Owner Residual Entity Member

Figure 2: Taxation of Savings – Business Actors in National Private Domain

This figure shows three level-2 business actors:

• Paying Agent;

• Economic Operator;

• Relevant Interest Recipient.

Two level-3 business actors are defined in the branch of the Paying Agent business actor:

• Effective Paying Agent;

• Residual Entity in a role of Paying Agent.

Two level-3 business actors are defined in the branch of the Relevant Interest Recipient:

• Beneficial Owner;

• Residual Entity in a role of Relevant Interest Recipient.

Two level-4 business actors are defined in the branch of the Beneficial Owner business actor:

• Effective Beneficial Owner;

• Residual Entity Member.

This Business Actors Model depicts for example the following cases covered by the Council Directive:

• All business processes associated with the Paying Agent are applicable to the Effective

Paying Agent and to the Residual Entity in the role of Paying Agent, while the business processes associated with the Residual Entity in the role of Paying Agent apply only to

this Residual Entity;

• All business processes defined for the Beneficial Owner in fact apply to both the Effective

Beneficial Owner and to the Residual Entity Member.

According to this Business Actor modelling, the Residual Entity plays a dual role:

• The role of Paying Agent, for which all associated business processes are fully applicable.

This role concerns all the exchanges of the Residual Entity with the Beneficial Owner, either Effective or Residual Entity Member, such as the payment of interest on savings

and the transmission of statements of interest on savings;

• The role of Relevant Interest Recipient, for which all associated business processes apply.

This role concerns all the exchanges between a Paying Agent or an Economic Operator

and the Residual Entity, such as reception of interest or of withholding tax certificate.

The Economic Operator has been defined to depict the characteristic specified in the Council Directive of a business actor with no fiscal role or fiscal responsibility. The Economic Operator puts funds at the disposal of other economic actors in order for them to play their role of Paying Agent.

This reflects the situation described in the Council Directive [A01] for the Residual Entity (Art.4.2).

Figure 3 presents the business actors defined in the National Public Domain:

Figure 3: Taxation of Savings – Business Actors in National Public Domain

This figure defines three level-2 business actors in the National Public Domain, corresponding to the level-2 business actors defined in the National Private Domain:

• The Competent Authority of the Paying Agent;

• The Competent Authority of the Economic Operator;

• The Competent Authority of the Relevant Interest Recipient.

The modelling of the Council Directive did not identify the need to further specify any of these business actors. For instance, the Competent Authority of the Paying Agent has the same role and is subject to the same business processes, whether the Paying Agent is effective or a Residual Entity.

3.3. Business Architecture

The following sections provide an overall picture of the interactions – in the form of notification, exchange of information, or financial transfers – occurring between the Business Actors defined in the Council Directive 2003/48/EC i on taxation of savings income in the form of interest payment [A01], resulting in the overall Business Architecture to be put into place in support of this Council Directive.

Although the following sections do not present the full picture including all cases, alternate scenarios and exceptions, they provide the complete vision of the different kinds of interactions defined in the Council Directive that will be further described later in the current document.

3.3.1. Exchange of Information Mechanism for Beneficial Owner

Figure 4 illustrates the general mechanism of information exchange in the sense of the Council Directive. This mechanism covers the cases of automatic and voluntary disclosure schemes.

RIR - Beneficial

Owner Paying Agent

Gross Interest Saving

Statement of Interest

Tax Payment

Interest on

Saving Tax Payment Interest Payment Notification

Declaration Information

Interest Payment Information

Competent Authority of Relevant Interest Recipient

Competent Authority of Paying Agent

MS of Fiscal Residence of Relevant Interest Recipient MS of Paying Agent

Figure 4: Taxation of Savings – Exchange of Information Mechanism for Beneficial

Owner

According to this mechanism, the Paying Agent transmits a statement of interest for the gross interest to be paid or guaranteed to the Beneficial Owner, and performs the corresponding funds transfer through the banking channel.

At the end of the fiscal period, the Paying Agent transmits to its Competent Authority the information regarding the gross interest it has paid to the Beneficial Owners during the fiscal period. This information is provided at least on a per Beneficial Owner basis.

The Competent Authority of the Paying Agent collects the interest payment information from all national Paying Agents, performs a compilation and a break down of this information at least per MS, per Beneficial Owner, and transmits this information to the Competent Authority of every concerned MS.

At the end of the fiscal period, each Beneficial Owner submits a tax return to its Competent Authority, which mentions the interest received for all the savings it owns.

Based on this tax return and on the information received from the Competent Authority of Paying Agent for all MS where the exchange of information mechanism applies, the Competent Authority of the Beneficial Owner performs a reconciliation of the received information, and issues a notification of the tax to be paid to the Beneficial Owner for the concerned fiscal period.

Upon reception of this tax payment notification, the Beneficial Owner proceeds with the tax payment to its Competent Authority through the banking channel.

3.3.2. Exchange of Information Mechanism for Residual Entity

Figure 5 illustrates the mechanism of information exchange in the case where the Relevant Interest Recipient is the residual Entity. This mechanism covers the cases of automatic and voluntary disclosure schemes.

RIR – Residual

Entity Economic Operator

Gross Interest Saving

Statement of Interest

Residual Entity plays the role

of Paying Agent Interest Payment Information

(Refer to related sections )

Interest Payment Information

Competent Authority of Relevant Interest Recipient

Competent Authority of Economic Operator

MS of Fiscal Residence of Relevant Interest Recipient MS of Economic Operator

Figure 5: Taxation of Savings – Exchange of Information: Mechanism for Residual

Entity

This mechanism is similar to the one described in section 3.3.1, but it covers other actors according to the modelling of the Council Directive: Economic Operator, Residual Entity in its role of Relevant Interest Recipient, and their respective Competent Authorities.

The Economic Operator transmits a statement of interest to the Residual Entity with the gross interest to be paid, and performs the corresponding funds transfer through the banking channel.

At the end of the fiscal period, the Economic Operator transmits to its Competent Authority the information regarding the gross interest it has paid to the Residual Entities during the fiscal period. This information is provided at least on a per Residual Entity basis.

The Competent Authority of the Economic Operator collects all interest payment information from all national Economic Operators, performs a compilation and a break down of this information at least per MS and per Residual Entity, and transmits this information to the Competent Authority of every concerned MS.

The difference with the general mechanism for the exchange of information lies in the absence of taxation of the profits of the Residual Entity by its Competent Authority. The provision of funds to the Residual Entity does not represent any revenue, but rather the sum of all the interest the Residual Entity will pay to its members. For a part of this interest (the part paid to those Residual Entity Members who are individuals resident of a Member State other than the Member State of the Residual Entity), the Residual entity will play the role of Paying Agent.

3.3.3. Withholding Tax Mechanism for Beneficial Owner

Figure 6 illustrates the withholding tax mechanism in the case where the Relevant Interest Recipient is a Beneficial Owner. This mechanism covers the transitional arrangements adopted for some countries to apply a withholding tax on savings owned by non-resident Beneficial Owners according to Art.14 of the Council Directive [A01].

RIR - Beneficial

Owner Net Interest Paying Agent

Statement of Saving

Interest

Certificate of Withholding Tax (Art.1.4)

Withholding Tax Revenue

Interest on

Saving Tax Payment or Declaration Credit

Certificate of Withholding Tax

Withholding Notification Revenue Notification

Tax (Art.1.4)

Tax Payment or Refund

Withholding Tax Revenue Notification

Competent Authority of

Relevant Interest Recipient Withholding Tax

Revenue (75%) Competent Authority of Paying Agent

MS of Fiscal Residence of Relevant Interest Recipient MS of Paying Agent

Figure 6: Taxation of Savings – Withholding Tax Mechanism for Beneficial Owner According to this mechanism, the Paying Agent transmits a statement of interest to the Beneficial Owner with the interest to be paid or guaranteed to the Beneficial Owner after deduction of withholding tax (Net Interest). The Paying Agent performs the corresponding funds transfer through the banking channel. In addition, the Paying Agent transmits a certificate of withholding tax to the Beneficial Owner.

At the end of the fiscal period, the Paying Agent notifies its Competent Authority about the overall withholding tax revenue for the fiscal period. The Paying Agent also performs the corresponding funds transfer to its Competent Authority through the banking channel.

Based on the information received from all national Paying Agents, the Competent Authority breaks down the global withholding tax revenue per MS of fiscal residence of the Beneficial Owners according to their respective weight (in terms of the amount of interest paid to the resident Beneficial Owners), and distributes to the Competent Authority of each concerned MS a part of those weighted funds representing 75% of the revenue from the withholding tax. This credit transfer is accompanied by a notification through banking statement of credit.

The Competent Authority of Paying Agent notifies the Competent Authority of every concerned MS of the amounts transferred for the concerned fiscal period, as a record of the funds transfer.

At the end of the fiscal period, the Beneficial Owner issues for its Competent Authority a tax return which mentions its worldwide income including the taxable interest received for all the savings it owns. The Beneficial Owner encloses the certificate of withholding tax with its tax return.

Based on the amount of taxable income specified in the tax return from the Beneficial Owner, and on the certificate of withholding tax, the Competent Authority of the Beneficial Owner issues a tax notification to the Beneficial Owner for the concerned fiscal period. This notification consists of:

• A tax payment notification if the amount of tax due according to the national law (after

deduction of possible other withholding taxes on the interest) is greater than the withholding tax applied to the interest of the Beneficial Owner as mentioned in the

certificate of withholding tax;

• A tax credit notification, if the amount of tax due according to the national law (after

deduction of possible other withholding taxes on the interest) is lower than this

withholding tax.

Upon reception of this Tax Payment/Credit Notification:

• The Beneficial Owner proceeds with the tax payment for the difference to its Competent

Authority in the first scenario;

• Or, the Competent Authority of the Beneficial Owner performs a tax credit for the

difference in the second scenario.

3.3.4. Withholding Tax Mechanism for Residual Entity

Figure 7 illustrates the withholding tax mechanism in the case where the Relevant Interest Recipient is a Residual Entity. The figure also shows the exchange between the Residual Entity as a Paying Agent and the Residual Entity Member, with the purpose to illustrate the mechanism of the certificate of withholding tax as described in Art.11.5 of the Council Directive [A01].

RIR – Residual Net Interest Net Interest Residual Entity Paying Agent

Entity Member

Statement of Saving Statement of Interest Interest Saving

Certificate of PA Role RIR Role Certificate of Withholding Tax Withholding Tax (Art.11.5 – Art.14) (Art.11.5 – Art.14)

Withholding Tax Revenue

MS of Fiscal Residence of

MS of PA – Residual Entity RIR – Residual Entity Interest on Saving Withholding Tax Overall

Declaration Information for Residual Tax Payment or Entities

Certificate of Credit Notification

Withholding Tax (Art.11.5 – Art.14) Tax Payment or Refund

Withholding Tax Proportionate Revenue (Variable)

Proportionate Revenue Sharing

Information (Art.12.2)

Competent Authority of Relevant Interest Recipient

Competent Authority of MS of Fiscal Residence of Relevant Interest Recipient MS of Paying Agent Paying Agent

Figure 7: Taxation of Savings – Withholding Tax Mechanism for Residual Entity

In the current scenario, the Paying Agent transmits a statement of interest to the Residual Entity with the overall interest to be paid to the Residual Entity Members via the Residual Entity after deduction of the overall withholding tax (Overall Net Interest). The Paying Agent performs the corresponding funds transfer through the banking channel.

The Paying Agent also issues a certificate of Withholding Tax (Art.11.5) for the Residual Entity with the overall amount of the withholding tax.

Upon reception of the statement, of the certificate of withholding tax and of the corresponding overall net amount of interest, the Residual Entity breaks down the net interest to be paid or guaranteed to – or invested for the account of – the Residual Entity Members. The Residual Entity also splits the overall certificate of withholding into individual certificates, mentioning the individual amount of withholding tax for each beneficiary Residual Entity Member who is an individual resident in a Member State other than the Member state of the Residual Entity. The Residual Entity in its role of Paying Agent then sends both the individual statements of interest (Net Interest) and the individual certificates of withholding tax to the beneficiary Residual Entity Members.

The Residual Entity also performs the corresponding payment of net interest to – or the corresponding investment for the account of – the beneficiary Residual Entity Members.

At the end of the fiscal period, the Paying Agent notifies its Competent Authority of the revenue generated by the Withholding Tax for the fiscal period. The Paying Agent also performs the corresponding funds transfer to its Competent Authority through the banking channel.

Consequently, in this scenario the Competent Authority of the Paying Agent does not know the actual MS of the final Residual Entity Member, so that it is not able to evaluate the proportion of the revenues generated by the Residual Entity Members from each MS. The Competent Authority therefore applies a proportion equivalent to the proportion calculated on the revenues from the withholding tax generated by the beneficial owners according to the mechanism described in section 3.3.3.

The Competent Authority of the Paying Agent distributes a proportionate (variable) part of those weighted funds to the Competent Authority of every MS, and notifies each Competent Authority of Relevant Interest Recipient about the transferred proportionate revenue sharing amount for the concerned fiscal period.

At the end of the fiscal period, the beneficiary Residual Entity Member issues a tax return for its Competent Authority, which mentions its worldwide income including the taxable interest received for all the savings it owns. The Residual Entity Member encloses the individual certificate of withholding tax (Art.11.5) with its tax return.

Based on the amount of taxable income mentioned in the tax return from the Residual Entity Member and on the individual certificate of withholding tax, the Competent Authority issues a tax notification to the Residual Entity Member for the concerned fiscal period. This notification consists of:

• A tax payment notification if the amount of tax due according to the national law (after

deduction of possible other withholding taxes on the interest) is greater than the withholding tax applied to the interest of the Residual Entity Member as mentioned in the

certificate of withholding tax;

• A tax credit notification, in the opposite case.

Upon reception of this Tax Payment/Credit Notification:

• The Residual Entity Member effects the tax payment for the difference to its Competent

Authority in the first scenario;

• Or, the Competent Authority of the Relevant Interest Recipient performs a tax credit for

the difference in the second scenario.

3.3.5. Withholding Tax Mechanism with Certificate of Non-Deduction for Beneficial Owner

Figure 8 illustrates the withholding tax mechanism in the case where the Relevant Interest Recipient is a Beneficial Owner in the same context as that described in section 3.3.3 but including the use of a certificate for non-deduction (Art.13.2).

RIR - Beneficial Certificate for Owner non-Deduction (Art.13.2) Paying Agent

Saving Statement of

Interest

Gross Interest

Tax Payment

Certificate for Interest on

non-Deduction Saving Tax Payment No Information on Paid Notification

(Art.13.2) Declaration Interests

No Information on Paid Interests

Competent Authority of Relevant Interest Recipient

Competent Authority of Paying Agent

MS of Residence of Relevant Interest Recipient MS of Paying Agent

Figure 8: Taxation of Savings – Withholding Tax Mechanism with Certificate for non

Deduction

In this scenario, the Beneficial Owner must first receive a certificate of non-deduction from its Competent Authority. The Beneficial Owner transmits this certificate to the Paying Agent. (A refund of the withholding tax is also possible when a certificate of non-deduction is produced after the interest payment. Such a scenario is not described in this section).

Based on this certificate, the Paying Agent does not deduct withholding tax from the interest generated by the savings of the Beneficial Owner. It transmits a statement of interest to the Beneficial Owner with the gross interest to be paid or guaranteed to the Beneficial Owner, and performs the corresponding funds transfer through the banking channel.

At the end of the fiscal period, the Paying Agent has therefore no revenue generated by the withholding tax to be notified and transferred to its Competent Authority, which therefore transfers no funds to the Competent Authority of the Relevant Interest Recipient.

At the end of the fiscal period, the Beneficial Owner issues a tax return for its Competent Authority, which mentions the taxable gross interest received or guaranteed for the savings it owns.

Based on the amount of interest in the tax return from the Beneficial Owner and on other possible withholding taxes on the interest, the Competent Authority notifies the Beneficial Owner of the tax to be paid or credited for the concerned fiscal period.

Upon reception of this tax payment/credit notification, the Beneficial Owner proceeds with the tax payment to its Competent Authority or the Competent Authority proceeds with the tax refund through the banking channel.

3.4. Business Use Case Model

This section provides an overview of the future functionality. It presents the covered business functions then it details the set of business use cases included in the target solution.

A business use case is a sequence of business actions that a business actor performs to achieve a particular business goal.

Table 5 presents all business use cases, split per business actor defined in the business model. Every business use case is presented with an identification code and a short description.

The Business Use Cases that are in the scope of the FS document are highlighted italicised and ticked in the “In scope” column.

All Business Use Cases will be defined in chapter 3. In addition, the in scope Business Use Cases will be exhaustively described from a system perspective in chapter 4 of this document.

Business Use Case Short Description Use Case Id In Scope

Business Actor: Paying Agent

Sends Statement of Interest BUC-PA-010

Sends Interest Payment Information BUC-PA-020

Pays Gross Interest on Savings BUC-PA-030

Receives Disclosure Info Authorisation BUC-PA-040

Deducts Withholding Tax BUC-PA-050

Sends Withholding Tax Information BUC-PA-060

Pays Net Interest On Savings BUC-PA-070

Pays Revenue from Withholding Tax BUC-PA-080

Delivers Certificate of Withholding Tax (Art 14) BUC-PA-090

Delivers Certificate of Withholding Tax (Art 11.5) BUC-PA-100

Receives Certificate for Non-Deduction (Art 13.2) BUC-PA-110

Manages Savings of RIR BUC-PA-120

Manages Certificates from RIR BUC-PA-130

Business Actor: Paying Agent – Residual Entity

Breaks Down Interest Information BUC-PA-RE-010

Breaks Down Interest Payments BUC-PA-RE-020 Business Use Case Short Description Use Case Id In Scope

Breaks Down Withholding Tax Information BUC-PA-RE-030

Business Actor: Economic Operator

Sends Statement of Interest BUC-EO-010

Sends Interest Payment Information BUC-EO-020

Pays Gross Interest on Savings BUC-EO-030

Manages Savings of Residual Entity BUC-EO-040

Qualifies Residual Entity as Paying Agent BUC-EO-050

Business Actor: Relevant Interest Recipient

Receives Statement of Interest BUC-RIR-010

Receives Net Interest Payment BUC-RIR-020

Receives Gross Interest Payment BUC-RIR-030

Transmits Disclosure Info Authorisation BUC-RIR-040

Business Actor: Relevant Interest Recipient - Beneficial Owner

Declares Interest on Savings BUC-RIR-BO-010

Receives Tax Payment Notification BUC-RIR-BO-020

Pays Tax on Interest of Savings BUC-RIR-BO-030

Receives Certificate of Withholding Tax (Art.14) BUC-RIR-BO-040

Receives Tax Credit Notification BUC-RIR-BO-050

Requests Certificate for Non-Deduction (Art 13.2) BUC-RIR-BO-060

Receives Certificate for Non-Deduction (Art 13.2) BUC-RIR-BO-070

Sends Certificate for Non-Deduction (Art 13.2) BUC-RIR-BO-080

Submits Request for Tax Correction BUC-RIR-BO-090

Claims from Tax Overpayment BUC-RIR-BO-100

Business Actor: Relevant Interest Recipient - Residual Entity

Receives Certificate of Withholding Tax (Art 11.5) BUC-RIR-RE-010

Provides Official Evidence of non-Residual Entity State BUC-RIR-RE-020

Business Actor: Competent Authority of Paying Agent

Receives Interest Payment Information BUC-CA-PA-010

Breaks Down Interest Payment Information BUC-CA-PA-020

Transmits Interest Payment Information BUC-CA-PA-030

Cancels Interest Payment Transmission BUC-CA-PA-035

Receives Withholding Tax Information BUC-CA-PA-040

Breaks Down Withholding Tax Information BUC-CA-PA-050

Receives Revenue from Withholding Tax BUC-CA-PA-070

Transfers Revenue from Withholding Tax BUC-CA-PA-080

Receives Request for Correction of Interest Information BUC-CA-PA-090

Analyses the Request for Correction BUC-CA-PA-110

Proceeds with the Correction of the Information BUC-CA-PA-120

Requests Correction from Paying Agent BUC-CA-PA-130

Receives Correction from Paying Agent BUC-CA-PA-140

Transmits Correction of Interest Information BUC-CA-PA-150

Effects a Corrective Transfer of Withholding Tax Revenue BUC-CA-PA-170

Claims from Overpayment BUC-CA-PA-180 Business Use Case Short Description Use Case Id In Scope

Claims for Corrective Payment BUC-CA-PA-190

Manages Paying Agent Data BUC-CA-PA-230

Business Actor: Competent Authority of Economic Operator

Receives Interest Payment Information BUC-CA-EO-010

Breaks Down Interest Payment Information BUC-CA-EO-020

Performs Interest Payment Correction BUC-CA-EO-030

Requests Correction from Economic Operator BUC-CA-EO-040

Receives Correction from Economic Operator BUC-CA-EO-050

Manages Economic Operator Data BUC-CA-EO-060

Business Actor: Competent Authority of Relevant Interest Recipient

Receives Interest of Savings Declaration BUC-CA-RIR-010

Receives Interest Payment Information BUC-CA-RIR-020

Receives Notification of Interest Payment Transmission Cancellation BUC-CA-RIR-030

Receives Certificate of Withholding Tax BUC-CA-RIR-040

Cross-Checks Interest of Savings Information BUC-CA-RIR-050

Delivers Certificate for Non-Deduction (Art 13.2) BUC-CA-RIR-060

Computes Tax on Interest on Savings BUC-CA-RIR-070

Refunds Withholding Tax BUC-CA-RIR-080

Notifies Tax Payment or Credit BUC-CA-RIR-090

Reimburses Overpaid Revenues BUC-CA-RIR-100

Manages Beneficial Owner Parameters BUC-CA-RIR-130

Issues Request for Correction of Interest Information BUC-CA-RIR-150

Receives Correction of Interest Information BUC-CA-RIR-160

Handles Correction BUC-CA-RIR-170

Table 5: Taxation of Savings – List of Business Use Cases

3.5. Business Use Cases Description

The following sections provide a description of the Business Use Cases identified in the Business Use Cases Model. Each section describes the Business Use Case for a given Business Actor.

A global Business Use Cases diagram is presented for each Business Actor, then every Business use Case is described in a dedicated section. Refer to the Annotation appendix in section 7.4.4.1 for the explanation of the template used for the Business Use Case Description.

The following sections make a clear distinction between:

• In scope Business Use Cases, reflecting business processes related to the exchange

processes between the MS according to the exchange of information mechanism requiring

a detailed description level;

• Out of scope Business Use Cases, which are not in the scope of this document, but which

could have an impact to processes or information exchange part of the scope, so that it is

worth having a high-level understanding of those business use cases.

This is reflected in the next sections by using the following legend:

Figure 9: Taxation of Savings – Legend

3.5.1. Paying Agent Use Cases

Figure 10 presents the Business Use Cases identified for the Paying Agent.

Sends Statement of Interest

Manages Sends Interest Certificate from RIR Payment Information

Manage Savings of Pays Gross

RIR Interest on Savings Receives Disclosure

Info Authorisation

Receives Certificate Deducts for non Deduction Withholding Tax (Art. 13. 2)

Paying Agent

Delivers Certificate Sends Withholding of Withholding Tax Tax Information ( Art.11 . 5 )

Delivers Certificate Pays Net Interest Legend : In Scope

of Withholding Tax on Savings ( Art .14)

Out of Scope

Pays Revenue from Withholding Tax

Figure 10: Taxation of Savings – Business Use Cases for the Paying Agent BUC-PA-010 Sends Statement of Interest

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Common

Description:

At the end of the interest period, the Paying Agent sends a statement to the RIR containing the amount of interest the RIR’s savings have attracted. This statement of interest may concern:

• Gross interest, in the context of exchange of information or in the context of

withholding tax mechanism involving certificates of non-deduction (Art.13.2);

• Net interest, in the context of withholding tax mechanism where there is no certificate

of non-deduction.

Constraints: -

BUC-PA-020 Sends Interest Payment Information

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The Paying Agent sends information to its CA on interests paid to or guaranteed for the RIR.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  In countries and territories that operate the withholding tax mechanism with provision for voluntary disclosure, interest payment information can only be provided to the CA if the Paying Agent has received a certificate from the RIR to authorise disclosure of information (see BUC-PA-040).

BUC-PA-030 Pays Gross Interest On Savings

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Common

Description:

The Paying Agent pays the gross interest that is due on the RIR’s savings. For the purposes of the Council Directive, this includes capitalisation of interest or interest not physically paid to the RIR (for example, interest retained and managed by the Paying Agent or invested by the Residual Entity in the role of Paying Agent for the account of the Residual Entity Member).

Constraints:

This business process applies if any of the following constraints is fulfilled:

• 1. 

  In countries or territories that operate the exchange of information taxation mechanism;

• 2. 

  In countries or territories that operate the withholding tax mechanism with provision for voluntary disclosure, if the Paying Agent has received a certificate from the RIR to authorise disclosure of information (see BUC-PA-040).

• 3. 

  In countries or territories that operate the withholding tax mechanism, if the Paying Agent has received a Certificate for Non-Deduction from the RIR (see BUC-PA-110).

BUC-PA-040 Receives Disclosure Info Authorisation

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent receives a Certificate from the RIR authorising it to disclose information on interest payments to its CA.

The Paying Agent records the Certificate for later reference.

Constraints: -

BUC-PA-050 Deducts Withholding Tax

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent deducts withholding tax from the interest payment it makes to the RIR.

The Paying Agent records the amount of withholding tax deducted and the country or territory of fiscal residence of the RIR for later processing.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The Paying Agent has not received a Certificate for Non-Deduction from the RIR (see BUC-PA-110).

BUC-PA-060 Sends Withholding Tax Information

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent sends information to its CA on the global amount of withholding tax it has deducted for the concerned fiscal period, broken down by the country or territory of fiscal residence of the RIR.

Constraints: -

BUC-PA-070 Pays Net Interest on Savings

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent pays the net interest that is due on the RIR’s savings. For the purposes of the Council Directive, this includes capitalisation of interest or interest not physically paid to the RIR (for example, interest retained and managed by the Paying Agent or invested by the Residual Entity in the role of Paying Agent for the account of the Residual Entity Member).

Constraints:

This business process applies if both of the following constraints are fulfilled:

• 1. 

  In countries or territories that operate the withholding tax mechanism with provision for voluntary disclosure, if the Paying Agent has not received a certificate from the RIR to authorise disclosure of information (see BUC-PA-040);

• 2. 

  In countries or territories that operate the withholding tax mechanism, if the Paying Agent has not received a Certificate for Non-Deduction from the RIR (see BUC-PA- 110).

BUC-PA-080 Pays Revenue from Withholding Tax

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent transfers funds to its CA for the amount of withholding tax it has deducted from interest payments made to its RIRs.

Constraints: -

BUC-PA-090 Delivers Certificate of Withholding Tax (Art.14)

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent sends to the RIR a certificate or any other evidence stating the amount of withholding tax that has been deducted from interest payments made to the RIR.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR is an effective Beneficial Owner.

BUC-PA-100 Delivers Certificate of Withholding Tax (Art.11.5)

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent sends to the RIR a certificate or any other evidence stating the amount of withholding tax that has been deducted from interest payments made to the RIR.

Constraints:

This business process applies if any of the following constraint is fulfilled:

• 1. 

  This is an Effective Paying Agent and the RIR is a residual entity

• 2. 

  This is a Residual Entity acting as Paying Agent and the RIR is a Residual Entity Member.

BUC-PA-110 Receives Certificate for Non-Deduction (Art.13.2)

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The Paying Agent receives a Certificate issued by the CA of the fiscal residence of the RIR stating that withholding tax must not be deducted from interest payments made for a specific account or security belonging to the RIR.

The Paying Agent records the information for later reference.

Constraints: -

BUC-PA-120 Manages Savings of RIR

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Common

Description:

The Paying Agent deals with the overall management of the information of its RIR’s savings.

Constraints: -

BUC-PA-130 Manages Certificates from RIR

Actor: Paying Agent Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The Paying Agent manages the following types of certificates received from the RIR:

• Certificate of Non-Deduction of Withholding Tax (Art.13.2);

• Certificate for Tax Residence in a Third Country (Art.3);

• Certificate for being treated as a UCITS (Art.4.3);

• Certificate for Business Taxation (Art.4.2.b).

The Paying Agent must ensure that the validity period of the certificate is respected.

Constraints: -

3.5.2. Paying Agent – Residual Entity Use Cases

Figure 11 presents the specific Business Use Cases identified for the Residual Entity acting as a Paying Agent.

Those business use cases assume that the Paying Agent – Residual entity is established in a country or territory that recognises the concept of Residual Entity. These countries and territories are specified in section 7.2 of the current document.

Figure 11: Taxation of Savings – Business Use Cases for the PA – Residual Entity BUC-PA-RE-010 Breaks Down Interest Information

Actor: Paying Agent – Residual Entity Domain: National Private

Taxation Mechanism: Common

Description:

Based on the statement of interest and on the interest payment received from the Paying Agent (Withholding Tax taxation mechanism) or from the Economic Operator (Exchange of Information taxation mechanism) and on the distribution method managed internally, the Paying Agent – Residual Entity apportions the global amount of interest to the Beneficial Owners.

In the specific Withholding Tax taxation mechanism, the Paying Agent – Residual Entity takes into account the apportioned withholding tax amount to calculate the amount of interest to be paid to the Beneficial Owners (Refer to BUC-PA-RE-030).

Constraints:

This business process applies if all of the following constraints are fulfilled:

• 1. 

  The Residual Entity in its role of RIR has received the statement of interest from the Paying Agent or Economic Operator (See BUC-RIR-010);

• 2. 

  The Residual Entity in its role of RIR has received the interest payment from the Paying Agent or Economic Operator (See BUC-RIR-020 and BUC-RIR-030);

• 3. 

  In the Withholding Tax taxation mechanism, the computation of the withholding tax amount to be apportioned to the Beneficial Owners is completed (See BUC-PA-RE- 030).

BUC-PA-RE-020 Breaks Down Interest Payments

Actor: Paying Agent – Residual Entity Domain: National Private

Taxation Mechanism: Common

Description:

Based on the calculated amount of interest to be paid to the Beneficial Owners, the Paying Agent – Residual Entity prepares interest payments for Beneficial Owners.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The computation of the interest to be paid must be completed (See BUC-PA-RE-010) BUC-PA-RE-030 Breaks Down Withholding Tax Information

Actor: Paying Agent – Residual Entity Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

Based on the certificate of Withholding Tax received from the Paying Agent (Art.11.5) and on the distribution method managed internally, the Paying Agent – Residual Entity apportions the global amount of withholding tax deducted by the Paying Agent to the Beneficial Owners.

The Paying Agent – Residual Entity fills in the corresponding certificates of withholding tax with personal information of the Effective Beneficial Owners (Art.14) or the Residual Entity Members (Art.11.5), according to the process described in BUC-PA-090 and BUC-PA-100.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The Residual Entity in its role of RIR must have received the certificate of withholding tax from the Paying Agent (See BUC-RIR-RE-010),

3.5.3. Economic Operator Use Cases

Figure 12 presents the specific Business Use Cases identified for the Economic Operator.

By the definition of the Economic Operator Business Actor, these business use cases are applicable to the Exchange of Information taxation mechanism only.

Figure 12: Taxation of Savings – Business Use Cases for the Economic Operator BUC-EO-010 Sends Statement of Interest

Actor: Economic Operator Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

At the end of the interest period the Economic Operator sends a statement to the RIR – Residual Entity containing the amount of interest RIR’s savings have attracted. This statement of interest always concerns gross interest paid to a Residual Entity.

Constraints: -

BUC-EO-020 Sends Interest Payment Information

Actor: Economic Operator Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The Economic Operator sends information to its CA on interest it has paid to the RIR – Residual Entity.

Constraints: -

BUC-EO-030 Pays Gross Interest On Savings

Actor: Economic Operator Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The Economic Operator pays the gross interest that is due on the RIR – Residual Entity’s savings.

Constraints: -

BUC-EO-040 Manages Savings of Residual Entity

Actor: Economic Operator Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The Economic Operator deals with the overall management of the information of its RIR - Residual Entities’ savings.

Constraints: -

BUC-EO-050 Qualifies Residual Entity as Paying Agent

Actor: Economic Operator Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The Economic Operator certifies that a RIR - Residual Entity acts as a Paying Agent with regard to the Beneficial Owners by checking that none of the following conditions applies, according to Art.4.2:

• It is a legal person, except for o (a) in Finland: avoin yhtiö (Ay) and kommandiittiyhtiö (Ky)/öppet bolag and

kommanditbolag;

o (b) in Sweden: handelsbolag (HB) and kommanditbolag (KB).

• It has its profits taxed under the general arrangements for business taxation;

• It is a UCITS recognised in accordance with Directive 85/611/EEC i.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The Economic Operator has received the necessary documentation from Paying Agents.

3.5.4. Relevant Interest Recipient Use Cases

Figure 13 presents the generic Business Use Cases identified for the Relevant Interest Recipient.

Figure 13: Taxation of Savings – Business Use Cases for the Relevant Interest Recipient

BUC-RIR-010 Receives Statement of Interest

Actor: Relevant Interest Recipient Domain: National Private

Taxation Mechanism: Common

Description:

At the end of an interest period, the RIR receives a statement of the amount of interest its savings have attracted. This statement of interest may concern:

• Gross interest, in the context of exchange of information or in certain cases of

withholding tax involving certificates of non-deduction;

• Net interest, in the other cases under withholding tax mechanism.

Constraints: -

BUC-RIR-020 Receives Net Interest Payment

Actor: Relevant Interest Recipient Domain: National Private

Taxation Mechanism: Withholding Tax

Description:

The RIR receives a payment for the amount of interest its savings have attracted after the deduction of withholding tax (net interest). This payment could be in the form of capitalisation of the interest, or it may not be physically received by the RIR (for example, it could be retained and managed by the Paying Agent or invested by the Residual Entity in the role of Paying Agent for the account of the Residual Entity Member).

Constraints: -

BUC-RIR-030 Receives Gross Interest Payment

Actor: Relevant Interest Recipient Domain: National Private

Taxation Mechanism: Common

Description: The RIR receives a payment for the amount of interest its savings have attracted. This payment could be in the form of capitalisation of the interest, or it may not be physically received by the RIR (for example, it could be retained and managed by the Paying Agent or invested by the Residual Entity in the role of Paying Agent for the account of the Residual Entity Member).

Constraints: -

BUC-RIR-040 Transmits Disclosure Info Authorisation

Actor: Relevant Interest Recipient Domain: National Private

Taxation Mechanism: Exchange of Information

Description:

The RIR sends to the Paying Agent a Certificate authorising the Paying Agent to disclose the information regarding the RIR and to apply all the processes related to the Exchange of Information taxation mechanism, such as payment of gross interest and transmission of Interest Payment Information to the CA of PA.

Constraints: -

3.5.5. Relevant Interest Recipient – Beneficial Owner Use Cases

Figure 14 presents the specific Business Use Cases identified for the Beneficial Owner.

Figure 14: Taxation of Savings – Business Use Cases for the Beneficial Owner

BUC-RIR-BO-010 Declares Interest on Savings

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Common

Description:

The RIR - BO declares the interest his savings have attracted to the CA of his fiscal residence.

In the context of a withholding tax taxation mechanism, the RIR - BO attaches a certificate or any other evidence of Withholding Tax to its tax return.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR - BO has received the statement of interest from his Paying Agent.

In the context of a withholding tax taxation mechanism, this business process requires the following additional constraint to be fulfilled:

• 2. 

  The RIR – BO has received a Certificate of Withholding Tax (Art.11.5 or Art.14) from his Paying Agent;

BUC-RIR-BO-020 Receives Tax Payment Notification

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Common

Description:

The RIR - BO receives from the CA of his fiscal residence a notification of taxes due on his savings interest.

Constraints: -

BUC-RIR-BO-030 Pays Tax on Interest of Savings

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Common

Description:

The RIR – BO pays the income tax due on the interest of his savings based on the amounts mentioned in the tax payment notification.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR – BO has received a tax payment notification from its CA.

BUC-RIR-BO-040 Receives Certificate of Withholding Tax (Art.14)

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Withholding Tax

Description:

The RIR - BO receives from the Paying Agent a certificate or any other evidence stating the amount of tax that has been deducted from his savings interest.

If the Beneficial Owner is an Effective Beneficial Owner, the Certificate is covered by Art.14. If the Beneficial Owner is a Residual Entity Member, the certificate is covered by Art.11.5.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR – BO has received an interest payment from which withholding tax has been deducted according to Art.11.

BUC-RIR-BO-050 Receives Tax Credit Notification

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Withholding Tax

Description:

The RIR - BO receives a tax credit notification from the CA of his fiscal residence for the amount of tax that he has overpaid.

Constraints:

This business process applies if both of the following constraints are fulfilled:

• 1. 

  The RIR – BO has received an interest payment from which withholding tax has been deducted under Art.11;

• 2. 

  The amount of withholding tax deducted by the Paying Agent is more than the tax rules of the fiscal residence of the RIR - BO require.

BUC-RIR-BO-060 Requests Certificate for Non-Deduction (Art.13.2)

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Withholding Tax

Description:

The RIR - BO applies to the CA of his fiscal residence for a Certificate allowing him to receive interest without deduction of withholding tax.

Constraints: -

BUC-RIR-BO-070 Receives Certificate for Non-Deduction (Art.13.2)

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Withholding Tax

Description:

The RIR - BO receives a Certificate for Non-Deduction (Art.13.2) from the CA of his fiscal residence.

Constraints: -

BUC-RIR-BO-080 Sends Certificate for Non-Deduction (Art.13.2)

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Withholding Tax

Description:

The RIR - BO transmits the Certificate for Non-Deduction (Art.13.2) to the Paying Agent.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR - BO has received a Certificate for Non-Deduction from the CA of his fiscal residence.

BUC-RIR-BO-090 Submits Request for Tax Correction

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Common

Description:

Based on the received interests and, if relevant, on the withholding tax deduction, the RIR - BO considers that the tax assessed on interest payments by the CA of his fiscal residence is incorrect, so that the RIR - BO asks the CA of his fiscal residence to correct the tax assessment.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR - BO has received an erroneous tax credit notification or a tax payment notification.

BUC-RIR-BO-100 Claims from Tax Overpayment

Actor: Relevant Interest Recipient – Beneficial Domain: National Private

Owner

Taxation Mechanism: Withholding Tax

Description:

The RIR – BO submits a claim for a tax refund to the CA of his fiscal residence, as a legal procedure after rejection by the CA of his fiscal residence of his request for Tax Correction.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The Request for Tax Correction submitted by the RIR – BO to the CA of his fiscal residence has been processed and rejected.

3.5.6. Relevant Interest Recipient – Residual Entity

Figure 15 presents the specific Business Use Cases identified for the Residual Entity acting as Relevant Interest Recipient.

Receives Certificate of Withholding Tax (Art.11.5)

Provides Official Evidence of non-Residual Entity

State

Legend: In Scope

Out of Scope RIR - Residual Entity

Figure 15: Taxation of Savings – Business Use Cases for the RIR – Residual Entity

BUC-RIR-RE-010 Receives Certificate of Withholding Tax (Art.11.5)

Actor: Relevant Interest Recipient – Residual Domain: National Private

Entity

Taxation Mechanism: Withholding Tax

Description:

The RIR – Residual Entity receives a Certificate from the Paying Agent stating the amount of withholding tax that has been deducted from the savings interest.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR – Residual Entity has received an interest payment from which withholding tax has been deducted according to Art.11.

BUC-RIR-RE-020 Provides Official Evidence of non-Residual Entity State

Actor: Relevant Interest Recipient – Residual Domain: National Private

Entity

Taxation Mechanism: Withholding Tax

Description:

The RIR – RE demonstrates to the Economic Operator that it does not act as a Residual Entity, by any of the following means:

• Producing official evidence that it is a legal person;

• Producing official evidence that its profits are submitted to business taxation;

• Providing the Economic Operator with a UCITS certificate recognised in accordance

with Directive 85/611/EEC i

Figure 16 contains a flow diagram that describes the process for identifying a Residual Entity.

Constraints: -

Figure 16: Taxation of Savings – Flow Diagram for Identifying Residual Entity.

3.5.7. Competent Authority of Paying Agent Use Cases

Figure 17 presents the Business Use Cases identified for the CA of PA.

Figure 17: Taxation of Savings – Business Use Cases for the CA of the Paying Agent

BUC-CA-PA-010 Receives Interest Payment Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of PA receives information on interest payments made to – or guaranteed for – RIRs during the concerned fiscal period. The concerned RIRs have their fiscal residence in a MS or a territory applying the principle of reciprocal information exchange. The list of those MS and territories is presented in the appendix of the current document, section 7.2. This principle does not apply to Third Countries.

The CA of PA validates the information syntactically and semantically, and stores the information for later processing.

Constraints: -

BUC-CA-PA-020 Breaks Down Interest Payment Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

Based on the interest payment information received from the national Paying Agents, validated syntactically and semantically, the CA of PA performs the following processing:

• 1. 

  Compiling the interest payment information from the different Paying Agents;

• 2. 

  Grouping this information by MS or territory requiring reciprocal information exchange;

• 3. 

  Further grouping this information at least by RIR.

The CA of PA stores the grouped information for later processing.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has received syntactically and semantically valid interest payment information from the national Paying Agents.

  BUC-CA-PA-030 Transmits Interest Payment Information

  Actor: CA of PA Domain: National Public

  Taxation Mechanism: Exchange of Information

  Description:

  The CA of PA transmits with the agreed format the interest payment information to all CA of RIR for which it has information.

  The main and back up transmission channels need to be agreed between Competent Authorities.

  If the CA of PA receives a rejection message for the transmission, this means that the CA of RIR has detected a syntax error in the message. In this case, the CA of PA must make the necessary corrections and repeat the process.

Around the same time of the transmission of interest payment information the CA of PA must

also send a Technical Sheet 1 to the CA of RIR summarising the content of the transmission.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has broken down the interest payment information according to the principles specified in BUC-CA-PA-020.

BUC-CA-PA-035 Cancels Interest Payment Transmission

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of PA tells the CA of RIR, to which it has transmitted interest payment information, that this information must be discarded.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has transmitted interest payment information.

EN 57 EN

BUC-CA-PA-040 Receives Withholding Tax Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

The CA of PA receives information from Paying Agents specifying the overall amount of withholding tax deducted under Art.11 for the concerned fiscal period. This information is broken down by the country or territory of the RIR.

In countries and territories that recognise the concept of a “Residual Entity”, the CA of PA receives, in addition, information about the overall amount of withholding tax deducted from interest payments made to the whole community of RIR - Residual Entities established in the European Union.

Constraints: -

BUC-CA-PA-050 Breaks Down Withholding Tax Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

Scenario 1: Break Down of Withholding Tax Information related to RIR – Beneficial Owner

The CA of PA summarises withholding tax information related to Art.11.1-3 by country or territory of fiscal residence.

75% of the sum total per country or territory of fiscal residence is allocated to that country or territory; 25% of the sum total is retained by the CA of PA.

Scenario 2: Break Down of Withholding Tax Information related to RIR – Residual Entity

The CA of PA summarises withholding tax information related to Art.11.5. The country or territory of fiscal residence of the Effective Beneficial Owner / Residual Entity Member is not known.

75% of the sum total is distributed to countries and territories in the same proportion that the overall revenue in Scenario 1 was distributed to these countries and territories.

25% of the sum total is retained by the CA of PA.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has received withholding tax information from one or more paying agents.

BUC-CA-PA-070 Receives Revenue from Withholding Tax

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

The CA of PA receives a transfer of funds from the national Paying Agents representing the overall amount of withholding tax revenue deducted from interest payments to the RIRs.

Constraints: -

BUC-CA-PA-080 Transfers Revenue from Withholding Tax

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

Based on the computed amount of withholding tax broken down per CA of RIR, the CA of PA prepares and transfers funds to all CA of RIR who are due withholding tax revenue.

These transfers of funds are made through the banking channel and respect arrangements agreed between the Competent Authorities such as the identification of the bank accounts.

Around the same time as the transfer of withholding tax revenue, the CA of PA must also

send a Technical Sheet 2 to the CA of RIR summarising the tax transfer.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has broken down the withholding tax information according to the principles specified in BUC-CA-PA-050.

EN 60 EN

BUC-CA-PA-090 Receives Request for Correction of Interest Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of PA receives from a CA of RIR, a request for correction of the information concerning one or more interest payments.

The CA of PA performs a syntactical validation of the request (which may be done immediately or during processing of the request). If there is a syntax error, the CA of PA may send a rejection message to the CA of RIR, but it is not obliged to do this.

Exception Scenario:

At any time after receiving a request for correction the CA of PA may be notified by the CA of RIR that the correction is no longer required. The CA of PA must then stop its investigations and, if necessary, must inform the PA that the correction is not needed.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has transmitted interest payment information to the CA of RIR for the concerned interest payment items.

BUC-CA-PA-110 Analyses the Request for Correction

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of PA analyses the content of the request for correction to determine the piece of information to be corrected and the correction to be brought to this piece of information.

If the CA of PA concludes that the process of the request for correction requires information from the Paying Agent, it issues a request for correction to the Paying Agent according to the process described in BUC-CA-PA-130.

Exception Scenario:

If the analysis results in no correction to do, the CA of PA rejects the request for correction.

Table 39 lists the valid reasons for rejecting a request for correction.

Constraints:

This business process applies if the following constraints are fulfilled:

• 1. 

  The CA of PA has transmitted interest payment or withholding tax information to the CA of RIR;

• 2. 

  Any of the following conditions:

  • a. 

    The CA of PA has received a valid request for correction of a piece of information that was sent as part of the initial transmission;

  • b. 

    The CA of PA has received an internal request for correction.

BUC-CA-PA-120 Proceeds with the Correction of the Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

Resulting from the analysis process of correction described in BUC-CA-PA-110 or from a (interest payment or withholding tax information) requirement of correction received from the Paying Agent, the CA of PA makes the necessary corrections in its data set, and prepares the corrected information for transmission to the requestor (either internal or the CA of RIR)

Constraints:

This business process applies if any of the following constraints is fulfilled:

• 1. 

  The analysis process described in BUC-CA-PA-110 came to the conclusion that information has to be corrected;

• 2. 

  The CA of PA has received a message from a Paying Agent requiring a correction of information regarding interest payment or withholding tax.

BUC-CA-PA-130 Requests Correction from Paying Agent

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

Resulting from the analysis process of correction described in BUC-CA-PA-110, the CA of PA prepares a request for correction (interest payment or withholding tax) information that it needs from the Paying Agent.

The CA of PA transmits the request to the Paying Agent and waits for the response. The request is transmitted through the communication channel agreed between the CA of PA and the Paying Agent.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The analysis process described in BUC-CA-PA-110 concluded that information could be corrected only with input from the Paying Agent.

BUC-CA-PA-140 Receives Correction from Paying Agent

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of PA receives correction (interest payment or withholding tax) information from the Paying Agent by means of a supplementary declaration.

Constraints:

This business process applies if any of the following constraints is fulfilled:

• 1. 

  The CA of PA has sent a request for correction of information to the Paying Agent;

  • 2. 

    The Paying Agent uncovered information that has to be corrected.

BUC-CA-PA-150 Transmits Correction of Interest Payment Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of PA transmits the interest payment information correction to the CA of RIR. This transmission may also involve rejection of interest payment correction requests.

If the CA of PA receives a rejection message for the transmission, this means that the CA of RIR has detected a syntax error in the message. In this case, the CA of PA must make the necessary corrections and repeat the process.

Constraints:

This business process applies if one of the following constraints is fulfilled:

• 1. 

  The CA of PA has proceeded with the correction of information according to the process defined in BUC-CA-PA-120;

• 2. 

  The CA of PA has analysed the request for correction and has rejected it according to the process defined in BUC-CA-PA-110.

BUC-CA-PA-170 Effects a Corrective Transfer of Withholding Tax Revenue

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

Resulting from the correction process of withholding tax described in BUC-CA-PA-120, the CA of PA prepares and performs a corrective transfer of revenue from withholding tax, in the form of a credit to the CA of RIR.

This funds transfer is done through the banking channel and respects arrangements agreed between the Competent Authorities, such as the identification of the bank accounts.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The correction process results in a corrective transfer of withholding tax to the CA of RIR in the form of a credit.

BUC-CA-PA-180 Claims from Overpayment

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

Resulting from the correction process of withholding tax described in BUC-CA-PA-120, the CA of PA issues a claim from overpayment to the CA of RIR.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The correction process results in an overpayment of withholding tax to the CA of RIR.

BUC-CA-PA-190 Claims for Corrective Payment

Actor: CA of PA Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

Resulting from the correction process of withholding tax described in BUC-CA-PA-120, the CA of PA issues a claim for corrective payment to the Paying Agent.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The correction process results in a corrective transfer of funds from the Paying Agent for the overdue withholding tax revenue.

BUC-CA-PA-230 Manages Paying Agent Data

Actor: CA of PA Domain: National Public

Taxation Mechanism: Common

Description: The CA of PA maintains the information it needs to deal effectively with Paying Agents, such as contact information, TIN, etc.

Constraints: -

3.5.8. Competent Authority of Economic Operator Use Cases

Figure 18 presents the Business Use Cases identified for the CA of EO.

Receives Interest Payment Information

Breaks down Interest Payment Information

Performs Interest Payment Corrections

Requests Correction from Economic Operator

CA of Economic Operator

Receives Correction from Economic Operator

Legend: In Scope

Claims from Out of Scope

Overpayment

Manages Economic Operator Data

Figure 18: Taxation of Savings – Business Use Cases for the CA of the Economic

Operator

BUC-CA-EO-010 Receives Interest Payment Information

Actor: CA of EO Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of EO receives information on interest payments made to – or guaranteed for – RIRs during the concerned fiscal period. The concerned RIRs have their fiscal residence in a MS or a territory applying the principle of reciprocal information exchange. The list of those MS and territories is presented in the appendix of the current document, section 7.2. This principle does not apply to Third Countries.

Constraints: -

BUC-CA-EO-020 Breaks Down Interest Payment Information

Actor: CA of EO Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of EO processes each new data set received from the Economic Operator:

o Information is grouped by MS or territory requiring reciprocal disclosure;

o Information is further grouped by RIR.

The CA of EO stores the grouped information for later processing.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of EO has received interest payment information from one or more Economic Operators.

BUC-CA-EO-030 Performs Interest Payment Correction

Actor: CA of EO Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

If the CA of EO has received a correction request message, it analyses the content of the message to help it determine which information needs to be corrected.

If the CA of EO decides that the corrections can be made without reference to the Economic Operator, the CA of EO makes the necessary corrections in its data set.

If the CA of EO decides that the corrections require information from the Economic Operator, the CA of EO requests correction from the Economic Operator (see use cases BUC-CA-EO- 040 and BUC-CA-EO-050).

Constraints:

This business process applies if the following constraints are fulfilled:

• 1. 

  The CA of EO has transmitted interest payment information to a CA of RIR.

• 2. 

  The CA of EO:

• has received a message from the CA of RIR requesting that some interest

payment information be corrected; or

• has uncovered an error in the interest payment information it has transmitted to

the CA of RIR.

BUC-CA-EO-040 Requests Correction from Economic Operator

Actor: CA of EO Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of EO prepares a request for the correction information that it needs from the Economic Operator.

The CA of EO transmits the request to the Economic Operator and waits for a response.

The transmission is through the channel agreed between the CA of EO and the Economic Operator.

Constraints:

This business process applies if any of the following constraints is fulfilled:

• 1. 

  The CA of EO has received a request for correction of interest payment information from a CA of RIR.

• 2. 

  The CA of EO has uncovered an error in the interest payment information it has received from the Economic Operator.

BUC-CA-EO-050 Receives Correction from Economic Operator

Actor: CA of EO Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of EO receives correction information from the Economic Operator.

The CA of EO updates its data set with the correction information.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of EO has sent a request for correction of information to the Economic Operator.

BUC-CA-EO-060 Manages Economic Operator Data

Actor: CA of EO Domain: National Public

Taxation Mechanism: Exchange of Information

Description: The CA of EO maintains the information it needs to deal effectively with economic operators, such as contact information, TIN, etc.

Constraints: -

3.5.9. Competent Authority of Relevant Interest Recipient Use Cases

Figure 19 presents the Business Use Cases identified for the CA of RIR. These Business Use Cases are subject to the general assumption that the CA of RIR is in a country or territory that taxes interest on savings.

Figure 19: Taxation of Savings – Business Use Cases for the CA of the Relevant Interest Recipient

BUC-CA-RIR-010 Receives Interest of Savings Declaration

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Common

Description:

After the end of a fiscal year, the CA of RIR receives a tax return from the RIR declaring the amount of interest it has received on savings.

In the context of the withholding tax taxation mechanism, the CA of RIR receives, in addition, the Certificate of Withholding Tax or any evidence stating the amount of withholding tax that has been deducted, attached to the tax return of the RIR – BO.

Constraints: -

BUC-CA-RIR-020 Receives Interest Payment Information

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of RIR receives information from a CA of PA concerning interest payments made to individuals whose fiscal residence is within its jurisdiction. The information is received in the agreed format.

The main and back up transmission channels need to be agreed between Competent Authorities.

The CA of RIR validates the received information syntactically.

If the information is valid, the CA of RIR stores the information for later processing.

If the information provided is not valid, the CA of RIR may send a rejection message to the CA of PA, identifying the piece of information that failed the syntactical validation, but it is not obliged to do this.

Constraints: -

BUC-CA-RIR-030 Receives Notification of Interest Payment Transmission Cancellation

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of RIR receives notification from a CA of PA that a transmission of interest payment information by the latter must be cancelled.

The CA of RIR does everything necessary to remove the interest payment information from its systems.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has transmitted interest payment information to a CA of RIR.

BUC-CA-RIR-040 Receives Certificate of Withholding Tax

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

The CA of RIR receives the certificate from the RIR – Beneficial Owner and ensures that it is valid.

If the Beneficial Owner is an Effective Beneficial Owner, the Certificate is covered by Art.14. If the Beneficial Owner is a Residual Entity Member, the certificate is covered by Art.11.5.

Constraints:

This business process applies if the following constraints are fulfilled:

• 2. 

  The RIR has had withholding tax deducted under Art.11 from interest payments received in a country or territory other than its fiscal residence.

• 3. 

  The RIR has received a certificate stating how much withholding tax was deducted from interest payments.

BUC-CA-RIR-050 Cross-Checks Interest of Savings Information

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

This Business Use Case covers the crosschecking of the interest payment information reported on the tax return from the RIR (BUC-CA-RIR-010) with the interest payment information received from the CA of PA (BUC-CA-RIR-020) in exchange of information – automatic or with voluntary disclosure – taxation mechanism.

This comparison is based on the following business information:

• RIR: The name, address, date of birth, city of birth, TIN (or any other identification

number) and any other information which is at the disposal of the CA of RIR;

• Paying Agent: The account number and address.

Scenario 1 – The interest payment information received from the CA equals the interest payment amount declared by the RIR.

The CA of RIR takes the following action:

• Compute the Tax Payment for the amount of interest reported in both the RIR tax

return and the interest payment information, according to the process described in

BUC-CA-RIR-090.

Scenario 2 – The interest payment information received from the CA does not equal the interest payment amount declared by the RIR.

The CA of RIR may take one of the following actions:

• Ask the RIR to explain the difference;

• Compute the tax Payment on basis of the information provided by the CA of PA,

according to the process described in BUC-CA-RIR-090;

• Request the CA that provided the information for a correction;

• Any other action to resolve the discrepancy.

Scenario 3 – There is no interest payment information received from the CA

The CA of RIR may take one of the following actions:

• Compute the tax Payment on basis of the information provided by the RIR, according

to the process described in BUC-CA-RIR-090;

• Ask the RIR to check the interest on savings declared in its tax return;

• Request the CA that provided the information for a correction;

• Any other action to resolve the discrepancy.

Scenario 4 – The RIR has not declared interest payment information, but there is interest payments information received from CA of PA for the given RIR

The CA of RIR may take one of the following actions:

• Seek clarification from the RIR;

• Compute the tax Payment on basis of the information provided by the CA of PA,

according to the process described in BUC-CA-RIR-090;

• Request the CA that provided the information for a correction;

• Any other action to resolve the discrepancy

Constraints: -

BUC-CA-RIR-060 Delivers Certificate for Non-Deduction (Art.13.2)

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

The CA of RIR verifies that the request received from the RIR – BO is valid and contains all required information.

The CA of RIR prepares the certificate, including a period of validity that may not be more than three years.

The CA of RIR sends the certificate to the RIR – BO.

Note: The certificate must be delivered within a period of two months starting the date it was requested by the RIR – BO.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The RIR – BO has submitted to the CA of RIR of his fiscal residence a request for a Certificate for Non-Deduction under Art.13.2.

BUC-CA-RIR-070 Computes Tax on Interest on Savings

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Common

Description:

Using the information received from all CA of PA on interest payments made to the RIR (BUC-CA-RIR-020), the tax return received from the RIR (BUC-CA-RIR-010), and taking into account any Certificates of Withholding Tax received from the RIR (BUC-CA-RIR-050), the CA of RIR calculates the amount of tax that is due on the interest payments according to the laws and regulations in force in the country or territory of the CA of RIR.

This computation may result in a tax to be paid by the RIR in any of the following situations:

• Under the exchange of information mechanism;

• Under the withholding tax mechanism, in the case where the beneficial owner received

gross interests as remuneration of his savings, according to the certificate of nondeduction transmitted to the Paying Agent;

• Under the withholding tax mechanism, when the national tax of the MS of fiscal

residence of the RIR is higher than the withholding tax applied to the savings in the

country of the Paying Agent.

This computation may result in a tax to be credited to the RIR in the following situation:

• Under the withholding tax mechanism, when the national tax of the MS of fiscal

residence of the RIR is less than the withholding tax applied to the savings in the

country of the Paying Agent.

Constraints:

This business process applies if the following constraints are fulfilled:

• 1. 

  The CA of RIR has received the tax return from the RIR – BO

• 2. 

  Under the exchange of information mechanism, the CA of RIR has received the information on paid interest from the CA of PA

• 3. 

  The CA of RIR has calculated the income tax due.

BUC-CA-RIR-080 Refunds Withholding Tax

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

The CA of RIR makes a payment to the RIR to refund the excess withholding tax deducted from his interest payment.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  According to tax computation on interest of savings, the amount of withholding tax deducted was too high.

BUC-CA-RIR-090 Notifies Tax Payment or Credit

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Common

Description:

The CA of RIR sends a notification to the RIR containing the amount of tax that is due, or tax credit that will be given, on interest payments made to the RIR.

Scenario 1 – The tax computation showed that the RIR has not paid the due amount of tax on interest of savings, according to the computation process specified in BUC-CA-RIR-90

According to this scenario, the CA of RIR takes the following action:

• Sends a tax payment notification to the RIR with the remaining amount to be paid by

the RIR.

Scenario 2 – The tax computation showed that the RIR has been overtaxed for his interest of savings, according to the computation process specified in BUC-CA-RIR-90.

According to this scenario, the CA of RIR takes the following action:

• Sends a tax credit notification to the RIR with the amount to be credited to the RIR.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has computed the tax due on interest payments (BUC-CA-RIR-090).

BUC-CA-RIR-100 Reimburses Overpaid Revenues

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Withholding Tax

Description:

Resulting from the correction process of withholding tax described in BUC-CA-PA-120 and from the claim from overpayment issued by the CA of PA, the CA of RIR carries out a funds transfer for the overpaid amount of withholding tax revenue to the CA of PA.

Constraints:

This business process applies if the following constraints are fulfilled:

• 1. 

  The CA of RIR has received withholding tax revenue from a CA of PA.

• 2. 

  Due to subsequent corrections, the CA of PA issued a claim from overpayment of withholding tax revenue to the CA of RIR, according to process BUC-CA-PA-180.

BUC-CA-RIR-130 Manages Beneficial Owner Parameters

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Common

Description:

The CA of RIR maintains the information it needs to deal effectively with beneficial owners, such as contact information, TIN, etc.

Constraints: -

BUC-CA-RIR-150 Issues Request for Correction of Interest Information

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of RIR detects or suspects an error in interest payment information. This may result from a query from the relevant interest recipient, or from the CA of RIR’s own analyses.

The CA of RIR clearly identifies the information that needs or should need correction.

Prior to sending a correction request the CA or RIR must exhaust all possible means at national level to resolve the issue. If a correction request is deemed necessary, the CA of RIR sends such a request to the CA of PA that originally supplied the interest payment information. The request contains all of the information needed by the CA of PA to analyse and correct the information.

If the CA of RIR receives a rejection message for the request for correction it submitted, this means that the CA of PA has detected a syntax error in the request. In this case the CA of RIR must correct the request and submit it again.

Note 1: The CA of RIR must limit the requests for correction for information in the strict scope of the Directive.

Note 2: If the CA of RIR decides that it no longer needs the correction information, the CA of RIR may cancel the request for correction.

Note 3: In very specific circumstances the tax payer can report to its tax authority payments falling under the Council Directive but for which no information was reported. This can happen for the following reasons:

• - 

  the Paying Agent did not fulfil its obligations and did not report some information falling under the Council Directive;

• - 

  a technical problem at the CA of PA resulted in only partial transmission of information.

If the request for correction involves such information the CA of RIR must first exhaust all other possible means at its disposal before asking the CA of PA for a correction. For example it should ask the taxpayer to provide proof of the interest payment. A request for correction in these circumstances must contain a full dossier of information provided by the taxpayer in so far as it is relevant to the case and can legally be provided.

Note 4: Before submitting a request for correction, the CA of RIR should consider if the amount of money involved justifies the cost to the CA of PA and the PA of processing the request.

Constraints: This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has exhausted all possible means at national level to find the answer.

BUC-CA-RIR-160 Receives Correction of Interest Information

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

The CA of RIR receives the correction from CA of PA, or notification that its request for correction has been rejected, according to the standard format for exchange of interest payments information.

The CA of RIR performs a syntactical validation of the received correction. If the information provided is not valid, the CA of RIR may send a rejection message to the CA of PA, identifying the piece of information that failed the syntactical validation, but it is not obliged to do this.

Constraints: -

BUC-CA-RIR-170 Handles Correction

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information

Description:

Based on a valid correction received from CA of PA, the CA of RIR performs the necessary updates to its local dataset, and proceeds with the related internal process.

Constraints:

This business process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has received a valid response to its request for Correction.

3.6. Conceptual Data Model

This section indicates at a high level the relationships between the main entities in the data model. The term “entity” is used to refer to any business object in the model, and should not be confused with the specific use of the word found in Art. 4 of the Council Directive.

A conceptual entity-relationship model shows how the business world sees information. It suppresses non-critical details in order to emphasise business rules and user objects. It typically includes only significant entities that have business meaning, along with their relationships.

Section 7.4.1 explains the notation used in the diagrams in this section. These diagrams indicate the different views that the relevant business actors have on the data, depending on the functional context.

3.6.1. Main Entities

The entities considered are:

• Payment: this represents the information that will be exchanged for a payment of interest;

• Residual Entity: this represents the recipient of a payment under Art. 4.2 of the Council

Directive;

• Paying Agent: this represents the payer of interest under Art. 9 of the Council Directive;

• RIR: this represents the recipient of interest under Art. 9 of the Council Directive;

• Withholding Tax: this represents the information that, when summarised by the Paying

Agent and Competent Authority, will be exchanged for the withholding tax mechanism;

• Certificate: this represents the Certificate of Withholding Tax, or any evidence stating the

amount of withholding tax that has been retained, issued by a Paying Agent to the Relevant Interest Recipient when withholding tax has been deducted from an interest

payment;

3.6.2. Beneficial Owner Payment

Figure 20 indicates the relationships between Paying Agent, RIR, and Payment for the case of exchange of interest payment information.

Each CA has a similar view of the data – the CA of RIR’s view being restricted to the beneficial owners fiscally resident in its jurisdiction.

Figure 20: Conceptual Entity Relationship Diagram – Paying Agent/Beneficial

Owner/Payment

The CA of RIR is able to see all payments made to beneficial owners as well as the paying agents who made the payments.

3.6.3. Residual Entity Payment

Figure 21 indicates the relationships between Economic Operator, Residual Entity, and Payment for the case of interest-payment information disclosure.

Figure 21: Conceptual Entity Relationship Diagram – Residual Entity/Interest Payment

As there is no exchange of information concerning the identity of the Economic Operator who makes the payment to the RIR-Residual Entity, the competent authorities have a different view of the data.

3.6.4. RIR Withholding Tax

Figure 22 indicates the relationships between Paying Agent, RIR, Withholding Tax, and Payment.

Figure 22: Conceptual Entity Relationship Diagram – RIR/Withholding Tax

The CA of PA only sees the withholding tax deducted by the paying agent. The CA of PA transmits only the global withholding tax to the CA of RIR.

The CA of RIR only receives information on the RIR from the Certificate of Withholding Tax issued by the paying agent for the interest-payment. The RIR may submit the certificate to the CA of RIR with his tax return.

3.6.5. Residual Entity Withholding Tax

Figure 23 indicates the relationships between Paying Agent, Residual Entity, Withholding Tax and Payment.

RIR/ RE – PA View CA of RIR View

Certificate

RIR Payment name

name amount

address id

address currency amount

id account

country currency account

Residual Entity

name address id country

PA View Payment

Withholding Tax amount

currency amount account Paying Agent currency

name address id country

CA of PA View

Figure 23: Conceptual Entity Relationship Diagram – Residual Entity/Withholding Tax

Here, the Residual Entity Member is the RIR.

The CA of PA receives the withholding tax revenue from the Paying Agent and is required to distribute it amongst the various CA of RIR in the same ratio as withholding tax collected directly from RIRs (Figure 22). Hence, the withholding tax information is not directly shared with the CA of RIR.

The CA of RIR only receives information on the Residual Entity Member when the latter submits a Certificate of Withholding Tax.

• 4. 

  S YSTEM M ODEL

This chapter extends the analysis of the business model presented in chapter 3, focussing on the elements that involve the exchange of interest payment information between the CA of PA and the CA of RIR.

The chapter begins by listing the principal functional requirements of the target system.

Then, the business use cases that are in the scope of the system model are further analysed. As shown in Table 6, these business use cases decompose into a set of supporting system use cases. The relationships between the system use cases are illustrated in process data flow diagrams in section 4.3, and the processes are further elaborated by means of sequence diagrams in section 4.4. Section 4.6 provides a detailed description for each of the system use cases.

The remaining sections of the chapter provide a logical data model representing FISC153 as well as logical representations of messages that could be used to support the system and business processes.

4.1. Functional Requirements

This section describes the principal functional requirements of the system, with their level of criticality as defined in section 1.5.

[F.01] Transmit Interest Payment Information Must Do. The system must allow each CA of PA, in a country or territory operating the

exchange of information mechanism, to transmit automatically, at least once per year, interest payment information to every concerned CA of RIR. The information must be transmitted in the FISC153 format.

[F.02] Receive Interest Payment Information Must Do. The system must allow the CA of RIR to receive interest payment information

transmitted automatically from each CA of PA.

[F.03] Request Interest Payment Correction Information Must Do. It must be possible for a CA of RIR to request correction of interest payment

information that the CA of PA has already transmitted. If the data were supplied in FISC39 format the correction mechanism of FISC39 must be used. If the data were supplied in FISC153 format the correction mechanism of FISC153 must be used.

[F.04] Receive Request for Correction of Interest Payment Information Must Do. The CA of PA must be able to receive requests for correction of interest payment

information from the CA of RIR.

[F.05] Transmit Interest Payment Correction Information Must Do. The CA of PA, in a country or territory operating the exchange of information

mechanism, must be able to transmit interest payment correction information to each CA of RIR. The CA of PA must either provide this correction information at its own initiative, or in response to a request from the CA of RIR. The correction mechanism must be the one appropriate to the format in which the data were originally supplied. If the data were supplied in FISC39 format the correction mechanism of FISC39 must be used.

If the data were supplied in FISC153 format the correction mechanism of FISC153 must be used.

[F.06] Receive Interest Payment Correction Information Must Do. The CA of RIR must be able to receive interest payment correction information

from the CA of PA.

[F.07] Provide Interest Payment Correction Information Must Do. The CA of PA must be able to answer requests for correction during the

Correction Period agreed by MS on a basis of consensus and goodwill (see section 4.5).

This requirement includes transmissions performed using the FISC39 format, but corrections to data provided in the FISC39 format must use the correction mechanism of FISC39.

[F.08] Retransmit Interest Payment Information Must Do. In case of a syntax error, an error in transmission, or an error on the part of the

CA of RIR, the CA of PA must be able to repeat the initial automatic transmission of interest payment information and any subsequent correction of interest payment information.

[F.09] Cancel Transmission of Interest Payment Information Must Do. The CA of PA must be able to cancel the transmission of interest payment

information

[F.10] Cancel Request for Correction Must Do. The CA of RIR must be able to cancel a request for correction of interest payment

information.

4.2. Mapping of Business Use Cases to System Use Cases

Table 6 lists the business use cases that are in the scope of the document, and relates these to supporting system use cases. With the exception of SUC-CA-PA-040 (Corrects Local Data Set), each of these system use cases is supported by one or more structured messages (see section 4.8). SUC-CA-PA-040 is not in scope but is provided for a fuller description of the process flows.

Business Use Case Supporting System Use Case

BUC-CA- Transmits Interest SUC-CA-PA-010 Transmits Interest Payment PA-030 Payment Information Information

SUC-CA-020 Receives Rejection

SUC-CA-050 Corrects Syntax

BUC-CA- Receives Request for SUC-CA-PA-050 Receives Request for

PA-090 Correction of Interest Interest Payment Information Information Correction

SUC-CA-PA-070 Receives Cancellation of Interest Payment Correction Request

SUC-CA-040 Sends Rejection

BUC-CA- Transmits Correction SUC-CA-PA-040 Corrects Local Data Set PA-150 of Interest Information

SUC-CA-PA-060 Transmits Interest Payment Correction Information

SUC-CA-020 Receives Rejection Business Use Case Supporting System Use Case

SUC-CA-PA-080 Rejects Request for Interest Payment Correction

BUC-CA- Receives Interest SUC-CA-RIR-010 Receives Interest Payment RIR-020 Payment Information Information

SUC-CA-RIR-020 Validates Interest Payment Information

SUC-CA-040 Sends Rejection

BUC-CA- Issues Request for SUC-CA-RIR-040 Sends Request for

RIR-150 Correction of Interest Correction

Information

SUC-CA-RIR-060 Sends Cancellation of Interest Payment Correction Request

SUC-CA-020 Receives Rejection

BUC-CA- Receives Correction SUC-CA-RIR-050 Receives Correction

RIR-160 of Interest Information

Information

SUC-CA-RIR-020 Validates Interest Payment Information

SUC-CA-RIR-070 Receives Rejection of Interest Payment Correction Request

SUC-CA-040 Sends Rejection

Table 6: Business Use Cases and their Supporting System Use Cases 4.2.1. Triggering Events

This section describes external events that trigger sequences of system use cases. These events are referenced in the PDFDs in section 4.3 and in the descriptions of the system use cases in sections 4.6.1, 4.6.2, and 4.6.3.

Event: E-Fiscal Year Ends

Description:

The fiscal year ends in the country or territory of the CA of PA.

For reference, appendix 7.2 lists the last day of the fiscal year in each country or territory.

Event: E-Need for Correction Identified

Description:

The CA of RIR requires correction of information it has received from the CA of PA. This may arise if the CA of RIR identifies errors in the information it has received from the CA of PA, or from conflicting information it has received from the RIR.

Event: E-Corrections from PA or CA of PA

Description:

The CA of PA receives corrections from a paying agent for information that the CA of PA has already transmitted to the CA of RIR.

Alternatively, the CA of PA may itself identify errors in information it has sent to the CA of RIR.

Event: E-Request for Correction Received

Description:

The CA of PA receives a request for correction from the CA of RIR. This can legitimately occur during the Correction Period (see section 4.5).

Event: E- Notification of Cancellation of Interest Payment Correction Request

Description:

The CA of PA receives notification from the CA of RIR that it must cancel a request for correction of interest payment information

4.3. Process / Data Flow Diagrams

This section presents a series of process data flow diagrams (PDFD) that illustrate the relationships system use cases. Each diagram represents two closely related business use cases – one where the business actor is the CA of PA and the other where the business actor is the CA of RIR.

Section 7.4.2 contains a description of the notation used in the PDFD.

4.3.1. PDFD – Transmission of Interest payment Information

The process flow diagrams in this section represent the logical composition of the Transmit Interest Payment Information (BUC-CA-PA-030) and Receive Interest Payment Information (BUC-CA-RIR-020) use cases. Figure 24 shows the case of the initial automatic transmission of interest payment information.

National Public Domain

SUC-CA-PA-010 MES-INITIAL

E-Fiscal year ends SUC-CA-RIR-010 Transmits Interest Receives Interest

Payment Information Technical Payment Information

Sheet

End of

Process SUC-CA-RIR-020

Validates Interest Payments Information

Syntax SUC-CA-050

Corrects Syntax

Valid syntax End of Or Invalid Syntax and Process

Rejection Not Implemented Invalid syntax and

Rejection Implemented

SUC-CA-020

MES-REJECT SUC-CA-040 Receives Rejection

Sends Rejection

End of Process

MSA of Paying Agent MSA of RIR

Figure 24: Process Flow Diagram – Transmission of Interest Payment Information

Section 4.6 describes in detail the system use cases shown in the figure. Section 4.4 describes the process flows.

4.3.2. PDFD – Correction of Interest Payment Information

The process flow diagram in Figure 25 represents the logical composition of the Transmits Correction of Interest Information (BUC-CA-PA-150) and Receives Correction of Interest Information (BUC-CA-RIR-160) use cases. This process applies for the spontaneous and onrequest transmission of interest payment correction information by the CA of PA.

National Public Domain

SUC-CA-PA-080 SUC-CA-RIR-070 Rejects Request for Receives Rejection of

Interest Payment MES-REJREQ Interest Payment

Correction Correction Request

Request Rejected

E- Request for

Correction End of

End of

Received Process

Process

Request Accepted

E-Corrections SUC-CA-PA-040 From PA or CA of Corrects Local Data Set

PA

SUC-CA-RIR-050

SUC-CA-PA-060 Receives Correction Transmits Interest MES-CORRECT Information

Payments Correction Information

SUC-CA-RIR-020

E- Notification of Validates Interest

Cancellation of Interest End of End of Payment Information Payment Correction Process Process Syntax

Request

Valid syntax

SUC-CA-050 Or Invalid

Corrects Syntax Syntax and End of RejectionNot Process

Implemented Invalid

Syntax and Rejection

 Implemented

SUC-CA-020 SUC-CA-040

Receives Rejection MES-REJECT End of Sends Rejection Process

MSA of Paying Agent MSA of RIR

Figure 25: Process Flow Diagram –Correction of Interest Payment Information The process flow diagrams in Figure 26 and Figure 27 represent the logical composition of the Issues Request for Correction of Interest Information (BUC-CA-RIR-150) and Receives Request for Correction of Interest Information (BUC-CA-PA-090) use cases.

Figure 26: Process Flow Diagram – Request for Correction of Interest Payment

Information

Figure 27: Process Flow Diagram – Request for Correction of Interest Payment

Information - Cancellation

Section 4.6 describes in detail the system use cases shown in the figures. Section 4.4 describes the process flows.

4.3.3. Operational Procedures

Some processes will be managed via operational procedures and will be described in the corresponding document [R15]. Table 7 describes these processes.

Process Description

Cancel Interest Payment After transmitting interest payment information (either an initial transmission or corrections), the CA Transmission of PA may request the CA of RIR to disregard the transmission.

Request Retransmission of The CA of RIR may request the CA of PA to retransmit interest payment information (either an Interest Payment Information initial transmission or corrections). This may arise, for example, if the CA of RIR experiences a

process failure, for example a file may be corrupted.

Request Confirmation of non If, after the end of the Declaration Period, the CA of RIR has received no interest payment Receipt of Information information from a CA of PA, the CA of RIR may contact the CA of PA and ask it to confirm that it

has no information to provide.

Table 7: Processes managed by operational procedures.

4.4. Sequence Diagrams

This section uses sequence diagrams to elaborate further on the system use cases. Section 7.4.3 explains the notation used.

4.4.1. Rejection Process

The purpose of the rejection process is to let the sender of information know, by means of a rejection message sent by the recipient, of any syntax error in the transmitted information. The rejection message is defined in section 4.8.3.1. The process is applicable to the initial transmission of interest payment information, on-demand and spontaneous transmission of interest payment correction information, correction requests, and cancellation of correction requests.

The rejection process is entirely optional. The recipient of a syntactically incorrect message is free to decide whether to send a rejection message. Equally, the sender of a message is free to decide whether to check for the receipt of a rejection message.

The recipient of a message may choose to check the syntax on its receipt, or delay this check until the message is actually processed. Thus, if a rejection message is sent at all, it may be sent during a wide timeframe after the transmission of the syntactically incorrect message.

The sequence diagram in Figure 28 illustrates the rejection process, using as an example the rejection of the CA of RIR to spontaneously sent interest payment information containing invalid syntax.

Figure 28: Sequence Diagram – Rejection Process (Example)

• 1. 

  The sender (in this example, the CA of PA) transmits a message (in this example, the interest payment information) to the recipient (in this example, the CA of RIR).

• 2. 

  The recipient validates the syntax. The syntax is invalid.

• 3. 

  The recipient sends a rejection message back to the sender.

4.4.2. Initial Transmission Process

The sequence diagram in Figure 29 illustrates the initial transmission process for the exchange of interest payment information.

Figure 29: Sequence Diagram – Initial Transmission

• 1. 

  The CA of PA transmits the interest payment information to the CA of RIR.

• 2. 

  The CA of RIR receives the information and validates the syntax.

• 3. 

  If there is a syntax error, the CA of RIR may send a rejection message to the CA of PA, but it is not obliged to do this.

4.4.3. Correction Process

4.4.3.1. Correction Process Initiated by CA of PA

When the Paying Agent wishes to correct information it has supplied to the CA of PA, the

process illustrated in the sequence diagram of

Figure 30 applies.

Figure 30: Sequence Diagram – Correction Initiated by Paying Agent

• 1. 

  The CA of PA makes an update to its local dataset (perhaps as a result of corrections received from a Paying Agent, or from errors detected by the CA of PA). The CA of PA must then prepare a correction message for each of the CA of RIR affected.

• 2. 

  The CA of PA transmits the correction information to the CA of RIR.

• 3. 

  The CA of RIR receives the correction information and validates the syntax.

• 4. 

  If there is a syntax error, the CA of RIR may send a rejection message to the CA of PA, but it is not obliged to do this.

4.4.3.2. Correction Process Initiated by the CA of RIR

When the CA of RIR requires correction of information, the process illustrated in the sequence diagram of Figure 31 applies. The correction must be interpreted as a request for clarification. The corrections concern only data that were already transmitted.

Figure 31: Sequence Diagram – Correction Initiated by the CA of RIR

• 1. 

  After receiving a syntactically valid interest payments transmission from the CA of PA, the CA of RIR notices an error or inconsistency in the information (perhaps as a result of communication with the RIR). The CA of RIR sends a request for correction to the CA of PA. The request for correction identifies unambiguously the information for which the CA of RIR requires a correction.

• 2. 

  The CA of PA validates the syntax of the request for correction.

• 3. 

  If the syntax is invalid, the CA of PA may send a rejection message to the CA of RIR, but it is not obliged to do this. The process continues to step 4 only if the syntax is valid.

• 4. 

  The CA of PA is able to correct the information and updates its local data set (perhaps after consulting the Paying Agent).

• 5. 

  The CA of PA sends the corrected information to the CA of RIR.

• 6. 

  The CA of RIR receives the correction information and validates the syntax.

• 7. 

  If there is a syntax error, the CA of RIR may send a rejection message to the CA of PA, but it is not obliged to do this.

4.4.3.3. Correction Process Initiated by the CA of RIR – Cancellation of Request for Correction

When the CA of RIR requires correction of information, the process illustrated in the sequence diagram of Figure 31 applies. Sometime after submitting the request for correction, the CA of RIR may decide to cancel the request. The process illustrated in Figure 32 then applies.

Figure 32: Sequence Diagram – Cancellation of request for correction

• 1. 

  After receiving a syntactically valid interest payments transmission from the CA of PA, the CA of RIR notices an error or inconsistency in the information (perhaps as a result of communication with the RIR). The CA of RIR sends a request for correction to the CA of PA. The request for correction identifies unambiguously the information for which the CA of RIR requires a correction.

• 2. 

  The CA of PA validates the syntax of the request for correction.

• 3. 

  If the syntax is invalid, the CA of PA may send a rejection message to the CA of RIR, but it is not obliged to do this. The process continues to step 4 only if the syntax is valid.

• 4. 

  The CA of RIR decides that it no longer requires the correction information. It sends a message to the CA of PA that unambiguously identifies the request for correction that is no longer required.

• 5. 

  The CA of PA validates the syntax of the message.

• 6. 

  If the syntax is invalid, the CA of PA may send a rejection message to the CA of RIR, but it is not obliged to do this. The process continues to step 7 only if the syntax is valid.

• 7. 

  The CA of PA stops any investigation it may have started on the request for correction and, if necessary, instructs the PA to do likewise.

4.4.3.4. Correction Process Initiated by the CA of RIR – Rejection of Request for Correction

When the CA of RIR requires correction of information, the process illustrated in the sequence diagram of Figure 31 applies. It is possible that the CA of PA may reject the request for correction. In this case, the process illustrated in Figure 33 applies.

Figure 33: Sequence Diagram – Rejection of request for correction

• 1. 

  After receiving a syntactically valid interest payments transmission from the CA of PA, the CA of RIR notices an error or inconsistency in the information (perhaps as a result of communication with the RIR). The CA of RIR sends a request for correction to the CA of PA. The request for correction identifies unambiguously the information for which the CA of RIR requires a correction.

• 2. 

  The CA of PA validates the syntax of the request for correction.

• 3. 

  If the syntax is invalid, the CA of PA may send a rejection message to the CA of RIR, but it is not obliged to do this. The process continues to step 4 only if the syntax is valid.

• 4. 

  The CA of PA analyses the request for correction. This may involve passing the correction request onto the Paying Agent for analysis

• 5. 

  If the outcome of the analysis is that no correction is to be made, the CA of PA notifies the CA of RIR that it has rejected the request for correction. The reason for the rejection, from among those contained in Table 39, is also communicated.

4.5. Process Timescales

This section defines the timescales applicable for the processes described in section 4 of this document. The timescales that are not defined in the Council Directive are based on goodwill between the MS.

4.5.1. Process Timeline

The processes related to the business use cases described in this chapter may only occur during certain defined periods. Figure 34 shows the relationship between periods and processes, and the ability for processes to co-exist in the same period. The blue arrows point to events and indicate possible periods for the event to occur.

Figure 34: Process Timeline

The figure shows the following periods:

• The Fiscal Period is the period between the start of the fiscal year and the end of the fiscal

year. It has a duration of twelve months. At any time during this period:

• the CA of PA may make an initial transmission to the CA of RIR;

• the CA of PA may transmit spontaneous corrections to the CA of RIR;

• the CA of PA may transmit upon request corrections to the CA of RIR.

• The Declaration Period is the six months immediately following the end of the Fiscal

Period. At any time during this period:

• the CA of PA may make an initial transmission to the CA of RIR; • the CA of PA may transmit spontaneous corrections to the CA of RIR;

• the CA of PA may transmit upon request corrections to the CA of RIR.

• The Correction Period starts at the end of the Fiscal Period. Its duration is not defined in

the Council Directive and must be agreed by MS. In Figure 34 it is shown as twelve months. During the Correction Period:

• the CA of PA may transmit spontaneous corrections to the CA of RIR;

• the CA of PA may transmit upon request corrections to the CA of RIR.

• The Data Retention Period starts at the end of the Fiscal Period. Its duration is not defined

in the Council Directive and must be agreed by MS. In Figure 34 it is shown as five years. This must be interpreted as five years from the first day of the year following the year in which the transmission was made. During the Data Retention Period:

• the CA of PA must be able to respond to requests for correction from the CA of

RIR;

• the CA of PA may transmit upon request corrections to the CA of RIR.

4.5.2. Process Timescale Provisions

For the good operation of the system, it is desirable to define timescales for the various processes with which MS should agree to comply. Table 8 lists these processes and the timescales.

Process Timescale 3 Defined in Council

Directive

Transmits Interest Payment 6 months from end of fiscal Yes (Art. 9.2) Information period

Receives Request for Interest Up to 5 years from end of No Payment Information fiscal period Correction

Transmits Interest Payment Recommended to be 6 No Correction Information months after the end of the (spontaneous corrections) initial declaration period. May be sooner if urgency or importance justifies it.

Transmits Interest Payment Within 3 or 6 months after No Correction Information (onreceiving the request for request corrections) / Rejects correction, depending on Request for Interest Payment whether the PA is involved Correction Information (6 months) or not (3 months).

EN 99 EN

Process Timescale 3 Defined in Council

Directive

Re-Transmits Failed Interest Within 5 working days after No

Payment Information receiving notification of the

Transmission transmission failure. 4

Re-Transmission after syntax Within 1 month after No error receiving notification of the

transmission failure

Table 8: Process timescales.

4.6. System Use Cases Model

4.6.1. Use Cases Common to CA of PA and CA of RIR

This section describes system use cases applicable both to the CA of PA and to the CA of RIR.

SUC-CA-020 Receives Rejection

Actor: CA Domain: National Public

Taxation Mechanism: Common Event: -

Description:

The CA analyses the rejection message.

The CA uses the logical error code in the rejection message to identify the broad category of the error.

Table 45 lists the error codes that may be contained in a rejection.

Constraints: -

4 In case the timescale cannot be respected due to a major technical failure, a manual procedure must be

triggered to inform the addressee of the message of the delay.

SUC-CA-040 Sends Rejection

Actor: CA Domain: National Public

Taxation Mechanism: Common Event: -

Description:

The CA that received a request or information transmission sends a rejection to the originating CA.

The rejection message must contain enough information to associate it with the original request or information transmission and it must contain an error code to describe the reason for the rejection (see section 4.9).

The rejection message should contain any other information to allow the sender of the original transmission to identify and, if necessary, rectify the problem. For example, the rejection message may include the error output from a message parser.

The rejection message is sent through the agreed channel.

Constraints:

This system process applies if all of the following constraints are fulfilled:

• 1. 

  The CA has received either

  • interest payments information (initial transmission or corrections);

  • a request for correction, or

  • a cancellation of a request for correction

from another CA.

• 2. 

  The information received is syntactically incorrect.

• 3. 

  The information received is sufficient to identify the sender of the information or request.

SUC-CA-050 Corrects Syntax

Actor: Common Domain: National Public

Taxation Mechanism: Common Event: -

Description:

The CA analyses the content of the rejection message to help determine the source of the syntax error.

The CA makes the necessary corrections.

Constraints:

This system process applies the following constraint is fulfilled:

• 1. 

  The CA has received a rejection message containing the logical error code ERR_MSG_SYNTAX_INVALID.

4.6.2 Use Cases Specific to CA of PA

This section contains descriptions for system use cases applicable to the CA of PA.

SUC-CA-PA-010 Transmits Interest Payment Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information Event: E-Fiscal Year Ends

Description:

The CA of PA prepares a message compliant with the FISC153 schema, containing interest payment information for the CA of RIR.

The CA of PA transmits the message to the CA of RIR.

The transmission is through the agreed channel.

The CA of PA records the date and time of the transmission, and sufficient details to allow it to repeat the transmission if necessary.

The CA of PA should be able to respond to requests for correction on the transmitted information for the period defined in Table 8.

Constraints:

This system process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has interest payment information to send to a CA of RIR.

SUC-CA-PA-040 Corrects Local Data Set

Actor: CA of PA Domain: National Public

Taxation Mechanism: Common Event: E-Corrections from PA or CA of PA

Description:

Scenario 1 : Request for Correction or Rejection Message Received from CA of RIR

The CA of PA analyses the content of the rejection message, or the request for correction message, to help it determine the reason why the original transmission must be corrected.

The CA of PA makes the necessary corrections.

Scenario 2 : Correction Information Received Spontaneously from Paying Agent

The CA of PA updates its local dataset with the received information.

Scenario 3 : CA of PA Identifies Errors in Local Data Set

The CA of PA corrects its local data set.

Constraints:

This system process applies any of the following constraints is fulfilled:

• 1. 

  The CA of PA has received a rejection message from a CA of RIR and has implemented the optional process of checking for a rejection message.

• 2. 

  The CA of PA has received a request for correction from a CA of RIR.

• 3. 

  The CA of PA has received corrections from a Paying Agent.

• 4. 

  The CA of PA has identified an error in its local data set.

SUC-CA-PA-050 Receives Request for Interest Payment Information Correction

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of PA checks the syntax of the request for correction.

If the syntax is valid, the CA of PA stores the request for later processing.

If the syntax is not valid, the CA of PA may send a rejection message to the sender of the request (see SUC-CA-040), but is not obliged to do this. If sent, the rejection message contains the logical error code ERR_MSG_SYNTAX_INVALID.

Constraints:

This system process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has sent a request for correction.

SUC-CA-PA-060 Transmits Interest Payment Correction Information

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of PA prepares a message compliant with the FISC153 schema, containing the corrected interest payment information that it wishes to send to the CA of RIR.

The CA of PA transmits the message to the CA of RIR.

The transmission is through the agreed channel.

The CA of PA should be able to respond to requests for further correction of the transmitted information for the period defined in Table 8.

Multiple requests for correction can be grouped in a single message and multiple correction responses can be grouped in a single message. There is no relation between the grouping of requests for correction and the grouping of correction responses.

Constraints:

This system process applies if any of the following constraints are fulfilled:

• 1. 

  The CA of PA has correction information received from a PA to send to a CA of RIR.

  • 2. 

    The CA of PA has identified errors in a transmission it has previously sent.

  • 3. 

    The CA of PA has received a request for correction from a CA of RIR.

SUC-CA-PA-070 Receives Cancellation of Interest Payment Correction Request

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of PA checks the syntax of the interest payment request cancellation.

If the syntax is valid, the CA of PA stores the request for later processing.

If the syntax is not valid, the CA of PA may send a rejection message to the sender of the request (see SUC-CA-040), but is not obliged to do this. If sent, the rejection message contains the logical error code ERR_MSG_SYNTAX_INVALID.

Constraints:

This system process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has sent a request for correction.

SUC-CA-PA-080 Rejects Request for Interest Payment Correction

Actor: CA of PA Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

If the CA of PA has a valid reason not to provide correction information it may reject the request for correction.

Table 39 lists the valid reasons for rejecting a request for correction.

The CA of PA prepares a message for the CA of RIR.

The message refers to the request for correction and gives the reason why it has been rejected.

Constraints:

This system process applies if the following constraint is fulfilled:

• 1. 

  The CA of PA has received a request for correction from a CA of RIR.

4.6.3. Use Cases Specific to CA of RIR

This section contains descriptions for system use cases applicable to the CA of RIR.

SUC-CA-RIR-010 Receives Interest Payment Information

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of RIR receives interest payment information from a CA of PA through the agreed channel. The CA of RIR must store the information for later processing.

Constraints: -

SUC-CA-RIR-020 Validates Interest Payment Information Syntax

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of RIR parses the message to ensure it is compliant with the FISC153 schema. If the message is not well formed or is not compliant with the FISC153 schema, the CA of RIR may send a rejection message to the CA of PA, but is not obliged to do this. If sent, the rejection message must contain the logical error code ERR_MSG_SYNTAX_INVALID. The rejection message should also contain any errors detected by the message parser.

This process may be done immediately on receipt of an interest payment transmission or delayed until the interest payment information is processed.

Constraints:

This system process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has received interest payment information from a CA of PA.

SUC-CA-RIR-040 Sends Request for Correction

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information Event: E-Need for Correction Identified

Description:

The CA of RIR must identify the interest payment information that needs to be corrected and include this information in a correction request message.

The CA of RIR sends the correction request message to the CA of PA.

The message is sent through the agreed channel.

Constraints:

This system process applies if all of the following constraints are fulfilled:

• 1. 

  The CA of RIR has received the information on interest payments from a CA of PA;

  • 2. 

    The request for correction concerns a piece of information that was received from the CA of PA;

• 3. 

  The information has been provided within the Data Retention Period (see section 4.5).

SUC-CA-RIR-050 Receives Correction Information

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of RIR receives interest-payment correction information from a CA of PA through the agreed channel. The CA of RIR stores the information for later processing.

Constraints:

This system process applies if any of the following constraints are fulfilled:

• 1. 

  The CA of RIR has sent a request for correction to a CA of PA;

• 2. 

  The CA of PA has corrections to provide spontaneously to the CA of RIR.

SUC-CA-RIR-060 Sends Cancellation of Interest Payment Correction Request

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information Event: E-Need for Correction Identified

Description:

The CA of RIR identifies the request for correction that it now wishes to cancel.

The CA of RIR prepares a message containing the identifier of the request for correction and sends it to the CA of PA.

The message is sent through the agreed channel.

Constraints:

This system process applies the following constraint is fulfilled:

• 1. 

  The CA of RIR has sent a request for correction to the CA of RIR.

SUC-CA-RIR-070 Receives Rejection of Interest Payment Correction Request

Actor: CA of RIR Domain: National Public

Taxation Mechanism: Exchange of Information Event: -

Description:

The CA of RIR receives notification that a request for correction has been rejected by the CA of PA, and the reason for the rejection.

If the reason for the rejection is that insufficient information was provided to process the request, the CA of RIR may resubmit the request with more information.

For all other reasons the CA of RIR must accept the decision of the CA of PA.

Constraints:

This system process applies if the following constraint is fulfilled:

• 1. 

  The CA of RIR has sent a request for correction to a CA of PA; 4.7. Logical Data Model

Figure 35 presents a logical view of the main entities in the system and the relationships between them. This diagram takes into account the cardinality of Payments per Residual Entity, Paying Agent, and Beneficial owner. The notation used in the diagram is described in section 7.4.1.

The Logical Data Model is based on the definition of the FISC153 schema, considering that this schema is still under discussion and may be subject to amendments.

Residual Entity

AddressFree Address Article4_2Payment

name

addressFree legalAddresstype docRefId taxYearEnd countryCode LegalPersData specificPaymentType

yearOfPayment foundDate monAmount

PayingAgent currCode EUSDAccntInfo AddressStruct docRefId oecdLegalType IBAN street docRefId OBAN otherLocalId accntNoQlf

buildingIdentifier ISIN suiteIdentifier OSIN

floorIdentifier IndivPersData secNoQlf

districtName PartyID OTHER

POB birthDate othQlf

postCode birthCity partyIdType Article9Payment SWIFT

city birthCitySubEntity partyId shared

countrySubEntity birthCountryCode issuedBy taxYearEnd

gender specificPaymentType yearOfPayment

monAmount currCode

BeneficialOwner docRefId

Name_MiddleName resCountryCode

middleName docRefId contractBefore2004

Name_Title NameStruct

title

precedingTitle Name NameFree OtherPersData firstName othQlf

namePrefix type nameFree otherPersData

lastName Name_Suffix generalSuffix suffix

Name_GenerationIdentifier

generationIdentifier

Figure 35: Logical Entity Relationship Diagram

4.7.1. Entity-Attribute Model Template

All entities are presented as a sequence of data groups. Each data group has the format:

Logical Data Group Name

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed The logical name of An example or a Any allowed values If the Y if Y if Y if the attribute. Here, short description of for this attribute. attribute is empty attribute is attribute is ‘attribute’ is taken the attribute and This may include a required (R), value is required required to mean any how it is used if this logical type (e.g. optional (O) allowed, by the in property of the is not obvious from DATE) or another or is subject N if Council FISC39, entity. the name of the Logical Data Group to the given empty Directive, N if

Where the attribute attribute. Name. References condition value is N if attribute is is written between to other Logical (C). not attribute is not

angle brackets, e.g. Data Groups are allowed. not required <Address>, this italicised. required in FISC39 indicates a by the relationship to the Council logical data group Directive. mentioned between the brackets.

Table 9: Logical Data Structure Template

4.7.2 Entity-Attribute Models

Address

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

legalAddressType The type of the One of: O N N Y

address residentialOrBusine

ss residential

business registeredOffice

fiscal Residence unspecified

countryCode The country of the Two upper case R N Y Y address alphabetic

characters, compliant with [R08]

<AddressStruct> Fixed format AddressStruct C Either - - - address AddressFree

or AddressStruc t must be provided, both may be provided if available.

<AddressFree> Free format address AddressFree C Either - - -

AddressFree or AddressStruc t must be provided, both may be provided if available.

Table 10: Logical Data Structure for Address

AddressStruct

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed street The street name Unrestricted text O N Y Y

otherLocalID e.g., XZY Business Unrestricted text O N Y N

Park.

buildingIdentifier e.g., Robert Unrestricted text O N N N

Schumann Building.

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

suiteIdentifier Identifier for an Unrestricted text O N N N office suite

floorIdentifier e.g. First Floor Unrestricted text O N N N

districtName District Unrestricted text O N N N

POB Post Office Box Unrestricted text O N N N number

postCode Postal Code Unrestricted text O N Y Y

city City Unrestricted text R N Y Y

countrySubEntity An area of the Unrestricted text O N N N country larger than

the districtName, e.g., county, state, Länder.

Table 11: Logical Data Structure for AddressStruct

AddressFree

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed addressFree Free text form of Unrestricted text R N Y Y

address

Table 12: Logical Data Structure for AddressFree Article4_2Payment

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed taxYearEnd Last date of the tax DATE O N N N

year in which payment was made

specificPaymentTy Describes the type See appendix 7.3. O N N Y pe of interest paid.

yearOfPayment 5 Year in which YEAR O N N N

payment was made

monAmount Amount of payment INTEGER R N Y Y

Fractional amounts must be rounded down. Amounts less than 1 that have been rounded down to zero do not have to be included but the CA of PA may include them if it wishes

currCode Currency of Three upper case R N Y Y payment alphabetic

characters compliant with [R09]

docRefId An identifier that Text R N N Y

unambiguously The identifier must identifies the record commence with the in time and space code of one of the

countries or territories listed in Table 47, Table 48, or Table 49 for the CA of PA.

<EUSDAcctInfo> Information for the EUSDAccntInfo O - - - account that

generated the interest payment.

Table 13: Logical Data Structure for Article4_2Payment

5 According to FISC39, the YearOfPayment is defined as the year during which the payment was made,

although it should be borne in mind that: - for information from the United Kingdom this means the tax year (06/04/N – 05/04/N+1) - for information from the other MS: the calendar year.

Article9Payment

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed taxYearEnd Last date of the tax DATE O N N N

year in which payment was made

specificPaymentTy Describes the type See appendix 7.3. R N Y Y pe of interest paid.

yearOfPayment 6 Year in which YEAR R N Y Y

payment was made

monAmount Amount of payment INTEGER R N Y Y

Fractional amounts must be rounded down. Amounts less than 1 that have been rounded down to zero do not have to be included but the CA of PA may include them if it wishes

currCode Currency of Three upper case R N Y Y payment alphabetic

characters compliant with [R09]

docRefId An identifier that Text R N N Y

unambiguously The identifier must identifies the record commence with the in time and space code of one of the

countries or territories listed in Table 47, Table 48, or Table 49 for the CA of PA.

<EUSDAcctInfo> Information for the EUSDAcctInfo R - - - account that

generated the interest payment.

Table 14: Logical Data Structure for Article9Payment

6 According to FISC39, the YearOfPayment is defined as: “the year during which the payment was

made, although it should be borne in mind that: - for information from the United Kingdom this means the tax year (06/04/N – 05/04/N+1) - for information from the other MS: the calendar year.

BeneficialOwner

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed resCountryCode The fiscal residence One of the countries R N Y Y

country. or territories listed in Table 47, Table 48, or Table 49

docRefId An identifier that Text R N N Y

unambiguously The identifier must identifies the record commence with the in time and space code of one of the

countries or territories listed in Table 47, Table 48, or Table 49 for the CA of PA.

contractBefore2004 Indicates if the One of: R N Y N

contractual true relations 7 with the

Beneficial Owner false

began before unknown

01/01/2004

<PartyId> TIN information PartyID C May be - - - provided in

all cases, but either PartyID or IndivPersDat a is required if the contractual relationship with the Beneficial Owner started on or after 01/01/2004.

<IndivPersData> Personal IndivPersData C May be - - - information about provided in

the beneficial owner all cases, but either

PartyID or IndivPersDat a is required if the contractual relationship with the Beneficial Owner started on or after 01/01/2004.

7 The term “Contractual Relations” is not defined in the Council Directive. There exist at least two

interpretations: the initial contract a Beneficial Owner has with the Paying Agent; and, the latest

contract a Beneficial Owner has with the Paying Agent.

<OtherPersData> Personal OtherPersData O - - - identification data

different from a TIN (e.g. a passport number)

<Name> Name Name R - - -

<Address> Address list 1..n R - - -

Address

<Article9Payment> Payment made to list 1..n R - - -

the beneficial owner Article9Payment

Table 15: Logical Data Structure for BeneficialOwner

EUSDAccntInfo

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

IBAN International Bank Up to 34 alpha C exactly N Y Y

Account Number numeric characters one of

compliant with IBAN, “Electronic OBAN, Format” defined in ISIN, OSIN [R10] or OTHER

must be set.

OBAN Other Bank Unrestricted text C exactly N Y Y

Account Number one of (when IBAN is not IBAN, available) OBAN, ISIN, OSIN or OTHER must be set.

accntNoQlf The kind of Unrestricted text C must be Y N N account number set if and

provided in the only if OBAN attribute OBAN is set.

ISIN International 12 alpha-numeric C exactly N Y Y

Securities characters, one of Identification compliant with IBAN, Number [R13] OBAN, ISIN, OSIN or OTHER must be set.

OSIN Other Securities Unrestricted text C exactly Y Y Y

Identification one of Number (when IBAN, ISIN is not OBAN, available) ISIN, OSIN or OTHER must be set.

secNoQlf The kind of Unrestricted text C must be Y N N security provided set if and

in the OSIN only if OSIN attribute is set.

OTHER Any other Unrestricted text C exactly N Y N identification of the one of

debt claim that IBAN, cannot be set in OBAN, OBAN/IBAN/OSI ISIN, OSIN N/ISIN. or OTHER must be set.

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

othQlf The kind of Unrestricted text C must be Y N N information set if and

provided in the only if OTHER attribute OTHER is set.

SWIFT SWIFT code for 8 or 11 O may only N N Y the account alphanumeric be set if

characters, IBAN or compliant with OBAN is set. [R14]

shared Describes if the One of O (default is N N N

account is shared unknown unknown)

and, if it is, the

repartition method. not shared shared repartition

evenly shared repartition actual shared repartition total shared repartition unknown

Table 16: Logical Data Structure for EUSDAccntInfo

IndivPersData

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed birthDate The date of birth of DATE O N Y Y

the individual

birthCity The city of birth of Unrestricted text O N Y Y the individual

birthCitySubEntity E.g., an Unrestricted text O N N N administrative

district within a city

birthCountryCode Country of birth Two upper case O N Y Y alphabetic

characters, compliant with [R08] where possible

gender The gender of the Either M (male) or O N N N individual F (female)

Table 17: Logical Data Structure for IndivPersData

LegalPersData

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed foundDate A date that is DATE R N N N

relevant to the commencement of the legal person entity, e.g., the foundation date.

Table 18: Logical Data Structure for LegalPersData

Name

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed type This is the type of One of : O N N Y

the name. indiv It can be an alias

individual, an alias,

a nickname, an nick

“also known as” aka

name, “doing dba

business as”, a legal legal

name, the name at atbirth

birth, or some other

unspecified type of unspecified

name.

<NameStruct> Fixed format name NameStruct C Either - - -

NameFree or NameStruct must be provided, both may be provided if available.

<NameFree> Free format name NameFree C Either - - -

NameFree or NameStruct must be provided, both may be provided if available.

Table 19: Logical Data Structure for Name

NameStruct

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed precedingTitle Examples of this Unrestricted text O N N N

are Her Excellency, and The Estate of the Late.

firstName The first name. Unrestricted text R N Y Y

namePrefix E.g., de, van, von Unrestricted text O N N N

lastName The family name. Unrestricted text R N Y Y

generalSuffix E.g., deceased, Unrestricted text O N N N retired.

<Name_MiddleNa Middle names list 1..n O - - -

me> Name_MiddleName

<Name_Generation e.g. jnr., snr. VIII list 1..n O - - -

Identifier> Name_GenerationI

dentifier

<Name_Suffix> e.g. PhD list 1..n O - - -

Name_Suffix

<Name_Title> e.g. Dr, Frau list 1..n O - - -

Name_Title

Table 20: Logical Data Structure for NameStruct

NameFree

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed nameFree Free text form of the Unrestricted R N Y Y

name text

Table 21: Logical Data Structure for NameFree

Name_Suffix

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed suffix E.g, D.Phil., retd. Unrestricted text R N N Y

Table 22: Logical Data Structure for Name_Suffix

Name_GenerationIdentifier

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

generationIdentifier E.g., Junior, Senior, Unrestricted text R N N N

IV

Table 23: Logical Data Structure for Name_GenerationIdentifier

Name_MiddleName

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed middleName A name coming Unrestricted text R N N N

between the firstName and the lastName

Table 24: Logical Data Structure for Name_MiddleName

Name_Title

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

title This is the greeting Unrestricted text R N N N title, e.g. Mr., Dr.,

Professor,

Table 25: Logical Data Structure for Name_Title OtherPersData

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed othQlf type of other Unrestricted Text R N N N

personal data (e.g. passport, birth certificate)

otherPersData The identifying Unrestricted text R N N N details contained in

the identity document

Table 26: Logical Data Structure for OtherPersData

PartyID

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

partyIdType The type of identity TIN R N Y Y document

partyID The identification Unrestricted text R N Y Y number

issuedBy The country that One of the countries R (for a Y Y Y issued the document or territories listed BeneficialOw

in Table 47, Table ner this must 48, or Table 49 be the same as the resCountryC ode)

Table 27: Logical Data Structure for PartyId

PayingAgent

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

oecdLegal Type The legal type of One of : R N N N

the Paying Agent Individual

Corporation

Other

docRefId An identifier that Text R N N Y

uniquely identifies The identifier must the record in time commence with the and space code of one of the

countries or territories listed in Table 47, Table 48, or Table 49 for the CA of PA.

<LegalPersData> Information LegalPersData O Either - - - concerning paying LegalPersDat

agent who is a legal a or person IndivPersDat a may be provided but neither is required.

<IndivPersData> Information IndivPersData O Either - - - concerning paying LegalPersDat

agent who is an a or individual IndivPersDat a may be provided but neither is required.

<Address> Address Address R - - -

<Name> Name Name R - - -

<PartyID> TIN information PartyID O - - -

<BeneficialOwner> Beneficial owner(s) list 1..n R - - -

paid by the paying BeneficialOwner

agent

Table 28: Logical Data Structure for PayingAgent ResidualEntity

Attribute Description Valid Values Required, Empty Directive FISC39 Optional, or Value

Conditional Allowed

name The name of the Unrestricted text R N Y Y entity

docRefId An identifier that Text R N N Y

unambiguously The identifier must identifies the record commence with the in time and space code of one of the

countries or territories listed in Table 47, Table 48, or Table 49 for the CA of PA.

<Article4_2Paymen The payment list 1..n R - - - t> information Article4_2Payment

<Address> Address Address R - - -

Table 29: Logical Data Structure for ResidualEntity 4.8. Messages

This section describes the logical content of the messages 8 used to support the processes

described in section 4. The information content is defined in a way that is neutral of any particular channel, as the channel has not yet been defined. Moreover, as the messages defined here are logical, it is possible that the technical specifications may group some messages into one physical message.

Table 30 lists the messages. In the table, the Code column contains a unique identifier, the Description column is an informative name for the message. The last column shows the use cases for which the message is relevant.

Code Description Related Use Case(s)

MES-INITIAL INITIAL Initial Interest Payment SUC-CA-PA-010

Information SUC-CA-RIR-010

SUC-CA-RIR-020

MES-REJECT REJECT Rejection Message SUC-CA-020 SUC-CA-040 SUC-CA-050

MES-CORREQ CORREQ Request for Correction – SUC-CA-PA-070

Interest Payment Information SUC-CA-RIR-060

MES-CORRECT CORRECT Correction Message – SUC-CA-PA-080

Spontaneous or On-Request SUC-CA-RIR-070

Correction of Interest Payment Information

MES-CANREQ Cancellation of Request for SUC-CA-RIR-060

Correction SUC-CA-PA-070

MES-REJREQ Rejection of Request for Correction SUC-CA-RIR-080

SUC-CA-PA-070

Table 30: Message Codes and Names

The structure of a message definition is described with the template in Table 31.

Attribute Description Valid Values Required, Optional, or Conditional

The logical An example or a short Any allowed values for If the attribute is required (R), name of the description of the attribute and this attribute. This may optional (O) or is subject to the attribute. how its use. include a logical type given condition (C).

(e.g. DATE) or a Logical Data Group Name (see section 4.7.2.) References to other Logical Date Groups are italicised.

Table 31: Logical Data Structure Template

8 The term ‘message’ is used to refer to the container of business information conveyed between two

counterparts, without making any assumption on its technical implementation.

4.8.1. Initial Exchange Message

4.8.1.1. MES-INITIAL Initial Interest Payment Information

This message must be compliant with the FISC153 schema. Figure 36 depicts the structure of the message.

Initial Transmission

Article9Payment 1 BeneficialOwner 1 Article9Payment 2

Article9Payment ..n Article9Payment 1

PayingAgent 1 BeneficialOwner 2 Article9Payment 2 Article9Payment ..n Article9Payment 1

BeneficialOwner ..n Article9Payment 2 Article9Payment ..n Article9Payment 1

BeneficialOwner 1 Article9Payment 2 Article9Payment ..n Article9Payment 1

PayingAgent 2 BeneficialOwner 2 Article9Payment 2 Article9Payment ..n Article9Payment 1

BeneficialOwner ..n Article9Payment 2 Article9Payment ..n Article9Payment 1

BeneficialOwner 1 Article9Payment 2 Article9Payment ..n Article9Payment 1

PayingAgent ..n BeneficialOwner 2 Article9Payment 2 Article9Payment ..n Article9Payment 1

BeneficialOwner ..n Article9Payment 2 Article9Payment ..n

Article4_2Payment 1

ResidualEntity 1 Article4_2Payment 2

Article4_2Payment ..n

Article4_2Payment 1

ResidualEntity 2 Article4_2Payment 2

Article4_2Payment ..n

Article4_2Payment 1

ResidualEntity ..n Article4_2Payment 2

Article4_2Payment ..n

Figure 36: Structure of FISC153 format for Initial Transmission

of Interest Payment Information

The message is composed of the following elements:

• Information provided under Art. 4.2 of the Council Directive: any number of Residual

Entity, each linked to one or more Article4_2Payment;

• Information provided under Art. 9 of the Council Directive: any number of PayingAgent,

each linked to one or more BeneficialOwner, in turn linked to one or more

Article9Payment.

A message may contain information exclusively concerning either Art. 4 of the Council Directive or Art. 9 of the Council Directive; alternatively, a message may contain information concerning both of these articles.

4.8.2. Correction Management Messages

The initially transmitted interest payment information may be subject to later corrections – update, delete, or creation of new information. The CA of PA may provide corrections either spontaneously, or on demand following a request from the CA of RIR.

Corrections are managed by providing each correctable entity in the initial transmission with a unique identifier. A subsequent correction of the entity must provide this identifier, which allows the CA of RIR to identify the original records; the correction must also provide, at the same time, a new unique identifier for the entity. If the entity is subject to a further correction, it is the new unique identifier that is referenced, and yet another unique identifier is provided for the entity.

The CA of RIR must also provide the unique identifier in any request for correction.

The correctable entities are:

• PayingAgent,

• ResidualEntity,

• BeneficialOwner,

• Article9Payment,

• Article4_2Payment.

The docRefId attribute of these entities contains the unique identifier.

4.8.2.1. MES-CORRECT Correction Message – Spontaneous or On-Request Correction of Interest Payment Information

A Correction Message is used by the CA of PA to send spontaneous corrections to the CA of RIR or to provide on-request corrections to the CA of RIR.

The message allows any number of correctable entities (listed in section 4.8.2) to be updated or deleted. It also allows new payment information to be added without the necessity to repeat PayingAgent and BeneficialOwner/ResidualEntity information.

The content of the Correction Message is defined in Table 32.

Attribute Description Valid Values Required, Optional, or Conditional

Sender The country or territory of the One of the countries or R sender territories listed in

Table 47, Table 48, or Table 49

Destination The country or territory of the One of the countries or R intended recipient. territories listed in

Table 47, Table 48, or Table 49

Date The current date Timestamp R

ID Unique identifier for the Text R message

Correction The correction information. List of Correction R

Details Information (see Table

33).

Table 32: Data Elements for MES-CORRECT – Correction Message

Attribute Description Valid Values Required, Optional, or Conditional

ReqRefId Request ID of the request for Text C The field must be empty for correction, if any, that prompted spontaneous corrections. For the corrections. on-demand corrections, it must echo the Request ID of the corresponding request for correction.

DocRefID A new unique identifier for the Text. R

correctable entity for which a The identifier must correction is provided. commence with the

This replaces the identifier code of one of the previously provided for the countries or territories correctable entity. listed in Table 47, Table 48, or Table 49 for the CA of PA.

CorrDocRefId The identifier of the correctable Text. C This must echo the last

entity for which a correction is The identifier must DocRefiId provided with the provided. commence with the entity that is to be corrected, code of one of the unless the correction is countries or territories providing new information, in listed in Table 47, which case the field must be Table 48, or Table 49 empty.

for the CA of PA.

Action The action that must be One of: R

performed on the information Repeat

identified for correction Add

Update

Delete

Correction The corrected information. One of C This information is provided

Value ResidualEntity only when Action is Add or

Article4_2Payment Update

PayingAgent BeneficialOwner Article9Payment

Link ID Identifier that links new payment Text C Must be provided when

information to the relevant Must refer to a Action is Add and Correction BeneficialOwner or DocRefId of a Value contains either ResidualEntity or a BeneficialOwner, a Article4_2Payment, BeneficialOwner to a ResidualEntity or a Article9Payment or PayingAgent. PayingAgent. BeneficialOwner

Table 33: Data Elements for Correction Information

4.8.2.2. MES-CORREQ Request for Correction – Interest Payment Information

The CA of RIR may send a Request for Correction message to the CA of PA asking the latter to correct information that it has already transmitted.

Attribute Description Valid Values Required, Optional, or Conditional

Sender The country or territory of the One of the countries or R sender territories listed in

Table 47, Table 48, or Table 49

Destination The country or territory of the One of the countries or R intended recipient. territories listed in

Table 47, Table 48, or Table 49

Date The current date Timestamp R

ID Unique identifier for the Text R message

Correction Information to identify the data List of Correction R

Request that need to be corrected Request Information

Details (see Table 35)

Table 34: Data Elements for MES-CORREQ

Attribute Description Valid Values Required, Optional, or Conditional

ReqRefId Unique identifier for the request Text R

DocRefID The unique identifier for the This must echo the R correctable entity for which a corresponding identifier

correction is requested. originally provided with the piece of information for which a correction is requested.

ErrorType Type of error One from a set of defined R

error types.

See Table 45

Reason Reason for error One from a set of R defined error reasons.

See Table 46

Details Any information that may be Unrestricted O useful for the recipient of the

correction request to identify and correct the error.

ExpectedValu The value that the recipient of One of O

e the original information ResidualEntity

expected to see – for example,

the information provided by the Article4_2Payment

RIR or information from its own PayingAgent

data systems. BeneficialOwner

Article9Payment

Table 35: Data Elements for Correction Request Information

4.8.2.3. Response to Request for Correction

The response to a Request for Correction is the same as a spontaneous correction message (MES-CORRECT, defined in section 4.8.2.1) except that the ReqRefId of each Correction Information echoes the ReqRefId of the corresponding Correction Request Information.

4.8.2.4. MES-CANREQ Cancellation of Request for Correction – Interest Payment Information

The CA of RIR may decide to cancel a request for correction that it has submitted to the CA of PA

Attribute Description Valid Values Required, Optional, or Conditional

Sender The country or territory of the One of the countries or R sender territories listed in

Table 47, Table 48, or Table 49

Destination The country or territory of the One of the countries or R intended recipient. territories listed in

Table 47, Table 48, or Table 49

Date The current date Timestamp R

ID Unique identifier for the Text R message

RequestRejec Identifiers of the correction List of one or more R tions requests that must be cancelled identifiers, each of

which must correspond to a ReqRefId contained in a previous correction request message.

Table 36: Data Elements for MES-CANREQ

4.8.2.5. MES-REJREQ Rejection of Request for Correction – Interest Payment Information

The CA of PA, after receiving and analysing a request for correction from the CA of RIR, may decide to reject it.

Attribute Description Valid Values Required, Optional, or Conditional

Sender The country or territory of the One of the countries or R sender territories listed in

Table 47, Table 48, or Attribute Description Valid Values Required, Optional, or

Conditional Table 49

Destination The country or territory of the One of the countries or R intended recipient. territories listed in

Table 47, Table 48, or Table 49

Date The current date Timestamp R

ID Unique identifier for the Text R message

CorrectionRej Information describing the List of one or more R etions requests that have been rejected CorrectionRejection

and the reasons for each (see Table 38)

Table 37: Data Elements for MES-CANREQ

Attribute Description Valid Values Required, Optional, or Conditional

ReqRefId Identifier of the request for Text. R

correction that is rejected This must correspond

to the ReqRefId of a previously sent request for correction

Reason A reason for the rejection of the One of the reason codes R request for correction listed in Table 39

Details Any other information needed to Unrestricted O complement the rejection

Table 38: Data Elements for CorrectionRejection

Description

The information is already correct

The request for correction is outside the scope of the Council Directive

Correction information is unavailable

No data had to be provided (e.g. withholding tax is applicable or use of a certificate)

There was insufficient information in the request for correction to process it

Table 39: Correction Request Rejection Reason Codes

4.8.3. Exception Management

4.8.3.1. MES-REJECT Rejection Message

The recipient of a transmission may send a rejection message when the content of the message is syntactically invalid. This applies to the initial transmission of interest payment information, correction request and response messages, and spontaneous transmission of correction information.

Attribute Description Valid Values Required, Optional, or Conditional

Sender The country or territory of the One of the countries or R sender of the rejection message. territories listed in

Table 47, Table 48, or Table 49

Destination The country or territory of the One of the countries or R territories listed in

Attribute Description Valid Values Required, Optional, or Conditional

intended recipient. Table 47, Table 48, or

Table 49

Date Current date Timestamp R

ID Unique identifier for the Text R message

Rejected Identifier for the piece of Text O

Message ID information in which syntax If present, this must error was detected correspond to a

DocRefId of an intial transmission or transmission of correction information, or to the ReqRefId of a request for correction

ErrorType Type of the error One from a set of defined R

error types.

See Table 45.

Reason Reason for error One from a set of O defined error reasons.

See Table 46

Error Details A description of the error in Unrestricted O order to help the sender of the

syntactically incorrect message make corrections. For example, this could be the error output from the message parser.

Table 40: Data Elements of MES-REJECT

4.8.4. Examples of Messages

This section provides examples of the messages presented in sections 4.8.1 and 4.8.3.

4.8.4.1. Initial Transmission

Table 41 represents an initial transmission of interest payment information from ES to DE.

Sender ES

Destination DE

Interest Payment Information

PayingAgent[ESPA1]

BeneficialOwner[ESBO1]

Article9Payment[ESP1]

Article9Payment[ESP2]

BeneficialOwner[ESBO2]

Article9Payment[ESP3]

PayingAgent[ESPA2]

BeneficialOwner[ESBO3]

Article9Payment[ESP4]

ResidualEntity[ESRE1]

Article4_2Payment[ES4P1]

Table 41: Message Example – MES-INITIAL - Initial Transmission The message contains information from two Paying Agents: the first Paying Agent provides information for two Beneficial Owners, having two and one payment; the second Paying Agent provides information for one payment to one Beneficial Owner. The message also contains information for a payment made to a Residual Entity. The text in square brackets represents the unique identifier for the correctable entity (i.e. the docRefId).

4.8.4.2. Spontaneous Correction

Table 42 represents a spontaneous correction of information.

Sender ES

Destination DE

Correction Details

ReqRefId

DocRefId ESP5

n 1 CorrDocRefId ti o

ec Action Add

o rr Correction Value Article9Payment C

Link ID ESBO1

ReqRefId

 2 DocRefId ESBO2bis CorrDocRefId ESBO2

ti o

n

ec Action Update

rr Correction Value BeneficialOwner*

C o Link ID

ReqRefId

DocRefId ESP2bis

CorrDocRefId ESP2

ti o n 3

ec Action Delete

Correction Value

C o

rr

Link ID

Table 42: Message Example – MES-CORRECT - Spontaneous Correction

The message is sent from ES to DE. The information is provided spontaneously, not in response to a request for correction, therefore the ReqRefId fields are empty.

The message contains three corrections.

• The first correction informs DE that there is an additional payment that was missed from

the initial transmission of information. This payment is given a unique identifier ESP5. The Link ID tells DE that this payment belongs to the Beneficial Owner identified by

ESBO1 in a previous transmission.

• The second correction simply tells DE to update the Beneficial Owner identified as

ESBO2 with the supplied Correction Value. The updated Beneficial Owner is given a new

unique identifier, ESBO2bis.

• The third correction tells DE to delete the payment identified as ESP2. A new DocRefId,

ESP2bis, is provided for conformance with the message format; this identifier has no

functional use.

4.8.4.3. Correction Request

Table 43 represents a request for correction of information. The request refers to information provided in the message described in section 4.8.4.1.

Sender DE

Destination ES

Correction Request Details

ReqRefId DEREQ1

t 1 DocRefId ESBO1 u es ErrorType ERR_MSG_SEMANTIC_INVALID

eq Reason The name is incorrect

n R ti o Details

ec rr

C o

Expected Value BeneficialOwner*

ReqRefId DEREQ2

t 2 DocRefId ESP3 u es ErrorType ERR_MSG_SEMANTIC_INVALID

eq Reason The security identifier number is

n R incorrect ti o

ec Details

rr

C o

Expected Value

Table 43: Message Example – MES-CORREQ - Correction Request

The message is sent from DE to ES.

The message contains two requests for correction, having unique identifiers DEREQ1 and DEREQ2.

The first request for correction concerns a Beneficial Owner with identifier ESBO1. DE believes the name supplied by ES is incorrect (for example, the Beneficial Owner information may have contained a TIN and the name associated with the TIN in the national database of DE may be different from the name supplied by ES).

DE optionally provides the name it expected to see (for example, the name in its national database associated with the TIN). This information may be of use to ES or the Paying Agent in tracking down the source of the error.

The second request for correction in the message concerns the Article9Payment with identifier ESP3. DE believes the security identifier number is incorrect (for example, an ISIN may have been provided that does not correspond to a real security).

In this case, DE has no expected value to provide.

4.8.4.4. Correction Response

Table 44 represents a response to a request for correction of information. The response refers to the request message described in section 4.8.4.3.

Sender ES

Destination DE

Correction Details

ReqRefId DEREQ2

 1 DocRefId ESP3bis

ti o

n CorrDocRefId ESP3

ec

rr Action Update

C o Correction Value Article9Payment*

Link ID

Table 44: Message Example – MES-CORRECT - Correction Response

The message from ES tells DE to update the payment identified as ESP3 with the provided correction value (which may, for example, contain a revised ISIN). The payment is given a new unique identifier, ESP3bis. ES has echoed the ReqRefId DEREQ2 of the corresponding request for correction in its response.

The correction response message contains just one correction, whereas the correction request contained two requests for correction. This is entirely in order – the recipient of a message containing multiple requests for correction may reply with several messages.

4.9. Logical Error Codes and Reason Codes

Table 45 defines the logical error codes that may occur during the initial automatic exchange of interest payment information or correction processes. The errors are grouped into the following logical categories:

Syntactic Errors – those logical errors relating to problems with the format of data;

Semantic Errors – those logical errors relating to problems with the content or processing of exchanged information.

Logical Error Code Description

Syntax Errors

ERR_MSG_SYNTAX_INVALID Syntax error found in the message.

Semantic Errors

ERR_MSG_SEMANTIC_INVALID There is a semantic error in the message.

Table 45: Logical Error Codes

Table 46 lists reason codes that may be linked to the ERR_MSG_SEMANTIC_INVALID or ERR_MSG_SYNTAX_INVALID errors.

Description

ERR_MSG_SYNTAX_INVALID

Message not well-formed

Message not compliant with schema

Description

ERR_MSG_SEMANTIC_INVALID

The country of residence of the beneficial owner is different from the country of the message recipient

The name is incorrect

The address is incorrect

The TIN is incorrect

The date of birth is incorrect

The place of birth is incorrect

The date does not correspond to the fiscal year for the payment(s)

The specific payment type code is incorrect

The year of the payment is incorrect

The savings account number is incorrect

The security identifier number is incorrect

The SWIFT code is incorrect

The amount of interest is incorrect

The destination country of the message does not correspond to the actual recipient country

The issuer of the TIN is different from the country of the message recipient

Table 46: Error Reason Codes 5. N ON -F UNCTIONAL R EQUIREMENTS

The non-functional requirements refer to the qualities the stakeholders expect from a technical architecture:

• Qualities related to the way the functional requirements are satisfied, being judged not in

terms of internal implementation, but rather in terms of characteristics observable or measurable by the end-users (run-time qualities);

• Qualities related to the development process, including the effort and cost associated with

current development as well as support for future changes or uses (development-time qualities).

The following sections list the non-functional requirements that the technical architecture supporting the exchange of interest information will be expected to meet.

Those sections are presented under the form of a table of requirements, including the requirement identifier, a short description of the requirement, and an evaluation of the requirement, according to the convention defined in section 1.5.

5.1. Usability

Usability requirements concentrate on the ability of the system supporting the exchange of interest payment information to be used by the end-users. It includes all the facilities developed or put into place to assist new end-users in getting operative.

ID Description Priority Responsibility

[NF.USE.01] Ease of Use Must Do. National Public Domain The system must provide consistent user interfaces,

menus and commands across all parts of the application to assist users in their day-to-day work, and to help new users in getting “up to speed”.

[NF.USE.02] Error Messages Must Do. National Public Domain,

The system must produce meaningful error messages Common Domain

that give users a clear prompts as to how to take corrective action.

[NF.USE.03] Documentation Must Do. National Public Domain,

An extensive documentation of the system must be Common Domain

provided to all the end-users expected to interact with the system. This documentation must cover at least all functions able to be accessed by the end-users. The best should be that this documentation is tailored to match end-users specific role.

[NF.USE.04] Online Help Should Do. National Public Domain

An extensive online help facility should be included in the application. This online help is expected to cover all user functions, is indexed and fully searchable.

[NF.USE.05] Training Should Do. National Public Domain End-users will require training in how to use the

system. Training must be tailored to match the different roles of the users.

ID Description Priority Responsibility

[NF.USE.06] Learn Ability Should Do. National Public Domain This requirement concentrates on the ability of the

system supporting the exchange of interest payment information to be easily learned by the end-users.

5.2. Security

Security requirements focus on the measures to be put into place to ensure a good protection of the interconnected systems and of the information circulating between those systems.

ID Description Priority Responsibility

[NF.SEC.01] System Availability Must Do. National Public Domain,

The system availability depicts the proportion of time Common Domain

the technical architecture supporting the exchange of interest information is in a functioning condition. Due to the low periodicity of the exchanges of interest information (in principle once a year, excluding corrections), and on the non-criticality of the processes supporting those exchanges, a high level of availability of the technical architecture is not justified from a business perspective. A rate of 90% is considered acceptable for the overall system availability. Note The fiscal period ends on 31 December for all MS but GB, therefore for initial information transmissions the system must expect a usage peak in the first half of the year, and almost no usage in the last two months.

[NF.SEC.02] System Availability Statistic Should Do. National Public Domain,

Statistical process is recommended to be Common Domain

implemented with the purpose to provide input about the overall system availability.

[NF.SEC.03] Integrity Must Do. National Public Domain,

The technical architecture must ensure that Common Domain

transmitted information is protected from any intentional corruption (e.g., via unauthorised creation, modification, deletion), or unintentional corruption, thereby ensuring that the transmitted information is complete and accurate, and can be trusted.

[NF.SEC.04] Reliability Must Do. National Public Domain,

The reliability concerns the ability of the exchange of Common Domain

interest payment information system to behave consistently in a user-acceptable manner when operating within the environment and the period of time for which the system was intended. The technical architecture is required to ensure a high level of reliability, resulting in high level of confidence of the users of the system.

ID Description Priority Responsibility

[NF.SEC.05] Confidentiality – Legitimate Use of the System Must Do. National Public Domain,

The technical architecture supporting the exchange of Common Domain

interest payment information must ensure that unauthorized individuals and programs do not gain access to sensitive data and communications. The technical architecture must ensure provision of access to data and communications on a “need to know” basis, thereby minimising the risk of loss of userconfidence or of legal liabilities. The technical architecture supporting the exchanges of interest payment information between the Competent Authorities must ensure that only authorised users in the intended Competent Authority will be able to access the information according to user privilege.

5.3. Business Continuity

The business continuity requirements qualify the ability of the system supporting the exchange of interest payment information to continue to reach its objectives after an unexpected event with minor or major consequence (Disaster). This requirement is principally achieved through the deployment of redundant hardware and software, the use of fault tolerant systems, as well as a solid backup and recovery strategy.

ID Description Priority Responsibility

[NF.BSN.01] Safeguard of Service Continuity Must Do. National Public Domain,

An operational process must be put into place to Common Domain

ensure a permanent safeguard of service continuity, including preventing, detecting and correcting service disruptions. This includes a continuous monitoring of the systems supporting the exchange of interest payment information, a permanent logging of the events and technical failures linked to the exchanges of information, and a full technical support of the system to correct service disruptions.

[NF.BSN.02] Backup Procedure Must Do. National Public Domain In particular, the Competent Authority of the

territories applying the exchange of information mechanism in support of the Council Directive must ensure that the information regarding interest payment is backed up for a minimum period of 6 months. This requirement is applicable to the Competent Authority of the sending territories. This is a should do for the Competent Authority of the recipient territories.

The minimum requirement is that the interest payment related information must be able to be resent during a period of time of 6 months. If the Competent Authority of the sending country is not in position to deal with internal back-up / restore process for any legal or technical reason, the Competent Authority of the sending territory must put into place a process to recover this information from the Paying Agent.

ID Description Priority Responsibility

[NF.BSN.03] Recovery Procedures Must Do. National Public Domain Recovery procedures must be put into place to deal

with disruption of any component of the technical architecture due to unexpected event. The technical architecture must be fully operational after a period of time of 2 weeks after the disruption. Recovery procedures must be put into place to deal with disastrous events. The overall technical architecture must be recovered and fully operational within a period of time of 1 month after a disaster.

[NF.BSN.04] Fallback Transmission Means Should Do. National Public Domain Fallback transmission means should be used in case

of disruption of the primary transmission channel, with the same level of security for the transmission of the information and related processes. Due to the periodicity of the transmissions (yearly) and the level of criticality of the business processes in support of the Council Directive, this requirement is considered a nice to have.

5.4. Quality of Service

Those requirements concern the performance required for the transmission of the interest payment information between the Competent Authorities.

ID Description Priority Responsibility

[NF.QoS.01] System Capacity Must Do. National Public Domain,

The fiscal period ends on 31 December for all MS Common Domain

but GB, therefore the system is expected to accommodate usage peaks in May and June, and almost no usage in November and December.

ID Description Priority Responsibility

[NF.QoS.02] Response Time Should Do. National Public Domain,

Due to the low periodicity of the exchanges of Common Domain

interest information (in principle once a year, excluding corrections), and on the non-criticality of the processes supporting those exchanges, a high level of response time is not justified from a business perspective.

[NF.QoS.03] System Scalability Must Do. National Public Domain,

The system must be extendable to be in position to Common Domain

absorb any potential traffic increase or any reduction of timeframe for the processing of the interest payment information.

The following factors are expected to result in information traffic fluctuations: 2. Subjecting savings of individuals to effective taxation will reduce distortions in capital flows, resulting in the reduction of the size of interest payment information to be exchanged between the Competent Authorities;

• 3. 

  Continuing moves to encourage cross-border competition in the services sector will have an impact on the amount of exchanged information, in the sense of a regular and slow growing;

• 4. 

  The movement of the labour force within the Community will imply an increase of the amount of exchanged information;

• 5. 

  The Council Directive foresees a transitional period, allowing some Member States, Third Countries and Associated Territories to apply the withholding tax as taxation mechanism. Due to the temporary character of those dispositions, it is likely that the traffic will mark a sharp and significant peak at the end of the transitional period, when this option will no more be applicable;

• 6. 

  The arrival of new countries in the European Community is expected to have an impact on the traffic in the sense of sudden but limited steps of growth of the exchanges.

The combination of all those factors is expected to result in the following fluctuation of the traffic regarding interest payment information: 7. During the transitional period, it is likely that the traffic will tend to grow smoothly and regularly; 8. At the end of the transition period, while countries will be encouraged to adopt the exchange of information as taxation mechanism, the traffic will mark a sharp significant peak; 9. After the transitional period, due to the reduction of the distortions between the countries, maybe compensated by a natural growth of the cross-border competition in

ID Description Priority Responsibility the services sector, the traffic will possibly

be stable or decrease regularly. All those factors incite to design the system architecture in such a way that it will be able to support fluctuating traffic, which requires it to be scalable.

However, there is currently no means to determine precisely the evolution of the traffic for to come years.

[NF.QoS.04] Capacity Management Should Do. National Public Domain,

Resulting from the fluctuations identified in the Common Domain

previous section, and from the difficulty to evaluate the traffic growth for future years, it is strongly recommended – although not required – to develop statistical processes regarding the exchange of interest payment information, in order to have a valuable input for an extensive capacity management of the overall system.

5.5. Legal

ID Description Priority Responsibility

[NF.LEG.01] Compliance Must Do. National Public Domain,

This requirement considers the ability of the Common Domain

information to comply with laws, regulations, and contractual arrangements to which the business process is subject, imposed by external criteria and internal policies. Legal texts to be complied with include: 10. Commission Decision C(2006) 3602 on the protection of information systems laying down measures to protect information systems against potential threats which could affect their integrity, availability and confidentiality, so as to keep risks to an acceptable level ; 11. Commission Decision 2001/844/EC i, notified under number C(2001) 3031, which lays down the basic principles and minimum standards of security to be respected in an appropriate manner by the Commission in all its places of employment, as well as by all recipients of Classified Information, so that security is safeguarded and each may be assured that a common standard of protection is established;

• 12. 

  Regulation 2001/45/EC, amending Council Directive 89/655/EEC i concerning the minimum safety and health requirements for the use of work equipment by workers at work (second individual Directive within the meaning of Article 16(1) of Directive 89/391/EEC i);

• 13. 

  Directive 95/46/EC i of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data;

• 14. 

  Council Decision 2001/264/EC i, which lay down the basic principles and minimum standards of security to be respected in an appropriate manner by the Council, by the General Secretariat of the Council, by the Member States and by the decentralised agencies of the European Union, so that security of European Union classified information is safeguarded and each may be assured that a common standard of protection is established.

5.6. Development Qualities

ID Description Priority Responsibility

[NF.DEV.01] System Configurability Should Do. National Public Domain

The system supporting the exchange of interest information should be configurable in order to present a high level of flexibility.

[NF.DEV.02] System Testability Should Do. National Public Domain The system supporting the exchange of interest

information should be easily and thoroughly tested.

• 6. 

  A SSUMPTIONS / C ONSTRAINTS / R ISKS

This chapter will present the list of assumptions and constraints prevailing to the production of this specification document. It will then deduce the list of risks if any of those assumptions or constraints is not met.

6.1. Assumptions and Constraints

The current section presents the legal and business assumptions and the technical constraints applicable to this document.

6.1.1. Legal Assumptions

The following legal assumptions, specified in the Council Directive, have been considered for the resolution of this specification:

• Member States shall take the necessary measures to ensure that the tasks necessary for the

implementation of the Council Directive are carried out by Paying Agents established within their territory, irrespective of the place of establishment of the debtor of the debt

claim producing the interest (Art.1.2);

• Each Member State shall, within its territory, adopt and ensure the application of the

procedures necessary to allow the Paying Agent to identify the Beneficial Owners and their residence for the purpose of Articles 8 to 12 related to the information reporting by the Paying Agents, the dispositions adopted for transitional period, the withholding tax

and the revenue sharing (Art. 3.1);

• Third Countries specified in the appendix of the current document apply, from 1 st of

January 2005, measures equivalent to those contained in the Council Directive in accordance with agreements entered into by them with the European Community (Art.

17.2).

• Dependent and Associated Territories specified in the appendix of the current document

st

apply, from 1 of January 2005, the same measures as those contained in the Council Directive in accordance with agreements entered into by them with the European

Community (Art. 17.2).

6.1.2. Business Assumptions

This specification document has considered the following business assumption:

• Correction processes are implemented for good working of the Council Directive. These

processes will use FISC153 format for the exchange of related interest information;

6.1.3. Technical Constraints

The following technical constraint has been identified in this specification document:

• The selected channel(s) for communication must satisfy the non-functional requirements

set out in chapter 5. Especially, the selected channel must satisfy all non-functional requirements, in particular the requirements related to the volume of information to be

exchanged.

6.2. Risks

Resulting from the preceding legal, business and technical assumptions and constraints, the following but not limited list of risks and resulting non desirable effects has been identified so far, which could jeopardise the good functioning of the Council directive:

• Legal Risk: If any of the MS do not adopt the necessary measures for their national

processes:

• Information will not be effectively shared;

• Savings interest of affected Beneficial Owners will not be subjected to effective

taxation;

• Capital flight and market distortions may occur;

• MS administrations may become disillusioned with the process.

• Legal Risk: If any of the Third Countries or Dependent and Associated Territories

specified in the appendix of the current document do not apply measures equivalent to or

the same as those defined in the Council Directive:

• Information will not be effectively shared;

• Savings interest of affected Beneficial Owners will not be subjected to effective

taxation;

• Capital flight and market distortions may occur;

• If the correction process is not applied by any of the MS:

• Quality of data will suffer.

• 7. 

  A PPENDICES

7.1. Reference Data

7.1.1. ISO-3166 Alpha 2 Country Codes

This section contains the ISO-3166 Alpha 2 country codes for Member States, relevant Third Countries and Dependent and Associated Territories [R08].

7.1.1.1. Member States

Country Name ISO-3166 Alpha-2 Code

Austria AT

Belgium BE

Bulgaria BG

Cyprus CY

Czech Republic CZ

Germany DE

Denmark DK

Estonia EE

Greece GR

Spain ES

Finland FI

France FR

United Kingdom GB

Hungary HU

Ireland IE

Italy IT

Lithuania LT

Luxembourg LU

Latvia LV

Malta MT

The Netherlands NL

Poland PL

Portugal PT

Romania RO

Sweden SE

Slovenia SI

Slovakia SK

Table 47: List of ISO-3166 Alpha 2 Codes for Member States

7.1.1.2. Third Countries

Third country name ISO-3166 Alpha-2 Code

Switzerland CH

Monaco MC

Andorra AD

Liechtenstein LI

San Marino SM

Table 48: List of ISO-3166 Alpha 2 Codes for Third Countries 7.1.1.3. Dependent and Associated Territories

Territory name ISO-3166 Alpha-2 MS to which Code Territory is Associated or on which it is Dependent

Anguilla AI GB

Aruba AW NL

British Virgin Islands VG GB

Cayman Islands KY GB

Guernsey GG GB

Isle of Man IM GB

Jersey JE GB

Montserrat MS GB

Netherlands Antilles AN NL

Turks and Caicos TC GB Islands

Table 49: List of ISO-3166 Alpha 2 Codes for Dependent and Associated Territories

7.1.2. Selected ISO-4217 Alpha-3 Currency Codes

Table 50 lists a selection of ISO-4217 Alpha-3 currency codes [R09].

Currency Code

Australia, Dollars AUD

Bulgaria, Leva BGN

Canada, Dollars CAD

Switzerland, Francs CHF

Cyprus, Pounds CYP

Czech Republic, Koruny CZK

Denmark, Kroner DKK

Estonia, Krooni EEK

Euro Member Countries, Euro EUR

United Kingdom, Pounds GBP

Hong Kong, Dollars HKD

Croatia, Kuna HRK

Hungary, Forint HUF

Iceland, Kronur ISK

Japan, Yen JPY

Lithuania, Litai LTL

Latvia, Lati LVL

Malta, Liri MTL

Norway, Krone NOK

Poland, Zlotych PLN

Romania, New Lei RON

Russia, Rubles RUB

Sweden, Kronor SEK

Slovenia, Tolars SIT

Slovakia, Koruny SKK

Turkey, New Lira TRY

United States of America, Dollars USD

Table 50: Non-Exhaustive List of ISO-4217 Alpha 2 Currency Codes 7.2. Territorial Features

Table 51 summarises various features specific to the countries and territories that are affected by the Council Directive. Where a table cell is empty, the corresponding information is unknown.

9 f

n

o f o n

 - g 11 rt . io d

in 1 a te o 13

Country or Territory ci

ty u ct io ro g e a ti ld ry re

ed .1

.b a l er 15

14

ip a

n

rm 10 h

o rt .

1

n ta 12

fo .

9 th o su a

x -

 a

.1 . ti

fi ca 1 3 u id ty l P re su

R ec E x

ch

In a rt Wi ta V o

lu

d is

cl

1 3 C er n D . n o a rt R es E n

ti

F is

ca

C lo

EU Member States

All MS except AT, BE, GB, LU Y Y N N NA Y 31/12

Austria Y N Y N Y Y 31/12

Belgium Y N Y N Y Y 31/12

Luxembourg Y N Y Y Y Y 31/12

United Kingdom (Gibraltar) Y (Y) Y (N) N (Y) N (Y) NA (Y) Y ( ) 05/04 (30/06)

GB Crown Dependencies

Jersey Y N Y Y Y Y 31/12

Guernsey Y N Y Y Y Y 31/12

Isle of Man Y N Y Y Y Y 05/04

GB Caribbean Territories

Anguilla N Y N N NA Y 31/12

British Virgin Islands Y N Y Y Y Y 31/12

Cayman Islands N Y N N NA Y 30/06

Montserrat Y Y N N NA Y 31/12

Turks & Caicos Islands N N Y Y Y Y 30/09

NL Caribbean Territories

Aruba Y Y N NA NA Y 31/12

The Netherlands Antilles Y N Y Y Y Y 31/12

Third Countries

Andorra N N Y N Y N 31/12

Liechtenstein N N Y Y N N 31/12

Monaco N N Y Y N N 31/12

San Marino N N Y Y N N 31/12

Switzerland N N Y Y N N 31/12

Table 51: Territorial Features

9 Indicates if the country or territory requires reciprocity, that is, whether savings of its citizens who are

resident in a MS should be subject to information exchange or withholding tax.

10 Indicates if the country or territory applies the exchange of information mechanism. 11 Indicates if the country or territory applies the withholding tax mechanism. 12 Indicates if the country or territory permits beneficial owners voluntarily to authorise information

exchange rather than have withholding tax deducted from their savings.

13 Indicates whether the country or territory accepts a Certificate of Non-Deduction issued to the

Beneficial Owner by the Competent Authority of his Member State of Residence.

14 Indicates if the country or territory recognises the concept of a Residual Entity.

EN 147 EN

7.3. Allowed Values for Specific Payment Type

Table 53 shows the allowed values that may be contained in the specificPaymentType attribute of interest payment information. This attribute is a four-character code that allows the CA of PA to report on the type of interest payment, under Art. 8.2 of the Council Directive.

Position 1 Position 2* Position 3* Position 4*

Specification of category of Combination of Specification of the Exclusion of interest

it io

n

interest (a, b, c, d, or e) or choice category (a to e) computation method st accrued before 1 July

used for Art. 6, 1 (d) 2005 (see ECOFIN

ef in

of the restrictive option of last with:

paragraph of Art. 8.2 (1 or 2) Total Amount : 1 interest. (see last Conclusion of n D paragraph of Art. 6.1): 12/4/2005):

ti o Interest/Income : 2 "Couponnage † ": 1 Yes : 1

P o

si

"Non couponnage": 2 No : 2

a Not relevant** Not relevant 1 or 2

es b 1 or 2 1 or 2 1 or 2

a lu c 1 or 2 Not relevant 1 or 2

 V

ed d 1 or 2 1 or 2 1 or 2 o w e 1 or 2 1 or 2 1 or 2

A ll 1 Not relevant Not relevant 1 or 2

2 Not relevant Not relevant Not relevant

Table 52: Allowed values for Specific Type of Income

• * 

  For positions 2 to 4, the values 1 and 2 can always be replaced by 'x' whenever the information is not available.

** In the case of 'Not relevant', the character 'x' must be set in the corresponding position.

† The term 'couponnage' means limiting the reported income to underlying interest, as provided for in the last paragraph of Art. 6(1) of the Council Directive.

Table 53 contains all possible values that result from applying the rules in Table 52, with the addition of the value ‘xxxx’, which is used when the information is not provided for an Art. 4.2 payment. The table does not include the values obtained by application of the first footnote for Table 52.

Allowed Values

axx1 b212 d111 d222 e221

axx2 b221 d112 e111 e222

b111 b222 d121 e112 1xx1

b113 c1x1 d122 e121 1xx2

b121 c1x2 d211 e122 2xxx

b122 c2x1 d212 e211 xxxx

b211 c2x2 d221 e212

Table 53: Possible Values for Specific Type of Income 7.4. Notation Catalogue

7.4.1. Entity Relationship Diagram

Figure 37 is an example of an entity relationship diagram. The purpose of such a diagram is to illustrate the cardinality of relationships between entities in the system.

Entities are shown as boxes and relationships are drawn as lines between the boxes.

Figure 37: Example of an Entity Relationship Diagram

 There is a “one-to-zero-or-more” relationship between Entity 1 and Entity 3.

 There is a “one-to-one” relationship between Entity 3 and Entity 4.

 There is a “one-to-one-or-more” relationship between Entity 5 and Entity 4.

 There is a “one-to-zero-or-one” relationship between Entity 2 and Entity 5.

 Entity 1 has three attributes: attribute1, attribute2, and attribute3. attribute2, shown in

bold, is mandatory

7.4.2. Process Flow Diagram

Figure 38 shows an example of a process flow diagram.

Figure 38: Example Process Flow Diagram

7.4.2.1. Process Flow Diagram Elements

Location

A location ( 1) is a logical place where a process occurs.

Event

An event ( 2) is an occurrence that triggers the business to respond in a predictable fashion.

An event causes a sequence of processes to start. The event is represented as a large arrow pointing from left to right and is drawn in the column of the location(s) where it happens. Each event name starts with an E- followed by the name.

For example:

Figure 39: Example of an Event

Elementary Business Process (EBP)

An elementary business process ( ) or process is represented as a single rectangle, containing the identifier and name of the process. Process names should focus on an active definition, beginning with a meaningful verb, followed by the object under consideration.

For example:

Figure 40: Example of an Elementary Business Process

An optional EBP ( ) is represented by a dashed rectangle.

For example:

Figure 41: Example of an optional Elementary Business Process

The EBP identifiers adhere to a defined structure, where each identifier is represented in the format ‘PP-AA-SSS’:

‘PP’ identifies whether the process is a business process (BUC) or a system process (SUC). For example, SUC-CA-PA-050 represents a system process.

‘AA’ identifies the principal business actor, e.g. SUC-CA-PA-050 (for CA of PA);

‘SSS’ is the identifier for the business process (e.g. “SUC-CA-PA-050). The identifier must be unique for a particular actor.

End of Process

The end of a process flow is depicted by a curve-edged rectangle:

Figure 42: Example of End of Process

7.4.2.2. Flows between the components

The exchange of information and artefacts between organisations and other processes are

shown as flows ( 56). Flows are represented as various forms of connecting lines the

diagram, terminating with an arrowhead to indicate the direction of the flow:

A mandatory flow within the same location ( 5) is represented by a narrow solid line. This

indicates that the flow always occurs in all cases. The flow is never optional or deviated from (Figure 43);

Figure 43: Mandatory flows within the same location

A mandatory flow between different locations ( ) is represented by a wide solid line. As before, the flow is mandatory, but the notation emphasises that the information exchanged between the processes occurs across multiple locations. This is important as it helps identify potential interfaces and communications mechanisms;

Figure 44: Mandatory flows between different locations

Where the identifier of the message that represents the data in the flow is written on the line.

7.4.2.3. Decision

A decision ( 7) is represented by a rhombus (Figure 45). Captions attached to the flows

exiting the rhombus describe the decisions.

Figure 45: Decision

7.4.3. Sequence Diagrams

Figure 46 is an example of a sequence diagram. A sequence diagram shows the sequence of messages that are exchanged between the actors of the system, arranged in time.

Figure 46: Example of a Sequence Diagram

 A solid vertical line is a timeline. Time flows from top to bottom.

 A stick man represents the actor sending or receiving the message.

 A solid arrow indicates the flow of information from one actor to another actor. The label above the arrow describes the information.

 A solid arrow starting an ending on the same timeline represents an internal process.

 A broken arrow represents an optional response.

 Blue underlined text at the left of the sequence diagram indicates the period in which the sequence may occur.

7 Red underlined text indicates the type of information:

• C – Creation

• U – Updates

• D – Deletion

• Any - Any

7.4.4. Element Definition Templates

Many of the elements that are presented in a process flow diagram are specified in greater detail using structured textual descriptions. This relates specifically to elementary business processes and entity definitions.

The following section includes the templates used in the FSS documentation.

7.4.4.1. Business or System Use Case Template

ID Name

Actor: Domain:

Taxation Mechanism: Event:

Description:

Constraints: -

 Table 54: Elementary Business Process Template

Each elementary business process is described by the following attributes.

• ID – a unique code that identifies the process.

• Name – a meaningful name that summarises the intent of the business process.

• Actor – The role responsible for performing the process.

• Domain – the domain or domains in which the process occurs.

• Taxation Mechanism – one of:

• Withholding Tax: Relates to the levying of withholding tax on savings interest

under Art. 11 of the Council Directive.

• Exchange of Information: Relates to the exchange of information regarding

savings interest payments under Art. 8 and 9 of the Council Directive.

• Common: Relates to both the Withholding Tax and the Exchange of Information

mechanisms.

• Constraints – any constraints, limitations or restrictions that apply to the business process.

For example, legal constraints, timing issues etc. If the field is blank, then no constraints

have been identified. Enumerated constraints are cumulative.

• Description – a description of the business process. This includes a description of the

activities within the elementary business process, the information being processed,

conditional operations etc.

• Event – This is an optional element included in some of the system use cases. It contains

any external events that may trigger the use case.

Met de EU Monitor volgt u alle Europese dossiers die voor u van belang zijn en bent u op de hoogte van alles wat er speelt in die dossiers. Helaas kunnen wij geen nieuwe gebruikers aansluiten, deze dienst zal over enige tijd de werkzaamheden staken.

De EU Monitor is ook beschikbaar in het Engels.