protocol over de afgifte van de · pdf fileprotocol over de afgifte van de portfoliotabellen...

26
PROTOCOL OVER DE AFGIFTE VAN DE PORTFOLIOTABELLEN (BAISSEPOSITIE, UITGEGEVEN EFFECTEN EN BUITEN BALANS) DOOR DE KREDIETINSTELLINGEN PROTOCOLE DE REMISE DES TABLEAUX DE PORTEFEUILLE (POSITION A LA BAISSE, TITRES EMIS ET HORS BILAN) PAR LES ETABLISSEMENTS DE CREDIT Versie 1.0 Version 1.0 11-2004

Upload: vohanh

Post on 06-Mar-2018

219 views

Category:

Documents


2 download

TRANSCRIPT

PROTOCOL OVER DE AFGIFTE VAN DE PORTFOLIOTABELLEN (BAISSEPOSITIE, UITGEGEVEN EFFECTEN EN BUITEN BALANS)

DOOR DE KREDIETINSTELLINGEN

PROTOCOLE DE REMISE DES TABLEAUX DE PORTEFEUILLE (POSITION A LA BAISSE, TITRES EMIS ET HORS BILAN)

PAR LES ETABLISSEMENTS DE CREDIT

Versie 1.0 Version 1.0

11-2004

PROTOCOL OVER DE AFGIFTE VAN DE PORTFOLIOTABELLEN (BAISSEPOSITIE, UITGEGEVEN EFFECTEN EN BUITEN BALANS)

DOOR DE KREDIETINSTELLINGEN Gelet op hun eenparig verlangen het algemeen belang beter te dienen, hebben

1. de Belgische Vereniging van Banken, handelend in naam en voor rekening van al haar leden en daartoe behoorlijk gemachtigd bij besluit van haar Directiecomité, en

2. de Nationale Bank van België, onderling de volgende bepalingen vastgelegd:

1. De bepalingen van dit protocol betreffende de afgifte van de portfoliotabellen (baissepositie, uitgegeven effecten en buiten balans) door de kredietinstellingen zijn goedgekeurd en treden in werking vanaf de rapportering van de situatie ultimo december 2005.

2. Een exemplaar van dit protocol zal worden gedeponeerd bij de Nationale Bank van België, die

het zal bewaren en het secretariaat zal waarnemen.

3. De partijen vertegenwoordigd door de ondertekenaars van dit protocol die van oordeel zijn dat er om technische of organisatorische redenen een aanleiding bestaat om aan de bepalingen, vervat in dit protocol, een wijziging aan te brengen, zijn verplicht de hierna beschreven werkwijze te volgen met het oog op een snelle en efficiënte behandeling van het probleem.

De betrokkene(n) richt(en) een voorstel tot het Secretariaat. Een werkgroep wordt door het Secretariaat samengeroepen om het voorgelegde

probleem te onderzoeken. Deze werkgroep bevat een vertegenwoordiger van elke ondertekenaar van het protocol. De eerste bespreking van het voorstel dient plaats te vinden binnen 14 dagen na

ontvangst van het verzoek. Het Secretariaat staat in voor het opstellen van de geamendeerde teksten en de

ondertekening van gewijzigde of geamendeerde protocollen.

Opgemaakt te Brussel in 3 exemplaren.

PROTOCOL OVER DE AFGIFTE VAN DE PORTFOLIOTABELLEN DOOR DE KREDIETINSTELLINGEN

1 Onderwerp van het protocol ....................................................................................................... 1 2 Transmissieprocedure ............................................................................................................... 1 2.1 Structuur van de afgiften ......................................................................................................... 1 2.2 Middelen voor de afgifte van de portfoliotabellen ..................................................................... 1 2.3 Gebruik van de CSSR ............................................................................................................ 1 2.4 Verantwoordelijkheid van de aangever en opvolgingsmogelijkheden ....................................... 1 2.5 Dienst verleend aan de gebruikers van de CSSR .................................................................... 1 2.6 Algemeen formaat van de gegevens ....................................................................................... 2 2.7 Modaliteiten van snelle afgifte ................................................................................................. 2 2.8 Kalender ................................................................................................................................. 2 3 Noodoplossing bij defect van de CSSR ...................................................................................... 2 3.1 Ingebruikneming ..................................................................................................................... 2 3.2 Formaat van de gegevens ...................................................................................................... 2 3.3 Vertrouwelijkheid en onweerlegbaarheid ................................................................................. 2 3.4 Procedure............................................................................................................................... 2 3.4.1 Aanbieding .......................................................................................................................... 2 3.4.2 Kopie ................................................................................................................................... 3 3.4.3 Indiening .............................................................................................................................. 3 3.4.4 Kalender .............................................................................................................................. 3 4 Validering .................................................................................................................................. 3 5 Het correctieproces ................................................................................................................... 3 6 Kwaliteitscontrole....................................................................................................................... 4 7 niet-naleving van de regels en sancties...................................................................................... 4 8 De coderingen ........................................................................................................................... 4 8.1 Kredietinstellingen .................................................................................................................. 4 8.2 Landen en munten .................................................................................................................. 4 8.3 Effecten .................................................................................................................................. 5 8.3.1 Prioritair gebruik van de ISIN-code ....................................................................................... 5 8.3.2 Aanvraag van een ISIN-code ............................................................................................... 5 8.3.3 Uitgifte van effecten ............................................................................................................. 6 8.3.4 Eventueel gebruik van de fictieve ISIN-code (enkel voor sommige buitenlandse effecten

en voor Belgische kas- en groeibons ).................................................................................. 6

Lijst van de bijlagen

Bijlage 1: Definitie van de portfoliotabellen Bijlage 2: Afgiftekalender Bijlage 3: Afgifteborderel Bijlage 4: Lijst van aanvaarde codetypes Bijlage 5: Lijst van fictieve ISIN-codes voor kas- en groeibons Bijlage 6: XML protocol

1.

1 ONDERWERP VAN HET PROTOCOL

Het onderhavige protocol regelt de manier waarop de gegevens van de portfoliotabellen (baissepositie, uitgegeven effecten en buiten balans) (bijlage 1) door de kredietinstellingen aan de Nationale Bank van België (NBB) worden meegedeeld, dit zowel wat de te volgen procedure als wat de technische aspecten betreft. De portfoliotabellen aangaande de activa of haussepositie worden geregeld door een specifiek protocol.

2 TRANSMISSIEPROCEDURE

2.1 STRUCTUUR VAN DE AFGIFTEN

De minimale rapporteringseenheid is de tabel. Concreet betekent dit dat de correctie van een individueel gegeven onmogelijk is en dat de volledige tabel teruggestuurd moet worden.

2.2 MIDDELEN VOOR DE AFGIFTE VAN DE PORTFOLIOTABELLEN

De afgifte van de portfoliotabellen gebeurt via één enkel kanaal, namelijk de Central Server for Statistical Reporting (CSSR). Het gebruik van de CSSR maakt het onder meer mogelijk:

de gegevens te valideren, over het algemeen binnen het uur na de doorzending ervan; een beveiliging van hoog niveau te verzorgen.

2.3 GEBRUIK VAN DE CSSR

Uitvoerige technische informatie met betrekking tot de CSSR vindt men op de site : http://www.nbb.be/dq/n/dq8/readme_cssr.htm

2.4 VERANTWOORDELIJKHEID VAN DE AANGEVER EN OPVOLGINGSMOGELIJKHEDEN

Via de toepassing CSSR beschikt de aangever over voldoende mogelijkheden om de behandeling van zijn aangifte op te volgen en te controleren. Hij beschikt daarvoor over de volgende functies:

ontvangstberichten (acknowledgements), inclusief een foutenrapport dat door de server teruggestuurd wordt;

op de server voorkomende loggings; raadpleging van de loggings en van de foutenrapporten, rechtstreeks op de server; raadpleging van de aangifte.

2.5 DIENST VERLEEND AAN DE GEBRUIKERS VAN DE CSSR

De Nationale Bank van België biedt de volgende diensten in het kader van het gebruik van de CSSR: opening van de server voor een verzending en gewaarborgde behandeling: 08.00 u. tot

20.00 u. tijdens de Belgische bankwerkdagen; bijstand aan de gebruikers gewaarborgd van 08.30 u. tot 16.00 u.; contactpunten voor de gebruikers:

o Statistieken (methodologie, codificering, moeilijkheid voor het identificeren van een probleem): 02 221 47.20

o IT (technische problemen): 02 221 40 60 o Administratie (paswoorden,...): 02 221 47.28

behandelingsduur voor een aangifte onder normale omstandigheden minder dan 1 uur. Al deze informatie is beschikbaar op de site van de CSSR.

2.

2.6 ALGEMEEN FORMAAT VAN DE GEGEVENS

De rapportering via de CSSR dient te gebeuren volgens het generische formaat van de CSSR, in de XML-taal die beschreven is in bijlage 6.

2.7 MODALITEITEN VAN SNELLE AFGIFTE

Teneinde te voldoen aan de statistische vereisten gesteld door de Europese Centrale Bank zijn een aantal kredietinstellingen verplicht om binnen de 11 Belgische bankwerkdagen volgend op de rapporteringsdatum de portfoliotabellen op territoriale basis mee te delen aan de Nationale Bank van België.

2.8 KALENDER

De kredietinstellingen moeten de in bijlage 2 opgegeven kalender naleven. Maar de kredietinstellingen kunnen te werk gaan met opeenvolgende afgiften voor een welbepaalde rapporteringsdatum, met inachtneming van de limietdata die voor de gezamenlijke portfoliotabellen zijn vastgelegd. Voor de individuele portfoliotabellen evenwel mogen, behoudens verzoek of toelating van de Nationale Bank van België, geen nieuwe versies meer opgestuurd worden nadat de CSSR deze tabellen als correct beschouwd heeft. Indien echter een nieuwe versie van de actiefstaat, passiefstaat of buiten balansstaat opgestuurd wordt zal een hervalidatie van de portfoliotabellen gebeuren en dient de kredietinstelling zonodig nieuwe portfoliotabellen over te maken.

3 NOODOPLOSSING BIJ DEFECT VAN DE CSSR

3.1 INGEBRUIKNEMING

Als noodoplossing kan, na overleg met het contactpunt Statistieken, gebruik worden gemaakt van diskettes als de CSSR defect blijkt te zijn.

3.2 FORMAAT VAN DE GEGEVENS

De gegevens dienen geleverd te worden volgens het formaat XML.

3.3 VERTROUWELIJKHEID EN ONWEERLEGBAARHEID

Teneinde de vertrouwelijkheid en de onweerlegbaarheid van de gegevens te waarborgen, zullen de ondertekening en de encryptie van de gegevens door middel van het certificaat en de software ad hoc nodig zijn opdat ze aanvaard kunnen worden. In geval van problemen bij bv. encryptie kan, na overleg, van deze standaardprocedure afgeweken worden.

3.4 PROCEDURE

3.4.1 AANBIEDING

De diskette moet in een kartonnen hoes verpakt zijn. De volgende vermeldingen moeten op de hoes en de diskette voorkomen:

3.

de code van de kredietinstelling : BIC CODE de code van de toepassing : "PORTFOLIO" de creatiedatum : DDMMYYYY het volgnummer :

Er mag geen enkele andere vermelding op voorkomen.

3.4.2 KOPIE

De kredietinstelling moet een kopie van de inhoud van de diskette bewaren. Deze kopie moet volgens de procedure hierboven ten spoedigste opgestuurd worden mocht het origineel onleesbaar blijken te zijn.

3.4.3 INDIENING

De diskettes, gericht aan de Dienst Betalingsbalans, afdeling Portfolio-enquête, moeten per bode gebracht worden naar de Nationale Bank van België, de Berlaimontlaan 14, 1000 Brussel. Het afgifteborderel (zie bijlage 3) wordt in 2 exemplaren opgesteld. Het eerste wordt door de dienst Betalingsbalans van de Nationale Bank van België bewaard ; exemplaar nummer 2 wordt bij de afgifte van de informatiedrager aan de bode teruggegeven als ontvangstbewijs. Na het lezen van de magnetische informatiedrager gaat de Nationale Bank van België na of het borderel en de inhoud overeenstemmen. Op het afgifteborderel komen het nummer van de informatiedrager en zijn creatiedatum voor. Als twee magnetische informatiedragers op dezelfde datum gecreëerd zijn, dient het nummer van de informatiedragers te verschillen. De creatiedatum en het nummer van de informatiedrager dienen op deze laatste te worden vermeld.

3.4.4 KALENDER

De kalender voor de afgiften via de CSSR is strikt van toepassing voor de indiening via de noodprocedure.

4 VALIDERING

De gegevens, zoals ze door de kredietinstellingen afgegeven worden, zullen worden gevalideerd alvorens ze door de Nationale Bank van België worden aanvaard.. De standaardvalideringsregels worden ter beschikking van de gebruikers gesteld in een document met de naam "Valideringsregels van toepassing op de portfoliotabellen van de kredietinstellingen".

5 HET CORRECTIEPROCES

De Nationale Bank van België behandelt de door de kredietinstellingen verstrekte gegevens door middel van de valideringsprogramma's. Als uit die behandeling fouten blijken die geen afbreuk doen aan de meegedeelde gegevens, bezorgt de Dienst Betalingsbalans van de Nationale Bank van België aan de betrokken kredietinstelling een lijst van de ontdekte fouten, opdat de kredietinstelling de nodige correcties kan aanbrengen, wat kan gebeuren:

door de indiening van de verbeterde gegevens via de CSSR, telefonisch (gevolgd door een schriftelijke bevestiging) voor een beperkt aantal correcties.

4.

De correcties van de tabellen moeten binnen een termijn van ten hoogste 1 Belgische bankwerkdag ingediend worden.

6 KWALITEITSCONTROLE

Teneinde zich van de intrinsieke kwaliteit van de gegevens te vergewissen, gaat de Nationale Bank van België over tot een kwaliteitscontrole op bepaalde posten van de portfoliotabellen. Die controles dienen voor het opsporen van afwijkingen. In voorkomend geval wordt met de kredietinstelling in contact getreden om een afwijking toe te lichten. Indien de afwijking voortkomt uit foutieve gegevens, dan wordt de kredietinstelling verzocht, de desbetreffende gegevens te verbeteren volgens de hierboven uiteengezette procedure.

7 NIET-NALEVING VAN DE REGELS EN SANCTIES

De gegevens worden door de Nationale Bank van België ingezameld en gebruikt in toepassing van de wet van 28 februari 2002 met betrekking tot het opstellen van de betalingsbalans en van de externe vermogenspositie van België.. De tekst van deze wet en van de besluiten en reglementen genomen ter uitvoering ervan zijn beschikbaar op de internetsite www.betalingsbalans.be. Om een correcte uitvoering van de statistische opdrachten te waarborgen die de wetgever heeft toevertrouwd aan de Nationale Bank van België werd de mogelijkheid overwogen dat een gegevensverstrekker zich onttrekt aan zijn verplichtingen en werd, naast boetes, een procedure voor uitvoering van ambtswege voorzien op kosten van de gegevensverstrekker die in gebreke blijft.

8 DE CODERINGEN

8.1 KREDIETINSTELLINGEN

De kredietinstellingen worden volgens de BIC-norm van S.W.I.F.T. gecodeerd op het blad waarmee elke portfoliotabel wordt ingevoerd. De kredietinstellingen die geen BIC-code hebben, worden verzocht er een aan te vragen bij S.W.I.F.T.: SOCIETY FOR WORLDWIDE INTERBANK FINANCIAL TELECOMMUNICATIONS S.C. Bank Support Division BIC-Administration Adèlelaan 1 1310 Terhulpen Tel. : 02/655.31.11 Fax : 02/655.30.09

8.2 LANDEN EN MUNTEN

De landen en munten worden volgens de ISO-standaarden gecodeerd (onder voorbehoud van toekomstige evoluties)

Land ISO 3166 - 2 posities de X-codes volgens de site van de NBB: www.nbb.be/dq/N/dq6/bop_n/countryN.htm

5.

Munten

ISO 4217 - 3 posities de X-codes volgens de site van de NBB: www.nbb.be/dq/N/dq6/bop_n/moneyN.htm behalve: USN, USS, XFO, XFU, XRE, XXX

8.3 EFFECTEN

8.3.1 PRIORITAIR GEBRUIK VAN DE ISIN-CODE

Voor het coderen van de effecten dient de ISIN-code (ISO 6166) gebruikt te worden. Indien geen ISIN-code bestaat mag een ander codetype gebruikt worden (zie bijlage 4). Bij gebrek aan enige code zijn blanco's toegelaten. Het gebruikte codetype moet geïdentificeerd worden (zie bijlage 4). Voor nieuwe codetypes dienen de eerste 2 karakters van de benaming opgegeven te worden. Blanco's zijn toegelaten wanneer geen enkele code is opgegeven.

8.3.2 AANVRAAG VAN EEN ISIN-CODE

De kredietinstellingen die geen ISIN-code voor de effecten hebben, worden verzocht deze bij Nextinfo (voorheen het Secretariaat voor Effecten) aan te vragen of bij de beschrijving van het effect alle specificaties te vermelden die voor het coderen ervan door Nextinfo nodig zijn, zodat de Nationale Bank van België de aanvraag in naam en voor rekening van de betrokken kredietinstelling kan verrichten.

NEXTINFO N.V. Beurspaleis Beursplein 1 1000 Brussel Tel. : 02/509.94.35 Fax : 02/509.12.26

Elke aan Nextinfo gerichte aanvraag om een ISIN-code moet vergezeld zijn van de beschrijving van de effecten en van de verhandelbare waarden die het voorwerp van de aanvraag zijn.

(a) Voor de rentedragende roerende waarden en verhandelbare effecten dient de beschrijving

minstens de volgende specificaties te bevatten:

1. volledige benaming van de kredietnemer; 2. nationaliteit van de kredietnemer (indien Belgische, het volledige adres vermelden); 3. soort lening (b.v obligatielening, warrantlening, kasbon ... ); 4. munt van uitgifte; 5. jaar van uitgifte; 6. jaar van terugbetaling; 7. datum van betaling van de coupons/interesten; 8. waarde van de vaste rentevoet of bepaling van de variabele rentevoet.

(b) Voor de niet-rentedragende deelbewijzen en roerende waarden dienen tenminste de volgende

inlichtingen te worden meegedeeld:

1. benaming van de emittent; 2. nationaliteit van de emittent (indien Belgische, het volledige adres vermelden); 3. soort emissie (b.v. aandeel, participatie... ); 4. munt van uitgifte; 5. datum van oprichting van de emitterende vennootschap.

6.

8.3.3 UITGIFTE VAN EFFECTEN

Voor elke uitgifte van effecten door een kredietinstelling moet deze laatste bij Nextinfo een ISIN-code aanvragen. Als de kredietinstelling op autonome wijze ISIN-codes toewijst die geput worden uit de reeks van codes die Nextinfo haar heeft toegewezen, moet de instelling onmiddellijk Nextinfo inlichten over de voornoemde specifieke eigenschappen van elk effect waaraan zij een ISIN-code toegewezen heeft.

8.3.4 EVENTUEEL GEBRUIK VAN DE FICTIEVE ISIN-CODE (ENKEL VOOR SOMMIGE BUITENLANDSE EFFECTEN EN VOOR BELGISCHE KAS- EN GROEIBONS )

8.3.4.1 Voorwaarden om de fictieve ISIN-code te gebruiken

De buitenlandse effecten die, volgens usantie, geen ISIN-code dragen, worden ondergebracht in fictieve ISIN-codes. Voor die effecten wordt per categorie, hierna gedefinieerd, een fictieve code gebruikt om het gegroepeerde bedrag in onder te brengen. Deze mogelijkheid is van toepassing voor buitenlandse effecten uitgegeven door niet-financiële ondernemingen en financiële ondernemingen andere dan kredietinstellingen. De Nationale Bank van België mag bij de rapporterende instelling de nominatieve lijst van de effecten opvragen die gegroepeerd worden in een fictieve code. Belgische kas- en groeibons, met of zonder kapitalisatie en vervallen coupons van kas- en groeibons met facultatieve kapitalisatie worden onder een algemene fictieve ISIN-code vermeld (zie bijlage 5).

8.3.4.2 Structuur van de fictieve ISIN-code voor buitenlandse effecten

De fictieve ISIN-code zal de volgende vorm hebben: FFNXXMMMTTTC met FF fictieve code N code voor type-emittent (tijdelijk steeds = 1 voor de niet-financiële ondernemingen of 2 voor

de financiële ondernemingen andere dan kredietinstellingen) XX ISO-code land (ISO 3166) MMM ISO-code munt (ISO 4217) van de emissie (voor de vastrentende effecten) of van het kapitaal

van de emitterende vennootschap (voor de waarden met variabel inkomen) TTT cijfercode die het type van effect bepaalt (cf. hierna) C check-digit Type van effecten (TTT) : “002” : Effecten op lange termijn (> 1 jaar) “020” : Effecten op korte termijn (< of = 1 jaar) “007” : Aandelen “009” : Warrants “029” : Rechten van deelneming / aandelen van

beleggingsinstellingen “039” : Asset Backed Securities / Mortgage Backed Securities

Bijlage 1

DEFINITIE VAN DE PORTFOLIOTABELLEN

Nummers van de tabellen Definitie van de portfoliotabellen*

04.90 t/m 04.92 Gedetailleerde inventaris van de baissepositie effecten

04.93 t/m 04.95 Gedetailleerde inventaris van de uitgegeven effecten

05.90 t/m 05.92 Gedetailleerde inventaris van de effecten in buiten balans

* De tabellen 03.90 tot en met 03.99 (activa of haussepositie) mogen volgens dit XML-formaat

afgeleverd worden mits voldaan wordt aan de voorwaarden uit het protocol over de afgifte van de periodieke staten (SCHEMA A).

Bijlage 2

AFGIFTEKALENDER

Territoriale basis (1)

Vennootschap- pelijke basis

(2)

Geconsoli-deerde basis

(3) Kredietinstellingen onder-

worpen aan de snelle rapportering voor de E.C.B.

Andere krediet-

instellingen

Portfoliotabellen Maandelijkse tabellen 04.90 t/m 04.92 11 b.w.d. 25 k.d. /////////////// /////////////// 04.93 t/m 04.95 11 b.w.d. 25 k.d. /////////////// /////////////// 05.90 t/m 05.92 11 b.w.d. 25 k.d. /////////////// ///////////////

Legende : b.w.d. Belgische bankwerkdagen / k.d. : kalenderdagen

(1) Voor de monetaire statistieken ten behoeve van de ECB wordt enkel de territoriale basis geviseerd (i.e. de basis 10 volgens de Schema A-terminologie). De

kredietinstellingen met kantoren in het buitenland rapporteren over de vennootschappelijke positie door afzonderlijke tabellen op te stellen enerzijds voor de territoriale positie (positiecode 10) en anderzijds voor de positie van het geheel van de buitenlandse kantoren (positiecode 19).

(2) I.e. de basis 20 volgens de Schema A-terminologie. (3) I.e. de basis 30 volgens de Schema A-terminologie.

Bijlage 3

Portfoliotabellen : Afgifteborderel Kredietinstelling (BIC-code) : | | | | | | | | | | | | Rapporteringsdatum1 : | | | | | | | | | | | In te vullen Creatiedatum1 : | | | | | | | | | | | Nummer van de informatiedrager : | | | | | | |

°°°°°°°°°°° Naam van de kredietinstelling : ................................................................. Naam van de verantwoordelijke : ............................................ tel............... nr......... Handtekening voor ontvangst Handtekening van de afgever ........................................ ........................................ Ontvangstdatum2 | | | | | | | | | | |

1 Volgens jjjj mm dd - formaat. 2 Voorbehouden aan de NBB.

Bijlage 4/1

LIJST VAN AANVAARDE CODETYPES

Tabel 4.1 - ISIN-codes en aanverwante codes

Nummer codetype Naam Omschrijving Verantwoordelijke instelling Structuur

01 ISIN Internationale standaard Association of National Numbering Agencies (ANNA) en national numbering agencies

12 karakters: 2 alfabetische en 10 numerieke, w.v. de laatste een check digit is m.b.t. de eerste 11 karakters

02 COMMON Gemeenschappelijke code voor Euroclear Bank en Clearstream Bank Euroclear Bank en Clearstream Bank

eerste 9 numerieke karakters uit de 10 numerieke karakters van de ISIN-code (zonder de check digit)

03 SVM - SRW Vroegere Belgische standaard voor in België uitgegeven effecten

Secretariaat van de roerende waarden

8 karakters waarvan 6 numerieke en de check digit "modulus 97"

04 SEDOL 1 "Stock Exchange Daily Official List" is een code voor de identificatie van effecten in de UK en Ierland

London Stock Exchange 7 numerieke karakters

05 SEDOL 2 "Stock Exchange Daily Official List" is een code voor de identificatie van effecten in de UK en Ierland

London Stock Exchange 7 numerieke karakters

Bijlage 4/2

Tabel 4.2 - Internationale codes die niet aan de ISIN-code gerelateerd zijn

Nummer codetype Naam Omschrijving Verantwoordelijke instelling Structuur

21 CUSIP Gebruikt door de "US finance industry" voor effecten, uitgegeven of verhandeld binnen de US en CA

Standard & Poor's, New York 9 alfanumerieke karakters

22 CINS

"Cusip International Numbering System" wordt door de "US-finance industry" gebruikt voor effecten, uitgegeven of verhandeld buiten de US en CA.

Standard & Poor's, New York 9 alfanumerieke karakters

23 BLO (nog aan te duiden) Bloomberg, New York (nog aan te duiden)

24 ISM (nog aan te duiden) ISMA, London (nog aan te duiden)

25 RIC Reuters Identification Code Reuters Data Center, London max. 18 alfanumerieke karakters

26 TK "Valoren" is een Zwitserse standaard voor uitgegeven effecten Telekurs max. 7 numerieke karakters

Bijlage 4/3

Tabel 4.3 - Andere codes

Nummer codetype Naam Omschrijving Verantwoordelijke instelling Structuur

41 SIS "Securities information system" is een Belgische standaard voor uitgegeven effecten

Secretariaat van de roerende waarden

9 karakters waarvan 7 numerieke en de check digit "modulus 97"

42 WKN "Wertpapierkennummer" is een Duitse standaard voor uitgegeven effecten Kassenverein 6 alfanumerieke karakters

43 SVN "Valoren" is een Zwitserse standaard voor uitgegeven effecten

Telekurs 7 alfanumerieke karakters

Bijlage 5

LIJST VAN FICTIEVE ISIN-CODES VOOR KAS- EN GROEIBONS

Op ten hoogste één jaar Op meer dan één jaar

Zonder

kapitalisatie FF06MAXI01Y6 FF06OVER01Y9

Met facultatieve

kapitalisatie FF06FACUCAP3

Met automatische

kapitalisatie FF06AUTOCAP9

Vervallen coupons van kas- en

groeibons met facultatieve kapitalisatie

FF06EXPCOUP1

__________________________

Portfolio

Revision HistoryRevision 1.0 1 Sep 2004

Table of Contents1. Introduction ............................................................................................................................ 12. Comparision with Schema A reporting protocol ............................................................................. 23. XML Schema .......................................................................................................................... 2

3.1. Some general definitions ................................................................................................. 23.1.1. Schema A Rubric ................................................................................................ 2

3.1.1.1. Description ............................................................................................. 23.1.1.2. Schema Definition .................................................................................... 23.1.1.3. Details ................................................................................................... 3

3.1.2. Column ............................................................................................................. 33.1.2.1. Description ............................................................................................. 33.1.2.2. Schema Definition .................................................................................... 33.1.2.3. Details ................................................................................................... 3

3.2. Portfolio definitions ....................................................................................................... 33.2.1. Portfolio Dataset ................................................................................................. 3

3.2.1.1. Description ............................................................................................. 33.2.1.2. Schema Definition .................................................................................... 33.2.1.3. Details ................................................................................................... 4

3.2.2. A portfolio table ................................................................................................. 43.2.2.1. Description ............................................................................................. 43.2.2.2. Schema Definition .................................................................................... 43.2.2.3. Details ................................................................................................... 4

3.2.3. Definition of a reported cell .................................................................................. 53.2.3.1. Description ............................................................................................. 53.2.3.2. Schema Definition .................................................................................... 63.2.3.3. Details ................................................................................................... 6

3.2.4. Sequential number .............................................................................................. 63.2.4.1. Description ............................................................................................. 63.2.4.2. Schema Definition .................................................................................... 73.2.4.3. Details ................................................................................................... 7

4. All XML Schema definitions together .......................................................................................... 75. Example Delivery .................................................................................................................... 8

1. IntroductionThe reporting for the 'Portfolio Survey' is done via the Central Server for Statistical Reporting (CSSR).

At the moment of this writing, it will consist of the tables 039x, 049x and 059x (anno 2004). In the future it is pos-sible that based on this protocol additional tables are added to the 'Portfolio Survey'.

In this document only specific information related to the reporting itself is described. For general information aboutusage and functionality of CSSR, we refer to the website and the documentation of the CSSR workgroup. 1

1

Bijlage 6

1this documentation can be obtained by contacting the team resposible for the technical implementation of CSSR at the NBB, see CSSRGuidelines on NBB website [http://www.nbb.be/dq/n/dq8/Readme_cssr.htm]

To give a quick summary, a cssr document is divided into two parts :

• Admin part : containing definitions to control the processing of the transfer. This part is independend of the re-porting it contains

• Content part : an application specific part containing the actual data to report

It is the content part that is further described in this document.

The first section will describe the XML Schema at which the <content> element of the XML document must satis-fy. Small examples will be given with their associated definition of the part it highlights. The second section givesthe complete XML Schema, followed by a last section with an example of a valid cssr document containing a fic-tional delivery of this reporting.

2. Comparision with Schema A reporting protocolAnno 2004, the financial institutions report already portfolio tables (039x) as part of the Schema A reporting. Thisprotocol is based on it and will correspond exactly with it, taking the following differences into account.

• Because the amounts are expressed in the currency unit of the security, as reported in the data, or in EUR if notapplicable, the attribute cbrk is omitted on the <table> tag.

• The portfolio is a reporting where rubric is just a sequential numbering to identify a reported item. Because ofthis uniformity in the portfolio, the attribute dyn is also deleted.

• Different content type, instead of SfiAcquisitionDataset it will be PrtAcquisitionDataset

3. XML SchemaNote

This schema needs definitions defined elsewhere in CSSR.

3.1. Some general definitionsThe following types are defined.

3.1.1. Schema A Rubric

3.1.1.1. Description

Schema A rubric Code

3.1.1.2. Schema Definition

<xsd:simpleType xmlns:xsd="http://www.w3.org/2001/XMLSchema"name="SfiTableRubric">

Portfolio

2

<xsd:restriction base="xsd:string"><xsd:pattern value="[0-9,A-Z]{1,6}" />

</xsd:restriction></xsd:simpleType>

3.1.1.3. Details

Restriction based on xsd:string

3.1.2. Column

3.1.2.1. Description

Column Code

3.1.2.2. Schema Definition

<xsd:simpleType xmlns:xsd="http://www.w3.org/2001/XMLSchema"name="SfiTableColumn"><xsd:restriction base="xsd:string">

<xsd:pattern value="[0-9,A-Z]{1,3}" /></xsd:restriction>

</xsd:simpleType>

3.1.2.3. Details

Restriction based on xsd:string

3.2. Portfolio definitionsThe following types are defined.

3.2.1. Portfolio Dataset

3.2.1.1. Description

Definition of a portfolio dataset containing the tables to report

The <content> element.

<content xsi:type="PrtAcquisitionDataset"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="http://www.nbb.be/cssr">the table elements

</content>

3.2.1.2. Schema Definition

<xsd:complexType xmlns:xsd="http://www.w3.org/2001/XMLSchema"name="PrtAcquisitionDataset"><xsd:complexContent>

<xsd:extension base="cssr:Content">

Portfolio

3

<xsd:sequence><xsd:element name="table" type="cssr:PrtAcquisitionTable"

maxOccurs="unbounded" /></xsd:sequence>

</xsd:extension></xsd:complexContent>

</xsd:complexType>

3.2.1.3. Details

Content : complex

Inheriting elements and attributes from the definition of cssr:Content

Content : a sequence of

name type min max description

table cssr:PrtAcquisitionTable 1 N

3.2.2. A portfolio table

3.2.2.1. Description

A table is the minimal unit of reporting, so when one cell must be updated the complete table must be send again.

<table> element

<table per="2006-05" tblnr="0490" bas="10" nihil="false">... cell elements ...</table>

<table> element for a nihil declaration

<table per="2006-05" tblnr="0493" bas="10" nihil="true" />

3.2.2.2. Schema Definition

<xsd:complexType xmlns:xsd="http://www.w3.org/2001/XMLSchema"name="PrtAcquisitionTable"><xsd:sequence>

<xsd:element name="cell" type="cssr:PrtCell" minOccurs="0"maxOccurs="unbounded" />

</xsd:sequence><xsd:attribute name="per" type="xsd:gYearMonth" use="required" /><xsd:attribute name="tblnr" type="cssr:SfiTableNumber" use="required" /><xsd:attribute name="bas" type="cssr:SfiBase" use="required" /><xsd:attribute name="nihil" type="xsd:boolean" default="false" />

</xsd:complexType>

3.2.2.3. Details

Portfolio

4

Attributes

name type required defaultvalue

description

per xsd:gYearMonth YesReporting period to where the data refers to

tblnr cssr:SfiTableNumber Yes

bas cssr:SfiBase Yes

nihil xsd:boolean No falseUsed to denote that the table is a nihil declara-tion (true) or not (false). For a nihil declarationno cells may be reported.

Content : a sequence of

name type min max description

cell cssr:PrtCell 0 N

3.2.3. Definition of a reported cell

3.2.3.1. Description

The cell is the smallest unit inside a table, to report. It corresponds to a single value

The <cell> element contains a value to report. Any alphanumerical string is allowed although some restriction ap-plies which are defined in the application. Its format depends on the actual datatype expected for the indicatedcolumn and table.

The following table describes the possible datatypes. The format of the datatypes which corresponds to a definitionin the XML Schema standard, are identical to the format described there.

XML Schema/data type Description Example

string a finite sequence of characters. Onlycharacters defined in the "ASCII ex-tended character set" are accepted

decimalA real number with in theory infiniteprecision

A point will be used as decimaleseperator and no grouping characterwill be used to seperate thousands

When according to the definition ofthe table, more decimals are reportedthen defined, they will be truncated.

• 210

• 12667.543

• -1.23

• +1000.00

schema A rubric see cssr:SfiTableRubric 1113

currency code see cssr:SfiCurrency USD

Note

Portfolio

5

In the validation process, based on the definition of the indicated column, restriction are applied on the ac-tual maximal length of a string and the number of significant digits and the scale in case of a decimal.When a decimal is reported with less precision then the one expected according to the column definition,zeros are assumed for the higher precision digits. For example 1.1 will be treated as 1.1000... .

Some examples of the <cell> element :

<cell rub="1" col="005">13211</cell>

<cell rub="1" col="040">USD</cell>

<cell rub="1" col="060">1986453</cell>

3.2.3.2. Schema Definition

<xsd:complexType xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="PrtCell"><xsd:simpleContent>

<xsd:extension base="xsd:string"><xsd:attribute name="rub" type="cssr:PrtSeqNumber" use="required"

/><xsd:attribute name="col" type="cssr:SfiTableColumn"

use="required" /></xsd:extension>

</xsd:simpleContent></xsd:complexType>

3.2.3.3. Details

Content : simple

Inheriting elements and attributes from the definition of xsd:string

Attributes

name type required defaultvalue

description

rub cssr:PrtSeqNumber YesSequential code

col cssr:SfiTableColumn YesColumn Code

Any missing zero will be added until thecolumn code consit of 3 characters, so for ex-ample reported column code 15 will be treatedas 015.

3.2.4. Sequential number

3.2.4.1. Description

Portfolio

6

2in other words it is defined by xmlns:xsd="http://www.w3.org/2001/XMLSchema

Identification

For example 1, 2, 3, ...

Gaps between the numbering is allowed, its only purpose is to uniquely identify a reported item

3.2.4.2. Schema Definition

<xsd:simpleType xmlns:xsd="http://www.w3.org/2001/XMLSchema"name="PrtSeqNumber"><xsd:restriction base="xsd:integer">

<xsd:minExclusive value="0" /></xsd:restriction>

</xsd:simpleType>

3.2.4.3. Details

Restriction based on xsd:integer

4. All XML Schema definitions togetherThe following XML Schema contains all definitions for the content part of a 'Portfolio Reporting'.

References to types for which the prefix is xsd, refers to the one made in the XML Schema specifications. 2

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"attributeFormDefault="unqualified" elementFormDefault="qualified"targetNamespace="http://www.nbb.be/cssr"><xsd:simpleType name="SfiTableRubric">

<xsd:restriction base="xsd:string"><xsd:pattern value="[0-9,A-Z]{1,6}" />

</xsd:restriction></xsd:simpleType><xsd:simpleType name="SfiTableColumn">

<xsd:restriction base="xsd:string"><xsd:pattern value="[0-9,A-Z]{1,3}" />

</xsd:restriction></xsd:simpleType><xsd:complexType name="PrtAcquisitionDataset">

<xsd:complexContent><xsd:extension base="cssr:Content">

<xsd:sequence><xsd:element name="table" type="cssr:PrtAcquisitionTable"

maxOccurs="unbounded" /></xsd:sequence>

</xsd:extension></xsd:complexContent>

</xsd:complexType><xsd:complexType name="PrtAcquisitionTable">

<xsd:sequence><xsd:element name="cell" type="cssr:PrtCell" minOccurs="0"

maxOccurs="unbounded" /></xsd:sequence><xsd:attribute name="per" type="xsd:gYearMonth" use="required" /><xsd:attribute name="tblnr" type="cssr:SfiTableNumber" use="required"

/>

Portfolio

7

<xsd:attribute name="bas" type="cssr:SfiBase" use="required" /><xsd:attribute name="nihil" type="xsd:boolean" default="false" />

</xsd:complexType><xsd:complexType name="PrtCell">

<xsd:simpleContent><xsd:extension base="xsd:string">

<xsd:attribute name="rub" type="cssr:PrtSeqNumber"use="required" />

<xsd:attribute name="col" type="cssr:SfiTableColumn"use="required" />

</xsd:extension></xsd:simpleContent>

</xsd:complexType><xsd:simpleType name="PrtSeqNumber">

<xsd:restriction base="xsd:integer"><xsd:minExclusive value="0" />

</xsd:restriction></xsd:simpleType>

</xsd:schema>

5. Example DeliveryThe following example is pure fictional and is not complete. It just demonstrates how cell values must be reported.

<cssr_document xmlns="http://www.nbb.be/cssr"><admin creation_time="2006-04-05T10:20:00.000">

<sender vat="1234567890"><contact>

<name>Mr. X</name><communication

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:type="Email" address="[email protected]" />

<communicationxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:type="Telephone" number="02/987.654.32" />

</contact></sender><receiver bic="NBBBEBB" /><processing_parameters>

<email_response>[email protected]</email_response><transform_response>true</transform_response><test>false</test>

</processing_parameters><description>This is a user-description of the delivery</description>

</admin><content xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:type="PrtAcquisitionDataset"><table per="2006-03" tblnr="0490" bas="10" nihil="true" /><table per="2006-03" tblnr="0492" bas="10">

<cell rub="1" col="005">13211</cell><cell rub="1" col="010">BE0365251744</cell><cell rub="1" col="011">ISIN</cell><cell rub="1" col="015">DT/PC 19/08/11</cell><cell rub="1" col="025">1920</cell><cell rub="1" col="040">EUR</cell><cell rub="1" col="060">8591</cell><cell rub="1" col="070">9865</cell><cell rub="1" col="071">1</cell><cell rub="2" col="005">13211</cell><cell rub="2" col="010">BE0165251841</cell>

Portfolio

8

<cell rub="2" col="011">ISIN</cell><cell rub="2" col="015">DF/SD 19/02/15</cell><cell rub="2" col="025">946</cell><cell rub="2" col="040">EUR</cell><cell rub="2" col="060">6565</cell><cell rub="2" col="070">4646</cell><cell rub="2" col="071">1</cell>

</table></content>

</cssr_document>

Portfolio

9