OP-POHJOLA GROUP C2B SERVICES. Payment Services

Transcription

1 OP-POHJOLA GROUP C2B S Payment Services Service Description November 2010

2 2/63 Contents 1 General information Making of C2B payments Recurring C2B payments C2B payload checks by the bank Responses to C2B payment messages Sending and retrieval of messages Stages in the process Structure of the payload file sent by the customer Payload processing schedules Structure of responses retrieved by the customer Response creation and schedules Checking of available funds and payment Clearing codes Charge bearer codes Requirements for implementation The testing environment Testing environment IDs and certificates URLs Limitations of the testing environment Negotiations and transaction information C2B payment initiation message and example descriptions Group Header SEPA credit transfer Recurring SEPA credit transfers sent as a separate batch International payment payment order International payment urgent payment order International payment foreign-currency cheque International payment SWIFT cheque Bank responses and message description Report on technical validation Report on payload content validation Payment status report ( pain ) Debit notification message ( camt ) Example C2B payment messages Example response messages Report on technical validation Report on accepted technical validation Report on rejected technical validation Report on payload content validation Report on accepted content validation Report on partially accepted content validation Report on payment Report on accepted payload ( pain ) Report on partly accepted payload ( pain ) Notification for successful payment ( camt )... 62

3 3/63 1 General information 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, and international payments. Osuuspankki s batch transfer service currently provides the following corresponding services: invoice payment service (LMP), recurring payments (TS), and international payments (LUM2). The use of C2B payment initiation messages may differ from the services available for LMP, LUM2, and TS formats. After migration to the Single Euro Payments Area (SEPA), these Finnish credit transfer message formats will be replaced with the C2B payment initiation message. Payloads cannot be sent in these formats after 31 October 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. The C2B message is an international ISO message in XML format. The schema for the payload sent to the bank is pain xsd, and the schema for the bank s response that the customer retrieves from the bank is pain xsd. The 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 message descriptions are subject to change. For up-to-date descriptions, please refer to: The Federation of Finnish Financial Services Web site, at The OP-Pohjola Group Web site, at ISO standard message types For the schemas and documentation, please refer to the ISO Web site at Additional information is also available at the Federation of Finnish Financial Services Web site, at C2B payment message from the customer to the bank The name of the message is CustomerCreditTransferInitiationV02. The XML schema identifier is pain In the Osuuspankki batch transfer service, the payload type of the C2B payment message is XM (XML payment data). The type of the payload sent to the Web Services channel is pain Response from the bank to the customer The name of the message is PaymentStatusReportV02. The XML schema identifier is pain In the Osuuspankki batch transfer service, the payload type of the response to the C2B payment message is XP (XML response data). The type of payload retrieved from the Web Services channel is pain

4 1.1 Making of C2B payments 4/63 The account number is given in the International Bank Account Number (IBAN) format in C2B payment messages. The Bank Identification Code (BIC) too is mandatory. 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 payee. 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 bank. For C2B payments to Finland, the payment date i.e., information on the account debit date is transferred to the payee. C2B payment payloads can contain additional information that cannot be provided in LMP or LUM2 format. The additional information in the C2B payment message aids in, for instance, the reconciliation of payments and identification of the payer. However, it is not possible to guarantee that all information provided will be transferred to the beneficiary, as this depends on the beneficiary 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, no XML tags. Finnish reference numbers are provided in a structured message. Instead of the 140-character message, it is possible to transfer, at maximum, nine remittance information entries, max. 280 characters each, to SEPA* banks that operate in Finland. * Aktia, savings banks and local cooperative banks (HELSFIHH) Danske Bank (DABAFIHX) DnB NOR (DNBAFIHX) Handelsbanken (HANDFIHH) Nordea (NDEAFIHH) OP-Pohjola Group (OKOYFIHH) Sampo Bank (DABAFIHH) SEB (ESSEFIHX) S-Bank (SBANFIHH) Swedbank (SWEDFIHH) Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22) The payments are debited from the customer s account on the due date. It is the payer s responsibility to make sure that the account to be debited has sufficient funds available to cover the specified message amount on the due date. If the amount of funds is insufficient, the entire batch will be rejected during the last run of the due 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 single transactions or whether the payments in each individual <PmtfInf> block are bundled into one debit from the payer s account. In the case of recurrent payments, all payments will be bundled into one payment. Account transaction C2B debit C2B credit Transaction identifier 5UTV 5UTH Application IDs XM = XML payment data (C2B payments, C2B recurring payments) XP = C2B payment response data

5 1.2 Recurring C2B payments 5/63 C2B payload can be used to initiate salary, pension, benefit, and other recurring payments. The batch is recognised as a recurrent payment through use of the code SALA in the Category Purpose element of the C2B payment message. Instead of the payment date (the date of the beneficiary s credit), which is used in TS payloads, the C2B payment message specifies the execution date (the date of the initiator s debit) for recurring SEPA payments. The funds are credited to the beneficiary s account on the morning of the following banking day, regardless of which domestic bank the beneficiary s account is with. 1.3 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. The 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, due date, and amount, are validated during further processing. This validation will create a new C2B report, which notifies the payer of the acceptance or rejection of the batch/transactions. The payer s message ID (MsgId) must be unique for a minimum of three months, to prevent the same payload being sent more than once. 1.4 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, responses are sent to the sender after each payload has been processed. The original C2B payment initiation message (pain ) that the C2B payment status report (pain ) is for is identified in the <OrgnlGrpInfAndSts><OrgnlMsgId> element. This element contains the original <GrpHdr><MsgId> provided by the customer in the C2B payload. In single payments, the original payment that the response is for is identified as follows: In SEPA credit transfers, the report created for a single payment contains the ID of the original payment given by the customer in <InstrId>. An individual batch is identified in the report by the OrgnlPmtInfId element, which matches the PmtInfId element of the payment batch sent. 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 explanation for the rejection. The Bank-to-Customer Debit/Credit Notification (camt ) message has the following levels: Group Header (GrpHdr) and Notification (Ntfctn). The elements of the Group Header block contain common message information for the message, and the elements in 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 of the information for each individual transaction. The original C2B payment initiation message (pain ) that the Bank-to-Customer Debit/Credit Notification (camt ) message is for is identified in the

6 6/63 <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. 2 Sending and retrieval of messages 2.1 Stages in the process A customer sends a C2B payload in the ISO message format and 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. The bank creates responses 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. A response is always created. o Response concerning the customer profile check: The bank validates the format of the bank account details, 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 The report in pain format at the end of the due date for processed payments and payments rejected because insufficient funds were available: The customer s C2B payment service agreement specifies whether a message is to be created for processed payments. The report is a summary for the batch. Reports are always created for payments rejected because insufficient funds are available. o The notification message in camt format for successful payments: The notification is created three times a day (at 12pm, 3pm, and 6pm) 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 recurrent payments with the code SALA. o The customer may specify in the C2B payment service agreement that C2B payments will be itemised in the customer s account statement. The customer must retrieve these messages immediately after they are created. The parameter for message retrieval is of the format mmdd.99999, where is the ID of the message from the bank. 2.2 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 Debtor, Debtor Account, and Requested Execution Date. The Payment Information part of the message is repeated if, for example, the Requested Execution Date and/or Debtor 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 Creditor, Creditor Account, and InstructedAmount.

7 7/63 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 Group is currently 100 MB. An individual C2B payload file can contain, at maximum, 50,000 payments. If a file contains more payments, it must be split Payload processing schedules Payloads sent to Osuuspankki will be processed further according to the following daily schedule: SEPA credit transfers (C2B) Recurrent SEPA credit transfers (C2B) Outgoing international payments (C2B) 7am every 30 minutes 6pm Payloads received after 6pm 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. 7am every 30 minutes 6pm A payload that is received after 6pm 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. 7:30am every 30 minutes 5pm Payments received before 5pm on the execution date will be processed on the same banking day. This applies to payloads sent on New Yea s Eve and Maundy Thursday. 2.3 Structure of responses retrieved by the customer The bank s responses to payments initiated by a C2B payment message use the schema pain or camt The customer retrieves the messages from the batch transfer service or the Web Services channel. The pain status report on payments initiated by a C2B payment message contains references to the original payload and in some cases also to individual payments. If the batches or transactions contain errors, status reports are created after each payload has been processed. The camt notification message for payments initiated by a C2B payment message contains details of the credit transfer transactions in the batch, such as payer s name and account number, payee s name and account number, amount payable, payment date, transaction identifier, and (for international payments) exchange rate information. 2.4 Response creation and schedules Status reports (pain ) are created for C2B payment messages as the bank processes the payments, as follows: 1) Report on technical validation in the batch transfer service, within 30 minutes of sending, during processing times; in the Web Services channel, immediately after the payload is received. 2) Report on content validation within 30 minutes of sending, during processing times. 3) The pain payment status report on the due date / processing date at the end of the day, at 9:20pm. Creation of reports for successfully made payments is specified separately in the service agreement.

8 8/63 The camt notification is created at 12pm, 3 pm, and 6 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. 2.5 Checking of available funds and payment It is the payer s responsibility to make sure that the account to be debited has sufficient funds available to cover the specified message amount on the due date. If the amount of funds is insufficient, the entire batch will be rejected during the last run of the due date. If the customer and bank have agreed on single payments in the C2B agreement, payments are made in the order they appear in the payment instruction until insufficient funds remain, and the rest of the payments are rejected. Bank service charges are charged monthly by the fifth banking day of the month following the invoicing month. 2.6 Clearing codes ISO clearing codes are maintained in the External Clearing System Identification Code List, which is available on the Web site of the International Organization for Standardization for ISO OP-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. Clearing code is specified at the transaction level in the ClrSysMmbId element. Example: <ClrSysMmbId> <Id> USABA </Id> For rouble payments to Russia, the payee s bank account number in the clearing centre of the Central Bank of the Russian Federation (20 numbers) must also be provided, with a slash as a separator. Example: <ClrSysMmbId> <Id> RUCBC / </Id> Bank Identifier Country Clearing Code long definition Code ([charactertype] {length}) Example Currencies Accepted by OP-Pohjola Australia Australian Bank State Branch Code (BSB) AUBSB [0-9]{6,6} AUBSB only AUD YES Austria Austrian Bankleitzahl ATBLZ [0-9]{5,5} ATBLZ12345 only EUR NO Canada Canadian Payments Association Payment Routing Number CACPA [0-9]{9,9} CACPA only CAD YES China CNAPS Identifier CNAPS [0-9]{12,12} CNAPS only CNY NO Germany German Bankleitzahl DEBLZ [0-9]{8,8} DEBLZ only EUR NO Greece Hellenic Bank Identification Code GRBIC [0-9]{7,7} GRHIC only EUR NO Hong Kong Hong Kong Bank Code HKNCC [0-9]{3,3} HKNCC123 only HKD YES India Indian Financial System Code INFSC [a-za-z0-9]{11,11} INFSC123AZ only INR YES Ireland Irish National Clearing Code IENCC [0-9]{6,6} IENCC only EUR NO Italy Italian Domestic Identification Code ITNCC [0-9]{10,10} ITNCC only EUR NO Japan Japan Zengin Clearing Code JPZGN [0-9]{7,7} JPZGN only JPY YES New New Zealand National Clearing Code NZNCC [0-9]{6,6} NZNCC only NZD YES Zealand Poland Polish National Clearing Code PLKNR [0-9]{8,8} PLKNR only PLN YES Portugal Portuguese National Clearing Code PTNCC [0-9]{8,8} PTNCC only EUR NO Russia Russian Central Bank Identification RUCBC [0-9]{9,9} RUCBC only RUB YES

9 9/63 Code Singapore IBG Sort Code SGIBG [0-9]{7,7} or [0-9]{3,4} (first two numbers always 04) SGIBG only SGD YES South Africa South African National Clearing Code ZANCC [0-9]{6,6} ZANCC only ZAR YES Spain Spanish Domestic Interbanking Code ESNCC [0-9]{8,9} ESNCC only EUR NO Sweden Sweden Bankgiro Clearing Code SESBA [0-9]{4,4} SESBA1234 only SEK NO Switzerland Swiss Clearing Code (BC Code) CHBCC [0-9]{3,5} CHBCC12345 only CHF YES Switzerland Swiss Clearing Code (SIC Code) CHSIC [0-9]{6,6} CHSIC only CHF YES Taiwan Financial Institution Code TWNCC [0-9]{7,7} TWNCC only TWD NO UK UK Domestic Sort Code GBDSC [0-9]{6,6} GBDSC only GBP YES US CHIPS Participant Identifier USPID [0-9]{4,4} USPID1234 only USD YES US United States Routing Number (Fedwire, NACHA) USABA [0-9]{9,9} USABA only USD and EUR YES 2.6 Charge bearer codes A charge bearer code can be given at the 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. The values SHAR and TYHJÄ (empty) are changed to SLEV for SEPA credit transfers. The charge bearer codes that are possible for international payments are SHAR, DEBT, and CRED. For 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 charge bearer code SHAR is mandatory for international payments that fall under the Finnish payment services act when: - The payee 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, charge bearer code DEBT is possible also. 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 charge bearer codes DEBT and CRED to SHAR for payments that fall under the payment services act. 2.7 Requirements for implementation 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. 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.

10 2.8 The testing environment 10/63 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, usernames, and certificates. Also, the functionality of the testing environment is 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 attachment, provided that the structural validity of the attached payload has been checked against the schema. For more information on testing, please contact opk-sepa@op.fi. The customer sends the C2B payload to the testing environment in the same way as to the production environment. The customer will receive first-level (technical validation) and second-level (customer profile check) status reports automatically for the payload sent. At present, the testing environment does not create third-level report messages and account statements. 2.9 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 will contain the customer ID, payment identifier, and payment accounts specified in the C2B agreement. In the Web Services channel, the customer will 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 is instructed in the Web Services channel application guide URLs Please contact opk-sepa@op.fi to obtain IDs and keys for the testing environment. The testing environment URL is: The WSDL description for services of the testing environment is available here: The WSDL description for the authentication service of the testing environment is available here: The general descriptions and XML schemas of the services are available from the Federation of Finnish Financial Services Web site at the following URL: Limitations of the testing environment The maximum size limit for 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.

11 11/63 Only a C2B payload can be sent to the client testing environment (pain ). The payload sent is checked, and responses are created for the technical validation and customer profile (first-level and second-level reports). The client testing environment does not create reports on successful payments (third-level reports) Negotiations and transaction information CLEARING S FOR DOMESTIC AND INTERNATIONAL TRANSACTIONS Clearing services for domestic transactions Mon. Fri., 9am to 4:30pm: Phone ( 1.50/min. + local network charges). The service will instruct you how to proceed. Fax opk-mlselvittely@op.fi. Account transaction Direct debit Payment terminal Invoice payment Payment order Recurring payment Automatic balance transfer E-invoice payment via OP online service Outgoing SEPA Incoming SEPA C2B debit C2B credit Transaction identifier 5SV 5MT and 5EM 5LM 5LM 5TS 5SNG 5FVT UTU UTZ 5UTV 5UTH Other transactions Cash management service Deletion of material Clearing services for international payments and SEPA credit transfers Mon. Fri., 9am to 4:30pm: Phone ( 1.50/min + local network charges). The service will instruct you how to proceed. Fax Clearing of international payments and SEPA credit transfers 3 C2B payment initiation message and example descriptions The first column, Index, refers to the element number according to the ISO 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 (see Payments_Standards-Initiation.pdf). The second column, Number, contains the number of element occurrences according to the schema the element is optional, and there can be only one occurrence the element is mandatory, and there must be only one occurrence the element is optional, and there can be max. two occurrences 0..n - the element is optional, and there can be several occurrences 1..n - the element is mandatory, and there can be several occurrences

12 12/63 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 the name indicate how deep in the XML structure the element is. The fifth column, Description, contains a brief description of how the element is to be used. The sixth column, Additional information, contains additional instructions (if any). The messages have the following structure: 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 due date and debit account. A separate Payment Information level will be created for credit transfers that use the SALA code and have the same due date and debit account. If the customer has agreed with the bank on use of the SDVA code, a separate batch will be created for these transactions. Transaction Information there can be more than one. This level contains the information for a single credit transfer transaction. 3.1 Group Header The Mandatory column contains an X if the OP-Pohjola Group Central Cooperative requires an element that is marked as optional in the schema. Index Num ber Mand atory * (=X) Element Example content Description GrpHdr Each message must contain at least one block of this kind that contains common information for the message MsgId Message ID given by the payer, which must be checks the ID to identify duplicates CreDtTm T09:00:01+02:00 Date and time of the message s creation by the payer, mandatory NbOfTxs 10 The number of individual transactions, or by the payer, mandatory; the bank will not check the information given CtrlSum Not mandatory. Arithmetic sum of the amounts contained in the message; foreign currencies have no effect on the sum, and the Bank will not check the information supplied Grpg MIXD Mandatory element the values allowed are GRPD, SNGL, and MIXD MIXD the message has one or several occurrences of the PmtInf block, where each may contain one or several occurrences of the CdtTrfTxInf block The payload is processed as if the value were MIXD.

13 13/ InitgPty Nm Firma Oy Name of message creator PstlAdr Postal address of message creator AdrLine Teollisuuskatu 1 Street address AdrLine Helsinki Postal code and location Ctry FI Mandatory if AdrLine is given: country code under ISO3166; according to Alpha SEPA credit transfer Index Num ber Man dator y* (=X) Element SEPA credit transfer example content Description n PmtInf Each message must contain at least one block of this kind that contains common information for the transfers and the debit information PmtInfId Not mandatory but recommended, a reference assigned by the payer to identify payment information not passed on to the payee PmtMtd TRF Mandatory the values allowed are TRF, CHK, and TRA The only code allowed for SEPA credit transfers is TRF. The CHK value gives instruction to process the credit transfer as a cheque. Cheque information is primarily checked from element If element 2.47 is empty and this element has the value CHK, the value BCHQ is conveyed to transaction level, to element PmtTpInf InstrPrty Urgency of payment the codes allowed are: NORM processed by the payer s bank as a normal payment order; this is the only urgency code allowed for SEPA credit transfers HIGH processed by the payer s bank as an urgent payment order; does not require that the payee s bank process the transfer as an urgent payment order (HIGH is not allowed for SEPA credit transfers) The information is primarily retrieved from element If it is empty, the information contained in this element (if any) is used for the transaction SvcLvl Cd SEPA The values allowed are SEPA, SDVA, and PRPT

14 14/ CtgyPurp Not a mandatory payment category code. The code SALA must be used to identify recurrent SEPA credit transfers; see 2.64 (Purpose). Payment batches that use the code SALA will be debited from the account on the due date and are credited to the payee on the banking day following the due date ReqdExctnDt The requested execution date mandatory may be no more than 365 days in the future Note: The SALA due date must be a banking day. If it is not, the batch will be rejected Dbtr Mandatory payer information Nm Firma Oy The bank passes on the payer s name used in the C2B agreement PstlAdr AdrLine The bank passes on the payer s address used in the C2B agreement Ctry FI The country code is mandatory for the payer s address if an address is given X ++Id Information used to identify the customer s payload at the bank and to provide information about the payer to the payee The customer provides the payment identifier, which the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory. In addition, the customer can give one business identifier in a SEPA credit transfer. The ID is not observed in international payments. The only ID observed for international payments is the payment identifier. 1. Payment identifier*) mandatory 9 11 characters the same as in the customer s C2B agreement given in the OrgId.BkPtyId element not passed on to the payee 2. Business ID optional item either a business ID or a personal ID business IDs (OrgId) allowed: BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, and PrtryId

15 15/ DbtrAcct Mandatory passed on to the payee s bank Id IBAN FI For SEPA credit transfers, the account number {Or is always given in IBAN format The debit account in OP-Pohjola Group must always be in the IBAN format Or Or} +++BBAN +++PrtryAcct When the debit account is not with OP-Pohjola Group, it can be in the BBAN format (letters and numbers allowed). For SEPA credit transfers, it is not possible to give an account number in the BBAN format. When the debit account is not with OP-Pohjola Group, it can be in a proprietary format (using numbers, letters, and punctuation marks) For SEPA credit transfers, it is not possible to give an account number in the proprietary format Ccy EUR DbtrAgt Payer s bank information mandatory FinInstnId BIC OKOYFIHH UltmtDbtr Original payer not mandatory Nm The name of the original payer is passed on by a SWIFT MT103 message to the message field (field 70), preceded by B/O ( By order of ) ChrgBr SLEV The charge bearer code can be given for each individual transaction; If there is no transaction-specific charge bearer code, this field is checked n +CdtTrfTxInf Credit transfer transaction information The charge bearer code for SEPA credit transfers is SLEV. For SEPA credit transfers, the code values SHAR and TYHJÄ (empty) are changed to SLEV. The codes possible for international payments are SHAR, DEBT, and CRED. For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR. At least one block of this kind is required PmtId Mandatory payment identification InstrId Identification assigned to the payment by the payer, passed on to the messages sent to the

16 16/ EndToEndI d payer and account statement (customer s own information) but not passed on to the payee Mandatory end-to-end identification, or unique identification assigned by the payer to identify the transaction always passed on to the payee but passed on to the payer only for single 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) s line 1, preceded by /ROC/ ( Ordering Customer Reference ) PmtTpInf Payment type information for the bank InstrPrty NORM Urgency of payment the codes allowed are: NORM processed by the payer s bank as a normal payment order; this is the only urgency code allowed for SEPA credit transfers HIGH processed by the payer s bank as an urgent payment order, which does not require that the payee s bank process the transfer as an urgent payment order; HIGH is not allowed for SEPA credit transfers The information is primarily retrieved from this element. If this element has no value, the value in element 2.4 (if any) is used for the transaction SvcLvl Service Level, not used information is given at the PmtInf level (i.e., in element 2.6) CtgyPurp Payment category code, the only value allowed is TAXS tax-related message In Finland, SEPA credit transfers to the Finnish tax authorities that contain a tax-related message must use the code TAXS and reference (2.105) as well as the so-called tax message (2.108) Amt Mandatory information for the amount payable InstdAmt 150 Amount payable InstdAmt attribute 'Ccy' EUR Currency of the instructed amount XchgRateInf Exchange rate information CtrctId Currency exchange deal number i.e., rate reference, which is used only in international payments ChrgBr Charge bearer code can be given for each individual transaction For SEPA credit transfers, the code values

17 17/63 SHAR and TYHJÄ (empty) are changed to SLEV. The codes possible for international payments are SHAR, DEBT, and CRED ChqInstr For international payments, the code values SLEV and TYHJÄ (empty) are changed to SHAR ChqTp For foreign-currency cheques, the value is BCHQ Values CCCH, CCHQ, DRFT, and ELDR are changed to BCHQ. The CHK value in element 2.2 gives instruction to process the credit transfer as a cheque. Cheque information is primarily checked from this element. If this element is empty and element 2.2 contains the value CHK, the value used for this element is BCHQ DlvryMtd Cheque delivery method Prtry For a SWIFT cheque, the mandatory value is SWIFT CdtrAgt FinInstnId {Or ++++BIC GENODEFF The BIC code of the payee s bank is mandatory for SEPA credit transfers CmbndId Or} ClrSysM Clearing code mbid Id The clearing code of the payee 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 payee s bank are mandatory with a clearing code Nm In international payments, the name of the payee s bank is mandatory if a BIC code is not given and/or the payment is not identified as a cheque PstlAdr AdrLin e In international payments, the address of the payee s bank is mandatory if a BIC code is not given and/or the payment is not identified as a cheque Ctry The country code of the payee s bank is mandatory if the PstlAdr element is used X ++Cdtr Payee s name and address X +++Nm Warenhaus Köln Payee s name is mandatory PstlAdr Payee s postal address

18 18/ AdrLine Kirchenstrasse 3 In cross-border payments, the payee s postal address is mandatory; SEPA credit transfers can contain, at maximum, two addresses DE Köln StrtNm Street address is mandatory and used only in payment orders PstCd Postal code is mandatory and used only in payment orders TwnNm Town name is mandatory and used only in payment orders Ctry DE Payee s country code is mandatory if the payee s address is given Id Payee ID {Or ++++OrgId In SEPA credit transfers, the business IDs allowed are BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, BkPtyId, and PrtryId In payment orders, it is recommended to give either the payee s Business ID or the social security number (TaxIdNb or SclSctyNb) Or} ++++PrvtId In SEPA credit transfers, the personal IDs allowed are DrvrsLicNb, CstmrNb, SclSctyNb, AlnRegnNb, PsptNb, TaxIdNb, IdntyCardNb, MplyrIdNb, DtAndPlcOfBirth, and OthrId In SEPA salary payments (payment coded as SALA), it is recommendable to use the payee s social security number (SclSctyNb). In payment orders, it is recommended to give either the payee s Business ID or the social security number (TaxIdNb or SclSctyNb) CdtrAcct DE For SEPA credit transfers, the payee s account number is always given in the IBAN format In foreign payments, the account number can also be in the BBAN or proprietary format. In payment orders, the following standard value is given as the account number: FI Payee s account is not given for foreign-currency cheques and SWIFT cheques UltmtCdtr If the payment is not a foreign-currency cheque or SWIFT cheque, an account number is mandatory and the payment is rejected if it is missing Nm Passed on for SEPA credit transfers InstrForCdtr Instructions for the creditor agent / payee bank Agt are passed on for international payments The first two instructions are observed Cd Payment instruction code according to the UNIFI standard

19 19/63 Codes currently in use: [PHOB] payee collects from the bank Paid once the payee is identified [CHQB] payment to payee by cheque InstrInf Further instructions for the foreign bank, max. 140 characters InstrForDbtr Agt Instructions for the payer s bank The only instruction code currently in use for SEPA credit transfers: [EIOHJ] no instruction Purp Purpose of payment Cd Additional information on the purpose of the SEPA credit transfer from the payer to the payee 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 2.12) contains the code SALA and this field contains one of the codes listed, the text matching the code will be passed on to the OP-Pohjola Group payee s account information. Other Purpose codes are passed on as given. Note: If the Category Purpose field (Index 2.12) does not contain the code SALA, the code provided is passed on as given RmtInf Message or reference for the payee The message may contain a Remittance Information block that can contain a Ustrd element and, at maximum, nine Strd elements. If both are given, the Strd elements are passed on to another bank in Finland and the Ustrd element for cross-border payments. In this case, the first occurrence must be data in Ustrd format: max. 140 characters option of giving invoice details using

20 20/63 code words occurrences 2 10 can be long Strd blocks: max. 280 characters each structured invoice details if tax-message payment, only one Strd block allowed Note: In the Strd block, XML tags are included in the length, in the Ustrd block only the content. The following banks operating in Finland accept invoice details for SEPA credit transfers (so-called AOS2 banks): Aktia, savings banks and local co-operative banks (HELSFIHH) Danske Bank (DABAFIHX) DnB NOR (DNBAFIHX) Handelsbanken (HANDFIHH) Nordea (NDEAFIHH) OP-Pohjola Group (OKOYFIHH) Sampo Bank (DABAFIHH) SEB (ESSEFIHX) S-Bank (SBANFIHH) Swedbank (SWEDFIHH) Tapiola Bank (TAPIFI22) Ålandsbanken (AABAFI22) The bank will not check these details but does ensure that long Strd data will be passed on to only banks that accept said data (see above); Ustrd data will be sent to other banks. For more instructions on the provision of invoice details, please consult the UNIFI Guide of the Federation of Finnish Financial Services; see Ustrd Unstructured message to the payee; see 2.84 In international payments, the purpose of the payment (max. 140 characters) is given in this field. Max. 1 occurrence. The information is conveyed to the message field (field 70) by a SWIFT MT 103 message. It should be noted also that EndToEndId (2.26) is placed at the beginning of the message field. If provided in the payload, CdtrRef (2.105) and UltmtDbtr/Nm (2.19) are also used. This information decreases the number of characters available for the free-format message n +++Strd Structured message to the payee; see RfrdDocI nf RfrdDoc Invoice type Tp Cd Used only if the sum has not been given CREN credit note CINV or other code invoice

21 21/63 Otherwise, the code (CREN/CINV) is determined by the total bucket (2.97 or 2.98) in which the invoice or credit note sum has been entered RfrdDoc Nb RfrdDocR ltddt n ++++RfrdDocA mt.ccy RmtdA {Or mt Or} +++++CdtNote Amt CdtrRefIn f Invoice number, not passed on for international payments Date of invoice, not in use for the time being Amount and currency of the invoice or credit note Invoice amount If the invoice type is CINV or some other code (excl. CREN), this element must be used. In international payments, the invoice amount is placed in the camt message to the payer. This datum is not passed on to the payee or the payer s account statement. Credit note amount Creditor reference information i.e., invoice or credit note reference CdtrRef Tp Cd If field contains a domestic reference, the value SCOR is given in this field Issr Indicator of the standards-based reference number that is in use CdtrRef Creditor reference e.g., Finnish reference number In cases of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the following block (2.108) AddtlRmtI nf The RF reference and other reference information is conveyed to the message field (field 70) by a SWIFT MT 103 message. Max. 140 characters of unstructured information In cases of tax payment, the code TAXS is given in 2.36 and this block contains the reference number. The tax-related message is given in the previous block (2.105). Not passed on for international payments. 3.3 Recurring SEPA credit transfers sent as a separate batch n PmtInf Example content for recurring SEPA credit transfer Each message must contain at least one block of this kind that contains common information for the transfers and the debit information

22 22/ PmtInfId Not mandatory but recommended, a reference assigned by the payer to identify payment information, not passed on to the payee PmtMtd TRF Mandatory the values allowed are TRF, CHK, and TRA The only code allowed for SEPA credit transfers is TRF. CHK instructs that the payment be processed as an international payment PmtTpInf Not mandatory SvcLvl Cd SEPA CtgyPurp The code SALA must be used to identify recurrent SALA SEPA credit transfers; see 2.64 (Purpose) Payment batches that use the code SALA will be the due date ReqdExctnDt The requested execution date mandatory may be no more than 365 days in the future Note: The SALA due date must be a banking day. If it is not, the batch will be rejected Dbtr Mandatory payer information Nm Firma Oy The bank passes on the payer s name used in the C2B agreement PstlAdr AdrLine The bank passes on the payer s address used in the C2B agreement Ctry FI The country code is mandatory for the payer s address if an address is given X*) ++Id This information is used to identify the customer s payload at the bank and to provide information about the payer to the payee The customer provides the payment identifier that the bank uses to link the payload to a service agreement i.e., checks which customer s payload this is. The payment identifier is mandatory. In addition, the customer can supply one business identifier in a SEPA credit transfer. 1. Payment identifier*) mandatory 9 11 characters the same as in the customer s C2B agreement given in the OrgId.BkPtyId element

23 23/ DbtrAcct Mandatory not passed on to the payee 2. Business ID or private ID optional can be either business ID or personal ID business IDs (OrgId) allowed: BIC, IBEI, BEI, EANGLN, USCHU, DUNS, TaxIdNb, and PrtryId passed on to the payee s bank Id IBAN FI For SEPA credit transfers, the account number is always given in IBAN format Ccy EUR DbtrAgt Mandatory payer s bank information FinInstnId BIC OKOYFIHH UltmtDbtr Not mandatory, original payer Nm ChrgBr SLEV 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 recurring SEPA credit transfers, the charge bearer code is SLEV. In recurring SEPA credit transfers, codes SHAR and TYHJÄ are changed to SLEV n +CdtTrfTxInf Payee information At least one block of this kind is required PmtId Mandatory payment identification InstrId Identification assigned to the payment by the payer, passed on to the messages sent to the payer and account statement (customer s own information) but not passed on to the payee EndToEndI d Mandatory end-to-end identification, or unique identification assigned by the payer to identify the transaction always passed on to the payee but passed on to the payer only for single payments In the absence of this information, the bank will indicate NOTPROVIDED PmtTpInf Payment type information for the bank SvcLvl Service Level not used; information is given at the PmtInf level (i.e., in element 2.6) CtgyPurp