You are on page 1of 30

Implementation Guide for Technical

Enhancements

April 2011

THIS PAGE INTENTIONALLY LEFT BLANK.

ii

Table of Contents
Using this Document ......................................................................................................................... 1
Purpose....................................................................................................................................... 1
Audience & Application Scope .................................................................................................. 1
Time Expressed .......................................................................................................................... 1
Support ....................................................................................................................................... 1
1 New Programs and Functions ...................................................................................................... 3
1.1 MO/TO.............................................................................................................................. 3
1.1.1 Description ............................................................................................................. 3
1.1.2 Compliance ............................................................................................................ 3
1.1.3 Transaction types and processes ............................................................................ 3
1.1.4 The use of key fields .............................................................................................. 4
1.1.5 Clearing and settlement process ............................................................................. 7
1.1.6 Key issues in the transition period ......................................................................... 7
1.2 RECURRING ................................................................................................................... 7
1.2.1 Transaction description .......................................................................................... 7
1.2.2 Compliance .......................................................................................................... 7
1.2.3 Transaction types and processes ............................................................................ 8
1.2.4 Usage of key fields ................................................................................................. 8
1.2.5 Clearing and settlement process ............................................................................. 9
1.2.6 Key issues in transition period ............................................................................... 9
1.3 Online refund and offline refund for E-cash ..................................................................... 9
1.3.1 Description ............................................................................................................. 9
1.3.2 Compliance .......................................................................................................... 10
1.3.3 Transaction types and processes .......................................................................... 10
1.3.4 Format of online message .................................................................................... 10
1.3.5 Definition of message format ............................................................................... 10
1.3.6 Clearing and settlement process ................................................................................... 10
1.3.7 Key issues in transition period ............................................................................. 11
1.4 Cross-border remittance .................................................................................................. 11
1.4.1 Description ......................................................................................................... 11
1.4.2 Compliance .......................................................................................................... 11
1.4.3 Transaction types and processes .......................................................................... 12
1.4.4 Explanation on online message ............................................................................ 12
1.4.5 Clearing and settlement process ........................................................................... 12
1.4.6 Key issues in transition period ............................................................................. 12
2 Enhancements on Settlement Files ............................................................................................ 13
2.1.
(FCP) Format of fee collection and payment file ................................................. 13
2.2 TC804 (MCT) (New) .............................................................................................. 13
2. 3 Format of General Audit Trailer File ..................................................................... 14
2. 4 Dispute Audit Trailer File ...................................................................................... 14
2. 5 Settlement files of Dual Message........................................................................... 14
2. 6 File rejection code .................................................................................................. 15
i

2. 7 Introduction to the processing of presentment files by CUPS ............................... 15


3 Enhancements for Fields ............................................................................................................ 20
3.1 Instruction for filling F22, F60.2.2 and F60.2.3.............................................................. 20
3.1.1 Enhancement Description .................................................................................... 20
3.1.3 Issues to be noticed by the acquirers .................................................................... 21
3.1.4 Issues to be noticed by the issuers........................................................................ 21
3.2 Processing of F61 ............................................................................................................ 21
3.2.1 Enhancement Description .................................................................................... 21
3.2.2 Processing instruction .......................................................................................... 22
3.2.3 Compliance .......................................................................................................... 23
3.2.4 Supporting transaction types and processes ......................................................... 23
3.2.5 Instruction for settlement process ........................................................................ 23
3.2.6 Issues to be noticed by the acquirers .................................................................... 23
3.2.7 Issues to be noticed by the issuers........................................................................ 23
3.3 Instructions for filling out F42 ........................................................................................ 23
3.3.1 Background .......................................................................................................... 23
3.3.2 Compliance .......................................................................................................... 24
3.4 Instructions for using F54 ............................................................................................... 24
3.4.1 Enhancement Description .................................................................................... 24
3.4.2 Compliance .......................................................................................................... 24
3.4.3 Issues to be noticed by the issuers........................................................................ 24
4 Summary of Enhancements ....................................................................................................... 24

ii

Using this Document


Purpose
This Guide is formulated as complementary manual of Technical Specifications V2.0
(April 2011) to help participants better understanding the revisions and amendment
made in the new edition so as to facilitate the system upgrade and transformation.
Audience & Application Scope
The audiences of this Guide are the stuff from UnionPay and UnionPay participants.
The Guide applies to all UnionPay Participants.
Time Expressed
UnionPay has operation centers in several locations including Shanghai, Beijing and
Hong Kong. For operational purpose, the time frame in this manual, unless
particularly indicated, refers to Beijing time.
Coordinated Universal Time (UTC) is the basic measuring time throughout the world.
Beijing time is 8 hours ahead of UTC. Also, there is no Daylight Saving Time in
China.
Unless otherwise specified, the Day in this Volume refers to the calendar day and the
Business Day refers to the working day subject to local regulations of the country
where the processing Participant is located.
Support
Please address your questions to the service teams as follows:
For questions related to this manual:
Fax:

(86-21) 5036-2339

E-mail:

publications_intl@chinaunionpay.com

For questions related to transaction processing:


Fax:

(86-21) 5036-2339

E-mail:

support_intl@chinaunionpay.com

THIS PAGE INTENTIONALLY LEFT BLANK.

New Programs and Functions


1.1 MO/TO
1.1.1

Description

MO/TO is a non-magnetic-based and non-password-based transaction initiated


through telephone or fax, etc., supporting transaction types such as MO/TO purchase,
MO/TO pre-authorization and MO/TO authorization. Only credit cards are authorized
to initiate cross-border MO/TO transactions. Under the condition of dual message
being converted to single message, MO/TO authorization will not distinguish whether
its an estimated or a fixed amount, and all of authorization transactions will be
converted to MO/TO pre-authorization transactions. Message format of MO/TO
transaction differs from common transactions only in the value of field 25.
1.1.2

Compliance

1.1.2.2 For Acquirers


It is optional for acquirers. Acquirers having the demand to expand MO/TO
merchants and transactions may choose to update system to support MO/TO
transactions.
1.1.2.2 For Issuers
It is optional for issuers. Issuers who would like to provide this function to their credit
card holders may update system to support MO/TO transactions.
1.1.3

Transaction types and processes

1.1.3.1 Transaction Types


Transaction types supported by MO/TO include:
1. Authorization type: MO/TO authorization, MO/TO authorization cancellation,
MO/TO authorization reversal, MO/TO authorization cancellation reversal;
2. Pre-authorization type: MO/TO pre-authorization, MO/TO pre-authorization
cancellation,
MO/TO
pre-authorization
completion
(request),
MO/TO
pre-authorization completion cancellation, manual MO/TO pre-authorization
cancellation, manual MO/TO pre-authorization completion, MO/TO pre-authorization
completion (notice), MO/TO settlement notice, MO/TO pre-authorization reversal,
MO/TO pre-authorization cancellation reversal, MO/TO pre-authorization completion
(request) reversal, MO/TO pre-authorization completion cancellation reversal,
manual MO/TO pre-authorization cancellation reversal;
3

3. Purchase type: MO/TO purchase, MO/TO purchase reversal, MO/TO purchase


cancellation, MO/TO purchase cancellation reversal,
4. MO/TO refund: refund (online), manual refund.
1.1.3.2 Transaction process
Process of normal transactions, exceptional transactions and error transactions is the
same as traditional authorization, pre-authorization, and purchase type.
1.1.4

The use of key fields

1.1.4.1 Field 25
For MO/TO, value 08 in field 25 is used to identify MO/TO authorization, MO/TO
purchase from traditional authorization and purchase transactions, value 18 is used to
identify MO/TO pre-authorization from traditional pre-authorization transactions. The
acquirer should fill in the request message in accordance with the definition of the
field.
1.1.4.2 Field 60.2.5
Value 19 is added in Field 60.2.5 to indicate MO/TO transactions initiated by fax,
value 08, 09 or 17 to indicate MO/TO business initiated by telephone, and value 12 to
indicate manual MO/TO transactions initiated from the public service platform of
UnionPay.
1.1.4.3

Values for key fields

Transaction Name

Message type

Transaction
Processing
Code F3

Point of
Service
Conditi
on code
(F25)

Terminal
TypeF60.
2.5

MO/TO purchase

0200/0210

00x000

MO/TO
cancellation

purchase

0200/0210

20x000

08,09,17 Telephone

MO/TO
reversal

Purchase

0420/0430

00x000

19 - Fax

MO/TO
Purchase
cancellation reversal

0420/0430

20x000

MO/TO Authorization

0100/0110

00x000

MO/TO Authorization
cancellation

0100/0110

20x000

08

12
Public
Service
Platform
of

Transaction Name

MO/TO
reversal

Message type

Transaction
Processing
Code F3

Authorization

0420/0430

00x000

MO/TO Authorization
cancellation reversal

0420/0430

20x000

MO/TO
Pre-authorization

0100/0110

03x000

MO/TO
Pre-authorization
cancellation

0100/0110

20x000

MO/TO
Pre-authorization
completion (request)

0200/0210

00x000

MO/TO
Pre-authorization
completion cancellation

0200/0210

20x000

MO/TO
Pre-authorization
completion(notice)

0220/0230

00x000

MO/TO
notice

0220/0230

00x000

MO/TO
Pre-authorization
reversal

0420/0430

03x000

MO/TO
Pre-authorization
cancellation reversal

0420/0430

20x000

MO/TO
Pre-authorization
completion(request)
reversal

0420/0430

00x000

MO/TO
Pre-authorization
completion cancellation
reversal

0420/0430

20x000

Manual
MO/TO
pre-authorization
cancellation

0100/0110

20x000

Manual
MO/TO
pre-authorization

0220

00x000

Settlement

Point of
Service
Conditi
on code
(F25)

08

Terminal
TypeF60.
2.5

UnionPay
(manual
transactio
n)

18

Transaction Name

Message type

Transaction
Processing
Code F3

Point of
Service
Conditi
on code
(F25)

Terminal
TypeF60.
2.5

completion
Manual
MO/TO
pre-authorization
cancellation reversal

0420/0430

20x000

1.1.4.4 Definition of message format


Transaction Name

Section Number in Part II: On-line Message

MO/TO purchase

7.5.1.1.10

MO/TO purchase cancellation

7.5.1.1.12

MO/TO Purchase reversal

7.5.1.1.13

MO/TO Purchase cancellation reversal


MO/TO Authorization

7.5.1.2.1

MO/TO Authorization cancellation

7.5.1.2.1

MO/TO Authorization reversal

7.5.1.2.1

MO/TO Authorization cancellation reversal


MO/TO Pre-authorization

7.5.1.1.3

MO/TO Pre-authorization cancellation

7.5.1.1.5

MO/TO Pre-authorization completion


(request)

7.5.1.1.7

MO/TO Pre-authorization completion


cancellation

7.5.1.1.12

MO/TO Pre-authorization
completion(notice)

7.5.1.1.14

MO/TO Settlement notice

7.5.1.1.15

MO/TO Pre-authorization reversal

7.5.1.1.13

MO/TO Pre-authorization cancellation


reversal
MO/TO Pre-authorization
completion(request) reversal
MO/TO Pre-authorization completion
cancellation reversal
Manual MO/TO pre-authorization
cancellation

7.5.1.1.5

Manual MO/TO pre-authorization


completion

Offline message

Manual MO/TO pre-authorization

7.5.1.1.13

cancellation reversal

1.1.5

Clearing and settlement process

The clearing and settlement process of MO/TO authorization, MO/TO


pre-authorization and MO/TO purchase is the same as the process of the common
authorization, pre-authorization and purchase settlement process.
1.1.6

Key issues in the transition period

There is no transition period for new transactions. As a new transaction type, MO/TO
could only be successful when both the acquirer and the issuer support the
transaction.
1.2

RECURRING
1.2.1

Transaction description

A recurring transaction refers to a transaction initiated by a merchant that is


authorized by a cardholder in an agreement to make the payment for some services on
behalf of the cardholder with the his/her credit card and submit the transaction
information (or batch file) to its acquirer on a regular basis through the acquiring
platform, terminals or other applicable systems.
Only credit cards are authorized to initiate recurring transactions for cross-border
transactions currently. For single message transaction the message format is the same
as that of purchase transaction while for dual message transaction, the message format
is the same as that of authorization transaction, the only difference lies in the value of
F25.
1.2.2

Compliance

1.2.2.1 For Acquirers


It is optional for acquirers. Acquirers having the demand to expand recurring
merchants and transactions may choose to update system to support such transactions.
1.2.2.2 For issuers
It is optional for issuers. Issuers who would like to provide this function to their credit
card holders may update system to support recurring transactions.

1.2.3

Transaction types and processes

1.2.3.1 Transaction Type


Recurring supports the following transaction types:
1. Authorization type: recurring authorization, recurring authorization cancellation,
recurring authorization cancellation, recurring authorization cancellation reversal
2. Purchase type: recurring, recurring reversal, recurring cancellation, recurring
cancellation reversal
1.2.3.2 Transaction process
Its ordinary transaction, exceptional transaction and dispute transaction are the same
with common authorization and purchase transactions.
1.2.4

Usage of key fields

1.2.4.1 Field 25
In recurring business, value 28 in field 25 is used to distinguish other authorization
type transactions and traditional purchase transactions. The acquirer should fill out
the transaction request message to be forwarded by it in accordance with the
definition of the field.
1.2.4.2

Values for key fields

Transaction Name

Message type

Transaction
processing
code (F3)

Point of
Service
Condition
Code
(F25)

Terminal
Type
(F60.2.5)

Recurring

0200/0210

00x000

28

Recurring cancellation

0200/0210

20x000

Recurring reversal

0420/0430

00x000

Recurring cancellation reversal

0420/0430

20x000

To be fill out
based on the
actual
situation

Recurring authorization

0100/0110

00x000

Recurring authorization
cancellation

0100/0110

20x000

Recurring authorization reversal

0420/0430

00x000

Recurring authorization
cancellation reversal

0420/0430

20x000

1.2.4.3 Definition of Message Format


Transaction Types

Section in Part II Online Message

Recurring

7.5.1.1.11

Recurring cancellation

7.5.1.1.12

Recurring reversal

7.5.1.1.12

Recurring cancellation reversal


Recurring authorization

7.5.1.2.1

Recurring authorization cancellation

7.5.1.2.2

Recurring authorization reversal

7.5.1.2.3

Recurring authorization cancellation


reversal
1.2.5

Clearing and settlement process

The clearing and settlement of recurring authorization and recurring transaction in


single message is the same as that of authorization and purchase transaction
respectively.
1.2.6

Key issues in transition period

There is no transition period for new transactions. As a new transaction type,


recurring could only be successful when both the acquirer and the issuer support the
transaction.
1.3

Online refund and offline refund for E-cash


1.3.1

Description

Pure e-cash card and e-cash card bound with debit and credit account in the back
office should support online refund, off-line refund and manual refund. With a
"pre-load balance field" account in the back office, the refund amount of pure e-cash
card will reach the back office account first. For off-line purchase transactions
whose original record cannot be found in the transaction details of terminals, its
refund will be done online; for off-line purchase transaction whose original record can
be found, its refund will be done offline. Therefore, refund (online) transactions are
added in this specification enhancement, and the previous IC card offline purchase
file is changed as IC card offline settlement file, in which the transaction code TC301
is added to indicate off-line refund.

1.3.2

Compliance

1.3.2.1 For Acquirers


It is optional for acquirers.
1.3.2.2 For Issuers
It is optional for issuers.
1.3.3

Transaction types and processes

1.3.3.1 Transaction Type


Refund (online) transaction is a new transaction for IC card based on CUPIC debit
and credit application.
1.3.3.2 Transaction process
The process of refund (online) transaction of E-cash is the same as the current process
of refund (online) of IC card based on CUPIC credit and debit application and offline
refund process is the same as that of off-line purchase.
1.3.4

Format of online message

The message format of refund (on-line) of E-cash is the same as that of IC card refund
and the settlement advice based on CUPIC debit and credit application.
1.3.5

Definition of message format

Transaction

Section in Part II

Refund (on-line)

7.5.1.1.16

1.3.6

Clearing and settlement process

Refund (online) transaction of IC card e-cash application and general refund (online)
transaction files will be included in general audit trailer files. In IC card off-line
settlement file, transaction code 301 is added to indicate off-line refund, in the same
format as TC300 (off-line purchase). The process of manual refund is the same as that
of the magnetic stripe card, which will be included in the general audit trailer file.

10

1.3.7

Key issues in transition period

There is no transition period for new transactions. As a new transaction type,


recurring could only be successful when both the acquirer and the issuer support the
transaction.
1.4

Cross-border remittance
1.4.1

Description

Currently two kinds of remittance are supported:


- Remittance in non-RMB currency from outside China Mainland to accounts in
mainland China, being settled in RMB
- Remittance in one non-RMB currency from one country outside of China Mainland
to the other non-RMB accounts in the other country outside of China Mainland,
settled in non-RMB.
Prior to the cross-border remittance transaction, remittance verification must be
initiated. In addition, with the change of requirements for remittance verification,
remittance verification message is changed accordingly, based on the following
reasons:
1. In remittance verification, the acquirer should forward the identity information
(name, ID number) of the remitter and purpose of the remittance, which will not be
forwarded to the issuer;
2. In remittance verification, the issuer needs to return the cardholders identity
information, which will not be forwarded to the acquirer;
3. The transfer-out partys name sent by the acquirer shall be in alphabets.
4. For account remittance, the transfer-out partys account number is required to be
forwarded in the remittance verification message.
1.4.2

Compliance

1.4.2.1 For acquirers


Its mandatory for acquirers who have finished the system modification for
cross-border remittance to adjust the system to be compliant with this new
specification.
1.4.2.2 For Issuers
Issuers who would like to support remittance transfer-in with their cards shall modify
their systems to comply with this new specification.

11

1.4.3

Transaction types and processes

1.4.3.1 Transaction Type


Remittance verification;
Remittance.
1.4.3.2 Transaction process
It is the same as the previous remittance transaction.
1.4.4

Explanation on online message

1.4.4.1

Value of key fields

The value of key field of the message is the same as that of the previous remittance
verification transaction and remittance transaction:
1As the purpose of remittance needs to be forwarded in the remittance verification,
RE usage, a fixed-length of 3 digits being used to indicate the remittance purpose, is
added in field 48
2Transfer-out partys name and ID number will be forwarded through field 61,
among which the transfer-out party name is stored in the cardholders name of NM
usage
3. For a remittance through a transfer-out account, the transfer-out remittance account
needs to be forwarded in field 102 in the remittance verification
1.4.4.2 Definition of message format

1.4.5

Transaction

Section No. in Part II

Remittance verification

7.5.1.18

Remittance

7.5.1.18

Clearing and settlement process

Settlement process is the same as that of the previous remittance (online) transaction.
1.4.6

Key issues in transition period

There is no transition period for this transaction.

12

Enhancements on Settlement Files


2.1.

(FCP) Format of fee collection and payment file

2.1.1 Enhancement Description


In order to successfully settle the funds in disputed transactions between institutions,
fee collection and payment transaction have been added. Theres no online message
for this transaction. Settlement procedures will be completed by entering manually
into CDRS., the settlement result will be reflected in the new file record of fee
collection and payment (FCP).
Fee collection transaction can only be initiated by UnionPay, while fee payment
transactions may be initiated either by both UnionPay and participants.
File of fee collection and payment (IFDYYMMDD?? FCP) is added. For specific
definition, please refer to Technical Specifications: Part III: File Interface
4.1.1.3 .
2.1.2 Compliance
It is mandatory for all acquirers and issuers.
2.2

TC804 (MCT) (New)

2.2.1 Enhancement Description


In order to add description of MCC in the stand-in authorization , below are
especially added in the stand-in authorization parameter file: the whole file of
merchant group for the stand-in authorization institution, rejection file of the whole
file of merchant group for the stand-in authorization institution, rejection file of the
incremental file of merchant group for the stand-in authorization institution, also
TC804 record format is added to describe merchant group information. For specific
definition, please refer to Technical Specifications: Part III File Interface. The process
of this type of parameter file is the same as other stand-in authorization. For details,
please refer to Technical Specifications: Part III File Interface 4.1.3.2.
Issuers having selected the stand-in authorization business can add and forward the
MCC in this record format in the whole file of merchant group and enquiry of
increment amount.
2.2.2 Compliance
Issuers who have adopted stand-in authorization may modify system to comply with
the above amendment.
13

2. 3

Format of General Audit Trailer File

2. 3.1 Enhancement Description


1. Since the country information of the merchant, i.e., value of field 19, should be
reflected in relevant files of cross-border transactions, a field of merchant country
code should be added in the reserved field of general audit trailer fileCOM/COMB.
2. Filling blank instead of N in the digit for stand-in authorization indicator in the
general audit trailer file stands for non stand-in authorization transactions.
2. 3.2 Compliance
The first enhancement is mandatory for all acquirers.
The second enhancement is mandatory for all acquirers.
2. 4

Dispute Audit Trailer File

2.4.1 Enhancement Description


In the dispute audit trailer file, it also needs to reflect the country information of the
merchant, i.e., value of field 19. So, a field of merchant country code is added in the
reserved field of dispute audit trailer file(ERR/ERRB.
2. 4.2 Compliance
It is a mandatory for all acquirers and issuers.
2. 5

Settlement files of Dual Message

2. 5.1 Enhancement Description


1. The merchant country code also needs to be added in dual message files, therefore,
field 19 is added in the reserved field of section 0 in the dual message settlement files.
The reason for the adding please refer to Section4.1.4.12. Requirement for filling in
the digit for stand-in authorization identifier in section 0 is amended, filling blank in
the digit for stand-in authorization identifier stands for non stand-in authorization
transaction, reasons for the amendment please refer to; Section4.1.4.1
3. Since field 0, field 3 and field 25 are key elements in determining the transaction
type, and new values for MO/TO and recurring transaction have also been added in
field 25 to identify the transaction type, so field 25 is added in the reserved field in
section 0 of dual message settlement files;
4. I/O descriptions concerning foreign exchange rate in section 1 of dual message
settlement files are revised to O because settlement information is returned to the
14

institutions by CUPS where the institutions should receive instead of forwarding the
message, which include settlement value, settlement currency, settlement exchange
rate, debit amount of the cardholder, currency of the cardholders account, exchange
rate of charging the cardholder, service fee, currency of service fee, exchange rate of
service fee;
5. Supplementary description is given to the filling of some fields in section 0; for
settlement transactions, filling in the following fields of transaction transmission time
and system tracking number is changed to filling in the value of the corresponding
field of the original authorization transactions. For refund transactions, the field will
be re-generated by the acquirer; for different circumstances, further detailed
descriptions are given to the requirement for filling in the authorization response
identification code of the field, the authorization date, the original transaction
information, the single and dual message ID (including IC card offline purchase, IC
card offline refund, and general refund).
2. 5.2 Compliance
It is mandatory for all the dual message institutions. However, because a meaningful
field is added in the reserved field, the structure of the whole file is not changed. And
the institutions having not implemented the transformation won't be affected.
2. 6

File rejection code

2. 6.1 Enhancement Description


Since the current rejection codes for rejection of settlement files are the same as those
for online messages and are not enough to describe all the reasons of rejecting the
settlement files, the rejection codes for settlement files are added in the Part appendix.
For details please refer to the Appendix.
2. 6.2 Compliance
It is mandatory for all the dual message institutions.
2. 7

Introduction to the processing of presentment files by CUPS

Dual message acquirers shall present to UnionPay with a presentment file on each day
before the dual message transactions are settled by CUPS (4:00 am each day). After
the processing is completed, CUPS will generate receipt settlement file, a rejection
file and a reconciliation report, and feedback them to the acquirer. File name of the
presentment file forwarded by the institution is OFCYYMMDD51C, file name of
successful settlement file is IFCYYMMDD51C, name of the rejection file is
IFRYYMMDD51C, name of reconciliation report is IFRYYMMDD01C608DZ, and
format of all the files is TEXT file. Presentment file, successful settlement file and
15

rejection file are all in line with Technical Specification V2.0, while the reconciliation
report is in the format of report file. Below is the introduction to the processing of
presentment files by CUPS.
2. 7.1 Explanation on key fields in presentment files
There are four key fields in Block 0 of the presentment file: institution identification
number, system trace number, transaction time and authorization date and these four
key fields shall be unique in the same presentment file.
From the current situation, major transactions are TC100 (presentment) and TC101
(refund).
For TC100 transaction, the key fields are institution identification number, system
trace number and transaction time. The combination of these three fields shall be
unique to locate the original online authorization transaction. These three fields must
be identical to those in the original online authorization transaction.
For TC101 file, the institution identification number shall be the same as that of the
original transaction. But the system trace number and the transaction time of TC101
transactions shall be those of the refund transactions instead of those of TC100
transactions to avoid duplicate of the combination of the above-mentioned three key
fields.
.
For TC101 transaction, fields used to locate the original transaction are institution
identification number, original system trace number of original transaction, original
transaction time of original transaction and the original settlement date of original
transaction, which are different from those for TC100 transaction.
For TC100 or TC101 transaction with estimated amount of original transaction, the
above-mentioned fields may not be able to locate the original authorization
transaction. For these presentment transactions, original authorization transactions can
be located indirectly.
Step One: Locate the primary account number and authorization response
identification code field of original transaction;
Step Two: Search the authorization historical library through these two fields
(authorization history library maintains the basic information of all the authorization
transactions with estimated amount within 3 months) to find the institution
identification number, system trace number, transaction date and time, authorization
date of the original transaction, through which to locate the original online
authorization transaction.

16

2.7.2 The processing of presentment files by CUPS


For the presentment files forwarded by acquirers, except the header and the end of the
file, each line represents one transaction, which contains at least segment 0 and
segment 1, while in IC card related transactions also contains segment 2. When
processing the presentment files, CUPS will read transaction records one by one from
beginning to the end. Each read transaction record will be processed according to the
following steps until the end of the file:
Read a transaction from the presentment file

Search for the original transaction through key fields

Validity Verification

Insert into the dual message log

2. 7.3 Method of tracing the original transaction


Before tracing the original transaction, first it needs to obtain relevant fields of the
original transaction. Then it searches the original transaction in the order of
"authorization date", "authorization date -1", "authorization date + 1", and once the
transaction is found, it will stop searching immediately. If the transaction cannot be
found within 3 days, it may judge that the original transaction may be with an
uncertain amount. Then the system will switch to search the history authorization
library according to the key information of the institution identification number,
system trace number, transaction time and authorization date, etc. of the original
authorization transaction. If the transaction still cannot be found in the history
authorization library, the system will reject the presentment transaction with the
reason of "cannot trace the original transaction", if key information of the original
transaction is found in the history authorization library, the system will re-verify the
transaction log to find detailed information of the original authorization transaction
according to this key information.

17

2. 7.4 Description of rejection code


In the previous version of specification, the rejection code for presentment transaction
is specified as that of the online transaction. In accordance with the specification, the
rejection code of rejection file IFCYYMMDD51R is the on-line rejection code. But
because the procession of exceptional online transaction is different from that of the
presentment transaction, the rejection code of the online transaction is unable to
describe the exceptional circumstances occurred in processing presentment transactions.
Therefore, the new version of specification has defined a new file rejection code and
the equivalent online rejection code.
2. 7.5

Validity Verification

The system will verify the legitimacy of each transaction to determine whether to
accept the transaction or not. Legitimacy verification mainly includes:
Format verification:
Currently it will only check the file header, the file tail and each field length. If the
file is found invalid, it will reject the whole file, and will not process any transaction
in the file.
The number of transactions recorded at the end of the file should be the same as the
actual number of transactions. Otherwise, it will reject the whole file, and will not
process any transactions contained in the file.
Presentment period:
Presentment period for TC100 transaction is 30 days from the date of the original
authorization transaction; any transactions over 30 days will be rejected.
Presentment period for TC101 transaction is 90 days from the date of the original 100
presentment transaction; any transactions over 90 days will be rejected.
Original transaction relevant:
If the original authorization transaction cannot be found, then the transaction will be
rejected;
If the original master account of the transaction is not identical with that of the
original authorization, then the transaction will be rejected;
If the original transaction being found is a non-authorization transaction, then the
transaction will be rejected;
If the currency of the presentment transaction is not the same with that of the original
transaction, then the transaction will be rejected;
If the original transaction is an unsuccessful authorization, then the transaction will be
rejected;
If the original transaction is a reversed authorization, then the transaction will be
rejected;
If the merchant code of the presentment transaction is not the same as the original
transaction, then the transaction will be rejected;
If the merchant type of the presentment transaction is not the same as the original
transaction, then the transaction will be rejected;
18

If the card media of the presentment transaction is not the same as the original
transaction, then the transaction will be rejected;
If the original transaction is a fixed amount authorization, but the amount of the
presentment transaction does not equal with the original transaction, then the
transaction will be rejected;
If the original transaction is a non-fixed amount authorization, but the amount of the
presentment transaction is greater than the maximum limit of a presentment, then the
transaction will be rejected;
If the original transaction is a non-fixed amount authorization, but the authorization
code of the presentment transaction is not the same as the original transaction, then
the transaction will be rejected.
Transaction type restrictions:
The current system supports TC100, TC101 and TC102 transactions, and other
transactions will be rejected.
Credit adjustment without presentment is related with a chargeback without
presentment:
If credit allocation or chargeback without presentment has been done to the original
authorization transaction, then the presentment transaction will be rejected.
Duplicate transactions:
If a presentment was done for the transaction earlier, and no repeated presentment is
allowed, then the transaction will be rejected;
If refund (TC101) is done for transactions without presentment, then the refund
transaction will be rejected;
If refund is done for several times for transactions with presentment, but the total
amount of the refund exceeds the amount of the presentment, then the last refund
transaction which exceeds the limit will be rejected.
2. 7.6

Other explanations for the presentment

The date of the presentment file, the successful settlement file and the rejection file
has one days difference with the settlement date of CUPS, i.e., the file date is the
settlement date plus 1. Suppose the UnionPay system will process day Ts settlement
on day T+1, then the file name provided by the institution on T day or T+1 day
( before 4:00) should be T+1, for example: If today is 24th, and tomorrow is 25th ,
then the institution needs to write 25th on the file submitted on 24th and before 4:00
of 25th, while the system will carry out settlement after 4:00 of 25th, which is
actually processing transactions of 24th.

19

Enhancements for Fields


3.1
3.1.1

Instruction for filling F22, F60.2.2 and F60.2.3


Enhancement Description

F22: Currently the first two digits of field 22 indicate the method for reading cards,
however, the classification criteria is different, e.g., some are classified as per reading
by magnetic stripe card or IC card, and others are classified as per reading by contact
or contactless method. The different classification criteria will result in chaos in
filling out the value of this field by the acquirers, so in the latest amendment the
classification criteria are unified. The basic idea is to have a clear description without
modifying the value. For details, please refer to Part II: On-line Message. PF60.2.2:
Values of these sub-fields are also classified by different criteria. The value of 2 and 5
describe the readable card media, but not indicating whether it has a contactless
interface or not; while the value of 6 defines that it has a contactless interface, without
defining the readable card media. As a result, it should be classified by unified criteria
with a unified description just as F22, the basic idea of which is to have a clear
description as well without modifying the value. For details, please refer to Part II:
On-line Message. From the description of the amended value, theres a relationship of
containing and being contained between the values, i.e., 6 contains 5 and 5 contains 2.
In filling out terminal capacity, the maximum capacity of the terminal should be filled
out. When sorting as per the capability, 6 is the highest, 5 follows it, and 2 is the
lowest. When swiping a real magnetic stripe card transaction on a terminal of capacity
of 5 or 6, the field still needs to be filled out with 5 or 6, instead of 2.
As the description of the above two fields is not precise enough, their relevant values
are even more confusing.
1. Value of 05,95 in F22 corresponds with value of 5 in F60.2.2, these corresponding
values looks as if the terminal with the value of 5 does not have the capacity to read
non-contact type card.
2. Value of 07, 91, 96, 97, 98 in F22 correspond with value of 6 in F60.2.2. These
corresponding values seem as if the terminal with the value 6 can only read IC card.
But in F60.2.2 its clearly indicated that the value 6 indicates contactless interface,
without indicating whether there is any contact interface, while the value of 97 in F22
does clearly state that it reads though the contact interface.
Therefore, both F60.2.2 and F22 should be re-described from the two aspects of card
media and contact method.
F60.2.3: The current description of the sub-field is too simple. If there is no further
explanation for "the last transaction" mentioned in the description, different people
may have different interpretations. Therefore, in order to avoid ambiguity and
enhance clarity of the specification, it is necessary to have a more detailed description
of the scenarios of the sub-field with the value of 1 or 2. For details, please refer to
Part II: Online Message
20

CUPS will determine the transaction media, based on the combined value of the first
two digits of service point in input code (F22), terminal reading capability (F60.2.2),
and IC card condition code (F60.2.3) of the message, and will store the result in
F60.3.6 to help the issuers to identify the transaction media. For details, please refer
to Part II: On-line Message 5.2.2 Transformation Type( optional/mandatory)
3.1.2 Compliance
It is optional for acquirers; if the acquirer wishes to carry out IC card business, it
should be able to correctly forward the combined value of these three fields based on
the transaction scenarios.
It is optional for issuers; if the issuer wishes to carry out IC card business, it should be
able to identify relevant values of these three fields, and correctly identify the
transaction media.
3.1.3

Issues to be noticed by the acquirers

If the transaction media is FallBack card, the accepting terminal should be able to
correctly forward field 60.2.3, as the existence of large amount of the value 1 or 2 in
this field represents different degree of suspected merchant fraud.
3.1.4

Issues to be noticed by the issuers

When the transaction media is FallBack card, if therere a large amount of value 1 or
2 in field 60.2.3, which represent different degree of suspected merchant fraud, the
issuers should be able to correctly identify them.
3.2

Processing of F61
3.2.1

Enhancement Description

3.2.1.1 Requirement of verification method


For the large number of non-password and non-magnetic transactions in the market,
in order to ensure transaction security and fraud risk, its also required to clarify
contents that must be verified by the issuer for on-line transactions, such as
verification of PVN, CVN, etc.. For other transactions, it should also clarify whether
it is needed to verify the magnetic track, password or the validity of the card and so
on. To achieve this purpose, it has chosen to store contents required to be verified by
the acquirers in this field, and add AM usage in sub-field F61.6. For specific
definition, please refer to Part II: On-line Message

21

3.2.1.2 Name verification requirement


F61 is used to store ID verification information of various types of cardholders, such
as the defined ID card information. With the development of various business types,
single identity verification cannot meet the requirements. As bankcard frauds and
similar cases are changing and increasing, the increasingly complicated market
environment has resulted in the need of verifying the cardholders name. In
particularly, in non-card transactions of trans-territory remittances and deposits,
verification of the non card transaction, i.e., verification of the cardholders name,
who is either a recipient or a transfer-out party, has become more important and
urgent. The premise of name verification is that the name should be forwarded to the
issuer by means of the on-line message. To do this, this field has been selected to
store the names to be verified. And NM usage is added in the sub-field F61.6. For
specific definition, please refer to
3.2.2

Processing instruction

3.2.2.1 Processing of verification mode


The current specification defines 8 types of contents that need special attention of the
issuers in verification, including: password authentication, card validity verification,
identity card verification, magnetic track information verification, fiduciary
relationship validation, CVN (CVN2) authentication, PVN authentication and name
validation . These verification contents are arranged in sequence. As long as theres a
valid value in the byte, it indicates that the issuer needs to verify the content. These
verification contents can either occur alone, or appear in combination. Occurrence
alone means that it only needs to verify the only one content; occurrence in
combination indicates that multiple contents need to be verified.
In addition to defining fixed format verification content, the usage has also defined a
larger space for the acquirer to attach other necessary contents to be notified to the
issuer. The acquirer can freely fill in this field according to their own business
requirements.
There are a few contents concerning the usage that need special attention:
1, Once this sub-field appears, it has the highest verification priority. For example, if
the field requires verifying magnetic track information, but the forwarded on-line
transaction message does not carry a magnetic track. Although in terms of message
format, this message is correct, the issuer should reject the transaction as it does not
meet the verification requirements of the business.
2. Currently each usage of F61.6 are mutually exclusive, so when this usage requires
to verify names, the name can only be stored in the above described "customized
business data" .Since NM usage cannot appear when the AM usage occurs, NM
usage cannot be used to forward names.

22

3.2.2.2 Method of filling in names


For the forwarded names, as there may need to fill out two names (e.g. in the transfer
transaction, there are a transferor cardholder and a transferee cardholder), NM usage
has defined two name fields, Name field 1 and Name field 2 respectively. To facilitate
a unified processing, for transactions only having one name, all the names will appear
in name field 1, such as deposit transactions and cash withdrawal transactions.
Although the cash flow is in the opposite direction, only one account name will need
to be verified, so all of them will use name field 1. When the transaction needs to
verify two names, the cardholder name which is of higher security requirements will
be stored in name field 1, the other cardholder name will be stored in name field 2.
3.2.3

Compliance

It is optional for both acquirers and issuers.


3.2.4

Supporting transaction types and processes

Prior to the remittance business, a remittance verification transaction must be


forwarded, which must be successful before the remittance business can be
implemented. As a result, the remittance verification transaction only needs to send
F61, and there is no need to forward the remittance transaction once again. As such, in
addition to the remittance transactions, all the other transaction types defined in this
specification are required to support the new use of this field.
3.2.5

Instruction for settlement process

This amendment does not involve settlement processing.


3.2.6

Issues to be noticed by the acquirers

No special requirements for the acquirers.


3.2.7

Issues to be noticed by the issuers

For matters to be noticed by the issuers, please refer to the contents that need special
attention described in Section 5.3.2.1.
3.3

Instructions for filling out F42


3.3.1

Background

In transactions initiated at ATMs or self-service machines, as the machines do not


necessarily correspond to specific merchants, some institutions do not know how to
23

fill out this field. At present, this field is freely filled out by the institutions. In order
to regulate the filling of the message field, if the acquirer has no special requirements
in the field, then all of them will be filled out with the default value 0.
3.3.2

Compliance

It is mandatory for acquirers and The issuer should be able to correctly identify all 0
values.
3.4
3.4.1

Instructions for using F54


Enhancement Description

With the increasing account types nowadays, the way of describing account balance is
different among different account types. For example, debit card calls it available
balance; while the credit card has both consumption limit and cash advance limit. In
addition, different types of transactions with different terminal types also have
different amount limits. Therefore, in the current specification, the simple definition
of carrying balance and available balance is less applicable. Based on the above
reasons, the specification has re-combed and described the carrying balance and the
available balance of the current day from the perspectives of different account types
(credit card account, debit card account), terminal types (POS, ATM) and transaction
types. For details, please refer to Part II: On-line Message
3.4.2

Compliance

It is mandatory for both acquirers and issuers.


3.4.3

Issues to be noticed by the issuers

The issuer should be able to determine whether to refund the balance information
based on transaction types and terminal types. If it has refunded balance information
in the case that it should not have done it, then the issuer should bear its own risk.

Summary of Enhancements

24

The following table summarizes all the enhancements and the effective date of each enhancement.
S.N

Type

Ehancement

Compliance for

Compliance

Effective

Where

Availabe

acquirer

for issuer

Date

to look

Online Test

Remarks

Time
1.

New Programs

MO/TO

Optional

Optional

15 Apr, 2011

1.1

31 Dec, 2010

The

2.

and Functions

Recurring

Optional

Optional

15 Apr, 2011

1.2

31 Dec, 2010

optional

Optional

Optional

21 Oct, 2011

1.3

30 Apr, 2011

only for those participant

3.

online refund and

offline

5.

31 Dec, 2010

the programms.

2.1

30 Jun, 2011

Only apply to acquirers

21 Oct, 2011

2.2

15 Apr, 2011

Mandatory

21 Oct, 2011

2.3

15 Apr, 2011

Mandatory

Mandatory

21 Oct, 2011

2.4

15 Apr, 2011

Mandatory

Mandatory

21 Oct, 2011

2.5

15 Apr, 2011

Add File rejection code

Mandatory

Mandatory

21 Oct, 2011

2.6

15 Apr, 2011

Optimization of field 22,

Mandatory

Mandatory

21 Oct 2011

3.1

15 Apr, 2011

Optional

Optional

Enhancements

Add

Mandatory

Mandatory

on

collection

---

Optional

Mandatory

files
6.

programs

1.4

Cross-border remittance

settlement

date

record format for fee


and

of
are

that choose to implement

refund for E-cash


4.

effective

15 Apr,2011

payment

(FCP) files
TC

804:Processing

of

merchant group files of


stand-in

authorization

institutions
7.

General Audit Trailer File


(F19)

8.

Dispute Audit Trailer File


(F19)

9.

Settlement

file

for

dual

message
10.
11.

Enhancements

S.N

Type

Ehancement

Compliance for

Compliance

Effective

Where

Availabe

acquirer

for issuer

Date

to look

Online Test
Time

for fields

field 60.2.2 and field 60.2.3

12.

Optimization of field 61

Optional

Optional

21 Oct,2011

3.2

15 Apr, 2011

13.

Processing of field 42

Mandatory

__

21 Oct,2011

3.3

15 Apr, 2011

14.

Processing of field 54

Mandatory

Mandatory

21 Oct,2011

3.4

15Apr, 2011

Remarks