FUNCTIONAL SPECIFICATION OF THE EKS, THE ELECTRONIC CLEARING SYSTEM

2 CONTENTS PAYMENT PROCESSING PROCEDURE .............................................................................. 3 RULES FOR PREPARING FILES............................................................................................ 7 GENERAL GUIDELINES FOR PREPARING MESSAGES................................................... 9 PAYMENT MESSAGE ........................................................................................................... 10 PAYMENT FILE CONTROL MESSAGE.............................................................................. 20 REFUND MESSAGE .............................................................................................................. 21 REFUND FILE CONTROL MESSAGE ................................................................................. 23 NOTICE OF FILE RECEPTION............................................................................................. 24 NOTICE OF FILE REJECTION ............................................................................................. 25 NOTICE OF ERRONEOUS PAYMENT MESSAGE REJECTION ...................................... 26 CONTROL MESSAGE OF ERRONEOUS PAYMENT REJECTION FILE ........................ 27 NOTICE OF PAYMENT MESSAGE TRANSMISSION....................................................... 28 CONTROL MESSAGE OF PAYMENT TRANSMISSION FILE ......................................... 29 NOTICE OF PAYMENT MESSAGE REJECTION IF THE BANK HAS BEEN EXCLUDED FROM CLEARING........................................................................................... 30 CONTROL MESSAGE OF PAYMENT REJECTION FILE OF THE BANK EXCLUDED FROM CLEARING ................................................................................................................. 31 CLEARING RESULT MESSAGE .......................................................................................... 33 FILE VALIDATION................................................................................................................ 35 CHECK OF THE BASIC HEADER BLOCK ......................................................................... 37 CHECK OF THE APPLICATION HEADER BLOCK........................................................... 37 PAYMENT MESSAGE VALIDATION ................................................................................. 37 REFUND MESSAGE VALIDATION .................................................................................... 42 ERROR CODES ...................................................................................................................... 44 DIRECTORY OF BRANCHES............................................................................................... 47 APPLICATION FOR CHANGES IN THE DIRECTORY OF BRANCHES......................... 48 NOTICE OF CHANGES IN THE DIRECTORY OF BRANCHES ....................................... 49 APPLICATION FOR CHANGES IN THE DIRECTORY OF INSTITUTIONS AND BANKS .................................................................................................................................................. 50 NOTICE OF CHANGES IN THE DIRECTORY OF INSTITUTIONS AND BANKS......... 51 WARNING MESSAGE ........................................................................................................... 52

3

PAYMENT PROCESSING PROCEDURE The payment processing procedure comprises sequential EKS procedures performed from the moment of payment initiation to its full completion (see Chart 1).
Originator's bank
Payment initiation Payment execution at the originator's bank

Bank of Latvia
EKS file reception and registration in the archives Validation of the electronic payment message Erroneous payment message rejection

Calculation of clearing positions

Net settlement

Issue of clearing results and EKS files

Beneficiary's bank
Receipt of EKS files at the beneficiary's bank Acceptance or rejection of messages at the beneficiary's bank Payment completion

Chart 1. Clearing procedures

There are two clearing cycles in the EKS, with net settlement after 10.30 a.m., but no later than by 10.45, and after 3.00 p.m., but no later than by 3.15 p.m. All payment messages submitted for clearing from 8.30 a.m. to 10.30. a.m. are processed in the first clearing cycle. All payment messages transmitted from the first clearing cycle, as well as those submitted for clearing from 10.30 a.m. to 3.00. p.m. are processed in the second clearing cycle (see Chart 2).
Timeline of EKS operation
0 :0 10 :3 0 10 :4 5

8:30

:1

5

16:00

15

First clearing cycle Net settlement of the first clearing cycle

Second clearing cycle Net settlement of the second clearing cycle Deferred net settlement

Chart 2. Timeline of the EKS operation

15

4 • Payment initiation A payment is initiated as soon as the originator's bank accepts the originator's payment order for execution. • Payment execution at the originator's bank The originator's bank shall execute the original payment order by drafting an electronic payment message, sending it (in a payment message file) to the Bank of Latvia and providing funds sufficient for fulfilling its settlement obligations on its account with the Bank of Latvia. • File receipt at the Bank of Latvia and registration in the archives The Bank of Latvia receives electronic payment message files from banks and checks the following: file name, its sequence number on the respective settlement day; file authenticity on the basis of the selected cryptographic package; presence of the control message in the file; whether the number and the amount of the included payment messages correspond to the information indicated in the control message. Having received an electronic payment message file, the Bank of Latvia validates each payment message received. Where the Bank of Latvia identifies an error in the electronic message according to the error code table, the message is not included in the calculation of clearing positions and a notice of erroneous payment message rejection is sent to the originator's bank. Where all messages are without errors, the Bank of Latvia prepares a notice of file reception, sending it immediately to the originator's bank. In the event of an erroneous payment message file the Bank of Latvia rejects the respective file and prepares a notice of file rejection, sending it immediately to the originator's bank. The Bank of Latvia registers in the archives all payment message files received, and clearing results and payment message files sent to banks. The Bank of Latvia stores the above documents in the archives for at least five years. In the event of possible dispute the Bank of Latvia provides paper copies of payment messages. Calculation of clearing positions The Bank of Latvia calculates clearing positions twice a day (at 10.45 a.m. and 3.15 p.m.), and for each bank with a negative (debit) position verifies its ability to meet its obligations. The Bank of Latvia performs the verification and debits the respective amount from the account of the respective bank with the Bank of Latvia.

5 Net settlement Where all banks are capable of meeting their settlement obligations, the Bank of Latvia effects net settlement. At this moment the originator's bank has fulfilled its settlement obligations and payment obligations are transferred to the beneficiary's bank. Where a bank is unable to meet its settlement obligations in the first clearing cycle, the Bank of Latvia, in the sequence of payment file and payment message file submission, transmits all those payment messages of the bank which cannot be executed due to insufficient funds on the bank's settlement account to the next clearing cycle, recalculates clearing results and effects net settlement. Where a bank in the first clearing cycle submits no payment messages at all, all payment messages submitted by other banks and addressed to the respective bank for settlement in this cycle are transmitted to the next clearing cycle. Where a bank is unable to meet its settlement obligations in the second clearing cycle, the settlement in the EKS is postponed until the respective bank has provided sufficient funds on its settlement account with the Bank of Latvia, but no later than by 4.00 p.m. After the above deadline the Bank of Latvia excludes the bank from clearing, rejects all payments submitted by or addressed to it, recalculates clearing results and effects net settlement. The net settlement effected at the Bank of Latvia is final and irrevocable. • Issue of clearing results and files After net settlement has been effected, the Bank of Latvia prepares clearing result files, containing information on the payment message file names included in clearing, number of payment messages and the net settlement amount, as well as payment message files, grouped by receiving bank. Files are authorised with the digital signature of the person authorised by the Bank of Latvia and sent to the receiving banks. • Receipt of files at the beneficiary's bank The beneficiary's bank receives from the Bank of Latvia a clearing result file authorised by the Bank, as well as payment message files. Upon the receipt of payment message files the beneficiary's bank validates the files in the same way the Bank of Latvia does. Should any problems arise upon the receipt of files, the beneficiary's bank shall notify the Bank of Latvia thereof no later than by the end of the current settlement day. In the event of an erroneous file the Bank of Latvia prepares a new file and sends it to the beneficiary's bank. • Acceptance or rejection of messages at the beneficiary's bank Prior to the acceptance of payment messages the beneficiary's bank shall verify the following: whether the beneficiary can be identified; whether the beneficiary's account has not been closed; whether it is not forbidden by law to credit funds to the beneficiary's account.

6 If the beneficiary's bank cannot accept the payment. the bank rejects the payment and refunds the sending bank. • Payment completion . preparing a refund message no later than during the clearing on the next settlement day.

January 1 shall be "001".7 RULES FOR PREPARING FILES File name A unique name is assigned to each file in the format cdddnnnn. E – erroneous payment rejection file. The code table PC-8/LR of the standard RST 1040-90 shall be used for Latvian language characters. E – erroneous payment rejection file. nnnn – file sequence number on the current settlement day. For information message files: A – file containing a notice of file receiption. C – file containing a notice of file rejection. Number of messages per file The maximum number of messages in a file is 999. F – payment transmission file.ENT. M – other files. R – refund file. Format Only text files shall be used. R – refund file. 2 The format of a file name for the directory of branches is described on page 45. F – payment transmission file. ddd – the date expressed as a number of days from the beginning of the current year (e.e. 1 Allowed values of the file type 1. U – payment rejection file of the bank excluded from clearing. U – payment rejection file of the bank excluded from clearing.: P – payment file. excluding the control message.g. Control Message A control message shall be included in files that according to the file type are appropriate for sending several messages. ENT – extension of an encrypted and digitally signed file. where: c – file type1. i. February 25 shall be "056") shall be the same as the date of the current settlement day. . B – file containing the directory of branches2. 2. For payment message files: P – payment file. T – clearing result file.

The procedure for drafting control messages is described on pp.8 The control message shall be included in the file irrespective of the number of messages to be sent (even if only one message is sent). and it has to be the first message in the row. 22. payment rejection file of the bank excluded from clearing (type U) or payment transmission file (type F). 26. The total number of messages in the file (excluding the control message) and their total amount shall be specified in the control message. 28 and 30. The total amount shall not be indicated in the control message included in the erroneous payment rejection file (type E). . 19.

BANKLV2X. beginning with page 10... In the field Recipient Address (12 characters)..g. Each message shall consist of the following mandatory message blocks: Name according to the SWIFT Basic Header Block Application Header Block Text Block Block identifier 1 2 4 Each message begins with the characters "01h" (SOH) and ends with the characters "03h" (EXT) and "0D0Ah" (CrLf)...XXX.g. the BIC of the receiving bank together with the branch code "XXX" shall be indicated.g.". e.. Application Header Block In the field Message Type (3 characters) of the Application Header Block. Example of Message Blocks "01h"{1:.". the respective message type shall be specified. Text Block A detailed description of the contents of each particular message is available. Basic Header Block According to the procedure stipulated by the SWIFT standard.}{2:.e.g. i. the Bank of Latvia's BIC shall be indicated in the field Recipient Address. according to the procedure stipulated by the SWIFT standard. e. The rest of the block's mandatory fields shall be filled in with any characters allowed in the block.. e.BANKLV2X. ". The rest of the block's mandatory fields shall be filled in with any characters allowed in the block. the BIC of the sending bank together with the branch code "XXX" shall be indicated in the address field LT Address (12 characters) of the Basic Header Block. 103.}{4:"CrLf" the message text follows in the defined format -}"03h""CrLf" . The message shall be drafted either in Latvian or in English. Please note that the control messages drafted by banks shall always be addressed to the Bank of Latvia. Message blocks shall be filled in according to the SWIFT standard and the instructions below. e.XXX..9 GENERAL GUIDELINES FOR PREPARING MESSAGES Messages shall be drafted in compliance with the SWIFT Standards message formats.103LACBLV2X. in capital letters only... ".XXX..

. Payment messages shall be addressed to the bank whose account with the Bank of Latvia shall be credited (the BIC of the respective receiving bank shall be indicated in the field Recipient Address of the Application Header Block).10 PAYMENT MESSAGE Payment messages shall be included in payment files (type P files). Currency Code. the message shall be addressed to the bank servicing settlements of the above institutions. C or D A. O – optional. B. Interbank Settled Amount Currency/-Instructed Amount Exchange Rate Ordering Customer Sending Institution Ordering Institution Sender's Correspondent Receiver's Correspondent Third Reimbursement Institution Intermediary Institution Account with Institution Beneficiary Customer Remittance Information Details of Charges Sender's Charges Receiver's Charges Sender to Receiver Information Regulatory Reporting Type1 M O M O O M M O M O O O O O O O M O M O O O M Format2 16x /8c/4!n1!x4!n 4!c 4!c[/30x] 3!c 6!n3!a15d 3!a15d 12d A or K [/1!a][/34x] 4!a2!a2!c[3!c] A or D A. B or D A. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see page 9). The indicators used for field formats hereinafter have been described in line with the SWIFT Standards General Information handbook. but with some exceptions: n – numbers (from 0 to 9). Preparation of MT103 Single Customer Credit Transfer Text Block Field 20 13C 23B 23E 26T 32A 33B 36 50a 51A 52a 53a 54a 55a 56a 57a 59a 70 71A 71F 71G 72 77B 1 2 Name according to the SWIFT Sender's Reference Time Indication Bank Operation Code Instruction Code Transaction Type Code Value Date. Where a message is prepared for an institution who services customer accounts but does not participate in the Bank of Latvia's payment systems. C or D A or without a special format 4*35xl 3!a 3!a15d 3!a15d 6*35xl 3*35x M – mandatory. B or D A. B or D A. A payment message shall be prepared in the SWIFT Standards MT103 Single Customer Credit Transfer message format. a – capital letters of the Latin alphabet (from A to Z).

Field 57a "Account with Institution" must also be present.11 c – capital letters of the Latin alphabet and numbers. x – capital letters of the Latin alphabet. Interbank Settled Amount" and Field 33B "Currency/Instructed Amount" shall be specified with no more than two digits after the decimal comma. At least one of the persons indicated in Field 50a "Ordering Customer" and Field 59a "Beneficiary Customer" must be a non-bank. numbers and characters '/'. Field 59a "Beneficiary Customer" shall contain the IBAN of the beneficiary.g. Where Field 57 "Account with Institution" is not present. if Field 59a "Beneficiary Customer" contains the IBAN issued by an institution which services customer accounts but is not a direct participant of the Bank of Latvia's payment systems. '. Field 33B "Currency/Instructed Amount" also must be present. Currency Code.'. Interbank Settled Amount". '?'. 3! Rules for preparing messages If the currency code presented in Field 33B "Currency/Instructed Amount is not the same as in Field 32A "Value Date. For payments involving only institutions registered in the Republic of Latvia where the amount of money is to be transferred to the beneficiary's account. However. '('. e. Currency Code. ')'.'. Interbank Settled Amount". 'CrLf'. 'SPACE'. If Field 57a "Account with Institution" contains the BIC of an institution which services customer accounts but is not a direct participant of the Bank of Latvia's payment systems. '''. Currency Code. Field length indicators: nn – maximum field length (minimum is 1). '''. Where the IBAN has been specified in Field 59a "Beneficiary Customer". The amount in Field 32A "Value Date. nn! – fixed field length. ')'. it shall correspond to the BIC indicated in Field 57 "Account with Institution". '+'. '. numbers and characters '/'. '('. '-'. Rules for checking duplicate messages . the IBAN specified in Field 59a "Beneficiary Customer" shall correspond to the BIC of the receiving bank indicated in the field Recipient Address in the Application Header Block. '?'.'. 'SPACE'. '. If Field 71F "Sender's Charges" or Field 71G "Receiver's Charges" is present. ':'. '. ':'. If Field 56a "Intermediary Institution" is present. Field 59a "Beneficiary Customer" shall contain the IBAN issued by the institution. Field 36 "Exchange Rate" must not be present. If the currency code presented in Field 33B "Currency/Instructed Amount" is the same as in Field 32A "Value Date. xl – capital letters of the Latvian and Latin alphabets. d – decimals. Field 36 "Exchange Rate" must also be present. Field 57 "Account with Institution" shall contain the BIC of the said institution. '-'. 'CrLf'. '+'.'.

PHON – please advise account with institution by phone. if any. INTC – the payment is an intra-company payment.e. the Bank Operation Code. • Field 23B "Bank Operation Code" CRED. • Field 20 "Sender's Reference".. and the Bank of Latvia shall reject them.12 The following fields shall be used for checking duplicates: • LT Address. sending a notice to this effect with a defined error code to the sending bank. a payment between two companies belonging to the same group. It is possible to indicate several processing times for a payment message. e. The optional account number line in Field 59a must not be used. Checking of duplicates does not apply to messages rejected due to errors detected. REPA – payment has a related e-Payments reference. i. the second and all subsequent payment messages received at the Bank of Latvia shall be considered duplicates.e. HOLD – beneficiary customer/claimant will call. SDVA – payment must be executed with same day value to the beneficiary. foreign exchange deal. The codes to be used in this field are as follows: BONL – payment is to be made to the beneficiary customer only. • Recipient Address. If the values of these fields are the same in two or more payment messages. (i. • Field 13C "Time Indication" The time related to the payment message processing shall be indicated in the field. • Field 23E "Instruction Code" The Instruction Code and additional information. securities transaction. pay upon identification. . shall be indicated in the field. the payment order does not provide for transfer of funds to the beneficiary's account). It is not necessary to use this field in the EKS payment messages. shall be specified in the field. PHOB – please advise/contact beneficiary/claimant by phone. Message Field Specifications • Field 20 "Sender's Reference" The unique reference number assigned by the sending bank to the payment message shall be indicated in this field. CORT – payment is made in settlement of a trade. implying that it is a credit transfer where there is no SWIFT Service Level involved. PHOI – please advise the intermediary institution by phone.g. CHQB – pay beneficiary customer only by cheque.

salaries and wages. This field may be repeated several times within one message. The value date shall be the same as the Bank of Latvia's current settlement day date. If payment is not subject to sender's charges or receiver's charges and no currency conversion takes place. TELB – please advise/contact beneficiary/claimant by the most efficient means of telecommunication. TELB. REPA. • Field 36 "Exchange Rate" . All charges withheld by the sending bank or the beneficiary's bank shall be deducted from the above amount. the currency code and the amount to be transferred to the beneficiary. Additional information after the code is only allowed where the following codes have been used: PHON. Interbank Settled Amount" This field specifies the value date. Currency Code. pensions. If the beneficiary's account number has not been specified in the customer's payment order. dividends. The currency code shall be LVL. Field 32A "Value Date. the code /HOLD/ and the respective identification data of the beneficiary shall be indicated in Field 23E. TELE. Example :23E:TELI/12345678 :23E:CHQB • Field 26T "Transaction Type Code" In this field. Currency Code. Example :26T:REF • Field 32A "Value Date. TELI or HOLD. • Field 33B "Currency/Instructed Amount" In the field. Eurostat's Code List for Balance of Payments Collection Systems may be used in the field. the code indicates the type or purpose of payment. PHOB. the currency (according to the international standard ISO 4217 Codes for the representation of currencies and funds) and the amount indicated by the ordering customer when submitting the payment shall be specified. The contents of this field has to remain unchanged throughout the payment chain. e.13 TELE – please advise account with institution by the most efficient means of telecommunication.g. TELI – Please advise the intermediary institution by the most efficient means of telecommunication. PHOI. Interbank Settled Amount" corresponds to Field 33B "Currency/Instructed Amount".

if it has been specified in the payment order submitted by the ordering customer and accepted by the ordering institution. the following requirement shall be complied with: information on the originator shall be specified. To identify an ordering customer. Example 1. tax payer's code or ID number. shall be indicated in the field. the tax payer's code shall be indicated without the two-character country code LV.g. The ordering customer's account number or the IBAN with the ordering institution shall be specified in the first row of the field. but the person's ID number shall not contain the character "-" in the format 11!n. Example :36:0. for a non-resident natural person. the code 20000000000 shall be specified instead. maximum information allowed in Field 50a shall be as follows: Format 4*35xl Explanation Name of the ordering customer or its BEI/BIC Rows 1-4 Note: When filling in the field.14 The field must be present when the sending bank has performed currency conversion. starting with Row 1. maximum information allowed in Field 50a shall be as follows: Format [/34x] 2*35xl [/ID/13x or 11!n] Explanation IBAN of the ordering customer Name of the ordering customer or its BEI/BIC Company registration number. it shall be preceded by the code /ID/. /ID/12345678901. Where a tax payer is a non-resident legal entity. using the format /34x. If a company registration number. The field shall be present in format A or K. e. the BIC or BEI shall be used instead of its name in format A . The . tax payer's code or person's ID number of the ordering customer has been specified in the customer payment order. but is not a participant of the Bank of Latvia's payment systems. tax payer's code or ID number Row 1 Rows 2 and 3 Rows 3 and 4 Example 2.e.9236 • Field 50a "Ordering Customer" The initiator of the payment. i. tax payer's code or ID number. whereas in format K the ordering customer's name shall be written in words. the ordering customer. and no empty rows are allowed. In payments to the Treasury. If the ordering customer is a customer of an institution which services customer accounts. Where the ordering customer has indicated the account number and the company registration number. the customer's IBAN assigned by the institution shall be specified. Where the ordering customer has not specified the account number and the company registration number. indicating the BIC of the above institution in Field 52a "Ordering Institution". the code 10000000000 shall be indicated instead of the tax payer's code.

• Field 57a "Account with Institution" . • Field 53a "Sender's Correspondent" The bank who is the mediator for the sending bank's payment to the receiving bank shall be specified in this field. • Field 51A "Sending Institution" The bank sending the message shall be specified in the field. When preparing a payment message. It is not necessary to use this field in the EKS payment messages. • Field 55a "Third Reimbursement Institution" This field specifies the receiver's branch. • Field 56a "Intermediary Institution" This field specifies the financial institution. BANKLV2X001. • Field 52a "Ordering Institution" Where the ordering customer is not a customer of the sending bank. If the ordering customer is a customer of a branch of the sending bank. It is not necessary to use this field in the EKS payment messages. e. the field shall be present with option D and the first 11 characters of the field shall comprise the sending bank's BIC and the branch code registered with the Bank of Latvia. between the Receiver and the account with institution. • Field 54a "Receiver's Correspondent" This field specifies the branch of the receiving bank or another bank at which the funds will be made available to the Receiver.15 examples show the sequence of presenting the maximum information on the originator allowed in the respective rows of the field. but is not a participant of the Bank of Latvia's payment systems. information on the ordering customer. may be placed in other rows if the scope of information to be provided is smaller than that specified in the above examples. through which the transaction must pass. Where Field 50a "Ordering Customer" contains the IBAN assigned by an institution which services customer accounts.g. the field shall be present with option A and the BIC of the institution which has assigned the IBAN shall be specified in the field. when the funds are made available to this branch through a financial institution other than that indicated in field 53a "Sender's Correspondent". This field need not be used in the EKS payment messages. except for the account number or the IBAN. the ordering institution shall be indicated in the field.

Example 1. • Field 59a "Beneficiary Customer" This field specifies the customer which will be paid. but is not a participant of the Bank of Latvia's payment systems. Where the beneficiary is a customer of an institution which services customer accounts. the code /ID/ shall be used before it. Where Field 59a "Beneficiary Customer" contains the IBAN assigned by an institution which services customer accounts. and the BIC of the institution which has assigned the IBAN shall be specified in Field 57a "Account with Institution". Where the beneficiary has not specified the account number and the company registration number. tax payer's code or person's ID. but is not a participant of the Bank of Latvia's payment systems. In payments to the Treasury. maximum information allowed in Field 59a shall be as follows: Format [/34x] 3*35xl [/ID/13x] Explanation The beneficiary's IBAN Name of the beneficiary Company registration number or tax payer's code. Where the beneficiary is the customer of a branch of the receiving bank. and the first 11 characters of the field shall contain the BIC of the receiving bank and the branch code registered with the Bank of Latvia. or the beneficiary's account with the institution specified in Field 57a. In format A.16 This field specifies the financial institution – when other than the Receiver – which services the account for the beneficiary customer. the field shall be present with option A and the BIC of the institution which has assigned the IBAN shall be specified in the field. tax payer's code or person's ID. the account number or the IBAN assigned to the customer shall be specified. the first row of the field shall contain the account number identifying the beneficiary's account with the receiving bank if the message contains no Field 57a. Where the beneficiary has specified the account number and the company registration number. the field shall be present with option D. tax payer's registration number or a person's ID of the beneficiary has been specified in the customer's payment order. maximum information allowed in Field 59a shall be as follows: Format 4*35xl Explanation Beneficiary's name Rows 1–4 . BEI is used to identify the ordering customer instead of its name. The field shall be present in format A or without a specific format. Where the field is present without a specific format. Where the company registration number. or person's ID Row 1 Rows 2–4 Rows 4 and 5 Example 2. there is no specific field format to be used.

the following requirement shall be complied with: information on the beneficiary shall be specified. the code HOLD and the respective identification data of the beneficiary shall be specified in Field 23E "Instruction Code". If field 71G is present. • Field 70 "Remittance Information" Information to be transmitted to the beneficiary customer which has been included in the payment order accepted by the originator's bank shall be specified in the field. The Bank of Latvia shall execute the payment message in full amount. When preparing a payment message. Examples show the sequence of presenting the maximum information on the beneficiary allowed in the respective rows of the field. without deducting the charge applied by the Bank of Latvia. • Field 71G "Receiver's Charges" This field specifies the currency and amount of the transaction charges due to the Receiver. but Field 71G is not allowed. Where the code OUR is present. Codes BEN (All transaction charges are to be borne by the beneficiary customer) or SHA (Transaction charges on the Sender's side are to be borne by the ordering customer. Note: When filling in the field. • Field 71A "Details of Charges" A code denoting the party which will bear the charges for the transaction shall be specified in this field. information on the beneficiary. starting with Row 1. • Field 71F "Sender's Charges" This field specifies the currency and amount of the transaction charges deducted by the Sender and by previous banks in the transaction chain. the Bank of Latvia charges it from the ordering institution in accordance with the tariffs for cash and securities electronic settlements as approved by the Bank of Latvia.17 If the account number of the beneficiary has not been indicated in the customer's payment order. • Field 72 "Sender to Receiver Information" . the amount must not equal "0". Where the code BEN is present. if the code SHA is used. except for the account number or the IBAN. Field 71F is optional. transaction charges on the Receiver's side are to be borne by the beneficiary customer) shall be stated where the customer has specially pointed it out in its payment order. but Field 71G is not allowed. and no empty rows are allowed. may be placed in other rows if the scope of information to be provided is smaller than that specified in the example. The code to be specified in all payments shall be OUR (All transaction charges are to be borne by the ordering customer). However. Field 71F is mandatory (at least one occurrence). Irrespective of the code of the charge indicated in the payment message. Field 71F is not allowed and Field 71G is optional.

XXX.12.55"CrLf" :50K:/LV75BANK0123456789123"CrLf" AS RĪGAS LĪNIJA BRĪVĪBAS 1. The code /INS/ shall be used to specify the Instructing Institution which instructed the Sender by a payment order to execute the transaction. placed between slashes "/". • Each code used must be between slashes "/" and appear at the beginning of a line. i."CrLf" :72:/COD/1010"CrLf" :77B:/ORDERRES/LV"CrLf" /BENEFRES/LV"CrLf" -}"03h""CrLf" .55"CrLf" :33B:LVL1510.e.06. the code /ORDERRES/ and a two-letter country code shall be used in all payments... • Field 77B "Regulatory Reporting" Where the residence of the ordering customer is to be identified. • Narrative text relating to a preceding code.XXX.. if the Instructing Institution is not the Ordering Institution indicated in Field 52a. JAUNAIS PROSPE"CrLf" KTS.103LATTLV22.: • Line 1 shall begin with a code. The format shall be /COD/10n....18 This field specifies additional information for the Receiver... PAMATSKOLA. RĪGA LA"CrLf" TVIJA /ID/LV12345678901"CrLf" :52D:BANKLV2X001"CrLf" :57D:LATTLV22003"CrLf" :59:/LV15LATT1230123456789"CrLf" RĪGAS 0. must start with a double slash "//". where 10n is the budgetary revenue code. which is continued on the next line(s)."CrLf" :71A:OUR"CrLf" :71G:LVL10.BANKLV2X.}{2:... The code /COD/ shall be used if the beneficiary is a budgetary institution and the budgetary revenue code has been specified in the customer's payment order. The field shall be filled in according to SWIFT rules. LV-1050 RĪGA"CrLf" /ID/10000001111"CrLf" :70:SAMAKSA PAR LĪGUMU NR. Example :77B:/ORDERRES/LV /BENEFRES/LV Example of a payment message "01h"{1:. A/12300987-1"CrLf" 1 2000.}{4:"CrLf" :20:01-AAA"CrLf" :23B:CRED"CrLf" :32A:000624LVL1500.. The code /BENEFRES/ and a two-letter country code shall be used only in the event the beneficiary's residence has been specified in the payment order submitted by the customer.

....55"CrLf" :33B:LVL1510.XXX..BANKLV2X.103LATTLV2X.....55"CrLf" :50K:/LV97BANK0123456789"CrLf" AS RĪGAS LĪNIJA BRĪVĪBAS 1.}{2:.BANKLV2X.....}{4:"CrLf" :20:01-AAA"CrLf" :23B:CRED"CrLf" :32A:000624LVL20.}{2:.19 Examples of payment messages addressed to the customer serviced by an institution which is not a participant of the Bank of Latvia's payment systems Payment to the Treasury: "01h"{1:.}{4:"CrLf" :20:01-AAA"CrLf" :23B:CRED"CrLf" :32A:000624LVL1500.XXX..55"CrLf" :50K:/1234509"CrLf" JĀNIS LIEPA"CrLf" /ID/50003108181"CrLf" :57A:LPNSLV21"CrLf" :59:/LV61LPNS0123456789000"CrLf" PĒTERIS LIEPA"CrLf" /ID/10105678908"CrLf" :70:PARĀDA SAMAKSA"CrLf" :71A:OUR"CrLf" :77B:/ORDERRES/LV"CrLf" /BENEFRES/LV"CrLf" -}"03h""CrLf" . RĪGA LA"CrLf" TVIJA /ID/12345678901"CrLf" :57A:TRELLV21"CrLf" :59:/LV25TREL0000123160009"CrLf" VALSTS KASE"CrLf" :70:AKCĪZES NODOKĻA SAMAKSA"CrLf" :71A:OUR"CrLf" :77B:/ORDERRES/LV"CrLf" /BENEFRES/LV"CrLf" -}"03h""CrLf" Payment to a customer of the non-profit organisation state joint stock company Latvijas pasts: "01h"{1:.XXX.32"CrLf" :33B:LVL1510.....XXX.....103LACBLV2X.

Row 1 Row 2 /TOTAL/15d Example of a payment file control message "01h"{1:..}{4:"CrLf" :20:02-AAB-008"CrLf" :79:/MSGS/062"CrLf" /TOTAL/6480.XXX. /TOTAL/ implies the total amount of payment messages included in the file. 9). Text Block Field 20 79 1 Name according to the SWIFT Transaction Reference Number Narrative Type1 M M Format 16x 35*50xl M – mandatory.70"CrLf" -}"03h""CrLf" .199LACBLV2X.. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the sending bank to the payment file control message shall be indicated in this field.. • Field 79 "Narrative" The total number and amount of payment messages included in the file shall be specified in the field.BANKLV2X...}{2:.. 15d – total amount of payment messages... The following format shall be used: Format /MSGS/3n Explanation /MSGS/ implies the total number of payment messages included in the file.. 3n – total number of payment messages.XXX.20 PAYMENT FILE CONTROL MESSAGE A payment file control message shall be prepared in the SWIFT Standards MT199 Free Format message format... The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p.

the second and all subsequent refund messages received at the Bank of Latvia shall be considered duplicates. 9). sending a notice to this effect with a defined error code to the sending bank.21 REFUND MESSAGE Refund messages shall be included in payment refund files (type R files). Currency Code. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p. Currency Code. Amount Sender's Correspondent Beneficiary Institution Sender to Receiver Information Type1 M M M O M M Format 16x 16x 6n3a15d A A 6*35xl M – mandatory. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the sending bank to the refund message shall be indicated in this field. and the Bank of Latvia shall reject them. A refund message shall be prepared in the SWIFT Standards MT202 General Financial Institution Transfer message format. O – optional. Text Block Field 20 21 32A 53a 58a 72 1 Name according to the SWIFT Transaction Reference Number Related Reference Value Date. Rules for preparing messages The amount in Field 32A "Value Date. • Recipient Address. Checking of duplicates does not apply to the messages which have not been included in clearing due to errors detected. • Field 21 "Related Reference" The field contains the reference number of the rejected payment message. Amount" must not contain more than two digits following the decimal comma. . Rules for checking duplicate messages The following fields shall be used for checking duplicate messages: • LT Address. If the values of these fields are the same in two or more refund messages. • Field 21 "Transaction Reference".

In all interbank payments the BIC of the Bank of Latvia shall be specified.. i. which is continued on the next line(s).202BANKLV2X. must start with a double slash "//". placed between slashes "/".XXX.LATTLV22. 1a2n – code of the rejection reason. relevant information on each of them shall be specified.. The following format shall be used: Format /REJECT/1a2n [5*35xl] Explanation Code /REJECT/ implies rejection of a customer payment..55"CrLf" :53A:LACBLV2XXXX"CrLf" :58A:BANKLV2XXXX"CrLf" :72:/REJECT/R03"CrLf" //KONTS SLĒGTS"CrLf" -}"03h""CrLf" .: • Line 1 shall begin with a code.22 • Field 32A "Value Date. Currency Code. except cases of direct refund to the Bank of Latvia or other institutions having opened accounts with the Bank of Latvia but not participating directly in clearing.}{2:. • Field 58a "Beneficiary Institution" The field shall contain the BIC of the bank to whose account with the Bank of Latvia the reimbursed funds shall be credited. Information explaining the customer payment rejection Row 1 Following lines The field shall be filled in according to SWIFT rules.}{4:"CrLf" :20:22-BAA"CrLf" :21:01-AAA"CrLf" :32A:000625LVL1500.XXX.. The reason for payment message rejection shall be stated in the field. The currency code shall be LVL.. The BIC specified in this field shall be the same as the BIC of the bank stated in the field Recipient Address in the Application Header Block. the settlement amount shall be the same as the amount of the rejected payment message. Amount" The value date.. Where several reasons for payment message rejection have been detected. • Each code used must be between slashes "/" and appear at the beginning of a line. The value date shall be the same as the Bank of Latvia's current settlement day date... providing also additional information for the Receiver if necessary.. • Field 53a "Sender's Correspondent" This field specifies the bank through which the Sender's bank will reimburse the Receiver.e.. Example of a refund message "01h"{1:. • Narrative text relating to a preceding code.. currency code and the settlement amount shall be indicated in the field. • Field 72 "Sender to Receiver Information" This field is mandatory in refund messages.

Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the sending bank to the refund file control message shall be indicated in this field. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p.. /TOTAL/ implies the total amount of refund messages included in the file. Row 1 Row 2 Example of a refund file control message "01h"{1:. 9).LATTLV22.}{4:"CrLf" :20:22-BAA-01"CrLf" :79:/MSGS/003"CrLf" /TOTAL/825..XXX.. Text Block Field 20 79 1 Name according to the SWIFT Transaction Reference Number Narrative Type1 M M Format 16x 35*50xl M – mandatory..}{2:. 3n – total number of refund messages.XXX.. The following format shall be used: Format /MSGS/3n /TOTAL/15d Explanation /MSGS/ implies the total number of refund messages included in the file. 15d – total amount of refund messages......00"CrLf" -}"03h""CrLf" .. • Field 79 "Narrative" The total number and amount of refund messages included in the file shall be specified in the field.23 REFUND FILE CONTROL MESSAGE A refund file control message shall be prepared in the SWIFT Standards MT199 Free Format message format.199LACBLV2X.

Format /ACCEPT/8x12n Explanation /ACCEPT/ indicates notice of file reception..}{2:. • Field 79 "Narrative" The file name and time of file reception shall be specified in the field...XXX. 12n – date and time of file reception in the following format: YYYYMMDDHHMM..24 NOTICE OF FILE RECEPTION A notice of file reception shall be included in a Type A file.. 9). 8x – file name without extension..LACBLV2X.. A notice of file reception shall be prepared in the SWIFT Standards MT999 Free Format message format.. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the notice of reception message shall be indicated in this field. Text Block Field 20 79 1 Name according to the SWIFT Transaction Reference Number Narrative Type1 M M Format 16x 35*50xl M – Mandatory.. Row 1 Example of a notice of file reception "01h"{1:.999BANKLV2X. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p..XXX..}{4:"CrLf" :20:02-AAA-001"CrLf" :79:/ACCEPT/P1750001200006241030"CrLf" -}"03h""CrLf" .

9).. Row 1 Following lines [34*50xl] Where there is more than one reason for file rejection.XXX. Example of a notice of file rejection "01h"{1:.25 NOTICE OF FILE REJECTION A notice of file rejection shall be included in a Type C file.. 8x – file name without extension. 42). Format /REJECT/8x12n1a2n Explanation /REJECT/ indicates notice of file rejection.. A notice of file rejection shall be prepared in the SWIFT Standards MT999 Free Format message format.. [34*50xl] – information explaining the rejection reason..999BANKLV2X. The reason for the rejection shall be specified according to the error code table (see p. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the notice of rejection message shall be indicated in this field.LACBLV2X. • Field 79 "Narrative" The file name and time of file reception shall be specified in the field.. information on each of them shall be specified in the above format... 12n – date and time of file reception in the following format: YYYYMMDDHHMM. Text Block Field 20 79 1 Name according to the SWIFT Transaction Reference Number Narrative Type1 M M Format 16x 35*50xl M – Mandatory.XXX..}{2:.. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p.}{4:"CrLf" :20:02-AAA-002"CrLf" :79:/REJECT/P1750002200006241033C05"CrLf" NESAKRĪT ZIŅOJUMU SKAITS"CrLf" -}"03h""CrLf" . 1a2n – code of the rejection reason..

. LAUKS 000625"CrLf" NEPAREIZS DATUMS"CrLf" T02"CrLf" 57D.26 NOTICE OF ERRONEOUS PAYMENT MESSAGE REJECTION Notices of erroneous payment message rejection shall be included in a rejection file (Type E). 9). [2*50xl] – explanatory information may take up 2 rows.. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p....XXX... The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p. Where several errors have been identified in the message. 9).}{4:"CrLf" :20:01-AAA-003"CrLf" :21:03-AAA"CrLf" :79:T01"CrLf" 32A. • Field 79 "Narrative" The error code (see p. A notice of erroneous payment message rejection shall be prepared in the SWIFT Standards MT199 Free Format message format. information on each of them shall be indicated. LAUKS LATTLV22033"CrLf" NEPAREIZS FILIĀLES KODS"CrLf" -}"03h""CrLf" .199BANKLV2X.XXX. Format 1a2n [2*50xl] Explanation 1a2n – error code. Text Block Field Name according to the SWIFT 20 Transaction Reference Number 21 Related Reference 79 Narrative 1 M – Mandatory. Type1 M M M Format 16x 16x 35*50xl Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the notice of erroneous payment message rejection shall be specified in this field..}{2:. 42) shall be specified in this field... Row 1 Rows 2 and 3 Example of a notice of erroneous payment message rejection "01h"{1:..LACBLV2X. • Field 21 "Related Reference" The reference number of the rejected erroneous payment message or refund message shall be indicated in this field.

LACBLV2X...199BANKLV22.XXX.27 CONTROL MESSAGE OF ERRONEOUS PAYMENT REJECTION FILE A control message of an erroneous payment rejection file shall be prepared in the SWIFT Standards MT199 Free Format message format.... The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p. 9).}{2:. Format /ERRMSGS/3n Explanation /ERRMSGS/ implies the number of notices included in the file. • Field 21 "Related Reference" The name (without extension in format 8x) of the respective payment file (Type P or R) containing the rejected payment messages shall be specified in the field..XXX... Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the control message of an erroneous payment rejection file shall be indicated in this field. • Field 79 "Narrative" The field shall contain the number of payment message rejection notices included in the file.. Row 1 Example of a control message of an erroneous payment rejection file "01h"{1:. Text Block Field 20 21 79 1 Name according to the SWIFT Transaction Reference Number Related Reference Narrative Type1 M M M Format 16x 16x 35*50xl M – Mandatory.. 3n – number of notices of erroneous payment message rejection.}{4:"CrLf" :20:01-AAA-004"CrLf" :21:P0623003"CrLf" :79:/ERRMSGS/001"CrLf" -}"03h""CrLf" ..

The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p. A notice of payment message transmission shall be prepared in the SWIFT Standards MT199 Free Format message format.199BANKLV2X.LACBLV2X.... Example of a notice of payment message transmission "01h"{1:..28 NOTICE OF PAYMENT MESSAGE TRANSMISSION Notices of payment message transmission are included in a transmission file (Type F file). 9).}{2:."CrLf" NORĒĶINU CIKLU.XXX. • Field 79 "Narrative" The field shall contain information with respect to which clearing cycle the payment has been transmitted to. as well as the reason thereof. • Field 21 "Related Reference" The reference number assigned to the rejected transmitted payment message or refund message shall be indicated in this field.. TRŪKST LĪDZEKĻU.}{4:"CrLf" :20:01-AAA-003"CrLf" :21:03-AAA"CrLf" :79:MAKSĀJUMA ZIŅOJUMS PĀRCELTS UZ 2.. Text Block Field 20 21 79 1 Name according to the SWIFT Transaction Reference Number Related Reference Narrative Type1 M M M Format 16x 16x 35*50xl M – Mandatory. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the notice of payment message transmission shall be specified in this field......XXX."CrLf" -}"03h""CrLf" .

Format /FRWMSGS/3n Explanation /FRWMSGS/ means the number of notices included in the file. 3n – number of notices of transmitted payment messages.XXX. Row 1 Example of a control message of a payment transmission file "01h"{1:. • Field 21 "Related Reference" The name (without extension in format 8x) of the respective payment file (Type P or R) containing the payment messages transmitted to the next clearing settlement cycle shall be specified in the field. • Field 79 "Narrative" The field shall contain the number of notices of payment transmission included in the file.}{2:..}{4:"CrLf" :20:01-AAA-004"CrLf" :21:P0623003"CrLf" :79:/FRWMSGS/001"CrLf" -}"03h""CrLf" . The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p.29 CONTROL MESSAGE OF PAYMENT TRANSMISSION FILE A control message of a payment transmission file shall be prepared in the SWIFT Standards MT199 Free Format message format...XXX.. 9).LACBLV2X. Text Block Field 20 21 79 1 Name according to the SWIFT Transaction Reference Number Related Reference Narrative Type1 M M M Format 16x 16x 35*50xl M – Mandatory.199BANKLV22....... Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the control message of a payment transmission file shall be indicated in this field..

shall be indicated in this field. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p.XXX. shall be included in a rejection file (Type U). Text Block Field 20 21 79 1 Name according to the SWIFT Transaction Reference Number Related Reference Narrative Type1 M M M Format 16x 16x 35*50xl M – Mandatory.. if the bank has been excluded from clearing..... Format 1a2n [2*50xl] Explanation Code of the message rejection reason Explanatory information Row 1 Rows 2 and 3 Example of a notice of a payment message rejection "01h"{1:.. 9). 42). A notice of payment message rejection. if the bank has been excluded from clearing..}{4:"CrLf" :20:01-AAA-018"CrLf" :21:22-AAA"CrLf" :79:U01"CrLf" LATTLV22XXX IZSLĒGTA NO KLĪRINGA"CrLf" -}"03h""CrLf" .LACBLV2X.199BANKLV2X. • Field 79 "Narrative" The field shall contain the reason for the message rejection (for error codes see p.XXX.. • Field 21 "Related Reference" The reference number of the rejected payment message or refund message shall be specified in this field.30 NOTICE OF PAYMENT MESSAGE REJECTION IF THE BANK HAS BEEN EXCLUDED FROM CLEARING A notice of payment message rejection... Message Field Specifications • Field 20 "Transaction Reference Number" The unique message reference number assigned by the Bank of Latvia to the notice of payment message rejection..}{2:. shall be prepared in the SWIFT Standards MT199 Free Format message format. if the bank has been excluded from clearing.

.XXX.. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the control message shall be indicated in this field. • Field 21 "Related Reference" The name (without extension in format 8x) of the respective payment file (Type P or R) containing the rejected payment messages shall be specified in the field.. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p...... 3n – number of notices of erroneous payment message rejection.31 CONTROL MESSAGE OF PAYMENT REJECTION FILE OF THE BANK EXCLUDED FROM CLEARING A control message of a payment rejection file of the bank excluded from clearing shall be prepared in the SWIFT Standards MT199 Free Format message format.}{4:"CrLf" :20:01-AAA-004"CrLf" :21:P0623003"CrLf" :79:/UNWMSGS/022"CrLf" -}"03h""CrLf" .LACBLV2X. • Field 79 "Narrative" The field shall contain the number of notices of payment message rejection included in the file. Format /UNWMSGS/3n Explanation /UNWMSGS/ implies the number of notices included in the file.199BANKLV22...}{2:. 9).XXX. Text Block Field 20 21 79 1 Name according to the SWIFT Transaction Reference Number Related Reference Narrative Type1 M M M Format 16x 16x 35*50xl M – Mandatory.. Row 1 Example of a control message of a payment rejection file of the bank excluded from clearing "01h"{1:.

.

The Bank of Latvia shall prepare a clearing result message in the SWIFT Standards MT999 Free Format message format.33 CLEARING RESULT MESSAGE A clearing result message shall be included in a clearing result file (Type T). Clearing result rows are numbered in ascending sequence. Message Field Specifications • Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia to the clearing result message shall be indicated in this field. O – Optional. 9). in each subsequent message the numbering continues from the previous message. starting with 1. Each file is allocated one row consisting of the following sub-fields: Sub-field 1 Format 4n Explanation Sequence number. • Field 21 "Related Reference" Where due to limits on maximum length of a message the clearing result comprises several messages. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p. • Field 79 "Narrative" All payment files included in clearing shall be specified in the field. each subsequent message in this field shall bear the reference number of the previous message. File name D – debit or C – credit Number of payment documents in the file Total amount of the payment documents 2 3 4 5 8x 1a 3n 15d . Where the clearing result contains several messages. Text Block Field 20 21 79 1 Name according to the SWIFT Transaction Reference Number Related Reference Narrative Type1 M O M Format 16x 16x 35*50xl M – Mandatory.

00"CrLf" 0002P1740002D0225000. Net position settlement date in the format YYYYMMDD D – debit or C – credit Total amount of net position Example of a clearing result message "01h"{1:. C – credit Total number of credit turnover messages Total amount of credit turnover messages Row n " Net position" Sub-field 1 2 3 4 5 Format 4n /TOTAL/ 8n 1a 15d Explanation Sequence number /TOTAL/ denotes net position.00"CrLf" 0009/TOTAL/20000624D4800.34 The last three rows are clearing result aggregating rows (n denotes the last row).XXX.999LATTLV22...00"CrLf" -}"03h""CrLf" . D – debit Total number of debit turnover messages Total amount of debit turnover messages Row n-1 "Credit turnover" Sub-field 1 2 3 4 5 Format 4n /CRTOTAL/ C 5n 15d Explanation Sequence number /CRTOTAL/ denotes credit turnover..00"CrLf" 0008/CRTOTAL/C000223700.00"CrLf" 0003P1740003D007500...LACBLV2X. Row n-2 "Debit turnover" Sub-field 1 2 3 4 5 Format 4n /DRTOTAL/ D 5n 15d Explanation Sequence number /DRTOTAL/ denotes debit turnover.00"CrLf" 0007/DRTOTAL/D000448500...XXX.00"CrLf" 0005P1740086C005500.00"CrLf" 0006P1740087C007700.}{4:"CrLf" :20:01-AAA-013"CrLf" :79:0001P1740001D0153000..}{2:..00"CrLf" 0004P1740085C0102500...

3. 4.4. 3. expressed as the number of days from the beginning of the year.3. 1. C15 – 4. in between the indications of start and end of the message ("01h" and "03h") contain the mandatory message blocks in line with the procedure stipulated on pp. 19) or a refund file control message (see p. Sequence number File extension File name length File name uniqueness File size File authenticity Status of the sending bank Sending bank's account Information authenticity Place of file origin Validity period of the key User status C03 C04 C05 C06 C07 – C08 3. and the SWIFT standard? Error code 4 – C01 C02 1.5.35 FILE VALIDATION Upon receipt of payment files. Message structure F01 . According to the SWIFT standard. which has not been suspended in the clearing system? Is the file received from the sending bank signed with the digital signature of the person authorised by the same bank? Does the file contain the digital signature of the authorised person of the sending bank. 2.2. C11 C12 3. 7)? Does the file name contain the allowed file type (see p. 7)? Does the file extension correspond to the cryptographic package used? Does the file name length correspond to the one defined in the rules for preparing files (see p. 1. correspond to the date of the current settlement day? Does the file sequence number correspond to the format specified in the rules for preparing files (see p. Items to be checked 2 File name File Type Date Explanation 3 Is the file name prepared in line with the general rules for preparing files (see p. the same as the received and encrypted file name without extension? Does the digitally signed and encrypted file not contain several files? Has the control message been prepared in line with the rules for preparing a payment file control message (see p. 1. 1.1. 22)? Should errors be detected as a result of the checks herein. in the clearing system not temporarily suspended? Is the file name without extension.7. 1 1. based on the cryptographic package used? Has the bank sending the file concluded an agreement with the Bank of Latvia on executing electronic settlements in the Bank of Latvia's clearing system? Has the sending bank's account with the Bank of Latvia not been closed? Does the file contain a valid digital signature of the person authorised by the sending bank.6. does the control message.4. 3.44 MB? Is the file received from the sending bank authentic. the file must not be accepted for clearing. C09 C10 3. 7)? Is the name of the file received from the sending bank on the respective settlement day unique? Does the size of the digitally signed and encrypted file not exceed 1. 1. who has signed the file. 3. Name of the signed file Number of the signed files Control message C14 3.1. 7)? Does the date. the Bank of Latvia performs the following checks: No.6. C13 3.1. prior to its digital signing at the sending bank. whose validity period of the key has not expired? Is the participation of the bank's authorised person.8.2. 19 and 22.3.5.

4. 35) Has the Text Block of the control message been drafted in compliance with the general guidelines for preparing messages (see p. determined by taking into account the indications of start and end of each message included in the file ("01h" and "03h")? Is the total amount of messages indicated in the control message equal to the total amount of messages included in the file. 9)? (See the check of the Application Header Block on p.3.4.3.1.2. 9)? (See the check of the Basic Header Block on p. Field 20 Field 79 Field format Field specific information Message number code Message number 3 Has the Basic Header Block of the control message been drafted in compliance with the general guidelines for preparing messages (see p.1.2.4.4.3.2. Block structure Block field sequence 4.2.3.4.2. Message aggregation Number of messages included 5.2.4. 4.3.1. 22)? Is each field of the Text Block present in an appropriate format and does it contain relevant information according to the rules for preparing a payment file control message (see p.1.3.2. 22)? Is Field 20 present in an appropriate format? Is Field 79 present in an appropriate format? 4 – – – F04 F05 – F06 – F06 – T05 T06 4. T07 T08 – C16 C17 .4.4.2.2.3.4.2. 4.3. beginning with the seventh character.2. 5.2.2. 4.36 1 4.3.2. Application Header Block 4. beginning with the eighth symbol.4. 9)? Is the Text Block present in line with the SWIFT standard? Does the Text Block contain message fields in a definite sequence according to the rules for preparing a payment file control message (see p. 4.4. 19) or a refund file control message (see p. Text Block 4. 4. 4.4.2. 4. Structure of each field 4.3. Total message amount code Total message amount 5. 19)? Does the number and total amount of messages included in the file correspond to the data specified in the control message? Is the number of messages specified in the control message equal to the number of messages included in the file (excluding the control message).3.1. 2 Basic Header Block 4. contain the total amount of messages included in the file in line with the format stipulated by the rules for preparing a payment file control message (see p. 19) or a refund file control message (see p.2. derived by aggregating the amounts specified in Field 32A of the Text Block of each message included in the file? Where the amount of any message has been specified incorrectly. 35) Has the Application Header Block of the control message been drafted in compliance with the general guidelines for preparing messages (see p. it is to be considered "0". Total amount of messages included Do the first six characters of Row 1 of this field contain the code /MSGS/? Does Row 1 of this field.4. contain the number of messages included in the file (3 digits)? Do the first seven characters of Row 2 of this field contain the code /TOTAL/? Does Row 2 of this field.

Basic Header Block – 3. 35) Error code 4 F01 2. Name of the check Block structure Check explanation Is the Application Header Block drafted in compliance with the SWIFT standard and the general guidelines for preparing messages (see p. Application Header Block – . the Bank of Latvia shall conduct the following message checks: No. 1. whose authorised person has digitally signed the file. 1 1.2. 2. 9)? (See the Application Header Block check on p. 9? Has the Basic Header Block of the payment message been drafted in line with the general guidelines for preparing messages (see p.1. 9)? Error code F03 2. the Bank of Latvia shall conduct the following checks of the Application Header Block: No. in between the indications of start and end of the message ("01h" and "03h"). 1. 2. 2.37 CHECK OF THE BASIC HEADER BLOCK Upon the receipt of messages from the sending bank. the Bank of Latvia shall conduct the following checks of the Basic Header Block: No. been specified? T01 CHECK OF THE APPLICATION HEADER BLOCK Upon the receipt of messages from the sending bank.3. 35) Has the Application Header Block of the payment message been prepared in line with the general guidelines for preparing messages (see p. Block specific information Field Message Type Field Recipient Address Status of the receiving bank – Is the message type indicated correctly? Is the BIC of the receiving bank indicated correctly? Is the receiving bank's account with the Bank of Latvia not closed? T02 T03 T04 PAYMENT MESSAGE VALIDATION Upon the receipt of messages from the sending bank. 2. Name of the check 2 Message structure Check explanation 3 Does the payment message. contain the mandatory message blocks in line with provisions stipulated on p. Block specific information Field LT Address – Has the BIC of the sending bank which is the same as the BIC of the bank. 9)? (See the Basic Header Block check on p. 9)? Error code F02 2.1. Name of the check Block structure Check explanation Is the Basic Header Block drafted in compliance with the SWIFT standard and the general guidelines for preparing messages (see p.

2.4. 4.5.1.3.3.4.3.3.3.3. 10)? Is each field of the Text Block present in an appropriate format and does it contain relevant information according to the rules for preparing a payment message (see p.3.7.6.2. does Field 23E contain the code /HOLD/? (Optional.2.) Where the beneficiary's account number is not present in Field 59a. Is Field 23E present in an appropriate format? (Optional. 4.3.4.6.3.2.2.3. 1 Amount 2 Is the amount not equal to 0 and is the digital comma present? 3 T11 4 .3.3.1. 2 Text block 3 Has the Text Block of the payment message been drafted in compliance with the general guidelines for preparing messages (see p.2.3.2.1. 4. – 4.) Is Field 13C present in an appropriate format? Optional.4. 10)? Is the Text Block present in line with the SWIFT standard? Does the Text Block contain message fields in a definite sequence according to the rules for preparing a payment message (see p.3. Amount Field 33B Field format T29 – F06 4. 4.3. 4. 4.7. Is Field 32A present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a payment message (see p.6.2. 4. 4.6. 4.3. 4. 10)? Is Field 20 present in an appropriate format? (Mandatory) Is Field 23B present in an appropriate format? (Optional.2.3.3. 4. 9) and a payment message (see p.3. F06 F06 F06 – F06 T20 4.e. Field 26T Field 32A Field format Field specific information Value date Currency code Amount F06 – F06 – T09 T10 T11 4.1.6. and does the amount contain no more than two digits following the comma? Is the maximum amount allowed per payment in clearing not exceeded? Mandatory.6. i. 4.1. 10)? Is the specified value date the same as the Bank of Latvia's current settlement day date? Has the lats code been indicated.) Is Field 26T present in an appropriate format? Mandatory. LVL? Is the amount not equal to 0. Is Field 33B present in an appropriate format? 4 – 4.3. is the digital comma present. 4.38 1 4.1.2.7.6. 4. Block structure Block field sequence Structure of each field Field 20 Field 23B Field 13C Field 23E Field format Code /HOLD/ F04 F05 4.

Does Field 53a contain the permitted option and is it present in an appropriate format? Optional. IBAN T31 4. tax payer's code or a person's ID Tax payer's code T13 T16 4.14.3.2. does the company registration number.8. 4.1.1. T22 4.2.9.3.9. has the code /ID/ been specified. Branch code field option Field 53a Field 54a T17 F07 F07 1 4.3.3.12.2.2.9.10.1. 4. 4. 4. 2 Field 55a Field 56a 3 Optional. 4. 10)? (Optional) Where the account number has been specified. Is Field 50a present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a payment message (see p. 10)? Where the field contains Option D and its first 11 characters contain the branch code. is it indicated in Row 1 in line with the procedure stipulated by the SWIFT standard? If the IBAN issued in Latvia has been specified. Does Field 52a contain the permitted option and is it present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a payment message (see p. Does Field 54a contain the permitted option and is it present in an appropriate format? – F06 T32 – F06 – T12 4. Is Field 36 present in an appropriate format? Does the exchange rate contain at least one digit and is the digital comma present? Mandatory.3.4. does the code correspond to the branch registered for the respective sending bank listed in the directory of branches? Is the branch code not indicated with field Option A? Optional.2.1.3. 4. Originator's name Company registration number.3. 4.3.10.10. 4.10.3. 4.3.3.9. Field 36 Field format Currency code Field 50a Field format Field specific information Account number Optional.3.3. does its structure correspond to that of the Latvian IBAN (inter alia.3.1.2.3.3.11.3.3.8.9.13. 4. 4. Does Field 55a contain the permitted option and is it present in an appropriate format? (Optional.8.2.2. is its control digit correct)? Has the originator's name or its BIC/BEI been specified? (Optional) Where the code /ID/ has been specified.2.2.2. followed by a tax payer's code right after it in the defined format? Optional.9. tax payer's code or a person's ID follow right after it in the defined format? Where the payment is addressed to the Treasury. Field 52a Field format Field specific information Branch code – F07 – T16 4. 4.9.9.3. 4.5.) Does Field 56a contain the permitted option and is it present in an appropriate format? 4 F07 F07 .10.39 4.3.3.2.

2 Field 71F Field 71G Field 72 3 (Mandatory or must not be present) Is Field 71F present in an appropriate format? (Optional.3.3.3.2.5.16.2.19.21.15.) Where the account number has been specified. Is Field 59a present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a payment message (see p.1. 4.15. is it indicated in Row 1 in line with the procedure stipulated by the SWIFT standard? If the IBAN issued in Latvia has been specified. 4.40 4.3. 4.20.16.3.16.3.1.2.2. Branch code field option Beneficiary's bank Field 59a Field format Field specific information Account number T17 T19 – F06 – T12 4.17. IBAN T33 4.3.) Is Field 71F present in an appropriate format? Optional.3.) Is Field 70 present in an appropriate format? (Optional. 4.3.3. has the beneficiary's bank been specified in this field? Mandatory. does the company registration number.15. does the specified IBAN correspond to the BIC of the receiving bank indicated in the Application Header Block? Has the beneficiary's name or its BIC/BEI been specified? (Optional.2.16.2.3. does the code correspond to the branch registered for the respective receiving bank listed in the directory of branches? Is the branch code not indicated with field Option A? Where Field 56a is present.15. 4. 10)? (Optional.4. Field 57a Field format Field specific information Branch code Optional.3.) Where the code /ID/ has been specified. 4. 4.1. 10)? Where the field contains Option D and its first 11 characters contain the branch code. 4.16.16.16.1.2.3.2.3.) Is Field 71A present in an appropriate format? – F07 – T16 4. is its control digit correct)? Does the specified IBAN correspond to the BIC indicated in Field 57? Where Field 57 is not present. Beneficiary's name Company registration number. tax payer's code or a person's ID follow right after it in the defined format? (Optional. IBAN T31 4. 4.2.2.3. F06 F06 1 4.3.3. 4 F06 F06 – .15.18.2. 4. 4. does its structure correspond to that of the Latvian IBAN (inter alia.3.3.3.15.3.16.2. Does Field 57a contain the permitted option and is it present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a payment message (see p. 4. tax payer's code or a person's ID Field 70 Field 71A T13 T16 4.

1.2.3.3.41 4.3.22. 4. 4.3. Field format Field specific information Field 77B Field format Sender's residence Duplicate messages Is Field 72 present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a payment message (see p. 10)? Mandatory.2.1. 4. Has Field 77B been specified in an appropriate format? Is the code /ORDERRES/ and the code of the ordering customer's country of residence present? Has the message received from the sending bank on the respective settlement day not been duplicated? F06 – – F06 T30 T21 . 4.3. 5.22.21.22.21.

3. Text Block – 4. 4. Block structure Block field sequence F04 F05 4. 9)? (See the check of the Application Header Block on p.3. 20)? Is the specified value date the same as the Bank of Latvia's current settlement day date? Has the lats code been indicated. Field 58a Field format – F07 1 4. 35) Has the Text Block of the refund message been drafted in compliance with the general guidelines for preparing messages (see p.3.3. 20)? Is the Text Block present in line with the SWIFT standard? Does the Text Block contain message fields in a definite sequence according to the rules for preparing a refund message (see p.3.2. Name of the check 2 Message structure Check explanation 3 Does the refund message. 20)? Does Field 58a contain the BIC of the receiving bank ? Error code 4 F01 2.1.42 REFUND MESSAGE VALIDATION Upon the receipt of refund messages from the sending bank. 20)? Does Field 53a contain the Bank of Latvia's BIC (except for cases when the Bank of Latvia makes the refund or a bank refunds the Bank of Latvia)? Mandatory. and does the amount contain no more than two digits following the comma? Optional.2.3.3.3. Application Header Block – 4. 4.2.4. 4. 9? Has the Basic Header Block of the refund message been drafted in compliance with the general guidelines for preparing messages (see p.3.3. 9)? (See the check of the Basic Header Block on p.2. Is Field 32A present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a refund message (see p.1. i. F06 F06 – F06 – T09 T10 T11 – F07 – T18 4. 4. LVL? Is the amount not equal to 0. 1 1. 4.2. 20)? Is each field of the Text Block present in an appropriate format and does it contain relevant information according to the rules for preparing a refund message (see p. 9) and a refund message (see p.3. 4.4.1.5. 4. 4.3. in between the indications of start and end of the message ("01h" and "03h").3.1. contain the mandatory message blocks in line with provisions stipulated on p.3.3.3.5. 4. 4.3.2. Basic Header block – 3. 2 Field specific information Bank BIC 4 – T26 .2.2.5. Structure of each field Field 20 Field 21 Field 32A Field format Field specific information Value date Currency code Amount Field 53a Field format Field specific information Bank of Latvia's BIC – 4.1. Does Field 53a contain option A and is it present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a refund message (see p. 20)? Is Field 20 present in an appropriate format? Is Field 21 present in an appropriate format? Mandatory.e. 4. 4.3. Does Field 58a contain option A and is it present in an appropriate format? 3 Is the information in this field presented in compliance with the rules for preparing a refund message (see p.1.2.1.2.1.3. 4.5.4.4. the Bank of Latvia shall conduct the following message checks: No.3.3.3.3.3.2. 4. 35) Has the Application Header Block of the refund message been drafted in compliance with the general guidelines for preparing messages (see p.

Field 72 Field format Field specific information Code /REJECT/ Error code Duplicate messages Mandatory. 5.6.1.3. Is Field 72 present in an appropriate format? Is the information in this field presented in compliance with the rules for preparing a refund message (see p.6.1.3. 20)? Is code /REJECT/ indicated in Row 1 of the field? Does payment rejection code in an appropriate format follow the code /REJECT/ in Row 1 of the field? Has the payment message received from the sending bank on the respective settlement day not been duplicated? – F06 – T27 T28 T21 .6.3.2.3.2.6.2.2. 4.6.3.43 4. 4. 4. 4.

44 ERROR CODES Group 1 C Error Error name code 2 3 Payment file errors C01 Unauthorised file type C02 Incorrect date Explanation 4 File name contains an unauthorised file type. The file has been signed with an expired key. The Text Block format does not comply with the stipulated standard. The length of the digitally signed file exceeds the defined one. File sequence number contained in the file name is incorrect. wrong or belongs to an authorised person recalled by the bank. File extension is not appropriate for the encryption package used. The file was received from a bank unauthorised to send files. The message structure does not comply with the stipulated standard. The file received does not contain the digital signature of the authorised person of the bank sending the file. File name length does not comply with the one defined in the rules. expressed as the number of days from the beginning of the year. The field is present in an incorrect format. unauthorised fields. The field contains unauthorised option or is present in an incorrect format. The Application Header Block format does not comply with the stipulated standard. The Basic Header Block format does not comply with the stipulated standard. or mandatory fields are not present. is not the same as the date of the current settlement day. More than one file has been included in the digitally signed and sent file. The date indicated in the file name. It is mandatory to specify the particular error after this code. Total amount of messages indicated in the control message is not the same as the total amount of messages included in the file. The Text Block contains incorrect field sequence. Total number of messages indicated in the control message is not the same as the number of messages included in the file (excluding the control message). C03 C04 C05 C06 C07 C08 Incorrect sequence number Unauthorised file extension Unauthorised length of file name Duplicated file Unauthorised file length Participation of the sending bank in clearing has been suspended Incorrect digital signature C10 C11 F File signatory is not the bank's authorised person C12 Signatory's certificate is not valid C13 File signatory's key is blocked C14 Incorrect name of the signed file C15 The encrypted file contains several files C16 Incorrect number of messages has been indicated in the control message C17 Incorrect total amount of payments has been indicated in the control message C00 Other errors Format errors F01 Incorrect message structure F02 Incorrect Basic Header Block structure F03 Incorrect Application Header Block structure F04 Incorrect Text Block structure F05 Incorrect field sequence F06 F07 Incorrect format Incorrect option or format The digital signature in the file received is erroneous. . Prior to signing the file has had a different name than the digitally signed and received file (apart from its extension). The file has been signed by a user whose participation in the clearing system has been temporarily suspended. Duplicated file name on the respective settlement day.

The message contains Field 56a. Value date is not the same as the date of the current settlement day. 1 T 2 3 Text errors T01 Incorrect BIC of the sending bank T02 T03 T04 Unauthorised message type Incorrect BIC of the receiving bank The receiving bank has been suspended from participation in clearing Code /MSGS/ is not present Number of messages has not been specified Code /TOTAL/ is not present Total amount of messages has not been specified Incorrect value date The currency specified is not LVL Incorrect amount Incorrect account number Customer name is not present Incorrect customer code 4 The BIC of the bank specified in the field LT Address is incorrect or does not correspond to the bank whose authorised person has digitally signed the respective file. Code /REJECT/ is followed by an incorrect error code. The code has not been specified in line with the stipulated procedure. The total number of messages does not follow right after the code /MSGS/. tax payer's code or a person's ID in line with the stipulated procedure. The Field does not contain the name of the originator or the beneficiary or its BIC/BEI. The currency code is not LVL. The BIC of the specified bank is not the same as the BIC of the receiving bank indicated in the refund message. The account number has not been specified in line with the SWIFT standard. The code has not been specified in line with the stipulated procedure. Code /REJECT/ has not been specified in line with the stipulated procedure. The amount has not been specified. Total amount of messages does not follow right after the code /TOTAL/. The branch code has not been specified with Option D. The field does not contain the BIC of the Bank of Latvia. The BIC of the bank specified in the field Recipient Address is incorrect. The settlement account of the bank specified in the field Recipient Address has been suspended. T05 T06 T07 T08 T09 T10 T11 T12 T13 T16 T17 T18 T19 T20 Incorrect option for the branch code BIC of the Bank of Latvia is not present Field 57 is not present Code /HOLD/ is not present Duplicate message T21 T22 T26 T27 T28 T29 Tax payer's code is not present BIC of the receiving bank has not been specified Incorrect code REJECT Incorrect rejection code The amount exceeds the defined limit . The code /ID/ is not followed by the originator's or beneficiary's company registration number. The values of fields indicated in the message and stipulated by the rules are the same as the field values of a message processed before. The field Message Type contains an unauthorised message type. but the beneficiary's bank has not been specified in Field 57a. is equal to 0 or has been specified with more than two digits after the decimal comma. Code /ID/ and a tax payer's code has not been specified in Field 50a of a payment message addressed to the Treasury. The amount exceeds the maximum amount per payment permitted in clearing.45 F00 Other errors It is mandatory to specify the particular error after this code. Code /HOLD/ is not present but is mandatory in Field 23E since Field 59a does not contain the beneficiary's account number.

T00 Other errors Rejection codes R01 Incorrect account number Where errors are found in the Text Block field. Example of error specification T25"CrLf" 72. The beneficiary's IBAN does not correspond to the BIC of the beneficiary's bank or the receiving bank. The exchange rate does not comprise at least one digit or the digital comma is not present in the field. R03 Closed account The beneficiary's account with the beneficiary's bank is closed. U02 Receiving bank is The message prepared by the sending bank is rejected as the excluded from clearing receiving bank is excluded from clearing. . or the code /HOLD/ is followed by insufficient information about the beneficiary. LAUKS. and the bank has no customer order for further transfer of funds. R02 Blocked account The beneficiary's account with the beneficiary's bank is blocked or it is forbidden to credit funds to the account according to the procedure stipulated by legislation. Codes for a bank excluded form clearing U01 Sending bank is excluded The message prepared by the sending bank is rejected as the from clearing sending bank is excluded from clearing.46 1 2 T30 3 The sender's residence has not been specified 3 IBAN 4 The code word /ORDERRES/ and the ordering customer's country of residence code are not present. R04 Erroneous beneficiary's The beneficiary's account number indicated does not data correspond to the beneficiary's name. It is mandatory to specify the particular error after this code. 1 2 T31 T32 T33 Exchange rate IBAN R U No account with the number indicated in Field 59a has been opened by the beneficiary with the beneficiary's bank. NEPAREIZS AKCEPTA DATUMS"CrLf". the number of the respective field shall be indicated before the text of the respective error. 4 The specified IBAN's structure does not correspond to that of the Latvian IBAN or the IBAN control digits have not been calculated correctly.

9999 – indicator of the complete directory of branches.2 Format 11x 70xl 70x 70xl 70x Explanation Branch code Branch name in Latvian Branch name in English Branch address in Latvian Branch address in English Information about each branch ends with the characters CrLf. Information has been listed in alphabetical order of the bank BICs. .1 Address No. containing the following fields: Field Code Name No. File structure Information about each branch shall be indicated in one row. File name File name format is Bddd9999.2 Address No.1 Name No. ddd – date (expressed as a number of days from the beginning of the current year) when the information specified in the file becomes effective.ENT. ENT – encrypted and digitally signed file extension. where: B – identifier of the directory of branches.47 DIRECTORY OF BRANCHES The Bank of Latvia shall prepare the directory of branches as a file.

48 APPLICATION FOR CHANGES IN THE DIRECTORY OF BRANCHES Date _____________________ Application No. Do not fill in if the branch is to be deleted from the directory of branches. ______________ Bank name Bank BIC Please make the following change in the directory of branches1: include a new branch delete data about a branch change data about a branch ___________________________________ x x x x x x x x x x x x x x x x (branch code) New values of banking details of the branch to be included in the directory2 Banking details Code Name in Latvian Name in English Address in Latvian Address in English New value x x x x x x x x __________________ (signature) 1 2 Only one change to be made in the directory of branches shall be specified. .

ENT. File structure Information on changes in the directory of branches contains the following fields: Field Change code Format 1a Explanation Possible values: A – the directory of branches shall be supplemented by a new branch code and name. ENT – encrypted and digitally signed file extension.2 11x 70xl 70x 70xl 70x Where the directory of branches has been supplemented with a new branch code or the information about a branch has been deleted.1 Address No.1 Name No. name or address ends with the characters CrLf. D – information about the branch shall be deleted from the directory of branches. where: B – identifier of the directory of branches. the file shall consist of two rows related to this branch. The second row with the code A and the following branch code indicates that the new information about the respective branch shall be included in the directory. Information has been compiled in alphabetical order of the bank BICs. ddd – date (expressed as a number of days from the beginning of the respective year) when the information specified in the file becomes effective. Information on the change of branch code. 0000 – indicator of changes in the directory of branches. Branch code Branch code in Latvian Branch code in English Branch address in Latvian Branch address in English Code Name No.2 Address No.49 NOTICE OF CHANGES IN THE DIRECTORY OF BRANCHES The Bank of Latvia shall draft a notice of changes in the directory of branches in line with the following rules: File name File name format shall be Bddd0000. the file shall contain one row beginning with the change code A or D respectively. . Where information about a branch already listed in the directory of branches has to be changed. The first row with the code D and the following branch code indicates that the present information about the respective branch shall be deleted.

______________ Bank name Bank BIC Please make the following change in the directory of institutions serviced by the bank1: ___________________________________ include a new institution serviced by the bank delete the institution serviced by the bank x x x x x x x x x x x x x x x x (institution code) Institution values to be included in the directory of institutions and banks2 Banking details Code Name in Latvian Name in English New value x x x x x x x x __________________ (signature) 1 2 Only one change to be made in the directory of serviced institutions shall be specified. Do not fill in if the institution is to be deleted from the directory of serviced institutions.50 APPLICATION FOR CHANGES IN THE DIRECTORY OF INSTITUTIONS AND BANKS Date _____________________ Application No. .

}{2:. Text Block Field 20 79 1 Name according to SWIFT Transaction Reference Number Narrative Type1 M M Format 16x 35*50xl M – mandatory.. comprising comprehensive information on all institutions and banks servicing them no later than on the next business day after the receipt of the application for changes.. several Type M files may be sent if necessary...299BANKLV2X.XXX.... It shall be followed by the BIC of the institution who services customer accounts and the BIC of the respective participant of the Bank of Latvia's payment systems through whom settlements with the above institution can be executed. Where the list to be sent cannot be placed in one Type M file. A notice of changes in the directory of institutions and banks servicing them shall be prepared in the SWIFT Standards MT299 Free Format message format.. 9). Field 79 "Narrative" In Row 1 of the field..}{4:"CrLf" :20:EKS4011018000130"CrLf" :79: 20041018"CrLf" TRELLV21-LACBLV2X"CrLf" LPNSLV21-HABALV22"CrLf" "CrLf" . the date when the changes take effect shall be specified.. Message Field Specifications Field 20 "Transaction Reference Number" The unique reference number assigned by the Bank of Latvia shall be indicated in this field. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p.LACBLV2X. Example of a notice of changes in the directory of institutions and banks "01h"{1:..51 NOTICE OF CHANGES IN THE DIRECTORY OF INSTITUTIONS AND BANKS A notice of changes in the directory of institutions and banks servicing them shall be included in a Type M file. In the event of any changes in the directory a complete directory shall be sent.XXX.

. Message Field Specifications • Field 20 "Transaction Reference Number" The reference number assigned by the Bank of Latvia to the warning message shall be indicated in this field. • Field 79 "Narrative" Information to the bank on the situation and its consequences.52 WARNING MESSAGE A warning message shall be included in a Type M file. A warning message shall be drafted in the SWIFT Standards MT299 Free Format message format. The Basic Header Block and Application Header Block shall be prepared in line with the general guidelines for preparing messages (see p. Text Block Field 20 79 1 Name according to the SWIFT Transaction Reference Number Narrative Type1 M M Format 16x 35*50xl M – Mandatory. 9).

Sign up to vote on this title
UsefulNot useful