SVFE CBS-Specification
SVFE CBS-Specification
09.01.2023 15:38:33
CONTENTS
CONTENTS .................................................................................................................................. 2
OVERVIEW .................................................................................................................................. 7
OVERVIEW
This document describes specifications for the SmartVista Front – End (SVFE) Core Banking
System (CBS) external message protocol. The protocol can be used to provide authorization and
information services to card processing hosts or transaction concentrators.
The current software releases are implementing an external message based on the International
Organization for Standardization (ISO) 8583-2:1993 standard.
The message specifications in this manual are applicable to the ISO-based external message only.
TCP/IP is a point to point communication protocol with a delivery guarantee and data sequence
guarantee. The connection party, which initiates a connection, is a TCP/IP client. The connection
party, which accepts the connection, is a TCP/IP server. TCP/IP client establishes connection
identifying а target application with an IP address of the host and a port number within that host. If
the connection is dropped by any reason it should be re-established by the client application.
SVFE host can act in a TCP/IP connection as a client or as a server depending on the host
configuration. For data transmission TCP/IP uses sessions. Each session is a bi-directional data
stream. SVFE protocol uses a single TCP/IP session to transfer data between hosts in both
directions. The continuous TCP/IP data stream is split into frames. Each ISO – 8583 message is sent
in a separate frame. A Frame consists of a configurable length header and a message body. The
header contains the length of the following message.
N bytes N bytes
1. Authorization Messages
1100 – Authorization Request
Message Type: 1100
Description: Authorization Request (1100) message requests approval authorization or guarantee
for the transaction to proceed. Authorization Response (1110) is expected in return for 1100
message, either approving or denying the request.
2. Financial Messages
3. Reversal Messages
Description: Authorization Request Repeat (1421) is identical to 1420 message, except that
it denotes to the receiver that it is a possible duplicate message. Format and contents of fields at
1421message are the same as at 1420 message. This message is used when an
expected acknowledgement to 1420 message was not received.
4. Administrative Messages
1600 – Administrative Request
Message Type: 1600
Description: Administrative Request (1600) is used to Reset ATM Counters. Administrative
Response (1610) is expected in return for 1600 message, either approving or denying the request.
1. Authorization Messages
sd Auth
SVFE CBS
1100()
1110()
Message 1121 is sent 60 seconds after sending message 112X, for which a response has not been
received.
sd Auth Adv ice
SVFE CBS
1120()
1130()
1121()
1130()
3. Financial Messages
sd Auth
SVFE CBS
1200()
1210()
Message 1221 is sent 60 seconds after sending message 122X, for which a response has not been
received.
sd Auth Advice
SVFE CBS
1220()
1230()
1221()
1230()
5. Reversal Messages
SVFE sends 1420/1421 messages in case a request for authorization cancellation has been received
from terminal devices and payment networks, or in case of authorization cancellation in SVFE
system in stand-in mode.
Message 1420 is sent 5 seconds after sending the message 1100 or 1200, for which there was no
response.
Message 1421 is sent 60 seconds after sending the message 142X, for which there was no response.
Message 1421 is sent not more than three times. If after sending the last message 1421 there was still
no response, the authorization request, for which there was no response, is considered to be
processed in stand-in mode.
sd Rev ersal
SVFE CBS
1420()
1430()
1421()
1430()
SVFE sends 1420/1421 messages in case the SVFE does not receive a response to 1100 or 1200
message.
Message 1421 is sent in case the response to message 1420 is not received.
sd Rev ersal
SVFE CBS
1420()
1430()
1420()
1430()
1421()
1430()
6. Administrative Messages
sd Administrativ e
SVFE CBS
1600()
1610()
The SVFE system periodically sends a message 1804 with a query of type 831 – “Test of
connection”. A repeated message 1804 is sent 60 seconds after sending the message 1804, for which
there was no response. In case there is no response to message 1804, the message 1804 is repeated
not more than three times.
If after the last message 1804 there was no response, or if there was a response message 1814 with
response code other than “000”, the SVFE system will send to CBS a message 1804 of query type
802 – “Sign Off” and starts to process authorization requests in stand-in mode.
SVFE CBS
1804()
1804()
1814()
CBS SVFE
1804()
1804()
1814()
SAF List End message is used when required notification of CBS about finishing of the Stand-In
processed transactions.
In case of logical connection between SVFE and CBS lost SVFE could process transaction in Stand-
In mode. After the connection is established the SVFE upload all transactions as advices. When all
transactions are uploaded SVFE sends SAF List End message to inform CBS all the transactions
were uploaded.
CBS SVFE
Connection Lost
Stand-In processing()
Stand-In processing()
1804(Test of connection)
1814()
1804(Sign-On)
1814()
1120()
1130()
1120()
1130(Last transaction)
1814()
DATA FIELDS
S Special characters
…16 Variable length up to a maximum of 16 characters. All variable length fields will also contain two or
three positions at the beginning of the field to identify the number of positions following to the end of
that field
Bit – 8 bytes (64 bits) in binary format. Each bit signifies the presence (1) or the absence (0) in the
Map message of the data field associated with that particular bit
x “C” for credit, “D” for debit and shall always be associated with a numeric amount data field, i.e.,
x+n 16 in amount, net reconciliation means prefix “C” or “D” and 16 digits of amount, net
reconciliation
MM Month
DD Day
YY Year
hh Hour
mm Minute
SS Second
LL Length of variable data field that follows, from 01-99. The variable length subelement is two numeric
characters.
LLL Length of variable data field that follows, from 001-999. The variable length subelement is three
numeric characters.
LLLL Length of variable data field that follows, from 0001-9999. The variable length subelement is four
numeric characters.
O – Optional. Field/value presence in the message is up to the message initiator or the responder.
4.1.1. Format
Bit-Map
4.1.2. Description
This field is a bit map indicating the presence or absence of fields in the secondary portion of the
message, bits 65-128. This field should only be present if there is at least one field from the
secondary range in the message.
4.2.1. Format
llvar n.. 24
4.2.2. Description
This field is also used to match a response message with its original message.
4.3.1. Format
n6
4.3.2. Description
The processing code is a series of three two-byte codes. The first two bytes (bytes 1 and 2) indicate
the type of transaction.
The second and third two bytes (bytes 3 and 4, and bytes 5 and 6) indicate the account 1 and account
2 type, respectively .
4.4.1. Format
n 12
4.4.2. Description
Funds requested by the cardholder in the local currency of the acquirer or source location of the
transaction, exclusive of amounts, fees.
In the 1100 and 1200 balance inquiry request, this field will contain zeroes.
For incremental authorization, this field will contain the additional amount.
For partial reversal, this field will contain the amount of the original request.
For partial reversal of incremental authorizations, this field will contain the total amount authorized.
4.5.1. Format
n 12
4.5.2. Description
In requests field contains transaction amount to be debited/credited to the account (in the account
currency).
4.6.1. Format
n 12
4.6.2. Description
This field contains the transaction amount (Field 4), converted to the currency used to bill the
cardholder’s account. The conversion rate is in Field 10. No decimal point appears in this field; the
decimal place is implied based on the currency. If it is present, the following fields are also required:
“Field 10: Conversion Rate, Cardholder Billing”.
4.7.1. Format
n 10 , MMDDhhmmss
4.7.2. Description
Date and time this message was sent by the message initiator
4.8.1. Format
n8
4.8.2. Description
This field contains the rate used to convert the transaction amount (Field 4) to the cardholder billing
amount (Field 6). The Field 4 amount multiplied by this rate equals the Field 6 amount. The left-
most digit denotes the number of positions the decimal separator shall be moved from the right
(allowable values are 0 to 7). Positions 2–8 of the field are the actual rate.
4.9.1. Format
n8
4.9.2. Description
This field contains the rate used to convert the Account amount (Field 5) to the Cardholder Account
amount (Field 4). The left-most digit denotes the number of positions the decimal separator shall be
moved from the right (allowable values are 0 to 7). Positions 2–8 of the field are the actual rate.
4.10.1.Format
n6
4.10.2.Description
This field is also used to match a response message with its original message.
4.11.1.Format
n 12
YYMMDDhhmmss
4.11.2.Description
The local year, month, day, and time the transaction takes place at the card acceptor location in
authorization and financial messages.
This field is also used to match a response message with its original message.
4.12.1.Format
n4
YYMM
4.12.2.Description
SmartVista Front-End ISO-8583 CBS INTERFACE
25
Banking Production Center
The year and month that the card will become expired.
4.13.1.Format
n6
YYMMDD
4.13.2.Description
4.14.1.Format
n4
4.14.2.Description
A code describing the merchant’s type of business product or service. See ISO-8583 standard
documentation for the list of valid categories.
4.15.1.Format
ans 12
4.15.2.Description
A series of codes intended to identify terminal capability, terminal environment and presentation
security data. It shall be used to indicate specific conditions that are (or were) present at the time a
transaction took place at the point of service and/or when the transaction has been initiated.
4.16.1.Format
n3
4.16.2.Description
Code indicating the specific purpose of the message within its message class.
4.17.1.Format
llvar n.. 11
4.17.2.Description
This code identifies the financial institution acting as the acquirer of this cardholder transaction. The
acquirer is a member or system user that installed the terminal. The ID can be a Visa BIN, a
MasterCard BIN, or another code that identifies the financial institution or branch within SmartVista
Front-End. BINs are usually six digits, but the code may be up to 11 digits long. The value length
specifies the number of digits in the ID code.
4.18.1.Format
an 12
4.18.2.Description
A reference supplied by the system retaining the original source information and used to assist in
locating that information or a copy thereof.
If no reply was received to the original transaction Field 037 must still be present, but it should
contain a string of spaces.
4.19.1.Format
ans 6
4.19.2.Description
In the C program shown below the input parameter “u” of function “auth” is value of Field 37, and
output parameter “a” is value of field 38.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char *voc[6]={
“123456789”,
“0123456789ABCEFHKMNRSTUVWXYZ”,
“0123456789ABCEFHKMNRSTUVWXYZ”,
“0123456789”,
“0123456789ABCEFHKMNRSTUVWXYZ”,
“0123456789ABCEFHKMNRSTUVWXYZ”
};
int I,l;
l=strlen(voc[i]);
a[i]=voc[i][u%l];
u/=l;
}}
4.20.1.Format
an 3
4.20.2.Description
A code which defines the action taken or to be taken as well as the reason for taking the action.
826 001 Successful transaction, but MCC is in list 6010, 4829, 6051, 7995, 7511
959 914 This code is sent from CBS in case the cancellation request 703 was sent
when the operational day in CBS is closed.
1
Response codes 4XX are sent by SVFE in 142X messages
(DEBTS_ABSENCE)
997 997 The customer does’’t have the service of advance repayment of debt
(SERVICE_NOT_ALLOWED)
243 243 LUK has expired or transaction limit for this key has been exceeded
4.21.1.Format
ans 8
4.21.2.Description
A code that uniquely identifies a particular terminal at the card acceptor’s location. An identification
code of less than eight positions must be left-justified and the remainder of the field space-filled. This
field is mandatory if the terminal id is available.
4.22.1.Format
an 15
4.22.2.Description
A code that uniquely identifies Point of Sale (POS) / merchant for a given acquirer.
4.23.1.Format
ans 40
4.23.2.Description
The name and location of the card acceptor. This field is required in authorization requests, advice
messages and related reversal requests for all card-read transactions. It contains the information
necessary for printing on customer account statements and on credit card billing statements.
Subfield Type and Data dictionary
length of data
1 ans 38 • Merchant number of bank name;
• Separator ‘>’
• Merchant city or location of the terminal device
• Trailing spaces
2 ans 2 ISO code of the country
4.24.1.Format
Tag data format: 3 bytes for each tag name + 3 bytes for each tag length + tag data
4.24.2.Description
This field is used to carry SmartVista Front-End internal information. There is a number of tags packed in
field 48. The tags have the TLV structure. It means they are repeated groups of Tag IDs, Tag Lengths and
Tag Values.
Banking Production Center may occasionally introduce new Field 48 tags between SVFE releases to
facilitate special processing. Banking Production Center requires members using SVFE CBS
specification to be able to successfully process various online messages that may contain new
unannounced Field 48 tags.
4.25.1.Format
n3
4.25.2.Description
This field is used in any message related to a cardholder transaction that contains one or more of the
amount fields listed above, even when the amount is zero. This field is also used in balance inquiry
requests, even when the value of field 4 equals zero. This code specifies the currency in which the
acquirer wants the balance amount to be expressed.
4.26.1.Format
n3
4.26.2.Description
4.27.1.Format
n3
4.27.2.Description
This field contains a 3-digit numeric code that identifies the currency used by the issuer to bill the
cardholder’s account.
4.28.1.Format
lllvar an…999
4.28.2.Description
This field is used to carry SmartVista Front-End account balance information. There is a number of tags
packed in Field 54. The tags have the TLV structure. It means they are repeated groups of Tag IDs, Tag
Lengths and Tag Values.
Banking Production Center may occasionally introduce new Field 54 tags between SVFE releases to
facilitate special processing. Banking Production Center requires members using SVFE CBS
specification to be able to successfully process various online messages that may contain new
unannounced Field 54 tags.
4.29.1.Format
lllvar b…255
4.29.2.Description
This field is carried in VSDC and Contactless Magnetic Stripe transactions and supports
4.30.1.Format
lllvar an…999
4.30.2.Description
This field is used to carry SmartVista Front-End account balance information. There is a number of tags
packed in Field 61. The tags have the TLV structure. It means they are repeated groups of Tag IDs, Tag
Lengths and Tag Values.
Banking Production Center may occasionally introduce new Field 61 tags between SVFE releases to
facilitate special processing. Banking Production Center requires members using SVFE CBS
specification to be able to successfully process various online messages that may contain new
unannounced Field 61 tags.
4.31.1.Format
4.31.2.Description
Field contains mini-statement data, only for 704 SVFE Transaction Type, up to 10 sets:
N Description Attributes Comments
“ ” – noop transaction
4 Amount Transaction N 12
4.32.1.Format
llllvar ans…9999
4.32.2.Description
4.33.1.Format
b8
4.33.2.Description
The Primary Message Authentication Code data field carries the message authentication code
(MAC) for the message. This code is generated by ANSI X9.19 Method. Fields at MAC are filled in
according type of message formats represented at next chapter “MASSAGE FORMAT” (look at last
column “Field Used For Mac –Y or N”)
If the message contains secondary data fields, Field 128 is used to carry the message authentication
code. If the message authentication code is carried in Field 128, Field 64 is not included in the
message.
4.34.1.Format
an 1
4.34.2.Description
Value Description
1 Add operation
3 Delete operation
4.35.1.Format
lllvar an…999
4.35.2.Description
This field is used to carry SmartVista Front-End amount information. There is a number of tags packed
in Field 95. The tags have the TLV structure. It means they are repeated groups of Tag IDs, Tag Lengths
and Tag Values.
Banking Production Center may occasionally introduce new Field 95 tags between SVFE releases to
facilitate special processing. Banking Production Center requires members using SVFE CBS
specification to be able to successfully process various online messages that may contain new
unannounced Field 95 tags.
4.36.1.Format
LLVAR ans… 4
4.36.2.Description
4.37.1.Format
llvar ans.. 32
4.37.2.Description
4.38.1.Format
llvar ans.. 32
4.38.2.Description
Field is used in cardholder transactions. Field identifies second account number of cardholder
relationship. For example, “TO account” for transfers. Data element should not be present in the
message if it contains no data.
4.39.1.Format
LLLLLVAR ans…99999
4.39.2.Description
Field is used for transmit some data between EPAY and CBS, there is no additional processing in
SVFE
4.40.1.Format
b8
4.40.2.Description
4.41. TheSecondaryMessageAuthenticationCodedatafieldcarriesthemessageauthenticationcode
(MAC) for the message. See Field 63: Private Data, Multiple Sets
4.41.1.Format
llllvar ans…9999
4.41.2.Description
MESSAGE FORMATS
1. Authorization Message
1.1. Request
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
18 Merchant Type n4 C Y
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
Code
49 Currency Code, n3 M Y
Transaction
1.2. Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
38 Authorisation ans6 C Y
Identification Response
42 Card Acceptor an 15 M Y
Identification Code
50 Currency Code, n3 C Y
Account
2.1. Request
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
18 Merchant Type n4 C Y
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
38 Authorisation ans6 M Y
Identification Response
49 Currency Code, n3 M Y
Transaction
2.2. Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
42 Card Acceptor an 15 M Y
Identification Code
50 Currency Code, n3 C Y
Account
3. Financial Message
3.1. Request
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
18 Merchant Type n4 C Y
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
49 Currency Code, n3 M Y
Transaction
3.2. Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
38 Authorisation ans6 C Y
Identification Response
42 Card Acceptor an 15 M Y
Identification Code
50 Currency Code, n3 C Y
Account
4.1. Request
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
18 Merchant Type n4 C Y
38 Authorisation ans6 M Y
Identification Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
Terminal Identification
49 Currency Code, n3 M Y
Transaction
4.2. Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
42 Card Acceptor an 15 M Y
Identification Code
50 Currency Code, n3 C Y
Account
5. Reversal Messages
5.1. Request
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
18 Merchant Type n4 M Y
49 Currency Code, n3 M Y
Transaction
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
5.2. Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
3 Processing Code n6 M Y
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
42 Card Acceptor an 15 M Y
Identification Code
6. Administrative Messages
6.1. Request
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
6.2. Response
Field Used
Bit Attri- Sta-
Data field Name Format Comments / Remarks For Mac
No. butes tus
Y or N
42 Card Acceptor an 15 M Y
Identification Code
7.1. Request
24 Function Code N3 M
7.2. Response
24 Function Code N3 M
MESSAGE MATCHING
• Message Type.
The 810 response matching fields are Message Type and System Trace Audit Number (field 11).
Appropriate request message type (0800) is used as value for matching.
1. Structure Field 48
Size Data
3 LLL – 3
3 3 NNN bytes
Must be present in
1100/1120/1121/1200/1220/1221/1420/1421/1600 messages for
us-on-us and us-on-them transactions.
Optional for 806 and 807 SVFE transactions types
Format: YYMMDD
YYMMDD
008 N6 YYMMDD
009 N6 YYMMDD
0 – valid card
1 – call issuer
2 – warm card
3 – do not honor
4 – honor with id
5 – not permitted
6 – lost card, capture
7 – stolen card, capture
8 – call security, capture
9 – invalid card, capture
10 – pick up card, special condition
11 – call acquirer security
12 – card is not activated
13 – pin_attempts_exceeded
14 – forced pin change
15 – credit debts
17 – pin activation
18 – instant card personification waiting
19 – fraud prevention
20 – temprory blocked by client
21 – permanent blocked by client
Must be present in 1100/1200 messages if Transaction Code =
91.
022 ans ..32 Mobile phone number for mobile top-up services.
0 – Debit.
1 – Debit with overdraft.
2 – Credit.
29 n .. 12 Card ID.
For transaction Remittance and Cardless redemption (709) this tag contains value of Tag 031 – FE transaction number
from Remittance and Cardless origination transaction (714).
For transaction POS Purchase Cancellation (738), this tag contains value of Tag 031 – FE transaction number from
origination transaction POS Purchase (774).
For incremental transaction, this tag contains value of Tag 031 – FE transaction number from original transaction.
035 ans .. 993 This tag holds Network Reference Data if presented. Actual
length and format depends on the originating network.
Presented if available.
039 n12 The local year, month, day, and time the transaction takes place
at the card acceptor location in authorization and financial
messages in YYMMDDhhmmss format.
041 ans .. 100 Tag 041 contains multiple VISA Token tags, which can be
provided in VISA authentication transactions.
Subtag name element is 3 bytes wide, subtag length element is
also 3 bytes wide, subtag data element’s length is the number
which is stored in subtag length element.
Presented if available.
Format N%M, where N and M are sets of digits. Not more than
6 digits for N, 4 digits for M. N or M must be present.
046 Ans..36 Billing Card ID. Card Identifier in external Billing System like
Yota Billing.
048 n4 contains a code that identifies why STIP responded for the
issuer or why the Switch generated an advice.
066 an..16 contains the card2 number from Sender Data Block
067 an..34 contains the receiver account number from Sender Data Block
P2P
069 an..30 Contains the name of the entity receiving the funds.
Field is recommended to be used in all IBFT transactions.
077 ans...1 This field will be sent having value “1” if transaction is
incremental authorization.
078 ans...300 This field will be sent for transaction TAR, TCN , ACN from MC
079 ans...512 This field will be sent for transaction TAR, TCN , ACN from
VISA
080 ans...999 This field will be sent for transaction TAR, TCN , ACN from
NSPK
1. Structure Field 54
Size Data
3 LLL – 3
3 3 NNN bytes
010 an 17..153 1-9 Issuer Fee Amount and Id Blocks. Block content:
Position 1 – Fee Sign (C or D)
1. Structure Field 61
Size Data
3 LLL – 3
3 3 NNN bytes
1. Structure Field 95
Size Data
3 LLL – 3
3 3 NNN bytes
1. Structure of Field 63
Size Data
4 LLL – 3
3 LLL – 3
3 3 NNN bytes
• ‘ ‘ – Noop transaction
Mandatory for Mini-Statement transaction response.
004 ans ..60 Transaction description of the transaction from the statement.
or
b ..240 Transaction description could be provided in ASCII or in UTF-
8. If UTF-8 is used, the limitation is 60 UTF-8 characters (up to
240 bytes).
Optional for Mini-Statement transaction response.
LIST OF REVISIONS
№ Date Name, Surname Modifications
2 2010-11-24 Grigoriev A.S. Added operations: Debit account with presentment, Credit
account with presentment.
3 2011-02-04 Sasin S.S. Changes in accordance with the Main Project: transaction
type for P2P_DEBIT (781) and UTILITY_PAYMENT
(508) is being changed to POSP (774), and CBS will never
know original operation type
5 2011-05-25 Dudnikov V.M. Added Account Verification transaction. Added tag 14, 15
to field 48.
7 2011-07-29 Dudnikov V.M. Added tags 16, 17, 18 to field 48. Added field 91, Added
SVFE transaction types 493, 508, 510, 596, 603, 644, 672,
751, 753, 782, 797, 798, transaction codes 16, 91, 92, 93.
Added value 841 to field 24. Changed transaction code for
transaction types 585, 618. Removed transaction type 587.
9 2011-09-19 Kondrashin E.K. Changed field 43 format and comment field 62.3
10 2011-09-19 Sasin S.S. New processing code – Predefined Service Payment (50) –
was added.
22A 2015-01-13 Sheina E.D. Added new Tag 29 (Card ID) to DE48.
23A 2015-01-23 Vernik K.A. Added new Tag 30 (Card type ID) to DE48. Added new
Tag 10 (Issuer Fee Details) and Tag 11 Transaction
Amount, Account Currency to DE54.
24A 2015-02-16 Sheina E.D. Fixed DE43 format in “Message format” section.
25A 2015-02-25 Sheina E.D. Fixed DE39 description: changed SV resp for CBS resp =
124.
26A 2015-03-25 Karpov A.V. Add DE37 to the set of key fields used for matching CBS
responses with requests.
29A 2015-09-09 Karpov A.V. Change status of DE102 and DE103 from MANDATORY
to CONDITIONAL as it is possible that these data elements
may be empty.
30A 2015-09-11 Sheina E.D. Actualized processing codes and SVFE transaction types
list.
31A 2015-10-14 Sheina E.D. Added new tag 031 (FE transaction number (utrnno)) to DE
48.
32A 2015-11-27 Karpov A.V. Added new tag 032 (Customer Mobile Phone Number -
taken from CREF_TAB only) to DE 48.
33A 2016-02-04 Karpov A.V. Change format for DE62. New subfield added for N3
transaction currency code.
35A 2016-04-20 Sheina E.D. Added new response code: 940 – Original transaction not
found.
36A 2016-06-06 Sheina E.D. Added new response code: 957 – Payment institution is
unknown or unsupported.
37A 2016-10-26 Rashin G.D. Generic transaction description field was added to field 62
(Mini statement data)
38A 2017-04-06 Vikharev A.S. Added the new tag 012 for the Field 54. The tag 009 is
marked as unused.
39A 2017-06-01 Shinkarenko T.N. Added the new tag 033 for the Field 48 (Customer ID).
40A 2017-07-18 Karpov A.V. Added new tag 48.039 Local Transaction Date and Time.
41A 2017-07-20 Vikharev A.S. Added new function code 36xxxx (Transfer Inquiry) for
DE#3.
43A 2017-08-15 Vikharev A. S. Added new tag 48.040 (External Transaction ID).
44A 2017-08-16 Letovaltcev N.V. Added new tag 48.041 (VISA Token Tags)
46A 2017-09-08 Letovaltcev N.V. Added new tag 48.044 (Message Reason Code)
48А 2017-02-16 Ignatov M.V. Added new tag 48.045 (Card Mask)
49A 2018-03-28 Karpov A.V. Added new tag 49.046 (Billing Card ID)
50A 2018-04-05 Ignatov M.V. Add field 7 Transmission Date and Time,
52A 2018-07-24 Sheina E.D. Change usage of Field 54 tags 001, 006, 010. Tags could be
present in 1110/1130 messages.
2018-08-17 Karpov A.V. Add description of field 7 from 50A to message layouts.
53A 2018-09-11 Ignatov M.V. Add new tag 48.052 CAVV results code
54A 2018-09-20 Karpov A.V. Optional field 48 added to layout of 1430 reversal advice
response.
55A 2018-10-01 Sheina E.D. Added processing codes for Cashback and Purchase with
Cashback transactions.
Added new tag 16 for Field 54 – Cashback amount.
Added new values for Field 22: position 1 – value S,
position 5 – values I and R, position 11 – value 5, position
12 – value S.
56A 2019-01-15 Budnikov V.V. Added new Response Codes (Field 39): 370 and 371.
57A 2019-02-08 Karpov A.V. Change format and description of Field 63 Account Balance
to allow negative amounts with leading minus sign .
58A 2019-06-19 Karpov A.V. Add DE54 presence to Authorization Advice Message
Request Layout.
59A 2019-06-24 Karpov A.V. Add Processing Code 01 for TT 683 EPOS Cash Advance.
60A 2019-07-05 Ermolaev N.A. Add support Remittance and Cardless Withdrawal
transactions.
61A 2019-07-15 Ignatov M.V. Add new tag 48.053 Advice Flow Number
62A 2019-09-19 Karpov A.V. Add possibility of DE63’s presence in reversal’s responses.
63A 2020-01-16 Gulyaev S.S. Add new tags 48.054 – External Card ID, 48.055 –
Original Network Reference Number.
64A 2020-02-12 Shuklin R.V. The broken link was replaced by a link to field 64 in field
128. Approved by Sheina E.D
72A 2020-10-23 Thao N Update tag 002 and 003 of Field 54 according to existing
SVFE implementation
73A 2020-10-28 Thao N Update Comment/Remark for DE42 in Message Format and
tag 001 of Field 54 according to existing SVFE
implementation
74A 2020-12-09 Dudnikov V.M. Updated SVFE transaction type for Transfer Inquiry for
Transfer to External Account. Updated description of Field
48 tag 069.
75A 2020-12-15 Thao N Add new processing code : 23-External Account Cash
Deposit
76A 2020-15-18 Dudnikov V.M. SVFE transaction type 567 changed to 443.
78A 2021-01-13 Dudnikov V.M. Description of field 5 has been updated. Field 63 has been
removed. Description of field 54 tag 015 has been updated.
79A 2021-01-14 Karagichev A.A. Increased size of 48.60 – Sender State, up to 99 characters
in accordance with Epay specification.
80A 2021-03-02 Gulyaev S. S. Fix status of field 2 and field 48 tag 29 in response
messages. Add more information for matching section. Fix
example in field 48 tag 45.
81A 2021-04-01 Thao N Updated description of SVFE transaction type 807 at DE03
and description of DE48 tag 001
82A 2021-04-20 Dudnikov V.M. Remove DE 4 usage as available balance for Balance
Inquiry response.
84A 2021-06-15 Thao N Add new processing code : 02-POS Purchase Cancellation
86A 2021-07-12 Thao N Update description of DE04 and DE48 tag 034 for
incremental transaction.
87A 2021-08-31 Sheina E.D. Add processing code 29 for Fast Refund transaction (813).
88A 2021-10-20 Gulyaev S.S. Add description for messages 12xx as for 11xx
91A 2022-02-04 Dudnikov V.M. Added new IBFT check and ITFT transfer to DE 3 values.
93A 2022-05-06 Gulyaev S.S. Added description for search of original requests for
reversals and repeats
94A 2022-05-18 Dudnikov V.M. Added DE 54 tag 20, updated description of DE 48 tags
1/18/19.
95A 2022-06-01 Kaligin S.S. Field 32 marked as conditional for authorization request
and authorization advice.
97A 2022-06-28 Karagichev A.A. Added processing codes for 725 and 726 transactions
98A 2022-09-28 Dudniko V.M. Added new DE 63. Update format of 1110/1210 response
messages.