Validation XBRL
Contents
1. Report and get feedback TEY C KO s Ms 0 Mm E Partici xx wees pants am Sectorial report 00 Consultation request reply vu J the choice to oth JJ Prudential control icipants to use either a fully 4 int A2A a many figure 2 A2A The A2A entry point is useful for participants that will fully automate the reporting process This entry point is based on web service calls Sending a report via this entry point is a 3 step process Each step corresponds to a web service method 1 Send the report and receive an acknowledgement TicketId 2 Retrieve the list of available feedback files This list contains identifications of the feedback files 3 For each feedback file identifier retrieve the specific feedback file U2A The U2A entry point is a web interface It allows manual data entry in forms This is an option for participants who have a limited data to report Alternatively the web interface also allows the manual upload of a XML reporting file Participants whose systems generate XML files in the correct format but who do not wish to invest in automated web service calls can use this as an intermediary solution Through the web interface the user can get an overview of the reporting status and consult the details of each report The history of exchanged reports and their associated feedback files can be visualized and downloaded Page2. post Authorization Authorization confirms the user credentials and determines if the service requestor is entitled to perform the operation which can range from invoking a service to executing a certain part of its functionality Only authorized and authenticated users will be able to access the system and only with the privileges assigned to them according to their user profile The privileges will be assigned according to e the user certificate for A2A and U2A functions e the user workgroup for internal functions In order to access the application with a class 3 certificate the certificate needs to be known by the system and given the required authorisations A certificate registration procedure will be available to request the required authorisation as explained in Error eference source not found Signing Non repudiation Non repudiation guarantees the message sender s identity i e that the message sender is the same as the creator of the message The non repudiation is not required for CKO2 which means that messages will not be digitally signed Should it be required later for some reason it is good to know that signing is a basic feature of OneGate Backup NBB centralized backup solution will be used All messages exchanged between the participants and the system will be included in the backup procedure 2 8 Access procedures to OneGate CSSR and CKO2 and authorizations The registration procedure implements the authori
3. e the production and sending of sectoral and geographical statistics based on data warehouse tools e the production and sending of results from data checks based on data warehouse tools Moreover CKO2 will register process store and deliver some new data aimed at helping the stakeholders to better assess the credit risks linked to the debtors The conversion from CKO1 to CKO2 requires a period of tests and just after the go live of the application the load of all debtors identification data 1 6 Business context Since 2000 participants have expressed their needs to improve the current CKO2 system CKO1 mainly by allowing data exchange over the network and online consultation The NBB has also been in favour of an enhanced IT application for a few years as CKO has become an assembly of several applications and components due to the need to cope with important updates of its system and to comply with the evolution of the IT Therefore several proposals have been made to renew the application content and functions but without coming to an agreement In the near future the CCCR will have to bear important costs in order to cover a technical upgrade of an essential software called VAGen that will not be supported anymore by IBM To avoid these costs that do not provide any functional advantages for the system or the participants it is strongly recommended to plan the go live of CKO2 as close as possible to the end of the VAGen lifecycle To
4. available feedbacks and then for each of the feedbacks identified in that list the web service feedbackRequest to get each time one feedback file Because the list of identifiers contains also the ticketIDs the user can choose to get only the feedbacks related to 1 reporting file Brief descriptions of these 3 OneGate web services Detailed descriptions of these web services can be found in document Ref 2 The web service uploadFile Function uploads a report file to OneGate Input o the upload file which contains the report encryption not required for CKO2 signing not required for CKO2 zipping recommanded validation against XML schema prior to the upload recommanded o optional filename of the upload file Output o TicketID to identify the file upload uniquely acknowledgement The web service feedbackListRequest Function requests the list of feedback identifiers available Restrictions se Only the identifier of the feedback associated with a file sent by this technical user will be sent back The feedback associated with files sent by another user but for a common declarer will not be sent back You can choose between requesting a list of the identifiers of the feedback o that the user has never requested read or o those that you have already requested read during a specified timeframe The second option offers the possibility to request a feedback that was retrieved earlier Output The list con
5. file exchange log Page 15 of 25 e consultation of the incoming messages and the linked attachments containing the feedback and output files in attachments e consultation of the outgoing messages e view the content of the reporting feedback and output files These functions will be described in a specific OneGate document ref 2 Page 16 of 25 2 5 Overview of components channels and format Input channels Communication INPUT channel between CCCR and participants Reporting declarations credits debtors possible CCCR applications 2 a Ss SSS SSL via OneGate interactive via asynchronous OneGate Interactive input via browser data entry via screen webapplication U2A interactive upload of XML file generic OneGate XML possible channels using OneGate webservices input parameter 1 uploadfile generic OneGate XML A2A Table 3 Page 17 of 25 Output Channels Communication OUTPUT channel between CCCR and participants a ee eee output monthly feedback retour automatique CCCR specific XML possible CCCR applications output directories credits of a participant per debtor for subscribers CCCR specific XML output results of monthly checks PDF XLS interactive via online view of the content of the feedbackfiles will be possible XML will be OneGate converted to HTML webapplication x U2A interactive download of OneGate message to participant with feedbackfile outputf
6. for the last 12 ends of month So from then on the database of the new CKO2 will contain the reported credit situations of the debtors for 12 ends of months Page 24 of 25 3 GLOSSARY DEFINITION OF TERMS AND ABBREVIATIONS Definition of terms Systems Integrator SI or abbreviated Integrator An individual or company that specializes in building complete computer systems by putting together components from different vendors Unlike software developers systems integrators typically do not produce any original code Instead they enable a company to use off the shelf hardware and software packages to meet the company s computing needs Third party declarer A company that delivers reporting services to one or more participants These services can be create report send the reporting process the feedback follow up of the reporting processes etc Gateway telecommunications A computer or a network that allows or controls access to another computer or network Gateway computer program A link between two computer programs allowing them to share information and bypass certain protocols on a host computer Abbreviation Description CKO2 Central Corporate Credit Register CKO Centrale voor Kredieten aan Ondernemingen Dutch for CKO2 CCE Centrale des cr dits aux entreprises French for CKO2 CKO2 Current project for renewal of the IT application and the database content of the CCCR A2A Application to Application CSSR Central Statistica
7. minimize the efforts and costs in development and maintenance it was decided to re use the functions reporting validations feedback security high availability high volumes zipping messaging broadcasting U2A and A2A of the OneGate CSSR generic reporting application which is currently rewritten soon the first reporting will be done in production The old CSSR application is currently already used by the old CKO2 application also called CKO1 1 7 References Ref ID Author Title 1 CKO2 P Bissot CKO2 Specifications for participant institutions 2 CKO2 C Van Puyvelde OneGate CSSR Web Services End User Manual 3 OneGate L Van Belle OneGate CSSR Manuel d utilisation pour le d clarant 1 8 Overview and evolution of the document This document is intended to define the technical requirements to communicate with the new CKO2 application Nevertheless it is only the first version of the document to be used by the reporting institutions to begin the first phases of their development define technical and non functional requirements and define architecture and required infrastructure as it could still be subject to some modifications in the course of the detailed analysis by the development team in the NBB Page 4 of 25 Section 2 describes the technical ways in which the participants will be able to communicate with the CKO2 application with all the possibilities e g fully automatic or manual communication requir
8. the 2 periods e else the available 1 or 2 credit situation s of the debtor will be available in the reply B if the debtor can t be uniquely identified with certainty e g homonyms Iy 2 Comments on A2A As described the parallelism between the U2A and A2A solution is not 100 O no credit situations debtor data e if U2A consultation via browser o additional id data of all the debtors found in the CKO2 database o the inquirer is invited to introduce a new query with selection criteria corresponding to only one debtor e if A2A web service getOneDebtorsCredits o return status flag indicating that more than 1 debtor in the CKO2 database corresponds to the selection criteria o to obtain additional id data of all the debtors found in the CKO2 database a second web service getMultipleDebtors will be available See description in next paragraph the web service getOneDebtorsCredits does exactly the same as the U2A solution in all cases except when more than 1 debtor is found but in case more than 1 debtor is found a second web service will be available to get automatically the additional debtor identification data Because the target of this single consultation is one debtor the possibility that the input identifies more than 1 debtor is just an exception that complicates the output structure and processing To respect design guidelines for web services keep it simple and separate functions not but 2 web services
9. the same CKO2 specifications test environment and support to all participants and integrators and e at the same moment 2 14 4 Initial loading The debtor identification data present in CKO1 will not be transferred to the new CKO2 database many participants prefer a scenario where the new CKO2 application starts from scratch and so the participants will then need to supply the CKO2 with data on all debtors and their credits The initial load of debtors debtor checks and matching with KBO and the NRNP could take some time so an initial loading planning has to be established The credit data on new debtors relating to periods preceding entry into production will not have to be reported by participants in order to limit the initial loading operations The debtor credit data already present in CKO1 will not be transferred to CKO2 either Therefore inquiries on the data base will only make sense after the reporting in the beginning of the first month after the entry into production of CKO2 2 14 5 Database contains credit situation for a number of reporting dates The participants will have to report not only for the last period end of previous month but sometimes in case of delays or mistake also for a number of preceding months reporting dates in the new CKO2 If the number of months will be one at the start of the new CKO2 it will increase month after month until this number is 12 cf 2 14 4 From then on the participant can report
10. 2 However the test environment will still be available after that date and regularly cleaned e g every 3 months Testing environment An environment for integration testing will be available e from 1 12 2010 for monthly reporting and feedback e from 1 2 2011 for consultations and outputs monthly feedback directories geographical and sectoral statistics checks Participants interested in stress testing load tests volume tests or other testing requirements are invited to communicate their specific testing requirements so arrangements can be made in time A2A Tools like SOAPUI user interface and Curl both available for free on the internet allow testing and automation of web service calls in a relatively easy way This can be done manually for testing and gradually evolve to an automated solution 2 14 Special topics 2 14 1 Linking feedbacks to their reports When uploading reporting files with U2A or A2A a ticketID will be returned to the sender acknowledgement When the participants system will later request the list of available feedbacks the ticketID will be present in the list so the participant can link the feedback to his reporting file provided the participant stores the ticketID received at upload until the feedback is fetched Maybe it will be possible to add a participant s reference to the reports and consultation requests In that case the participant will be able to link the feedbacks and consultat
11. 9 of 25 Validation As shown in the figure above Onegate is a buffer between the participants and the actual CKO2 application The reports will be received validated and stored by Onegate Onegate performs security checks and does a form validation XML schema and logistics checks In case of U2A data entry Onegate will perform the form validation immediately and the errors will be visible in the online form Additional business validations will be done by the CKO2 application The result of the CKO2 validation will also be available in a feedback file associated with the report In case of manual XML file upload or A2A report these feedback files will be associated to the report and can be consulted using the A2A channel or through the web interface A nightly transfer procedure will forward the reports concerning credits from Onegate to the CKO2 application for further processing and business validation CKO2 will produce at least one feedback report for the declaration This means that several feedback reports could be generated for a single declaration The CKO2 application will indicate by means of an end of feedback flag that the validation of the report is complete and no further feedback reports will follow The declarer will need to take the initiative to retrieve the feedback reports until an end of feedback is received Both the Onegate and the CKO2 feedback reports will be retrieved from the same Onegate entry poin
12. CKO2 Technical specifications for participant institutions Status Draft English version Authors W Braem and L D haese Reviewers P Bissot V Hendrichs participant institutions Document version 1 0 Date 30 11 2009 N National OF BELGIUM Page 1 of 25 TABLE OF CONTENTS 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 2 1 22 23 2 4 25 2 6 2 7 2 8 2 9 2 10 2 11 2 12 2 13 2 14 INTRODUCTION DOCUMENT HISTORY CONTENT OF DOCUMENT PURPOSE OF DOCUMENT PURPOSE OF DEVELOPMENT SCOPE OF DEVELOPMENT BUSINESS CONTEXT REFERENCES OVERVIEW AND EVOLUTION OF THE DOCUMENT GENERAL DESCRIPTION NEW CKO2 GENERAL FUNCTIONS COMMUNICATION CHANNELS AND ACTORS ONEGATE CSSR AS A MAJOR INTERFACE TO THE CKO2 APPLICATION DIRECT ACCESS CHANNELS TO THE CKO2 APPLICATION BUSINESS SCENARIOS PER COMPONENT AND PER CHANNEL OVERVIEW OF COMPONENTS CHANNELS AND FORMATS VOLUMES SECURITY ACCESS PROCEDURES TO ONEGATE CSSR AND CKO2 AND AUTHORIZATIONS AVAILABILITY AND SUPPORT FORMATS DESCRIPTION OF THE INTERFACES OF THE PARTICIPANTS WITH ONEGATE AND CKO2 OVERVIEW TECHNICAL ASPECTS TESTING SPECIAL TOPICS 2 14 1 LINKING FEEDBACKS TO THEIR REPORTS 2 14 2 THIRD PARTY DECLARER 2 14 3 INTEGRATORS AND GATEWAY 2 14 4 INITIAL LOADING 2 14 5 DATABASE CONTAINS CREDITSITUATION FOR A NUMBER OF REPORTING DATES GLOSSARY DEFINITION OF TERMS AND ABBREVIATIONS Page 2 of 25 1 INTRODUCTION 1 1 Document history Date Ver Autho
13. alled CKO2 that e allows the financial institutions to better assess risks when providing their financial services e helps the Banking Finance and Insurance Commission CBFA to control credit institutions by providing information on the risks they run provides the NBB with data necessary to develop risk assessment tools aiming at giving additional information to the financial institutions on the risks they run and to the NBB for financial stability purposes and for credit risk assessment of the bank loans used by credit institutions as collateral of monetary policy operations e exchanges data with European central credit registers in accordance with the Memorandum of Understanding MoU ratified by the governors of the European central banks The IT department of the NBB took advantage of the opportunity to start from scratch to redesign the architecture and renew the infrastructure From the point of view of the participants the result is a central CKO2 application database maintained by the participants reports and delivering the required replies to consultations and outputs through online browser based web applications and web services Page 3 of 25 1 5 Scope of development The scope of the new system includes the same functions as CKO 1 e e the collection of granted credits e the consultation of the reported credits e the creation and sending of several outputs e back office functions for managing and monitoring the system
14. ance of a system integrator SI which might implement a Gateway cf Glossary to the CKO2 The costs of the development of such a Gateway can be shared by interested participants The access to these web applications and web services will be limited to the CKO2 participants NBB CKO2 back office Composition of the application The CKO2 application can be divided in the following components with specific functions e the participants have to report declare on debtors and credits and get feedback validations e they can send requests for consultations and get the answer in the reply e they can fetch the outputs made available by the CKO2 application oto all participants the results of the monthly checks of the quality and consistency of the data o only to subscribing participants monthly feedback directories repertories and geographical and sectoral statistics A detailed description of these components and the roles of actors stakeholders can be found in document ref 1 often open source freeware Page 7 of 25 2 2 QONEGATE CSSR as a major interface to the CKO2 application General description Onegate CSSR is the successor of CSSR Onegate is the central reporting channel for many of the reports exchanged between external actors and the NBB CSSR is used for the reporting for several business domains and many institutions are using ONEGATE as a communication channel Onegate offers a set of functions that are reused i
15. c for this CKO2 application The XML schema to describe and validate these specific XML format will be available to the participants as soon as possible PDF and XLS The geographical and sectoral statistics and results of monthly checks will be available in PDF and XLS format Page 20 of 25 2 11 Description of the interfaces of the participants with OneGate CSSR and CKO2 A2A OneGate A general description of these web services is available in the document Ref 2 OneGate CSSR Web Services End User Manual A more detailed description including the WSDL and the generic OneGate XML schema will follow later U2A OneGate U2A A general description of the OneGate online application will be soon available in the document Ref 3 One Gate CSSR Manuel d utilisation pour le d clarant A2A and U2A CKO2 This is limited to the CKO2 component Single consultation of 1 debtor and a general description is given in 2 4 2 Page 21 of 25 2 12 Overview technical aspects A general overview of the technical aspects for both A2A and U2A can be found in next figure CKO2 Technical CKO2 via CRS direct with CKO2 specifications and interactive sae aa using CRS CKO2 CKO2 webservices architecture Pue d webservices or https webapplications for for consultations requests A2A consultations U2A A2A data entry The payload can be The payload can be included in a SOAP included in a SOAP request web service req
16. d number of Certification Authorities accepted cf Security and will allow the participant s collaborators logon into a CKO2 webapplication for interactive data entry of the selection criteria and get immediately the results of the query displayed in the screenform of the browser A2A The CKO2 web service getOneDebtorsCredits will be available to allow the participants systems to send an XML request with the selection criteria and get immediately synchronous communication the XML reply with the results of the query Exception In case getOneDebtorsCredits reports that more than debtor corresponds to the selection criteria the participants system technical user can call the web service getMultipleDebtors to request the debtor identification data of these debtors It is only an option to process this exception this way Exchanged data of U2A consultation with browser and A2A web service getOneDebtorsCredits e request input gt request reference reference of the participant can be used for troubleshooting etc Optional and only present in case of A2A web service selection criteria gt debtor identification identifier s of one debtor by passing a unique identifier e g enterprise number KBO BCE or other identifiers e g name postcode birth date which identify the debtor almost uniquely gt 2 ends of months also called periods to be chosen by the participant from 11 complete monthly cred
17. debtors credits o during the data entry the ONEGATE validations are shown immediately in the input forms and these errors can be corrected o OneGate CSSR indicates when the ONEGATE accepts the input But the validation process has not ended yet During the day the CKO2 application regularly validates and processes the incoming debtor reports The credit reports will be processed only during a nightly procedure so these validation files can only be expected in the morning next day The feedback files will be available in the ONEGATE control panel more precisely as attachments of incoming messages from the CKO2 application to the participant ONEGATE declarer The content of the feedback files can be opened and the validation results will be readable HTML format If the reporting file was not valid the CKO2 errors can be corrected in the same way data entry in a new report possibly using specific action codes see detailed description of the business data U2A with XML semi automatic file upload download The reporting file in XML format has to be available to the PC that will be used to get access to OneGate CSSR The participant s user o has to login via his browser with a valid certificate into the ONEGATE web application o chooses for reporting file upload selects the reporting file o gets a ticketID from OneGate CSSR when the reporting file is received acknowledgment During the day the CKO2 application regularly validate
18. ect Bad request parameters with some more details e g The requested months should be within a lapse of 12 months other technical problems e g database access problems access denied can be more detailed other exceptions if U2A consultation with browser the return status will be displayed in the screen form with a readable sentence possibly with guideline to solve the problem Especially in the following cases 2 9 debtor can t be identified Then the following message will be displayed The following debtor could not be identified please check the id key s you entered and that are shown below and try again more than 1 debtor Then following message will be displayed We found several debtors corresponding to the identification key s you entered please choose one of the debtors below and enter his ID keys in a new consultation request The identification data of these debtors will be shown on the screen If A2A web service getOneDebtorsCredits the return status will be integrated as a value in a separate field in the reply gt debtor identification data and credit situation A if only one debtor in the CKO2 database corresponds to the selection criteria 1 and 2 additional id data of the debtor including the legal situation from KBO BCE credit situation e if no credits found in the CKO2 database for 1 or the 2 periods absence of credit will be indicated in the return status for 1 or
19. ed by NBB This can be done manually and gradually evolve to an automated solution 2 Other browser OS versions can be tested on demand but will not be officially supported 3 To be confirmed for A2A and NBB certificates Participants which have already NBB certificates can use them no new NBB certificates will be assigned Other aspects U2A online Specific configuration requirements browser OS will be communicated e g To be able to use the OneGate web application the users browser must accept cookies Technical description is provided in the user manual of the declarer Ref 3 appendix 1 Page 22 of 25 2 13 Testing It was agreed to guarantee a period of 6 month of testing between the CCCR and participants The NBB will provide exclusively for CKO2 participants and their integrators a test environment which will be available full time during the test period planned before entry into production of the new CKO2 application and subsequently before entry into production of new releases of the application The CCCR will draw up a schedule of tests that participants will have to carry out taking account of the functionalities which they choose and the timetable agreed with the CCCR Successful completion of the tests planned by the CKO2 is compulsory for all participants before entry into production All participants must proceed to production on the same date From then on they must start by supplying data for the CCCR via CKO
20. ed is what it actually claims to be Authentication involves accepting credentials from the entity and validating them against an authority Mutual authentication is a prerequisite for accessing the new CKO2 U2A and A2A functions This implies that both the CSSR server and the participant must be authenticated with digital certificates NBB best practices allow only class 3 certificates for this purpose The class 3 certificates provide the highest assurance thanks to a rigorous identification of the certificate holder The system supports GlobalSign Certipost Isabel and NBB certificates NBB certificates will not be issued for CKO2 but participants who have an NBB certificate will be allowed to use it for the new CKO2 application until it expires It is still to be confirmed whether the same certificate will be usable for A2A and U2A Confidentiality and data integrity Data protection is required to ensure that requests and responses have not been tampered Communication over U2A and A2A between the client and server is encrypted over HTTPS to guarantee confidentiality and privacy SSL is implemented This means that no additional encryption of reporting files by the participant is required For internal functions the data protection means in use in the NBB for the applications dealing with confidential information will be implemented limited number of functions authorized for a work post limited number of people authorized to access a work
21. ements e g technical protocols certificates browsers formats and limits e g volume restrictions The detailed specifications of the business data that will be exchanged between the participants and the CCCR will soon be released in a separate document Page 5 of 25 2 GENERAL DESCRIPTION 2 1 New CKO2 General functions communication channels and actors Figure 1 shows the new CKO2 application also called CKO2 application as the centralized database and distribution centre of data from debtors and credits with the different actors stakeholders Internet U2A online via browser and A2A webservices CCCR CCCR CKO2 application IT application with central database National Register Debtor Inquiry and CCC R Debtor Inquiry backoffice hosted in NBB Pa rt i C i 5 Report ry pants Lt Consultation request reply Tg Ay a r all participants WGCR ts of g A ecks Ps i oo ea becribers l Y 4 Niji Replication gt OPORERTIOADANAONNNEN i TPE geographicdl and sectorial reports paie ke DWH Infocenter Prudential control Figure 1 All the communication with the participants uses the internet in one of the 2 following ways further called channels or type of entry points e U2A user to application the participants collaborators can use all the CKO2 functions online interactive via a common browser by manual keyboard manipulations and screen views o enter report
22. ile in attachment possible channels Download feedback output in 2 steps using OneGate webservices A2A via OneGate asynchronous 1 Download list of OneGate internal ID s of available feedbackfiles outputfiles For feedbackfiles the ticketID s will be also in that list 2 Download 1 of the feedbackfiles outputfiles from the list and this x times once for each file from the list Table 4 2 6 Volumes Zipping of reports is supported and even recommended to limit data traffic The system will automatically detect if zipping is applied to the received file A size limit of 10 MB is imposed on incoming reporting files zipped or uncompressed Reports larger than 10 MB should be split into more than 1 file The logical unit of work for the report is the action code e g CRED This allows splitting the report into a file for each action code This implies that all credits for a single debtor must be sent in a single report Of course a single reporting file normally will hold credit reports concerning many debtors Files will be treated by the system in the order in which they arrive Roughly estimated a 10MB zipped file can contain around 15 000 credits l one credit one amount and 6 values corresponding to 6 dimensions type of credit authorized or used credit form residual term initial term currency and country Page 18 of 25 2 7 Security Authentication Authentication ensures that an entity involv
23. ing data upload reporting files download feedback files o download outputs o consultation of the data of debtors credits processing status To do this these collaborators have to access the web applications from the NBB The U2A entrypoints allows the participants to meet the reporting obligations and get the required debtor and credit data with minimal investment in T equipment and without IT development e A2A application to application the participants systems can use all the CKO2 functions using web services for file exchange in XML format With these web services the participants can automate the interaction between their applications and the CKO2 at 2 levels 1 The processing of the XML files create read requires T development at the participant side 2 The exchange of the XML files can be full automatic by calls of the CKO2 web services initiated from the participants systems for complete integration of the CKO2 functions in the participants applications Page 6 of 25 can be semi automatic by using web service testing tools like SOAPUI and cURL This might be appropriate e for testing the XML s before the exchange is automated e when the number of the participants exchanges are limited The use of these tools will be sufficient and reduce the need for IT investments e incase of problems with the automatic exchange of the XML files business recovery plans One or both levels can be done with the assist
24. ion replies using his own references and then there is no need to store the ticketID 2 14 2 Third party declarer In OneGate the concept of delegated authorizations is under construction This concept allows a corporate user of a participant to delegate access to his reporting functions to an external user participating institution or not called delegate user which is not a collaborator belonging to the participant s company By this the participant delegates the reporting and feedback management to that external user called third party declarer This last has to get its own class 3 certificate This concept of delegated authorizations requires also separate reporting files per declarer participant even if the reports of different participants are managed by the same third party declarer the generic XML of OneGate provides only one declarer ID per reporting file 2 14 3 Integrators and Gateway Different participants can cooperate to build a common interface Gateway cf 3 Glossary to the new CKO2 They also can delegate the development of a common interface to an integrator cf 3 Glossary Possible benefits e g e reducing development costs and work for each of the participants sharing of costs and delegate to specialized company e easy integration of the CKO2 function in the participant s systems Page 23 of 25 The NBB CKO2 has no special role mission to build or participate in a CKO2 Gateway and will deliver e
25. it situations available situation on end of last month could be incomplete depending on the date of consultation 1 to identify an end of month month year 2 default if no ends of month are chosen 2 last calendar ends of month e reply output gt return status tells if the request could be processed with success Following cases will be reported only one debtor and credits found for each requested month This is the most common situation only one debtor in the CKO2 database corresponds to the selection criteria and corresponding credits where found for both periods absence of credits only one debtor in the CKO2 database corresponds to the selection criteria but the credits for one or two periods were not found 2 cases e The following debtor has no credit corresponding to the requested month 1 e The following debtor has no credit corresponding to the requested month 1 and month 2 more than 1 debtor In this case no credit data will be returned and the data of the debtor will be available e onscreen in case of online U2A e via a second web service in case of A2A Page 13 of 25 A SCS hS gt hS SCS 2S 2 debtor can not be identified at all e g enterprise number not valid The following debtor could not be identified please check the id key s you entered and that are shown in the output and try again The XML structure of the uploaded file is not corr
26. l Server for Reporting NBB National Bank of Belgium NUIN NBB Unique Identifier Number U2A User to Application KBO Kruispuntbank van Ondernemingen BCE Banque Carrefour des Entreprises FIFO First in First Out NRNP National Register of Natural Persons CBFA Banking Finance and Insurance Commission Page 25 of 25
27. n the context of CKO2 security measures confidentiality authentication and authorization data validation high availability measures support for zipping messaging system between the system administrators and participants transformation of XML to HTML It is important to note that the processing of a CKO2 reporting file via Onegate is always asynchronous When Onegate receives a report the system will respond with an acknowledgement in the form of a ticket ID The acknowledgement only indicates that the report was received and is ready for processing The processing by Onegate takes some time depending on the size of the report A feedback report is created after the processing The feedback report contains the result of the validation in Onegate It is up to the declarer to retrieve the validation report for a declaration The declarer has to take the initiative both for sending the declaration and the retrieval of the validation reports All inputs and outputs between the participants and the CKO2 will be exchanged via OneGate except the single debtor consultation function which is implemented as a synchronous function in a specific CKO2 application The figure below shows that Onegate will be used for the reporting part of CKO2 The single debtor consultation function is not part of Onegate Page 8 of 25 Internet U2A online vi browser S C KO2 and A2A webservices National Debtor Inquiry Reg ister
28. puts Different kind of outputs from the CKO2 application are regularly made available in OneGate to the participants Destination gt To subscribers monthly automatic feedback XML directories r pertoires repertoriums XML sectoral and geographical statistics PDF or Excel file gt To all participants results of monthly checks PDF or Excel file Scenario gt subscriptions can be made by a participant by sending a message via OneGate to CKO2 backoffice gt CKO2 makes the reports available in OneGate feedback files attached to messages to subscribers participants in XML PDF or Excel format gt Participants can choose how to collect these outputs In fact this can be done the same way the OneGate feedback files are downloaded e Manual via U2A file download in OneGate or Automatic via 2 web services in 2 steps 1 Get list with available outputs via web service feedbackListRequest 1 2 Get one specific output from the list via web service feedbackRequest 1 All outputs can be downloaded by repeating the call of this web service for each available output 1 or a very similar web service This is yet an open question for the CKO2 designers 2 4 4 Follow up consultations view results logging history The web application U2A of OneGate allows also e consultation of the reporting status of the files sent control panel e consultation of the history characteristics and status of the reports
29. r Description 25 11 2009 1 0 L D haese Wouter Braem English version After the reviews of the version 1 0 revised version will be published 1 2 Content of document This document includes e the technical description of the activities of the CCCR Central Corporate Credit Register the way it collects data their processing and the outputs produced through the new IT application called CKO2 e the main specifications of the IT system architecture e references to documents of ONEGATE CSSR completing this description e references to documents describing the business aspects 1 3 Purpose of document This document aims at giving the necessary information to the participants of the CCCR to allow them to assess the needed human and technical resources and the cost of their own developments It constitutes also the basis for the CCCR to write the technical requirements for its IT department and the final protocols which will be distributed among all its future participants according to the planning agreed with them so that they will be in state to begin their own developments This document is written with the participants in mind what do they have to know about the architecture and technology of the new CKO2 application communication channels interfaces access procedures 1 4 Purpose of development The CCCR fulfils a legal obligation To perform its mission the CCCR must develop and offer to the stakeholders a new central IT system c
30. red by a separate SLA Support Support is only guaranteed during office hours Support can be given besides the opening hours but only if a supporting staff is still available Support will be based on best effort no commitment on the result This means in practical terms that the participants can send files outside the opening hours but that the NBB will only start solving the potential arisen problems the morning of the next working day 2 10 Formats Overview see 2 5 Overview of components channels and formats Generic XML format The CKO2 reporting files will be in a generic One Gate XML format This means that this XML format e is general enough to describe the many different kinds of reports that will be processed by OneGate by adding some metadata e has a relatively simple generic XML schema that describes the XML data and can be used to validate reporting files of all OneGate reports This generic XML schema will soon be available to the participants Will be in this format e The reporting files uploaded via OneGate U2A and A2A e the feedbacks generated by OneGate and the CKO2 application On demand of the declarer these feedbacks will be transformed in a more readable HTML format to examine these feedbacks via the online OneGate interface CKO2 specific XML format The XML format used for the request reply of the single consultation for debtor for monthly feedback and directories r pertoires will be specifi
31. s and processes the incoming debtor reports The credit reports will be processed only during a nightly procedure so these validation files can only be expected in the morning next day The feedback files will be available in the ONEGATE control panel more precisely as attachments of incoming messages from the CKO2 application to the participant ONEGATE declarer The content of the feedback files can be opened and the validation results will be presented in readable HTML format or XML format depending on the participant s preference The feedback files can then be downloaded and made accessible to the participants application via the PC in XML format A2A full automatic The participant s technical user can call 1 OneGate web service to upload a report and 2 webservices to get the feedback s of the report s Upload report The OneGate web service uploadFile can be called to get access to OneGate upload the XML reporting file to OneGate and receive a ticketID acknowledgment This ticketID is in fact the identifier of the file transfer to whom the feedback is associated and so there is a unique ticketID for each reporting file which is uploaded with success might be useful to get specific feedback files later and therefore can be stored in the participant s database Page 11 of 25 Get feedbacks How The user has to call first the OneGate web service feedbackListRequest to get the list of the identifiers of the
32. t The feedback reports will be formatted as XML files The feedback files can be transformed into the more readable HTML for viewing on request by the declarer 2 3 Direct access channels to the CKO2 application The participants will be able to communicate directly to the CKO2 application without using ONEGATE for the component single consultation for one debtor and the channels U2A via browser and A2A web services Synchronous communication For both A2A and U2A the reply with the output results will immediately follow the requests short response times A detailed functional description will be given in the paragraph describing the business scenario Single consultation for 1 debtor The A2A multiple consultations web services to request for the credit situations of multiple debtors can be implemented by calling the web service single consultation of one debtor for each of the multiple debtors This proposal will be discussed in the paragraph Multiple consultations under Special Topics Page 10 of 25 2 4 Business scenarios per component and per channel 2 4 1 Reporting and feedback The OneGate functions described below are detailed further in 2 and 3 U2A without XML no or very limited automation The participant s user o has to login via his browser with a valid certificate into the ONEGATE web application o chooses for data entry of the forms of his reports in the ONEGATE domain for reporting of
33. tains for each feedback an identifier of the feedback file internal OneGate unique identifier the ticketID of the upload file The webservice feedbackRequest Function requests one specific feedback file Input the identifier of the requested feedback same type as in the list of available feedback identifiers OneGate internal number not the ticketID Output o message containing the requested feedback file not encrypted not signed encoded in base 64 decode before use structure message body Body of the message in plain text Example Validation report for ticket number 480 attachment of the message o encoded in base 64 the feedback file If the feedback contains the Feedback OneGate or CKO2 you need to decode the Attachment and then process the XML file result of the decoding Page 12 of 25 Because the participant has to take the initiative for all transactions but does not know when the feedbacks are available because of the asynchronous communication of OneGate he can call the web services at regular times and each time process all the available feedbacks 2 4 2 Single consultation for 1 debtor Function Request for the credit situations for 2 previous months for one debtor Channels will be implemented via channel for direct access from the participants to the CKO2 application so without OneGate CSSR including U2A An internet a common browser a CKO2 url and a valid certificate limite
34. uest web service calls in strict sense or calls in strict sense directly in a HTTPS or directly in a HTTPS request required ben class 3 Isabel Certipost Global Sign NBB 3 certificats p g 3 file encryption XML for input and output data entry Outputfiles can include also PDF XES asynchronous inputfiles are waiting in CRS until synchronous CKO2 fetches them and outputfiles are waiting until asynchronous participants fetches results Not suitable for online transactions UA cmon oarn Ii eee aA oo oor 1 ee or fully automated limited automation oy eee very limited automation solutions solutions common browser IE semi automated or versions 7 fully automated Mozilla Firefox versions application using the 3 and OS Windows CKO2 webservices XML for input and output Outputtfiles can include also PDF XLS XML for input and on screen data output no attachments synchronous suitable for online inquiries Usage profiles Requirements for common browser Internet Explorer versions 7 rticl n i i paricipanis Mozilla Firefox versions 3 infrastructure or 2nd OS Windows XP and semi automated or fully automated application using the CRS Gateway Vista 2 AE XP and Vista 2 1 Table 5 1 Tools like SOAPUI user interface and Curl both available freely on the internet allow testing and automation of web service calls in a relatively easy way using the WSDL deliver
35. will be available Page 14 of 25 1 Webservice getOneDebtorsCredits will be implemented as described in previous paragraph Webservice getMultipleDebtors This is not a general purpose web service partipants will only be allowed to use it to solve the specific debtor identification problems homonyms encountered in the first web service request input request reference of the participant optional same as for getOneDebtorsCredits debtor identification same as for getOneDebtorsCredits reply output o return status tells if the request could be processed with success Following cases will be considered only one debtor This is the most common situation only one debtor in the CKO2 database corresponds to the selection criteria more than debtor debtor can not be identified at all e g enterprise number not valid The XML structure of the uploaded file is not correct Bad request parameters with some more details e g The requested months should be within a lapse of 12 months other technical problems e g database access problems access denied can be more detailed e other exceptions o additional debtor identification data for each debtor in the CKO2 database corresponding to the selection criteria For each debtor the same data is returned as the first web service in case of 1 unique debtor SES S SCS S sO S SO S gt KS Ss KS L2 2 4 3 Out
36. zation of a client certificate for use of the application The registration starts when a user tries to access the OneGate online application and his certificate is not known by the NBB The user will be redirected to a site to request access to the application The procedure consists of following steps Page 19 of 25 1 The certificate details will automatically be stored in the system At this point the certificate does not have any authorizations 2 The user will be requested to enter identification and contact details and indicate the application for which access is requested 3 An NBB administrator will verify the validity of the certificate and registration details and grants or denies access to the application If access is granted the necessary authorizations are attributed to the certificate and the user is able to access the application with the certificate 2 9 Availability and support System availability User functions will be accessible 24 hours 7 days a week except during maintenance periods The highest availability rate for reporting functions should be reached between the 5th and 15th of each month Indeed the system should be able to process all reports during this period Therefore especially the OneGate production front end that will be responsible for the reception of the CKO2 reports and acknowledgments will be implemented as a highly available environment The availability percentage and maximum down time can be cove
Download Pdf Manuals
Related Search