Depositor Compensation Scheme
Consultation Document on the setting up of a Fast Payout Mechanism &
Reform of Reporting Requirements
30/03/2012
Page | 1
Contents
1
Introduction .................................................................................................................................... 3
2
Current statutory obligations.......................................................................................................... 3
2.1
3
Electronic Information Transmission and Fast Payout System ....................................................... 4
3.1
SCV High-level Technical Architecture and Workflow ............................................................ 5
3.2
Required Information and Overview of the SCV Templates ................................................... 5
3.2.1
Template A ...................................................................................................................... 6
3.2.2
Template B ...................................................................................................................... 6
3.2.3
Template C ...................................................................................................................... 8
3.2.4
Templates D1 and D2 ...................................................................................................... 8
3.2.5
Codes............................................................................................................................... 8
3.2.6
Additional Notes ............................................................................................................. 9
3.3
Data Collection over a Secure Channel ................................................................................. 10
3.3.1
Access to the DCS SCV Hub ........................................................................................... 10
3.3.2
Directory tree ................................................................................................................ 10
3.4
4
Proposed arrangements under the Recast DGS Directive ...................................................... 4
Input File Format................................................................................................................... 11
3.4.1
Common features ......................................................................................................... 11
3.4.2
Format and Structure of CSV Files ................................................................................ 12
3.5
Confidentiality ....................................................................................................................... 13
3.6
Testing ................................................................................................................................... 13
Revision of Schedule LD7 .............................................................................................................. 14
4.1
Annexes ................................................................................................................................. 14
30/03/2012
Page | 2
1
Introduction
The Management Committee of the Depositor Compensation Scheme (DCS) is planning to reform a
number of reporting requirements by credit institutions in terms of the DCS regulations.
The reform has two objectives, namely to guarantee a fast compensation payout to all eligible
depositors within the period stipulated by the regulations in the event of a credit institution failure
as well as to enable the DCS to have access to consolidated data about eligible and insured/covered
deposits which is both timely and reliable.
In respect of the first objective, the Management Committee intends to develop an electronic
system to receive and process specific depositors’ data sent by credit institutions to the Scheme.
As to the second objective, the Management Committee is reviewing the statutory return ‘Schedule
LD7’, which credit institutions submit periodically to the MFSA.
The purpose of this document is for the Management Committee to engage with stakeholders on
the various aspects relating to this reform in the light of the current legislative requirements.
The information contained in this document is only intended for consultation purposes and does not
purport to represent or prejudge the final position that the Management Committee will take in
relation to the topics covered.
Stakeholders are invited to send their views on any aspects of the reform as outlined in this
document by 15 May 2012 to info@compensationschemes.org.mt. Responses will be published on
the Depositor Compensation Scheme’s website, unless a stakeholder requests that a submission
remains confidential.
2
Current statutory obligations
Regulation 13 of LN 369 of 2003 (DCS regulations) requires the competent authority to make a
determination “…as soon as possible and in any event no later than five working days after first
becoming satisfied that a credit institution has failed to repay deposits which are due and payable.”
Sub-paragraph (3) of the same regulation specifies that “as soon as practicable after a determination
is made, the competent authority shall inform the Management Committee in writing of such
determination…”
The determination will trigger a fast payout process to depositors of the affected credit institution.
In order to further foster the DCS’ preparedness, the Management Committee is proposing that the
Authority should give advance warning to the DCS of any impending processes that may lead to a
determination.
According to sub-paragraph 4 of Regulation 14 of LN 369 of 2003, “The Management Committee
shall proceed to pay compensation for verified claims within twenty working days from the date of
the determination given in terms of Regulation 13(1). This time limit includes the collection and
transmission of the accurate data on depositors and deposits, which are necessary for the verification
of claims”. The Competent Authority may, in wholly exceptional circumstances and in special cases,
allow an extension of 10 working days on application by the Management Committee.
30/03/2012
Page | 3
Furthermore, sub-paragraph 6 of Regulation 14 requires credit institutions to ensure “that they have
electronic information systems in place to the satisfaction of the Scheme to enable the Scheme to
process claims for compensation by depositors and this at all times, whether or not a determination
has been made under Regulation 13(1).”
The current regulations stipulate that before payout, a depositor is required to apply to the Scheme
for compensation. The Scheme may postpone payment until it is certain that the depositor is eligible
to receive compensation. The Scheme may also make partial payments where, in the opinion of the
Management Committee, circumstances so warrant.
Sub-paragraph 19(1)(c) also requires the Scheme to deduct from the total liability of the credit
institution “the amount of any liability of the depositor to that credit institution in respect of which a
right of set-off against the said deposit existed immediately before the notice of determination issued
in terms of Regulation 13 or in respect of which such a right would have existed had the said deposit
been repayable on demand and such liability fallen due immediately before the issue of such a notice
of determination.”
Regulation 26 empowers the Management Committee to request information from credit
institutions “…which the Management Committee may consider relevant for the proper
administration of the Scheme.” Any information which a credit institution communicates to the
Management Committee “…as may be required to enable the Management Committee and its
officers or agents to perform their duties and carry out their functions under these regulations” shall
not be in breach of the duty of confidentiality in terms of Regulation 27 of the same regulations.
2.1
Proposed arrangements under the Recast DGS Directive
Although discussions on the proposal for a re-cast Directive on Deposit Guarantee Schemes (July
2010) are on-going, there are certain aspects on which a broad consensus has already been reached
or likely to have been reached. For the purposes of the objectives for which this consultation has
been drawn up, it is likely that the payout period under a future directive is likely to remain 20
working days for a yet undefined number of years in order to allow the Schemes to setup
appropriate systems to manage the incidence of credit institution failures and the processing of
compensation payments. Thereafter, a shortened payout period will most likely come into force.
Moreover, a peer-review system is planned to be established in order to ensure that all Schemes
have the appropriate systems in place to discharge their duties under the Directive.
In addition, the recast Directive provides for all currencies to be covered up to EUR 100,000 (and
equivalent in any non-euro currency). Moreover, all depositors will be eligible to receive
compensation (except for a few exceptions) and set-off will no longer be applied on amounts not yet
fallen due. Depositors will not be required to apply to receive compensation, which essentially
requires credit institutions to have their data updated in real-time and have this readily available for
transmission to the Scheme for processing purposes.
3
Electronic Information Transmission and Fast Payout System
The key element of the reform is the creation of an electronic process by the Scheme which provides
for an efficient and secure transmission of customers’ information by a deposit taking credit
institution to the Scheme. For the purposes of the Scheme, a customer means any depositor of a
30/03/2012
Page | 4
credit institution, excluding those persons listed in the First Schedule of the Scheme’s Regulations
dated 21st November 2003, who is eligible to receive compensation in terms of the Schemes’
Regulations.
Each credit institution is responsible to develop/modify its internal IT systems to enable the
generation of the required data files with specific fields and codes that map the information
required on every eligible (certain and potential) depositor of the credit institution. For the purposes
of the Scheme, the information reported by a credit institution on its customers shall be called
Single Customer View (SCV) information and this may be composed of 1 or more data files as
explained further below. Upon determination of a credit institution’s failure under Regulation 13 of
the Scheme, the failed credit institution will be obliged to transmit the SCV data to the Scheme by
uploading its SCV file/s into the Scheme’s electronic system within a maximum of three working
days.
3.1
SCV High-level Technical Architecture and Workflow
The solution will namely consist of the main components and processes identified in the figure
presented below.
3.2
Required Information and Overview of the SCV Templates
Deposit taking credit institutions have already agreed, under the auspices of the Malta Bankers’
Association (MBA), customer data sets that the DCS would require to receive from a failed credit
institution in order to process its compensation obligations. However, new research and analysis
conducted since then revealed that the information to be reported needs to be enhanced to ensure
the timely and efficient processing of compensation payments to every eligible depositor of a failed
credit institution.
30/03/2012
Page | 5
To enable the automated processing of customer’s data, the DCS has prepared standard templates
containing the SCV information which credit institutions will be required to report on each customer.
For ease of reporting and processing of compensation payments, each template shall contain a
specific set of data, which is relevant for every particular client account scenario.
When there is a deemed determination, the failed credit institution will be required to compile the
following templates:
Template
Template A
Template B
Template C
Template D1
Template D2
Description
Customer details
Details of Account(s)
Claims against customer (With a right of set-off)
Aggregation details
Compensation details
A copy of each template is being attached to this document, such that every member of the Scheme
will ensure that it is in a position to provide all the necessary details as required by the Scheme.
Credit institutions are invited to review the contents, including the fields, codes and descriptions
contained in the templates and send any comments to the Scheme as mentioned further above in
this document
A description of the SCV templates is briefly outlined in the following sections and a soft-copy of
each template is being attached in Section 3.4.2.2
3.2.1 Template A
The identification and address details of a customer are to be included in this template.
In the event of joint accounts, each joint account holder shall be treated as a separate customer.
Moreover, where a customer is holding an account on behalf of other persons under a contractual
agreement (such as a deed of trust, nominee agreement etc.), the details of such customer should
also be reported in the generated file. The SCV Identifier (SCV Id) should be unique for each and
every customer. In cases where a particular customer features in more than 1 of the reported
templates, then the respective SCV Identifier (SCV Id) should link to this field to enable the required
relationships/linkages.
3.2.2 Template B
This template will contain the core information required on each account for every customer, which
will thereon form the basis for the compensation payable to the customer.
Specific fields are included in this table for the reporting of the designated currency of each account.
This will enable the compensation payment to be processed in the designated currency as per
Regulation 17 of the Scheme’s Regulations. Template B is divided into three classes of account
details so that the Scheme can determine the appropriate action required on the respective account
balance. The three classes are:
Class 1 – This class comprises the accounts which are “fit for straight-through payout” and will
include the current and savings accounts in which the holder is the underlying beneficiary. Joint
30/03/2012
Page | 6
accounts are included under this class, the amount of which shall reflect the joint account holder’s
share in line with Regulation 23 of the Scheme.
Class 2 – This includes “beneficiary accounts”. For the purposes of the SCV requirements, the owner
of a beneficiary account holds the account on behalf of underlying clients by way of a contractual
arrangement, such as a deed of trust etc. Beneficiary accounts are deemed “not fit for straightthrough payout” because they will require the Scheme to obtain more information, such as the
identification of each beneficiary, before payments of the respective compensations are effected.
As a consequence, the failed credit institution will also be required to provide the Scheme within a
period of time agreed with the Management Committee, with a list of the SCV identification
numbers and account numbers of all beneficiary accounts reported in Template B, together with the
following data on each respective beneficiary: Name, ID Number, Contact Details (Mail Address,
Email Address, Telephone Number), Beneficiary’s Share on the Account.
Class 3 – This includes all other accounts which are “not fit for straight-through payout”. Such
account class will encompass fixed term deposit accounts or any accounts which are blocked
because of any legal impediment. The compensation regarding fixed term deposit accounts will be
flagged for payment on the actual maturity of each deposit. In the case of any account with a legal
impediment, the Management Committee may decide to delay compensation payment until the
outcome of a legal resolution is finalised.
Any information available by the failed credit institution concerning this account status, which may
be of relevance for the Scheme to determine whether and when compensation payment may be
effected (E.g. The End Date of a Minor Status, Garnishee Order, Pledge File Number etc…), must be
included in the “Account Status Information” column to be reported with Template B for Case 3 only.
In the event of a current or savings account which is partially blocked, the blocked amount should be
reported as a Class 1 record on its own. The unblocked amount must be reported as a separate Class
3 record in the same Template.
In the case of a fixed term account which is partially blocked, the blocked and unblocked amounts
must also be reported in separate Class 3 records within Template B and marked by the relevant
account status codes as follows:


Blocked amount: E.g. “BLOCK” is the status for a blocked account
Unblocked amount: E.g. “TERM” is the status for an account that is flagged for payment on
maturity of deposit
Note: Refer to the Section 3.2.5 for a list of different possible account statuses.
Regarding accounts which are recorded in Template B, the failed credit institution will also be
obliged to provide to the Scheme with any further information available to it, which may assist the
Scheme to determine the way forward.
As mentioned earlier, and also in view of creating a robust SCV database, the details of every
account held by a customer must be recorded separately in the respective classes (Class 1; Class 2
and Class 3) of the SCV. For example, if a customer holds different accounts in the same account
30/03/2012
Page | 7
class (E.g. a current account and a savings account in Class 1) the details of both accounts must
feature in separate records of Template B. Furthermore, each record will be numbered for
identification purposes. The segregation of each customer account is intended to assist the Scheme
in its control functions and in addressing any queries from eligible depositors.
3.2.3 Template C
This template shall contain the details of any legal claims against a customer in respect of which, the
failed credit institution has a right of set off as per Regulation 19 of the Scheme’s Regulations. The
table will include fields for the reporting of the debit balance and accrued interest on any loan or
overdrawn account of the customer as well as for the reporting of the type of customer liability,
such as “house loan”, “overdraft” etc... To enable the automated processing of data, the “gross
balance” of any liability account (including the balance and accrued interest) with a right of set-off, is
identified by code “CLAIM1”.
Different liability accounts of a customer should also be reported as separate records.
3.2.4 Templates D1 and D2
Templates D1 and D2 contain the aggregate balances of the accounts which are fit for straightthrough payout and the other accounts which are not fit for straight-through payout (not including
“beneficiary accounts”). No consolidation of data is required in the case of beneficiary accounts
because of the reasons explained earlier. Where an eligible customer has more than one account per
class of account details (Class 1 or Class 3), the aggregate balances in Template D1 will reflect the
total of his separate account balances for each class and for each currency denomination
respectively. The designated currency and the exchange rate should be included in the aggregation
table to ensure compliance with the statutory compensation limit of €100,000 and to enable
payment of compensations in the designated currency as and where appropriate.
The compensation table (Table D2) will include the “net position” of each customer in EUR or EUR
equivalent, after deducting any claims over which the failed credit institution has a right of set-off
against the customer. The compensation due to a customer shall be based on the customer’s net
position. Where a customer holds accounts in different currencies and his aggregate deposit balance
exceeds the maximum compensation limit, the criteria to be used for the choice of the payment
currencies shall be as follows:


The default payment currency will be EUR
The residual balance will be paid in the currency of the account which has the highest (EUR
equivalent) amount.
3.2.5 Codes
To enable easier automation of data processing, the following specific codes will be required for the
identification of the account type, account holder type and/or the account status:
Field
Code
Description
Account Type
Current
Saving
Term
Current account
Savings account
Fixed Term Deposit account
30/03/2012
Page | 8
Account Holder Indicator
001
002/3/etc…
101
102
201
202
Account Status Code
FSTP
TERM
NOM
CLIENT
TRUST
OTHER
FRAUD
LAUND
DORM
BLOCK
PLEDGE
MINOR
DISP
GONEA
DEC
Single account holder
One of two joint account holders / one of
three joint account holders / etc…
Beneficiary account – Current or Savings
account
Beneficiary account – Fixed Term Deposit
account
Other Account Not Fit for Straight-Through
Payout – Current or Savings account
Other Account Not Fit for Straight-Through
Payout – Fixed Term Deposit account
Fit for straight-through payout
Account flagged for payment on maturity of
deposit
Nominee account
Client account
Trust account
Other beneficiary account
Fraud risk
Money laundering suspicion
Dormant account
Blocked account
Pledged account
Minor account
Legal dispute or competing claim on the
account
Account holder gone away
Deceased customer
3.2.6 Additional Notes
The above-mentioned information requirements are essential to guarantee an efficient and
transparent administration of compensation payments in the event of a credit institution failure.
The Management Committee is committed to ensure that every credit institution would have the
necessary resources and systems in place to be able to provide the information to the Scheme in line
with the above-mentioned requirements. Since it is likely that not all deposits will be fit for straight
through payout, it will be necessary for the Scheme to retain a channel of communication with the
credit institution in respect of which a determination has been made. Consequently the DCS is
recommending that all credit institutions should nominate an official in possession of the necessary
authority and with access to the credit institution’s records in order to respond to the information
requirements of the DCS.
The SCV requirements as mentioned in this consultation document are based on the current DCS
regulations. In the meantime, the Management Committee is following developments in the recast
Directive, which may require amendments in future in the local legislation. The Management
Committee will also consider recommendations from stakeholders which whilst simplifying the fast
payout process do not jeopardise the interests of depositors or breach the Directive. For this
purpose the Management would welcome the comments of stakeholders to the following measures:
30/03/2012
Page | 9



3.3
The compensation regarding fixed term deposits to be payable within the prescribed
compensation period instead of on maturity of the deposit
All compensation payments to be effected in Euro only
The elimination of the right of set-off against a customer in the calculation of the customer’s
compensation
Data Collection over a Secure Channel
The DCS through the SCV system that is being proposed here will be providing a channel for the
collection of data by allowing credit institutions to upload the required files by interfacing with the
DCS SCV hub through standard communication protocols. The DCS SCV hub is a central infrastructure
on which all credit institutions can connect using their own credentials (See Section 3.3.1) and
upload files in order to exchange them with the DCS SCV system.
Each credit institution will have its own area on a server hosted by the Malta Financial Services
Authority on behalf of the Depository Compensation Scheme that will be configured in a firewallprotected environment. This area will contain all files the entity has sent. Credit institutions will
connect to the hub using either FTPs1 or sFTP2 protocols. The manual exchange system using sFTP or
FTPs can also be automated. This automation is the responsibility of the credit institutions and it can
be done by using scripting languages.
The credit institutions are responsible for acquiring and maintaining their own software to connect
to the DCS SCV hub. Each credit institution decides the protocol and client to connect to the hub.
This client software should be fully compatible with the relevant protocols.
The DCS SCV hub supports the following protocols:
Standard Protocol:
FTP
Security Protocol:
SSL V3 and TLS V1; SSH2 and SFTP V3
3.3.1 Access to the DCS SCV Hub
The access to the DCS SCV Hub is performed using credentials (username / password). These will be
provided by the system administrator.
An agreed set of credentials will be delivered for each credit institution providing data to the DCS.
User access for any deposit taking credit institution shall be restricted to the SCV information of its
credit institution only. The profiles to be provided to the system administrators and to the DCS
management team shall enable these users to access all the information stored in the system.
3.3.2 Directory tree
As already mentioned, each credit institution will have its own area on the server that can be
accessed only by them. This area has the same directory structure for all entities. Whichever
protocol is used to connect, the credit institutions will have access to the same area (credit
institution area).
1
2
FTP over TLS/SSL (explicit encryption)
SFTP using SSH2 (SSH File Transfer Protocol)
30/03/2012
Page | 10
A possible tentative directory structure in each area allocated to each and every credit institution
may contain the following directories:





Incoming
Outgoing
Rejected
Archive / Incoming
Archive / Outgoing
The incoming directory will contain the files received/uploaded by the credit institution. The
outgoing directory is the folder to be used by the DCS in circumstances when it requires exchanging
files with a particular credit institution. Archive folders contain the files sent or received. Rejected
files are not archived in the archive / outgoing directory. The rejected folder contains erroneous
files, which have been sent and have been rejected by the HUB due to some kind of error.
3.4
Input File Format
In order to simplify the automation of the SCV system that is being proposed here the DCS considers
that one standard format should be applied and used by every credit institution for the transmission
of the file/s holding the required information. This will also enable an acceptable level of
harmonisation.
The MBA has already expressed its opinion that simple file formats such as CSV Files are preferred.
The Scheme will consider any feedback from the stakeholders on the file format and structure and
any problems that may be envisaged in the generation of the electronic files and their transmission
into the SCV system. The IT specifications and system design will be created following finalisation of
the consultation phase.
3.4.1
Common features
3.4.1.1 Naming Convention
The name of the SCV file/s must comply with the format below and only accepts Latin characters.
[CreditInstitutionID]_ [TemplateID]_SCV_[SequenceNumber]_[Timestamp].csv
Where:
[CreditInstitutionId] is the unique ID of the credit institution uploading the files
[TemplateID] is the name of the template on which this particular file is based
[SequenceNumber] is a unique sequence number on 6 digits. This field is completed with 0 to fit to 6
characters (for example 000524). This number is incremented each time an entity sends a file. This
sequence number does not depend on the file type, recipient or any other characteristic. It can start
again at 000000 after 999999. If the same file is sent again, a new sequence number is provided. This
number identifies uniquely a single file. Should a problem occur in the sending of a file, the sequence
number will help identifying a unique file.
[Timestamp] = YYYYMMDD
30/03/2012
Page | 11
Example of file name: BOV_TemplateA_SCV_000524_20120320.csv
For each uploaded SCV file matching any of the templates mentioned in Section 3.2, the credit
institution should also upload a corresponding header file. For the time-being, it is foreseen that this
file will contain the total number of records uploaded in the corresponding SCV data file. Sequence
number of the header file should precede that of the actual SCV file. In a similar way to the SCV file,
the same naming conventions apply but HDR is used instead of SCV as shown below:
[CreditInstitutionID]_ [TemplateID]_HDR_[SequenceNumber]_[Timestamp].csv
Example of file name: BOV_TemplateA_HDR_000523_20120320.csv
3.4.1.2 Files further characteristics
The data-entry encoding rules which constitute the records of files must be respected:
•
Alphanumeric fields: All type is allowed, either in capital or lower-case letter. (Exception:
Hellenic Alphabet and Cyrillic script are not allowed).
3.4.1.3 Delivery modes
The default mode in the DCS SCV system consists in an overwriting process for all data contained in
the submitted file. This means that data coming from each credit institution will erase the data
previously submitted if it has the same filename.
Further than this, the information transmitted by any credit institution shall be retained in the SCV
system until the liquidation proceedings are processed and all eligible compensations are duly paid
out and the statutory prescription period will have elapsed.
3.4.1.4 Volumetric analysis
A volumetric study will be carried out to identify the average maximum size of the files that will be
exchanged with the DCS SCV system. This study should take into account the number of credit
institutions that may potentially use this system in the eventuality that a credit institution fails.
Depending on the final outcome of this study, SCV files may require to be compressed and
encrypted using tools like WinZip before uploading them onto the DCS SCV hub. In this case to allow
the DCS SCV team to process the file/s, you will also need to send the password in a separate email
addressed to the DCS SCV system administrator.
3.4.2 Format and Structure of CSV Files
The format of the CSV files should correspond to a flat file format: each data field is separated from
one another by a “|”.
One CSV file must only contain data common to:

A single Excel Template from those specified in Section 3.2
3.4.2.1 Description of the Format
Global organization of CSV file format is the following:


Rows must be separated using a CR character (carriage return)
Columns must be separated using pipe delimiter ( | )
30/03/2012
Page | 12

Each single data must be surrounded by quote characters (“”)
 That includes empty values when allowed
3.4.2.2 Fields Description
The templates attached here describe the data expected for each and every template.
Template
Template A
Description
Customer details
File
Template A.xlsx
Template B
Details of Account(s)
Template B.xlsx
Template C
Claims against customer (With a right of
set-off)
Template C.xlsx
Template D1
Aggregation details
Template D1.xlsx
Template D2
Compensation details
Template D2.xlsx
3.5
Confidentiality
In the event of any contractual arrangements entered into by the Scheme with a third party for the
provision of any services on the processing and management of compensations, the third party shall
be legally bound by a non-disclosure agreement. Furthermore, the third party will be bound to
cleanse any data derived from the Scheme, on completion of its services to the Scheme.
3.6
Testing
The Scheme’s electronic system and procedures are planned to be rigorously tested and will require
the involvement of the member credit institutions in the process through the transmission of
“dummy” or “real” data to the system. The use of “dummy” data processing is intended to enable
the Scheme to receive data which does not factually reflect that of the existing customers of credit
institutions (e.g. camouflaging depositors’ names, addresses and identification number details), thus
ensuring that the customers’ confidentiality is maintained during any test processes. However,
certain testing may be conducted on the basis of the actual descriptive and quantitative data held by
the credit institutions (such as account balances, account status, individual aggregate balances of
every customer) without the need to divulge the identity of any customer.
Rigorous stress testing is also planned to be undertaken to the system to ensure that the SCV
platform is a resilient one and is able to manage the maximum volume of data that may possibly be
needed to be transmitted to the system. Other periodic tests will also be undertaken to ensure that
30/03/2012
Page | 13
all credit institutions are able to comply, on an on-going basis, with the transmission of the SCV
information requirements to the Scheme.
In addition to the testing exercises, the Scheme shall periodically request each credit institution to
provide a certification from an external auditor, that it has its electronic SCV system in place and the
credit institution is able to transmit electronically its SCV file containing live (real) data to the central
SCV system, according to the Scheme’s regulations, at any time on request by the Scheme.
4
Revision of Schedule LD7
In order to achieve a more reliable assessment of the funding requirements of the Scheme, the
Management Committee is currently reviewing the statutory return ‘Schedule LD7’, which every
credit institution is obliged to provide periodically to the MFSA. The return contains the aggregated
data on the amounts of eligible deposits held by every credit institution. The planned revision is
intended to bring the schedule in line with the existing DCS regulations and to facilitate the
calculation of the compensation funding required regarding the eligible deposits that are covered in
terms of the statutory compensation limit of €100,000 per single customer.
Amendments to the Explanatory Notes to Schedule LD7 are being proposed in order to enable credit
institutions to report the required information as correctly as possible. A copy of the revised
Schedule and Explanatory Notes is being included with this document marked as Annex 2. The
Scheme is seeking feedback in this regard by not later than 15 May 2012.
For ease of guidance, the main changes that are currently being proposed are as follows:



Deletion of the ‘up to €22,000’ category to reflect the new compensation limit.
Inclusion of two categories on ‘core information’ and ‘ancillary information’, which will
encompass the aggregated data in euro area currencies and non-euro area currencies
respectively and elimination of the USD and GBP sections.
Introduction of ‘covered deposits’ which will include formulas calculating the aggregate
compensation for the respective amount categories.
Currently, credit institutions are required to submit Schedule LD7 on an annual basis. However, the
Scheme intends to request such data to be provided on a more frequent basis, initially quarterly.
4.1
Annexes
The documents related to the revised Schedule LD7 are annexed below:
Annex
Annex 1
Description
File
Schedule LD7
Schedule LD7 - Data
on bank deposits.xls
Annex 2
30/03/2012
Depositor Compensation Scheme –
Explanatory Notes on Revised Schedule
LD7
DCS - Explanatory
Notes on Revised Schedule LD7.docx
Page | 14