Question1.xlsxAnova ResultsSUMMARY OUTPUTRegression Statistic.docx

Question/1.xlsx
Anova ResultsSUMMARY OUTPUTRegression
StatisticsMultiple R0.9773822473R
Square0.9552760573Adjusted R Square0.9463312687Standard
Error355813.814640011Observations25ANOVAdfSSMSFSignifi
cance
FRegression454083453731574.513520863432893.6106.7969413
4250Residual202532069413773.53126603470688.676Total2456
615523145348CoefficientsStandard Errort StatP-valueLower
95%Upper 95%Lower 95.0%Upper 95.0%Intercept-
5044576.809151977437899.36290137-
0.67822601020.50540053-
20559762.960199610470609.3418957-
20559762.960199610470609.3418957System
Downtime380542.72363115681284.76994958574.68159931890.
0001434149210985.665182202550099.782080111210985.66518
2202550099.782080111Employees215342.33921144746648.626
33399634.61626324580.000166914118035.010092074312649.6
68330819118035.010092074312649.668330819Data Quality-
826052.4853891157303552.87097784-
0.11310282820.9110766274-
16060996.76581814408891.7950397-
16060996.76581814408891.7950397Transactions2.7595300042.
94265839090.93776770440.359551285-
3.37874781968.8978078276-
3.37874781968.8978078276RESIDUAL
OUTPUTPROBABILITY OUTPUTObservationPredicted
LossesResidualsPercentileLosses1748240.904018606-
513828.904018606202285460.218251674-
194226.2182516746033079152.60926184-
345143.6092618391012241060225.90729582-
714564.907295818145455-
174493.243879396175038.243879396189186392451.464016624

-276539.464016624221200710461.4951115575-
9227.49511155752612348387256.776997224-
296023.7769972243014569348010.74127973-
292102.7412797334289110-
26610.030962751238612.030962751238987111-
676105.777812173699561.7778121734212002121736087.24002
3251546.75997679964617654136689589.87019547544114.1298
0453150234561414767.6134696555-
11876.6134696555545590815-
158242.371685589158364.371685589589123316-
217027.131383497217027.131383497629123417-
223887.322973547223887.3229735476611591218331705.67361
1212-130919.6736112127020078619-
125391.674965674126847.6749656747423441220-
157621.47743468158539.4774346878345661211580791.407773
82-346696.40777382382109503322-
10097.259844981127751.259844981186123409523-
26636.374711000236507.374711000290178763424781129.2390
33207313903.76096679394273400925-
358248.494686358359448.494686358987233704
System Downtime Line Fit Plot
Losses 3.0 1.0 10.0 3.0 0.0 1.0 0.0 1.0 1.0 0.0
0.0 8.0 16.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 5.0
0.0 0.0 3.0 0.0 234412.0 91234.0 2.734009E6
345661.0 545.0 115912.0 1234.0 91233.0
55908.0 12002.0 23456.0 1.787634E6 7.233704E6
2891.0 122.0 0.0 0.0 200786.0 1456.0 918.0
1.234095E6 17654.0 9871.0 1.095033E6 1200.0
Predicted Losses 3.0 1.0 10.0 3.0 0.0 1.0 0.0
1.0 1.0 0.0 0.0 8.0 16.0 0.0 0.0 0.0 0.0 1.0
0.0 0.0 5.0 0.0 0.0 3.0 0.0 748240.9040186057
285460.2182516743 3.07915260926184E6
1.06022590729582E6 -174493.2438793964
392451.464016624 10461.49511155754
387256.7769972243 348010.7412797297 -

26610.03096275125 -676105.7778121727
1.7360872400232E6 6.68958987019547E6
14767.61346965551 -158242.3716855893 -
217027.1313834973 -223887.3229735473
331705.6736112124 -125391.6749656742 -
157621.4774346797 1.58079140777382E6 -
10097.25984498113 -26636.37471100024
781129.239033207 -358248.4946863581
System Downtime
Losses
Employees Line Fit Plot
Losses 22.0 24.0 19.0 24.0 24.0 24.0 24.0 24.0 24.0 24.0
21.0 17.0 24.0 24.0 24.0 24.0 24.0 24.0 24.0 24.0 22.0
24.0 24.0 22.0 23.0 234412.0 91234.0 2.734009E6
345661.0 545.0 115912.0 1234.0 91233.0
55908.0 12002.0 23456.0 1.787634E6 7.233704E6
2891.0 122.0 0.0 0.0 200786.0 1456.0 918.0
1.234095E6 17654.0 9871.0 1.095033E6 1200.0
24.0 24.0 24.0 21.0 17.0 24.0 24.0 24.0 24.0 24.0 24.0
24.0 24.0 22.0 24.0 24.0 22.0 23.0 748240.9040186057
285460.2182516743 3.07915260926184E6
1.06022590729582E6 -174493.2438793964
392451.464016624 10461.49511155754
387256.7769972243 348010.7412797297 -
26610.03096275125 -676105.7778121727
1.7360872400232E6 6.68958987019547E6
14767.61346965551 -158242.3716855893 -
217027.1313834973 -223887.3229735473
331705.6736112124 -125391.6749656742 -
157621.4774346797 1.58079140777382E6 -
10097.25984498113 -26636.37471100024
781129.239033207 -358248.4946863581
Employees
Losses

Data Quality Line Fit Plot
Losses 0.94 0.96 0.88 0.95 0.98 0.97 0.98 0.98 0.98 0.98
0.98 0.89 0.81 0.97 0.98 0.99 0.99 0.95 0.97 0.98 0.95
0.96 0.97 0.96 0.99 234412.0 91234.0 2.734009E6
345661.0 545.0 115912.0 1234.0 91233.0
55908.0 12002.0 23456.0 1.787634E6 7.233704E6
2891.0 122.0 0.0 0.0 200786.0 1456.0 918.0
1.234095E6 17654.0 9871.0 1.095033E6 1200.0
0.98 0.98 0.98 0.98 0.89 0.81 0.97 0.98 0.99 0.99 0.95
0.97 0.98 0.95 0.96 0.97 0.96 0.99 748240.9040186057
285460.2182516743 3.07915260926184E6
1.06022590729582E6 -174493.2438793964
392451.464016624 10461.49511155754
387256.7769972243 348010.7412797297 -
26610.03096275125 -676105.7778121727
1.7360872400232E6 6.68958987019547E6
14767.61346965551 -158242.3716855893 -
217027.1313834973 -223887.3229735473
331705.6736112124 -125391.6749656742 -
157621.4774346797 1.58079140777382E6 -
10097.25984498113 -26636.37471100024
781129.239033207 -358248.4946863581
Data Quality
Losses
Transactions Line Fit Plot
Losses 250096.0 208111.0 345611.0 210075.0 185321.0
249876.0 252345.0 250987.0 236765.0 238911.0
237654.0 293778.0 415422.0 250912.0 191210.0
172901.0 170415.0 221876.0 200121.0 191435.0
278987.0 238908.0 235908.0 268001.0 199761.0
234412.0 91234.0 2.734009E6 345661.0 545.0
115912.0 1234.0 91233.0 55908.0 12002.0
23456.0 1.787634E6 7.233704E6 2891.0 122.0

0.0 0.0 200786.0 1456.0 918.0 1.234095E6
17654.0 9871.0 1.095033E6 1200.0 Predicted
Losses 250096.0 208111.0 345611.0 210075.0 185321.0
249876.0 252345.0 250987.0 236765.0 238911.0
237654.0 293778.0 415422.0 250912.0 191210.0
172901.0 170415.0 221876.0 200121.0 191435.0
278987.0 238908.0 235908.0 268001.0 199761.0
748240.9040186057 285460.2182516743
3.07915260926184E6 1.06022590729582E6 -
174493.2438793964 392451.464016624 10461.49511155754
387256.7769972243 348010.7412797297 -
26610.03096275125 -676105.7778121727
1.7360872400232E6 6.68958987019547E6
14767.61346965551 -158242.3716855893 -
217027.1313834973 -223887.3229735473
331705.6736112124 -125391.6749656742 -
157621.4774346797 1.58079140777382E6 -
10097.25984498113 -26636.37471100024
781129.239033207 -358248.4946863581
Transactions
Losses
Normal Probability Plot
2.0 6.0 10.0 14.0 18.0 22.0 26.0 30.0 34.0 38.0 42.0 46.0
50.0 54.0 58.0 62.0 66.0 70.0 74.0 78.0 82.0 86.0 90.0
94.0 98.0 0.0 0.0 122.0 545.0 918.0 1200.0
1234.0 1456.0 2891.0 9871.0 12002.0
17654.0 23456.0 55908.0 91233.0 91234.0
115912.0 200786.0 234412.0 345661.0 1.095033E6
1.234095E6 1.787634E6 2.734009E6 7.233704E6
Sample Percentile
Losses
Sheet1DateLossesNumber of LossesSystem
DowntimeEmployeesData QualityTransactions1-
Jul$234,412.001000432294%2500962-

Jul$91,234.00728412496%2081113-
Jul$2,734,009.0017972101988%3456114-
Jul$345,661.00861332495%2100755-
Jul$545.00574502498%1853218-
Jul$115,912.00974512497%2498769-
Jul$1,234.00807502498%25234510-
Jul$91,233.00928712498%25098711-
Jul$55,908.00887912498%23676512-
Jul$12,002.00907902498%23891115-
Jul$23,456.00907802198%23765416-
Jul$1,787,634.001351481789%29377817-
Jul$7,233,704.0024510162481%41542218-
Jul$2,891.00805402497%25091221-
Jul$122.00606102498%19121022-
Jul$0.00536002499%17290123-Jul$0.00528302499%17041524-
Jul$200,786.00838712495%22187625-
Jul$1,456.00660402497%20012126-
Jul$918.00593402498%19143529-
Jul$1,234,095.001143852295%27898730-
Jul$17,654.00728702496%23890831-
Jul$9,871.00754902497%2359081-
Aug$1,095,033.001098832296%2680012-
Aug$1,200.00120002399%199761
Assignment 2:
a.) Using Excel (or some other data analysis software), come
up with a statistical model to predict Losses as a function of
System Downtime, Employees, Data Quality and the Number of
Transactions.
b.) Which composite factors would you think of using?
c.) What type of nonlinearity would you build in your function?
d.) Give an estimate for the probability that you will lose
$1200 on any given day?
e.) In a year you expect the average number of daily trades to
double. However, you do not want the expected losses on any
give day to go up. How many new employees do you think you
should you hire by next year?

Question/2.pdf
8 March 2007
TARGET2-SECURITIES
THE BLUEPRINT
Table of contents
Introduction 2
1. Project Objectives 2
2. Perimeter of TARGET2-Securities 8
3. Functional Architecture 12
4. TARGET2-Securities Project Time frame 19
Address: Kaiserstrasse 29, 60311 Frankfurt am Main, Germany
Postal address: Postfach 16 03 19, 60066 Frankfurt am Main,
Germany
Telephone: +49 69 1344 0
Fax: +49 69 1344 6000
Website: http://www.ecb.int
All rights reserved.
Reproduction for educational and non-commercial purpose is
permitted provided that the source is acknowledged.
© European Central Bank, 2007

of 20
Introduction
At its meeting on 6 July 2006 the Governing Council of the
European Central Bank (ECB) decided to
explore, in cooperation with central securities depositories
(CSDs) and other market participants, the
possibility of setting up a new service for securities settlement
in the euro area, called TARGET2-
Securities (T2S). Since then, the Eurosystem has been actively
soliciting the views of CSDs and market
participants. It is also carrying out an internal Operational
Feasibility Study on the project. A high-level
presentation on the methodology, the principles and the
preliminary findings of this study has already
been shared with the market via industry-wide meetings held in
the ECB, including representatives from
the European public authorities.
This paper presents a first blueprint of the T2S design that can
be used for the formal market consultation,
following the Governing Council’s decision in March 2007 to
initiate the project.
It should be clarified at the outset that only the high-level
principles of the project are presented here. For
a thorough understanding of the legal, operational, technical
and economic aspects of the project,
reference should be made to the T2S Feasibility Study
document(s) which will be published in parallel.
Section 1 describes the background to the proposal and the

benefits that T2S would bring. Section 2
describes the perimeter of T2S and the scope of services it
would provide. Section 3 presents how T2S
would work. Finally, Section 4 presents the project’s time
frame.
1. Project Objectives
Contributing to integration in EU securities settlement
Over the past decade, two trends have been apparent in the
development of the European securities
settlement infrastructure:
• There has been considerable progress in integrating settlement
systems at the national level, with
the result that in most EU countries, there is now just one
settlement platform for all types of
securities.
• At the EU level, some cross-border company mergers have
resulted in bringing CSDs in different
countries under common ownership (e.g. Clearstream and
Euroclear Group). Although these
mergers have the objective of integrating settlement platforms
progress has to date been slow.
Consequently, while efficiency at the national level has
improved, there is widespread consensus that
more needs to be done at a cross-border level. It is particularly
striking that, almost eight years after the
introduction of the euro, the euro area still lacks an efficient,
integrated securities infrastructure that
would support the operation of a single financial market. This
illustrates the difficulty faced by

of 20
independent and competing organisations in coordinating
solutions across multiple countries and
involving many different participants.
The result of this fragmented infrastructure is that the cost of
clearing and settlement is considerably
higher in the EU compared to the US. Various studies (by
CEPS, Giovannini, LSE/OXERA) have
concluded that the price per cross-border transaction in Europe
is between 2.5 and 5 times higher than in
the US, with the cost per cross-border transaction between 1.5
and 4 times higher.
Increasing efficiency of settlement of securities transactions in
euro
The implementation of TARGET2 presents an opportunity for
the European securities industry to take a
major step forward. TARGET2 will, for the first time, provide a
single technical infrastructure that
enables market participants to pool their euro liquidity across
different countries. This will make it
possible to bring together the payments associated with
securities settlement across multiple CSDs.
However, the benefits to banks of pooling liquidity are limited
if TARGET2 has to maintain separate
interfaces to multiple securities settlement engines in the
various CSDs.
To maximise the settlement efficiency of securities transactions,
two conditions need to be satisfied:

• a single cash account (that will allow for liquidity pooling)
must be operated; and
• it should be possible to deliver in real time, simultaneously
settling cash and securities on a single
platform via common procedures.
The concept of T2S has emerged out of these requirements.
The most innovative element in this concept is that the
securities accounts of multiple CSDs will be
maintained on a single technical platform together with central
bank cash accounts, while all other
functions – notably, the relationship with intermediaries,
investors and issuers and the management of
corporate actions – remain with the CSDs, as is the case today.
However, while this split is a radical one,
it is also logical. Settlement is the most standardised process
among CSDs activities. The relationships
with intermediaries, investors and issuers, on the other hand,
are much more heterogeneous, with
numerous local variations. It is therefore possible to integrate
the settlement process relatively rapidly,
while allowing the eventual harmonisation of local market
practices to take place at a later stage.
The Eurosystem is in a unique position in Europe, given that the
euro area level is a truly operative
decision-making framework that is just as efficient as any
national level scheme. In addition, in seeking to
overcome sectoral or national barriers that stand in the way of a
more efficient market structure, is
reassuming a traditional role for central banks in many
countries*. This is entirely consistent with the
mandates of the ECB and the national central banks (NCBs) of

the Eurosystem. The provision of T2S is
possibly the only solution that will allow existing national
CSDs to continue to operate in a decentralised
framework. In doing so, it provides the same service and
functionality to all financial market users as a
minimum in the euro area (and potentially in the whole
EU/European Economic Area as well).
By maintaining CSDs’ current role in relation to intermediaries,
investors and issuers, the project ensures
that there will continue to be choice and competition in the
provision of services; if anything, T2S will
Page 4 of 20
provide greater possibilities for choice and competition.
Participants may choose among multiple CSDs to
access securities through a single entry point based on a
common Settlement Engine. This would be also
true for other infrastructures (e.g. central counterparties (CCPs)
and trading platforms) in respect of the
Code of Conduct recently signed under the auspices of the
European Commission. Issuers can also
improve the liquidity and issuance cost of their securities by
making them directly available to a wider
range of participants via a single, potentially local CSD.
The ability of any bank (including international CSDs (ICSDs))
to offer securities settlement in
commercial bank money will not be affected. The parallel
provision of securities settlement services in
central bank money and commercial bank money represents a
stimulus for central banks to provide
efficient services. This is as true for T2S as it is for TARGET2.

T2S shares the same objectives as other public initiatives in this
field, most notably the European
Commission’s Code of Conduct. The common objective is to
improve efficiency and reduce costs
through ensuring greater competition. The Code of Conduct
pursues this objective through CSDs’ self-
commitment to provide price transparency, to facilitate access
and interoperability, to unbundle services
and to separate accounts. T2S, on the other hand, approaches
this issue from an operational angle. The
two initiatives naturally reinforce one another, and for this
reason the European Commission has stated its
support for T2S right from the start. The European Parliament
has also concluded that “until such time as
an [integrated settlement] infrastructure may have been
introduced, an ECB governance must be put in
place”.1
The potential benefits for TARGET2-Securities users
Although the initial impulse for the T2S concept was the
opportunity created by the TARGET2 payment
system, the potential benefits go much further and affect a wide
range of users.
• The settlement of cross-border securities transactions can be
as efficient as domestic settlement,
eliminating the cost disadvantages that have hitherto impeded
the development of a single financial
market especially when compared with the US one (see Chart
1). This will be achieved by bringing
together the securities accounts of multiple CSDs (as well as
dedicated sub-cash accounts of NCBs)
on a single platform. The bookings for the transfer of securities

between participants of different
CSDs can all be made simultaneously, together with the cash
movements. This eliminates the
current highly complex and costly processes of interactions
between various platforms, which are
costly often not synchronised, entailing delays and could pose a
risk in terms of failing to achieve
1 European Parliament Resolution on the ECB’s Annual Report
2005:
“15. Welcomes the publication of the ECB's first report on
financial integration in the euro zone, since this is vital both for
putting across information concerning monetary policy and for
financial stability; notes that, according to the ECB, financial
integration calls for the integration of market infrastructures, in
particular settlement-delivery systems; notes the intention of
the
ECB to create a settlement infrastructure; notes that, until such
time as an infrastructure may have been introduced, an ECB
governance must be put in place”.
Page 5 of 20
settlement finality. These shortcomings are responsible for the
current unattractiveness of CSD
links. T2S will also automate the realignment process between
CSDs on a real-time basis without
needing to use additional, often costly, procedures.
• T2S will propose the same pricing for domestic and cross-
border settlements. All markets may
operate in real time under the same settlement engine, thus

allowing a faster reuse of securities and
central bank money
• Competition would be fostered by pooling all securities that
settle in central bank money in a single
settlement engine accessible via multiple CSDs. At the same
time, a decentralised structure is
maintained whereby each CSD is responsible for maintaining its
relationships with intermediaries,
investors and issuers, as well as asset-servicing.
• As the European securities settlement industry could still
achieve significant economies of scale, a
single settlement engine with the volume scale of T2S could
potentially lead to a substantial
decrease in settlement costs on average. This is particularly the
case for cross-CSD settlement. The
economic feasibility of the project shows that this is possible
despite the conservative working
assumptions currently used in the calculations.
• A reduction in the number of settlement engines will decrease
the CSDs’ infrastructure costs on the
one hand, and the number of interfaces needed by market
participants on the other. This is an
additional factor which is reasonably expected to benefit
infrastructures and users’ back office
development and running costs.
• T2S will encourage CSDs to offer their participants the
opportunity, if they choose, to centralise
their securities holdings in one place. This will depend on the
readiness of CSDs to hold securities
issued in other CSDs, although it should be noted that CSDs
will have an incentive to do so in
order to improve their competitive position vis-à-vis their

participants.
• Issuers may potentially reach a much wider set of participants
while continuing to use the same
CSD they are using today (and with the same procedures as
today under their local legal and tax
regimes). This effectively makes the euro financial market a
domestic market that does not entail
any additional costs. In addition, this will increase the
attractiveness of securities, which are
currently marginalised because of their national nature, by
making them available throughout the
euro market.
• Investors will obtain cheaper access to non-local securities,
which today requires prohibitive cross-
border settlement procedures, and will therefore benefit from
greater opportunities to diversify their
portfolio. In addition, institutional investors will probably also
benefit from lower fees to access the
domestic market, while the share of infrastructure costs
represents a significant part of the fees they
pay to their custodians.
• The Eurosystem and its counterparties will also benefit from
this efficiency in terms of using
collateral in its credit operations. With cross-border deliveries
becoming as efficient as domestic
ones, a new generation of Eurosystem collateral handling
procedures could be implemented.
Page 6 of 20
Improved Eurosystem collateral management could rationalise

and harmonise Eurosystem
practices in this field, in particular replacing the current
correspondent central banking model
(CCBM) procedures and multiple domestic procedures when
securities are used for collateral
purposes.
• Finally, by de facto introducing standardised euro area-wide
settlement, T2S will significantly
contribute to the momentum for further harmonisation in the
financial markets. The successful
introduction of T2S will further facilitate, even during its
development phase, the current industry
cooperation towards elimination of the remaining barriers
identified by the Giovannini Report.
Although TARGET2 is a euro payment system, the problems of
fragmentation and inefficiency are wider
than in the euro area. T2S will therefore be designed in such a
way (an open architecture) that it could
later on provide settlement against other EU currencies, where
there is market demand, and provided that
the relevant NCB is prepared to enable settlement in its
currency.
As far as the Eurosystem is concerned, this is a project unlike
any undertaken before, as it reaches out
beyond banks and payments systems into securities markets.
The Governing Council has indicated that
the Eurosystem is willing to finance and operate T2S, but it also
recognises that it will need the
cooperation and commitment of CSDs and securities market
participants in order to deliver the service
successfully. It is therefore looking at mechanisms to enable its
project partners to participate fully in its
design and development, in a way that appropriately links the

degree of commitment with the level of
involvement in decision-making.
Chart 1: Domestic and Cross border settlement costs in EU
0
5
10
15
20
25
30
35
United
States
EU
dom estic
EU cross-
border
Min Max Avg.
- E U d o m e stic co sts ran ge fro m
0 .3 5 to 3 .4 3 �€ ;
- �… an d are h igh e r th an U S

(+ 0 .1 0 to 2 .9 0 �€ );
- C ro ss-b o rd e r co sts h igh e r th an
d o m e stic o n e s (1 9 .5 to 3 5 .0 �€ ).
S o u rce : O x e ra, L SE , C E P S
Conclusion
By providing a single platform for the settlement of the cash
and securities legs of all the transactions
today effected in the various CSDs, T2S will significantly
contribute to increasing the efficiency of
Page 7 of 20
settlement and the integration of the EU capital markets
infrastructure. A single platform will enable the
settlement of all domestic and cross-border securities
transactions.
It will also allow the potential benefits stemming from
TARGET2 (cash) to be fully exploited, since this
will complement the possibility of having a single pool of
liquidity with that of a having a single entry
point for the settlement of securities, providing cash and
securities settlement in the same platform.

of 20
2. Perimeter of TARGET2-Securities
Functional specialisation: custody and settlement
Two dimensions can be distinguished with regard to the
functional organisation of the securities market
infrastructure:
• the management of flows, including the trading, clearing and
settlement functions as a result of the
movement of securities (against or not cash);
• the management of stocks, involving the custody or asset-
servicing function as a result of the
relationship between issuers and investors (see Chart 1).
Chart 2: Two dimensions of CSD services today
INVESTOR
CSD
INVESTOR
CSD
SECURITIES
SETTLEMENT
SECURITIES
SETTLEMENT
TRADINGTRADING

ISSUER
CSD
ISSUER
CSD
ISSUERISSUER INVESTORINVESTOR
CCP
CLEARING
CCP
CLEARING
CeBM
SETTLEMENT
CeBM
SETTLEMENT
BANK &
BROKER
BANK &
BROKER
LISTINGLISTING
Management of Flows
Management of Stocks
Asset Services
Corporate actions
Investor information

A CSD today typically undertakes tasks related to both the
settlement and custody functions. The
proposed model represents an opportunity for CSDs to perform
their securities settlement function in
central bank money via T2S. The custody function (investor and
issuer CSDs) will continue to be
performed by the CSDs as is currently the case, including the
responsibility for the notary function of
issuance (see Chart 2). Other services such as settlement against
commercial bank money and value-
added business are not part of the scope of T2S.
Chart 3: Perimeter of T2S
Page 9 of 20
INVESTOR
CSD
INVESTOR
CSD
SECURITIES
SETTLEMENT
SECURITIES
SETTLEMENT
TRADINGTRADING
ISSUER
CSD

ISSUER
CSDISSUERISSUER INVESTOR
INVESTOR
CCP
CLEARING
CCP
CLEARING
CeBM
SETTLEMENT
CeBM
SETTLEMENT
BANK &
BROKER
BANK &
BROKER
LISTINGLISTING
EXCHANGE
CSD
TARGET2-SECURITIES
CLEARING
HOUSE
A CSD has extensive relations to its home market stakeholders:

the issuers, the investors directly or via
the brokers and the custodian banks, the CCPs, the tax
authorities, the supervisory authorities and the
legislators. These relations require a range of asset-servicing
activities that are typically adapted to local
market conditions, for which the local CSD has long-standing
expertise. The settlement function, on the
other hand, only relates to the participants in the settlement
process and to the cash clearing entity, the
central bank and its participating banks.
Participants in the settlement process are often active in several
markets. As a consequence, they have to
build and maintain multiple connections to several systems, or
have to route their transactions through
more expensive custodian networks. The introduction of
TARGET2 for cash settlement within the euro
area has facilitated these connections for the cash side of
settlement transactions. For the securities leg,
however, these complex and costly connections remain.
The proposed management of the settlement and custody
functions in separate platforms (T2S and asset-
servicing platforms of CSDs) is motivated by the fact that
settlement services are already highly
standardised and easier to harmonise than the custody business.
The latter is typically more complex and
may take more time to harmonise owing to the national
differences that exist with regard to custody,
corporate actions and beneficial ownership (e.g. owing to
different legal and tax regimes). The feasibility
of this separation will be presented in detail in the operational
and business analysis chapter of the T2S
Feasibility Study.
To avoid parallel settlement and to allow CSDs to

decommission their settlement platforms and systems,
T2S needs to offer the same level of settlement services for the
assets that CSDs settle in euro today.
Page 10 of 20
T2S scope of services
Within the context of the functionality described above, T2S
will cover the following aspects in the
services provided:
Scope of assets
T2S will provide settlement services for all securities (with
International Security Identification Number
(ISIN) codes) held through the participating CSDs’ accounts.
These include debt instruments, equities,
investment funds and warrants.2 Securities that are denominated
in foreign currency but settled in euro
will also be covered by T2S, provided they are held through a
T2S-connected CSD. This implies that
securities issued outside T2S could be settled through T2S,
provided that a T2S-connected CSD has a link
with the external issuer CSD.
Settlement type
T2S will offer an “optimised delivery versus payment (DvP)”
settlement model. It will be based on real-
time gross settlement (RTGS) procedures combined with self-

collateralisation and continuous
optimisation (including technical netting and other algorithms),
as well as recycling mechanisms.3 Such
mechanisms will compensate for situations where participants
lack liquidity (e.g. self-collateralisation) or
for complex transactions (specific algorithms for back-to-back
transactions or chains of trades, for
example). This innovative optimised DvP settlement model will
maximise settlement efficiency in terms
of liquidity, speed and safety.
In addition, free of payment (FOP) settlement and other types of
securities settlement needed for CSDs to
function effectively will be offered as well.
Scope of services
T2S will manage the entire settlement process by offering the
following services:
• receiving settlement instructions4 and checking their technical
validity against a static reference
database (updated and controlled by the CSDs – the information
checked will be defined with the
CSDs);
• providing matching services, mainly for transactions
conducted between participants of different
markets;
• verifying the availability of and reserving securities and
central bank money;
• managing queues;

2 This list of assets may not be exhaustive.
3 The details of the self-collateralisation procedure, e.g. the
application of haircuts, assets and counterparties, are to be
performed
in accordance with the rules defined by the Eurosystem and the
relevant NCB providing the credit. Further analysis on the
exact rules and procedures will be described in the next phase
of the project.
4 T2S will accept unmatched or matched settlement instructions
from CSDs, CCPs, stock exchanges or other organised markets,
and possibly also market participants (users).
Page 11 of 20
• providing settlement optimisation mechanisms;
• offering self-collateralisation;
• executing debits and credits on securities accounts;
• performing automated real-time realignment of inter-CSD
accounts where applicable; and
• reporting to CSDs and other participants on the status of each
settlement instruction5 and the
account balance.
Operating hours
T2S will offer daylight and night-time settlement in order to
cover the range of services already provided
by some CSDs. The daylight operating hours of T2S will be in

line with the timetable of TARGET2.
Similarly, T2S will perform night-time settlement during the
same night-time period when TARGET2
supports the settlement of ancillary systems.
Currency
In principle, T2S will cover securities transactions settling in
euro central bank money. This service will
also be available to CSDs outside the euro area settling in euro
central bank money. The design of T2S
will also allow for the provision of securities settlement in other
EU currencies, provided that there is
market demand, and assuming that the relevant NCB is prepared
to enable settlement in its currency.
Non-compulsory participation
T2S is a project that seeks to offer safe, efficient and
competitive settlement services across all connected
markets. Market participants largely support the project.
However, the benefits for the market will only
materialise if all CSDs, or at least a critical mass of them, join
the project because of the greater
competition it will introduce, even if this may run counter to
their corporate interests in the short term.
At this stage, the Eurosystem believes that the pressure of the
market and the quality of the solution
proposed are sufficiently strong to convince all CSDs to follow
the European integration approach. In this
context, participation in T2S should not be made mandatory.
5 In case of direct user access (see footnote 1), T2S would also
provide settlement-related information directly to the user as

well
as to the CSD.
Page 12 of 20
3. Functional Architecture
A high-level overview of T2S
This high-level description, in combination with the more
detailed Operational Feasibility Study, presents
the T2S functionalities necessary to provide CSDs with efficient
securities settlement services. The
custody and value-added services which are processed and
initiated at the CSD level have an impact on
T2S operations insofar as they can result in changes in the
securities accounts balances maintained via
T2S (see Boxes 1 and 2).
As a consequence, the CSDs will instruct T2S to perform
related settlement activities. T2S will provide
via its interfaces specific instruction types for this purpose
which would be restricted to the CSDs.
Within the proposed T2S business model, three main building
blocks can be distinguished under the high-
level overview:
o the T2S Settlement Engine and Transactions Database
(including the Lifecycle
Management);
o the dedicated sub-cash accounts in TARGET2;

o the Securities Accounts Database(s) and interactions with
CSDs.
The first refers to the core functionality of the system, the
platform responsible for checking the
availability of cash and securities and eventually executing final
settlement in the securities accounts and
the Cash Accounts Database. The second is a database of the
dedicated cash sub cash accounts to be used
during the DvP processes and how this database interacts with
the RTGS accounts. The third is the set of
all securities accounts opened with the participating CSDs.
Chart 4: An overview of T2S
CSD ACSD A
CSD BCSD B
CSD CCSD C
T2S
SETTLEMENT
ENGINE

T2S
SETTLEMENT
ENGINE
SECURITIES
ACCOUNTS
TARGET2
CASH ACCOUNTS
CSD A SECURITIES
ACCOUNTS
NCB C ACCOUNTS
T2S
SETTLEMENT INSTRUCTIONS
ParticipantParticipant
NCB B ACCOUNTS
NCB A ACCOUNTS
CSD B SECURITIES
ACCOUNTS
CSD C SECURITIES
ACCOUNTS
Page 13 of 20

The dedicated cash sub-accounts (Chart 4) are part of the RTGS
accounts opened in TARGET2 with the
NCBs, technically dedicated to T2S. They function
independently; i.e. the T2S Settlement Engine can
only debit and credit these dedicated sub-accounts. The CSDs’
participants can choose to move liquidity
in and out of these sub-accounts at any time using the
TARGET2 functionality (ICM and payment
functionality) At the end of the day, all liquidity is pooled back
into the main TARGET2 RTGS account
in order to process end-of-day cash balances.
Chart 5: TARGET2 Dedicated Sub-account
Functional description
If we analyse T2S in more detail, two main functional blocks
can be distinguished: Lifecycle
Management and the core Settlement Engine (see Box 1). The
T2S Static Data constitutes a third rather
static functional block that supports the operations of the other
two, and includes the CSD-specific rules
for settlement. The current version of the Operational
Feasibility Study also covers in some detail the
level of functionality described below.
Lifecycle Management
The Lifecycle Management covers the lifecycle of an
instruction, the different processes it can take
within the system, and the related lifecycle status attached to
these processes (e.g. validated, matched,
unmatched, settled, etc.). Depending on the current lifecycle

status and on the underlying market rules, an
instruction will be processed within the following functional
modules:
• Validation – This checks that the instructions of incoming
messages are correct. The rules against
which instructions are validated are the ones maintained by the
CSDs in the T2S Static Data
databases.
• Matching – This matches instructions (if not already matched
at CSD level).
• Settlement eligibility – This module distinguishes between
eligible and non-eligible instructions. It
verifies whether an instruction is eligible for settlement
(depending on settlement date, deadlines,
market closing, etc.) and then either hands it over for
settlement, or returns instructions that are no
longer eligible (e.g. due to expired deadlines) by assigning them
a non-eligible status.
Dedicated cash
Sub-accounts
RTGS account
Managed via T2S functionality
Page 14 of 20
• Instructions maintenance – This updates the parameters of

instructions (e.g. prioritisation,
enrichment, etc.).
• Purging – This removes settled instructions from the system
at the end of the day.
Settlement Engine
The following modules apply exclusively to instructions that are
eligible for settlement and form the core
of the Settlement Engine:
• Sequencing – This creates queues of instructions that are
eligible for settlement in a way that
optimises settlement results while also taking into account
different levels of priority.
• Booking – This is the heart of the Settlement Engine, where
the final bookings of the movements
related to the instructions regarding the securities and cash
accounts are performed. This is the only
place where account balances can be changed.
• Optimisation – This identifies linked sets of (failed)
instructions which could be settled if certain
technical netting procedures are performed. Optimisation will
propose these instructions as linked
sets for processing in the Sequencing Module.
• Recycling – This determines when instructions that failed in
their first attempt will be put forward
again for settlement. Recycling will propose these instructions
for processing in the Sequencing
Module.

The T2S Static Data functional block can only be accessed by
CSDs via the authorisations interface (see
next section). The block purely includes stocks of data relevant
for the processing of settlement in T2S.
These data include updated information on valid participants’
accounts, active ISINs, and access and
rights for CSDs’ participants.
Interfaces
Three kinds of data groups to be stored and processed in T2S
can be differentiated: settlement
instructions, balances stored on the securities and cash
accounts, and authorisations (i.e. the information
on which kind of securities are admitted for which kind of
settlement, as well as the account set-up
information plus the connectivity set-up of each customer).
Box 1 provides an overview of how the relevant data (on
instructions, balances/holdings and
authorisations) relate to each other. Four different interfaces are
required for the interaction between T2S,
CSDs and the users6:
6 Users are defined as CSDs’ participants.
Page 15 of 20
An instructions interface, which can be accessed by CSDs as
well as some users. This will provide a bi-
directional functionality in order to instruct settlement, to

receive settlement status and feedback, to
query the status of instructions, and to maintain and manage
instructions.
An authorisation interface, which can only be accessed by
CSDs. This provides the latter with the
functionality to authorise securities and participants relevant for
settlement.
An accounts balance interface, which can be uni-directionally
accessed by CSDs as well as some users to
query balance information and to monitor accounts.
A payment system Interface, which allows CSDs’ participants to
transfer liquidity between dedicated sub-
cash accounts located in T2S and the main RTGS account
located in TARGET2 (cash), if and when
required.
These interfaces are primarily for the use of the CSDs, although
CSDs can give their participants limited
access to the instructions and accounts balance interfaces.
Box 1: A High-level Functional Description of T2S
TARGET2-Securities
Lifecycle Management and
Matching
T2S Static data
C
us

to
m
er
s
/ E
xc
ha
ng
es
/
C
C
P
s
C
S
D
P
ar
tic
ip
an
ts
Account

Balances
Interface
•
Query•
Monitor
Instructions
Interface
• Instruct
• Query Status
• Maintain
Instruction
CSD A
CSD A
ISINS
SECURITIES
ISINs and data
PARTICIPANTS
Customers data
CSD B
CSD A
CSD B
CSD A
CSD A
RULES
CSD A

CSD B
CSD A
CSD B
CSD A
CSD A
CSD A
CSD A
RULES
CSD A
CSD B
CSD A
CSD A
SECURITIES
CSD A
CSD B
CSD A
CSD B
CSD A
CSD A
CSD A
CSD A
SECURITIES
Information
on status
Instruction ready
for settlement

CSD A
ACCOUNTS
SECURITIES
ACCOUNTS
CSD B
ACCOUNTS
CSD…
CSD A
ACCOUNTS
SECURITIES
ACCOUNTS
CSD B
ACCOUNTS
CSD…
CASH
ACCOUNTS
NCB C
ACCOUNTS
NCB…
TARGET2
CASH
ACCOUNTS

NCB…
NCB A
ACCOUNTS
NCB B
ACCOUNTS
TARGET2
CASH
ACCOUNTS
NCB…
NCB A
ACCOUNTS
NCB B
ACCOUNTS
Optimization
procedures
S
et
tle
m
en
t
E

ng
in
e
Optimization
procedures
S
et
tle
m
en
t
E
ng
in
e
N
C
B
sCSD
AUTHORIZA-
TION
INTERFACE
CSD A
NCB B
CSD A

NCB B
CSD A
NCB A
SETTLEMENT
AGENTS
•Set up / change /
maintain
• Participants
• Securities
• Rules CSD ACSD B
CSD A
CSD A
CSD A
CSD B
CSD A
CSD B
CSD A
CSD A
CSD A
CSD A
CSD
PARTICIPANTS
A typical settlement transaction (e.g. a “plain vanilla” DvP
over-the-counter trade) could follow this lifecycle:
instructions will enter the T2S system via the instructions
interface. If not already validated and matched at the CSD

level, these functions will be performed at the T2S level. The
T2S Static Data will provide reference information for
the validation of instructions. The Lifecycle Management and
Matching will provide the functionalities required for
the lifecycle of a settlement transaction (validation, matching,
settlement prioritisation, etc.). “Ready to settle”
transactions will be forwarded to the Settlement Engine where
the availability of securities and cash balances will
be checked. If enough balances are available, final and
irrevocable transfers of cash and securities will be executed
in an RTGS mode. If there are not enough balances (either
owing to a lack of cash or securities), pending
Page 16 of 20
transactions will be re-entered for settlement via pre-specified
optimisation and self-collateralisation procedures.
Instructing parties (CSDs and users) will be notified
accordingly via the instructions interface.
The account balances interface will report on the securities
holdings. The authorisations interface will provide
CSDs with the functionality of updating the static data
necessary for the settlement process (e.g. authorised CSD
participants, valid ISINs, market-specific rules for Lifecycle

Management, etc.).
TARGET2 will allow users to add central bank liquidity to and
withdraw it from the dedicated cash sub accounts.
The interaction of functional modules in T2S
The picture below shows how the different functional blocks
and modules interact with each other. A few
explanations need to be added:
• Real-time interfaces to the Static Data databases are required,
to accommodate any change in
securities reference data, in customer authorisations, or in
schedules and deadlines. Changes in static
data eventually have to be applied to all modules, but during
settlement processing, they mainly affect
the Lifecycle Management.
• In the flow process example described below, instructions are
split between eligible and non-eligible
ones.
• Instructions maintenance can also be performed for eligible
instructions*, but with a subset of
potential activities.
Box 2: An Overview of the Interaction of the Main Functional
Blocks in T2S
Page 17 of 20

Settlement Engine
Matching & Lifecycle
Management Engine
Lifecycle
Management
Instructions
Validation
Matching
Instruction
Maintenance
Purge &
Archive
Regulatory
Reporting
Static Data
Manager
Optimization Sequencing Recycling
Settlement
Eligibility
Instructions
not yet/ no
longer
eligible

Eligible
instructions
Booking
Feed back
Propose for settlement
Securities
accounts
Cash
accounts
1
2
3
4
5
6
7
8
9 10
11

A typical data flow in a straight “plain vanilla” over-the-counter
trade would be as follows: settlement
instructions “captured” via the instructions interface are
processed in the Validation Module (1)
according to the rules and restrictions stored in the T2S Static
Data Module via the Static Data Manager
(3). Once validated, instructions are matched in the Matching
Module (2). Whatever the outcome of the
matching process, instructions may be affected by the
Instructions Maintenance Module (4). Successfully
matched transactions are moved to the Settlement Eligibility
Module (5), where they are checked for their
settlement eligibility (e.g. checking the settlement date, blocked
instructions, etc.). Once they have been
assessed as eligible for settlement, instructions are prioritised in
the Sequencing Module (6) and
processed, in RTGS mode, for the final settlement (cash and
securities) in the Booking Module (7).
Assuming successful settlement in both securities and cash
accounts (optimised DvP model), transactions
reach the final stage of their lifecycle management and are
eventually purged and archived via the
relevant module (8). In the case of failed settlement,
transactions are moved to the Optimisation Module
in order to be optimised according to the T2S optimisation rules
(9). In case of successful optimisation,
the instructions are then immediately put into the settlement
queue via the Sequencing Modules. In case
optimisation was not successful, instructions are stored and
eventually recycled (10) and re-entered in the
Sequencing and Booking Modules, according to the T2S
recycling rules.

of 20
For reasons of simplicity, instruction reporting is not covered
here. In some transaction lifecycle stages,
immediate reporting to the instructing entities is required. This
is not to be confused with the regulatory
reporting facility for the CSDs (11).
Annex 1 of the Operational Feasibility Study provides more
detail on the functionalities and interactions
of the T2S functional blocks and modules.
Connectivity
CSDs will be directly connected to and will communicate with
T2S. Users (CSDs’ participants)7 will
normally connect to T2S via their own CSD, i.e. the CSD with
which they legally hold their accounts.
This is particularly relevant for smaller local participants,
especially within the first period of live
operation of T2S. Users can also continue to send instructions
in their proprietary formats. Their CSDs
will be responsible for converting these instructions into the
T2S harmonised standards (message formats,
codification of securities accounts, etc.).
However, some users may see the need to have direct technical
connectivity to T2S. In particular, some
major European custodians have already expressed their
willingness to explore right from the start of T2S
the possibility of ensuring direct connectivity to the centralised
infrastructure.8 Whatever the strategy
chosen by the market participants, the nature of their
connectivity should be agreed and established in
cooperation with their local CSD, i.e. the system with which

they legally hold their securities accounts.
Within this scenario, directly connected entities must be able to
instruct T2S according to the harmonised
messages and standards, since T2S will not offer converting and
mapping services.
All stakeholders along the settlement chain are expected to
cooperate on the basis of their mutual interest
and should not abuse their controlling positions. Any
“restrictive” policies that are against the interests of
the local settlement community will be counterbalanced by the
open architecture of the T2S system and
the expected improved competition in the depository market
(i.e. there will be more opportunities for
CSD participants to open securities accounts in any CSD
connected to T2S). The Code of Conduct has a
similar incentivation effect.
In principle, the T2S architecture should be sufficiently open to
accommodate both direct and indirect
connectivity options for market participants. As Box 1 shows,
whatever the connectivity model,
settlement instructions will only be managed and processed in
the T2S environment by a single entry
point: the T2S Settlement Engine.
7 CCPs, despite being part of the post-trading infrastructure, are
also considered CSD participants for the purpose of securities
settlement. However, the functionality available in the T2S
Settlement Engine will take into account the specific settlement
requirements stemming from central counterparty netting.
8 Here connectivity is meant only in technical terms. Legally,
market participants will only remain direct participants in their

CSDs.
Page 19 of 20
T2S will use a standard communication protocol based on the
ISO 15022/20022 standard for messages.
(For more information on the standards to be adopted in T2S,
see the Operational Feasibility Study.)
Cross-CSD transactions
It is generally accepted that an issuer CSD cannot refuse to
open an inter-CSD account for an investor
CSD (unilateral outbound account). This point has recently been
reinforced by the Code of Conduct.
In order to achieve full coverage for all actors within T2S, all
investor CSDs should be ready to open
inter-CSD accounts in all issuer CSDs.
However, it is also recognised that some links may lack an
underlying business case, or that an investor
CSD may not be adequately prepared to provide its participants
with custody services for all kinds of
securities, at least not right from the start of T2S production.
Therefore, each investor CSD will have to
specify which securities of a remote issuer CSD it is ready to
accept in its participants’ accounts. This
implies accepting handling these securities and the related
corporate actions as proposed in the standard
agreement of the European Central Securities Depositories
Association (ECSDA).

Participants may hold their securities in the CSD in which they
have been issued (“issuer CSD”) or with
any other CSD (“investor CSD”) that is not the issuer CSD,
provided that the investor CSD accepts these
securities. From a technical point of view, transfer of securities
across national borders will take place as
a change of holdings in a single database (Annex 2 of the
Operational Feasibility Study provides concrete
examples of how these transactions will be handled in T2S).
The transmission of a security from one participant in an
investor CSD to another participant in another
investor CSD would necessarily imply a realignment at the level
of the issuer CSD. In other words, the
issuer CSD should always know in which investor CSD the
security is held. Realignment between
securities accounts at the issuer CSD level will take place in
real time. This functionality will exceed the
minimum requirements set by the ECSDA standards (at least
regarding end-of-day realignment).
T2S should also enable participants to settle securities issued in
CSDs not directly connected to T2S
(external CSDs). (This issue is also covered in some detail in
the Operational Feasibility Study.)
4. TARGET2-Securities Project Timeframe
Due to its complexity and wide range of specifications, it is
foreseen that the T2S project will take
between four to six years to materialise.
A tentative project timetable is presented, based on a six-year
project.. A detailed and thoroughly

documented time frame will be developed following the
initiation decision alongside the preparation of
the User Requirements.
Page 20 of 20
- Phase 1: User Requirements and Design (approximately 40%
of the project workload;
estimated to take place between Q2 2007 – Q3 2009). This
phase will start with the Governing
Council’s final decision to initiate the project. It includes the
definition of the User
Requirements and, as a next step, the first draft of the Detailed
Functional Specifications (DFS)
of the T2S functionalities. An extended engagement with CSDs
and market participants is
foreseen for this phase in order to ensure that services offered
by T2S will enable, on the one
hand, the design of an efficient pan-European infrastructure,
and on the other the smooth
functioning of the CSDs’ operations. Synergies with TARGET2
could help reduce the time
needed for this phase. The definition of the non-functional
requirements is also to be developed
here.
- Phase 2: Development and Implementation (approximately
30% of the project workload;
estimated to take place between Q4 2009 – Q3 2011). In this
phase, the development and
finalisation of the DFS would occur. This phase includes the
application development of T2S
and implementation steps, and the various units and modules
testing at the project team level.

Fine-tuning to the DFS could also take place at this stage.
- Phase 3: Testing and Deployment (approximately 30% of
project workload; estimated to take
place between Q4 2010 – Q1 2013). This final phase includes
testing on module integration,
interfaces, performance and back-up facilities. The supporting
documentation (manuals,
procedures, etc.) will be finalised during this phase, and user
training will be conducted. The
final user acceptance tests should be performed at the start of
this phase.
Migration options
The various options and details relating to the gradual migration
to the T2S environment, namely the
move of the CSDs’ settlement function to the central system,
should be discussed with the market. This
migration could be based on the different jurisdictions (as in
TARGET2) or on different assets (debt
instrument vs. equities markets). This may be particularly
relevant for new Eurosystem members that join
the Eurosystem by the time that T2S goes into production.
Chart 6: Provisional T2S Project Phases and Timeframe
Phase 1 Phase 2 Phase 3
• Public Consultation
• User Requirements
• Detailed Functional Specifications

(DFS)
• Architectural Specifications
• Decision on Migration Policy
March 2007
• T2S Development &
Implementation
• Units and Modules
Testing
• Fine Tuning (DFS)
• UAT Testing
• Integration,
performance,
interface & back up
testing
• Migration Options
• Final Deployment
T2S
March
2013
Governing
Council
TARGET2-SECURITIES - THE BLUEPRINTTable of
contentsIntroduction1. Project Objectives2. Perimeter of
TARGET2-Securities3. Functional Architecture4. TARGET2-
Securities Project Timeframe

Question/Question.doc
Maximum 5 pages (1.5 spaced); figures and/or tables are
allowed on additional pages.
1. (60 points – maximum 3 pages)
Do the problem that is described in the attached Excel
spreadsheet. When you do this problem, you are allowed to ask
for help within your organization of a person, who is very well
versed in Excel (or any other appropriate data analysis
software). However, the person who would help you with the
use of Excel should not assist you with regard to the design of
your expressions or formulas or with the interpretation of the
results.
When you experiment with your regression analysis, you have
to decide on a trade-off between a relatively simple expression
and an acceptable R-Squared. (Any one of the five KRIs may
appear only in at most two of the (composite) factors in your
expression.)
2. (40 Points - maximum 2 pages)
See the attached document that describes a trade settlement
system and answer following questions:
a) Identify the potential points of failure in the trade
settlement system described in the document.
b) Describe the types of events that can result in Operational
Risk losses. Can you say anything about the frequencies and
severities of losses? You may want to provide a qualitative
discussion about the frequencies and severities, possibly as a
function of total number of trades, the types of trades, or other
system or environment characteristics.
c) Describe KRIs that would be useful for the tracking or
monitoring of the ops risk.
d) Recommend risk controls for this organization (on a
tactical level as well as on a more strategic level).

Question1.xlsxAnova ResultsSUMMARY OUTPUTRegression Statistic.docx

Question1.xlsxAnova ResultsSUMMARY OUTPUTRegression Statistic.docx

Recommended

Recommended

More Related Content

Similar to Question1.xlsxAnova ResultsSUMMARY OUTPUTRegression Statistic.docx

Similar to Question1.xlsxAnova ResultsSUMMARY OUTPUTRegression Statistic.docx (20)

More from catheryncouper

More from catheryncouper (20)

Recently uploaded

Recently uploaded (20)

Question1.xlsxAnova ResultsSUMMARY OUTPUTRegression Statistic.docx