Implementation Guide for Technical Enhancement_April 2011

8/19/2019 Implementation Guide for Technical Enhancement_April 2011

1/30

Implementation Guide for Technical

Enhancements

April 2011


2/30

THIS PAGE INTENTIONALLY LEFT BLANK.


3/30

Table of ontents

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


4/30

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


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


3.4.2

Compliance .......................................................................................................... 24

3.4.3 Issues to be noticed by the issuers........................................................................ 24

4

Summary of Enhancements ....................................................................................................... 24


5/30

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.


6/30

THIS PAGE INTENTIONALLY LEFT BLANK.


7/30

1 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

it‟s 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

t ti


8/30

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 toidentify 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

V l 19 i dd d i Fi ld 60 2 5 t i di t MO/TO t ti i iti t d b f


9/30

Transaction Name Message type Transaction

Processing

Code F3

Point of

Service

Conditi

on code

(F25)

Terminal

TypeF60.

2.5

MO/TO Authorization

reversal

0420/0430 00x000

08

UnionPay

(manual

transactio

n)

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

0220/0230 00x000


10/30

Transaction Name Message type Transaction

Processing

Code F3

Point of

Service

Conditi

on code

(F25)

Terminal

TypeF60.

2.5

completion

Manual MO/TO

pre-authorizationcancellation 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.10MO/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


11/30

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

b h lf f th dh ld ith th hi /h dit d d b it th t ti


12/30

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, recurringcancellation reversal


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


13/30

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.2Recurring 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

Th i t iti i d f t ti A t ti t


14/30

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


Refund (online) transaction is a new transaction for IC card based on CUPIC debit

and credit application.


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


15/30

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


16/30

1.4.3 Transaction types and processes


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:

1．As 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

2．Transfer-out party‟s name and ID number will be forwarded through field 61,


17/30

2 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. There‟s 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 specificdefinition, 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.


18/30

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 file（COM/COMB）.

2. Filling blank instead of „ N‟ in the digit for stand-in authorization indicator in thegeneral 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


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


19/30

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 cardholder‟s 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


20/30

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 beunique 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

i id d li f h bi i f h b i d h k


21/30

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


22/30

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

i i d i h fil


23/30

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

i ill b j d


24/30

3 Enhancements for Fields

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


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, there‟s a relationship of


25/30

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


26/30

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 cardholder‟s name. In

particularly, in non-card transactions of trans-territory remittances and deposits,

verification of the non card transaction, i.e., verification of the cardholder‟s 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,


27/30

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


28/30

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 Instructions for using F54


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


29/30

1

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

S.N Type Ehancement Compliance for

acquirer

Compliance

for issuer

Effective

Date

Where

to look

Availabe

Online Test

Time

Remarks

1. New Programs

and Functions

MO/TO Optional Optional 15 Apr, 2011 1.1 31 Dec, 2010 The effective date of

optional programs are

only for those participant

that choose to implement

the programms.

2. Recurring Optional Optional 15 Apr, 2011 1.2 31 Dec, 2010

3. online refund and offline

refund for E-cash

Optional Optional 21 Oct, 2011 1.3 30 Apr, 2011

4. Cross-border remittance Optional Optional 15 Apr,2011 1.4 31 Dec, 2010

5. Enhancements

on settlement

files

Add record format for fee

collection and payment

(FCP) files

Mandatory Mandatory 2.1 30 Jun, 2011 Only apply to acquirers

6. TC 804:Processing of

merchant group files of

stand-in authorization

institutions

--- Optional 21 Oct, 2011 2.2 15 Apr, 2011

7. General Audit Trailer File

(F19)

Mandatory Mandatory 21 Oct, 2011 2.3 15 Apr, 2011

8. Dispute Audit Trailer File

(F19)


9. Settlement file for dual

message


10. Add File rejection code Mandatory Mandatory 21 Oct, 2011 2.6 15 Apr, 2011

11. Enhancements Optimization of field 22, Mandatory Mandatory 21 Oct 2011 3.1 15 Apr, 2011


30/30

2

S.N Type Ehancement Compliance for

acquirer

Compliance

for issuer

Effective

Date

Where

to look

Availabe

Online Test

Time

Remarks

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

Implementation Guide for Technical Enhancement_April 2011

Documents

Transcript of Implementation Guide for Technical Enhancement_April 2011