OP's C2B SERVICES Pain 02. Payment transfer products

Transcription

1 OP's C2B SERVICES Pain 02 Payment transfer products Customer Guidelines March 2015

2 2/105 Version Key Changes Changed section November 2012 added money orders 1.3 C2B money orders July 2013 updated payment removal 1,1,5, and 6 September 2013 C2B urgent payment among SEPA 3.2, 3.6, 3.7 payment data, specified the currencies of foreign currency cheques and SWIFT cheques September 2013 paying in the Baltic countries 1.4 December 2013 Changes to the SEPA End Date setting taken into consideration March 2015 Removed foreign currency cheque from the payment methods of cross-border payments. Removed the previous section 3.4 Minor updates to the document.

3 Contents 3/105 1 General C2B payment Recurring C2B payments C2B urgent payments C2B money orders C2B payments in Estonia, Latvia and Lithuania C2B payload checks by the bank Responses to C2B payment messages C2B cancellation request Sending and retrieval of messages Stages in the process Structure of the payload file sent by the customer Schedules for payload sent by customer to bank Structure of responses retrieved by the customer Response creation and schedules Checking of available funds and payment Clearing codes Charge bearer codes Requirements for adopting the service The testing environment Testing environment IDs and certificates URLs Limitations of the testing environment Help desk and sorting C2B payment initiation message and example descriptions Group Header SEPA payment (incl. instructions for sending urgent payments (one or more) among the rest of the SEPA payload) Recurring SEPA credit transfers are sent in a separate batch (only used in Finland, not in Estonia, Latvia or Lithuania) International payment payment order International payment urgent payment order International payment - SWIFT cheque International payment international payment instruction Real-time C2B urgent payment File type of real-time C2B urgent payment Example message of a real-time C2B urgent payment Bank C2B response and message description Report on technical validation Report on payload content validation Payment status report ( pain ) Report on processed payments ('camt') Response message to a real-time C2B urgent payment initiation message and the reasons of rejection 62 5 C2B cancellation request (camt ) Response to C2B cancellation request (camt ) Example messages Example response messages Report on technical validation Report on accepted technical validation Report on rejected technical validation Report on rejected techical validation of real-time C2B urgent payment Report on payload content validation Report on accepted content validation Report on partially accepted content validation Report on rejected content validation of real-time C2B urgent payment payload... 91

4 4/ Report on payment Report on accepted payload ( pain ) Report on partly accepted payload ( pain ) Notification for successful payment ( camt ) Example responses to cancellation request Report on technical validation (content check) Report on rejected technical validation Report for cancellation request processing Report for successfully processed cancellation request Notification for partially successful cancellation request Report on a totally rejected cancellation request General With the C2B (Customer-to-Bank) payment initiation message, it is possible to use one payment standard for all company bank transfers. C2B messages can be used for invoice payments, recurring payments, money orders, international payments and C2B urgent payments. C2B payment initiation messages are sent to the Osuuspankki batch transfer service and the Web Services channel. The customer retrieves the bank s responses to C2B messages from the channel to which the payment initiation message was sent. PATU2 hash value calculation is required for a C2B payload that is sent to the batch transfer service. In the Web Services channel, the customer verifies the integrity of the payload retrieved from the bank by verifying the digital signature. Using a C2B payment initiation message specified in this description, a company operating in Finland can also send payments where the debit account is an account in Estonia, Latvia or Lithuania. The C2B message is an international ISO message in XML format. The schema for the payload sent to the bank is pain xsd, and the schema for the bank s response that the customer retrieves from the bank is pain xsd. The C2B cancellation request message is an international ISO message in XML format. The schema for the cancellation request sent to the bank is camt The schema for the bank's response that the customer retrieves from the bank is camt The Federation of Finnish Financial Services has published a guide for banks that operate in Finland. It covers the message structure and content of the message used to initiate SEPA credit transfers. In addition to this general guide, the instructions provided by OP apply. The automated cancellation request message must be implemented in compliance with the guidelines issued by OP for the C2B cancellation request. The message descriptions are subject to change. For up-to-date descriptions, please refer to: Website of the Federation of Finnish Financial Services The OP websitewww.op.fi Message types conforming to the ISO standard For the schemas and documentation, please refer to the ISO website at Additional information is also available on the Federation of Finnish Financial Services web site, at Material types in the Web Services (WS) and batch transfer channel

5 5/105 Name Customer-sent materials Credit transfer (incl. C2B urgent payment among SEPA payment data) Recurring payments (Salaries and Pensions) Money orders Cross-border payments Real-time C2B urgent payments C2B cancellation request Customer-retrieved materials Report on technical validation Report on payload content validation Report on payment (rejected) Report on processed payments Report for a processed cancellation request Message types conforming to the ISO standard Schema CustomerCreditTransferInitiantionV02 pain xsd CustomerCreditTransferInitiantionV02 pain xsd CustomerCreditTransferInitiantionV02 pain xsd CustomerCreditTransferInitiantionV02 pain xsd CustomerCreditTransferInitiantionV02 pain xsd CustomerPaymentCancellationRequestV01 camt xsd PaymentStatusReportV02 pain PaymentStatusReportV02 pain PaymentStatusReportV02 pain BankToCustomerDebitCreditNotificationV03 camt MP ResolutionOfInvestigationV03 camt Value of FileType field in WS channel pain pain pain pain pain camt pain pain pain camt camt File identifier of the batch transfer channel XM XM XM XM TP4 PS01 service only in WS channel XP XP XP XC service only in WS channel 1.1 C2B payment For SEPA credit transfers, the account number is given in the international IBAN format. A reference number provided according to the Finnish reference number standard and given as remittance information in a C2B payment message is passed on to the beneficiary in Finland as a reference for the creditor. The reference number is passed on as-is to other countries, but the manner of passing the data on to the beneficiary depends on the beneficiary s bank. For C2B payments to Finland, the payment date that is, information on the account debit date is transferred to the creditor. Additional information can be included in the C2B payment payload in order to facilitate the matching and posting of payments or to identify the debtor, for example. However, it is not possible to guarantee that all information provided will be transferred to the beneficiary, as this depends on the beneficiary s bank. C2B payment messages can contain one written message (max. 140 characters), in either unstructured or structured format. In a structured message (Strd), the 140-character limit also includes XML tags and data. In an unstructured message (Ustrd), the 140 characters include only the content of the element, without XML tags. Finnish reference numbers are provided in a structured message. Instead of the 140-character message, it is possible to transfer a maximum of nine remittance information entries, with a maximum of 280 characters each, to SEPA* banks that operate in Finland. For payments within OP in Finland, structured invoice details (max. 999x280 characters) are allowed. *

6 Aktia HELSFIHH Savings banks, from 1 Nov 2014 ITELFIHH POP banks HELSFIHH (from 7 Feb 2015 POPFFI22) Danske Bank (DABAFIHX) DnB NOR (DNBAFIHX) Handelsbanken (HANDFIHH) Nordea (NDEAFIHH) OP (OKOYFIHH) Danske Bank (DABAFIHH) SEB (ESSEFIHX) S-Bank (SBANFIHH) Swedbank (SWEDFIHH) Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22). 6/105 Payments are debited from the customer s account on the requested execution date. It is the debtor s responsibility to make sure that the account to be debited has sufficient funds available to cover the specified message amount on the requested execution date. If the amount of funds is insufficient, the entire batch is rejected during the last run of the requested execution date. The C2B payment service agreement signed by the customer and the bank will specify whether the payments sent in the C2B payload are paid as individual transactions or whether the payments in each individual <PmtfInf> block are bundled into one debit from the debtor s account. In the case of recurring payments, all payments will be bundled into one payment. Account transaction POS terminal Sweep service E-invoice payment via OP online service Outgoing SEPA Incoming SEPA C2B debit C2B credit Transaction identifier 5MT and 5EM 5SNG 5FVT UTU UTZ 5UTV 5UTH 1.2 Recurring C2B payments The C2B payload can be used to initiate SEPA salary, pension, benefit, and other recurring payments in Finland. The batch is recognised as a recurring payment through the use of the code SALA in the Category Purpose element of the C2B payment message. The C2B payment message is used to indicate the requested execution date, that is, the debiting date from the creditor s account, for recurring payments. The funds are credited to the beneficiary s account on the morning of the following banking day, regardless of the domestic bank at which the beneficiary s account is held. There is no pan-european or global salary payment service agreed between banks. When salaries are paid outside Finland, the payments are either regular SEPA payments (if the requirements for a SEPA payment are otherwise fulfilled) or traditional foreign payments. We cannot unilaterally guarantee that they are processed all the way to the payee's bank as salary payments as stipulated by Finnish salary payment regulations. 1.3 C2B urgent payments Domestic C2B urgent payments can be made in two ways.

7 7/105 a) In data format among SEPA payment data. Urgent payment batches or individual urgent payments can be among normal SEPA payment data. The size limit for an urgent payment batch is 1000 urgent payments per batch. Urgent payments are identified by the URGP code given at batch or transaction level. Urgent payments sent among SEPA payment data are processed at OP according to the SEPA payment processing schedules and then transmitted to the payee's bank as quickly as possible. C2B urgent payments in data format can be sent with a value date that is the current date or a future date. The cut-off time for reception on the current day is at 3.30 p.m. Payments received before p.m. on New Year's Eve and Maundy Thursday will be processed on the same banking day. b) In real time as individual, online C2B urgent payments. These urgent payments sent as separate urgent payment data types (pain TP4 PS01 and pain TP4 PS01) are processed immediately with no delays, and the sender will receive an immediate online response (not retrieved materials). Individual online urgent payments do not involve due date processing, and their cut-off time for the current day is at 4.30 p.m. Payments received before 1.30 p.m. on New Year's Eve and Maundy Thursday will be processed on the same banking day. Both of the above-mentioned C2B urgent payment types can be paid to the following banks operating in Finland. Aktia HELSFIHH Savings banks from 1 Nov 2014 ITELFIHH POP banks HELSFIHH (from 7 Feb 2015 POPFFI22) Danske Bank (DABAFIHX) DnB NOR (DNBAFIHX) Handelsbanken (HANDFIHH) Nordea (NDEAFIHH) OP (OKOYFIHH) Danske Bank (DABAFIHH) SEB (ESSEFIHX) S-Bank (SBANFIHH) Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22) 1.4 C2B money orders A money order is a payment sent in a C2B payload, containing the payee's name, postal address, town/city and postcode instead of the payee's account number. It can also include the Personal Identity Number or a Business ID if you wish to specify the payee in more detail. The bank will debit the payment from the payer's account on the due date and notify the payee that he/she or a person authorised by him/her can redeem the payment at an OP- member bank branch. If the payee is a member of an OP-Pohjola Group member bank, he/she can send a deposit order to the bank. The payer can agree a deadline for the redemption; the deadline can be 14, 21, 28 or 45 calendar days. If the last redemption date is not a banking day, the redemption can still be made on the next banking day. When the redemption deadline is longer than 14 days, the payer can agree with he bank that the payee is sent a notification in addition to the arrival notification if the payment has not been redeemed within 14 calendar days of the due date of the money order. Payments not redeemed within the redemption period specified by the payer are returned to the payer on the banking day following the end of the redemption period according to the payer's choice: - as individual transactions on the bank statement - as a reference service (the money order must have a reference as its identification details)

8 8/105 The money orders must arrive at OP by noon on the payment date. The money orders are automatically transferred to further processing at noon on the payment date, after which the payee is mailed a notification of an arrived money order. Once the payee has received the notification, he/she can redeem the money order. Payers cannot cancel money order transactions after they have become due and debited from their account. The payer must agree directly with the payee on any cancellations. The payee can notify an OP-Pohjola Group member bank that he/she will not redeem the money order, or merely leave the money order unredeemed. Cancelled money orders are returned to the payer on the banking day following the cancellation. The implementation of the service is agreed with a MONEY ORDER SERVICE agreement between the customer and the OP-Pohjola Group member bank. 1.5 C2B payments in Estonia, Latvia and Lithuania A company that operates in Finland and has a debit account in Estonia, Latvia or Lithuania can send C2B payment data conforming to this description to OP's Web Services channel. Estonian, Latvian and Lithuanian debit accounts are entered in the international IBAN format for C2B payments. The features of the SEPA recurring payment service and cheques are not available for the Baltic countries. 1.6 C2B payload checks by the bank The bank performs several checks to validate the C2B payload. The bank validates the C2B payload sent via the batch transfer service against the schema during the next available batch run. This validation generates a report in C2B format for the customer to retrieve. The code for accepted technical validation is ACTC. If the payload is rejected, the code is RJCT. A C2B payload sent via the Web Services channel is validated immediately against the schema, and the customer also receives the report in C2B format right away. The contents of a C2B payment payload, such as account numbers, agent, payment identifier, requested execution date, and amount, are validated during further processing. This validation creates a new C2B report, which notifies the debtor of the acceptance or rejection of the batch/transactions. The debtor s message ID (MsgId) must be unique for a minimum of three months, to prevent the same payload being sent more than once. If MsgId, the monetary amounts and quantities of the payments belonging to the batch, and the payment identifier of the batch are the same as in a payload sent successfully during the last three months, the payload will be rejected as a duplicate. The duplicate check will not be performed on a C2B payment batch that has been sent previously but rejected. If you wish to resend a payload and do not wish it to be rejected due to the duplicate check, the MsgId or the monetary amount and/or quantity data of the batch must be modified. 1.7 Responses to C2B payment messages Response and payment identification The bank s responses to payments initiated by a C2B payment message contain references to the original payment payload and in some cases also to individual payments in it. If the batches or transactions contain errors, status reports are created after each payload has been processed. The original C2B payment initiation message (pain ) for which the C2B payment status report (pain ) is generated is identified in the <OrgnlGrpInfAndSts><OrgnlMsgId> element. This element contains the original <GrpHdr><MsgId> provided by the customer in the C2B payload.

9 9/105 In the case of individual C2B payments, the report created for an individual payment contains the ID of the original payment given by the customer in <InstrId>. An individual batch is identified in the report using the 'OrgnlPmtInfId' element. In addition to the ID, the report contains status information and, in the event of errors, a standard C2B error code and possibly a more detailed description of the rejection. The Bank-to-Customer Debit/Credit Notification (camt ) message has the following levels: Group Header (GrpHdr) and Notification (Ntfctn). The elements of the Group Header block contain common message information for the message, and the elements of the Notification block contain common status report information for the message. The Notification level is further divided into two: the Entry (Ntry) part contains common information for all transactions processed, and the Transaction Details (TxDtls) part contains all the information for each individual transaction. The original C2B payment initiation message (pain ) for which the Bank-to-Customer Debit/Credit Notification (camt ) message is generated is identified in the <Ntry><NtryDtls><Btch><PmtInfId> element. This element contains the original <PmtInf><PmtInfId> data provided by the customer in the C2B payload. Identification is also possible by means of the information in the <Ntry><NtryDtls><TxDtls><Refs><InstrId> element and the <Ntry><NtryDtls><TxDtls><Refs><EndToEndId> element. The payment identification data provided by the customer in the cancellation message is cleared against the identification data of the original payment initiation message. Only cancellation requests that can be matched with the original payment initiation message proceed to cancellation processing. The IDs of cancellation request messages must be identical to the respective IDs of the original payment initiation messages. The cancellation of a payment batch is identified using the 'PaymentInformationIdentification' and payment identifier of the original payment initiation message. An individual payment is cancelled using, in addition to the InstructionIdentification and EndToEndIdentification in the original payment initiation message, at least one of the following: requested execution date, debtor account, beneficiary account and/or payment amount. After the cancellation request is processed, the system generates a report for all accepted batches and transactions, as well as for any batch or transaction that cannot be matched, to the customer who submitted the payload. 1.8 C2B cancellation request C2B cancellation request messages can be sent to the co-operative bank 24/7, and C2B cancellation requests are processed on banking days between 8am and 4pm. The bank performs a number of different checks to validate the C2B cancellation request. C2B cancellation requests sent to the Web Services channel are schema validated immediately by technical means. If the payload validation results in an error, the customer is given the notification '12 schema validation failed' during the session. The technical implementation of the error message given during the session is described in the service description of the Web Services channel. You can get a more detailed description of the reason for the rejection by calling the Corporate and Credit Transfer Services, tel If the payload passes the validation of the Web Services channel, the cancellation request is transferred to processing by the bank systems, and the customer receives a report in the camt.029 format. The contents of a C2B cancellation request payload, such as account numbers, agent, payment identifier, requested execution date, and amount, are validated during further processing. 2 Sending and retrieval of messages

10 2.1 Stages in the process 10/105 C2B payment payload A customer sends a C2B payload that conforms with the message structure and contents of ISO and OP s customer guidelines. The bank identifies the sender and checks that the sender is authorised to send a payload. In Finland, the bank returns response messages into the Web Services channel on three levels o Channel-level response: Validation of message structure (schema validation). In the batch transfer service, the response is created approximately 30 minutes after the payment initiation message is sent; in the Web Services channel, it is created immediately during the session and sent in a response message. A response is always created. o A response concerning the customer profile check: The bank validates the format of the bank account details, the validity of bank accounts for OP accounts, and the validity of the required agreements. This message is created within about 30 minutes after receipt of the payment message. A response is always created. o Response for a payment: Response in 'pain' format for SEPA and foreign payments in a single batch that have been paid, and for payments waiting for processing or sufficient funds. This message is created within about 30 minutes after the processing of the payload. The response is a summary of the batch paid thus far and the payments waiting for processing or sufficient funds. The last response of the day at 9.20 p.m. includes the rest of the payments that could be processed during the day and payments that lacked sufficient funds. The customer s C2B payment service agreement specifies whether a message is to be created for processed payments. Reports are always automatically created for payments rejected if insufficient funds are available. o The responses in 'camt' format is created four times a day (at noon, 3 p.m., 6 p.m., and 9.30 p.m.) for those payments in the batch that have been successfully paid by that time. The customer s C2B payment service agreement specifies whether a message is to be created for successful payments. However, camt messages are never created for batches that contain recurring payments with the code SALA. o The customer may specify in the C2B payment service agreement that C2B payments will be itemised on the customer s account statement. The customer must retrieve these messages immediately after they are created. The parameter for message retrieval is in the format mmdd.99999, where is the ID of the message from the bank. Cancellation request A customer sends a C2B cancellation request (camt ) in ISO message format via the Web Services channel with contents according to OP s customer guidelines. The bank identifies the sender and checks that the sender is authorised to send a payload. In Finland, the bank returns response messages into the Web Services channel as follows: o Channel-level schema validation response: Validation of message structure (schema validation). Immediately via the Web Services channel. The response is given during the session. Responses in 'pain' or 'camt' formats that need to be retrieved are not generated. The technical implementation of giving an error message during the session is described in the service description of the Web Services channel. o Cancellation response for reception (technical validation) and processing (processing of the cancellation request): o Technical validation: Check the agreements and the correctness of the information on the cancellation request message. If the agreements or the information contents have shortcomings or errors, a response is generated for the customer. The response only includes the invalid transactions. Otherwise, the cancellation request message will continue to the final cancellation request processing. o Processing of the cancellation request: During the processing, the actual cancellation of batches and payments takes place in accordance with the original request. A response is generated for the customer, including both the approved and rejected batches and transactions.

11 11/105 The customer must retrieve these messages immediately after they have been created. All other responses are retrievable with the exception of the schema validation response that is given to the customer during the session. 2.2 Structure of the payload file sent by the customer The payment message is composed of three, mandatory parts: Group Header, Payment Information, and Credit Transfer Transaction Information. Only one Group Header (block A) is allowed in each payment message. It contains the common identifying elements of the message, such as MessageIdentification and CreationDateAndTime. A payment message may contain several Payment Information (block B) parts. This portion contains the debit information for the transaction, such as the debtor, debtor s account, and requested execution date. The Payment Information part of the message is repeated if, for example, the requested execution date and/or the debtor s account changes. Credit Transfer Transaction Information (block C) is part of Payment Information and can be repeated. It contains the credit elements for the transaction, including the creditor, creditor s account, and instructed amount. The C2B payload must use UTF-8 encoding. The payload must be presented in row format and can be without indentation. The file size limit for payloads sent to OP is 100 MB. An individual C2B payload file can contain a maximum of 100,000 payments. If a file contains more payments, it must be split. 2.3 Schedules for payload sent by customer to bank Payloads sent to Osuuspankki will be processed further according to the following daily schedule: SEPA payments (C2B) SEPA recurring payments (C2B) C2B urgent payments among a SEPA payload Outgoing international payments (C2B) at 3.30 a.m., then 7.00 a.m. every 30 minutes 6.00 p.m. Payloads received after 6.00 p.m. will be processed on the next banking day. Payloads can be sent to await payment for max. 365 calendar days prior to the due date. at 3.30 a.m., then 7.00 a.m. every 30 minutes 6.00 p.m. A payload that is received after 6.00 p.m. will be processed on the next banking day. The due date of a SALA batch must be a banking day. If it is not, the batch will be rejected. at 8.00 a.m., then every 30 minutes 3.30 p.m. C2B urgent payments with the current date as the value date received after cut-off are rejected. Payloads can be sent to await payment for max. 365 calendar days prior to the due date. Payments received before p.m. on New Year's Eve and Maundy Thursday will be processed on the same banking day. at 3.30 a.m., then 7.00 a.m. every 30 minuts 5.00 p.m. Payments received prior to 5.00 p.m. on the execution date are processed during the same banking day. Payments received before noon on New Year's Eve and Maundy Thursday will be processed on the same banking day.

12 12/105 Real-time C2B urgent payments Outgoing payments (C2B) from Estonian, Latvian and Lithuanian accounts Outgoing international payments (C2B) from Estonian, Latvian and Lithuanian accounts C2B urgent payments from Estonian, Latvian and Lithuanian accounts 8.00 a.m. in real-time 4.30 p.m. No requested execution date is allowed. Payments received before 1.30 p.m. on New Year's Eve and Maundy Thursday will be processed on the same banking day. Payments received prior to 2.30 p.m. on the execution date are processed on the same banking day. Payments received prior to 3.00 p.m. on the execution date are processed on the same banking day a.m. in real-time 3.00 p.m. No requested execution date is allowed Structure of responses retrieved by the customer The bank s responses to payments initiated by a C2B payment message use the schema pain or camt The customer retrieves the messages from the batch transfer service or the Web Services channel. The pain status report on payments initiated by a C2B payment message contains references to the original payload and in some cases also to individual payments. If the batches or transactions contain errors, status reports are created after each payload has been processed. The camt notification message for payments initiated by a C2B payment message contains details of the credit transfer transactions in the batch, such as debtor s name and account number, the creditor s name and account number, the amount payable, the payment date, the transaction identifier, and (for international payments) exchange rate information. 2.5 Response creation and schedules Status reports (pain ) are created for C2B payment messages as the bank processes the payments, as follows: 1) Report on technical validation in the batch transfer service, within 30 minutes of sending, during processing times; in the Web Services channel, immediately after the payload is received. 2) Report on content validation within 30 minutes of sending, during processing times. 3) 'Pain' payment report within 30 minutes of payload processing and at 9.20 p.m. at the end of the day. Creation of camt messages for successful payments is specified separately in the service agreement. The camt notifications are created at noon, 3 p.m., 6 p.m., and 9.30 p.m. for those payments in the batch that have been made successfully by those times. However, camt messages are not created for batches for which the batch-level (PmntInf) payment category code (CtgyPurp) is SALA. Creation of camt messages for successful payments is specified separately in the service agreement. 2.6 Checking of available funds and payment It is the debtor s responsibility to make sure that the account to be debited has sufficient funds available to cover the specified message amount on the requested execution date. If the amount of funds is insufficient, the entire batch is rejected during the last run of the requested execution date. If the customer and bank have agreed on individual payments in the C2B agreement, payments are made

13 13/105 in the order in which they appear in the payment instruction until insufficient funds remain, and the rest of the payments are rejected. A retrievable report on payments with insufficient funds is generated for the customer already during the day. Additionally, at 9.20 p.m. at the end of the day, a report is generated for payments with insufficient funds during the day. Bank service charges are charged monthly by the fifth banking day of the month following the invoicing month. 2.7 Clearing codes ISO clearing codes are maintained in the External Clearing System Identification Code List, which is available on the Web site of the International Organization for Standardization for ISO OP accepts clearing codes for countries in bold in the table below, and in those countries, in currencies specified in the Currencies column. For countries that do not appear in bold, clearing codes are not used, because payments are transferred with BICs and IBANs, or because OP does not have a nostro account in the country. The clearing code is specified at transaction level in the ClrSysMmbId element. For example: <ClrSysMmbId> USABA For ruble denomination payments to Russia, in addition, the account of the creditor's bank (separated by a slash) with the clearing centre of the Russian Central Bank must be provided (20 characters). For example: <ClrSysMmbId> RUCBC / Bank Identifier Country Clearing Code long definition Code ([charactertype] {length}) Example Currencies Accepted by OP-Pohjola Australia Australian Bank State Branch Code AUBSB [0-9]{6,6} AUBSB only AUD YES (BSB) Austria Austrian Bankleitzahl ATBLZ [0-9]{5,5} ATBLZ12345 only EUR NO Canada Canadian Payments Association CACPA [0-9]{9,9} CACPA only CAD YES Payment Routing Number China CNAPS Identifier CNAPS [0-9]{12,12} CNAPS only CNY NO Germany German Bankleitzahl DEBLZ [0-9]{8,8} DEBLZ only EUR NO Greece Hellenic Bank Identification Code GRBIC [0-9]{7,7} GRHIC only EUR NO Hong Kong Hong Kong Bank Code HKNCC [0-9]{3,3} HKNCC123 only HKD YES India Indian Financial System Code INFSC [a-za-z0- INFSC123AZ only INR YES 9]{11,11} Ireland Irish National Clearing Code IENCC [0-9]{6,6} IENCC only EUR NO Italy Italian Domestic Identification Code ITNCC [0-9]{10,10} ITNCC only EUR NO Japan Japan Zengin Clearing Code JPZGN [0-9]{7,7} JPZGN only JPY YES New New Zealand National Clearing Code NZNCC [0-9]{6,6} NZNCC only NZD YES Zealand Poland Polish National Clearing Code PLKNR [0-9]{8,8} PLKNR only PLN YES Portugal Portuguese National Clearing Code PTNCC [0-9]{8,8} PTNCC only EUR NO Russia Russian Central Bank Identification Code RUCBC [0-9]{9,9} RUCBC (first two numbers only RUB YES Singapore IBG Sort Code SGIBG [0-9]{7,7} or [0-9]{3,4} always 04) SGIBG only SGD YES South Africa South African National Clearing Code ZANCC [0-9]{6,6} ZANCC only ZAR YES Spain Spanish Domestic Interbanking Code ESNCC [0-9]{8,9} ESNCC only EUR NO Sweden Sweden Bankgiro Clearing Code SESBA [0-9]{4,4} SESBA1234 only SEK NO Switzerland Swiss Clearing Code (BC Code) CHBCC [0-9]{3,5} CHBCC12345 only CHF YES

14 14/105 Switzerland Swiss Clearing Code (SIC Code) CHSIC [0-9]{6,6} CHSIC only CHF YES Taiwan Financial Institution Code TWNCC [0-9]{7,7} TWNCC only TWD NO UK UK Domestic Sort Code GBDSC [0-9]{6,6} GBDSC only GBP YES US CHIPS Participant Identifier USPID [0-9]{4,4} USPID1234 only USD YES US United States Routing Number (Fedwire, NACHA) USABA [0-9]{9,9} USABA only USD and EUR YES 2.8 Charge bearer codes A charge bearer code can be given at CdtTrfTxInf level for each transaction in the ++ChrgBr element. If a transaction-specific charge bearer code is not given, the PmtInf-level +ChrgBr code is used for the batch. For SEPA credit transfers, the code is SLEV. For SEPA credit transfers, the code values SHAR and TYHJÄ (empty) are changed to SLEV. The codes allowed for international payments are SHAR, DEBT, and CRED. For foreign currency and SWIFT cheques, the charge bearer code must be SHAR. For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR. Note that the charge bearer code SHAR is mandatory for international payments that fall under the Finnish Payment Services Act when: - The creditor s bank is located in an EU or EEA country, and - The payment currency is the euro or the currency of some other member state, and - The payment is debited to an account in the same currency (no currency exchange). If a payment that falls under the Finnish Payment Services Act involves currency exchange, the charge bearer code DEBT is also possible. The charge bearer code CRED can never be used for payments that fall under the Finnish Payment Services Act. The program used by the bank automatically changes the charge bearer codes DEBT and CRED to SHAR for payments that fall under the Finnish Payment Services Act. 2.9 Requirements for adopting the service To be able to send a C2B payload to the bank, the customer must sign a C2B service agreement with Osuuspankki. The agreement specifies items such as the customer s payment identifier, the accounts used, reporting preferences, and the payload sender. The C2B cancellation request procedure is included in the C2B service agreement, and does not require a separate agreement. In addition, the party sending a payload to the bank must sign an agreement on the use of the batch transfer service or the Web Services channel. Before a payment payload is sent to the bank, the structural validity of the payload must be checked against the schema and the messages must be tested. With regard to accounts in Estonia, Latvia and Lithuania, the customer must add the account numbers of its accounts in the Baltic countries into the account register of its system The testing environment

15 15/105 OP provides a testing environment for the purpose of testing client applications with the Web Services channel. The use of the testing environment does not differ from that of the production environment, except for the different URL, user names, and certificates. The functions of the testing environment are also limited. To be able to use the testing environment, the customer must sign an agreement on the use of the WS channel and C2B service with OP. The customer needs to use a Web Services client that supports C2B payment messages and the related responses from the bank and the Web Services channel. It is also possible to send a test payload to OP by attachment, provided that the structural validity of the attached payload has been checked against the schema. For more information on testing, contact [email protected] The customer sends the C2B payload to the testing environment in the same way as to the production environment. The customer receives first-level (technical validation) and second-level (customer profile check) status reports automatically for the payload sent. Third-level responses are not delivered from the testing environment Testing environment IDs and certificates To be able to use the testing environment, the customer must sign an agreement on the use of the Web Services channel and C2B payment messages. The payload sent to the testing environment should contain the customer ID, payment identifier, and payment accounts specified in the C2B agreement. In the Web Services channel, the customer should use the user ID specified in the WS agreement, as well as a testing-environment-specific transfer key and the related certificate retrieved from the testing service. To use the client testing environment, the customer must have a separate certificate for the Web Services channel. The certificate created for the production environment cannot be used in the testing environment. To retrieve the certificate for the testing environment, the customer needs a transfer key, which is delivered by the bank after the agreement is signed. The certificate can be retrieved with the transfer key as instructed in the Web Services channel application guide URLs To obtain IDs and keys for the testing environment, please contact the following address: [email protected]. The testing environment URL is: The WSDL description of services in the testing environment is available here: The WDSL description of the certificate service in the customer test environment is available in the following address: The general descriptions and XML schemas of the services are available from the Federation of Finnish Financial Services web site at the following URL: Limitations of the testing environment The maximum size of a payload sent to the client testing environment is 20 KB, which includes the payload and the SOAP envelope used in the Web Services channel. Each customer can send a payload to the testing

16 16/105 environment a maximum of 20 times in a 24-hour period. Service requests sent to the client testing environment must specify the value TEST as the Environment parameter. Only a C2B payload can be sent to the client testing environment (pain ). The payload sent is checked, and responses are created for the technical validation and customer profile (first-level and second-level reports). The client testing environment does not create reports on successful payments (third-level reports) Help desk and sorting Telephone service for corporate credit transfer services Phone ( 0,10/min + local network charges). The service is available from 8am to 4.30pm on weekdays. The service will instruct you how to proceed. [email protected] Account transaction POS terminal Sweep service E-invoice payment via OP online service Outgoing SEPA Incoming SEPA C2B debit C2B credit Transaction identifier 5MT and 5EM 5SNG 5FVT UTU UTZ 5UTV 5UTH Other transactions Cash management service C2B payment initiation message and example descriptions The first column, Index, refers to the element number according to the ISO standard. For the numbering, please see the following document: UNIFI (ISO20022) Message Definition Report, Payments Standards Initiation, Edition September 2006, Approved by UNIFI Payments SEG on 6 June 2006 (Payments_Standards- Initiation.pdf). The second column, Number, contains the number of element occurrences according to the schema the element is optional, and there can be only one occurrence; the element is mandatory, and there must be only one occurrence; the element is optional, and there can be a maximum of two occurrences; 0..n - the element is optional, and there can be several occurrences; 1..n - the element is mandatory, and there can be several occurrences. The third column, Mandatory (= X), contains an X if the bank requires the field. The fourth column, Element, contains the element name according to the schema. The plus (+) symbols in front of a name indicate how deep the element is in the XML structure. The fifth column, 'Example content', contains an example of field content. The sixth column. 'Description', contains a brief description of the element's designed use and provides additional instructions, if any.

17 The messages have the following structures: 17/105 Group Header this level contains the common information for the message. Payment Information there can be more than one. This level is created for credit transfer transactions per requested execution date and debit account. A separate Payment Information level is created for credit transfers that use the SALA code and have the same requested execution date and debit account. If the customer has agreed with the bank on the use of the SDVA code, a separate batch is created for these transactions. Transaction Information there can be more than one. This level contains the information on an individual credit transfer transaction. 3.1 Group Header The Mandatory column contains an X if the OP-Pohjola Group Central Cooperative requires an element that is marked as optional in the schema. Index Qty Man Element Example content Description dato ry* (=X) GrpHdr Each message must contain at least one block of this kind that contains common information for the message MsgId Message ID given by debtor, which must be unique for a minimum of three months the bank checks the ID to identify duplicates (If 'Msgld' data is identical, changing the 'Number' or 'Sum' will enable the payload to pass the double check.) Date and time of message creation by the debtor, mandatory CreDtTm T09:00:01+02: BtchBookg Not in use. Separate debiting bundles are always created for urgent payments (co-operative banks in their own bundle and payments to other financial institutions in a shared bundle). The debiting methods of other payments (in bundles or individually) are agreed in the service agreement NbOfTxs 10 Mandatory; the number of individual transactions, or CdtTrfTxInf transactions, included in the message by the debtor. Bank will not check the information given CtrlSum Not mandatory. Arithmetic sum of the amounts (InstdAmt tai EqvtAmt) of CdtTrfTxInf transactions contained in the message; foreign currencies have no effect on the sum. Bank will not check the information given Grpg MIXD Mandatory element the values allowed are GRPD, SNGL, and MIXD MIXD the message has one or several occurrences of the PmtInf block, where each may contain one or several occurrences of the

18 CdtTrfTxInf block 18/105 The payload is always processed as if the value were MIXD InitgPty Nm Firma Oy Name of message creator PstlAdr Postal address of message creator AdrLine Teollisuuskatu 1 Street address AdrLine Helsinki Postal address Ctry FI Mandatory if AdrLine is given: country code under ISO3166; according to Alpha SEPA payment (incl. instructions for sending urgent payments (one or more) among the rest of the SEPA payload) Index Qty Man dato ry* (=X) Element SEPA credit transfer example content Description n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information PmtInfId Not mandatory but recommended, the reference assigned by the debtor to identify payment batch, passed on to the messages for the debtor and account statement. Not passed on to the creditor PmtMtd TRF Mandatory the values allowed are TRF, CHK, and TRA The only code allowed for SEPA credit transfers is TRF. The CHK value gives instruction to process the credit transfer as a cheque. Cheque information is primarily checked from element If element 2.47 is empty and this element has the value CHK, the value BCHQ is conveyed to transaction level, to element PmtTpInf InstrPrty Urgency of payment the codes allowed are: NORM processed by the debtor s bank as a normal payment order this is the only urgency code allowed for SEPA credit transfers HIGH not allowed for SEPA credit transfers SvcLvl The information is primarily retrieved from element If it is empty, the information contained in this element (if any) is used for the transaction.

19 19/ Cd SEPA The values allowed are SEPA, SDVA, and PRPT. This element is not used for urgent payments, and the urgent payment code URGP is given in element Prtry The only allowed value is the urgent payment code URGP. When it is entered here, all payments of the batch are urgent payments. 2 Dec 2014 You can pay an individual payment as an urgent payment by entering the URGP code in the crediting information in element CtgyPurp Purpose of payment code, not mandatory. The code SALA must be used to identify recurrent SEPA credit transfers; see 2.64 (Purpose) Payment batches that use the code SALA will be debited from the account on the requested execution date and are credited to the creditor on the banking day following the requested execution date ReqdExctnD t NB SALA-coded urgent payments are debited and credited on the same day The mandatory requested execution date can be a maximum of 365 days in the future (also applies to urgent payments). Note! The requested execution date for a SALA batch and an urgent payment must be a banking day. If it is not, the batch will be rejected Dbtr Mandatory debtor information Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement This information is passed on to another financial institution on an urgent payment PstlAdr AdrLine The bank passes on the debtor s address used in the C2B agreement Ctry FI The country code is mandatory for the debtor s address if an address is given X ++Id This information is used to identify the customer s payload at the bank and to provide information about the debtor to the creditor The customer provides the payment identifier, which the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory. In addition, the customer can supply one business identifier in a SEPA credit transfer.

20 20/105 The ID is not observed in international payments. The only ID observed for international payments is the payment identifier. 1. *)Payment identifier mandatory 9 11 characters the same as in the customer s C2B agreement given in the OrgId.BkPtyId element not passed on to the creditor 2. Business ID optional can be either business ID or personal ID business IDs (OrgId) allowed: BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, and PrtryId passed on to the creditor s bank DbtrAcct Mandatory Id {Or +++IBAN FI For SEPA credit transfers, the account number is always given in the IBAN format Or Or} +++BBAN +++PrtryAcct The debit account in OP must always be in the IBAN format. Also when the debit account is an account at Pohjola Bank Estonia, Latvia or Lithuania. When the debit account is not with OP, it can be in BBAN format (letters and numbers allowed) For SEPA credit transfers, the account number cannot be given in BBAN format. When the debit account is not with OP, it can be in a proprietary format (using numbers, letters, and punctuation marks) For SEPA credit transfers, the account number cannot be givenin a proprietary format Ccy EUR DbtrAgt Debtor s bank information, mandatory FinInstnId BIC OKOYFIHH In SEPA credit transfers, BIC is not mandatory but recommended UltmtDbtr Not mandatory, original debtor Nm The name of the original debtor is passed on by a SWIFT MT103 message to the message field (field 70), preceded by B/O ( By order of ) ChrgBr SLEV The charge bearer code can be given for each individual transaction If there is no transaction-specific charge bearer code, it is checked from this field The charge bearer code for SEPA credit transfers is SLEV.

21 21/ n +CdtTrfTxI nf Credit transfer transaction information Code values SHAR and TYHJÄ (empty) are changed to SLEV. The codes allowed for international payments are SHAR, DEBT, and CRED. Code values SLEV and TYHJÄ (empty) are changed to SHAR. At least one block of this kind is required PmtId Mandatory payment identification InstrId Identification assigned to the payment by the debtor, passed on to the messages for the debtor and account statement (customer s own information) not passed on to the creditor EndToEn did Mandatory end-to-end identification, or unique identification assigned by the debtor to identify the transaction always passed on to the creditor but passed on to the debtor only for individual payments In the absence of this information, the bank will indicate NOTPROVIDED. EndToEndId is passed on by a SWIFT MT103 message to the message field (field 70), line 1, preceded by /ROC/ ( Ordering Customer Reference ). Not passed on to the creditor in urgent payments PmtTpInf Payment type information for the bank InstrPrty NORM Urgency of payment the codes allowed are: NORM processed by the debtor s bank as a normal payment order this is the only urgency code allowed for SEPA credit transfers HIGH not allowed for SEPA credit transfers. The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction SvcLvl Service Level, not used Information is given at the PmtInf level i.e., in element Cd Not in use. Information is given at the PmtInf level i.e., in element Prtry URGP The only allowed value is the urgent payment code URGP. You can pay an individual payment as an urgent payment by entering the code here. If you wish to pay all payments in the batch as urgent payments, enter the URGP code in element 2.7.

22 22/ CtgyPurp Payment category code, the only value allowed is TAXS tax-related message In Finland, SEPA credit transfers to the Finnish tax authorities that contain a tax-related message must use the code TAXS and reference (2.105) as well as the so-called tax message (2.108) Amt As mandatory information, the amount payable InstdAmt 150 Instructed amount payable. The specified amount must be between 0,01 and , InstdAmt attribute 'Ccy' EUR This information is passed on to another financial institution on an urgent payment. Currency of the amount instructed This information is passed on to another financial institution on an urgent payment XchgRateIn Exchange rate information f CtrctId Currency exchange deal number i.e., rate reference, which is used only in international payments ChrgBr The charge bearer code can be given for each individual transaction For SEPA credit transfers, the code values SHAR and TYHJÄ (empty) are changed to SLEV. The codes allowed for international payments are SHAR, DEBT, and CRED ChqInstr Code values SLEV and TYHJÄ (empty) are changed to SHAR ChqTp The values CCCH, CCHQ, DRFT, and ELDR are changed to BCHQ. The CHK value in element 2.2 instructs that the credit transfer be processed as a cheque. Cheque information is primarily checked from this element. If this element is empty and element 2.2 contains the value CHK, the value used for this element is BCHQ DlvryMtd Cheque delivery method Prtry For a SWIFT cheque, a field with the mandatory value SWIFT CdtrAgt FinInstnId {Or CmbndId ++++BIC GENODEFF The BIC code of the creditor s bank is not mandatory information for SEPA credit transfers. If it has been specified, it will only be used as complementary information in exceptional situations.

23 23/105 Or} ClrSys Clearing code MmbId Id The clearing code of the creditor s bank can be given for international payment if the BIC is not known; The clearing code must be given according to the ISO standard The name and address of the creditor s bank are mandatory in connection with a clearing code Nm In international payments, the name of the creditor s bank is mandatory if a BIC code is not given and/or the payment is not identified as a cheque PstlAdr AdrLin e In international payments, the address of the creditor s bank is mandatory if a BIC code is not given and/or the payment is not identified as a cheque Ctry The country code of the creditor s bank is mandatory if the PstlAdr element is used X ++Cdtr Creditor s name and address X +++Nm Warenhaus Köln Creditor s name is mandatory. Maximum length of the creditor's name on money orders is 30 characters. This information is passed on to another financial institution on an urgent payment PstlAdr Creditor s postal address AdrLine Kirchenstrasse 3 Not mandatory but recommended for SEPA payments and recurring payments. Max. two (2) address lines. Creditor address is mandatory datum in international payments. Max. number of 70 characters in the address field allowed for international payments. DE Köln StrtNm Street address is mandatory and used only in money orders. Maximum length 30 characters PstCd Postal code is mandatory and used only in money orders. 5 characters TwnNm Town name is mandatory and used only in money orders. 10 characters Ctry DE Creditor s country code is mandatory if the creditor s address is given Id Creditor ID {Or ++++OrgId In SEPA credit transfers, the business IDs allowed are BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, BkPtyId, and PrtryId Or} ++++PrvtId In payment orders, it is recommended to give either the creditor s Business ID or the social security number (TaxIdNb or SclSctyNb). In SEPA credit transfers, the personal IDs allowed are DrvrsLicNb, CstmrNb, SclSctyNb, AlnRegnNb, PsptNb, TaxIdNb, IdntyCardNb, MplyrIdNb, DtAndPlcOfBirth, and OthrId The Personal Data File Act regulates the use of

24 Personal Identity Numbers. 24/ CdtrAcct DE In payment orders, it is recommended to give either the creditor s Business ID or the social security number (TaxIdNb or SclSctyNb). For SEPA credit transfers and urgent payments, the creditor's account number is mandatory, and it must always be in the IBAN format. This information is passed on to another financial institution on urgent payments. In international payments, the account number can also be in the BBAN or proprietary format. In payment orders, the following standard value is given as the account number: FI Creditor s account is not given for SWIFT cheques UltmtCdtr If the payment is not a foreign-currency cheque or a SWIFT cheque, an account number is mandatory and the payment is rejected if it is missing Nm Passed on for SEPA credit transfers InstrForCdt Instructions for the creditor agent / creditor bank ragt are passed on for international payments The first two instructions are observed Cd Payment instruction code according to the UNIFI standard Codes currently in use: [PHOB] creditor collects from the bank Paid once the creditor is identified [CHQB] payment to creditor by cheque InstrInf Further instructions for the foreign bank, max. 140 characters InstrForDbt ragt Instructions for the debtor s bank The only instruction code currently in use for SEPA credit transfers: [EIOHJ] no instruction Purp Purpose of payment Cd Additional information on the purpose of the SEPA credit transfer from the debtor to the creditor This is entered as a code. STDY (Study) BECH (ChildBenefit)

25 25/105 PENS (PensionPayment) BENE (UnemploymentDisabilityBenefit) SSBE (SocialSecurityBenefit) AGRT (Agricultural Payment) SALA (Salary) TAXS (TaxPayment) If the Category Purpose field (Index 2.12) contains the code SALA and this field contains one of the codes listed, the text matching the code will be passed on to the OP-Pohjola Group creditor s account information. Other Purpose codes are passed on as given. Note! If the Category Purpose field (index 2.12) does not contain the code SALA, the code provided is passed on as given RmtInf Message or reference for the creditor The message can contain a Remittance Information block, which may contain a Ustrd element and, at maximum, nine Strd elements. In payments between co-operative banks, the max. number of 999 Strd elements is allowed. If both are given, the Strd elements are passed on to another bank in Finland and the Ustrd element for cross-border payments. In such a case, 1st occurrence must be data in Ustrd format: max. 140 characters option of supplying invoice details using code words 2nd-10th occurrence can be long Strd blocks: max. 280 characters each structured invoice details if tax-message payment, only one Strd block allowed Note! XML tags are included in the length of the Strd element but only the content in the length of the Usdr element. Finnish banks to which structured invoice details can be passed on using SEPA credit transfers (so-called AOS2 banks): Aktia HELSFIHH Savings banks, from 1 Nov 2014 ITELFIHH POP banks HELSFIHH (from 7 Feb 2015 POPFFI22) Danske Bank (DABAFIHX) DnB NOR (DNBAFIHX) Handelsbanken (HANDFIHH) Nordea (NDEAFIHH) OP (OKOYFIHH) Danske Bank (DABAFIHH) SEB (ESSEFIHX) S-Bank (SBANFIHH) Swedbank (SWEDFIHH) Tapiola Bank (TAPIFI22)

26 Ålandsbanken (AABAFI22) 26/105 The bank will not check these details but ensures that long Strd data will be passed on to only those banks that accept long Strd data (see above). Ustrd data will be sent to other banks. Further instructions on the provision of invoice details can be found in UNIFI Guide prepared by the Federation of Finnish Financial Services; visit Ustrd Unstructured message to the payee; see 2.84 This information is passed on to another financial institution on an urgent payment. A message is recommended with urgent payments. In international payments, the purpose of the payment (max. 140 characters) is given in this field. Max. 1 occurrence. The information is conveyed to the message field (field 70) by a SWIFT MT 103 message. It should be noted also that EndToEndId (2.26) is placed at the beginning of the message field. If provided in the payload, CdtrRef (2.105) and UltmtDbtr/Nm (2.19) are also used. This information decreases the number of characters available for the open-ended message n +++Strd Structured message to the payee; see RfrdDocI nf RfrdDo Invoice type ctp Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice Otherwise, the code (CREN, CINV) is determined by in which totals bucket (2.97 or 2.98) the sum of the invoice or credit note has been entered RfrdDo cnb RfrdDoc RltdDt n ++++RfrdDoc Amt.Ccy RmtdA {Or mt Invoice number, not passed on for international payments Date of invoice, not in use for the time being Amount and currency of the invoice or credit note Invoice amount If the invoice type is CINV or some other code

27 27/105 (excl. CREN), this element is to be used Or} +++++CdtNot eamt CdtrRefI nf In international payments, the invoice amount is placed in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement. Credit note amount Creditor reference information i.e., invoice or credit note reference CdtrRef Tp 2, Cd If field contains a domestic reference, the value SCOR is given in this field Issr Indicator of which standards-based reference number is in use CdtrRef RF Creditor reference e.g., Finnish reference number. The processing of the reference as a reference cannot be guaranteed in domestic urgent payments. In the case of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the following block (2.108) AddtlRm tinf The RF reference and other reference information is conveyed to the message field (field 70) by a SWIFT MT 103 message. Max. 140 characters of unstructured information In cases of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the previous block (2.105). Not passed on for international payments. 3.3 Recurring SEPA credit transfers are sent in a separate batch (only used in Finland, not in Estonia, Latvia or Lithuania) n PmtInf Example content for recurring SEPA credit transfer Each message must contain at least one block of this kind that contains common information for the transfers and the debit information PmtInfId Not mandatory but recommended, the reference assigned by the debtor to identify payment batch, passed on to the messages for the debtor and account statement. Not passed on to the creditor PmtMtd TRF Mandatory the values allowed are TRF, CHK,

28 and TRA 28/105 The only code allowed for SEPA credit transfers is TRF. CHK instructs that the payment be processed as an international payment PmtTpInf Not mandatory SvcLvl Cd SEPA 2 Dec CtgyPurp ReqdExctnD t SALA The code SALA must be used to identify recurrent SEPA credit transfers; see 2.64 (Purpose) Payment batches that use the code SALA will be debited from the account on the requested execution date and are credited to the creditor on the banking day following the requested execution date The requested execution date mandatory may be, at max., 365 days in the future Note! The SALA requested execution date must be a banking day. If it is not, the batch will be rejected Dbtr Mandatory debtor information Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement PstlAdr AdrLine The bank passes on the debtor s address used in the C2B agreement Ctry FI The country code is mandatory for the debtor s address if an address is given X*) ++Id This information is used to identify the customer s payload at the bank and to provide information about the debtor to the creditor The customer provides the payment identifier, which the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory. In addition, the customer can supply one business identifier in a SEPA credit transfer. 1. *)Payment identifier mandatory 9 11 characters the same as in the customer s C2B agreement given in the OrgId.BkPtyId element not passed on to the creditor 2. Business ID or private ID optional can be either business ID or personal ID

29 29/105 business IDs (OrgId) allowed: BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, and PrtryId passed on to the creditor s bank DbtrAcct Mandatory Id IBAN FI For SEPA credit transfers, the account number is always given in the IBAN format Ccy EUR DbtrAgt Debtor s bank information, mandatory FinInstnId BIC In SEPA credit transfers, BIC is not mandatory but recommended. OKOYFIHH UltmtDbtr Not mandatory, original debtor Nm ChrgBr SLEV The charge bearer code can be given for each individual transaction If there is no transactionspecific charge bearer code, it is checked from this field In recurring SEPA credit transfers, the charge bearer code is SLEV. In recurring SEPA credit transfers, charge bearer codes SHAR and TYHJÄ are changed to SLEV n +CdtTrfTxI nf Creditor information At least one block of this kind is required PmtId Mandatory payment identification InstrId Identification assigned to the payment by the debtor, passed on to the messages for the debtor and account statement (customer s own information) not passed on to the creditor EndToEn did Mandatory end-to-end identification, or unique identification assigned by the debtor to identify the transaction always passed on to the creditor but passed on to the debtor only for individual payments In the absence of this information, the bank will indicate NOTPROVIDED PmtTpInf Payment type information for the bank SvcLvl Service Level, not used Information is given at the PmtInf level i.e., in element CtgyPurp Amt As mandatory information, the amount payable InstdAmt 2000 Instructed amount payable. The specified amount must be between 0,01 and , InstdAmt EUR Currency of the amount instructed attribute 'Ccy' ChrgBr The charge bearer code can be given for each individual transaction In recurring SEPA credit transfers, the charge bearer code is SLEV CdtrAgt In recurring SEPA credit transfers, charge bearer codes SHAR and TYHJÄ are changed to SLEV.

30 30/ FinInstnId BIC OKOYFIHH The BIC code of the creditor s bank is not mandatory information for SEPA credit transfers. If it has been specified, it will only be used as complementary information in exceptional situations X ++Cdtr Creditor s name and address X +++Nm Pekka Palkansaaja Creditor's name PstlAdr Creditor s postal address AdrLine Kotikatu 1 Not mandatory but recommended for SEPA payments and recurring payments. Max. two (2) address lines Helsinki StrtNm Street address is mandatory and used only in money orders PstCd Postal code is mandatory and used only in money orders TwnNm Town name is mandatory and used only in money orders Ctry FI Creditor s country code is mandatory if the creditor s address is given Id Creditor ID {Or ++++OrgId In SEPA credit transfers, the business IDs allowed are BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, BkPtyId, and PrtryId Or} ++++PrvtId In payment orders, it is recommended to give either the creditor s Business ID or the social security number (TaxIdNb or SclSctyNb). In SEPA credit transfers, the personal IDs allowed are DrvrsLicNb, CstmrNb, SclSctyNb, AlnRegnNb, PsptNb, TaxIdNb, IdntyCardNb, MplyrIdNb, DtAndPlcOfBirth, and OthrId In payment orders, it is recommended to give either the creditor s Business ID or the social security number (TaxIdNb or SclSctyNb) CdtrAcct FI For SEPA credit transfers, the creditor s account number is always given in the IBAN format UltmtCdtr In payment orders, the following standard value is given as the account number: FI Nm InstrForDbt ragt Instructions for the debtor s bank The only instruction code currently in use for SEPA credit transfers: [EIOHJ] no instruction Purp Purpose of payment Cd SALA Additional information on the purpose of the SEPA credit transfer from the debtor to the creditor

31 This is entered as a code. 31/105 STDY (Study) BECH (ChildBenefit) PENS (PensionPayment) BENE (UnemploymentDisabilityBenefit) SSBE (SocialSecurityBenefit) AGRT (Agricultural Payment) SALA (Salary) TAXS (TaxPayment) If the Category Purpose field (Index 2.12) contains the code SALA and this field contains one of the codes listed, the text matching the code will be passed on to the OP-Pohjola Group creditor s account information. Other Purpose codes are passed on as given. Note! If the Category Purpose field (index 2.12) does not contain the code SALA, the code provided is passed on as given RmtInf Message or reference for the creditor The message can contain a Remittance Information block, which may contain a Ustrd element and, at maximum, nine Strd elements. If both are given, the Strd elements are passed on to another bank in Finland and the Ustrd element for cross-border payments. In such a case, 1st occurrence must be data in Ustrd format: max. 140 characters option of supplying invoice details using code words 2nd-10th occurrence can be long Strd blocks: max. 280 characters each structured invoice details if tax-message payment, only one Strd block allowed Note! XML tags are included in the length of the Strd element but only the content in the length of the Usdr element. Finnish banks to which structured invoice details can be passed on using SEPA credit transfers (so-called AOS2 banks): Aktia HELSFIHH Savings banks, from 1 Nov 2014 ITELFIHH POP banks HELSFIHH (from 7 Feb 2015 POPFFI22) Danske Bank (DABAFIHX) DnB NOR (DNBAFIHX) Handelsbanken (HANDFIHH) Nordea (NDEAFIHH) OP (OKOYFIHH) Danske Bank (DABAFIHH) SEB (ESSEFIHX) S-Bank (SBANFIHH) Swedbank (SWEDFIHH)

32 Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22) 32/105 The bank will not check these details but ensures that long Strd data will be passed on to only those banks that accept long Strd data (see above). Ustrd data will be sent to other banks. Further instructions on the provision of invoice details can be found in UNIFI Guide prepared by the Federation of Finnish Financial Services; visit Ustrd Unstructured message to the payee; see n +++Strd Structured message to the payee; see RfrdDocI nf RfrdDo Invoice type ctp Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice RfrdDo cnb RfrdDoc RltdDt n ++++RfrdDoc {Or Or} Amt.Ccy +++++RmtdA mt +++++CdtNot eamt CdtrRefI nf Otherwise, the code (CREN, CINV) is determined by in which totals bucket (2.97 or 2.98) the sum of the invoice or credit note has been entered. Date of invoice, not in use for the time being Amount and currency of the invoice or credit note Invoice amount If the invoice type is CINV or some other code (excl. CREN), this element is to be used. Credit note amount If the invoice type is CREN, this element is to be used. Creditor reference information i.e., invoice or credit note reference CdtrRef Tp 2, Cd If field contains a domestic reference, the value SCOR is given in this field Issr Indicator of which standards-based reference number is in use CdtrRef Creditor reference e.g., Finnish reference number AddtlRm tinf Max. 140 characters of unstructured information In cases of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the previous block (2.105).

33 33/ International payment payment order n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information PmtInfId Not mandatory but recommended, the reference assigned by the debtor to identify payment batch, passed on to the messages for the debtor and account statement. Not passed on to the creditor PmtMtd TRF Mandatory the values allowed are TRF, CHK, and TRA The CHK value gives instruction to process the credit transfer as a cheque. Cheque information is primarily checked from element If element 2.47 is empty and this element has the value CHK, the value BCHQ is conveyed to transaction level, to element PmtTpInf InstrPrty NORM Urgency of payment the codes allowed are: NORM processed by the debtor s bank as a normal payment order HIGH processed by the debtor s bank as an urgent international payment order; does not require that the creditor s bank process the transfer as an urgent payment order SvcLvl Cd The information is primarily retrieved from element If it is empty, the information contained in this element (if any) is used for the transaction. 2 Dec CtgyPurp ReqdExctnDt 10/05/2011 The requested execution date mandatory may be, at max., 365 days in the future Dbtr Mandatory debtor information Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement PstlAdr AdrLine The bank passes on the debtor s address used in the C2B agreement Ctry FI The country code is mandatory for the debtor s address if an address is given X*) ++Id This information is used to identify the customer s payload at the bank and to provide information about the debtor to the creditor

34 34/105 The customer provides the payment identifier, which the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory DbtrAcct Mandatory Id {Or Or Or} +++IBAN FI A debit account in OP must always be given in IBAN format This also applies when the debit account is an account at Pohjola Bank Estonia, Latvia or Lithuania. +++BBAN +++PrtryAcct When the debit account is not with OP, it can be in BBAN format (letters and numbers allowed) When the debit account is not with OP, it can be in a proprietary format (using numbers, letters, and punctuation marks) Ccy DbtrAgt Debtor s bank information, mandatory FinInstnId BIC OKOYFIHH UltmtDbtr Not mandatory, original debtor Nm The name of the original debtor is passed on by a SWIFT MT103 message to the message field (field 70), preceded by B/O ( By order of ) ChrgBr The charge bearer code can be given for each individual transaction if there is no transactionspecific charge bearer code, it is fetched from this field n +CdtTrfTxIn f Credit transfer transaction information For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR. At least one block of this kind is required PmtId Mandatory payment identification InstrId Identification assigned to the payment by the debtor, passed on to the messages for the debtor and account statement (customer s own information) not passed on to the creditor EndToEndI d Mandatory end-to-end identification, or unique identification assigned by the debtor to identify the transaction always passed on to the creditor but passed on to the debtor only for individual payments When payment is debited from a foreign account, the debtor s reference is given in this element. If the debtor does not want to use a reference, NOTPROVIDED must be used. EndToEndId is passed on by a SWIFT MT103 message to the message field (field 70), line 1, preceded by /ROC/ ( Ordering Customer Reference ).

35 35/ PmtTpInf Payment type information for the bank InstrPrty NORM NORM processed by the debtor s bank as a normal payment order The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction SvcLvl Service Level, not used Information is given at the PmtInf level i.e., in element CtgyPurp Amt As mandatory information, the amount payable InstdAmt Amount payable {Or InstdAmt USD Currency of the amount instructed attribute 'Ccy' Or} +++EqvtAmt Information on the amount of the counter-value payment Amt Amount payable in the currency of the debit account (EUR) Amt attribuutti 'Ccy' EUR Currency of debit transaction, always EUR CcyOfTrf Currency of payment transaction, other than the currency of debit account XchgRateInf Exchange rate information CtrctId Currency exchange deal number i.e., rate reference, which is used only in international payments ChrgBr SHAR The charge bearer code can be given for each individual transaction CdtrAgt For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR FinInstnId {Or ++++BIC IRVTUS3N The BIC code of the creditor s bank is mandatory for SEPA credit transfers CmbndId Or} ClrSysM Clearing code mbid Id The clearing code of the creditor s bank can be given for international payment if the BIC is not known; The clearing code must be given according to the ISO standard The name and address of the creditor s bank are mandatory in connection with a clearing code Nm In a payment order for an international payment, the name of the creditor s bank is mandatory if a BIC code is not provided PstlAdr AdrLin e In a payment order for an international payment, the address of the creditor s bank is mandatory if a BIC code is not provided Ctry The country code of the creditor s bank is

36 36/105 mandatory if the PstlAdr element is used X ++Cdtr Creditor s name and address X +++Nm Ewing Oil Creditor s name is mandatory PstlAdr Creditor s postal address AdrLine 5th Avenue Creditor address is mandatory datum in international payments. 70 characters in total on the first two address line are observed Dallas TEXAS 1234 USA Ctry US Creditor s country code is mandatory Id Creditor ID OrgId {Or PrvtId Or} CdtrAcct In international payments, the account number can also be in the BBAN or proprietary format InstrForCdtr Agt If the payment is not a SWIFT cheque, an account number is mandatory and the payment is rejected if it is missing. Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed Cd Payment instruction code according to the UNIFI standard Codes currently in use: [PHOB] creditor collects from the bank Paid once the creditor is identified [CHQB] payment to creditor by cheque InstrInf Further instructions for the foreign bank, max. 140 characters InstrForDbtr Agt Instructions for the debtor s bank Only used for special payment methods requiring a separate agreement Purp Purpose of payment Cd RmtInf Message or reference for the creditor Ustrd Invoice 5656 Unstructured message to the payee; see 2.84 In international payments, the purpose of the payment (max. 140 characters) is given in this field. Max. 1 occurrence. The information is conveyed to the message field (field 70) by a SWIFT MT 103 message. It should be noted also that EndToEndId (2.26) is placed at the beginning of the message field. If provided in the payload, CdtrRef (2.105) and UltmtDbtr/Nm (2.19) are also used. This information decreases the number of characters available for the open-ended message.

37 37/ n +++Strd Structured message to the payee; see RfrdDocIn f RfrdDoc Invoice type Tp Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice RfrdDocR ltddt n ++++RfrdDocA mt.ccy RmtdAm {Or t Otherwise, the code (CREN, CINV) is determined by in which totals bucket (2.97 or 2.98) the sum of the invoice or credit note has been entered. Date of invoice, not in use for the time being Amount and currency of the invoice or credit note Invoice amount If the invoice type is CINV or some other code (excl. CREN), this element is to be used Or} +++++CdtNote Amt In international payments, the invoice amount is placed in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement. Credit note amount If the invoice type is CREN, this element is to be used. In international payments, the credit note amount is included in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement CdtrRefInf Creditor reference information i.e., invoice or credit note reference CdtrRef Tp 2, Cd CdtrRef The RF reference and other reference information is conveyed to the message field (field 70) by a SWIFT MT 103 message. 3.5 International payment urgent payment order n +CdtTrfTxI nf Credit transfer transaction information At least one block of this kind is required PmtId Mandatory payment identification InstrId Identification assigned to the payment by the debtor, passed on to the messages for the debtor and account statement (customer s own information) not passed on to the creditor EndToEn Mandatory end-to-end identification, or unique

38 38/105 did identification assigned by the debtor to identify the transaction always passed on to the creditor but passed on to the debtor only for individual payments In the absence of this information, the bank will indicate NOTPROVIDED. EndToEndId is passed on by a SWIFT MT103 message to the message field (field 70), line 1, preceded by /ROC/ ( Ordering Customer Reference ) PmtTpInf Payment type information for the bank InstrPrty. HIGH HIGH processed by the debtor s bank as an urgent international payment order; does not require that the creditor s bank process the transfer as an urgent payment order The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction SvcLvl Service Level, not used Information is given at the PmtInf level i.e., in element CtgyPurp Amt As mandatory information, the amount payable InstdAmt Amount payable {Or InstdAmt INR Currency of the amount instructed attribute 'Ccy' Or} +++EqvtAmt Information on the amount of the counter-value payment Amt Amount payable in the currency of the debit account (EUR) Amt EUR Currency of debit transaction, always EUR. attribuutti 'Ccy' CcyOfTrf Currency of payment transaction, other than the currency of debit account XchgRateIn Exchange rate information f CtrctId Currency exchange deal number i.e., rate reference, which is used only in international payments ChrgBr SHAR The charge bearer code can be given for each individual transaction For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR CdtrAgt FinInstnId BIC SBININBB104 {Or CmbndId Or} ClrSys Clearing code MmbId Id The clearing code of the creditor s bank can be given for international payment if the BIC is not

39 39/105 known; The clearing code must be given according to the ISO standard The name and address of the creditor s bank are mandatory in connection with a clearing code Nm In an urgent international payment order, the name of the creditor s bank is mandatory if a BIC code is not provided PstlAdr AdrLin e In an urgent international payment order, the address of the creditor s bank is mandatory if a BIC code is not provided Ctry The country code of the creditor s bank is mandatory if the PstlAdr element is used X ++Cdtr Creditor s name and address X +++Nm Indi As Creditor's name PstlAdr Creditor s postal address AdrLine Indian Street 3 Creditor address is mandatory datum in international payments. 70 characters in total on the first two address line are observed Indiala Kalkuta INDIA Ctry IN Creditor s country code is mandatory Id Creditor ID OrgId {Or PrvtId Or} CdtrAcct C In international payments, the account number can also be in the BBAN or proprietary format InstrForCdt ragt If the payment is not a SWIFT cheque, an account number is mandatory and the payment is rejected if it is missing. Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed Cd Payment instruction code according to the UNIFI standard Codes currently in use: [PHOB] creditor collects from the bank Paid once the creditor is identified [CHQB] payment to creditor by cheque InstrInf Further instructions for the foreign bank, max. 140 characters InstrForDbt ragt Instructions for the debtor s bank Only used for special payment methods requiring a separate agreement Purp Purpose of payment Cd Note! If the Category Purpose field (index 2.12) does not contain the code SALA, the code provided is passed on as given.

40 40/ RmtInf Message or reference for the creditor Ustrd Payment number carpets Unstructured message to the payee; see 2.84 In international payments, the purpose of the payment (max. 140 characters) is given in this field. Max. 1 occurrence. The information is conveyed to the message field (field 70) by a SWIFT MT 103 message. It should be noted also that EndToEndId (2.26) is placed at the beginning of the message field. If provided in the payload, CdtrRef (2.105) and UltmtDbtr/Nm (2.19) are also used. This information decreases the number of characters available for the open-ended message n +++Strd Structured message to the payee; see RfrdDocI nf RfrdDo Invoice type ctp Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice RfrdDoc RltdDt n ++++RfrdDoc Amt.Ccy RmtdA {Or mt Otherwise, the code (CREN, CINV) is determined by in which totals bucket (2.97 or 2.98) the sum of the invoice or credit note has been entered. Date of invoice, not in use for the time being Amount and currency of the invoice or credit note Invoice amount If the invoice type is CINV or some other code (excl. CREN), this element is to be used Or} +++++CdtNot eamt In international payments, the invoice amount is placed in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement. Credit note amount If the invoice type is CREN, this element is to be used CdtrRefI nf In international payments, the credit note amount is included in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement. Creditor reference information i.e., invoice or credit note reference CdtrRef Tp 2, Cd If field contains a domestic reference, the value SCOR is given in this field

41 41/ Issr Indicator of which standards-based reference number is in use If field has an RF reference, the value ISO is given here CdtrRef Creditor reference e.g., Finnish reference number In the case of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the following block (2.108). The RF reference and other reference information is conveyed to the message field (field 70) by a SWIFT MT 103 message. 3.6 International payment - SWIFT cheque n +CdtTrfTxI nf Credit transfer transaction information At least one block of this kind is required. See also 1.7 Grpg PmtId Mandatory payment identification InstrId Identification assigned to the payment by the debtor, passed on to the messages for the debtor and account statement (customer s own information) not passed on to the creditor EndToEn did Mandatory end-to-end identification, or unique identification assigned by the debtor to identify the transaction always passed on to the creditor but passed on to the debtor only for individual payments If the debtor does not want to use a reference, NOTPROVIDED must be used. EndToEndId is passed on by a SWIFT MT103 message to the message field (field 70), line 1, preceded by /ROC/ ( Ordering Customer Reference ) PmtTpInf Payment type information for the bank InstrPrty. NORM NORM processed by the debtor s bank as a normal payment order The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction SvcLvl Service Level, not used Information is given at the PmtInf level i.e., in element CtgyPurp Amt As mandatory information, the amount payable InstdAmt 150 Amount payable InstdAmt USD Payment currency, the possible currencies on attribute 'Ccy' XchgRateIn f SWIFT cheques are: EUR, USD and GBP. Exchange rate information

42 42/ CtrctId Currency exchange deal number i.e., rate reference, which is used only in international payments ChrgBr SHAR The charge bearer code can be given for each individual transaction ChqInstr For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR ChqTp The values CCCH, CCHQ, DRFT, and ELDR are changed to BCHQ. The CHK value in element 2.2 instructs that the credit transfer be processed as a cheque. Cheque information is primarily checked from this element. If this element is empty and element 2.2 contains the value CHK, the value used for this element is BCHQ DlvryMtd Cheque delivery method Prtry SWIFT For a SWIFT cheque, a field with the mandatory value SWIFT X ++Cdtr Creditor s name and address X +++Nm Hotel Ahmed Creditor's name PstlAdr Creditor s postal address AdrLine Ata 7 Creditor address is mandatory datum in international payments. 70 characters in total on the first two address line are observed Istanbul TURKEY Ctry TR Creditor s country code is mandatory Id Creditor ID OrgId {Or PrvtId Or} CdtrAcct The creditor s account must not be given for InstrForCdt ragt SWIFT cheques Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed Cd Payment instruction code according to the UNIFI standard Codes currently in use: [PHOB] creditor collects from the bank Paid once the creditor is identified [CHQB] payment to creditor by cheque InstrInf Further instructions for the foreign bank, max. 140 characters InstrForDbt ragt Instructions for the debtor s bank Not in use for SWIFT cheques Purp Purpose of payment Cd

43 43/ RmtInf Message or reference for the creditor Ustrd Reservation Unstructured message to the payee; see 2.84 In international payments, the purpose of the payment (max. 140 characters) is given in this field. Max. 1 occurrence. The information is conveyed to the message field (field 70) by a SWIFT MT 103 message. It should be noted also that EndToEndId (2.26) is placed at the beginning of the message field. If provided in the payload, CdtrRef (2.105) and UltmtDbtr/Nm (2.19) are also used. This information decreases the number of characters available for the open-ended message n +++Strd Structured message to the payee; see RfrdDocI nf RfrdDo Invoice type ctp Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice RfrdDoc RltdDt n ++++RfrdDoc Amt.Ccy RmtdA {Or mt Otherwise, the code (CREN, CINV) is determined by in which totals bucket (2.97 or 2.98) the sum of the invoice or credit note has been entered. Date of invoice, not in use for the time being Amount and currency of the invoice or credit note Invoice amount If the invoice type is CINV or some other code (excl. CREN), this element is to be used Or} +++++CdtNot eamt In international payments, the invoice amount is placed in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement. Credit note amount If the invoice type is CREN, this element is to be used CdtrRefI nf In international payments, the credit note amount is included in the camt message to the debtor. This datum is not passed on to the creditor or the debtor s account statement. Creditor reference information i.e., invoice or credit note reference CdtrRef Tp 2, Cd If field contains a domestic reference, the value SCOR is given in this field Issr Indicator of which standards-based reference number is in use

44 44/105 If field has an RF reference, the value ISO is given here CdtrRef Creditor reference e.g., Finnish reference number In the case of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the following block (2.108). The RF reference and other reference information is conveyed to the message field (field 70) by a SWIFT MT 103 message. 3.7 International payment international payment instruction Index Qty Man dato ry* (=X) Element Example content of international payment instruction Description n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information PmtInfId Not mandatory but recommended, the reference assigned by the debtor to identify payment batch, passed on to the messages for the debtor and account statement. Not passed on to the creditor PmtMtd TRF TRF or TRA allowed PmtTpInf InstrPrty The urgency value can be either NORM or HIGH. The information is primarily retrieved from element If it is empty, the information contained in this element (if any) is used for the transaction ReqdExctnD t 10/05/2011 The requested execution date mandatory may be, at max., 365 days in the future Dbtr Mandatory debtor information Nm Firma Co The bank passes on the debtor s name used in the C2B agreement PstlAdr AdrLine The bank passes on the debtor s address used in the C2B agreement Ctry The country code is mandatory for the debtor s address if an address is given X ++Id The customer provides the payment identifier, which the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory DbtrAcct Mandatory debtor account number

45 45/ Id IBAN AT The debit account can be entered as IBAN. {Or Or +++BBAN The debit account can also be entered as BBAN (digits and characters) Or} +++PrtryAcct The debit account can also be entered in proprietaty format (digits, characters and puctuation marks) Ccy DbtrAgt Debtor s bank information, mandatory FinInstnId BIC BKAUATWW ChrgBr The information is primarily retrieved from element If it is empty, the information contained in this element (if any) is used for the transaction n +CdtTrfTxI nf Credit transfer transaction information The charge bearer codes allowed SHAR, DEBT and CRED. Code values SLEV and TYHJÄ (empty) are changed to SHAR. At least one block of this kind is required PmtId Mandatory payment identification EndToEn did The reference of the IPI is conveyed in this element PmtTpInf Payment type information for the bank InstrPrty NORM The urgency value can be either NORM or HIGH. The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction Amt As mandatory information, the amount payable InstdAmt Amount payable InstdAmt EUR Currency of the amount instructed attribute 'Ccy' ChrgBr SHAR The charge bearer codes allowed SHAR, DEBT and CRED. Code values SLEV and TYHJÄ (empty) are changed to SHAR. The information is primarily retrieved from this element. If this element has no value, the value in element 2.20 (if any) is used for the transaction CdtrAgt Creditor s bank details FinInstnId BIC OKOYFIHH BIC of creditor's bank. {Or CmbndId Or} ClrSys Clearing code MmbId Id The clearing code of the creditor s bank can be given for international payment if the BIC is not known; The clearing code must be given according to the ISO standard The name and address of the creditor s bank are

46 46/105 mandatory in connection with a clearing code Nm In an urgent international payment order, the name of the creditor s bank is mandatory if a BIC code is not provided PstlAdr AdrLin e The name of the creditor s bank is mandatory if a BIC code is not provided Ctry The country code of the creditor s bank is mandatory if the PstlAdr element is used X ++Cdtr Creditor s name and address X +++Nm Firma Oy Creditor s name is mandatory PstlAdr Creditor s postal address AdrLine Teollisuuskatu 1 In cross-border payment instructions, the creditor s postal address is mandatory Helsinki FINLAND Ctry FI Creditor s country code is mandatory CdtrAcct FI The account number can also be in the BBAN or proprietary format InstrForDbt ragt Instructions for the debtor s bank Not in use for international orders RmtInf Message or reference for the creditor Ustrd Invoice 765 Unstructured message to the creditor. The purpose of the payment (max. 140 characters) is given in this field n +++Strd Reference for the creditor CdtrRefI nf CdtrRef Reference Creditor reference information i.e., invoice or credit note reference 3.8 Real-time C2B urgent payment File type of real-time C2B urgent payment The real-time C2B urgent payment initiation message is an international ISO message in XML format. The schema for the payload sent to the bank is pain xsd, and the schema for the payload generated for bank's immediate response is pain xsd. The real-time C2B urgent payment uses the 'uploadfile' operation: a request file is uploaded to the Web Services channel in the 'ApplicationRequest.content' element. The 'ApplicationRequest.fileType is 'pain TP4 PS01 Notwithsatnding the 'ResponseCode' value of the application request response, the response provided in the 'ApplicationResponse.content' element must be checked. If the value in the 'GrpSts' and 'TxtSts' elements is 'ACSP', the debit and credit transactions associated with the payment are successful.

47 47/ Example message of a real-time C2B urgent payment Index Qty Man Element Example content Description dato ry* (=X) GrpHdr Each message must contain at least one block of this kind that contains common information for the message MsgId Message ID given by debtor, which must be unique for a minimum of three months the bank checks the ID to identify duplicates Timestamp of the message s creation by the debtor, mandatory CreDtTm T07:51: : NbOfTxs 1 Mandatory; the number of individual transactions, or CdtTrfTxInf transactions, included in the message by the debtor. Bank will not check the information given CtrlSum Not mandatory. Arithmetic sum of the amounts (InstdAmt tai EqvtAmt) of CdtTrfTxInf transactions contained in the message; foreign currencies have no effect on the sum. Bank will not check the information given Grpg MIXD Mandatory element the values allowed are GRPD, SNGL, and MIXD MIXD the message has one or several occurrences of the PmtInf block, where each may contain one or several occurrences of the CdtTrfTxInf block; Payload is always processed under the assumption that the value is MIXD InitgPty Nm Firma Oy Name of message creator PstlAdr Postal address of message creator AdrLine Teollisuuskatu 1 Street address AdrLine Helsinki Postal address Ctry FI Mandatory if AdrLine is given: Country code under ISO 3166, according to Alpha n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information PmtInfId Not mandatory but recommended, the reference assigned by the debtor to identify payment batch, passed on to the messages for the debtor and account statement. Not passed on to the creditor PmtMtd TRF The only code allowed for urgent payments is TRF PmtTpInf Not mandatory InstrPrty Urgency of payment the codes allowed are: NORM processed by the debtor s bank as a normal payment order this is the only

48 48/105 urgency code allowed for SEPA credit transfers HIGH processed by the debtor s bank as an urgent payment order; does not require that the creditor s bank process the transfer as an urgent payment order HIGH is not allowed for SEPA credit transfers SvcLvl Service Level {Or +++Cd Service Level code. The allowed value is SEPA Prtry URGP The only code allowed for urgent Or} ReqdExctnD t payments is URGP. 12/09/2011 For urgent payments, the current banking day is the mandatory requested execution date. If such date is not the current date, service rejects the message Dbtr Mandatory debtor information Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement PstlAdr AdrLine The bank passes on the debtor s address used in the C2B agreement Ctry The country code is mandatory for the debtor s address if an address is given Id This information is used to identify the customer s payload at the bank and to provide information about the debtor to the creditor {Or +++OrgId The customer provides the payment identifier, which the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory. In addition, the customer can supply one business identifier in a SEPA credit transfer. Optional company ID both Business ID and Personal ID allowed values BIC Company ID passed on to the creditor's bank IBEI Company ID passed on to the creditor's bank BEI Company ID passed on to the creditor's bank EANGL N Company ID passed on to the creditor's bank USCHU Company ID passed on to the creditor's bank DUNS Company ID passed on to the creditor's bank X ++++BkPtyId The customer provides the payment identifier, which the bank uses to link the

49 49/105 payload to a C2B service agreement i.e., checks which customer s payload this is. Payment identifier (9-11 char.), mandatory datum, not passed on to the creditor TaxIdNb Company ID passed on to the creditor's bank PrtryId Company ID passed on to the creditor's bank Id Issr Or} ++++PrvtId {{Or +++++DrvrsLi cnb Or +++++CstmrN b Or +++++SclScty Nb Or +++++AlnReg nnb PsptNb Or Or +++++TaxIdN b Or +++++IdntyCa rdnb Or +++++MplyrId Nb Or +++++DtAndP lcofbirth BirthD t PrvcO fbirth CityOf Birth CtryOf Birth OthrId Or}} Id IdTp DbtrAcct Mandatory Id In SEPA credit transfers, the personal IDs allowed are DrvrsLicNb, CstmrNb, SclSctyNb, AlnRegnNb, PsptNb, TaxIdNb, IdntyCardNb, MplyrIdNb, DtAndPlcOfBirth, and OthrId {Or +++IBAN FI A debit account in OP must always be in the IBAN format Ccy EUR Currency of the debit account DbtrAgt Debtor s bank information, mandatory FinInstnId BIC OKOYFIHH BIC code for debtor s bank UltmtDbtr Original debtor. This data can also be conveyed at level C in field If both fields 2.19 and 2.48 contain data,

50 50/105 the data in field 2.48 is observed Nm Name of original debtor ChrgBr SLEV The charge bearer code can be given for each individual transaction If there is no transaction-specific charge bearer code, it is checked from this field In urgent payments, the charge bearer code must be SLEV. Code values SHAR and TYHJÄ (empty) are changed to SLEV n +CdtTrfTxInf Credit transfer transaction information The message must contain at least one of these blocks (in urgent payments, only one block per payment/message allowed) PmtId Mandatory payment identification InstrId Identification assigned to the payment by the debtor, passed on to the messages for the debtor and account statement (customer s own information) not passed on to the creditor EndToEn did The mandatory EndToEndId reference is a unique identifier for the transaction assigned by the payer. Not passed on to the payee in domestic urgent payments. In the absence of this information, the bank will indicate NOTPROVIDED PmtTpInf Payment type information for the bank InstrPrty Urgency of payment the codes allowed are: NORM processed by the debtor s bank as a normal payment order this is the only urgency code allowed for SEPA credit transfers HIGH processed by the debtor s bank as an urgent payment order; does not require that the creditor s bank process the transfer as an urgent payment order HIGH is not allowed for SEPA credit transfers The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction SvcLvl Service Level {Or +++Cd Service Level code. The allowed value is SEPA Or} +++Prtry URGP The only code allowed for urgent payments is URGP Amt As mandatory information, the amount payable InstdAmt 150 Amount payable InstdAmt EUR Currency of the amount instructed attribute 'Ccy' ChrgBr SLEV The charge bearer code is determined primarily at transaction level In urgent payments, the charge bearer code must be SLEV.

51 51/ UltmtDbtr Original debtor. This data can also be conveyed at the 'Payment Information' hierachy level in field If both fields 2.19 and 2.48 contain data, the data in field 2.48 is observed Nm Name of original debtor CdtrAgt FinInstnId BIC NDEAFIHH The BIC code of the creditor s bank is mandatory for urgent payment orders X ++Cdtr Creditor s name and address X +++Nm Company Ltd Creditor s name is mandatory PstlAdr Creditor s postal address AdrLine Mannerheimintie 1 In urgent payments, the address is not mandatory but recommended. Max. two (2) address lines. ++++AdrLine FI Helsinki Ctry FI Creditor s country code is mandatory if the creditor s address is given Id Creditor ID {Or ++++OrgId The company IDs allowed are BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, BkPtyId, and PrtryId BIC Company ID passed on to the creditor's bank IBEI Company ID passed on to the creditor's bank BEI Company ID passed on to the creditor's bank EANGL N Company ID passed on to the creditor's bank USCHU Company ID passed on to the creditor's bank DUNS Company ID passed on to the creditor's bank BkPtyId The customer provides the payment identifier, which the bank uses to link the payload to a C2B service agreement i.e., checks which customer s payload this is TaxIdNb Company ID passed on to the creditor's bank PrtryId Company ID passed on to the creditor's bank Id Issr Or} ++++PrvtId {{Or +++++DrvrsLi cnb Or +++++CstmrN b Or +++++SclScty Nb AlnReg In SEPA credit transfers, the personal IDs allowed are DrvrsLicNb, CstmrNb, SclSctyNb, AlnRegnNb, PsptNb, TaxIdNb, IdntyCardNb, MplyrIdNb, DtAndPlcOfBirth, and OthrId

52 52/105 Or nnb PsptNb Or Or +++++TaxIdN b Or +++++IdntyCa rdnb Or +++++MplyrId Nb Or +++++DtAndP lcofbirth BirthD t PrvcO fbirth CityOf Birth CtryOf Birth OthrId Or}} Id IdTp X ++CdtrAcct Account number is mandatory for urgent payments Id {Or ++++IBAN FI For urgent payments, the creditor s account number is always given in the IBAN format UltmtCdtr Ultimate creditor. This information is passed on in urgent payments Nm Name of ultimate creditor RmtInf Message or reference for the creditor Ustrd Unstructured message to creditor Purpose of urgent payment is provided in this field (max. 140 characters). Max. 1 occurrence. A message is recommended with urgent payments n +++Strd Structured message to the payee; see CdtrRefI nf Creditor reference information i.e., invoice or credit note reference CdtrRef Tp 2, Cd SCOR If field contains a domestic or RF reference, the value SCOR is given in this field. The processing of the reference as a reference cannot be guaranteed in domestic urgent payments Issr Indicator of which standards-based reference number is in use CdtrRef RF Creditor reference e.g., Finnish reference number

53 53/105 4 Bank C2B response and message description 4.1 Report on technical validation The structure of the C2B payment message is accepted (technical validation): o Message 'GroupStatus' is ACTC. A payment message is rejected: o Message 'GroupStatus' is RJCT. Even a single payment with a schema error causes the entire payload to be rejected. 4.2 Report on payload content validation All transactions in the payment message are accepted: o o Message Group Status is ACCP. 'TransactionStatus' for each batch is ACCP. Some batches are rejected and some accepted: o o o Message 'GroupStatus' is PART. 'TransactionStatus' for each accepted batch is ACCP. 'TransactionStatus' for each rejected batch is RJCT. All batches in the message are rejected: o o Message 'GroupStatus' is RJCT. 'TransactionStatus' for each batch is RJCT. Some payments in a batch are rejected: o o o Message 'GroupStatus' is PART. Message 'TransactionStatus' for the rejected credit transfer transaction is RJCT. Accepted payments are not reported. 4.3 Payment status report ( pain ) A pain status report is always created for transactions that were rejected or had insufficient funds. When entering into the agreement, the customer selects whether the responsewill also report successfully paid batches. The (debiting) batch of the payment initiation message remains with the payments with insufficient funds:

54 54/105 The Group Status of the response message is PDNG, and the Transaction Status of each/the (debiting) batch / payment with insufficient funds is PDNG. Once funds arrive to the account so that all payments can be debited, a response in which Group Status is ACSP and Transaction Status is ACSP is created. At 9.20 p.m. at the end of the day on the due date/processing date, a response in which Group Status and Transaction Status are RJCT is formed of the payments that ultimately failed due to insufficient funds. All transactions in the payment message are accepted: The Group Status of the response message and the Transaction Status of each batch is ACSP. Instructed Amount is the total amount of the successful batch. Some batches of the payment initiation message are rejected, some accepted, or some have insufficient funds: The Group Status of the response message is PART. The Transaction Status of each fully accepted batch is ACSP. Other information of the accepted transactions is not reported in the response message. The information of individually accepted payments are not reported in the response message. The Transaction Status of each rejected batch/payment is RJCT. The Transaction Status of each batch for which there were insufficient funds is PDNG. All batches in the payment initiation message are rejected: The Group Status of the response message and the Transaction Status of each batch is RJCT. If the payload include payments/batches with a due date in the future, the Group Status of the current day's response is PART; this also applies if the payload contains only accepted payments/batches with a Transaction Status ACSP. If, at the end of the current day, all payments/batches in the payload have been rejected, the Group Status is RJCT. There was no time for processing all payments in the batch on the same day. This can happen, when a batch contains SEPA credit transfers and international payments and the batch arrives at the bank after the international payment cut-off time at 5 p.m. The international payments are then given the next day's date as the due date, and they will be processed in the same way as the processing of batches with several due dates described above. Index Qty Element Example content Description GrpHdr MsgId Unique ID assigned by the bank to the response payload CreDtTm Creation date and time of response message 11T18:12:02+03: OrgnlGrpInfAndSts OrgnlMsgId Identification from the original pain message (MsgId) OrgnlMsgNmId pain Type of original message (pain ) OrgnlCreDtTm Timestamp from the original message s CreDtTm 12T09:00:01+02: OrgnlNbOfTxs 1 Number of transactions in the original message +OrgnlCtrlSum GrpSts ACCP Payload status code ACSP all batches in the payload have been processed successfully ACCP payload is accepted for processing ACTC technical validation has succeeded

55 55/105 RJCT all batches in the payload are rejected PART some batches in the payload have been processed successfully and some rejected, some transactions in at least one batch will be processed later, or the payload contains batches that specify different requested execution dates StsRsnInf More detailed description of status data StsRsn 2 Dec Cd Rejection reason code AddtlStsRsnInf Error description (optional), to provide additional information for the above code n +TxInfAndSts Status of individual payments / batch OrgnlPmntInfId Unique batch identifier given by the customer from the payload field OrgnlInstrId Unique payment identifier given by the customer: from the InstrId field of the pain message OrgnlEndToEndI d From the EndToEndId field of the pain message OrgnlTxId ERA Archive ID TxSts ACCP Payment/batch status code ACSP batch has been processed successfully ACCP payment/batch is accepted for processing RJCT payment/batch is rejected PDNG transaction awaiting processing or funds StsRsnInf StsRsn Cd Rejection reason code 3 Dec AddtlStsRnsInf Error description (optional), to provide additional information for the above code ++OrgnlTxRef Amt InstdAmt 150 Amount for transaction/batch ReqdExctnDt 10/05/2011 Requested execution date +++UltmtDbtr Original debtor ++++Nm Name +++Dbtr Debtor ++++Nm Name DbtrAcct Debtor s account Id IBAN FI Account number in IBAN format BBAN Account number in BBAN format PrtryAcct Id Other account number +++Cdtr Creditor ++++Nm Name CdtrAcct Creditor s account Id IBAN Account number in IBAN format BBAN Account number in BBAN format PrtryAcct Id Other account number +++UltmtCdtr ++++Nm Ultimate creditor Name

56 56/105 Rejection codes NARR Debtor Id missing Payment identifier missing DT01 Incorrect due date Incorrect due date AC01 Incorrect account Incorrect account AM03 Incorrect currency Incorrect currency NARR Incorrect service level Incorrect service level (not in use for international payments) NARR Incorrect category purpose Incorrect category purpose (not in use for international payments) NARR Incorrect charge bearer Incorrect charge bearer code (not in use for international payments) AG01 Agreement missing Agreement missing NARR Sender not permitted Sender not permitted AG01 Account not found in the agreement Account not found in the agreement TM01 Invalid Cut Off Time Cut-off time passed (used for urgent payments) NARR Incorrect urgency level Incorrect urgency level (not in use for international payments) AM09 Incorrect amount Incorrect amount AM03 Incorrect currency Incorrect currency AM18 Invalid Number Of Transactions Invalid number of transactions (used for urgent payments) NARR Incorrect payer's bank Incorrect payer's bank NARR Incorrect payment method Incorrect payment method (not in use for international payments) ED01 Incorrect payee bank's BIC Incorrect payee bank's BIC NARR Payee bank's address missing Payee bank's address missing NARR Payee bank's name and/or address missing Payee bank's name and/or address missing NARR Incorrect payee bank's country code Incorrect payee bank's country code BE06 Payee's name missing Payee's name missing BE04 Payee's address missing Payee's address missing NARR Incorrect payee's country code Incorrect payee's country code AC01 Incorrect payee's account Incorrect payee's account AC01 Payee's account missing Payee's account missing NARR Incorrect account type for periodic payment Incorrect account type for a periodic payment (not in use for international payments) NARR Incorrect reference Incorrect reference NARR Money order service agreement missing Money order service agreement missing (not in use for international payments) NARR Too many elements of supplementary Too many elements of supplementary information information NARR Too much supplementary information Supplementary information too long AM04 Insufficient funds Insufficient funds NARR Payment removed at customer's request Payment removed at customer's request AM05 Double data Duplicate data NARR Payer has several agreements Payer has several agreements AC06 Account deactivated Account deactivated NARR Payment to payee failed Payment to payee failed AC04 Account closed Account closed AC04 Payee's account closed Payee's account closed NARR Account not found Account not found NARR Payee's account not found Payee's account not found NARR Error in IBAN-BIC checking Error in IBAN-BIC checking NARR No account number permitted on cheque No account number permitted on cheque NARR Incorrect payee bank's information Incorrect payee bank's information NARR Incomplete payee's name or address Incomplete payee's name or address

57 57/105 NARR Incorrect payee information Incorrect payee information NARR Double payment Double payment AM03 Non-processable currency Invalid currency code AC01 Incorrect payer's account Incorrect payer's account NARR Incomplete message information Incomplete message information NARR Incorrect payment instrument Incorrect payment instrument NARR Reference number mandatory Reference number mandatory NARR Payment to chosen country not permitted Payment to chosen country not permitted NARR Wrong length of payee account number Wrong length of payee account number NARR Wrong BIC for payment order/urgent payment Wrong BIC for payment order/urgent payment order order NARR IBAN/BIC combination not allowed IBAN/BIC combination not allowed NARR Payment awaiting processing Payment awaiting processing 4.4 Report on processed payments ('camt') When entering into the agreement, the customer selects whether camt notifications will be created for successfully processed international payments, successfully processed SEPA credit transfers, successfully processed SEPA credit transfers, and international payments, or not at all. Index Element name Element Qty Example content Description 1.0 GroupHeader <GrpHdr> [1..1] Each message contains one GrpHdr element that contains the common information for the message 1.1 +MessageIdentification <MsgId> [1..1] Unique ID given by the bank to response data 1.2 +CreationDateTime <CreDtTm> [1..1] T18:12:02+03:00 Message creation timestamp 1.3 +MessageRecipient <MsgRcpt> [0..1] Identification [0..1] OrganisationIdentifi <OrgId> [1..1] cation Other <Othr> [0..n] Identification [1..1] Receiver ID SchemaName <SchmeNm> [0..1] Code <Cd> [1..1] BANK 2.0 Notification <Ntfctn> [1..n] Common information for the notification 2.1 +Identification [1..1] Notification identifier 2.4 +CreationDateTime <CreDtTm> [1..1] T18:00:02+03: Account <Acct> [1..1] Identification [1..1] IBAN <IBAN> [1..1] FI Creation time of notification by the bank Debtor s account in IBAN format Other <Othr> [1..1] Identification [1..1] Debtor s account in other than IBAN format 01/02/ Currency <Ccy> [0..1] EUR Currency of the debtor's account Servicer <Svcr> [0..1] FinancialInstitutionIde <FinInstnId> [1..1] ntification BIC <BIC> [0..1] OKOYFIHH Bank issuing the message

58 58/ Entry <Ntry> [0..n] 1..1 Common information for processed transactions In practice, there is always only one Entry level Amount <Amt> [1..1] 250 Amount for processed transactions <CCy> [1..1] XXX Currency for processed transactions Because the amount may be composed of transactions in different currencies, the currency code value used is XXX CreditDebitIndicator <CdtDbtInd> [1..1] DBIT Indicator that this is a debit tranaction Status <Sts> [1..1] BOOK The status of transactions in a notification is always BOOK BookingDate <BookgDt> [0..1] Date <Dt> [1..1] 02/11/2011 Payment date AccountServicerRefe rence <AcctSvcrRef> [0..1] Transaction identifier for a bundled SEPA credit transfer transaction BankTransactionCod <BkTxCd> [1..1] e Proprietary <Prtry> [0..1] Code <Cd> [1..1] Debiting Standard text Entry Details <NtryDtls> [0..n] Batch <Btch> [0..1] PaymentInformatio nidentification <PmtInfId> [0..1] NumberOfTransact ions In practice, there is always only one Entry Details level The PmtInfId data from the pain.001 message <NbOfTxs> [0..1] Total number of transactions in the original payment batch TransactionDetails <TxDtls> [0..n] Details of an individual processed transaction References <Refs> [0..1] MessageIdentific ation AccountServicer Reference InstructionIdentifi cation <MsgId> [0..1] Contents of MsgId data in Pain.001 message <AcctSvcrRef> [0..1] Archive ID <InstrId> [0..1] InstrId information in the Pain.001 message EndToEndIdentifi cation <EndToEndId> [0..1] EndToEndId information in the Pain.001 message AmountDetails <AmtDtls> [0..1] Amount details for the transaction InstructedAmount <InstdAmt> [0..1] Amount <Amt> Attribute Ccy [0..1] USD 1328,80 Amount payable in the currency specified by the customer, Ccy the same

59 59/105 as SourceCurrency CurrencyExcha <CcyXchg> [0..1] Exchange rate information nge SourceCurrency <SsrCcy> [1..1] USD Currency of the amount instructed TargetCurrenc <TrgtCcy> [0..1] EUR Always EUR y UnitCurrency <UnitCcy> [0..1] EUR Always EUR ExchangeRate <XchgRate> [1..1] Exchange rate ContractIdentifi cation <CtrctId> [0..1] Foreign exchange trading reference TransactionAmou <TxAmt> [0..1] nt Amount <Amt> Attribute Ccy [1..1] EUR 1000,00 Amount to be debited in the customer's account currency, Ccy the same as TargetCurrency CurrencyExcha <CcyXchg> [0..1] Exchange rate information nge SourceCurrenc <ScrCcy> [1..1] EUR Always EUR y TargetCurrenc y <TrgtCcy> [0..1] EUR Currency of the debit account UnitCurrency <UnitCcy> [0..1] EUR Currency of the debit account ExchangeRate <XchgRate> [1..1] Exchange rate ContractIdentifi cation <CtrctId> [0..1] Foreign exchange trading reference CounterValueAm <CntrValAmt> [0..1] ount Amount <Amt> Attribute Ccy [1..1] EUR 1328,80 Counter value always in EUR CurrencyExcha <CcyXchg> [0..1] Exchange rate information nge SourceCurrenc <ScrCcy> [1..1] EUR Always EUR y TargetCurrenc <TrgtCcy> [0..1] EUR Always EUR y UnitCurrency <UnitCcy> [0..1] EUR Always EUR ExchangeRate <XchgRate> [1..1] Exchange rate constant QuotationDate <QtnDt> [0..1] T14:12:02+03:00 Time of currency conversion Charges <Chrgs> [0..n] Amount <Amt> [1..1] 0.00 Always Bearer <Br> [0..1] SHAR Charge bearer code RelatedParties <RltdPties> [0..1] Payment parties Debtor <Dbtr> [0..1] Name <Nm> [0..1] Firma Oy Name of the Debtor Identification [0..1] Debtor s identification data OrganisationId <OrgId> [1..1] entification Other <Othr> [0..n] Identificatio [1..1] Debtor ID

60 60/105 n UltimateDebtor <UltmtDbtr> [0..1] Name <Nm> [0..1] Name of original debtor Creditor <Cdtr> [0..1] Name <Nm> [0..1] Ewing Oil Creditor's name PostalAddress <PstlAdr> [0..1] Country <Ctry> [0..1] US Country code of creditor's bank AddressLine <AdrLine> [0..7] 5th Avenue Creditor s address AddressLine <AdrLine> Dallas AddressLine <AdrLine> TEXAS AddressLine <AdrLine> USA Identification [0..1] Creditor s identification data Organisation <OrgId> [1..1] Identification BICOrBEI <BICOrBEI> [0..1] BIC or BEI Other <Othr> [0..n] Identificatio [1..1] Corporate customer s ID n PrivateIdentific <PrvtId> [1..1] ation Other <Othr> [0..n] Identificatio [1..1] Private customer s ID n CreditorAccount <CdtrAcct> [0..1] Identification [1..1] IBAN <IBAN> [1..1] Creditor s account in IBAN format Other <Othr> [1..1] Identification [1..1] Creditor s non-iban account UltimateCreditor <UltmtCdtr> [0..1] Name <Nm> [0..1] Name of ultimate creditor (not used in international payments) RelatedAgents <RltdAgts> [0..1] CreditorAgent <CdtrAgt> [0..1] Creditor s bank details FinancialInstituti <FinInstnId> [1..1] onidentification BIC <BIC> [0..1] IRVTUS3N BIC code for creditor s bank ClearingSyste <ClrSysMmbId [0..1] mmemberidentification > MemberIdenti fication <MmbId> [1..1] Clearing code for creditor s bank Name <Nm> [0..1] Name of creditor s bank PostalAddress <PstlAdr> [0..1] AddressLine <AdrLine> [0..7] Address of creditor s bank

61 61/ Purpose <Purp> [0..1] Purpose of payment Code <Cd> [1..1] Additional information on the purpose of the credit transfer from the debtor to the creditor RemittanceInforma <RmtInf> [0..1] tion Unstructured <Ustrd> [0..n] Invoice 5656 Unstructured message to the creditor Structured <Strd> [0..n] 0..9 Structured message to the creditor In practice, there may not be more than nine structured messages ReferredDocum <RfrdDocInf> [0..n] Credit note information entinformation Type <Tp> [0..1] CodeOrPropri <CdOrPrtry> [1..1] etary Code <Cd> [1..1] RfrdDocInf/RfrdDocTp/Cd information in the Pain.001 message that can be either CREN or CINV ReferredDocum entamount CreditNoteAm ount RemittedAmou nt <RfrdDocAmt> [0..1] <CdtNoteAmt> [0..1] CdtNoteAmt information content in Pain.001 message <RmtdAmt> [0..1] RmtdAmt information content in Pain.001 message CreditorReferen <CdtrRefInf> [0..1] ceinformation Type <Tp> [0..1] CodeOrPropri <CdOrPrtry> [1..1] etary Code <Cd> [1..1] The 'Cd' information from the pain.001 message Reference <Ref> [0..1] CdtrRef information content (SCOR) in Pain.001 message AdditionalRemitt anceinformation <AddtlRntInf> [0..1] AddtlRmtInf information content in Pain.001 message RelatedDates <RltdDts> [0..1] AcceptanceDate <AccptncDtTm Time > [0..1] 02/11/2011 Transaction-specific payment date This is the same as on batch level in 2.62.

62 62/ InterbankSettlem entdate <IntrBkSttlmDt > [0..1] International settlement date 4.5 Response message to a real-time C2B urgent payment initiation message and the reasons of rejection Index Qty Element Example content Description GrpHdr MsgId Unique ID assigned by the bank to the response payload CreDtTm Creation date and time of response message 12T07:51: : OrgnlGrpInfAndSts {Or +OrgnlMsgId Identification from the original pain message (MsgId) 2.2 Or} NtwkFileNm Technical identifier of request message Used only if technical validation fails OrgnlMsgNmId pain Type of original message (pain ) OrgnlCreDtTm T07:51: :00 Timestamp from the original message s CreDtTm OrgnlNbOfTxs 1 Number of transactions in the original message; for urgent payments, 1 in all cases GrpSts ACSP Payload status code ACSP payload processed successfully RJCT - payload rejected PDNG payload status 'Pending' StsRsnInf More detailed description of status data StsOrgtr Id OrgId PrtryId Id WSC username Used only if technical validation fails StsRsn 2 Dec Cd Rejection reason code. For urgent payments, payload-level reason code in use only if technical validation fails AddtlStsRsnInf Error description (optional), to provide additional information for the above code n +TxInfAndSts Status of individual payment / batch OrgnlPmntInfId Unique payload identifier given by the customer from field PmntInfId OrgnlInstrId Unique payment identifier given by the customer: from the InstrId field of the pain message OrgnlEndToEndId From the EndToEndId field of the pain message OrgnlTxId MD0002 Transaction identifier TxSts ACSP Payment/batch status code ACSP payment/batch processed successfully RJCT payment/batch is rejected PDNG payment/batch status is 'Pending'

63 63/ StsRsnInf StsRsn Cd Reason code for payment with status 'Rejected' or 'Pending' 3 Dec AddtlStsRnsInf Error description (optional), to provide additional information for the above code Amt InstdAmt Amount for transaction/batch ReqdExctnDt 12/09/2011 Requested execution date DbtrAcct Debtor s account Id IBAN FI Account number in IBAN format CdtrAcct Creditor s account Id IBAN FI Account number in IBAN format New reason of rejection codes introduced by the real-time urgent C2B payment. NARR NARR NARR NARR NARR NARR NARR NARR NARR NARR NARR No right of access to the account Unclear, contact your own bank Username missing Incomplete payer information Only one urgent payment permitted per message Transfer of urgent payments is possible on banking days 8.00 am 4.30 pm Incomplete payee information Payee's account subject to limited use Warning related to the payee's account Technical error, contact your own bank Above/below security limits 5 C2B cancellation request (camt ) With the C2B cancellation request message, it is possible to cancel payment batches consisting of C2B SEPA payments or international payments, or individual C2B SEPA payments or international payments pending for the requested execution date. Cancellation requests concerning the entire payload are not possible; the entire payload can be cancelled by cancelling the batches included in the payload. A C2B cancellation request initiated by the customer is processed using the Web Services channel. A service fee according to the service price list in force applies to the cancellation. The C2B cancellation request message is an international ISO message in XML format. The schema for the cancellation request sent to the bank is camt The sent payload is validated against the schema by technical means. If the payload validation returns an error, the customer is given the following responses: If the Web Services channel schema validation finds an error, the customer is given the '12 schema validation failed' error message during the session. You can get a more detailed description of the reason for the rejection by calling the Corporate and Credit Transfer Services, tel ) or by validating the payload using, for example, the validation service provided by XMLdation.com. If mandatory information is missing from a received cancellation request, the customer will receive a single 'camt.029' response with no batch or payment level. If the entire batch or all individual payments are rejected, the customer will receive a single 'camt.029' response.

64 64/105 If the entire batch or all individual payments are approved, the customer will receive a single 'camt.029' response. If some of the batches or individual payments are rejected and approved, the customer will receive a single 'camt.029' response containing both the rejected and approved payment batches or payments. For the time being, a bank employee can also manually cancel transactions pending for the requested execution date. Structure of the cancellation request message common parts of message presented in black; to be provided in all cases elements associated with the payment (<OrgnlPmtInfAndCxl>) presented in blue; to be provided in all cases elements associated with the individual payment <TxInf>; to be provided only for the cancellation of individual payments Index Element name Element Qty Example content Description 1.0 Assignment <Assgnmt> [1..1] Each message has one Assgnmt block that contains the common information for the message 1.1 +Identification [1..1] Unique ID given by customer to the cancellation request message 1.2 +Assigner <Assgnmt> [1..1] Company Ltd Information of the sender of the cancellation request message Party <Pty> [1..1] Name <Nm> [0..1] Name of debtor company Identification [1..1] OrganisationIdentific <OrgId> [1..1] ation Other <Othr> [0..n] Identification [1..1] Payment identifier;

65 65/ mandatory datum to be provided in element 4.26 for each batch, or in here, if the cancellation request pertains to an individual initiation message under the payment identifier SchemeName <SchmeNm> [0..1] Code <Cd> [1..1] Value: BANK Assignee <Assgne> [1..1] Agent <Agt> [1..1] FinancialInstitutionIde <FinInstnId> [1..1] ntification BIC [0..1] OKOYFIHH Receiver of cancellation request; standard value: OKOYFIHH 1.8 +CreationDateTime <CreDtTm> [1..1] T09:30:47Z Timestamp for message creation time 3.0 ControlData <CtrlData> [0..1] Control data for the cancellation message. If provided, the number must correspond to the number of transactions cancelled by the message and the amount must correspond to the total amount of the transactions to be cancelled 3.1 +NumberOfTransactions <NbOfTxs> [1..1] Number of transactions to be cancelled 3.2 +ControlSum <CtrlSum> [0..1] Total amount of transactions to be cancelled 4.0 Underlying <Undrlyg> [1..n] Information of the transaction underlying the cancellation; one item per message 4.1 +OriginalGroupInformatio nandcancellation GroupCancellationIden tification OriginalMessageIdentif ication OriginalMessageName identification OriginalCreationDateTi me <OrgnlGrpInfA ndcxl> [0..1] Elements relate to the identification of the original message <GrpCxlId> [0..1] Identifier assigned by sender to the cancellation request <OrgnlMsgId> [1..1] Identifier assigned by sender to the original message <OrgnlMsgNmI d> <OrgnlCreDtT m> [1..1] pain Type and version of the original message sent by customer [0..1] T 9:30:47Z Creation time and date of the original message sent by customer

66 66/105 4 Dec NumberOfTransactions <NbOfTxs> [0..1] 2 Number of transactions in the original message ControlSum <CtrlSum> [0..1] Total amount of transactions in the original message GroupCancellation <GrpCxl> [0..1] False The cancellation request message is processed by default as if the cancellation of one or multiple individual payments or batches were requested, irrespective of whether the 'Group Cancellation' element is included in the message OriginalPaymentInforma tionandcancellation <OrgnlPmtInfA ndcxl> [0..n] The information of at least one batch must be provided (4.2.1). Information of the original batch the cancellation of which is requested. <PmtCxlId> [0..1] Identifier of the batch cancellation request PaymentCancellationId entification Case <Case> [0..1] Data group must be provided, if no payment identifier is given in element 1.3. Information is primarily checked from this element Identification [1..1] Creator <Cretr> [1..1] Information of the creator of the cancellation request Party <Pty> [1..1] 05/01/ /01/ /01/ /01/ Identification [1..1] OrganisationIdent <OrgId> [1..1] ification Other <Othr> [0..n] Identification [1..1] The elements associated with the payment identifier must be provided here, if the message contains cancellation requests related to multiple payment identifiers. The payment identifier can be given messagespecifically in element /01/ SchemeNam [0..1] 2017 e 05/01/ Code [1..1] Value: BANK OriginalPaymentInform ationidentification <OrgnlPmtInfId > [1..1] The identifier of the original batch sent by

67 67/105 customer is mandatory datum to be provided in the cancellation request message in all cases NumberOfTransactions <NbOfTxs> [0..1] 2 If provided, this number must correspond to the number of transactions to be cancelled from the batch ControlSum <CtrlSum> [0..1] If provided, this amount must correspond to the total amount of transactions to be cancelled from the batch PaymentInformationCa ncellation <PmtInfCxl> [0..1] True Cancellation request pertains to the entire batch; information of individual transactions (4.43) not permitted. False Cancellation request pertains to one or multiple individual transactions: information of the individual transactions (4.43) mandatory. At least one piece of the identifying information on the original payment is mandatory when cancelling an individual payment. One of the following elements must appear: 4.51, 4,52, or TransactionInformation <TxInf> [0..n] Information related to the cancellation of an CancellationIdentifica tion OriginalInstructionIde ntification OriginalEndToEndIde ntification OriginalInstructedAm ount OriginalInstructedAm ount OriginalRequestedEx ecutiondate OriginalTransactionRef erence RemittanceInformatio n individual payment. <CxlId> [0..1] Identifier for the cancellation of an individual transaction. <OrgnlInstrId> [0..1] Identifier assigned by sender to the original payment. <OrgnlEndToE ndid> [0..1] Identifier passed on to creditor in the original payment. <OrgnlInstrAmt > [0..1] Amount of the original payment <OrgnlInstrAmt [0..1] EUR Currency code of the > attribuutti original payment Ccy <OrgnlReqdEx [0..1] Requested execution date ctndt> of the original payment <OrgnlTxRef> [0..1] Reference information of creditor, debtor, accounts, etc. of the payment to be cancelled. <RmtInf> [0..1] Remittance information of the original payment; only one (1) structured element permitted. Structured invoice details (=AOS2) rejected upon receipt, not entered to processing.

68 68/ Structured <Strd> [0..1] +++++CreditorReferenceI <CdtrRefInf> [0..1] nformation Type <Tp> [0..1] CodeOrPropriet <CdOrPrtry> [1..1] ary Code <Cd> [1..1] Value: SCOR Reference <Ref> Reference of the original payment transaction. +++Debtor <Dbtr> [0..1] Debtor ++++Name <Nm> [0..1] +++DebtorAccount <DbtrAcct> [0..1] ++++Identification [1..1] +++++IBAN <IBAN> [1..1] Debtor's account number in IBAN format +++Creditor <Cdtr> [0..1] Creditor ++++Name <Nm> [0..1] Creditor's name +++CreditorAccount <CdtrAcct> [0..1] ++++Identification [1..1] +++++IBAN <IBAN> [1..1] Creditor's account number in IBAN format 6 Response to C2B cancellation request (camt )

69 69/105 common parts of message presented in black; to be provided in all cases elements associated with the payment <OrgnlPmtInfAndSts> presented in blue; to be provided in all cases elements associated with the individual payment <TxInfAndSts>; to be provided only for the cancellation of individual payments Index Element name Element Qty Example content Description 1.0 Assignment <Assgnmt> [1..1] Each message has one Assgnmt block that contains the common information for the message 1.1 +Identification [1..1] Identifier assigned by bank to response message Assigner <Assgnmt> [1..1] Agent <Agt> [1..1] FinancialInstitutionIde <FinInstnId> [1..1] ntification BIC <BIC> [0..1] OKOYFIHH Sender of response message; OKOYFIHH in all cases Assignee <Assgne> [1..1] Party <Pty> [1..1] Name <Nm> [0..1] Company Ltd Information of the receiver of response message (= sender of the cancellation request message) 05/01/ /01/ /01/ /01/ /01/ /01/ Identification [0..1] ++++OrganisationIdentific <OrgId> [1..1] ation +++++Other <Othr> [0..n] Identification [1..1] Payment identifier; from element 1.3 in the cancellation request message SchemeName <SchmeNm> [0..1] Code <Cd> [1..1] Value BANK, if payment identifier is returned in this element CreationDateTime <CreDtTm> [1..1] T09:30:47Z Message creation timestamp 3.0 Status <Sts> [1..1] Processing information for the cancellation message 3.9 +AssignmentCancellation <AssgnmentCx [1..1] True Constant value: True Confirmation lconf> 4.0 CancellationDetails <CxlDtls> [0..n] In practice, only one instance of this element is generated OriginalGroupInformatio nandstatus <OrgnlGrpInfA ndsts> [0..1]

70 70/ OriginalGroupCancella tionidentification OriginalMessageIdentif ication OriginalMessageName identification OriginalCreationDateTi me 4 Dec OriginalNumberOfTran sactions <OrgnlGrpCxlId > [0..1] Identifier of the original cancellation request message from element 4.2. <OrgnlMsgId> [1..1] Identifier of the original payment initiation message from element 4.9. <OrgnlMsgNmI d> <OrgnlCreDtT m> <OrgnlNbOfTxs > OriginalControlSum <OrgnlCtrlSum > GroupCancellationStat us CancellationStsReaso ninformation [1..1] pain Type and version of the original payment initiation message from element 4.10 in the cancellation request message. [0..1] T 9:30:47Z Creation time of the original payment initiation message from element 4.11 in the cancellation request message. [0..1] 2 Number of transactions in the original payment initiation message from element 4.12 in the cancellation request message. [0..1] Amount of transactions in the original payment initiation message from element 4.13 in the cancellation request message. <GrpCxlSts> [0..1] Status options for the cancellation message: ACCR processed successfully PACR processed partially successfully RJCR rejected, not processed <CxlStsRsnInf> [0..n] Element included in response message, if the status of cancellation request message is RJCR Reason <Rsn> [0..1] Proprietary <Prtry> [1..1] Rejection reason code AdditionalInformation <AddtlInf> [0..n] Additional information provided by bank in the response OriginalPaymentInforma tionandstatus OriginalPaymentInform ationcancellationidentific ation <OrgnlPmtInfA ndsts> <OrgnlPmtInfC xlid> [0..n] Processing information of the cancellation request for the original payment batch; to be returned in all cases [0..1] Identifier of the cancellation request for the original payment batch

71 71/105 (element 4.22 in the cancellation request message) ResolvedCase <RslvdCase> [0..1] Information of the original cancellation request message from elements Identification [1..1] Creator <Cretr> [1..1] Information of the creator of the original cancellation request Party <Pty> [1..1] Identification [0..1] 05/01/ OrganisationIdent <OrgId> [1..1] 2013 ification 05/01/ Other <Othr> [0..n] /01/ /01/ /01/ Identification [1..1] Payment identifier; from element 4.26 in the original cancellation request message SchemeName <SchmeNm> [0..1] Code <Cd> [1..1] Value BANK, if payment identifier is returned in this element OriginalPaymentInform ationidentification <OrgnlPmtInfId > [1..1] The identifier of the original batch is returned to customer in the format used in the cancellation request message received in element OriginalNumberOfTran sactions <OrgnlNbOfTxs > [0..1] 1 Number received in element 4.34 of the original cancellation request message OriginalControlSum <OrgnlCtrlSum > [0..1] Amount received in element 4.35 of the original cancellation request message PaymentInformationCa ncellationstatus <PmtInfCxlSts> [0..1] Status of cancellation request for a batch; values: ACCR processed successfully RJCR rejected NB This element is empty where individual transactions are cancelled CancellationStatusRea soninformation <CxlStsRsnInf> [0..n] Reason information for the rejection of a batch if

72 72/105 status RJCR Reason <Rsn> [0..1] Proprietary <Prtry> [1..1] Rejection reason code AdditionalInformation <AddtlInf> [0..n] Additional information on rejection reason TransactionInformation AndStatus <TxInfAndSts> [0..n] Information concerning the cancellation of individual payment CancellationStatusIde ntification OriginalInstructionIde ntification OriginalEndToEndIde ntification TransactionCancellati onstatus CancellationStatusRe asoninformation transactions <CxlStsId> [0..1] Identifier for the cancellation of individual transaction from element 4.44 in the cancellation request message <OrgnlInstrId> [0..1] Identifier of the original payment initiation message from element <OrgnlEndToE ndid> [0..1] Identifier of the original payment initiation message from element 4.52 in the cancellation request message. <TxCxlSts> [0..1] Status of cancellation request for individual transaction; values: ACCR processed successfully RJCR rejected <CxlStsRsnInf> [0..n] Reason information for the rejection of individual transaction if status RJCR Reason <Rsn> [0..1] Proprietary <Prtry> [1..1] Rejection reason code AdditionalInformatio n <AddtlInf> [0..n] Additional information on rejection reason OriginalInstructedAm ount <OrgnlInstrAmt > OriginalInstructedAm ount OriginalRequestedEx ecutiondate <OrgnlInstrAmt > attribuutti Ccy <OrgnlReqdEx ctndt> [0..1] Amount of the original payment from element 4.53 in the cancellation request message. [0..1] EUR Currency code of the original payment from element 4.53 of the cancellation request message [0..1] Requested execution date of the original payment from element 4.54 in the cancellation request message OriginalTransactionR eference <OrgnlTxRef> [0..1] Reference information on the payment transaction cancelle, accounts, etc., from element 4.62 in the cancellation request message RemittanceInformatio <RmtInf> [0..1] Remittance information of

73 73/ n the original payment Structured <Strd> [0..1] CreditorReferenceI <CdtrRefInf> [0..1] 489 nformation Type <Tp> [0..1] CodeOrPropriet <CdOrPrtry> [1..1] 491 ary Code <Cd> [1..1] Value: SCOR Reference <Ref> Reference of the original payment transaction Debtor <Dbtr> [0..1] Debtor Name <Nm> [0..1] DebtorAccount <DbtrAcct> [0..1] Identification [1..1] IBAN <IBAN> [1..1] Debtor's account number in IBAN format Creditor <Cdtr> [0..1] Creditor Name <Nm> [0..1] Creditor's name CreditorAccount <CdtrAcct> [0..1] Identification [1..1] IBAN <IBAN> [1..1] Creditor's account number in IBAN format Cancellation request rejected in schema validation o The '12 schema validation failed' message is given immediately during the session. Cancellation request rejected in technical validation o o The 'GroupCancellationStatus' value in the response message is 'RJCT' No batch or transaction level information is given. Cancellation request accepted: o o o The 'GroupCancellationStatus' value in the response message is 'ACCR'. 'PaymentInformationCancellationStatus' for each accepted batch cancellation request is ACCR. 'TransactionCancellationStatus' for each accepted transaction cancellation request is ACCR. Cancellation request partially accepted: o The 'GroupCancellationStatus' value in the response message is PACR.

74 74/105 o o 'PaymentInformationCancellationStatus' for each accepted batch cancellation request is ACCR or RJCT. 'TransactionCancellationStatus' for each accepted transaction cancellation request is ACCR or RJCT. Cancellation request is rejected: o o o The 'GroupCancellationStatus' value in the response message is RJCR. 'PaymentInformationCancellationStatus' for each rejected batch cancellation request is RJCR. 'TransactionCancellationStatus' for each rejected transaction cancellation request is RJCR. Rejection codes Message Payment cancelled at customer's request Missing agreement Not allowed sender Account not found in the agreement Debtor Id missing Incorrect due date Incorrect account Incorrect payer's bank Incorrect payment method Incorrect service level Incorrect category purpose Incorrect charge bearer Incorrect currency Double data Description Payment cancelled at customer's request Missing agreement Sender not allowed Account not found in the agreement Debtor Id missing Incorrect due date Incorrect account Incorrect payer's bank Incorrect payment method Incorrect service level Incorrect category purpose Incorrect charge bearer code value Incorrect currency Duplicate data Payer's account may not be a foreign bank's account Payer's account may not be a foreign bank's account Debit account not possible at the moment Payment cancellation not allowed Payment to be cancelled not found Payment already cancelled Payment already processed Transaction cancellation not allowed Transaction to be cancelled not found Transaction already cancelled Transaction already processed Incomplete message information Debit account not possible at the moment Payment cancellation not allowed Payment to be cancelled not found Payment already cancelled Payment already processed Transaction cancellation not allowed Transaction to be cancelled not found Transaction already cancelled Transaction already processed Incomplete message information

75 Message Incomplete transaction identification information Description Incomplete transaction identification information 75/105 7 Example messages <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T09:00:01+02:00</CreDtTm> <NbOfTxs>6</NbOfTxs> <CtrlSum> </CtrlSum> <Grpg>MIXD</Grpg> <InitgPty> <Nm>Firma Oy</Nm> <PstlAdr> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> <Ctry>FI</Ctry> </PstlAdr> </InitgPty> </GrpHdr> SEPA payment <PmtInf> <PmtInfId> </PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> </PmtTpInf> <ReqdExctnDt> </ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> </PstlAdr> <OrgId> <BkPtyId> </BkPtyId> </OrgId> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <ChrgBr>SLEV</ChrgBr> <CdtTrfTxInf> <PmtId>

76 76/105 <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">150</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>GENODEFF</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Warenhaus Köln</Nm> <PstlAdr> <AdrLine>Kirchenstrasse 3</AdrLine> <AdrLine>DE Köln GERMANY</AdrLine> <Ctry>DE</Ctry> </PstlAdr> </Cdtr> <CdtrAcct> <IBAN>DE </IBAN> </CdtrAcct> <RmtInf> <Ustrd>Invoice 123</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> SEPA salary and an individual urgent payment <PmtInf> <PmtInfId> </PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> <CtgyPurp>SALA</CtgyPurp> </PmtTpInf> <ReqdExctnDt>14/08/2013</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> </PstlAdr> <OrgId> <BkPtyId> </BkPtyId> </OrgId> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <ChrgBr>SLEV</ChrgBr>

77 77/105 </PmtInf> <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> <SvcLvl> <Prtry>URGP</Prtry> </SvcLvl> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">450</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Ella Eläkkeensaaja</Nm> <PstlAdr> <AdrLine>Kotikatu 1</AdrLine> <AdrLine>00100 Helsinki</AdrLine> <Ctry>FI</Ctry> </PstlAdr> <PrvtId> <SclSctyNb> H</SclSctyNb> </PrvtId> </Cdtr> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> <Purp> <Cd>PENS</Cd> </Purp> </CdtTrfTxInf> Individual urgent payment can be included in the same batch as a SEPA payment <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> <SvcLvl> <Prtry>URGP</Prtry> </SvcLvl> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">350.50</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>NDEAFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Oy Yritys Ab</Nm> <PstlAdr> <AdrLine>Hämeenkatu 1</AdrLine> <AdrLine>00100 Helsinki</AdrLine>

78 78/105 <Ctry>FI</Ctry> </PstlAdr> </Cdtr> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> <RmtInf> <Ustrd>Urgent payment for your invoice No on 30 July 2013</Ustrd> </RmtInf> </CdtTrfTxInf> Urgent payment batch <PmtInf> <PmtInfId> </PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <SvcLvl> <Prtry>URGP</Prtry> </SvcLvl> </PmtTpInf> <ReqdExctnDt>14/08/2013</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> </PstlAdr> <OrgId> <BkPtyId> </BkPtyId> </OrgId> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <ChrgBr>SLEV</ChrgBr> <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>NDEAFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Oy Yritys Ab</Nm> <PstlAdr> <AdrLine>Hämeenkatu 1</AdrLine>

79 79/105 <AdrLine>00100 Helsinki</AdrLine> <Ctry>FI</Ctry> </PstlAdr> </Cdtr> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> <RmtInf> <Ustrd>Urgent payment of your invoice No on 1 August 2013</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> SEPA credit transfer with a reference The reference is exported to the recipient's referece listing: <RmtInf> <Strd> <CdtrRefInf> <CdtrRefTp> <Cd>SCOR</Cd> </CdtrRefTp> <CdtrRef> </CdtrRef> </CdtrRefInf> </Strd> </RmtInf> SEPA credit transfer with a message The message is exporte to the recipient's account statement: <RmtInf> <Ustrd>Invoice number 1122</Ustrd> </RmtInf> SEPA-AOS2 invoice itemisation In AOS2 structured invoice details, at least one invoice detail must be a credit note there must be at least one normal invoice in addition to the credit note The references are not exported to reference listing but the information is passed on to the creditor's account statemement with reference: In the example, InstdAmt is (net total) <RmtInf> <Strd> <RfrdDocInf> <RfrdDocTp> <Cd>CINV</Cd> </RfrdDocTp> <RfrdDocNb>Inv 12345</RfrdDocNb>

80 80/105 </RfrdDocInf> <RfrdDocAmt> <RmtdAmt Ccy="EUR"> </RmtdAmt> (gross total) </RfrdDocAmt> <CdtrRefInf> <CdtrRefTp> <Cd>SCOR</Cd> </CdtrRefTp> <CdtrRef> </CdtrRef> </CdtrRefInf> </Strd> <Strd> <RfrdDocInf> <RfrdDocTp> <Cd>CREN</Cd> </RfrdDocTp> <RfrdDocNb>Inv 12359</RfrdDocNb> </RfrdDocInf> <RfrdDocAmt> <CdtNoteAmt Ccy="EUR">200.00</CdtNoteAmt> (credit note amount) </RfrdDocAmt> <CdtrRefInf> <CdtrRefTp> <Cd>SCOR</Cd> </CdtrRefTp> <CdtrRef> </CdtrRef> </CdtrRefInf> </Strd> </RmtInf> International payment - payment order <PmtInf> <PmtInfId> </PmtInfId> <PmtMtd>TRF</PmtMtd> <ReqdExctnDt> </ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> </PstlAdr> <OrgId> <BkPtyId> </BkPtyId> </OrgId> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="USD">250.90</InstdAmt>

81 </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>IRVTUS3N</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Ewing Oil</Nm> <PstlAdr> <AdrLine>5th Avenue</AdrLine> <AdrLine>Dallas</AdrLine> <AdrLine>TEXAS 1234</AdrLine> <AdrLine>USA</AdrLine> <Ctry>US</Ctry> </PstlAdr> </Cdtr> <CdtrAcct> <BBAN> </BBAN> </CdtrAcct> <RmtInf> <Ustrd>Invoice 5656</Ustrd> </RmtInf> </CdtTrfTxInf> 81/ International payment payment order (clearing code) <CdtTrfTxInf> <PmtId> <InstrId>InstrId_2014_038</InstrId> <EndToEndId>e2e_038</EndToEndId> </PmtId> <Amt> <InstdAmt Ccy="USD">25.21</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <ClrSysMmbId> <MmbId>USABA </MmbId> </ClrSysMmbId> <Nm>First National Bank</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>123 5th Avenue</AdrLine> <AdrLine>New York</AdrLine> <AdrLine> NY</AdrLine> </PstlAdr> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>John Doe</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>PO BOX 7</AdrLine> <AdrLine>New York</AdrLine> <AdrLine> NY</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Othr> </Othr>

82 82/105 </CdtrAcct> <RmtInf> </RmtInf> </CdtTrfTxInf> <Ustrd>clearing code in one field</ustrd> International payment urgent payment order <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>HIGH</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="INR">290.10</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>SBININBB104</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Indi As</Nm> <PstlAdr> <AdrLine>Indian Street 3</AdrLine> <AdrLine>Indiala</AdrLine> <AdrLine>Kalkuta</AdrLine> <AdrLine>INDIA</AdrLine> <Ctry>IN</Ctry> </PstlAdr> </Cdtr> <CdtrAcct> <PrtryAcct> C </PrtryAcct> </CdtrAcct> <RmtInf> <Ustrd>Payment number carpets</ustrd> </RmtInf> </CdtTrfTxInf> International payment SWIFT cheque <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="USD">150</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <ChqInstr> <DlvryMtd> <Prtry>SWIFT</Prtry> </DlvryMtd> </ChqInstr> <Cdtr> <Nm>Hotel Ahmed</Nm>

83 <PstlAdr> <AdrLine>Ata 7</AdrLine> <AdrLine>Istanbul</AdrLine> <AdrLine>TURKEY</AdrLine> <Ctry>TR</Ctry> </PstlAdr> </Cdtr> <RmtInf> <Ustrd>Reservation </Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> </pain > </Document> 83/ International payment - International order <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR>45000</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </ FinInstnId > </ CdtrAgt > <Cdtr> <Nm>Firma Oy</Nm> <PstlAdr> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki FINLAND</AdrLine> <Ctry>FI</Ctry> </PstlAdr> </Cdtr> <CdtrAcct>FI </CdtrAcct > <RmtInf> <Ustrd>Invoice 765</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> </pain > </Document> Real-time C2B urgent payment <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T07:51: :00</CreDtTm> <NbOfTxs>1</NbOfTxs> <Grpg>MIXD</Grpg> <InitgPty>

84 84/105 <Nm>Firma Oy</Nm> <PstlAdr> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> <Ctry>FI</Ctry> </PstlAdr> </InitgPty> </GrpHdr> <PmtInf> <PmtInfId> </PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <SvcLvl> <Prtry>URGP</Prtry> </SvcLvl> </PmtTpInf> <ReqdExctnDt> </ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> <Ctry>FI</Ctry> </PstlAdr> <OrgId> <BkPtyId> </BkPtyId> </OrgId> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <CdtTrfTxInf> <PmtId> <EndToEndId> </EndToEndId> </PmtId> <PmtTpInf> <SvcLvl> <Prtry>URGP</Prtry> </SvcLvl> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">150.00</InstdAmt> </Amt> <ChrgBr>SLEV</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>NDEAFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Yritys Oy</Nm> </Cdtr> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> <RmtInf> <Ustrd>message</Ustrd> </RmtInf>

85 </CdtTrfTxInf> </PmtInf> </pain > </Document> 85/ Cancelling individual payment transactions <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:camt camt xsd"> <CstmrPmtCxlReq> <Assgnmt> ;8)G57 KO8SL DT0114.9KMT <Assgnr> <Pty> <Nm>Test</Nm> </Pty> </Assgnr> <Assgne> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgne> <CreDtTm> T14:35:32+02:00</CreDtTm> </Assgnmt> <Undrlyg> <OrgnlGrpInfAndCxl> <GrpCxlId>;8)G57 KO8SL DT0114.9KMT </GrpCxlId> <OrgnlMsgId>;8)G57 RE3LL TS0114.DN0B420000</OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <GrpCxl>false</GrpCxl> </OrgnlGrpInfAndCxl> <OrgnlPmtInfAndCxl> <Case> NOTPROVIDED <Cretr> <Pty> <OrgId> <Othr> <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Pty> </Cretr> </Case> <OrgnlPmtInfId>;8)G57 RE3LL TS0114.DN0B420001</OrgnlPmtInfId> <PmtInfCxl>false</PmtInfCxl> <TxInf> <CxlId>;8)G57 KO8SL DT0114.9KMT420001</CxlId> <OrgnlEndToEndId>NOTPROVIDED</OrgnlEndToEndId> <OrgnlInstdAmt Ccy="EUR"> </OrgnlInstdAmt> <OrgnlReqdExctnDt>14/01/2015</OrgnlReqdExctnDt> <OrgnlTxRef> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct>

86 <CdtrAcct> <IBAN> FI </IBAN> </CdtrAcct> </OrgnlTxRef> </TxInf> </OrgnlPmtInfAndCxl> </Undrlyg> </CstmrPmtCxlReq> </Document> 86/ Cancelling the entire batch <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:camt camt xsd"> <CstmrPmtCxlReq> <Assgnmt> ;8)G57 G47*L DT0114.NG <Assgnr> <Pty> <Nm>Test</Nm> </Pty> </Assgnr> <Assgne> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgne> <CreDtTm> T14:51:34+02:00</CreDtTm> </Assgnmt> <Undrlyg> <OrgnlGrpInfAndCxl> <GrpCxlId>;8)G57 G47*L DT0114.NG </GrpCxlId> <OrgnlMsgId>;8)G57 EHH+L TS0114.5C7Z520000</OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <GrpCxl>false</GrpCxl> </OrgnlGrpInfAndCxl> <OrgnlPmtInfAndCxl> <PmtCxlId>;8)G57 G47*L DT0114.NG </PmtCxlId> <Case> NOTPROVIDED <Cretr> <Pty> <OrgId> <Othr> <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Pty> </Cretr> </Case> <OrgnlPmtInfId>;8)G57 EHH+L TS0114.5C7Z520001</OrgnlPmtInfId> <NbOfTxs>3</NbOfTxs> <CtrlSum>143.00</CtrlSum> <PmtInfCxl>true</PmtInfCxl> </OrgnlPmtInfAndCxl> </Undrlyg> </CstmrPmtCxlReq>

87 </Document> 87/105 8 Example response messages 8.1 Report on technical validation Report on accepted technical validation <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T12:01:10+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>ACTC</GrpSts> </OrgnlGrpInfAndSts> </pain > </Document> Report on rejected technical validation <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T12:01:10+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>RJCT</GrpSts> <StsRsnInf> <StsRsn> <Cd>NARR</Cd> </StsRsn> <AddtlStsRsnInf>pain could not be processed, please verify structure. cvc-datatype-valid.1.2.1: '4847,37'</AddtlStsRsnInf> <AddtlStsRsnInf>is not a valid value for 'decimal'.cvc-type.3.1.3: The value '4847,37' of element 'CtrlSum' is not val</addtlstsrsninf> <AddtlStsRsnInf>id.</AddtlStsRsnInf> </StsRsnInf> </OrgnlGrpInfAndSts> </pain > </Document> Report on rejected techical validation of real-time C2B urgent payment

88 88/105 <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> <pain > <GrpHdr> <MsgId>TESTI_ </MsgId> <CreDtTm> T09:00:33+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <NtwkFileNm> </NtwkFileNm> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <GrpSts>RJCT</GrpSts> <StsRsnInf> <StsOrgtr> <OrgId> <PrtryId> </PrtryId> </OrgId> </StsOrgtr> <StsRsn> <Cd>NARR</Cd> </StsRsn> <AddtlStsRsnInf>pain could not be processed, please verify structure.cvc-elt.1: Cannot find the declaration of</addtlstsrsninf> <AddtlStsRsnInf>element 'Document'.</AddtlStsRsnInf> </StsRsnInf> </OrgnlGrpInfAndSts> </pain > </Document> 8.2 Report on payload content validation Report on accepted content validation <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain file:///c:/kultalinkki_ws2/c2b_ws/pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T13:31:34+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_ </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> :00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>150</OrgnlCtrlSum> <GrpSts>ACCP</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>ACCP</TxSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">150</InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr>

89 89/105 <Dbtr> </Dbtr> <DbtrAcct> <Nm>Firma Oy</Nm> </Document> </Document> </TxInfAndSts> </pain > </OrgnlTxRef> </DbtrAcct> <IBAN>FI </IBAN> Report on partially accepted content validation The payload contains four batches: Batch 1 - credit transfer of is OK - credit transfer of has an incorrect reference - credit transfer of 111, is OK Two transactions in the batch will be processed later Batch 2 has an incorrect requested execution date, so the entire batch is rejected Batch 3 - credit transfer of is OK - credit transfer of is OK Batch 4 - credit transfer of 500, is OK <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain file:///c:/kultalinkki_ws2/c2b_ws/pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T13:31:35+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_ </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>8</OrgnlNbOfTxs> <OrgnlCtrlSum> </OrgnlCtrlSum> <GrpSts>PART</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlInstrId>InstrId_147859</OrgnlInstrId> <OrgnlEndToEndId>e2e_147859</OrgnlEndToEndId> <OrgnlTxId> UTH </OrgnlTxId> <TxSts>RJCT</TxSts> <StsRsnInf> <StsRsn> <Cd>NARR</Cd> </StsRsn> <AddtlStsRsnInf>Incorrect reference.</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">22.10</InstdAmt>

90 </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> 90/105 </DbtrAcct> <Cdtr> </Cdtr> <CdtrAcct> <IBAN>FI </IBAN> <Nm>Oy Yritys Ab</Nm> </TxInfAndSts> <TxInfAndSts> </TxInfAndSts> <TxInfAndSts> </OrgnlTxRef> </CdtrAcct> <UltmtCdtr> </UltmtCdtr> <IBAN>FI </IBAN> <Nm>Ultimate Creditor</Nm> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>RJCT</TxSts> <StsRsnInf> <StsRsn> <Cd>DT01</Cd> </StsRsn> <AddtlStsRsnInf>Incorrect due date</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">741</InstdAmt> </Amt> <ReqdExctnDt>09/01/2013</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> </OrgnlTxRef> </DbtrAcct> <IBAN>FI </IBAN> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>ACCP</TxSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">665.99</InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr>

91 91/105 </Dbtr> <DbtrAcct> <Nm>Firma Oy</Nm> </Document> </TxInfAndSts> <TxInfAndSts> </TxInfAndSts> </pain > </OrgnlTxRef> </DbtrAcct> <IBAN>FI </IBAN> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>ACCP</TxSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt> ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> </OrgnlTxRef> Report on rejected content validation of real-time C2B urgent payment payload Incorrect due date: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T08:49: :00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T07:51: :00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>RJCT</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlEndToEndId> </OrgnlEndToEndId> <TxSts>RJCT</TxSts> <StsRsnInf> <StsRsn> <Cd>DT01</Cd> </StsRsn> <AddtlStsRsnInf>Incorrect due date.</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">15.00</InstdAmt> </Amt>

92 92/105 <ReqdExctnDt>16/09/2011</ReqdExctnDt> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </pain > </Document> Incorrect reference: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T08:55: :00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T07:51: :00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>RJCT</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlEndToEndId> </OrgnlEndToEndId> <TxSts>RJCT</TxSts> <StsRsnInf> <StsRsn> <Cd>NARR</Cd> </StsRsn> <AddtlStsRsnInf>Incorrect reference.</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">200.00</InstdAmt> </Amt> <ReqdExctnDt>19/09/2011</ReqdExctnDt> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </pain > </Document>

93 8.3 Report on payment Report on accepted payload ( pain ) 93/105 <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain file:///c:/kultalinkki_ws2/c2b_ws/pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T13:35:12+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_ </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>150</OrgnlCtrlSum> <GrpSts>ACSP</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>ACSP</TxSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">150</InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> </Document> <IBAN>FI </IBAN> </TxInfAndSts> </pain > </OrgnlTxRef> </DbtrAcct> Report on accepted real-time C2B urgent payment debit and credit transactions <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T12:45: :00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T07:51: :00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>ACSP</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlInstrId>invoice 123</OrgnlInstrId>

94 94/105 <OrgnlEndToEndId> </OrgnlEndToEndId> <OrgnlTxId>593728MD0002</OrgnlTxId> <TxSts>ACSP</TxSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">150.00</InstdAmt> </Amt> <ReqdExctnDt>12/09/2011</ReqdExctnDt> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </pain > </Document> Report on failed real-time C2B urgent payment debit and credit transactions <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T11:35: :00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T07:51: :00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>RJCT</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlEndToEndId> </OrgnlEndToEndId> <TxSts>RJCT</TxSts> <StsRsnInf> <StsRsn> <Cd>AC01</Cd> </StsRsn> <AddtlStsRsnInf>Incorrect payee's account.</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">200.00</InstdAmt> </Amt> <ReqdExctnDt>16/09/2011</ReqdExctnDt> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </pain > </Document>

95 95/105 Report on pending real-time C2B urgent payment <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T11:35: :00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId> </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T07:51: :00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>PDNG</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlEndToEndId> </OrgnlEndToEndId> <TxSts>PDNG</TxSts> <StsRsnInf> <StsRsn> <Cd>NARR</Cd> </StsRsn> <AddtlStsRsnInf>Unclear, contact your own bank.</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">200.00</InstdAmt> </Amt> <ReqdExctnDt>16/09/2011</ReqdExctnDt> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> <CdtrAcct> <IBAN>FI </IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </pain > </Document> Report on partly accepted payload ( pain ) The payload contains three batches: Batch 1 - credit transfer of credit transfer of 111, The customer s service agreement specifies that SEPA credit transfers can be bundled. The balance is insufficient for the bundled amount, so the batch cannot be paid. Batch 2 payment processed payment processed Batch 3 - credit transfer of 500, not processed, because of insufficient balance

96 96/105 The payment processing report, generated during the day after the processing of each C2B reception, includes all successfully paid batches and batches/transactions with the PDNG status that temporarily have insufficient funds or are waiting for processing. <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain file:///c:/kultalinkki_ws2/c2b_ws/pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T13:35:13+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_ </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>8</OrgnlNbOfTxs> <OrgnlCtrlSum> </OrgnlCtrlSum> <GrpSts>PART</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>PDNG</TxSts> <StsRsnInf> <StsRsn> <Cd>AM04</Cd> </StsRsn> <AddtlStsRsnInf>Insufficient funds</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> </TxInfAndSts> <TxInfAndSts> </OrgnlTxRef> </DbtrAcct> <IBAN>FI </IBAN> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>ACSP</TxSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">665.99</InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN>

97 97/105 </Document> </TxInfAndSts> <TxInfAndSts> </TxInfAndSts> </pain > </OrgnlTxRef> </DbtrAcct> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>PDNG</TxSts> <StsRsnInf> <StsRsn> <Cd>AM04</Cd> </StsRsn> <AddtlStsRsnInf>Insufficient funds</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> </OrgnlTxRef> The response message only contains payments awaiting sufficient funds: <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain file:///c:/kultalinkki_ws2/c2b_ws/pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T14:02:14+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_ </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>8</OrgnlNbOfTxs> <OrgnlCtrlSum> </OrgnlCtrlSum> <GrpSts>PDNG</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>PDNG</TxSts> <StsRsnInf> <StsRsn> <Cd>AM04</Cd> </StsRsn> <AddtlStsRsnInf>Insufficient funds</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt>

98 98/105 </Document> </TxInfAndSts> <TxInfAndSts> </TxInfAndSts> </pain > </OrgnlTxRef> <UltmtDbtr> </UltmtDbtr> <Dbtr> </Dbtr> <DbtrAcct> </DbtrAcct> <Nm>Original Debtor</Nm> <Nm>Firma Oy</Nm> <IBAN>FI </IBAN> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>PDNG</TxSts> <StsRsnInf> <StsRsn> <Cd>AM04</Cd> </StsRsn> <AddtlStsRsnInf>Insufficient funds</addtlstsrsninf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> </OrgnlTxRef> At the end of the day, an RJCT response, where the payments with insufficient funds are displayed as rejected. <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain file:///c:/kultalinkki_ws2/c2b_ws/pain xsd"> <pain > <GrpHdr> <MsgId> </MsgId> <CreDtTm> T17:32:02+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_ </OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgnlCreDtTm> T09:00:01+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>8</OrgnlNbOfTxs> <OrgnlCtrlSum> </OrgnlCtrlSum> <GrpSts>RJCT</GrpSts> </OrgnlGrpInfAndSts> <TxInfAndSts> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>RJCT</TxSts>

99 99/105 </Document> </TxInfAndSts> <TxInfAndSts> </TxInfAndSts> </pain > <StsRsnInf> </StsRsnInf> <OrgnlTxRef> </OrgnlTxRef> <StsRsn> <Cd>AM04</Cd> </StsRsn> <AddtlStsRsnInf>Insufficient funds</addtlstsrsninf> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> <OrgnlPmtInfId> </OrgnlPmtInfId> <OrgnlTxId> UTV </OrgnlTxId> <TxSts>RJCT</TxSts> <StsRsnInf> <StsRsn> <Cd>AM04</Cd> </StsRsn> <AddtlStsRsnInf> Insufficient funds </AddtlStsRsnInf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> <ReqdExctnDt>18/02/2015</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <IBAN>FI </IBAN> </DbtrAcct> </OrgnlTxRef> Notification for successful payment ( camt ) <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt " xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:camt camt xsd"> <BkToCstmrDbtCdtNtfctn> <GrpHdr> <MsgId> </MsgId> <CreDtTm> T18:12:02+03:00</CreDtTm> <MsgRcpt>

100 100/105 <OrgId> <Othr> </Othr> </OrgId> </MsgRcpt> </GrpHdr> <Ntfctn> <CreDtTm> T18:00:02+03:00</CreDtTm> <Acct> <IBAN>FI </IBAN> <Ccy>EUR</Ccy> <Svcr> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Svcr> </Acct> <Ntry> <Amt Ccy="XXX">250.9</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Sts>BOOK</Sts> <BookgDt> <Dt> </Dt> </BookgDt> <BkTxCd> <Prtry> <Cd>DBIT</Cd> </Prtry> </BkTxCd> <NtryDtls> <Btch> <PmtInfId> </PmtInfId> <NbOfTxs>1</NbOfTxs> </Btch> <TxDtls> <Refs> <MsgId>MsgId_ </MsgId> <AcctSvcrRef>111102ACCTSTMTARCH04</AcctSvcrRef> <InstrId> </InstrId> <EndToEndId> </EndToEndId> </Refs> <AmtDtls> <InstdAmt> <Amt Ccy="USD">250.9</Amt> <CcyXchq> <SrcCcy>USD</SrcCcy> <TrgtCcy>EUR</TrgtCcy> <UnitCcy>EUR</UnitCcy> <XchqRate>1.3389</XchqRate> <QtnDt> T14:12:02+03:00</QtnDt> </CcyXchq> </InstdAmt> <TxAmt> <Amt Ccy="EUR">187.39</Amt> <CcyXchg> <SrcCcy>EUR</SrcCcy> <TrgtCcy>EUR</TrgtCcy> <UnitCcy>EUR</UnitCcy> <XchgRate>1</XchgRate> </CcyXchg> </TxAmt> <CntrValAmt> <Amt Ccy="EUR">187.39</Amt> <CcyXchg>

101 101/105 <SrcCcy>EUR</SrcCcy> <TrgtCcy>EUR</TrgtCcy> <UnitCcy>EUR</UnitCcy> <XchgRate> </XchgRate> </CcyXchg> </CntrValAmt> </AmtDtls> <Chrgs> <Amt Ccy="EUR">0.0</Amt> <Br>SHAR</Br> </Chrgs> <RltdPties> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Cdtr> <Nm>Ewing Oil</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>5th Avenue</AdrLine> <AdrLine>5th Avenue</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Othr> >Id> </Othr> </CdtrAcct> </RltdPties> <RltdAgts> <CdtrAgt> <FinInstnId> <BIC>IRVTUS3N</BIC> </FinInstnId> </CdtrAgt> <IntrmyAgt1> <FinInstnId> <BIC> IRVTUS3N</BIC> </FinInstnId> </IntrmyAgt1> </RltdAgts> <RmtInf> <Ustrd>Invoice 5656</Ustrd> </RmtInf> <RltdDts> <AccptncDtTm> </AccptncDtTm> </RltdDts> </TxDtls> </NtryDtls> </Ntry> </Ntfctn> </BkToCstmrDbtCdtNtfctn> </Document> 9 Example responses to cancellation request 9.1 Report on technical validation (content check) Report on rejected technical validation

102 102/105 <RsltnOfInvstgtn> <Assgnmt> CANCROI/100928/ROI001 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <OrgId> <Othr> <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm> T16:10:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlGrpCxlId>CANCEL001</OrgnlGrpCxlId> <OrgnlMsgId>PAYMENT001</OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgCreDtTm> T16:10:30</OrgCreDtTm> <OrgnlNbOfTxs>3</OrgnlnbofTxs> <OrgnlCtrlSum>333,33</OrgnlCtrlSum> <GrpCxlSts>RJCR</GrpCxlSts> <CxlStsRsnInf> <Rsn> <Prtry>NARR</Prtry> <AddtlInf>Invalid original message name identification </AddtlInf> </Rsn> </CxlStsRsnInf> </OrgnlGrpInfAndSts> </RsltnOfInvstgtn> 9.1 Report for cancellation request processing Report for successfully processed cancellation request <RsltnOfInvstgtn> <Assgnmt> CANCROI/100928/ROI001 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <OrgId>

103 103/105 <Othr> <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm> T16:10:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlGrpCxlId>CANCEL001</OrgnlGrpCxlId> <OrgnlMsgId>PAYMENT001</OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgCreDtTm> T16:10:30</OrgCreDtTm> <OrgnlNbOfTxs>3</OrgnlnbofTxs> <OrgnlCtrlSum>333,33</OrgnlCtrlSum> <GrpCxlSts>ACCR</GrpCxlSts> <OrgnlPmtinfAndSts> <OrgnlPmtInfId>PMT000001</OrgnlPmtInfId> <PmtInfCxlSts>ACCR</PmtInfCxlSts> </RsltnOfInvstgtn> Notification for partially successful cancellation request <RsltnOfInvstgtn> <Assgnmt> CANCROI/100928/ROI002 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <OrgId> <Othr> <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm> T16:10:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlMsgId>ABC/100928/CCT01</OrgnlMsgId> <OrgnlMsgNmId>pacs </OrgnlMsgNmId> <OrgnlCreDtTm> T14:07:00</OrgnlCreDtTm> <OrgnlNbOfTxs>3</OrgnlNbOfTxs>

104 104/105 <GrpCxlSts>PACR</GrpCxlSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfCxlId>PMTCXL0001</OrgnlPmtInfCxlId> <OrgnlPmtInfId>ABC/086</OrgnlPmtInfId> <OrgnlNbOfTxs>2</OrgnlNbOfTxs> <TxInfAndSts> <OrgnlInstrId>ABC/100928/CCT01/1</OrgnlInstrId> <TxCxlSts>RJCR</TxCxlSts> <CxlStsRsnInf> <Rsn> <Prtry>NARR</Prtry> <AddtlInf>Incomplete transaction identification information</addtlinf> <OrgnlInstdAmt Ccy="JPY"> </OrgnlInstdAmt> <OrgnlReqdExctnDt> </OrgnlReqdExctnDt> <OrgnlInstrId>ABC/100928/CCT01/2</OrgnlInstrId> <TxCxlSts>ACCR</TxCxlSts> <OrgnlInstdAmt Ccy="EUR"> </OrgnlInstdAmt> <OrgnlReqdExctnDt> </OrgnlReqdExctnDt> </TxInfAndSts> </OrgnlPmtInfAndSts> </RsltnOfInvstgtn> Report on a totally rejected cancellation request <RsltnOfInvstgtn> <Assgnmt> CANCRO3/100928/ROI003 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <OrgId> <Othr> <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm> T16:12:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlGrpCxlId>CANCEL002</OrgnlGrpCxlId> <OrgnlMsgId>PAYMENT002</OrgnlMsgId> <OrgnlMsgNmId>pain </OrgnlMsgNmId> <OrgCreDtTm> T16:12:30</OrgCreDtTm> <GrpCxlSts>RJCR</GrpCxlSts> <OrgnlPmtinfAndSts> <OrgnlPmtInfId>PMT000002</OrgnlPmtInfId> <PmtInfCxlSts>RJCR</PmtInfCxlSts> <CxlStsRsnInf> <Rsn> <Prtry>NARR</Prtry> <AddtlInf>Payment already processed </AddtlInf>

105 105/105 </Rsn> </CxlStsRsnInf> </OrgnlPmtInfAndSts <OrgnlPmtinfAndSts> <OrgnlPmtInfId>PMT000003</OrgnlPmtInfId> <PmtInfCxlSts>RJCR</PmtInfCxlSts> <CxlStsRsnInf> <Rsn> <Prtry>NARR</Prtry> <AddtlInf>Payment cancellation not allowed </AddtlInf> </Rsn> </CxlStsRsnInf> </OrgnlPmtInfAndSts </OrgnlGrpInfAndSts>