Rabo Direct Connect. Handleiding

Transcriptie

1 Rabo Direct Connect Handleiding November 2017

2 Inhoud 1. INLEIDING Mogelijkheden 4 Formaten 5 Randvoorwaarden voor gebruik 5 2. HET INRICHTEN VAN RDC VOOR GEBRUIK Het Inrichtingsformulier RDC 6 Het wijzigen of beëindigen van de overeenkomst 6 Het tot stand brengen van de sftp verbinding met de Rabobank 6 Het ondertekenen van betaalbestanden 6 PKCS#7 7 Het creëren van een certificaat voor ondertekening 7 Het verifiëren van de bestanden van Rabobank 8 Test scenario s 8 Het testen van de sftp verbinding 8 Het testen via de Klant Acceptatie Omgeving 9 Het testen in productie middels penny tests 9 Go Live beslissing 9 Serviceberichten 9 3. DE KLANT ACCEPTATIE OMGEVING Beschrijving van de Klant Acceptatie Omgeving 10 Wat kunt u testen met de Klant Acceptatie Omgeving 10 Technische test 10 Testen statusinformatie PAIN.001 en PAIN Testen statusinformatie BTL91 10 Testen van betaalformaten 11 Testen verantwoordingsinformatie 11 Aanvragen Klant Acceptatie Omgeving (KAO) 11 Zelf ondertekend certificaat 11 Disclaimer INITITATIE Het initiëren van een incasso- of betaalopdracht 13 Het initiatiebestand De header file Controle De payload file ZIP archive DEFLATE 15 De initiatie stap voor stap 15 Wat kunt u verwachten indien er iets niet goed gaat? 16 2

3 4.6 Uitvoerdata en geagendeerde betalingen STATUS BERICHTEN EN VERANTWOORDING ACK/NACK Statusberichten 18 PAIN.002 status berichten 19 Verantwoordingsinformatie 19 Directe verantwoording stap voor stap 21 Bundeling verantwoordingsinformatie 21 Intradag rapportage 22 Intradag huidige boekdag 22 Intradag boekdag overschrijdend 22 Formaat 23 Vergelijkingstabel aanlevervarianten intradagrapporten AGENDEREN, INTREKKEN EN TEKENEN Inrichten Overeenkomst RIB Pro 25 Functionaliteiten RIB Pro 25 Agenderen 25 Intrekken 25 Tekenen PRODUCTBEELD ONDERSTEUNING EN SERVICE Contact gegevens 27 Noodprocedure blokkeren verbinding RDC 27 APPENDIX 1: AFKEURREDENEN 28 APPENDIX 2. CHECKLIST SIGNING 32 Verify your own signature of type RAW with openssl: 32 Verify your own signature of type PKCS#7 with openssl: 32 APPENDIX 3: RANDVOORWAARDEN RABO INTERNETBANKIEREN PROFESSIONAL 33 APPENDIX 4: CERTIFICATE GENERATION STEP-BY-STEP 34 Setup for first use 34 A) Generate a self-signed certificate for use in the Customer Acceptance environment 35 B) Generate a Certificate Signing Request (CSR) for signing by a Certificate Authority 36 Extracting the certificate and private key 37 APPENDIX 5. LOGBOEK WIJZIGINGEN 38 3

4 1. Inleiding Rabo Direct Connect (RDC) is een host to host oplossing voor Financial Institutions, Large Corporates en Grootzakelijke Klanten van de Rabobank. Met RDC kunnen betaalbestanden uitgewisseld worden met de Rabobank. Via dit kanaal kan een klant vanuit zijn ERP-pakket bestanden met getekende opdrachten insturen en laten verwerken door de Rabobank. Voor het gebruik van het kanaal is dus geen gebruikersinterface nodig. De verantwoordingsinformatie kan direct worden uitgelezen in het ERP-pakket. Via een PULL mechanisme kunt u deze als klant ophalen uit RDC. 1.1 Mogelijkheden Hieronder vindt u een opsomming van de verschillende mogelijkheden van RDC. Insturen van opdrachten kan in de volgende formaten: BTL 91 Wereldbetalingen, Spoedbetalingen PAIN Euro-incasso s PAIN meerdere opdrachttypen mogelijk: o Eurobetalingen: opdrachten in de muntsoort EUR naar een begunstigde in een SE- PA land. o Spoed Binnenland Eurobetalingen: spoedopdrachten in de muntsoort EUR tussen Nederlandse rekeningnummers. o Spoed Eurobetalingen: spoedopdrachten in de muntsoort EUR naar een begunstigde in een SEPA-land o Wereldbetalingen: opdrachten naar een begunstigde in een niet-sepa land, in elke mogelijke muntsoort (ook EUR). Het is mogelijk om een PAIN.001-bestand aan te leveren met een mix van batches met verschillende typen betaalopdrachten. Dit noemen we een Generic Payment File en moet aan de volgende voorwaarden voldoen: één debetrekening per batch een batch bevat òf alleen Eurobetalingen (exclusief Spoed) òf alleen Spoed en/of Wereldbetalingen Statusinformatie ontv angt u in de volgende formaten: ACK/NACK: ACK betekent goedgekeurd; NACK betekent afgekeurd. Statusbericht: PAIN (bevat afgekeurde of geweigerde betaal- of incasso-opdrachten) Verantwoordingsinformatie kunt u in de volgende formaten ontvangen: Dagafschrift einde dag: MT940 Structured Dagafschrift einde dag: CAMT Intradag rapportage: MT942 Structured Intradag rapportage: CAMT

5 1.2 Formaten Van alle bovenstaande bestanden zijn formaatbeschrijvingen beschikbaar. Deze formaatbeschrijvingen voor RDC kunt u terugvinden op: Randvoorwaarden voor gebruik Voordat u aan de slag kunt gaan met RDC zijn de onderstaande randvoorwaarden belangrijk. Indien u als klant niet kunt voldoen aan onderstaande voorwaarden, kunt u niet alle voordelen van RDC volledig benutten.tevens kan er geen optimale service worden geboden. Houdt hier rekening mee wanneer u voor dit product kiest. Binnen uw bedrijf is een hoge mate van automatisering aanwezig. Binnen uw bedrijf is een professionele IT omgeving en goede infrastructuur aanwezig. Er is een hoge mate van treasury centralisatie binnen uw bedrijf. Er is een gecentraliseerde AP/AR (SSC of payment factory). Voor het gebruik (waaronder de beveiliging) van Rabo Direct Connect is permanent beschikbare professionele ICT (beveiligings)deskundigheid bij uw bedrijf noodzakelijk. 5

6 2. Het inrichten van RDC voor gebruik 2.1 Het Inrichtingsformulier RDC Op het Inrichtingsformulier RDC (beschikbaar via uw Rabobank contactpersoon) kunt u aangeven hoe u de RDC overeenkomst wilt inrichten. Denk hierbij aan: Welke Rabobank rekeningen u wilt gebruiken in combinatie met RDC (het is ook mogelijk om eindedag- of intradaginformatie van een spaarrekening te ontvangen) Het type verantwoordingsinformatie dat u wenst te ontvangen Of u intradag rapportages wilt ontvangen en met welke interval/op welke tijdstippen Het type initiatiebestanden dat u wenst in te sturen Op welk adres u uw RDC service berichten wilt ontvangen Het is belangrijk dat u de inhoud van dit formulier goed afstemt met de Rabobank. Indien u hulp nodig heeft bij het invullen van dit formulier kunt u gebruik maken van het bijbehorende toelichtingsformulier in afstemming met uw Rabobank contactpersoon. 2.2 Het wijzigen of beëindigen van de overeenkomst U kunt uw RDC overeenkomst ook wijzigen door gebruik te maken van het Inrichtingsformulier. Hierop kunt u dan aangeven dat u een wijziging wilt doorgeven en vervolgens kunt u deze wijziging in het formulier vermelden. Het is ook mogelijk om de overeenkomst te beëindigen via dit formulier. In het toelichtingsformulier wordt duidelijk uitgelegd hoe een wijziging of beëindiging moet worden aangegeven. Leest u deze bij onduidelijkheden eerst door. 2.3 Het tot stand brengen van de sftp verbinding met de Rabobank De eerste stap die gezet moet worden is het inrichten van de secure FTP (sftp) verbinding met de Rabobank. sftp is een Secure Shell (SSH) verbinding over één poort waarbij inloggen en versturen van bestanden in een veilige sessie plaatsvinden. Het aanmaken van een sftp-verbinding is programmatuur die soms standaard op een server platform beschikbaar is. Zo niet, dan moet het worden geïnstalleerd. Dit onderdeel faciliteert een veilig transport van bestanden tussen uw organisatie en Rabobank en bestaat altijd uit een test- en productieverbinding. Voor deze verbinding moet u beschikken over een sftp client. Hierin genereert u twee SSH keys waarvan u de private keys in beheer neemt. De private keys moeten zijn opgeslagen op de locatie waar uw sftp client draait. Van u hebben we nodig: De public key van de SSH key voor de productieverbinding De public key van de SSH key voor de testverbinding Graag ontvangen wij deze keys bij het Inrichtingsformulier. Mochten wij vragen hebben hierover dan nemen wij daarvoor contact op met de contactpersoon van uw IT afdeling die u opgeeft op het Inrichtingsformulier. Let er op dat deze persoon (personen) beschikbaar is (zijn) gedurende de implementatie van RDC. Naast deze SSH keys hebben we aanvullende informatie, zoals IP-adressen en de te gebruiken poorten nodig voor de verbinding. Deze kunt u aangeven op het Inrichtingsformulier. 2.4 Het ondertekenen van betaalbestanden Naast de veilige verbinding met Rabobank moeten de betaalbestanden worden ondertekend. Deze handtekening bevestigt dat er gedurende het transport geen wijzigingen zijn aangebracht in het betaalbestand en dat het bestand afkomstig is van de juiste klant. Een handtekening van een betaalbestand is een SHA-256 hash van de payloadfile, die is versleuteld met een 2048 bits RSA sleutel van u als klant. 6

7 Om de handtekening van het betaalbestand te kunnen verifiëren moet een X.509-certificaat door u aan Rabobank beschikbaar worden gesteld. Dit certificaat is de publieke tegenhanger van de RSA private key die voor ondertekening wordt gebruikt en wordt gebruikt om de handtekening te verifieren. Het proces voor het verkrijgen van de RSA private key plus certificaat is beschreven in hoofdstuk PKCS#7 De handtekening van het betaalbestand kan in raw format of in PKCS#7 formaat worden verstuurd. Beiden worden door RDC geaccepteerd. Java applications genereren doorgaans het raw formaat wanneer JCE bibliotheken worden gebruikt. Als Castle of.net wordt gebruikt wordt doorgaans een PKCS#7 handtekening gegenereerd. 2.6 Het creëren van een certificaat voor ondertekening Voor zowel de Klant Acceptatie Omgeving (KAO, zie ook hoofdstuk 32.10) als voor de productieomgeving zijn certificaten benodigd. Het verschil is echter dat voor de KAO een zelf ondertekend certificaat volstaat, waarvoor certificering door een derde partij niet nodig is. Een zelf ondertekend certificaat is niet toegestaan in de productieomgeving; deze dient te zijn getekend door een Certificaatautoriteit. Momenteel accepteert Rabobank alleen de certificaten van onderstaande Autoriteiten. Voor certificaten van andere partijen raden wij u aan om contact op te nemen met uw implementatiemanager. Houdt er rekening mee dat aan de aanvraag van het certificaat kosten zijn verbonden en dat u het certificaat regelmatig dient te vernieuwen. Symantec Het aanvraagproces voor een certificaat van Symantec vindt u hier: Digicert Het aanvraagproces voor een certificaat van Digicert vindt u hier: LET OP: Een certificaat mag een maximale geldigheidsduur van 2 jaar hebben. Stem dit goed af met de leverancier van het certificaat. Vermeld de geldigheidsduur van het certificaat op het Inrichtingsformulier. Het blijft uw eigen verantwoordelijkheid om de geldigheidsdatum te bewaken en ruim voor het verstrijken van de geldigheid een nieuw certificaat aan te vragen en op te sturen naar Rabobank. Op die manier kan Rabobank de RDC diensten zonder onderbreking aan u blijven leveren. Een uitgebreid stappenplan voor het verkrijgen van een correct certificaat vindt u in Appendix 4. De schematische weergave: 7

8 Het certificaat stuurt u als volgt naar Rabobank: <klantnaam>rdcpublickey.crt.txt. Volg hierbij zorgvuldig de instructies voor verzending van het certificaat. Deze vindt u in de toelichting van het Inrichtingsformulier. Vergeet niet het formulier te ondertekenen. 2.7 Het verifiëren van de bestanden van Rabobank Rabobank voorziet bestanden die zij naar u stuurt van een handtekening. Deze handtekening kunt u controleren door gebruik te maken van de publieke sleutel in het X.509 certificaat van Rabobank. Deze publieke sleutel wordt aan u beschikbaar gesteld. U kunt het Rabobank certificaat voor RDC vinden op onder Downloads. 2.8 Test scenario s Als klant zult u het gebruik van RDC willen testen voordat u het daadwerkelijk in gebruik neemt. In deze paragraaf staat een aantal aanbevelingen voor het uitvoeren van deze testen. Voor alle testen geldt dat u deze vooraf met de implementatiemanager van Rabobank afstemt. Alleen dan kan Rabobank zorgen voor de juiste begeleiding om u bij het testen te ondersteunen. Het testen van de sftp verbinding Nadat de IT-afdelingen (van u en van Rabobank) gezamenlijk de sftp verbinding hebben opgezet (een test- en een productieverbinding) is het advies deze verbinding te testen door het versturen van een betaalbestand over de aangelegde testverbinding. Via deze verbinding is het mogelijk om te controleren of bestanden op de juiste manier worden getransporteerd van uw omgeving naar die van Rabobank. Daarnaast kan Rabobank u via deze verbinding een bestand sturen om te controleren of bestanden correct getransporteerd worden van Rabobank naar uw omgeving. 8

9 Het testen via de Klant Acceptatie Omgeving Via de Klant Acceptatie Omgeving kunnen uw verbinding met RDC en uw metadata (header.xml) getest worden. In hoofdstuk drie wordt dit verder uitgelegd. Het testen in productie middels penny tests Nadat de sftp verbinding met een positief resultaat is getest via de testverbinding, is het advies eerst een pennytest te doen door het versturen van één of een klein aantal minibetalingen van en naar een rekening binnen uw organisatie. Het is daarbij verstandig om voor elk betaalformaat dat u gaat gebruiken een aparte test te doen om vast te stellen dat de minibetaling juist wordt verwerkt en teruggemeld in de verantwoording. 2.9 Go Live beslissing Nadat de verschillende tests succesvol zijn uitgevoerd beslist u in overleg met Rabobank of u wilt starten met het daadwerkelijk gebruik van RDC. Indien de testen hebben uitgewezen dat hier geen belemmeringen meer voor zijn kan de RDC verbinding ingezet worden voor uw betalingsverkeer. De Go Live beslissing wordt in overleg met Rabobank genomen Serviceberichten Via serviceberichten informeert Rabobank u over onderhoud, nieuwe functionaliteiten en downtime met betrekking tot RDC. Rabobank tracht u minstens 1 maand voor de release van nieuwe functionaliteiten te informeren, zodat u voldoende tijd heeft om u voor te bereiden op de nieuwe situatie. Op het Inrichtingsformulier geeft u aan op welk adres/welke adressen u deze serviceberichten wilt ontvangen. Indien u dit adres later wilt wijzigen kunt u hiervoor het Inrichtingsformulier gebruiken. Overigens worden een naar alle geregistreerde adressen gestuurd. 9

10 3. De Klant Acceptatie Omgeving 3.1 Beschrijving van de Klant Acceptatie Omgeving Naast testen via een productieverbinding beschikt RDC ook over een Klant Acceptatie Omgeving (KAO). Deze omgeving staat los van onze productiesystemen en simuleert de werking van RDC. U kunt dit systeem gebruiken om te testen of uw ERP-pakket op de juiste manier is geconfigureerd voor het verzenden van initiatiebestanden en het ontvangen van verwerkingsinformatie via RDC. Indien u een testbestand in het formaat BTL91 instuurt en deze voldoet aan de gestelde voorwaarden, ontvangt u via de verbinding een ACK en vervolgens een PAIN.002. Indien u een testbestand in het formaat PAIN.001 of PAIN.008 instuurt en deze voldoet aan de gestelde voorwaarden, ontvangt u alleen een PAIN.002. In beide gevallen bevat deze PAIN.002 een willekeurige afkeurcode en heeft geen betrekking op het door u aangeleverde bestand. U ontvangt deze PAIN.002 zodat u direct kunt verifiëren of uw systeem gereed is voor de ontvangst en verwerking van dit bestandstype. Als het bestand niet conform de voorwaarden is opgesteld, ontvangt u een NACK. Hierna volgt geen PAIN.002 bericht, omdat het bestand voor verwerking is afgekeurd. Daarnaast stuurt Rabobank u een gesimuleerd verantwoordingsbestand. U heeft de keuze uit CAMT.053 of MT940 Structured. Op het Inrichtingsformulier geeft u aan welk formaat u wilt ontvangen. Binnen de Klant Acceptatie Omgeving is geen koppeling met Rabo Internetbankieren Professional voor het intrekken of bijtekenen van opdrachten. Technische test 3.2 Wat kunt u testen met de Klant Acceptatie Omgeving Testen sftp verbinding RDC (verbinding klant Rabo) Testen van metadata (header.xml) Testen statusinformatie PAIN.001 en PAIN.008 Status informatie type Omschrijving ACK U ontvangt géén ACK wanneer u een testbestand in PAINformaat instuurt NACK U ontvangt een NACK wanneer er fouten in de verbinding of de header zijn gevonden PAIN U ontvangt een PAIN.002 indien de verbinding en de header goed zijn. Deze bevat dummy data Testen statusinformatie BTL91 Status informatie type ACK Omschrijving U ontvangt een ACK wanneer de verbinding, de metadata (header.xml) en het bestand zijn goedgekeurd 10

11 NACK PAIN U ontvangt een NACK wanneer er fouten in de verbinding of de header zijn gevonden U ontvangt een PAIN.002 indien de verbinding en de header goed zijn. Deze bevat dummy data Testen van betaalformaten De volgende formaten kunnen worden getest, waarbij de inhoud van het PAIN-testbestand niet wordt getest. Voor het testen van de inhoud van uw PAIN-bestanden (de payload), raden wij u aan MyStandards te gebruiken. Meer informatie hierover vindt u hier of u kunt contact opnemen met uw Rabobank contactpersoon. Initiatie PAIN PAIN BTL91 Testen verantwoordingsinformatie Verantwoording MT940S CAMT De verantwoordingsinformatie ontvangt u rond uur (dit tijdstip kan variëren). In de productieomgeving ontvangt u eindedag-informatie na het afsluiten van een boekdag rond middernacht en uiterlijk om uur na de boekdag. 3.3 Aanvragen Klant Acceptatie Omgeving (KAO) Bij het aanvragen van een Klant Acceptatie Omgeving heeft u twee mogelijkheden. U kunt uw KAO gelijk houden aan uw productieomgeving; dat wil zeggen dat u in uw Klant Acceptatie Omgeving dezelfde rekeningen en functionaliteiten laat opvoeren als in uw productieomgeving. U kunt er echter ook voor kiezen andere rekeningen of services op te voeren in uw Klant Acceptatieomgeving. 3.4 Zelf ondertekend certificaat Voor het gebruik van de KAO is een apart certificaat nodig. Deze vraagt u aan via de beschreven wijze in in hoofdstuk 2.6 bij een derdeninstantie, zoals Symantec. Echter, een zelf ondertekend certificaat is ook een toegestane mogelijkheid binnen de Klant Acceptatie Omgeving. U mag uit veiligheidsoverwegingen voor de Klant Acceptatie Omgeving geen productiecertificaat gebruiken. Een certificaat bevat de publieke sleutel waarmee de handtekening wordt gecontroleerd. Bij een zelf-ondertekend certificaat genereert u zelf een sleutelpaar (RSA, 2048 bits, private en public key) en maakt vervolgens een certificaat aan die met deze zelfde sleutel is ondertekend. Bij een echt certificaat wordt het certificaat ondertekend door een derde partij. Dit gebeurt na controle van de identiteit van het bedrijf en aanlevering van de publieke sleutel in een certificaat aanvraag bestand. U dient dit zelf-ondertekende certificaat mee te sturen bij uw aanvraag voor de Klant Acceptatie Omgeving. 3.5 Disclaimer Rabobank kan geen garantie bieden dat in de testomgeving behaalde resultaten representatief zijn voor werking in de productieomgeving. Hier kunnen geen rechten of plichten aan worden ont- 11

12 leend. Daarom adviseren wij u om, nadat u in de Klant Acceptatie Omgeving getest heeft, ook een aantal pennytesten uit te voeren over uw productieverbinding. 12

13 4. Inititatie 4.1 Het initiëren van een incasso- of betaalopdracht Het initiëren van een incasso- of betaalopdracht is per organisatie verschillend, afhankelijk van de gebruikte software oftewel ERP-pakket. Via het ERP-pakket zijn bestanden via de opgezette sftp verbinding (zie hoofdstuk 2) te exporteren naar RDC. Toelichting over het gebruik van uw ERPpakket kunt u bij uw ERP-leverancier opvragen. Dit hoofdstuk beschrijft hoe u de initiatiebestanden opbouwt en aan welke benaming dit bestand moet voldoen. 4.2 Het initiatiebestand Het initiatiebestand bestaat uit een header (zie paragraaf 4.2.1) en een payloadfile (zie paragraaf 4.2.3), die uit 1 of meerdere batches bestaat. Een batch wordt ook wel een Payment Information Block genoemd. Er geldt een aantal regels voor de benaming van een initiatiebestand. Een initiatiebestand wordt ook wel een file genoemd. Hierna worden in de tekst de termen file en bestand gebruikt voor het aanduiden van een initiatiebestand. Voor de benaming (filename) van een bestand is het advies om de volgende structuur te gebruiken (dit is echter geen dwingend advies): <action>_<customer-id>_< contractid >_<datetime>.zip Toelichting: <action> kan zijn SCT voor Credit Transfers (Eurobetalingen en non-eurobetalingen, te weten spoed en/of Wereldbetalingen, mits in PAIN.001/Generic Payment File aangeleverd), SDD voor SEPA Direct Debits (Euro-incassi) of BTL voor Wereldbetalingen (in BTL91 formaat). <customer-id> is de klant identificatie code. Dit customer id bepaalt u zelf. Randvoorwaarde is dat dit alfanumeriek is en maximaal 8 karakters bevat. < contractid > is het identificatie nummer van de overeenkomst. Dit contract ID heeft u ontvangen van Rabobank. <datetime> Wordt ingezet om de bestandsnaam uniek te maken, numeriek, yymmddhhmmssxx (y = jaar, m = maand, d = dag, h = uur, m = minuut, s = seconde, xx = volgnummer of honderdste seconde). Naast bovenstaande gelden de volgende regels voor de benaming (filename): Hoofdlettergevoelig, geen spaties toegestaan, underscores moeten worden gebruikt om de elementen te scheiden. De filename mag maximaal 175 karakters bevatten. Karakters die gebruikt mogen worden: a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z _ De header file Voor de benaming van een header file geldt het volgende: <header>.xml In de header staat de handtekening van de klant en andere metadata. 13

14 De header ziet er volgt uit: ZIP file mypain001.zip header.xml <?xml version="1.0" encoding="utf-8"?> <RDCInitiationRequest> <ContractId>123</ContractId> <PayloadAction>SCT</PayloadAction> <PayloadVersion>pain </PayloadVersion> <UniqueReference> </UniqueReference> <TimeStamp> T12:50:06</TimeStamp> <Signature>SuaY3DCuv+hTJ9GxOVSOxdNTxt9f/GpdUNcFW271FbJcvPEHpa8dJQ 9lahTXepXYrk2+NBoofQ50RVAdCCKCI5Nk90D7CiHV/Bzf+bLARvBh/9EvWXS75GQ5Tkn3jgc/3 32AFWuJf8rdpPDTaqStKpZHW96TfHcoMI/bCxlavrArucwrBbVweuW3F6JPsDosT1fey+GNtKTUG GZVV7m71j+2oEosiL54TUjZoHM0HQIP0amg6+pZ6JRSmte7yuneGS5DpruVszGfpU9RfBcrQetr qxscwwqqjlcjbnlzs4hexqd8j/feem609jpsx4wm+q2yrwqvdayj1b1ercgfwg==</signature> </RDCInitiationRequest> mypain001.xml Verklaring van de velden/tags: Veld Toelichting Toegestane waarden Verplicht Opmerking XML type ContractId Y string PayloadAction PayloadVersion SCT SDD BTL PAIN PAIN BTL91 UniqueReference Y Value from customer TimeStamp Y Value from customer Signature Y Signed with customer private key Y Y string string string datetime base64binary Controle Met behulp van het RDCInitiationRequest.xsd bestand kunt u de XML bestanden juist creëren en valideren. Het bestand RDCInitiationRequest.xsd kunt u vinden op onder downloads XSD files (voor validatie) De payload file Voor de payload file geldt het advies om de volgende structuur te gebruiken (dit is echter geen dwingend advies): 14

15 PAIN: <action>_<customer-id>_<datetime>.xml BTL: <action>_<customer-id>_<datetime>.txt Toelichting: <action> kan zijn SCT voor Credit Transfers (Eurobetalingen en non-eurobetalingen, te weten spoed en/of Wereldbetalingen, mits in PAIN.001/Generic Payment File aangeleverd), SDD voor SEPA Direct Debits (Euro-incassi) of BTL voor Wereldbetalingen (in BTL91 formaat). <customer-id> is de klant identificatie code. Dit customer id bepaalt u zelf. Randvoorwaarde is dat dit alfanumeriek is en maximaal 8 karakters bevat. <datetime> Wordt ingezet om de bestandsnaam uniek te maken, numeriek, yymmddhhmmssxx (y = jaar, m = maand, d = dag, h = uur, m = minuut, s = seconde, xx = volgnummer of honderdste seconde). Het is niet mogelijk om in één payloadfile zowel PAIN.001 als PAIN.008-batches of BTL91-batches aan te bieden. Zowel de header en de payload file moeten zijn gebaseerd op de UTF-8 karakterset. 4.3 ZIP archive DEFLATE Het reduceren van de bestandsgrootte van een file kan via de compressiemethode DEFLATE. Deze compressiemethode wordt wereldwijd gebruikt en is in veel programmeertalen en operating systems tools beschikbaar. Een technische beschrijving vindt u hier (link). 4.4 De initiatie stap voor stap 1) ERP-systeem genereert betaalbestand. 2) Betaalbestand wordt getekend. De handtekening (versleutelde SHA-256 van de payload) is nodig om de herkomst en integriteit te waarborgen. Het tekenen is vanuit beveiligingsoogpunt verplicht. De handtekening wordt versleuteld met de private key vanuit uw keystore. 3) Betaalbestand wordt klaargezet voor verzending. 4) Klant start sftp sessie op. 5) De sftp-server van Rabobank verifieert of u bent wie u zegt te zijn (authenticatie). Als u niet wordt herkend, wordt de verbinding verbroken en is het niet mogelijk bestanden naar Rabobank te verzenden. 6) Betaalbestand wordt verzonden. 7) Na ontvangst wordt het bestand gedecomprimeerd 8) Handtekeningen en klantafspraken worden gecontroleerd 9) Het betaalbestand wordt opgepakt voor controle en verdere verwerking. 15

16 4.5 Wat kunt u verwachten indien er iets niet goed gaat? Wanneer een bestand wordt verstuurd naar de Rabobank over de beveiligde (sftp) verbinding, worden verschillende controles uitgevoerd door RDC. Indien deze negatief zijn stuurt Rabobank u een NACK (negative acknowledgement) of een PAIN.002. Rabobank zal het bestand in dat geval niet verder verwerken. In Appendix 1 van deze handleiding vindt u een overzicht van alle mogelijke afkeuringen. Hierin wordt op hoofdlijnen aangegeven welk typen afkeuringen er zijn. Hieronder volgt een aantal voorbeelden waarbij u een NACK of een PAIN.002 kunt verwachten: Indien decompressie niet mogelijk is, ontvangt u een NACK. Het proces controleert of het bestand is gewijzigd door het controleren van de meegestuurde handtekening (SHA 256 file). Als de integriteitscontrole niet correct is wordt een NACK bericht verstuurd. Er wordt gecontroleerd of het bestandstype herkenbaar is en of u bent gerechtigd bestanden van dit type aan te leveren. Indien dit niet is afgesproken stuurt RDC een NACK bericht terug. Er wordt gecontroleerd of hetzelfde bestand niet al eerder is aangeleverd om te voorkomen dat een bestand per ongeluk tweemaal verwerkt wordt. Dit gebeurt op basis van de bestandsnaam en de payload. Indien RDC een duplicaat vindt stuurt RDC een NACK bericht terug. Decryptie. Indien het bestand versleuteld is (optioneel), decodeert Rabobank het bestand. Als het bestand niet kan worden gedecodeerd wordt een NACK bericht verstuurd. Er wordt gecontroleerd of het aangeleverde bestand verwerkbaar is. De volgende controles worden uitgevoerd: o Voldoet het formaat van de payload aan de eisen zoals gesteld in het Rabobank formatenboek (zie o Wordt hierbij niet afgeweken van de voorgeschreven tekenset? o Wordt het maximum van betaalopdrachten per bestand niet overschreden? o Wordt het maximum van batches in een bestand niet overschreden? o Maakt de rekening waar de betalingsopdracht voor is onderdeel uit van de RDC overeenkomst? o Is de gevraagde uitvoeringsdatum van de transactiebetaling geldig? Zie paragraaf 4.6. o Voldoet de betaalopdracht aan de eisen vanuit wet- en regelgeving? o Per betalingsopdracht wordt tijdens verwerking een aantal controles uitgevoerd. In geval deze controles een negatief resultaat hebben wordt een PAIN.002 verstuurd. 4.6 Uitvoerdata en geagendeerde betalingen Het aanbieden van opdrachten met een uitvoerdatum in de toekomst is alleen mogelijk in combinatie met RIB Pro. Ook is het mogelijk om opdrachten met een uitvoerdatum in het verleden aan te bieden. Hieronder staan de regels die worden gehanteerd: Betaalopdracht via PAIN.001: Vandaag - 14 dagen <= uitvoerdatum <= vandaag Vandaag + 1 dag <= uitvoerdatum <= vandaag +365 dagen Anders (te ver in het verleden of de toekomst) Batch wordt meteen verwerkt, Geen RIB Pro noodzakelijk Alleen mogelijk in combinatie met RIB Pro. Anders wordt batch afgekeurd Batch wordt afgekeurd 16

17 Wereld- en Spoedbetaling via BTL91: Vandaag - 10 dagen <= uitvoerdatum <= vandaag +10 dagen Vandaag + 11 dagen <= uitvoerdatum <= vandaag +365 dagen Anders (te ver in het verleden of de toekomst) Geen RIB Pro nodig Alleen mogelijk in combinatie met RIB Pro. Anders wordt opdracht afgekeurd Opdracht wordt afgekeurd SDD via PAIN.008: Vandaag - 14 dagen <= uitvoerdatum <= vandaag + 20 dagen Vandaag + 20 dagen < uitvoerdatum <= vandaag +365 dagen Anders (te ver in het verleden of de toekomst) Geen RIB Pro nodig Alleen mogelijk in combinatie met RIB Pro. Anders wordt batch afgekeurd Batch wordt afgekeurd Het kanaal RDC checkt niet de aanleverdatum maar de uitvoerdatum. De aanleverdatum voor Euroincasso s is D-1 vóór 7.00 uur en voor Bedrijven Euro-incasso s vóór uur. Dit geldt voor alle sequence types: eerste (first), volgende (recurrent), eenmalige (one-off ) en laatste (last) incasso. Indien de opdrachten vóór genoemde tijdstippen zijn ontvangen, worden deze direct verwerkt en de volgende dag bijgeschreven op de rekening. Spoedbetalingen kunnen worden ingezonden in BTL91-formaat of in een Generic Payment File. In dat laatste geval moet er een separate batch met Spoed- en/of Wereldbetalingen worden aangeboden. Reguliere betalingen verwerkt RDC conform de Tijdslijnen girale verwerking voor zakelijke klanten. Meer informatie over verwerking tijdens feestdagen vindt u hier. 17

18 5. Status berichten en verantwoording 5.1 ACK/NACK Statusberichten Voor elk bestand dat wordt ingezonden wordt getracht binnen 15 minuten een XML bestand terug te sturen. In dit XML bericht staat aangegeven of het bestand wel of niet is geaccepteerd. Voor een geaccepteerd bestand ontvangt u een ACK. Indien het bestand niet is geaccepteerd, ontvangt u een NACK. Hieronder een voorbeeld van een NACK bericht. Voorbeeld: mypain001.zip_ _reply.xml <?xml version="1.0" encoding="utf-8"?> <RDCInitiationReply> <ContractId>123</ContractId> <PayloadAction>SCT</PayloadAction> <PayloadVersion>pain </PayloadVersion> <UniqueReference> </UniqueReference> <Status>NACK</Status> <TimeStamp> T08:00:00</TimeStamp> <Errors> <Error> <ErrorCode>CAT_001</ErrorCode> <ErrorMessage><![CDATA[ Text you want to escape goes here... ]]> </ErrorMessage> </Error> </Errors> </RDCInitiationReply> Verklaring van de velden/tags:veld Toelichting Toegestane waarden Verplicht Opmerking XML type ContractId Y string PayloadAction PayloadVersion SCT SDD PAIN PAIN Y Y Repeated from request Repeated from request UniqueReference Y Repeated from request Status ACK NACK Y Value from Rabobank Timestamp Y Value from Rabobank Errors:Error: ErrorCode Errors:Error: ErrorMessage N N string string string string datetime string string Met behulp van het RDCInitiationReply.xsd bestand kunt u de XML bestanden correct aanmaken en valideren. Het bestand RDCInitiationReply.xsd kunt u vinden op onder downloads. 18

19 Standaard benaming: originalfilename_ <klantreferentie>_reply.xml Het bericht is gebaseerd op de oorspronkelijke naam van het bestand die door u is bepaald, gevolgd door een underscore en de klantreferentie. Deze klantreferentie is gelijk aan uw RDC contractid. Als het door u ingestuurde bestand niet leesbaar is en de klantreferentie niet bepaald kan worden dan wordt deze ook niet gegeven. In dat geval ziet de bestandsnaam er als volgt uit: originalfilename_ reply.xml Als hetzelfdebestand twee keer wordt verstuurd ontvangt u twee reacties: originalfilename_ <klantreferentie>_reply.xml (normale ACK/NACK) Originalfilename(1)_reply.xml (NACK omdat er een duplicaat is gedetecteerd) De 1 in de regel geeft aan dat het om het eerste duplicaat gaat en bevat altijd een NACK. Duplicaten worden afgekeurd. De referentie is in deze regel niet gespecificeerd. 5.2 PAIN.002 status berichten Indien tijdens de verwerking van betaal- en incasso-initiaties blijkt dat een batch of individuele transactie niet uitgevoerd kan worden, stuurtrabobank u een melding in de vorm van een XML bericht, een zogenaamde PAIN.002,. Dit is alleen mogelijk voor opdrachten geïnitieerd in PAINformaat. LET OP! Dit is een ander bericht dan de ACK/NACK berichten die RDC stuurt! De kenmerken van een PAIN.002 melding: PAIN.002 meldingen worden op batchniveau óf op transactieniveau gestuurd. Pre settlement R-messages (R = reject) worden ook via PAIN.002 beschikbaar gesteld (naast bruto boeken op afschrift). LET OP! De afkeuring met reden op transactieniveau bevat de volledige originele transactiedetails. In geval van een salarisbetaling heeft dit tot gevolg dat het bedrag en begunstigde worden meegestuurd in de PAIN.002. Een functionele en technische beschrijving van het PAIN.002 bericht zijn beschikbaar op via Downloads, dan onder Export formats. In de functionele omschrijving kunt u ook de afkeurcodes vinden. De opbouw van de bestandsnaam van PAIN.002 is als volgt: <Originele bestandsnaam inclusief extensies zoals.xml en/of.zip>_< volgnummer>-pain002.xml Voorbeeld: Originele, door u gegenereerd bestand: SCT_ _ xml.zip, levert bij de eerste PAIN.002 de volgende bestandsnaam op: : SCT_ _ xml.zip_0000-PAIN002.xml 5.3 Verantwoordingsinformatie Aan het einde van de dag wordt een verantwoordingsbestand (End of day) verzonden in het gekozen bestandsformaat (CAMT.053 of MT940 Structured). Intradag verantwoording is beschikbaar via RDC in de formaten CAMT.052 en MT942 Structured. Een verantwoordingsbestand blijft 2 maanden lang beschikbaar en kan via uw sftp verbinding worden opgehaald. Houdt u er rekening mee dat u na 2 maanden geen CAMT.053, MT940 Structured, CAMT.052 of MT942 Structured meer kunt ophalen. 19

20 Onderstaand voorbeeld toont de inhoud van een door RDC uitgeleverd CAMT.053 bestand: ZIP file CAMT053_ _081011_123.zip header.xml <?xml version="1.0" encoding="utf-8"?> <RDCInformationReply> <ContractId>123</ContractId> <UniqueReference> T08:10:11</UniqueReference> <TimeStamp> T08:10:11</TimeStamp> <PayloadList> <Payload> <FileName>CAMT _081011_123.xml</FileName> <Signature>OzqpF3zVMBatlKKH/T18mhbelWM8afWgK/GzaEARF9Cc7AF2CuSSnlL iosk9oj07y/+zqdzpqqr3vzeckguuo6s8mcw9fkfmelntz4szobj/uthh3kpjtbwgokodd0xqo EHqLaOBgUmDEwzjLvmMOBhbON41CitJN+EpYUrHx+kHr5mPSMfZv7AvbMdMychMDWgY7khs lfmtawwksb1bdqava18hi3w7v+htpf6n3yq2ssiwxoalqo5zdkdg5jiavffig25bb4tpbixl00qt Ui5dBxp30k0vdoGL6pw2l3YgvFRCy1mJyY3ofQgaAuGBDI7jnqu9ztVyKQRL70BBHA==</Signat ure> <PayloadAction>CAMT053</PayloadAction> <PayloadVersion>CAMT053v1.2</PayloadVersion> </Payload> </PayloadList> </RDCInformationReply> CAMT053_ _081011_123.xml Verklaring van de velden/tags: Veld Toelichting Toegestane waarden Verplicht Opmerking XML type ContractId Y string UniqueReference Y Value from Rabobank Timestamp Y Value from Rabobank PayloadList: Payload: FileName PayloadList: Payload: Signature PayloadList: Payload: PayloadAction PayloadList: Payload: PayloadVersion CAMT.053 MT940 Structured CAMT.053v1.2 MT940 Structuredv1.2 Y Y Y Y Value from Rabobank Value from Rabobank Value from Rabobank Value from Rabobank string string datetime string datetime string Met behulp van het RDCInformationReply.xsd bestand kunt u de XML bestanden juist creëren en valideren. Het bestand RDCInformationReply.xsd kunt u vinden op onder Downloads. Verantwoordingsinformatie wordt afgeleverd in een zip bestand met een header met daarin een handtekening. De benaming van het zip bestand is als volgt: StatementType_Date_Time_ContractId_statementTransportAgreementId.zip 20

21 Voorbeelden: CAMT053_ _152431_ _590.zip MT940S_ _152431_ _8.zip 5.4 Directe verantwoording stap voor stap 1) De BackOffice systemen van de Rabobank genereren de verantwoordingsinformatie die met u afgesproken is. 2) De verantwoordingsinformatie wordt indien afgestemd versleuteld. 3) De verantwoordingsinformatie wordt klaargezet. 4) Rabobank stuurt het bericht naar uw systeem. 5) De sftp server verifieert of u bent wie u zegt te zijn. Als u niet wordt herkend wordt de verbinding verbroken. 6) Vervolgens haalt u het bestand op en verplaatst u het naar de gewenste locatie. 7) U verbreekt de verbinding met de bank en kunt het bestand in uw ERP systeem verwerken. 5.5 Bundeling verantwoordingsinformatie Standaard verstuurt Rabobank per verantwoordingsservice één bundel (.zip) met daarin alle rekeningnummers die onder uw contract vallen. U kunt er ook voor kiezen om de verantwoordingsinformatie te splitsen in meerdere bundels. Zo kunt u bijvoorbeeld per bedrijfsonderdeel een aparte bundel instellen. Op die manier is het eenvoudig om rekeningnummers in uw administratiesysteem van elkaar gescheiden te houden en hoeft u niet alle afschriften uit 1 bundel te zoeken. Deze optie kunt u voor zowel eindedaginformatie als de intradaginformatie gebruiken. Indien u rekeningen wilt bundelen, dan kunt u dit op het Inrichtingsformulier aangeven. Hieronder ziet u een voorbeeld voor eindedaginformatie: Rekening CCY MT940 Bundel CAMT.053 Bundel Structured NL81RABO<rekening1> EUR X 1 NL81RABO<rekening2> EUR X 1 NL81RABO<rekening3> EUR X 1 NL81RABO<rekening4> EUR X 1 NL81RABO<rekening5> USD X 1 NL81RABO<rekening6> GBP X 1 NL81RABO<rekening7> EUR X 2;1 NL81RABO<rekening8> EUR X 2;1 NL81RABO<rekening9> EUR X 2 NL81RABO<rekening10> EUR X 3 X 2 21

22 NL81RABO<rekening11> EUR X 3 NL81RABO<rekening12> EUR X 3 NL81RABO<rekening13> EUR X 3 In dit voorbeeld vindt u rekening 1 t/m 8 in bundel 1, rekening 7 t/m 10 in bundel 2 en rekening 10 t/m 13 in bundel 3. Daarnaast zitten rekeningen 7 en 8 in zowel bundel 1 als in bundel 2 en rekening 10 in bundel 2 en 3. Het is niet mogelijk in 1 bundel zowel CAMT.053 als MT940 Structured of CAMT.052 en MT942 Structured op te voeren; deze formaten zullen altijd in verschillende bundels verzonden worden. In de files die u vervolgens downloadt ziet dat er als volgt uit (waarbij het dikgedrukte deel het bundelnummer is): StatementType_Date_Time_ContractId_statementTransportAgreementId.zip Voorbeeld: MT940S_ _213818_ _7.zip De bundelnaam (bundelcode) mag alleen letters en cijfers bevatten en is maximaal 8 posities lang. De bundelcode kan opgegeven worden via het Inrichtingsformulier. Indien u geen bundelcode opgeeft wordt automatisch een code voor u gegenereerd op basis van een ID. Deze code heeft een lengte van 1 t/m 19 tekens en ontvangt u van de Rabobank tijdens uw implementatie. 5.6 Intradag rapportage U kunt een rapportage ontvangen van transacties die zijn bij- of afgeboekt vóór het afsluiten van de dag, oftewel een intradag rapportage. Hierdoor kunt u bijvoorbeeld al eerder reconciliëren, leveringen vrijgeven en/of beter bepalen wat uw cash positie is gedurende de dag. Er zijn twee varianten om uw intradagrapporten op te halen: de Intradag huidige boekdag en Intradag boekdag overschrijdend. Uw RDC-contract kunt u via het Inrichtingsformulier uitbreiden met intradag rapportages. Dit formulier kunt u later ook gebruiken om wijzigingen door te geven. Om voor een rekening intradag informatie aan te vragen, moet deze rekening al deel uitmaken van de eindedag verantwoording die via dit contract loopt. Intradag huidige boekdag Intradag huidige boekdag bevat alle transacties van de huidige boekdag. Elke opvraag bevat nieuwe transacties. Intradaginformatie wordt alleen uitgeleverd op werkdagen. In het weekend en/of op Target closing days wordt er geen intradaginformatie uitgeleverd. Het eerste uitlevermoment is 07.00, het laatste uitlevermoment is uur. U kunt, via het Inrichtingsformulier, ervoor kiezen om na het laatste uitlevermoment een intradagrapport te ontvangen met de resterende transacties, waardooruw intradagrapport aansluit op uw eindedagrapport. De intradagrapporten kunnen per bundel uitgeleverd worden. Indienin een bundel geen nieuwe intradaginformatie beschikbaar is, wordt er geen intradagrapport uitgeleverd. Wilt u toch een (leeg) intradagrapport ontvangen dan kunt u dit aangeven in het Inrichtingsformulier. Intradag boekdag overschrijdend Intradag boekdag overschrijdend bevat transacties over een bepaalde periode waarbij u de selectieperiode via het Inrichtingsformulier kunt aanvragen. Het rapport zal boekdag overschrijdende transacties bevatten. Deze variant wordt zeven dagen per week uitgeleverd. Tevens kunt u ervoor kiezen om ook op Target closing days de intradaginformatie uitgeleverd te krijgen. Dit geeft u aan- 22

23 op het Inrichtingsformulier. Deze variant sluit niet aan op het eindedagrapport en is vooral geschikt indien u doorlopend intradaginformatie wilt ontvangen. De intradagrapporten worden per bundel uitgeleverd. Indien in een bundel geen nieuwe intradaginformatie beschikbaar is wordt er geen intradagrapport uitgeleverd. Wilt u toch een (leeg) intradagrapport ontvangen dan kunt u dit aangeven in het Inrichtingsformulier. Formaat U kunt de intradag rapportages ontvangen in twee formaten, MT942 Structured of CAMT.052. Het voordeel van de MT942 Structured is dat dit formaat gebaseerd is op een standaard die al lange tijd door veel financiële administraties/erp pakketten ondersteund wordt en daarmee relatief eenvoudig te importeren is in uw financiële administratie. Het voordeel van het CAMT.052 formaat is dat deze gebaseerd is op de XML standaard en geschikt voor volledige rapportage van alle velden die u kunt opgeven bij een Eurobetaling (SEPA Credit Transfer) of Euro-incasso (SEPA Direct Debit). Een functionele beschrijving van de verschillende intradagformaten zijn beschikbaar op via Downloads, dan onder Export formats. Vergelijkingstabel aanlevervarianten intradagrapporten In onderstaande tabel kunt u de verschillende varianten met elkaar vergelijken. Omschrijving: Intradag huidige boekdag Intradag boekdag overschrijdend Dagen waarop intradag transacties geleverd worden Elke werkdag m.u.v. zaterdag, zondag en Target closing day 2. Elke werkdag, zaterdag en zondag en Target closing day 3. Eerste mogelijke levertijdstip Laatste mogelijke levertijdstip Levering op vaste tijdstippen of Levering via met vaste frequentie uur. De eerste rapportage van de dag levert alle transacties die sinds het einde van de vorige boekdag zijn bij- of afgeschreven. Start van de huidige boekdag uur 5. Einde huidige boekdag. Maximaal tien vaste levertijdstippen in te stellen per kwartier tussen en inclusief het eerste en laatste levermoment, bijvoorbeeld om 07.00, 11.15, 15.30, en uur. Elke 15, 30, 60 of 120 minuten worden de bij- of afgeschreven transacties gerapporteerd, vanaf het eerste levertijdstip tot en met het laatste levertijdstip. Secure File Transfer Protocol (sftp) of SWIFT FileAct 6 Maximaal tien vaste levertijdstippen in te stellen per kwartier tussen en inclusief het eerste en laatste levermoment, bijvoorbeeld om 05.00, 11.15, 15.30, en uur. Elke 15, 30, 60 of 120 minuten worden de bij- of afgeschreven transacties gerapporteerd, vanaf het eerste levertijdstip tot en met het laatste levertijdstip. Secure File Transfer Protocol (sftp) of SWIFT Fileact Boekdagen U ontvangt alleen transacties die Boekdag overschrijdend. 2 Op TARGET closing days is geen betalingsverkeer in Euro s mogelijk, er worden dan geen transacties verwerkt. TARGET closing days zijn Nieuwjaarsdag, Goede Vrijdag, Eerste Paasdag, Dag van de Arbeid en 1 ste en 2 de Kerstdag. 3 Intradag informatie op Target closing days is bij de boekdag overschrijdende intradag variant beschikbaar en kan geleverd worden. U kunt dit aangeven op het Inrichtingsformulier. TARGET closing days zijn Nieuwjaarsdag, Goede Vrijdag, Eerste Paasdag, Dag van de Arbeid en 1ste en 2de Kerstdag. 4 Intradag boekdag overschrijdend wordt 24 uur per dag en zeven dagen in de week uitgeleverd. Het eerste uitlevermoment is om en eindigt op Het is mogelijk dat na 18.00, of na uw laatste ingestelde levermoment, nog transacties worden verwerkt met boekdag vandaag. Het kan dan zijn dat er transacties gerapporteerd worden op uw dagafschrift (MT940S of CAMT.053) die niet gerapporteerd zijn via een intradag rapportage. U kunt er voor kiezen om deze transacties nog intradag geleverd te krijgen. 6 Via sftp ontvangt u van ons een Zip-bestand met daarin een header bestand met handtekening en een MT942S of CAMT.052 bestand. 23

24 met boekdag vandaag geboekt zijn. Wat als er geen transacties te rapporteren zijn? U kunt er voor kiezen om intradag rapportage te ontvangen indien op geen van de rekeningen in een bundel waarvoor u intradag rapportage heeft ingesteld een transactie geboekt is sinds de vorige levering van een intradag rapportage. U kunt dit aangeven op het Inrichtingsformulier. U kunt er voor kiezen om intradag rapportage te ontvangen indien op geen van de rekeningen in een bundel waarvoor u intradag rapportage heeft ingesteld een transactie geboekt is sinds de vorige levering van een intradag rapportage. U kunt dit aangeven op het Inrichtingsformulier. Beschikbare formaten MT942 Structured en CAMT.052 MT942 Structured en CAMT

25 6. Agenderen, intrekken en tekenen Door Rabo Direct Connect (RDC) in combinatie met Rabo Internetbankieren Professional (RIB Pro) te gebruiken, is het mogelijk een deel van de mogelijkheden van RIB Pro te gebruiken. Dit zijn agenderen, intrekken en tekenen. We benoemen en beschrijven de belangrijkste kenmerken van deze mogelijkheden, maar voor uitgebreide informatie over de functionaliteiten in RIB Pro verwijzen wij u naar de handleidingen op de website van RIB Pro. Voor inloggen in RIB Pro en voor meer informatie over veilig bankieren gaat u naar de volgende websites: RIB Pro inloggen Rabo Internetbankieren Professional Hoe werkt Rabo Internetbankieren Professional? Meer over veilig internetbankieren 6.1 Inrichten Overeenkomst RIB Pro Voor het gebruik van RDC in combinatie met Rabo Internetbankieren Professional is een overeenkomst van RIB Pro nodig. Deze overeenkomst inclusief gebruikerspassen en Raboscanners wordt opgezet naast de RDC-overeenkomst. Zodra de overeenkomst actief is, regelt de eigenaar van de overeenkomst zélf de autorisaties voor de gebruikers van de RIB Pro-overeenkomst. De autorisatie-instellingen vindt u onder de optie Zelf regelen Autorisaties. Zo kunt u zelf het aantal handtekeningen per batch/opdracht instellen. Voor Eurobetalingen is het mogelijk de batches door 2 gebruikers te laten ondertekenen. Voor SDD en BTL is alleen 1 e handtekening mogelijk. Om een 1 e of 2 e handtekening te kunnen zetten, zijn in RIB Pro de volgende instellingen noodzakelijk: Voor het zetten van de 1 e handtekening: Minimaal 1 gebruiker moet voor alle rekeningen die in het bestand gebruikt worden, geautoriseerd zijn voor het zetten van de 1e handtekening Voor het zetten van de 2 e handtekening (alleen voor Euro betalingen): Voor elke rekening in het bestand waarvoor getekend moet worden, moet minimaal 1 gebruiker geautoriseerd zijn voor het zetten van de 2e handtekening De benodigde autorisaties kunt u zelf instellen via Zelf regelen > Autorisaties. Meer informatie over de autorisatie-mogelijkheden binnen RIB Pro vindt u in de handleidingen Autorisaties(basis), limieten en opties en Uitgebreide Rekeningautorisaties. 6.2 Functionaliteiten RIB Pro Agenderen Indien betaal- en incasso-opdrachten binnen de in hoofdstuk 4.6 genoemde termijnen zijn aangeleverd, is het mogelijk deze te raadplegen in RIB Pro (mits de gebruiker de juiste autorisaties heeft). Intrekken In RIB Pro is het mogelijk om geagendeerde batches in te trekken. Echter, voor batches die zijn aangeleverd in een Generic Payment File wordt dit op een later tijdstip mogelijk. Tot dat moment wordt hiervoor tijdelijk een workaround via Customer Support ondersteund. Tekenen Het ondertekenen van Generic Payment Files en -batches in RIB Pro wordt op een later tijdstip mogelijk. Tot dat moment kunnen alléén BTL91- en Euro-bestanden en -batches (SCT) worden ondertekend. SDD-opdrachten kunnen alleen op bestandsniveau worden getekend. 25

26 7. Productbeeld U kunt een productbeeld voor het verkrijgen van extra inzicht in uw instellingen opvragen via uw contactpersoon bij Rabobank. Het productbeeld is een Nederlandstalig pdf-bestand met daarin de volgende RDC gegevens: NAW gegevens onderneming Contactpersonen Contractgegevens Rekeninginformatie o Producten o Afrekenrekening o Bundelinformatie Intradag instellingen 26

27 8. Ondersteuning en Service 8.1 Contact gegevens Na succesvolle ingebruikname van Rabo Direct Connect kunt u voor vragen of het oplossen van problemen terecht bij Rabo Corporate Support. Supportdesk: Rabo Corporate Support Geopend: maandag t/m vrijdag van 8:00 tot 17:30 Telefoon: corporatesupport@rabobank.com Website: Houdt u er rekening mee dat we voor een juiste afhandeling van uw vraag onderstaande gegevens nodig zullen hebben: Uw gegevens: Bedrijfsnaam of andere referentie De vraag/probleemstelling Informatie over de betreffende download/upload zoals de datum, tijd en bestandsnaam 8.2 Noodprocedure blokkeren verbinding RDC Wanneer er sprake is van, of het vermoeden bestaat, dat er misbruik wordt gemaakt van uw RDCovereenkomst,kunt u tijdens bovengenoemde kantooruren contact opnemen met Rabo Corporate Support. Buiten de openingstijden van deze desk is een noodprocedure van toepassing. U kunt dan contact opnemen met: Telefoon: Dit nummer kan enkel voor deze noodprocedure worden ingezet. In alle andere gevallen wordt u niet ondersteund buiten kantooruren. Wanneer u dit nummer belt zal ter verificatie gevraagd worden naar uw contract ID. Zorg ervoor dat u dit nummer bij de hand heeft wanneer u belt. Dit nummer heeft u ontvangen bij de implementatie van RDC. Bewaar dit nummer dus goed. Nadat we uw identiteit hebben bevestigd wordt de verbinding verbroken en zetten we het noodproces in gang. U wordt uiterlijk binnen twee uur teruggebeld met een bevestiging dat de RDC verbinding is geblokkeerd. Daarna zullen we contact met u opnemen om te bespreken hoe we de verbinding weer op een veilige manier kunnen herstellen. Indien de melding s nachts is gedaan wordt u de volgende ochtend teruggebeld hierover en wanneer u de melding in het weekend heeft gedaan wordt u hierover op maandagochtend gebeld. 27

28 Appendix 1: Afkeurredenen Indien een opdracht, batch of bestand wordt afgekeurd, wordt een NACK of PAIN.002 gegenereerd, afhankelijk van het type afkeuring. Hieronder vindt u een overzicht van de NACK s die u kunt ontvangen. Indien een afkeurcode onduidelijk is kunt u contact opnemen met Rabo Corporate Support. De verklaring van afkeuringen via PAIN.002 vindt u in de Functionele Formaatbeschrijving PAIN.002. NACK: Reject reason code Description NO_AGREEMENT_FOR_ACCOUNT 1, "File {0} contains one or more account(s) ({1}) which are not in the agreement." (only for transactions in BTL91-format) NOT_DIRECT_PROCESSABLE SIGNATURE_NOT_VERIFIED SENDER_NOT_AUTHORIZED XSD_VERSION_UNKNOWN INPUTFILE_NOT_A_ZIP_FILE INPUTFILE_ZIP_CONTAINS_FOLDERS INPUTFILE_ZIP_CONTAINS_TOO_MANY_FILES PAYLOAD_FILE_TYPE_NOT_ZIP_ENC PAYLOAD_FILE_TYPE_NOT_XML_OR_TXT INPUTFILE_ZIP_NOT_COMPLIANT 2, "One or more Execution date(s) are not valid, payment(s) not direct processable: {0}." (only for transactions in BTL91-format) 4, "The signature of file {0} could not be verified successfully." 5, "The sender of file {0} is not authorised to deliver payment instructions, unknown agreement." 6, "Unknown version specified (for XSD) in the header." 7, "The input file ({0}) is not a zip file." 8, "The compressed input file {0} contains one or more folders." 9, "The compressed input file {0} has too many files." 10, "The payload file is of an incorrect file type ('.zip.enc' expected): {0}." 11, "The payload file is of an incorrect file type ('.xml' or '.txt' expected): {0}." 12, "The content of the compressed input file is not conform specification (expected header or payload file cannot be found)." PAYLOADFILE_ZIP_CONTAINS_FOLDERS 13, "The compressed payload file of input file {0} contains one or more folders." PAYLOAD- FILE_ZIP_CONTAINS_INCORRECT_FILE_TYPE 14, "The compressed payload file of input file {0} contains an incorrect file type ('.xml' or '.txt' expected)." PAYLOADFILE_ZIP_CONTAINS_NO_ENTRIES 15, "The compressed payload file of input file {0} contains no entries." PAYLOADFILE_ZIP_CONTAINS_TOO_MANY_FILES 16, "The compressed payload file of input file {0} contains too many files." PAYLOADFILE_ZIPENTRY_FILE NAME_NOT_COMPLIANT DUPLICATE_PAYLOAD HEADER_NOT_VALID 17, "The compressed payload file of input file {0} contains an entry with an invalid name." 18, "Duplicate found, the payload of this input file ({0}) has already been successfully processed." 19, "The Header of File {0} does not comply to the RDCInitiationRequest scheme. Technical reason: 28

29 Reject reason code TOO_MANY_SIGNATURES UNKNOWN_CT_XSD_VERSION UNKNOWN_DD_XSD_VERSION UNKNOWN_BTL_VERSION HEADER_NOT_WELL_FORMED UNKNOWN_XSD_VERSION PAYLOAD_NOT_VALID PAYLOAD_NOT_WELL_FORMED TOO_MANY_CERTIFICATES NO_CERTIFICATES FILE_CAN_NOT_BE_DECRYPTED PAYLOAD_FILE NAME_NOT_COMPLIANT NO_SHARED_SECRET_KEY MISSING_ATTRIBUTE_IN_SHARED_SECRET_KEY TOO_MANY_SHARED_SECRET_KEYS INVALID_INPUT_DIRECTORY INPUTFILE NAME_CONTAINS_SPACES DUPLICATE_INPUTFILE_DETECTED DUPLICATE_INPUTFILES_DETECTED SIGNATURE_NOT_CORRECTLY_BASE64_ENCODED AGREEMENT_SERVICE_RETRIEVAL_EXCEPTION INVALID_REQUEST_TYPE NOT_SCHEDULABLE Description {1}." 20, "Header contains multiple signatures. This is not allowed." 21, "Version of XSD specified in header for Credit Transfer XML is unknown!" 22, "Version of XSD specified in header for Direct Debit XML is unknown!" 23, "Version specified in header for BTL is unknown!" 24, "The Header of File {0} is not well-formed. Technical reason: {1}." 25, "Unknown version specified (for XSD) in the header." 26, "The payload of File {0} does not comply to the SEPA scheme ({1}). Technical reason: {2}." 27, "The payload of File {0} is not well-formed (SEPA scheme ({1}). Technical reason: {2}." 28, "More than one valid certificate available, exactly one certificate should be valid at a given time." 29, "No valid certificate available, exactly one certificate should be valid at a given time." 30, "The file {0} could not be decrypted." 32, "The payload file name found in file {0} is invalid." 33, "Party sent an encrypted file, so at least one valid SharedSecretKey should be available." 34, "Party sent an encrypted file, so SharedSecret- Key attributes are mandatory and should be available." 35, "More than one valid secret key available, only one secretkey should be valid at a given time." 36, "The input directory does not match the directory expected for the agreement of this party." 37, "The input file name ({0}) contains one or more spaces." 38, "A duplicate input file ({0}) has been detected." 40, "Duplicate input files ({0}, {1}) have been detected." 41, "The signature is not correctly base64 encoded." 43, "Exception occured in Agreement Service while retrieving InitiationServiceAgreement." 44, "The RequestType specified in header file {0} is invalid." 48, "One or more Execution date(s) are not valid, payment(s) not schedulable that far in the future: {0}." 29

30 Reject reason code Description BETAALRECORD_1_NOT_FOUND 100, "BetaalRecord 1 was not found at line {0}." BETAALRECORD_2_NOT_FOUND 101, "BetaalRecord 2 was not found at line {0}." BETAALRECORD_3_NOT_FOUND 102, "BetaalRecord 3 was not found at line {0}." BETAALRECORD_4_NOT_FOUND 103, "BetaalRecord 4 was not found at line {0}." SLUITRECORD_NOT_FOUND 104, "Sluitrecord was not found at line {0}." UNKNOWN_RECORD_CODE INCORRECT_LINE_LENGTH INCORRECT_FIELD_VALUE SECOND_VOORLOOPRECORD_FOUND BETAALRECORD_BEFORE_VOORLOOPRECORD BETAALRECORD_AFTER_SLUITRECORD TOTAALRECORD_BEFORE_VOORLOOPRECORD TOTAALRECORD_BEFORE_BETAALRECORD TOTAALRECORD_AFTER_SLUITRECORD SLUITRECORD_BEFORE_VOORLOOPRECORD SLUITRECORD_BEFORE_BETAALRECORD SLUITRECORD_BEFORE_TOTAALRECORD INVALID_OPDRACHTNUMMER PHANTOM_TOTAALRECORD SUPERFLUOUS_TOTAALRECORD TOTAAL_RECORD_AANTAL_BETAAL_ OPDRACHTEN_ INCORRECT TOTAAL_RECORD_TOTAAL_BEDRAG_MUNTSOORT _INCORRECT SLUIT_RECORD_TOTAAL_AANTAL_RECORDS_ INCORRECT 105, "A line was found with an unknown Recordcode at line {0}." 106, "A line was found with an incorrect line length at line {0}." 107, "A line was found with an incorrect field value at line {0}, field=''{1}'', rejected value=''{2}''." 108, "A second VoorloopRecord was found at line {0}." 109, "A BetaalRecord was found before a VoorloopRecord was found at line {0}." 110, "A BetaalRecord was found after a SluitRecord was found at line {0}." 111, "A TotaalRecord was found before a VoorloopRecord was found at line {0}." 112, "A TotaalRecord was found before a BetaalRecord was found at line {0}." 113, "A TotaalRecord was found after a SluitRecord was found at line {0}." 114,"A SluitRecord was found before a VoorloopRecord was found at line {0}." 115, "A SluitRecord was found before a BetaalRecord was found at line {0}." 116, "A SluitRecord was found before a TotaalRecord was found at line {0}." 117, "A BetaalRecord was found with an incorrect value for field 'Opdrachtnummer(1-4)' at lines {0} - {1}." 118, "A TotaalRecord for currency ''{0}'', for which there are no BetaalRecords, was found at line {1}." 119, "A TotaalRecord for currency ''{0}'' was found for which a TotaalRecord has already been found at line {1}." 120, "The number of 'BetaalRecords' counted ({2}) for currency ''{0}'' does not match the number of records specified ({3}) in the TotaalRecord (field 'AantalBetaalopdrachten') at line {1}." 121, "The sum of 'OpdrachtBedrag' ({2}) found in 'BetaalRecords' for currency ''{0}'' does not match the amount specified ({3}) in the TotaalRecord (field 'TotaalbedragMuntsoort') at line {1}." 122, "The number of records counted does not match the number of records specified in the 30

31 Reject reason code SLUIT_RECORD_TOTAAL_AANTAL_TRANSACTIE_ RECORDS_INCORRECT MISSING_TOTAALRECORD INCORRECT_FILE_FORMAT SWIFT_PAR_FIRST_BYTE_ERROR SWIFT_PAR_INCOMPLETE_HEADER_OR_CONTENT SWIFT_ENCRYPTED_ZIP_NOT_SUPPORTED SWIFT_INVALID_COMPRESSION_TYPE SWIFT_XML_XPATH_ERROR SWIFT_PAYLOAD_DIGEST_ERROR SWIFT_PAR_NOT_FOUND SWIFT_PAYLOAD_FILE_INVALID_LENGTH Description SluitRecord (field 'TotaalAantalRecords') at line {0}." 123, "The number of transactions counted does not match the number of transactions specified in the SluitRecord (field 'TotaalAantalTransactierecordS') at line {0}." 124, "A TotaalRecord for currency ''{0}'' was not found." 125 The payload of file {0} has an incorrect BTL file format (e.g. line(-s) too short, line(-s) too long, missing cr or lf, etc.). 204, "The first byte in the PAR file ''{0}'' is not 0x1f, it is {1}" 205, "PAR file ''{0}'' has an incomplete header or no content, checksum or LAU (size < 38)." 209, "Zip file {0} is encrypted which is not supported." 210, "Compression type {0} is not supported." 211, "The par file "{0}" contains no file digest algorithm." 250, "Payload file ''{0}'' has file digest ''{1}'', but expected ''{2}''." 252, "Corresponding par file for payload file ''{0}'' not found." 253, "The length of the name of the payload file ''{0}'' is invalid." DAP_XML_VALIDATION_ERROR 300, "The XML in the file ''{0}'' is not valid. Errors: {1}" DAP_XML_SYNTAX_ERROR 301, "A syntax error occurred while reading the xml in file ''{0}'': {1}" De meldingen 1, 2 en 100 t/m 124 zijn de afkeurredenen die verzonden worden voor BTL91 betalingen. 31

32 Appendix 2. Checklist Signing We expect you to calculate the hash with the SHA256 algorithm and use a 2048 bytes RSA private key to create the signature. For the openssl dgst commands below you need to use a PEM format of your public key. You can also use openssl to convert your public key to the PEM format. The openssl commands generates hashes and verifies signatures. You can compare the hashes with the results of your own code and these should be identical. After encrypting the hash (creation of the signature) you can verify them with the given openssl commands. Verify your own signature of type RAW with openssl: 1. Check your own hash (result of your code) against the hash calculated by openssl ; openssl dgst -sha256 <payload-file> 2. Verify your own signature (result of your code) against your public key with openssl; Openssl dgst -sha256 -verify <public-key-file> -signature <signature-file> <payload-file> 3. Check base64 encoding Verify your own signature of type PKCS#7 with openssl: 1. Check your own hash (result of your code) against the hash calculated by openssl; openssl dgst -sha256 <payload-file> 2. Verify your own signature (result of your code) against your public key with openssl; openssl smime -verify -inform DER -in <binary sig.der> -content <payload-file> -certfile <certificate> -noverify -nointern 3. Check Base64 encoding : 32

33 Appendix 3: Randvoorwaarden Rabo Internetbankieren Professional LET OP: onderstaande is niet van toepassing voor Generic Payment Files. Dit formaat kan tot nader order niet in combinatie met RIB Pro worden gebruikt. Definities Batches: een som van één of meerdere losse opdrachten CT of SDD; Bestanden : een bestand bevat meerdere batches CT of SDD of losse opdrachten Wereldbetaling; Losse opdrachten: individuele betalingen die in een BTL 91 (Wereldbetalingen) bestand of batch CT of SDD zitten. Randvoorwaarden agenderen en/of tekenen via Rabo Internetbankieren Professional Agenderen Intrekken 1 e handtekening SEPA DD batch 2 e handtekening SEPA SCT batch > e handtekening verplicht* Wereldbetaling BTL91 batch 1 e handtekening wordt gezet in scherm zetten 2 e handtekening. * het bedrag van de verplichting van de tweede handtekening kan iom de bank aangepast worden. Randvoorwaarden agenderen - U kunt uw opdrachten geagendeerd insturen tot en met 365 dagen in de toekomst; - Geagendeerde batches zijn in te trekken totdat deze de verwerking in gaan. De tijdslijnen van verwerking kunnen voor u belangrijk zijn. Kijk voor de Brochure tijdslijnen Girale Verwerking op de volgende webpagina: Verwerkingstijden. 33

34 Appendix 4: Certificate generation step-by-step To demonstrate the certificate generation process we use a free tool (XCA) to show the steps involved (to be installed on a pc). In section A the process for generating a self signed certificate is described. In section B you find the process for generating a Certificate Signing Request (CSR) for signing by a Certificate Authority. URL: Setup for first use Start the application Select New Database from the File menu, select a name and location for the database and optionally set a password Select File > Options and set the following values: Default hash algorithm: SHA 256 Check Disable legacy Netscape extensions Click OK In the main application view, select the Templates tab Click New Template, then click Ok On the Subject tab, fill in the template name (e.g. Rabobank RDC) and your company details. Only the commonname field is mandatory. 34

35 On the Extensions tab, set Type to End Entity and enable the Critical checkbox On the Key Usage tab, select Digital Signature and Non Repudiation Then click OK A) Generate a self-signed certificate for use in the Customer Acceptance environment In the main application window, select the Certificates tab. Click New Certificate 35

36 Select the Rabobank RDC template and click Apply all. Then, select the Subject tab. Click Generate a new key. A popup appears. Give the key a name and make sure the Keytype is RSA and the Keysize is 2048 bits. Then click Create to create the private key. Finally, click OK to create the self-signed certificate. B) Generate a Certificate Signing Request (CSR) for signing by a Certificate Authority In the main application window Certificate signing request tab, click New Request. 36

37 Select the Rabobank RDC template and click Apply all. The unstructuredname and challengepassword are depending on what the certificate authority requires and are usually optional. Click Apply all Select the Subject tab and give the request an Internal Name for your own reference. Next, click Generate a new key. Give the new key a suitable name. Click Create Finally, click OK. The CSR has been created and can be exported in the format required by the Certificate Authority. Extracting the certificate and private key In the main application window Certificates tab, select the newly created or imported certificate in the list, and click Export. Choose a filename and select PEM as Export Format. Click OK. Now the certificate is saved in the proper format for sending to the Rabobank. From the main application s window Private Keys tab, select the newly created private key in the list, and click Export. Select a format suitable for your application, choose a filename and press OK. 37