Rabo Direct Connect. Manual

Transcription

1 Rabo Direct Connect Manual November 2017

2 Contents 1. INTRODUCTION Options Formats Preconditions for use 6 2. CUSTOMIZING RDC FOR USE The RDC Application form Changing or terminating the agreement Setting up the sftp connection with Rabobank The signing of payment files PKCS# Creating a signing certificate Verifying the files from Rabobank Test scenarios 9 Testing the sftp link 9 Testing through the Customer Acceptance Environment 10 Testing in production by means of penny tests Go Live decision Service messages THE CUSTOMER ACCEPTANCE ENVIRONMENT Description of the Customer Acceptance Environment Test facilities of the Customer Acceptance Environment 11 Technical test 11 Testing status information PAIN.001 and PAIN Testing status information BTL91 11 Testing payment initiation files 12 Testing reporting information Apply for Customer Acceptance Environment Self signed certificate Disclaimer INITIATION Initiating a direct debit or payment order The initiation file The header file Checks The payload file 14 2

3 4.3 ZIP archive DEFLATE The initiation step by step What can you expect if something goes wrong? Execution dates and scheduled payments STATUS MESSAGES AND REPORTING ACK/NACK status messages PAIN.002 status messages Reporting information Direct transmission step by step Bundled reporting information Intraday reports 22 Intraday current book date 22 Intraday multiple book dates 22 Format 23 Comparison table - two versions of intraday reports SCHEDULING, WITHDRAWING AND SIGNING OF YOUR ORDERS Setting up a RIB Pro agreement Functionalities RIB Pro 25 Future Payments 25 Withdrawing 25 Signing PRODUCT OVERVIEW SUPPORT AND SERVICE Contact details Emergency procedure for blocking RDC connection 28 APPENDIX 1: REJECT REASON CODES 29 APPENDIX 2: CHECKLIST SIGNING 33 Verify your own signature of type RAW with openssl: 33 Verify your own signature of type PKCS#7 with openssl: 33 APPENDIX 3: FRAMEWORK FOR USING RABO INTERNET BANKING PROFESSIONAL 34 PLEASE NOTE: INFORMATION BELOW DOES NOT APPLY FOR GENERIC PAYMENT FILES. THIS FORMAT CANNOT BE USED IN COMBINATIONS WITH RIB PRO UNTIL FUTHER NOTICE. 34 APPENDIX 4: CERTIFICATE GENERATION STEP-BY-STEP 35 Setup for first use 35 A) Generate a self-signed certificate for use in the Customer Acceptance environment 36 B) Generate a Certificate Signing Request (CSR) for signing by a Certificate Authority 37 Extracting the certificate and private key 38 APPENDIX 5: CHANGE LOG 39 3

4 4

5 1. Introduction RDC is a host-to-host solution for Financial Institutions, Large Corporates and Mid Corporate Clients of Rabobank. RDC can be used to exchange payment files with Rabobank. This channel allows clients to use their ERP application to send files with signed orders for processing by Rabobank. No specific user interface is therefore needed for this application. The reporting information can be uploaded directly in the ERP application. Via a PULL mechanism you can collect it from RDC. 1.1 Options A summary of the range of options offered by RDC is set out below. Orders can be submitted in the following formats: BTL 91: World Payments, Urgent Payments PAIN Euro Direct Debit PAIN o Euro Payments: payments in the EUR currency to a beneficiary in a SEPA country o Urgent Domestic Euro Payments: urgent payments in the EUR currency between Dutch bank accounts o Urgent Euro Payments: urgent payments in the EUR currency to a beneficiary in a SEPA country o World Payments: payments to a beneficiary in a non-sepa country in any currency (also EUR). It is now possible to deliver a PAIN.001-file containing a mix of batches with different payment types. This is a so called Generic Payment File, and should comply with the following conditions: One debit account per batch A batch can consist of only Euro Payments (excluding Urgent Domestic), or of Urgent and/or World Payments Status information can be sent in the following formats: ACK/NACK: ACK means approved and NACK means rejected Status message: PAIN (with rejected or refused payment or direct debit-orders ) Reporting information can be sent in the next formats: End of day statement: MT940 Structured End of day statement: CAMT Intraday reports: MT942 Structured Intraday reports: CAMT

6 1.2 Formats Detailed RDC format descriptions for all files referred to above are available here: Preconditions for use Before you can get started with RDC it is important to consider the preconditions listed below. Clients who cannot comply with the conditions below may be unable to fully enjoy the benefits of RDC. Neither can we guarantee that we can give the optimal support. Please take this into account if you opt for RDC. A high degree of automation is in place within your business. A professional IT environment and good infrastructure are in place within your business. There is a high degree of treasury centralization within your business. There is a centralized AP/AR (SSC or payment factory). Permanently available ICT (security) expertise is required in your business for using Rabo Direct Connect and safeguarding its security. 6

7 2. Customizing RDC for use 2.1 The RDC Application form You can state on the RDC Application form (available via your Rabobank) how you wish to set up your RDC agreement, for instance: Which Rabobank accounts you want to use in combination with RDC. It is also possible to receive savings account(s) reports Which type of reporting information you wish to receive If you want to receive intraday statements and with which schedule Which type of initiation files you wish to submit Which address your RDC service notifications should be sent to It is important that you consult Rabobank on the contents of this form. If you need assistance in filling out this form you can use the associated explanatory notes form or ask your Rabobank contact. 2.2 Changing or terminating the agreement You can also use the Application form to change your RDC agreement. This allows you to state that you want to inform us of a change, and you can then state the change on the form. You can also use this form to terminate the agreement. The explanatory notes form contains clear instructions on how to inform us of a proposed change or termination. Please read this form first if you have any questions. 2.3 Setting up the sftp connection with Rabobank The first step you need to take is setting up the secure FTP (sftp) connection with Rabobank. sftp is a Secure Shell (SSH) connection via a single port and logging in and file transmission always takes place in a secure session. The programming for creating a sftp connection is sometimes available as standard on a server platform. If not, it needs to be installed. This component facilitates the secure transmission of files between your organization and Rabobank. The connection always consists of a test connection and production connection. This connection requires you to have a sftp client, within which you generate two SSH keys for which you will manage the private keys. The private keys must be stored in the location where your sftp client is running. We will need the following from you: The public key of the SSH key for the production connection The public key of the SSH key for the test connection Please provide the keys with your Application form. If we have any questions regarding the keys we will be contacting the person in your IT department whom you designate for that purpose in the Application form. Please make sure that this (these) person(s) is (are) available during the implementation of RDC. We will also require further information to set up the connection, in addition to the SSH keys. You must provide this information, for instance the IP addresses and the ports to be used, in the Application form. 2.4 The signing of payment files In addition to setting up the safe connection with the bank, the payment files must be signed. This signature confirms that no changes have been made in the payment file during transportation. It also confirms the identity of the client. The signature of the file is an SHA-256 hash of the payload file encrypted using a 2048 bit RSA key provided by you, the client. 7

8 In order to be able to verify the signature of the payment file you need to provide a X.509-certificate to Rabobank. This certificate is the public counterpart of the RSA private key that is used for signing, and is used to verify the signature. How the RSA private key plus certificate can be obtained is described in Chapter PKCS#7 The signature of the payment file can be sent in raw format or in PKCS#7 format, both of which are accepted by RDC. As a rule, Java applications generate the raw format if JCE libraries are used and PKCS#7 formats if libraries such as Bouncy Castle are used..net usually generates PKCS#7 signatures. 2.6 Creating a signing certificate Rabobank currently accepts certificates issued by the parties below. You can choose one of these two certificates. In case of other parties please contact your implementation manager. For both the Customer Acceptance Environment (CAE, see Chapter3) and the production environment certificates are required. However, for the CAE a self signed certificate is sufficient, which makes third party certification unnecessary. A self signed certificate is not allowed in the production environment; this one needs to be signed by a Certificate Authority. Currently, Rabobank accepts certifcates of below mentioned Authorities. In case you want to use a certificate of another party, please contact your Implementation Manager. Bare is mind that a certificate is not free of charge and needs to be updated regularly. Symantec How to apply a certificate from Symantec can be found on Symantec s site: Digicert How to apply a certificate from Digicert can be found on Digicert s site: NOTE: the validity of certificates may not exceed 2 years. Please make sure to inform your supplier accordingly. The expiration date of the certificate needs to be entered in the Application form. However, it is the clients responsibility to monitor the expiration date, and to apply for a new one well before the end of the validity. Do not forget to provide Rabobank with the details of the new certificate accordingly, in order for Rabobank to be able to continue the RDC services smoothly. An extensive description of the process how to obtain a certificate can be found in Appendix 4. A diagram of the procedure: 8

9 The certificate should be sent to Rabobank as follows: <client name> RDCpublickey.crt.txt. Please make sure to carefully follow the instructions for sending the certificate. These can be found in the Explanatory notes RDC Application form. Do not forget to sign the form. 2.7 Verifying the files from Rabobank Rabobank also adds a signature to the files it sends to the client. You can verify this signature by using the public key in the X.509 certificate of Rabobank. You can find the public key for RDC on in Downloads. 2.8 Test scenarios As client, you will want to test the use of RDC before you actually start using it. This section contains some brief recommendations for performing those tests. All tests require you to arrange the timing of each specific test in advance with the implementation manager of Rabobank. Otherwise the bank cannot ensure that the proper support is in place to assist you at the time concerned. Testing the sftp link After the IT departments (yours and Rabobank s) have jointly set up the sftp connection (a test and a production link) we advise you to test this connection by sending a payment file via the test connection that has been established. This connection allows you to check whether files are correctly transmitted from your environment to Rabobank. In addition, Rabobank can send you a file via this connection to check whether files are correctly transmitted from the bank to your environment. 9

10 Testing through the Customer Acceptance Environment Through the Customer Acceptance Environment you can test your connection with RDC and your metadata (header.xml). Please read Chapter 3 for more details. Testing in production by means of penny tests After we have tested the sftp link in the test connection and obtained a positive outcome, we advise you to perform a penny test first by sending one or a small number of low-value payments from and to an account within your organization. To do so, it is advisable to perform a separate test for each payment format that you will be using and to establish that the low-value payments are processed properly and stated correctly in the reported information. 2.9 Go Live decision After the various tests have been successfully performed, you must decide in consultation with Rabobank whether you want to go live with RDC. If the tests have established that there are no longer any impediments to doing so, the RDC connection can be used for your normal payment transactions. The Go Live decision must be taken in consultation with Rabobank Service messages Rabobank uses service messages to inform you of maintenance, new functionality and downtime with regard to RDC. Via this channel, Rabobank tries to inform you at least one month in advance of new functionality, giving you enough time to prepare for the new situation. In the Application form you fill in the address(es) that can be used for these service messages. If you want to change this later, please use the Application form again to inform us accordingly. Please note that the s will be sent to all addresses mentioned in the Application form. 10

11 3. The customer acceptance environment 3.1 Description of the Customer Acceptance Environment RDC has a Customer Acceptance Environment (CAE) in addition to the production environment. This environment is separate from our production systems and simulates RDC's operations. You can use this system to test whether your ERP application is configured correctly for sending initiation files via RDC, and receiving status messages via RDC. If you send a test file in BTL91-format, and all conditions are met, you will receive an ACK- and next a PAIN.002-message. If you send a test file in the formats PAIN.001 or PAIN.008, and all conditions are met, only a PAIN.002-message will be sent. In both cases this PAIN.002 will contain a random rejection code and is not related to the file you supplied. You receive the PAIN.002 so that you can immediately verify whether your system is ready to receive and process files of this kind. If the files composition is not in accordance with these conditions, you receive a NACK. This is not followed by a PAIN.002-message, because the file was rejected in an early stage in the chain. In addition, Rabobank will send you a simulated reporting file. You can choose: CAMT.053 or MT940 Structured. You can state your choice on the Application form. Within the Customer Acceptance Environment there is no connection with Rabo Internetbankieren Professional for testing the withdrawal or signing of batches. Technical test 3.2 Test facilities of the Customer Acceptance Environment Testing sftp connection RDC and FileAct (connection customer Rabo) Testing metadata (header.xml) Testing status information PAIN.001 and PAIN.008 Status information type Description ACK You will not receive an ACK message when you send a test-file in PAIN-format NACK You will receive a NACK message when the connection or header are not accepted PAIN You will receive a PAIN.002 if the connection and header are accepted. This PAIN.002 contains dummy data Testing status information BTL91 Status information type ACK NACK PAIN Description You will receive an ACK message when the connection, the metadata (header.xml), and the file are accepted You will receive a NACK message when the connection or header are not accepted After an ACK message you will receive a PAIN002 containing dummy data 11

12 Testing payment initiation files With this test you will check the format and layout of the file. The content of the PAIN-file will not be tested. You can use MyStandards for testing the payload of your PAIN-files. More information about MyStandards is available on this site or you can contact your Rabobank contact person. Initiation file PAIN PAIN BTL91 Testing reporting information Reporting MT940S CAMT The reporting information will be sent around 16:00 CET (time may vary). Eventually in the production environment end-of-day reporting will be sent around midnight and before 06:00 CET. 3.3 Apply for Customer Acceptance Environment You have two options when applying for a Customer Acceptance Environment. You can keep your Customer Acceptance Environment the same as your production environment; this means that you arrange for the same accounts and services to be entered in your Customer Acceptance Environment as those in your production environment. You can also opt to enter different accounts or services in your Customer Acceptance Environment. 3.4 Self signed certificate To use the Customer Acceptance Environment you require a separate certificate which you can request from a third party agency, such as Symantec, by following the procedure described in section 2.6. However, you are also permitted to use a self-signed certificate in the Customer Acceptance Environment. For security reasons you cannot use the production certificate for the Customer Acceptance Environment. We hereby remind you that a certificate contains the public key which is used to verify the signature. With a self-signed certificate you generate your own pair of keys (RSA, 2048 bits, private and public key) and then produce a certificate which is signed with the same key. In the case of a real certificate, the certificate is signed by a third party, after verification of the company's identity and the public key's delivery in a certificate application file. You have to send the self-signed certificate with your application for the Customer Acceptance Environment. 3.5 Disclaimer Rabobank stresses that results achieved in the test environment are not a guarantee for the production test and that no rights or obligations can be derived from them. We therefore advise you to perform a number of penny tests through your production connection once you have tested the Customer Acceptance Environment. 12

13 4. Initiation 4.1 Initiating a direct debit or payment order The initiation of a direct debit or payment order cannot be described in general terms as every organization uses its own software for this. Files are exported from that software to RDC via the sftp link established as described in chapter 2. We advise you to consult the user manuals provided by your accounting application/software supplier for that purpose on any questions concerning the use of their software. This chapter describes the requirements for the format of the initiation files and the naming conventions the files must comply with. 4.2 The initiation file The initiation file consists of a header (section 4.2.1) and a payload file (section 4.2.3). A file may constis of 1 or more batches. Another term for batch is Payment Initiation Block. There is a number of rules for naming initiation files. We will refer to this below by means of the file name. We advise you to use the following formats for the file name of the file (however, this is not compulsory): <action>_<customer-id>_< contractid >_<datetime>.zip Explanation: <action> can be SCT for Credit Transfers (Euro Payments, and Urgent Euro and/or World Payments, in case of delivery via PAIN.001/Generic Payment File), SDD for SEPA Direct Debits or BTL for World Payments in BTL91 format. <customer-id> is the client identification code. This customer id make you yourself. Conditions are that this is alphanumerical and that is consists of eight characters maximum. < contractid > is the identification number of the agreement. You have received this contract ID from Rabobank. <datetime> Is used to make the file name unique, numerical, yymmddhhmmssxx (y = year, m = month, d = day, h = hour, m = minute, s = second, xx = sequential number or hundredth of a second). Besides the above, the following rules apply for the file name: Case sensitive, no spaces allowed, underscores must be used to separate the various components. The maximum length of the file name is 175 characters. Permitted characters: 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 _ The header file The following applies for naming a file file: <header>.xml The header contains the client s signature and other metadata. The format of the header is as follows: 13

14 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 Explanation of the tags: Field Explanation Allowed values Required Comment 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 Checks You can correctly create and validate the XML files by using the RDCInitiationRequest.xsd file. The file RDCInitiationRequest.xsd is available on in downloads The payload file We advise you to use the next description for the payload file (this is not compulsory): PAIN: <action>_< customer-id>_<datetime>.xml BTL91: <action>_< customer-id>_<datetime>.txt 14

15 Explanation: <action> can be SCT for SEPA Credit Transfers, SDD for SEPA Direct Debits or BTL for World Payments in BTL91 format. <customer-id> is the client identification code. This customer id make you yourself. Conditions are that this is alphanumerical and that is consists of eight characters maximum. <datetime> Is used to make the file name unique, numerical, yymmddhhmmssxx (y = year, m = month, d = day, h = hour, m = minute, s = second, xx = sequential number or hundredth of a second). It is not possible to combine PAIN.001-batches with PAIN.008- or BTL91-batches in one file. Both the header and the payload file must be based on the UTF-8 character set. 4.3 ZIP archive DEFLATE The compression method that is supported is DEFLATE. This compression method is used worldwide in many programming languages and operating systems tools. A technical description is available here. 4.4 The initiation step by step 1) ERP system generates payment file (optionally you can encrypt the enclosed payload file). 2) Payment file is signed. The signature (encrypted SHA 256 of the payload) is necessary to assure its origin and integrity. Signing is mandatory, from a security perspective. The signature is encrypted using the private key from your keystore. 3) Payment file is ready for sending (optionally after compressing the file). 4) Client starts up sftp session. 5) Rabobank s sftp server verifies whether you are who you claim to be (authentication). If you are not recognized, the connection will be disconnected and it will not be possible to transmit files to Rabobank. 6) Payment file is sent. 7) The file will be decompressed. 8) Signatures and client agreements are checked. 9) If the payload was encrypted, decryption will take place now. Eventually the payment file will be checked, and enter the processing chain. 4.5 What can you expect if something goes wrong? If a file is sent to Rabobank via the secure (sftp) connection a range of checks will be performed by RDC. If they are negative, Rabobank will send you a NACK (negative acknowledgement) or a PAIN.002. In that case, Rabobank will not proceed to process the file. Appendix 1 provides an overview of the possible rejections, which are only briefly outlined below. In case decompression is nog possible, you will receive a NACK message. 15

16 The process checks whether the file has been changed, by checking the accompanying signature (SHA 256 file). A NACK message will be sent to you if the integrity cannot be verified. We check whether the file type is recognizable and whether you are authorized to submit files of that type. If you are not, you will receive a NACK message. To prevent a file being accidentally processed twice, we check whether the same file has not already been submitted. This is done on the basis of the file name and the payload. We will send you a NACK message if it identifies a duplicate. Decryption. If the file has been encrypted, Rabobank will decode the file. A NACK message will be sent to you if the file cannot be decoded. We check whether the file submitted can be processed. Those checks are: o Does the format of the payment file comply with the requirements set out in the Rabobank formatdescription (link)? o Are there no deviations from the prescribed character set? o Is the maximum of 100,000 payment orders per file not exceeded? o Is the maximum of 10,000 batches in one file not exceeded? o Is the account to which the payment order relates included in the RDC agreement? o Is the requested execution date for the transaction payment valid? See section 4.6. o Does the payment order comply with requirements pursuant to statutory and regulatory provisions? o During the processing of a payment order a number of checks will be conducted. In case the outcome is not satisfactory, a PAIN.002 will be sent. 4.6 Execution dates and scheduled payments It is possible to submit payment orders with a future execution date when used in combination with Rabobank Internet Bankieren Professional (RIB Pro). It is also possible to submit payment orders with execution dates in the past. Payment orders must comply with the requirements below: Payment orders via PAIN.001: Today - 14 days <= execution date <= today Today + 1 day <= execution date <= today +365 days Other (too far in the past/future) Batch will be processed immediately. RIB Pro not required Only possible in combination with RIB Pro. If not, batch will be rejected Batch will be rejected Urgent and World Payments via BTL91: Today - 10 days <= execution date <= today +10 days Today + 11 days <= execution date <= today +365 days Other (too far in the past/future) No RIB Pro required Only possible in combination with RIB Pro. If not, payment order will be rejected Payment order will be rejected 16

17 SDD via PAIN.008: Today - 14 days <= execution date <= today + 20 days Today + 20 days < execution date <= today +365 days Other (too far in the past/future) No RIB Pro required Only possible in combination with RIB Pro. If not, batch will be rejected Batch will be rejected Please note that the channel RDC checks the execution date and not the submission date. The respective submission dates for SDD Core is D-1 before 7:00 AM, and for SDD B2B it is before 11:00 AM. This applies to all types of SDD: First, Recurrent, One-off, and Last. If payment orders are received before mentioned times, they will be processed immediately, and credited in the account the next day. Urgent Payments can be submitted in 2 formats: BTL91 and Generic Payment File (PAIN.001). In the latter option, a separate batch containing only Urgent Payments (possibly combined with World Payments, but not with Euro Payments!) must be submitted. RDC processes payments in accordance with Rabo timeframes. You will find relevant information on payments here: Opening hours on public holidays. 17

18 5. Status messages and reporting 5.1 ACK/NACK status messages Rabobank strives to return an XML file within 15 minutes for every file that is submitted. This XML message states whether or not the file was accepted. An accepted file will result in sending an ACK. In case the file is rejected, a NACK will be sent. An example of a NACK message is provided below Example: 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> Explanation of the tags:field Explanation Allowed values Required Comment 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 You can correctly create and validate the XML files by using the RDCInitiationReply.xsd file. The file RDCInitiationReply.xsd is available on in Downloads. Standard naming format: originalfilename_<customerreference>_reply.xml 18

19 The message is based on the original file name chosen by you, followed by an underscore and the customer reference. This customer reference is equal to your RDC contract-id. If the file you submitted cannot be read and the customer reference cannot be determined, no customer reference will be provided. In that case the file name will have the following format: Originalfilename_reply.xml If the file is submitted twice, for whatever reason, you will receive two responses: Originalfilename_<customerreference>_reply.xml (normal ACK/NACK) Originalfilename(1)_reply.xml (NACK because a duplicate has been identified) The 1 indicates that this relates to the first duplicate and always contains a NACK. The reference is not specified in this line. 5.2 PAIN.002 status messages If processing of payment and direct debit initiations reveals that a batch or individual payment order cannot be executed, Rabobank sends you an XML message: a PAIN.002. This service can only be used for initiations that are submitted in PAIN-format. NOTE! This is not the same message as the ACK/NACK messages sent by RDC! Features of a PAIN.002 message: PAIN.002 messages will be sent on batch- or on transaction level. Pre-settlement R-messages will also be made available via PAIN.002 (in addition to gross bookings included in the statement) Please note: The rejection with reason at transaction level will contain the complete original transaction details. In the case of a salary payment, this means that the amount and the beneficiary are also included in the PAIN.002 message. A functional and a technical format description are available on in Downloads under Export formats. Descriptions of the rejection or return codes provided in the PAIN.002 are available in the Functional Format Description PAIN.002. The structure of the PAIN.002 file name is as follows: <Original file name including extension such as.xml and/or.zip>_<four digit sequence number>- PAIN002.xml For example, if this was the name of the original file, provided by you : SCT_ _ xml.zip, the first PAIN.002 you receive has the following name: SCT_ _ xml.zip_0000-PAIN002.xml 5.3 Reporting information A reporting file (End of day) is sent at the close of the day in the chosen file format (CAMT.053 or MT940 Structured). Intraday reporting is available in RDC via CAMT.052 and MT942 Structured.. A reporting file will remain available for a period of 2 months and can be retrieved via your sftp link. Please note that you can no longer retrieve CAMT.053, MT940 Structured, CAMT.052 or MT942 Structured after the 2-month period. Please find an example of RDC generated CAMT.053 below: 19

20 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 Explanation of tags: Field Explanation Allowed values Required Comment XML type ContractId Y string UniqueReference Y Value from Rabobank Timestamp Y Value from Rabobank PayloadList: Payload: File name 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 You can correctly create and validate the XML files by using the RDCInformationReply.xsd file. The file RDCInformationReply.xsd is available on in downloads. Reporting information is delivered in a zip file with a header containing a signature. The format of the zip file is as follows: StatementType_Date_Time_ContractId_StatementTransportAgreementId.zip Examples: CAMT053_ _152431_ _590.zip MT940S_ _152431_ _8.zip 20

21 5.4 Direct transmission step by step 1) Rabobank s BackOffice systems generate the reporting information as agreed with you. 2) The reporting information is encrypted (optional). 3) The reporting information is lined up for retrieval. 4) Rabobank sends the message to your system. 5) The sftp server verifies whether you are who you claim to be. If you are not recognized, the connection will be broken off. 6) Next, you retrieve the file and move it to your chosen target location. 7) You terminate the connection with the bank and can process the file in your ERP system. 5.5 Bundled reporting information As a rule Rabobank sends one bundle (.zip) per reporting service containing all the account numbers covered by your contract. However, you may also opt to divide reporting information into a number of bundles. For example, you can set up a separate batch for each business unit. This makes it easy to keep account numbers separated from each other in your ERP system and there is no need to search for all the statements in a single Bundle. This option is applicable for both end of day reporting and intraday information. On the Application form you can indicate what bundles you want to compose. The example below shows bundles for end of day reporting: Account CCY MT940 Bundle CAMT.053 Bundle Structured NL81RABO<account1> EUR X 1 NL81RABO<account2> EUR X 1 NL81RABO<account3> EUR X 1 NL81RABO<account4> EUR X 1 NL81RABO<account5> USD X 1 NL81RABO<account6> GBP X 1 NL81RABO<account7> EUR X 2;1 NL81RABO<account8> EUR X 2;1 NL81RABO<account9> EUR X 2 NL81RABO<account10> EUR X 3 X 2 NL81RABO<account11> EUR X 3 NL81RABO<account12> EUR X 3 NL81RABO<account13> EUR X 3 21

22 This example includes accounts 1 to 8 in Bundle 1, accounts 7 to 10 in Bundle 2 and accounts 10 to 13 bundle 3. Accounts 7 and 8 are included in batch 1 as well as in batch 2 and account 10 is included in batches 2 and 3. It is not possible to enter CAMT.053 and MT940 Structured or CAMT.052 and MT942 Structured in a single bundle as these formats will always be sent in different bundles. This appears in the files you download as follows (with the bundle code indicated in bold text): StatementType_Date_Time_ContractId_statementTransportAgreementId.zip Example: MT940S_ _213818_ _7.zip The bundle name (code) must contain only letters and numbers and is up to 8 characters long. The bundle name can be specified on the Application form. If you do not specify a bundle name the RDC system generates a number for you automatically, based on an ID. This number is up to 19 characters, and will be provided by to you by Rabobank during your implementation. 5.6 Intraday reports You can receive a report of transactions credited or debited before close of business on that day, otherwise known as an intraday report. This enables you, for example, to complete reconciliation earlier, release deliveries and/or determine your cash position more effectively during the day. To receive your intraday reports you can choose from two versions: the Intraday current book date and the Intraday multiple book dates. You can add intraday reports to your RDC contract using the Application form. You can also use this form to make any subsequent changes. In order to apply for intraday information for an account, the account must already be part of the end-of-day reporting operating under this contract. Intraday current book date Intraday current book date contains all transactions of the current book date. It contains only new transactions of the current book date. Each query contains new transactions. Intraday information is only delivered on workdays. In the weekends and/or on Target closing days no intraday information is delivered. The first delivery time is at 07:00 CET, the last delivery time is at 18:00 CET. Via the Application form you can choose to receive an intraday report after the last delivery time with the remaining transactions, in order to ensure your intraday report connects to your end of day report. The intraday reports can be delivered per bundle. If there is no new intraday information available in a bundle no new report is delivered. Do you wish to receive an empty intraday report, please indicate so on the Application form. Intraday multiple book dates Intraday multiple book dates contains transactions of a specific period, you can indicate the desired selection period on the Application form. The report will contain transactions that exceed a book date. This version is delivered seven days a week. You can also to choose to receive intraday information on Target closing days, you can indicate this on the Application form. This version does not connect to the end of day report and is especially suitable if you wish to receive intraday information continuously. The intraday reports can be delivered per bundle. If there is no new intraday information available in the bundle no new report is delivered. Do you wish to receive an empty intraday report, please indicate this on the Application form. 22

23 Format You can receive the intraday reports in two formats, SWIFT MT942 Structured (MT942S) or CAMT.052. The advantage of the MT942 Structured is that this format is based on a standard which already has been supported by many financial administrations/erp applications for quite some time and can therefore be relatively easily imported into your own financial administration. The advantage of the CAMT.052 format is that it is based on the XML standard and is suitable for full reporting of all fields that you can submit when making a Euro payment (SEPA Credit Transfer) or Euro collection (SEPA Direct Debit). A functional description of the two intraday formats is available at via Downloads Export formats. Comparison table - two versions of intraday reports In the table below you can compare the two versions. Description Intraday current book date Intraday multiple book dates Days on which intraday transactions are delivered Only on workdays, not on Saturday, Sunday and Target closing days 1. Every workday, Saturday, Sunday and Target closing days 2. First possible delivery time 07:00 CET. The first report of the day delivers all debit/credit transactions since the end of the previous book date. Last possible delivery time Delivery At set times Maximum of ten fixed delivery times with 15 minutes in between and including the first and last delivery time, e.g. at 07:00, 11:15, 15:30, 17:00 and 18:00 CET. Delivery through Book dates With set frequency What happens if there are no transactions to be reported? Start of current book date 3. 18:00 CET 4. End of current book date. Every 15, 30, 60 or 120 minutes the debit/credit transactions are reported, from the first delivery time up to and including the last delivery time. Secure File Transfer Protocol (sftp) or SWIFT FileAct 5 You only receive transactions booked with book date today. You can choose to receive an intraday report when there are no transactions booked since the previous delivery time of an intraday report for the accounts in the bundle for which intraday reports are set. You can indicate this on the Maximum of ten fixed delivery times with 15 minutes in between and including the first and last delivery time, e.g. at 07:00, 11:15, 15:30, 17:00 and 18:00 CET. Every 15, 30, 60 or 120 minutes the debit/credit transactions are reported. Secure File Transfer Protocol (sftp) or SWIFT FileAct 5 Multiple book dates. You can choose to receive an intraday report when there are no transactions booked since the previous delivery time of an intraday report for the accounts in the bundle for which intraday reports are set. You can indicate this on the Application 1 On Target closing days no payments in Euros are possible, transactions are not processed. Target closing days are: New Year's day, Good Friday, Easter Monday, Labour Day, Christmas and Boxing day. 2 With this version of intraday reports you can choose to receive intraday information on Target closing days. You can indicate this on the Application form. Target closing days are: New Year's Day, Good Friday, Easter Monday, Labour Day, Christmas and Boxing Day. 3 Intraday multiple book dates is delivered 24 hours per day and seven days a week. The first delivery time is 00:00 CET, the last delivery time is 23:45 CET. 4 It is possible that more transactions are processed with book date today after 18:00 CET or after your last set delivery time. It is therefore possible that transactions are reported on your End of day statement (MT940S of CAMT.053) which were not reported through an intraday report. You can choose to receive these transactions intraday by indicating this on the Application form. 5 You receive a Zip-file via sftp, containing a header file with signature and a MT942S of CAMT.052 file. 23

24 Application form. form. Available formats MT942S and CAMT.052 MT942S and CAMT

25 6. Scheduling, withdrawing and signing of your orders By combining RDC with Rabo Internetbankieren Professional (RIB Pro), it is possible schedule, withdraw and/or sign the batches/order that you initiated using RDC. We will describe these features in RIB Pro, but limit ourselves to that part which is relevant for the use in combination with RDC. For more information about RIB Pro and safe banking, please visit the following websites: RIB Pro Log in Rabo Internet Banking Professional Support for Internet Banking Professional More about safe banking online 6.1 Setting up a RIB Pro agreement To use RDC in combination with RIB Pro, an agreement for RIB Pro is necessary. This agreement including key cards and Rabo scanners will be set up next to the RDC agreement. Once the RIB Pro agreement is available and active, the Owner of the agreement grants functionalities, accounts, limits and access tools to each user. You can find the settings for authorisations under Self-service Authorisations. You can determine which users are allowed to place the first and/or second signature per batch/payment order. Note that second signature is only available for Euro Payments, first signature is also possible for SDD/PAIN.008 and BTL91. For setting up signature rights in RIB Pro the next conditions apply: First signature: At least one user should be allowed to place the first signature for all accounts in the file Second signature (only for Euro Payments): For every account in the file, at least one user should be able to place the second signature For more information about the authorisations withing RIB Pro please refer to the manuals Authorisations and limits and Extensive account authorisations. 6.2 Functionalities RIB Pro Future Payments It is possible to view payment and direct debit orders in RIB Pro, if they were submitted within the timelines mentioned in chapter Fout! Verwijzingsbron niet gevonden., provided that the user is authorised to do so. Withdrawing In RIB Pro it is possible to withdraw future dated batches and payment orders. However, for batches that were submitted via Generic Payment File this feature will become available in due course. Until that moment a workaround via Customer Support is in place. 25

26 Signing Currently, only BTL91-, SDD- and SCT-files can be signed. It is also possible to place a signature on batch-level for SCT. However, signing Generic Payments Files- and batches in RIB Pro is not available yet. This will become available in due course. 26

27 7. Product overview It is possible to request a product overview for additional insight into your product settings. If you wish to receive this product overview (in Dutch) you can request this via your contact person at Rabobank. The product overview is a.pdf file containing the following data: Company name and address information Contact information Contract information Account information o Products o Charge account o Bundled Intraday settings 27

28 8. Support and service 8.1 Contact details After you have successfully start using Rabo Direct Connect, you can contact the Rabo Corporate Support Desk with any questions you might have and for troubleshooting. Support Desk: Rabo Corporate Support Open: Monday to Friday from 8:00 to 17:30 CET Telephone: +31 (0) Website: Please note that we will require the following information from you in order to deal with your question appropriately: Your details: Business name or other reference The question/problem Information about the relevant download/upload, such as the date, time and file name 8.2 Emergency procedure for blocking RDC connection When there is or when you suspect that your RDC-connection is being wrongfully used, you can contact Rabobank Corporate Support during mentioned business hours. Outside these business hours an emergency hotline is in place. Telephone: +31 (0) This number can be used only for this emergency procedure. In all other cases, there is no support outside office hours. When you call this number, you will be asked for your contract ID for verification purposes. Make sure you always have this number ready when you call. You received this number as part of the implementation of RDC. It is therefore important to make sure you have this number available at all times. After we have confirmed your identity, the connection will be broken off and we will initiate the emergency procedure. You will be called back within two hours to confirm that the RDC connection has been blocked. We will subsequently contact you to discuss how the connection can be safely restored. If you called at night you will be called back about this the next morning and if you called during the weekend, you will be called back about this on Monday morning. 28

29 Appendix 1: Reject Reason codes In case a file, batch, or payment order is rejected, a NACK or PAIN.002 will be sent. The type of message that you receive depends on the type of rejection. An overview of NACK messages that might be sent, is set out below. If you do not understand a reject code, please contact the Rabo Corporate Support Desk. The Functional Format Description for PAIN.002 can be found on the site. 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 authorized 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: 29

30 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 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 30escripcate 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. BETAALRECORD_1_NOT_FOUND 100, BetaalRecord 1 was not found at line {0}. SIGNATURE_NOT_CORRECTLY_BASE64_ENCODED AGREEMENT_SERVICE_RETRIEVAL_EXCEPTION INVALID_REQUEST_TYPE NOT_SCHEDULABLE 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: 30

31 Reject reason code 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_INC ORRECT SLUIT_RECORD_TOTAAL_AANTAL_TRANSACTIE_ RECORDS_INCORRECT Description {0}." 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 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}. 31

32 Reject reason code 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 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}" Messages 1, 2 and 100 to 124 are the only available reject reasons for BTL91 payments. 32

33 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) againstthe 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 : 33

34 Appendix 3: Framework for using Rabo Internet Banking Professional Please note: information below does not apply for Generic Payment Files. This format cannot be used in combinations with RIB Pro until futher notice. Definitions Batches: a sum of one or more individual CT or SDD orders; Files: a file consists of multiple CT or SDD batches or individual World Payment orders; Individual orders: individual payments contained in a BTL 91 (World Payments) file or CT or SDD batch. Framework for scheduling and/or signing via Rabo Internetbankieren Professional. Scheduling Withdrawal 1 st signature SEPA DD batch 2 nd signature SEPA SCT batch > nd signature required* World Payment BTL91 batch 1 st signature is placed in menu item Place 2nd signature. * this amount can be adjusted in consultation with the bank. Scheduling framework You can submit scheduled orders up to 365 days in the future Scheduled orders can be withdrawn up until the point when they are processed. The processing time lines can be important for you. View the brochure Timeframes for Payment Processing for Rabobank business clients on the site Processing times. Batches: a sum of one or more individual CT or SDD 34

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

36 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 36

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

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