GUIDE TO TARGET2 USER TESTING
Contents
1. j Wi ul STUD mili Hini imil TARGET2 USE i e n gt a gt j Sao S gt N a Foreword Testing activities are an important part of the change management procedures for TARGET2 In this context test requirements and test procedures shall be made clear to TARGET2 participants in case changes are occurring on either the participants on the Central Banks or on the SSP side That is why the Eurosystem developed a harmonised testing framework which national central banks are responsible for implementing with their national banking communities This Guide to TARGET2 User Testing aims at providing future TARGET2 direct participants and ancillary systems with details of all the technical functional and procedural aspects while scheduling organising and performing TARGET 2 related testing activities It is largely based on its predecessor TARGET2 User Testing Guide for the Migration While it presents procedures applicable to all connected countries information specific to individual national banking communities can be found on the TARGET2 websites of the respective national central banks This guide exclusively deals with activities on the test amp training environment and does not touch upon the preparatory activities on the production environment In the case of newly connecting participants or banking communities please refer to the relevant Eur2. in a way that it can be tested in A2A mode 2 3 2 Preconditions for starting the interoperability testing The future TARGET2 user must receive confirmation from its respective CB that connectivity testing has been completed successfully before commencing the interoperability testing 2 3 3 List of interoperability test cases The list of all mandatory and conditional interoperability test cases can be found in Annex2 Whenever PHA systems are used participants are invited to refer to the respective national testing documentation for details on how the interoperability tests with the PHA can be performed see Annex4 _CB_Contacts 2 4 Business day testing 2 4 1 Scope and aim While connectivity and interoperability checks the technical ability of the user to Participant s Activities interact with the system Business day and CB s _ inthe internal production lt environment testing focuses more on the tests organisational and operational aspects of _ f j j TARGET 2 Beyond a few common Aae f r j functionalities it mainly touches upon the use of proprietary systems the local contingency arrangements and the domestic settlement of ancillary systems 2 4 2 Preconditions for starting Business day testing The future TARGET 2 user must receive confirmation from its respective CB that interoperability testing has been completed successfully before commencing the Business da
3. Live BIC BIC T amp T BIC T amp T Live BIC BIC T amp T Live BIC n a BIC T amp T Live BIC Live BIC BIC T amp T Live BIC BIC T amp T Live BIC BIC T amp T Live BIC BIC T amp T Live BIC BIC T amp T Live BIC n a Like the live environment the TARGET2 Directory in CUST will be based on the SSP static data Fields participant Addressee and Account holder must be filled in with T amp T BICs If a user wants to have its live BIC8 published in the TARGET2 Directory used in CUST it must request the creation of a wildcard rule for registering its live BIC as addressable BIC behind its T amp T BIC The wildcard rule for the inclusion of live BICs should have the branch option flag set to NO and the field BIC Addressee should not be used for Live BICs 1 3 General organisation of certification activities 1 3 1 Phases of TARGET2 User Testing Each user must undergo a number of certification testing activities which will depend 1 on the type of change connection envisaged 11 on the profile of the participant and iii on the profile of Central Bank banking community Further factors impacting the type and number of tests to be performed are e g the participation in different Ancillary Systems After a careful analysis of these factors certification requirements will be defined by the respective Central Bank and will be organised in different phases from the simplest
4. 4 1 Scope and aim and CB s inthe internal production Free testing provides participants with an tests opportunity to run testing activities which a Activities environment strictly speaking are not mandatory for its certification While there is no obligation to carry out free testing future participants are encouraged to make use of it in order to become familiar with TARGET2 The following tests can be carried out Interoperability test elaborated from chapter 2 in non certification mode Additional test scenarios required by the user for their own verifications and staff training Volume testing see limitations as mentioned in 1 2 3 Bilateral multilateral tests to be agreed between voluntary participants e g multinational credit institutions willing to organise liquidity management tests with its branches in other countries ancillary systems willing to perform ad hoc end to end tests with its participants before Business day testing credit institutions willing to organise tests with its indirect participants etc Negative testing e g rejections of payment instructions 1 4 2 Rules to adhere to In order to avoid unwanted side effects on test activities performed by other users each user must adhere to following rules oO oO oO oO Ensure not to exceed the volume limitations defined in 1 2 3 without prior authorisation from the CB No use of test BICs of other users including C
5. Internet based users e Fach internet based user should have the required hardware and software for the connection with a smart card and an Internet browser Internet Explorer or FireFox e The process of acquiring the smart card s with the local Central Bank should be completed See User Manual Internet Access for the public key certification published on the TARGET2 Web site on 30 June 2010 3 2 3 List of connectivity test cases The detailed test case descriptions can be found in Annex1 Whenever PHA systems are used participants are invited to refer to the respective national testing documentation for details on how the connectivity tests with the PHA can be performed see Annex4_CB_ Contacts 3 3 Interoperability testing 3 3 1 Scope and aim In teroperabili ty test i n g ensures th at th e T 3 Jne ai l Central Bank and each of its users can Participant s Activities participate in TARGET2 by using all relevant and CB s inthe internal production functionalities of the SSP modules and if tests environment applicable in the CB s respective proprietary j systems All future TARGET2 users should be able to send and receive correctly formatted information A different set of test cases is assigned to the user depending on its user profile direct participant CB customer HAM account holder AS The optional SSP modules chosen by the connecting CB and the optional fu
6. and security features like encryption and authorisation should be verifiable For instance that includes for SWIFT based users the correct setting up of the TARGET2 Closed User Group CUG and the connectivity required to use the ICM and the exchange RMA with the SSP For internet based users it includes the certificate creation via the Central Bank and the correct setup of the PC used for TARGET2 and the internet connection see System requirements for Internet Access published on the TARGET2 Web site in June 2010 However it should be noted that no separate connectivity test cases for SWIFTNet InterAct and FileAct in application to application mode are envisaged 2 2 2 Preconditions for starting the connectivity testing Before the start of connectivity testing the following entry criteria have to be met in addition to those mentioned under chapter 2 1 SWIFT based users Each SWIFT based user should have the required software for accessing SWIFTNet FIN SWIFTNet FileAct SWIFTNet InterAct and SWIFTNet Browse RMA must be exchanged between participant and the SSP as central institution for CUG PM with TRGTXEPO for CUG HAM with TRGTXEHO and or CUG CB Customers with TRGTXEC0 Internet based users Each internet based user should have the required hardware and software for the connection in place This included a smart card device and an Internet browser Internet Explorer or Firefox The process of acquiring personalized
7. be able to verify all functions implemented in terms A re of hardware software which are part of the user s interfaces with T2 Testing of proprietary systems should be included in addition to the SSP modules e For critical functions applicable to all TARGET2 users e g payment processing cancellation of payments mandatory test cases are defined which each participant has to complete and report on to the national service desk as part of the certification process e For critical functions which are applicable only to a subset of TARGET2 users conditional test cases are defined Typically conditional test cases cover features provided by an optional module e g HAM or additional services offered to participants e g liquidity pooling If applicable to the participant a conditional test case becomes mandatory and the test results must be reported as part of its certification process Otherwise the participant does not have to run it Users connecting to the ICM server in application to application A2A mode should test the respective functionality both in user to application U2A and A2A mode The test cases are always described according to the U2A approach using ICM but contain a reference to the respective XML structures to be used in A2A mode Based on this information and the individual implementation of the A2A interface it is the responsibility of the user to translate the U2A mode test case description
8. change requires an update of the TARGET2 static data the user must provide its national service desk with the relevant updated TARGET2 registration forms 4 3 Types of changes and testing process associated The re certification requirements will be defined by the Central Bank depending on the impact of the envisaged change They will consist in a partial of full repetition of the connectivity interoperability tests possibly complemented by business day testing For Ancillary systems tests with settlement banks might also be organized 4 4 Connectivity testing 4 4 1 Scope and aim Connectivity testing after a change verifies the ability of the existing TARGET user to still connect to the different SSP modules that the respective CB has opted for and if applicable to the CB s respective proprietary systems All SWIFTNet connectivity features necessary to communicate with the SSP need to be re checked for the correct set up of parameters and security features 4 4 2 Pre conditions for starting the connectivity testing The change must be completed in the test environment in the same way it will be implemented in the Live environment before starting the interoperability testing certification 4 4 3 List of connectivity test cases All connectivity testing mentioned in annex 1 should be performed by the participant 4 4 4 Changes subject to re testing of connectivity test cases The following changes trigger
9. eee ene eee ee 30 4 4 2 Pre conditions for starting the CONNECTIVITY testing cccscccccccescescescsessceseeesseeeeceseeesseeeseens 30 4 4 3 List Of CONNECTIVITY test CASES ccccccsccccsescessseesseesseceseseeseecseeceseeceseeesseecsseeenseeceeeseesenseeensaeenses 30 4 4 4 Changes subject to re testing Of CONNECTIVITY test CASCS ccccccscccscccesscesseessesesseesesesesessseeseens 30 4 5 INTEROPERABILITY TESTING wssciiiirsadansniannsdnscaetencstantaivesiontunaelvaseadsaraiiunsinaniens Sonkhaassbantaduosiiunsitanttsadeiaie 31 4 5 1 Oe T a pases ase A A A A A A A AA A 31 4 5 2 Pre conditions for starting the Interoperability teSting cccccccccccccccsccccsscccssccesscsssscessseeesees 3 4 5 3 List of Inieropera bil TOS COSC S asa O N EE EE 31 4 5 4 Changes triggering the re certification of the Interoperability teSting cccccccccceee 3 ED CUS TINIE DAT TS IN sr perce E eee ec ae hee er a2 4 6 1 CO Oh sc tacestas mses gee nad te csr Rea ane ate cance ged natok be ssn Soc E T 32 4 6 2 Pre conditions for starting the Business day testing ccccccccccscccessccesscccsscsssscsessceesscesseeessees ga 4 6 3 Changes triggering the re certification of the Business day teSTING cccccccccccesscesseeeees 32 4 7 ANENG ELEMENT aaa A EEA EAA EOE AAE AORA EA OAE AEEA 32 S TOCHA NGESON THE SSP SIDE e a E A E 33 Sel GENERAL PREC ONDIVIONG nopairiieaneisainiraa a N ETE a NE A ETa 33 Jld CORT O O a A E E E A E A 33 5 1 2 LAANE O
10. terre ret trrr irr rr trier rier errrrrrrrrrrry Participant s Activities and CB s _ inthe internal production tests environment TARGET2 User Testing for changes on the SSP side 5 1 General preconditions 5 1 1 Communication The Eurosystem will publicly announce the content of the new SSP release early enough to allow participants to assess the changes and to prepare their own applications Once the specification of the changes are known and reflected in the UDFS the Eurosystem will communicate the test requirements applying to participants and a timetable for the testing activities Test requirements will touch upon new features introduced by the release features modified by the release as well as non regression tests This information will be widely communicated via the TARGET2 website of the ECB https target2 ecb de and possibly by the TARGET2 websites of the NCBs In case the SSP release coincides with the yearly SWIFT FIN standard release it is expected that participants will have to connect to the SWIFT FIN Test amp Training network in future mode 5 1 2 Registration It is expected that new SSP releases will not require a modification of the existing SWIFT registration for already connected participants In the unlikely case that a modification of the SWIFT registration is required specification instructions would be given A new SSP release may lead to changes to the SSP
11. testing ccccccccccsccccssccessccessceessceesscessseessees 18 2 3 3 List of imneropera lly TEST CASES rdi eE EE S 18 2 4 PE OE DO US ING os etcetera epee etre eee nten een seeded A eueneieds 18 2 4 1 DCO OA e E EEA aden ea Gases 18 2 4 2 Preconditions for starting Business day testing ccccccccccsccccssccesscccssccesscsesscsessessseessecesseeeesees 18 2 4 3 List Of Business day SCONATIOS c cccccccccccccsscccssccsescsesesseeecssecessesessecessecsssecessecessecessecesesenseeeses 18 Ze TIMING ELEMENTS oct sisters ce ecu E E 19 noe Timeline for the certification Of a NEW PATLTICIPAN ccccccccccccscccessccssecessscessccessscessseesseeeses 19 2 9 2 Windows for NEW CONNECTIONS v eccccccccseccscccescesscsssesesesesseseessseseseesseesusceseeeseeseeceseeeseeesseenseens 20 3 CONNECTION OF A NEW BANKING COMMUNITY ssrerererereseresesesereeeeeeeeererererororerererererereses ZL 3 1 G1 BUNS 220 Om 2 Pe 2 JB lB J gen en ee ee ee 21 ey ae OPAC OI ieee ttre E EEE AE E A E 21 3 1 2 FROG US ITT OM AEAEE ET EEE E E 22 a ONIN CT WS Nets ra concrete ag irc cei ene se cee st doe ee cee ance T 23 D221 SCOPE I ace E RE seas eaectns sans apse ane sn en pate Reagents anneaonneoe aes 23 Jee Preconditions for starting the connectivity tOSTING cccccccccccesccesseesctesecesseesseseseeeseessseeeseens 23 362 3 List of connec hivy Esl CO SCS srai ine E A A EAA ass snea neo ices 24 3 3 INTEROPERABILITY TESTING siniraan T 24 ENA OEA e E oe cos
12. testing when mandatory should be completed before starting the Interoperability testing re testing 4 5 3 List of Interoperability test cases All relevant mandatory and conditional interoperability testing impacted by the change and mentioned in the Annex 2 should be performed 4 5 4 Changes triggering the re certification of the Interoperability testing The following changes that users want to apply are subject to Interoperability testing e User adopting new TARGET functions corresponding to new Interoperability test cases Any test case mentioned as conditional usage COUS might become mandatory e Any software or hardware change in the SWIFT infrastructure Internet based infrastructure e Any software or hardware change in the application connected to TARGET using A2A triggers the re testing of the test cases declared as mandatory and conditional usage COUS e For Ancillary systems change in the procedure used e Any change in the participation type of the user 4 6 Business day testing 4 6 1 Scope and aim Business day testing after a change should ensure that the existing user can still participate in TARGET2 focusing on the organizational and operational aspects of TARGET2 4 6 2 Pre conditions for starting the Business day testing Business testing can start if connectivity and Interoperability testing phase is completed when required 4 6 3 Changes triggering the re certification
13. to the more elaborated ones Certification will start with test requirements at the level of individual participants connectivity and interoperability testing and may be complemented with test requirements involving a group of participants country and TARGET2 wide testing More detailed information on the different test phases can be found in chapters 2 to 5 of this document 1 3 2 Possible simplification of test requirements In principle test requirements apply the same way to all users under the scope of TARGET2 User Testing see 1 1 2 Nevertheless some exceptions are foreseen in very specific circumstances in order to avoid the unnecessary repetition of tests The main exceptions are as follows non exhaustive list a Multi country banks managing several direct participations from the same technical hub may not need to repeat the whole range of certification tests with all the Central Banks to which they are connected Some exemptions and simplifications in interoperability tests may be granted if justified o In some cases users may open so called specific purpose accounts for which the BICs are not published in the TARGET2 Directory Such accounts may be opened by some participants e g for Reserve Management purposes for the settlement of Monetary Policy transactions or for the management of cash operations If due to the nature of such an account not all test cases apply Central Banks can based on a concrete request fro
14. B and AS without prior bilateral agreement Inform the local CB at least one week in advance about specific test support requirements No interference with other phases of the user testing e g Business day testing Free testing phase should be run as smoothly and flexibly as possible users are advised to run their free testing activities by using multiple test BICs related to their own accounts whenever possible 1 4 3 Preconditions for using free testing opportunities The registration and technical preparation as explained in the respective paragraphs of the chapters 2 5 must be fulfilled before starting testing 2 CONNECTION OF NEW PARTICIPANTS Credit institutions or ancillary systems which want to connect to TARGET as new participants are subject to the test requirements described in this chapter Beside some general preconditions which must be fulfilled future participants are expected to run the relevant connectivity and interoperability scenarios adapted to their future usage of the SSP Some complementary tests are foreseen in the particular context of national specific arrangements coCCCCCCCC CCC COCO CCC OCCT CCC i nnn nn nnn WIRE EEEE OTIS err errr reeer terre errr terest rer etree reer rrery i Participan ts Activities and CB s _ inthe internal production tests i environment TARGET2 User testing for new participants 2 1 General preconditions 2 1 1 Communication When the c
15. CB_Contacts The registration forms for testing should cover the same functional profile as the one to be filled in for live operations Meaning a functionality that a user intends to request for live operations should also be requested for testing and the required certification tests should be performed beforehand There are a priori no limits on the number of BICs to be registered for testing 2 2 Connectivity testing 2 2 1 Scope and aim Connectivity testing verifies the ability of the future TARGET2 users to connect to the T Participant s Activities environment different SSP modules that the respective CB and CB s hie has opted for and if applicable to the CB s y potia production respective proprietary systems All SWIFTNet connectivity features necessary to Oita a E Ei EE communicate with the SSP need to be checked for the correct setting up of parameters and security features By performing this type of activity as early as possible users can reserve time to solve any potential problem related to the underlying services occurring at a later stage which otherwise could delay the start of the following user test phases That cases are defined in a way that oO all possible communication interfaces between a TARGET2 user and the SSP and if applicable a TARGET2 user and a proprietary system should be covered all layers below the application level are covered This means the network
16. L structures to be used in A2A mode Based on this information and the individual implementation of the A2A interface it is the responsibility of the user to translate the U2A mode test case description in a way that it can be tested in A2A mode 3 3 2 Preconditions for starting the interoperability testing The future TARGET2 user must receive confirmation from the connecting CB that connectivity testing has been completed successfully before commencing the interoperability testing 3 3 3 List of interoperability test cases The list of all mandatory and conditional interoperability test cases can be found in Annex2 Whenever PHA systems are used participants are invited to refer to the respective national testing documentation for details on how the interoperability tests with the PHA can be performed see Annex4_CB_Contacts 3 4 Business day testing 3 4 1 Scope and aim peeejsssiuisosesssrsstessosj ssssiocoosss sissossocs eee eee e ees e ess cnccee eta cnecectetettasceeseenenesetes While connectivity and interoperability testing checks the technical ability of the x Participant s a Activities user to interact with the system Business t andCB s inthe internal production day testing focuses more on the tests environment organisational and operational aspects of T ARGET2 Beyond a few common i See j C E l functionalities it mainly touches upon the use of proprietary sys
17. N EEEE E EEE E EE 34 32 CONN CITN Y TESTING consin r acna A E E TEA T 34 IZ SCOPE O I e E E A apse one sn en pate eee anna aes 34 DA Preconditions for starting the connectivity tOSTING cccccccccccesccescesceesseessessseseseeseessseesseens 34 J 2 3 List f Connecivil y ICSF TUSOS sersan rE E E E E E EEEE 34 5 3 INTEROPERABILITY TESTING ninoraieiniiieri E 34 a OOS Id A se incest E oe cose cas cea sal ae cso cic ae nes ead eee eae 34 J Preconditions for starting the interoperability testing cccccccccccccccssccessccessceesscsessceseeessees 35 5 3 3 List of interoperability test CASES cccccccccccecccsssccssccsssccssssesssscesssesssscsssscssasesssscssaeessascesaeessasensas 33 sA BUNE DAY TE IN e a E E T A E E EN TEE 36 5 4 1 OPCO O parse A E A IA E EA A AA 36 5 4 2 Preconditions for starting Business day testing cccccccccccccccsccccsscccssccesscsessccssscesssesssseesseeessees 36 5 4 3 List of Business day TESTING SCCNATIOS acesti SEEE E 36 5 5 TIMING ELEMENTS ccccccccsseccccccscccccccccccccccucecccccauecccccuuceeccccuuceecessuusecescsauceeccsuuuceecessaseseesuaaesces 37 1 INTRODUCTION This section provides general background information on the user testing organisational responsibilities and set up It applies to all types of TARGET2 User Testing activities covered in sections 2 to 5 1 1 Scope of TARGET2 User Testing TARGET2 User testing aims at verifying the readiness of TARGET2 users in the event of
18. any change which may impact on their interaction with the Single Shared Platform 1 1 1 Types of changes taken on board The following changes may fall under the scope of TARGET2 User Testing The definition of testing requirements would depend on the detailed changes which are envisaged A further description of each category is provided in the forthcoming parts of this document a Connection of a new participant e g credit institution becoming direct participant connection of an ancillary system new Central Bank customer CB customer or new HAM participant For further information please refer to chapter 2 a Connection of a new banking community e g in connection with the adoption of the Euro For further information please refer to chapter 3 a Changes on the participant s side e g change of account structure or change on the participant s technical interface For further information please refer to chapter 4 a Changes to the SSP platform e g yearly release triggered by a SWIFT change delivery of a corrective patch or new feature For further information please refer to chapter 5 1 1 2 Parties involved Besides the Central Banks of the Eurosystem and the providers of the platform 3CB TARGET2 User Testing foresees the involvement of the direct PM participants the ancillary systems the Central Bank customers the HAM account holders and the HAM co managers Some restrictions exemptions may apply to spec
19. ase version different from the one running on the production environment PROD Differences may come from the delivery of SSP yearly releases or the implementation of corrective patches The CUST environment is used o by the Central Banks to test the releases patches delivered by the SSP provider 3CB 2 by participants to perform their certification tests against the new SSP releases o by already connected participants to recertify after a change on their internal applications o by new participants or new banking communities for their certification before the connection 2 by Central Banks and participants for regular trialling and training activities 1 2 2 Availability CUST is in principle available on all TARGET working days From Monday to Friday the system is available from 7 00 until 19 00 see schedule below One day per month the SSP may be closed for maintenance reasons Phases of the business day in the test environment MON FRI Prepare daylight operations 07 00 07 15 Activation of standing orders for highly urgent and urgent reservations Day trade phase 07 15 14 30 Payment business and AS settlement procedures 1 6 00 Interbank cut off time 14 30 reserve period Starts 15 minutes later on the last day of the minimum reserve period Liquidity provisioning 15 30 16 00 Starts 15 minutes later on the last day of the minimum All times are given in CET ee ee reserve period
20. ases These test cases will correspond either to newly introduced items to modified items or to existing items to be covered as non regression tests 5 4 Business day testing 5 4 1 Scope and aim Business day testing would aim at verifying that the TARGET2 organisational and Participant s d Activities E operational procedures have not been and CB s S ihe affected by the new SSP release and that the pani y production environ ment changes have been appropriately integrated Beyond TARGET wide procedures l EEE E 7 i ee f business day testing may also include interaction with proprietary systems the local contingency arrangements and the settlement of ancillary systems 5 4 2 Preconditions for starting Business day testing In the event that connectivity tests and or interoperability tests are required users must receive confirmation from their Central Bank that all participants from their banking community passed them successfully before commencing the business day tests 5 4 3 List of Business day testing scenarios Business day test scenarios are based on a common list of scenarios prepared at Eurosystem level and completed by specific scenarios prepared by the National Central Banks These specific scenarios should cover at least the following test items e Payment messages MT103 202 202COV and MT204 e Ancillary system interface The scenarios might also cover th
21. but nevertheless ending at 16 00 Night time settlement 16 00 19 00 Night time processing AS settlement procedure 6 only Technical maintenance 19 00 06 30 No user testing activities Night time settlement 06 30 07 00 Continuing of Night time processing AS settlement procedure 6 only Occasionally on an exceptional basis operating hours as well as the timing of the different business phases may be extended to cater for specific testing requirements allowing e g for testing according to live operating hours On the other hand from time to time the test environment may be closed for maintenance and internal testing purposes Such exceptions are announced well in advance Limited ad hoc delays may be exceptionally granted 1f this is considered to be in the overall interest of the users Possible triggering events may be the completion of some urgent testing activities of a major ancillary system or a national user community Business day testing By default proprietary systems like a PHA if available for testing should align their availability with the timing applicable for the SSP on the same date For details please check with the national central bank for more detailed information see Annex4_CB_Contacts 1 2 3 Volume limitations Any user testing activity requiring hourly volumes that exceed the following limits need central coordination and prior approval owing to volume restrictions imposed by SWIFT and or the SSP u
22. caarnanieiana aie E E EIST a ES E One 12 1 3 6 Reporting on test result s isissssicsisisssepsiisserrisriiesiis ain oier eisses Sariai See 12 1 4 FREE TESTING cecccccccccscececcceccccccccccececececesecececcucucusucesecssssssssessaseseseseseseseseseseseseseacssssacacacacacacasacaavees 12 1 4 1 CODE and CUM eisirean ee a E a E Ei a aE iE e Eai eie 12 1 4 2 E A FACTO TO E EE E sec sees E O E E A E E 13 1 4 3 Preconditions for using free testing opportunities ccccccccccsccessccessceeseeessceesseeesseesseeessees 13 2 CONNECTION OF NEW PARTICIPANTS oeeceseseriisesseteontetoerintsiseateneeoorinucsntn setae arsaa oirne eese 14 2 1 GENERAL PRECONDITIONS eiicsicaupec cans pes sous uaceaaxseiantnasiacscroasnasacndeni naa asiatior sone eso ab TEER 14 2d COT O OM eana EE E E A sete antec E E E EAE ES 14 24 2 TOTS IO TUM en E cents eossieereslensaw esta vasa ican sono erie ees eta t Inn Eaten E 14 Zao CONN TS IN ha esac cence ees tient meses sep ee ec esc oie 15 OAS COPE OT I reassess A aed ate coerce ns aerate enya natch be mse soe st et ane so A sac sages 15 Dee Preconditions for starting the connectivity COSTING cccccccccccesccesccesceeseceseeesseeeseeeseesseeesseens 16 At ie List Of CONNEC CVII TOS COSES senrose ra O EET E E OE E E EOR 17 2 INTEROPERABILITY TESTING a soseceteaesaeucaan aces Ana aueuciansceavoen A EE 17 2 3 1 OPE T ee eee E Ea eC CeO eat ee meee ee eee tre nen renee 17 22 Preconditions for starting the interoperability
23. cable to the participant a conditional test case becomes mandatory and the test results must be reported as part of its certification process Otherwise the participant does not have to run it e Users connecting to the ICM server in application to application A2A mode should test the respective functionality both in user to application U2A and A2A mode The test cases are always described according to the U2A approach using ICM but contain a reference to the respective XML structures to be used in A2A mode Based on this information and the individual implementation of the A2A interface it is the responsibility of the user to translate the U2A mode test case description in a way that it can be tested in A2A mode 5 3 2 Preconditions for starting the interoperability testing In the event that connectivity tests are required the future TARGET2 user must receive confirmation from its Central Bank that connectivity testing was successfully completed before commencing the interoperability testing 5 3 3 List of interoperability test cases If it is confirmed that interoperability testing is required for a given SSP release the list of interoperability test cases in Annex 2 may have to be reviewed modification or deletion of existing test cases and or addition of new ones Users will then be informed via the TARGET2 web site https target2 ecb de about the test cases they will have to run i e mandatory and conditional test c
24. e Annex4_CB_Contacts CBs must provide the SSP service desk with all static data information required The forms can be found on the ECB Website for CBs The registration forms for testing should cover the same functional profile as the one to be filled in for live operations Meaning a functionality that a user intends to request for live operations should also be requested for testing and the required certification tests should be performed beforehand There are a priori no limits on the number of BICs to be registered for testing 10 SWIFT based user only 3 2 Connectivity testing 3 2 1 Scope and aim oT ates Connectivity testing verifies the new Central Participant s Activities Bank and the ability of each of its TARGET2 ae Noo TE internal production users to connect to the different SSP modules tss a that the connecting CB has opted for and 1f applicable to the CB s proprietary systems All SWIFTNet connectivity features necessary to communicate with the SSP need to be checked for the correct set up of parameters and security features By performing this type of activity as early as possible users can reserve time to solve any potential problems related to the underlying services occurring at a later stage which otherwise could delay the start of the following user test phases That cases are defined in a way that 2 all possible communication interfaces between a TARGET2 user and t
25. e cs cosh sal ae E ices nes ead ee eae 24 J Preconditions for starting the interoperability testing cccccccccccccccsscccssccessceesscesssceseeessees 25 3 3 3 List of interoperability test CASES ccccccccccsecccsscccssscssssesssscsssscssssesssscessscssseesssscssasesaecssasessasensas 25 3 4 PUE DAS TE TIN aon T TEE EA TEE 25 3 4 1 LOTE IG a E EEEE E EAEE nant 25 3 4 2 Preconditions for starting Business day testing cccccccccccccccsccccsscccssccesscsessccssscessscessecesseeessees 25 3 4 3 List of Business day TESTING SCCHOTIOS acesta SEE eae 26 3 MMINGELEMENTS mcirdemrieecpisyer er eN Een Aeneae e EENEN OEE E EO ean E Ean E asai 26 3 5 1 Timeline for the connection of a new banking community cccccccccscccsecsssscesseessesssseeseeesees 26 3 5 2 Windows for NEW CONNECTIONS v ccccccccccscccsccsescesscessesesscesseeseesseceseceseesssecesecsseesesceseeeseeenseeeseens 27 4 1 SCOPE OF TESTING RELATED TO CHANGE ON PARTICIPANT SIDE u ceeeceeccccsccccceeceeeeeeessssssseeeess 28 42 GENERAL PRE CONDITIONS cise cece tet ne tees ce EEEE wt AEE E T 28 4 2 1 OHTA OD ceo cee esses EE E E EEA EEEE REENE 28 4 2 2 POOF SOM A sea AA A AAEE AAEE O A EAE 29 4 3 TYPES OF CHANGES AND TESTING PROCESS ASSOCIATED c cccsssssesecececececececscececacacatecacaceravevees 29 4 4 ONIN CV TESEN ca psec stea arcane ase eeeasce N sagatoac nutaveanescecmuaentausaenaeeecananaauaaceate 30 4 4 1 PSY 60 8 201 16 T eR CRE a EE eC ECE TT MR RTE renee eee EA
26. e following e Domestic contingency procedures back up payments from a direct participant or ancillary system delivery of critical payments between the Central Bank and direct participants via agreed contingency channels Central Bank acting on behalf of an Ancillary System e PHA HAM testing including the simulation of a failure of the PHA HAM e SF and RM testing e Billing including the generation of invoices and the application of charges to the relevant accounts e Etc For each banking community the Central Bank will communicate the list of common and specific scenarios as well as the testing calendar for business day tests Common scenarios defined at Eurosystem level will be run on the same days for all communities connected to TARGET2 For some scenarios the Test amp Training environment may be operated in live timing i e operating times similar to those of the production environment The participation of users in the business day testing of its banking community is in principle mandatory Moreover a user from a given banking community may be required to take part in specific scenarios organised in another community in the following cases o The participant is a settlement bank in an ancillary system in this community o The participant has entered into a specific arrangement with banks from the connecting community e g multi addressee access HAM co management virtual account consolidated information 5 5 Timi
27. equivalent T amp T BIC8s will be loaded in the system For instance provided the live BIC BANKCCLLXXX is published in live it is available on CUST together with its equivalent T amp T BIC BANKCCLOXXX However while the published BIC BANKCCLL123 would be available the associated T amp T BANKCCLO123 would not If a user wants to use a T amp T BIC with a branch code e g BANKCCLO123 or a special T amp T BIC e g ZY AACCLOXXX or ZYAACCLO123 it needs to ask its Central Bank to load this specific BIC in the system Upon request Central Banks will provide their users with a list of T amp T BICs to be used for addressing messages to during interoperability or free tests e Usage of test amp training and live BICs in the test messages While only T amp T BICs are allowed in the message header users may use both T amp T and live BICs in the body of the message according to the following table HEADER Receiver 52 53 57 58 BIC T amp T BIC T amp T BIC T amp T BIC T amp T Live BIC BIC T amp T Sender HAM MT202 ve BIC T amp T BIC T amp T BIC T amp T MT103 BICT amp T BIC T amp T BIC T amp T BIC T amp T n a Shape Y Copy a Field 52a is not allowed in incoming messages BIC T amp T BIC T amp T BIC T amp T BIC T amp T BIC T amp T BIC T amp T oe If 56 is present otherwise only BIC T amp T e TARGET Directory for CUST Live BIC BIC T amp T Live BIC n a BIC T amp T Live BIC BIC T amp T
28. est cases These test cases will correspond either to newly introduced items to modified items or to existing items to be covered as non regression tests 5 3 Interoperability testing 5 3 1 Scope and aim Interoperability testing would aim at ensuring os that the ability of each user to participate in TARGET2 and to use all relevat oo n Activities and CB s _ inthe internal production lt functionalities of the SSP modules has not been affected by the SSP release It would al SO V erify th at th e new fe atures h ave b een SE f E tests f environment properly integrated by the participants The definition of the test requirements will take on board the changes introduced by the release content the optional SSP modules used by the community and the optional functionalities chosen by the participants Test cases for interoperability testing will be developed according to the following principles e For critical functions which are available to all TARGET2 users mandatory test cases will be defined Each participant will have to complete them and report results to the national service desk as part of the certification process e For critical functions which are available only to a subset of TARGET2 users conditional test cases will be defined Typically conditional test cases cover features provided by an optional module or additional services offered to participants If appli
29. experienced during testing to its CB reporting of the re certification test results to the CB ensuring the readiness of its associated indirect participants and addressable BICs Whenever applicable the Central Bank is responsible for Oo defining the test requirements applicable to participants making a change to their interface with TARGET2 defining the test planning at country level the set up and maintenance of static and dynamic data for their participants providing a direct contact point for all user testing related questions and support national service desk providing information and support to their participants on a best effort basis monitoring of business activities payment activities liquidity streams profiles monitoring the readiness of their users contingency processing arrangements communicating to their users information on incidents in the SSP and proprietary systems which may impact on the testing progress the evaluation and consolidation of test reports from their users SWIFT based users o Liaising with the SSP service desk as well as with the TARGET2 Test Coordination function at the ECB e g for the organisation of tests involving participants in more than one country 1 2 User testing environment CUST 1 2 1 Purpose The Eurosystem provides participants with a specific user testing environment on the SSP for test amp training purposes CUST CUST may run with a rele
30. he SSP and if applicable between a TARGET2 user and a proprietary system should be covered o all layers below the application level are covered This means the network and security features like encryption and authorisation should be verifiable For instance that includes for SWIFT based users the correct setting up of the TARGET2 Closed User Group CUG and the connectivity required to use the ICM and the exchange of keys for RMA with the SSP For internet based users it includes the certification creation with the Central Bank and the correct setup of the PCs used for TARGET2 and the internet connection completed See User Manual Internet Access for the public key certification published on the TARGET2 Web site on 30 June 2010 However it should be noted that no separate connectivity test cases for SWIFTNet InterAct and FileAct in application to application mode are envisaged 3 2 2 Preconditions for starting the connectivity testing Before the start of connectivity testing the following entry criteria have to be met in addition to those mentioned under chapter 3 1 SWIFT based users e Each SWIFT based user should have the required software for accessing SWIFTNet FIN SWIFTNet FileAct SWIFTNet InterAct and SWIFTNet Browse e RMA must be exchanged between the SWIFT based user according to its profile and the SSP as central institution for CUG PM with TRGTXEP0O for CUG HAM with TRGTXEHO and or CUG CB customers with TRGTXEC0O
31. he composition of a virtual account or consolidated information change in the definition of the wildcard rules 4 2 General pre conditions 4 2 1 Communication When the connecting participant is an ancillary system and the change is related to the settlement process i e change in the procedure the AS shall provide its settlement banks as well as the respective central bank with a test plan and a description of the change A change to the ancillary system profile ASP could be needed which will be updated on the TARGET2 website https target2 ecb de and possibly on the website of the respective CB The publication shall be done early enough to allow settlement banks to be ready on time for the start of the user tests Any other changes within the scope of this document should be communicated to the national service desk of the Central Bank 4 2 2 Registration e SWIFT e ordering for testing E Mssf Reporting sheet In the following cases the user must perform registration updates as explained in the chapter 3 1 2 e Addition or change in the BIC definition e Addition or change of the type of participation e Usage of Application to application A2A e Change in the definition of SWIFT queues e Change in the definition of the routing of files or Interact messages e Change in the SWIFTNet closed user group information e Change in the SWIFTNet browse information SNL definition e TARGET registration When the
32. hen o These participants are settlement banks in an ancillary system s which is connecting to TARGET2 o These participants have entered into a specific arrangement with banks from the connecting community e g multi addressee access HAM co management virtual account consolidated information o The participation of users which are already connected will only be required when fully justified by the necessity to verify the technical and operational readiness of all parties involved 3 5 Timing elements 3 5 1 Timeline for the connection of a new banking community The workload for the connection of a new banking community will depend on a number of factors such as the number and types of participants e g ancillary system HAM or PM account holder the profile of the Central Bank e g with or without PHA with or without optional modules as well as the experience of the participants with the SWIFT services used by the SSP e g majority of actors already using FileAct and InterAct or majority of actors not yet connected to SWIFT Nevertheless some general indications can be given e The completion of all SWIFT and SSP registration for all users and the CB may take up to 4 weeks The CB should register before the registration process of it s banking community takes place e Users shall be given at least two months for completing their connectivity and interoperability tests e tis not expected that Business day tests take more tha
33. ific actors o Considering the limited functionalities offered to multi addressee access addressees only fall under the scope of TARGET2 User Testing for connectivity and interoperability test cases which are applicable for this type of connection o The testing between direct participants and their indirect participants and addressable BICs via direct participants is a matter for the direct participants and is not part of the TARGET2 User Testing as such o Tests with the Proprietary Home Accounting system PHA are only envisaged to the extent the PHA is used to provide liquidity to the RTGS account For further details on other PHA testing requirements please refer to your Central Bank CB see Annex4_CB_Contacts 1 1 3 Roles and responsibilities in TARGET2 user testing Whenever applicable the participant is responsible for oO oO oO informing the CB in good time about its wish to connect to TARGET2 informing the CB in good time about any change made to its TARGET2 interface which may impact on its interaction with the SSP updating the SWIFT registration for the respective closed user groups e ordering see 2 1 initiate the exchange of RMA see 3 2 filling in the TARGET 2 registration forms and submitting them to its central bank see 2 2 updating the definition of RBAC roles assigned to users planning preparing and performing testing activities in a timely manner reporting any incidents
34. ing new or modification of the E Mssf process are subject to connectivity testing SWIFT based user e Addition or change in the BIC definition for TARGET e Addition or change of the type of participation e Usage of Application to application A2A e Change in the definition of SWIFT queues e Change in the definition of the routing for Store and Forward services e Change in the definition of the routing for real time services e Change in the SWIFTNet closed user group information e Change in the SWIFTNet browse information SNL definition e Changes in the SWIFT infrastructure including new message standards new version of the CBT and or new version of the SWIFTNet browser SWIFT Alliance Gateway or Web platform for SWIFT based users Internet based user e Addition or change in the BIC definition for TARGET e Addition or change of the type of participation e Changes in the infrastructure used to connect as Internet based users local security policy network changes changes in the hardware software used for authentication 4 5 Interoperability testing 4 5 1 Scope and aim Interoperability testing after a change on the user infrastructure should ensure that the existing participant can still interact with TARGET2 by using all relevant functionalities of the SSP modules and if applicable in the CB s respective proprietary system 4 5 2 Pre conditions for starting the Interoperability testing Connectivity
35. ion of the monthly BIC Directory This rule avoids introducing undue discrepancies between the BIC Directory and the TARGET2 Directory Empirically it is expected that the connection of a new banking community will coincide with its adoption of the Euro and takes place on the first business day of the year Regardless of the calendar adopted for the new connection all TARGET participants will be informed in due time via the TARGET2 or the via ECB website 4 CHANGES ON PARTICIPANT S SIDE Credit institutions or ancillary systems already connected to TARGET2 which want to proceed with a change either in a component of their infrastructure or in their use of TARGET2 services are subject to test requirements Beside some general pre conditions applicable to specific cases see below participants that want to implement changes are expected to run relevant connectivity and interoperability scenarios adapted to their change Participant s Activities and CB s _ inthe internal production tests environment TARGET2 User Testing for participants with change 4 1 Scope of testing related to change on participant side This chapter refers to changes on the participant side that may impact on its interaction with the SSP This document does not refer to the following type of changes connection of indirect participants change in the composition for a multi addressee participant change in t
36. m the user describing the intended usage of the account reduce the test requirements accordingly In the cases listed above the user needs to contact its respective Central Bank in good time and to provide all relevant information supporting the request It is the responsibility of the Central Bank to assess the validity of the request and to grant the simplification 1 3 3 Set up of the test environment on the user s side The test environment on the user s side should be as similar as possible to the future live environment Furthermore before starting any phase of the TARGET2 User Testing it is expected that the user Carries out extensive internal tests to reduce the risk of failure during the certification steps The respective Central Bank must be informed in writing about any changes in the test environment of the user during or after the certification testing That includes specifically the use of optional functions which were not used in the past and therefore not part of a previous certification process Besides clearly describing the nature and scope of the change and the associated risks this information should contain a proposal with regard to the test cases to be re run due to the change non regression testing The Central Bank will assess the proposal made 1 3 4 Central Bank support Upon request each Central Bank will offer the necessary training for the preparation of its users before the start of te
37. n 2 months e A freezing period of one month before the connection to TARGET2 is recommended The following graphs provide an overview of the different registration and testing steps and an indication of their maximum duration 1 CB Registration phase and technical readiness SWIFT queues E Mssf registration to SWIFT sent CB registration Treatment E Mssf by SWIFT and SSP OT Treatment by SWIFT and SSP OT sent to configuration SSP OT request 2 1 SWIFT based user registration phase and technical readiness SWIFT queues E Mssf registration to SWIFT sent Treatment by CB SWIFT and SSP OT Treatment E Mssf by SWIFT and SSP OT User registration sent to configuration SSP OT request Week 9 11 2 2 Internet based user registration phase and technical readiness User Treatment by CB Technical registration and SSP OT readiness sent to CB Week 7 11 Week 12 3 Testing phases by the Central Bank and its users Connectivity Interoperability Business day Frozen period testing testing before go live testing Week 13 14 Week 15 20 Week 21to 28 3 5 2 Windows for new connections Week 29 to 32 Activation queues and local configuration Activation queues and local configuration Week 12 Technically speaking the connection of a new banking community may take place at the start of each month more precisely on each Monday following the activat
38. nctionalities chosen by the participant affect the overall number of test cases to be performed Test cases for interoperability testing are developed according to the following principles e The TARGET2 users should be able to verify all functions implemented in terms of hardware software which are part of the user s interfaces with T2 Testing of proprietary systems should be included in addition to the SSP modules e For critical functions applicable to all TARGET2 users e g payment processing cancellation of payments mandatory test cases are defined which each participant has to complete and report on to the national service desk as part of the certification process e For critical functions which are applicable only to a subset of TARGET2 users conditional test cases are defined Typically conditional test cases cover features provided by an optional module e g HAM or additional services offered to participants e g liquidity pooling If applicable to the participant a conditional test case becomes mandatory and the test results must be reported as part of its certification process Otherwise the participant does not have to run it Users connecting to the ICM server in application to application A2A mode should test the respective functionality both in user to application U2A and A2A mode The test cases are always described according to the U2A approach using ICM but contain a reference to the respective XM
39. ness day 1 day buffer Week 9 10 10 11 2 5 2 Windows for new connections In principle certified users will be given the possibility to connect to TARGET2 once a month more precisely on each Monday following the activation of the monthly BIC Directory please refer to www swift com for the timetable of BIC directory updates This rule avoids introducing undue discrepancies between the BIC Directory and the TARGET2 Directory Nevertheless the Central Banks may grant exceptions whenever strongly justified 3 CONNECTION OF A NEW BANKING COMMUNITY A new national banking community which wants to connect to TARGET2 is subject to the test requirements summarised in this chapter The most likely business case for such a connection is when the country joins the EMU All participants from this banking community need to undergo the connectivity and interoperability scenarios adapted to their future usage of the SSP before multilateral tests are organised at country level or even TARGET2 wide occ COCO COCO CECT a WEST ES OOOO eer e errr re err rre tier ererr reer rrrry Participan re Activities and CB s _ inthe internal production tests environment TARGET2 User testing for new a banking community 3 1 General preconditions 3 1 1 Communication The connecting Central Bank shall publicly announce its plan for the connection as well as the envisaged profile i e adoption of optional modules e
40. ng elements The workload for the testing in the event of changes on the SSP side will largely depend on the release content Nevertheless some general indications can be given for a normal yearly release e Test scenarios shall be communicated early April on the TARGET2_ website https target2 ecb de e In the event that connectivity and or interoperability tests are required users shall be given at least 4 weeks for completing them e For business day testing scenarios different days should be foreseen in a window from 2 to 4 weeks The test scenarios shall be communicated at least one month before the start of the testing phase e Weeks foreseen to run in future mode should be included in the test planning in order to ensure user testing with the new SWIFT release same implementation date like SSP standard release e A freezing period of at least two weeks before the go live of the new SSP release is recommended A testing schedule for all testing weeks is always established well in advance before the installation of the SSP release in CUST environment Yearly release schema for testing schedule New Connectivity and Business day Frozen period certified Interoperability testing testing Go live new nee Week Week Week Week Week Week Week Week release available 1 7 3 4 5 6 7 8 7 Overlapping might be proposed for more flexibility
41. of the Business day testing The following changes brought by a participant should trigger new organisation of Business day testing e Change of procedure for the Ancillary system re testing by the Ancillary system and its settlement banks e Change in the Ancillary system application e Change in the Domestic contingency procedures e Use of new functionalities in TARGET 4 7 Timing elements The workload for re certifying a participant will depend on the nature of the change It will be up to the Central Bank to evaluate the timeline necessary for the testing window 5 CHANGES ON THE SSP SIDE In the event that changes are made on the SSP side participants may be required to test to check that these changes did not affect their interface with the platform Such changes may either be scheduled a long time in advance e g SSP new and intermediary releases or at short notice e g for hot fixes While the test procedures in case of a hot fix will follow an ad hoc certification procedure the present chapter mainly focuses on the general case of fully fledged yearly SSP releases Depending on the content of the release participants will be asked to carry out connectivity and or interoperability and or business day tests The present chapter does not cover the changes that a new SSP release may trigger on Central Banks proprietary applications e g PHA OCC ECO CCC CCC CCC CCC CC i enn ee Wr PEPE ee errr er errs
42. onnecting participant is an ancillary system it shall provide its future settlement banks with a tentative plan and a description of the type of connection envisaged i e PM vs ASI settlement model and associated options in case the ASI is chosen This will take the form of an Ancillary System Profile ASP which will be published on the TARGET2 website https target2 ecb de and possibly on the website of the respective CB The publication shall be done early enough to allow settlement banks to get ready on time for the start of the user tests 2 1 2 Registration Users must undergo the following registration processes before they can participate in User Testing e SWIFT e ordering for testing SWIFT based users only SWIFT based user only DOODOOOOOOOGIIEOOOOnn EG iEonnnnnni thon nnn innnnnnnnnn nnn nnn nnn wnt oring DO DT TS a OE ee KAEA SE Sey yy Cr Sry ry ay rats PSE EE EEEE ELE OEE Oye Coy ey ey LS TOOL LOVEE LOLeyoL Sy Ty yoy eye y oy ey ed Reporting sheet Soeanancncnce ancnaa cnet on cect eA EAA AA ERAN ATLANTA EN PER nnnnnnanannanA nannan nnnnana nnn DNTa nnn annn nT annann nn nnn n a Workflow for SWIFT e ordering Click here on E Ordering for further information on the e ordering process for testing e TARGET2 SSP registration for testing The user must provide its national service desk with all static data information required Please contact your CB for the respective forms see Annex4_
43. osystem documentation Preparation to the Go Live for connecting Central Bank or for connecting new participants GUIDE FOR TARGET2 USER TESTING Table of contents E O OE Ged BU E T re rr Os PU E A OUP pe 6 1 1 SCOPE OF TARGE T2 USER TESTING siorrraireiiirirneike nino AEEA aca AEE A ARAETA E 6 1 1 1 Types of changes taken ON DOA cccccccccccsccccsscccsscsesseeeseseseesessecsseesessessssesesecessseessesessecessseesaees 6 1 42 Parnes TV OIE separi a Ea Suctsea i atone 6 1 1 3 Roles and responsibilities in TARGET 2 user testing ccccccccccccsccccssccessceessceesseessscessseessseessees 7 I2 USER TESTING ENVIRONMENT CUS T cosscscessessscsccassnczvasacnsatepaandavssseeeesnanessecersdueabadanssevoinentansgannseess 8 Led PDO O EE E EA E E E TEE A T A EA 8 1 2 2 ATD specssesdica ce A E E TE 8 1 2 3 V lume AIA ATION saiisine a a aia adai ii 9 1 2 4 SEES a EE E EE E E E E S E E E EE 10 L3 GENERAL ORGANISATION OF CERTIFICATION ACTIVITIES 0 cccccccccsssccsscccssssesssssssecesssesseeseeees 11 La Phases of TARGE 2 User TeS UNE miren cases cite case cuecayeundebn aon eetneeedcncckee 11 L32 Possible simplification of test rEQUITCMENTES ccccccccccssccessccesscsescsessesessessseeesseeessecesseeesees 11 1 3 3 Set up of the test environment on the user s side cccccccccccsscccssccessceessceesseessecssseeessecesseeessees 12 1 3 4 CCHIT IN SU O aE E E E E AE E O E EE eee 12 1 3 5 In ident MandgeMehi sassiacasisacowsnssaras
44. registration of already connected participants For instance when new static data has to be handled or when a new optional service is offered In such cases Central Banks would issue a new set of SSP forms and would provide further instruction on how and when these forms should be completed by participants 5 2 Connectivity testing 5 2 1 Scope and aim Connectivity testing would aim at verifying that the ability of TARGET2 users to connect to the Participant s Activities s andCB s sin the SSP has not been affected by the new SSP intemal V producion y tests environment release It is expected that this step could be superfluous unless the SSP release introduces changes to the technical communication layer 5 2 2 Preconditions for starting the connectivity testing In the event that the SWIFT or SSP registration had to be modified participants must receive confirmation that the required modifications were implemented before commencing the connectivity testing 5 2 3 List of connectivity test cases If it is confirmed that connectivity testing is required for an SSP release the list of connectivity test cases in Annex 1 may have to be reviewed modification or deletion of existing test cases and or addition of new ones Users will then be informed early April and via the TARGET2 web site https target2 ecb de about the test cases they will have to run i e mandatory and conditional t
45. ser test environment These limits apply per direct participant or per ancillary system The volumes requiring approval from the CB per user and hour are a more than 60 FIN messages to be sent and or a more than 30 XML messages SWIFTNet InterAct in A2A mode to be sent by the user Users intending to exceed any of these limits e g for volume testing must send a request to the national service desk of their CB at least one week in advance The request should contain the expected volumes to be tested hourly volumes for each of the categories mentioned above and the expected duration of the test The national service desk will verify with the SSP service desk whether the requested volumes can be processed Consecutively the national service desk will inform the user via e mail whether the testing can be performed as scheduled or whether any modifications in terms of date time and or volumes are required High volume tests of 20 000 FIN messages and more need also to be addressed to SWIFT 4 weeks in advance SWIFT TIP 2008531 on Fridays limited to 16h00 17h00 t on Fridays starting at 17 00 This explicitly includes the Free Testing phase 1 2 4 Management of BICs e Available BICs in CUST SWIFT does not provide a BIC Directory in T amp T Therefore a specific BIC directory had to be created and loaded in CUST for the purpose of user testing This directory includes all published live BICs as well as all
46. smart card s with the local Central Bank should be completed See User Manual Internet Access for the public key certification published on the TARGET2 Web site on 30 June 2010 for backup payments i V Copy applies 2 2 3 List of connectivity test cases The detailed test case descriptions can be found in Annex1 Whenever PHA systems are used participants are invited to refer to the respective national testing documentation for details on how the connectivity tests with the PHA can be performed see Annex4_CB_ Contacts 2 3 Interoperability testing 2 3 1 Scope and aim Interoperability testing ensures that the future user can participate in TARGET2 by using all relevant functionalities of the SSP modules and if applicable in the CB s respective proprietary systems All future TARGET users should be able to send and receive correctly formatted information A different set of test cases is assigned to the user depending on its user profile direct participant CB customer HAM account holder Ancillary system The optional SSP modules chosen by the respective CB and the optional functionalities chosen by the participant affect the overall number of test cases to be performed Test cases for interoperability testing are developed according to the following 7 Activities inthe production lt environment Participant s principles andCB s internal tests f e The TARGET users should
47. ss type SWIFT or Internet based For SWIFT based users their experience with the SWIFT services used by the SSP e g participant already using FileAct and InterAct participant not yet connected to SWIFT will also influence the time for his certification Nevertheless some general indications can be given e The completion of all required SSP and SWIFT registrations takes around 5 weeks for SWIFT based and Internet based users e Provided the participant has extensively tested its new interface in free testing mode connectivity tests can be completed within a day and interoperability tests can be completed within 2 weeks e Although the Business day tests may differ from country to country it is expected that their completion would not take more than 2 weeks The following tables provide an overview of the different registration and testing steps and an indication of their duration 1 Registration of SWIFT based user User Treatment E Mssf Treatment by CB SWIFT SWIFT Activation registration sent by CB and registration and SSP OT queues queue and local to SSP OT SSP OT sent configuration configuration request Week 1 2 Week 3 5 2 Registration of Internet based user Internet Treatment by SSP OT and Central Bank registration senttoCB Week Week Week Week Week 1 2 3 4 3 3 Testing phases by the participants SWIFT and Internet based Connectivity testing Interoperability testing Busi
48. sting activities This may cover inter alia the organisational aspects of the user testing as well as ICM training For details please refer to the specific information accessible via the TARGET2 website of your Central Bank see Annex4_CB_Contacts 1 3 5 Incident Management The participant should report any incident experienced while testing which may be related to a malfunction of the SSP or a proprietary system to the respective national service desk Depending on the nature of the problem the national service desk will investigate and solve the problem or will transfer the matter internally to the SSP service desk The national service desk will keep the users informed via adequate means about any incidents in the SSP or proprietary systems which may affect its testing activities 1 3 6 Reporting on test result With the exception of free testing users must report on the outcome of all their certification tests directly to their respective Central Banks via the national service desks Also test cases which cannot be performed or continuously fail should be reported For further information on the forms and communication means please refer to the specific information accessible via the TARGET2 website of your Central Bank see Annex4_CB_Contacts Upon reception of the test report the Central Bank will verify the outcome of the reported test and will notify the user accordingly 1 4 Free testing Participant s 1
49. tems the local contingency arrangements and the domestic settlement of ancillary systems In some circumstances the participation of already connected participants from banking communities may be required 3 4 2 Preconditions for starting Business day testing All users belonging to the national user community together with the connecting CB must successfully complete the required interoperability certification tests before the start of the Business day testing 3 4 3 List of Business day testing scenarios Business day test scenarios are prepared and carried out under the responsibility of the connecting CB and shall cover at least the following test items e Domestic part of the settlement procedure of ancillary systems in normal and contingency mode i e CB acting on behalf of the AS e PHA HAM testing if applicable including the simulation of a failure of the PHA HAM e Billing including the generation of invoices and the application of charges to the relevant accounts e Domestic contingency procedures failure back up payments of a direct participant or domestic ancillary system delivery of critical payments between the CB and direct participant via agreed contingency channels CB acting on behalf of an AS e Changeover activities if and when applicable The participation of users which are already connected in other banking communities may be envisaged in specific scenarios This is in particular the case w
50. xistence of proprietary systems This will take the form of a National Migration Profile NMP which will be published on the TARGET2 website https target2 ecb de and possibly on the website of the connecting CB The announcement shall be done early enough to allow future participants to get ready on time for the start of the user tests Additionally for each ancillary system connecting to TARGET2 a description of the type of connection will be made available to settlement banks i e PM vs ASI settlement model and associated options in case the ASI is chosen This will take the form of an Ancillary System Profile ASP which will be published on the TARGET2 website https target2 ecb de and possibly on the website of the connecting CB The publication shall be done early enough to allow settlement banks to get ready on time for the start of the user tests 3 1 2 Registration The connecting Central Bank as well as the future users of the National Banking Community must undergo the following registration processes before User Testing can start e SWIFT e ordering for testing oring Reporting sheet Workflow for SWIFT e ordering Click here on E Ordering link for further information on the e ordering process for testing e TARGET2 SSP registration for testing The future user must provide the national service desk with all static data information required Please contact your CB for the respective forms se
51. y testing 2 4 3 List of Business day scenarios This phase focuses on Business day test scenarios which are prepared and carried out under the responsibility of the respective Central Bank and cover at least the following test items e Domestic part of the settlement procedure of ancillary systems in normal and contingency CB acting on behalf of the AS mode e PHA HAM testing if applicable including the simulation of a failure of the PHA HAM e Billing including the generation of invoices and the application of charges to the relevant accounts updated for each yearly release of the SSP e Domestic contingency procedures failure back up payments of a direct participant or domestic ancillary system delivery of critical payments between the CB and direct participant via agreed contingency channels CB acting on behalf of an AS using ASI If need be the participation of already connected participants may be foreseen for instance in case the newly connecting participant is an ancillary system or in case a high number of new participants are connecting to TARGET2 2 5 Timing elements 2 5 1 Timeline for the certification of a new participant The workload for certifying a new participant will depend on a number of factors such as the type of participation e g ancillary system HAM or PM account holder the profile of the Central Bank e g with or without PHA with or without optional modules as well as the acce
Download Pdf Manuals
Related Search