OP's C2B SERVICES Pain 03. Payment Transfer Products

OP's C2B SERVICES Pain 03 Payment Transfer Products Customer Guidelines March 2015

2/104 Version Key Changes Changed section November 2012 added money orders 13 C2B money orders July 2013 updated payment removal 115 and 6 September 2013 C2B urgent payment among SEPA 32, 36, 37 payment data, specified the currencies of foreign currency cheques and SWIFT cheques September 2013 paying in the Baltic countries 14 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 36 Minor updates to the document

Contents 3/104 1 General notes 4 11 C2B payment 5 12 Recurring C2B payments 6 13 C2B urgent payments 7 14 C2B money orders 7 15 C2B payments from accounts in Estonia, Latvia and Lithuania 8 16 C2B payload checks by the bank 8 17 Responses to C2B payment messages 8 18 C2B cancellation request 9 2 Sending and retrieval of messages 9 21 Stages in the process 10 22 Structure of the payload file sent by the customer 11 23 Schedules for payload sent by customer to bank 11 24 Structure of responses retrieved by the customer 12 25 Response creation and schedules 12 26 Checking of available funds and payment 12 27 Clearing codes 13 28 Charge bearer codes 14 29 Requirements for adopting the service 14 210 The testing environment 15 211 Testing environment IDs and certificates 15 212 URLs 15 213 Limitations of the testing environment 16 214 Help desk and sorting 16 3 C2B payment initiation message and example descriptions 16 31 Group Header 17 32 SEPA payment (incl instructions for sending urgent payments (one or more) among the rest of the SEPA payload) 18 33 Recurring SEPA credit transfers are sent in a separate batch (only used in Finland, not in Estonia, Latvia or Lithuania) 28 34 International payment payment order 34 35 International payment urgent payment order 38 36 International payment SWIFT cheque 42 37 International payment international payment instruction 44 38 Real-time C2B urgent payment 47 381 File type of real-time C2B urgent payment 47 382 Example message of a real-time C2B urgent payment 48 4 Bank C2B response and message description 53 41 Report on technical validation 53 42 Report on payload content validation 53 43 Payment status report ( pain ) 54 44 Report on processed payments ('camt') 57 45 Response message to a real-time C2B urgent payment initiation message and the reasons of rejection 62 5 C2B cancellation request (camt05500101) 64 6 Response to C2B cancellation request (camt02900103) 69 7 Example messages 76 8 Example response messages 89 81 Report on technical validation 89 811 Report on accepted technical validation 89 812 Report on rejected technical validation 89 813 Report on failed technical validation of real-time C2B urgent payment 89 82 Report on payload content validation 90 821 Report on accepted content validation 90 822 Report on partially accepted content validation 91 823 Report on rejected content validation of C2B payload 93 83 Report on payment 94

4/104 831 Report on accepted payload ('pain') 94 832 Report on partially accepted payload ('pain') 97 833 Notification for successful payment ( camt ) 99 9 Example responses to cancellation request 101 91 Report on technical validation (content check) 101 911 Report on rejected technical validation 101 91 Notification for processed cancellation request 102 911 Report for successfully processed cancellation request 102 912 Notification for partially successful cancellation request 102 913 Report on a totally rejected cancellation request 103 1 General notes 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 20022 message in XML format The schema for the payload sent to the bank is pain00100103xsd, and the schema for the bank s response that the customer retrieves from the bank is pain00200103xsd The C2B cancellation request message is an international ISO 20022 message in XML format The schema for the cancellation request sent to the bank is camt05500101 The schema for the bank's response that the customer retrieves from the bank is camt02900103 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-Pohjola Group apply The automated cancellation request message must be implemented in compliance with the guidelines issued by OP-Pohjola Group 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 wwwfklfi Website of the OP-Pohjola Group wwwopfi Message types conforming to the ISO 20022 standard For the schemas and documentation, please refer to the ISO website at wwwiso20022org Additional information is also available on the Federation of Finnish Financial Services web site, at wwwfklfi Material types in the Web Services (WS) and batch transfer channel Name Message types conforming to the ISO 20022 standard Schema Value of FileType field in WS channel Material identifier in batch transfer channel

5/104 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 Notification for processed cancellation request Message types conforming to the ISO 20022 standard Schema CustomerCreditTransferInitiantionV03 pain00100103xsd CustomerCreditTransferInitiantionV03 pain00100103xsd CustomerCreditTransferInitiantionV03 pain00100103xsd CustomerCreditTransferInitiantionV03 pain00100103xsd CustomerCreditTransferInitiantionV03 pain00100103xsd CustomerPaymentCancellationRequestV01 camt05500101xsd PaymentStatusReportV03 pain00200103 PaymentStatusReportV03 pain00200103 PaymentStatusReportV03 pain00200103 BankToCustomerDebitCreditNotificationV03 camt05400102 MP ResolutionOfInvestigationV03 camt02900103 Value of FileType field in WS channel pain00100103 pain00100103 pain00100103 pain00100103 pain00100103 camt05500101 pain00200103 pain00200103 pain00200103 camt05400102 camt02900103 Material identifier in batch transfer channel XM XM XM XM TP4 PS01 service only in WS channel XP XP XP XC service only in WS channel 11 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 provided in the C2B payload, 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 the OP- Pohjola Group in Finland, structured invoice details (max 999x280 characters) are allowed

* 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/104 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 12 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

13 C2B urgent payments 7/104 Domestic C2B urgent payments can be made in two ways 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-Pohjola 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 330 pm b) In real time as individual, online C2B urgent payments These urgent payments sent as separate urgent payment data types (pain00100102 TP4 PS01 and pain00100103 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 430 pm 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) 14 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-Pohjola Group 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) The money orders must arrive at OP-Services Ltd 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

8/104 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 15 C2B payments from accounts 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 the Web Services channel of the OP-Pohjola Group 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 16 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 17 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 (pain00100103) for which the C2B payment status report (pain00200103) is generated is identified in the <OrgnlGrpInfAndSts><OrgnlMsgId> element This element contains the original <GrpHdr><MsgId> provided by the customer in the C2B payload In individual payments, the original payment for which the response is generated is identified as follows:

9/104 In 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 (camt05400102) 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 (pain00100103) for which the Bank-to-Customer Debit/Credit Notification (camt05400102) 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 In addition to the InstructionIdentification and EndToEndIdentification in the original payment initiation message, the cancellation of an individual payment is identified by 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 18 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 +358 100 05151 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 camt029 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

21 Stages in the process 10/104 C2B payment payload A customer sends a C2B payload in ISO 20022 message format with contents according to OP-Pohjola Group s customer instructions 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-Pohjola Group 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 920 pm 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 pm, 6 pm and 930 pm) 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 mmdd99999, where 99999 is the ID of the message from the bank Cancellation request A customer sends a C2B cancellation request (camt05500101) in ISO 20022 message format via the Web Services channel with contents according to OP-Pohjola Group s service description 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/104 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 22 Structure of the payload file sent by the customer The payment message is composed of three 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-Pohjola Group 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 23 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) at 330 am, then 700 am every 30 minutes 600 pm Payloads received after 600 pm 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 330 am, then 700 am every 30 minutes 600 pm A payload that is received after 600 pm 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 C2B urgent payments among a SEPA payload Outgoing international payments (C2B) Real-time C2B urgent payments at 800 am, then every 30 minutes 330 pm 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 at 330 am, then 700 am every 30 minuts 500 pm Payments received prior to 500 pm on the execution date are processed during the same banking day Payments received before noon on New Year's Day and Maundy Thursday will be processed on the same banking day 800 am in real-time 430 pm No requested execution date is allowed

12/104 Outgoing payments (C2B) from Estonian, Latvian and Lithuanian accounts Payments received prior to 230 pm on the execution date are processed on the same banking day Outgoing international payments (C2B) from Estonian, Latvian and Lithuanian accounts C2B urgent payments from Estonian, Latvian and Lithuanian accounts Payments received prior to 300 pm on the execution date are processed on the same banking day 800 am in real-time 300 pm No requested execution date is allowed 24 Structure of responses retrieved by the customer The bank s responses to payments initiated by a C2B payment message use the schema pain00200103 or camt05400102 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 25 Response creation and schedules Status reports (pain00200103) 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' report on payment processing on the requested execution date at the end of the processing day Creation of camt messages for successful payments is specified separately in the service agreement The camt notifications are created at 12pm, 3 pm, 6 pm and 930 pm 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 26 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 in the order in which they appear in the payment instruction until insufficient funds remain, and the rest of the payments are rejected

13/104 A retrievable report on payments with insufficient funds is generated for the customer already during the day, if this has been agreed on the service agreement Additionally, at 920 pm at the end of the day, a report is automatically generated for payments with insufficient funds without requiring separate agreement Bank service charges are charged monthly by the fifth banking day of the month following the invoicing month 27 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 ISO20022 OP-Pohjola Group accepts clearing codes only for countries and currencies that appear in boldface in the table below For countries that do not appear in bold, clearing codes are not used, because payments are transferred with BICs and IBANs, or because OP-Pohjola Group does not have a nostro account in the country The clearing code is specified at transaction level in the ClrSysMmbId element For example: <ClrSysMmbId> <Id> USABA123456789 or <ClrSysMmbId> <ClrSysId> <Cd>USABA</Cd> </ClrSysId> <MmbId>123456789</MmbId> </ClrSysMmbId> For rouble 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> <Id> RUCBC041234567/12345678901234567890 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} AUBSB123456 only AUD YES (BSB) Austria Austrian Bankleitzahl ATBLZ [0-9]{5,5} ATBLZ12345 only EUR NO Canada Canadian Payments Association Payment Routing Number CACPA [0-9]{9,9} CACPA123456789 only CAD YES China CNAPS Identifier CNAPS [0-9]{12,12} CNAPS123456789012 only CNY NO Germany German Bankleitzahl DEBLZ [0-9]{8,8} DEBLZ12345678 only EUR NO Greece Hellenic Bank Identification Code GRBIC [0-9]{7,7} GRHIC1234567 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-9]{11,11} INFSC123AZ456789 only INR YES Ireland Irish National Clearing Code IENCC [0-9]{6,6} IENCC123456 only EUR NO Italy Italian Domestic Identification Code ITNCC [0-9]{10,10} ITNCC1234567890 only EUR NO Japan Japan Zengin Clearing Code JPZGN [0-9]{7,7} JPZGN1234567 only JPY YES New New Zealand National Clearing Code NZNCC [0-9]{6,6} NZNCC123456 only NZD YES Zealand Poland Polish National Clearing Code PLKNR [0-9]{8,8} PLKNR12345678 only PLN YES Portugal Portuguese National Clearing Code PTNCC [0-9]{8,8} PTNCC12345678 only EUR NO Russia Russian Central Bank Identification Code RUCBC [0-9]{9,9} RUCBC041234567 (first two numbers always 04) only RUB YES

14/104 Singapore IBG Sort Code SGIBG [0-9]{7,7} or [0-9]{3,4} SGIBG1234567 only SGD YES South Africa South African National Clearing Code ZANCC [0-9]{6,6} ZANCC123456 only ZAR YES Spain Spanish Domestic Interbanking Code ESNCC [0-9]{8,9} ESNCC12345678 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 Switzerland Swiss Clearing Code (SIC Code) CHSIC [0-9]{6,6} CHSIC123456 only CHF YES Taiwan Financial Institution Code TWNCC [0-9]{7,7} TWNCC1234567 only TWD NO UK UK Domestic Sort Code GBDSC [0-9]{6,6} GBDSC123456 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} USABA123456789 only USD and EUR YES 28 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 29 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

15/104 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 210 The testing environment OP-Pohjola 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-Pohjola Group 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 the OP-Pohjola Group Central Cooperative by e-mail attachment, provided that the structural validity of the attached payload has been checked against the schema For more information on testing, contact ict-tupamaksuliike@opfi 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 211 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 212 URLs To obtain IDs and keys for the testing environment, please contact the following e-mail address: icttupamaksuliike@opfi The testing environment URL is: https://wskasiakastestiopfi The WSDL description of services in the testing environment is available here: https://wskasiakastestiopfi/wsdl/maksuliikewsxml The WDSL description of the certificate service in the customer test environment is available in the following address: https://wskasiakastestiopfi/wsdl/maksuliikecertservicexml

16/104 The general descriptions and XML schemas of the services are available from the Federation of Finnish Financial Services web site at the following URL: http://wwwfklfi/www/page/fk_www_3830 213 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 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 (pain00100102pain00100103) 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) 214 Help desk and sorting Corporate and credit transfer services Phone +358 100 05151 ( 010/min + local network charges) The service is available from 8am to 430pm on weekdays The service will instruct you how to proceed E-mail yrityspuhelinpalvelu@opfi 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 593497 593592 593220 593530 593561 3 C2B payment initiation message and example descriptions The first column, Index, refers to the element number according to the ISO 20022 standard 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-Initiationpdf) The second column, Number, contains the number of element occurrences according to the schema 01 - the element is optional, and there can be only one occurrence; 11 - the element is mandatory, and there must be only one occurrence; 02 - the element is optional, and there can be a maximum of two occurrences;

17/104 0n - the element is optional, and there can be several occurrences; 1n - 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 The messages have the following structures: 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 31 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) 11 CstmrCdtTrfIn itn Message type 10 11 GrpHdr Each message must contain at least one block of this kind that contains common information for the message 11 11 +MsgId 20110102-0000001 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) 12 11 +CreDtTm 2011-01- 02T09:00:01+02:00 Timestamp of the message s creation by the debtor, mandatory 16 11 +NbOfTxs 6 The number of individual transactions, or CdtTrfTxInf transactions, included in the message by the debtor, mandatory; Bank will not check the information given 17 01 +CtrlSum 2000000 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 18 11 +InitgPty 18 01 ++Nm Firma Oy Name of message creator

18/104 18 01 ++PstlAdr Postal address of message creator 18 01 +++Ctry FI Mandatory if AdrLine is given: Country code under ISO 3166, according to Alpha-2 18 02 +++AdrLine Teollisuuskatu 1 Street address 00550 Helsinki Postal address 32 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 20 1n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information 21 11 +PmtInfId 20110102-123456-01 Mandatory identifier assigned by debtor to identify a payment batch, passed on to the messages for the debtor and account statement Not passed on to the creditor 22 11 +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 253 If element 253 is empty and this element has the value CHK, the value BCHQ is conveyed to element 253 on the transaction level 23 01 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 26 01 +PmtTpInf Not mandatory 27 01 ++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 element 232 If it is empty, the information contained in this element (if any) is used for the transaction 28 01 ++SvcLvl The Service Level code is primarily given in this

19/104 field, in which case all payments in the batch are interpreted according to the given code 29 11 +++Cd SEPA The values allowed are SEPA, SDVA, PRPT, and URGP The only value allowed for SEPA credit transfers is SEPA When value URGP is entered here, all payments of the batch are urgent payments You can pay an individual payment as an urgent payment by entering the URGP code in the crediting information in element 234 214 01 ++CtgyPurp 215 11 +++Cd Purpose of payment code, not mandatory The SALA code is used to identify recurring SEPA credit transfers; Also see 286 (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 217 11 +ReqdExctnD t NB: SALA-coded urgent payments are debited and credited on the same day 2011-05-10 The mandatory requested execution date can be a maximum of 365 days in the future (also applies to urgent payments) This information is passed on to another financial institution on an urgent payment NB: 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 219 11 +Dbtr Mandatory debtor information 219 01 ++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 219 01 ++PstlAdr 219 01 +++Ctry The country code is mandatory for the debtor s address if an address is given 219 05 +++AdrLine The bank passes on the debtor s address used in the C2B agreement 219 01 X ++Id Debtor ID 219 11 +++OrgId 219 01 ++++BICOrB EI In SEPA payments, also the BIC or BEI code provided in addition to the payment identifier 219 02 ++++Othr 219 11 +++++Id 12345678900 The customer provides the payment identifier, which the bank uses to link the payload to a C2B service agreement ie, checks which

customer s payload this is 20/104 Payment identifier (9-11 char), mandatory datum, not passed on to the creditor In SEPA payments, one Compay ID can be provided in addition to the payment identifier by repeating the 'Othr' structure This identifier is passed on to the creditor 219 01 +++++Schme Nm 219 11 {Or ++++++Cd BANK The 'BANK' value indicates that a payment identifier is provided in the 'Id' field 219 11 Or} ++++++Prtry 220 11 +DbtrAcct Mandatory 220 11 ++Id 220 11 {Or This indicates the type of a further company ID that may be provided in addition to the payment identifier in SEPA payments, such as a "Business ID" +++IBAN FI2550001520322972 For SEPA credit transfers, the account number is always given in IBAN format The debit account in OP-Pohjola Group must always be in the IBAN format Also when the debit account is an account at Pohjola Bank Estonia, Latvia or Lithuania 220 11 +++Othr Or} 220 11 ++++Id A debit account with a bank other than the OP- Pohjola Group can be presented as BBAN (letters and numbers) or in proprietary format (letters, numbers and punctuation marks) For SEPA credit transfers, it is not possible to give an account number in the BBAN or proprietary format 220 01 ++Ccy EUR Currency of the debit account 221 11 +DbtrAgt Debtor s bank information, mandatory 221 11 ++ FinInstnId 221 01 +++BIC OKOYFIHH In SEPA credit transfers, BIC is not mandatory but recommended 223 01 +UltmtDbtr Original debtor 223 01 ++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 ) 223 01 ++Id 223 11 +++OrgId {Or 223 01 ++++BICOrB BIC or BEI code of the original debtor EI 223 01 ++++Othr 223 11 +++++Id Company ID of the original debtor 223 11 +++PrvtId Or} 223 01 ++++Othr 223 11 +++++Id Personal ID of the original debtor 224 01 +ChrgBr SLEV The charge bearer code can be given for each

21/104 individual transaction If there is no transactionspecific charge bearer code, it is checked from this field In SEPA payments, the charge bearer code must be SLEV 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 227 1n +CdtTrfTxInf Credit transfer At least one block of this kind is required transaction information 228 11 ++PmtId Mandatory payment identification 229 01 +++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 230 11 +++EndToEn did 9834454645554699 Mandatory end-to-end reference, 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 ) 231 01 ++PmtTpInf Payment type information for the bank 232 01 +++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 The information is primarily retrieved from this element If this element has no value, the value in element 27 (if any) is used for the transaction 233 01 +++SvcLvl Service level Information is primarily entered at PmtInf level, or element 29 234 11 ++++Cd URGP The only code allowed for urgent payments is 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 29 239 01 +++CtgyPurp 240 11 ++++Cd Payment category code, the only value allowed is TAXS tax-related message

22/104 In Finland, SEPA credit transfers to the Finnish tax authorities that contain a tax-related message must use the code TAXS and reference (2126) as well as the so-called tax message (2129) 242 11 ++Amt As mandatory information, the amount payable 243 11 +++InstdAmt 15000 Instructed amount payable The specified amount must be between 0,01 and 999999999,99 243 11 +++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 Exchange rate information 247 01 ++XchgRateIn f 250 01 +++CtrctId Currency exchange deal number ie, rate reference, which is used only in international payments 251 01 ++ChrgBr The charge bearer code is determined primarily at transaction level In SEPA payments, the charge bearer code must be SLEV Code values SHAR and TYHJÄ (empty) are changed to SLEV 252 01 ++ChqInstr The codes allowed for international payments are SHAR, DEBT, and CRED Code values SLEV and TYHJÄ (empty) are changed to SHAR 253 01 +++ChqTp For foreign-currency cheques, a field with the value BCHQ The values CCCH, CCHQ, DRFT, and ELDR are changed to BCHQ The CHK value in element 22 instructs that the credit transfer be processed as a cheque Cheque information is primarily checked from element 253 If this element is empty and element 22 contains the value CHK, the value used for this element is BCHQ 258 01 +++DlvryMtd Cheque delivery method 260 11 ++++Prtry For a SWIFT cheque, a field with the mandatory value SWIFT 270 01 ++UltmtDbtr Original debtor This data can also be provided at 'PaymentInformation' level in field 223 If both fields 223 and 270 contain data, the data in field 270 is observed 270 01 +++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 ) 270 01 +++Id

23/104 270 11 ++++OrgId {Or 270 01 +++++BICOrB BIC or BEI code of the original debtor EI 270 01 +++++Othr 270 11 ++++++Id Company ID of the original debtor 270 11 ++++PrvtId Or} 270 01 +++++Othr 270 11 ++++++Id Personal ID of the original debtor 277 01 ++CdtrAgt 277 11 +++FinInstnId 277 01 ++++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 277 01 ++++ClrSysM Clearing code mbid 277 11 +++++MmbId 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 277 01 ++++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 277 01 ++++PstlAdr 277 01 +++++Ctry The country code is mandatory for the debtor s address if an address is given 277 05 +++++AdrLine 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 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Warenhaus Köln Creditor s name is mandatory This information is passed on to another financial institution on an urgent payment 279 01 +++PstlAdr Creditor s postal address 279 01 ++++StrtNm Street address is mandatory and used only in payment orders Maximum length 30 characters 279 01 ++++PstCd Postal code is mandatory and used only in payment orders Maximum length 5 characters 279 01 ++++TwnNm Town name is mandatory and used only in payment orders Maximum length 10 characters 279 01 ++++Ctry DE Creditor s country code is mandatory if the creditor s address is given 279 04 ++++AdrLine Kirchenstrasse 3 Not mandatory but recommended for SEPA payments and recurring payments recurring payments Max 2 address

24/104 lines In international payments, the creditor's address is mandatory ++++AdrLine DE-26458 Köln 279 01 +++Id Creditor ID 279 11 {Or ++++OrgId In payment orders, it is recommended to give either the creditor s Business ID or Social Security Number (TaxIdNb or SclSctyNb) 279 01 +++++BICOrB BIC or BEI EI 279 01 +++++Othr 279 11 ++++++Id Creditor company ID 279 01 ++++++Schm enm 279 11 {{Or +++++++Cd 279 11 Or}} 279 11 Or} +++++++Prtry ++++PrvtId For SEPA payments, the allowed company IDs are: BANK, CUST, DUNS, EMPL, GS1G and TXID Any other company ID values are provided in this element 279 01 +++++Othr 279 11 ++++++Id In SEPA salary payments (payment coded as SALA), it is recommendable to use the creditor s social security number (SclSctyNb) 279 01 ++++++Schm enm 279 11 {Or +++++++Cd For SEPA payments, the allowed personal IDs are: ARNU, CCPT, CUST, DRLC, EMPL, NIDN, SOSE ja TXID 279 11 Or} +++++++Prtry Any other personal ID values are provided in this element 280 01 ++CdtrAcct In international payments, the account number can also be in the BBAN or proprietary format Creditor s account is not given for foreigncurrency cheques and SWIFT cheques 280 11 +++Id 280 11 ++++IBAN DE893704004405320130 00 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 For SEPA credit transfers and urgent payments, the creditor s account number is always given in the IBAN format This information is passed on to another financial institution on an urgent payment In payment orders, the following standard value is given as the account number:

FI5059999999999991 25/104 IBAN format is not mandatory for international payments 280 11 ++++Othr 280 11 +++++Id In international payments, the account number can also be provided in a format other than IBAN 281 01 ++UltmtCdtr Ultimate creditor Passed on for SEPA credit transfers 281 01 +++Nm Name of ultimate creditor 281 01 +++Id ID for ultimate creditor 281 11 ++++OrgId Company ID for ultimate creditor {Or 281 11 ++++PrvtId Personal ID for ultimate creditor Or} 282 02 ++InstrForCdt ragt Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed 283 01 +++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 284 01 +++InstrInf Further instructions for the foreign bank, max 285 01 ++InstrForDbt ragt 140 characters Instructions for the debtor s bank The only instruction code currently in use for SEPA credit transfers: [EIOHJ] no instruction 286 01 ++Purp Purpose of payment 287 11 +++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) PENS (PensionPayment) BENE (UnemploymentDisabilityBenefit) SSBE (SocialSecurityBenefit) AGRT (Agricultural Payment) SALA (Salary) TAXS (TaxPayment) If the Category Purpose field (Index 215) 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 NB: If the Category Purpose field (index 215)

26/104 does not contain the code SALA, the code provided is passed on as given 298 01 ++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 NB: 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) Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22) 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

27/104 by the Federation of Finnish Financial Services; visit wwwfklfi 299 01 +++Ustrd Unstructured message to the creditor In the case of an urgent payment, you can enter text or an RF reference in this field This information is passed on to another financial institution on an urgent payment 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 also be noted that EndToEndId (230) is placed at the beginning of the message field If provided in the payload, Ref (2126) and UltmtDbtr/Nm (223 or 270) are also used This information decreases the number of characters available for the open-ended message 2100 0n +++Strd Structured message to the payee; see 298 2101 01 ++++RfrdDocI nf 2102 01 +++++Tp Invoice type 2103 11 ++++++CdOr Prtry 2104 11 +++++++Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice Otherwise, the code (CREN or CINV) is determined by the total bucket (2112 or 2119) in which the amount of the invoice or credit note has been entered 2107 01 +++++Nb Invoice number, not passed on for international payments 2108 01 +++++RltdDt Date of invoice, not in use for the time being 2109 01 ++++RfrdDoc Amt Amount and currency of the invoice or credit note 2112 01 +++++CdtNot Credit note amount eamt +++++CdtNot Currency of credit note eamt 'Ccy' 2119 01 +++++RmtdA mt Invoice amount If the invoice type is CINV or some other code (excl CREN), this element is to be used +++++RmtdA mt 'Ccy' 2120 01 ++++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 Currency of invoice Creditor reference information ie, invoice or credit note reference

28/104 2121 01 +++++Tp 2122 11 ++++++CdOr Prtry 2123 11 +++++++Cd SCOR If field 2126 contains a domestic or RF reference, the value SCOR is given in this field 2125 01 ++++++Issr Indicator of which standards-based reference number is in use 2126 01 +++++Ref RF0212345614 Reference, for example a Finnish reference number (also for urgent payments) This information is passed on to another financial institution on an urgent payment In the case of tax payment, the code TAXS is given in 240 and this block contains the reference number The tax-related message is given in the following block (2129) 2129 01 ++++AddtlRm tinf The 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 240 and the previous block (2126) contains the reference number The tax-related message is given in the this block Not passed on for international payments 33 Recurring SEPA credit transfers are sent in a separate batch (only used in Finland, not in Estonia, Latvia or Lithuania) 20 1n 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 21 11 +PmtInfId 20110102-123456-01 Mandatory identifier assigned by debtor to identify a payment batch, passed on to the messages for the debtor and account statement Not passed on to the creditor 22 11 +PmtMtd TRF The only code allowed for SEPA credit transfers is TRF 26 01 +PmtTpInf Not mandatory 27 01 ++InstrPrty NORM The only code allowed for SEPA credit transfers is NORM 28 01 ++SvcLvl 29 11 +++Cd SEPA The only value allowed for SEPA credit transfers is SEPA 214 01 ++CtgyPurp 215 11 +++Cd SALA The code SALA must be used to identify recurrent SEPA credit transfers; See also 286 (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

29/104 217 11 +ReqdExctnD t on the banking day following the requested execution date 2011-05-10 The requested execution date mandatory may be, at max, 365 days in the future NB: The SALA requested execution date must be a banking day If it is not, the batch will be rejected 219 11 +Dbtr 219 01 ++Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement 219 01 ++PstlAdr 219 01 +++Ctry The country code is mandatory for the debtor s address if an address is given 219 05 +++AdrLine The bank passes on the debtor s address used in the C2B agreement 219 01 X ++Id Debtor ID 219 11 +++OrgId 219 01 ++++BICOrB EI In SEPA payments, also the BIC or BEI code provided in addition to the payment identifier 219 02 ++++Othr 219 11 +++++Id 12345678900 The customer provides the payment identifier, which the bank uses to link the payload to a C2B service agreement ie, checks which customer s payload this is Payment identifier (9-11 char), mandatory datum, not passed on to the creditor In SEPA payments, one Compay ID can be provided in addition to the payment identifier by repeating the 'Othr' structure This identifier is passed on to the creditor 219 01 +++++Schme Nm 219 11 {Or ++++++Cd BANK The 'BANK' value indicates that a payment identifier is provided in the 'Id' field 219 11 Or} ++++++Prtry This indicates another type of company ID that may be provided in addition to the payment identifier in SEPA payments, such as a "Business ID" 220 11 +DbtrAcct 220 11 ++Id 220 11 +++IBAN FI2550001520322972 For SEPA credit transfers, the account number is always given in IBAN format The debit account in OP-Pohjola Group must always be in the IBAN format 220 01 ++Ccy EUR Currency of the debit account 221 11 +DbtrAgt Information of debtor's bank 221 11 ++ FinInstnId 221 01 +++BIC OKOYFIHH In SEPA credit transfers, BIC is not mandatory but recommended 223 01 +UltmtDbtr Original debtor 223 01 ++Nm Name of original debtor 223 01 ++Id

30/104 223 11 +++OrgId {Or 223 01 ++++BICOrB BIC or BEI code of the original debtor EI 223 01 ++++Othr 223 11 +++++Id Company ID of the original debtor 223 11 +++PrvtId Or} 223 01 ++++Othr 223 11 +++++Id Personal ID of the original debtor 224 01 +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 For SEPA credit transfers, the code values SHAR and TYHJÄ (empty) are changed to SLEV 227 1n +CdtTrfTxInf Credit transfer At least one block of this kind is required transaction information 228 11 ++PmtId Mandatory payment identification 229 01 +++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 230 11 +++EndToEn did 9834454645554699 Mandatory end-to-end reference, 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 242 11 ++Amt As mandatory information, the amount payable 243 11 +++InstdAmt 200000 Instructed amount payable The specified amount must be between 0,01 and 999999999,99 243 11 +++InstdAmt EUR Currency of the amount instructed attribute 'Ccy' 251 01 ++ChrgBr The charge bearer code is determined primarily at transaction level For SEPA payments, the allowed values are SLEV, SHAR and empty SHAR and empty are changed to SLEV 270 01 ++UltmtDbtr Original debtor This data can also be provided at 'PaymentInformation' level in field 223 If both fields 223 and 270 contain data, the data in field 270 is observed 270 01 +++Nm Name of original debtor 270 01 +++Id 270 11 ++++OrgId {Or 270 01 +++++BICOrB BIC or BEI code of the original debtor EI 270 01 +++++Othr

31/104 270 11 ++++++Id Company ID of the original debtor 270 11 ++++PrvtId Or} 270 01 +++++Othr 270 11 ++++++Id Personal ID of the original debtor 277 [01] ++CdtrAgt 277 11 +++FinInstnId 277 01 ++++BIC OKOYFIHH The BIC code of the creditor s bank is mandatory for SEPA credit transfers 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Pekka Palkansaaja Creditor s name is mandatory 279 01 +++PstlAdr Creditor s postal address 279 01 ++++Ctry FI Creditor s country code is mandatory if the creditor s address is given 279 04 ++++AdrLine Kotikatu 1 Not mandatory but recommended for SEPA payments and recurring payments recurring payments Max 2 address lines 00100 Helsinki 279 01 +++Id Creditor ID 279 11 ++++PrvtId 279 01 +++++Othr 279 11 ++++++Id 010160-777H In SEPA salary payments (payment coded as SALA), it is recommendable to use the creditor s social security number (SclSctyNb) 279 01 ++++++Schm enm 279 11 +++++++Cd SOSE The code indicates that the value provided in the 'Id' element is a social security number 280 01 ++CdtrAcct 280 11 +++Id 280 11 ++++IBAN FI5158410220025201 For SEPA credit transfers, the creditor s account number is always given in the IBAN format 281 01 ++UltmtCdtr 'Ultimate creditor' is passed on for SEPA credit transfers 281 01 +++Nm Name of ultimate creditor 281 01 +++Id 281 11 ++++OrgId Company ID for ultimate creditor {Or 281 11 ++++PrvtId Personal ID for ultimate creditor Or} 285 01 ++InstrForDbt ragt Instructions for the debtor s bank The only instruction code currently in use for SEPA credit transfers: [EIOHJ] no instruction 286 01 ++Purp Purpose of payment 287 11 +++Cd SALA 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) PENS (PensionPayment)

32/104 BENE (UnemploymentDisabilityBenefit) SSBE (SocialSecurityBenefit) AGRT (Agricultural Payment) SALA (Salary) TAXS (TaxPayment) If the Category Purpose field (Index 215) 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 NB: If the Category Purpose field (index 215) does not contain the code SALA, the code provided is passed on as given 298 01 ++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 NB: 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) Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22) 33/104 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 wwwfklfi 299 01 +++Ustrd Unstructured message to the creditor 2100 0n +++Strd Structured message to the payee; see 298 2101 01 ++++RfrdDocI nf 2102 01 +++++Tp Invoice type 2103 11 ++++++CdOr Prtry 2104 11 +++++++Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice Otherwise, the code (CREN or CINV) is determined by the total bucket (2112 or 2119) in which the amount of the invoice or credit note has been entered 2107 01 +++++Nb 'Invoice number' is not passed on for international payments 2108 01 +++++RltdDt Date of invoice, not in use for the time being 2109 01 ++++RfrdDoc Amt Amount and currency of the invoice or credit note 2112 01 +++++CdtNot Credit note amount eamt +++++CdtNot Currency of credit note eamt 'Ccy' 2119 01 +++++RmtdA mt Invoice amount If the invoice type is CINV or some other code (excl CREN), this element is to be used +++++RmtdA Currency of invoice mt 'Ccy' 2120 01 ++++CdtrRefI nf Creditor reference information ie, invoice or credit note reference 2121 01 +++++Tp 2122 11 ++++++CdOr Prtry 2123 11 +++++++Cd If field 2126 contains a domestic or RF reference, the value SCOR is given in this field 2125 01 ++++++Issr Indicator of which standards-based reference number is in use 2126 01 +++++Ref Creditor reference eg, Finnish reference number

34/104 34 International payment payment order 20 1n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information 21 11 +PmtInfId 20110102-123456-01 Mandatory identifier assigned by debtor to identify a payment batch, passed on to the messages for the debtor and account statement Not passed on to the creditor 22 11 +PmtMtd TRF The only code allowed for payment orders is TRF 217 11 +ReqdExctnD t 2011-05-10 The requested execution date mandatory may be, at max, 365 days in the future 219 11 +Dbtr 219 01 ++Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement 219 01 ++PstlAdr 219 01 +++Ctry The country code is mandatory for the debtor s address if an address is given 219 05 +++AdrLine The bank passes on the debtor s address used in the C2B agreement 219 01 X ++Id Debtor ID 219 11 +++OrgId 219 01 ++++Othr 219 11 +++++Id 12345678900 The customer provides the payment identifier, which the bank uses to link the payload to a C2B service agreement ie, checks which customer s payload this is Payment identifier (9-11 char), mandatory datum, not passed on to the creditor 219 01 +++++Schme Nm 219 11 ++++++Cd BANK The 'BANK' value indicates that a payment identifier is provided in the 'Id' field 220 11 +DbtrAcct Mandatory 220 11 ++Id 220 11 {Or +++IBAN FI2550001520322972 The debit account in OP-Pohjola Group must always be in the IBAN format Also when the debit account is an account at Pohjola Bank Estonia, Latvia or Lithuania 220 11 +++Othr Or} 220 11 ++++Id A debit account with a bank other than the OP- Pohjola Group can be presented as BBAN (letters and numbers) or in proprietary format (letters, numbers and punctuation marks) 220 01 ++Ccy Currency of the debit account 221 11 +DbtrAgt Information of debtor's bank 221 11 ++ FinInstnId 221 01 +++BIC OKOYFIHH BIC code for debtor s bank 223 01 +UltmtDbtr Original debtor 223 01 ++Nm The name of the original debtor is passed on by

35/104 a SWIFT MT103 message to the message field (field 70), preceded by B/O ( By order of ) 224 01 +ChrgBr 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 The codes allowed are SHAR, DEBT, and CRED For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR 227 1n +CdtTrfTxInf Credit transfer At least one block of this kind is required transaction information 228 11 ++PmtId Mandatory payment identification 229 01 +++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 230 11 +++EndToEn did 9834454645554699 Mandatory end-to-end reference, 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 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 ) 231 01 ++PmtTpInf Payment type information for the bank 232 01 +++InstrPrty NORM The only code allowed for payment orders is NORM The information is primarily retrieved from this element If this element has no value, the value in element 27 (if any) is used for the transaction 242 11 ++Amt Amount instructed 243 11 +++InstdAmt 25090 Amount payable {Or 243 11 +++InstdAmt USD Currency of the amount instructed attribute 'Ccy' 244 11 Or} +++EqvtAmt Information on the amount of the counter-value payment 245 11 +++Amt 250000 Amount payable in the currency of the debit account (EUR) 245 11 +++InstdAmt attribute 'Ccy' EUR Currency of debit transaction, always EUR 246 11 ++++CcyOfTrf Currency of payment transaction, other than the currency of debit account 247 01 ++XchgRateIn Exchange rate information

36/104 f 250 01 +++CtrctId Currency exchange deal number ie, rate reference, which is used only in international payments 251 01 ++ChrgBr SHAR The charge bearer code is determined primarily at transaction level The codes allowed are SHAR, DEBT, and CRED For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR 270 01 ++UltmtDbtr Original debtor This data can also be provided at 'PaymentInformation' level in field 223 If both fields 223 and 270 contain data, the data in field 270 is observed 270 01 +++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 ) 277 01 ++CdtrAgt 277 11 +++FinInstnId 277 01 ++++BIC IRVTUS3N BIC code for creditor s bank 277 01 ++++ClrSysM Clearing code mbid 277 11 +++++MmbId 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 277 01 ++++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 277 01 ++++PstlAdr 277 01 +++++Ctry The country code of creditor's bank is mandatory if an address is given 277 05 +++++AdrLine 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 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Ewing Oil Creditor s name is mandatory 279 01 +++PstlAdr Creditor s postal address 279 01 ++++Ctry US Creditor s country code is mandatory if the creditor s address is given 279 04 ++++AdrLine 5th Avenue In international payments, the creditor's address is mandatory Dallas TEXAS 1234 USA 280 01 ++CdtrAcct Account number is mandatory for payment

37/104 orders 280 11 +++Id 280 11 ++++IBAN In international payments, the account number can also be provided as IBAN 280 11 ++++Othr 280 11 +++++Id 9876543210 In international payments, the account number can also be provided in a format other than IBAN 282 02 ++InstrForCdt ragt Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed 283 01 +++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 284 01 +++InstrInf Further instructions for the foreign bank, max 285 01 ++InstrForDbt ragt 140 characters Instructions for the debtor s bank Only used for special payment methods requiring a separate agreement 298 01 ++RmtInf Message or reference for the creditor 299 01 +++Ustrd Invoice 5656 Unstructured message to the creditor 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 (230) is placed at the beginning of the message field If provided in the payload, Ref (2126) and UltmtDbtr/Nm (223 and 270) are also used This information decreases the number of characters available for the open-ended message 2100 0n +++Strd Structured message to the payee; see 298 2101 01 ++++RfrdDocI nf 2102 01 +++++Tp Invoice type 2103 11 ++++++CdOr Prtry 2104 11 +++++++Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice Otherwise, the code (CREN or CINV) is determined by the total bucket (2112 or 2119) in which the amount of the invoice or credit note has been entered 2109 01 ++++RfrdDoc Amount and currency of the invoice or credit

38/104 Amt 2112 01 +++++CdtNot eamt +++++CdtNot eamt 'Ccy' 2119 01 +++++RmtdA mt +++++RmtdA mt 'Ccy' 2120 01 ++++CdtrRefI nf note Credit note amount Currency of credit note Invoice amount If the invoice type is CINV or some other code (excl CREN), this element is to be used 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 Currency of invoice Creditor reference information ie, invoice or credit note reference 2121 01 +++++Tp 2122 11 ++++++CdOr Prtry 2123 11 +++++++Cd If field 2126 contains a domestic or RF reference, the value SCOR is given in this field 2125 01 ++++++Issr Indicator of which standards-based reference number is in use 2126 01 +++++Ref Creditor reference eg, Finnish reference number The information is conveyed to the message field (field 70) by a SWIFT MT 103 message 35 International payment urgent payment order 227 1n +CdtTrfTxInf Credit transfer At least one block of this kind is required transaction information 228 11 ++PmtId Mandatory payment identification 229 01 +++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 230 11 +++EndToEn did 9834454645554699 Mandatory end-to-end reference, 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 ) 231 01 ++PmtTpInf Payment type information for the bank 232 01 +++InstrPrty HIGH The only code allowed for urgent international payment orders is HIGH HIGH processed by

39/104 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 The information is primarily retrieved from this element If this element has no value, the value in element 27 (if any) at 'Payment Information' level is used for the transaction 242 11 ++Amt As mandatory information, the amount payable 243 11 +++InstdAmt 29010 Amount payable {Or 243 11 +++InstdAmt INR Currency of the amount instructed attribute 'Ccy' 244 11 Or} +++EqvtAmt Information on the amount of the counter-value payment 245 11 +++Amt 250000 Amount payable in the currency of the debit account 245 11 ++++EqvtAmt attribuutti EUR Currency of amount payable 'Ccy' 246 11 ++++CcyOfTrf Currency of payment transaction, other than the currency of debit account 247 01 ++XchgRateIn Exchange rate information f 250 01 +++CtrctId Currency exchange deal number ie, rate reference, which is used only in international payments 251 01 ++ChrgBr SHAR The charge bearer code is determined primarily at transaction level The codes allowed are SHAR, DEBT, and CRED For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR 270 01 ++UltmtDbtr Original debtor This data can also be provided at 'PaymentInformation' level in field 223 If both fields 223 and 270 contain data, the data in field 270 is observed 270 01 +++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 ) 277 01 ++CdtrAgt 277 11 +++FinInstnId 277 01 ++++BIC SBININBB104 BIC code for creditor s bank 277 01 ++++ClrSysM Clearing code mbid 277 11 +++++MmbId 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

40/104 code 277 01 ++++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 277 01 ++++PstlAdr 277 01 +++++Ctry The country code of creditor's bank is mandatory if an address is given 277 05 +++++AdrLine 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 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Indi As Creditor s name is mandatory 279 01 +++PstlAdr Creditor s postal address 279 01 ++++Ctry IN Creditor s country code is mandatory if the creditor s address is given 279 04 ++++AdrLine Indian Street 3 In international payments, the creditor's address is mandatory Indiala Kalkuta INDIA 280 01 ++CdtrAcct Account number is mandatory for urgent payment orders 280 11 +++Id 280 11 ++++IBAN In international payments, the account number can also be provided as IBAN 280 11 ++++Othr 280 11 +++++Id C-310312345 In international payments, the account number can also be provided in a format other than IBAN 282 02 ++InstrForCdt ragt Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed 283 01 +++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 284 01 +++InstrInf Further instructions for the foreign bank, max 285 01 ++InstrForDbt ragt 140 characters Instructions for the debtor s bank Only used for special payment methods requiring a separate agreement 298 01 ++RmtInf Message or reference for the creditor 299 01 +++Ustrd Payment number 678 5 carpets Unstructured message to the creditor 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

41/104 field (field 70) by a SWIFT MT 103 message It should be noted also that EndToEndId (230) is placed at the beginning of the message field If provided in the payload, Ref (2126) and UltmtDbtr/Nm (223 and 270) are also used This information decreases the number of characters available for the open-ended message 2100 0n +++Strd Structured message to the payee; see 298 2101 01 ++++RfrdDocI nf 2102 01 +++++Tp Invoice type 2103 11 ++++++CdOr Prtry 2104 11 +++++++Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice 2109 01 ++++RfrdDoc Amt 2112 01 +++++CdtNot eamt +++++CdtNot eamt 'Ccy' 2119 01 +++++RmtdA mt +++++RmtdA mt 'Ccy' 2120 01 ++++CdtrRefI nf Otherwise, the code (CREN or CINV) is determined by the total bucket (2112 or 2119) in which the amount of the invoice or credit note has been entered Amount and currency of the invoice or credit note Credit note amount Currency of credit note Invoice amount If the invoice type is CINV or some other code (excl CREN), this element is to be used 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 Currency of invoice Creditor reference information ie, invoice or credit note reference 2121 01 +++++Tp 2122 11 ++++++CdOr Prtry 2123 11 +++++++Cd If field 2126 contains a domestic or RF reference, the value SCOR is given in this field 2125 01 ++++++Issr Indicator of which standards-based reference number is in use 2126 01 +++++Ref Creditor reference eg, Finnish reference number The information is conveyed to the message field (field 70) by a SWIFT MT 103 message

36 International payment SWIFT cheque 42/104 227 1n +CdtTrfTxInf Credit transfer At least one block of this kind is required transaction information 228 11 ++PmtId Mandatory payment identification 229 01 +++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 230 11 +++EndToEn did 9834454645554699 Mandatory end-to-end reference, 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 ) 231 01 ++PmtTpInf Payment type information for the bank 232 01 +++InstrPrty NORM The only code allowed for SWIFT cheques is NORM The information is primarily retrieved from this element If this element has no value, the value in element 27 (if any) is used for the transaction 242 11 ++Amt Amount instructed 243 11 +++InstdAmt 15000 Amount payable 243 11 +++InstdAmt attribute 'Ccy' USD Payment currency, the possible currencies on SWIFT cheques are: EUR, USD and GBP 247 01 ++XchgRateIn Exchange rate information f 250 01 +++CtrctId Currency exchange deal number ie, rate reference, which is used only in international payments 251 01 ++ChrgBr SHAR The charge bearer code is determined primarily at transaction level For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR 252 01 ++ChqInstr 253 01 +++ChqTp For foreign-currency cheques, a field with the value BCHQ The values CCCH, CCHQ, DRFT, and ELDR are changed to BCHQ The CHK value in element 22 instructs that the credit transfer be processed as a cheque Cheque information is primarily checked from element 253 If this element is empty and element 22 contains the value CHK, the value used for this element is BCHQ

43/104 258 01 +++DlvryMtd Cheque delivery method 260 11 ++++Prtry SWIFT For a SWIFT cheque, a field with the mandatory value SWIFT 270 01 ++UltmtDbtr Original debtor This data can also be provided at 'PaymentInformation' level in field 223 If both fields 223 and 270 contain data, the data in field 270 is observed 270 01 +++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 ) 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Hotel Ahmed Creditor s name is mandatory 279 01 +++PstlAdr Creditor s postal address 279 01 ++++Ctry TR Creditor s country code is mandatory if the creditor s address is given 279 04 ++++AdrLine Ata 7 In international payments, the creditor's address is mandatory Istanbul TURKEY 282 02 ++InstrForCdt ragt Instructions for the creditor agent / creditor bank are passed on for international payments The first two instructions are observed 283 01 +++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 284 01 +++InstrInf Further instructions for the foreign bank, max 285 01 ++InstrForDbt ragt 140 characters Instructions for the debtor s bank Not in use for SWIFT cheques 298 01 ++RmtInf Message or reference for the creditor 299 01 +++Ustrd Reservation 7878799 Unstructured message to the creditor 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 (230) is placed at the beginning of the message field If provided in the payload, Ref (2126) and UltmtDbtr/Nm (223 and 270) are also used This information decreases the number of characters available for the open-ended message 2100 0n +++Strd Structured message to the payee; see 298 2101 01 ++++RfrdDocI nf 2102 01 +++++Tp Invoice type 2103 11 ++++++CdOr Prtry

44/104 2104 11 +++++++Cd Used only if the amount has not been given CREN = credit note CINV or other code = invoice 2109 01 ++++RfrdDoc Amt 2112 01 +++++CdtNot eamt +++++CdtNot eamt 'Ccy' 2119 01 +++++RmtdA mt +++++RmtdA mt 'Ccy' 2120 01 ++++CdtrRefI nf Otherwise, the code (CREN or CINV) is determined by the total bucket (2112 or 2119) in which the amount of the invoice or credit note has been entered Amount and currency of the invoice or credit note Credit note amount Currency of credit note Invoice amount If the invoice type is CINV or some other code (excl CREN), this element is to be used 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 Currency of invoice Creditor reference information ie, invoice or credit note reference 2121 01 +++++Tp 2122 11 ++++++CdOr Prtry 2123 11 +++++++Cd If field 2126 contains a domestic or RF reference, the value SCOR is given in this field 2125 01 ++++++Issr Indicator of which standards-based reference number is in use 2126 01 +++++Ref Creditor reference eg, Finnish reference number The information is conveyed to the message field (field 70) by a SWIFT MT 103 message 37 International payment international payment instruction Index Qty Man dato ry* (=X) Element Example content of international payment instruction Description 20 1n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information 21 11 +PmtInfId 20110102-123456-01 Mandatory identifier assigned by debtor to identify a payment batch, passed on to the messages for the debtor and account

45/104 statement Not passed on to the creditor 22 11 +PmtMtd TRF TRF or TRA allowed 26 01 +PmtTpInf Not mandatory 27 01 ++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 payment order; does not require that the creditor s bank process the transfer as an urgent payment order 217 11 +ReqdExctnD t The information is primarily retrieved from element 232 If it is empty, the information contained in this element (if any) is used for the transaction 2011-05-10 The requested execution date mandatory may be, at max, 365 days in the future 219 11 +Dbtr Mandatory debtor information 219 01 ++Nm Firma Co The bank passes on the debtor s name used in the C2B agreement 219 01 ++PstlAdr 219 01 +++Ctry The country code is mandatory for the debtor s address if an address is given 219 05 +++AdrLine The bank passes on the debtor s address used in the C2B agreement 219 01 X ++Id Debtor ID 219 11 +++OrgId 219 02 ++++Othr 219 11 +++++Id 12345678900 The customer provides the payment identifier, which the bank uses to link the payload to a C2B service agreement ie, checks which customer s payload this is 219 01 +++++Schme Nm 219 11 {Or 220 11 +DbtrAcct Mandatory Payment identifier (9-11 char), mandatory datum, not passed on to the creditor ++++++Cd BANK The 'BANK' value indicates that a payment identifier is provided in the 'Id' field 220 11 ++Id 220 11 +++IBAN AT611904300234573201 The debit account can be entered as IBAN {Or 220 11 +++Othr Or} 220 11 ++++Id The debit account can also be provided as BBAN (numbers and letters) or in a proprietary format (letters, numbers and punctuation marks)

46/104 220 01 ++Ccy EUR Currency of the debit account 221 11 +DbtrAgt Debtor s bank information, mandatory 221 11 ++ FinInstnId 221 01 +++BIC BKAUATWW BIC 224 01 +ChrgBr SHAR 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 227 1n +CdtTrfTxI nf Credit transfer transaction information The codes allowed are SHAR, DEBT, and CRED Code values SLEV and TYHJÄ (empty) are changed to SHAR At least one block of this kind is required 228 11 ++PmtId Mandatory payment identification 230 11 +++EndToEn 9834454645554699 The reference of the IPI is conveyed in this did element 231 01 ++PmtTpInf Payment type information for the bank 232 01 +++InstrPrty NORM NORM or HIGH allowed The information is primarily retrieved from this element If this element has no value, the value in element 27 (if any) is used for the transaction 242 11 ++Amt Amount instructed 243 11 +++InstdAmt 4500000 Amount payable 243 11 +++InstdAmt EUR Currency of the amount instructed attribute 'Ccy' 247 01 ++XchgRateIn Exchange rate information f 250 01 +++CtrctId Currency exchange deal number ie, rate reference, which is used only in international payments 251 01 ++ChrgBr SHAR The charge bearer code is determined primarily at transaction level The codes allowed are SHAR, DEBT, and CRED Code values SLEV and TYHJÄ (empty) are changed to SHAR 277 01 ++CdtrAgt 277 11 +++FinInstnId 277 01 ++++BIC OKOYFIHH BIC code for creditor s bank 277 01 ++++ClrSysM Clearing code mbid 277 11 +++++MmbId The clearing code of the creditor s bank can be given 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

47/104 are mandatory in connection with a clearing code 277 01 ++++Nm The name of the creditor s bank is mandatory if a BIC code is not provided 277 01 ++++PstlAdr 277 01 +++++Ctry The country code of creditor's bank is mandatory if an address is given 277 05 +++++AdrLine The name of the creditor s bank is mandatory if a BIC code is not provided 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Firma Oy Creditor s name is mandatory 279 01 +++PstlAdr Creditor s postal address 279 01 ++++Ctry FI Creditor s country code is mandatory 279 04 ++++AdrLine Teollisuuskatu 1 Creditor's address is mandatory 00550 Helsinki FINLAND 280 01 ++CdtrAcct Account number is mandatory 280 11 +++Id 280 11 ++++IBAN FI2550001520322972 Account number can be entered as IBAN 280 11 ++++Othr 280 11 +++++Id The account number can also be provided in a format other than IBAN 285 01 ++InstrForDbt ragt Instructions for the debtor s bank Not in use for international orders 298 01 ++RmtInf Message or reference for the creditor 299 01 +++Ustrd Invoice 5656 Unstructured message to the creditor 2100 0n +++Strd Reference for the creditor 2120 01 ++++CdtrRefI nf 2126 01 +++++Ref Reference 38 Real-time C2B urgent payment 381 File type of real-time C2B urgent payment The real-time C2B urgent payment initiation message is an international ISO 20022 message in XML format The schema for the payload sent to the bank is pain00100103xsd, and the schema for the payload generated for bank's immediate response is pain00200103xsd The real-time C2B urgent payment uses the 'uploadfile' operation: a request file is uploaded to the Web Services channel in the 'ApplicationRequestcontent' element The 'ApplicationRequestfileType is 'pain00100102 TP4 PS01 Notwithstanding the 'ResponseCode' value of the application request response, the response provided in the 'ApplicationResponsecontent' 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

48/104 382 Example message of a real-time C2B urgent payment Index Qty Manda Element Example content Description tory* (=X) 10 11 GrpHdr Each message must contain at least one block of this kind that contains common information for the message 11 11 +MsgId 20110901-0000001 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 12 11 +CreDtTm 2011-09- 20T07:32:34834+03:00 16 11 +NbOfTxs 1 The number of individual transactions, or CdtTrfTxInf transactions, included in the message by the debtor, mandatory; Bank will not check the information given 17 01 +CtrlSum 150 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 18 11 +InitgPty 18 01 ++Nm Firma Oy Name of message creator 18 01 ++PstlAdr Postal address of message creator 18 01 +++Ctry FI Mandatory if AdrLine is given: Country code under ISO 3166, according to Alpha- 2 18 02 +++AdrLine Teollisuuskatu 1 00550 Helsinki Street address Postal address 20 1n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information 21 11 +PmtInfId 20110920-123456-01 Mandatory identifier assigned by debtor to identify a payment batch, passed on to the messages for the debtor and account statement Not passed on to the creditor 22 11 +PmtMtd TRF The only code allowed for urgent payments is TRF 26 01 +PmtTpInf Not mandatory 27 01 ++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

49/104 28 01 ++SvcLvl Service Level 29 11 {Or +++Cd URGP The only code allowed for urgent payments is URGP FK_ISO20022_Payments_guidepdf 214 01 ++CtgyPurp 215 11 +++Cd Purpose of payment code, not mandatory 217 11 +ReqdExctnDt 2011-09-20 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 219 11 +Dbtr Mandatory debtor information 219 215 219 219 219 219 219 219 219 01 ++Nm Firma Oy The bank passes on the debtor s name used in the C2B agreement 01 ++PstlAdr 01 +++Ctry FI The country code is mandatory for the debtor s address if an address is given 05 +++AdrLine Teollisuuskatu 1 The bank passes on the debtor s address 00550 Helsinki used in the C2B agreement 01 X ++Id Debtor ID 11 +++OrgId 01 ++++BICOrBE I 02 ++++Othr In urgent payments, also the BIC or BEI code provided in addition to the payment identifier 11 +++++Id 12345678900 The customer provides the payment identifier, which the bank uses to link the payload to a C2B service agreement ie, checks which customer s payload this is Payment identifier (9-11 char), mandatory datum, not passed on to the creditor 219 01 +++++Schme Nm 219 11 {Or 219 11 {Or ++++++Cd BANK The 'BANK' value indicates that a payment identifier is provided in the 'Id' field ++++++Prtry This indicates another type of company ID that may be provided in addition to the payment identifier, such as a "Business ID" 220 11 +DbtrAcct Mandatory 220 11 ++Id 220 11 {Or +++IBAN FI2550001520322972 The debit account in OP-Pohjola Group must always be in the IBAN format 220 11 +++Othr Or} 220 11 ++++Id A debit account with a bank other than the OP-Pohjola Group can be presented as BBAN (letters and numbers) or in proprietary format (letters, numbers and punctuation marks) For urgent payments, it is not possible to give an account number in the BBAN or

50/104 proprietary format 220 01 ++Ccy EUR Currency of the debit account 221 11 +DbtrAgt Debtor s bank information, mandatory 221 11 ++ FinInstnId 221 01 +++BIC OKOYFIHH BIC code for debtor s bank 223 01 +UltmtDbtr Original debtor This data can also be conveyed at level C in field 270 If both fields 223 and 270 contain data, the data in field 270 is observed 223 01 ++Nm Name of original debtor 223 01 ++Id 223 11 +++OrgId {Or 223 01 ++++BICOrBE BIC or BEI code of the original debtor I 223 01 ++++Othr 223 11 +++++Id Company ID of the original debtor 223 11 +++PrvtId Or} 223 01 ++++Othr 223 11 +++++Id Personal ID of the original debtor 224 01 +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 227 1n +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) 228 11 ++PmtId Mandatory payment identification 229 01 +++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 230 11 +++EndToEnd Id 9834454645554699 Mandatory end-to-end reference, 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 231 01 ++PmtTpInf Payment type information for the bank 232 01 ++InstrPrty Urgency of payment the codes allowed

51/104 233 01 +++SvcLvl Service Level 234 11 {Or 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 27 (if any) is used for the transaction +++Cd URGP The only code allowed for urgent payments is URGP 242 11 ++Amt As mandatory information, the amount payable 243 11 +++InstdAmt 10000 Amount payable 243 11 +++InstdAmt EUR Currency of the amount instructed attribute 'Ccy' 251 01 ++ChrgBr SLEV The charge bearer code is determined primarily at transaction level In urgent payments, the charge bearer code must be SLEV 270 01 ++UltmtDbtr Original debtor This data can also be conveyed at the 'Payment Information' hierarchy level in field 223 If both fields 223 and 270 contain data, the data in field 270 is observed 270 01 +++Nm Name of original debtor 270 01 +++Id 270 11 ++++OrgId 270 01 +++++BICOrB BIC or BEI code of the original debtor EI 270 01 +++++Othr 270 11 ++++++Id Company ID of the original debtor 270 11 ++++PrvtId {Or 270 01 +++++Othr 270 11 ++++++Id Personal ID of the original debtor 277 01 ++CdtrAgt 277 11 X +++FinInstnId 277 01 ++++BIC NDEAFIHH The BIC code of the creditor s bank is mandatory for urgent payments 279 01 X ++Cdtr Creditor s name and address 279 01 X +++Nm Company Ltd Creditor s name is mandatory

52/104 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 01 +++PstlAdr Creditor s postal address 01 ++++Ctry FI Creditor s country code is mandatory if the creditor s address is given 04 ++++AdrLine Mannerheimintie 1 In urgent payments, address datum is not mandatory but recommended Max two (2) address lines ++++AdrLine FI-00100 Helsinki 01 +++Id Creditor ID 11 ++++OrgId {Or 01 +++++BICOrB EI 01 +++++Othr BIC or BEI 11 ++++++Id Creditor company ID 01 ++++++Schme Nm 11 +++++++Cd {{Or 11 +++++++Prtry Or}} 11 ++++PrvtId Or} 01 +++++Othr 11 ++++++Id 01 ++++++Schme Nm 11 +++++++Cd {Or For SEPA payments, the allowed company IDs are: BANK, CUST, DUNS, EMPL, GS1G and TXID Any other company ID values are provided in this element For SEPA payments, the allowed personal IDs are: ARNU, CCPT, CUST, DRLC, EMPL, NIDN, SOSE ja TXID Any other personal ID values are provided in this element 279 11 Or} +++++++Prtry 280 01 X ++CdtrAcct Account number is mandatory for urgent payments 280 11 +++Id 280 11 ++++IBAN FI2112345600000785 For urgent payments, the creditor s account number is always given in the IBAN format 280 11 ++++Othr 280 11 +++++Id In international payments, the account number can also be provided in a format other than IBAN 281 01 ++UltmtCdtr Ultimate creditor This information is included in urgent payments 281 01 +++Nm Name of ultimate creditor 281 01 +++Id ID for ultimate creditor 281 11 ++++OrgId Company ID for ultimate creditor

53/104 {Or 281 11 ++++PrvtId Personal ID for ultimate creditor Or} 298 01 ++RmtInf Message or reference for the creditor 299 01 +++Ustrd Unstructured message to creditor Purpose of urgent payment is provided in this field (max 140 characters) Max 1 occurrence 2100 0n +++Strd Structured message to the payee; see 298 2120 01 ++++CdtrRefIn f Creditor reference information ie, invoice or credit note reference 2121 01 +++++Tp 2122 11 ++++++CdOrP rtry 2123 11 +++++++Cd SCOR If field 2126 contains a domestic or RF reference, the value SCOR is given in this field 2125 01 ++++++Issr Indicator of which standards-based reference number is in use 2126 01 +++++Ref RF0212345614 Creditor reference eg, Finnish reference number 4 Bank C2B response and message description 41 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 42 Report on payload content validation All transactions in the payment message are accepted: o o Message Group Status is ACCP Message 'PaymentInformationStatus' for each batch is ACCP Some batches are rejected and some accepted: o o o Message 'GroupStatus' is PART Message 'PaymentInformationStatus' for each accepted batch is ACCP Message 'PaymentInformationStatus' for each rejected batch is RJCT All batches in the message are rejected: o Message 'GroupStatus' is RJCT

54/104 o Message 'PaymentInformationStatus' for each batch is RJTC Some payments in a batch are rejected: o o o Message 'GroupStatus' is PART Message 'PaymentInformationStatus' for each rejected batch is PART Message 'TransactionStatus' for the rejected credit transfer transaction is RJCT 43 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: 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 920 pm 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 pm 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 Description 11 CstmrPmtStsRpt Message root 10 11 GrpHdr

55/104 11 11 +MsgId Unique ID assigned by the bank to the response payload 12 11 +CreDtTm Creation date and time of response message 20 11 OrgnlGrpInfAndSts 21 11 +OrgnlMsgId Identification from the original pain00100103 message (MsgId) 22 11 +OrgnlMsgNmId Type of original message (pain00100103) +OrgnlCreDtTm Timestamp from the original message s CreDtTm +OrgnlNbOfTxs Number of transactions in the original message 26 01 +GrpSts Payload status code ACSP all batches in the payload have been processed successfully ACCP payload is accepted for processing ACTC technical validation has succeeded 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 27 01 +StsRsnInf More detailed description of status data 29 01 ++Rsn 210 11 +++Cd Rejection reason code 212 01 ++AddtlInf Error description (optional), to provide additional information for the above code 30 0n OrgnlPmtInfAndSts 31 11 +OrgnlPmntInfId Unique batch identifier given by the customer; from the payload field 32 01 +OrgnlNbOfTxs Number of transactions in the batch 33 01 +OrgnlCtrlSum Control sum of the transactions in the batch 34 01 +PmtInfSts Batch status code ACSP batch has been processed successfully ACCP batch is accepted for processing RJCT - batch rejected PART - some transactions in the batch have been processed successfully and some rejected, some transactions are awaiting processing or some transactions are not accepted for processing 35 01 +StsRsnInf 37 01 ++Rsn 38 11 +++Cd Rejection reason code 310 01 ++AddtlInf Error description (optional), to provide additional information for the above code 311 0n +NbOfTxsPerSts 312 11 ++DtldNbOfTxs Status code-specific number of transactions 313 11 ++DtldSts Status code 314 01 ++DtldCtrlSum Status code-specific control sum of transactions 315 0n +TxInfAndSts Status of individual payments 317 01 ++OrgnlInstrId Unique payment identifier given by the customer; from the 'InstrId' field of the pain00100103 message 318 01 ++OrgnlEndToEndId From the 'EndToEndId' field of the pain00100103 message 319 01 ++TxSts Transaction status code RJCT - transaction rejected PDNG transaction awaiting processing 320 01 ++StsRsnInf 322 01 +++Rsn 323 11 ++++Cd Rejection reason code 325 01 +++AddtlInf Error description (optional), to provide additional

56/104 information for the above code 332 01 ++OrgnlTxRef 334 01 +++Amt 335 11 ++++InstdAmt Transaction amount 341 01 +++ReqdExctnDt Requested execution date +++UltmtDbtr Original debtor ++++Nm Name +++Dbtr Debtor ++++Nm Name 3122 01 +++DbtrAcct Debtor s account 3122 11 ++++Id 3122 11 +++++IBAN Account number in IBAN format 3122 11 +++++Othr Account number in other than IBAN format +++Cdtr Creditor ++++Nm Name 3128 01 +++CdtrAcct Creditor s account 3128 11 ++++Id 3128 11 +++++IBAN Account number in IBAN format 3128 11 +++++Othr Account number in other than IBAN format +++UltmtCdtr Ultimate creditor ++++Nm Name 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) NARR Debit account not possible at the moment Debit account not possible at the moment NARR Payer's account may not be a foreign bank's Payer's account may not be a foreign bank's account account NARR Incorrect delivery method Incorrect delivery method NARR Incorrect payee bank's clearing code Incorrect payee bank's clearing code 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

57/104 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 NARR Incorrect payee information Incorrect payee information NARR Double payment Duplicate 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 44 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 10 GroupHeader <GrpHdr> [11] Each message contains one GrpHdr element that contains the common information for the message 11 +MessageIdentification <MsgId> [11] 457587587 Unique ID given by the bank to response data 12 +CreationDateTime <CreDtTm> [11] 2011-02- 11T18:12:02+03:00 Message creation timestamp 13 +MessageRecipient <MsgRcpt> [01]

58/104 13 ++Identification <Id> [01] 13 +++OrganisationIdentifica <OrgId> [11] tion 13 ++++Other <Othr> [0n] 13 +++++Identification <Id> [11] 1245678900 Receiver ID 13 +++++SchemaName <SchmeNm> [01] 13 ++++++Code <Cd> [11] BANK 20 Notification <Ntfctn> [1n] Common information for the notification 21 +Identification <Id> [11] 4575875871 Notification identifier 24 +CreationDateTime <CreDtTm> [11] 2011-02- 11T18:00:02+03:00 Creation time of notification by the bank 210 +Account <Acct> [11] 210 ++Id <Id> [11] 210 +++IBAN <IBAN> [11] FI25500015203229 72 Debtor s account in IBAN format 210 +++Other <Othr> [11] 210 ++++Identification <Id> [11] Debtor s account in other than IBAN format 1211 ++Currency <Ccy> [01] EUR Currency of the debtor's account 210 +Servicer <Svcr> [01] 210 ++FinancialInstitutionIden <FinInstnId> [11] tification 210 +++BIC <BIC> [01] OKOYFIHH Bank issuing the message 256 +Entry <Ntry> [0n] 11 Common information for processed transactions In practice, there is always only one Entry level 258 ++Amount <Amt> [11] 250 Amount for processed transactions 258 <CCy> [11] XXX Currency for processed transactions Because the amount may be composed of transactions in different currencies, the currency code value used is XXX 259 ++CreditDebitIndicator <CdtDbtInd> [11] DBIT Indicator that this is a debit tranaction 261 ++Status <Sts> [11] BOOK The status of transactions in a notification is always BOOK 262 ++BookingDate <BookgDt> [01] 262 +++Date <Dt> [11] 2011-11-02 Payment date 264 ++AccountServicerRefere nce <AcctSvcrRef> [01] Transaction identifier for a bundled SEPA credit transfer transaction 271 ++BankTransactionCode <BkTxCd> [11] 277 +++Proprietary <Prtry> [01] 278 ++++Code <Cd> [11] Debiting Standard text 2115 ++Entry Details <NtryDtls> [0n] 11 In practice, there is always only one Entry Details level

59/104 2116 +++Batch <Btch> [01] 2118 ++++PaymentInformation Identification <PmtInfId> [01] 20110101-123456- 01 2119 ++++NumberOfTransacti ons The PmtInfId data from the pain001 message <NbOfTxs> [01] Total number of transactions in the original payment batch 2122 +++TransactionDetails <TxDtls> [0n] Details of an individual processed transaction 2123 ++++References <Refs> [01] 2124 +++++MessageIdentificati on <MsgId> [01] Contents of MsgId data in Pain001 message 2125 +++++AccountServicerRe <AcctSvcrRef> [01] Archive ID ference 2127 +++++InstructionIdentific ation <InstrId> [01] Contents of InstrId data in Pain001 message 2128 +++++EndToEndIdentific ation <EndToEndId> [01] 983445464555469 9 Contents of EndToEndId data in Pain001 message 2136 ++++AmountDetails <AmtDtls> [01] Amount details for the transaction 2136 +++++InstructedAmount <InstdAmt> [01] 2136 ++++++Amount <Amt> [01] USD 1328,80 Amount payable in the currency specified by the customer, Ccy the same as SourceCurrency 2136 ++++++CurrencyExchang <CcyXchg> [01] Exchange rate information e 2136 ++++++SourceCurrency <SsrCcy> [11] USD Currency of the amount instructed 2136 +++++++TargetCurrency <TrgtCcy> [01] EUR Always EUR 2136 +++++++UnitCurrency <UnitCcy> [01] EUR Always EUR 2136 +++++++ExchangeRate <XchgRate> [11] 1328800 Exchange rate 2136 +++++++ContractIdentific ation <CtrctId> [01] Foreign exchange trading reference 2136 +++++TransactionAmoun <TxAmt> [01] t 2136 ++++++Amount <Amt> Attribute Ccy [11] EUR 1000,00 Amount to be debited in the customer's account currency, Ccy the same as TargetCurrency 2136 ++++++CurrencyExchang <CcyXchg> [01] Exchange rate information e 2136 +++++++SourceCurrency <ScrCcy> [11] EUR Always EUR 2136 +++++++TargetCurrency <TrgtCcy> [01] EUR Currency of the debit account 2136 +++++++UnitCurrency <UnitCcy> [01] EUR Currency of the debit account 2136 +++++++ExchangeRate <XchgRate> [11] 1000000 Exchange rate 2136 +++++++ContractIdentific ation <CtrctId> [01] Foreign exchange trading reference 2136 +++++CounterValueAmo <CntrValAmt> [01] unt 2136 ++++++Amount <Amt> Attribute Ccy [11] EUR 132880 Counter value always in EUR 2136 ++++++CurrencyExchang <CcyXchg> [01] Exchange rate

60/104 e information 2136 +++++++SourceCurrency <ScrCcy> [11] EUR Always EUR 2136 +++++++TargetCurrency <TrgtCcy> [01] EUR Always EUR 2136 +++++++UnitCurrency <UnitCcy> [01] EUR Always EUR 2136 +++++++ExchangeRate <XchgRate> [11] 1000000 Exchange rate constant 1000000 2136 +++++++QuotationDate <QtnDt> [01] 2011-02- 11T14:12:02+03:00 Time of currency conversion 2152 ++++Charges <Chrgs> [0n] 2154 +++++Amount <Amt> [11] 000 Always 000 2160 +++++Bearer <Br> [01] SHAR Charge bearer code 2179 ++++RelatedParties <RltdPties> [01] Payment parties 2181 +++++Debtor <Dbtr> [01] 2181 ++++++Name <Nm> [01] Firma Oy Name of the Debtor 2181 ++++++Identification <Id> [01] Debtor s identification data 2181 +++++++OrganisationIde <OrgId> [11] ntification 2181 ++++++++Other <Othr> [0n] 2181 +++++++++Identification <Id> [11] 12345678900 Debtor ID 2183 +++++UltimateDebtor <UltmtDbtr> [01] 2183 ++++++Name <Nm> [01] Name of original debtor 2184 +++++Creditor <Cdtr> [01] 2184 ++++++Name <Nm> [01] Ewing Oil Creditor's name 2184 ++++++PostalAddress <PstlAdr> [01] 2184 +++++++Country <Ctry> [01] US Country code of creditor's bank 2184 +++++++AddressLine <AdrLine> [07] 5th Avenue Creditor s address 2184 +++++++AddressLine <AdrLine> Dallas 2184 +++++++AddressLine <AdrLine> TEXAS 1234 2184 +++++++AddressLine <AdrLine> USA 2184 ++++++Identification <Id> [01] Creditor s identification data 2184 +++++++Organisation <OrgId> [11] Identification 2184 ++++++++BICOrBEI <BICOrBEI> [01] BIC or BEI 2184 ++++++++Other <Othr> [0n] 2184 +++++++++Identification <Id> [11] Corporate customer s ID 2184 +++++++PrivateIdentificat <PrvtId> [11] ion 2184 ++++++++Other <Othr> [0n] 2184 +++++++++Identification [11] Private customer s ID

61/104 2185 +++++CreditorAccount <CdtrAcct> [01] 2185 ++++++Identification <Id> [11] 2185 +++++++IBAN <IBAN> [11] Creditor s account in IBAN format 2185 2185 +++++++Other <Othr> [11] ++++++++Identification <Id> [11] 9876543210 Creditor s non-iban account 2186 +++++UltimateCreditor <UltmtCdtr> [01] 2186 ++++++Name <Nm> [01] Name of ultimate creditor (not used in international payments) 2191 ++++RelatedAgents <RltdAgts> [01] 2193 +++++CreditorAgent <CdtrAgt> [01] Creditor s bank details 2193 ++++++FinancialInstitutio <FinInstnId> [11] nidentification 2193 +++++++BIC <BIC> [01] IRVTUS3N BIC code for creditor s bank 2193 +++++++ClearingSystem <ClrSysMmbId [01] MemberIdentification > 2193 ++++++++MemberIdentifi cation <MmbId> [11] Clearing code for creditor s bank 2193 +++++++Name <Nm> [01] Name of creditor s bank 2193 +++++++PostalAddress <PstlAdr> [01] 2193 ++++++++AddressLine <AdrLine> [07] Address of creditor s bank 2204 ++++Purpose <Purp> [01] Purpose of payment 2205 +++++Code <Cd> [11] Additional information on the purpose of the credit transfer from the debtor to the creditor 2214 ++++RemittanceInformati <RmtInf> [01] on 2215 +++++Unstructured <Ustrd> [0n] Invoice 5656 Unstructured message to the creditor 2216 +++++Structured <Strd> [0n] 09 Structured message to the creditor In practice, there may not be more than nine structured messages 2217 ++++++ReferredDocume <RfrdDocInf> [0n] Credit note information ntinformation 2218 +++++++Type <Tp> [01] 2219 ++++++++CodeOrProprie <CdOrPrtry> [11] tary 2219 +++++++++Code <Cd> [11] RfrdDocInf/RfrdDocTp/Cd information in the Pain001 message that can be either CREN or

62/104 2225 ++++++ReferredDocume ntamount 2228 +++++++CreditNoteAmou nt 2235 +++++++RemittedAmoun t <RfrdDocAmt> [01] CINV <CdtNoteAmt> [01] CdtNoteAmt information content in Pain001 message <RmtdAmt> [01] RmtdAmt information content in Pain001 message <CdtrRefInf> [01] 2236 ++++++CreditorReferenc einformation 2237 +++++++Type <Tp> [01] ++++++++CodeOrProprie <CdOrPrtry> [11] tary 2239 +++++++++Code <Cd> [11] The 'Cd' information from the pain001 message 2242 +++++++Reference <Ref> [01] CdtrRef information content in Pain001 message 2245 ++++++AdditionalRemitta nceinformation 2246 ++++RelatedDates <RltdDts> [01] 2247 +++++AcceptanceDateTi <AccptncDtTm me > <AddtlRntInf> [01] AddtlRmtInf information content in Pain001 message [01] 2011-11-02 Transaction-specific payment date 2250 +++++InterbankSettleme ntdate <IntrBkSttlmDt > This is the same as on batch level in 262 [01] International settlement date 45 Response message to a real-time C2B urgent payment initiation message and the reasons of rejection Index Qty Element Example content Description 11 CstmrPmtStsRp Message root t 10 11 GrpHdr 11 11 +MsgId 1316771523490 Unique ID assigned by the bank to the response payload 12 11 +CreDtTm 2011-09- 23T12:52:03490+03:00 Creation date and time of response message 20 11 OrgnlGrpInfAnd Sts 21 11 +OrgnlMsgId 20110901-0000001 Identification from the original pain00100103 message (MsgId) 22 11 +OrgnlMsgNmId pain00100103 Type of original message (pain00100103) 26 01 +GrpSts ACSP Payload status code ACSP payload processed successfully RJCT - payload rejected PDNG payload status 'Pending' 27 01 +StsRsnInf More detailed description of status data 28 01 ++Orgtr 28 11 +++Id 28 11 ++++OrgId 28 11 +++++Othr

63/104 28 11 ++++++Id WSC username Used only if technical validation fails 29 01 ++Rsn 210 11 +++Cd Rejection reason code For urgent payments, payload-level reason code in use only if technical validation fails 212 01 ++AddtlInf Error description (optional), to provide additional information for the above code 30 0n OrgnlPmtInfAnd Sts 31 11 +OrgnlPmntInfId 20110920-123456-01 Unique batch identifier given by the customer from the payload field 32 01 +OrgnlNbOfTxs 1 Number of transactions in the batch For urgent payments, 1 in all cases 33 01 +OrgnlCtrlSum 1000000 Control sum of the transactions in the batch 34 01 +PmtInfSts ACSP Batch status code ACSP batch has been processed successfully RJCT - batch rejected PDNG batch status 'Pending' 35 01 +StsRsnInf 37 01 ++Rsn 38 11 +++Cd Rejection reason code For urgent payments, batch-level rejection reason code in use if error detected in batch-level or contract information validation check 310 01 ++AddtlInf Error description (optional), to provide additional information for the above code 311 0n +NbOfTxsPerSt s 312 11 ++DtldNbOfTxs 1 Status code-specific number of transactions; for urgent payments, 1 in all cases 313 11 ++DtldSts ACSP Status code 314 01 ++DtldCtrlSum 1000000 Status code-specific control sum of transactions; for urgent payments, the same as the amount of the individual transaction 315 0n +TxInfAndSts Status of individual payments 317 01 ++OrgnlInstrId Unique payment identifier given by the customer; from the 'InstrId' field of the pain00100103 message 318 01 ++OrgnlEndToE ndid 9834454645554699 From the 'EndToEndId' field of the pain00100103 message 319 01 ++TxSts ACSP Transaction status code ACSP payment transaction executed successfully (both debit and credit transactions successful) RJCT - transaction rejected PDNG transaction status 'Pending' 320 01 ++StsRsnInf 322 01 +++Rsn 323 11 ++++Cd Reason code for the 'Rejected' or 'Pending' status For urgent payments, transaction-level reason code in use in the

64/104 following cases: - if error in transaction data detected - if debit or credit transaction fails - if debit or credit transaction is pending 325 01 +++AddtlInf Error description (optional), to provide additional information for the above code 330 01 ++AcctSvcrRef 593728B70003 Transaction identifier, assigned only to successful tranactions 332 01 ++OrgnlTxRef 334 01 +++Amt 335 11 ++++InstdAmt 1000000 Transaction amount 341 01 +++ReqdExctnD 2011-09-19 Requested execution date t 3122 01 +++DbtrAcct Debtor s account 3122 11 ++++Id 3122 11 +++++IBAN FI2550001520322972 Account number in IBAN format 3128 01 +++CdtrAcct Creditor s account 3128 11 ++++Id 3128 11 +++++IBAN FI2112345600000785 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 800 am 430 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 (camt05500101) 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 or by calling the Corporate and Credit Transfer Services, tel +358 100 05151 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 20022 message in XML format The schema for the cancellation request sent to the bank is camt05500101 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

65/104 for the rejection by calling the Corporate and Credit Transfer Services, tel +358 100 05151) or by validating the payload using, for example, the validation service provided by XMLdationcom If mandatory information is missing from a received cancellation request, the customer will receive a single 'camt029' response with no batch or payment level If the entire batch or all individual payments are rejected, the customer will receive a single 'camt029' response If the entire batch or all individual payments are approved, the customer will receive a single 'camt029' response If some of the batches or individual payments are rejected and approved, the customer will receive a single 'camt029' response containing both the rejected and approved payment batches or payments 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 10 Assignment <Assgnmt> [11] Each message has one Assgnmt block that contains the common information for the message 11 +Identification <Id> [11] 45758758743544 Unique ID given by customer to the cancellation request message 12 +Assigner <Assgnmt> [11] Company Ltd Information of the sender of the cancellation request message 13 ++Party <Pty> [11] 151 +++Name <Nm> [01] Name of debtor company

66/104 151 +++Identification <Id> [11] 151 ++++OrganisationIdentific <OrgId> [11] ation 151 +++++Other <Othr> [0n] 151 16 ++++++Identification <Id> [11] Payment identifier; mandatory datum to be provided in element 426 for each batch, or in here, if the cancellation request pertains to an individual initiation message under the payment identifier 151 ++++++SchemeName <SchmeNm> [01] 17 151 +++++++Code <Cd> [11] Value: BANK 18 15 +Assignee <Assgne> [11] 17 ++Agent <Agt> [11] 1210 +++FinancialInstitutionIde <FinInstnId> [11] ntification 1211 ++++BIC [01] OKOYFIHH Receiver of cancellation request; standard value: OKOYFIHH 18 +CreationDateTime <CreDtTm> [11] 2012-12- 17T09:30:47Z Timestamp for message creation time 30 ControlData <CtrlData> [01] 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 31 +NumberOfTransactions <NbOfTxs> [11] Number of transactions to be cancelled 32 +ControlSum <CtrlSum> [01] Total amount of transactions to be cancelled 40 Underlying <Undrlyg> [1n] Information of the transaction underlying the cancellation; one item per message 41 +OriginalGroupInformatio nandcancellation 42 ++GroupCancellationIden tification 49 ++OriginalMessageIdentif ication <OrgnlGrpInfA ndcxl> [01] Elements 49-413 relate to the identification of the original message <GrpCxlId> [01] Identifier assigned by sender to the cancellation request <OrgnlMsgId> [11] Identifier assigned by sender to the original message 410 ++OriginalMessageName identification <OrgnlMsgNmI d> [11] pain0010102 Type and version of the original message sent by customer 411 ++OriginalCreationDateTi <OrgnlCreDtT [01] 2012-12-17T Creation time and date of

67/104 me m> 9:30:47Z the original message sent by customer 412 ++NumberOfTransactions <NbOfTxs> [01] 2 Number of transactions in the original message 413 ++ControlSum <CtrlSum> [01] 123400 Total amount of transactions in the original message 414 ++GroupCancellation <GrpCxl> [01] 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 421 +OriginalPaymentInforma tionandcancellation <OrgnlPmtInfA ndcxl> [0n] The information of at least one batch must be provided (421) Information of the original batch the cancellation of which is requested <PmtCxlId> [01] Identifier of the batch cancellation request 422 ++PaymentCancellationId entification 423 ++Case <Case> [01] Data group must be provided, if no payment identifier is given in element 13 Information is primarily checked from this element 424 +++Identification <Id> [11] 425 +++Creator <Cretr> [11] Information of the creator of the cancellation request 426 ++++Party <Pty> [11] 5112 +++++Identification <Id> [11] 5113 ++++++OrganisationIdent <OrgId> [11] ification 5115 +++++++Other <Othr> [0n] 5116 ++++++++Identification <Id> [11] 12345678900 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 13 5117 +++++++++SchemeNam [01] e 5118 ++++++++++Code [11] Value: BANK 429 ++OriginalPaymentInform ationidentification <OrgnlPmtInfId > [11] The identifier of the original batch sent by customer is mandatory datum to be provided in

68/104 the cancellation request message in all cases 434 ++NumberOfTransactions <NbOfTxs> [01] 2 If provided, this number must correspond to the number of transactions to be cancelled from the batch 435 ++ControlSum <CtrlSum> [01] 123400 If provided, this amount must correspond to the total amount of transactions to be cancelled from the batch 436 ++PaymentInformationCa ncellation <PmtInfCxl> [01] True Cancellation request pertains to the entire batch; information of individual transactions (443) not permitted False Cancellation request pertains to one or multiple individual transactions: information of the individual transactions (443) 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: 451, 4,52, or 61495 443 ++TransactionInformation <TxInf> [0n] Information related to the cancellation of an 444 +++CancellationIdentifica tion 451 +++OriginalInstructionIde ntification 452 +++OriginalEndToEndIde ntification 453 +++OriginalInstructedAm ount 453 +++OriginalInstructedAm ount 454 +++OriginalRequestedEx ecutiondate 462 ++OriginalTransactionRef erence 61 467 61 469 +++RemittanceInformatio n individual payment <CxlId> [01] Identifier for the cancellation of an individual transaction <OrgnlInstrId> [01] Identifier assigned by sender to the original payment <OrgnlEndToE ndid> ++++Structured <Strd> [01] [01] Identifier passed on to creditor in the original payment <OrgnlInstrAmt > [01] 123400 Amount of the original payment <OrgnlInstrAmt [01] EUR Currency code of the > attribuutti original payment Ccy <OrgnlReqdEx [01] Requested execution date ctndt> of the original payment <OrgnlTxRef> [01] Reference information of creditor, debtor, accounts, etc of the payment to be cancelled <RmtInf> [01] Remittance information of the original payment; only one (1) structured element permitted Structured invoice details (=AOS2) rejected upon receipt, not entered to processing

69/104 61 489 61 490 61 491 61 473 61 495 61 626 61 627 61 669 61 670 61 671 61 791 61 792 61 834 61 835 61 836 +++++CreditorReferenceI <CdtrRefInf> [01] nformation ++++++Type <Tp> [01] +++++++CodeOrPropriet <CdOrPrtry> [11] ary ++++++++Code <Cd> [11] Value: SCOR ++++++Reference <Ref> Reference of the original payment transaction +++Debtor <Dbtr> [01] Debtor ++++Name <Nm> [01] +++DebtorAccount <DbtrAcct> [01] ++++Identification <Id> [11] +++++IBAN <IBAN> [11] Debtor's account number in IBAN format +++Creditor <Cdtr> [01] Creditor ++++Name <Nm> [01] Creditor's name +++CreditorAccount <CdtrAcct> [01] ++++Identification <Id> [11] +++++IBAN <IBAN> [11] Creditor's account number in IBAN format 6 Response to C2B cancellation request (camt02900103)

70/104 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 10 Assignment <Assgnmt> [11] Each message has one Assgnmt block that contains the common information for the message 11 +Identification <Id> [11] 45758758743544 Identifier assigned by bank to response message 12 +Assigner <Assgnmt> [11] 14 ++Agent <Agt> [11] 210 +++FinancialInstitutionIde <FinInstnId> [11] ntification 211 ++++BIC <BIC> [01] OKOYFIHH Sender of response message; OKOYFIHH in all cases 15 +Assignee <Assgne> [11] 16 ++Party <Pty> [11] 510 +++Name <Nm> [01] Company Ltd Information of the receiver of response message (= sender of the cancellation request message) 5112 +++Identification <Id> [01] 5113 ++++OrganisationIdentific <OrgId> [11] ation 5115 +++++Other <Othr> [0n] 5116 ++++++Identification <Id> [11] Payment identifier; from element 13 in the cancellation request message 5117 ++++++SchemeName <SchmeNm> [01] 5118 +++++++Code <Cd> [11] Value BANK, if payment identifier is returned in this element 18 +CreationDateTime <CreDtTm> [11] 2001-12- 17T09:30:47Z Message creation timestamp 30 Status <Sts> [11] Processing information for the cancellation message 39 +AssignmentCancellation <AssgnmentCx [11] True Constant value: True Confirmation lconf> 40 CancellationDetails <CxlDtls> [0n] In practice, only one instance of this element is generated 41 +OriginalGroupInformatio nandstatus <OrgnlGrpInfA ndsts> [01] 42 ++OriginalGroupCancella <OrgnlGrpCxlId [01] Identifier of the original

71/104 tionidentification > cancellation request message from element 42 49 ++OriginalMessageIdentif ication 410 ++OriginalMessageName identification 411 ++OriginalCreationDateTi me 412 ++OriginalNumberOfTran sactions <OrgnlMsgId> [11] Identifier of the original payment initiation message from element 49 <OrgnlMsgNmI d> <OrgnlCreDtT m> <OrgnlNbOfTxs > 413 ++OriginalControlSum <OrgnlCtrlSum > 414 ++GroupCancellationStat us 415 ++CancellationStsReaso ninformation [11] pain00100102 Type and version of the original payment initiation message from element 410 in the cancellation request message [01] 2001-12-17T 9:30:47Z Creation time of the original payment initiation message from element 411 in the cancellation request message [01] 2 Number of transactions in the original payment initiation message from element 412 in the cancellation request message [01] 123400 Amount of transactions in the original payment initiation message from element 413 in the cancellation request message <GrpCxlSts> [01] Status options for the cancellation message: ACCR processed successfully PACR processed partially successfully RJCR rejected, not processed <CxlStsRsnInf> [0n] Element included in response message, if the status of cancellation request message is RJCR 417 +++Reason <Rsn> [01] 419 ++++Proprietary <Prtry> [11] Rejection reason code 420 +++AdditionalInformation <AddtlInf> [0n] Additional information provided by bank in the response 425 +OriginalPaymentInforma tionandstatus 426 ++OriginalPaymentInform ationcancellationidentific ation <OrgnlPmtInfA ndsts> <OrgnlPmtInfC xlid> [0n] Processing information of the cancellation request for the original payment batch; to be returned in all cases [01] Identifier of the cancellation request for the original payment batch (element 422 in the cancellation request

72/104 message) 427 ++ResolvedCase <RslvdCase> [01] Information of the original cancellation request message from elements 423 427 428 +++Identification <Id> [11] 429 +++Creator <Cretr> [11] Information of the creator of the original cancellation request 430 ++++Party <Pty> [11] 512 +++++Identification <Id> [01] 5113 ++++++OrganisationIdent <OrgId> [11] ification 5115 +++++++Other <Othr> [0n] 5116 ++++++++Identification <Id> [11] 12345678900 Payment identifier; from element 426 in the original cancellation request message 5117 ++++++++SchemeName <SchmeNm> [01] 5118 ++++++++++Code <Cd> [11] Value BANK, if payment identifier is returned in this element 433 ++OriginalPaymentInform ationidentification <OrgnlPmtInfId > [11] The identifier of the original batch is returned to customer in the format used in the cancellation request message received in element 429 438 ++OriginalNumberOfTran sactions <OrgnlNbOfTxs > [01] 1 Number received in element 434 of the original cancellation request message 439 ++OriginalControlSum <OrgnlCtrlSum > [01] 120000 Amount received in element 435 of the original cancellation request message 440 ++PaymentInformationCa ncellationstatus <PmtInfCxlSts> [01] Status of cancellation request for a batch; values: ACCR processed successfully RJCR rejected 441 ++CancellationStatusRea soninformation NB: This element is empty where individual transactions are cancelled <CxlStsRsnInf> [0n] Reason information for the rejection of a batch if status RJCR 443 +++Reason <Rsn> [01] 445 ++++Proprietary <Prtry> [11] Rejection reason code

73/104 446 +++AdditionalInformation <AddtlInf> [0n] Additional information on rejection reason 451 ++TransactionInformation AndStatus <TxInfAndSts> [0n] Information concerning the cancellation of individual payment 452 +++CancellationStatusIde ntification 459 +++OriginalInstructionIde ntification 460 +++OriginalEndToEndIde ntification 461 +++TransactionCancellati onstatus 462 +++CancellationStatusRe asoninformation transactions <CxlStsId> [01] Identifier for the cancellation of individual transaction from element 444 in the cancellation request message <OrgnlInstrId> [01] Identifier of the original payment initiation message from element 451 <OrgnlEndToE ndid> [01] Identifier of the original payment initiation message from element 452 in the cancellation request message <TxCxlSts> [01] Status of cancellation request for individual transaction; values: ACCR processed successfully RJCR rejected <CxlStsRsnInf> [0n] Reason information for the rejection of individual transaction if status RJCR 464 ++++Reason <Rsn> [01] 465 +++++Proprietary <Prtry> [11] Rejection reason code 467 ++++AdditionalInformatio n <AddtlInf> [0n] Additional information on rejection reason 468 +++OriginalInstructedAm ount <OrgnlInstrAmt > 468 +++OriginalInstructedAm ount 469 +++OriginalRequestedEx ecutiondate 471 +++OriginalTransactionR eference 61 467 61 469 <OrgnlInstrAmt > attribuutti Ccy <OrgnlReqdEx ctndt> [01] 123400 Amount of the original payment from element 453 in the cancellation request message [01] EUR Currency code of the original payment from element 453 of the cancellation request message [01] Requested execution date of the original payment from element 454 in the cancellation request message <OrgnlTxRef> [01] Reference information on the payment transaction cancelle, accounts, etc, from element 462 in the cancellation request message +++RemittanceInformatio <RmtInf> [01] Remittance information of n the original payment ++++Structured <Strd> [01]

74/104 61 489 61 490 61 491 61 473 61 495 61 626 61 627 61 669 61 670 61 671 61 791 61 792 61 834 61 835 61 836 +++++CreditorReferenceI <CdtrRefInf> [01] nformation ++++++Type <Tp> [01] +++++++CodeOrPropriet <CdOrPrtry> [11] ary ++++++++Code <Cd> [11] Value: SCOR ++++++Reference <Ref> Reference of the original payment transaction +++Debtor <Dbtr> [01] Debtor ++++Name <Nm> [01] +++DebtorAccount <DbtrAcct> [01] ++++Identification <Id> [11] +++++IBAN <IBAN> [11] Debtor's account number in IBAN format +++Creditor <Cdtr> [01] Creditor ++++Name <Nm> [01] Creditor's name +++CreditorAccount <CdtrAcct> [01] ++++Identification <Id> [11] +++++IBAN <IBAN> [11] 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

75/104 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 Double 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 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

Message Incomplete message information Incomplete transaction identification information Description Incomplete message information Incomplete transaction identification information 76/104 7 Example messages <CstmrCdtTrfInitn> <GrpHdr> <MsgId>20110102-0000001</MsgId> <CreDtTm>2011-01-12T09:00:01+02:00</CreDtTm> <NbOfTxs>6</NbOfTxs> <CtrlSum>2000000</CtrlSum> <InitgPty> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> </PstlAdr> </InitgPty> </GrpHdr> ------------------------- SEPA payment ------------------------- <PmtInf> <PmtInfId>20110102-123456-01</PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <InstrPrty>NORM</InstrPrty> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> </PmtTpInf> <ReqdExctnDt>2011-05-10</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <Id> <OrgId> <Othr> <Id>12345678900 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Dbtr> <DbtrAcct> <Id> <IBAN>FI2550001520322972</IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <ChrgBr>SLEV</ChrgBr> <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</EndToEndId> </PmtId>

77/104 <Amt> <InstdAmt Ccy="EUR">150</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>GENODEFF</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Warenhaus Köln</Nm> <PstlAdr> <Ctry>DE</Ctry> <AdrLine>Kirchenstrasse 3</AdrLine> <AdrLine>DE-26458 Köln GERMANY</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <IBAN>DE89370400440532013000</IBAN> </CdtrAcct> <RmtInf> <Ustrd>Invoice 123</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> ------------------------------------------------------------- SEPA salary and an individual urgent payment ------------------------------------------------------------- <PmtInf> <PmtInfId>20130814-123456-01</PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <InstrPrty>NORM</InstrPrty> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> <CtgyPurp> <Cd>SALA</Cd> </CtgyPurp> </PmtTpInf> <ReqdExctnDt>2013-08-14</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <Id> <OrgId> <Othr> <Id>12345678900 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Dbtr> <DbtrAcct> <Id> <IBAN>FI2550001520322972</IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <ChrgBr>SLEV</ChrgBr>

78/104 <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</EndToEndId> </PmtId> <Amt> <InstdAmt Ccy="EUR">2000</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Pekka Palkansaaja</Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine>Kotikatu 1</AdrLine> <AdrLine>00100 Helsinki</AdrLine> </PstlAdr> <Id> <PrvtId> <Othr> <Id>010160-777H <SchmeNm> <Cd>SOSE</Cd> </SchmeNm> </Othr> </PrvtId> </Cdtr> <CdtrAcct> <Id> <IBAN>FI5158410220025201</IBAN> </CdtrAcct> <Purp> <Cd>SALA</Cd> </Purp> </CdtTrfTxInf> <CdtTrfTxInf> <PmtId> <EndToEndId>98344546455632</EndToEndId> </PmtId> <PmtTpInf> <SvcLvl> <Cd>URGP</Cd> </SvcLvl> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">450</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Ella Eläkkeensaaja</Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine>Kotikatu 1</AdrLine> <AdrLine>00100 Helsinki</AdrLine> </PstlAdr> <Id> <PrvtId> <Othr> <Id>150540-123T <SchmeNm> <Cd>SOSE</Cd> </SchmeNm>

</Othr> </PrvtId> </Cdtr> <CdtrAcct> <Id> <IBAN>FI5158410220025201</IBAN> </CdtrAcct> <Purp> <Cd>PENS</Cd> </Purp> </CdtTrfTxInf> </PmtInf> 79/104 ----------------------------- Individual urgent payment ------------------------------ can be included in the same batch as a SEPA payment <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</EndToEndId> </PmtId> <PmtTpInf> <SvcLvl> <Cd>URGP</Cd> </SvcLvl> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">35050</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>NDEAFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm> Oy Yritys Ab </Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine> Hämeenkatu 1</AdrLine> <AdrLine>00100 Helsinki </AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <IBAN> FI7210423000000226</IBAN> </CdtrAcct> <RmtInf> <Ustrd> Urgent payment of your invoice 69854/31 July 2013</Ustrd> </RmtInf> </CdtTrfTxInf> ------------------------- Urgent payment batch ------------------------- <PmtInf> <PmtInfId>20130814-123456-01</PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <InstrPrty>NORM</InstrPrty> <SvcLvl> <Cd>URGP</Cd> </SvcLvl> </PmtTpInf>

80/104 <ReqdExctnDt>2013-08-14</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <Id> <OrgId> <Othr> <Id>12345678900 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Dbtr> <DbtrAcct> <Id> <IBAN>FI2550001520322972</IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <ChrgBr>SLEV</ChrgBr> <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</EndToEndId> </PmtId> <Amt> <InstdAmt Ccy="EUR">150</InstdAmt> </Amt> <CdtrAgt> <FinInstnId> <BIC>NDEAFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm> Oy Yritys Ab </Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine> Hämeenkatu 1</AdrLine> <AdrLine>00100 Helsinki </AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <IBAN> FI7210423000000226</IBAN> </CdtrAcct> <RmtInf> <Ustrd> Urgent payment of your invoice No 1568962 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>

81/104 <Cd>SCOR</Cd> </CdtrRefTp> <CdtrRef>00000000000000001245</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 103071 (net total) <RmtInf> <Strd> <RfrdDocInf> <RfrdDocTp> <Cd>CINV</Cd> </RfrdDocTp> <RfrdDocNb>Inv 12345</RfrdDocNb> </RfrdDocInf> <RfrdDocAmt> <RmtdAmt Ccy="EUR">123070</RmtdAmt> (gross total) </RfrdDocAmt> <CdtrRefInf> <CdtrRefTp> <Cd>SCOR</Cd> </CdtrRefTp> <CdtrRef>00000000000000000013</CdtrRef> </CdtrRefInf> </Strd> <Strd> <RfrdDocInf> <RfrdDocTp> <Cd>CREN</Cd> </RfrdDocTp> <RfrdDocNb>Inv 12359</RfrdDocNb> </RfrdDocInf> <RfrdDocAmt> <CdtNoteAmt Ccy="EUR">20000</CdtNoteAmt> (credit note amount) </RfrdDocAmt> <CdtrRefInf> <CdtrRefTp> <Cd>SCOR</Cd> </CdtrRefTp> <CdtrRef>00000000000000001245</CdtrRef> </CdtrRefInf>

</Strd> </RmtInf> 82/104 ---------------------------------------------- International payment - payment order ---------------------------------------------- <PmtInf> <PmtInfId>20110102-123456-01</PmtInfId> <PmtMtd>TRF</PmtMtd> <ReqdExctnDt>2011-05-10</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> </PstlAdr> <Id> <OrgId> <Othr> <Id>12345678900 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Dbtr> <DbtrAcct> <Id> <IBAN>FI2550001520322972</IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</EndToEndId> </PmtId> <PmtTpInf> <InstrPrty>NORM</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="USD">25090</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>IRVTUS3N</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Ewing Oil</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>5th Avenue</AdrLine> <AdrLine>Dallas</AdrLine> <AdrLine>TEXAS 1234</AdrLine> <AdrLine>USA</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <Othr> <Id>9876543210 </Othr>

</CdtrAcct> <RmtInf> <Ustrd>Invoice 5656</Ustrd> </RmtInf> </CdtTrfTxInf> 83/104 --------------------------------------------------------------------- International payment payment order (clearing code) -------------------------------------------------------------------- <CdtTrfTxInf> <PmtId> <InstrId>InstrId_2014_039</InstrId> <EndToEndId>e2e_040</EndToEndId> </PmtId> <Amt> <InstdAmt Ccy="USD">2521</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <ClrSysMmbId> <ClrSysId> <Cd>USABA</Cd> </ClrSysId> <MmbId>123456789</MmbId> </ClrSysMmbId> <Nm>First National Bank</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>123 5th Avenue</AdrLine> <AdrLine>New York</AdrLine> <AdrLine>256985 NY</AdrLine> </PstlAdr> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>John Doe</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>PO BOX 7</AdrLine> <AdrLine>New York</AdrLine> <AdrLine>256985 NY</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <Othr> <Id>60763131926819 </Othr> </CdtrAcct> <RmtInf> <Ustrd>clearing code in two fields</ustrd> </RmtInf> </CdtTrfTxInf> ------------------------------------------ International payment urgent payment order ------------------------------------------ <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</EndToEndId> </PmtId>

84/104 <PmtTpInf> <InstrPrty>HIGH</InstrPrty> </PmtTpInf> <Amt> <InstdAmt Ccy="INR">29010</InstdAmt> </Amt> <ChrgBr>SHAR</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>SBININBB104</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Indi As</Nm> <PstlAdr> <Ctry>IN</Ctry> <AdrLine>Indian Street 3</AdrLine> <AdrLine>Indiala</AdrLine> <AdrLine>Kalkuta</AdrLine> <AdrLine>INDIA</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <Othr> <Id>C-310312345 </Othr> </CdtrAcct> <RmtInf> <Ustrd>Payment number 678 5 carpets</ustrd> </RmtInf> </CdtTrfTxInf> ------------------------------------------- International payment SWIFT cheque ------------------------------------------- <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</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> <PstlAdr> <Ctry>TR</Ctry> <AdrLine>Ata 7</AdrLine> <AdrLine>Istanbul</AdrLine> <AdrLine>TURKEY</AdrLine> </PstlAdr> </Cdtr> <RmtInf> <Ustrd>Reservation 7878799</Ustrd> </RmtInf> </CdtTrfTxInf>

85/104 ----------------------------------------------------------- International payment - International order ----------------------------------------------------------- <CdtTrfTxInf> <PmtId> <EndToEndId>9834454645554699</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> <Ctry>FI</Ctry> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> <AdrLine>FINLAND</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <IBAN>FI2550001520322972</IBAN> </CdtrAcct> <RmtInf> <Ustrd>Invoice 5656</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf> </CstmrCdtTrfInitn> ------------------------- Real-time C2B urgent payment ------------------------- <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00100103" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:pain00100103 pain00100103xsd"> <CstmrCdtTrfInitn> <GrpHdr> <MsgId>20110901-0000001</MsgId> <CreDtTm>2011-09-20T07:32:34834+03:00</CreDtTm> <NbOfTxs>1</NbOfTxs> <InitgPty> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> </PstlAdr> </InitgPty> </GrpHdr> <PmtInf> <PmtInfId>20110920-123456-01</PmtInfId> <PmtMtd>TRF</PmtMtd> <PmtTpInf> <SvcLvl> <Cd>URGP</Cd> </SvcLvl> </PmtTpInf>

86/104 <ReqdExctnDt>2011-09-20</ReqdExctnDt> <Dbtr> <Nm>Firma Oy</Nm> <PstlAdr> <Ctry>FI</Ctry> <AdrLine>Teollisuuskatu 1</AdrLine> <AdrLine>00550 Helsinki</AdrLine> </PstlAdr> <Id> <OrgId> <Othr> <Id>12345678900 < SchmeNm> <Cd> BANK</Cd> </ SchmeNm> </Othr> </OrgId> </Dbtr> <DbtrAcct> <Id> <IBAN>FI2550001520322972</IBAN> <Ccy>EUR</Ccy> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </DbtrAgt> <CdtTrfTxInf> <PmtId> <InstrId>instrid</InstrId> <EndToEndId>9834454645554699</EndToEndId> </PmtId> <PmtTpInf> <SvcLvl> <Cd>URGP</Cd> </SvcLvl> </PmtTpInf> <Amt> <InstdAmt Ccy="EUR">124</InstdAmt> </Amt> <ChrgBr>SLEV</ChrgBr> <CdtrAgt> <FinInstnId> <BIC>NDEAFIHH</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>Yritys Oy</Nm> </Cdtr> <CdtrAcct> <Id> <IBAN>FI2112345600000785</IBAN> </CdtrAcct> <RmtInf> <Strd> <CdtrRefInf> <Tp> <CdOrPrtry> <Cd>SCOR</Cd> </CdOrPrtry> </Tp> <Ref>RF0212345614</Ref> </CdtrRefInf> </Strd> </RmtInf> </CdtTrfTxInf>

</PmtInf> </CstmrCdtTrfInitn> </Document> 87/104 ------------------------------------------------------- Cancellation request for one transaction -------------------------------------------------------- <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt05500101" xmlns:xsi="http://wwww3org/2001/xmlschema-instance" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:camt05500101 camt05500101xsd"> <CstmrPmtCxlReq> <Assgnmt> <Id>;8)G57 KO8SL DT01149KMT420000 <Assgnr> <Pty> <Nm>Testi</Nm> </Pty> </Assgnr> <Assgne> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgne> <CreDtTm>2015-01-14T14:35:32+02:00</CreDtTm> </Assgnmt> <Undrlyg> <OrgnlGrpInfAndCxl> <GrpCxlId>;8)G57 KO8SL DT01149KMT4200010001</GrpCxlId> <OrgnlMsgId>;8)G57 RE3LL TS0114DN0B420000</OrgnlMsgId> <OrgnlMsgNmId>pain0010102</OrgnlMsgNmId> <GrpCxl>false</GrpCxl> </OrgnlGrpInfAndCxl> <OrgnlPmtInfAndCxl> <Case> <Id>NOTPROVIDED <Cretr> <Pty> <Id> <OrgId> <Othr> <Id>020212100 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Pty> </Cretr> </Case> <OrgnlPmtInfId>;8)G57 RE3LL TS0114DN0B420001</OrgnlPmtInfId> <PmtInfCxl>false</PmtInfCxl> <TxInf> <CxlId>;8)G57 KO8SL DT01149KMT420001</CxlId> <OrgnlEndToEndId>NOTPROVIDED</OrgnlEndToEndId> <OrgnlInstdAmt Ccy="EUR">250000</OrgnlInstdAmt> <OrgnlReqdExctnDt>2015-01-14</OrgnlReqdExctnDt> <OrgnlTxRef> <DbtrAcct> <Id> <IBAN>FI9112120720054543</IBAN> </DbtrAcct> <CdtrAcct> <Id> <IBAN> FI9112120720054543</IBAN>

</CdtrAcct> </OrgnlTxRef> </TxInf> </OrgnlPmtInfAndCxl> </Undrlyg> </CstmrPmtCxlReq> </Document> 88/104 ------------------------------------------------------------------------------ Cancellation request for the entire batch ------------------------------------------------------------------------------- <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt05500101" xmlns:xsi="http://wwww3org/2001/xmlschema-instance" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:camt05500101 camt05500101xsd"> <CstmrPmtCxlReq> <Assgnmt> <Id>;8)G57 G47*L DT0114NG81620000 <Assgnr> <Pty> <Nm>Testi</Nm> </Pty> </Assgnr> <Assgne> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgne> <CreDtTm>2015-01-14T14:51:34+02:00</CreDtTm> </Assgnmt> <Undrlyg> <OrgnlGrpInfAndCxl> <GrpCxlId>;8)G57 G47*L DT0114NG816200010001</GrpCxlId> <OrgnlMsgId>;8)G57 EHH+L TS01145C7Z520000</OrgnlMsgId> <OrgnlMsgNmId>pain0010102</OrgnlMsgNmId> <GrpCxl>false</GrpCxl> </OrgnlGrpInfAndCxl> <OrgnlPmtInfAndCxl> <PmtCxlId>;8)G57 G47*L DT0114NG81620001</PmtCxlId> <Case> <Id>NOTPROVIDED <Cretr> <Pty> <Id> <OrgId> <Othr> <Id>020212100 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </Pty> </Cretr> </Case> <OrgnlPmtInfId>;8)G57 EHH+L TS01145C7Z520001</OrgnlPmtInfId> <NbOfTxs>3</NbOfTxs> <CtrlSum>14300</CtrlSum> <PmtInfCxl>true</PmtInfCxl> </OrgnlPmtInfAndCxl> </Undrlyg> </CstmrPmtCxlReq> </Document

89/104 8 Example response messages 81 Report on technical validation 811 Report on accepted technical validation <CstmrPmtStsRpt> <GrpHdr> <MsgId>1539869</MsgId> <CreDtTm>2010-06-08T12:01:10+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>20110102-0000001</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <GrpSts>ACTC</GrpSts> </OrgnlGrpInfAndSts> </CstmrPmtStsRpt> 812 Report on rejected technical validation <CstmrPmtStsRpt> <GrpHdr> <MsgId>1539869</MsgId> <CreDtTm>2010-06-08T12:01:10+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>20110102-0000001</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <GrpSts>RJCT</GrpSts> <StsRsnInf> <Rsn> <Cd>NARR</Cd> </Rsn> <Addtllnf>pain00100103 could not be processed, please verify structure cvc-datatype-valid121: '4847,37'</AddtlInf> <AddtlInf>is not a valid value for 'decimal'cvc-type313: The value '4847,37' of element 'CtrlSum' is not val</addtlinf> <AddtlInf>id</AddtlInf> </StsRsnInf> </OrgnlGrpInfAndSts> </CstmrPmtStsRpt> 813 Report on failed technical validation of real-time C2B urgent payment <?xml version="10" encoding="iso-8859-15"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1317984993537</MsgId> <CreDtTm>2011-10-07T13:56:33+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>1317984987543</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <GrpSts>RJCT</GrpSts> <StsRsnInf> <Orgtr> <Id> <OrgId> <Othr> <Id>1000002046 </Othr>

90/104 </OrgId> </Orgtr> <Rsn> <Cd>NARR</Cd> </Rsn> <AddtlInf>pain00100103 could not be processed, please verify structurecvc-complex-type24a: Invalid content w</addtlinf> <AddtlInf>as found starting with element 'ThisShouldNotBeValid' One of '{"urn:iso:std:iso:20022:tech:xsd:pain001</addtlinf> <AddtlInf>00103":GrpHdr}' is expected</addtlinf> </StsRsnInf> </OrgnlGrpInfAndSts> </CstmrPmtStsRpt> </Document> 82 Report on payload content validation 821 Report on accepted content validation <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103" xmlns:xsi="http://wwww3org/2001/xmlschema-instance"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1539898</MsgId> <CreDtTm>2014-01-08T13:33:47+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>20140102-0000001</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgnlCreDtTm>2014-01-08T10:24:00+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>ACCP</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20110102-123456-01</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>9008</OrgnlCtrlSum> <PmtInfSts>ACCP</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>ACCP</DtldSts> <DtldCtrlSum>9008</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">9008</InstdAmt> </Amt> <ReqdExctnDt>2014-01-08</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document>

91/104 822 Report on partially accepted content validation The payload contains four batches: Batch 1 - credit transfer of 2711 is OK - credit transfer of 2211 has an incorrect reference - credit transfer of 111,73011 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 - 61011-13011 Batch 3 Batch 4 credit transfer of 52511 is OK credit transfer of 14011 is OK - credit transfer of 500,00011 is OK <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103" xmlns:xsi="http://wwww3org/2001/xmlschema-instance"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1540378</MsgId> <CreDtTm>2014-01-11T16:31:48+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_110610</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgnlCreDtTm>2014-01-08T10:24:00+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>8</OrgnlNbOfTxs> <GrpSts>PART</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-01</OrgnlPmtInfId> <OrgnlNbOfTxs>3</OrgnlNbOfTxs> <OrgnlCtrlSum>11177933</OrgnlCtrlSum> <PmtInfSts>PART</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>2</DtldNbOfTxs> <DtldSts>ACCP</DtldSts> <DtldCtrlSum>11175722</DtldCtrlSum> </NbOfTxsPerSts> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>RJCT</DtldSts> <DtldCtrlSum>2211</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlInstrdId>201401115UTH00000154</OrgnlInstrdId> <OrgnlEndToEndId>TEST PMT</OrgnlEndToEndId> <TxSts>RJCT</TxSts> <StsRsnInf> <Rsn> <Cd>NARR</Cd> </Rsn> <AddtlInf>Incorrect reference</addtlinf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">2211</InstdAmt> </Amt> <ReqdExctnDt>2014-01-11</ReqdExctnDt>

92/104 <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI4858498520016103</IBAN> </DbtrAcct> <Cdtr> <Nm>Oy Yritys Ab</Nm> </Cdtr> <CdtrAcct> <Id> <IBAN>FI4880002002330354</IBAN> </CdtrAcct> <UltmtCdtr> <Nm>Ultimate Creditor</Nm> </UltmtCdtr> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-02</OrgnlPmtInfId> <OrgnlNbOfTxs>2</OrgnlNbOfTxs> <OrgnlCtrlSum>74022</OrgnlCtrlSum> <PmtInfSts>RJCT</PmtInfSts> <StsRsnInf> <Rsn> <Cd>DT01</Cd> </Rsn> <AddtlInf>Incorrect requested execution date</addtlinf> </StsRsnInf> <NbOfTxsPerSts> <DtldNbOfTxs>2</DtldNbOfTxs> <DtldSts>RJCT</DtldSts> <DtldCtrlSum>74022</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">74022</InstdAmt> </Amt> <ReqdExctnDt>2014-01-08</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-03</OrgnlPmtInfId> <OrgnlNbOfTxs>2</OrgnlNbOfTxs> <OrgnlCtrlSum>66522</OrgnlCtrlSum> <PmtInfSts>ACCP</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>2</DtldNbOfTxs> <DtldSts>ACCP</DtldSts> <DtldCtrlSum>66522</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt>

93/104 </OrgnlTxRef> </TxInfAndSts> <InstdAmt Ccy="EUR">66522</InstdAmt> </Amt> <ReqdExctnDt>2014-01-08</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlPmtInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-04</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>50000011</OrgnlCtrlSum> <PmtInfSts>ACCP</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>ACCP</DtldSts> <DtldCtrlSum>50000011</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">50000011</InstdAmt> </Amt> <ReqdExctnDt>2014-01-08</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> 823 Report on rejected content validation of C2B payload <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103" xmlns:xsi="http://wwww3org/2001/xmlschema-instance"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>3395684</MsgId> <CreDtTm>2014-01-08T13:32:45+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>MsgId_20140108-00004</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgnlCreDtTm>2014-01-08T10:24:00+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>RJCT</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140108-123456-01</OrgnlPmtInfId>

94/104 <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>1308</OrgnlCtrlSum> <PmtInfSts>RJCT</PmtInfSts> <StsRsnInf> <Rsn> <Cd>DT01</Cd> </Rsn> <AddtlInf>Incorrect requested execution date</addtlinf> </StsRsnInf> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>RJCT</DtldSts> <DtldCtrlSum>1308</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">1308</InstdAmt> </Amt> <ReqdExctnDt>2014-01-02</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> 83 Report on payment 831 Report on accepted payload ('pain') <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103" xmlns:xsi="http://wwww3org/2001/xmlschema-instance"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1540314</MsgId> <CreDtTm>2014-01-11T10:46:34+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>20140102-0000001</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgnlCreDtTm>2014-01-08T10:24:00+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <GrpSts>ACSP</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-01</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>9008</OrgnlCtrlSum> <PmtInfSts>ACSP</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>ACSP</DtldSts> <DtldCtrlSum>9008</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">9008</InstdAmt> </Amt>

95/104 </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> <ReqdExctnDt>2014-01-08</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> Report on accepted real-time C2B urgent payment debit and credit transactions <?xml version="10" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1316426908834</MsgId> <CreDtTm>2011-09-19T13:08:28834+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>123456789</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <GrpSts>ACSP</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20110901-123-01</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>124</OrgnlCtrlSum> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>ACSP</DtldSts> <DtldCtrlSum>124</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlInstrId>instrid</OrgnlInstrId> <OrgnlEndToEndId>9834454645554699</OrgnlEndToEndId> <TxSts>ACSP</TxSts> <AcctSvcrRef>593728B70003</AcctSvcrRef> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">124</InstdAmt> </Amt> <ReqdExctnDt>19/09/2011</ReqdExctnDt> <DbtrAcct> <Id> <IBAN>FI1258410220039095</IBAN> </DbtrAcct> <CdtrAcct> <Id> <IBAN>FI2758410220035721</IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> Report on failed real-time C2B urgent payment debit and credit transactions

96/104 <?xml version="10" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1316770988216</MsgId> <CreDtTm>2011-09-23T12:43:08216+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>123456789</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <GrpSts>RJCT</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20110920-123456-01</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>124</OrgnlCtrlSum> <PmtInfSts>RJCT</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>RJCT</DtldSts> <DtldCtrlSum>124</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlInstrId>instrid</OrgnlInstrId> <OrgnlEndToEndId>9834454645554699</OrgnlEndToEndId> <TxSts>RJCT</TxSts> <StsRsnInf> <Rsn> <Cd>AC01</Cd> </Rsn> <AddtlInf>Incorrect payee's account</addtlinf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">124</InstdAmt> </Amt> <ReqdExctnDt>2011-09-23</ReqdExctnDt> <DbtrAcct> <Id> <IBAN>FI1258410220039095</IBAN> </DbtrAcct> <CdtrAcct> <Id> <IBAN>FI5051009420103111</IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> Report on pending real-time C2B urgent credit transfer <?xml version="10" encoding="utf-8" standalone="yes"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1317097820647</MsgId> <CreDtTm>2011-09-27T07:30:20647+03:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts> <OrgnlMsgId>123456789</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <GrpSts>PDNG</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20110920-123456-01</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs>

97/104 <OrgnlCtrlSum>124</OrgnlCtrlSum> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>PDNG</DtldSts> <DtldCtrlSum>124</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlInstrId>instrid</OrgnlInstrId> <OrgnlEndToEndId>9834454645554699</OrgnlEndToEndId> <TxSts>PDNG</TxSts> <StsRsnInf> <Rsn> <Cd>NARR</Cd> </Rsn> <AddtlInf>Unclear, contact your own bank</addtlinf> </StsRsnInf> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">124</InstdAmt> </Amt> <ReqdExctnDt>2011-09-27</ReqdExctnDt> <DbtrAcct> <Id> <IBAN>FI1258410220039095</IBAN> </DbtrAcct> <CdtrAcct> <Id> <IBAN>FI2112345600000785</IBAN> </CdtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> 832 Report on partially accepted payload ('pain') The payload contains three batches: Batch 1 - credit transfer of 2711 - credit transfer of 111,73011 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 Batch 3 payment 52511 processed payment 14011 processed payment of 500,00011 not processed, because of insufficient balance <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain00200103" xmlns:xsi="http://wwww3org/2001/xmlschema-instance"> <CstmrPmtStsRpt> <GrpHdr> <MsgId>1540404</MsgId> <CreDtTm>2014-01-11T16:40:19+02:00</CreDtTm> </GrpHdr> <OrgnlGrpInfAndSts>

98/104 <OrgnlMsgId>MsgId_110610</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgnlCreDtTm>2014-01-29T10:24:00+02:00</OrgnlCreDtTm> <OrgnlNbOfTxs>8</OrgnlNbOfTxs> <GrpSts>PART</GrpSts> </OrgnlGrpInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-02</OrgnlPmtInfId> <OrgnlNbOfTxs>3</OrgnlNbOfTxs> <OrgnlCtrlSum>11177933</OrgnlCtrlSum> <PmtInfSts>PNDG</PmtInfSts> <StsRsnInf> <Rsn> <Cd>NARR</Cd> </Rsn> <AddtlInf>Payment waiting for processing</addtlinf> </StsRsnInf> <NbOfTxsPerSts> <DtldNbOfTxs>3</DtldNbOfTxs> <DtldSts>PNDG</DtldSts> <DtldCtrlSum>11177933</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">11177933</InstdAmt> </Amt> <ReqdExctnDt>2014-01-29</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> <OrgnlPmtInfAndSts> <OrgnlPmtInfId>20140102-123456-03</OrgnlPmtInfId> <OrgnlNbOfTxs>2</OrgnlNbOfTxs> <OrgnlCtrlSum>66522</OrgnlCtrlSum> <PmtInfSts>ACSP</PmtInfSts> <NbOfTxsPerSts> <DtldNbOfTxs>2</DtldNbOfTxs> <DtldSts>ACSP</DtldSts> <DtldCtrlSum>66522</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">66522</InstdAmt> </Amt> <ReqdExctnDt>2014-01-29</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> <OrgnlPmtInfAndSts>

99/104 <OrgnlPmtInfId>20140102-123456-03</OrgnlPmtInfId> <OrgnlNbOfTxs>1</OrgnlNbOfTxs> <OrgnlCtrlSum>50000011</OrgnlCtrlSum> <PmtInfSts>PNDG</PmtInfSts> <StsRsnInf> <Rsn> <Cd>NARR</Cd> </Rsn> <AddtlInf>Payment waiting for processing</addtlinf> </StsRsnInf> <NbOfTxsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>PNDG</DtldSts> <DtldCtrlSum>50000011</DtldCtrlSum> </NbOfTxsPerSts> <TxInfAndSts> <OrgnlTxRef> <Amt> <InstdAmt Ccy="EUR">50000011</InstdAmt> </Amt> <ReqdExctnDt>2014-01-29</ReqdExctnDt> <UltmtDbtr> <Nm>Original Debtor</Nm> </UltmtDbtr> <Dbtr> <Nm>Firma Oy</Nm> </Dbtr> <DbtrAcct> <Id> <IBAN>FI9250009420108078</IBAN> </DbtrAcct> </OrgnlTxRef> </TxInfAndSts> </OrgnlPmtInfAndSts> </CstmrPmtStsRpt> </Document> 833 Notification for successful payment ( camt ) <?xml version="10" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt05400102" xsi:schemalocation="urn:iso:std:iso:20022:tech:xsd:camt05400102 camt05400102xsd"> <BkToCstmrDbtCdtNtfctn> <GrpHdr> <MsgId>457587587</MsgId> <CreDtTm>2011-02-11T18:12:02+03:00</CreDtTm> <MsgRcpt> <Id> <OrgId> <Othr> <Id>123456789 <SchmeNm> <Cd>BANK</Cd> </SchmeNm> </Othr> </OrgId> </MsgRcpt> </GrpHdr> <Ntfctn> <Id>4575875871 <CreDtTm>2011-02-11T18:00:02+03:00</CreDtTm> <Acct> <Id> <IBAN>FI2550001520322972</IBAN> <Svcr>

100/104 <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Svcr> </Acct> <Ntry> <Amt Ccy="XXX">20852</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Sts>BOOK</Sts> <BookgDt> <Dt>2011-11-02</Dt> </BookgDt> <BkTxCd> <Prtry> <Cd>Veloitus</Cd> </Prtry> </BkTxCd> <NtryDtls> <Btch> <PmtInfId>201110101-123456-01</PmtInfId> <NbOfTxs>1</NbOfTxs> </Btch> <TxDtls> <Refs> <AcctSvcrRef>111102ACCTSTMTARCH04</AcctSvcrRef> <InstrId>201110101-123456-01</InstrId> <EndToEndId>9834454645554699</EndToEndId> </Refs> <AmtDtls> <InstdAmt> <Amt Ccy="USD">20852</Amt> <CcyXchq> <TrgtCcy>EUR</TrgtCcy> <UnitCcy>USD</UnitCcy> <XchqRate>08341</XchqRate> <QtnDt>2011-02-11T14:12:02+03:00</QtnDt> </CcyXchq> </InstdAmt> <CntrValAmt> <Amt>250</Amt> </CntrValAmt> </AmtDtls> <Chrgs> <Br>SHAR</Br> </Chrgs> <RltdPties> <Dbtr> <Nm>Firma Oy</Nm> <Id> <OrgId> <Othr> <Id>12345678900 </Othr> </OrgId> </Dbtr> <Cdtr> <Nm>Ewing Oil</Nm> <PstlAdr> <Ctry>US</Ctry> <AdrLine>5th Avenue</AdrLine> <AdrLine>5th Avenue</AdrLine> <AdrLine>5th Avenue</AdrLine> <AdrLine>5th Avenue</AdrLine> </PstlAdr> </Cdtr> <CdtrAcct> <Id> <Othr> >Id>9876543210

101/104 </Othr> </CdtrAcct> </RltdPties> <RltdAgts> <CdtrAgt> <FinInstnId> <BIC>IRVTUS3N</BIC> </FinInstnId> </CdtrAgt> </RltdAgts> <RmtInf> <Ustrd>Invoice 5656</Ustrd> </RmtInf> <RltdDts> <AccptncDtTm>2011-11-02</AccptncDtTm> </RltdDts> </TxDtls> </NtryDtls> </Ntry> 9 Example responses to cancellation request 91 Report on technical validation (content check) 911 Report on rejected technical validation <RsltnOfInvstgtn> <Assgnmt> <Id>CANCROI/100928/ROI001 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <Id> <OrgId> <Othr> <Id>088899996 <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm>2010-09-08T16:10:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlGrpCxlId>CANCEL001</OrgnlGrpCxlId> <OrgnlMsgId>PAYMENT001</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgCreDtTm>2010-09-08T16:10:30</OrgCreDtTm> <OrgnlNbOfTxs>3</OrgnlnbofTxs> <OrgnlCtrlSum>333,33</OrgnlCtrlSum> <GrpCxlSts>RJCR</GrpCxlSts>

102/104 <CxlStsRsnInf> <Rsn> <Prtry>NARR</Prtry> <AddtlInf>Invalid original message name identification </AddtlInf> </Rsn> </CxlStsRsnInf> </OrgnlGrpInfAndSts> </RsltnOfInvstgtn> 91 Notification for processed cancellation request 911 Report for successfully processed cancellation request <RsltnOfInvstgtn> <Assgnmt> <Id>CANCROI/100928/ROI001 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <Id> <OrgId> <Othr> <Id>088899996 <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm>2010-09-08T16:10:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlGrpCxlId>CANCEL001</OrgnlGrpCxlId> <OrgnlMsgId>PAYMENT001</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgCreDtTm>2010-09-08T16:10:30</OrgCreDtTm> <OrgnlNbOfTxs>3</OrgnlnbofTxs> <OrgnlCtrlSum>333,33</OrgnlCtrlSum> <GrpCxlSts>ACCR</GrpCxlSts> <OrgnlPmtinfAndSts> <OrgnlPmtInfId>PMT000001</OrgnlPmtInfId> <PmtInfCxlSts>ACCR</PmtInfCxlSts> </RsltnOfInvstgtn> 912 Notification for partially successful cancellation request <RsltnOfInvstgtn> <Assgnmt> <Id>CANCROI/100928/ROI002 <Assgnr> <Agt>

103/104 <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <Id> <OrgId> <Othr> <Id>088899996 <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm>2010-09-08T16:10:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlMsgId>ABC/100928/CCT01</OrgnlMsgId> <OrgnlMsgNmId>pacs00100103</OrgnlMsgNmId> <OrgnlCreDtTm>2010-09-28T14:07:00</OrgnlCreDtTm> <OrgnlNbOfTxs>3</OrgnlNbOfTxs> <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">100000000</OrgnlInstdAmt> <OrgnlReqdExctnDt>2010-09-29</OrgnlReqdExctnDt> <OrgnlInstrId>ABC/100928/CCT01/2</OrgnlInstrId> <TxCxlSts>ACCR</TxCxlSts> <OrgnlInstdAmt Ccy="EUR">102000</OrgnlInstdAmt> <OrgnlReqdExctnDt>2010-09-29</OrgnlReqdExctnDt> </TxInfAndSts> </OrgnlPmtInfAndSts> </RsltnOfInvstgtn> 913 Report on a totally rejected cancellation request <RsltnOfInvstgtn> <Assgnmt> <Id>CANCRO3/100928/ROI003 <Assgnr> <Agt> <FinInstnId> <BIC>OKOYFIHH</BIC> </FinInstnId> </Agt> </Assgnr> <Assgne> <Pty> <Nm>ABC Corporation</Nm> <Id>

104/104 <OrgId> <Othr> <Id>088899996 <SchmeNm> <Cd>BANK</Cd> </ScmeNm> </Othr> </OrgId> </Pty> </Assgne> <CreDtTm>2010-09-08T16:12:30</CreDtTm> </Assgnmt> <Sts> <AssgnmentCxlConf>True</AssgnmentCxlConf> </Sts> <CxlDtls> <OrgnlGrpInfAndSts> <OrgnlGrpCxlId>CANCEL002</OrgnlGrpCxlId> <OrgnlMsgId>PAYMENT002</OrgnlMsgId> <OrgnlMsgNmId>pain00100103</OrgnlMsgNmId> <OrgCreDtTm>2010-09-08T16:12:30</OrgCreDtTm> <GrpCxlSts>RJCR</GrpCxlSts> <OrgnlPmtinfAndSts> <OrgnlPmtInfId>PMT000002</OrgnlPmtInfId> <PmtInfCxlSts>RJCR</PmtInfCxlSts> <CxlStsRsnInf> <Rsn> <Prtry>NARR</Prtry> <AddtlInf>Payment already processed </AddtlInf> </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>