Eks Funct

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 Validation of the electronic Erroneous payment message
registration in the archives payment message rejection
Calculation of clearing Net settlement Issue of clearing results and

positions EKS files
Beneficiary's bank
Receipt of EKS files at the Acceptance or rejection of Payment completion
beneficiary's bank messages at the beneficiary's
bank
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
5
0
5
:3
:4
:0
:1
8:30 16:00
10
10
15
15
First clearing cycle Second clearing cycle
Net settlement of Net settlement of Deferred net

the first clearing the second clearing settlement
cycle cycle
Chart 2. Timeline of the EKS operation

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, preparing a refund message no later than during the clearing on the next
settlement day.
• Payment completion
7
RULES FOR PREPARING FILES
File name
A unique name is assigned to each file in the format cdddnnnn.ENT, where:

c – file type1;
ddd – the date expressed as a number of days from the beginning of the current year (e.g.
January 1 shall be "001", February 25 shall be "056") shall be the same as the date of the
current settlement day;
nnnn – file sequence number on the current settlement day;
ENT – extension of an encrypted and digitally signed file.
1
Allowed values of the file type
1. For payment message files:

P – payment file;
R – refund file.
2. For information message files:
A – file containing a notice of file receiption;
C – file containing a notice of file rejection;
E – erroneous payment rejection file;
F – payment transmission file;
U – payment rejection file of the bank excluded from clearing;
T – clearing result file;
B – file containing the directory of branches2;
M – other files.
2
The format of a file name for the directory of branches is described on page 45.
Number of messages per file
The maximum number of messages in a file is 999, excluding the control message.
Format
Only text files shall be used. The code table PC-8/LR of the standard RST 1040-90 shall be
used for Latvian language characters.
Control Message
A control message shall be included in files that according to the file type are appropriate for
sending several messages, i.e.:
P – payment file;
R – refund file;
E – erroneous payment rejection file;
F – payment transmission file;
U – payment rejection file of the bank excluded from clearing.
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. The total
number of messages in the file (excluding the control message) and their total amount shall be
specified in the control message. The total amount shall not be indicated in the control
message included in the erroneous payment rejection file (type E), payment rejection file of
the bank excluded from clearing (type U) or payment transmission file (type F). The
procedure for drafting control messages is described on pp. 19, 22, 26, 28 and 30.
9
GENERAL GUIDELINES FOR PREPARING MESSAGES
Messages shall be drafted in compliance with the SWIFT Standards message formats. Each
message shall consist of the following mandatory message blocks:
Name according to the SWIFT Block identifier

Basic Header Block 1
Application Header Block 2
Text Block 4
Each message begins with the characters "01h" (SOH) and ends with the characters "03h"
(EXT) and "0D0Ah" (CrLf). The message shall be drafted either in Latvian or in English, in
capital letters only. Message blocks shall be filled in according to the SWIFT standard and the
instructions below.
Basic Header Block
According to the procedure stipulated by the SWIFT standard, 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, e.g. BANKLV2X.XXX. The rest of the block's
mandatory fields shall be filled in with any characters allowed in the block, e.g. ".".
Application Header Block
In the field Message Type (3 characters) of the Application Header Block, the respective
message type shall be specified, e.g. 103. In the field Recipient Address (12 characters),
according to the procedure stipulated by the SWIFT standard, the BIC of the receiving bank
together with the branch code "XXX" shall be indicated. Please note that the control messages
drafted by banks shall always be addressed to the Bank of Latvia, i.e. the Bank of Latvia's
BIC shall be indicated in the field Recipient Address. The rest of the block's mandatory fields
shall be filled in with any characters allowed in the block, e.g. ".".
Text Block
A detailed description of the contents of each particular message is available, beginning with
page 10.
Example of Message Blocks
"01h"{1:...BANKLV2X.XXX..........}{2:.103LACBLV2X.XXX.}{4:"CrLf"
the message text follows in the defined format
-}"03h""CrLf"
10
PAYMENT MESSAGE
Payment messages shall be included in payment files (type P files).
A payment message shall be prepared in the SWIFT Standards MT103 Single Customer
Credit Transfer message format. 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). Where a
message is prepared for an institution who services customer accounts but does not participate
in the Bank of Latvia's payment systems, the message shall be addressed to the bank servicing
settlements of the above institutions. The Basic Header Block and Application Header Block
shall be prepared in line with the general guidelines for preparing messages (see page 9).
Preparation of MT103 Single Customer Credit Transfer
Text Block
Field Name according to the SWIFT Type1 Format2

20 Sender's Reference M 16x
13C Time Indication O /8c/4!n1!x4!n
23B Bank Operation Code M 4!c
23E Instruction Code O 4!c[/30x]
26T Transaction Type Code O 3!c

32A Value Date, Currency Code, M 6!n3!a15d
Interbank Settled Amount
33B Currency/-Instructed Amount M 3!a15d
36 Exchange Rate O 12d
50a Ordering Customer M A or K
51A Sending Institution O [/1!a][/34x]
4!a2!a2!c[3!c]
52a Ordering Institution O A or D
53a Sender's Correspondent O A, B or D
54a Receiver's Correspondent O A, B or D
55a Third Reimbursement O A, B or D
Institution
56a Intermediary Institution O A, C or D
57a Account with Institution O A, B, C or D
59a Beneficiary Customer M A or without a
special format
70 Remittance Information O 4*35xl
71A Details of Charges M 3!a
71F Sender's Charges O 3!a15d
71G Receiver's Charges O 3!a15d
72 Sender to Receiver O 6*35xl
Information
77B Regulatory Reporting M 3*35x
1
M – mandatory, O – optional.
2
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),
a – capital letters of the Latin alphabet (from A to Z),
11
c – capital letters of the Latin alphabet and numbers,

x – capital letters of the Latin alphabet, numbers and characters '/', '-', '+', '?', ':', '(', ')', '.', ',', ''', 'SPACE', 'CrLf',
xl – capital letters of the Latvian and Latin alphabets, numbers and characters '/', '-', '+', '?', ':', '(', ')', '.', ',', ''',
'SPACE', 'CrLf',
d – decimals,
Field length indicators:
nn – maximum field length (minimum is 1),
nn! – fixed field length, e.g. 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, Currency Code, Interbank Settled Amount", Field 36 "Exchange
Rate" must also be present.
If the currency code presented in Field 33B "Currency/Instructed Amount" is the same as in
Field 32A "Value Date, Currency Code, Interbank Settled Amount", Field 36 "Exchange
Rate" must not be present.
At least one of the persons indicated in Field 50a "Ordering Customer" and Field 59a
"Beneficiary Customer" must be a non-bank.
If Field 56a "Intermediary Institution" is present, Field 57a "Account with Institution" must
also be present.
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,
Field 59a "Beneficiary Customer" shall contain the IBAN issued by the institution. However,
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 57 "Account with Institution" shall contain the BIC of the said institution.
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, Field 59a "Beneficiary
Customer" shall contain the IBAN of the beneficiary.
Where the IBAN has been specified in Field 59a "Beneficiary Customer", it shall correspond
to the BIC indicated in Field 57 "Account with Institution". Where Field 57 "Account with
Institution" is not present, 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.
The amount in Field 32A "Value Date, Currency Code, Interbank Settled Amount" and Field
33B "Currency/Instructed Amount" shall be specified with no more than two digits after the
decimal comma.
If Field 71F "Sender's Charges" or Field 71G "Receiver's Charges" is present, Field 33B
"Currency/Instructed Amount" also must be present.
Rules for checking duplicate messages

12
The following fields shall be used for checking duplicates:

• LT Address;
• Recipient Address;
• Field 20 "Sender's Reference".
If the values of these fields are the same in two or more payment messages, the second and all
subsequent payment messages received at the Bank of Latvia shall be considered duplicates,
and the Bank of Latvia shall reject them, sending a notice to this effect with a defined error
code to the sending bank. Checking of duplicates does not apply to messages rejected due to
errors detected.
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.
• Field 13C "Time Indication"
The time related to the payment message processing shall be indicated in the field. It is
possible to indicate several processing times for a payment message. It is not necessary to use
this field in the EKS payment messages.
• Field 23B "Bank Operation Code"
CRED, the Bank Operation Code, shall be specified in the field, implying that it is a credit
transfer where there is no SWIFT Service Level involved.
• Field 23E "Instruction Code"
The Instruction Code and additional information, if any, shall be indicated in the field.
The codes to be used in this field are as follows:

BONL – payment is to be made to the beneficiary customer only;
CHQB – pay beneficiary customer only by cheque. The optional account number line in Field
59a must not be used;
CORT – payment is made in settlement of a trade, e.g. foreign exchange deal, securities
transaction;
HOLD – beneficiary customer/claimant will call; pay upon identification; (i.e., the payment
order does not provide for transfer of funds to the beneficiary's account);
INTC – the payment is an intra-company payment, i.e. a payment between two companies
belonging to the same group;
PHON – please advise account with institution by phone;
PHOB – please advise/contact beneficiary/claimant by phone;
PHOI – please advise the intermediary institution by phone;
REPA – payment has a related e-Payments reference;
SDVA – payment must be executed with same day value to the beneficiary;
13
TELE – please advise account with institution by the most efficient means of
telecommunication;
TELB – please advise/contact beneficiary/claimant by the most efficient means of
telecommunication;
TELI – Please advise the intermediary institution by the most efficient means of
telecommunication.
Additional information after the code is only allowed where the following codes have been
used: PHON, PHOB, PHOI, REPA, TELE, TELB, TELI or HOLD. This field may be
repeated several times within one message.
If the beneficiary's account number has not been specified in the customer's payment order,
the code /HOLD/ and the respective identification data of the beneficiary shall be indicated in
Field 23E.
Example
:23E:TELI/12345678
:23E:CHQB
• Field 26T "Transaction Type Code"
In this field, the code indicates the type or purpose of payment, e.g. salaries and wages,
pensions, dividends. Eurostat's Code List for Balance of Payments Collection Systems may be
used in the field.
Example
:26T:REF
• Field 32A "Value Date, Currency Code, Interbank Settled Amount"
This field specifies the value date, the currency code and the amount to be transferred to the
beneficiary. All charges withheld by the sending bank or the beneficiary's bank shall be
deducted from the above amount. The value date shall be the same as the Bank of Latvia's
current settlement day date. The currency code shall be LVL.
• Field 33B "Currency/Instructed Amount"
In the field, 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.
If payment is not subject to sender's charges or receiver's charges and no currency conversion
takes place, Field 32A "Value Date, Currency Code, Interbank Settled Amount" corresponds
to Field 33B "Currency/Instructed Amount".
• Field 36 "Exchange Rate"

14
The field must be present when the sending bank has performed currency conversion.
Example
:36:0,9236
• Field 50a "Ordering Customer"
The initiator of the payment, i.e. the ordering customer, shall be indicated in the field.
The field shall be present in format A or K. To identify an ordering customer, the BIC or BEI
shall be used instead of its name in format A , whereas in format K the ordering customer's
name shall be written in words.
The ordering customer's account number or the IBAN with the ordering institution shall be
specified in the first row of the field, using the format /34x, if it has been specified in the
payment order submitted by the ordering customer and accepted by the ordering institution.
If the ordering customer is a customer of an institution which services customer accounts, but
is not a participant of the Bank of Latvia's payment systems, the customer's IBAN assigned by
the institution shall be specified, indicating the BIC of the above institution in Field 52a
"Ordering Institution".
If a company registration number, tax payer's code or person's ID number of the ordering
customer has been specified in the customer payment order, it shall be preceded by the code
/ID/, e.g. /ID/12345678901. In payments to the Treasury, the tax payer's code shall be
indicated without the two-character country code LV, but the person's ID number shall not
contain the character "-" in the format 11!n. Where a tax payer is a non-resident legal entity,
the code 10000000000 shall be indicated instead of the tax payer's code; for a non-resident
natural person, the code 20000000000 shall be specified instead.
Example 1. Where the ordering customer has indicated the account number and the company
registration number, tax payer's code or ID number, maximum information allowed in Field
50a shall be as follows:
Format Explanation
Row 1 [/34x] IBAN of the ordering customer
Rows 2 and 3 2*35xl Name of the ordering customer or its BEI/BIC
Rows 3 and 4 [/ID/13x or Company registration number, tax payer's code or ID number
11!n]
Example 2. Where the ordering customer has not specified the account number and the
company registration number, tax payer's code or ID number, maximum information allowed
in Field 50a shall be as follows:
Format Explanation
Rows 1-4 4*35xl Name of the ordering customer or its BEI/BIC
Note: When filling in the field, the following requirement shall be complied with: information
on the originator shall be specified, starting with Row 1, and no empty rows are allowed. The
15
examples show the sequence of presenting the maximum information on the originator
allowed in the respective rows of the field. When preparing a payment message, information
on the ordering customer, except for the account number or the IBAN, may be placed in other
rows if the scope of information to be provided is smaller than that specified in the above
examples.
• Field 51A "Sending Institution"
The bank sending the message shall be specified in the field. It is not necessary to use this
field in the EKS payment messages.
• Field 52a "Ordering Institution"
Where the ordering customer is not a customer of the sending bank, the ordering institution
shall be indicated in the field. If the ordering customer is a customer of a branch of the
sending bank, 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, e.g. BANKLV2X001.
Where Field 50a "Ordering Customer" contains the IBAN assigned by an institution which
services customer accounts, but is not a participant of the Bank of Latvia's payment systems,
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.
• 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 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. 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, 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.
• Field 56a "Intermediary Institution"
This field specifies the financial institution, between the Receiver and the account with
institution, through which the transaction must pass.
• Field 57a "Account with Institution"

16
This field specifies the financial institution – when other than the Receiver – which services
the account for the beneficiary customer. Where the beneficiary is the customer of a branch of
the receiving bank, the field shall be present with option D, 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.
Where Field 59a "Beneficiary Customer" contains the IBAN assigned by an institution which
services customer accounts, but is not a participant of the Bank of Latvia's payment systems,
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.
• Field 59a "Beneficiary Customer"
This field specifies the customer which will be paid.

The field shall be present in format A or without a specific format. In format A, BEI is used to
identify the ordering customer instead of its name. In payments to the Treasury, there is no
specific field format to be used.
Where the field is present without a specific format, 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, or the beneficiary's account with the institution specified in Field 57a.
Where the company registration number, tax payer's registration number or a person's ID of
the beneficiary has been specified in the customer's payment order, the code /ID/ shall be used
before it.
Where the beneficiary is a customer of an institution which services customer accounts, but is
not a participant of the Bank of Latvia's payment systems, the account number or the IBAN
assigned to the customer shall be specified, and the BIC of the institution which has assigned
the IBAN shall be specified in Field 57a "Account with Institution".
Example 1. Where the beneficiary has specified the account number and the company
registration number, tax payer's code or person's ID, maximum information allowed in Field
Format Explanation
Row 1 [/34x] The beneficiary's IBAN
Rows 2–4 3*35xl Name of the beneficiary
Rows 4 and [/ID/13x] Company registration number or tax payer's code, or person's ID
5
Example 2. Where the beneficiary has not specified the account number and the company
registration number, tax payer's code or person's ID, maximum information allowed in Field
Format Explanation
Rows 1–4 4*35xl Beneficiary's name
17
If the account number of the beneficiary has not been indicated in the customer's payment
order, the code HOLD and the respective identification data of the beneficiary shall be
specified in Field 23E "Instruction Code".
Note: When filling in the field, the following requirement shall be complied with: information
on the beneficiary shall be specified, starting with Row 1, and no empty rows are allowed.
Examples show the sequence of presenting the maximum information on the beneficiary
allowed in the respective rows of the field. When preparing a payment message, information
on the beneficiary, except for the account number or the IBAN, may be placed in other rows
if the scope of information to be provided is smaller than that specified in the example.
• 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.
• Field 71A "Details of Charges"
A code denoting the party which will bear the charges for the transaction shall be specified in
this field. The code to be specified in all payments shall be OUR (All transaction charges are
to be borne by the ordering customer). 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, 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.
Where the code OUR is present, Field 71F is not allowed and Field 71G is optional. Where
the code BEN is present, Field 71F is mandatory (at least one occurrence), but Field 71G is
not allowed. However, if the code SHA is used, Field 71F is optional, but Field 71G is not
allowed.
The Bank of Latvia shall execute the payment message in full amount, without deducting the
charge applied by the Bank of Latvia. Irrespective of the code of the charge indicated in the
payment message, 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.
• 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.
• Field 71G "Receiver's Charges"
This field specifies the currency and amount of the transaction charges due to the Receiver. If
field 71G is present, the amount must not equal "0".
• Field 72 "Sender to Receiver Information"

18
This field specifies additional information for the Receiver.
The code /INS/ shall be used to specify the Instructing Institution which instructed the Sender
by a payment order to execute the transaction, if the Instructing Institution is not the Ordering
Institution indicated in Field 52a.
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 format shall be
/COD/10n, where 10n is the budgetary revenue code.
The field shall be filled in according to SWIFT rules, i.e.:

• Line 1 shall begin with a code, placed between slashes "/";
• Each code used must be between slashes "/" and appear at the beginning of a line;
• Narrative text relating to a preceding code, which is continued on the next line(s), must
start with a double slash "//".
• Field 77B "Regulatory Reporting"
Where the residence of the ordering customer is to be identified, the code /ORDERRES/ and a
two-letter country code shall be used in all payments. 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.
Example
:77B:/ORDERRES/LV
/BENEFRES/LV
Example of a payment message

"01h"{1:...BANKLV2X.XXX..........}{2:.103LATTLV22.XXX.}{4:"CrLf"
:20:01-AAA"CrLf"
:23B:CRED"CrLf"
:32A:000624LVL1500,55"CrLf"
:33B:LVL1510,55"CrLf"
:50K:/LV75BANK0123456789123"CrLf"
AS RĪGAS LĪNIJA BRĪVĪBAS 1, RĪGA LA"CrLf"
TVIJA /ID/LV12345678901"CrLf"
:52D:BANKLV2X001"CrLf"
:57D:LATTLV22003"CrLf"
:59:/LV15LATT1230123456789"CrLf"
RĪGAS 0. PAMATSKOLA, JAUNAIS PROSPE"CrLf"
KTS, LV-1050 RĪGA"CrLf"
/ID/10000001111"CrLf"
:70:SAMAKSA PAR LĪGUMU NR. A/12300987-1"CrLf"
1 2000.06.12."CrLf"
:71A:OUR"CrLf"
:71G:LVL10,"CrLf"
:72:/COD/1010"CrLf"
:77B:/ORDERRES/LV"CrLf"
/BENEFRES/LV"CrLf"
-}"03h""CrLf"
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:

:20:01-AAA"CrLf"
:23B:CRED"CrLf"
:32A:000624LVL1500,55"CrLf"
:33B:LVL1510,55"CrLf"
:50K:/LV97BANK0123456789"CrLf"
AS RĪGAS LĪNIJA BRĪVĪBAS 1, 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"
/BENEFRES/LV"CrLf"
-}"03h""CrLf"
Payment to a customer of the non-profit organisation state joint stock company Latvijas pasts:
"01h"{1:...BANKLV2X.XXX..........}{2:.103LATTLV2X.XXX.}{4:"CrLf"
:20:01-AAA"CrLf"
:23B:CRED"CrLf"
:32A:000624LVL20,32"CrLf"
:33B:LVL1510,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"
/BENEFRES/LV"CrLf"
-}"03h""CrLf"
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. 9).
Text Block
Field Name according to the SWIFT Type1 Format

20 Transaction Reference Number M 16x
79 Narrative M 35*50xl
1
M – mandatory.
• 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. The following format shall be used:
Format Explanation
Row 1 /MSGS/3n /MSGS/ implies the total number of payment messages included in the
file;
3n – total number of payment messages.
Row 2 /TOTAL/15d /TOTAL/ implies the total amount of payment messages included in the
file;
15d – total amount of payment messages.
Example of a payment file control message

:20:02-AAB-008"CrLf"
:79:/MSGS/062"CrLf"
/TOTAL/6480,70"CrLf"
-}"03h""CrLf"
21
REFUND MESSAGE
Refund messages shall be included in payment refund files (type R files).
A refund message shall be prepared in the SWIFT Standards MT202 General Financial
Institution Transfer 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).
Text Block

21 Related Reference M 16x
32A Value Date, Currency Code, M 6n3a15d
Amount
53a Sender's Correspondent O A
58a Beneficiary Institution M A
72 Sender to Receiver Information M 6*35xl
1
M – mandatory, O – optional.
Rules for preparing messages
The amount in Field 32A "Value Date, Currency Code, 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;
• Recipient Address;
• Field 21 "Transaction Reference";
If the values of these fields are the same in two or more refund messages, the second and all
subsequent refund messages received at the Bank of Latvia shall be considered duplicates,
and the Bank of Latvia shall reject them, sending a notice to this effect with a defined error
code to the sending bank. Checking of duplicates does not apply to the messages which have
not been included in clearing due to errors detected.
The unique reference number assigned by the sending bank to the refund message shall be
• Field 21 "Related Reference"
The field contains the reference number of the rejected payment message.
22
• Field 32A "Value Date, Currency Code, Amount"
The value date, currency code and the settlement amount shall be indicated in the field. The
value date shall be the same as the Bank of Latvia's current settlement day date. The currency
code shall be LVL, the settlement amount shall be the same as the amount of the rejected
payment message.
• Field 53a "Sender's Correspondent"
This field specifies the bank through which the Sender's bank will reimburse the Receiver. In
all interbank payments the BIC of the Bank of Latvia shall be specified, 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.
• 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. 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.
• Field 72 "Sender to Receiver Information"
This field is mandatory in refund messages. The reason for payment message rejection shall
be stated in the field, providing also additional information for the Receiver if necessary.
Where several reasons for payment message rejection have been detected, relevant
information on each of them shall be specified. The following format shall be used:
Format Explanation
Row 1 /REJECT/1a2n Code /REJECT/ implies rejection of a customer payment;
1a2n – code of the rejection reason.
Following [5*35xl] Information explaining the customer payment rejection
lines
The field shall be filled in according to SWIFT rules, i.e.:

• Line 1 shall begin with a code, placed between slashes "/";
• Each code used must be between slashes "/" and appear at the beginning of a line;
• Narrative text relating to a preceding code, which is continued on the next line(s), must
start with a double slash "//".
Example of a refund message

"01h"{1:...LATTLV22.XXX..........}{2:.202BANKLV2X.XXX.}{4:"CrLf"
:20:22-BAA"CrLf"
:21:01-AAA"CrLf"
:32A:000625LVL1500,55"CrLf"
:53A:LACBLV2XXXX"CrLf"
:58A:BANKLV2XXXX"CrLf"
:72:/REJECT/R03"CrLf"
//KONTS SLĒGTS"CrLf"
-}"03h""CrLf"
23
REFUND FILE CONTROL MESSAGE
A refund 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. 9).
Text Block

1
M – mandatory.
The unique reference number assigned by the sending bank to the refund file control message
shall be indicated in this field.
The total number and amount of refund messages included in the file shall be specified in the
field. The following format shall be used:
Format Explanation
Row 1 /MSGS/3n /MSGS/ implies the total number of refund messages included in the file;
3n – total number of refund messages.
Row 2 /TOTAL/15d /TOTAL/ implies the total amount of refund messages included in the
file;
15d – total amount of refund messages.
Example of a refund file control message

"01h"{1:...LATTLV22.XXX..........}{2:.199LACBLV2X.XXX.}{4:"CrLf"
:20:22-BAA-01"CrLf"
:79:/MSGS/003"CrLf"
/TOTAL/825,00"CrLf"
-}"03h""CrLf"
24
NOTICE OF FILE RECEPTION
A notice of file reception shall be included in a Type A file.
A notice of file reception shall be prepared in the SWIFT Standards MT999 Free Format
Text Block

1
M – Mandatory.
The unique reference number assigned by the Bank of Latvia to the notice of reception
The file name and time of file reception shall be specified in the field.
Format Explanation
Row 1 /ACCEPT/8x12n /ACCEPT/ indicates notice of file reception;
8x – file name without extension;
12n – date and time of file reception in the following format:
YYYYMMDDHHMM.
Example of a notice of file reception

"01h"{1:...LACBLV2X.XXX..........}{2:.999BANKLV2X.XXX.}{4:"CrLf"
:20:02-AAA-001"CrLf"
:79:/ACCEPT/P1750001200006241030"CrLf"
-}"03h""CrLf"
25
NOTICE OF FILE REJECTION
A notice of file rejection shall be included in a Type C file. The reason for the rejection shall
be specified according to the error code table (see p. 42).
A notice of file rejection shall be prepared in the SWIFT Standards MT999 Free Format
Text Block

1
M – Mandatory.
The unique reference number assigned by the Bank of Latvia to the notice of rejection
The file name and time of file reception shall be specified in the field.
Format Explanation
Row 1 /REJECT/8x12n1a2n /REJECT/ indicates notice of file rejection;
8x – file name without extension;
12n – date and time of file reception in the following format:
YYYYMMDDHHMM;
1a2n – code of the rejection reason.
Following [34*50xl] [34*50xl] – information explaining the rejection reason.
lines
Where there is more than one reason for file rejection, information on each of them shall be
specified in the above format.
Example of a notice of file rejection
:20:02-AAA-002"CrLf"
:79:/REJECT/P1750002200006241033C05"CrLf"
NESAKRĪT ZIŅOJUMU SKAITS"CrLf"
-}"03h""CrLf"
26
NOTICE OF ERRONEOUS PAYMENT MESSAGE REJECTION
Notices of erroneous payment message rejection shall be included in a rejection file (Type E).
The Basic Header Block and Application Header Block shall be prepared in line with the
general guidelines for preparing messages (see p. 9).
A notice of erroneous payment message rejection shall be prepared in the SWIFT Standards
MT199 Free Format message format. The Basic Header Block and Application Header Block
Text Block

1
M – Mandatory.
The unique reference number assigned by the Bank of Latvia to the notice of erroneous
payment message rejection shall be specified in this field.
The reference number of the rejected erroneous payment message or refund message shall be
The error code (see p. 42) shall be specified in this field. Where several errors have been
identified in the message, information on each of them shall be indicated.
Format Explanation
Row 1 1a2n 1a2n – error code.
Rows 2 [2*50xl] [2*50xl] – explanatory information may take up 2 rows.
and 3
Example of a notice of erroneous payment message rejection

:20:01-AAA-003"CrLf"
:21:03-AAA"CrLf"
:79:T01"CrLf"
32A. LAUKS 000625"CrLf"
NEPAREIZS DATUMS"CrLf"
T02"CrLf"
57D. LAUKS LATTLV22033"CrLf"
NEPAREIZS FILIĀLES KODS"CrLf"
-}"03h""CrLf"
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).
Text Block

1
M – Mandatory.
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.
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 field shall contain the number of payment message rejection notices included in the file.
Format Explanation
Row 1 /ERRMSGS/3n /ERRMSGS/ implies the number of notices included in the file;
3n – number of notices of erroneous payment message rejection.
Example of a control message of an erroneous payment rejection file
"01h"{1:...LACBLV2X.XXX..........}{2:.199BANKLV22.XXX.}{4:"CrLf"
:20:01-AAA-004"CrLf"
:21:P0623003"CrLf"
:79:/ERRMSGS/001"CrLf"
-}"03h""CrLf"
28
NOTICE OF PAYMENT MESSAGE TRANSMISSION
Notices of payment message transmission are included in a transmission file (Type F file).
A notice of payment message transmission shall be prepared in the SWIFT Standards MT199
Free Format message format. The Basic Header Block and Application Header Block shall be
Text Block

1
M – Mandatory.
The unique reference number assigned by the Bank of Latvia to the notice of payment
message transmission shall be specified in this field.
The reference number assigned to the rejected transmitted payment message or refund
The field shall contain information with respect to which clearing cycle the payment has been
transmitted to, as well as the reason thereof.
Example of a notice of payment message transmission

:20:01-AAA-003"CrLf"
:21:03-AAA"CrLf"
:79:MAKSĀJUMA ZIŅOJUMS PĀRCELTS UZ 2."CrLf"
NORĒĶINU CIKLU. TRŪKST LĪDZEKĻU."CrLf"
-}"03h""CrLf"
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. The Basic Header Block and Application Header Block
Text Block

1
M – Mandatory.
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.
containing the payment messages transmitted to the next clearing settlement cycle shall be
specified in the field.
The field shall contain the number of notices of payment transmission included in the file.
Format Explanation
Row 1 /FRWMSGS/3n /FRWMSGS/ means the number of notices included in the file;
3n – number of notices of transmitted payment messages.
Example of a control message of a payment transmission file
:20:01-AAA-004"CrLf"
:21:P0623003"CrLf"
:79:/FRWMSGS/001"CrLf"
-}"03h""CrLf"
30
NOTICE OF PAYMENT MESSAGE REJECTION IF THE BANK HAS BEEN

EXCLUDED FROM CLEARING
A notice of payment message rejection, if the bank has been excluded from clearing, shall be
included in a rejection file (Type U).
A notice of payment message rejection, if the bank has been excluded from clearing, 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).
Text Block

1
M – Mandatory.
The unique message reference number assigned by the Bank of Latvia to the notice of
payment message rejection, if the bank has been excluded from clearing, shall be indicated in
this field.
The reference number of the rejected payment message or refund message shall be specified
in this field.
The field shall contain the reason for the message rejection (for error codes see p. 42).
Format Explanation
Row 1 1a2n Code of the message rejection reason
Rows 2 [2*50xl] Explanatory information
and 3
Example of a notice of a payment message rejection

:20:01-AAA-018"CrLf"
:21:22-AAA"CrLf"
:79:U01"CrLf"
LATTLV22XXX IZSLĒGTA NO KLĪRINGA"CrLf"
-}"03h""CrLf"
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. The Basic Header
Block and Application Header Block shall be prepared in line with the general guidelines for
preparing messages (see p. 9).
Text Block

1
M – Mandatory.
The unique reference number assigned by the Bank of Latvia to the control message shall be
containing the rejected payment messages shall be specified in the field.
The field shall contain the number of notices of payment message rejection included in the
file.
Format Explanation
Row 1 /UNWMSGS/3n /UNWMSGS/ implies the number of notices included in the file;
3n – number of notices of erroneous payment message rejection.
Example of a control message of a payment rejection file of the bank excluded from
clearing
:20:01-AAA-004"CrLf"
:21:P0623003"CrLf"
:79:/UNWMSGS/022"CrLf"
-}"03h""CrLf"
33
CLEARING RESULT MESSAGE
A clearing result message shall be included in a clearing result file (Type T).
The Bank of Latvia shall prepare a clearing result message in the SWIFT Standards MT999
Free Format message format. The Basic Header Block and Application Header Block shall be
Text Block

21 Related Reference O 16x
1
M – Mandatory, O – Optional.
The unique reference number assigned by the Bank of Latvia to the clearing result message
shall be indicated in this field.
Where due to limits on maximum length of a message the clearing result comprises several
messages, each subsequent message in this field shall bear the reference number of the
previous message.
All payment files included in clearing shall be specified in the field. Each file is allocated one
row consisting of the following sub-fields:
Sub-field Format Explanation

1 4n Sequence number. Clearing result rows are numbered in ascending sequence,
starting with 1. Where the clearing result contains several messages, in each
subsequent message the numbering continues from the previous message.
2 8x File name
3 1a D – debit or C – credit
4 3n Number of payment documents in the file
5 15d Total amount of the payment documents
34
The last three rows are clearing result aggregating rows (n denotes the last row).
Row n-2 "Debit turnover"

1 4n Sequence number
2 /DRTOTAL/ /DRTOTAL/ denotes debit turnover.
3 D D – debit
4 5n Total number of debit turnover messages
5 15d Total amount of debit turnover messages
Row n-1 "Credit turnover"

2 /CRTOTAL/ /CRTOTAL/ denotes credit turnover.
3 C C – credit
4 5n Total number of credit turnover messages
5 15d Total amount of credit turnover messages
Row n " Net position"

2 /TOTAL/ /TOTAL/ denotes net position.
3 8n Net position settlement date in the format YYYYMMDD
4 1a D – debit or C – credit
5 15d Total amount of net position
Example of a clearing result message
"01h"{1:...LACBLV2X.XXX..........}{2:.999LATTLV22.XXX.}{4:"CrLf"
:20:01-AAA-013"CrLf"
:79:0001P1740001D0153000,00"CrLf"
0002P1740002D0225000,00"CrLf"
0003P1740003D007500,00"CrLf"
0004P1740085C0102500,00"CrLf"
0005P1740086C005500,00"CrLf"
0006P1740087C007700,00"CrLf"
0007/DRTOTAL/D000448500,00"CrLf"
0008/CRTOTAL/C000223700,00"CrLf"
0009/TOTAL/20000624D4800,00"CrLf"
-}"03h""CrLf"
35
FILE VALIDATION
Upon receipt of payment files, the Bank of Latvia performs the following checks:
No. Items to be checked Explanation Error

code
1 2 3 4
1. File name Is the file name prepared in line with the general rules for –
preparing files (see p. 7)?
1.1. File Type Does the file name contain the allowed file type (see p. 7)? C01
1.2. Date Does the date, expressed as the number of days from the C02
beginning of the year, correspond to the date of the current
settlement day?
1.3. Sequence number Does the file sequence number correspond to the format C03
specified in the rules for preparing files (see p. 7)?
1.4. File extension Does the file extension correspond to the cryptographic C04
package used?
1.5. File name length Does the file name length correspond to the one defined in the C05
rules for preparing files (see p. 7)?
1.6. File name Is the name of the file received from the sending bank on the C06
uniqueness respective settlement day unique?
2. File size Does the size of the digitally signed and encrypted file not C07
exceed 1.44 MB?
3. File authenticity Is the file received from the sending bank authentic, based on –
the cryptographic package used?
3.1. Status of the Has the bank sending the file concluded an agreement with C08
sending bank the Bank of Latvia on executing electronic settlements in the
Bank of Latvia's clearing system?
3.2. Sending bank's Has the sending bank's account with the Bank of Latvia not C09
account been closed?
3.3. Information Does the file contain a valid digital signature of the person C10
authenticity authorised by the sending bank, which has not been
suspended in the clearing system?
3.4. Place of file origin Is the file received from the sending bank signed with the C11
digital signature of the person authorised by the same bank?
3.5. Validity period of Does the file contain the digital signature of the authorised C12
the key person of the sending bank, whose validity period of the key
has not expired?
3.6. User status Is the participation of the bank's authorised person, who has C13
signed the file, in the clearing system not temporarily
suspended?
3.7. Name of the signed Is the file name without extension, prior to its digital signing C14
file at the sending bank, the same as the received and encrypted
file name without extension?
3.8. Number of the Does the digitally signed and encrypted file not contain C15
signed files several files?
4. Control message Has the control message been prepared in line with the rules –
for preparing a payment file control message (see p. 19) or a
refund file control message (see p. 22)? Should errors be
detected as a result of the checks herein, the file must not be
accepted for clearing.
4.1. Message structure According to the SWIFT standard, does the control message, F01
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 and 22, and the
SWIFT standard?
36
1 2 3 4
4.2. Basic Header Block Has the Basic Header Block of the control message been –
drafted in compliance with the general guidelines for
preparing messages (see p. 9)? (See the check of the Basic
Header Block on p. 35)
4.3. Application Header Has the Application Header Block of the control message –
Block been drafted in compliance with the general guidelines for
preparing messages (see p. 9)? (See the check of the
Application Header Block on p. 35)
4.4. Text Block Has the Text Block of the control message been drafted in –
compliance with the general guidelines for preparing
messages (see p. 9)?
4.4.1. Block structure Is the Text Block present in line with the SWIFT standard? F04
4.4.2. Block field Does the Text Block contain message fields in a definite F05
sequence sequence according to the rules for preparing a payment file
control message (see p. 19) or a refund file control message
(see p. 22)?
4.4.3. Structure of each Is each field of the Text Block present in an appropriate –
field format and does it contain relevant information according to
the rules for preparing a payment file control message (see p.
19) or a refund file control message (see p. 22)?
4.4.3.1. Field 20 Is Field 20 present in an appropriate format? F06
4.4.3.2. Field 79 –
4.4.3.2.1. Field format Is Field 79 present in an appropriate format? F06
4.4.3.2.2. Field specific –
information
4.4.3.2.2.1. Message number Do the first six characters of Row 1 of this field contain the T05
code code /MSGS/?
4.4.3.2.2.2. Message number Does Row 1 of this field, beginning with the seventh T06
character, contain the number of messages included in the file
(3 digits)?
4.4.3.2.2.3. Total message Do the first seven characters of Row 2 of this field contain the T07
amount code code /TOTAL/?
4.4.3.2.2.4. Total message Does Row 2 of this field, beginning with the eighth symbol, T08
amount 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)?
5. Message Does the number and total amount of messages included in –
aggregation the file correspond to the data specified in the control
message?
5.1. Number of Is the number of messages specified in the control message C16
messages included equal to the number of messages included in the file
(excluding the control message), determined by taking into
account the indications of start and end of each message
included in the file ("01h" and "03h")?
5.2. Total amount of Is the total amount of messages indicated in the control C17
messages included message equal to the total amount of messages included in the
file, 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, it is to be considered "0".
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. Name of the check Check explanation Error

code
1. Block structure Is the Basic Header Block drafted in compliance with the F02
SWIFT standard and the general guidelines for preparing
2. Block specific –
information
2.1. Field LT Address Has the BIC of the sending bank which is the same as the T01
BIC of the bank, whose authorised person has digitally
signed the file, been specified?
CHECK OF THE APPLICATION HEADER BLOCK
following checks of the Application Header Block:

code
1. Block structure Is the Application Header Block drafted in compliance with F03
the SWIFT standard and the general guidelines for preparing
2. Block specific –
information
2.1. Field Message Type Is the message type indicated correctly? T02
2.2. Field Recipient Is the BIC of the receiving bank indicated correctly? T03
Address
2.3. Status of the Is the receiving bank's account with the Bank of Latvia not T04
receiving bank closed?
PAYMENT MESSAGE VALIDATION
following message checks:

code
1 2 3 4
1. Message structure Does the payment message, in between the indications of F01
start and end of the message ("01h" and "03h"), contain the
mandatory message blocks in line with provisions stipulated
on p. 9?
2. Basic Header Has the Basic Header Block of the payment message been –
Block drafted in line with the general guidelines for preparing
messages (see p. 9)? (See the Basic Header Block check on
p. 35)
3. Application Has the Application Header Block of the payment message –
Header Block been prepared in line with the general guidelines for
preparing messages (see p. 9)? (See the Application Header
Block check on p. 35)
38
1 2 3 4
4. Text block Has the Text Block of the payment message been drafted in –
messages (see p. 9) and a payment message (see p. 10)?
4.1. Block structure Is the Text Block present in line with the SWIFT standard? F04
4.2. Block field Does the Text Block contain message fields in a definite F05
sequence sequence according to the rules for preparing a payment
message (see p. 10)?
4.3. Structure of each Is each field of the Text Block present in an appropriate –
the rules for preparing a payment message (see p. 10)?
4.3.1. Field 20 Is Field 20 present in an appropriate format? F06
4.3.2. Field 23B (Mandatory) Is Field 23B present in an appropriate format? F06
4.3.3. Field 13C (Optional.) Is Field 13C present in an appropriate format? F06
4.3.4. Field 23E Optional. –
4.3.4.1. Field format Is Field 23E present in an appropriate format? F06
4.3.4.2. Code /HOLD/ (Optional.) Where the beneficiary's account number is not T20
present in Field 59a, does Field 23E contain the code
/HOLD/?
4.3.5. Field 26T (Optional.) Is Field 26T present in an appropriate format? F06
4.3.6. Field 32A Mandatory. –
4.3.6.1. Field format Is Field 32A present in an appropriate format? F06
4.3.6.2. Field specific Is the information in this field presented in compliance with –
information the rules for preparing a payment message (see p. 10)?
4.3.6.2.1. Value date Is the specified value date the same as the Bank of Latvia's T09
current settlement day date?
4.3.6.2.2. Currency code Has the lats code been indicated, i.e. LVL? T10
4.3.6.2.3. Amount Is the amount not equal to 0, is the digital comma present, T11
and does the amount contain no more than two digits
following the comma?
4.3.6.2.4. Amount Is the maximum amount allowed per payment in clearing not T29
exceeded?
4.3.7. Field 33B Mandatory. –
4.3.7.1. Field format Is Field 33B present in an appropriate format? F06
4.3.7.2. Amount Is the amount not equal to 0 and is the digital comma T11
present?
1 2 3 4
39
4.3.8. Field 36 Optional. –
4.3.8.1. Field format Is Field 36 present in an appropriate format? F06
4.3.8.2. Currency code Does the exchange rate contain at least one digit and is the T32
digital comma present?
4.3.9. Field 50a Mandatory. –
4.3.9.1. Field format Is Field 50a present in an appropriate format? F06
4.3.9.2.1. Account number (Optional) Where the account number has been specified, is T12
it indicated in Row 1 in line with the procedure stipulated by
the SWIFT standard?
4.3.9.2.2. IBAN If the IBAN issued in Latvia has been specified, does its T31
structure correspond to that of the Latvian IBAN (inter alia,
is its control digit correct)?
4.3.9.2.3. Originator's name Has the originator's name or its BIC/BEI been specified? T13
4.3.9.2.4. Company (Optional) Where the code /ID/ has been specified, does the T16
registration number, company registration number, tax payer's code or a person's
tax payer's code or ID follow right after it in the defined format?
a person's ID
4.3.9.2.5. Tax payer's code Where the payment is addressed to the Treasury, has the T22
code /ID/ been specified, followed by a tax payer's code
right after it in the defined format?
4.3.10. Field 52a Optional. –
4.3.10.1. Field format Does Field 52a contain the permitted option and is it present F07
in an appropriate format?
4.3.10.2.1. Branch code Where the field contains Option D and its first 11 characters T16
contain the branch code, does the code correspond to the
branch registered for the respective sending bank listed in
the directory of branches?
4.3.10.2.2. Branch code field Is the branch code not indicated with field Option A? T17
option
4.3.11. Field 53a Optional. Does Field 53a contain the permitted option and is F07
it present in an appropriate format?
1 2 3 4
4.3.14. Field 56a (Optional.) Does Field 56a contain the permitted option and F07
is it present in an appropriate format?
40
4.3.15.1. Field format Does Field 57a contain the permitted option and is it present F07
in an appropriate format?
4.3.15.2.1. Branch code Where the field contains Option D and its first 11 characters T16
contain the branch code, does the code correspond to the
branch registered for the respective receiving bank listed in
the directory of branches?
4.3.15.2.2. Branch code field Is the branch code not indicated with field Option A? T17
option
4.3.15.2.3. Beneficiary's bank Where Field 56a is present, has the beneficiary's bank been T19
specified in this field?
4.3.16.1. Field format Is Field 59a present in an appropriate format? F06
4.3.16.2.1. Account number (Optional.) Where the account number has been specified, is T12
it indicated in Row 1 in line with the procedure stipulated by
the SWIFT standard?
4.3.16.2.2. IBAN If the IBAN issued in Latvia has been specified, does its T31
structure correspond to that of the Latvian IBAN (inter alia,
is its control digit correct)?
4.3.16.2.3. IBAN Does the specified IBAN correspond to the BIC indicated in T33
Field 57? Where Field 57 is not present, does the specified
IBAN correspond to the BIC of the receiving bank indicated
in the Application Header Block?
4.3.16.2.4. Beneficiary's name Has the beneficiary's name or its BIC/BEI been specified? T13
4.3.16.2.5. Company (Optional.) Where the code /ID/ has been specified, does the T16
registration number, company registration number, tax payer's code or a person's
tax payer's code or ID follow right after it in the defined format?
a person's ID
4.3.17. Field 70 (Optional.) Is Field 70 present in an appropriate format? F06
4.3.18. Field 71A (Optional.) Is Field 71A present in an appropriate format? F06
1 2 3 4
4.3.19. Field 71F (Mandatory or must not be present) Is Field 71F present in F06
an appropriate format?
4.3.20. Field 71G (Optional.) Is Field 71F present in an appropriate format? F06
4.3.21. Field 72 Optional. –

41
4.3.22. Field 77B Mandatory. –
4.3.22.1. Field format Has Field 77B been specified in an appropriate format? F06
4.3.22.2. Sender's residence Is the code /ORDERRES/ and the code of the ordering T30
customer's country of residence present?
5. Duplicate Has the message received from the sending bank on the T21
messages respective settlement day not been duplicated?
42
REFUND MESSAGE VALIDATION
Upon the receipt of refund messages from the sending bank, the Bank of Latvia shall conduct
the following message checks:
No. Name of the check Check explanation Error code

1 2 3 4
1. Message structure Does the refund message, in between the indications of start F01
and end of the message ("01h" and "03h"), contain the
mandatory message blocks in line with provisions stipulated
on p. 9?
2. Basic Header block Has the Basic Header Block of the refund message been –
drafted in compliance with the general guidelines for
preparing messages (see p. 9)? (See the check of the Basic
Header Block on p. 35)
3. Application Header Has the Application Header Block of the refund message –
Block been drafted in compliance with the general guidelines for
preparing messages (see p. 9)? (See the check of the
Application Header Block on p. 35)
4. Text Block Has the Text Block of the refund message been drafted in –
messages (see p. 9) and a refund message (see p. 20)?
4.1. Block structure Is the Text Block present in line with the SWIFT standard? F04
4.2. Block field sequence Does the Text Block contain message fields in a definite F05
sequence according to the rules for preparing a refund
message (see p. 20)?
4.3. Structure of each Is each field of the Text Block present in an appropriate –
the rules for preparing a refund message (see p. 20)?
4.3.3. Field 32A Mandatory. –
4.3.3.1. Field format Is Field 32A present in an appropriate format? F06
information the rules for preparing a refund message (see p. 20)?
4.3.3.2.1. Value date Is the specified value date the same as the Bank of Latvia's T09
current settlement day date?
4.3.3.2.2. Currency code Has the lats code been indicated, i.e. LVL? T10
4.3.3.2.3. Amount Is the amount not equal to 0, and does the amount contain T11
no more than two digits following the comma?
4.3.4.1. Field format Does Field 53a contain option A and is it present in an F07
appropriate format?
4.3.4.2.1. Bank of Latvia's BIC Does Field 53a contain the Bank of Latvia's BIC (except for T18
cases when the Bank of Latvia makes the refund or a bank
refunds the Bank of Latvia)?
4.3.5.1. Field format Does Field 58a contain option A and is it present in an F07
appropriate format?
1 2 3 4
4.3.5.2.1. Bank BIC Does Field 58a contain the BIC of the receiving bank ? T26
43
4.3.6. Field 72 Mandatory. –

4.3.6.2.1. Code /REJECT/ Is code /REJECT/ indicated in Row 1 of the field? T27
4.3.6.2.2. Error code Does payment rejection code in an appropriate format T28
follow the code /REJECT/ in Row 1 of the field?
5. Duplicate messages Has the payment message received from the sending bank T21
on the respective settlement day not been duplicated?
44
ERROR CODES
Group Error Error name Explanation

code
1 2 3 4
C Payment file errors
C01 Unauthorised file type File name contains an unauthorised file type.
C02 Incorrect date The date indicated in the file name, expressed as the number
of days from the beginning of the year, is not the same as the
date of the current settlement day.
C03 Incorrect sequence number File sequence number contained in the file name is incorrect.
C04 Unauthorised file File extension is not appropriate for the encryption package
extension used.
C05 Unauthorised length of file File name length does not comply with the one defined in the
name rules.
C06 Duplicated file Duplicated file name on the respective settlement day.
C07 Unauthorised file length The length of the digitally signed file exceeds the defined one.
C08 Participation of the The file was received from a bank unauthorised to send files.
sending bank in clearing
has been suspended
C10 Incorrect digital signature The digital signature in the file received is erroneous, wrong
or belongs to an authorised person recalled by the bank.
C11 File signatory is not the The file received does not contain the digital signature of the
bank's authorised person authorised person of the bank sending the file.
C12 Signatory's certificate is The file has been signed with an expired key.
not valid
C13 File signatory's key is The file has been signed by a user whose participation in the
blocked clearing system has been temporarily suspended.
C14 Incorrect name of the Prior to signing the file has had a different name than the
signed file digitally signed and received file (apart from its extension).
C15 The encrypted file contains More than one file has been included in the digitally signed
several files and sent file.
C16 Incorrect number of Total number of messages indicated in the control message is
messages has been not the same as the number of messages included in the file
indicated in the control (excluding the control message).
message
C17 Incorrect total amount of Total amount of messages indicated in the control message is
payments has been not the same as the total amount of messages included in the
indicated in the control file.
message
C00 Other errors It is mandatory to specify the particular error after this code.
F Format errors
F01 Incorrect message The message structure does not comply with the stipulated
structure standard.
F02 Incorrect Basic Header The Basic Header Block format does not comply with the
Block structure stipulated standard.
F03 Incorrect Application The Application Header Block format does not comply with
Header Block structure the stipulated standard.
F04 Incorrect Text Block The Text Block format does not comply with the stipulated
structure standard.
F05 Incorrect field sequence The Text Block contains incorrect field sequence,
unauthorised fields, or mandatory fields are not present.
F06 Incorrect format The field is present in an incorrect format.
F07 Incorrect option or format The field contains unauthorised option or is present in an
incorrect format.
45
F00 Other errors It is mandatory to specify the particular error after this code.
1 2 3 4
T Text errors
T01 Incorrect BIC of the The BIC of the bank specified in the field LT Address is
sending bank incorrect or does not correspond to the bank whose authorised
person has digitally signed the respective file.
T02 Unauthorised message The field Message Type contains an unauthorised message
type type.
T03 Incorrect BIC of the The BIC of the bank specified in the field Recipient Address
receiving bank is incorrect.
T04 The receiving bank has The settlement account of the bank specified in the field
been suspended from Recipient Address has been suspended.
participation in clearing
T05 Code /MSGS/ is not The code has not been specified in line with the stipulated
present procedure.
T06 Number of messages has The total number of messages does not follow right after the
not been specified code /MSGS/.
T07 Code /TOTAL/ is not The code has not been specified in line with the stipulated
present procedure.
T08 Total amount of messages Total amount of messages does not follow right after the code
has not been specified /TOTAL/.
T09 Incorrect value date Value date is not the same as the date of the current settlement
day.
T10 The currency specified is The currency code is not LVL.
not LVL
T11 Incorrect amount The amount has not been specified, is equal to 0 or has been
specified with more than two digits after the decimal comma.
T12 Incorrect account number The account number has not been specified in line with the
SWIFT standard.
T13 Customer name is not The Field does not contain the name of the originator or the
present beneficiary or its BIC/BEI.
T16 Incorrect customer code The code /ID/ is not followed by the originator's or
beneficiary's company registration number, tax payer's code or
a person's ID in line with the stipulated procedure.
T17 Incorrect option for the The branch code has not been specified with Option D.
branch code
T18 BIC of the Bank of Latvia The field does not contain the BIC of the Bank of Latvia.
is not present
T19 Field 57 is not present The message contains Field 56a, but the beneficiary's bank
has not been specified in Field 57a.
T20 Code /HOLD/ is not Code /HOLD/ is not present but is mandatory in Field 23E
present since Field 59a does not contain the beneficiary's account
number.
T21 Duplicate message 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.
T22 Tax payer's code is not Code /ID/ and a tax payer's code has not been specified in
present Field 50a of a payment message addressed to the Treasury.
T26 BIC of the receiving bank The BIC of the specified bank is not the same as the BIC of
has not been specified the receiving bank indicated in the refund message.
T27 Incorrect code REJECT Code /REJECT/ has not been specified in line with the
stipulated procedure.
T28 Incorrect rejection code Code /REJECT/ is followed by an incorrect error code.
T29 The amount exceeds the The amount exceeds the maximum amount per payment
defined limit permitted in clearing.
46
1 2 3 4
T30 The sender's residence has The code word /ORDERRES/ and the ordering customer's
not been specified country of residence code are not present.
1 2 3 4
T31 IBAN The specified IBAN's structure does not correspond to that of
the Latvian IBAN or the IBAN control digits have not been
calculated correctly.
T32 Exchange rate The exchange rate does not comprise at least one digit or the
digital comma is not present in the field.
T33 IBAN The beneficiary's IBAN does not correspond to the BIC of the
beneficiary's bank or the receiving bank.
T00 Other errors It is mandatory to specify the particular error after this code.
R Rejection codes
R01 Incorrect account number No account with the number indicated in Field 59a has been
opened by the beneficiary with the beneficiary's bank.
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.
R03 Closed account The beneficiary's account with the beneficiary's bank is
closed, and the bank has no customer order for further transfer
of funds.
R04 Erroneous beneficiary's The beneficiary's account number indicated does not
data correspond to the beneficiary's name, or the code /HOLD/ is
followed by insufficient information about the beneficiary.
U 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.
U02 Receiving bank is The message prepared by the sending bank is rejected as the
excluded from clearing receiving bank is excluded from clearing.
Where errors are found in the Text Block field, the number of the respective field shall be
indicated before the text of the respective error.
Example of error specification
T25"CrLf"
72. LAUKS. NEPAREIZS AKCEPTA DATUMS"CrLf".
47
DIRECTORY OF BRANCHES
The Bank of Latvia shall prepare the directory of branches as a file.
File name
File name format is Bddd9999.ENT, where:

B – identifier of the directory of branches;
ddd – date (expressed as a number of days from the beginning of the current year) when the
information specified in the file becomes effective;
9999 – indicator of the complete directory of branches;

ENT – encrypted and digitally signed file extension.
File structure
Information about each branch shall be indicated in one row, containing the following fields:
Field Format Explanation

Code 11x Branch code
Name No.1 70xl Branch name in Latvian
Name No.2 70x Branch name in English
Address No.1 70xl Branch address in Latvian
Address No.2 70x Branch address in English
Information about each branch ends with the characters CrLf.
Information has been listed in alphabetical order of the bank BICs.

48
APPLICATION FOR CHANGES IN THE DIRECTORY OF BRANCHES
Date _____________________
Application No. ______________
Bank name ___________________________________
Bank BIC
Please make the following change in the directory of branches1:
include a new branch

delete data about a x x x x x x x x
branch
change data about a x x x x x x x x
branch
(branch code)
New values of banking details of the branch to be included in the directory2
Banking details New value

Code x x x x x x x x
Name in Latvian
Name in English
Address in Latvian
Address in English
__________________
(signature)
1
Only one change to be made in the directory of branches shall be specified.
2
Do not fill in if the branch is to be deleted from the directory of branches.
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.ENT, where:

B – identifier of the directory of branches;
ddd – date (expressed as a number of days from the beginning of the respective year) when
the information specified in the file becomes effective;
0000 – indicator of changes in the directory of branches;

ENT – encrypted and digitally signed file extension.
File structure
Information on changes in the directory of branches contains the following fields:
Field Format Explanation

Change code 1a Possible values:
A – the directory of branches shall be supplemented by a new branch
code and name;
D – information about the branch shall be deleted from the directory of
branches.
Code 11x Branch code
Name No.1 70xl Branch code in Latvian
Name No.2 70x Branch code in English
Address No.1 70xl Branch address in Latvian
Address No.2 70x Branch address in English
Where the directory of branches has been supplemented with a new branch code or the
information about a branch has been deleted, 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 file shall consist of two rows related to this branch. The first row with the code
D and the following branch code indicates that the present information about the respective
branch shall be deleted. 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 on the change of branch code, name or address ends with the characters CrLf.
Information has been compiled in alphabetical order of the bank BICs.

50
APPLICATION FOR CHANGES IN THE DIRECTORY OF INSTITUTIONS AND BANKS
Date _____________________
Application No. ______________
Bank name ___________________________________
Bank BIC
Please make the following change in the directory of institutions serviced by the bank1:
include a new institution serviced by x x x x x x x x

the bank
delete the institution serviced by the x x x x x x x x
bank
(institution code)
Institution values to be included in the directory of institutions and banks2
Banking details New value

Code x x x x x x x x
Name in Latvian
Name in English
__________________
(signature)
1
Only one change to be made in the directory of serviced institutions shall be specified.
2
Do not fill in if the institution is to be deleted from the directory of serviced institutions.
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.
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. The Basic Header Block and
Application Header Block shall be prepared in line with the general guidelines for preparing
messages (see p. 9). Where the list to be sent cannot be placed in one Type M file, several
Type M files may be sent if necessary. In the event of any changes in the directory a complete
directory shall be sent, 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.
Text Block
Field Name according to SWIFT Type1 Format

1
M – mandatory.
Field 20 "Transaction Reference Number"
The unique reference number assigned by the Bank of Latvia shall be indicated in this field.
Field 79 "Narrative"
In Row 1 of the field, the date when the changes take effect shall be specified. 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.
Example of a notice of changes in the directory of institutions and banks

:20:EKS4011018000130"CrLf"
:79: 20041018"CrLf"
TRELLV21-LACBLV2X"CrLf"
LPNSLV21-HABALV22"CrLf"
"CrLf"
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. 9).
Text Block

1
M – Mandatory.
The reference number assigned by the Bank of Latvia to the warning message shall be
Information to the bank on the situation and its consequences.

Eks Funct

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eks Funct

Uploaded by

Copyright:

Available Formats

FUNCTIONAL SPECIFICATION OF THE EKS, THE

ELECTRONIC CLEARING SYSTEM

PAYMENT PROCESSING PROCEDURE .............................................................................. 3

PAYMENT PROCESSING PROCEDURE

Calculation of clearing Net settlement Issue of clearing results and

Chart 1. Clearing procedures

Timeline of EKS operation

First clearing cycle Second clearing cycle

Net settlement of Net settlement of Deferred net

Chart 2. Timeline of the EKS operation

file authenticity on the basis of the selected cryptographic package;

presence of the control message in the file;

Calculation of clearing positions

• Issue of clearing results and files

• Receipt of files at the beneficiary's bank

whether the beneficiary's account has not been closed;

whether it is not forbidden by law to credit funds to the beneficiary's account.

RULES FOR PREPARING FILES

A unique name is assigned to each file in the format cdddnnnn.ENT, where:

1. For payment message files:

Number of messages per file

GENERAL GUIDELINES FOR PREPARING MESSAGES

Name according to the SWIFT Block identifier

Basic Header Block

Application Header Block

Example of Message Blocks

Payment messages shall be included in payment files (type P files).

Preparation of MT103 Single Customer Credit Transfer

Field Name according to the SWIFT Type1 Format2

23B Bank Operation Code M 4!c

23E Instruction Code O 4!c[/30x]

26T Transaction Type Code O 3!c

c – capital letters of the Latin alphabet and numbers,

Rules for preparing messages

Rules for checking duplicate messages

The following fields shall be used for checking duplicates:

Message Field Specifications

• Field 20 "Sender's Reference"

• Field 13C "Time Indication"

• Field 23B "Bank Operation Code"

• Field 23E "Instruction Code"

The codes to be used in this field are as follows:

• Field 26T "Transaction Type Code"

• Field 32A "Value Date, Currency Code, Interbank Settled Amount"

• Field 33B "Currency/Instructed Amount"

• Field 36 "Exchange Rate"

• Field 50a "Ordering Customer"

• Field 51A "Sending Institution"

• Field 52a "Ordering Institution"

• Field 53a "Sender's Correspondent"

• Field 54a "Receiver's Correspondent"

• Field 55a "Third Reimbursement Institution"

• Field 56a "Intermediary Institution"

• Field 57a "Account with Institution"

• Field 59a "Beneficiary Customer"

This field specifies the customer which will be paid.

• Field 70 "Remittance Information"

• Field 71A "Details of Charges"

• Field 71F "Sender's Charges"

• Field 71G "Receiver's Charges"

• Field 72 "Sender to Receiver Information"

This field specifies additional information for the Receiver.

The field shall be filled in according to SWIFT rules, i.e.: