30-10-2009 and 09112009

Leo D'haese - Wouter Braem

Central Corporate Credit Register

project CKO2

IT-overview

L

Agenda

► New CCCR - functions and actors

► One Gate as major interface

► Participants choices to make: automation?

► A2A and U2A entry-points

► Security aspects

► Reuse KCP-Gateway?

► Questions and Answers

2 / 25W

New CCCR - General functions and actors

3 / 25

CKO Partici-

pants

CKO2 IT-application and

CCCR-backoffice

hosted in NBB

KBO

National

RegisterDebtor Inquiry

Debtor Inquiry NCB x

NCB y

NCB z

WGCR

WGCR

WGCR

DWH

Infocenter

CBFA/NBB

Replication

Prudential control

Report and get feedback

Consultation: request/reply

Output:

for all participants:

- results of monthly checks

for subscribers:

- monthly feedback

- repertories

- geographical and sectorial reports

Internet :

U2A (online via browser)

and

A2A (webservices)

Get reports

W

4 / 25

One Gate as major interfaceproject One Gate = successor of CSSR -> CRS application

One Gate will be the Central Reporting channel of the NBB

W

CKO

Partici-

pants

CKO2KBO

National

RegisterDebtor Inquiry

Debtor Inquiry NCB x

NCB y

NCB zWGCR

WGCR

WGCR

DWH

Infocenter

CBFA

Replication

Prudential control

Report and get feedback

Consultation: request/reply

for 1 debtor

Output

for all participants:

- results of consistency checks

for subscribers:

- repertories

- monthly feedback

- geographical and sectorial reports

Internet :

U2A (online via browser)

and

A2A (webservices)

Get reports

CRS

Optional:

Multiple consultations

(x debtors in request)

5 / 25

Why One Gate as major interface ?

! direct access to CCCR only for consultation for 1 debtor (A2A + U2A, synchronous)

One Gate for exchange of data and messages between CKO2 and participants

+ Reuse developments and faster results: standardisation, reduce costs and

respect targetdates

+ Including: - validations, security, high availability, U2A and A2A

- asynchronous, important volumes, zipping

W

One Gate Use

6 / 25

► Buffer between participants and CKO2

► nightly update of CKO2 with declarations in One

Gate

=> stability of consultation results over 1 day

► Initiative for input/output always from participant

► 2-steps validation of declaration

► One Gate: xml schema & domain validations (data

type...)

► CKO: limited to business rules validations

One Gate and CKO2 feedback files are retrieved from

One Gate entrypoint (common formats & procedure)

W

Profiles

► Participants choices to make:

● full automation:

A2A (webservices) to automate the exchanges with CKO2

XML-input and -output to enable automation of processing at

participants' side

● no automation: online via browserinterface

U2A data entry and

get readable feedback and outputs

● partial automation:

no webservices: U2A file upload/download

XML-input and -output

7 / 25L

8 / 25

A2A Entrypoints

► Web services communication with XML

► Asynchronous (feedback only available after a while)

► uploadFile

► feedbackList

► feedback

► Synchronous (immediate return of feedback results)

► consultation of 1 debtor's credits

► WSDL describes the web service methods, parameters and entrypoint URLs

► A2A-purposes:

► Full or partial automation

► Open Source tools like SOAPUI / cURL can be used

► Integration with client system (application of participant)

L

9 / 25

Reporting & feedback A2A

► Upload declarationfile with webservice:

► send declaration file

► receive ticketID

► Get feedback in 2 steps (2 webservices):

► 1. Get list of available feedbacks (One Gate ID and ticketID)

► 2. Get specific feedback file with one One Gate ID (repeat)

► Zipping recommended

► Size limit of 10 MB (zipped) => split big declaration files

► Asynchronous:

► One Gate-feedback available after a (short) while

► CKO2-feedback only created next night

W

10 / 25

Single Consultation A2A

► Webservice function: Get report on debts for 1 debtor

► Synchronous: immediate return of results => can be

called from online and batchapplications of the

participant

► Can be used for multiple consultations (x debtors) by

calling this webservice once for each debtor

W

11 / 25

Multiple Consultations A2A & U2AInitial proposal

► A2A

► Upload (webservice UploadFile): Participant sends a "declaration" to One Gate containing unique identifiers of the x debtors

► Feedback: participant collects 1 consultation result XML-file (debts of x debtors) from his feedbackfiles in One Gate

► U2A : Upload XML-file with unique ID's of x debtors, followed by download XML-file with debts of x debtors

► Asynchronous: feedbackresults only available after a while => not suitable for online applications.

Alternative proposed by NBB

► A2A: Multiple consultations (x debtors) = x calls of single consultation (1 debtor) webservice

► Synchronous: immediate result => suitable for integration in participant's online and batch applications

► P.M. U2A only available in single debtor consultation with debts shown in browser

Consequence

Initial proposal not developped:

+ price reduction of development (± 20.000 € per year)

+ less development ==> less difficult to respect target dates

L

12 / 25

Outputs A2A and U2A► To subscribers: monthly automatic feedback, repertories, sectoral

and geographical statistics

► To all participants: results of monthly checks

► Concept:

► subscriptions can be made by sending a message via CRS One Gate to CCCR-backoffice

► CCCR makes the reports available in One Gate-feedbackfiles

► attached to messages to subscribers/participants

► in PDF or Excel-format

► Participants can choose how to collect these outputs from One Gate-feedbackfiles:

► Automatic via 2 webservices in 2 steps:

► 1. Get list with available outputs

► 2. Get one specific output from the list (repeat)

► Manual via U2A file download in One Gate

L

13 / 25

U2A Entrypoints (1)

► Purpose ?

► Manual interface for participants who don't want to

invest in A2A-automation

► Backup solution in case of A2A-communication

problems for participants who normally use A2A

► How ?

► Webapplication interface

► using common browser and screenforms

► for manual online operations (data-entry, manual upload and

download, consultation of feedbacks & status...)

W

14 / 25

U2A Entrypoints (2)

Functions ?

► Input to CKO2 via One Gate: declarations

► Data entry in forms (manual screen input + One Gate-validations)

► Manual Upload File (XML input)

► Output via One Gate

► Manual download feedback-files after declaration

► Manual download outputfile(s) from CKO2: monthly feedback...

► Interactive consultation directly in CKO2: debts for 1 debtor

► Webinterface One Gate allows to consult logging and

statusinfo

W

15 / 25

Reporting & feedback U2A (1)

► Declaration: 2 options

► data entry: manual input and One Gate-validations

► file upload of XML declaration = semi automated

► Consult status, results and content of declarations:

► Consult reporting status of files sent = control panel

► Open data entry screenforms (click ID of report)

Remark: identification of report (Period) is simplified in example

W

16 / 25

Reporting & feedback U2A (2)

► 2. Exchanges: logs and feedbackmessages

► 2.a. File exchange log: consult history, status and details of

declarations (click link to Client Filename)

L

17 / 25

Reporting & feedback U2A (3)

► 2.b.Feedback Messages: contains attachment with validation

reports for declarations (by ticket number)

L

18 / 25

Reporting & feedback U2A (4)

► XML File Upload

W

Outputs U2A

19 / 25

► Function? Get feedbacks from declarations and Outputs via One

Gate

► How? Manual Download file(s)

► What ?

► Get feedbacks from declarations

► if input was data-entry: only CKO2-feedback

(One Gate-validations already passed during data-entry)

► if input was XML-file: One Gate- and CKO2-feedback

► Get Outputs CKO2 via One Gate

► Formats:

► Feedback from declarations: html-file (easy to read) and XML-file

► Output :

► monthly feedback: XML

► statistics, repertories: PDF or Excel-format

L

Consultation U2A

20 / 25

► Web interface (common browsers)

► Function: Retrieve debtor credit status for 1 debtor

► Online input: debtor identification (all possible debtors)

► Online output:

► Show debts of that debtor and more debtor

identification data

► if debtor is not unique: show only debtor

identification data, no debts

► if debtor not found: message "debtor not found" + no

debts and no debtor data

L

Security aspects

21 / 25

► A2A & U2A communication over HTTPS (encryption to

guarantee confidentiality)

► Class 3 client certificates (highest level of authentication security)

► for U2A :

► 3rd party certificate from Globalsign, Certipost, Isabel.

► NBB-certificats (Idealix) : only for those who have

already NBB-certificate

► for A2A : normally will be the same as U2A (to be confirmed)

► No additional encryption/signing

► Registration procedure to request access to the application

with a certificate (approval of CCCR-backoffice)

W

22 / 25

Reuse KCP-Gateway?

► Comparison: CKO2-specs <-> KCP-specs: see next slide

► Differences in security-requirements (signing, IPSec...),

protocols and algorithm => not obvious to reuse KCP-

Gateway

L

23 / 11

interactive

data entry

(U2A)

interactive file

upload/

download

(U2A)

using CRS-

webservices or https-

requests (A2A)

CKO2

webapplications for

consultations (U2A)

CKO2 webservices

for consultations

(A2A)

hppt/

httpshttps https https https https https

http over IPSec

tunnel

soap - -

The payload can be

included in a SOAP

request (web service

calls in strict sense) or

directly in a HTTPS

request.

-

The payload can be

included in a SOAP

request (web service

calls in strict sense)

or directly in a HTTPS

request.

- -

class 3

Isabel,

Certipost,

Global Sign,

NBB (3)

class 3 Isabel,

Certipost,

Global Sign,

NBB (3)

class 3 Isabel,

Certipost, Global Sign,

NBB (3)

class 3 Isabel,

Certipost, Global Sign,

NBB (3)

class 3 Isabel,

Certipost, Global

Sign, NBB (3)

class 3 - NBB

(IdealX)

class 3 - NBB

(IdealX)

no no no no no form signing clear signing

no no no no no no no

data entry

XML for input

and output -

outputfiles can

include also

PDF, XLS ...

XML for input and

output - outputfiles can

include also PDF, XLS

...

on screen data

XML for input and

output (no

attachements)

S/MIME

(containing XML-

message +

signature)

S/MIME (containing

XML-message +

signature)

synchronous and

asynchronous

depending on

function

synchronous and

asynchronous,

depending on

function

A2A semi-automated

or fully automated

solutions

U2A solutions: no or

very limited automation

A2A semi-automated

or fully automated

solutions

U2A

A2A semi-

automated or fully

automated

solutionssemi-automated or fully

automated application

using the CRS-

webservices (1)

common browser (IE-

versions 7+,

Mozilla/Firefox-versions

3+) and OS (Windows

XP and Vista). (2)

semi-automated or

fully automated

application using the

CKO2-webservices

(1)

Common

browser (IE6, 7)

semi-automated or

fully automated

application

(3) Participants which have already NBB-certificats can use them, no new NBB-certificats will be assigned.

(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

delivered 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.

synchronous/

asynchronous

asynchronous: inputfiles are waiting in CRS until

CKO2 fetches them, and outputfiles are waiting until

participants fetches results. Not suitable for online

transactions

synchronous, suitable for online inquiries

Usage profilesU2A solutions: no or very

limited automation

Requirements for

participants'

infrastructure or

Gateway

common browser (Internet

Explorer-versions 7+,

Mozilla/Firefox-versions 3+)

and OS (Windows XP and

Vista) (2)

file formats

CKO2

direct with CKO2

Comparison between CKO2/CRS and KCP concerning the communication with participants

Technical

specifications and

architectureKCP internet KCP extranet

required

certificats

proto

col

signing

file encryption

CKO2 via CRS

KCP

L

24 / 25

► Participants and integrator(s) (Accenture or others) can

cooperate to build CKO2-Gateway

► NBB/CKO has no special role/mission to build a CKO2-

Gateway

► In other words: delivers the same CKO2-specifications,

test-environment and support to all participants and

integrators and at the same moment

Reuse KCP-Gateway ?

L

25 / 25

Q&A

L