BOGS Feasibility Assessment towards T2S

BOGS Feasibility Assessment towards T2S

v 1.0

Athens, April 2012

Table of Contents

1. EXECUTIVE SUMMARY ......................................................................................................................... 3

2. IMPACT ANALYSIS/ADAPTATION APPROACH ....................................................................................... 3

2.1 LEGAL/REGULATORY.................................................................................................................................. 4 2.1.1 Compliance with legal and regulatory requirements ................................................................... 4 2.1.2 Supervision ................................................................................................................................... 4 2.1.3 Eligibility Criteria .......................................................................................................................... 5 2.1.4 Other topics .................................................................................................................................. 5

2.2 TECHNICAL .............................................................................................................................................. 6 2.2.1 Network Connectivity ................................................................................................................... 6 2.2.2 Software and database ................................................................................................................ 6

2.3 FUNCTIONAL ............................................................................................................................................ 6 2.3.1 Static Data.................................................................................................................................... 7

2.3.1.1 Participants ........................................................................................................................................... 7 2.3.1.2 Securities ............................................................................................................................................... 7 2.3.1.3 Securities Accounts ............................................................................................................................... 7 2.3.1.4 Dedicated Cash Accounts ...................................................................................................................... 8 2.3.1.5 Rules and Parameters ........................................................................................................................... 8

2.3.2 Settlement Instructions ................................................................................................................ 9 2.3.3 Business Validation and Matching ............................................................................................... 9 2.3.4 Securities Settlement .................................................................................................................. 10 2.3.5 Corporate Actions ...................................................................................................................... 10 2.3.6 Information Services .................................................................................................................. 10 2.3.7 BOGS internal services ............................................................................................................... 11

2.3.7.1 Users Management ............................................................................................................................. 11 2.3.7.2 Fees ..................................................................................................................................................... 11 2.3.7.3 Auditing ............................................................................................................................................... 12 2.3.7.4 Archiving ............................................................................................................................................. 12

2.3.8 New functionalities .................................................................................................................... 12 2.3.8.1 Auto-collateralisation .......................................................................................................................... 12 2.3.8.2 Partial settlement ................................................................................................................................ 13

2.4 SETTLEMENT CALENDAR/SCHEDULE............................................................................................................ 13 2.5 COMMUNITY .......................................................................................................................................... 13 2.6 TESTING/MIGRATION .............................................................................................................................. 14

3. ADAPTATION PLAN ............................................................................................................................ 14

4. CONCLUSION ...................................................................................................................................... 15

1. Executive Summary

This paper provides an impact analysis on the Bank of Greece Settlement System (BOGS) in

terms of being ready to migrate into wave 1 of TARGET2-Securities (T2S), which is expected to

go live on 22/6/2015. The following impact analysis is mainly based on the currently available

documentation and in particular:

- the UDFS v.1.2;

- the GFS v.4.0.0;

- the Business Process Description v.1.0; and

- the T2S Executive Summary Plan and Operational Plan as of 21/3/2012.

The paper summarises the high-level impact analysis and the relevant adaptation approach that

BOGS will follow to match the requirements of its participation in migration wave 1 with regard

to the following major areas:

- Legal/regulatory

- Technical

- Functional

- Settlement calendar/schedule

- Community

- Testing/Migration

Overall, the assessment concludes that the adaptation of the BOGS IT system and processes to

interoperate with T2S look feasible from both functional and time perspective. In particular, the

assessment does not identify any crucial issue that could prevent BOGS, i.e. any potential show-

stopper, from being successfully migrated to T2S. This positive conclusion, which is also

described in the last section of this paper, should be considered as a first indication of the

feasibility of BOGS adaptation that supports the decision of signing the T2S Framework

Agreement in April 2012. The exact specifications in terms of both software and business

processes adaptations are still to be detailed and finalised.

The basic principles that drive BOGS adaptation are i) to minimise the adaption impact for its

participants, ii) to continue offering the same, as much as possible, type and quality of services to

its participants and iii) to exploit to the greatest extent possible the new functionalities provided

by T2S. In T2S world, the BOGS will fully outsource the securities settlement and matching to

the T2S platform.

At the current stage, the BOGS has entered the investigation phase of requirements analysis,

which will result in the detailed set of requirements for adapting the BOGS software and the

relevant business processes.

2. Impact Analysis/Adaptation Approach

This chapter presents a high-level summary of the T2S expected impact on BOGS as well

as the relevant adaptation approach, in case the latter can be determined at this stage.

Wherever possible, the assessment is expressed using a three-level scale, i.e. low,

medium and high, at the end of the relevant section. Each value represent the estimated

level of the adaptation complexity, which takes into account a number of different

parameters, if applicable, such as the required effort in terms of manpower, the number of

modules to be adapted, the number and the nature of the affected stakeholders, the time

required for implementing the change, the difficulty of adapting the relevant business

processes etc.

2.1 Legal/Regulatory

2.1.1 Compliance with legal and regulatory requirements

The key (national) legal and regulatory requirements related to the CSD under assessment

here, i.e. the System for Monitoring Transactions in Securities in electronic Book-Entry

(BOGS), are set out in Law 2198/1994 (introducing at the Bank of Greece a System for

monitoring transactions in securities in book-entry form), as currently in force, and, by

virtue of this law, in the Operating Regulations of the abovementioned System (BOGS

Operating Regulation), resolved by an Act of the Governor of the Bank of Greece. Of

paramount importance in this context is, furthermore, Law 2789/2000 implementing the

provisions of Directive 98/26/EC on Settlement Finality.

BOGS’ compliance with the said legal and regulatory requirements has been extensively

evaluated by means of assessments conducted on the basis of the methodology followed

by the Eurosystem in assessing securities settlement systems from the perspective of user

of collateral involved in its credit operations (see relevant information on eligible SSSs

on the ECB webpage http://www.ecb.int/paym/coll/coll/eligiblesss/html/index.en.html).

For the purposes of the present feasibility assessment, which has dealt primarily, given

the significance of finality issues for T2S, with the application of Settlement Finality rule

II (irrevocability of transfer orders) and Settlement Finality rule III (irrevocability of

transfers), it suffices to note that the BOGS complies with relevant national and legal

regulatory requirements as defined in the T2S Framework Agreement and that, in view of

the objective of T2S to facilitate legally sound, seamless cross-border DVP settlement, its

system rules define the moment of irrevocability of transfer orders and the moment of

settlement finality in accordance with the principles expressed in the SFD and the

CESR/ESCB Recommendations.

2.1.2 Supervision

As regards steps taken by BOGS vis-à-vis its relevant supervisory authority (BoG) in

relation to the future use of T2S Services as well as the issue of whether BOGS detects

legal and regulatory requirements that could jeopardize its participation in T2S, reference

should be made to the fact that neither Law 2198/1994 nor the BOGS Operating

Regulations contain any provisions relating to the outsourcing of technical functions to

third parties. In view of the fact that the central feature of T2S is that a core part of the

IT-functions of participating CSDs, namely the processing of transfer orders and the

http://www.ecb.int/paym/coll/coll/eligiblesss/html/index.en.html

technical maintenance of its securities account database, will be outsourced to the

Eurosystem, it is currently being contemplated whether relevant (enabling) provisions to

that effect (i.e., provisions that explicitly allow the technical outsourcing of particular

actions) should be included, for legal certainty/clarity purposes, either in Law 2198/1994

or the BOGS Operating Regulations, as currently in force.

2.1.3 Eligibility Criteria

As to the initial assessment of BOGS against the CSDs access (eligibility) criteria, as

defined in Guideline ECB/2010/2 of 21 April 2010, it is to be noted that BOGS has

indeed been notified to the European Commission under Article 10 of Directive 98/26/EC

of the European Parliament and of the Council of 19 May 1998 on settlement finality in

payment and securities settlement systems and should, furthermore, be deemed compliant

vis-à-vis the CESR/ESCB Recommendations for Securities Settlement Systems (access

criteria 1 and 2). In relation to access criteria 3, 4 and 5 (i.e., CSDs shall make each

security/ISIN for which they are an issuer CSD (or technical issuer CSD) available to

other CSDs in T2S upon request; commit to offer to other CSDs in T2S basic custody

service on a non-discriminatory basis; commit towards other CSDs in T2S to carry out

their central bank money settlement in T2S if the currency is available in T2S), BOGS’

senior management team has provided, despite the fact that the said

obligations/commitments are not presently documented in legally binding

texts/documents, assurances that BOGS will both strictly abide by access criteria 3, 4 and

5 and introduce any necessary amendments to the BOGS Operating Regulation (prior to

the T2S Operational Phase).

2.1.4 Other topics

One of the main goals of T2S is the harmonisation, to the extent possible, of the market

practices. For this purpose, the Eurosystem has established Task Forces, such as the

Harmonisation Steering Group and the Subgroup on Corporate Actions, with the task to

identify the issues for harmonisation and release the relevant standards. Although the

relevant impact has not been thoroughly analysed, BOGS intends to adopt these standards

and therefore to perform any legal/regulatory changes that may be required.

Finally, as regards contractual arrangements for DCPs (Directly Connected Parties),

BOGS is, presently, in the process of an initial assessment of the terms and conditions to

be included in the said arrangements.

2.2 Technical

2.2.1 Network Connectivity

At the current stage it is envisaged that BOGS will most probably choose a VAN

provider, mainly due to the high cost of the dedicated link solution. The negotiation with

both the T2S VAN providers (Sia/Colt and SWIFT) has already been initiated.

Regardless of the final decision on the selected provider, the impact is expected to be

high, as the current BOGS network configuration will have to be completely modified.

Expected impact: High

2.2.2 Software and database

As described below (see section 2.3), the adaptation of the software system will be

determined by the required functional changes. The overall impact of the software

adaptations is expected to be high, since i) a number of core system modules, such as the

settlement/optimisation module, will have to be de-activated, ii) most of the remaining

modules will have to significantly be modified, and iii) new modules and interfaces will

have to be introduced to implement/support new features, such as the A2A interface to

T2S.

At the database level, the impact is also expected to be high, due to the outsourcing of

many static data to the T2S database and the necessary changes for the synchronisation

between the two databases. In particular as far as the synchronisation is concerned, the

working assumption is that synchronisation will be needed, however the exact level and

granularity of the affected entities is still under investigation.


2.3 Functional

The functional impact analysis is mainly focused on the functionality which is currently

provided by the BOGS information system, whereas both the analysis and the adaptation

approach for the relevant business processes is subject to the consultation with the Greek

market and therefore cannot be provided at this preliminary stage.

2.3.1 Static Data

2.3.1.1 Participants

The identification of participants differs between BOGS and T2S. To successfully

migrate to T2S, BOGS will map each internal participant identifier to the T2S identifier

(i.e. the pair of CSD and participant SWIFT BICs). In addition, some market specific

attributes may be introduced to allow for compliance with BOGS participants

management, such as the participant’s profile type (e.g. bank, broker, etc.) which also

affects its privileges.

Expected impact: Low

2.3.1.2 Securities

The definition and maintenance of securities for which the BOGS is the issuer CSD, will

take place in T2S platform and will refer only to the limited set of data relevant for the

settlement process. Hence, only a subset of securities data will be migrated to T2S,

whereas the complete set will still need to be maintained in the local BOGS database.

This is mainly due to the data needed for the processing of corporate actions. The upload

of the T2S relevant data will be performed by using the Data Migration Tool, whereas

after migrating to T2S the U2A mode will mainly be used. One point that is still open is

whether and which market specific attributes will be used.


2.3.1.3 Securities Accounts

The BOGS system uses an account structure that allows for defining a hierarchy of

securities accounts, which may consist of multiple levels. Based on this model, it is

mandatory for the BOGS’ participants to separate their balances in multiple securities

accounts depending on the identity of the group of holders to whom the relevant balances

correspond, i.e. own portfolio/collateral accounts, omnibus client accounts for their

clients when this participant acts as a custodian, segregated accounts, etc. With the

purpose to map the above structure to T2S, a number of market specific attributes will be

defined to cater for the additional characteristics of BOGS securities accounts. It should

be clarified that the above rule for multiple securities accounts only applies to BOGS

participants other than CSDs. In the case of a participant CSD (i.e. an Investor CSD) only

one omnibus account in BOGS is required. Prior joining T2S, the above structure will be

re-assessed in consultation with the BOGS’ participants and thus it may be partially

restructured.

Similarly to T2S, in BOGS each securities account is owned by a BOGS eligible

participant. The structure of the account number of each securities account allows for the

identification of its owner as well as its area of business/category. On the contrary, in

T2S the securities account numbers are currently specified to be randomly generated

using its internal codification, pending the implementation of a change request that

allows the CSDs to define their preferable identifier. Unless the change request is

implemented, this will hazard the migration process and force the BOGS to implement an

internal mapping to T2S random identifiers.

Expected impact: Medium to High

2.3.1.4 Dedicated Cash Accounts

The cash accounts in the BOGS are initially defined at a participant level, being the

owner of this specific account and there is no limit on the number of cash accounts each

participant may have. Upon definition, each cash account is linked to one or many

securities accounts regardless of the owner of the relevant securities/cash accounts

meaning that eventually the same cash account can be linked to securities accounts

owned by different participants.

T2S will introduce the usage of dedicated cash accounts, which will be under the control

of the respective Central Bank. The logic under which the dedicated cash accounts will

be defined and operate is very similar to the one currently existing in BOGS, i.e. multiple

(dedicated) cash accounts per participant. Therefore, the BOGS schema may be migrated

into T2S as it stands, combined with the required information regarding the Credit

Memorandum Balances (CMB), which is configured by the relevant Central/payment

bank.

Expected impact: Medium

2.3.1.5 Rules and Parameters

The BOGS supports the definition and maintenance of a number of system parameters as

well as rule sets regarding the management of the incoming settlement instructions. In the

light of migrating to T2S, it will be necessary to distinguish between those parameters

and rules that can/shall be migrated to the relevant T2S structures and those that shall not

(i.e. the latter will either remain in BOGS or will be entirely dropped). Once this

distinction is made, the migration will be performed with the usage of the DMT and/or

the T2S GUI.


2.3.2 Settlement Instructions

At the current stage BOGS receives a number of different types of settlement

instructions, which constitutes a superset compared to the T2S supported type of

instructions. Participants forward such instructions to the BOGS with the use of ISO

15022 SWIFT messages. A specific operation code (numeric field) is included in each

message for the BOGS system to differentiate between the numerous instruction types.

T2S on the other hand uses ISO codes for the categorisation of the supported settlement

instructions. To successfully migrate to T2S, the BOGS shall map all of its operation

codes to the relevant ISO codes and in addition correlate any of its T2S non-supported

instructed types to the equivalent set of supported settlement instruction types (FOP,

DVP/RVP and PFOD). The latter may require the definition of market specific attributes.

An example of a T2S non-supported instruction type is the exchange of securities, where

the system automatically generates the settlement instructions required on behalf of the

issuer. In the case of cross-border settlement or direct connectivity, it is initially foreseen

that the additional information required will be retrieved by using the allegement

mechanism. A detailed analysis on these operations will be provided at a later stage when

the final instructions types’ configuration for BOGS is concluded.

The BOGS also offers a set of value-added services to its participants for instructions

requiring a second leg, such as repos, buy-sell-backs, lending etc. The BOGS aims to

continue offering, to the extent possible, such services to its participants.

It should be noted that the BOGS will consult its market participants to finalise which of

the above value-added services and T2S non-supported instruction types will be

maintained. Such finalisation will also take into account the outcome of the T2S

harmonisation work-streams, such as the recommendations made by the TFAX group.


2.3.3 Business Validation and Matching

The BOGS will fully outsource the matching facility and the relevant allegement

mechanism to T2S, i.e. the BOGS matching sub-system will be discontinued once

migrated to T2S. As far as the business validation of the settlement instructions is

concerned, BOGS will to some extent maintain its current mechanism with some

adaptations, wherever required. Thus, BOGS business validation will be a first check

before sending an instruction to T2S, where the complete and final business validation

check is performed. This first check aims at avoiding, to the extent possible, forwarding

to T2S invalid instructions.

Finally, the adaptation process for business validation will also focus on the compliancy

with the T2S validation rules and the relevant reason codes will be harmonised

accordingly.

Expected impact: Medium

2.3.4 Securities Settlement

The securities settlement, including all the relevant ancillary services, such as the

optimization and recycling, will be fully outsourced to T2S. The adaptation process

includes firstly the identification of all the affected BOGS modules, secondly the design

of the plan for safely dismantling those modules from the BOGS legacy system and

finally the implementation plan and testing of its results.


2.3.5 Corporate Actions

T2S as a settlement platform will not offer any service regarding corporate actions

management, which will therefore continue to occur at the BOGS level. In this context,

the BOGS will generate and transmit to T2S all the relevant settlement instructions.

It should be noted that BOGS, being merely an issuer CSD, supports only a limited set of

corporate actions on stock, which include coupon payments and redemptions. Corporate

actions on flow as well as the broader scope of corporate actions on stock are not

currently supported. Nevertheless and based on the analysis being performed by the

CASG, all CSDs upon migrating to T2S shall be compliant with both CASG and

CAJWG standards. For BOGS this will have two main implications:

i) the implementation of the relevant mechanism for the processing of the

corporate actions on flow, and

ii) the implementation of the relevant mechanism for both corporate on stock and

on flow, for the cases where BOGS will act as Investor CSD (depending on

the market needs).


2.3.6 Information Services

Currently, the BOGS provides to its participants real-time information about the progress

status of their settlement instructions with same-day value or with a future value date,

including matching, allegement and business validation results. Such information is

provided through various channels, such as the WEB, the Bank of Greece Electronic

Secondary Market Platform and SWIFT (statement reports). In addition, the BOGS

software system provides its internal users (operators) with a large number of reports and

query abilities to facilitate the support to the BOGS participants.

Migrating to T2S will bring changes to both ends, i.e. the BOGS’ participants and its

internal users (operators). The magnitude of this impact depends on the level of

synchronisation between the BOGS and the T2S database (see section 3.2.2). The higher

the level of synchronisation the lower the impact of adaptation and vice-versa.


2.3.7 BOGS internal services

2.3.7.1 Users Management

The BOGS currently uses an internal users’ management schema including specific roles

and privileges for each user. This schema is not expected to be affected by T2S. The only

impact from T2S, is that a similar schema will need to be defined in the T2S platform.

The definition of this schema will be performed primarily by using the Data Migration

Tool. After migration, the U2A mode will be used for maintaining/updating this schema.


2.3.7.2 Fees

The fee mechanism of BOGS is limited to the calculation of an one-off fee per instruction

which covers the whole cost for each participant, i.e. transaction fee, custody fee,

corporate actions processing fee, communication fee, etc. For this calculation, the BOGS

system takes into account a number of parameters, such as the instructions’ transmitting

time, the aggregated volume of instructions, the type of counterparty etc.

In the T2S world, the fee mechanism will be completely different and several separate

fees will have to be calculated and applied to its participants, .i.e. transaction fees,

custody fees, fees for reports and queries, etc. For this reason, the BOGS fee mechanism

should be significantly modified to incorporate the T2S charging model.


2.3.7.3 Auditing

Similarly to T2S, the BOGS provides an audit trail for recording the actions taken and the

relevant timing per operator. After migrating to T2S, the internal BOGS audit trail

mechanism will remain without any significant change and will be used as a

complementary function to the T2S relevant audit information. The latter will be

retrieved by querying T2S on an ad-hoc basis.


2.3.7.4 Archiving

To fulfill the legal requirements (Greek civil code) the BOGS system includes an archival

mechanism that allows for the storage of the settlement-related information for 20 years.

The T2S archival facility for harmonization purposes is based on a storage period of 10

years. Considering that the current legislation is difficult to be changed, the BOGS

archival mechanism should technically be adapted to cater for the 10 years that are not

covered by T2S archival. The feasibility of such adaptation implies a level of technical

synchronisation between BOGS and T2S database (see also section 2.2.2).


2.3.8 New functionalities

2.3.8.1 Auto-collateralisation

Auto-collateralization is an optimisation functionality provided by T2S, which is

activated whenever a settlement instruction included in the settlement process cannot be

settled due to lack of cash. In such case, the relevant T2S Actors may receive liquidity

from the relevant Central Bank or payment/settlement bank in order to cover the missing

resources in cash. This liquidity is provided against collateral under specific rules and it

requires the definition of a set of data in the T2S database upon creation of a new

dedicated cash account.

Such functionality is not currently supported by BOGS and therefore the overall impact

in both business and technical level is expected to be high. More specifically, depending

on the technical synchronisation level between BOGS and T2S, the BOGS’ system will

have to be modified to process the T2S relevant information about the new instructions

generated for auto-collateralisation purposes and the newly generated/updated balances.


2.3.8.2 Partial settlement

Partial settlement is another optimisation functionality provided by T2S allowing the

partial settlement of instructions sent by CSDs’ participants depending on the available

balances in both cash and securities accounts. It requires a set of data to be defined by i)

the T2S Actors in their settlement instructions, ii) the T2S Operator in the Static Data and

iii) the T2S Actors acting as administrator for the relevant ISINs.

Partial settlement functionality is not currently provided by BOGS to its participants and

therefore an instruction can be settled only if both cash and securities balances are

available in total. For this reason, the relevant impact of introducing such a business

process is expected to be high, assuming that the market decides to adopt it. Regarding

the BOGS’ IT system, the impact will depend on the level of synchronisation between the

BOGS and the T2S database (see section 2.2.2).

Expected impact: Medium to high

2.4 Settlement Calendar/Schedule

The migration of BOGS to T2S will affect the calendar, which is currently in force in the

Hellenic market, since BOGS will have to adapt to the harmonised T2S calendar. In

particular, the Hellenic market is closed during the Orthodox Easter and the national

holidays even though these are working days for TARGET2. After migrating to T2S,

BOGS will have to be fully operational during the T2S working days.

Furthermore, BOGS will have to adapt to the daily schedule of T2S which will result to

extended operating hours for BOGS in comparison to the current situation. In addition,

night time settlement functionality will be introduced to the BOGS participants.

Another topic that needs to be finalised with the issuer is the timeframe for the corporate

actions. Currently, the issuer sends to BOGS the instruction to redeem the relevant

payments to the beneficiaries at the beginning of the day of the payment date. According

to the current daily schedule, this day coincides with the calendar day since there is no

night time settlement in BOGS. In the T2S world, the issuer shall send the instruction to

BOGS on the calendar day before the payment day, in order for BOGS to produce the

relevant T2S instructions.

2.5 Community

At the current juncture, the communication between BOGS and its community for T2S

relevant topics is mainly performed via the Hellenic National User Group (NUG-GR). In

addition and whenever deemed necessary, the set-up of ad-hoc task forces with specific

expertise is envisaged to cater for consultations on concrete issues.

As far as the assessment of the T2S impact to the market is concerned, at this stage it is

difficult to make any estimation. The relevant consultation (in terms of both physical

meetings and written procedures) with the market is still ongoing and it is expected to be

concluded in the course of this year, as more detailed specifications from BOGS will be

available. The BOGS community plan also envisages the establishment of a progress

monitoring framework in terms of a mutually agreed reporting schema on the basis of a

number of synchronisation points. Moreover, and in the absence of a final picture

regarding the number of Directed Connected Actors (DCAs) in the Greek market, BOGS

confirms that it will be feasible to support DCAs by adapting the relevant regulatory/legal

frameworks.

2.6 Testing/Migration

BOGS is committed to participate in migration wave 1 of T2S and therefore will comply

with the agreed time-plan and set of activities, as described in the relevant Schedules of

the Framework Agreement (2, 3 and 4) as well as in a number of additional documents

which are still to be finalised, such as the User Testing Terms of Reference, the Pilot

Testing Terms of Reference, the Migration Storyline etc.

Prior being involved in the Pilot and the User Testing, BOGS will execute its internal

testing with the participation of its participants (see section 3 below, reference to BOGS

internal testing and BOGS community testing). During the T2S Pilot and User Testing,

BOGS intends to use the test environment in both normal and slow motion, whenever

available. It also intends to use the tools that facilitate both testing and migration

activities, such as the Data Migration Tool (DMT), the Snapshot facility etc.

3. Adaptation plan

The figure below depicts a high-level timeplan of the BOGS major tasks towards its

migration to T2S. The granularity of the depicted plan corresponds to the T2S Executive

Summary Plan. As shown below, the BOGS plan is aligned with the T2S Programme Plan as

this stands on 21/3/2012.

ID Task Name

2012 2013 20152014

Q4Q2 Q3Q1 Q2Q2Q3 Q4 Q1Q3Q4 Q1 Q2

2 Preparation Phase

5 Development Phase

12 Pilot Testing

10 BOGS Internal Testing

1 30/4/2012FA Signature

Start

30/4/2012

30/4/2012

1/1/2013

3/2/2014

9/6/2014

Q3

14

13

22/6/2015 22/6/2015GO LIVE

1/10/2014User Testing

9 3/2/2014Testing

6 1/1/2013Functionality

Finish

30/4/2012

29/3/2013

31/1/2014

31/1/2014

19/6/2015

2/5/2014

30/9/2014

19/6/2015

22/6/2015

7 31/1/20141/10/2013Legal/Regulatory

8 31/1/20141/10/2013Network Connectivity

3 29/3/201330/4/2012Specifications

4 29/3/20131/10/2012Network Provider Negotiation

11 6/6/20145/5/2014BOGS Community Testing

4. Conclusion

The feasibility assessment concludes that the adaptation of the BOGS software system

and the relevant processes to interoperate with T2S look feasible from both functional

and time perspective. In particular, the assessment did not identify any crucial issue, i.e.

any potential show-stopper, that could prevent BOGS from being successfully migrated

to T2S. This positive conclusion should be considered as a first indication of the

feasibility of BOGS adaptation that supports the decision of signing the T2S Framework

Agreement in April 2012. The exact specifications in terms of both software and business

processes adaptations are still to be detailed and finalised.

BOGS Feasibility Assessment towards T2S

Documents