03 v.I.P. System Services Volume 2 0853B

V.I.P.
System Services, Volume 2
V.I.P. SYSTEM
Effective: 1 June 2013
© 1999 - 2013 Visa. All Rights Reserved. 0853B–22
Visa Confidential
Important Note on Confidentiality and Copyright
The Visa Confidential label signifies that the information in this document is confidential and
proprietary to Visa and is intended for use only by Visa Clients subject to the confidentiality
restrictions in Visa's Operating Regulations, non-Client Third Party Processors that have
an executed and valid Exhibit K on file with Visa, and other third parties that have a
current nondisclosure agreement (NDA) with Visa that covers disclosure of the information
contained herein.
This document is protected by copyright restricting its use, copying, distribution, and
decompilation. No part of this document may be reproduced in any form by any means
without prior written authorization of Visa.
Visa and other trademarks are trademarks or registered trademarks of Visa.
All other product names mentioned herein are the trademarks of their respective owners.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR

TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE
INFORMATION HEREIN: THESE CHANGES WILL BE INCORPORATED IN NEW
EDITIONS OF THE PUBLICATION. VISA MAY MAKE IMPROVEMENTS AND/OR
CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS
PUBLICATION AT ANY TIME.
If you have technical questions or questions regarding a Visa service or capability, contact
your Visa representative. If you have comments or questions about this document, send
them to TCS@visa.com.
Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
Manual.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
About This Manual
Audience.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Audience
Structure of This Manual
Manual.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Conventions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Document Conventions
Descriptions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
System Documentation Descriptions
Contents
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Sources of System Information
Book.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
How To Use This Book
Samples.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Obtaining Report Samples
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
For More Information
PART 6 AUTHORIZATION DATABASE FILES AND SERVICES
CHAPTER 16 CARDHOLDER DATABASE OVERVIEW

16.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
In Brief 16-33
16.2 Files.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Database Files 16-33
16.3 Format.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
File Record Format 16-44
16.3.1 How V.I.P. Determines Effective and Update Date and Time. . . .16-4
16.4 Descriptions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
File Descriptions 16-44
16.4.1 Related Services Listings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
16.5 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Activity File 16-55
16.5.1 Merchant Group Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
16.5.2 PIN-Entry Attempt Activity Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
16.6 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Address Verification File 16-77
16.7 Advice File
File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
16-77
16.8 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Card-Level Product ID File 16-88
16.9 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Exception File 16-88
16.9.1 Visa International Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
16.9.2 Online Exception File Editing Summary (0302 Messages). . . . .16-10
16.9.3 Exception File Purge Date Assignments. . . . . . . . . . . . . . . . . . . . . . . . .16-11
16.9.4 Global Customer Assistance Services (GCAS). . . . . . . . . . . . . . . . . .16-12
16.10 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
PIN Verification File 16-12
12
16.11 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Portfolio File 16-13
13
16.12 File.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
Risk-Level File 16-14
14
16.13 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
For More Information 16-15
15
CHAPTER 17 AUTOMATIC CARDHOLDER DATABASE UPDATE (AUTO-CDB) SERVICE

17.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
In Brief 17-33
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 i

X Contents
17.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-

Eligible Participants 17-33
17.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
Service Summary 17-33
17.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
Participation Requirements 17-4
4
17.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
17.4.2 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
17.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
Related Messages 17-44
17.6 How Automatic Cardholder Database Update (Auto-CDB) Service Works Works.. . . . .17- 17-4
4
17.6.1 Advice Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.6.1.1 Exception File Update Advices. . . . . . . . . . . . . . . . . . .17-5
Contents
17.6.1.2 Exception File Discrepancy Advices. . . . . . . . . . . . .17-5

17.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
Process Flows 17-55
17.7.1 Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
Message Flows 17-66
17.8.1 Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7
17.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
Key Fields Glossary 17-88
17.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
CHAPTER 18 MERCHANT CENTRAL FILE SERVICE (MCFS)

18.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
In Brief 18-33
18.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
18.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
18.3.1 Updating the Merchant Central File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
18.3.1.1 Effective Date for File Updates. . . . . . . . . . . . . . . . . . .18-4
18.3.2 Acquirer Review of File Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
5
18.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18.4.3 File Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
18.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
18.5.1 MCFS-Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
18.5.2 Merchant Central File Update Messages. . . . . . . . . . . . . . . . . . . . . . . . . .18-7
18.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
How Merchant Central File Service (MCFS) Works 18-7
7
18.6.1 Establishing Merchant Central File Augmentation Data. . . . . . . . . .18-9
18.6.1.1 Merchant Category Code (Field 18). . . . . . . . . . . .18-10
18.6.1.2 Merchant Name, Location, Country (Field 43).18-10
18.6.1.3 Card Acceptor Identification Code (Field 42). .18-10
18.6.1.4 Terminal Identification (Field 41). . . . . . . . . . . . . . .18-11
18.6.1.5 Province, ZIP, or Postal Code (Field 59). . . . . . .18-11
18.6.1.6 Merchant Verification Value (Field 62.20). . . . .18-11
18.6.1.7 Vendor ID (Field 100). . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
18.6.2 Specifying Key Online Message Fields. . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
18.6.3 Updating MCFS Records Online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-15
18.6.3.1 File Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-15
18.6.3.2 Field 127 Merchant File Update Fields. . . . . . . . .18-17
ii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
18.6.4 Updating Merchant IDs for Visa, American Express,

MasterCard, and Check Acceptance Record Types. . . . . . . . . . . . .18-19
18.6.4.1 Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-19
18.6.4.2 Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-20
18.6.4.3 Using Both Field 41 and Field 42. . . . . . . . . . . . . . .18-20
18.6.5 Updating Merchant IDs for Universal Record Types. . . . . . . . . . . .18-20
18.6.5.1 Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-20
18.6.5.2 Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
18.6.5.3 Using Both Field 41 and Field 42. . . . . . . . . . . . . . .18-21
18.6.6 Updating Merchant IDs for Discover Record Types. . . . . . . . . . . . .18-21
Contents
18.6.6.1 Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
18.6.6.2 Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
18.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
Process Flows 18-21
21
18.7.1 Processing an Authorization or Financial Request. . . . . . . . . . . . . .18-21
18.7.2 Processing MasterCard Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-23
18.7.3 Terminal Translation Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-23
18.7.3.1 American Express Requests. . . . . . . . . . . . . . . . . . . .18-23
18.7.3.2 Discover Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-24
18.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
Message Flows 18-25
25
18.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
25
18.9.1 Key Fields Glossary for Merchant Central File Updates. . . . . . . .18-27
18.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
30
PART 7 AUTHORIZATION SERVICES
CHAPTER 19 ACCOUNT VERIFICATION SERVICE

19.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
In Brief 19-33
19.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
19.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
19.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
4
19.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4
19.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
19.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
How Account Verification Service Works 19-55
19.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
Process Flows 19-66
19.7.1 MasterCard AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8
19.8 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
19.9 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
10
CHAPTER 20 ADDRESS VERIFICATION SERVICE (AVS)

20.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
In Brief 20-33
20.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
20.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
20.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 iii

X Contents
20.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-

4
20.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4
20.4.3 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
20.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
20.5.1 Visa Custom Payment Services (CPS)/POS Transactions. . . . . . .20-6
20.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
How Address Verification Service (AVS) Works 20-6
6
20.6.1 Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7
20.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
Process Flows 20-88
Contents
20.7.1 When V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . .20-12

20.7.1.1 Forwarding AVS Data to Issuers. . . . . . . . . . . . . . .20-12
20.7.2 Address Verification Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-12
20.7.2.1 Address Verification Data Standards. . . . . . . . . . .20-12
20.7.2.2 Field 123 Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-13
20.7.3 Data Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-15
20.7.4 Matching Merchant Address Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
20.7.5 Translating Fixed and TLV Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
20.7.6 Field 123 Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
20.7.6.1 U.S.-Domestic Transactions. . . . . . . . . . . . . . . . . . . .20-19
20.7.6.2 U.K.-Domestic Transactions. . . . . . . . . . . . . . . . . . . .20-19
20.7.6.3 All Other Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-19
20.7.6.4 Result Code Conversion Based on
Jurisdiction and Representment
Rights (All Regions Except the U.S.
and the U.K.). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-21
20.7.6.5 Result Code Conversion Based on
Acquirer Participation (U.K. and U.S. Only). . .20-22
20.7.7 AVS Process Flow Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-23
20.7.7.1 V.I.P. Performs Address Verification. . . . . . . . . . .20-23
20.7.7.2 When the Issuer Performs Address
Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-23
20.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
Message Flows 20-24
24
20.8.1 V.I.P. Performs Address Verification and Authorization. . . . . . . . .20-25
20.8.2 V.I.P. Performs Address Verification Only. . . . . . . . . . . . . . . . . . . . . . . .20-28
20.8.3 Issuer Does Not Support Address Verification. . . . . . . . . . . . . . . . . . .20-29
20.8.4 Issuer Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-30
20.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
34
20.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
37
20.10.1 Merchant Guide for AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-37
CHAPTER 21 ADVICE RETRIEVAL SERVICE—BASE I

21.1 In Brief
Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
21-33
21.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
21.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
21.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
iv Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
21.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-4

21.5 Related Messages
Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
21-66
21.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
How BASE I Advice Retrieval Service Works 21-66
21.6.1 BASE I Advice Message Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-6
21.6.2 BASE I Message Processing Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
21.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
Process Flows 21-77
21.7.1 Multiple Stations per PCR Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9
Contents
21.7.2 BASE II Advice Delivery (Offline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9
21.7.3 Advice Retrieval During and After a VIC Switchover. . . . . . . . . . . .21-10
21.7.3.1 VIC Processing Hierarchy. . . . . . . . . . . . . . . . . . . . . . .21-10
21.7.3.2 During Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
21.7.3.3 After Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
21.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
Message Flows 21-11
11
21.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
12
21.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
12
CHAPTER 22 ADVICE RETRIEVAL SERVICE—SMS

22.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
In Brief 22-33
22.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
22.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
22.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
4
22.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-4
22.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
22.5.1 VisaNet-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-6
22.5.2 Member-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-7
22.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
How SMS Advice Retrieval Service Works 22-88
22.6.1 Creating SMS Advice Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-8
22.6.2 Receiving Advices in Batch File Format. . . . . . . . . . . . . . . . . . . . . . . . . . .22-8
22.6.3 Flexible Online Delivery of BASE II Advices. . . . . . . . . . . . . . . . . . . . . . .22-9
22.6.4 Processing SMS Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-9
22.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
Process Flows 22-99
22.7.1 Multiple Stations per PCR Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-11
22.7.2 Advice Retrieval During and After a VIC Switchover. . . . . . . . . . . .22-12
22.7.2.1 During Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12
22.7.2.2 After Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12
22.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
Message Flows 22-12
12
22.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
13
22.10 For More Information
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
22-14
14
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 v

X Contents
CHAPTER 23 ATM FORMAT CONVERSION SERVICE

23.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
In Brief 23-33
23.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
23.3 Service Summary
Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
23-33
23.3.1 ATM Format Conversion Service Options. . . . . . . . . . . . . . . . . . . . . . . . .23-4
23.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
4
23.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4
Contents
23.4.3.1 Existing Card Range Considerations. . . . . . . . . . . .23-4

23.4.3.2 New Card Range Considerations. . . . . . . . . . . . . . . .23-5
23.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
23.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
How ATM Format Conversion Service Works 23-6
6
23.6.1 Message Augmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-6
23.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
Process Flows 23-77
23.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
Message Flows 23-99
23.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
11
23.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
12
CHAPTER 24 CARD VERIFICATION VALUE (CVV) SERVICE

24.1 Foreword.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
Foreword 24-33
24.2 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
In Brief 24-44
24.2.1 CVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-4
24.2.2 dCVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-5
24.3 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
24.4 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
24.4.1 CVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-6
24.4.1.1 Generating and Encoding CVV and
iCVV Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-6
24.4.1.2 Verifying the CVV or the iCVV. . . . . . . . . . . . . . . . . . .24-6
24.4.2 dCVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-8
24.5 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
24.5.1 Issuer Participation Requirements (CVV and iCVV). . . . . . . . . . . . . .24-8
24.5.2 Acquirer Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-9
24.5.3 Testing for CVV and iCVV Service Participation. . . . . . . . . . . . . . . . .24-10
24.5.3.1 Issuer Testing
Requirements—Testing Plastics. . . . . . . . . . . . . . .24-10
24.5.3.2 Phases of the Issuer Testing Process. . . . . . . . .24-10
24.5.3.3 Acquirer Testing Requirements. . . . . . . . . . . . . . . . .24-12
24.5.4 Service Monitoring for CVV and iCVV Service Participation. . . .24-12
24.5.4.1 Issuer Monitoring Requirements. . . . . . . . . . . . . . . .24-13
24.5.4.2 Acquirer Monitoring Requirements. . . . . . . . . . . . .24-13
24.5.5 Planning and Implementation (CVV and iCVV). . . . . . . . . . . . . . . . . .24-14
24.5.5.1 Planning and Implementation for Issuers. . . . . .24-14
vi Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
24.5.5.2 Planning and Implementation for Acquirers. . .24-17

24.5.5.3 Initiating Full Participation. . . . . . . . . . . . . . . . . . . . . . .24-18
24.5.6 Acquirer and Issuer Participation Requirements—dCVV. . . . . . .24-18
24.5.6.1 Acquirers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-19
24.5.6.2 Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-19
24.6 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
20
24.7 How Card Verification Value (CVV) Service WorksWorks.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .24- 24-20
20
24.7.1 CVV and iCVV Verification Considerations. . . . . . . . . . . . . . . . . . . . . .24-22
24.7.2 CVV and iCVV Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-22
24.7.3 Invalid CVV Response Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-23
Contents
24.7.4 CVV Emergency Replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-23
24.7.4.1 CVV Emergency Replacement Error Codes. . .24-24
24.7.5 MasterCard CVV Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . .24-24
24.7.6 Application Transaction Counter (ATC). . . . . . . . . . . . . . . . . . . . . . . . . .24-24
24.8 How Dynamic Card Verification Value (dCVV) Service Works Works.. . . . . . . . . . . . . . . . .24- 24-25
25
24.8.1 dCVV Processing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-26
24.8.2 STIP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-27
24.8.2.1 Emergency Replacement dCVV Cards. . . . . . . .24-27
24.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
27
24.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
30
CHAPTER 25 CARD VERIFICATION VALUE 2 (CVV2) SERVICE

25.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
In Brief 25-33
25.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
25.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
25.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
5
25.4.1 Issuer Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-5
25.4.2 Acquirer Processor Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-6
25.4.3 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-6
25.4.3.1 Issuer Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-6
25.4.3.2 Acquirer Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-7
25.4.5.1 Issuer Implementation Requirements. . . . . . . . . . .25-8
25.4.5.2 Card Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-8
25.4.5.3 Acquirer Implementation Requirements. . . . . . . . .25-9
25.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
25.5.1 BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . .25-9
25.5.2 BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . .25-9
25.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . .25-
How Card Verification Value 2 (CVV2) Service Works 25-10
10
25.6.1 CVV2 Calculation, Encryption, and Verification. . . . . . . . . . . . . . . . . .25-10
25.6.1.1 CVV2 Expiration Date. . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
25.6.1.2 DES Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
25.6.1.3 Encryption Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
25.6.1.4 Card Verification Keys. . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 vii

X Contents
25.6.2 Issuer Option Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12

25.6.2.1 CVV2 ALL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
25.6.2.2 CVV2 NONE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
25.6.3 Stand-In Processing and CVV2 Failure Response Codes. . . . . .25-13
25.6.4 CVV2 Processing Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-13
25.6.5 CVV2 Verification-Only Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
25.6.6 CVV2 Emergency Replacements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
25.6.6.1 CVV2 Emergency Replacement Error Codes . 25-16
25.6.7 When Transactions Contain Both a CVV2 and a CAVV. . . . . . . .25-16
25.6.8 MasterCard CVV2 Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
Contents
25.6.9 American Express, Diners Club, and Discover Processing. . . . .25-17

25.6.9.1 American Express. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
25.6.9.2 Diners Club and Discover. . . . . . . . . . . . . . . . . . . . . . .25-17
25.6.10 Japan Credit Bureau (JCB). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
25.6.11 Account Funding Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-18
25.6.12 Visa Europe CVV2 CNP Fee Program. . . . . . . . . . . . . . . . . . . . . . . . . . .25-18
25.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
Process Flows 25-19
19
25.7.1 CVV2 Pass-Through Processing for Card-Present
Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-21
25.8 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
21
25.8.1 Key Fields Glossary for CVV2 Emergency Replacement. . . . . . .25-24
25.9 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
25
CHAPTER 26 CARDHOLDER AUTHENTICATION VERIFICATION VALUE (CAVV)

VERIFICATION SERVICE
26.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
In Brief 26-33
26.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
26.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
26.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
5
26.4.1 Issuer Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-5
26.4.2 Acquirer Processor Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
26.4.3 Required Verified by Visa Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
26.4.4 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
26.4.6.1 Issuer Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
26.4.6.2 Acquirer Considerations. . . . . . . . . . . . . . . . . . . . . . . . . .26-7
26.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
26.5.1 BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . .26-7
26.5.2 BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . .26-7
26.6 How Cardholder Authentication Verification Value (CAVV)
Verification Service Works
Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
26-88
26.6.1 CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-9
26.6.2 Verifying CAVV Results From Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
26.6.3 Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-15
26.6.4 Dispute Resolution Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-15
viii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
26.6.5 Ineligible Transactions Passing CAVV Validation. . . . . . . . . . . . . . .26-16

26.6.6 When Transactions Contain Both a CAVV and a CVV2. . . . . . . .26-16
26.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
Process Flows 26-16
16
26.8 Key Fields Glossary
Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
26-17
17
26.9 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
19
CHAPTER 27 CUSTOM PAYMENT SERVICE (CPS)/ATM

27.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
In Brief 27-33
27.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
Contents
27.3 Service Summary
Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
27-44
27.3.1 BASE I and SMS CPS Processing Overview. . . . . . . . . . . . . . . . . . . . . .27-4
27.3.2 CPS/ATM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-5
27.3.3 Liability for Non-Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-5
27.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
5
27.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-6
27.5 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
How Custom Payment Service (CPS)/ATM Works 27-77
27.6 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
Process Flows 27-77
27.6.1 Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-8
27.6.1.1 Downgraded Transactions. . . . . . . . . . . . . . . . . . . . . . .27-9
27.6.1.2 Special ATM Handling Fee. . . . . . . . . . . . . . . . . . . . . . .27-9
27.6.2 Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
27.6.2.1 Authorization vs. Clearing Amounts. . . . . . . . . . . .27-10
27.6.2.2 Reclassified Transactions. . . . . . . . . . . . . . . . . . . . . . .27-10
27.6.2.3 Delivering the Transaction to the Issuer. . . . . . .27-10
27.6.3 Exception Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
27.6.3.1 Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . .27-11
27.6.4 V.I.P. Field Edit and DRC Requirements for CPS/ATM
Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-13
27.7 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
14
27.8 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
15
27.8.1 Other Related Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-15
CHAPTER 28 CUSTOM PAYMENT SERVICE (CPS)/POS

28.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
In Brief 28-33
28.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
28.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
28.3.1 BASE I and SMS CPS Processing Overview. . . . . . . . . . . . . . . . . . . . . .28-4
28.3.2 CPS/POS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-5
28.3.3 Qualifying for CPS/POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-5
28.3.4 CPS/POS Programs—All National Markets. . . . . . . . . . . . . . . . . . . . . . .28-5
28.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
6
28.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 ix

X Contents
28.5 How Custom Payment Service (CPS)/POS Works Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28- 28-6
6
28.5.1 Reclassification From CPS/POS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
28.5.2 CPS/POS Program Clearing Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28.5.2.1 Qualification Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28.5.3 Fee Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28.5.4 Ineligible CPS/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.5 Amount Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.5.1 Adjusting Amounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.6 Chargeback Reduction Service (CRS). . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.6.1 CPS Authorization-Related
Contents
Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . . .28-8

28.5.6.2 Chargeback Reduction Service
Life-Cycle Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
28.6 Flow.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
CPS/POS Process Flow 28-99
28.7 Markets.. . . . . . . . . . . . . . . . .28-
Common CPS/POS Data Requirements: All National Markets 28-99
28.7.1 Common CPS/POS Authorization Field Edit Requirements. . . . .28-9
28.7.2 Common CPS/POS Clearing Requirements. . . . . . . . . . . . . . . . . . . . .28-12
28.8 Brazil.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
National Market CPS/POS Program: Brazil 28-13
13
28.8.1 Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-14
28.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
15
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
28-17
17
CHAPTER 29 DEFERRED CLEARING ADVICE FILE (DCAF) SERVICE

29.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
In Brief 29-33
29.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
29.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
29.3.1 DCAF Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
29.3.2 File Delivery Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
29.3.3 File Content and Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-5
29.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
5
29.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-5
29.4.4 Issuer Host Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-7
29.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
29.6 Works.. . . . . . . . . . . . . . . . . . . . .29-
How Deferred Clearing Advice File (DCAF) Service Works 29-88
29.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
Process Flows 29-88
29.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
Message Flows 29-99
29.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
10
29.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
10
CHAPTER 30 DYNAMIC KEY EXCHANGE (DKE) SERVICE

30.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
In Brief 30-33
x Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
30.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-

30.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
30.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1.1 Implementation Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1.2 Key Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1.3 Key Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1.4 Number of Keys Maintained. . . . . . . . . . . . . . . . . . . . . .30-5
30.3.1.5 Support Fallback to Static Key. . . . . . . . . . . . . . . . . . .30-5
30.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
5
30.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6
Contents
30.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
30.5.1 On-Request Key Exchange Messages (V.I.P. Master). . . . . . . . . . .30-6
30.5.2 Automatic Key Exchange Message Flow (V.I.P. Master). . . . . . . . .30-6
30.5.3 Member-Provided Key Exchange Messages (V.I.P. Slave). . . . . .30-7
30.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
How Dynamic Key Exchange (DKE) Service Works 30-77
30.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
Process Flows 30-77
30.7.1 On-Request Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . .30-8
30.7.2 Automatic Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . .30-10
30.7.3 Member-Provided Key Exchange Process Flow (V.I.P. Slave).30-11
30.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
Message Flows 30-12
12
30.8.1 On-Request Key Exchange Message Flow. . . . . . . . . . . . . . . . . . . . . .30-13
30.8.2 Automatic Key Exchange Message Flow. . . . . . . . . . . . . . . . . . . . . . . . .30-15
30.8.3 Member-Provided Key Exchange Process Flow. . . . . . . . . . . . . . . . .30-17
30.8.4 Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-19
30.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
20
30.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
23
CHAPTER 31 INTERNATIONAL AUTOMATED REFERRAL SERVICE (IARS)

31.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
In Brief 31-33
31.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
31.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
31.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
4
31.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-4
31.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
31.6 How International Automated Referral Service (IARS) Works Works.. . . . . . . . . . . . . . . . . . .31- 31-5
5
31.6.1 Currency Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-5
31.6.2 Translation Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
31.6.3 Equipment Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
31.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
Process Flows 31-99
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xi

X Contents
31.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-

Message Flows 31-10
10
31.8.1 IARS Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-11
31.8.2 Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
31.9 Key Fields Glossary
Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
31-12
12
31.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
13
CHAPTER 32 MULTICURRENCY SERVICE

32.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
In Brief 32-33
32.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
Contents
32.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-

32.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
4
32.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-5
32.4.3.1 Decimal Positioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-5
32.4.3.2 Clearing and Settlement Currency Conversion.32-6
32.4.3.3 The Currency Precision Service for Acquirers. .32-6
32.4.3.4 The Currency Precision Service for Issuers. . . . .32-6
32.4.3.5 Optional Issuer Fee (OIF). . . . . . . . . . . . . . . . . . . . . . . .32-7
32.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
32.6 How Multicurrency Service Works
Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
32-77
32.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
Process Flows 32-77
32.7.1 Multicurrency Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-7
32.7.1.1 Processing VisaNet-Acquired
MasterCard Transactions. . . . . . . . . . . . . . . . . . . . . . . . .32-9
32.7.1.2 Processing for Non-Participating Members. . . .32-10
32.7.2 VisaNet BASE II Currency Rate Delivery Service. . . . . . . . . . . . . . .32-10
32.7.3 Currency Conversion Charge Calculation Process. . . . . . . . . . . . . .32-10
32.7.4 How VisaNet Applies Buy and Sell Currency
Conversion Rates to Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-11
32.7.4.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-11
32.7.4.2 Currency Conversion Approach. . . . . . . . . . . . . . . .32-12
32.7.4.3 Using USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . .32-13
32.7.4.4 Using Non-USD-Based Rates. . . . . . . . . . . . . . . . . .32-20
32.7.4.5 Classifying Transactions by Exchange
Direction Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-25
32.7.5 Currency Precision Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-28
32.7.5.1 One Position Decimal Adjustment. . . . . . . . . . . . . .32-29
32.7.5.2 Two Position Decimal Adjustment. . . . . . . . . . . . . .32-29
32.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
Message Flows 32-30
30
32.8.1 Message Flows Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-31
32.8.2 BASE I, POS, and ATM Multicurrency Message Flows. . . . . . . . .32-31
32.8.3 SMS POS Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . .32-33
32.8.4 SMS Visa/Plus ATM Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-40
32.8.5 SMS Interlink Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-48
xii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
32.8.6 Partial Amount Authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-61

32.8.6.1 Processing POS Balance Returns
With Multiple Currencies. . . . . . . . . . . . . . . . . . . . . . . .32-62
32.8.6.2 Acquirer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-62
32.8.6.3 Issuer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-63
32.8.6.4 Message Flow Examples. . . . . . . . . . . . . . . . . . . . . . .32-64
32.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
66
32.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
70
CHAPTER 33 PIN VERIFICATION SERVICE (PVS)
Contents
33.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
In Brief 33-33
33.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
33.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
33.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-5
33.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
6
33.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-6
33.4.3.1 Prerequisites for Using the PVV Method. . . . . . . .33-7
33.4.3.2 Prerequisites for Using the IBM PIN
Offset Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-9
33.4.3.3 Placement of Data on Track 1 of the
magnetic stripe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-11
33.4.3.4 Placement of Data on Track 2 of the
magnetic stripe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-11
33.4.4 MasterCard PIN Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-12
Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
33-12
12
33.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
How PIN Verification Service (PVS) Works 33-12
12
33.6.1 PIN Verification Value (PVV) Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-12
33.6.2 IBM PIN Offset Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
33.6.3 Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
33.6.3.1 Acquirer Zone and Working Key. . . . . . . . . . . . . . . .33-14
33.6.3.2 Issuer Zone and Working Key. . . . . . . . . . . . . . . . . .33-15
33.6.3.3 PIN Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-15
33.6.4 Triple Data Encryption Standard Requirements and Timeline. .33-15
33.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
Process Flows 33-17
17
33.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
Message Flows 33-19
19
33.8.1 MasterCard PIN Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . . .33-20
33.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
20
33.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
25
CHAPTER 34 POS CHECK SERVICE

34.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
In Brief 34-33
34.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xiii

X Contents
34.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-

34.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
34.3.2 POS Check Service Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
34.4 Participation Requirements
Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34- 34-5
5
34.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
34.4.3.1 Acquirer or Processor Implementation. . . . . . . . . .34-6
34.4.3.2 Merchant Implementation. . . . . . . . . . . . . . . . . . . . . . . .34-7
34.4.3.3 Participating Drawee Financial
Contents
Institution Implementation. . . . . . . . . . . . . . . . . . . . . . . .34-7

34.4.3.4 Delivery Methods for POS Check
Service Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-8
34.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
34.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
How POS Check Service Works 34-99
34.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
Process Flows 34-99
34.7.1 Authorization Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-10
34.7.2 Settlement Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-11
34.7.2.1 Settlement Through VisaNet. . . . . . . . . . . . . . . . . . . .34-11
34.7.2.2 Settlement Through the ACH. . . . . . . . . . . . . . . . . . .34-12
34.7.3 ABA Account Number Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-13
34.7.4 MICR Line Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-13
34.7.5 Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-14
34.7.6 POS Check Exception Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-14
34.7.7 Visa Resolve Online (VROL) Processing of POS
Check Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-15
34.8 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
15
34.9 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
19
CHAPTER 35 POSITIVE AUTHORIZATION CAPACITY MANAGEMENT (PACM) SERVICE

35.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
In Brief 35-33
35.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
35.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
35.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
4
35.4.1 Determining Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
35.4.1.1 Advice Message Management. . . . . . . . . . . . . . . . . . .35-5
35.4.2 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-5
35.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
35.6 Works.. . . 35-
How Positive Authorization Capacity Management (PACM) Service Works 35-55
35.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
Process Flows 35-66
35.7.1 Determining Which Transactions To Divert. . . . . . . . . . . . . . . . . . . . . . . .35-6
35.7.1.1 Transactions Always Routed To STIP. . . . . . . . . . .35-6
35.7.1.2 Transactions Eligible for STIP Diversion. . . . . . . .35-6
xiv Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
35.7.1.3 Transactions Not Eligible for STIP Diversion. . .35-7

35.7.2 Calculating a Diversion Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
35.7.3 BASE I and SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-8
35.7.3.1 BASE I Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . .35-8
35.7.3.2 SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
35.7.3.3 Stand-In Processing of
PACM-Diverted Transactions. . . . . . . . . . . . . . . . . . .35-10
35.8 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
11
35.9 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
11
Contents
CHAPTER 36 POSITIVE CARDHOLDER AUTHORIZATION SERVICE (PCAS)
36.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
In Brief 36-33
36.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
36.2.1 Key Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-3
36.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
36.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
4
36.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-4
36.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
36.6 How Positive Cardholder Authorization Service (PCAS) Works Works.. . . . . . . . . . . . . . . . .36- 36-4
4
36.6.1 Merchant Category Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
36.6.2 Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
36.6.3 Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
36.6.3.1 Merchant Category Group Activity Limits. . . . . . .36-7
36.6.3.2 Total Purchase and Total Cash Activity Limits. .36-7
36.6.3.3 Issuer-Available- and
Issuer-Unavailable-Activity Limits. . . . . . . . . . . . . . . .36-7
36.6.3.4 Count, Amount, and 4-Day Multiplier
Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-8
36.6.4 Mandated Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-8
36.6.4.1 Mandatory Minimum (T&E) Issuer Limits. . . . . . . .36-8
36.6.4.2 Mandatory Minimum Non-T&E Issuer Limits. . . .36-9
36.6.4.3 Mandatory Minimum Activity Limits. . . . . . . . . . . . . .36-9
36.6.4.4 Applying Appropriate Issuer and
Activity Limits: Issuer-Specified or
Visa-Mandated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-9
36.6.4.5 Overriding Mandatory Minimum Limits. . . . . . . .36-10
36.6.4.6 Mandatory Zero MOTO Issuer Limit. . . . . . . . . . . .36-10
36.6.5 Advice Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-10
36.6.6 Activity Checking and Accumulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-10
36.6.7 Cardholder Risk Levels and Individual Limits. . . . . . . . . . . . . . . . . . . .36-11
36.6.7.1 Defining Risk-Level Limits. . . . . . . . . . . . . . . . . . . . . .36-12
36.6.7.2 Multiple Limit Selection Rules. . . . . . . . . . . . . . . . . .36-12
36.6.8 Random Selection Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-13
36.6.9 BIN Blocking and Country Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . .36-13
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xv

X Contents
36.6.9.1 Risky Countries and

Country-to-Country Embargoes. . . . . . . . . . . . . . . .36-13
36.7 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
14
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
36-14
14
CHAPTER 37 PREAUTHORIZED PAYMENT CANCELLATION SERVICE (PPCS)

37.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
In Brief 37-33
37.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
37.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
Contents
37.4 Participation Requirements

Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37- 37-4
4
37.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-4
37.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
37.6 How Preauthorized Payment Cancellation Service (PPCS) Works Works.. . . . . . . . . . . . .37- 37-5
5
37.6.1 Updating the Cardholder Database Portfolio File (PF). . . . . . . . . . . .37-5
37.6.1.1 File Edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-6
37.7 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
37.8 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
CHAPTER 38 STATUS CHECK SERVICE

38.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
In Brief 38-33
38.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
38.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
38.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
4
38.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-4
Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
38-44
38.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
How Status Check Service Works 38-44
38.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
Process Flows 38-55
38.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
Message Flows 38-66
38.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
38.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
CHAPTER 39 VISA CASHBACK PROCESSING: VISANET CASHBACK SERVICE

39.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
In Brief 39-33
39.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
39.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
39.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
5
39.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-5
39.4.4 Issuer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-6
xvi Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Contents
39.4.4.1 Magnetic Stripe Considerations. . . . . . . . . . . . . . . . . .39-6

39.4.4.2 Chip Card Considerations. . . . . . . . . . . . . . . . . . . . . . . .39-6
39.4.5 Acquirer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . .39-7
39.4.5.1 Chip Transaction Processing. . . . . . . . . . . . . . . . . . . . .39-7
39.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
39.6 How VisaNet Cashback Service WorksWorks.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39- 39-8
8
39.6.1 Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-8
39.6.2 PIN Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-9
39.6.3 VSDC Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-9
39.6.4 Participating Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-9
Contents
39.6.5 Other Cashback Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
39.6.5.1 United Kingdom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
39.6.5.2 United States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
39.7 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
10
39.8 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
11
Index
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xvii

THIS PAGE INTENTIONALLY LEFT BLANK.
Contents
xviii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Figures
1 Sample Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

17-1 Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6
17-2 Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
18-1 Record Type Structure by Merchant (Card Acceptor). . . . . . . . . . . . . . . . . . . . . . . . . . . .18-8
18-2 Record Type Structure by Merchant Terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-9
18-3 How V.I.P. Inserts an MCF Value in a Visa Card Type Request. . . . . . . . . . . . . . .18-14
Figures
18-4 How V.I.P. Inserts an MCF Value in a Universal Card Type Request. . . . . . . . .18-14
18-5 How V.I.P. Substitutes an MCF Value in a Visa Card Type Request. . . . . . . . . .18-15
18-6 MCFS Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-22
18-7 MCFS Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-25
19-1 Account Verification Service Process and Message Flow (Issuer Available) . . 19-7
19-2 Account Verification Service Process and Message Flow (Issuer
Unavailable). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8
20-1 AVS Process Flow When the Issuer Must Perform Address
Verification and Is Available. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-10
20-2 AVS Process Flow When the Issuer Must Perform Address
Verification and Is Unavailable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-11
20-3 AVS Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-24
21-1 BASE I Advice Retrieval Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9
21-2 BASE I Advice Retrieval Service Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-11
22-1 SMS Advice Retrieval Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-11
22-2 SMS Advice Retrieval Service Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-13
23-1 ATM Format Conversion Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-8
23-2 ATM Format Conversion Service Authorization Request Message Flow. . . . . . .23-9
23-3 ATM Format Conversion Service Reversal (Misdispense) Request
Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-10
23-4 ATM Format Conversion Service Reversal Request Message Flow. . . . . . . . . .23-11
25-1 CVV2 Process Flow and Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-20
29-1 DCAF Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-9
29-2 DCAF Service Deferred Clearing Advice Message Flow. . . . . . . . . . . . . . . . . . . . . . .29-10
30-1 DKE Process Flow—On-Request Key Exchange Request (V.I.P. Master). . . . .30-8
30-2 DKE Process Flow—Automatic Key Exchange Request (V.I.P. Master). . . . . .30-10
30-3 DKE Process Flow—Automatic Key Exchange Request (V.I.P. Slave). . . . . . .30-11
30-4 DKE Message Flow—On-Request Key Exchange Request (V.I.P. Master). .30-14
30-5 DKE Message Flow—Automatic Key Exchange Request (V.I.P. Master). . . .30-16
30-6 DKE Message Flow—Automatic Key Exchange Request (V.I.P. Slave). . . . . .30-18
31-1 Automated Language Matching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
31-2 IARS Referral Center Translation Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
31-3 Acquirer With Tone-Generating Telephone System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
31-4 Acquirer With Rotary or Pulse-Generating Telephone. . . . . . . . . . . . . . . . . . . . . . . . . . .31-8
31-5 IARS Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
32-1 Multicurrency Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-9
32-2 Purchase Transaction—USD-Based Currency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-15
32-3 Purchase Transaction—Non-USD-Based Currency. . . . . . . . . . . . . . . . . . . . . . . . . . . .32-22
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xix

X Figures
32-4 Example of One-Decimal Position Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-29

32-5 Example of Two-Decimal Position Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-30
32-6 Message Flow—BASE I POS ATM Transactions, No Cashback. . . . . . . . . . . . . .32-32
32-7 Message Flow—BASE I POS ATM Transactions, Cashback, and
ATM Partial Dispenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-33
32-8 Message Flow—SMS POS or Visa Electron Authorization. . . . . . . . . . . . . . . . . . . . .32-34
32-9 Message Flow—SMS POS or Visa Electron Purchase. . . . . . . . . . . . . . . . . . . . . . . . .32-35
32-10 Message Flow—SMS POS Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-36
32-11 Message Flow—SMS POS Representment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-37
32-12 Message Flow—SMS POS Reversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-38
Figures
32-13 Message Flow—SMS POS Chargeback and Chargeback Reversal. . . . . . . . . .32-39

32-14 Message Flow—SMS POS Merchandise Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-40
32-15 Message Flow—SMS Visa/Plus ATM Cash Disbursement With
Balance Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-42
32-16 Message Flow—SMS Visa/Plus Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-43
32-17 Message Flow—SMS Visa/Plus Representment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-44
32-18 Message Flow—SMS Visa/Plus Balance Inquiry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-45
32-19 Message Flow—SMS Visa/Plus Reversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-47
32-20 Message Flow—SMS Visa/Plus Chargeback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-48
32-21 Message Flow—Interlink Preauthorization—Full Approval. . . . . . . . . . . . . . . . . . . . .32-50
32-22 Message Flow—Interlink Preauthorization—Partial Approval. . . . . . . . . . . . . . . . . .32-51
32-23 Message Flow—Interlink Preauthorization Completion. . . . . . . . . . . . . . . . . . . . . . . . .32-52
32-24 Message Flow—Interlink Purchase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-54
32-25 Message Flow—Interlink Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-55
32-26 Message Flow—Interlink Representment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-56
32-27 Message Flow—Interlink Balance Inquiry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-57
32-28 Message Flow—Interlink Reversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-58
32-29 Message Flow—Interlink Chargeback—Full Amount. . . . . . . . . . . . . . . . . . . . . . . . . . .32-59
32-30 Message Flow—Interlink Chargeback—Partial Amount. . . . . . . . . . . . . . . . . . . . . . . .32-60
32-31 Message Flow—Interlink Merchandise Credit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-61
32-32 Acquirer and Non-Multicurrency Issuer With the Same Currency. . . . . . . . . . . . .32-65
32-33 Acquirer and Multicurrency Issuer With Different Currencies. . . . . . . . . . . . . . . . . .32-65
32-34 Acquirer and Non-Multicurrency Issuer With Different Currencies. . . . . . . . . . . . .32-66
33-1 Overview of PVV Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-9
33-2 Example of IBM PIN Offset Method of PIN Verification. . . . . . . . . . . . . . . . . . . . . . . . .33-11
33-3 Encryption Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
33-4 Zone Encryption Key Pairs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
33-5 PVS Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-17
33-6 PVS Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-19
34-1 POS Check Authorization Processing Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-10
34-2 POS Check Service VisaNet Settlement Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-11
34-3 POS Check Service ACH Settlement Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-12
34-4 Layout of Check MICR Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-14
35-1 PACM Diversion Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-6
35-2 PACM Calculation of Diversion Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-8
38-1 Status Check Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
38-2 Status Check Service Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-7
xx Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Tables
1 Document Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
2 Descriptions of V.I.P. System Manuals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
16-1 Purchase and Cash Activity Merchant Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
16-2 Exception File Update Processing Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
16-3 V.I.P. Format Exception File Update Processing Actions . . . . . . . . . . . . . . . . . . . . . .16-11
17-1 Auto-CDB Pick-Up Action Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
Tables
18-1 Effective Date for File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18-2 MCF Record Types and Data by Card Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-9
18-3 Key MCF Fields by Record Type for 0100 and 0400 Messages. . . . . . . . . . . . . . .18-12
18-4 MCFS Augmentation Logic by Record Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-12
18-5 Merchant Central File Record Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-16
18-6 Field 127M.4 Universal Format Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .18-19
18-7 Information Supplied by MCFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-22
18-8 Field 91 File Update Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-28
20-1 Key AVS Data Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7
20-2 Fixed Format Address Data Compression by Leading Numerics and
by First Five Numerics Algorithms for Non-U.K. Participants. . . . . . . . . . . . . . . . . .20-17
20-3 Fixed Format Address and Postal or ZIP Code Compression by First
Five Numerics for U.K. Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-17
20-4 AVS Format Matching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
20-5 Field 44.2 Address Verification Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-20
20-6 AVS Result Code Conversion Based on Jurisdiction and
Representment Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-21
20-7 AVS Result Code Conversion Based on Acquirer Participation . . . . . . . . . . . . . . .20-22
20-8 Sample Address Verification Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-22
20-9 Abbreviations Used in Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-25
20-10 Full and Compressed Data Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-36
21-1 BASE I Field 70 Advice Recovery Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-12
22-1 SMS Field 70 Advice Recovery Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-14
24-1 Issuer Participation Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-9
24-2 Issuer Testing Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-11
24-3 V.I.P. Monitoring of Issuer CVV Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-13
24-4 V.I.P. Monitoring of Acquirer CVV Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-13
24-5 Set A and Set B Parameter Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-15
24-6 Issuer Implementation Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-15
24-7 Acquirer Implementation Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-17
24-8 CVV or iCVV Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-23
24-9 CVV Error Codes for Emergency Replacement Cards. . . . . . . . . . . . . . . . . . . . . . . . .24-24
24-10 dCVV Verification Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-26
24-11 dCVV Verification Service Options for Stand-In Processing. . . . . . . . . . . . . . . . . . .24-27
25-1 CVV2 Processing Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-14
25-2 CVV2 Error Codes for Emergency Replacement Cards. . . . . . . . . . . . . . . . . . . . . . . .25-16
25-3 CVV2 Key Data Requirements and Fee Program Edit Criteria. . . . . . . . . . . . . . . .25-18
25-4 Subfield 126.10 Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-24
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xxi

X Tables
26-1 Required Verified by Visa Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6

26-2 CAVV Verification Service Processing Under Normal and STIP
Conditions for Full Authentication Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-9
26-3 CAVV Verification Service Processing and STIP Options Summary
for Attempt Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-12
26-4 Chargeback Reason Codes the CAVV Verification Service Does Not Allow . 26-15
27-1 CPS/ATM Fields Protected by CPS Validation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-8
27-2 Authorization Characteristics Indicator (ACI) Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
27-3 CPS/ATM Key Data Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-11
27-4 CPS/ATM Field Edit Requirements and DRC Conditions. . . . . . . . . . . . . . . . . . . . . .27-13
Tables
28-1 CPS/POS Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-5

28-2 CPS/POS Clearing Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28-3 Amount Tolerances—Brazil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28-4 CPS/POS Field Edit Requirements and DRC Conditions. . . . . . . . . . . . . . . . . . . . . .28-10
28-5 Valid Data Element Value Combinations for CPS/POS National Markets. . . .28-12
28-6 Validation Code Protected Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-13
28-7 CPS/Retail Key Data Requirements for Brazil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-15
28-8 Authorization Characteristics Indicator (ACI) Values. . . . . . . . . . . . . . . . . . . . . . . . . . .28-16
29-1 DCAF Service Implementation Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-6
30-1 DKE Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-19
31-1 IARS Referral Center Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
32-1 New Rate-Related Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-11
32-2 Map of Section Terminology to V.I.P. and BASE II Fields in Purchase
Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-11
32-3 Processing Rules for USD-Based Rate Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
32-4 Example of USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-15
32-5 Currency Entry for USD-Based Rate in TC 56 Record for Scenario 1. . . . . . . .32-16
32-6 Populating Amount Fields in V.I.P. and BASE II Transactions for
Scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-17
Scenario 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-18
Scenario 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-20
32-11 Processing Rules for USD-Based Rate Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . .32-21
32-12 Example of Non-USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-22
32-13 Currency Entry for Non-USD-Based Rate in TC 56 Record for
Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-23
Scenario 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-24
32-15 Currency Entry for Non-USD-Based Rate in TC 56 Record for
Scenario 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-25
Scenario 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-25
32-17 Buy–Sell Currency Conversion Direction by Transaction Type . . . . . . . . . . . . . . . .32-26
32-18 Sell–Buy Currency Conversion Direction by Transaction Type . . . . . . . . . . . . . . . .32-28
32-19 Field 54 Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-68
xxii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Tables
33-1 Triple Data Encryption Migration Dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-15

33-2 Field 53 Security Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-24
34-1 POS Check Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
34-2 POS Check Service Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
34-3 POS Check Field 125 Format Requirements—Unformatted MICR. . . . . . . . . . . .34-17
34-4 POS Check Field 125 Format Requirements—Parsed MICR. . . . . . . . . . . . . . . . . .34-18
35-1 BASE I PACM Diversion Tables by Visa Region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
35-2 SMS PACM Diversion Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
36-1 Choosing Issuer-Specified or Visa-Mandated Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-9
37-1 Portfolio File Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-6
Tables
37-2 PF Data Elements for Field 127. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-8
39-1 Cashback Services Currently Supported by VisaNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-5
39-2 Cashback Programs in the U.K. and the U.S.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xxiii

Tables
xxiv Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X About This Manual
V.I.P. System Services, Volume 1 and Volume 2, provides updated, comprehensive

information about the various services available from the VisaNet Integrated Payment
(V.I.P.) System, including processing specification details. Message and process flow
diagrams help illustrate the ways the services work. Specific examples, where appropriate,
address actual situations, questions, and problems.
Each service chapter also lists available documents that contain additional information,
technical specifications, service implementation specifics, and service activation
information.
AUDIENCE
This manual is intended for Visa members' technical and non-technical staff and managers,
as well as for Visa Member Services and customer support personnel who answer
members' system and production questions. Non-technical staff will find this information
useful in making decisions about subscribing to services and selecting service options.
About This Manual

Readers who do not have a working knowledge of VisaNet and of the V.I.P. System
should refer to Chapter 1, Introduction to System Services, and to Chapter 2, System
Fundamentals, before reading the service descriptions.
STRUCTURE OF THIS MANUAL
The two-volume V.I.P. System Services manual has seven parts, based on service
functions.
Volume 1
2)—Part 1 provides an overview of V.I.P. services

Part 1: System Basics (Chapters 1 and 2)—
and defines the scope of the manual. It also contains a basic overview of the V.I.P. System,
including a description of VisaNet components, and V.I.P. transaction processing.
10)—Part 2 describes routing messages

Part 2: Routing Services (Chapters 3 through 10)—
to networks and to systems outside of VisaNet and additional, optional services for routing
messages within VisaNet.
12)—Part 3 contains descriptions

Part 3: Risk Management Services (Chapters 11 and 12)—
of risk management services available through the V.I.P. System.
Part 4: Visa Secure Electronic Commerce (VSEC) Services (Chapter 13)— 13)—Part 4 contains
a description of the VSEC service available through the V.I.P. System that provides security
for electronic payment transactions sent over the Internet.
15)—Part 5 contains descriptions of the

Part 5: Chip Card Services (Chapters 14 and 15)—
services available through the V.I.P. System that use chip cards and terminals capable
of reading chip cards in addition to magnetic stripe cards.
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 1

X Document Conventions
Volume 2
Part 6: Authorization Database Files and Services (Chapters 16 through 18)—

18)—Part 6
contains an overview of the Cardholder Database and a detailed service description of the
Automatic Cardholder Database Update (Auto-CDB) Service, which members can use to
update the Cardholder Database. Part 6 also describes the Merchant Central File and the
Merchant Central File Service (MCFS) in detail.
39)—Part 7 contains descriptions

Part 7: Authorization Services (Chapters 19 through 39)—
of services that perform functions related to message authorization.
DOCUMENT CONVENTIONS
Table 1 identifies the document conventions used in this manual.
Table 1 Document Conventions
Document Convention Purpose in This Manual

boldface Extra emphasis (stronger than italics); field values and codes.
Identifies an example of what the accompanying text describes or
EXAMPLE
explains.
About This Manual
IMPORTANT Highlights important information in the text.

italics Document titles; emphasis; variables; terms or acronyms being defined.
Section names referenced in a chapter; first instance of a word used in
“text in quote marks”
an unconventional or technical context.
text in Courier New
URLs and email addresses.
font
NOTE Provides more information about the preceding topic.

n/a Not applicable.
Systems or procedures that are not directly involved in the process
shaded illustrations
being illustrated in the graphic.
white boxes in flow
White boxes represent request messages.
diagrams
shaded boxes in flow
Shaded boxes represent response messages.
diagrams
dotted line boxes in flow
Boxes with dotted lines illustrate advice messages.
diagrams
2 Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X System Documentation Descriptions
SYSTEM DOCUMENTATION DESCRIPTIONS
This two-volume book is part of the set of V.I.P. System documents. V.I.P. System Services,
Volume 1 and Volume 2, is designed to be a companion to the V.I.P. System Overview,
which has also been updated. The V.I.P. System Overview and V.I.P. System Services,
Volume 1 and Volume 2, contain new and updated information, and incorporate all system
changes and revisions described in the April 2013 VisaNet Business Enhancements Global
Technical Letters and Implementation Guides published after October 2012 through
April 2013. (See “Sources of System Information” in this chapter for a complete list of
sources used to prepare this V.I.P. System Services manual.)
The first three manuals in this series: V.I.P. System Overview, V.I.P. System Services,
Volume 1 and Volume 2, and V.I.P. System Reports, apply both to BASE I System
processing and to Single Message System (SMS) processing.
The next two manuals are specific to the BASE I System: V.I.P. System BASE I Processing
Specifications and V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2.
For the Single Message System (SMS), the Visa U.S.A. (U.S.) region processing
specifications for ATM, for Interlink, and for POS are consolidated in one manual,
V.I.P. System SMS Processing Specifications (U.S.). For the international audience,
About This Manual

there are separate processing specifications manuals for ATM and for POS.
Table 2 provides brief descriptions of the V.I.P. System manuals.
Table 2 Descriptions of V.I.P. System Manuals
General Information
V.I.P. System Overview
Provides basic descriptions of the VisaNet network and its components, access points, processing
concepts, requirements, and options. Contains descriptions of the V.I.P. System, the BASE I
System, and the Single Message System (SMS), VisaNet Access Points (VAPs), issuer and
acquirer responsibilities, and Visa Interchange Center (VIC) operations. Also provides a brief
introduction to V.I.P. services.
Doc ID 0851-22
V.I.P. System Reports
Provides sample reports for BASE I and SMS processing and for V.I.P. System services.
Doc ID 0852-22

Table 2 Descriptions of V.I.P. System Manuals (continued)

V.I.P. System Services, Volume 1
Provides complete information about V.I.P. System services available to BASE I users and to SMS
users. Service descriptions include basic information, processing requirements, options, features,
key message fields, and message flows.
Volume 1 contains the following parts:
Part 1: V.I.P. Basics

Part 2: Routing Services
Part 3: Risk Management Services
Part 4: Visa Secure Electronic Commerce (VSEC) Services
Part 5: Chip Card Services
Doc ID 0853A-22
Provides complete information about V.I.P. System services available to BASE I users and to SMS
users. Service descriptions include basic information, processing requirements, options, features,
key message fields, and message flows.
Volume 2 contains the following parts:

About This Manual
Part 6: Authorization Database Files and Services

Part 7: Authorization Services
Doc ID 0853B-22


BASE I
V.I.P. System BASE I Processing Specifications
Describes V.I.P. transaction processing in the BASE I System environment, including message
types, processing considerations, related services, and VisaNet Access Points (VAPs).
Doc ID 0847-22
V.I.P. System BASE I Technical Specifications, Volume 1
Documents technical specifications of V.I.P. transaction processing in the BASE I System

environment. This companion volume to V.I.P. System BASE I Processing Specifications describes
the fields for BASE I.
Doc ID 0844A-23
V.I.P. System BASE I Technical Specifications, Volume 2
Documents technical specifications of V.I.P. transaction processing in the BASE I System

environment. This companion volume to V.I.P. System BASE I Processing Specifications describes
the message formats and the file specifications for BASE I.
Doc ID 0844B-23
About This Manual

Interlink
V.I.P. System SMS Processing Specifications (U.S.)
Contains information about the Single Message System, including message types, processing
considerations, VisaNet Access Points (VAPs), and related services for Interlink, Visa and Plus
ATM, Visa POS, and Visa Electron.
Doc ID 0857-22
V.I.P. System SMS Interlink Technical Specifications
Companion volume to V.I.P. System SMS Processing Specifications (U.S.). Describes message
formats, field descriptions, and file specifications for Interlink.
Doc ID 0866-21
SMS ATM
considerations, VisaNet Access Points (VAPs), and related services for Visa and Plus ATM,
Interlink, Visa POS, and Visa Electron for members in the Visa U.S.A. (U.S.) region.
Doc ID 0857-22
V.I.P. System International SMS ATM Processing Specifications
Contains information about Single Message System ATM processing, including message types,
processing considerations, VisaNet Access Points (VAPs), and related services for members
outside of the U.S. region.
Doc ID 0839-22

X Sources of System Information

V.I.P. System SMS ATM Technical Specifications, Volume 1
Companion volume to V.I.P. System SMS Processing Specifications (U.S.) and to V.I.P. System
International SMS ATM Processing Specifications. Contains information about field descriptions
for ATM.
Doc ID 0868A-21
V.I.P. System SMS ATM Technical Specifications, Volume 2
International SMS ATM Processing Specifications. Contains information about message formats
and file specifications for ATM.
Doc ID 0868B-21
SMS POS
considerations, VisaNet Access Points (VAPs) and related services for Visa POS, Visa Electron,
Visa and Plus ATM, and Interlink for members in the U.S. region.
About This Manual
Doc ID 0857-22
V.I.P. System International SMS POS (Visa & Visa Electron) Processing Specifications
Contains information about Single Message System POS processing, including message
types, processing considerations, VisaNet Access Points (VAPs), related services, and reports
for members outside of the U.S. region.
Doc ID 0835-22
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1
International SMS POS (Visa & Visa Electron) Processing Specifications. Describes the fields
for Visa POS and for Visa Electron.
Doc ID 0869A-21
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 2
International SMS POS (Visa & Visa Electron) Processing Specifications. Describes message
formats and file specifications for Visa POS and for Visa Electron.
Doc ID 0869B-21
SOURCES OF SYSTEM INFORMATION
This section lists the primary sources for the information contained in V.I.P. System
Services. The information from these sources has been analyzed, rewritten,
and reorganized, when necessary. Technical staff and subject matter experts reviewed and
verified these updates. In addition, this revised manual incorporates, where appropriate,
all of the comments and change requests received from members and from Visa staff.

X How To Use This Book
Existing V.I.P. System Manuals
For a list of the existing V.I.P. manuals, refer to Table 2.
VisaNet Business Enhancements Global Technical Letters and Implementation Guides
The V.I.P. System Services, Volume 1 and Volume 2, includes information from the
following technical letter and implementation guide: the April 2013 VisaNet Business
Enhancements Global Technical Letter and Implementation Guide, Version 3.0, effective
14 March 2013.
Other Documents
Other documents used as sources for V.I.P. System Services include the Visa International
Operating Regulations (and all revisions), RTN publications, general design documents,
detailed design documents, service advisories, and project presentations.
HOW TO USE THIS BOOK

This manual has seven parts, based on service functions, to help readers quickly find
information about available services that address specific needs.
About This Manual

Chapter Structure
Service description chapters appear in the part (V.I.P. Basics or Routing Services,
for instance) appropriate to their functions, as described in “Structure of This Manual” in this
chapter. With the exception of introduction and overview chapters, which appear first,
service chapters within each part are listed alphabetically.
Each service description chapter follows a standard structure, using the same section
headings to make finding information as easy as possible. A service description chapter
begins with a brief explanation of the service and then presents the following sections
of information.
Eligible Participants
This section contains text and icons (simple graphics) that identify which entities can use
the service. Icons indicate the following:
—The regions in which the service is available

There are icons for each of the five Visa regions and for Visa Europe. Each icon indicates
that the service is available to members in that region or in Visa Europe. The “ALL” icon
indicates that the service is available to members in all Visa regions and in Visa Europe.
Represents all Visa regions and Visa Europe

Represents the Asia-Pacific (AP) region
Represents the Visa Canada (CAN) region

NOTE
CA, but V.I.P. documentation refers to the
The V.I.P. System internally refers to the Visa Canada region as CA
CAN.
Visa Canada region as CAN
About This Manual
Represents the Central and Eastern Europe, Middle East, and Africa (CEMEA) region
Represents Visa Europe (VE)
Represents the Latin America and Caribbean (LAC) region

Represents the Visa U.S.A. (U.S.) region
—The system on which the service is available (BASE I, SMS, or both)
BASE I
SMS
BASE I only
BASE I
SMS
About This Manual

SMS only
BASE I
SMS
BASE I and SMS

—The type of member for which the service is available (issuer or acquirer)
Issuer
Acquirer
Service Summary
This section contains a complete description of the service and available options.
Participation Requirements
This section describes all prerequisites and requirements for participating in the service.
About This Manual
It provides specific information about:

• Testing.
• Service monitoring.
• Planning and implementation.
Related Messages
This section lists the message types that the service directly uses or that contain key
service fields.
How the [Service Name] Works
This section provides processing details specific to each service, including:

• Process flows, which provide a visual representation of the processing.
• Message flows, which illustrate the flows of messages and significant field information
from the message initiator through VisaNet to the message recipient.
In some cases, the process flow and the message flow are combined.
Key Fields Glossary
This section lists the fields that directly influence the processing of the service and gives a
short description of the fields and of their contents.
For More Information
This section lists other publications that provide additional information about the service.

Interpreting Flow Diagrams
The process and message flow diagrams in each service chapter illustrate the path that
messages take from the originator of the message to the message recipient. Figure 1
shows a sample flow.
• Icons at the top of the illustration show the destinations of the message (acquirer, V.I.P.,
issuer, merchant, network, vendor).
• Arrows indicate the entity that creates the message and the entity that receives it
(acquirer, V.I.P., issuer, merchant, network, vendor).
Boxes list key message fields and specific field values contained in the messages,
as appropriate.
• White boxes represent request messages. Shaded boxes represent response messages.
• Boxes with dotted lines illustrate advice messages. The arrows between the boxes
indicate the creator and the path of the advice messages.
NOTE
V.I.P. typically creates advice messages for issuers to let them know that it performed processing on
their behalf.
About This Manual

In Figure 1, the acquirer creates the request message and sends it to the V.I.P. System
within VisaNet. V.I.P. processes the message and, as indicated by the next arrow,
sends the message to the issuer for processing.
The issuer creates a response message and sends it to V.I.P. for processing. V.I.P.
performs its functions on the response message and sends it to the acquirer.
For the purposes of illustrating an advice flow, Figure 1 shows that V.I.P. creates an
advice message for the issuer to recover. When the issuer receives the advice, the issuer
responds with an advice response message.

X Obtaining Report Samples
NOTE
Responding to some advices is optional. For other advices, a response is mandatory.
Figure 1 Sample Message Flow
Acquirer V.I.P. Issuer
0100 Request 0100 Request 0100 Request
0110 Response 0110 Response 0110 Response

About This Manual
0x2x Advice 0x2x Advice
0x3x Advice Response 0x3x Advice Response
NOTE
In actual service chapters, each message flow indicates key fields, as appropriate.
OBTAINING REPORT SAMPLES
Visa offers several reports to members. Many of these reports clarify and track service
processing. The following manuals provide report samples:
• V.I.P. System Reports
• VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports
Members can contact their Visa representatives to discuss reporting options or to obtain
additional report samples.

X For More Information
FOR MORE INFORMATION
Visa provides documentation to support Visa products and services. For many of the
services described in this manual, Visa has developed implementation guides that contain
region-specific details about signing up for a service, selecting options, and installing,
testing, and operating the service. Members can ask their Visa representatives for regional
guides.
The V.I.P. documentation suite does not contain details about the BASE II System.
For information about this system, members can contact their Visa representatives.
Related Publications
The publications listed in this section provide information about Visa systems, regulations,
and additional services not covered in this manual. If you have technical questions or
questions regarding a Visa service or capability, contact your Visa representative.
Use the following information to obtain any of the listed publications, to be added to or
removed from distribution lists, or to inquire about other publications.
• U.S. members and third-party processors can contact Publication Orders by sending
an email to publicationorders@visa.com.
About This Manual

• Members and third-party processors in all other Visa regions or in Miami can contact
their Visa representatives.
If you have comments or questions about this document, send them to TCS@visa.com.
Operating Regulations
The operating regulations are contained in the Visa International Operating Regulations
(VIOR).
Qualifying merchants and third-party agents can also request a copy of the Interchange
Qualification Guide.
PIN Management Requirements
For complete, current information about PIN management requirements, refer to:
Payment Card Industry PIN Security Requirements Manual—This manual contains

requirements for the secure management, processing, and transmission of personal
identification number (PIN) data during online and offline payment card transaction
processing at ATMs and at attended and unattended terminals.
PIN-Entry Device Security Requirements—The following manuals contain physical and

logical security device requirements and management procedures for online and offline
PIN-entry devices and the procedures and forms that entities use to measure compliance:
• Payment Card Industry Encrypting PIN PAD (EPP) Security Requirements Manual
• Payment Card Industry POS PIN-Entry Device Security Requirements Manual
POS Check Service
For information about the POS Check Service, refer to:

Visa U.S.A. POS Check Service Operating Regulations
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1 and
Volume 2
VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports
Risk Management Services
For information about risk management services, refer to:
Card Recovery Bulletin Service User's Guide
Fraud Reporting System (FRS) User's Guide
Issuer's Clearinghouse Service User's Guide
Merchant Fraud Performance Program Guide
Risk Management Process Guide

About This Manual
Visa Risk Manager
Security
For complete, current information about data and system security, refer to:
Payment Technology Standards Manual—This manual contains standards for PINs

and for encoding account and cardholder data on Visa payment form factors.
Visa Extended Access Servers (EA Servers)
For information about Visa Extended Access Servers (EA Servers), refer to:
Extended Access Administration and Installation Guide
Visa Extended Access Server Endpoint Guide
Extended Access Management Installation Guide
Extended Access Management Operators Guide
Extended Access Security Administration Guide
Extended Access Server Endpoint Guide
Visa Incentive Network (VIN)
For information about the Visa Incentive Network (VIN), refer to:
Visa Incentive Network Service Description—(This is a high-level overview and is not the
same as the V.I.P. System Services descriptions.)
Visa Incentive Network Member Implementation Guide

Credit Rewards Key Implementation Tasks and Best Practices
Credit Rewards: Visa Incentive Network and Credit Interchange Frequently Asked
Questions
October 2005 VisaNet Business Enhancements Technical Letter, updated version 3.0,
dated September 15, 2005
Visa Traditional Rewards Registration Toolkit
Visa Signature Registration Toolkit
Visa Resolve Online (VROL)
For information about Visa Resolve Online (VROL), refer to:
Visa Resolve Online Administrator's Guide
Visa Resolve Online Bulk Systems Interface Development Guide
Visa Resolve Online Member Implementation Guide
Visa Resolve Online Real-Time Systems Interface Development Guide
About This Manual

Visa Resolve Online Reference Manual
Visa Resolve Online User's Guide
Visa Smart Debit/Smart Credit (VSDC) Service
For information about the VSDC Service, refer to:
JCB, MasterCard, Visa (EMV) Specifications, EMV '96 Version 3.1.1 and EMV 2000
Version 4.0—These documents contain industry standards for chip card and terminal
interaction. They are available at www.emvco.com.
Visa Smart Debit and Visa Smart Credit Service Description—This manual provides a
high-level description of the features and the benefits of a VSDC program.
Visa Smart Debit and Credit Planning Guide—This manual helps members plan their VSDC
program and migration strategy to position themselves competitively for the future.
Visa Smart Debit and Credit Member Implementation Guide for Acquirers—This manual
provides guidelines for acquirers involved in the implementation of new VSDC programs.
Visa Smart Debit and Credit Member Implementation Guide for Issuers—This manual
provides guidelines for issuers involved in the implementation of new VSDC programs.
Visa Smart Debit/Visa Smart Credit System Technical Manual—This manual provides
information for members and for Visa staff responsible for the implementation and the
operation of a VSDC program.
Visa Integrated Circuit Card Specifications (VIS)—This 3-volume manual contains the
technical specifications for the VSDC card application, describing both the functionality and
the flow of a VSDC transaction.

Miscellaneous Systems and Services
For more information about miscellaneous systems and services relevant to V.I.P., refer to:
Credit Gateway Service Cross-Reference Guide—This document includes field-by-field

data transfer descriptions between V.I.P.-format dual-message transactions, and American
Express- and MasterCard-format transactions.
Visa Global ATM Planning Guide—This manual contains information about the Visa and
Plus International ATM Program. It includes an overview of the program, its business
requirements, optional services, risk management, processing options, testing procedures,
and back-office management.
Visa Information System User's Guide
Visa Test System—V.I.P. User's Guide
VisaNet Settlement Service (VSS) User's Guide, Volume 1, Specifications
VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports

About This Manual

Part 6 Authorization Database Files and Services
Part 6, Authorization Database Files and Services, includes information about the
Cardholder Database (Chapter 16) and the Merchant Central File (Chapter 18). These two
main databases within the V.I.P. System contain cardholder and merchant data.
Part 6 contains the following chapters:
Overview—This chapter describes the Cardholder

Chapter 16, Cardholder Database Overview—
Database, the files and fields it contains, and the services that access the database. Part 7,
Authorization Services, describes these services.
Chapter 17, Automatic Cardholder Database Update (Auto-CDB) Service—Service—This chapter

describes the optional service that allows V.I.P. to update the database automatically when
participating issuers return pick-up response codes in authorization response messages.
(MCFS)—This chapter provides an overview

Chapter 18, Merchant Central File Service (MCFS)—
of the Merchant Central File, which contains merchant data. The chapter describes the
Merchant Central File Service (MCFS), which uses information from this database to check
for complaints against merchants.


Chapter 16 Cardholder Database Overview
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
IN BRIEF 16-33
FILES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
DATABASE FILES 16-33
FORMAT.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
FILE RECORD FORMAT 16-44
Cardholder Database Overview

How V.I.P. Determines Effective and Update Date and Time. . . . . . . . . . . . . . . . . . . . . . . . . .16-4
DESCRIPTIONS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
FILE DESCRIPTIONS 16-44
Related Services Listings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
ACTIVITY FILE 16-55
Merchant Group Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
PIN-Entry Attempt Activity Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
ADDRESS VERIFICATION FILE 16-77
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
ADVICE FILE 16-77
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
CARD-LEVEL PRODUCT ID FILE 16-88
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
EXCEPTION FILE 16-88
Visa International Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
Online Exception File Editing Summary (0302 Messages). . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10
Exception File Purge Date Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
Global Customer Assistance Services (GCAS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
PIN VERIFICATION FILE 16-12
12
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
PORTFOLIO FILE 16-13
13
FILE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
RISK-LEVEL FILE 16-14
14
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-
FOR MORE INFORMATION 16-15
15
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 16-1

16-2 Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

Chapter 16 Cardholder Database Overview
16.1 IN BRIEF
The Cardholder Database (CDB) resides at each VisaNet Interchange Center (VIC).
This database contains cardholder information used by the stand-in processor (STIP)
when it handles authorization, address verification, PIN verification, account verification,
and stop payment requests.

This chapter summarizes the CDB files, the file layouts, and the field contents, and also
identifies which entity is responsible for maintaining each file.
A full description of the Cardholder Database and its files appears in V.I.P. System BASE I
Processing Specifications and in V.I.P. System SMS Processing Specifications (U.S.).
Field description requirements for the files appear in V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, and in V.I.P. System SMS POS (Visa & Visa
Electron) Technical Specifications, Volume 1 and Volume 2.
16.2 DATABASE FILES

The following figures illustrate the Cardholder Database files. Visa is responsible for
maintaining the Activity File and the advice files. Issuers are responsible for establishing
and for maintaining the remaining CDB files.
NOTE
The shaded areas in the figures represent the data that Visa maintains.
Activity File
All Data Maintained by Visa
Advice File
All Data Maintained by Visa
Address Verification File

Account Cardholder Address
Number Account Country Verification Effective
Length Number Purge Date Code Postal Code Value Update Time Time
Exception File
Account Cardholder Spending
Number Account Purge Country Action Region Amount Spending Update Effective
Length Number Date Code Code Coding Limit Count Limit Time Time

Chapter 16 File Record Format
PIN Verification File

Cardholder
Account Account PIN Verification
Number Length Number Purge Date Country Code Data Update Time Effective Time
Portfolio File
Account Cardholder Card- Merchant
Number Account Country Issuer ID Type of holder Account
Length Number Purge Date Code Length Issuer ID Stop Order Name Number
Risk-Level File
Merchant
Account Cardholder Issuer Daily Group
Number Account Purge Country ID Issuer Risk Spending Activity Update Effective
Length Number Date Code Length ID Level Limit Limits Time Time
16.3 FILE RECORD FORMAT

The file record format determines which fields VisaNet requires for online file update
advices (0120 and 0322) and responses (0130 and 0332). The V.I.P. System technical
specifications manuals provide descriptions of these formats and their requirements.
16.3.1 How V.I.P. Determines Effective and Update Date and Time
Effective Date and Time for Records—Effective time is the date and time when the record
goes into effect. The effective time is the date and time the VIC receives the message.
This time applies both to adding records and to deleting records.
Update Date and Time for Records—Update time is a system-generated “time stamp”
indicating the date and time that a VisaNet establishes a record. Update time is not visible
to users but is available to Visa for research and for settling chargeback disputes. VisaNet
automatically generates the update time when it first enters a pick-up record in the file, and
when it changes a VIP (Very Important Person) or an XA (exception action) code in an
existing record to a pick-up code.
For the Exception File, update time refers to the first date and time that VisaNet updates
01, 04
the file with an action code other than an approval, that is, pick-up codes 01 04, 07
07, 41
41,
43. VisaNet keeps this date and time and does not change it during subsequent updates
or 43
as long as the action code is not an approval. For file types other than Exception File types,
the update time date specifies the date and time of the last record update.
16.4 FILE DESCRIPTIONS

The following sections describe each file contained in the Cardholder Database and identify
which V.I.P. System services use that file. For additional information about file-related
services, refer to the chapters noted in the file descriptions. For additional information
about specific Cardholder Database files, refer to V.I.P. System BASE I Processing
Specifications, to V.I.P. System International SMS POS (Visa & Visa Electron) Processing
Specifications, and to V.I.P. System SMS Processing Specifications (U.S.).

Chapter 16 Activity File
16.4.1 Related Services Listings

Every file description in this chapter contains a Related Services subsection.
These subsections list the V.I.P. services that check the cardholder file being described.
The service chapters in this manual describe only those files that directly relate to the
processing of the specific service. While V.I.P. may check additional files during transaction
processing, this chapter does not describe these files or illustrate them in the flows.
Thus, the Related Services subsections may mention relationships between files and
services that the service chapters do not describe.
16.5 ACTIVITY FILE

Description
The Activity File is a VIC-resident online file that contains, for each cardholder, accumulated
transaction and PIN-entry activity that the VIC processes. The Activity Files does not
contain activity information about individual transactions. STIP uses these files it performs
an activity check as part of authorization processing and then only under certain conditions.
See Chapter 2, V.I.P. System Fundamentals, in Volume 1, for an overview of STIP activity
processing.
Related Services
The following V.I.P. System services rely on the Activity File:
The PIN Verification Service (PVS)—

(PVS)—For issuer processors using the PIN Verification
Service, the activity record contains one accumulator that tracks the number of consecutive
invalid PIN-entry attempts. Issuer processors control PIN-retry activity by selecting a value
to limit the number of consecutive invalid PIN-entry attempts for one day.
(PCAS)—Issuers establish activity limits

The Positive Cardholder Authorization Service (PCAS)—
(using PCAS) for BASE I STIP. When an issuer is not available, V.I.P. acts as a back-up
processor and authorizes or declines point-of-sale or point-of-service (POS) transactions
on the issuer's behalf. This function is referred to as stand-in processing, or STIP. All
issuers specify the stand-in processing parameters that V.I.P. is to use for STIP processing.
NOTE
POS refers to the place where the customer and the card acceptor are located at the time a customer uses a
card (or check) for a purchase or for cash.
File Control
Each VIC has a unique Activity File, containing STIP and PIN-verification activity for its
issuer processors. Visa is solely responsible for the content, the maintenance, and the
integrity of the activity files at all VICs.
File Content
The Activity File organizes activity file records by cardholder account number. For activity
checking, each cardholder record contains accumulators that track:
• Merchant group activity.
• Invalid PIN-entry activity (applies to BASE I only).
V.I.P. accumulates activity for approved transactions. Issuer processors specify whether
STIP is to check activity and set activity limits.

Chapter 16 Activity File
The following table illustrates the contents and the structure of an activity record for
purchases and for cash.
Activity Record
Invalid PIN-entry
attempts (BASE I
Purchase Activity Cash Activity Daily Spending Monthly Spending only)
16.5.1 Merchant Group Activity

For merchant group activity checking, the file contains accumulated counts and dollar
amounts of STIP-generated approvals for purchase and cash transactions for the current
processing day and for the past three days. VisaNet groups the activity data into nine sets
of activity accumulators, as listed in Table 16-1.
• Four travel and entertainment (T&E) groups (Commercial Travel, Lodging, Automobile
Rental, Restaurant)
• Mail Order and Telephone Order (MOTO)
• Risky Purchase
• Total Purchase
• Total Cash
• ATM Cash
Each set consists of two accumulators:
• Total approvals for the current day
• Total approvals for the current day plus the past three days
Issuer processors can set separate activity limits for when the issuer processor center is
available and for when it is unavailable. The Activity File, however, does not maintain
separate counts of transactions approved under each set of activity limits (available and
unavailable). V.I.P. accumulates all activity together.
Table 16-1 Purchase and Cash Activity Merchant Groups
Merchant Groups for

Merchant Groups for Purchase Activity Cash Activity
Auto Mail and Risky Total ATM
Travel Lodging Rental Restaurant Phone Purchase Purchase Total Cash Cash
1-Day
Totals
Count
4-Day
Totals
Count
16.5.2 PIN-Entry Attempt Activity Data

The content of an activity record for invalid PIN-entry attempts contains the total number of
consecutive invalid PIN-entry attempts for the current day.

Chapter 16 Address Verification File
16.6 ADDRESS VERIFICATION FILE

Description
The Address Verification File (AVF) contains cardholder address information, which
allows acquirers to validate the cardholder billing address for direct marketing (mail order
or telephone order) transactions, for airline transactions, and for card-present (CP)
transactions.
Related Services
The following V.I.P. System service relies on the Address Verification File:

(AVS)—When V.I.P. verifies addresses, it checks
The Address Verification Service (AVS)—
the address data in the request message against the billing address information in the
Cardholder Database's Address Verification File. Issuers maintain this file at the VIC.
Issuers supply the address verification result code in the 0110 authorization response
message, unless STIP performs the address verification on behalf of the issuer. In this
case, STIP then sends an 0120 advice message to the issuer. The 0120 advice message
contains the billing address and the AVS result code.
File Control
Issuers are responsible for maintaining the contents of the Address Verification File.
File Maintenance
Issuer processors that choose to use the Address Verification File are responsible for
assigning and for maintaining the postal or ZIP code and the address verification value
fields.
16.7 ADVICE FILE
Description
Each VIC maintains advice files to store records of BASE I and SMS STIP responses.
Each record contains information from the authorization or reversal request, the STIP
response, and the reason why STIP processed the request.
Related Services
All V.I.P. services that use STIP also use the advice files. For information about the advice
files as they relate to a particular service, see the pertinent service chapter.
File Control
Visa is responsible for maintaining the data in the advice files. BASE I and SMS issuers,
as well as SMS acquirers, are responsible for retrieving advices from the advice files.
File Maintenance
VisaNet keeps advices on file at the VIC. Issuer processors can choose to receive their
advice records either by using online messages or through BASE II. If issuer processors
recover their advices online, they cannot recover the same advices using BASE II.
They can, however, request printed BASE I or BASE II reports of their advices.
NOTE
V.I.P. stores SMS advices online for 30 days. SMS issuers that want to retrieve their advices need to retrieve
them within this 30-day period.

Chapter 16 Card-Level Product ID File
For more information about advice retrieval, see Advice Retrieval Service—BASE I, and
Advice Retrieval Service—SMS.
16.8 CARD-LEVEL PRODUCT ID FILE
Description
The Visa Incentive Network (VIN) maintains the reward program requirements for programs
such as Visa Traditional Rewards. This network and file enables issuers in the Visa
U.S.A. (U.S.) region and in Visa Canada (CAN) to offer reward programs to cardholders.
For example, a 10% discount for purchase amounts over USD$100 at Office One.
Issuers use the Card-Level Product ID File to register their reward programs and eligible
cardholders in the VIN’s Cardholder Information Repository (CIR) database. In turn,
the CIR periodically (daily, monthly, semi-annually) provides the online Cardholder
Database (CDB) with updated information that V.I.P. needs for authorization processing.
Currently, the VIN provides the CDB with Visa Traditional Rewards program data.
When V.I.P. receives an 0100 authorization or 0200 full-financial request from an acquirer,
V.I.P. uses the CDB data to populate Field 62.23—Card-Level Results with the appropriate
product value for the cardholder before it forwards the request to the issuer. If the CDB
does not contain information for the account number being processed, V.I.P. uses the
BIN default product value.
File Content
The update file consists of a control record followed by as many data records necessary for
updates. A separate file containing a trailer record follows the last data record. All records
(control, data, and trailer) are in variable length EBCDIC and UMF format
The Card-Level Product ID File consists of the following fields:

• Activation Date
• Account Product ID
• Rewards Program ID
File Control
The CDB’s Card-Level Product File is updated from data in the CIR database.
File Maintenance
Issuers are responsible for ensuring (maintaining and updating) that the CDB file data
is correct.
16.9 EXCEPTION FILE
Description
The Exception File is a VIC-resident online file that contains data for an issuer's cardholder
accounts that require non-standard responses to authorization requests. V.I.P. accesses
the file during STIP processing when STIP is responding to an authorization request on
behalf of an issuer. Reasons for exception (non-standard) authorization responses include:
• A merchant or a member should confiscate the card if a cardholder presents it.
• STIP should provide a referral response. Acquirers try to contact issuers directly.
For international referrals, if issuers are unavailable, acquirers should contact the

Chapter 16 Exception File
International Automated Referral Service (IARS). See the International Automated

Referral Service (IARS) for information about this service.
• The issuer should process the request whenever possible.
• STIP should approve transactions on this account regardless of cardholder activity.
File—V.I.P. uses this file for authorizations and issuers maintain it. Issuers use it
Exception File—
to list accounts in the CRB
The Exception File types are:
E1—Exception File (V.I.P. Auth-Only)—batch file update only

E1

E2—Exception File (V.I.P. Auth-Only)
E2
E3—Exception File (V.I.P. Auth-Only and V.I.P. Full Service)

E3
E4—Exception File (V.I.P. Full Service)

E4
Issuers can update the Exception File using an online transaction. To list an account
number, issuers use message type 0302 specifying file type E1 E1, E2
E2, E3
E3, or E4
E4. Once
E3, for any future updates for that account
issuers list an account number using file type E3
number, issuers must always use file type E3E3; otherwise, V.I.P. rejects the updates.
For CDB update files and file types, refer to V.I.P. System BASE I Technical Specifications,
Volume 1 and Volume 2, V.I.P. System SMS ATM Technical Specifications, Volume 1 and
Volume 2, V.I.P. System SMS Interlink Technical Specifications, and V.I.P. System SMS
POS (Visa & Visa Electron) Technical Specifications, Volume 1 and Volume 2.
16.9.1 Visa International Exception File

Visa offers a CD-ROM bulletin version of the exception file to all non-U.S. centers. Centers
use this copy, known as the Visa International Exception File, during manual and back-up
authorization.
Related Services
The following V.I.P. System services rely on the exception files:
Service—When V.I.P. STIP receives an account verification request,

Account Verification Service—
it checks the card expiration date and the Exception File.
Service—The ATM/POS Split Routing Service allows issuers that

ATM/POS Split Routing Service—
operate as alternate processors to update and to access exception file account records
on behalf of the primary issuer.
Service—If an issuer participates

Automatic Cardholder Database Update (Auto-CDB) Service—
in this optional service, whenever the issuer responds to an authorization request with
a “pick-up card” response—response code 04 (pick-up card [non-fraud]), 07 (pick-up
card—special condition [fraud]), 41 (pick-up card—lost card [fraud]), or 43 (pick-p
card—stolen card [fraud])—V.I.P. checks the Exception File to determine if the file lists the
cardholder account. If the file does not list the account, V.I.P. automatically adds the
account to the file with the applicable pick-up code and with region code 0. It also sends an
advice of the Exception File update to the issuer.

NOTE
Issuers in the U.S. region can also use negative action code 05 (do not honor) to list U.S.-domestic accounts in
the CRB. Issuers in all other regions must use one of the four pick-up action codes to list accounts in the CRB.
Card Recovery Bulletin (CRB) Service—

Service—The Exception File is the only source for the
electronic CRB bulletins. Entering an account number in the Exception File with a pick-up
response code and with the CRB region coding ensures that the service includes the
account number in the applicable bulletins.
V.I.P. rejects issuer-submitted updates containing invalid account numbers. If an issuer

needs to list an account in the CRB for pick-up reasons but the account number is invalid
(not in V.I.P.'s system tables), the issuer must contact its Visa representative for help.
Visa then places the account number in a file, which the system later combines with the
Exception File for updates to the CRB.
NOTE
The CRBs contain only accounts with pick-up action codes; that is, 04 (pick-up card, unspecified,
41 (pick-up
non-fraudulent), 07 (pick-up card (special conditions [other than lost, stolen, or counterfeit card]), (41
card, lost card [fraud]), or 43 (pick-up card, stolen card [fraud]). Issuers in the U.S. region can also use
negative action code 05 (do not honor) to list U.S.-domestic accounts in the CRBs. Issuers in all other regions
must use pick-up action code to list accounts in the CRBs.
Service—As part of standard request processing,

Visa Shortest Online Path (VSOP) Service—
V.I.P. checks the Exception File and then routes the authorization requests directly to the
issuers, bypassing MasterCard's Banknet.
File Control
Issuers are responsible for the contents and the maintenance of the Exception File.
Every issuer must decide how best to use the Exception File. They base this decision on
the authorization center's mode of operation and on the degree of control they want.
Visa advises issuers to include all pick-up accounts in the Exception File so that STIP does
not authorize transactions for those accounts when processing transactions for the issuer.
File Maintenance
When updating the Exception File, issuers can update accounts having 5- to 28-digit
account numbers, including alphanumeric account numbers.
16.9.2 Online Exception File Editing Summary (0302 Messages)

Members can maintain their exception records without knowing the current status of the
record on the V.I.P. file.
• VisaNet accepts an attempt to add a record for a cardholder that is already on the file
as a change.
• VisaNet accepts an attempt to change a record for a cardholder that is not already on the
file as an addition.
• V.I.P. rejects attempts to delete a record that is not on the file with reject code 565
(deletion error).
• VisaNet processes attempts to add, to change, or to delete exception records that are
subject to a dual-item check according to member instructions (add, change, or delete).
Out-of-synchronization conditions do not affect the update task.

Which file types Issuers can use depend on the sending station. Violations result in Reject
530—Invalid File Type. Valid file types are E1
Code 530 E1, E2
E2, E3
E3, and E4
E4.
Table 16-2 summarizes the Exception File update processing actions.
Table 16-2 Exception File Update Processing Actions
Card Number Valid— Card Number Valid—

Not Present on File Present on File
Action and File Type Result Result
Add E1 Replace

Add E2 Replace
Change E1 Add to File
Delete E1 0565
Error—0565
Delete E2 0565
Error—0565
Add E4 Replace
Table 16-3 summarizes the V.I.P. format exception file update processing actions.
Table 16-3 V.I.P. Format Exception File Update Processing Actions
BASE I BASE I BASE I BASE I

Invalid/ BASE I Invalid/ BASE I Valid/ BASE I Present/
SMS Invalid/ SMS Valid/ SMS Present/ SMS
Invalid SMS Valid Present SMS Valid Present SMS Valid Present
Action and File Type Result Result Result Result Result Result Result
E3—
Add E3
Network specified Add/Replace Add/Replace Replace
E3—
Add E3
Network not specified Replace Add/Replace Add/Replace Replace
Add E4 Replace Replace Replace
E3—
Change E3
Network specified Add Add/Change Add/Change
E3—
Change E3
Network not specified Add Add/Change Add/Change
Change E4 Add Add Add Add
E3—
Delete E3 0571 0572
Network not specified
Delete E4 0571 0572
16.9.3 Exception File Purge Date Assignments

The purge date field contains a date indicating when VisaNet is to remove a record from
the Exception File.

Chapter 16 PIN Verification File
Changes—For additions and changes to Exception File records,

Format 2 Additions and Changes—
V.I.P. converts the purge date to coincide with the expiration date of the CRB in effect
at that time, using the YYMMDD format.
V.I.P. rejects Exception File records submitted with purge date years 2042 through 2098.
NOTE
The exception file stores only one purge date at a time for an account. This date corresponds to the expiration
date of the applicable bulletin for the region in which the account is listed.
Assignments—When the Auto-CDB Service initiates an update to the Exception

Purge Date Assignments—
File, V.I.P. assigns the purge date in the request to the file record. If the issuer does not
provide the purge date, V.I.P. assigns the authorization purge date to the file record.
Refer to V.I.P. System BASE I Processing Specifications for more information about purge
dates.
16.9.4 Global Customer Assistance Services (GCAS)

Issuers may report lost or stolen cards to Global Customer Assistance Services (GCAS).
GCAS can update the Exception File on behalf of the issuer.
16.10 PIN VERIFICATION FILE
Description
When a cardholder uses a personal identification number (PIN) at the point of service
(POS) or at an ATM, the acquirer includes the PIN in the authorization request so that
the issuer (or STIP) can verify the cardholder. The VIC performs this service for those
issuers that choose to have V.I.P. perform PIN verification during normal processing or
when the issuer is unavailable.
NOTE
STIP is not available for MasterCard transactions.
The Visa Security Module (VSM) at the VIC uses the PIN Verification File to verify the
cardholder for the issuer. V.I.P. uses the PIN Verification File as follows:
• When the issuer does not encode the PIN Verification Value (PVV) and the PIN
Verification Key Index (PVKI) or the IBM PIN offset on the magnetic stripe, they must list
these values in the PIN Verification File. Otherwise, V.I.P. assumes that the PVV and
PVKI or the offset appears in the authorization request.
• When the issuer encodes the PVV and PVKI or the offset on the stripe, issuer use of the
file is optional. An issuer may use the file for exceptions, such as for emergency card
reissues or for changes in account numbers, PINs, or PIN Verification Keys (PVKs).
In these instances, the data on the file overrides any magnetic stripe data present in
the authorization request.
NOTE
The PIN Verification File cannot contain multiple PVV and PVKIs or IBM offsets for the same cardholder
account. If the issuer issues cards with the same account number but with unique PVVs and PVKIs or offsets
for individual family members, the issuer should not use the PIN Verification File.

Chapter 16 Portfolio File
Related Services
The following V.I.P. System services rely on the PIN Verification File:
Service—The ATM/POS Split Routing Service allows issuers that

ATM/POS Split Routing Service—
operate as alternate processors to update and to access PIN Verification File account
records on behalf of the primary issuer.
(PVS)—The issuer must place PVVs and PVKIs or offsets on the

PIN Verification Service (PVS)—
magnetic stripe of its cards or must maintain them in the PIN Verification File at the VIC.
If PVVs and PVKIs appear both on the magnetic stripe and in the PIN Verification File,

the data in the PIN Verification File overrides the data in the magnetic stripe.
Service—If the issuer uses the Split Routing option for

PIN/No-PIN Split Routing Service—
PIN/No-PIN transactions or to route ATM and POS transactions, V.I.P. uses information in
the PIN Verification File to process transactions with PINs.
Service—For VSOP issuers, V.I.P. uses information in

Visa Shortest Online Path (VSOP) Service—
the PIN Verification File to process transactions with PINs. Issuers, however, must define
their MasterCard account ranges in the split-BIN table to be linked to the same BIN as
their Visa card account ranges.
File Control
Issuers are responsible for ensuring that the PIN Verification File contains current account
numbers, PVVs, and PIN verification keys or IBM PIN offset values. If the file is incomplete
or is out of date, V.I.P. cannot verify PINs correctly.
File Maintenance
When updating this file, issuer processors can update accounts having 5- to 28-digit
account numbers, including alphanumeric account numbers.
16.11 PORTFOLIO FILE
Description
The Portfolio File contains issuer-supplied stop payment commands for recurring payment
transactions.
• Cardholders initiate stop payment orders, and the Preauthorized Payment Cancellation
Service (PPCS) enables issuers to stop electronic funds transfers for specific recurring
transactions or for installment payment transactions for a specific account from a
particular merchant when requested by the cardholder.
• For revocation of authorization orders, PPCS enables issuers to stop all future electronic
funds transfers for recurring or installment payment transactions for a specific account
from a particular merchant when requested by the cardholder.
When V.I.P. receives a recurring payment authorization request
(Field 60.8—Mail/Phone/Electronic Commerce and Payment Indicator
contains 2 or field 126.13 contains R), V.I.P. checks the Portfolio File to see if there is a
stop payment command on file. If V.I.P. does not find a match, it continues processing the
request. If V.I.P. finds a match, it declines the transaction on behalf of the issuer with
one of the following response codes in field 39: R0 (stop payment order), R1 (revocation
of authorization order), R3 (revocation of all authorizations order), or C2 (revocation of

Chapter 16 Risk-Level File
all authorizations order). SMS advices contain code 9031 in Field 63.4—STIP/Switch
Reason Code.
NOTE
C2.
Only BASE II transactions use code C2
Related Services
The following V.I.P. System service relies on the Portfolio File:
(PPCS)—PPCS enables issuers to stop

Preauthorized Payment Cancellation Service (PPCS)—
payments on preauthorized payment transactions, such as those for recurring or installment
payments. Participating issuers place stop payment orders in the Portfolio File. When
acquirers submit a preauthorized payment transaction, V.I.P. checks the database and if it
encounters a stop payment order for that account number, it declines the request.
File Control
Issuers are responsible for maintaining all of their cardholders' stop payment orders in the
Portfolio File.
File Maintenance
Issuers update the records with 0302 messages using a tag-length-value (TLV) field format
for the type of stop order, cardholder name, and merchant account number. V.I.P. gets
other record information, such as the transaction identifier (TID), from other fields in the
0302 message. Refer to the field 127.PF description in V.I.P. System BASE I Technical
Specifications, Volume 1, for details about submitting Portfolio File data.
16.12 RISK-LEVEL FILE
Description
Issuers using BASE I risk-level controls access the risk-level file for the following reasons:
• To assign an account-specific risk level
• To assign account-specific daily spending limits
• To assign account-specific merchant group daily activity limits
Using these options, issuers can tailor risk levels and daily spending and activity limits to
suit a particular cardholder. The file-resident risk levels override the BIN defaults and the
card-encoded risk levels. This file lists only accounts that have exceptions to the assigned
default values.
Related Services
The following V.I.P. System services rely on the risk-level file:
Positive Authorization Capacity Management (PACM) Service— Service—Issuers using the PACM
Service specify risk parameters, which they maintain in the exception files and in the
risk-level file. If STIP finds one of the Very Important Person (VIP VIP)
VIP action codes A1
through A9 listed in the Exception File, it checks the limits in the risk-level file (if available)
instead of the standard activity limits.
NOTE
VIP action codes indicate that special high-value activity limits apply.

Chapter 16 For More Information
File Control
Issuer processors that choose to use the risk-level file have sole responsibility for assigning
and for maintaining individual cardholder's risk levels, daily spending limits, and merchant
group daily activity limits in the risk-level file.
File Maintenance
A, B, C, or D), V.I.P. assigns the default risk
If the issuer has not specified a risk level (A
level (CC).
Refer to V.I.P. System BASE I Processing Specifications for more information about the

risk-level file.
16.13 FOR MORE INFORMATION

For more information about the Cardholder Database, refer to the following documents:
• V.I.P. System BASE I Processing Specifications
• V.I.P. System International SMS ATM Processing Specifications
• V.I.P. System International SMS POS (Visa & Visa Electron) Processing Specifications
• V.I.P. System SMS Processing Specifications (U.S.)


Chapter 17 Automatic Cardholder Database Update (Auto-CDB) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
IN BRIEF 17-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
ELIGIBLE PARTICIPANTS 17-33
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
SERVICE SUMMARY 17-33
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
PARTICIPATION REQUIREMENTS 17-44
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
RELATED MESSAGES 17-44
HOW AUTOMATIC CARDHOLDER DATABASE UPDATE (AUTO-CDB)

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
SERVICE WORKS 17-44
Auto-CDB Service
Advice Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
Exception File Update Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
Exception File Discrepancy Advices. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .17-5
PROCESS FLOWS
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
17-55
Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
MESSAGE FLOWS 17-66
Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-
KEY FIELDS GLOSSARY 17-88
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-

Auto-CDB Service

Chapter 17 Automatic Cardholder Database Update (Auto-CDB) Service
17.1 IN BRIEF
The Automatic Cardholder Database Update (Auto-CDB) Service allows V.I.P. to
update the Exception File when participating issuers return a pick-up response code in
authorization response messages.
Auto-CDB Service helps issuers prevent losses from problem accounts and improves the
accuracy of cardholder information available to V.I.P. for stand-in processing (STIP).
17.2 ELIGIBLE PARTICIPANTS
The Auto-CDB Service is available to members in all Visa regions.
Auto-CDB Service
BASE I
The Auto-CDB Service is available to both BASE I System and Single Message
SMS System (SMS) issuers that process Visa Electron and Plus ATM transactions.
It is not available for Interlink card issuers.
BASE I and SMS
I Participation in the Auto-CDB Service is optional for issuers. Processors select

Auto-CDB at the BIN level.
Issuer
17.3 SERVICE SUMMARY

The Automatic Cardholder Database Update (Auto-CDB) Service allows V.I.P. to
update the Exception File when participating issuers return a pick-up response code in
authorization response messages.
The Exception File is comprised of account data, both favorable and unfavorable.
V.I.P. checks these files during online authorization when STIP responds to a request on
the issuer's behalf. The account records in the Exception Files specify the action STIP is
to take for each listed account.
V.I.P. confirms issuer requests for updates to the Exception File by generating either an
0130 or 0332 advice message. For Auto-CDB Exception File updates, V.I.P. confirms the
updates in an 0210 or 0322 response message.
For more information about the exception file, refer to the Cardholder Database Overview
chapter.

Chapter 17 Participation Requirements
17.4 PARTICIPATION REQUIREMENTS

This section contains information about participation requirements for the Auto-CDB
Service.
Participation in the Auto-CDB Service requires no issuer system or programming changes.
17.4.1 Testing
Visa requires testing before issuers can use the Auto-CDB Service. Issuers that choose to
receive 0120 advices must test that they can receive 0120 advices and can send 0110 file
update messages. Issuers that choose to receive 0322 advices must test that they can
receive 0322 advices and can optionally send 0332 advice response messages.
Refer to the Card Recovery Bulletin (CRB) Service, in Volume 1 for more information.
To prepare for Auto-CDB testing, issuers must supply Visa with test account numbers.
To test this service, members must contact their Visa representatives.
17.4.2 Service Monitoring

Service monitoring is not available for the Auto-CDB Service.
17.5 RELATED MESSAGES

Auto-CDB Service
The following messages pertain to the Auto-CDB Service.
0110: Auto-CDB Authorization Response—

Response—When issuers specify the pick-up action code in
Field 39—Response Code and the Exception File does not already list the account with a
pick-up status, V.I.P. updates the exception file and sends an 0120 advice. (See Table 17-1
for a list of pick-up action codes.)
Update—This message notifies issuers that V.I.P. has

0120: Advice of Exception File Update—
updated the Exception File (Field 44.1—Response Source/Reason Code contains CRB
reason code 0).
Response—When issuers specify the pick-up action code in

0210: Financial Transaction Response—
field 39 and the Exception File does not already list the account with a pick-up status,
V.I.P. updates the Exception File and sends an 0220 advice.
Advice—This message notifies issuers that choose to receive 0322

0322: File Update Advice—
advices that V.I.P. updated the Exception File; it includes the updated authorization
response information. If V.I.P. could not process the 0110 or 0210 message, the 0322
message includes the discrepancy code in Field 48—Additional Data—Private.
SMS issuers must generate an 0332 response to acknowledge receipt of this advice.
Issuers that choose to receive 0322 advices optionally may generate an 0332
response to acknowledge receipt of this advice. Message type 0322 does not contain
Field 44—Additional Response Data.
Response—This message notifies V.I.P. that the issuer received

0332: File Update Advice Response—
the 0322 advice.
17.6 HOW AUTOMATIC CARDHOLDER DATABASE UPDATE (AUTO-CDB) SERVICE

WORKS
This section explains advice generation for the Auto-CDB Service.

Chapter 17 Process Flows
17.6.1 Advice Generation

V.I.P. generates both updates and discrepancy advices for Auto-CDB.
17.6.1.1 Exception File Update Advices

Whenever the Auto-CDB Service updates the Exception File, V.I.P. generates an 0120 or
0322 advice and stores it in the advice file. Issuers can retrieve these advices the same
way as they would any other advices. Refer to the Advice Retrieval Service—BASE I or to
the Advice Retrieval Service—SMS chapters for information about advice retrieval.
The issuer receives one of the following types of Exception File update advices:
• 0120 advice of Exception File update
• 0322 file update advice (sent only to issuers that have successfully completed testing
to process message type 0322)
NOTE
An issuer cannot receive both types of update advices.
See “Related Messages” in this chapter for more information about 0120 and 0322 advice
messages.
Auto-CDB Service
17.6.1.2 Exception File Discrepancy Advices
V.I.P. generates a discrepancy advice when the file update action code in Field 91—File
Update Code conflicts with the message response code in field 39. In such a case,
V.I.P. does not process the requested file update. Issuers should send a new request with
the correct file update information.
The discrepancy advice may contain a file update error code indicating that the update
request was inconsistent with the authorization response or that the request contained
edit errors.
For a description of valid error codes, refer to V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2.
17.7 PROCESS FLOWS

The following subsection describes the process flow for the Auto-CDB Service.
17.7.1 Auto-CDB Process Flow

As illustrated in Figure 17-1, the Auto-CDB Service process flow begins when the acquirer
sends an authorization request to the issuer through V.I.P. The issuer responds with a
pick-up action code.
Table 17-1 lists the pick-up action codes for the Auto-CDB Service that issuers can send in
field 39 of an 0110 or 0210 authorization response.
Table 17-1 Auto-CDB Pick-Up Action Codes
Code Description
04 (non-fraud)—This code is a decline-and-pick-up response. For an
Pick-Up Card (non-fraud)—
unspecified but non-fraud reason, the issuer wants the card recovered at the
point of sale or point of service (POS).

Chapter 17 Message Flows
Table 17-1 Auto-CDB Pick-Up Action Codes (continued)

Code Description
07 (fraud)—This code is a decline-and-pick-up
Pick-Up Card—Special Condition (fraud)—
response. For a reason other than a lost or stolen card, the issuer wants the
card recovered at the POS.
41 (fraud)—This code is a decline-and-pick-up response.
Pick-Up Card—Lost Card (fraud)—
A cardholder has reported a lost card; the issuer wants the card recovered.
43 (fraud)—This code is a decline-and-pick-up
Pick-Up Card—Stolen Card (fraud)—
response. A cardholder has reported a card theft; the issuer wants the card
recovered.
During Auto-CDB processing, V.I.P. checks the Exception File for accounts receiving
a pick-up response code in the authorization response message. If the Exception File
lists the account with something other than pick-up status, V.I.P. changes the listing to
pick-up status. If the file does not list the account, the V.I.P. System adds the listing with
the appropriate pick-up code and with CRB region code 0.
The Auto-CDB Service lists the account either for the authorization purge date or until the
original expiration date for the existing account listing, whichever date is later.
Auto-CDB Service
Figure 17-1 Auto-CDB Process Flow
Exception
File
The acquirer sends an V.I.P. performs standard The issuer indicates a

authorization request to request processing. pick-up response code.
the issuer.
V.I.P. adds the pick-up

code to the Exception
File after receiving the
authorization response
and then forwards the
issuer's response to
the acquirer
17.8 MESSAGE FLOWS

The following subsection describes and illustrates the Auto-CDB Service message flow.

17.8.1 Auto-CDB Message Flow

Figure 17-2 illustrates the Auto-CDB message flow. The acquirer sends an 0100 or 0200
request. The issuer sends the acquirer an 0110 or 0210 authorization response containing
pick-up response code 04 04, 07
07, 41
41, or 43 in field 39 (see Table 17-1). V.I.P. sends the issuer
an 0120 or 0322 advice indicating that it updated the Exception File.
NOTE
Issuers receive either the 0120 or 0322 advice. V.I.P. includes the authorization information in the 0322
advice and the discrepancy code in field 48 (if applicable). SMS issuers must respond with an 0332 advice
response to acknowledge receipt of the 0322 advice. Issuers that choose to receive an 0322 advice optionally
may respond with an 0332 advice acknowledging receipt of the advice.
Auto-CDB Service

Chapter 17 Key Fields Glossary
Figure 17-2 Auto-CDB Message Flow
Exception
File
0100 or 0200 Request 0100 or 0200 Request 0100 or 0200 Request
0110 or 0210 Response 0110 or 0210 Response 0110 or 0210 Response

Field 39: 04, 07, 41, or 43 Field 39: 04, 07, 41, or 43 Field 39: 04, 07, 41, or 43
Field 91: File Update Code Field 91: File Update Code Field 91: File Update Code
Auto-CDB Service
0120 Advice 0120 Advice

Field 44.1: Response Source/ Field 44.1: Response Source/
Reason Code = 0 Reason Code = 0
Field 91: File Update Code Field 91: File Update Code
0130 Advice Response 0130 Advice Response
(or)

Field 73: Record Purge Date Field 73: Record Purge Date
Field 101: File Name Field 101: File Name
Field 127E.1: Action Code Field 127E.1: Action Code
0332 Advice Response 0332 Advice Response
17.9 KEY FIELDS GLOSSARY

This section includes the fields that pertain to updating the Exception File using the
Auto-CDB Service.

Field 39—Response Code

V.I.P. does not use field 39 in 0322 Auto-CDB responses. Field 39 appears in
0120 advices; the code is either 00 (successful update), or 06 (discrepancy advice).
See Table 17-1 for a list of pick-up response codes that issuers use in 0110 and 0210
authorization responses for Auto-CDB.
Field 63.4—STIP/Switch Reason Code

This field contains a code that identifies why SMS STIP responded for the issuer or
why SMS generated an advice.
SMS Auto-CDB participants use field 63.4 to identify the reason that SMS generated
9030, indicating a pick-up
an advice. It appears in 0322 advices and contains code 9030
response from the issuer.
Field 91—File Update Code

This field contains a code that specifies the type of file processing required. It appears
in 0110 and 0120 responses, and in 0322 advices.
• V.I.P. Auth-Only issuers use field 91 in 0110 responses for add, replace, or delete
requests. A value of 1 indicates add; a value of 2 indicates change; a value of 3
Auto-CDB Service
indicates delete. V.I.P. rejects an add request if the account is already on file.
A replace request adds or updates the account record if it is not already on file.
• For V.I.P. Full Service issuers that choose to receive 0322 advices, field 91 appears
in 0322 advices for Auto-CDB. Issuers do not return it in 0332 responses. Field 91
must not contain the value 4 for Full Service participants.
Field 127E.1—Action Code

This field contains the code that determines the response and the special STIP handling
required when V.I.P. performs stand-in authorization on the issuer's behalf.
Field 127E.1 appears in 0110 responses as well as in 0120 and 0322 advices. It must
contain the pick-up code from field 39.
For V.I.P. Auth-Only participants, the 0322 advice contains the original contents that
the issuer included in field 127E1. VisaNet does not require an advice response
(0332 message). For V.I.P. Full Service participants, issuers receive field 127 in the
0322 advice. Issuers, however, do not return field 127 in the 0332 advice response.

The following documents contain additional information about Auto-CDB:
• V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2
• V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1
and Volume 2

Auto-CDB Service

Chapter 18 Merchant Central File Service (MCFS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
IN BRIEF 18-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
Updating the Merchant Central File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Effective Date for File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Acquirer Review of File Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
File Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
MCFS-Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
Merchant Central File Update Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7
WORKS.. . . . . . . . . . . . . . . . . . . . . . . .18-
HOW MERCHANT CENTRAL FILE SERVICE (MCFS) WORKS 18-77
Establishing Merchant Central File Augmentation Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-9
Merchant Category Code (Field 18). . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .18-10
Merchant Name, Location, Country (Field 43). . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .18-10
Merchant Central File Service (MCFS)

Card Acceptor Identification Code (Field 42). . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .18-10
Terminal Identification (Field 41). . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
Province, ZIP, or Postal Code (Field 59). . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .18-11
Merchant Verification Value (Field 62.20). . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .18-11
Vendor ID (Field 100). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
Specifying Key Online Message Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
Updating MCFS Records Online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-15
File Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-15
Field 127 Merchant File Update Fields. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .18-17
Updating Merchant IDs for Visa, American Express, MasterCard, and
Check Acceptance Record Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-19
Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-19
Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-20
Using Both Field 41 and Field 42. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .18-20
Updating Merchant IDs for Universal Record Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-20
Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-20
Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21

Chapter 18
Using Both Field 41 and Field 42. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .18-21

Updating Merchant IDs for Discover Record Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
PROCESS FLOWS 18-21
21
Processing an Authorization or Financial Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
Processing MasterCard Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-23
Terminal Translation Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-23
American Express Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-23
Discover Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-24
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
MESSAGE FLOWS 18-25
25
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
25
Key Fields Glossary for Merchant Central File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-27
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-
30

Chapter 18 Merchant Central File Service (MCFS)
18.1 IN BRIEF
The Merchant Central File Service (MCFS) supplies merchant information from the point of
sale or point of service (POS) that VisaNet requires in all authorization or reversal requests.
When the required information does not appear in the request because of device limitations,
V.I.P. adds the information from the Merchant Central File (if the data is available) before it
forwards the request to the issuer or to the stand-in processor (STIP).
The Merchant Central File (MCF) is separate from the Cardholder Database.
See Chapter 16, Cardholder Database Overview, for information about this database.
The Merchant Central File Service (MCFS) uses the MCF database of merchant information
exclusively; therefore, this chapter includes the description of the Merchant Central File.
Understanding the function of the MCF is essential to understanding MCFS.
MCFS is available to acquirers in all Visa regions.
BASE I
SMS MCFS is available to BASE I and SMS acquirers that participate in

0002.
Network 0002
BASE I and SMS
A Participation in MCFS is optional for both BASE I and SMS acquirers and
processors.
Acquirer

The Merchant Central File (MCF) is a VisaNet Interchange Center (VIC)-resident file that
acquirers use to store authorization, financial, and reversal request information that a
terminal at the POS cannot supply because of device limitations.
The MCF organizes files by acquirer BIN and by merchant identification (merchant ID,
merchant terminal ID, or both). Each merchant ID or merchant terminal ID within a
merchant facility can support multiple card types (such as MasterCard and Discover).

Chapter 18 Service Summary
The Merchant Central File Service (MCFS) retrieves merchant information stored in the
MCF and adds field data that the merchant cannot supply in requests before it forwards
them to issuers.
IMPORTANT
If an acquirer uses MCFS, it must comply with the policies and procedures necessary to maintain its entries
in the MCF at the VIC. Acquirers must include the controls necessary to ensure accuracy of the data and
the procedures for conveying updates to the VIC.
Acquirers are responsible for supplying and for maintaining the data in the MCF. If the
acquirer does not provide VisaNet with the necessary MCFS information in the MCF,
V.I.P. forwards to the issuer those requests that are missing the necessary message
information.
18.3.1 Updating the Merchant Central File

Acquirers submit updates to the MCF using one of the following methods:
Connection—This method enables acquirers to perform

Online Update Through a VisaNet Connection—
online updates using format 2 file update request messages (0300s and 0310s). Acquirers
submit these messages through their VisaNet connection. (Refer to About This Manual for
documentation about VisaNet connections.)
Update—MCFS offers a batch update option. Members must coordinate all batch
Batch File Update—
MCF update tape updates through their account managers. These files require additional
VIC processing time. Visa can provide members with the approximate processing time
once staff verifies the total number of records. During V.I.P. freeze periods, Visa scrutinizes
requests to process large files (such as the MCF) to avoid causing major spikes in the
highest processing periods. Members should expect increased processing delays with
large update files.
For message specifications, refer to the pertinent V.I.P. System technical specifications
manuals listed in “For More Information” in this chapter.
For more information about the record format for the update tapes, refer to V.I.P. System
BASE I Technical Specifications, Volume 1 and Volume 2, and to the pertinent V.I.P.
System SMS technical specifications manuals.
18.3.1.1 Effective Date for File Updates

The effective date field contains the date and time that the MCF record update goes into
effect. V.I.P. determines the effective date and time of a record by the following methods
used to create or to update the record:
Method—The effective date and time is the date and time the VIC receives the
Online Method—
message.
Method—The effective date and time is the center-specified date and time in the file
Batch Method—
header (for instance, the file creation date or time).
The VIC uses the effective date and time to control the priority of multiple updates to the
same record. The question of priority arises when an acquirer updates a record by batch
method and then updates the same record online before the VIC receives the tape.

When the effective date and time of the MCF database record does not match the effective
date and time of the update record under the specified conditions, V.I.P. processes the
record according to the guidelines in Table 18-1.
Table 18-1 Effective Date for File Updates
If... Then...
The database effective date and time is less V.I.P. updates the MCF with the information in
than the effective date and time on the update the update record.
record...
The database effective date and time is greater V.I.P. does not update the MCF and rejects
than the effective date and time of the update the record with an effective date error (error
record... 707).
number 707
The database effective date and time is equal For an update processed by the same VIC
to the effective date and time of the update as the previous update, V.I.P. accepts the
record... change. Otherwise, if a different VIC processes
the update, V.I.P. rejects the update with an
707).
effective date and time error (error number 707
18.3.2 Acquirer Review of File Records

Acquirers can review their Merchant Central File records by sending an online message
to the VIC. The message specifies the merchant identification (merchant ID, merchant
terminal ID, or both) and the acquirer BIN for review; the VIC response contains the
requested record.
Acquirers can request MCF records at any time while they are signed on to the network.
However, Visa reserves the right to ask that acquirers not request records during peak
volume hours. When VisaNet receives a request, it verifies that the acquirer or the
processing center is authorized for file access.

Acquirers or processing centers can also contact their Visa representatives to request a
listing of MCF records for a Processing Center Record (PCR), for BINs, or for BIN ranges
within a PCR.
For details about online file inquiry requests, refer to V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, and to the pertinent V.I.P. System SMS technical
specifications manuals.

Visa has no specific requirements for participating in MCFS.
18.4.1 Testing
Visa does not require testing for participation in MCFS if acquirers deliver MCF updates
using the CUP batch method. Otherwise, acquirers must test that they can send 0300
messages and can receive 0310 responses.
The VisaNet Certification Management Service (VCMS) provides testing assistance

for MCFS participants. Members can contact their Visa representatives to make the
arrangements.

Chapter 18 Related Messages

Service monitoring is not available for the Merchant Central File Service.
18.4.3 File Control

Both Visa and acquirers share responsibilities for the Merchant Central File.
Responsibilities—Acquirers are responsible for the contents and the maintenance

Acquirer Responsibilities—
of the MCF. Specifically, acquirers are responsible for:
• Determining which merchant IDs, merchant terminal IDs, or both, to include in the file.
• Establishing the records.
• Keeping records current.
• Deleting records (when the acquirer wants to remove records prior to their expiration
date).
Responsibilities—Visa is responsible for:
Visa Responsibilities—
• Ensuring confidentiality of the MCF at each VIC.
• Maintaining the integrity of the MCF at each VIC.
When an acquirer updates its records, VisaNet distributes the updates to all VICs.
File integrity also includes keeping back-up copies of the file for recovery after a failure.
• Purging expired records.
VisaNet deletes records from the file after the expiration of their purge date.

This section describes messages that pertain to MCFS as well as messages used to
update the MCF.
18.5.1 MCFS-Related Messages

The following messages pertain to MCFS:
Request—When V.I.P. receives an 0100

0100: Authorization Request and 0200: Financial Request—
request or an 0200 request for an acquirer, V.I.P. checks the system tables to determine if
MCF augmentation data exists for the acquirer. V.I.P. then adds the MCF data to these
fields in the request (as applicable to each card type):
• Field 18—Merchant Type • Field 59—National Point-of-Service Geographic

Data
• Field 42—Card Acceptor Identification • Field 62.20—Merchant Verification Value
Code (for Universal Service only)
• Field 43—Card Acceptor Name/Location • Field 100—Receiving Institution Identification
Code (for Check Acceptance Service only)
NOTE
MCFS uses Field 32—Acquiring Institution Identification Code and Field 41—Card Acceptor Terminal
Identification to retrieve the file from the MCF. MCFS does not update the information in these fields.
Response—This message provides

0110: Authorization Response and 0210: Financial Response—
the issuer's decision to approve or to decline the customer transaction. For an approval
response, Field 39—Response Code contains response code 00 (approved and completed
successfully).

Chapter 18 How Merchant Central File Service (MCFS) Works
Request—When V.I.P. receives an 0400 request for an acquirer,

0400: Reversal Request—
V.I.P. checks the system files to determine if augmentation data exists for the acquirer.
V.I.P. then adds the MCF data to these fields in the request (as applicable to each card
type):
• Field 18 • Field 59
• Field 42 • Field 62.20 (for Universal Service only)
• Field 43 • Field 100 (for Check Acceptance Service only)
NOTE
MCFS uses field 32 and field 41 to retrieve the file from the MCF. MCFS does not update the information in
these fields.
0410: Reversal Response—

Response—This message is the response to an 0400 message,
acknowledging receipt of the reversal request. For an approval response, field 39 contains
00.
response code 00
18.5.2 Merchant Central File Update Messages

The following messages pertain to updating the MCF:
Request—Acquirers use this message to add, change, delete,

0300: Acquirer File Update Request—
or retrieve MCF information. An 0300 message includes the following fields indicating the
specific information to add to the authorization or reversal request:
• Field 127M.1—Format 2, Merchant Record Type • Field 127M.4—Format 2, Merchant Data 2

• Field 127M.2—Format 2, Merchant Data 1 • Field 127M.5—Format 2, Merchant Data 2
• Field 127M.3—Format 2, Merchant Data 2
NOTE

Field 63.1—Network ID Code is mandatory in SMS 0300 request and 0310 response messages.
Response—This message is the response to an 0300 file

0310: Acquirer File Update Response—
update request indicating the results of the file update. Field 39 indicates whether V.I.P.
updated the Merchant Central File with the additional information provided in the 0300
request. If V.I.P. encounters errors with the request, it does not perform the update and
inserts response Code 06 (error) in field 39. V.I.P. inserts a code in Field 48—Additional
Data—Private that identifies the error.
For a description of the information acquirers require in authorization, financial, or reversal

request messages, refer to the pertinent V.I.P. System technical specifications manuals
listed in “For More Information” in this chapter.
18.6 HOW MERCHANT CENTRAL FILE SERVICE (MCFS) WORKS

When V.I.P. receives a request or a reversal, it retrieves the applicable MCF information
and adds it to the designated fields in the message before it forwards it to the issuer.
In some cases, the MCF information replaces, or overlays, existing field information in the
message. The record type and the member's settings in the system tables (that Visa
representatives establish on behalf of the member) determine how V.I.P. adds or overlays

the MCF information and how it maintains the file records. Members update MCF
information in the following ways:
• For all record types except Universal, V.I.P. augments a message by adding MCF data
or by overlaying existing message field values with MCF data. For instance, if a Visa
authorization request comes in with Field 18—Merchant Type containing a merchant type
(merchant category code), and if the MCF for that merchant contains a different merchant
type, V.I.P. replaces the merchant type in the incoming message with the one in the MCF.
• For Universal record types, V.I.P. adds MCF data to the message but does not replace
any existing message field data with MCF data.
Acquirers can set up their merchant files on the basis of record type (card type) by merchant,
or by record type (card type) by merchant terminals. Each merchant or terminal may
support multiple record types such as Visa, MasterCard, and Discover. Acquirers must
establish a separate MCF record for each record type they are using, and must establish a
separate record for each of its merchants or its terminals using that record type.
Figure 18-1 illustrates the structure for an acquirer that establishes record types by
merchant. In addition to Visa cards and MasterCard cards, Merchant A can also accept
Discover and American Express cards. Thus, the acquirer would have four MCF records
for Merchant A, one each for Visa, MasterCard, Discover, and American Express, and all
are keyed to the merchant ID for Merchant A. Merchant B only accepts Visa cards and
MasterCard cards. Thus, the acquirer would have two Merchant Central File records for
Merchant B, one each for Visa and for MasterCard, and both are keyed to the merchant ID
for Merchant B. If the acquirer has 100 merchants accepting only Visa cards, there must be
100 Visa-record-type merchant identification records in the MCF.
Figure 18-1 shows this structure by merchant.
Figure 18-1 Record Type Structure by Merchant (Card Acceptor)

Acquirer
Merchant A Merchant B
Visa American Visa MasterCard

Express
MasterCard Discover

Figure 18-2 illustrates an example structure for an acquirer that establishes record types
by merchant terminal. For Merchant A, there would be four separate MCF records for
Terminal A (Visa, MasterCard, Discover, and American Express), another four MCF records
for Terminal B, and another four for Terminal C. All would be keyed to the merchant ID
for Merchant A.
Figure 18-2 Record Type Structure by Merchant Terminal
Acquirer
Merchant A
terminal A terminal B terminal C
Visa American Visa American Visa American

Express Express Express
MasterCard Discover MasterCard Discover MasterCard Discover
If an acquirer establishes record types by merchant terminal ID, and the merchant has 200
terminals, the MCF must contain 200 different terminal identification records keyed to

that merchant for each card type.
Acquirers have the option of establishing MCF Universal records with both the merchant ID
and the merchant terminal ID as keys. This option requires establishing the same number
of records as establishing records by merchant terminal ID.
18.6.1 Establishing Merchant Central File Augmentation Data

Within the allowable parameters of their designated record types, members decide whether
the MCFS data is to be located using the merchant ID, the merchant terminal ID, or both.
Then they specify which key fields in the authorization and reversal requests are to be used
by V.I.P. to locate the MCFS data and insert it in the requests. Table 18-2 summarizes the
Merchant Central File information available for the different card types.
Table 18-2 MCF Record Types and Data by Card Program
0100 and 0400 Request

Record Type Available For Augmentation Data
Visa Visa Merchant category code for
field 18

Table 18-2 MCF Record Types and Data by Card Program (continued)
0100 and 0400 Request
Record Type Available For Augmentation Data
Universal Visa Merchant category code for
field 18
Merchant name, location, and

country for field 43
Province, ZIP, or postal code

for field 59, positions 6–5
Merchant Verification Value

(MVV) in field 62.20
Universal MasterCard Merchant category code for
field 18

country for field 43

MasterCard MasterCard Merchant category code for
field 18

country, for field 43

American Express and American Express Terminal identification for
Discover field 41
Discover Card acceptor ID for field 42

Check Acceptance Check Acceptance Vendor ID for field 100
18.6.1.1 Merchant Category Code (Field 18)

Acquirers use Field 18—Merchant Type to identify the transaction’s merchant category
code. The Visa International Operating Regulations lists valid codes. Visa publishes
amendments, additions, and changes in VisaNet Business Enhancements Global Technical
Letters and Implementation Guides for members. The Merchant Classification Code
Guideline, available from the Bank Card Division of the American Bankers Association
(ABA), defines the basis for merchant category codes.
18.6.1.2 Merchant Name, Location, Country (Field 43)

Acquirers use field 43 to identify the card acceptor’s geographical location, for instance,
ABC Stores, Seattle, U.S.
18.6.1.3 Card Acceptor Identification Code (Field 42)

Acquirers use field 42 to identify the card acceptor. The field contains an ID that is unique
to that card acceptor.

18.6.1.4 Terminal Identification (Field 41)

Acquirers also use field 41 for an acquirer-defined code identifying the card acceptor’s
ATM or POS terminal.
18.6.1.5 Province, ZIP, or Postal Code (Field 59)

Acquirers use field 59 to identify the card acceptor’s geographical location within its country.
The presence of field 59 depends on the presence of field 43 and on its content. If field 43
contains US or CA (the United States or Canada1), field 59 must contain at least the state
or the province code (in positions 6–15), or the postal code if the field is being used by a
card acceptor outside of Visa U.S.A. or Visa Canada.
18.6.1.6 Merchant Verification Value (Field 62.20)

Field 62.20 contains a value V.I.P. uses to recognize and to authenticate a merchant at an
individual level, and more importantly, to validate the relationship between the merchant and
its Visa member. Visa assigns merchant verification values (MVVs) to specific merchants.
18.6.1.7 Vendor ID (Field 100)

Acquirers use field 100 to identify authorization or reversal request message destinations.
For MCFS, this field identifies check acceptance vendors. An example of a check
acceptance vendor ID is 861400 for TeleCheck. See V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, and V.I.P. System SMS Processing Specifications
(U.S.) for field attributes, format requirements, and additional field information.
18.6.2 Specifying Key Online Message Fields

A MCFS key field in an authorization or reversal request contains an acquirer-defined
merchant identifier used with the acquirer institution ID to point V.I.P. to the correct MCF
augmentation record. Participating acquirers establish key field pointer information through
BIN-level system settings.
Acquirers must specify whether Field 41—Card Acceptor Terminal Identification, or

Field 42—Card Acceptor Identification Code, or both (this option is available only for Visa
or Universal record types), is to be the key field in the 0100 or 0400 request. Acquirers
must notify their Visa representatives which key fields in the authorization request V.I.P. is
to use to locate an MCF record in the database. If the length of the key field is less than the
maximum size of the field (8 bytes for field 41, 15 bytes for field 42), acquirers must specify
the length of those key fields. V.I.P. matches the values in these key fields with the values
of these fields in the MCF. When a match occurs, V.I.P. either adds the data from the MCF
to the authorization request or replaces data that already exists in the request.
Table 18-3 lists the key fields for the different record types. Whether the acquirer can use
one field or the other, or both, depends on the record type. The key identifier length is the
card type’s maximum allowable length for the acquirer’s merchant identification (field 41,
field 42). The maximum merchant identifier for Universal card types is 23 bytes (8 bytes
1. The V.I.P. System internally refers to Canada as CA and uses CA when referring to system code; otherwise,
the abbreviation for Canada is CAN in the V.I.P. documentation.

for field 41 and 15 bytes for field 42). For all other card types, the maximum merchant
identifier length is 15 bytes.
Table 18-3 Key MCF Fields by Record Type for 0100 and 0400 Messages
Record Type Allowable Key Fields Key Identifier Length

Visa Field 41, Field 42, or both 23 bytes
Universal Field 41, Field 42, or both 23 bytes
MasterCard Field 41 or Field 42 15 bytes
American Express Field 41 or Field 42 15 bytes
Discover Field 41 or Field 42 15 bytes
Check Acceptance Field 41 or Field 42 15 bytes
Acquirers cannot set fields 41 and 42 for Visa and Universal data at the same time.
Table 18-4 summarizes the augmentation logic for the different record types.
Table 18-4 MCFS Augmentation Logic by Record Type
Record Type Logic

Visa The key pointer is field 42, field 41, or both, as defined in the system BIN
record. This logic assumes that the defined key pointer field or fields is present
in the request:
• If field 18 is or is not present in the request, and there is MCF data,
MCFS uses the MCC from the MCF record. If there is no MCC in the MCF,
V.I.P. forwards the request as-is to the issuer.
Universal The key pointer is field 42, field 41, or both, as defined in the system BIN record.
Assuming that the defined key pointer field or fields is present in the request:
• If field 18 is also present in the request, MCFS does not change it. Otherwise,
it add the MCC from the MCF record to the request.

• If fields 43 or 59 are also present in the request, MCFS does not change
them. If they are not present, MCFS adds the data from the MCF record to
the request.
• If the field 59 state code or ZIP code is zeros or spaces in the request,
MCFS replaces all of the request's field 59 values with the data from the MCF
record. (MCFS replaces the full field, not individual subfields).
• If fields 18, 43, or 59 are not present in the request, and there is no MCF
data, V.I.P. forwards the request as-is to the issuer.
MasterCard The key pointer is either field 42 or field 41, as defined in the system BIN
record. Assuming the defined key pointer field is present in the request:
• If fields 18, 43, or 59 are or are not present in the request, and there is MCF
data, MCFS uses the MCF data.
• If fields 18, 43, or 59 are not present in the request, and there is no MCF
data, V.I.P. forwards the request as-is to the issuer attached to Banknet.
V.I.P. replaces full fields, not individual subfields.

Table 18-4 MCFS Augmentation Logic by Record Type (continued)

Record Type Logic
American The key pointer is either field 42 or field 41, as defined in the system BIN record.
Express and This logic assumes the defined key pointer field is present in the request:
Discover • If field 41 is or is not present in the request, and there is MCF data,
MCFS uses the MCF data.
• If field 41 is not present in the request, and there is no MCF data,
V.I.P. forwards the request as-is to the issuer.
• For Discover only, if field 41 is present in the request, the value must comply
with the Discover check-digit routine or with MCF data supplied.
• For American Express only, if field 42 is or is not present in the request,
and there is no MCF data, V.I.P. uses a default value. The default value
8995900008.
is 8995900008
V.I.P. replaces full fields, not individual subfields.

Check The key pointer is field 42 or field 41, as defined in the system BIN record.
Acceptance This logic assumes the key pointer field is present in the request:
• If field 41 is or is not present, and there is MCF data, MCFS adds the card
acceptor terminal ID from the MCF record.
• If field 100 is or is not present in the request, and there is MCF data,
MCFS adds the vendor ID from the MCF record to the request.
• If there is no MCF data for field 41 and for field 100, V.I.P. forwards the
message as-is to the Check Acceptance Gateway.
NOTE:
The Check Acceptance Service is a U.S. region-only service.
Figure 18-3 shows how an acquirer might use MCFS to insert a merchant category code
in Visa-record-type authorization requests. The acquirer has previously specified that
the value in field 42 in the authorization or reversal request will always be 5 characters
in length. V.I.P. matches the value in field 42 (up to 5 characters in length) to the

corresponding field 42 five-character value in the MCF record. When a match occurs,

V.I.P. copies the merchant category code 9999 from the MCF record to Field 18—Merchant
Type in the request.
Figure 18-3 How V.I.P. Inserts an MCF Value in a Visa Card Type Request
System Table Merchant Central File Record
Acq ID: 7777 Key: Fld 42 length = 5 Acq ID: 7777: Merchant ID = 12345 (5 bytes)
Record Type = Visa Merchant Type = 9999
VIC receives Field 18 not present Field 18 = 9999

0100/0400 Field 32, Acq ID = 7777 to
Field 32, Acq ID = 7777
from MCFS Issuer
Field 42 = 12345 Field 42 = 12345
participant...
Figure 18-4 shows how V.I.P. inserts a merchant type (that is, a merchant category
code) and a merchant name and location in a Universal-card-type authorization request.
The acquirer has specified that the value in field 42 and in field 41 will always be the
merchant identification and a terminal identifier, and that this combined identifier will always
be 21 characters in length (the maximum length allowed is 23 bytes; 8 bytes for field 41,
15 bytes for field 42). V.I.P. matches the request's acquirer ID and the field 41 and field 42
values to the corresponding values in the correct MCF record. When a match occurs,
V.I.P. copies the MCF information to field 43 in the request.
Figure 18-4 How V.I.P. Inserts an MCF Value in a Universal Card Type Request
System Table
Merchant Central File Record
Acq ID: 7777 Key: Fld 41 length = 6 bytes Merchant ID= 123456789012345678 (21 bytes)
Fld 42 length = 15 bytes
Record type = Universal Merchant Type= 9999
Field 43 = anynameloc
VIC receives Field 18 not present Field 18 = 9999

0100/0400 Field 32, Acq ID = 7777 Field 32, Acq ID = 7777 to
from MCFS Field 41 and 42 = Field 41 and 42 = Issuer
participant... 123456789012345678 123456789012345678
Field 43 not present Field 43 = anynameloc

Figure 18-5 illustrates how V.I.P. replaces existing data in a request with MCF data.
All record types except Universal allow MCFS to overlay data.
Figure 18-5 How V.I.P. Substitutes an MCF Value in a Visa Card Type Request
System Table Merchant Central File Record
Acq ID: 7777 Key: Fld 42 length = 15 bytes Merchant ID= 123456789012345 (15 bytes)
Merchant Type= 9999

Record type = Visa
VIC receives Field 18 = 5999 Field 18 = 5697

0100/0400 Field 32, Acq ID = 7777 Field 32, Acq ID = 7777 to
from MCFS Field 42 = Field 42 = Issuer
participant... 123456789012345 123456789012345
18.6.3 Updating MCFS Records Online

Acquirers use 0300 file update messages to add, change, or delete merchant or merchant
terminal IDs in the MCF. The system expects to find the update message's merchant ID in
the field specified in the system tables, that is, in field 41, in field 42, or in both (Universal
format). The actual data to be added, changed, or deleted resides in Field 127—File
Record(s): Action and Data.

18.6.3.1 File Content
As illustrated in the following figure, the Merchant Central File organizes records by acquirer
institution ID and by merchant identification.
Acquiring Acquiring <---These first fields are common to all Merchant Central File records.
Institution Institution Merchant
ID Length ID Record Type
Presence of these fields depends on record type:
Merchant
Name,
Purge Merchant Location, Postal Update Effective
Date Merchant ID Type Country Terminal ID Vendor ID Zone Time Time

Table 18-5 summarizes the fields within a record.
Table 18-5 Merchant Central File Record Fields
Record
Record Type Field Description 0100/0400 Fields 0300 Fields
Visa, American Acquiring Function: key identifier Not applicable; resides n/a; resides in the
Express, Check Institution ID in the MCF MCF
Acceptance, Length Number of digits in the acquiring
Discover, institution ID.
MasterCard
Visa, American Acquiring Function: key identifier Field 32—Acquiring Field 32—Acquiring
Express, Check Institution ID Institution Identification Institution
Acceptance, (Acquiring The 4- to 11-digit acquiring Code Identification Code
Discover, BIN) institution ID. (It is usually 6 digits.)
MasterCard This field along with the merchant
identification field constitutes the
MCFS file key.
Visa, American Merchant Function: file maintenance n/a; resides in the MCF Field 127M.1—Format 2,
Express, Check Record Merchant Record
Acceptance, Type The 1-character code identifying Type
Discover, the card program. The values are:
MasterCard
A—Check Acceptance
D—Discover
M—MasterCard
V—Visa
X—American Express
Visa, American Purge Date Function: file maintenance n/a; resides in the MCF Field 73—Date, Action
Express, Check
Acceptance, The date after which VisaNet
Discover, removes the record. The format
MasterCard is MMDDYY. The date 999900
means an indefinite purge date.
Visa, Universal, Merchant Function: key identifier Field 41—Card Field 41—Card
American Express, Identifier Acceptor Terminal Acceptor Terminal
Check Acceptance, A unique 1- to 15-digit code for Identification Identification
Discover, the acquirer BIN's merchant or
MasterCard merchant's terminal. This field Field 42—Card Field 42—Card
along with the acquiring institution Acceptor Identification Acceptor Identification
ID constitutes the MCFS file key. Code Code
Depending on the card type,
field 41, field 42, or both, can Field 127M.2—Format 2,
contain the identifier. Merchant Data 1
In 0300 file update messages,

the identifier to be added,
changed, or deleted is in
Field 127M.2—Format 2,
Merchant Data 1.

Table 18-5 Merchant Central File Record Fields (continued)

Record
Record Type Field Description 0100/0400 Fields 0300 Fields
Visa, Universal, Merchant Function: augmentation data Field 18—Merchant Field 127M.2—Format 2,
MasterCard Type Type Merchant Data 1
The 4-digit merchant category
code associated with the merchant
identifier.
American Express, Replacement Function: augmentation data Field 41—Card Field 127M.2—Format 2,
Discover Terminal ID Acceptor Terminal Merchant Data 1
The 1- to 15-character terminal Identification
identification replacement value
in field 41 or field 42 of the Field 42—Card
authorization request. V.I.P. adds Acceptor Identification
the identifier to the request Code
before STIP-or-issuer routing.
V.I.P. reinstates the original
value in field 41 or field 42 of the
response.
Universal, Card Function: augmentation data Field 43—Card Field 127M.3—Format 2,
MasterCard Acceptor Acceptor Merchant Data 2
Name, The 40-digit merchant identifier Name/Location
Location, that comprises a 25-digit card Field 127M.4—Format 2,
Country acceptor name, 13-digit city name, Merchant Data 2
and 2-digit country code.
Check Acceptance Vendor ID Function: augmentation data Field 100 Field 127M.3—Format 2,
Merchant Data 2
A 1-character alphanumeric code
assigned to the vendor.
Universal, Postal Zone Function: augmentation data Field 59, positions 6–15 Field 127M.3—Format 2,
MasterCard Merchant Data 2

An alphanumeric 9-character
postal code.
Universal, Visa Merchant Function: augmentation data Field 62.20 Field 127M.5,
Verification Format 2, Merchant
Value An alphanumeric 10-character Data 2
MVV code.
18.6.3.2 Field 127 Merchant File Update Fields

For MCFS, field 127 comprises four subfields for online MCF updating. Subfield 127M.1
identifies the record type. Depending on the record type, subfields 127M.2 through
subfield 127M.4 contain the data for the MCF.
Field 127M.1—Format 2, Merchant Record Type

Acquirers use this subfield in 0300 file maintenance requests for all of the record types.
The subfield contains a code identifying the record type for the subsequent update data.
The codes are:
A—Check Acceptance
D—Discover
M—MasterCard

U—Universal
V—Visa
X—American Express
Field 127M.2—Format 2, Merchant Data 1

This subfield contains data MCFS is to add change in the MCF for the different record types:
• Check acceptance: 15-digit vendor-assigned terminal ID
• Discover: 15-digit Discover terminal ID
• MasterCard: 4-digit merchant category code
• Universal: 4-digit Visa merchant category code
• Visa: 4-digit merchant category code
• American Express: 15-digit American Express terminal ID

This field contains additional data MCFS is to add or change in the MCF for the different
record types.
• Check acceptance: 1-position check acceptance vendor ID, left-justified and space-filled.
Refer to the field 127M.3 field description in V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, for a list of check acceptance vendors.
• Discover: Not applicable.
• MasterCard: 40-digit card acceptor name/location, as follows. All subfields must be
present.
Subfield 127M.3.1 Subfield 127M.3.2 Subfield 127M.3.3

25-digit card acceptor name 13-digit city name 2-digit country code
• Universal: 40-digit card acceptor state, country, or ZIP code, as follows. All subfields
must be present.

• Visa: n/a.
• American Express: n/a.

This field contains additional data MCFS is to add or change in the Merchant Central
File for the different record types:
• Check acceptance: n/a.
• Discover: n/a.
• MasterCard: 40-digit card acceptor name/location as follows:

• Visa: n/a
• American Express: n/a
• Universal: 16-digit card acceptor state, country, ZIP, or province code, as shown in
Table 18-6.
Table 18-6 Field 127M.4 Universal Format Data Requirements
Subfield Content
127M.4.1 For all record types except M (MasterCard), this subfield contains a 2-digit
field length.
For MasterCard, this subfield contains a 25-digit card acceptor name.

127M.4.2 If the country code is US (United States) and the record type is not M,
this subfield contains the 2-digit numeric state code.
If the country code is CA (Canada1) and the record type is not M, this subfield
contains the 2-digit numeric province code.
If the country code is not US or CA and the record type is not M, this subfield
contains a 1- to 14-digit alphanumeric postal code.
If the record type is M (MasterCard), this subfield contains the 13-digit city
name.
127M.4.3 If the country code is US (United States) and the record type is not M,
this subfield contains the 3-digit numeric country code.
If the record type is M (MasterCard), this subfield contains the 2-digit

alphanumeric country code.
Otherwise, this subfield does not apply.

127M.4.4 If the country code is US (United States), this subfield contains the 5- or 9-digit
numeric ZIP code.

Otherwise, this subfield does not apply.
127M.5 This subfield contains the 10-character alphanumeric merchant verification
value.
Acquirers omit field 127M.5, format 2, when it does not apply.
1. The V.I.P. System internally refers to Canada as CA and uses CA when referring to system code; otherwise, the
abbreviation for Canada is CAN in the V.I.P. documentation.
18.6.4 Updating Merchant IDs for Visa, American Express, MasterCard, and Check
Acceptance Record Types
Updating merchant IDs using file update messages involves field 41, field 42, or both.
Field 41 is an 8-byte field and field 42 is a 15-byte field. Both are left-justified and are
space-filled after the value itself. When acquirers use file update messages to update
merchant IDs, acquirers store the ID value in the MCF and specify the key field in the
system tables.
18.6.4.1 Using Field 41 Only

If acquirers use field 41 only for the merchant ID, the system removes all of the spaces to the
right of the value, right-justifies the value, and fills the field to the left of the value with zeros.

If, in a file update message, field 41 contains 1234bbbb (where b = space),
00000000000000000001234.
the resulting key is 00000000000000000001234

If acquirers use field 42 only for the merchant ID, the system removes all of the spaces to the
right of the value, right-justifies the value, and fills the field to the left of the value with zeros.
If, in a file update message, field 42 contains 123456789bbbbbb (where b = space),
00000000000000123456789.
18.6.4.3 Using Both Field 41 and Field 42

This usage applies to Visa or Universal records only. If acquirers use both field 41
and field 42, the system removes the spaces to the right of the values (as described
above), and then concatenates the remaining values so that they are contiguous. V.I.P.
right-justifies the value that spreads across both fields and fills the remainder to the left with
zeros to achieve a maximum of 23 bytes.
123456789bbbbbb,
If field 41 contains 123456bb and field 42 contains 123456789bbbbbb
00000000123456123456789.
Regardless of the system table setting for key fields, if the acquirer spreads the merchant ID
across field 42 and field 41 and sends both fields in a file update message, the system
assumes that both fields are part of the key.
If both fields' concatenated value is 15 digits or less, V.I.P. stores the concatenated value
in the MCFS table and associates it with the key field specified in the system tables.
For instance, if the system table setting is field 42, then V.I.P. would insert the combined
value of field 42 and field 41 in the file update message into field 42.
If the result is more than 15 digits, V.I.P. uses only the value in the field specified in the
system tables as the merchant ID and ignores the other field value. For instance, if the
system tables specify field 41, then V.I.P. stores only field 41 in the 0300 message in the
MCFS table and discards the field 42 value.
18.6.5 Updating Merchant IDs for Universal Record Types

For Universal records, the merchant ID field is 23 bytes in length, and it includes field 41,
field 42, or both. Acquirers can set field 41, field 42, or both, in the system tables as the
match fields for authorization or reversal requests.

This is an 8-byte, left-justified field that acquirers space-fill after the value itself. If acquirers
use field 41 only for the merchant ID, the system right-justifies the value and any spaces,
and fills the field to the left of the value with spaces.
If, in a file update message, field 41 contains 1234bbbb (where b = space),
bbbbbbbbbbbbbbb1234bbbb.
the resulting key is bbbbbbbbbbbbbbb1234bbbb


This is a 15-byte, left-justified field that acquirers space-fill after the value itself. If acquirers
use field 42 only for the merchant ID, the system left-justifies the value including any
subsequent spaces, and fills the remainder of the field with spaces.
123456789bbbbbbbbbbbbbb.
the resulting key is 123456789bbbbbbbbbbbbbb
18.6.5.3 Using Both Field 41 and Field 42

If acquirers use both field 41 and field 42, the system prepares each field (as described
above), placing the field 42 value ahead of the field 41 value.
123456bb,
If field 42 contains 123456789bbbbbb and field 41 contains 123456bb
123456789bbbbbb123456bb.
the resulting key is 123456789bbbbbb123456bb
18.6.6 Updating Merchant IDs for Discover Record Types

For Discover records, the merchant ID field is 23 bytes in length and can reside in field 41
or in field 42. Acquirers can set field 41 or field 42 in the system tables as the match
fields for authorization or reversal requests.

If acquirers use field 41 only for the merchant ID, the system moves the value to the last
15 bytes of the field beginning at byte 9 and replaces any spaces connected with the value
with zeros. The system then fills the field to the left of the value with zeros.
If, in a file update message, field 41 contains 1234bbb (where b = space),
0000000012340000000000.

If acquirers use field 42 only for the merchant ID, the system moves the value to the last
15 bytes of the field beginning at byte 9 and replaces any spaces connected with the value
with zeros. The system then fills the field to the left of the value with zeros.
00000000123456789000000.
18.7 PROCESS FLOWS

This section contains the process flow and message flow information for MCFS as well
as details about the Merchant Central File (MCF), the database file that V.I.P. uses to
augment authorization or reversal requests with required data.
18.7.1 Processing an Authorization or Financial Request

When V.I.P. receives an authorization, financial, or reversal request from a participating
acquirer, V.I.P. checks the MCF to determine if augmentation data exists for the acquirer.
To perform this process, V.I.P. matches the acquirer institution ID and the merchant
terminal ID or merchant ID (or both) in the request to those in the MCF.
If V.I.P. finds a match, it adds or replaces the necessary information from the MCF to the
request message before it sends it to the issuer or to STIP for processing.

Figure 18-6 illustrates the MCFS process flow.
Figure 18-6 MCFS Process Flow
Merchant
Central
File
The acquirer sends the V.I.P. tries to match key The issuer provides an
authorization or reversal merchant information in the appropriate authorization
request to the issuer. request to the Merchant or reversal response.
Central File. When it finds
a match, V.I.P. adds the
necessary information to
the request.
V.I.P. forwards the issuer’s

response to the acquirer.
For transactions eligible for the MCFS Universal Service, if the field to be augmented
already exists in the message, V.I.P. does not change the information (except for that in
Field 59—National Point-of-Service Geographic Data). If field 59 is present but contains
zeros or blanks, V.I.P. considers field 59 as not being present and replaces the entire field
using the MCF data (if available).
NOTE
When applicable, V.I.P. does an all-inclusive field replacement, which comprises all subfields.
Depending on the type of card transaction, MCFS provides the information (in Table 18-7),
which the following example describes.
EXAMPLE
If an acquirer’s terminals cannot supply the merchant category codes for Visa transactions, the acquirer can
place those codes in the MCF. When the VIC receives a Visa card authorization or reversal request from
one of these terminals, V.I.P. adds the MCF merchant category code (MCC) to the request or replaces it
before routing the request to the issuer.
Table 18-7 Information Supplied by MCFS
Type of Transaction MCFS Action

Visa Card Adds or replaces the merchant category code
(MCC).

Table 18-7 Information Supplied by MCFS (continued)

Type of Transaction MCFS Action
MasterCard Adds or replaces the merchant postal code
(for non-U.S. regions) or the ZIP code (for the
U.S. region) and the MCC.
Check Acceptance Adds or replaces the vendor ID and the
merchant terminal ID.
American Express and Discover Replaces the merchant terminal ID with the
American Express merchant terminal ID or the
Discover merchant terminal ID, as appropriate.
(See “Terminal Translation Feature” in this
chapter for more information.)
Universal Service Adds the MCC, the merchant verification value
(MVV), the card acceptor name and location,
the province code (for Canada), and the postal
code (for non-U.S. regions) or the ZIP code
(for the U.S. region), as appropriate.
NOTE:
V.I.P. adds MCFS information only if the
equivalent information does not appear in a
request.
18.7.2 Processing MasterCard Requests

For MasterCard authorization requests, V.I.P. uses Field 41—Card Acceptor Terminal
Identification or Field 42—Card Acceptor Identification Code as a key to search the MCF.
When constructing MasterCard-compatible messages, however, V.I.P. uses whatever
field 41 value it receives. If the acquirer does not provide field 41, it does not appear in
the corresponding MasterCard message.

18.7.3 Terminal Translation Feature
The terminal translation feature replaces or adds the Discover or American Express
merchant terminal ID in the authorization or reversal message before V.I.P. forwards the
request to the issuer.
When V.I.P. does not find the merchant terminal ID in the authorization or reversal request
message in the MCF, it performs special processing, which the following subsections
describe.
NOTE
The terminal translation feature does not apply to Visa, MasterCard, or check acceptance transactions.
18.7.3.1 American Express Requests

For American Express authorization or reversal requests, V.I.P. replaces the card
acceptor ID (in field 42) with the terminal ID in the MCF, if available. If the MCF does not
contain the acquirer's data and the original message does not contain field 42, V.I.P. adds
the merchant terminal ID in the authorization or reversal request using the American
Express default terminal ID before it sends the request to the American Express Gateway.

• If field 42 is present in the message (either from the acquirer or from the MCF) and
is numeric, V.I.P. performs check-digit validation.
93, V.I.P. performs check-digit validation using
- If the first two digits of field 42 are 93
positions 1–10 of field 42.
- If the first two digits are not 9393, V.I.P. performs check-digit validation using
positions 2–10 of field 42.
If the check digit is valid, V.I.P. replaces the last five digits of field 42 with spaces. If the
check digit is not valid, V.I.P. replaces field 42 with the default terminal ID.
• If field 42 is present in the message (either from the acquirer or from the MCF) but is
not numeric, V.I.P. replaces the value in field 42 with the default terminal ID.
If Field 100—Receiving Institution Identification Code is present in the authorization or
reversal request, V.I.P. does not perform MCFS augmentation.
When V.I.P. returns the response message, it reinstates the original value in field 42.
18.7.3.2 Discover Requests

For Discover authorization or reversal requests:
• If the acquirer supplies a numeric 15-digit value in field 42 and the first five positions
60110, V.I.P. performs check-digit validation using positions 6–15 of field 42.
equal 60110
If the check-digit validation fails, V.I.P. replaces the card acceptor ID (in field 42) with
the terminal ID in the MCF, if available. If the Discover card acceptor ID contains a valid
check digit, V.I.P. does not perform MCFS augmentation.
• If the acquirer supplies a short-form numeric value in field 42 (for instance, the first
12 positions are numeric followed by spaces) and the first two positions equal 60 60,
V.I.P. performs check-digit validation using positions 3–12 of field 42.
If the check-digit validation fails, V.I.P. replaces the card acceptor ID (in field 42) with
the terminal ID in the MCF, if available. If the Discover card acceptor ID contains a valid
check digit, V.I.P. reformats the 12-digit value to a 15-digit value by setting the first five
positions of field 42 to 60110 and moving positions 3–12 of the original card acceptor ID
to field 42 beginning at position 6.
• If field 42 does not contain a 15-byte numeric field 42 or a short-form field 42,
V.I.P. replaces the card acceptor ID (in field 42) with the terminal ID in the MCF,
if available.
If V.I.P. finds no MCF record, and no card acceptor ID is present in the message,
V.I.P. returns a reject response code to the acquirer.
When V.I.P. returns the response message, it reinstates the original value in field 42.

18.8 MESSAGE FLOWS

Figure 18-7 illustrates the MCFS message flow. When the acquirer submits 0100, 0200, or
0400 requests, V.I.P. augments the request with MCF data and returns the appropriate
0110, 0210, or 0410 response messages from the issuer (or from STIP) to the acquirer.
Figure 18-7 MCFS Message Flow
Acquirer V. I.P. Issuer
Merchant
Central
File
0100, 0200, or 0400 0100, 0200, or 0400 0100, 0200, or 0400

Request Request Request
Field 18: Merchant Type Field 18: Merchant Type Field 18: Merchant Type
Field 32: Acquirer BIN Field 32: Acquirer BIN Field 32: Acquirer BIN
Field 41: Card Acceptor Field 41: Card Acceptor Field 41: Card Acceptor
Terminal ID Terminal ID Terminal ID
Field 42: Card Acceptor ID Field 42: Card Acceptor ID Field 42: Card Acceptor ID
Field 43: Card Acceptor Field 43: Card Acceptor Field 43: Card Acceptor
Name/Location Name/Location Name/Location
Field 59: National POS Field 59: National POS Field 59: National POS
Geographic Data Geographic Data Geographic Data
Field 100: Vendor ID Field 62.20: Merchant Field 62.20: Merchant
Verification Va lue Verification Value
Field 100: Vendor ID Field 100: Vendor ID
0110, 0210, or 0410 0110, 0210, or 0410 0110, 0210, or 0410

Response Response Response
Field 39: Response Code Field 39: Response Code Field 39: Response Code

This section lists and describes key fields associated with MCFS. A subsection of key fields
related to updating the Merchant Central File follows the MCFS field listings.

Field 18—Merchant Type

This field appears in 0100, 0200, or 0400 requests and contains a code describing the
merchant's type of business product or service. Refer to the Visa International Operating
Regulations and to the Visa International Certificate of Incorporation and By-Laws, as
amended by additions and changes published in VisaNet Business Enhancements and
Technical Letters for members, for lists of valid codes.
If the value in field 91 is 1 or 2 in an 0300 request, VisaNet requires field 18 for Visa
transactions and it must include the merchant's type. If field 18 does not appear in the
authorization, financial, or reversal request, V.I.P. adds the information using MCF data,
if available. For Visa and MasterCard transactions, if field 18 is present, V.I.P. replaces
the value using the data in the MCF, if available.
Field 32—Acquiring Institution Identification Code

For MCFS 0100, 0200, or 0400 requests, field 32 must contain a valid 6- to 11-digit Visa
BIN, as listed in the system files. V.I.P. uses field 32 and the merchant ID, the merchant
terminal ID, or both, to match the authorization, financial, or reversal message to the
applicable record in the MCF.
NOTE
Acquirers also use field 32 in 0300 requests for MCF updates.
Field 41—Card Acceptor Terminal Identification

This field appears in 0100, 0200, or 0400 requests and contains a code that identifies
the card acceptor terminal or the ATM. V.I.P. uses field 32 and the merchant ID,
the merchant terminal ID, or both, to match the authorization, financial, or reversal
message to the applicable record in the MCF.
For electronic POS terminals, when the ID is not unique to a specific terminal, acquirers
can use field 42 along with this field. ATM terminal IDs must be unique within the
acquirer's network, depending on the type of card transaction.

NOTE
Field 42—Card Acceptor Identification Code

This field appears in 0100, 0200, or 0400 requests and contains the 1- to 15-digit
code that uniquely identifies the merchant. V.I.P. uses field 32 and the merchant ID,
the merchant terminal ID, or both, to match the authorization or reversal message to
the applicable record in the MCF.
For check acceptance, American Express, and Discover authorization, financial, or

reversal transactions, V.I.P. replaces the value in field 42 with data from the MCF,
if available and applicable.
NOTE

Field 43—Card Acceptor Name/Location

Field 43 contains the name and the location of the card acceptor (such as the merchant
or the ATM), including the city name and the country code. When the point of service
(or card acceptor) is not in the same country as the acquirer processor, this field must
identify the point-of-service country. (This field identifies the merchant or the ATM
location.)
Field 43 appears in ATM 0100 requests and balance inquiries and in all ATM
confirmations. If it appears in the original request, it is required in any subsequent 0400
reversal. Issuers do not include it in 0110 or 0410 responses.
Field 59—National Point-of-Service Geographical Data

This field appears in 0100, 0200, or 0400 requests and contains a national-use field
to identify an intra-country geographical location in a request. V.I.P. uses this field to
indicate the location of a customer transaction within the country of the card acceptor.
Field 59 contains:
Acceptors—This identifier is a numeric state code, a numeric ZIP code,

U.S. Card Acceptors—
or both.
Acceptors—This identifier is a numeric province code, an alphanumeric

Canadian Card Acceptors—
postal code, or both.
Canada—This identifier is a 1- to 14-position

Card Acceptors Outside the U.S. or Canada—
alphanumeric postal code.
Field 62.20—Merchant Verification Value

Field 62.20 appears in 0100, 0200, or 0400 requests and contains a value V.I.P.
uses to recognize and to authenticate a merchant at an individual level, and more
importantly, to validate the relationship between the merchant and its Visa member.

Visa assigns merchant verification values (MVVs) to specific merchants. An MVV
consists of 10 alphanumeric characters, with fixed and variable components. The first
six characters are fixed and Visa assigns them. Acquirers use the last four characters
for specific merchant locations and they assign them in combination with Visa. Valid
values are 0–9 9 and A–FF.
IMPORTANT
Acquirers must provide the MVV in all authorization, clearing, and exception-item messages if the
merchant has an MVV assigned. Issuers must retain and return the MVV in all exception items.
Field 100—Vendor ID (Check Acceptance)

Field 100 appears in 0100, 0200, or 0400 requests for check acceptance records and
identifies the check acceptance vendor. The vendor ID represents one of six companies
that can approve a check used at a merchant location.
18.9.1 Key Fields Glossary for Merchant Central File Updates

Members use the following fields to update the MCF.

NOTE
Field 32, field 41, and field 42 also apply to messages updating the MCF. Refer to “Key Fields Glossary” in
this chapter for their descriptions.
Field 73—Date, Action

Field 73 appears in 03xx messages to indicate the date when VisaNet is to remove the
MCF record from the file. The purge date is in YYMMDD format.
If the file update code is 3 (delete), field 73 must not be present.
A date of 999900 indicates that VisaNet is not to purge the record.
Field 91—File Update Code (Format 2)

This field contains a code that specifies the type of file processing required for the 0300
message. Table 18-8 lists valid codes.
Table 18-8 Field 91 File Update Codes
Code Definition Explanation

1 Add Add a new record only if one does not already exist.
2 Change Change an existing record.
3 Delete Delete an existing record.
4 Replace VisaNet no longer supports this value.
5 Inquire Send a copy of an existing record.
If the file update request contains update code 4 in field 91, V.I.P. rejects the transaction
0568—Invalid Value in Field 127—Format 1: File Maintenance.
with Error Code 0568
Field 101—File Name

This field contains a code identifying the VIC-resident cardholder or the merchant file
V.I.P. is to access by a file update or inquiry (03xx message), and the update or inquiry
request format. Visa designates code M9 for format 2 MCF update requests.
Field 127M.1—Format 2, Merchant Record Type

This field appears in 03xx messages and contains a code indicating the type of MCF
record V.I.P. is to add, change, or delete. This code determines the content and the
format of the remainder of field 127. V.I.P. returns field 127M.1 in responses. The valid
values include:
• A = Check Acceptance
• D = Discover
• M = MasterCard
• U = Universal Visa Data
• V = Visa
• X = American Express


This field appears in 03xx messages and contains the merchant terminal ID,
the merchant category codes, or both for 0300 add, and change requests. V.I.P. returns
field 127M.2 in 0310 responses. The field does not appear in delete requests or in
file inquiries.
The length and content of field 127M.2 depends on the record type that appears in
field 127M.1. Also, the length and content of field 127M.2 depend on the merchant’s
type value that appears in field 18.
Depending on the type of card transaction, the following field requirements apply:
MasterCard—Field 127M.2
American Express, Discover, Visa, Check Acceptance, and MasterCard—
must appear in an 0300 request (except for check acceptance requests) if the code in
Field 101—File Name is M9 and the code in Field 91—File Update Code is 1 or 2
(add or change).
Format—Field 127M.2 appears if the code in field 101 is M9

Universal Data Format— M9, and the
code in field 91 is 1 or 2. Field 127M.2 (if supplied) must contain a valid merchant
category code. If the acquirer does not supply field 127M.2, it must supply a value
for field 127M.3 or field 127M.4. If the acquirer does not supply field 127M.3 and
field 127M.4, it must supply field 127M.2. The length of field 127 should be 5.
Visa and Universal Data—

Data—Acquirers must supply a valid merchant category code (MCC).
If the code in field 91 is 3 or 5, field 127M.2 should not appear in the message.

This field appears in 03xx messages and contains the postal code (for non-U.S. regions)
or the ZIP code (for the U.S. region), or the card acceptor name, city, and country code,
or a vendor ID. When present in a request, V.I.P. returns the field in the response.

The field does not appear in delete requests or in file inquiry requests.
Visa—This field does not apply for format 2 requests.

American Express, Discover, and Visa—
MasterCard—This field appears in 0300

Check Acceptance, Universal Data, and MasterCard—
format 2 add or change requests for the MCF.
The length and the content of field 127M.3 depend on the merchant’s type value in
field 18.

Field 127M.4, Format 2, Merchant Data 2

This field appears in 03xx messages and contains the national point-of-service
geographic data (for Universal transactions) or the card acceptor name and location
(for MasterCard transactions). Acquirers do not use this field in delete requests or in file
inquiry requests. Field 127M.4 could appear in a successful response.
Acceptance—This field does not apply.

American Express, Discover, Visa, and Check Acceptance—
Data—This field appears in 0300 format 2 add or change requests for the
Universal Data—
MCF. V.I.P. omits this field when it is not applicable. If present, the acquirer must supply
all of the subfields.
MasterCard—V.I.P. omits this field when it is not applicable. If present, the acquirer
MasterCard—
must submit all of the subfields (127M.4.1, 127M.4.2, and 127M.4.3). The country code
must be a valid 2-digit alphanumeric code.
Field 127M.5, Format 2, Merchant Data 2

This field appears in 03xx messages and contains the merchant verification value for
Universal transactions. Acquirers do not use this field in delete requests or in file inquiry
requests.
Data—This field appears in 0300 format 2 add or change requests for the
Universal Data—
MCF. V.I.P. omits this field when it is not applicable. The 0300 requests are able to
receive merchant verification values independent of the merchant data in field 127M.2
and in field 127M.4.

For further information about MCFS or about the Merchant Central File, refer to the
following documentation:
• VAP Operator's Guide
• VAP Interface Specifications: V.I.P. Processing

• V.I.P. System SMS ATM Technical Specifications, Volume 1 and Volume 2
and Volume 2

Part 7 Authorization Services
Part 7, Authorization Services, describes V.I.P. services that process authorization request
messages. These include:
Chapter 19—Account Verification Service
Chapter 20—Address Verification Service (AVS)
Chapter 21—Advice Retrieval Service—BASE I
Chapter 22—Advice Retrieval Service—SMS
Chapter 23—ATM Format Conversion Service
Chapter 24—Card Verification Value (CVV) Service
Chapter 25—Card Verification Value 2 (CVV2) Service
Chapter 26—Cardholder Authentication Verification Value (CAVV) Verification Service
Chapter 27—Custom Payment Service (CPS)/ATM
Chapter 28—Custom Payment Service (CPS)/POS
Chapter 29—Deferred Clearing Advice File (DCAF) Service
Chapter 30—Dynamic Key Exchange (DKE) Service
Chapter 31—International Automated Referral Service (IARS)
Chapter 32—Multicurrency Service
Chapter 33—PIN Verification Service (PVS)
Chapter 34—POS Check Service
Chapter 35—Positive Authorization Capacity Management (PACM) Service
Chapter 36—Positive Cardholder Authorization Service (PCAS)
Chapter 37—Preauthorized Payment Cancellation Service (PPCS)
Chapter 38—Status Check Service
Chapter 39—Visa Cashback Processing: VisaNet Cash Back Service


Chapter 19 Account Verification Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
IN BRIEF 19-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
HOW ACCOUNT VERIFICATION SERVICE WORKS

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
19-55
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
PROCESS FLOWS 19-66
MasterCard AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-
10
Account Verification Service


Chapter 19 Account Verification Service
19.1 IN BRIEF
The Account Verification Service enables merchants to request an account number
verification as an initial check for an estimated purchase. V.I.P. supports requests for
account number information through the Account Verification Service.
The Account Verification Service is available to members in all Visa regions.
BASE I
SMS The Account Verification Service is available both to BASE I System users and
to Single Message System (SMS) users.

BASE I and SMS
Participation in the Account Verification Service is mandatory for acquirers in

A the Visa U.S.A. (U.S.) region. The service is optional for acquirers in all other
Visa regions. All participating acquirers must successfully complete testing to
receive and to send account verification request messages.
Acquirer

The Account Verification Service provides:
• Chargeback protection for below-floor-limit transactions.
• Modulus-10 checking.
• Exception file checking.
NOTE
A merchant's floor limit is an amount limit set by the acquirer (subject to Visa U.S.A. and Visa International
Operating Regulations maximums) that determines if VisaNet authorization is needed to complete a
transaction. V.I.P. only processes transactions above a merchant’s floor limit. Transactions at or below the
floor limit do not require authorization processing.
The service replaces the manual process of checking paper card recovery bulletins.
Instead of using a paper bulletin, the merchant contacts its acquirer to initiate an account
verification request. Refer to Chapter 11, Card Recovery Bulletin (CRB) Service, in
Volume 1, for information about bulletins.

Using an 0100 authorization request message, merchants can request:

• Account verification only, to perform an initial check for an estimated purchase.
• Account verification and authorization, to request authorization when the transaction
takes place at the point of sale or the point of service (POS).

Participation in the Account Verification Service is mandatory for U.S. acquirers.
The service is optional for acquirers in all other Visa regions.
19.4.1 Testing
Testing is required for participation in the Account Verification Service. Acquirers must
successfully complete testing to send and to receive account verification request messages.
The VisaNet Certification Management Service (VCMS) provides testing assistance for
Account Verification Service participants. Members can contact their Visa representatives
to make the arrangements.

Visa does not require service monitoring before participation in the Account Verification
Service.

The following messages pertain to the Account Verification Service.
Request—This message supports several functions related to

0100: Authorization Request—
authorization and to verification of a card or customer transaction. The issuer, if available,

verifies that the:
• Account is an actual issued account.
• Check digit is valid.
• Account is open.
• Account is not in lost or stolen status.
NOTE
Additionally, the issuer must provide validation results for address verification and Card Verification Value 2
(CVV2) processing if the acquirer requests these results in the request message, unless the issuer chooses to
have V.I.P. perform these functions on its behalf.
If the issuer is not available, STIP checks the account in the 0100 request message
to determine if the check digit is valid, and if the account is listed in the Exception File.
If the message requests address verification, CVV2 verification, or both, STIP returns
an address verification results code, and, if the issuer has provided Visa with its CVV2
verification keys, a CVV2 verification results code.
NOTE
STIP is not available for MasterCard transactions.
Response—This message is the authorization response.

0110: Authorization Response—

Chapter 19 How Account Verification Service Works
19.6 HOW ACCOUNT VERIFICATION SERVICE WORKS

Merchants can request account verification only or can request account verification with
authorization for a specific amount. A value of 51 in Field 25—Point-of-Service Condition
Code indicates that the request is for account verification only.
For account verification-only status checks, the amount in field 4 must be zero in requests
and their reversals, if:
• Field 3—Processing Code, positions 1–2, contains:
- 39 (eligibility message) for SMS.
- 39 (eligibility message), 70 (PIN change/unblock), or 72 (PIN unblock or prepaid
activation) for BASE I.
• Field 25—Point-of-Service Condition Code contains 51 (zero amount account verification).
zero, V.I.P.
If the 0100 message contains code 51 in field 25, but field 4 does not contain zero
0018—Invalid Value.
rejects the account verification request with Reject Code 0018
If the issuer is available, VisaNet forwards the verification request to the issuer. The issuer
performs normal transaction verification and returns the appropriate response code. If the
issuer finds no negative condition, and the account is in good standing, the issuer returns
response code 85 (no reason to decline) or code 00 (approved). For account verification
purposes, V.I.P. treats both responses in the same manner.
NOTE
Visa Europe Authorisation Services can send 0100 account verification messages that contain Verified by Visa
(VbV) authentication data. V.I.P. authenticates the CAVV and performs standard VbV processing on these
messages before forwarding them to issuers.

If the request message requests address verification, the issuer returns its response
in Field 44.2—Address Verification Results Code, unless it chooses to have V.I.P.
perform this function on its behalf. If the request messages requests CVV2 verification
and the issuer chooses to perform the verification, it returns the verification result in
Subfield 44.10—CVV2 Result Code.
If the issuer is unavailable (either is logged off, or the transaction timed out), V.I.P. forwards
the account verification request to STIP (unless the request is a MasterCard request).
When STIP receives the verification request, it verifies the check digit and checks the
exception file. The exception file is an online file comprised of issuer-supplied cardholder
data, both favorable and unfavorable. Refer to the Cardholder Database Overview chapter
in this volume for information about the exception file.
STIP sends an 0110 response message to the acquirer containing response code 85
(no reason to decline), in Field 39—Response Code, if the card:
• Has a valid check digit.
• Is not listed in the exception file with a negative action code.
• Is listed in the exception file with a positive action code.
STIP returns negative response codes based on invalid check digits or on information that
the issuer lists in the exception file.
If the request message requests address verification:

• If V.I.P. performs address verification on behalf of the issuer, STIP returns the appropriate
results code in Field 44.2—Address Verification Results Code in the response message.
• If V.I.P. does not perform address verification on behalf of the issuer, STIP returns results
code U (address not verified) in field 44.2.
If the request message requests CVV2 verification, and if the issuer has provided Visa with
its CVV2 encryption keys, STIP verifies the CVV2 and returns the result in subfield 44.10.
STIP then creates an 0120 advice message for the issuer with code 2 in
Field 44.1—Response Source/Reason Code, indicating that STIP provided the code.
For general information about advices and about advice creation, refer to the V.I.P. System
Overview. Refer to the pertinent V.I.P. System technical specifications manuals for details
about advice creation. Refer to “For More Information” in About This Manual for a list of
V.I.P. publications.
19.7 PROCESS FLOWS

To obtain account information using the Account Verification Service, the merchant
contacts the acquirer, which submits the verification request to VisaNet. When the issuer
is available, VisaNet forwards the request to the issuer, which processes the request.
When the issuer is unavailable, the V.I.P. System stand-in processor (STIP) processes
the request, sends its response to the acquirer, and depending on issuer-selected options,
creates an advice for the issuer informing the issuer of the request and the response.

Figure 19-1 illustrates the Account Verification Service process and message flow when
the issuer is available.
Figure 19-1 Account Verification Service Process and Message Flow (Issuer Available)
Acquirer V.I.P. STIP Issuer
Exception
File

Field 4: zeros Field 4: zeros Field 4: zeros
Field 25: 51 Field 25: 51 Field 25: 51


Field 44.1: 2 Field 44.1: 2

Figure 19-2 illustrates the Account Verification Service process and message flow when
the issuer is unavailable.
Figure 19-2 Account Verification Service Process and Message Flow (Issuer Unavailable)
Acquirer V.I.P. STIP Issuer
Exception
File
0100 Request 0100 Request Issuer Unavailable

Field 4: zeros Field 4: zeros
Field 25: 51 Field 25: 51
0110 Response 0110 Response

Field 39: Response Code Field 39: Response Code

Field 44.1: 2 Field 44.1: 2
19.7.1 MasterCard AVS

MasterCard requirements differ from Visa’s, and include the following:
• Field 4 can contain zero if Field 123—Address Verification Data is included. Field 4 can
also contain zero if field 123 is present with address data and field 126.10 is present
with CVC2 data.
• If field 126.10 with CVC2 is present but field 123 with address data is not, field 4 cannot
contain a zero amount.
For information about MasterCard account verification, including the complete list of field
requirements, refer to the Credit Gateway Service Cross-Reference Guide.

This section describes key fields associated with the Account Verification Service.

Field 4—Amount, Transaction

zeros. V.I.P. ignores any other value. If the verification
This field should contain all zeros
request is successful, the issuer responds with response code 85 (no reason to decline)
or response code 00 (approved). If STIP performs the verification, it responds with
response code 8585.
Field 25—Point-of-Service Condition Code

This code identifies the transaction conditions at the POS. Field 25 must contain code 51
for Visa card and MasterCard card account verifications. POS condition code 51
indicates a request for account number verification without authorization, or a request
for account number verification and address verification without authorization.

This field contains the issuer response, either response code 85 (no reason to decline)
or response code 00 (approved). If STIP performs the verification, it responds with
response code 85 85. If the issuer performs the verification and finds no negative condition
and the account is in good standing, the issuer returns response code 85 (no reason to
decline) or response code 00 (approved). For unsuccessful verifications, the issuer or
STIP returns the appropriate negative response code.
Response code 85 is not the same as response code 00 (approved). Response code 00
specifically indicates that the transaction is approved. Response code 85 means
only that the issuer or STIP found no specific negative reason for an unsuccessful
verification. However, for account verification purposes, V.I.P. treats both responses in
the same manner.

Field 44.1—Response Source/Reason Code
This field contains code 2 when STIP responds to an account verification request.
Code 2 indicates that the response was provided by STIP because the issuer was
unavailable.
Field 44.2—Address Verification Results Code

The code in this field identifies the result of the address verification process, and
the entity that performs the address verification uses it only in response to address
verification requests. The entity verifying the address (V.I.P., a BASE I or SMS issuer,
or a MasterCard issuer through the Banknet gateway) provides the result code.
If V.I.P. performs address verification, it returns the verification result code in the
response to the acquirer. If requested by the issuer, V.I.P. also includes the code in the
advice sent to the issuer.
If V.I.P. performs address verification but the issuer performs the transaction approval,
V.I.P. includes its results code in field 44.2 when it forwards the response from the
issuer to the acquirer.
If the issuer performs address verification, it inserts the verification result code in
field 44.2 of the response.
If the issuer performs address verification, but STIP performs the authorization process,
the acquirer receives field 44.2 only if the issuer returns it in the response.

Subfield 44.10—CVV2 Result Code

If the issuer has provided Visa with its CVV2 encryption keys, V.I.P. verifies the CVV2
for participating issuers that select the CVV2 ALL processing option and passes
subfield 44.10 to the issuer in the appropriate BASE I and SMS 0100, 0200, 0120,
or 0220 messages. Refer to the CVV2 chapter in this manual for more information.

For further information about the Account Verification Service, refer to the following
documents:
and Volume 2

Chapter 20 Address Verification Service (AVS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
IN BRIEF 20-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4
Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
RELATED MESSAGES
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
20-55
Visa Custom Payment Services (CPS)/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
HOW ADDRESS VERIFICATION SERVICE (AVS) WORKS 20-66
Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7
PROCESS FLOWS
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
20-88
When V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-12
Forwarding AVS Data to Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .20-12
Address Verification Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-12
Address Verification Data Standards. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .20-12
Field 123 Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-13
Data Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-15
Address Verification Service (AVS)

Matching Merchant Address Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
Translating Fixed and TLV Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
Field 123 Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
U.S.-Domestic Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-19
U.K.-Domestic Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-19
All Other Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-19
Result Code Conversion Based on Jurisdiction and Representment
Rights (All Regions Except the U.S. and the U.K.). . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .20-21
Result Code Conversion Based on Acquirer Participation (U.K. and U.S. Only). .20-22
AVS Process Flow Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-23
V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .20-23
When the Issuer Performs Address Verification. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .20-23
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
MESSAGE FLOWS 20-24
24
V.I.P. Performs Address Verification and Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-25

Chapter 20
V.I.P. Performs Address Verification Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-28

Issuer Does Not Support Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-29
Issuer Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-30
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
34
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-
37
Merchant Guide for AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-37

Chapter 20 Address Verification Service (AVS)
20.1 IN BRIEF
The Address Verification Service (AVS) is an online Visa service that enables merchants
to reduce fraud losses by verifying cardholders' billing addresses for card-not-present
(CNP) transactions.
Merchants, acquirers, and issuers can use AVS for Visa, American Express, and Discover
transactions, and for MasterCard point-of-sale (POS) transactions. In the Visa U.S.A.
(U.S.) region, participants can also use AVS for Visa-approved U.S.-issuer proprietary and
private-label transactions.
NOTE
The V.I.P. stand-in processor (STIP) performs address verification for Visa and proprietary and private-label
transactions only.
AVS is available to members in all Visa regions.
BASE I
SMS AVS is available both to BASE I System users and to Single Message System
(SMS) users.
BASE I and SMS

All issuers in the U.S. region must support AVS. All issuers in the United
I Kingdom (U.K.) must support AVS. U.S. and U.K. issuers must successfully
complete testing to receive and to send AVS codes for all products.
Participation in AVS is optional for issuers in all other countries.

Issuer
Participating issuers can choose to perform their own address verifications or
can have the V.I.P. System perform verifications on their behalf.
A Participation in AVS is optional for acquirers in all regions. Acquirers can send
AVS information in any authorization or financial request transaction to VisaNet.
AVS is available to all merchants whose acquirers participate in the service.
Acquirer

For merchants in all regions, AVS provides verification of cardholders' billing addresses
for CNP transactions. To request verification of a cardholder's address, merchants submit
the verification request as:

• Part of an 0100 authorization request.

• Part of an 0200 financial POS purchase request.
• An address verification request only (sent as an 0100 or 0200 message).
When a message requests address verification and authorization, V.I.P. may process the
address verification request separately from the authorization depending on whether V.I.P.
or the issuer performs address verification.
For address verification-only status checks, the amount in field 4 can be zero in requests
and their reversals, if:
• Field 3—Processing Code, positions 1–2, contains:
- 39 (eligibility message) for SMS.
- 39 (eligibility message), 70 (PIN change/unblock), or 72 (PIN unblock or prepaid
activation) for BASE I.
• Field 123—Verification Data is present.
Also, field 4 can be zero in 0302 file update requests. If the request meets all the
verification-only field requirements, and field 4 contains an amount other than zero, STIP
ignores the amount and, if the request is successful, responds with a value of 85 (no
reason to decline) in field 39.
IMPORTANT
When V.I.P. receives an AVS-only account verification request destined for a U.K. issuer that is directly
connected to Visa Europe Authorisation Services, V.I.P. forwards the request to Visa Europe Authorisation
Services, which determines whether the request is to be processed by its stand-in processing system or
forwarded to the issuer.
V.I.P. or the issuer verifies the cardholder address submitted by the merchant. V.I.P. or
the issuer determines the verification response, and V.I.P. forwards the response to the
acquirer.
20.3.1 Service Options

AVS offers participating issuers two choices:
• Issuers can perform their own address verifications or can have V.I.P. perform them on
their behalf. Participating U.S.-domestic issuers can direct V.I.P. to verify the address
but then have the authorization routed to them under issuer-available conditions for
the final authorization decision.
• Issuers can choose not to receive address data or they can receive address data in
full format or in compressed format. (Refer to “Key Fields Glossary” in this chapter for
format descriptions.)
Refer to “How Address Verification Service (AVS) Works” in this chapter for details about
each option.

For issuers and acquirers that want to participate in AVS, the following requirements apply.
20.4.1 Testing
To use the service, testing is mandatory for all acquirers and issuers.

AVS testing ensures that the acquirer can send and can receive AVS fields in
authorization-related messages, and that the issuer can receive them and can respond
with the proper values in AVS fields:
• Field 25—Point-of-Service Condition Code
• Field 44.2—Address Verification Result Code
• Field 123—Address Verification Data
Issuers must supply test account numbers to use in test scripts.
The VisaNet Certification Management Service (VCMS) provides testing assistance for AVS
participants. Members can contact their Visa representatives to make the arrangements
for testing.

Members can contact their Visa representatives regarding service monitoring requirements.
20.4.3 Planning and Implementation

Issuers should review their authorization systems to make sure that they are accepting and
responding properly to AVS requests. Visa recommends that acquirers review their AVS
operations and extend the risk management benefits of the service to all merchants.

The following messages pertain to AVS:
Request—An 0100 authorization request message can include the

address verification request information. Acquirers can also use 0100 messages for
address-verification-only requests. V.I.P. and issuers respond to acquirers' request
messages with 0110 response messages. Acquirers cannot send address verification
requests in incremental authorization requests.
Response—V.I.P. and issuers send 0110 authorization response

messages in response to acquirers' 0100 request messages. The 0110 responses contain
the code identifying the result of the address verification in Field 44.2—Address Verification

Result Code and the authorization response code in Field 39—Response Code.
Advice—An 0120 advice notifies issuers when STIP processes an address

0120: Advice—
verification request on their behalf. If the address verification request includes an
authorization, field 39 contains the authorization response. Field 44.2 contains the address
verification result code. If the request does not include authorization, STIP includes only
the address verification result code in the advice.
Request—An 0200 financial request can include the address verification

0200: Financial Request—
request information. Acquirers can also use 0200 messages for address-verification-only
requests. V.I.P. and issuers send 0210 response messages to acquirers.
Response—V.I.P. and issuers send 0210 financial response

messages in response to 0200 financial request messages. An 0210 response message
contains the address verification result code in field 44.2 and the authorization response
code in field 39.
Advice—An 0220 advice notifies issuers when V.I.P. processes an address

0220: Advice—
verification request on their behalf. V.I.P. sends 0220 advices to issuers and to acquirers

Chapter 20 How Address Verification Service (AVS) Works
when V.I.P. performs address verification for 0200 request messages. If the address
verification request includes authorization, field 39 contains the authorization response
code. Field 44.2 contains the address verification result code. If the request does not
include authorization, V.I.P. includes only the address verification result code in the advice.
Advice—An 0420 advice notifies acquirers when V.I.P. sends an 0400 reversal
0420: Advice—
to the issuer because the acquirer is unavailable to receive an 0210 response. If the
0210 response includes authorization, field 39 contains the authorization response code.
Field 44.2 contains the address verification result code. If the request does not include
authorization, V.I.P. includes only the address verification result code in the advice.
AVS cannot be invoked for:

• BASE I or SMS ATM transactions.
• BASE I or SMS check acceptance transactions.
• SMS Visa Electron or SMS Interlink transactions.
Refer to “Key Fields Glossary” in this chapter for AVS fields in messages.
20.5.1 Visa Custom Payment Services (CPS)/POS Transactions

To qualify for certain Custom Payment Service (CPS)/POS interchange rates, V.I.P. or the
issuer must verify the addresses for certain CNP transactions. These transactions are:
• CPS passenger transport messages.
• CPS card-not-present authorization requests.
CPS passenger transport transactions do not require address verification if the customer's
signature is on file. For recurring CPS card-not-present transactions, Visa requires address
verification only on the initial authorization request, unless the recurrence period is longer
than one year. For information about these transactions, refer to Chapter 28, Custom
Payment Service (CPS)/POS.
20.6 HOW ADDRESS VERIFICATION SERVICE (AVS) WORKS

AVS enables merchants to submit a request to verify the cardholder's billing address
with an 0100 authorization request message or with an 0200 financial request message.
Acquirers have two request options:

• Combine a request to verify an address with a POS authorization or purchase request.
• Request address verification only.
For combined address verification and authorization approval requests, V.I.P. performs
the address verification separately from the approval process.
Table 20-1 identifies the key fields required in Visa messages requesting address
verification. “Key Fields Glossary” in this chapter fully describes the fields and their
contents.
To request address verification, acquirers must include cardholder billing address and
postal or ZIP code data in Field 123—Address Verification Data of the message. Visa does
not require U.S. acquirers to include state codes.
NOTE
If an acquirer or an issuer processor submits a non-original or exception item with address verification data in
0699—Presence of PIN/Track/AVS Data Inconsistent
field 123, SMS rejects the message with Reject Code 0699
With Message Type.

Chapter 20 How Address Verification Service (AVS) Works
IMPORTANT
V.I.P. assigns result code N (no match) to requests that include field 123 but the field is empty (all spaces).
Field 123 being present with all spaces also disqualifies an address verification request for CPS consideration.
The code in Field 62.1—Authorization Characteristics Indicator (Bit Map Format) in the response is N and the
downgrade reason code is AV AV.
Table 20-1 Key AVS Data Fields
Key Fields
Kind of Request
Field 3 Field 4 Field 49 Field 123
Address verification with authorization request 000000 Amount 840 Address data
Address verification without authorization 000000 Zeros 840 Address data
request
V.I.P. looks at the values in specific message fields to determine:

• Whether the acquirer requests only address verification.
• Whether the acquirer requests both address verification and authorization or financial
message processing.
When the issuer requests that V.I.P. verify addresses on its behalf, V.I.P. checks the
address data in the request message against billing address information in the Address
Verification File within the Cardholder Database. Issuers maintain this file at the VisaNet
Interchange Center (VIC).
When the issuer specifies that it wants to verify addresses, V.I.P. forwards the request
to the issuer for address verification.
Issuers can receive both the address data and the V.I.P. address verification result code
in incoming authorization requests. Acquirers receive the verification result code in the
response.

Refer to the Cardholder Database Overview chapter in this volume for more information
about the database and the files it contains.
20.6.1 Address Verification File

If the issuer has specified that V.I.P. is to perform address verifications on its behalf,
V.I.P. uses information in the Address Verification File (AVF) within the Cardholder
Database to verify cardholders' addresses. Issuers must regularly update their cardholders'
address information in the AVF.
The AVF contains records organized by account number. V.I.P. checks a portion of the
cardholder's address in the address verification request against a portion of the address
information in the AVF for the account.
V.I.P. compares the information in the following fields in AVF records to the address
information in request messages:
Code—This field in AVF records contains either the cardholder's 5-digit or

Postal or ZIP Code—
9-digit postal or ZIP code. If the acquirer uses five digits, it must left-justify the digits and
space-fill the remainder of the field. Visa calls the V.I.P. postal or ZIP code verification

process Visa Verify. Visa Verify functionality is currently available only to issuers in the
U.S. region.
(AVV)—This field in AVF records contains the leading digits

Address Verification Value (AVV)—
(up to five) of the cardholder's address. Acquirers must left-justify the contents of this field
and space-fill the remainder. Numeric street names must be in numeric form.
EXAMPLE
Acquirers must send “Third Street” as: “3 Street”.
The figure below illustrates the data fields in an AVF record. V.I.P. compares the shaded
fields to fields in the request message.
Account Card-holder Address

Number Account Country Verification Effective
Length Number Purge Date Code Postal Code Value Update Time Time
Refer to the V.I.P. System Overview for basic information about file maintenance. Refer to
the Files appendix in the appropriate V.I.P. technical specifications manuals for detailed
information about file maintenance processes and procedures.
Refer to the Cardholder Database Overview chapter for a description of the Cardholder
Database. Refer to the Cardholder Database, Merchant Central File, and Advice File
chapter in V.I.P. System BASE I Processing Specifications, and to the Cardholder
Database chapter in V.I.P. System SMS Processing Specifications (U.S.), for more detailed
information about the Cardholder Database.
Refer to V.I.P. System BASE I Processing Specifications or to V.I.P. System SMS

Processing Specifications (U.S.) for a summary of the AVF.
20.7 PROCESS FLOWS

The basic AVS process flows, shown in Figure 20-1 and in Figure 20-2, consist of the
following steps:
1. The acquirer submits an 0100 or 0200 authorization request (with the address
information included) to the issuer through VisaNet.
2. V.I.P. receives the request.
a. If the issuer has its own in-house address verification process, V.I.P. forwards the
request to the issuer.
• If the address verification request is for a MasterCard transaction, the acquirer
includes the cardholder's address in the MasterCard authorization request.
V.I.P. routes the request directly to MasterCard issuers through MasterCard's
Banknet gateway. Banknet and V.I.P. route responses through the same path.
• If the issuer normally performs address verification but is unavailable, V.I.P. inserts
code R (retry) in the response. If V.I.P. performs address verification on the
issuer's behalf but the account is not on file, V.I.P. inserts code U (address not
verified for domestic transaction) or code G (address not verified for international
transaction) in the response.
b. If the issuer chooses to have V.I.P. perform address verification, V.I.P. processes
the address verification request by comparing a portion of the billing address with
address data in the Address Verification File for the cardholder.

If an acquirer submits a request for address verification for a card product that is not
eligible for AVS, the acquirer receives verification result code U (address information
not verified for domestic transaction) or code G (global non-AVS participant,
address information not verified for global transaction) in Field 44.2—Address
Verification Result Code. Acquirers receive result code N (no match) if they submit
Field 123—Address Verification Data containing all spaces. Refer to Table 20-5
for a list of valid verification result codes.
3. The issuer or V.I.P. (whichever performs the address verification) inserts the
authorization response code in Field 39—Response Code and the address verification
result code in field 44.2.
4. V.I.P. performs transaction authorization or clearing functions (if applicable) and returns
the 0110 or 0210 response to the acquirer.

Figure 20-1 and Figure 20-2 illustrate the basic AVS process flows.
Figure 20-1 AVS Process Flow When the Issuer Must Perform Address Verification and Is Available
Address
Verification
File
The acquirer sends an If the issuer performs its The issuer performs
authorization request own address verifications address verification,
containing address in-house, V.I.P. forwards authorization (or both)
information to the issuer. the request message to the and returns the results
issuer. Otherwise, V.I.P. in the response message.
performs address
verification and forwards
the request message to
the issuer.


Figure 20-2 AVS Process Flow When the Issuer Must Perform Address Verification and Is Unavailable

(Unavailable)
Address
Verification
File
The acquirer sends an If the issuer is unavailable,

authorization request STIP processes the
containing address authorization portion of the
information to the issuer. request.
If the issuer chooses to

have V.I.P. perform address
verification and V.I.P. has
access to the address
information, STIP performs
the verification and sends
an advice to the issuer.
If address information is not

on file, STIP returns the
message to the acquirer
with one of the following
result codes:
- If the issuer performs its

own address verifications
in-house, STIP returns
result code R (retry).
- If V.I.P. performs address

verification for the issuer

and the transaction is
domestic, STIP returns
result code U (address
not verified for domestic
transaction).
- If V.I.P. performs address

verification for the issuer
and the transaction is
global, STIP returns
result code G (address
not verified for global
transaction).
- STIP returns result code

N if field 123 is present
but contains all spaces

20.7.1 When V.I.P. Performs Address Verification

To compare the address data supplied in the request with the data stored in the Address
Verification File, V.I.P. performs the following steps:
1. V.I.P. scans the 20-character address data in field 123 from left to right and extracts
the first five numeric characters before it comes to the first alphabetic character or
space. The algorithm ignores any special characters (for instance, /, \, #, -) within the
first five numerics.
2. It extracts the 5-digit or 9-digit postal or ZIP code.
3. V.I.P. then compares the extracted data with the postal or ZIP code and the Address
Verification Value (AVV) in the AVF.
4. Finally, V.I.P. returns a verification result code in the response message, indicating the
results of the data comparison. (See Table 20-5 for a list of result codes.)
20.7.1.1 Forwarding AVS Data to Issuers

V.I.P. forwards the verification results to the issuer in the 0100 or 0200 request message
depending on the issuer-supplied processing parameters in the V.I.P. system tables.
Issuers have the option of receiving full- or compressed-format address data from acquirers
and from V.I.P. The differences between the two formats are:
Format—The issuer receives the full 9-position postal or ZIP code and up to the first 20
Full Format—
alphanumeric characters of the street address.
Format—The issuer receives the 9-position postal or ZIP code and the leading
Compressed Format—
numeric characters of the street address.
Refer to “Key Fields Glossary” in this chapter for a detailed description of both formats.
IMPORTANT
Postal or ZIP code data compression is only available to U.K. members.
20.7.2 Address Verification Data

The address data V.I.P. receives in field 123 contains combinations of the following
characteristics:
• Address Data Standards
• Field Formats
• Issuer Receipt Options
20.7.2.1 Address Verification Data Standards

The International Data Standard (IDS) for AVS data defines uniform practices for domestic
and cross-border transactions.
IDS standards for the street address are:

• The address must be only in EBCDIC displayable characters.
• The length can be up to 40 characters. Merchants and acquirers must have the ability
to send a minimum of 20 characters. When the cardholder-provided address exceeds
available space, acquirers and merchants truncate the right-most characters. When the
cardholder's address is shorter than the available space, acquirers and merchants either
may shorten the field length or may space-fill the remainder of the field to the right.

• Acquirers must convert spelled numerics to numerals. For instance, acquirers must send
“Thirty-One Park Place” as “31 Park Place”.
• Other than converting spelled numerics, acquirers and merchants must not perform any
other compression or alteration of cardholder-supplied data.
IDS standards for the postal or ZIP code are:
• The code must be only in EBCDIC displayable characters.
• The length can be up to nine characters. Acquirers and merchants must have the ability
to send a minimum of five characters. When the cardholder's postal or ZIP code is
shorter than the available space:
- Acquirers and merchants sending Tag-Length-Value (TLV) format data may either
shorten the field length or may space-fill the remainder of the field to the right.
- Acquirers and merchants sending fixed-format data must space-fill the remainder of
the field to the right.
• Acquirers and merchants should send all alpha and numeric characters; sending only
numeric characters is acceptable but not preferred.
• Acquirers and merchants must not perform any compression or alteration of
cardholder-supplied data.
NOTE
Issuers in markets that have less than five numeric digits in their postal code should be prepared to receive
values of less than five characters because some acquirers and merchants do not send the alpha characters
in alphanumeric postal codes.
Non-IDS data must be specifically identified as such within the authorization request
message. Members that want to establish a data standard that varies from that of the
IDS must provide a definition of the non-IDS standard to Visa, Inc. through their Visa
representatives. Visa, Inc. will assign a data type identifier that must be sent in request
messages, allowing V.I.P. and issuers to identify the data type.
20.7.2.2 Field 123 Formats

Data in field 123 can be in one of two record formats:

• Fixed format
• Tag-Length-Value (TLV) format
Both formats comply with the IDS for street address and postal or ZIP code information.
Issuers and acquirers in all regions may use the TLV format, which is the only option
available outside of the U.S. region and the United Kingdom (U.K.). Acquirers in the U.S.
region and in the U.K. may send field 123 data either in fixed format or in TLV format,
depending on merchant support requirements.
NOTE
For U.K.-domestic transactions, U.K. acquirers use a unique U.K.-only compressed format for sending
address data in field 123.
Fixed Format
For U.S.-domestic transactions, members use the fixed format for sending address data in
field 123. The fixed format of this field has two subfields following the Length subfield:

Positions:
1–9 10–29
Length Postal Code Cardholder Street Address
Byte 1 Bytes 2–10 Bytes 11–30
Subfield—The value in this subfield indicates the number of bytes of field 123
Length Subfield—
after the Length subfield.
1–9)—The value in this subfield is the postal or ZIP code.

Postal Code Subfield (Positions 1–9)—
The subfield contains the 9-digit code or the 5-digit code left-justified with four positions of
right-space fill.
NOTE
For U.K.-domestic transactions, members use a unique U.K.-only compressed format for sending address
data in field 123.
10–29)—This subfield contains up to 20 characters

Cardholder Street Address (Positions 10–29)—
of the cardholder's street address. The acquirer or the merchant converts spelled-out
numbers to digits and left-justifies the data with right-space fill. Examples of street
addresses in the fixed format are:
Actual Address Acquirer's Subfield Entry

One Elm St 1 Elm St
123 First St 123 1st St
89 25th Ave 89 25th Ave
22 Walnut St #23 22 Walnut St #23
P.O. Box 12345 P. O. Box 12345
NOTE
Acquirers and merchants can submit field 123 data in fixed format in compressed or uncompressed
form. (Again, only U.K. service participants may compress the postal or ZIP code data.) Refer to “Data
Compression” in this chapter for information about compressing data.
TLV Format
The following table illustrates the TLV format.
Positions:
1 2–3 4–255
Subfield 1: Subfield 2: Subfield 3: Subfield 4:
Length Dataset ID Dataset Length Address Data TLV Elements
Tag Length Value Tag Length Value
TLV1 TLVN
Byte 1 Byte 2 Bytes 3–4 Bytes 5–256

Length Subfield—
Subfield—One-byte binary subfield that contains the number of bytes in this field.
(This Length subfield byte itself is not counted when defining the number of bytes of the
Length subfield.)
1)—This subfield contains a one-byte binary identifier assigned

Dataset ID (Position 1)—
66.
to each address verification dataset. The dataset identifier has a value of hexadecimal 66
VisaNet allows up to 256 possible datasets per composite data element.
2–3)—This subfield contains a two-byte binary number that

Dataset Length (Positions 2–3)—
indicates the total combined length of the subsequent postal or ZIP code and the street
address datasets. Acquirers and merchants right-justify the value with leading zeros.
4–255)—This 252-byte maximum subfield

Address Verification TLV Elements (Positions 4–255)—
contains all of the postal or ZIP code and the street address datasets. The subfield
supports two datasets:
• The Standard International Format Postal Code TLV is an 11-byte maximum dataset
per occurrence.
• The Standard International Format Street Address TLV is a 42-byte maximum dataset
per occurrence.
The datasets can be in any order. Each dataset contains the following elements:
Tag—This element is a one-byte binary value that identifies the postal or ZIP code dataset
Tag—
element or the street address dataset element:
• Hex C0 = postal or ZIP code
• Hex CF = street address
AVS global participants cannot send multiple elements within the same tag.
Length—This element is a one-byte binary value that indicates how many bytes of data
Length—
constitute the Value element. For instance, a value of 05 means that 5 bytes of postal
data reside in the Value element.

Value—This element contains either the:
Value—
• Postal Code—The postal code element has a 9-byte maximum. It is the postal or ZIP
code in alphanumeric EBCDIC format, left-justified. Postal or ZIP codes that have fewer
than 9 alphanumeric characters in length do not require spaces to fill the element.
Numeric-only data is acceptable.
• Street Address—The street address element has a 40-byte maximum. It is the street
address in alphanumeric EBCDIC format, left-justified. Street addresses that have fewer
than 40 characters in length do not require spaces to fill the element. Acquirers and
merchants must convert alphabetic numbers in street addresses to numeric equivalents;
for instance, participants must convert “twelve” to “12”.
20.7.3 Data Compression

Issuers that perform their own address verification can choose to have VisaNet forward the
address data to them in either uncompressed form or in compressed form.

IMPORTANT
Compression is available only for Visa card transactions, not for MasterCard, American Express, or Discover
transactions. Postal or ZIP code compression is available only to U.K. participants.
• If the issuer wants to receive the postal or ZIP code and the street address data exactly
as the acquirer sent it, V.I.P. does not perform any compression on the data (that includes
any non-numeric characters).
• If the issuer wants to receive compressed data, V.I.P. removes any alpha characters and
special symbols in a street address and sends only the numeric values. The address
verification services for U.S.- and U.K.-domestic transactions match only on numeric
values.
The compression option applies to street address and, for U.K. participants, to street
address and postal or zip code.
IMPORTANT
Acquirers must be capable of sending at least 20 characters of uncompressed street address data unless
agreements on compatible compression methods have been established between specific acquirers and
specific issuers.
V.I.P. provides two compression algorithms, leading numerics and first five numerics,
for compressing data sent to issuers and for compressing postal or ZIP code and street
address data stored in the Cardholder Database for issuers that choose to have V.I.P.
perform address verification. V.I.P. also supports unique regional compression methods
such as the non-leading numeric, first five approach participants use for U.K.-domestic
transactions. Refer to “U.K.-Domestic Transactions” in the “Field 123 Usage” section
for more information.
Numerics—V.I.P. scans the street address subfield from left to right, extracting
Leading Numerics—
numeric digits. V.I.P. stops scanning when it encounters a space or an alphabetic character
(not including any special characters) or when it scans the entire street address. Table 20-2
illustrates the leading numerics compression algorithm. The ^ symbol denotes spaces.
Numerics—V.I.P. scans the street address subfield from left to right, as it does in
First Five Numerics—
the leading numerics algorithm. V.I.P. stops scanning when it has extracted five numeric
digits or when it scans the entire street address. Table 20-2 illustrates the first five numerics
compression algorithm. The ^ symbol denotes spaces.

Table 20-2 shows the difference in results between the two algorithms using data submitted
in fixed format.
Table 20-2 Fixed Format Address Data Compression by Leading Numerics and by First Five
Numerics Algorithms for Non-U.K. Participants
Compressed
Postal/ZIP Compressed by by First Five
Code Actual Street Address Uncompressed Leading Numerics Numerics
91234-0615 123 1st Street 912340615 123 1st Street 912340615123 9123406151231
91234 1 Elm Street 91234^^^^1 Elm Street 91234^^^^1 91234^^^^1

70433-0123 22 Walnut St #23 704330123 22 Walnut St #23 70433012322 7043301232223
Table 20-3 shows the fixed format address and postal or ZIP code compression by first
five numerics for U.K. AVS participants for the address: 5678 London Court #99, Postal
Code: 5S76D.
Table 20-3 Fixed Format Address and Postal or ZIP Code Compression by
First Five Numerics for U.K. Participants
Compressed by First Five

Postal or ZIP Code Actual Street Address Numerics
5S76D 5678 LONDONCOURT#99 576^^^^^^56789
For fixed-format submissions, compressed data includes spaces necessary to fill out a
subfield.
Both algorithms ignore special characters such as:

/ (forward slash)
\ (backward slash)
# (number or pound sign)
- (hyphen in a hyphenated numeric; for instance, 214-30)
When compressing data in the TLV format, the element length equals the length of the
resulting compressed data. For TLV submissions, compressed data does not require
any space-fill.

20.7.4 Matching Merchant Address Data

Table 20-4 illustrates the AVS matching process when the format in which the merchant
sends the address differs from that in the file.
Table 20-4 AVS Format Matching
Street Address From Merchant Address on File Result

202 Second Avenue 202 2nd Avenue Full match
1505/Apt Two, Main St 1505/Apt 2, Main St Full match, forward slash ignored
20.7.5 Translating Fixed and TLV Data

When a transaction involves an acquirer that uses one format (fixed or TLV) and an issuer
that uses the other format, V.I.P. reformats the data where appropriate. When necessary,
V.I.P. truncates one or more elements of address data before it forwards transactions to
issuers when formats are incompatible and cannot be adequately translated.
The initial character in field 123 identifies the format; TLV data always begins with an
EBCDIC non-displayable character. V.I.P. translates:
• TLV IDS data to fixed data.
• Fixed U.S. IDS data to U.K. fixed data.
• Fixed U.S. IDS data to TLV IDS data.
When switching transactions to issuers, V.I.P. sometimes truncates one or more address
data elements if the formats are incompatible or cannot be accurately translated. These
translations are:
• TLV non-IDS data to fixed data.
• Fixed non-IDS U.K. data to U.S. fixed data.
• Fixed non-IDS U.K. data to TLV data.
NOTE
V.I.P. also converts issuer-generated AVS result codes to their counterpart codes for the appropriate format
when it encounters incompatible data standards. Refer to the Result Code Conversion sections in this chapter.
20.7.6 Field 123 Usage

Participants use Field 123—Address Verification Data in card-present and card-not-present
0100 authorization requests, and in 0120 advices if the issuer chooses to have it included.
The field is not used in responses or in reversals.
NOTE
If an acquirer or an issuer processor submits a non-original or exception item with address verification data in
0699—Presence of PIN/Track/AVS Data Inconsistent
field 123, SMS rejects the message with Reject Code 0699
With Message Type.
If V.I.P. receives an authorization request containing field 123 for a card type that is not
valid for AVS, it removes the field before passing the request to the issuer. When V.I.P.
receives the 0110 issuer response, it inserts result code U (unavailable; issuer not an AVS
participant) in Field 44.2—AVS Result Code.
Acquirers can use an 0100 message to request an address verification by itself or along
with an authorization request. Field 44.2 contains the address verification result code.

IMPORTANT
When V.I.P. receives an AVS-only account verification request destined for a U.K. issuer that is directly
connected to Visa Europe Authorisation Services, V.I.P. forwards the request to Visa Europe Authorisation
Services, which determines whether the request is to be processed by its stand-in processing system or
forwarded to the issuer.
The following subsections summarize regional AVS transaction requirements, including the
usage of field 123.
20.7.6.1 U.S.-Domestic Transactions

A domestic transaction is defined as one for which the merchant, the acquirer, and the
issuer are all located in the same country.
U.S. acquirers can submit uncompressed or compressed street address data either in fixed
or TLV formats. U.S. acquirers can also submit only the street address and the postal or
ZIP code; VisaNet does not require the state.
NOTE
Acquirers must always forward uncompressed address data unless agreements on compatible compression
methods have been established between specific acquirers and specific issuers.
IMPORTANT
U.S. issuer participation in AVS is mandatory. U.S. issuers can choose to receive address data either in fixed
or TLV format, and in compressed or uncompressed format.
20.7.6.2 U.K.-Domestic Transactions

U.K. issuer participation in AVS is mandatory. U.K. issuers send and receive address
verification data in their own unique compressed format, and they must perform their own
address verification. In issuer-unavailable conditions, V.I.P. routes the transaction to
STIP according to issuer specifications, but STIP does not perform address verification.
V.I.P. returns AVS result code U (unavailable; issuer not an AVS participant) in field 44.2.

U.K. acquirers submit address data in the U.K. compressed format, subject to the following
requirements:
• U.K.-domestic transactions use a U.K.-unique compression method.
• VisaNet forwards address verification data from U.K. acquirers unaltered to U.K. issuers.
• V.I.P. converts address verification data from non-U.K. acquirers using the International
Data Standard (IDS) format to the U.K. format and forwards the message to U.K. issuers.
• V.I.P. removes address verification data from requests bound for non-U.K. issuers.
• Address data in global transactions (U.K. merchants and acquirers to non-U.K. issuers)
can be in TLV IDS format.
20.7.6.3 All Other Users

Participation by non-U.S. and non-U.K. issuers and acquirers is optional. All non-U.S. and
non-U.K. members must use the TLV format. V.I.P. converts data sent by U.S.-domestic or
U.K.-domestic acquirers to non-U.S. or non-U.K. issuers to the TLV format if necessary.

NOTE
Issuers performing their own verifications should choose to receive uncompressed data unless their
verification approach is compatible with the leading numerics or first five numerics algorithms.
Table 20-5 lists the valid address verification result codes that V.I.P. returns in
Field 44.2—Address Verification Result Code in 0110 and 0210 response messages.
Table 20-5 Field 44.2 Address Verification Result Codes
Code Applies to
Code Definition Domestic Global
A Street addresses match. The street addresses match but ✓ ✓
the postal or ZIP codes do not, or the request does not
include the postal or ZIP code.
B Street addresses match. Postal or ZIP code not verified ✓ ✓
due to incompatible formats. (Acquirer sent both street
address and postal or ZIP code.)
C Street address and postal or ZIP code not verified due to ✓ ✓
incompatible formats. (Acquirer sent both street address
and postal or ZIP code.)
D Street addresses and postal or ZIP codes match. ✓
F Street addresses and postal codes match. Applies to ✓
U.K.-domestic transactions only.
G Address not verified for international transaction. Issuer ✓
is not an AVS participant, or AVS data was present in the
request but issuer did not return an AVS result, or V.I.P.
performed address verification on behalf of the issuer and
there was no address record on file for this account.
I Address information not verified. ✓
M Street addresses and postal and ZIP codes match. ✓
N No match. Acquirer sent postal or ZIP code only, or street ✓ ✓

address only, or both postal or ZIP code and street address.
P Postal or ZIP codes match. Acquirer sent both postal or ZIP ✓ ✓
code and street address, but street address not verified
due to incompatible formats.
R Retry: System unavailable or timed out. Issuer ordinarily ✓
performs address verification but was unavailable.
V.I.P. uses code R when issuers are unavailable. Issuers
should refrain from using this code.
S Not applicable. If present, V.I.P. replaces it with U or ✓
with G.1 Available for U.S. issuers only.
U Address not verified for domestic transaction. Address not ✓
verified for international transaction. Issuer is not an AVS
participant, or AVS data was present in the request but
issuer did not return an AVS result, or V.I.P. performed
address verification on behalf of the issuer and there was
no address record on file for this account.

Table 20-5 Field 44.2 Address Verification Result Codes (continued)

Code Applies to
Code Definition Domestic Global
W Not applicable. If present, V.I.P. replaces it with Z. Available ✓
for U.S. issuers only.
X Not applicable. If present, V.I.P. replaces it with Y. Available ✓
for U.S. issuers only.
Y Street address and postal and ZIP code match. ✓
Z Postal or ZIP codes match, street addresses do not match ✓ ✓
or street address not included in request.
1. Issuers can send codes S, W, and X, but V.I.P. converts them to U, Z, and Y, as appropriate, before it forwards the
message to the acquirer.
NOTE
V.I.P. uses AVS result code N (in field 44.2) if an acquirer requests address verification without providing any
address data in field 123 in the request. AVS transactions attempting to qualify for CPS consideration will not
qualify; they receive downgrade reason code AV AV. This process ensures that acquirers are not afforded a better
CPS rate and chargeback protection when requesting address verification without supplying address data.
However, V.I.P. does not downgrade transactions that include postal or ZIP code data in field 123 and they
receive CPS qualification.
It is mandatory for U.K. acquirers to receive the result code G in field 44.2. U.S. acquirers
can choose to receive all or none of these AVS result codes: B, C, D, G, I, M, P.
20.7.6.4 Result Code Conversion Based on Jurisdiction and Representment Rights

(All Regions Except the U.S. and the U.K.)
Depending on transaction jurisdiction and on member participation options, V.I.P. converts
the issuer's AVS result code to reflect the transaction's correct representment rights status.
Table 20-6 lists codes and the converted codes.
Table 20-6 AVS Result Code Conversion Based on Jurisdiction and

Representment Rights
Converted Result Code to Acquirer

Global Transaction
Issuer or V.I.P. Domestic Representment No Representment
Result Code Transaction Rights Rights
Y F (U.K.) M D
M1 Y (U.S.) or F (U.K.) D
D1 Y (U.S.) or F (U.K.) M
U I G
I2 U G
G2 U I
1. F in U.K.).
Only V.I.P. should use these codes. Issuers should use Y (F
2. Only V.I.P. should use these codes. Issuers should use U.

20.7.6.5 Result Code Conversion Based on Acquirer Participation (U.K. and U.S. Only)
If an acquirer cannot receive the AVS global result codes (B B, P, C, D, I, M, and G),
V.I.P. converts them, as indicated in Table 20-7, before forwarding the response to the
acquirer. If the acquirer cannot receive the first replacement code from V.I.P. or from the
issuer, V.I.P. uses the second, or default, replacement code.
Table 20-7 AVS Result Code Conversion Based on Acquirer Participation
Issuer or V.I.P. Result Code First Replacement Code Second Replacement Code
G I U
B A
C G U
D Y (U.S.) or F (U.K.)
I U
M Y (U.S.) or F (U.K.)
P Z
Table 20-8 shows sample results that can occur during address verification. The table
shows data extracted in compressed format. The caret symbol (^) in the table represents
a blank space.
Table 20-8 Sample Address Verification Results
Visa's or
Issuer's Result
Merchant-Supplied Address Verification Data Postal/ZIP Code AVV Code
(Field 123) Data Extracted (AVF) (AVF) (Field 44.2)
91234^^^ÔneÊlm^Street 91234 91234 1 Z
912340615123^1st^Street 912340615123 912340615 123 Y
912340615123^First^Street 912340615123 912340615 123 Y

85282^^^^89^25thÂvenue 85282^^^^89 85282 89 Y
85282^^^^89^Twenty-FifthÂven 85282^^^^89 85282 89 Y
70433012322^Walnut^Street^#23 70433012322 704330123 22 Y
70433^^^^22^Walnut^Street^#23 7043322 70433 22 Y
70454^^^^P.O.^Box^12345 70454^^^^ 70454 Y
94112^^^^111^Jones^Street 94112^^^^111 93123 111 A
43111^^^^998Âcorn^Street^#23 43111^^^^999 32678 999 N
94823^^^^222^Maple^Street 94823^^^^222 94823 346 Z
If STIP provides the authorization approval or decline code after the issuer has supplied the
address verification result code in Field 44.2—Address Verification Result Code (as occurs
for some transactions), the acquirer receives the authorization response value assigned by
STIP in Field 38—Authorization Identification Response, rather than the code assigned
by the issuer.

• If the issuer returns a non-approval response code (any code except 85

85) in field 39 for an
address-verification-only request, V.I.P. forwards the issuer-generated response to the
acquirer. Additionally, V.I.P. forwards the issuer-generated code in field 38.
• If the issuer returns response code 85
85, V.I.P. generates the code in field 38.
Refer to “Key Fields Glossary” in this chapter for AVS fields in messages.
20.7.7 AVS Process Flow Variations

The AVS process flow differs depending on the options chosen by issuers and by acquirers.
This section describes possible options. “Message Flows” in this chapter illustrates
possible message flows.
IMPORTANT
Because address verification processing and authorization and financial processing are two separate
processes, an acquirer could receive address verification result code N (no match) along with an authorization
approval.
20.7.7.1 V.I.P. Performs Address Verification

V.I.P. receives the address verification request from the acquirer.
V.I.P. performs address verification by comparing the incoming address data in the request
message with address data stored in the Address Verification File.
V.I.P. forwards the authorization request to the issuer or processes it in stand-in according
to issuer-specified parameters and transaction characteristics.
V.I.P. decides whether to process a request or to forward it based on:

• Whether the request is for address verification only or for address verification and
authorization.
• Issuer-specified AVS options.
• Transaction characteristics and issuer-specified parameters V.I.P. is to use when the
address verification request is combined with an authorization request.
V.I.P. performs transaction authorization functions as requested in the acquirer's message.

V.I.P. returns the 0110 or 0210 response, which includes the address verification result
code, to the acquirer.
NOTE
The issuer can request that V.I.P. include the address verification result code in an 0120 or 0220 advice.
20.7.7.2 When the Issuer Performs Address Verification

With the in-house address verification option, issuers can verify the cardholder's billing
address for 0100 and 0200 transactions using the current matching logic.
When an issuer chooses to perform address verification, V.I.P. routes the acquirer's address
verification request directly to the issuer for processing. The issuer verifies the address and
returns a verification result code. Table 20-5 lists valid address verification result codes.
If the request is for both address verification and authorization, the issuer verifies the
address data, and the issuer or V.I.P. processes the authorization request depending on
the transaction characteristics and on issuer-specified STIP parameters. V.I.P. returns
both results in the response to the acquirer.

20.8 MESSAGE FLOWS

This section describes the processing of an 0100 or 0200 request message
containing address verification data, the 0110 or 0210 response to that message, and,
when necessary, the 0120 or 0220 advice message. Figure 20-3 illustrates the basic
AVS message flow.
Figure 20-3 AVS Message Flow
Address In-house
Verification Address
File Verification

Field 25—POS Condition Field 25—POS Condition Field 25—POS Condition
Code Code Code
Field 123—Address Field 123—Address Field 123—Address
Verification Data Verification Data Verification Data
0110 or 0210 Response 0110 or 0210 Response 0110 or 0210 Response

Field 38—Authorization Field 38—Authorization Field 38—Authorization
Identification Response Identification Response Identification Response
Field 39—Response Code Field 39—Response Code Field 39—Response Code
Field 44.1—Response Source/ Field 44.1—Response Source/ Field 44.1—Response Source/
Reason Code Reason Code Reason Code
Field 44.2—Address Field 44.2—Address Field 44.2—Address
Verification Result Code Verification Result Code Verification Result Code

(optional)
0120 or 0220 Advice 0120 or 0220 Advice

Field 39—Response Code Field 39—Response Code
Field 44.2—Address Field 44.2—Address
Verification Result Code Verification Result Code
The examples that follow illustrate AVS processing when:

• V.I.P. performs both address verification and authorization.
• V.I.P. performs address verification only.

• The issuer does not support address verification.

• The issuer performs address verification.
As appropriate, the examples illustrate processing when the issuer is available, when the
issuer is unavailable and STIP processes the request, and when the STIP performs the
processing regardless of the availability of the issuer. Table 20-9 defines the abbreviated
terms the examples use.
Table 20-9 Abbreviations Used in Examples
Term Definition Field

Address data Address verification data 123
POS code POS condition code 25
Reason code Response source/reason code 44, position 1
Verification result Address verification result code 44, position 2
20.8.1 V.I.P. Performs Address Verification and Authorization

Examples 1 through 4 illustrate message flows when V.I.P. performs address verification
and the message requests authorization and address verification.
Examples 1 and 2 illustrate the processing flow when STIP processes the transaction
and the issuer chooses not to have V.I.P. forward the verification result. In Example 1,
the issuer is available; in Example 2, the issuer is unavailable.

Example 1
In this example, the following conditions exist:
- The request is for both address verification and authorization.
- The issuer is available.
V.I.P. does not forward the verification result to the issuer because the issuer chooses
not to receive it.
In this example, V.I.P. performs address verification for the issuer, but the issuer does
not want to see the result. V.I.P. passes the request without address data to the issuer.
When the acquirer requests an address verification, V.I.P. verifies the address data against
the information in the Address Verification File and sends the result in Field 44.2—Address
Verification Result Code in the response to the acquirer but does not advise the issuer that
it performed address verification.
0100 or 0200 Request 0100 or 0200 Request
Address data POS code = 51
0110 or 0210 Response 0110 or 0210 Response
Verification result
Example 2

- The issuer is unavailable.
V.I.P. does not forward the verification result to the issuer.
If the issuer is unavailable, STIP processes the request. The message flow is the same
as the message flow illustrated in Example 1, except that STIP does not forward the
authorization request to the issuer. If STIP creates an advice for the authorization,
the advice does not contain the verification result code in field 44.2.


(Unavailable)
0100 or 0200 Request
Address data
0110 or 0210 Response 0120 or 0220 Advice
Verification result
Examples 3 and 4 illustrate the processing flow when STIP processes the transaction and
the issuer chooses to have V.I.P. forward the verification result. In Example 3, the issuer is
available; in Example 4, the issuer is unavailable.
Example 3
V.I.P. forwards the verification result to the issuer.
In this example, V.I.P. performs address verification for the issuer, and the issuer wants
to see the result. When an acquirer submits a combination authorization and address
verification request, V.I.P. verifies the address data against the information in the Address
Verification File. V.I.P. forwards the verification result code (in field 44.2) and the address
data (in field 123) to the issuer in the request. The issuer returns the verification result code
in the response to the acquirer.

Address data Address data

Verification result
Verification result Verification result

Example 4
- The issuer is unavailable.
V.I.P. creates an advice for the issuer.
If the issuer is unavailable, STIP processes the request. The message flow is the same
as the message flow illustrated in Example 1, except that STIP does not forward the
authorization request to the issuer because the issuer is unavailable. If STIP creates an
advice for the authorization, STIP includes the verification result code (in field 44.2) and the
address data (in field 123) in the advice.

(Unavailable)
Address data
Verification result Address data

Verification result
20.8.2 V.I.P. Performs Address Verification Only

Example 5 illustrates the message flow when V.I.P. provides address verification and the
acquirer requests address verification only.

Example 5
- The request is for address verification only.
V.I.P. creates an advice for the issuer.
In this example, the acquirer requests address verification only by including POS condition
code 51 in the message in addition to address data. Because V.I.P. is verifying the address
for the issuer, V.I.P. processes the request entirely within the system. V.I.P. includes the
verification result code (in field 44.2) and the response code (in field 39) in the response
message sent to the acquirer. V.I.P. creates an advice for the issuer containing the
verification result and the address data.
Address data
Response code Address data

20.8.3 Issuer Does Not Support Address Verification

Some issuers outside of the U.S. region and the U.K. do not support address verification

requests. In Example 6, the acquirer requests address verification, but the issuer does
not support it, either in-house or through V.I.P. The issuer, therefore, has no cardholder
address information on file at the VIC. In this situation, V.I.P. omits the address data from
requests that it forwards to the issuer. When V.I.P. sends the response message to the
acquirer, it inserts verification result code U (unavailable) in field 44.2.
Example 6
- The acquirer requests address verification.
- The issuer does not support it.
The message flow is the same as those for address verification-only requests or for
combined authorization and address verification requests when the issuer supports
address verification.

Address data
Verification result = U
In Example 7, the acquirer requests address verification only, but the issuer is in the U.K.,
so V.I.P. forwards the transaction to Visa Europe Authorisation Services for approval
processing.
Example 7
- The acquirer requests address verification only.
- The issuer resides in the U.K.
V.I.P. does not forward the request to the issuer because the issuer is in the U.K.
V.I.P. forwards the request to Visa Europe Authorisation Services for an approval or
decline decision.
Acquirer V.I.P. Visa Europe

Authorisation System
POS code = 51
Address data
0110 or 0210 Response
Response code = 57
20.8.4 Issuer Performs Address Verification

Examples 8 through 10 illustrate message flows when the issuer performs address
verification and the message requests authorization and address verification.
Example 8

- The acquirer requests both authorization and address verification.

- The issuer prefers to perform these functions and is available.
When the acquirer submits a combination authorization and address verification request,
V.I.P. forwards the request to the issuer with the address data. The issuer verifies
the address data and authorizes the transaction. The issuer's response includes the
authorization response in Field 39—Response Code and the verification result in
Field 44.2—Address Verification Result Code.
Reason code = 5 Reason code = 5

Example 9

- The issuer prefers to perform these functions but is unavailable.
In this example, the issuer is unavailable, so STIP processes the authorization
request according to the issuer's STIP parameters and sends verification result code R
(retry—system unavailable or timed out) to the acquirer. If STIP creates an advice for the
authorization, it includes the address verification result code and the address data.


(Unavailable)
Address data

Reason code = 4 Address data
Verification result = R Verification result = R
Example 10
- The request is an airline transaction that qualifies for STIP processing, and the issuer is
available.
When STIP processes a combined authorization and address verification request that
contains an airline merchant category code (in Field 18—Merchant Type), V.I.P. changes
the POS code (in Field 25—Point-of-Service Condition Code) to 51 (address verification
only) and forwards the request with the address data to the issuer. V.I.P. then processes
the authorization according to the issuer's STIP parameters. The issuer verifies the address
information. If the issuer declines the transaction because it does not pass address
verification, the issuer returns a decline response code in field 44.2 in the response to V.I.P.
Then, V.I.P. sends field 44.2 and the STIP results in field 39 to the acquirer.
POS code = 0 POS code = 51

Reason code
Verification result
Verification result
Examples 11 and 12 illustrate message flows when the issuer performs address verification
and the message requests address verification only. In Example 11, the issuer is available;
in Example 12, the issuer is unavailable.

Example 11
- The issuer prefers to perform this function and is available.
When the acquirer requests address verification only (by using POS condition code 5151),
51.
V.I.P. forwards the request to the issuer with the address data and with POS code 51
The issuer verifies the address data and includes the address verification response in
Field 39—Response Code.
POS code = 51 POS code = 51


Response code Reason code = 5
Reason code = 5
Verification result
Verification result
Example 12
- The issuer prefers to perform this function but is unavailable.
In the following example, the issuer is unavailable, so STIP processes the request.
Because the issuer cannot verify the address, V.I.P. sends address verification result

code R (retry—system unavailable or timed out) in field 44.2 to the acquirer.

(Unavailable)
POS code = 51
Address data
0110 or 0210 Response
Verification result = R


This section describes the fields in 0100 and 0200 request messages and in 0110 and 0210
response messages that support address verification. It also provides information about full
and compressed data formats used for these fields by issuers.
Field 3—Processing Code

Field 3 contains coding that identifies:
• The customer transaction type.
• The customer account types, if any, affected by the transaction.
For address verification requests, field 3 must contain all zeros.

Requests for address verification only (indicated by code 51 in Field 25—Point-of-Service
zeros. If STIP processes the request on
Condition Code), must include field 4 set to zeros
behalf of the issuer, and field 4 contains an amount, STIP ignores the amount.

This field can contain any valid category code for merchants. Refer to V.I.P. System
BASE I Technical Specifications, Volume 1 and Volume 2, and to V.I.P. System SMS
POS (Visa & Visa Electron) Technical Specifications, Volume 1 and Volume 2, for a
complete list of valid merchant category codes.

This field can contain any valid code. Messages requesting address verification only
contain code 51 in this field. Refer to V.I.P. System BASE I Technical Specifications,
Volume 1 and Volume 2, and to V.I.P. System SMS POS (Visa & Visa Electron)
Technical Specifications, Volume 1 and Volume 2.
Field 38—Authorization Identification Response

Field 38 contains the authorization code, which the issuer provides. Field 38 is required
in all:
• Authorization approval responses.

• Responses to address verification requests that receive response code 85 (no
reason to decline) in field 39.
• Responses to request messages, with or without address verification requests,
when the response code in field 39 is 00 (approval).
In these transactions, both the issuer and V.I.P. make authorization and approval
decisions and pass both responses to the acquirer in fields 38 and 39.
If STIP provides the authorization approval or decline code after the issuer has supplied
the address verification response code, as occurs in some transactions, the acquirer
receives the code assigned by STIP, rather than the code assigned by the issuer,
in field 38.
Refer to V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2, and to
Volume 2, for a complete list of valid authorization codes and response codes.


Field 39 contains the code indicating the action to be taken by the acquirer in response
to a request. VisaNet requires the issuer to include the response code in all response
transactions.
An authorization approval or decline response depends on more than just a successful

address verification. The appropriate response code for a verification request is 85
(no reason to decline) unless V.I.P. overrides the response with a negative response
(such as edit errors or negative cardholder authorization data).

The code in this field identifies the entity responding to the authorization or verification
request. If V.I.P. performs address verification, the code in this field is 2. V.I.P. inserts
this code in response messages. If the response is provided by STIP, the code explains
why STIP is responding for the issuer.
If the issuer performs address verification, it inserts response source/reason code 5

in field 44.1, indicating that the response was provided by the issuer center.
However, if STIP provides the authorization decision after the issuer processor provides
the address verification response, the acquirer processor receives code 2 in field 44.1.
(The authorization source takes precedence over the address verification source.)
Field 44.2—Address Verification Result Code

The code in this field identifies the result of the address verification process and
the entity that performs the address verification uses it only in response to address
verification requests. The entity verifying the address (V.I.P., a BASE I or SMS issuer,
or a MasterCard issuer through the Banknet gateway) provides the result code.
If V.I.P. performs address verification, it returns the verification result code in the
response to the acquirer. If requested by the issuer, V.I.P. also includes the code in the
advice sent to the issuer.

If V.I.P. performs address verification but the issuer performs the transaction approval,
V.I.P. includes its results code in field 44.2 when it forwards the response from the
issuer to the acquirer.
If the issuer performs address verification, it inserts the verification result code in
field 44.2 of the response.
If the issuer performs address verification, but STIP performs the authorization process,
the acquirer receives field 44.2 only if the issuer returns it in the response.
Refer to Table 20-5 in this chapter for valid address verification result codes.
Field 49—Currency Code, Transaction

Field 49 contains a code that identifies the currency in field 4, even when the value in
field 4 is zero (as it is in a request for address verification only).

Field 123—Address Verification Data

This field is included for address verification requests from the acquirer. Issuers
performing their own address verification can optionally receive the data in this field in
the acquirer's full (or standard) format or in compressed format, which reduces the street
address to its first five digits not preceded by an alphabetic character or a space.
NOTE
Compression of postal or ZIP code data is available to U.K. issuers only.
Both formats are shown in Table 20-10. The caret symbol (^) represents a blank space.
Table 20-10 Full and Compressed Data Formats
Actual Field 123: Compressed

Address ZIP Code Field 123: Full Format Format
123 1st Street 91234-0615 912340615 123 1st Street 912340615123
1 Elm Street 91234 91234^^^^1 Elm Street 91234^^^^1
22 Walnut St 70433-0123 704330123 22 Walnut St #23 70433012322
#23
Field 123 consists of up to 29 characters of the cardholder's address. In the full format,
the first nine positions contain either the 5-digit or 9-digit postal or ZIP code, and the
remaining positions contain the first 20 alphanumeric characters of the street address.
If the issuer has chosen to receive address data in compressed format, it receives a total
of 14 positions made up of a 9-position postal or ZIP code field and a 5-position address
field. V.I.P. reduces the street address to its first five digits before the first alphabetic
character or space.
The number in a street address and any numeric names of streets must be sent by the
merchant or the acquirer in numeric form to match the address data stored in the Address
Verification File.
EXAMPLE
Acquirers must convert and send the address “One Fifty-Five Park Place” as “155 Park Place”.
The issuer must not return the address information in the response.
IMPORTANT
Acquirers should not send address data in compressed format because issuers have the option to receive the
data in the full, or uncompressed, format.
V.I.P. compresses address information only for Visa card transactions; it never compresses
address data for MasterCard, American Express, or Discover card transactions.
If V.I.P. receives an authorization request containing field 123 for a card type that is not
valid for address verification or is for an issuer that does not support address verification,
it removes field 123 before passing the request to the issuer. When V.I.P. receives the 0110
issuer response, it inserts code U (unavailable; issuer not an AVS participant) in field 44.2.

For issuer processors that participate in AVS but choose not to receive the result code,
V.I.P. removes this field from the request before it sends the request to the issuer processor
for authorization.
Volume 2, for a complete list of valid response codes and authorization codes.

For further information about AVS, refer to the following documents:
• V.I.P. System Overview
and Volume 2
20.10.1 Merchant Guide for AVS
To help acquirers educate their direct marketing, airline, and other merchants accepting
mail orders and telephone orders about this important risk management service, Visa offers
the Merchant Guide to the Visa Address Verification Service, targeting two merchant
audiences:
• Those currently using AVS who want specific details about the service
• Those considering AVS who want information about its benefits and its value as well
as its connection options
The guide also includes tips for reducing copy requests and chargebacks and a brief
description of the Merchant Direct Access Service (MDAS), which offers convenient
access to the electronic AVS using a touch-tone telephone. The guide is free and may be
ordered by calling the Visa Fulfillment Center at + 1-800 235-3580 and requesting Item
#VRM01.01.06.


Chapter 21 Advice Retrieval Service—BASE I
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
IN BRIEF 21-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
Advice Retrieval Service—BASE I

REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
HOW BASE I ADVICE RETRIEVAL SERVICE WORKS 21-66
BASE I Advice Message Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-6
BASE I Message Processing Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
PROCESS FLOWS 21-77
Multiple Stations per PCR Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9
BASE II Advice Delivery (Offline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9
Advice Retrieval During and After a VIC Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
VIC Processing Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
During Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
After Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
MESSAGE FLOWS 21-11
11
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
12
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-
12


Chapter 21 Advice Retrieval Service—BASE I
21.1 IN BRIEF
The BASE I Advice Retrieval Service allows issuers to retrieve (or to recover) their stand-in
processing (STIP) advice data from the BASE I advice file.

The BASE I Advice Retrieval Service is available to issuers in all Visa regions.
BASE I
The BASE I Advice Retrieval Service is mandatory for BASE I System issuers
SMS and processors.
BASE I only
I Participation in the BASE I Advice Retrieval Service is mandatory for BASE I

System issuers and processors.
Issuer

The BASE I Advice Retrieval Service enables issuers to keep informed of stand-in
authorizations, reversals, and Cardholder Database file updates by allowing issuers to
retrieve their advice data from the BASE I advice file at their VisaNet Interchange Center
(VIC).
Each VIC maintains a BASE I advice file, in which it stores BASE I STIP response records.
Every record reflects information from the authorization or reversal request, the STIP
response, and the reason why STIP processed the request.
NOTE
STIP does not create advices for all of the transactions that it processes. For instance, STIP does not
generate an advice for a request that has decline response code 15 (no such issuer).
V.I.P. creates a record in the BASE I advice file each time one of the following services
initiates an update to the Cardholder Database files:
• Global Customer Care Services (GCCS)
• Vsafe
• Merchant Fraud Performance Program

V.I.P. stores BASE I STIP advice records for a maximum of 15 days or until the issuer
retrieves the advices from the BASE I advice file. After 15 days, V.I.P. purges any
unretrieved BASE I advices. V.I.P. stores the following categories of advice messages
in the BASE I advice file:
• STIP processing advices (these include authorization and reversal requests, and negative
results obtained from checking the exception file).
• BASE I exception file update advices. Refer to the Cardholder Database Overview
chapter in this manual for information about this file.
• International Automated Referral Service (IARS) advices. Refer to the International
Automated Referral Service (IARS) chapter in this manual for more information.
Issuers can select one of the following methods for retrieving BASE I advices:
Online—Issuers can recover advices online using their VisaNet connection. For online
Online—
advice retrieval, issuers must be authorized to access the advice records. Issuers can use
either one station or multiple stations per Processing Center Record (PCR) to retrieve
advices:
• The One Station per PCR method uses a single station for each V.I.P. connection
identifier (known as a PCR), which initiates a sign-on message to retrieve advices from
the advice queue, one at a time. The participant must respond to each advice message
before it can retrieve the next advice message.
• The Multiple Stations per PCR method uses a single PCR, in which a processor can
sign on to more than one station at a time to retrieve advices from the advice queue.
This method allows processors to retrieve their BASE I advices much more quickly than
they could from a single station. Participants can continue advice retrieval from a single
station through their primary connection to VisaNet.
Offline—Issuers can receive machine-readable or print-ready advice records through the
Offline—
BASE II System as transaction code 48 (TC 48) advices.
Receiving advice data as TC 48 records is an alternative to online advice retrieval.
Receiving advices through BASE II is especially useful when the issuer is both a BASE I
authorization center and a BASE II processing center.
Issuers can also contact their Visa representatives to subscribe to the BASE I report
BIOSR320, Advice File Listing. BIOSR320 is a weekly report of all advices BASE I stored
since the last reporting date. The report can be delivered electronically or in printed form.

This section contains the participation requirements for the BASE I Advice Retrieval Service.
21.4.1 Testing
Advice retrieval testing is mandatory for all BASE I issuers that choose to retrieve advices
online. BASE I issuers in the Visa U.S.A. (U.S.) region must successfully complete testing
before they can receive advices whether or not they participate in the service.
The testing process ensures that the issuer can successfully send and receive the following
messages:

• 0120—STIP advices.
• 0120 and 0322—Exception File update advices for the following:
- The Automatic Cardholder Database Update (Auto-CDB) Service. Refer to the
Automatic Cardholder Database Update (Auto-CDB) Service chapter for information
about this service.
- Global Customer Assistance Services (GCAS). For information about GCCS, members
can contact their Visa representatives.
NOTE
Receipt of 0322 advices is optional for BASE I issuers, as is sending 0332 advice responses. SMS issuers
that participate in either or both advice retrieval services must successfully complete testing before they can

receive 0322 advices and send 0332 advice responses. If the BASE I issuer chooses not to receive 0322
advices, V.I.P. generates 0120 advices for file updates.
• 0420—Reversal advices.
• 0800 and 0810—Advice recovery sign-on and sign-off network management messages.
BASE I Advice Retrieval Service participants. Members can contact their Visa regional
representatives to make the arrangements.

Service monitoring is not available for the BASE I Advice Retrieval Service.

Issuers should consider the following key points to benefit fully from the BASE I Advice
Retrieval Service.
Advices—Issuers can choose to recover advices throughout the day or only

Recovering Advices—
during certain periods. Issuers can optionally set up some of their BINs for online advice
retrieval and set up other BINs for offline advice retrieval.
Issuers must sign off from Advice Recovery mode if they do not want to receive advices at
certain times. Issuers must sign on to Advice Recovery mode once they are ready to receive
advices. V.I.P. does not automatically sign an issuer on or off Advice Recovery mode.
Options—Issuers should consider the impact of STIP

Cardholder's Open-to-Buy Options—
authorization on advice recovery processing. STIP advices reflect authorization decisions
that can affect the cardholder's open-to-buy amount. If an issuer restricts advice recovery
to only certain periods, it may find that the cardholder's credit limit is insufficient to cover the
total value of issuer-approved and STIP-approved transactions.
Traffic—Issuers must be able to handle the increased advice

Increased Advice Message Traffic—
throughput. Processor host constraints may limit the number of stations that issuers can
sign on to Advice Retrieval mode at one time.
Method—Issuers can sign on to multiple stations per V.I.P.

Multiple Stations per PCR Method—
connection identifier (known as a Processing Center Record [PCR]) to speed up advice
recovery. Each issuer, however, must analyze their VisaNet connection capacity for the
following factors before converting to the Multiple Stations per PCR option:

• Line speed
• Number of stations
• Host connectivity protocol
Participants can discuss potential implementation problems with their Visa representatives.

The following messages pertain to the BASE I Advice Retrieval Service.
Advice—This advice is a notice of a request

0120: STIP Action or Exception File Update Advice—
and its response data when BASE I STIP processes a balance inquiry authorization request
or an address verification-only request on behalf of a BASE I issuer.
V.I.P. generates Exception File update advices for updates made by the Auto-CDB Service,
the Merchant Fraud Performance Program, Vsafe, or Global Customer Assistance Services
(GCAS). BASE I issuers can receive these advices as 0120 or 0322 message types, or as
BASE II TC 48 advices.
Response—BASE I issuers that

0130: STIP Action or Exception File Update Advice Response—
choose to receive 0120 file update advices can optionally send 0130 file update advice
response messages.
Advice—This advice indicates that V.I.P. updated the Cardholder

0322: File Maintenance Advice—
Database on the issuer's behalf. BASE I issuers can choose to receive either type of file
update advice, 0120 or 0322, but cannot choose to receive both. If a BASE I issuer chooses
to receive 0322 file update advices, it can optionally send 0332 advice response messages.
Advice—This advice notifies the issuer when STIP processes an 0400

0420: Reversal Advice—
reversal and advice creation is appropriate under the rules of the Positive Cardholder
Authorization Service (PCAS). For information about this service, refer to the Positive
Cardholder Authorization Service (PCAS) chapter.
Response—Issuers can optionally send this response message to

0430: Reversal Advice Response—
acknowledge receipt of an 0420 reversal advice.
Request—This message allows issuers to sign on to Advice

0800: Network Management Request—
Recovery mode. Issuers use the field 70 code 078 to sign on to recovery and code 079 to
stop the recovery process.
21.6 HOW BASE I ADVICE RETRIEVAL SERVICE WORKS

This section explains the creation of advice messages, as well as the BASE I Advice
Retrieval Service process flow and message flow.
21.6.1 BASE I Advice Message Creation

STIP generates advice messages during authorization and reversal processing. V.I.P. also
generates BASE I advice messages for Exception File updates.
BASE I participants enrolled in PCAS have the option to specify which conditions trigger
STIP to generate an advice. For information, see the Positive Cardholder Authorization
Service (PCAS) chapter.
For information about the exception file, see the Cardholder Database Overview chapter.

The response code in the advice message is usually, but not always, the code V.I.P.
returns in the response message. For instance, if the Card Verification Value (CVV) or the
Integrated Chip Card CVV (iCVV) failed the verification process, the issuer can receive
error code 082 in the advice, depending on the issuer's option for receiving notice of CVV
or iCVV errors. The acquirer, however, receives an issuer-defined default response code in
Field 39—Response Code, unless V.I.P. detects a more serious error. See V.I.P. System
BASE I Processing Specifications and V.I.P. System BASE I Technical Specifications,
Volume 1 and Volume 2, for more information.
21.6.2 BASE I Message Processing Modes

Issuers have two modes for message processing: Normal (signed-on) mode and Advice

Recovery mode. A station can be in Normal mode, in Advice Recovery mode, or in both
modes concurrently.
Mode—Issuers can receive and can send real-time messages but cannot receive
Normal Mode—
advices from V.I.P.
Mode—V.I.P. sends advices to issuers (at the time V.I.P. stores them in
Advice Recovery Mode—
the BASE I advice file).
When an issuer station is in Advice Recovery mode, it receives advices in one of the
following ways:
• The issuer can receive advices automatically every two seconds without a required
response. (Usually, advices arrive in chronological order, but creation of advices at a
secondary VIC can affect the order.) Stations request the automatic method by sending
BASE I an 0800 message with code 078 in Field 70—Network Management Information
Code.
• Issuers can choose a more rapid advice retrieval process by prompting V.I.P. to send the
next advice. To initiate rapid advice retrieval, issuers must respond to each advice request
message with a corresponding advice response message (to send the next advice).
NOTE
If the advice response message is longer than two seconds, normal pacing of transmission resumes.
Issuers can send and receive real-time messages as well as receive stored advices. The
issuer sends a “sign on to recovery” 0800 request while it is still signed on for normal
message processing.
21.7 PROCESS FLOWS

The online BASE I advice retrieval process consists of the following steps.
1. Signing Off from Normal (Request Processing) Mode—If the issuer chooses to operate
only in Advice Recovery mode, it must sign off from Normal (request processing) mode
by sending an 0800 message with code 072 in field 70. V.I.P. acknowledges the request
by sending an 0810 message with code 072 in field 70.
2. Signing On for Advice Recovery—To initiate advice retrieval, issuers submit an
0800 message with code 078 in field 70 to sign on to Advice Recovery mode.
V.I.P. acknowledges the request by sending an 0810 message with code 078 in
field 70. For more information about network messages, refer to V.I.P. System BASE I
Technical Specifications, Volume 1 and Volume 2, and to the pertinent V.I.P. System
SMS technical specifications manuals.

V.I.P. sends advices to the issuer's station at the rate of one advice every two seconds,
beginning with the highest priority advices on file. V.I.P. delivers BASE I advices in
the following priority sequence:
- Priority 1: 0120 STIP action or exception file update advices
- Priority 2: 0420 reversal advices
- Priority 3: 0620 administrative advices
NOTE
Advice recovery does not interrupt authorization traffic. The same issuer station can be signed on for
normal traffic and for advice recovery at the same time.
When V.I.P. performs advice recovery for issuers that participate in the Positive
Authorization Capacity Management (PACM) Service, the system pauses or stops
advice recovery when the issuer reaches its processing capacity. As soon as processing
returns to below capacity, the system resumes advice recovery. Refer to the Positive
Authorization Capacity Management (PACM) Service chapter for information about
this service.
3. Selecting More Rapid Advice Recovery (Optional)—Issuers can choose to speed up the
advice recovery process by responding to each advice or by using multiple stations for
signing on to Advice Recovery mode. To prompt for additional advices, issuers send a
corresponding advice response message after each advice request message.
When issuers use this option, V.I.P. immediately sends the next advice in the queue
rather than waiting two seconds before sending the next advice. V.I.P. sends the first
and subsequent advices, as prompted, all the way through the end of the file.
NOTE
For more information, see “Multiple Stations per PCR Option” in this chapter.
4. Signing off from Advice Recovery—To stop (and to sign off from) advice recovery while
using either the normal or rapid advice recovery method, issuers send an 0800 message
with code 079 in field 70. V.I.P. acknowledges the request by sending an 0810 message.
- To resume advice recovery processing at a later time, however, the issuer must
submit another “sign on to recovery” message.
Issuers can choose to remain in Advice Recovery mode after recovering all of their
advices from the BASE I advice file so that they can recover advices as V.I.P. creates
them.
5. Signing Back On to Normal (Request Processing) Mode—If the issuer is operating only
in Advice Recovery mode, it must sign on to Request Processing mode by sending an
0800 message with code 071 in field 70. V.I.P. acknowledges the request by sending
an 0810 message.

Figure 21-1 illustrates the BASE I Advice Retrieval Service process flow.
Figure 21-1 BASE I Advice Retrieval Service Process Flow
Issuer V.I.P.

Assuming the issuer is not V.I.P. acknowledges the
already in recovery mode, issuer’s “sign on to recovery”
the issuer sends a request to request
“sign on to recovery.”
The issuer receives advices V.I.P. sends the issuer’s

continually until all its advices individually until all
advices are retrieved. advices are sent or the
issuer sends a “sign off from
recovery” request.
For more rapid recovery, the (or) V.I.P. sends the issuer’s
issuer can optionally resond advices individually until all
to each advice. advices are sent.
21.7.1 Multiple Stations per PCR Option

If an issuer chooses to participate in the Multiple Stations per PCR option, it must send a
separate “sign on to recovery” message for each station participating in advice recovery.
If the issuer wants to have three stations actively processing advices, it must first send
three separate “sign on to recovery” messages. If the issuer chooses to retrieve its advices
more rapidly, it must respond to each advice that is received from each station.
NOTE
Visa does not require retesting for issuers that want to convert from the One Station per PCR retrieval method.
21.7.2 BASE II Advice Delivery (Offline)

V.I.P. places the BASE I advice file on an Event Tape Process (ETP) tape for transmission
to the BASE II System. BASE II programs the BASE I advices as TC 48 advices to enable
transmission of the advice data through the Interchange Transaction File and on to the
BASE II issuer. The BASE II issuer retrieves the data in machine-readable form or as a
printed report.

Issuers can select some of their BINs to retrieve advices online and can select other BINs
to retrieve advices through BASE II. However, issuers cannot set up the same BIN for both
the online and offline advice retrieval methods.
The BASE II System offers two TC 48 record formats for delivering BASE I advices:
Standard and Enriched. For information about both formats, refer to the BASE II Clearing
Interchange Formats manuals.
NOTE
The BASE II Advice Retrieval option delays receipt of advices until the next processing day.
21.7.3 Advice Retrieval During and After a VIC Switchover

Each VIC has its own BASE I advice file for the responses created by STIP at that VIC.
Under normal conditions, the file at the issuer's primary VIC contains all transactions
processed on the issuer's behalf. An issuer usually receives service through its primary
VIC. Conditions can occur, however, that cause the primary VIC to switch the issuer to a
back-up VIC for servicing.
Switchovers from a primary VIC to a back-up VIC can be planned (for instance, for a
network or systems test), or they can occur automatically when the primary VIC
experiences problems.
Whether planned or automatic, the switchover of VICs has impacts on advices stored in the
BASE I advice file, as explained in the next subsections.
21.7.3.1 VIC Processing Hierarchy

Each issuer’s PCR (Processing Control Record) has an associated VIC list that indicates
which VICs the issuer is connected to. In BASE I advice retrieval, the VIC list dictates the
processing hierarchy of which VIC is the primary VIC, which VIC is secondary back-up,
tertiary back-up etc. If the issuer’s primary VIC is down, the next available VIC in the
VIC list becomes the back-up VIC.
21.7.3.2 During Switchover

The next available VIC performs all VisaNet processing if the issuer's primary VIC becomes
unavailable.
During the switchover, V.I.P. stores advices in the advice file at the next available VIC.
Issuers that choose to recover advices during the switchover should be aware that some
advices may still be on file at the primary VIC. Issuers cannot recover these advices until
VisaNet switches them back to their primary VIC.
After the switchover, V.I.P. automatically delivers to the issuer any advices that the back-up
VIC created. After the switch back to the primary VIC, V.I.P. automatically delivers to the
issuer any remaining advices in the advice file at the primary VIC.
21.7.3.3 After Switchover

When VisaNet switches the issuer back to its primary VIC, the back-up VIC transfers all of
the advices it created to the primary VIC. If the issuer retrieves advices after the switch
back to the primary VIC, the advices can represent transactions processed at the primary
location, the back-up location, or at both locations.

NOTE
Issuers may not necessarily receive advices in chronological order.
21.8 MESSAGE FLOWS

When STIP handles an authorization (0100) or reversal (0400) request on behalf of the
issuer, it responds with an 0110 or 0410 message and creates an advice record (0120 or
0420) in the BASE I Advice File. V.I.P. stores the advice records in the BASE I Advice File
until the issuer retrieves the advices, for a maximum of 15 days.
Figure 21-2 illustrates the message flow for advice retrieval.

Figure 21-2 BASE I Advice Retrieval Service Message Flow
Issuer V.I.P.
0800 Sign-On Recovery Request 0800 Sign-On Recovery Request

Field 70: Advice Recovery Code 078 Field 70: Advice Recovery Code 078
0810 Sign-On Recovery Response 0810 Sign-On Recovery Response

0120, 0420 or 0620 Advice 0120, 0420 or 0620 Advice

Request Request
0130, 0430 or 0630 Advice 0130, 0430 or 0630 Advice

Response (Optional) Response (Optional)
0322 Advice Request 0322 Advice Request
0322 Advice Response (Optional) 0322 Advice Response (Optional)
0800 Sign-On Recovery Request 0800 Sign-On Recovery Request

(Optional) (Optional)
0810 Sign-Off Recovery Response 0810 Sign-Off Recovery Response



This section describes key fields associated with the BASE I Advice Retrieval Service.

This field appears in 0100 and 0400 requests and contains a code describing the
merchant's type of business product or service. The Visa International Operating
Regulations, as amended by additions and changes published in the VisaNet Business
Enhancements and Technical Letters for members, list valid codes.
If the code in Field 91—File Update Code is 1 or 2 in an 0300 request, VisaNet requires
that field 18 be present and must include the merchant category code.
Field 70—Network Management Information Code

This field contains a code that defines the type of network management needed:
- Network sign-on or sign-off
- Start or stop transmitting advices
- Communications link test between a VIC and the user
Table 21-1 lists BASE I and SMS advice recovery codes.
Table 21-1 BASE I Field 70 Advice Recovery Codes
Code Station Type Description

002 BASE I Sign off from V.I.P. System; terminate
BASE I processing
068 BASE I or CMI Start transmission of BASE I advices
069 BASE I or CMI Stop transmission of BASE I advices (in a
center-initiated message)
BASE I or CMI End of BASE I Advice File (in a
VIC-initiated message)
078 CMI Start transmission of both BASE I and
SMS advices
079 CMI Stop transmission of both BASE I and
SMS advices

For further information about the BASE I Advice Retrieval Service, refer to the following
documents:
• VisaNet Internal Certification Guide

Chapter 22 Advice Retrieval Service—SMS
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
IN BRIEF 22-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
VisaNet-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-6
Member-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-7
Advice Retrieval Service—SMS

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
HOW SMS ADVICE RETRIEVAL SERVICE WORKS 22-88
Creating SMS Advice Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-8
Receiving Advices in Batch File Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-8
Flexible Online Delivery of BASE II Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-9
Processing SMS Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-9
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
PROCESS FLOWS 22-99
Multiple Stations per PCR Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-11
Advice Retrieval During and After a VIC Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12
During Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12
After Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
MESSAGE FLOWS 22-12
12
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
13
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-
14


Chapter 22 Advice Retrieval Service—SMS
22.1 IN BRIEF
The SMS Advice Retrieval Service enables acquirers and issuers to retrieve (or to recover)
their stand-in processing (STIP) advice data from the SMS advice file.
The SMS Advice Retrieval Service is available to members in all Visa regions.
BASE I
SMS The SMS Advice Retrieval Service is mandatory for Single Message System
(SMS) users.

SMS only
I
Participation in the SMS Advice Retrieval Service is mandatory for SMS issuers.
Issuer
A Participation in the SMS Advice Retrieval Service is mandatory for SMS

acquirers.
Acquirer

The SMS Advice Retrieval Service enables acquirers and issuers to use online connections
to recover all types of advices from the SMS advice file. The service allows members
to decide when they want to retrieve advices so they can manage their advice volume
efficiently. The SMS advice file advice types include the following:
• STIP processing advices—Each VIC maintains an SMS advice file containing SMS STIP
authorization or reversal response records that include authorization or reversal request
information, the STIP responses, and the reasons why STIP processed the requests.
• STIP processing advices.
• Fraud reporting advices.
• BASE II deferred clearing advices—These advices originate from dual-message
acquirers that do not generate online clearing messages. Members that participate in
the Deferred Clearing Advice File (DCAF) Service can receive original BASE II clearing
transactions in batch file format. For DCAF Service information, see the Deferred
Clearing Advice File (DCAF) Service.

• SMS reversal and exception item processing advices.

• SMS file maintenance advices.
• SMS reconciliation totals advices.
• Funds transfer totals messages.
• BASE II transaction advices (deferred clearing advices).
NOTE
Service participants may retrieve their advice data online through their VisaNet connections
using one of the following methods:
One Station per Processing Center Record (PCR) Method—Method—For each V.I.P. connection
identifier (known as a PCR), a single station initiates a sign-on message to retrieve advices
from the advice queue, one at a time. The participant must respond to each advice
message before it can retrieve the next advice message.
Method—Using a single PCR, a processor can sign on to more

Multiple Stations per PCR Method—
than one station at a time to retrieve advices from the advice queue. This method allows
processors to retrieve their SMS advices much more quickly than they could from a single
station. Participants may continue advice retrieval from a single station through their
primary connection to VisaNet.
Service participants may retrieve deferred clearing advice data through V.I.P. on request.

This section contains the participation requirements for the SMS Advice Retrieval Service.
22.4.1 Testing
SMS Advice Retrieval Service testing is mandatory for all service participants that choose
to retrieve advices online.
The process requires testing to ensure that the member can successfully send and receive
the following messages:
• 0120 and 0130—STIP advices.
• 0220 and 0230—STIP advices.
• 0322 and 0332—Exception file update advices for the following services:
- Automatic Cardholder Database Update (Auto-CDB) Service. See the Automatic
Cardholder Database Update (Auto-CDB) Service, for information about this service.
- Merchant Fraud Performance Program.
- Global Customer Assistance Services (GCAS). For information about GCAS, members
can contact their Visa representatives.
• 0420 and 0430—Reversal advices.
• 0520—Reconciliation totals advices.
• 0620 and 0630—Funds transfer advices.
• 0800 and 0810—Advice Recovery mode sign-on and sign-off network management
messages.

SMS Advice Retrieval Service participants. Members can contact their Visa representatives
to make the arrangements.
NOTE
Visa does not require retesting for acquirers that want to convert from the One Station per PCR method
to the Multiple Stations per PCR retrieval method.

Service monitoring is not available for the SMS Advice Retrieval Service.

Service participants should consider the following key points to benefit fully from the service.
Advices—Participants can choose to recover advices throughout the day or

Recovering Advices—
only during certain periods.
Amounts—Participants should consider the impact of

Managing Cardholder Open-to-Buy Amounts—
STIP authorization on advice recovery processing. STIP advices reflect authorization
decisions that can affect the available funds in a cardholder's account. If an issuer restricts
advice recovery to only certain periods, it may find that account balances are insufficient to

cover the total value of issuer-approved and STIP-approved transactions.
Response—VisaNet must receive the response from

Same Station for Advice Retrieval and Response—
the same station that originated the request. Processors must ensure that the station that
sends the original advice sends the advice response back to VisaNet.
Option—Members can sign on to multiple stations per V.I.P.

Multiple Stations per PCR Option—
connection identifier (known as a Processing Center Record [PCR]) to speed up advice
recovery. Each member must analyze their VisaNet connection capacity for the following
factors before converting to the Multiple Stations per PCR option:
• Line speed
• Number of stations
• Host connectivity protocol
Members that still use a VAP may require a VAP upgrade to take advantage of this advice
retrieval option.
Traffic—Participants must be able to handle the increased

Increased Advice Message Traffic—
advice throughput. Processor host constraints may limit the number of stations that
participants can sign on to Advice Retrieval mode at one time.
Participants can discuss potential implementation problems with their Visa representatives.

The following messages pertain to the SMS Advice Retrieval Service.
There are two types of advices:

• VisaNet-generated advices
• Member-generated advices

22.5.1 VisaNet-Generated Advices

VisaNet-generated advices include:
Advice—This advice notifies an issuer that STIP has acted on

0220: STIP Processing Advice—
its behalf: STIP processed an 0200 financial transaction (original or adjustment); or
it responded to an 0200 balance inquiry, account transfer, resubmission, merchandise
credit, or downtime transaction. SMS STIP creates the advice for the issuer and stores it in
the advice file for the issuer to recover. The issuer must respond with an 0230 advice.
NOTE
Advice)—This advice notifies

0220: Advice of BASE II Transaction (Deferred Clearing Advice)—
an SMS issuer that BASE II processed a financial transaction from a BASE I acquirer.
SMS generates the advice on receipt of the transaction from BASE II and stores it in the
advice file for the issuer to recover. The issuer must respond with an 0230 advice.
Request—An SMS acquirer uses an 0220 message to

0220: Representment Validation Request—
submit a representment for Chargeback Reduction Service (CRS) validation. The acquirer
intends to re-present a financial transaction that the issuer charged back. The issuer
must respond with an 0230 advice.
Response—This message acknowledges receipt of

0230: Financial Transaction Advice Response—
an 0220 advice message.
Advice—Visa defines this message as a private-use message

0282: Representment Status Advice—
type that reports the results of CRS validation on representments. Receipt of this advice is
optional. If the acquirer sends this message, the issuer must send an 0292 response.
Response—Visa defines this advice as a private-use

0292: Representment Status Advice Response—
message type that acknowledges receipt of an 0282 representment status advice.
Advice—This message notifies an issuer that V.I.P. updated the

0322: File Maintenance Advice—
Cardholder Database file on the issuer's behalf; the advice includes the updated record
content.
Response—SMS issuers must send this response

0332: File Maintenance Advice Response—
message to acknowledge the receipt of an 0322 file maintenance advice. (BASE I issuers
that choose to receive 0322 file maintenance advices may optionally acknowledge their
receipt with these response messages.)
Advice—The issuer receives this advice when STIP processes an 0400

0420: Reversal Advice—
reversal on behalf of the issuer. The issuer must respond with an 0430 advice.
0430: Reversal Advice Response—

Response—This message acknowledges receipt of an 0420
reversal advice.
Advice—Members use this message for chargeback reversals,

0422: Chargeback Advice—
issuer fee collection or funds disbursement, advice of a BASE II transaction, chargeback
validation, and chargeback reversal validation. This advice requires an 0432 advice
response.

Response—This message acknowledges receipt of a

0432: Chargeback Advice Response—
chargeback, chargeback validation request, chargeback reversal, chargeback reversal
validation request, or issuer-initiated fee collection or funds disbursement.
Advice—Visa defines this message as a private-use message to

0480: Issuer Status Advice—
support CRS. The advice reports the results of CRS validation. Receipt of this message
type is optional for issuers. If V.I.P. sends this request, issuers must respond with an
0490 advice.
Response—This message acknowledges the issuer's receipt of

0490: Issuer Status Advice Response—
00,
an 0480 chargeback or chargeback reversal status advice. The response code must be 00
indicating acceptance of the 0480 advice.
Advice—This message is an advice that conveys gross

0520: Reconciliation Totals Advice—
interchange totals (the transaction totals SMS accumulated exclusive of transaction fees
and charges and any BASE II deferred clearing items) to an acquirer or to an issuer.
Response—This advice is the response to an

0530: Reconciliation Totals Advice Response—
0520 reconciliation advice. This reply indicates that the user agrees or disagrees with SMS
totals, or alternatively, that the user is simply acknowledging receipt of the totals.

Advice—This message includes copy request and administrative
0620: Administrative Advice—
free-text messages. This advice requires an 0630 response.
Response—This message is the response to an 0620

0630: Administrative Advice Response—
00.
administrative advice. The response code from an SMS center must be 00
22.5.2 Member-Generated Advices

Service participants (both issuers and acquirers) can retrieve member-generated advices
provided that the advices exist in the advice file. These member-generated advice types
include:
0220: Acquirer-Generated Original or Adjustment Financial Advice Usage 1a— An acquirer

creates this message to:
• Clear a financial transaction that was previously approved or does not require approval.
• Adjust a previously processed financial transaction.
00.
Issuers must respond with an 0230 advice. The response code must be 00
Only)—This advice applies when

0220: Good-Faith Collection Advice Usage 1b (Interlink Only)—
an issuer and an acquirer process a transaction that cannot be processed according to
standard Interlink procedures. Typically, issuers or acquirers use a good-faith collection
advice to process an adjustment, a chargeback, or a representment after the time limit
has expired. The issuer or the acquirer must respond with an 0230 advice response.
The response code must be 00 00.
0220: Representment Advice Response Usage 2— 2—This message is an advice from the
acquirer used to re-present a financial transaction that was charged back. The issuer must
respond with an 0230 advice response. The response code must be 00 00.

Chapter 22 How SMS Advice Retrieval Service Works
0220: Acquirer Fee Collection/Funds Disbursement Advice Usage 3— 3—This advice gives
notice that an acquirer is collecting or remitting a miscellaneous fee from or to an issuer.
This advice requires an 0230 advice response.
22.6 HOW SMS ADVICE RETRIEVAL SERVICE WORKS

This section explains advice message creation and the advice file, and contains the SMS
Advice Retrieval Service process flow and message flow.
22.6.1 Creating SMS Advice Messages

Acquirers, issuers, SMS STIP, or SMS itself can create advices. Additionally, V.I.P. stores
all incoming BASE II transactions as advices at the end of the offline clearing process.
These transactions can include financial and representment requests. Also, V.I.P. stores all
system-generated reversals as advices.
Acquirers use advices to deliver or to re-present financial transactions to issuers for

settlement and for account posting. In general, acquirers generate an advice when a
transaction does not require authorization processing either by the issuer or by STIP,
such as a representment. Subject to program operating rules, acquirers may also use an
advice instead of a request if they are unable to send the request in real time because of
communications problems.
Issuers use advices to charge back financial transactions or to initiate fee-related

transactions.
STIP uses advices to notify issuers of authorization and financial transactions processed
under stand-in conditions. An advice contains the request and the STIP response.
It provides the information the issuer needs for account maintenance and for settlement
of financial transactions.
SMS uses advices when supplying members with undeliverable approval responses,
settlement information, and status advices.
V.I.P. also uses advices for updating the SMS exception file. For information about the
exception file, see the Cardholder Database Overview chapter.
Advices—SMS issuers receive deferred clearing advices (0220s) when

Deferred Clearing Advices—
they acquire a clearing transaction in dual-message mode. Acquirers may submit deferred
clearing advices several days after authorization.
Several elements identify deferred clearing advices:

• Header field 10 contains code 255
255.
• Field 63.3—Message Reason Code contains 2105 2105.
• Field 63.4—STIP/Switch Reason Code contains 9100 or 9101
9101.
22.6.2 Receiving Advices in Batch File Format

Issuers that participate in the Deferred Clearing Advice File (DCAF) Service can choose
to retrieve deferred clearing advices in a file to alleviate capacity and resource contention
problems. Bulk file delivery uses network lines separate from online station lines.
This capability reduces issuers' online host and network capacity requirements and helps
members manage receipt of large volumes of advices.

For further information about DCAF, see the Deferred Clearing Advice File (DCAF) Service
chapter, the Deferred Clearing Advice File (DCAF) Service Technical Implementation
Guide, and the Deferred Clearing Advice File (DCAF) Service Technical Specifications
manual.
22.6.3 Flexible Online Delivery of BASE II Advices

Members can specify times for retrieving BASE II advices from online queues. Advices
from BASE II endpoints are available to SMS issuers shortly after they clear BASE II.
To facilitate different members' processing needs, SMS issuers can specify one of the
following options at the BIN level or at the processor level:
• Define a specific delivery time for advices from BASE II endpoints.
• Retrieve advices from BASE II endpoints as soon as they become available to V.I.P.,
currently as early as noon Pacific standard time (PST).
• Retrieve advices from BASE II endpoints at the standard system default time.
22.6.4 Processing SMS Messages

Service participants have two modes for message processing: Normal mode and Advice
Recovery mode. Issuers can have a station be in Normal (signed-on) mode, in Advice
Recovery mode, or in both modes concurrently.

Mode—Members can receive and can send real-time messages but cannot receive
Normal Mode—
advices from V.I.P.
Mode—V.I.P. sends advices (as it stores them in the SMS advice file)
Advice Recovery Mode—
to members.
Mode—Members can send and can receive real-time

Normal and Advice Recovery Mode—
messages as well as receive stored advices. The member “signs on to recovery” while it is
still signed on for normal message processing.
22.7 PROCESS FLOWS

The SMS advice retrieval process includes:
Processing—If the member chooses to operate only in

Signing Off From Request Processing—
Advice Recovery mode, it must sign off from request processing mode by sending an
0800 message with code 002 in Field 70—Network Management Information Code.
V.I.P. acknowledges the request by sending an 0810 message with code 002 in field 70.
Recovery—V.I.P. delivers SMS advices in the following priority

Signing On for Advice Recovery—
sequence:
• Priority 2: 0220 financial advices
• Priority 3: 0420 reversal advices
• Priority 4: 0520 reconciliation advices
• Priority 5: 0620 administrative advices
• Priority 6: BASE II transaction advices
To initiate advice retrieval, members submit an 0800 message with code 078 or 088
in field 70 to sign on to Advice Recovery mode. V.I.P. acknowledges the request by
sending an 0810 message with code 078 or 088 in field 70. Common Member Interface
(CMI) stations can use code 078 in field 70 to request transmission of both BASE I and
SMS advices. For more information about network messages, see V.I.P. System BASE I

Technical Specifications, Volume 1 and Volume 2, and V.I.P. System SMS POS (Visa &
Visa Electron) Technical Specifications, Volume 1 and Volume 2.
NOTE
Advice recovery does not interrupt authorization traffic. The same member station may be signed on for
normal traffic and for advice recovery at the same time.
When V.I.P. performs advice recovery for members that participate in the Positive
Authorization Capacity Management (PACM) Service, the system pauses or stops advice
recovery when the member reaches its processing capacity. As soon as processing returns
to below capacity, the system resumes advice recovery. For information about PACM,
refer to the Positive Authorization Capacity Management (PACM) Service chapter.
(Optional)—Members can choose to speed up the

Selecting More Rapid Advice Recovery (Optional)—
advice recovery process by having multiple stations “sign on to recovery.” See “Multiple
Stations per PCR Option” in this chapter for information.
Recovery—To stop (and to sign off from) Advice Recovery

Concluding Advice Recovery—
mode, the member can send an 0800 message with code 079 or 089 in field 70.
V.I.P. acknowledges the request by sending an 0810 message. To resume advice recovery
processing at a later time, the member must submit another “sign on to recovery” message.
Members can choose to remain in Advice Recovery mode after recovering all of their
advices from the SMS advice file so that they can recover advices as V.I.P. creates them.
NOTE
The system does not perform automatic sign-off after the member recovers the last advice in the file.
By default, members always remain signed on to Advice Recovery mode.
Processing—If the member is operating only in Advice

Signing Back On to Request Processing—
Recovery mode, it must sign on to Normal (request processing) mode by sending an
0800 message with code 001 in field 70. V.I.P. acknowledges the request by sending
an 0810 message.

Figure 22-1 illustrates the SMS Advice Retrieval Service process flow.
Figure 22-1 SMS Advice Retrieval Service Process Flow
V.I.P.
Acquirer Issuer
(or)
SMS
Advice
File
The member sends a V.I.P. acknowledges the

request to “sign on to member’s “sign on to
recovery.” recovery” request.
The member receives V.I.P. sends the member’s

advices individually. advices individually (by

priority).
The member sends a V.I.P. continually sends the

response to V.I.P. for each member’s advices until all
advice it receives. advices are sent.
Members can optionally V.I.P. ends the member’s

conclude their advice advice recovery session.
recovery session by
sending a “sign off from
recovery” message to V.I.P.
22.7.1 Multiple Stations per PCR Option

If a member chooses to participate in the Multiple Stations per PCR option, the processor
must send a separate “sign on to recovery” message for each station participating in advice
recovery.
If the member wants to have three stations actively processing advices, it must first send
three separate “sign on to recovery” messages. The member still needs to respond to each
advice individually before retrieving the next advice from the advice queue.

Service participants can contact their Visa representatives to convert from the One Station
per PCR option to the Multiple Stations per PCR option.
NOTE
Visa does not require retesting for acquirers or for issuers that want to convert from the One Station per
PCR retrieval method.
22.7.2 Advice Retrieval During and After a VIC Switchover

Each VIC has its own SMS advice file for the responses STIP creates at that VIC. Under
normal conditions, the file at the member's primary VIC includes advices for all of the
transactions STIP processed on the member's behalf. A member usually receives service
through its primary VIC. A member can choose to retrieve its advices both from the primary
VIC and from the secondary VIC, in which case V.I.P. delivers advices to both centers
simultaneously. Conditions may occur, however, that cause the primary VIC to switch
the member to the secondary VIC for servicing. Switchovers from a primary VIC to a
secondary VIC can be planned (for instance, for a network or systems test), or they can
occur automatically when the primary VIC experiences problems.
Whether planned or automatic, the switchover of VICs has impacts on advices V.I.P. stores
in the SMS advice file, as the next subsections describe.
22.7.2.1 During Switchover

The secondary VIC performs all VisaNet processing if the member's primary VIC becomes
unavailable.
During the switchover, V.I.P. stores advices in the advice file at the secondary VIC.
Members that choose to recover advices during the switchover should be aware that some
advices may still be on file at the primary VIC. Members cannot recover these advices until
VisaNet switches them back to the primary VIC.
22.7.2.2 After Switchover

When VisaNet switches a member back to its primary VIC, the secondary VIC transfers
all of the advices it created to the primary VIC. If the member retrieves advices after the
switch back to the primary VIC, the advices can re-present transactions processed at the
primary VIC, at the secondary VIC, or at both.
NOTE
Members may not necessarily receive advices in chronological order.
22.8 MESSAGE FLOWS

When SMS STIP handles a financial (0200) or reversal (0400) request on behalf of the
member, it responds with an 0210 or 0410 message and creates an advice record (0220
or 0420) in the SMS advice file. The advice records remain in the advice file until the
member retrieves them.
Figure 22-2 illustrates the message flow for SMS advice recovery.

NOTE
If possible, members should remain in Sign-On mode while retrieving advices.
Figure 22-2 SMS Advice Retrieval Service Message Flow
Acquirer Issuer V.I.P.
(or)
SMS
Advice
File
0800 Sign-On Recovery 0800 Sign-On Recovery

Request Request
Field 70 = 078 or 088 Field 70 = 078 or 088
0810 Sign-On Response 0810 Sign-On Response

Field 70 = 078 or 088 Field 70 = 078 or 088

Field 9: Message Status Flag Field 9: Message Status Flag
Field 63.4: STIP Reason Code Field 63.4: STIP Reason Code
0130 or 0430 Advice Response 0130 or 0430 Advice Response
0800 Sign-Off Recovery 0800 Sign-Off Recovery

Request Request
Field 70 = 079 or 089 Field 70 = 079 or 089
0810 Sign-Off Response 0810 Sign-Off Response

Field 70 = 079 or 089 Field 70 = 079 or 089

This section lists and describes key fields associated with the SMS Advice Retrieval
Service.

Header Field 9—Message Status Flags

This header field controls the processing of the message. It contains three bits V.I.P.
uses as advice-related flags. VisaNet sets the following flags, which the issuer or the
acquirer can examine during incoming message processing.
Advice-Created-by Flag:
1 = STIP-generated advice
0 = acquirer- or BASE II-generated advice
Advices-Pending Flag:
1 = advices pending recovery
0 = no advices pending
Advice-Transaction Flag:
1 = recovered advice
0 = not a recovered advice


Field 63.4 contains a code that identifies why SMS STIP responded for the issuer or
why SMS generated an advice. 0120, 0220, and 0420 advices, and all incoming
BASE II transactions contain this field. This field contains code 9100 or 9101 for
deferred clearing advices.

This field contains a code that defines the type of network management needed:
- Network sign-on or sign-off
- Start or stop transmitting advices
- Communications link test between a VIC and the user
Table 22-1 lists SMS advice recovery codes for field 70.
Table 22-1 SMS Field 70 Advice Recovery Codes
Code Station Type Description

078 Common Member Interface (CMI) Start transmission of BASE I and SMS advices
079 CMI Stop transmission of BASE I and SMS advices
088 SMS Start transmission of SMS advices
089 SMS Stop transmission of SMS advices

For further information about the SMS Advice Retrieval Service, refer to the following
documents:
• Deferred Clearing Advice File (DCAF) Service Technical Implementation Guide
• Deferred Clearing Advice File (DCAF) Service Technical Specifications


• V.I.P. System SMS Interlink Technical Specifications
and Volume 2
• V.I.P. System SMS POS Processing Specifications (U.S.)
• VisaNet Internal Certification Guide


Chapter 23 ATM Format Conversion Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
IN BRIEF 23-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
ATM Format Conversion Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4
Existing Card Range Considerations. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .23-4
New Card Range Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
HOW ATM FORMAT CONVERSION SERVICE WORKS

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
23-66
Message Augmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-6
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
PROCESS FLOWS 23-77
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
MESSAGE FLOWS 23-99
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
11
ATM Format Conversion Service

INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-
12


Chapter 23 ATM Format Conversion Service
23.1 IN BRIEF
Acquirers can choose to send ATM transactions either as single messages or as dual
messages. The ATM Format Conversion Service allows Single Message System (SMS)
issuers to receive all ATM transactions as single-message transactions.
V.I.P. supports both dual-message processing (authorization of transactions is requested

in a first message through the BASE I System, while financial clearing information is sent
in a second message through the BASE II System), and single-message processing
(the processing of interchange card transactions that contain authorization and clearing
information in a single message through SMS). Single messages are commonly referred
to as full financials.
The ATM Format Conversion Service offers SMS issuers the option of receiving all ATM
transactions as full financials, regardless of whether the acquirer uses dual-message
processing. For ATM Format Conversion Service participants, V.I.P. converts ATM
authorization requests from dual-message acquirers to full financials before it forwards
the requests to the SMS issuers.
The ATM Format Conversion Service is available to members in all Visa

regions.

BASE I
SMS The ATM Format Conversion Service is available to SMS users.
SMS only
I Participation in the ATM Format Conversion Service is optional for SMS issuers
in the Visa U.S.A. (U.S.) region. Participation in the service is required for
SMS issuers in all other Visa regions.
Issuer

The ATM Format Conversion Service converts Visa ATM 0100 authorization messages to
0200 financial ATM balance inquiry or cash disbursement messages before V.I.P. forwards
the transactions to participating SMS issuers.

NOTE
Plus international ATM transactions have always been converted from dual messages to full financials.
Members that issue proprietary Plus cards automatically participate in the ATM Format Conversion Service.
VisaNet authorizes, clears, and settles approved transactions with issuers on the same
settlement day it processes the authorization requests. This service description does not
include the processing for format conversion that V.I.P. performs for clearing transactions.
Members can contact their Visa representatives about processing ATM format-converted
reversals and exception item transactions.
23.3.1 ATM Format Conversion Service Options

Issuers can use the service for all ATM transactions or can specify by card range the
transactions it wants to receive as full financials.
EXAMPLE
An issuer may continue receiving credit card ATM cash advances as dual-message transactions, but can
receive its Visa check card ATM cash withdrawals as full-financial transactions.
Additionally, a member that issues cards that can access credit and deposit accounts may
choose to process credit cash advances as dual-message transactions, but can have
withdrawals from deposit accounts converted to full-financial transactions.

Participation in the ATM Format Conversion Service is optional for SMS issuers in the
U.S. region. Participation is required for SMS issuers in all other Visa regions.
23.4.1 Testing
Testing for this service is required for issuers before they can send and receive SMS Visa
ATM transactions. It is required for Plus issuers.

for ATM Format Conversion Service participants. Members can contact their Visa

Service monitoring is not available for the ATM Format Conversion Service.

Issuers must advise Visa of the card ranges participating in the service. Migration
requirements vary by region. Members can contact their Visa representatives for regional
specifics.
Members should consider the following key points in planning their implementation of the
ATM Format Conversion Service.
23.4.3.1 Existing Card Range Considerations

For established card ranges:
• All new card range considerations apply.
• For those existing card ranges experiencing approved transactions, issuers must specify
their service activation dates in V.I.P. system tables. V.I.P. looks at the activation date to

decide whether to convert the transaction or to route the transaction without conversion
as it did before the service was activated.
• Because of system cutoff timing, some transactions can post but not reach the issuer
at the same time. Cross-Systems Reconciliation (CSR) staff must manually process
adjustments for these transactions.
23.4.3.2 New Card Range Considerations

For new card ranges:
• Issuers must successfully complete testing to receive Visa 0200 transactions in V.I.P.
International Organization for Standardization (ISO) format.
• Issuers must complete a service participation request form confirming:
- The card range to be converted.
- Receipt of the ATM Format Conversion Service Activation Guide.
NOTE
Members can get the guide from their Visa representatives.
• Cross-Systems Reconciliation staff must review their changes and entries to the V.I.P.
system tables before service activation.
Members can contact their Visa representatives to make all service activation arrangements
and changes to their existing service specifications.

The following messages pertain to the ATM Format Conversion Service.
Authorization—V.I.P. converts this message to an 0200 cash disbursement request

0100: Authorization—
before it forwards the message to the issuer. The issuer must respond with an 0210
response.
Response—V.I.P. converts the 0210 response from the issuer to an 0110 response
0110: Response—

before it forwards the response to the acquirer.
Inquiry—V.I.P. converts this message to an 0200 balance inquiry request

0100: Balance Inquiry—
before it forwards the message to the issuer. The issuer must respond with an 0210
response.
Response—V.I.P. converts the 0210 response from the issuer to an 0110 response
0110: Response—
before it forwards the response to the acquirer.
Inquiry—V.I.P. converts a BASE I 0100 balance inquiry request to an SMS

0100: Balance Inquiry—
0200 balance inquiry request before it forwards the message to the issuer. The issuer must
respond with an 0210 response.
Response—V.I.P. converts the 0210 response to an 0110 response before it

0110: Response—
forwards the message to the acquirer.

Chapter 23 How ATM Format Conversion Service Works
Disbursement—V.I.P. converts a BASE I 0100 cash disbursement authorization

0200: Cash Disbursement—
request to an SMS 0200 cash disbursement request before it forwards the message to the
issuer. The issuer must respond with an 0210 response.
Response—V.I.P. converts this response to an 0110 response before it forwards the

0210: Response—
Reversal—V.I.P. converts this message to an SMS 0420 reversal before it

BASE I 0400: Reversal—
forwards the message to the issuer. The issuer must respond with an SMS 0410 reversal
response.
Response—V.I.P. converts the SMS 0410 response to a BASE I 0410

BASE I 0410: Response—
response before it forwards the response to the acquirer.
23.6 HOW ATM FORMAT CONVERSION SERVICE WORKS

The ATM Format Conversion Service converts BASE I 0100 authorization messages to
SMS 0200 financial request messages. It also converts BASE I 0400 reversals to SMS
0420 reversals. VisaNet reconverts the SMS responses to BASE I responses before it
forwards the responses to the acquirer.
VisaNet settles funds with the issuer before it receives a clearing transaction from the
acquirer. VisaNet holds the funds and the identifying transaction in suspense in a file
pending the clearing submission from the acquirer.
When VisaNet receives the BASE II clearing message (clearing record TC 07), it reconciles
the suspense file by matching the record with the information in the identifying transaction
held in suspense.
If VisaNet does not find an identifying transaction that matches the clearing message,
VisaNet returns the clearing message to the BASE II acquirer. If the acquirer does not
submit a clearing message that matches the identifying transaction held in suspense within
the number of days specified by the region, VisaNet generates a credit adjustment to the
SMS issuer to offset the previously settled cash withdrawal.
NOTE
VisaNet issues a credit adjustment to the issuer if a suspended cash withdrawal authorization remains
unmatched in the suspense file for more than the minimum number of days specified by the region and for
less than the maximum number of days specified by the region (for instance, more than 29 days and less
than 31 days).
23.6.1 Message Augmentation

Because the messages from dual-message acquirers originate as authorization-only
requests, in certain circumstances they do not contain all of the fields that single messages
contain. For service participants, V.I.P. must augment the converted messages with
required SMS fields and field values to meet the standards for full-financial messages.
V.I.P. augments the messages during conversion as follows:

• 0100 authorization to 0200 cash disbursement

If fields 12 and 13 are not sent by the acquirer, V.I.P. adds them using the value in field 7.
• 0100 balance inquiry to 0200 balance inquiry
If fields 12 and 13 are not sent by the acquirer, V.I.P. adds them using the value in field 7.
• BASE I 0400 reversal to SMS 0420 reversal (misdispense)
- V.I.P. sets the value in field 22 to 021x.
00.
- V.I.P. sets the code in field 25 to 00
- V.I.P. adds field 63.3.
- V.I.P. changes the trace number in field 11. Although the 0420 request has the same
trace number as the one in the original authorization request, SMS requires a new
trace adjustment.
- If fields 12 and 13 are not sent by the acquirer, V.I.P. adds them using the value
in field 7.
• BASE I 0400 reversal to SMS 0420 reversal
- V.I.P. adds field 63.3.
- If fields 12 and 13 are not sent by the acquirer, V.I.P. adds them using the value
in field 7.
Although BASE I rejects 0100 ATM Format Conversion authorization requests if the
field 43 subfields (43.1, 43.2, 43.3) are incorrect, BASE I does not reject 0400 ATM Format
Conversion reversals if they do not include the merchant name (subfield 43.1) or the
merchant location (subfield 43.2). The reversals must include subfield 43.3 country code;
otherwise, BASE I rejects the message. (BASE I rejects 0100 ATM requests if subfield 43.1
[merchant name] or subfield 43.2 [merchant location] are blanks or zeros, or if subfield 43.3
[country code] is missing, is filled with blanks or zeros, or is invalid.)
When the 0400 reversal is sent to SMS with only the subfield 43.3 country code, SMS
uses Field 19—Acquiring Institution Country Code to populate subfields 43.1 and 43.2
in the converted 0420 request. For instance, if field 19 indicates Australia, SMS sets

subfields 43.1, 43.2, and 43.3 as follows:
Subfield 43.1 Subfield 43.2 Subfield 43.3

ATM IN: AUSTRALIA AU (from the BASE I message)
23.7 PROCESS FLOWS

The process flow of an ATM withdrawal transaction from a dual-message acquirer to an
SMS issuer consists of the following steps.
1. The dual-message acquirer sends an 0100 ATM authorization request to V.I.P.
2. V.I.P. converts the 0100 message to an 0200 cash disbursement request and augments
the message with the required fields and field values.
3. V.I.P. forwards the 0200 request to the issuer. VisaNet holds the original message
and the transaction identifier in suspense.
4. The SMS issuer makes a decision to approve or to decline the request and returns an
0210 financial response to VisaNet. If the issuer approves the request, it may post the
financial transaction directly to the cardholder's account.
5. VisaNet receives the 0210 response from the issuer and matches it to the original 0200
financial request. V.I.P. converts the 0210 response to an 0110 authorization response
and forwards it to the dual-message acquirer.

6. The acquirer routes the 0110 authorization response back to the ATM, which disburses
the cash to the cardholder.
7. The dual-message acquirer submits the BASE II clearing record (TC 07) to VisaNet
within the next few days. VisaNet matches the TC 07 record with the original transaction
and the transaction identifier and clears the transaction. If VisaNet cannot match the
clearing record (TC 07) with a transaction held in the suspense file, it returns the TC 07
record to the acquirer as a returned item.
NOTE
The process flow is the same for a balance inquiry request, except that the issuer makes no approval
or decline decision, VisaNet does not match the response to the original request, there is no cash
disbursement, and no TC 07 record is generated. SMS issuers that do not support balance inquiries can
send Field 54—Additional Amounts in 0210 cash disbursement responses.
Figure 23-1 illustrates the basic ATM request transaction process flow.
Figure 23-1 ATM Format Conversion Service Process Flow
The acquirer submits the V.I.P. converts the request The issuer performs
0100 ATM request to V.I.P. to an 0200 financial standard processing and
request and forwards the returns the response to
request to the issuer. the acquirer.
VisaNet holds the original

message in suspense.
VisaNet matches the

response to the original
request and converts the
response to an 0110
response before V.I.P.
routes the issuer’s
The acquirer submits the VisaNet matches the TC 07

TC 07 clearing record to to the original message
VisaNet. in suspense and clears
the transaction.

23.8 MESSAGE FLOWS

Figure 23-2 illustrates the message flow when the acquirer submits an 0100 request.
After converting the request to an 0200 request, V.I.P. forwards the request to the issuer.
The issuer sends the 0210 response. After converting the request to an 0110 response,
V.I.P. forwards the response to the acquirer.
Figure 23-2 ATM Format Conversion Service Authorization Request Message Flow

Field 7: Transmission Date and Time Field 7: Transmission Date and Time Field 7: Transmission Date and Time
Field 12: Time, Local Transaction
Field 13: Time, Local Transaction


Figure 23-3 illustrates the message flow when the acquirer submits a BASE I 0400
reversal request for a misdispense. After converting the request to an SMS 0420 request,
V.I.P. forwards the request to the issuer. The issuer sends the SMS 0430 response.
After converting the response to an BASE I 0410 reversal response, V.I.P. forwards the
Figure 23-3 ATM Format Conversion Service Reversal (Misdispense) Request Message Flow
0400 Request (BASE I) 0400 Request (BASE I) 0420 Reversal (SMS)

Field 7: Transmission Date and Field 7: Transmission Date and Field 7: Transmission Date and
Time Time Time
Field 11: System Trace Audit Field 11: System Trace Audit Field 11: System Trace Audit
Number (with value "X") Number (with value "X") Number (with value "Y")
Field 19: Acquiring Institution Field 12: Time, Local Field 12: Time, Local
Country Code Transaction Transaction
Field 22: Point-of-Service Entry Field 13: Date, Local Field 13: Date, Local
Mode Code (with no value) Transaction Transaction
Field 25: Point-of-Service Field 19: Acquiring Institution Field 19: Acquiring Institution
Condition Code (with no value) Country Code Country Code
Field 43: Card Acceptor Field 22: Point-of-Service Entry Field 22: Point-of-Service Entry
Name/Location Mode Code (with no value) Mode Code (with value "021x")
Field 63.3: Message Reason Field 25: Point-of-Service Field 25: Point-of-Service
Code Condition Code (with no value) Condition Code (with value 00)
Field 43: Card Acceptor Field 43: Card Acceptor
Name/Location Name/Location
Field 63.3: Message Reason Field 63.3: Message Reason
Code Code
0410 Response (SMS) 0430 Response (SMS) 0430 Response (SMS)


Figure 23-4 illustrates the message flow when the acquirer submits a BASE I 0400 reversal
request. After converting the request to an SMS 0420 request, V.I.P. forwards the request
to the issuer. The issuer sends the SMS 0430 reversal response. After converting the
response to a BASE I 0410 reversal response, V.I.P. forwards the response to the acquirer.
Figure 23-4 ATM Format Conversion Service Reversal Request Message Flow
0400 Request (BASE I) 0400 Request (BASE I) 0420 Reversal (SMS)

Field 7: Transmission Date and Field 7: Transmission Date and Field 7: Transmission Date and
Time Time Time
Field 19: Acquiring Institution Field 12: Time, Local Field 12: Time, Local
Country Code Transaction Transaction
Field 43: Card Acceptor Field 13: Date, Local Field 13: Time, Local
Name/Location Transaction Transaction
Field 19: Acquiring Institution Field 19: Acquiring Institution
Country Code Country Code
Field 43: Card Acceptor Field 34: Card Acceptor
Name/Location Name/Location
Field 63.3: Message Reason
Code

0410 Response (SMS) 0430 Response (SMS) 0430 Response (SMS)

This section lists and describes key fields associated with the ATM Format Conversion
Service.
Field 7—Transmission Date and Time

This field contains the date and time that the transaction entered VisaNet.
Field 11—System Trace Audit Number

This field contains a number that uniquely identifies the transaction.

Field 12—Time, Local Transaction

This field contains the time the transaction occurs at the ATM in HHMMSS format.
Field 13—Date, Local Transaction

This field contains the date the transaction occurs at the ATM in MMDD format.
Field 19—Acquiring Institution Country Code

The value in this field identifies the country in which the acquirer resides.
Field 22—Point-of-Service Entry Mode Code

This field contains a code that identifies the method used to capture the account number
and expiration date and, if the method involves an electronic terminal, the code indicates
its capability to capture online PINs for transactions processed through VisaNet.

This field contains a code that identifies the transaction conditions at the point of service.

This field contains the name and the location of the ATM.
Field 61—Other Amount

In authorization requests, this field contains the cashback amount. It is not used for
ATM transactions and is removed by V.I.P. from the acquirer's request message when
it converts the message for the issuer.
Field 63.3—Message Reason Code

This field appears in any request or advice related to a customer transaction that
follows the original 0200 or 0220 message. It also appears in 0120 acquirer or STIP
authorization advices, and in STIP 0220 and 0420 advices. It does not appear in
responses.
The following codes are used only by issuers that participate in the ATM Format
Conversion Service:
2547—Indicates a potential duplicate financial transaction.

Code 2547—
2548—Indicates a duplicate (including retrieval reference number) financial

Code 2548—
transaction.

For more information about the ATM Format Conversion Service, refer to the following
documents:
• Single Message System (SMS) Service Activation Guide

Chapter 24 Card Verification Value (CVV) Service
FOREWORD.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
FOREWORD 24-33
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
IN BRIEF 24-44
CVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-4
dCVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-5
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
CVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-6
Generating and Encoding CVV and iCVV Values. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .24-6
Verifying the CVV or the iCVV. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-6
dCVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-8
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
Card Verification Value (CVV) Service

Issuer Participation Requirements (CVV and iCVV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-8
Acquirer Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-9
Testing for CVV and iCVV Service Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-10
Issuer Testing Requirements—Testing Plastics. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .24-10
Phases of the Issuer Testing Process. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .24-10
Acquirer Testing Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .24-12
Service Monitoring for CVV and iCVV Service Participation. . . . . . . . . . . . . . . . . . . . . . . . . .24-12
Issuer Monitoring Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .24-13
Acquirer Monitoring Requirements. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .24-13
Planning and Implementation (CVV and iCVV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-14
Planning and Implementation for Issuers. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .24-14
Planning and Implementation for Acquirers. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .24-17
Initiating Full Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-18
Acquirer and Issuer Participation Requirements—dCVV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-18
Acquirers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-19
Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-19
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
20
WORKS.. . . . . . . . . . . . . . . . . . . . . . .24-
HOW CARD VERIFICATION VALUE (CVV) SERVICE WORKS 24-20
20
CVV and iCVV Verification Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-22
CVV and iCVV Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-22
Invalid CVV Response Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-23
CVV Emergency Replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-23
CVV Emergency Replacement Error Codes. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .24-24

Chapter 24
MasterCard CVV Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-24

Application Transaction Counter (ATC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-24
WORKS.. . . . . . . . .24-
HOW DYNAMIC CARD VERIFICATION VALUE (DCVV) SERVICE WORKS 24-25
25
dCVV Processing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-26
STIP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-27
Emergency Replacement dCVV Cards. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .24-27
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
27
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-
30

Chapter 24 Card Verification Value (CVV) Service
24.1 FOREWORD
Visa offers two types of contactless cards:
• A magnetic stripe Visa card with an embedded contactless chip.
• A Visa Smart Debit/Smart Credit (VSDC) chip card that has a magnetic stripe and
supports a contactless chip.
NOTE
A contactless transaction is a transaction conducted using a contactless card over a wireless interface such
as radio frequency (RF) or infrared, at the point of service (POS).
CVV
A card verification value (CVV) is a unique value calculated from data encoded in the
magnetic stripe using the Data Encryption Standard (DES) algorithm. A CVV is a 3-digit
number that is stored in the following ways:
• It is encoded on the magnetic stripe located on the back of a credit or debit card.
• It is stored as an image in the “chip” of a Visa Smart Debit/Smart Credit (VSDC) card.

In VSDC chip cards, the magnetic stripe image (MSI) is stored in the contactless chip.
dCVV
A CVV can also be stored in a contactless chip card for contactless applications and is
referred to as a Dynamic Card Verification Value (dCVV). The dCVV is different from the
CVV. It is a unique 3-digit value calculated each time a contactless transaction is initiated
by Visa magnetic stripe data (MSD) contactless chip cards. A contactless transaction is a
transaction conducted over a wireless interface such as radio frequency (RF) or infrared,
at the point of service (POS).
Both the magnetic stripe and the magnetic stripe image (MSI) in the chip can contain the
same CVV. Therefore, VSDC issuers can choose to have CVV verification performed
using either of the following components:
• The magnetic stripe.
• The MSI in the chip.
• The magnetic strip and the MSI in the chip.
• The dCVV.
iCVV
VSDC issuers also have the option of choosing a 3-digit number that is different from the
CVV in the MSI. This alternate number is called an Integrated Chip Card card verification
value (iCVV); it is also referred to as an alternate CVV. The iCVV is a unique value
calculated from data encoded on the chip image using the DES algorithm. Therefore,
the CVVs in the magnetic stripe and in the MSI are identical, unless the MSI, in the chip
contains an iCVV.

Chapter 24 In Brief
NOTE
Members that want to accept and process VSDC chip cards for contactless transactions must participate in
the VSDC Service.
Issuers can include the contactless chip in VSDC chip cards or in non-VSDC magnetic
stripe Visa contactless cards. In a VSDC chip card, the contactless chip will contain
the dCVV algorithm as well as a CVV or an iCVV. In a non-VSDC magnetic stripe Visa
contactless card, the contactless chip will contain the dCVV algorithm and the CVV will
reside in the Track 1 or Track 2 magnetic stripe.
24.2 IN BRIEF
The Card Verification Value (CVV) Service and the Dynamic Card Verification Value
(dCVV) Service are point-of-sale or point-of-service (POS) and ATM risk control services
that protect issuers and acquirers from fraud losses associated with counterfeit Visa cards.
The Card Verification Value (CVV) Service verifies magnetic stripe-based CVVs and
chip-based CVVs and iCVVs. The Dynamic Card Verification Value (dCVV) Service verifies
dCVVs on contactless chip-based cards. V.I.P. processes dCVV-based transactions similar
to the way that it processes CVV and iCVV transactions. The differences between the
ways V.I.P. processes the three CVVs are minor. This service description explains how
CVVs, iCVVs, and dCVVs are processed, and where necessary, describes their processing
differences. It also explains how contactless chip cards work.
24.2.1 CVV Service

The CVV Service is a risk control service that provides protection for issuers and for
acquirers against magnetic stripe counterfeit. It allows issuers to detect invalid cards by
checking the content on a card’s magnetic stripe or in the MSI in the chip. The CVV Service
is a Visa verification service that is available through the VisaNet Integrated Payment
(V.I.P.) System. The CVV Service processes both CVVs and iCVVs. iCVV verification
protects against skimming of the MSI data from the chip to a counterfeit magnetic stripe
card.
CVV processing is successful under the following conditions:

• The POS and ATM environments support:
• Capture of the magnetic stripe.
• Capture of VSDC chip data, including the magnetic stripe image (MSI).
• Electronic authorization by V.I.P. or by the issuer.
• Acquirers provide complete, unaltered magnetic stripe data—either from the magnetic
stripe or from the MSI in the chip—in 0100 authorization messages and in 0200 financial
messages.
• The CVV is placed correctly on Track 2 of the magnetic stripe. The presence of padding
zeros does not matter.
• The content in the magnetic stripe and in the MSI in the chip are identical, unless the MSI
contains an iCVV.
IMPORTANT
In the event that information in the MSI has been used to create a fraudulent magnetic stripe, CVV verification
will fail if the magnetic stripe and MSI have different values, such as the CVV and the iCVV, respectively.

Chapter 24 In Brief
The CVV Service cannot be invoked:

• When either the issuer or the acquirer and their processing centers do not participate
in the service.
• For transactions for which the magnetic stripe or the chip was not read.
NOTE
This service description includes VSDC information to the extent necessary to explain iCVV. Refer to the Visa
Smart Debit/Smart Credit (VSDC) Service chapter in Volume 1 for more information about VSDC.
24.2.2 dCVV Service

The Dynamic Card Verification Value (dCVV) Service is a card verification value risk control
service for contactless chip-based card transactions. The dCVV Service processes dCVVs.
dCVV processing is successful under the following conditions:

• Participants in the dCVV Service also participate in the CVV Service.
• When issuer includes the contactless chip in VSDC chip cards or in non-VSDC magnetic
stripe Visa cards, the cards issued with the contactless chip adhere to Visa specifications,
including the use of the Visa-defined Issuer Discretionary Data (IDD) in Track 2 of the
contactless chip. This contains a contactless indicator that ensures correct processing
of the dCVV.

NOTE
The use of the contactless indicator applies only to U.S. issuers.
Contactless chips and the terminals that accommodate the contactless cards
communicate using wireless technology such as radio frequency (RF) or infrared.

Chapter 24 Eligible Participants
The CVV Service is available to members in all Visa regions.
BASE I
SMS The CVV Service is available to BASE I System users and to Single Message
System (SMS) users.
BASE I and SMS
I Participation in the CVV Service is mandatory for issuers of all Visa card
products.
Using iCVVs is optional for chip card issuers.

Issuer
A Acquirers of all Visa card products must provide complete, unaltered

magnetic stripe data (either from the magnetic stripe or from the chip) in 0100
authorization messages and in 0200 financial messages.
Acquirer

The CVV Service and dCVV Service are explained in this section.
24.4.1 CVV Service

CVV Service broadly comprises the tasks of generating, encoding, and verifying the values.
24.4.1.1 Generating and Encoding CVV and iCVV Values

Issuers encode a CVV on a card’s magnetic stripe using a cryptographic process that
requires a Data Encryption Standard (DES) key known to the issuer and, optionally, to Visa.
For VSDC cards, issuers encode the CVV or the iCVV in the MSI, in the chip using the
same DES key. The CVV and the iCVV values are calculated using the same formula,
with two exceptions:
• The CVV is calculated using a service code.
• The iCVV is calculated using a value of 999 instead of the service code.
24.4.1.2 Verifying the CVV or the iCVV

VIsaNet supports CVV checking of the physical magnetic stripe for the chip card as well
as the optional alternate iCVV checking for VSDC cards.
For all practical purposes, verifying the CVV from the magnetic stripe or from the MSI in
the chip and verifying the iCVV from the MSI, as well as member CVV Service options,
are the same. All options, parameters, and keys specified for CVV processing are used
to process iCVVs.

Issuers can choose to perform their own CVV or iCVV verification or to have V.I.P. perform
verification on their behalf. Also, issuers can choose to have V.I.P. verify the CVVs or the
iCVVs in all authorization requests or only in those processed by V.I.P. stand-in processing
(STIP).
If V.I.P. performs the verification, it verifies the CVV or the iCVV before it forwards the
authorization request to the issuer.
The issuer or V.I.P. verifies the CVV or the iCVV in the following manner:
• Uses the DES key, Primary Account Number (PAN), Card expiration date, and other
information from the track to calculate a CVV or an iCVV value. The algorithm for CVV
999.
uses a service code, while the algorithm for iCVV uses the value 999
• Compares the generated value to the encoded CVV value on the stripe or to the encoded
iCVV value in the MSI, in the chip.
The CVV is valid, if the generated CVV value exactly matches the encoded CVV value,
or the generated iCVV value exactly matches the encoded iCVV value. Otherwise, the
verification fails.
The CVV verification process fails, if any of the following conditions occur:
• MSD has been altered on the card.
• The iCVV value is received on a magnetic stripe-initiated transaction.

Issuers or V.I.P. can approve, refer, or decline transactions that fail CVV or iCVV
verification, depending on issuer-specified parameters.
The new iCVV calculation process poses minimal impact on existing systems that support
the generation and verification of CVVs.
For issuers that implement iCVV verification in addition to CVV verification, V.I.P. checks the
code in Field 22—Point-of-Service Entry Mode Code to determine which value to calculate.
• If the POS entry mode code is 90 90, which represents a magnetic stripe-initiated
transaction, V.I.P. or the issuer performs CVV verification.
• If the POS entry mode code is 05 05, which represents a chip-initiated transaction with
an iCVV, V.I.P. or the issuer substitutes the service code with 999 and performs iCVV
verification.
NOTE
The presence of code 90 in field 22 does not guarantee CVV processing. If a non-participating acquirer
submits code 90 in field 22, V.I.P. rejects the message.
NOTE
The service code on the MSI matches the service code on the physical magnetic stripe.
If iCVV value is received on a magnetic stripe-initiated transaction, and if the issuer uses
V.I.P. to verify the iCVV, V.I.P. declines these transactions. Issuers can, at their discretion,
implement risk-management software to identify magnetic stripe-initiated transactions with
failed CVVs that pass the iCVV verification process. This type of checking can help reveal
problems with fraudulent cards, suspicious merchants, or a merchant’s error in setting the
POS entry mode code, for instance, using code 90 instead of code 05 for chip-initiated
transactions with iCVVs.

Depending on issuer-specified options, STIP responds to CVV or iCVV failures or forwards

failures to the issuer for processing.
24.4.2 dCVV Service

The dCVV resides in the contactless Visa chip card. Contactless cards have the ability
to perform Visa transactions across a wireless interface at a physical POS terminal.
Contactless technology can operate on a range of wireless devices, such as chip cards,
mobile phones, and electronic keys.
• A contactless transaction is initiated when a VSDC or non-VSDC contactless chip card
detects that it is being read by a terminal that communicates with it using wireless
technology.
• dCVV processing begins. The contactless chip generates a CVV value unique to the
transaction and inserts it into the Track 1 or Track 2 magnetic stripe data. The dCVV
replaces any CVV data that may have been in the track data.
• This dCVV, along with other chip data, is transmitted to the POS or ATM terminal and
from there to the acquirer for submission to VisaNet in an authorization or financial
request.
• The ATC and the contactless indicator verify the dCVV.
• The participating issuer, or V.I.P. acting on the issuer’s behalf, generates a dCVV from
the request message and compares it with the dCVV in the request.
• If V.I.P. verifies the dCVV in the request, it uses field 44.5 to convey the results to the
issuer (fail = 1, pass = 2), depending on the issuer’s service participation settings.
Field 44.5 is also used to send dCVV result codes in responses to participating acquirers.
If a dCVV fails verification, V.I.P. does not check the CVV on the physical magnetic stripe;
it either declines the transaction, forwards it to available issuers, or sends it to STIP
for issuer-specified processing.

Participation requirements for the CVV Service vary depending on the card products
supported by individual issuers and acquirers. There are also differences in requirements
based on whether members are processing Visa, Plus, or Interlink transactions through
BASE I or through SMS.
IMPORTANT
Visa has migrated to the industry-standard Triple Data Encryption Standard (TDES). This change applies to all
Visa members and covers all PIN-based Visa credit and debit, Interlink, and Plus transactions processed
through VisaNet. Refer to the Payment Technology Standards Manual for further information.
This section summarizes CVV participation requirements. For further clarification,

members can contact their Visa representatives.
24.5.1 Issuer Participation Requirements (CVV and iCVV)

To participate in the CVV Service, issuers must:
• Demonstrate that CVVs and iCVVs are correctly calculated.
• Demonstrate that CVVs are placed correctly on the magnetic stripe and in the MSI, and
that iCVVs, if participating, are placed correctly in the MSI.
• Ensure that CVVs and iCVVs have valid expiration dates.
• Generate DES keys.
• Select a CVV processing option.

Table 24-1 lists the activities that issuers must perform to participate in the CVV Service.
Table 24-1 Issuer Participation Activities
Participation
Requirement Issuer Action
Card Encoding Issuers must:
• Add the CVV to all cards, and the iCVV if participating.
NOTE:
Encoding the CVV is allowed but is not required on proprietary Plus ATM
cards.
• Inform Visa of the CVV start date.

• Inform Visa if CVVs are desired on emergency replacement cards
issued by the Visa International Service Center (VISC).
DES Keys DES key issuers must generate a pair of DES keys and optionally supply
them to Visa on a Key Conveyance Form. Issuers can also request that
Visa generate a pair of DES keys on their behalf.
Refer to the Payment Technology Standards Manual for further

information about using this form.
CVV Verification Issuers must choose between four CVV processing options, depending

on whether the issuer is verifying the CVV or the iCVV, or if V.I.P. is
verifying the CVV or the iCVV on the issuer's behalf:
ALL—V.I.P. verifies the CVV or the iCVV on all eligible transactions and
ALL—
forwards the results to the issuer in the request messages.
RESPOND—V.I.P. verifies the CVV or the iCVV on all eligible

ALL RESPOND—
transactions. If the verification fails, V.I.P. responds to the acquirer using
the issuer's invalid CVV response code (or a more severe response
code determined by STIP, if applicable). V.I.P. also creates an advice
informing the issuer of the CVV results.
ONLY—V.I.P. verifies the CVV or the iCVV when the transaction

STIP ONLY—
is processed by STIP. If verification fails, and if no other, more severe
response code is assigned to the transaction, STIP responds to the
acquirer with the issuer-provided CVV invalid response code and indicates
that the CVV or the iCVV verification failed in the advice to the issuer.
NONE—The issuer verifies all CVVs or iCVVs. If the issuer is unavailable,

NONE—
STIP does not check the CVV or the iCVV.
NOTE:
The STIP ONLY and NONE options are not available in the Asia-Pacific region.
Members can contact their Visa representatives for more information.
24.5.2 Acquirer Participation Requirements

To participate in the CVV Service, acquirers must demonstrate the ability to:
• Transmit complete, unaltered magnetic stripe content on Track 1, on Track 2, or on both,
containing code 90 in field 22, from all terminal types.
• Receive reject code 0142 with all terminal types. (This requirement varies by region.)
• Receive Field 44.5—CVV/iCVV Results Code, if they select that option.

24.5.3 Testing for CVV and iCVV Service Participation

Testing demonstrates the ability to support CVV Service requirements. All issuers and
acquirers must successfully complete testing to participate. Testing requirements exist both
for issuers and for acquirers, although these requirements vary by region.
This section summarizes testing requirements.
24.5.3.1 Issuer Testing Requirements—Testing Plastics

Issuers must generally provide test plastics to Visa for testing, depending on regional
preferences. CVVs must be encoded on Track 1, on Track 2, or on both according to the
specifications in the Payment Technology Standards Manual. Requirements for supplying
test plastics vary by region.
Cards must be labeled “Valid” or “Invalid” as appropriate and must be received by Visa five
days before the test date. Visa may request additional cards if necessary.
Issuers—Issuers must generally provide three test cards, depending on regional

BASE I Issuers—
preferences. Two cards must have valid CVVs, and the third must have an incorrectly
calculated or improperly located CVV.
All test cards must have the same expiration date, equal to or later than the date established
on the Member Information Questionnaire (MIQ). The expiration dates must be at least a
few months in the future of any existing card issued to cardholders.
Visa does not return test cards. Members can contact their Visa representatives to get
a copy of the MIQ and testing specifics.
SMS Issuers—
Issuers—Issuers must generally provide four test cards, depending on regional
preferences. Three cards must have valid CVVs, and the fourth must have an incorrectly
calculated or improperly located CVV.
All four cards must have the same expiration date, equal to or later than the date
established on the MIQ.
Visa returns test cards after testing is complete.
24.5.3.2 Phases of the Issuer Testing Process

Issuer testing for participation in the CVV Service is a two-phase process.
Phase I Testing
Phase I is optional, depending on regional requirements. Visa recommends, however,
that issuers complete Phase I and Phase II at the same time to prevent issuing cards
with invalid keys.
Phase I testing confirms that the issuer is correctly calculating the CVVs and is correctly
locating the values on the test cards. Each issuer must pass Phase I for each unique set
of encryption keys and displacements to be used. If the issuer uses the same keys and
displacements across several BINs, a single phase testing is acceptable.

IMPORTANT
Phase I testing only verifies that the CVV is correctly encoded in the proper track location. Phase I does
not constitute a complete CVV testing.
Phase II Testing
Phase II is the online testing phase, confirming that the issuer's systems can meet the
processing requirements for the issuer's chosen options.
Visa uses the issuer-supplied plastics for two sets of testing:
Testing—The CVV is properly encoded using the keys loaded

Phase IIA, Key and Advice Testing—
into VisaNet. The issuer can receive advices containing CVV information.
Testing—Transactions are generated to verify that the

Phase IIB, Stripe and Response Testing—
issuer can accept code 90 in Field 22—Point-of-Service Entry Mode Code, and can
generate the appropriate values in response messages.
NOTE
Testing specifics vary by region.
Situations for Which Additional Testing Is Recommended

Once an issuer has successfully completed testing, Visa recommends separate testing for
cards being issued that use different BINs, encryption keys, or displacements. Retesting
requirements vary according to issuer circumstances and to the new cards being issued.
BIN—Issuers wanting to add additional BINs using previously tested

Adding an Additional BIN—
keys and displacements can submit a single card for the new BIN for testing. One card can
be used to test up to 200 BINs or BIN ranges as long as the displacement and keys are the
same and a detailed list of BINs or BIN ranges is included.
BIN—Visa strongly recommends testing for issuers adding a new BIN using
Adding a New BIN—
new keys or displacements, or adding additional keys or displacements to an existing BIN.
The testing involves new test plastics and certification testing.
In both cases, once the separate Phase IIB testing is successfully completed, Visa does
not require additional Phase IIB testing when issuers add new BINs or keys. Table 24-2
lists testing requirements.
Table 24-2 Issuer Testing Requirements
Phase I Phase IIB

Testing Required? Phase IIA Required? Required?
BASE I: Initial Testing Optional Yes Yes
BASE I: Additional BINs, Same Keys Optional Yes (keys only) No
BASE I: Additional BINs, New Keys Optional Yes (keys and advices) No
SMS: Initial Testing Yes Yes Yes
SMS: Additional BINs, Same Keys Optional Yes (keys only) No
SMS: Additional BINs, New Keys Yes Yes (keys and advices) No

24.5.3.3 Acquirer Testing Requirements

Acquirer testing verifies that the acquirer has:
• Demonstrated the ability to transmit complete, unaltered magnetic stripe content on
Track 1, on Track 2, or on both, containing code 90 in field 22, from all terminal types.
• Demonstrated the ability to receive reject code 0142 with all terminal types.
(This requirement varies by region.)
• Demonstrated the ability to receive Field 44.5—CVV/iCVV Results Code, if it selects
that option.
Visa may waive testing for both tracks if an acquirer can demonstrate, and confirm in
writing, that all of its equipment captures only one of the two tracks. Acquirers must notify
Visa when this situation changes.
Testing requirements for CVV and for iCVV vary by region. Generally, to test, acquirers
must execute Visa-supplied scripts using Visa-supplied test cards on the acquirer's
production system. One of the Visa-supplied test cards contains an invalid CVV; the others
contain valid ones. All cards have the same expiration date. Acquirers completing partial
testing as part of their initial service rollout are required only to complete the relevant steps.
IMPORTANT
Acquirers must use a physical device to perform testing. Visa cannot accept simulations or manual creation of
data.
Although each region determines its own testing requirements, acquirers must usually
include testing with a manually keyed transaction. Although the CVV Service does not
apply to key-entered transactions, testing ensures that manually keyed transactions contain
required data indicating that the full magnetic stripe was not read.
For further VSDC testing, monitoring, and participation information, see the Visa
Smart Debit/Smart Credit Service chapter in Volume 1. Refer to the VSDC Member
Implementation Guide for Acquirers, to the VSDC Member Implementation Guide for
Issuers, and to the VisaNet Certification Management Service Testing Guide, V.I.P.
System, Client Version for complete details. Also see the statement in “CVV Emergency
Replacement” in this chapter.
24.5.4 Service Monitoring for CVV and iCVV Service Participation

Once successfully tested, the issuer or the acquirer may enter a monitoring period, during
which Visa monitors CVV values and system responses to ensure that the participant is
adhering to CVV processing requirements. The monitoring phase begins within one week
of the successful tests.
Monitoring requirements vary by region.

• Monitoring is required in some regions before members can fully participate in the CVV
Service to process Visa POS transactions.
• Monitoring is not required before full participation in the CVV Service to process the
following transactions:
- Interlink
- Visa ATM
- Plus ATM

24.5.4.1 Issuer Monitoring Requirements

After issuers complete testing, Visa monitors issuers to identify problems.
Issuers already participating in the CVV Service that want to add BINs may optionally
undergo minimal monitoring of the new BINs to ensure magnetic stripe data integrity.
Table 24-3 lists the issuer monitoring activities V.I.P. performs.
Table 24-3 V.I.P. Monitoring of Issuer CVV Processing
If Field 22 Contains 90 or 05... If Field 22 Contains 02 or 95...

1. V.I.P. checks CVV or iCVV encoding. 1. V.I.P. checks CVV or iCVV encoding.
2. V.I.P. checks the accuracy of DES keys 2. V.I.P. checks the accuracy of DES keys
supplied to Visa by the issuer. supplied to Visa by the issuer.
3. V.I.P. tests the ability of the issuer's 3. V.I.P. tests the ability of the issuer's
system to support CVV processing. system to support CVV processing.
4. V.I.P. performs no online action. 4. V.I.P. forwards transactions to available
issuers.
5. V.I.P. provides no indication of CVV
checking to the issuer.

Visa representatives keep issuers informed of their status during the monitoring phase.
Monitoring is successful when Visa determines that:

• Issuer CVV checking for all authorization requests is correct.
• Invalid CVVs are the result of counterfeit activity or of acquirer error.
24.5.4.2 Acquirer Monitoring Requirements

After completing testing, acquirers may optionally enter a monitoring phase.
Monitoring requirements vary by region. The monitoring ensures that:
• magnetic stripes are properly captured and properly transmitted.
• Transactions are properly flagged for complete, unaltered, magnetic stripe content.
Table 24-4 lists the acquirer monitoring activities V.I.P. performs.
Table 24-4 V.I.P. Monitoring of Acquirer CVV Processing
V.I.P. Monitors Benchmark

CVVs for all eligible authorization requests from All acquired transactions consistently transmit
acquirers that have successfully completed the complete, unaltered magnetic stripe when
testing to send code 90 or code 05 in field 22. 05.
the value in field 22 = 90 or 05
The acquirer's BIN-level processing reports to No discrepancies or CVV failures.
ensure that there are no adverse impacts on
cardholders and on merchants. NOTE:
Visa and issuer staff research instances of
CVV failure to determine if there is a confirmed
counterfeit card or an acquirer problem.
Visa considers acquirer monitoring successful when:

• There is complete, unaltered magnetic stripe content when the value in field 22 is 90
05.
or is 05
• All checked CVVs are either correct, or invalid CVVs are the result of counterfeit activity
or of issuer encoding problems.
24.5.5 Planning and Implementation (CVV and iCVV)

This section describes the various planning and implementation tasks that issuers and
acquirers must complete to implement the CVV Service.
24.5.5.1 Planning and Implementation for Issuers

To prepare for CVV Service participation, issuers must first:
• Choose the location for the CVVs on the stripes and inform Visa of the location.
• Calculate and encode CVVs on their magnetic stripes, and on their MSIs if participating.
• Calculate and encode iCVVs in their MSIs, if participating.
• Establish the service start date.
Issuers optionally provide Visa with DES working keys.
Placing the CVV on the magnetic stripe and Chip Image

Visa issuers are responsible for calculating and for encoding an identical CVV on Tracks 1
and 2 of the magnetic stripe, and on the MSI if participating.
Issuers must encode the CVV according to the established Visa standard for CVV
calculation and CVV placement on the magnetic stripe or in the MSI.
NOTE
CVV processing is performed only if the CVV is positioned correctly on the track.
Issuers can generate the 3-digit CVV by one of two methods:

• Using a Visa Security Module (VSM), which communicates with the issuer's host system.
• Using their own programs that use the Visa algorithm for computing the CVV, if they
do not use a VSM.
Refer to the Card Verification Value (CVV) chapter of the Payment Technology Standards
Manual for full specifications for physical characteristics of CVVs, track contents, and
calculation methods.
Establishing the Service Start Date

The card expiration date determines whether a transaction is eligible for CVV Service
processing. Issuers must inform Visa of the CVV start date. This start date is equivalent to
the earliest expiration date of cards on which to apply CVV Service processing logic. All
new and reissued cards, including emergency replacement cards, that have an expiration
date equal to or greater than the CVV start date must be encoded with a CVV, or iCVV
if participating.
By using a second, later expiration date, issuers can encode cards with a CVV or an iCVV
that relates to a second set of encryption keys and is tied to a second start date.
Issuers have the option of specifying two date ranges to be used for CVV Service checking.
Issuers relate each date range to a CVV start date and to a set of processing parameters,
including CVV keys and CVV displacement specifics on Track 2 of the magnetic stripe.

By having two sets of parameters, issuers have the ability to vary encryption keys and the
placement of the CVV when they issue new cards.
These two sets of parameters are referred to as Set A and Set B. Table 24-5 indicates
V.I.P. processing for the two sets of cards.
Table 24-5 Set A and Set B Parameter Processing
If... Then...
The expiration dates are later than the CVV V.I.P. processes the CVV or the iCVV according
start date for Set A but are earlier than the start to Set A parameters.
date for Set B...
The expiration dates are later than the CVV start V.I.P. processes the CVV or the iCVV according
date for Set B... to Set B parameters.
For fraud prevention, Visa recommends that issuers issuing cards on a new BIN (never
before used to issue cards) indicate the expiration month as the current month rather than
as the earliest expiration date of the cards issued.
Providing CVV Working Keys

The issuer must provide Visa with a pair of Data Encryption Standard (DES) keys to be
used to generate and to verify the CVV, and the iCVV if participating. The issuer sends

these keys to VisaNet under the issuer's existing Zone Control Master Key (ZCMK). Refer
to the Payment Technology Standards Manual for more information.
IMPORTANT
Visa recommends that the issuer not use the same verification keys for CVVs as those used for PIN
Verification Values (PVVs) with the PIN Verification Service. If the common keys were compromised, it would
affect both the issuer's PVVs and CVVs.
However, Visa does recommend that issuers use the same verification keys for CVVs as
they do for Card Verification Value 2s (CVV2s). Refer to Chapter 25, Card Verification
Value 2 (CVV2) Service, in this manual for information about CVV2s.
Table 24-6 summarizes the implementation activities that issuers may be required to
complete to use the CVV Service to process Visa POS, Interlink, and ATM (both Visa
and Plus) transactions. Required activities vary by region. Issuers can contact their Visa
representatives for region-specific requirements.
Table 24-6 Issuer Implementation Activities
Type of Issuer
Implementation
Activity Visa POS Interlink Visa ATM and Plus
Encode the CVV on Both Track 1 and Track 2 Both Track 1 and
the magnetic stripe, Track 2 Track 2
and on the chip if
participating.
Supply Visa with Yes Yes Yes
DES keys for STIP
processing.

Table 24-6 Issuer Implementation Activities (continued)

Type of Issuer
Implementation
Activity Visa POS Interlink Visa ATM and Plus
Receive the specified Response code 82 Response code N6 Response code 82
negative CVV (BASE I and SMS (SMS issuers only) (SMS issuers only)
verification result in issuers)
field 39, if the issuer
chooses not to receive
the result in field 44.5.
NOTE:
Visa highly
recommends that
issuers successfully
complete testing to
receive CVV results
in field 44.5, rather
than in field 39.
(Optional) Receive Select option. Valid Select option. Valid Select option. Valid
positive or negative codes are: codes are: codes are:
CVV verification
results in field 44.5. 1 = The transaction 1 = The transaction 1 = The transaction
failed CVV verification. failed CVV verification. failed CVV verification.

NOTE:
Testing is required for 2 = The transaction 2 = The transaction 2 = The transaction
this option. passed CVV passed CVV passed CVV
verification. verification. verification.
3 = The transaction Space = The CVV was Space = The CVV was
passed CVV not tested. not tested.
verification. (This
value is used only
for emergency
replacement cards
issued by Global
Customer Assistance
Services [GCAS]).
Space = The CVV was

not tested.
Choose one of the Choose from: Choose from: Choose from:
specified invalid CVV
response codes for 00 = Approve 00 = Approve 00 = Approve
STIP processing. 01 = Refer to issuer 05 = Decline 04 = Pick-up card
04 = Pick-up card transaction 05 = Decline
05 = Decline transaction
transaction
Accept the 90 90 90, 02
90 02, 05
05, 95
specified values in
Field 22—Point-of- 05 NOTE:
Service Entry Mode V.I.P. converts
90.
code 02 to 90
Code.
Receive advices of Yes Yes Yes

STIP CVV checking.

24.5.5.2 Planning and Implementation for Acquirers

Acquirer processors must modify their systems in certain situations (described below).
• For CVV checking on magnetic stripe transactions, transmit complete, unaltered magnetic
stripe content on Track 1, on Track 2, or on both, and in the MSI (if participating),
containing code 90 in field 22 for all terminal types. The presence of code 90 in field 22
does not guarantee CVV processing. If a non-participating acquirer submits code 90 in
field 22, V.I.P. rejects the message.
• For CVV or for iCVV checking on chip transactions, transmit complete, unaltered magnetic
stripe content from the chip image, containing code 05 in field 22 for all terminal types.
• Receive reject code 0142 with all terminal types.
Acquirers must prepare a CVV enrollment form for contact information and complete a
Global Client Testing Questionnaire for scheduling implementation activities.
New terminal software or download loads may be required to support the capture and the
transmittal of the complete, unaltered magnetic stripe content and its associated indicator.
Table 24-7 summarizes the implementation activities that acquirers must complete to use
the CVV Service to process Visa POS, Interlink, and ATM (both Visa and Plus) transactions.
Table 24-7 Acquirer Implementation Activities

Type of Acquirer
Implementation Activity Visa POS Interlink Visa ATM and Plus
Test that systems can Yes No, because: No, because:
transmit complete, unaltered • Track 1—not • Track 1—not
Track 1 and Track 2 magnetic applicable applicable
stripe content. • Track 2—Interlink • Track 2—Visa
acquirers have ATM and Plus
successfully acquirers have
completed testing successfully
that complete completd testing
Track 2 data can that complete
be sent. Track 2 data can
be sent.
Send the specified value 90 or 05 if 90 90, 02
90 02, or 05
05, 95
in field 22 to indicate that chip-initiated
complete, unaltered magnetic NOTE: Visa recommends
stripe data is included in the V.I.P. converts using a value of 90
90.
code 02 to 90 or 05 to ensure
message.
consistency across
A value of 90 is multiple acceptance
required in the environments.1
Asia-Pacific (AP)
A value of 90 is
region.
required in the AP
region.
Send full Track 2 Yes Yes Yes
data; otherwise, no
counterfeit-stripe
chargebacks are allowed.

Table 24-7 Acquirer Implementation Activities (continued)

Type of Acquirer
Implementation Activity Visa POS Interlink Visa ATM and Plus
Must be monitored before full Varies by region Varies by region Varies by region
participation.
Accept reject header Yes Yes Yes
code 0142 (field 22 = 90
or 91 but no track data is
present).
1. Unless code 90 or 05 is present in ATM transactions originating from a BASE I acquirer, the Plus CVV Service is not
able to verify the CVV or the iCVV on behalf of the issuer.
24.5.5.3 Initiating Full Participation

Visa notifies the issuer and the acquirer (in writing) of the CVV Service participation
start date. Visa sets the issuer and the acquirer BINs to Participating mode in the V.I.P.
system tables.
IMPORTANT
Issuers and acquirers that fail to maintain compliance must rectify the situation immediately or they will be
subject to removal from Participating mode until the problem is resolved.
Acquirers must ensure that their merchants comply with the CVV Service requirements.
For further CVV Service testing, monitoring, and participation information, refer to the Card
Verification Value (CVV) Member Implementation Guide.
24.5.6 Acquirer and Issuer Participation Requirements—dCVV

The acquirer and issuer dCVV participation requirements in this section are summaries
from the Visa U.S.A. Contactless Payment Program Technical Implementation Guide.
Refer to that publication for detailed information. Members can contact their Visa
representatives for a copy of this publication.
Visa-Defined Issuer Discretionary Data (IDD)

Participating issuers must reissue new contactless cards that include the IDD in Track 2
data in the chip. The IDD in the contactless card is used to ensure accurate processing of
the dCVV at the initiation of a transaction.
Issuers use a contactless indicator sent from the contactless card in the authorization
message to identify contactless transactions. Issuers set the value for the contactless
indicator in the last nibble of the IDD field in Track 2 in the chip card. This value must not
equal 0 (zero) or space. A value other than 0 or space indicates that the POS payment is a
contactless transaction.
Issuers may continue to use the IDD field in Track 2 data in the physical magnetic stripe.
However, issuers must not use the last nibble of the IDD field in the physical magnetic
stripe as it reserved for contactless cards.
Acquirers and issuers that want to participate in the Contactless Payment Program must
modify their systems to:

• Participate in the CVV Service.

• Support the new POS entry mode code values.
• Provide the capability to process the unique value of the IDD that was provided
by the contactless chip card in the authorization in Field 35—Track 2 Data or in
Field 45—Track 1 Data.
• Process dCVVs for Track 1 or Track 2 data in contactless transactions.
• Support the ATC in field 35 or field 45 for online transactions.
• Support POS entry mode value 91 (contactless chip transaction using magnetic stripe
rules).
• Support Field 60.2—Terminal Entry Capability value 8 for contactless transactions.
• Support processing capabilities for BASE I or SMS message types. Interlink messages
also require support.
• Issue new card program for contactless transactions with chip data provided by the
chip card.
24.5.6.1 Acquirers
Participating acquirers must support the full set of transactions initiated for the contactless
program and responses from participating issuers and from VisaNet.
Acquirers that want to use the service must comply with Visa participation requirements
for BASE I and SMS transactions.

• Support the new POS entry mode code value 91 in field 22.
• Provide the ability to pass the unique value of Visa-defined Issuer Discretionary Data
(IDD) that is provided by the contactless chip card in the authorization in field 35 or
in field 45.
• Send the ATC in field 35 or in field 45.
• For SMS processing, send all the data necessary to authorize, clear, and settle
transactions with a single online message.
• For BASE I processing, send all the data necessary to authorize transactions. Clearing
and settlement is completed during BASE II processing.
Visa contactless cards can be used either for contactless transactions (at this time,
POS transactions) or magnetic stripe transactions.
Refer to the Visa U.S.A. Contactless Payment Program Technical Implementation Guide
for further information.
24.5.6.2 Issuers
Issuers participating in the service must support the full set of transactions. Issuers must
continue to support existing online fields and processing requirements including unique
values that are used to identify contactless transactions.
Participating issuers must comply with the following general Visa participation requirements
for contactless chip cards. The contactless chip cards must have the capability to support
both contactless payment processing and the normal point-of-sale processing of magnetic
stripe transactions.
• Support the new POS entry mode code value 91 in field 22.
• Establish the capability to support dCVV data including the unique value of the IDD that is
provided by the contactless chip card in the authorization in field 35 or in field 45.

• Establish a contactless processing BIN to support the new card program for contactless
payment.
• Support changes for contactless payment processing in BASE I, SMS, and Interlink
transactions.
• Provide Visa with a STIP default response code; 00 (approval) is not allowed.
Issuers participating in the contactless program must establish a BIN that supports both
contactless payment and magnetic stripe transactions.
Issuers participating in the service must reissue new contactless cards that support both
magnetic stripe and contactless transactions for acceptance at the point of sale.
Any Visa credit or debit card may be issued with a contactless chip in accordance with the
standards published by Visa. The Visa contactless chip cards must contain:
• A magnetic stripe with an embedded contactless chip.
• A dCVV embedded in the magnetic stripe data in the last 4 bytes of the IDD.
Refer to the Visa U.S.A. Contactless Payment Program Technical Implementation Guide
for further information.

CVV processing applies to these card-present message types:
• 0100 authorization request
• 0100 preauthorization (Interlink)1

• 0200 balance inquiry (ATM, POS, and Interlink)
• 0200 cash disbursement (ATM)
• 0200 purchase; purchase with cashback, merchandise return, manual cash disbursement
(POS)
• 0200 purchase; purchase with cashback, merchandise credit
• 0200 resubmission; original
• 0220 preauthorization completion (Interlink)
Messages that do not use CVV verification are:
• 0220 cash disbursement adjustment
• 0220 back-office adjustment
• 0220 representment
• 0302 file update
• 0420 reversal
• 0422 chargeback
• 0422 chargeback reversal
• 0600 administrative message
24.7 HOW CARD VERIFICATION VALUE (CVV) SERVICE WORKS
The acquirer uses Field 35—Track 2 Data, or Field 45—Track 1 Data, in the
0100 authorization or 0200 financial request message to transmit the track data from the
magnetic stripe or from the chip's image of the magnetic stripe. For ATM transactions, the
full, unaltered magnetic stripe content must be in field 35. If the acquirer or the issuer
processor submits field 35 or field 45 carrying track data in a non-original or exception item,
1. Interlink does not support VSDC-based iCVV processing.

Chapter 24 How Card Verification Value (CVV) Service Works
0699—Presence of PIN/Track/AVS Data

V.I.P. rejects the message with Reason Code 0699
Inconsistent With Message Type.
The value that the acquirer places in Field 22—Point-of-Service Entry Mode Code
determines if the track data is from the magnetic stripe or from the VSDC chip card.
• Code 90 or 05 in positions 1 and 2 indicates that the acquirer included the track data from
the chip or the magnetic stripe and that CVV or iCVV checking is possible.
• Code 02 or 95 in positions 1 and 2 indicates that the magnetic stripe data may be
unreliable and accurate CVV processing may not be possible.
• For Plus ATM transactions only, code 02 in positions 1 and 2 indicates that the exact
contents of track 2 were read and that CVV checking is possible.
• For Visa ATM or Interlink transactions, code 90 or 02 can be used to indicate that the
complete, unaltered magnetic stripe content has been read, and that CVV or iCVV
checking may not be possible. Interlink transactions require code 9090; if acquirers submit
90.
code 02 in Interlink requests, V.I.P. changes it to code 90
• For Visa ATM or Interlink transactions, code 05 can be used to indicate that the complete,
unaltered integrated circuit card content has been read, and that CVV or iCVV checking
is possible.
• For Visa ATM or Interlink transactions, code 95 can be used to indicate that the complete,
unaltered integrated circuit card content has been read, and that CVV or iCVV checking
may not be possible.

Visa recommends code 90 or 05 in field 22 to ensure consistency for acquirers across
multiple products to indicate that the entire, unaltered contents of the integrated circuit card
are included in the message. The presence of code 90 in field 22 does not guarantee CVV
processing. If a non-participating acquirer submits code 90 in field 22, V.I.P. rejects the
message. Code 90 must be used for transactions in the Asia-Pacific (AP) region.
If the issuer has not successfully completed testing for CVV processing, V.I.P. replaces
code 90 in field 22 with code 02 before forwarding the request message to the issuer. For
chip transactions, V.I.P. replaces code 05 with code 95 before forwarding the message.
When V.I.P. receives the request message with code 90 or 05 (or code 02 for Plus
transactions) in field 22, it:
1. Calculates the CVV or the iCVV.
2. Verifies the CVV or the iCVV on the card by comparing it to the calculated value.
3. Sends the result to the issuer or processes the transaction in STIP depending on the
CVV or iCVV result and on issuer-specified options.
NOTE
For CVV verification requests forwarded by BASE I acquirers to SMS issuers, the acquirer BIN (as
indicated in Field 32—Acquiring Institution Identification Code of the request) must have its CVV
participation flag on. Otherwise, V.I.P. downgrades the transaction from code 90 to 02 in field 22 for
magnetic stripe transactions, and from 05 to 95 for chip transactions.
For a detailed description of the DES algorithm and of the CVV or iCVV verification
process, refer to the Card Verification Value (CVV) chapter of the Payment Technology
Standards Manual.
CVV checking requires that:

• Both the acquirer and the issuer be CVV Service participants.

• Positions 1 and 2 of Field 22—Point-of-Service Entry Mode Code contain the correct
value.
• The full, unaltered magnetic stripe data is included in the appropriate field: field 35 for
Track 2 data, and field 45 for Track 1 data.
• The expiration dates on cards are within the designated ranges for CVV checking.
Issuers inform Visa of the earliest expiration dates for cards affected by an individual
encryption key set.
CVV or iCVV verification can fail for any one of the following reasons:
• Fraudulent card
• Inaccurate reading or transmission of Track 1 or of Track 2
• Incorrect encoding of the CVV or the iCVV, such as incorrect position or wrong key
24.7.1 CVV and iCVV Verification Considerations

Issuers verify CVVs and iCVVs when they have selected the NONE options and are
available to process the transactions. Otherwise, the CVV verification fails.
Issuers performing their own CVV and iCVV verification must follow these important
procedures:
• For non-chip CVV Visa and Plus ATM transactions, issuers must be able to receive
codes 90 or 02 in Field 22—Point-of-Service Entry Mode Code. For VSDC iCVV Visa
transactions, issuers must be able to receive codes 05 or 95 in field 22.
• For non-chip CVV Visa POS and Interlink transactions, issuers must be able to process
all defined values for field 22.
• Depending on the issuer's parameters, issuers must perform CVV or iCVV verification if:
05.
- The CVV or the iCVV is present, and the code in field 22 is 90 or is 05
- The CVV is present, and the value in field 22 is 02 or is 95 in Plus ATM transactions.
These codes indicate that the magnetic stripe or the magnetic stripe image in the chip
was read and that the entire contents were transmitted.
24.7.2 CVV and iCVV Results

When V.I.P. verifies the CVV or the iCVV, it informs the issuer of the results by placing a
code either in the original request message or, if the issuer is unavailable, in an advice
message. For both message types, the issuer can choose to receive CVV or iCVV
results either in field 39 or in field 44.5. (See “Key Fields Glossary” in this chapter for
more information.)
Optionally, issuers can send CVV or iCVV results generated either by V.I.P. or by the issuer
in field 44.5 of the response message. If the issuer returns field 44.5 in the response,
V.I.P. forwards the CVV or iCVV results to acquirers that have chosen to receive them.
IMPORTANT
If STIP provides a higher severity response than an invalid CVV or iCVV response, the code in field 39 in an
advice message may not be the same code as the one that was sent to the acquirer. To preserve the response
code in field 39 for the issuer, Visa recommends that issuers receive CVV or iCVV results in field 44.5.
NOTE
If the transaction response is a denial (field 39 contains a non-zero value), V.I.P. removes the CVV/iCVV
results from the response message unless the acquirer BIN is a VISC or V-SAFE BIN.

24.7.3 Invalid CVV Response Code

The issuer must specify one CVV or iCVV response code for V.I.P. to use when the CVV or
the iCVV fails verification. This code is called the invalid CVV or iCVV response code.
Table 24-8 lists the CVV or iCVV response codes from which issuers can choose.
Table 24-8 CVV or iCVV Response Codes
Valid for
Response Codes Visa Interlink Plus
00 = Approve ✓ ✓ ✓
(Not recommended for issuers using

the ALL RESPOND option)
01 = Refer to issuer ✓
(For POS transactions only)

04 = Pick-up ✓ ✓
(For ATM and POS transactions)

05 = Decline ✓ ✓ ✓

Volume 2, for VSDC-specific response codes.
24.7.4 CVV Emergency Replacement

V.I.P. can generate CVVs for emergency replacement non-chip cards at the request of the
Visa International Service Center (VISC) through Global Customer Assistance Services
(GCAS) for BASE I and SMS issuers. GCCS sends an 0600 administrative message
to request the CVV for the emergency replacement. V.I.P. responds with an 0610
message. GCCS sends in a one dollar (USD$1) 0100 authorization request containing
the replacement CVV to verify it. The VISC encodes the CVV on the magnetic stripe and
arranges delivery of the emergency replacement card to the cardholder.
The VISC also performs optional magnetic stripe encoding at an issuer's request. Refer to
the Payment Technology Standards Manual for more information about optional encoding.
CVV emergency replacement for Visa Electron cards are allowed for the following regions:
• Visa Europe (VE, Region 3)
• Asia Pacific (AP, Region 4)
• Latin American and Caribbean (LAC, Region 5)
• Central Europe, Middle East, and Africa (CEMEA, Region 6)
VisaNet cannot process CVV emergency replacement cards for Visa Electron card issuers
from the U.S. region (region 1) or from the Visa Canada region (region 2).
IMPORTANT
Emergency replacement cards with iCVVs are currently unavailable.

24.7.4.1 CVV Emergency Replacement Error Codes

The CVV error codes listed in Table 24-9 apply to conditions such as the system not being
able to calculate the CVV. These format 1 codes are returned in field 48 (usage 1a) of the
0312 file maintenance response.
NOTE
These codes also apply to CVV.
Table 24-9 CVV Error Codes for Emergency Replacement Cards
Error
Code System Description Length
1000 BASE I ERC participation flag not on for source station. 02
1002 BASE I and Invalid Card Product. 02
SMS
1004 BASE I, SMS Required CVV/CVV2 data is not present in system 02
tables (start dates, keys, and so forth).
1005 BASE I, SMS Error returned from security module. 02
1006 BASE I, SMS Security module could not be accessed. 02
1008 BASE I, SMS Expiration date before CVV start date. 02

1009 BASE I, SMS Invalid account number (not in valid range). 02
24.7.5 MasterCard CVV Processing in Malaysia

In Malaysia, Visa CVV processing is available for MasterCard CVC1 transactions. The
MasterCard CVC1 is the equivalent of the Visa CVV; Visa and MasterCard use the same
algorithm. Issuers must supply Visa with MasterCard CVC1 keys if they want V.I.P. to verify
the CVC1. Field 32—Acquiring Institution Identification Code must contain the acquirer's
Visa BIN that signed the MasterCard-accepting merchant that participates in the service.
24.7.6 Application Transaction Counter (ATC)

The ATC is 2-bytes binary and is used in the magnetic stripe Data (MSD) on the right-most
four digits.
V.I.P. sends all data elements to the issuer so the issuer can generate the correct dCVV.
The issuer's host security module (HSM) needs the primary account number (PAN) and the
PAN sequence number to generate the Unique Derivation Key (UDK). The PAN sequence
number is assumed to be zero for the calculation of the UDK used for dCVVs.
V.I.P. applies the same methodology for verifying dCVVs as for verifying CVVs; the only
difference is the usage of the IDD in verifying the dCVV. In addition, the dCVV methodology
leverages current systems and processes. dCVV methodology uses a cryptographic
algorithm similar to the one for CVV verification.
However, dCVV methodology uses a UDK, a cryptographic key unique to each card
and stored in the chip on the contactless card. The contactless card uses the UDK to
calculate a unique dCVV value that changes with each transaction, providing the issuer
with enhanced security.

Chapter 24 How Dynamic Card Verification Value (dCVV) Service Works
The UDK in the card, along with a count of transactions (the ATC), is used with the standard
CVV algorithm to generate a dCVV value for every transaction.
24.8 HOW DYNAMIC CARD VERIFICATION VALUE (DCVV) SERVICE WORKS

The following steps comprise the contactless payment process.
1. A contactless transaction begins when a cardholder taps the contactless card on the
contactless card reader. The contactless chip and the card reader communicate through
wireless technology, such as Radio Frequency Identification (RFID.
The contactless chip contains a cryptographic algorithm similar to the one used to verify
a CVV, along with a cryptographic Unique Derivation Key (UDK) that is unique to each
card. The contactless chip uses the algorithm and the key to calculate a unique 3-digit
dCVV value that changes with each transaction. The dCVV is inserted in Track 2,
replacing any existing CVV or iCVV value in the message's track data. Included with
the dCVV in Track 2 is the Issuer Discretionary Data (IDD), which contains a 4-digit
Application Transaction Counter (ATC) and the contactless indicator. The ATC records
the number of transactions to date. The card reader generates and forwards the
2. The acquirer prepares and forwards the request to VisaNet. The request must include
the merchant name, the POS entry mode value 91 91, full Track 1 or Track 2 data including
the IDD and the account transaction counter (ATC) data, and other required online
fields and values.

NOTE
Members that want to process contactless transactions in which the POS entry mode code is 07 or 05
must participate in the Visa Smart Debit/Smart Credit (VSDC) Service and must have the chip terminal
capability to support VSDC chip transactions.
3. V.I.P. edits the message and ensures that the issuer is a dCVV Service participant.
V.I.P. forwards requests to available issuers that have elected to perform their own
dCVV verification.
4. The Issuer verifies the dCVV and puts the result code in Field 44.5—CVV Results Code
in the response. The response does not include the POS entry mode value and full
Track 2 data.
5. V.I.P. forwards the response from the issuer to the acquirer. The transaction is
considered complete when the merchant receives the response from the acquirer. The
merchant must provide a transaction receipt to the cardholder upon request.

Chapter 24 How Dynamic Card Verification Value (dCVV) Service Works
24.8.1 dCVV Processing Options

Issuers that participate in the Visa contactless card program must establish dCVV
processing options with Visa. Table 24-10 lists the dCVV Service options for dCVV
verification for Issuers.
Table 24-10 dCVV Verification Service Options
Option Description V.I.P. Processing

Verification Option 1: Standard V.I.P.: V.I.P. processes transactions
Issuer dCVV Service • Performs all dCVV as follows:
verifications on the issuer’s • Places the dCVV result
behalf. value in the CVV results field
• Declines transactions when (field 44.5 = 1 [failed]).
dCVV verification fails. - V.I.P. declines the
• Forwards status results in transaction with response
field 44.5 of transactions that code 0505.
are not declined to the issuer. - Returns the dCVV results
code value in response
and advice messages.
• Places the dCVV results
code in the CVV results code
field (field 44.5 = 2 [passed]).
- V.I.P. forwards the
transaction to the issuer

with the dCVV results
code.
Verification Option 2: All dCVV V.I.P.: V.I.P. processes transactions
Verification Results to Issuer • Performs dCVV verifications as follows:
on the issuer’s behalf. • V.I.P. verifies the dCVV
• Forwards all dCVV submitted in the transaction.
verification results to the • V.I.P. forwards all dCVV
issuer in the CVV results verification results to the
code field (field 44.5). issuer with the appropriate
code in the CVV results code
field (field 44.5).
Verification Option 3: V.I.P.: V.I.P. processes transactions
Issuer Supports Own dCVV • Does not verify the dCVV in as follows:
Verification the transaction. • V.I.P. forwards Track 2 data
• Forwards the Track 2 data to the issuer to perform
to the issuer for the issuer to dCVV verification.
perform dCVV verification. • The issuer verifies the dCVV
using the dCVV verification
method specified by V.I.P.
• The issuer must return the
results of dCVV verification
in the CVV results code field
(field 44.5) in the response
message.

24.8.2 STIP Options

Table 24-11 lists the dCVV Service options for dCVV verification for issuers when V.I.P.
performs stand-in processing.
Table 24-11 dCVV Verification Service Options for Stand-In Processing
Option STIP Processing

For dCVV options 1 and 2: Issuers must V.I.P. processes transactions as follows:
establish dCVV Master Derivation Key(s) • Places the dCVV result value in the CVV
(MDKs) at Visa. results code field (field 44.5 = 1 [failed]).
- Declines the transaction with response
code 05 if the transaction contains a Track 2
with the contactless indicator.
- Returns the dCVV results code value in
response and advice messages.
• Places the dCVV results value in the CVV
results code field (field 44.5 = 2 [passed]).
- Processes the transaction based on existing
issuer STIP parameters.
- Returns the dCVV results code value in
response and advice messages.
For dCVV option 3: Issuers are not required to If issuers do not establish dCVV MDKs at Visa,

establish dCVV MDKs at Visa. V.I.P. cannot verify the dCVVs. V.I.P. processes
the transactions according to the issuer’s option.
NOTE: The options are:
Issuers can choose to establish dCVV MDKs
at Visa. If issuers provide dCVV MDKs, V.I.P. • Decline all transactions that contain a Track 2
processes transactions using the STIP processing with a contactless indicator with response
rules for verification options 1 and 2. 05.
code 05
• Ignore the presence or content of the
contactless indicator in Track 2 and respond
based on existing issuer STIP parameters.
24.8.2.1 Emergency Replacement dCVV Cards

Emergency replacement cards with dCVVs are not currently available.

This section describes key fields related to the CVV Service.


For non-chip transactions, code 90 in positions 1 and 2 indicates that the acquirer
has included the complete, unaltered magnetic stripe contents in the message. For
reversals, V.I.P. accepts code 90 in field 22 but does not require the magnetic stripe
content.
NOTE
The presence of code 90 in field 22 does not guarantee CVV processing. If a non-participating acquirer
submits code 90 in field 22, V.I.P. rejects the message.
NOTE
90. If acquirers submit code 02 in Interlink requests, V.I.P. changes it
Interlink transactions require code 90
to code 9090.
For VSDC transactions, code 05 or 95 in positions 1 and 2 indicates that the acquirer
has included the track data and the iCVV from the magnetic stripe image residing on
the VSDC card.
V.I.P. rejects authorization and financial requests with code 0142 if the code in field 22
90, 02
is 90 02, or 91
91, but there is no magnetic stripe data in field 35 or in field 45.
90,
V.I.P. also rejects authorization requests with code 0019 if the code in field 22 is 90
but the acquirer has not successfully completed testing to transmit code 9090.
For non-chip transactions, if issuers have not successfully completed testing, V.I.P.
replaces code 90 submitted by a participating acquirer with code 02 before it forwards
the request to available issuers. For chip transactions, V.I.P. replaces code 05 with
code 95 before forwarding the request.
The valid code for contactless transactions is 91 (contactless chip transaction originated
using magnetic stripe data rules).

Field 35—Track 2 Data

This field (or field 45) contains the track data from the magnetic stripe, or from the image
of the magnetic stripe if a VSDC chip card is used at the POS.
This field is required for contactless transactions.
The following applies to magnetic stripe-based CVVs and to chip-based iCVVs:

• Issuers must encode the CVV in any three contiguous positions of the magnetic
stripe's Track 2 discretionary data field. Track 2 data in field 35 must not include
the start sentinel, the end sentinel, and the longitudinal redundancy check (LRC).
Excluding these three fields, 37 characters are available to the issuer for encoding.
• The CVV can be placed anywhere within the discretionary data field. The length
available for discretionary data depends on three other fields: the length of the
primary account number, the possible requirement to include the country code, and
the option of encoding the PIN Verification Value.
For Plus transactions, Track 2 data with encoded CVVs can contain account numbers
with lengths from 12 to 19 digits.
Refer to the Payment Technology Standards Manual for complete format specifications
for Track 2.

When the CVV-tested issuer or the iCVV-tested issuer selects the ALL processing
option or the STIP ONLY option and chooses not to receive CVV or iCVV results in
field 44.5, V.I.P. inserts code 82 (for Visa POS and Visa and Plus ATM transactions)
or N6 (for Interlink transactions) in field 39 to indicate an invalid CVV or iCVV in requests
forwarded to the issuer for a final decision. If the CVV or the iCVV passes verification,
issuers receive no notification. Acquirers do not receive code 82 or N6 in response
messages. If the CVV or the iCVV fails verification, V.I.P. inserts code 82 or N6 in
field 39 of the advice, indicating that CVV or iCVV checking failed and that V.I.P. used
the issuer's invalid CVV or iCVV response code.
CVV-participating issuers can choose to receive CVV or iCVV results in field 44.5
instead of in field 39.

Field 44.5—CVV Results Code

This code indicates the positive or negative result of CVV or iCVV verification.
Depending on the transaction flow, V.I.P. or the issuer generates the code, as follows:
1 = The transaction failed CVV or iCVV verification.
2 = The transaction passed CVV or iCVV verification.
3 = The transaction passed CVV verification. (This value is used only for emergency
replacement cards issued by Global Customer Care Services (GCCS).
Space (or not present) = The CVV or the iCVV was not tested. Either the issuer did not
encode the card, or a system error prevented CVV or iCVV verification.
The use of field 44.5 is optional both for issuers and for acquirers. Issuers forward
CVV results generated either by V.I.P. or by the issuer in field 44.5 of the response
message. Then, V.I.P. forwards the CVV or iCVV results to acquirers that have chosen
to receive them. In any event, acquirers must not forward any code in this field to
merchant terminals.
The valid codes for dCVV verification are space or not present, 1 (fail), or 2 (pass).

This field (or field 35) contains the track data from the magnetic stripe, or from the image
of the magnetic stripe if a VSDC chip card is used at the POS.
The following applies to magnetic stripe-based CVVs and to chip-based iCVVs:

• Issuers place the 3-character CVV for Track 1 in the Visa-reserved field of the
magnetic stripe. This field is 11 characters long, and the CVV must be placed in
positions 3, 4, and 5. With the exception of position 8, the remainder of this field
should be zero-filled.
• Position 8 can contain the authorization characteristics indicator (ACI); otherwise,
it also should be zero-filled.
for Track 1. Issuers can additionally encode the CVV anywhere else in the discretionary
data field of Track 1 for internal use.
Field 48—Additional Data—Private, Usage 1a (Error Codes in 0312 Responses, Format 1)

The following is the �eld format when a CVV is returned in this �eld.
Positions:
1–2 3–6
Length CVV Displacement CVV2 Value with Leading Zero

For further information about the CVV Service, refer to the following documents:
• Payment Technology Standards Manual


and Volume 2
• Visa Smart Debit/Visa Smart Credit System Technical Manual (document ID 6001-02)


Chapter 25 Card Verification Value 2 (CVV2) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
IN BRIEF 25-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
Issuer Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-5
Acquirer Processor Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-6
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-6
Issuer Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-6
Acquirer Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-7
Issuer Implementation Requirements. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .25-8
Card Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-8
Acquirer Implementation Requirements. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .25-9
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
Card Verification Value 2 (CVV2) Service

WORKS.. . . . . . . . . . . . . . . . . . .25-
HOW CARD VERIFICATION VALUE 2 (CVV2) SERVICE WORKS 25-10
10
CVV2 Calculation, Encryption, and Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
CVV2 Expiration Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
DES Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
Encryption Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
Card Verification Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
Issuer Option Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
CVV2 ALL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
CVV2 NONE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
Stand-In Processing and CVV2 Failure Response Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-13
CVV2 Processing Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-13
CVV2 Verification-Only Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
CVV2 Emergency Replacements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
CVV2 Emergency Replacement Error Codes. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .25-16
When Transactions Contain Both a CVV2 and a CAVV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
MasterCard CVV2 Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
American Express, Diners Club, and Discover Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17

Chapter 25
American Express. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17

Diners Club and Discover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
Japan Credit Bureau (JCB). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
Account Funding Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-18
Visa Europe CVV2 CNP Fee Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-18
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
PROCESS FLOWS 25-19
19
CVV2 Pass-Through Processing for Card-Present Transactions. . . . . . . . . . . . . . . . . . . . .25-21
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
21
Key Fields Glossary for CVV2 Emergency Replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-24
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-
25

Chapter 25 Card Verification Value 2 (CVV2) Service
25.1 IN BRIEF
A Card Verification Value 2 is a 3-digit security number. The Card Verification
Value 2 (CVV2) Service is a card verification tool designed to reduce fraud losses on
card-not-present and card-present transactions including manual key-entered transactions.
In addition to deterring fraud, the CVV2 Service also provides issuers with enhanced risk
protection by:
• Checking cardholder address changes requested by phone.
• Preventing account fraud.
• Verifying new card activations.
Members can use the CVV2 number to verify that a genuine Visa card is present during
a transaction. The CVV2 is calculated using a secure cryptographic process and a key
known only to the issuer and to Visa.
Participating merchants manually enter the CVV2 numeric value for verification by the
V.I.P. System, by the issuer, or by both. V.I.P., the issuer, or both, verify the CVV2 and
return the CVV2 results code to the merchant. Depending on the region, VisaNet supports
CVV2 verification-only requests with a zero transaction amount.
All Visa cards (including emergency replacement cards) must carry the CVV2 security
number.

The CVV2 Service is available to all members in all regions, depending on

regional support.
BASE I
SMS The CVV2 Service is available both to BASE I System users and to Single
Message System (SMS) users.
BASE I and SMS
I All issuers can participate in the CVV2 Service if their region supports the
service. All issuers in the Visa U.S.A. (U.S.) region and in the United Kingdom
(U.K.) must participate in the CVV2 Service.
Issuer
A All acquirers can participate in the CVV2 Service if their region supports the
service.
Acquirer

Issuers indent-print a 3-digit Card Verification Value 2 (CVV2) on the back of a Visa card
using a reverse italic font. Issuers generate the CVV2 values using Data Encryption
Standard (DES) keys and an algorithm. The encrypted value is based on the primary
account number, the card's expiration date, and a three-zero service code.
Acquirers submit the CVV2 in Field 126.10—CVV2 Authorization Request Data in

authorization requests or in verification-only requests. Verification-only requests
must have a zero transaction amount in Field 4—Amount, Transaction, code 51 in
Field 25—Point-of-Service Condition Code, and CVV2 data in field 126.10—CVV2
Authorization Request Data.
To verify the CVV2, V.I.P. uses the DES key and other CVV2 parameters provided by
participating issuers to calculate the CVV2 value and then compares it to the CVV2 on the
card. If V.I.P. or the issuer generates a CVV2 “no match” result, V.I.P. assigns CVV2 result
code N—No Match to the transaction. V.I.P. forwards the results to the issuer. The issuer
optionally may recheck the CVV2 and return another CVV2 result code or may rely solely
on the V.I.P. CVV2 result and return the CVV2 result code along with the appropriate
response code.
For CVV2 verification-only status checks:

• Field 3—Processing Code, positions 1–2, must contain 39 (eligibility message), 70 (PIN
change/unblock), or 72 (PIN unblock or prepaid activation).
• Field 25—Point-of-Service Condition Code must contain 5151.
• Field 126.10—CVV2 Authorization Request Data must be present.
If the request meets all the verification-only field requirements, and field 4 contains an
amount other than zero, STIP ignores the amount and, if the request is successful,
responds with a value of 85 (no reason to decline) in field 39.
Issuers may also use the CVV2 Service for the following purposes:
• To enhance the effectiveness of voice referrals.
• To prevent account takeover fraud, to activate cards, and for address changes.
Issuers can perform their own CVV2 verification, can have V.I.P. verify the CVV2 for them,
or can do both. If V.I.P. performs the verification, it verifies the CVV2 before it passes
the authorization request to the issuer or to the V.I.P. stand-in processor (STIP). If V.I.P.
performs the verification and it is successful, it processes the CVV2 transaction normally
and approves or declines it based on all other conditions of the transaction. Issuers can
choose to have V.I.P. check the CVV2 in all CVV2-eligible authorization requests.
IMPORTANT
In the Visa U.S.A. (U.S.) region, if a merchant sends the CVV2 in the authorization request and the issuer
has not successfully completed testing for the CVV2 Service, the issuer should not use Chargeback Reason
Code 6161—Fraudulent Mail/Telephone Order Transaction, if the transaction is fraudulent.
61.
Acquirers have representment rights if an issuer tries to charge back a transaction using reason code 61
Acquirers receive CVV2 Result Code U—Untested Issuer to indicate that the issuer is unavailable, is not a
CVV2 Service participant or has not provided Visa with its encryption keys. Acquirers should retain the
result code to ensure their representment rights.

For both BASE I and SMS issuers, regional requirements determine participation in the

CVV2 Service.
25.4.1 Issuer Requirements

BASE I and SMS issuer participation in the CVV2 Service is optional except in the U.S.
region and the United Kingdom (U.K.) where participation is mandatory. Participating
issuers must provide Visa with their processing parameters and their encryption keys.
IMPORTANT
Visa has migrated to the industry-standard Triple Data Encryption Standard (TDES). This change applies to all
Visa members and covers all PIN-based Visa credit and debit, Interlink, and Plus transactions processed
through VisaNet. Refer to the Payment Technology Standards Manual, for further information.
Requirements—Participating issuer processors must modify their

Issuer Processor Requirements—
systems so that:

• Issuers using the CVV2 ALL option must receive authorization requests containing
Field 126.10—CVV2 Authorization Request Data and Field 44.10—CVV2 Result Code.
Issuers may override the CVV2 result sent by V.I.P. Additionally, issuers may send
response code N7 (decline for CVV2 no match) in Field 39—Response Code.
• Issuers using the CVV2 NONE option must receive authorization requests containing
Field 126.10—CVV2 Authorization Request Data. In the response to V.I.P., issuers
must be able to calculate the CVV2 in their host system and be able to format
Field 44.10—CVV2 Result Code with the appropriate CVV2 result codes. Additionally,
issuers may send response code N7 (decline for CVV2 no match) in Field 39—Response
Code.
Requirements—Full CVV2 Service participation requires issuers, processing
Issuer BIN Requirements—
through CVV2-tested processing centers, to:
• Submit to Visa the selected CVV2 processing option (CVV2 ALL or CVV2 NONE).
NOTE
Participating issuers in the U.S. region must select the CVV2 ALL processing option.
• Submit CVV2 encryption keys to Visa.

• Submit to Visa a valid card expiration date from which to begin CVV2 checking.
• Submit the expiration date format used in the calculation of the CVV2 (MMYY or YYMM).
• Supply CVV2 failure response codes to Visa.
• Complete regional requirements and forms.
Issuers should work with their Visa representatives to establish CVV2 keys and parameters.
Refer to “Planning and Implementation,” in this chapter, for further information.
NOTE
If V.I.P. performs the verification, the Visa Security Module (VSM) verifies the CVV2 before it passes the
authorization request to the issuer or to STIP. The issuer optionally may recheck the CVV2 and return another
CVV2 result code or may rely solely on the V.I.P. CVV2 result and return the CVV2 result code along with
the appropriate response code.
25.4.2 Acquirer Processor Requirements

BASE I and SMS acquirer participation in the CVV2 Service is optional except in the United
Kingdom, where participation is mandatory.
Participating acquirers must modify their systems so they can:

• Submit authorization requests containing Field 126.10— CVV2 Authorization Request
Data.
• Receive authorization responses containing the CVV2 result values in field 44.10, as well
as CVV2 response code N7 (decline for CVV2 no match) in field 39.
25.4.3 Testing
Visa requires testing for CVV2 Service participation. The VisaNet Certification Management
Service (VCMS) provides testing assistance for CVV2 Service participants. Members can
contact their Visa representatives to make the arrangements.
25.4.3.1 Issuer Testing

To test for CVV2 Service participation, issuer processors must supply Visa with:

• A completed V.I.P. System Business Enhancements Certification Questionnaire,

customized for regional requirements. For a copy of the questionnaire, refer to the
September 1998 V.I.P. System Business Enhancements Certification Guide.
• CVV2 encryption keys.
• Test account numbers, card expiration dates, and CVV2 values.
NOTE
In addition, issuers in the U.S. region must submit two test account numbers with card expiration dates and
with CVV2 values for each BIN (or BIN range) that share the same encryption keys.
To test, issuing processors must:

• Demonstrate the ability to correctly receive all of the CVV2 fields in 0100 BASE I
authorization requests and in 0200 SMS financial requests.
• Demonstrate the ability to transmit the new CVV2 field values in 0110 BASE I
authorization responses and in 0210 SMS response messages.
• Conduct testing with processor-provided account numbers, card expiration dates, and
CVV2 values.
• Demonstrate the capability to generate and to send response code N7 in
Field 39—Response Code.
• Demonstrate the ability to receive advices when V.I.P. sends a transaction to STIP.
• Test that the CVV2 keys provided to Visa are correct.
NOTE
In addition, issuers in the U.S. region must demonstrate the ability to calculate the CVV2 correctly for each
issuer BIN (or BIN range) that has the same keys by submitting test account numbers to Visa.
The issuer's processor must first pass the processor CVV2 testing before it can begin
the BIN-level testing. After a successful BIN testing, an issuer BIN moves directly to
CVV2-participating status.

IMPORTANT
V.I.P. does not perform CVV2 verification on transactions when issuers are unavailable, do not meet the
testing criteria, or have not provided Visa with their CVV2 encryption keys. Instead, V.I.P. sets the CVV2
result code to U (issuer is unavailable, has not successfully completed testing, or has not provided Visa with
its encryption keys), in the authorization request message if the processorhas successfully completed testing
to receive the CVV2 fields but this issuer has not established CVV2 keys for the BIN.
V.I.P. always overwrites any CVV2 result code sent in the response message from an issuer with code U
when there are no CVV2 keys at Visa for that issuer's BIN.
25.4.3.2 Acquirer Testing

To test, based on regional requirements, BASE I and SMS acquirers must complete the
V.I.P. System Business Enhancements Certification Questionnaire, which is located in the
September 1998 V.I.P. System Business Enhancements Certification Guide.
Visa does not require BIN-level testing for acquirers. Acquirer processors must
demonstrate the ability to:

• Correctly transmit Field 126.10—CVV2 Authorization Request Data in 0100 and 0200
authorization request messages and receive Field 44.10—CVV2 Result Code in 0110
and 0210 response messages.
• Conduct online testing with manually keyed transactions using Visa-provided scripts, test
account numbers, card expiration dates, and CVV2 values.
• Accept response code N7 in field 39.

Visa does not require service monitoring for participation in the CVV2 Service. After
successful testing, issuers and acquirers move directly to CVV2-participating status.

Issuers that participate in the CVV2 Service must modify V.I.P. authorization request,
response, and advice messages to support the service.
Acquirers that participate in the CVV2 Service must modify V.I.P. authorization request and
response message formats to support the service.
25.4.5.1 Issuer Implementation Requirements

Issuers that want to fully participate (verify their own CVV2 values) must modify their
systems to accept authorization requests containing Field 126.10—CVV2 Authorization
Request Data and Field 44.10—CVV2 Result Code, and provide CVV2 encryption keys to
Visa.
Issuers must be prepared to receive CVV2 verification-only requests.
Issuers can optionally generate response code N7 (declined for CVV2 no match). Issuers
should always return field 44.10. Additionally, 0120 and 0220 STIP advices include
field 126.10 and field 44.10. Advices also include the CVV2 failure response code in
field 39 when STIP processes a CVV2 that fails verification.
Members establishing their CVV2 encryption keys on their cards for the first time need to
consult and follow the CVV2 encryption standards in the Payment Technology Standards
Manual.
Issuers should work with their Visa representatives to establish the required CVV2
parameters.
25.4.5.2 Card Specifications

Issuers must imprint the CVV2 on the back of all new or reissued Visa cards in accordance
with Visa International Operating Regulations. Issuers must indent-print the CVV2 using the
unique reverse-italic font designed for this purpose. Issuers must print the CVV2 in black.
Issuers can use the same indent module both for Visa products and for MasterCard
products. If an issuer currently prints a CVV2 (called a Card Verification Code 2 [CVC2]
by MasterCard) on its MasterCard cards, it must use the same location and font for its
CVV2 on its Visa cards.
Issuers can place the CVV2 in one of two locations:

• In the upper portion of the Visa tamper-resistant signature panel.

• Outside the signature panel between the space allocated for the Signature 3 and the
first embossing line.
WARNING
Visa cautions issuers that plan to issue Visa card products equipped with integrated circuits not to place
the CVV2 in a location where it could damage or destroy the integrated circuits during the indent-printing
process. Safe locations include the upper-left portion of the signature panel or the alternate position
before the first embossing line.
Refer to the Payment Technology Standards Manual for documentation about the physical
characteristics of the CVV2 and about CVV2 calculation. For detailed card standards,
refer also to Visa International Operating Regulations.
25.4.5.3 Acquirer Implementation Requirements

Acquirer processing centers that participate in the CVV2 Service must make sure that mail
order or telephone order (MOTO) and card-not-present (CNP) merchants (and certain
card-present merchants in the Latin America and Caribbean [LAC] region) that are making
host or terminal changes to accommodate the CVV2 fields can correctly send and receive
the CVV2 fields. Acquirers must also make sure that participating merchants provide
expiration dates in authorization request messages. The expiration date is a critical
component in calculating the CVV2.
Acquirers can contact their Visa representatives for terminal specification changes related
to CVV2. For additional documentation about terminal changes, refer to Visa International
Acquirer Services, External Interface Specifications, Second Generation Authorization
Record Formats, EIS1080-v5.6.

The following messages pertain to the CVV2 Service:

• Authorization request messages (0100s and 0200s)
• Authorization response messages (0110s and 0210s)
• Advice messages (0120s and 0220s)
25.5.1 BASE I and SMS Authorization Requests

0100 authorization request messages (BASE I and SMS) and 0200 financial transaction
request messages (SMS) support CVV2 as follows:
• Field 126—Visa Private-Use Fields includes Subfield 126.10—CVV2 Authorization
Request Data.
• V.I.P. inserts Subfield 44.10—CVV2 Result Code within Field 44—Additional Response
Data for the CVV2 result code.
Additionally, the 0120 and 0220 STIP advices include field 126.10 and field 44.10.
Advices also include the CVV2 failure response code in field 39 when STIP processes a
CVV2 that fails verification.
25.5.2 BASE I and SMS Authorization Responses

BASE I and SMS 0110 and 0210 response messages include subfield 44.10 in field 44.

Chapter 25 How Card Verification Value 2 (CVV2) Service Works
During stand-in processing, V.I.P. does not return field 126.10 in response messages.
V.I.P. rejects response messages from issuers that return field 126.10 with reject code 0518
(the message contains an invalid field).
25.6 HOW CARD VERIFICATION VALUE 2 (CVV2) SERVICE WORKS

The merchant in the card-not-present (CNP) environment asks the cardholder for the card
number, the expiration date, and the CVV2 value, and then sends the message to VisaNet.
(Specific card-present merchants in the LAC region can get the information from the card
itself.) Depending on the CVV2 processing option selected by the issuer, the issuer
or V.I.P. recalculates the CVV2 using the primary account number, the expiration date
embossed on the front of the card, and the CVV2 read from the back of the card. A CVV2
match enhances the probability that the cardholder is using a genuine Visa card.
NOTE
For non-Visa card transactions, the Visa acquirer must populate field 126.10, position 1, with value 1 if the
CVV2 (or equivalent) is present, and position 2 with value 1 if they want the CVV2 results value from the
issuer returned in field 44.10.
Merchants can submit CVV2 values in card-present transactions involving an authorization

request, or submit CVV2 values in verification-only requests. This chapter describes
verification-only requests in a subsequent section.
If V.I.P. performs the verification, the Visa Security Module (VSM) verifies the CVV2 before
V.I.P. passes the authorization request to the issuer or to STIP. The issuer optionally may
recheck the CVV2 and return another CVV2 result code or may rely solely on the V.I.P.
CVV2 result and return the CVV2 result code along with the appropriate response code.
V.I.P. applies the issuer service selections for CVV2–based authorization requests to
verification-only requests.
When merchants receive CVV2 Result Code N—No Match, they have three options. They
can:
• Reject the transaction.
• Ask again for the CVV2 to obtain a match.
• Accept the transaction and the associated risk.
NOTE
VisaNet requires a full reversal if the merchant receives an approval response with a CVV2 value of N in
field 44.10 and does not want to conclude the transaction with the cardholder.
25.6.1 CVV2 Calculation, Encryption, and Verification

The following subsections describe how entities calculate, encrypt, verify, and process
a CVV2.
V.I.P., the issuer, or both, use the following data elements to compute the CVV2:
• Primary account number (PAN)
• Expiration date
• Three zeros, used as the service code value element in the calculation
V.I.P. or the issuer encrypts the three data elements using a DES algorithm and a Card
Verification Key (CVK) pair. This process determines the 3-digit CVV2 value.

25.6.1.1 CVV2 Expiration Date

The CVV2 VSM allows issuers to use either the MM/YY or YY/MM date format for
calculating the CVV2. During the enrollment and testing process, participating issuers
must indicate which date format they use so V.I.P. can correctly calculate the CVV2 for
each issuer.
25.6.1.2 DES Algorithm

V.I.P., the issuer, or both, compute the CVV2 using the same algorithm used for the CVV,
except for the card's expiration date format. The CVV2 calculation depends on the date
format used by the issuer.
The CVV2 calculation uses the Data Encryption Standard (DES) algorithm defined by the
National Institute of Standards and Technology (NIST) (formerly, the U.S. National Bureau
of Standards). The standard algorithm requires a 128-bit cryptographic key consisting of
two 64-bit DES keys, each having odd parity and constructed according to the standards in
the Payment Technology Standards Manual.
NOTE
Members establishing their CVV2 encryption keys and printing CVV2s on their cards for the first time need to
consult and follow the CVV2 encryption standards in the Payment Technology Standards Manual.
25.6.1.3 Encryption Keys

Visa recommends that issuers use their current Card Verification Value (CVV) encryption
keys for the CVV2 program. Issuers using the same CVV2 and CVV encryption keys do
not have to resubmit keys to Visa.
Visa requires issuers using new CVV2 encryption keys (or using CVV2 keys that are
different from those used for their CVV program) to submit those keys to Visa on a Key
Conveyance Form. The Payment Technology Standards Manual explains the generation
and conveyance of keys.

When Visa does not have the CVV2 encryption keys for an issuer, V.I.P. sends CVV2 result
code U (untested issuer) to the acquirer in Field 44.10—CVV2 Result Code.
25.6.1.4 Card Verification Keys

Entities use one pair of 64-bit cryptographic keys, called Card Verification Keys (CVKs),
to generate and to verify the CVV2. Issuers send these keys to VisaNet under the issuers'
existing Zone Control Master Keys (ZCMKs).
For ease of implementation, Visa recommends that issuers use the same encryption keys
for CVV2 that they use for CVV.
IMPORTANT
Visa mandates the following security precautions for CVV2 keys.

• Issuers must not use the same verification keys for CVV2 as those they use for PIN
Verification Values (PVVs) with the PIN Verification Service (PVS). If the common keys
are compromised, it would affect both the issuer's PVVs and its CVV2s.
• Issuers must keep the CVK pair secret and unknown, in their entirety, to any person.
If issuers know or suspect the unauthorized disclosure of a CVK pair, they should replace
the CVK pair immediately. Issuers should reissue cards with the CVV2 values generated
using the potentially compromised keys as soon as possible. When issuers have reissued
all such cards, they should invalidate the potentially compromised CVK pair.
To facilitate changing an issuer's CVK pair for any reason, V.I.P. supports multiple CVK
pairs for each issuer. V.I.P. can support two CVK pairs online.
Similar to any DES-based scheme, the security of the output value depends on the secrecy
of the DES keys.
25.6.2 Issuer Option Selection

Participating issuers must choose one of two options for CVV2 processing:
• CVV2 ALL—V.I.P. performs CVV2 verification
• CVV2 NONE—V.I.P. bypasses CVV2 verification
NOTE
If V.I.P. performs CVV2 verification on behalf of the issuer, V.I.P. checks the CVV2 in all eligible requests,
including verification-only requests, and responds on behalf of the issuer.
The following subsections explain these options.
25.6.2.1 CVV2 ALL

V.I.P. performs CVV2 verification. V.I.P. tries to perform CVV2 verification for all eligible
transactions and passes field 126.10 and field 44.10 to the issuer in the authorization
request message.
Issuers can reverify the CVV2 results received from V.I.P., by recalculating and generating
a CVV2 result code or can accept and use the result code generated by V.I.P. Issuers can
send back any CVV2 result code in the response message to the acquirer and return
any response code. Visa recommends that issuers use the CVV2 result code as a
component along with other factors when determining an authorization response. If the
issuer's processor is not available, STIP can perform CVV2 verification. In the U.S. region,
all issuers must select the CVV2 ALL processing option.
25.6.2.2 CVV2 NONE

V.I.P. bypasses CVV2 verification. V.I.P. does not try to verify the CVV2; it forwards
authorization request messages to the issuer for CVV2 verification. V.I.P. sends code P
(not processed) in field 44.10 of the request message to indicate that V.I.P. bypassed CVV2
processing. The issuer should calculate the CVV2 and respond to the acquirer with the
appropriate CVV2 result code along with the response code. Visa recommends that the
issuer use the CVV2 result as a component along with other factors when determining an
authorization response. If CVV2-participating issuers select the CVV2 NONE processing
option, V.I.P. does not perform CVV2 verification during stand-in processing.

25.6.3 Stand-In Processing and CVV2 Failure Response Codes

V.I.P. verifies the CVV2 for CVV2-participating issuers that select the CVV2 ALL
processing option when the issuer is unavailable. If STIP detects a CVV2 verification
failure processing, STIP responds to the acquirer with the CVV2 failure response code
00,
(00
00 0505, or N7
N7) pre-selected by the issuer. STIP also returns code N in Field 44.10—CVV2
Result Code to acquirers that have successfully completed testing to receive the field
(recommended). V.I.P. processes CVV2-qualified transactions that generate no match
responses in STIP according to the issuer's CVV2 default response code settings.
STIP responds to successful CVV2 verification-only requests with code 85 (no reason
to decline) in field 39 and a valid value in field 44.10. V.I.P. then processes the CVV2
transaction normally and approves or declines it based on all other conditions of the
transaction.
NOTE
The CVV2 response code STIP assigns depends on the hierarchy of response codes; higher priority failure
reasons may override the CVV2 failure response code.
STIP creates advices for messages that fail CVV2 verification, indicating that STIP detected
a CVV2 verification failure. Advices include the CVV2 in field 126.10, the CVV2 result code
in field 44.10, and the CVV2 failure response code in field 39 when STIP generates CVV2
Result Code N—No Match. For BASE I issuers, advice-generation is subject to the advice
limits specified by the issuer. STIP only sends advices with CVV2 fields to issuers that have
successfully completed testing to receive the CVV2 fields.
Participating issuers that select the CVV2 ALL option must supply Visa with two CVV2
failure response codes to use for messages that fail CVV2 verification when the issuer is
unavailable. STIP responds to the acquirer using one of the two CVV2 failure response
codes selected by the issuer. The code STIP uses depends on the CVV2 response type
option indicated by the merchant.

25.6.4 CVV2 Processing Variations
V.I.P. determines processing for CVV2 based on whether or not the acquirer, the issuer,
or both, participate in the CVV2 Service.
• If the acquirer populates the CVV2 fields but the acquirer processor is not certified,
V.I.P. drops field 126.10 from a transaction.
• If the acquirer is participating and the issuer processor has not successfully completed
testing, V.I.P. does not perform CVV2 verification and drops the CVV2 data fields from
the message sent to the issuer.
NOTE
If the acquirer requests that V.I.P. return the CVV2 result code, V.I.P. inserts code U in Field 44.10—CVV2
Result Code when the issuer is not available, the BIN has not been successfully tested, or the issuer has
not provided Visa with its encryption keys.

Table 25-1 summarizes the possible VisaNet processing variations.
Table 25-1 CVV2 Processing Variations
Acquirer Issuer
Encryption
Keys
Tested Tested Provided V.I.P. Processing
No Yes Yes V.I.P. does not pass any CVV2 data to the issuer.
Yes Yes Yes V.I.P. performs CVV2 verification and passes the CVV2 result to the issuer.
If the issuer selects the CVV2 NONE option, V.I.P. inserts code P in field 44.10
and passes the transaction to the issuer. The issuer can override this value
regardless of the processing option it selects. V.I.P. returns the value received
from the issuer to the acquirer unchanged.
Yes No Yes V.I.P. inserts code U in field 44.10 and returns this code to the acquirer at
the acquirer's option.
Yes Yes No V.I.P. passes the CVV2 data provided by the acquirer to the issuer. If the issuer
returns a CVV2 result code, V.I.P. overrides the result code. V.I.P. inserts
code U in field 44.10 and returns this code to the acquirer at the acquirer's
option.
Yes No No V.I.P. inserts code U in field 44.10 and returns this code to the acquirer at
the acquirer's option.
Request and Response Processing Rules

The following rules apply to processing requests (0100 authorization and 0200 full financial)
and their responses:
• If a participating tested issuer provides Visa with its CVV2 encryption keys, V.I.P. verifies
the CVV2 value and passes the CVV2 result in the request to the issuer for the approval
or decline decision. Code M in field 44.10 indicates a match. Code N indicates no

match. For the response, the issuer can override the V.I.P.-assigned result code with a
different code (MM, N, P, or S). Code S indicates that verification was unsuccessful and the
message should have contained a CVV2 value. V.I.P. forwards field 44.10 to the acquirer
as it was received from the issuer. Otherwise, V.I.P returns the V.I.P.-assigned code
in the response to the acquirer.
• If a participating issuer selected the CVV2 NONE service option but provides Visa
with its CVV2 encryption keys, V.I.P. inserts code P (not processed) in field 44.10 of
the 0100, 0200, 0120, or 0220 request message, and forwards the request to the
issuer for the approval or decline decision. For the response, the issuer can override
the V.I.P.-assigned result code with a different code (M M, N, P, or S); V.I.P. forwards

field 44.10 to the acquirer as it receives it from the issuer. Otherwise, V.I.P. returns
code P in field 44.10 in the response to the acquirer.
- If the issuer is unavailable, V.I.P. forwards the request to STIP, which returns code P
in field 44.10 in the response to the acquirer.
• If an issuer is not a CVV2 service participant, or has not provided Visa with its CVV2
encryption keys, V.I.P. inserts code U in field 44.10 of the 0100, 0200, 0120, or 0220
request message, and passes the message to the issuer for the approval or decline
decision. If the issuer overrides result code U with a different code (M M, N, P, or S),
V.I.P. restores the value of U in field 44.10 before it forwards the message to the acquirer.
The acquirer only receives code U in field 44.10 when STIP has responded to an
issuer-unavailable request and the issuer has not successfully completed testing or has
not provided Visa with its encryption keys.
Because the expiration date in Field 14—Date, Expiration determines which key to use,
CVV verification requires field 14. When a tested acquirer submits an authorization request
and does not supply the expiration date, V.I.P. edits the transaction. If the transaction
passes all tests, V.I.P. inserts code P or code U in field 44.10 and forwards the request to
the issuer for further processing. When the expiration date is missing, V.I.P. uses code P
if the issuer has successfully completed testing and has provided Visa with encryption
keys. It uses code U if the issuer has not successfully completed testing or did not provide
Visa with keys.
25.6.5 CVV2 Verification-Only Processing

VisaNet supports CCV2 verification-only requests, which V.I.P. processes similarly to the
way it processes account verification-only requests. Issuers can choose to have V.I.P.
perform the verification on the issuer's behalf.
In addition to the CVV2 data in field 126.10, a CVV2 verification-only request must
include a zero transaction amount in Field 4—Amount, Transaction, and include code 51
in Field 25—Point-of-Service Condition Code (request for account number and CVV2

verification without authorization). Successful verifications result in the response message
containing a valid value in field 44.10 and response code 85 (no reason to decline a request
for account number verification or address verification) in field 39.
25.6.6 CVV2 Emergency Replacements

V.I.P. can generate CVV2s for emergency replacement cards at the request of Global
Customer Care Services (GCCS) for the Visa International Service Center (VISC) for
BASE I and SMS issuers. GCCS uses an 0600 administrative message to request the
CVV2 for the emergency replacement card. Refer to the field 48 description in “Key Fields
Glossary for CVV2 Emergency Replacement” in this chapter for more information.
VisaNet supports CVV2 emergency replacement for Visa Electron cards in the following
regions:
• Visa Europe (VE, Region 3)
• Asia Pacific (AP, Region 4)
• Latin America and Caribbean (LAC, Region 5)
• Central and Eastern Europe, Middle East, and Africa (CEMEA, Region 6)
VisaNet cannot process CVV2 emergency replacements for Visa Electron card issuers in
the U.S. region (region 1) or in the Visa Canada region (region 2).

25.6.6.1 CVV2 Emergency Replacement Error Codes

The CVV2 error codes in Table 25-2 apply to conditions such as the system not being able
to calculate the CVV2. V.I.P. returns these codes in Field 48 (usage 1a)—Error Codes in
0610 Responses of the 0610 file maintenance response.
NOTE
These codes also apply to CVVs.
Table 25-2 CVV2 Error Codes for Emergency Replacement Cards
Error
Code System Description Length
1000 BASE I ERC participation flag not on for source station. 02
1002 BASE I and SMS Invalid card product. 02
1004 BASE I, SMS Required CVV or CVV2 data is not present in system tables (start 02
dates, keys, and so forth).
1005 BASE I, SMS Error returned from security module. 02
1006 BASE I, SMS Security module could not be accessed. 02
1008 BASE I, SMS Expiration date before CVV start date. 02
1009 BASE I, SMS Invalid account number (not in valid range). 02
25.6.7 When Transactions Contain Both a CVV2 and a CAVV

When an authorization or financial request contains both a Cardholder Authentication
Verification Value (CAVV) and a CVV2, the CAVV validation result takes precedence
over the CVV2 verification result. This includes issuer-unavailable transactions that V.I.P.
sends to STIP: if the CAVV passes validation, but the CVV2 fails the verification process,
STIP does not decline the transaction because of the CVV2 failure. For further information
about how STIP handles transactions that contain a CAVV in addition to a CVV2, refer to
“When Transactions Contain Both a CAVV and a CVV2” in Chapter 26, Cardholder
Authentication Verification Value (CAVV) Verification Service.
25.6.8 MasterCard CVV2 Processing

For MasterCard-acquired Visa transactions, the data element (DE) 48.92 contains the
CVV2. The VisaNet Gateway transfers the CVV2 from DE 48.92 to field 126.10 in the
VisaNet-format request message to the Visa issuer. For Visa-acquired MasterCard
transactions, field 126.10 contains the CVV2 and the VisaNet Gateway transfers it to
DE 48.92 in the Banknet-format request message to the MasterCard issuer.
In responses to MasterCard-acquired Visa transactions, the VisaNet Gateway transfers

the Visa CVV2 value in field 44.10 to DE 48.87 for delivery by Banknet to the acquirer.
In responses to Visa-acquired MasterCard transactions, the VisaNet Gateway transfers
the CVC2 result code from Banknet DE 48.87 to field 44.10 in the 0110 message if, in the
request, the acquirer set field 126.10, position 2, to 1 (return both the field 39 response
code and the field 44.10 results code). Otherwise (field 126.10, position 2 contains 0,
return only the field 39 response code), V.I.P. does not include field 44.10 in the response.
Valid result codes are:

M = Valid or matched CVC2 code
N = Invalid CVC2 code
P = Not processed
U = Issuer unregistered
Y = CVC1 no match when only CVC1 is present in the message
In Malaysia, the Visa CVV2 Service is available for MasterCard CVC2 transactions.
The CVC2 is the MasterCard equivalent of the Visa CVV2; Visa and MasterCard use the
same CVV2 algorithm. Issuers must supply Visa with MasterCard CVC2 keys if they want
VisaNet to verify the CVC2. Field 32—Acquiring Institution Identification Code must contain
the acquirer's Visa BIN that signed the MasterCard-accepting merchant that participates
in the service.
25.6.9 American Express, Diners Club, and Discover Processing

VisaNet supports the processing of Cardholder Identification Data (CID) for American
Express, for Diners Club, and for Discover. Acquirers sending in those transactions include
field 126.10 in the requests.
American Express does not use field 44.10; acquirers receive only the field 39 response
code.
25.6.9.1 American Express

If acquirers include a 4-digit CID in field 126.10 in an American Express request,
V.I.P. transfers the CID to field 53 in the American Express-format message. V.I.P. also
inserts code S in byte 7 of Field 22—Point-of-Service Entry Mode Code in the message
unless field 22 is already populated with hex zeros or spaces or if the request includes
magnetic stripe data, in which case V.I.P. leaves the field unchanged.

If VisaNet receives an American Express transaction containing a CID validation code in
field 44, position 2, V.I.P. maps the CID validation code to the V.I.P. CVV2 result code and
sends the CVV2 result code back to the acquirer if field 126.10 contains CVV2 data and if
position 2 of this field contains 1 (to indicate that the CVV2 result is required).
In responses, V.I.P. converts the American Express code to a corresponding Visa code
before it forwards the message to the acquirer.
25.6.9.2 Diners Club and Discover

Depending on the value in field 126.10, position 2, in the request, V.I.P. includes field 44.10
in the response to the acquirer. If field 126.10, position 2, contains 1 in a Diners Club or a
Discover request, V.I.P. includes the CID-specific result code in field 44.10 in the acquirers'
response as well as the field 39 response code. If the code in field 126.10, position 1, is 0,
V.I.P. includes only the field 39 response code.
25.6.10 Japan Credit Bureau (JCB)

Acquirers can optionally include the CVV2 in field 126.10 in 0100 card-not-present
authorization requests. Japan Credit Bureau (JCB) performs its own verification; if the
value is present in the request, V.I.P. forwards it unaltered to the issuer (JCB). STIP does
not verify the CVV2 in issuer-unavailable requests. JCB includes field 44.10 in the 0110

response with one of the following values: M (CVV2 match), N (CVV2 no match), P (not
processed), or S (CVV2 should be on the card but the merchant indicates it is not).
If field 126.10 is not present in the request, acquirers may receive response code N7
(decline for CVV2 no match) in field 39, in addition to code N, P, or S in field 44.10.
25.6.11 Account Funding Transactions

Electronic commerce (e-commerce) transactions for stored-value cards can qualify for
the Custom Payment Service (CPS)/Account Funding program if, in addition to other
requirements, the request includes a CVV2 value. For stored-value cards that are to be
refilled more than once, VisaNet requires the CVV2 only in the initial funding request for the
request to qualify; subsequent transactions can also qualify for the CPS program without
the CVV2 being present.
25.6.12 Visa Europe CVV2 CNP Fee Program

The Visa Europe CVV2 card-not-present (CNP) fee service supports SMS consumer
card retail transactions, including airline (MCCs 3000–3299 and 4511) transactions.
The program does not apply to domestic fee programs in Germany, Spain, Turkey, Cyprus,
and Portugal. Initial recurring transactions can qualify for the fee program, providing that
they are mail order or telephone order (MOTO) requests (not e-commerce) and that they
meet the field edit criteria, but subsequent submissions cannot.
The fee program covers credit, deferred-debit, and direct-debit account usages:
• Credit—A credit card offers the cardholder a line of credit, specific to that credit
card account, and the ability to revolve part of any outstanding balance, or all of the
outstanding balance, on the credit card account during each statement cycle.
• Deferred Debit—A deferred debit or charge card is linked to an account whereby:
- VisaNet accumulates the transactions with other transactions on a deferred basis.
- VisaNet issues a statement.
- The cardholder pays the account in full.
NOTE
For cardholders that have the option to revolve credit on the account, issuers should report the details as a
credit card program, not as a deferred debit card program.
• Direct Debit—A direct (immediate) debit card is linked to a current (or deposit access)
account from which a transaction is debited immediately (within a maximum of two
working days) on receipt of the transaction by the issuer.
Table 25-3 shows the key data requirements and the fee program edit criteria for the
CVV2 CNP fee program.
Table 25-3 CVV2 Key Data Requirements and Fee Program Edit Criteria
Data Element Field Value BASE II Field

Purchase Date 13 MMDD format. Must clear within four (4) TCR 0, Positions 58–61
days not counting the purchase date, Central
Processing Date, and Sundays. Public holidays
are not excluded.
Merchant Category 18 Airline (MCCs 3000–3299 and 4511) TCR 0, Positions 133–136
Code (MCC)

Table 25-3 CVV2 Key Data Requirements and Fee Program Edit Criteria (continued)
Data Element Field Value BASE II Field
POS Entry Mode Code 22 Must be key-entered. 01 = key-entered. TCR 0, Positions 162–163
Authorization Code 38 Valid authorization code values are: TCR 0, Positions 152–157
• Last position cannot be X.
• First three positions cannot be SVC
SVC.
• Last five positions cannot be: ^^^^^ (all
0000^, 0000N
spaces), 00000 (all zeros), 0000^ 0000N,
0000P, or 0000Y
0000P 0000Y.
Cardholder ID Method 60.9 Must be mail order or telephone order. TCR 0, Position 160
4 = mail-telephone or electronic commerce.
Reimbursement 63.11 Must request Visa Europe CVV2 CNP fee. TCR 0, Position 168
Attribute 7 = Visa Europe CVV2 CNP rate requested.
25.7 PROCESS FLOWS

The CVV2 Service transaction flow is the same as a basic transaction flow.

Accordingly, Figure 25-1 illustrates both the process flow and the message flow.
Figure 25-1 CVV2 Process Flow and Message Flow
CVV2-Certified CVV2-Certified
CNP Merchant Acquirer V.I.P. Issuer
Cardholder 0100 or 0200 0100 or 0200 0100 or 0200

Transaction Request Request Request
Subfield 126.10: Subfield 126.10: Subfield 126.10: Subfield 126.10:
CVV2 Authorization CVV2 Authorization CVV2 Authorization CVV2 Authorization
Request Data Request Data Request Data Request Data
Subfield 44.10: Subfield 44.10:
CVV2 Result CVV2 Result
(Visa to issuer) (Visa to issuer)
Transaction 0110 or 0210 0110 or 0210 0110 or 0210

Response Response Response Response
If the merchant puts Field 39: Response Field 39: Response Field 39: Response
a “0” in position 2 of Code Code Code
subfield 126.10, the Subfield 44.10: Subfield 44.10: Subfield 44.10:
merchant receives CVV2 Result, CVV2 Result CVV2 Result
only field 39. if the merchant (Visa to acquirer) (issuer to Visa)
If the merchant puts requests it. (V.I.P. strips off
a “1” in position 2 of field 44.10 if the

subfield 126.10, the merchant does not
merchant receives request it.)
field 39 and
subfield 44.10.
The CVV2 process flow consists of the following steps:

1. V.I.P. receives an authorization request containing relevant information, such as the
card number, the expiration date, and the CVV2 value.
2. If V.I.P. is performing verification:
a. V.I.P. calculates the CVV2 and compares it to the CVV2 on the card.
b. V.I.P. assigns a result code to the transaction and forwards the results to the issuer.

c. The issuer either rechecks the CVV2 or accepts the V.I.P. CVV2 result and returns
the CVV2 result code along with the appropriate response code to acquirer.
3. If the issuer is performing the verification:
a. V.I.P. forwards request message to the issuer.
b. The issuer calculates the CVV2 and forwards the results and appropriate response
code to the acquirer.
25.7.1 CVV2 Pass-Through Processing for Card-Present Transactions

When V.I.P. receives a BASE I authorization or SMS financial request that includes a
CVV2 in field 126.10 as well as magnetic stripe data in Field 35—Track 2 Data or in
Field 45—Track 1 Data, it processes the request as if field 126.10 is not present. V.I.P.
also does not use field 44.10 in CVV2 pass-through transactions; if the results code field is
present, V.I.P. ignores it.
For members that do not participate in CVV2 pass-through processing and have not
successfully completed testing to receive data in field 126.10, V.I.P. drops field 126.10
before forwarding the message with the magnetic-stripe data to the issuer. This action
applies to BASE I transactions only.
Members that choose to use CVV2 pass-through processing identify participation at the
BIN level. Visa does not require them to participate in the CVV2 Service.

This section lists and describes key fields that pertain to the CVV2 Service.

Participating issuers have the option of using response code N7 (decline for CVV2 no
match) in field 39 to indicate that the transaction is not approved because the CVV2
values do not match. When the CVV2 values do not match, response code N7 indicates
that the transaction would have been approved if the CVV2 had been valid.

Issuers can also generate response code N7 when the merchant indicates that the
Visa card has no CVV2 printed on it (CVV2 presence indicator contains 9) and the
issuer knows that the card was imprinted with a CVV2. Issuers can return CVV2 Result
Code S—CVV2 Should Be on the Card But the Merchant Has Indicated That CVV2 Is
Not Present in subfield 44.10.
When the merchant receives response code N7 N7, the merchant has the option of
declining the transaction, or of resubmitting the authorization request with a different
CVV2 value or with no CVV2.
For verificaton-only responses, field 39 contains 85 (no reason to decline).
Field 44—Additional Response Data

This field contains miscellaneous data needed in a response message. Subfield 44.10
contains the CVV2 result code.
Message)—If the issuer has provided

Subfield 44.10—CVV2 Result Code (Request Message)—
Visa with its CVV2 encryption keys, V.I.P. verifies the CVV2 for participating issuers that
select the CVV2 ALL processing option and passes subfield 44.10 to the issuer in the
appropriate BASE I and SMS 0100, 0200, 0120, or 0220 messages.

The results codes can be:

• M—CVV2 Match: Indicates that V.I.P. or the issuer was able to verify the CVV2
value provided by the merchant.
• N—CVV2 No Match: Indicates that V.I.P. or the issuer was not able to verify the
CVV2 value provided by the merchant.
• P—Not processed: Indicates that V.I.P. or the issuer was unable to verify the CVV2
value provided by the merchant because its verification system was not functioning
or because not all of the information needed to verify the CVV2 value (such as the
expiration date) was included in the request.
• S—CVV2 should be on the card: Indicates that V.I.P. or the issuer was unable to
perform CVV2 verification and notifies the merchant that the card should contain a
CVV2 value.
• U—Issuer is not available, does not participate in the CVV2 Service, or participates
but has not provided Visa with encryption keys: Indicates that the issuer is not
participating in the CVV2 Service or has not provided Visa with encryption keys
needed to perform verification, or that STIP has responded to an issuer-unavailable
response.
CVV2 verification requires the card's expiration date. When a tested acquirer submits
an authorization request that does not include an expiration date, V.I.P. performs edit
checks on the transaction. If the transaction passes all tests, V.I.P. inserts code P in
subfield 44.10 and forwards the request to the issuer for further processing. If the issuer
can access the expiration date for the card from its systems, the issuer may be able
to calculate the CVV2.
The following rules apply for setting the CVV2 result code if the acquirer does not
provide the expiration date:
• If the issuer has successfully completed testing and has provided Visa with the
encryption keys, V.I.P. inserts code P in subfield 44.10.
• If the issuer is unavailable, has not successfully completed testing, or has not
provided Visa with the encryption keys, V.I.P. inserts code U in subfield 44.10.
Message)—If the issuer decides to override
Subfield 44.10—CVV2 Result (Response Message)—
the result sent from V.I.P., the issuer must return code M, N, P, or S in subfield 44.10.
If the issuer returns an invalid code, V.I.P. rejects the response back to the issuer
with reject code 0149 and returns the V.I.P. result code in subfield 44.10 to the
acquirer. If the issuer does not override the V.I.P. CVV2 result code in subfield 44.10,
V.I.P. returns the V.I.P. CVV2 result code to the acquirer if the merchant has requested
that V.I.P. return subfield 44.10 in the response message.
IMPORTANT
If the issuer is not available, does not participate in the CVV2 Service, or has not sent Visa its CVV2
encryption keys, V.I.P. always returns CVV2 result code U to the acquirer, even if the issuer tries to
override the V.I.P. CVV2 result code in subfield 44.10. This processing also applies to non-Visa products
such as American Express.
The merchant has the option of receiving subfield 44.10 in the authorization response.
If the merchant has indicated that V.I.P. is not to return subfield 44.10 (CVV2 response
type = 0), V.I.P. removes subfield 44.10 from the authorization response.

Club/Discover—V.I.P. includes this field in responses to the acquirer if

Diners Club/Discover—
field 126.10 is present in the request and the code in position 2 is 1, indicating that
field 44.10 carries the CVV2–specific result code and that field 39 carries the overall
response code.
Express—As indicated in the above note, American Express CID processing

American Express—
does not use field 44.10.
Field 126—Visa Private-Use Fields

Field 126 is an existing field that Visa defines in bit-mapped field format. Field 126 was
renamed: from Electronic Banking Fields to Visa Private-Use Fields.
Subfield 126.10—CVV2 Authorization Request Data— Data—The way in which merchants are
to use the three positions of subfield 126.10 of field 126 are as follows:
• Position 1—CVV2 Presence Indicator
Participating merchants enter code 1 in Position 1—CVV2 Presence Indicator of
subfield 126.10 when it provides the CVV2. If the merchant deliberately does not send
the CVV2, or if the CVV is unavailable, is illegible, or is not on the card, merchants
must use the CVV2 presence indicator code to indicate the reason why it did not
include the CVV2. (Refer to Table 25-2 for valid CVV2 presence indicator codes.)
Participating merchants enter code 9 in Position 1—CVV2 Presence Indicator when
the cardholder states that the card does not have the CVV2 printed on it. Code 9 is a
flag that prompts the issuer to confirm that the card was issued without the CVV2
imprinted on it. If the issuer issued the card with the CVV2 imprinted on it, this flag
alerts the issuer to possible fraudulent activity.
If the CVV2 presence indicator is other than 0, 1, 2, or 9, V.I.P. rejects the transaction
0148.
with reject code 0148
• Position 2—CVV2 Response Type

Participating merchants enter a code in Position 2—CVV2 Response Type of
subfield 126.10 in the authorization request to indicate that V.I.P. is to return the
CVV2 response. Merchants can receive only the response code in field 39 or can
receive the response code in field 39 and the CVV2 result code in subfield 44.10:
0 = Field 39 only
1 = Field 39 and subfield 44.10
V.I.P. inserts the default value 0 when the CVV2 response type is other than 0 or 1.
• Position 3—CVV2 Value
The code in Position 3—CVV2 Value of subfield 126.10 is the 3-digit value
indent-printed on the reverse side of the Visa card. Visa uses three digits while
other card products can use four digits.
- When merchants are not sending the CVV2, they should blank-fill this field.
- If the CVV2 Value field is other than blank-filled, V.I.P. processes the contents as
a CVV2.
- When merchants do send the CVV2, They should right-justify and blank-fill the field.

Table 25-4 describes Subfield 126.10—CVV2 Authorization Request Data in field 126.
Table 25-4 Subfield 126.10 Description
Position Format Valid Values Description

1 1 byte, 0 = The CVV2 value is not provided: Position 1—CVV2 Presence Indicator
alphanumeric Indicates that the merchant is in subfield 126.10 contains the 1-digit
not providing a CVV2 value for CVV2 presence indicator code.
verification. Merchants use this code to indicate
whether the CVV2 is imprinted on
1 = The CVV2 value is present:
the card. A value other than 1 in this
Indicates that the merchant is
field provides information about why
providing the CVV2 value for
the CVV2 was not included in the
verification.
authorization request message.
2 = The CVV2 value is on the card but is
illegible: Indicates that the merchant
wants to provide the CVV2 value
but cannot because the cardholder
states that the value is illegible.
3 = There is no CVV2 value on card:
Indicates that the merchant wants to
provide the CVV2 value but cannot
because the cardholder states that
there is no value on the card.
2 1 byte, 0 = The merchant wants only the Position 2—CVV2 Response Type in
alphanumeric response code in field 39 to be subfield 126.10 contains the CVV2
returned in the response. response type. Merchants insert a code
in this field to indicate the response data
1= The merchant wants the response
they want returned to them in response
code in field 39 and the CVV2
messages.
result code in subfield 44.10 to be
returned.
3–6 4 bytes, A 3-digit value on the back of the Visa card. Position 3—CVV2 Value in
alphanumeric subfield 126.10 contains the
3-digit CVV2 value. The number
is right-justified, and the rest of the field
is blank-filled. When issuers deliberately
do not send the CVV2 value, they should
initialize positions 3–6 with blanks.
25.8.1 Key Fields Glossary for CVV2 Emergency Replacement

This section describes key fields related to the Emergency Replacement Card (ERC)
enhancement to the CVV2 Service.
Field 48—Additional Data–Private, Usage 1a

The following is the field format when V.I.P. returns a CVV2 in this field.
Positions:
1–2 3–6
Length CVV Displacement CVV2 Value with Leading Zero
See “Table 25-2” in this chapter for a list of the CVV2 error codes.


The code in this field identifies a CVV2 emergency replacement value request.
0171.
The code must be 0171

For additional information about the CVV2 Service, refer to the following documents:
• Visa International Operating Regulations, Volumes 1 and 2
• September 1998 VisaNet Business Enhancements Technical Letter, Update Bulletin #2,
Publication DS-9803012, dated 31 August 1998
• September 1998 VisaNet Business Enhancements Member Implementation Guide,
dated 15 July 1998


Chapter 26 Cardholder Authentication Verification Value (CAVV)
Verification Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
IN BRIEF 26-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
CAVV Verification Service

REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
Issuer Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-5
Acquirer Processor Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
Required Verified by Visa Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-6
Issuer Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
Acquirer Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
HOW CARDHOLDER AUTHENTICATION VERIFICATION VALUE (CAVV)

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
VERIFICATION SERVICE WORKS 26-88
CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-9
Verifying CAVV Results From Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-15
Dispute Resolution Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-15
Ineligible Transactions Passing CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-16
When Transactions Contain Both a CAVV and a CVV2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-16
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
PROCESS FLOWS 26-16
16
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
17
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-
19


Chapter 26 Cardholder Authentication Verification Value (CAVV)
Verification Service
26.1 IN BRIEF
The CAVV Verification Service is part of a suite of services available through Verified
by Visa (VbV). VbV enhances the security of Internet purchases cardholders make with
Visa cards. The service allows issuers to register cardholders for the service and to
authenticate the cardholder as the owner of the card account when the cardholder makes
an online purchase at a participating merchant location. For information about VbV,

refer to the Visa Secure Electronic Commerce (VSEC) With Verified by Visa (3-D Secure)
chapter in Volume 1.
The Cardholder Authentication Verification Value (CAVV) is a cryptographic value the

issuer or V.I.P. generates and sends to the merchant during the authentication process in
a VbV transaction.
The Cardholder Authentication Verification Value (CAVV) Verification Service provides the
functionality to verify that the Cardholder Authentication Verification Value (CAVV) that an
acquirer submits in a Verified by Visa (3-D Secure) authorization message matches the
CAVV generated by the Visa Access Control Server (ACS) or by an issuer's ACS during
authentication.
The outcome of the CAVV validation determines the type of transaction, either
authentication, authentication attempt (attempt), or non-secure. Liability shifts when V.I.P.
classifies a transaction as an authentication or an attempt.
Issuers can optionally have V.I.P. verify the CAVV on their behalf.

The CAVV Verification Service is available to members in all Visa regions.

To participate in the CAVV Verification Service, members must participate in
Verified by Visa. Each region determines the requirements for participating in
Verified by Visa.
BASE I
The CAVV Verification Service is available both to BASE I System users and to
SMS
Single Message System (SMS) users.
BASE I and SMS
I All issuers can participate in the CAVV Verification Service. Participation is

mandatory if the issuer participates in Verified by Visa, regardless of the region.
Issuer
All acquirers can participate in the CAVV Verification Service. Participation is

A mandatory if the acquirer participates in Verified by Visa, regardless of the
region.
Acquirer

The CAVV Verification Service is a risk-control service participants use to authenticate
the cardholder in electronic-commerce (e-commerce) authorization transactions. The
verification process involves two phases:
1. Verified by Visa (VbV)
2. CAVV Verification Service
During the Verified by Visa phase, the issuer or V.I.P. electronically identifies the cardholder
and generates a CAVV that it associates with the purchase.
The CAVV Verification Service begins when the acquirer submits the authorization or full
financial message and includes the CAVV that the issuer or V.I.P. generated during the
VbV phase in the request. When the CAVV is present in the transaction, the issuer or V.I.P.
verifies that the CAVV in the message matches the CAVV generated during the Verified by
Visa phase. If the CAVV passes verification, the transaction has protection from certain
chargebacks should disputes arise later.
When the issuer or V.I.P. completes the CAVV validation process, it populates the results
of the validation in Field 44.13—CAVV Results Code. The value in this field indicates the
outcome of the validation, which entity performed the validation, and the classification of
the transaction (either authentication, attempt, or non-secure).

To validate the CAVV, the issuer or V.I.P. uses Data Encryption Standard (DES) keys
and other CAVV parameters to calculate the CAVV and then compares it to the CAVV
generated by the appropriate ACS. Issuers that choose to have V.I.P. perform verification
on their behalf must provide Visa with their DES keys.
Visa offers two CAVV Verification Service processing options to issuers that participate in
Verified by Visa—authentication and attempt.
Authentication—With this option, the issuer is a full participant in the service and has
Authentication—
cardholders enrolled in Verified by Visa. Visa classifies transactions as authentication
transactions when the acquirer, the issuer, and the cardholder all participate in Verified by

Visa.
Attempt—With this option, the issuer or V.I.P. generates a CAVV for attempted transactions.
Attempt—
Visa classifies transactions submitted by a participating acquirer as attempt transactions
when either the issuer or the cardholder does not participate in Verified by Visa. Liability
shifts for these types of transactions. This option is mandatory in some regions.
Visa encourages issuers to participate in both options.
Both options allow issuers to select a predefined process by which VisaNet is to process
their transactions both in Normal mode and during stand-in processing (STIP):
Standard Issuer CAVV Service/Standard Decline/Failure Option— With this option, VisaNet
performs all validations on the issuer's behalf, declines transactions when the CAVV
validation fails, and forwards the status results of transactions that VisaNet did not decline
to the issuer.
Option—With this option, VisaNet performs all

All CAVV Verification Results to the Issuer Option—
validations on the issuer's behalf and forwards all status results of transactions to the issuer.
Option—With this option, VisaNet forwards the

Issuer Supports Own CAVV Verification Option—
transactions to the issuer to perform validation. The issuer returns the status results in
the response message.
Depending on the region, VisaNet assesses interchange reimbursement fees (IRFs) based
on the CAVV Verification Service classification of the e-commerce transactions.
The CAVV Verification Service supports both magnetic stripe Visa cards and Visa Smart
Debit/Smart Credit (VSDC) cards.

CAVV Verification Service participation is mandatory for issuers and for acquirers that
participate in Verified by Visa.
26.4.1 Issuer Requirements

Issuers that choose to participate in the CAVV Verification Service must:
• Participate in Verified by Visa.
• Submit to Visa the selected CAVV Verification Service Normal mode and STIP processing
options for either authentication transactions, attempt transactions, or both.
• Submit the CAVV encryption keys to Visa.

• Modify their systems to support the required Verified by Visa fields.

• Complete regional requirements and forms.
Issuers that want to participate in the CAVV Verification Service should work with their Visa
representatives to establish CAVV keys and parameters.
26.4.2 Acquirer Processor Requirements

Acquirers that choose to participate in the CAVV Verification Service must:
• Participate in Verified by Visa.
• Submit the required Verified by Visa fields in V.I.P. messages. CAVV validation requires
these fields.
• Modify their systems to receive Field 44.13—CAVV Results Code.
26.4.3 Required Verified by Visa Fields

Table 26-1 lists the key Verified by Visa fields that Visa requires for CAVV validation and
that participants must support in V.I.P. messages.
Table 26-1 Required Verified by Visa Fields
Data Element Field Value Data Source

POS Entry Mode Field 22, Must be 01 (key entry) The merchant or the
Positions 1–2 acquirer
POS Condition Code Field 25 Must be 59 The merchant or the
(VSEC request) acquirer
Additional POS Information— BASE I: BASE I: The merchant or the
Mail/Phone/ Field 60.8 05, 06
Must be 05 06, or 07 acquirer
Electronic Commerce
and Payment Indicator SMS: SMS:
Field 63.6, Must be 5, 6, or 7
Position 4
Transaction Identifier (XID)1 Field 126.8 Must contain a The merchant
unique number the
merchant server
generates to identify
the transaction
CAVV Data Field 126.9, Must contain the The merchant
Usage 2 or 3 data value that
the V.I.P. Access
Control Server
(ACS) or the issuer's
ACS generated to
enable V.I.P. or the
issuer to validate
the cardholder
authentication results
1. Visa only requires field 126.8 when the merchant submits usage 2 of field 126.9.
26.4.4 Testing
Visa must test that participants can send or can receive the following fields:
• Field 44.13—CAVV Results Code
• Field 60.8—Mail/Phone/Electronic Commerce and Payment Indicator (for BASE I)
• Field 63.6—Chargeback Reduction/BASE II Flags, Position 4, MOTO/ECI (for SMS)

• Field 126.8—Transaction ID (XID)

• Field 126.9—CAVV Data, Usage 2 or 3
CAVV Verification Service participants. Members can contact their Visa representatives to
make the arrangements.

Service monitoring is not available for the CAVV Verification Service.

The following subsections identify issues that participants should consider when planning
for and implementing the CAVV Verification Service.
26.4.6.1 Issuer Considerations

Issuers that choose to participate in the CAVV Verification Service:
• Must pass testing to receive the e-commerce fields.
• Must modify their systems to support the required Verified by Visa fields and to supply
responses.
• Should always return the CAVV results code field.
• Do not have to provide CAVV DES keys to Visa. However, issuers must provide keys
when they select the following authentication or attempt options:
- Standard Issuer CAVV Service/Standard Decline/Failure option
- All CAVV Verification Results to the Issuer option
• Can choose to:
- Validate themselves that the CAVV they receive is correct.
- Accept the CAVV that VisaNet validates and forwards.
Issuers that choose to participate in the CAVV Verification Service should work with their
Visa representatives to establish the required parameters.
26.4.6.2 Acquirer Considerations

Visa must test acquirers before they can participate in the CAVV Verification Service.
Participating acquirers must modify their systems to submit the required Verified by Visa
data and to receive the CAVV results code field.

The following BASE I and SMS message types pertain to the CAVV Verification Service:
• 0100, 0110, 0120, and 0130 authorization requests, responses, and advices
• 0200, 0210, 0220, and 0230 full financial requests, responses, and advices
26.5.1 BASE I and SMS Authorization Requests
VisaNet supports the required Verified by Visa fields in:
• BASE I and SMS 0100, 0120, and 0130 authorization requests and STIP advices
• SMS 0200, 0220, and 0230 full financial requests and STIP advices
For more information about required Verified by Visa fields, refer to Table 26-1 in this
chapter.
26.5.2 BASE I and SMS Authorization Responses

VisaNet supports Field 44.13—CAVV Results Code in:

Chapter 26 How Cardholder Authentication Verification Value
(CAVV) Verification Service Works
• BASE I and SMS 0110 authorization responses

• SMS 0210 full financial responses
26.6 HOW CARDHOLDER AUTHENTICATION VERIFICATION VALUE (CAVV)

VERIFICATION SERVICE WORKS
A cardholder purchases goods on the Internet using a Visa card at a Web site where
the merchant is a Verified by Visa participant. If the issuer is a participant in Verified by
Visa, the issuer or V.I.P. generates a CAVV for the purchase. The CAVV Verification
Service enables the issuer or V.I.P. to validate the cardholder's CAVV that resulted from
the issuer's authentication decision during the online Verified by Visa purchase session.
When the acquirer submits the authorization request, the CAVV must be in the request
along with other required Verified by Visa fields.
When the issuer or V.I.P. completes the validation process, it populates Field 44.13—CAVV
Results Code. For information about valid values, refer to V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, and to V.I.P. System SMS POS (Visa & Visa
Electron) Technical Specifications, Volume 1 and Volume 2.
Acquirers include the CAVV and an electronic commerce indicator (ECI) in BASE I and SMS
0100 authorizations and in SMS 0200 full financial requests. Table 26-1 lists the key fields.
Acquirers determine the appropriate ECI value to submit in BASE I messages (field 60.8)
and in SMS messages (field 63.6) as follows:
• 05 or 5: the authentication was successful.
• 06 or 6: the merchant or the acquirer tried to authenticate the transaction. Either the
issuer or the cardholder is not enrolled in Verified by Visa.
• 07 or 7: the issuer or V.I.P. could not perform the authentication.
NOTE
ECI codes 08 or 8 and 09 or 9 are invalid for Verified by Visa transactions.

26.6.1 CAVV Validation

Table 26-2 summarizes the issuer CAVV Verification Service processing and STIP options
for full authentication transactions.
Table 26-2 CAVV Verification Service Processing Under Normal and STIP
Conditions for Full Authentication Transactions
Option and
Description V.I.P. Processing
Authentication Options—Normal Mode Processing
Authentication V.I.P. processes transactions as follows:

option 1: Standard • If CAVV ACS result = 0 (successful) andand:
Issuer CAVV Service - CAVV validation fails, V.I.P. declines the transaction with Response
05—Do Not Honor.
Code 05
V.I.P.: - CAVV validation is successful, V.I.P. forwards the transaction to the
• Performs all CAVV issuer with CAVV Results Code 2—CAVV Passed Validation.
validations on the • If CAVV ACS result = 5 (authentication attempted, not able to
issuer's behalf. complete):
• Declines - V.I.P. forwards the transaction to the issuer with CAVV Results
transactions when Code 0—CAVV Not Validated Due to Erroneous Data Submitted.
CAVV validation • If CAVV ACS result = 9 (failed):
fails. - V.I.P. forwards the transaction to the issuer with CAVV results code 0.
• Forwards status
results in
transactions that
it did not decline to
the issuer.
Authentication V.I.P. processes transactions as follows:
option 2: All CAVV • V.I.P. validates the CAVV submitted in the transaction.
Verification Results to • V.I.P. forwards all CAVV validation results to the issuer with the
Issuer appropriate code in the CAVV results code field.
V.I.P.:
• Performs CAVV
validation on the
issuer's behalf.
• Forwards all CAVV
validation results to
the issuer.

Table 26-2 CAVV Verification Service Processing Under Normal and STIP Conditions
for Full Authentication Transactions (continued)
Option and
Authentication The issuer does not provide Visa with its CAVV DES key(s). V.I.P. does
option 3: Issuer not perform CAVV validation. V.I.P. processes the transaction according
Supports Own CAVV to the existing issuer STIP parameters and either declines all transactions
Verification that contain a CAVV or ignores the presence or content of �eld 126.9.
V.I.P.:
• Does not validate
the CAVV for the

transaction.
• Forwards the CAVV
fields to the issuer
for the issuer to
perform CAVV
validation.
• Forwards the XID,
if present, to the
issuer.

Table 26-2 CAVV Verification Service Processing Under Normal and STIP Conditions
for Full Authentication Transactions (continued)
Option and
Authentication Options—STIP Processing
For Authentication V.I.P. processes transactions as follows:
options 1 and 2: • If CAVV ACS results code = 0, V.I.P.:
- Declines the transaction with response code 05 if the transaction
Issuers must establish contains CAVV data in field 126.9.
CAVV DES keys at - Returns the CAVV results code value in response and advice

Visa. messages.
or
- Ignores the presence and the content of field 126.9 and responds
- Returns the CAVV results code value in response and advice
messages.
• If CAVV ACS results code = 1, depending on issuer parameters, V.I.P.:
05.
- Declines the transaction with response code 05
messages.
or
- Ignores the presence and the content of field 126.9 and responds
messages.
• If CAVV ACS results code = 2, V.I.P.:
- Processes the transaction based on existing issuer STIP parameters.
- Returns the CAVV results code in response and advice messages.
For Authentication If issuers do not establish DES keys at Visa, V.I.P. cannot validate the
option 3: Issuer CAVV. V.I.P. processes the transactions according to the issuer's option.
supports own CAVV The options are:
verification. (Visa • Decline all transactions that contain CAVV data in field 126.9 with
does not require response code 0505.
issuers to establish • Ignore the presence and the content of field 126.9 and respond based
CAVV DES keys at on existing issuer STIP parameters.
Visa.)
If issuers establish CAVV DES keys at Visa, V.I.P. processes transactions
NOTE: using the STIP processing rules for Authentication options 1 and 2.
Issuers can choose
to establish CAVV
DES keys at Visa.

Table 26-3 summarizes the issuer CAVV Verification Service processing and STIP options
for attempt transactions.
Table 26-3 CAVV Verification Service Processing and STIP Options

Summary for Attempt Transactions
Option and
Attempt Options—STIP Processing
Attempt Options—Normal Mode Processing
Attempt option 1: V.I.P. processes transactions as follows:

Standard • If CAVV ACS result = 7 (authentication attempt) and:
Decline/Failure - CAVV validation fails, V.I.P. declines the transaction with response
code 05 and returns CAVV results code 4 or 7.
V.I.P.: - CAVV validation is successful, V.I.P. forwards the transaction to the
• Performs all CAVV issuer with CAVV results code 3 or 8.
validations on the • If CAVV ACS result = 8 (authentication attempted, not able to complete
issuer's behalf. because issuer ACS is unavailable) and:
• Declines - CAVV validation fails, V.I.P. declines the transaction with response
transactions when code 05 and returns CAVV results code 9.
CAVV validation - CAVV validation is successful, V.I.P. forwards the transaction to the
fails. issuer with CAVV results code A.
• Forwards status
results in NOTE:
transactions that Only the Visa U.S.A. (U.S.) region uses CAVV ACS results code 8.
it did not decline
to the issuer.
Attempt option 2: All V.I.P. processes transactions as follows:
CAVV Verification • V.I.P. validates the CAVV submitted in the transaction.
Results to Issuer • V.I.P. forwards all CAVV validation results to the issuer with the
appropriate CAVV results code.
V.I.P.:
• Performs CAVV
validation on the
issuer's behalf.
• Forwards all CAVV
validation results to
the issuer.

Table 26-3 CAVV Verification Service Processing and STIP Options Summary
for Attempt Transactions (continued)
Option and
Attempt option 3: V.I.P. processes transactions as follows:
Issuer Supports Own • If CAVV ACS result = 7 (authentication attempt):
CAVV Verification - V.I.P. forwards the CAVV and the XID fields to the issuer to perform
CAVV validation.
V.I.P.: - Issuers validate the CAVV based on the CAVV calculation method

• Does not validate specified in the 3-D Secure protocol. Issuers return the results
the CAVV for the of CAVV validation in the CAVV results code field in response
transaction. messages.
• Forwards the CAVV • If CAVV ACS result = 8 (authentication attempted, not able to complete
field to the issuer for because issuer ACS is unavailable) and:
the issuer to perform - CAVV validation fails, V.I.P. declines the transaction with CAVV
CAVV validation. results code 9.
• Forwards the XID, - CAVV validation is successful, V.I.P. forwards the transaction to the
if present, to the issuer with CAVV results code A.
issuer.
NOTE:
Only the Visa U.S.A. (U.S.) region uses CAVV ACS results code 8.
For Attempt options 1 V.I.P. processes transactions as follows:

and 2: Participating • If CAVV ACS result = 7 (authentication attempt) and:
issuers can establish - CAVV validation fails, V.I.P. declines the transaction with response
attempt CAVV DES code 05 and returns CAVV results code 7.
keys at Visa. - CAVV validation is successful, V.I.P. does not forward the CAVV
results code to the issuer. V.I.P. processes the transaction using
processing rules according to the transaction characteristics and to
issuer-specified STIP processing parameters.
- V.I.P. returns the CAVV results code in response and advice
messages.
• CAVV ACS result = 8 (authentication attempted, not able to complete
because issuer ACS is unavailable) and:
- CAVV validation fails, V.I.P. declines the transaction with response
code 05 and returns CAVV results code 9.
- CAVV validation is successful, V.I.P. does not forward the CAVV
results code to the issuer. V.I.P. processes the transaction using
processing rules according to the transaction characteristics and to
issuer-specified STIP processing parameters.
- V.I.P. returns the CAVV results code in response and advice
messages.
NOTE:
Only the Visa U.S.A. (U.S.) region uses CAVV ACS results code 8.

Table 26-3 CAVV Verification Service Processing and STIP Options Summary
for Attempt Transactions (continued)
Option and
For Attempt option 3: V.I.P. processes transactions as follows:
Issuers support own • If CAVV ACS result = 7 (authentication attempt), V.I.P. cannot
CAVV verification validate the CAVV if the issuer does not establish DES keys at Visa.
(Visa does not require V.I.P. processes the transaction according to the issuer's option. The
issuers to establish options are:
CAVV DES keys at - Decline all transactions that contain CAVV data in field 126.9 with
Visa.) 05. V.I.P. does not include field 44.13 in response or
response code 05
advice messages.
NOTE:
- Ignore the presence and the content of field 126.9 and respond
Issuers can choose to
establish CAVV DES based on existing issuer STIP parameters.
keys at Visa. If the • If the CAVV ACS result is 8 (authentication attempted, not able to
issuer does provide complete because issuer ACS is unavailable), V.I.P.:
CAVV DES keys, - Processes the transaction based on existing issuer STIP parameters.
V.I.P. processes - Returns the CAVV results code in response and advice messages.
transactions using
the STIP processing NOTE:
rules for Attempt Only the Visa U.S.A. (U.S.) region uses CAVV ACS results code 8.
options 1 and 2.
For BASE I, if the issuer's selected CAVV Attempt or Authentication option in the Customer
Online Repository (CORE) is F or V, V.I.P. forwards the field 44.13 CAVV result code in the
request to the issuer. If the issuer responds with a code other than the one it received,
V.I.P. overrides the issuer's result code with its own before it sends the response to the
acquirer.
26.6.2 Verifying CAVV Results From Issuers

If participating issuers performing their own CAVV verification include CAVV results
code 0 (CAVV authentication results invalid) in the response, V.I.P. verifies the CAVV in
Field 126.9—CAVV Data, before forwarding the response to the acquirer.
• If Visa has the issuer's CAVV keys, and the CAVV results code validated by V.I.P. is not 0
(indicating that the first three positions of field 126.9 are valid), V.I.P. replaces code 0 in
field 44.13 with a valid CAVV results code and forwards the response to the acquirer.
• If Visa does not have the issuer's CAVV keys, and V.I.P. determines that the first three
positions of the CAVV field 126.9 do contain valid values, V.I.P. replaces code 0 in
field 44.13 with code C (CAVV was not validated—attempt) or code D (CAVV was not
validated—authentication) and forwards the response to the acquirer.
• If Visa has the issuer's CAVV keys, and the CAVV Results Code validated by V.I.P. is 0
(indicating that the first three positions of field 126.9 are not valid), then results code 0
is correct and VisaNet forwards the response to the acquirer.
IMPORTANT
If the issuer chooses to have V.I.P. validate the CAVV and receive the results in field 44.13, then revalidates
the CAVV using its own ACS and populates field 44.13 with a different value than that sent by V.I.P.,
V.I.P. overrides the value generated by the issuer with the value it forwarded to the issuer before sending
the response to the acquirer.

26.6.3 Chargeback Protection

To encourage participation by all parties, if a merchant tries to authenticate a cardholder,
Visa protects the merchant from certain chargebacks. If the merchant meets all required
conditions and tries to authenticate, liability for the transaction shifts, even if the issuer does
not participate or if the cardholder is not enrolled in Verified by Visa. Visa also protects
merchants from certain chargebacks when VisaNet or the issuer fully authenticates the
transaction.
The following types of transactions are not eligible for chargeback protection:
• Transactions using Visa Commercial cards (Visa Business, Visa Purchasing,

and Visa Corporate)
• Transactions using “anonymous” cards, such as gift cards and prepaid cards
• Transactions conducted in New Channels or in other devices that do not use a standard
Hypertext Markup Language (HTML) browser to process an authentication request
EXAMPLE
Any environment in which a cardholder initiates payment by a Cardholder-Access Device for electronic
commerce.
EXAMPLE
A cardholder uses a mobile phone to conduct a mail order or telephone order (MOTO) transaction.
• Transactions merchants submit in the Global Merchant Chargeback Monitoring Program.

Table 26-4 lists the chargeback reason codes for which issuers cannot submit chargebacks
of authentication or attempt transactions.
Table 26-4 Chargeback Reason Codes the CAVV Verification Service Does Not Allow
Reason
Code Description International U.S.
23 Invalid travel and entertainment (T&E) transactions ✓ ✓
61 Fraudulent mail order or telephone order (MOTO) or ✓
electronic commerce transaction
75 Cardholder does not recognize transaction ✓
83 Non-possession of card (fraudulent) transaction ✓
26.6.4 Dispute Resolution Processing

Visa allows issuers to dispute successfully authenticated transactions for reasons such
as the customer did not receive the merchandise or the transaction was a duplicate
transaction. However, issuers cannot submit successful authentication or attempt
transactions for the chargeback reason codes listed in Table 26–4.
Issuers can charge back an e-commerce transaction if V.I.P. or the issuer generated the
CAVV during the Verified by Visa phase, but the merchant or the acquirer does not submit
the CAVV in the authorization request.

26.6.5 Ineligible Transactions Passing CAVV Validation

When a transaction contains a CAVV, but the accompanying ECI in field 60.8 is not 5
or 6, the CAVV is nevertheless validated. V.I.P. generates code B for field 44.13. Code B
means the transaction is ineligible for Verified by Visa processing, and no liability shift
occurs. Transactions involving Visa Business, Visa Corporate, or Visa Purchasing cards
are not eligible for CAVV processing. Only V.I.P. is allowed to generate code B; the system
uses it for Visa-internal processing only.
26.6.6 When Transactions Contain Both a CAVV and a CVV2

V.I.P. accepts Visa authorization and full financial requests submitted with both a
Cardholder Authentication Verification Value (CAVV) and a Card Verification Value 2
(CVV2). When V.I.P. receives a request containing both a CAVV and a CVV2, the CAVV
validation result takes precedence over the other risk control's verification result.
This priority processing also applies to issuer-unavailable transactions that V.I.P. sends
to STIP: if the CAVV passes the validation process, but the CVV2 fails the verification
process, STIP does not decline the transaction because of the CVV2 failure.
When a CAVV and a CVV2 are present, V.I.P. validates the CAVV first:
• If the CAVV validation is successful, V.I.P. verifies the CVV2, and forwards both results
to the issuer and to the acquirer in the response. (The CVV2 result is contained in
field 44.10; the CAVV result is contained in field 44.13).
• If the CAVV validation fails, CAVV Verification Service rules apply:
- If the issuer specifies that V.I.P. is to decline all transactions that fail the CAVV check,
V.I.P. declines the transaction without verifying the CVV2.
- If the issuer specifies that V.I.P. is to forward all results to the issuer regardless of
the outcome, V.I.P. validates the CVV2 and includes both field results in the request
to the issuer.
NOTE
If the issuer approves the authorization request that contains a successful CAVV result, the issuer may not
submit a chargeback for reason code 23 (T&E—invalid transaction) or 61 (fraudulent mail order or telephone
order transaction).
If STIP validates the CAVV in a request that includes a CVV2 value:

• If the CAVV value is valid, STIP validates the CVV2 value and follows the issuer’s CVV2
STIP parameter rules.
- If the CAVV value is valid but the CVV2 value fails verification, the CAVV result takes
precedence and STIP follows the CAVV-related processing specifications.
• If the CAVV validation fails, STIP declines the transaction without validating the CVV2.
If STIP cannot complete the CAVV validation process, STIP still uses the issuer-specified
CAVV processing parameters:
• If STIP is to continue processing, it verifies the CVV2 according to the related processing
parameters.
• If STIP is to decline the transaction if CAVV validation fails, STIP validates the CVV2
and sends a decline response.
26.7 PROCESS FLOWS

The process of verifying the CAVV consists of the following steps:

1. The acquirer submits the CAVV in the authorization or full financial message.
2. The issuer or V.I.P. generates the CAVV.
3. The issuer or V.I.P. verifies whether the CAVV in the message matches the CAVV
generated by V.I.P. or by the issuer.
4. The issuer or V.I.P. populates the results in Field 44.13—CAVV Results Code and
returns the status results in the response message.

This section lists and describes key fields associated with the CAVV Verification Service.

the SMS POS technical specifications manuals for detailed field descriptions.

Code 59 in this field signifies that the transaction is an e-commerce request.
Successfully tested issuers receive code 59 in this field. For issuers that have not
successfully completed testing, V.I.P. replaces code 59 with code 0808, which indicates a
mail order or telephone order (MOTO) request.
Merchants or acquirers supply field 25, and Visa requires the field in:
• Authorization requests, reversals, and advices
• Full financial requests, reversals, and advices
• Merchandise credits and advices
VisaNet returns the field in responses.
Field 44.13—CAVV Results Code

Field 44.13—CAVV Results Code contains a 1-digit code that indicates the outcome of
the validation, the entity that performed the validation (either the issuer or V.I.P.), and
the classification of the transaction. Visa classifies transactions as:
Authentication—The cardholder, the acquirer, and the issuer all participate in Verified
Authentication—
by Visa.
Attempt—The issuer or the cardholder does not participate in Verified by Visa.

Attempt—
Non-Secure—Both the acquirer and the issuer do not participate in Verified by Visa.
Non-Secure—
The issuer or V.I.P. populates this field in authorization and full financial responses.
Field 60, Positions 9–10, Mail/Phone/Electronic Commerce and Payment Indicator

Field 60.8 (positions 9–10)—Additional POS Information contains a 2-digit code that
indicates the level of security for a CAVV transaction. Valid ECI values are:
• 05
05—Secure electronic commerce transaction.
• 06
06—Non-authenticated security transaction at a Verified by Visa merchant and
the merchant tried to authenticate the cardholder according to Verified by Visa
procedures.
• 07
07—Non-authenticated security transaction.
Merchants or acquirers supply this field, and Visa requires it in authorization requests, in
reversals, and in advices. VisaNet does not return it in responses.
BASE I drops field 60.8 if the issuer has not successfully completed testing to receive it.

Field 63.6, Position 4, Mail/Telephone or Electronic Commerce Indicator

Position 4 of Field 63.6—Chargeback Reduction/BASE II Flags contains a 1-digit code
that indicates the level of security for a CAVV transaction. Valid ECI values are:
• 5—Secure electronic commerce transaction.
• 6—Non-authenticated security transaction at a Verified by Visa merchant and
the merchant tried to authenticate the cardholder according to Verified by Visa
procedures.
• 7—Non-authenticated security transaction.
Merchants or acquirers supply this field, and Visa requires it in authorization requests,
reversals, and advices. Visa also requires it in adjustments, merchandise credits,

chargebacks, and chargeback reversals, as well as in their related advices, and in fraud
advices. VisaNet does not return it in responses.
Field 63.6, position 4, is a retain-and-return field. Exception transactions must contain

the same value in this field as that in the original financial transaction.
Field 126.8—Transaction ID (XID)

The XID is a unique number the merchant server generates to identify the transaction.
This ID is part of field 126.9.
Visa no longer requires this field in e-commerce transactions in some regions. When
required, merchants or acquirers supply this field, and it appears in 0100 authorization
requests and in 0200 financial requests. VisaNet does not return it in 0110 or 0210
responses. Reversals do not use this field.
Field 126.9—CAVV Data; Usage 2, 3-D Secure CAVV

This field contains the CAVV that the Visa ACS or the issuer's ACS calculates, and the
acquirer inserts in the authorization or financial request.
NOTE
Field 126.9 is an optional field for SMS quasi-cash 0100 transactions.
Some regions no longer use usage 2 in e-commerce transactions. When required,

merchants or acquirers supply this field, and it appears in 0100 authorization requests
and in 0200 financial requests. VisaNet does not return it in 0110 or 0210 responses.
Reversals do not use this field.
Field 126.9—CAVV Data; Usage 3, 3-D Secure CAVV, Revised Format

This field usage contains an authentication tracking number (ATN) and the Cardholder
Authentication Verification Value (CAVV) in compressed format. The CAVV value is
unique to the cardholder and to the transaction that was authenticated. The ATN
replaces the need for the XID in field 126.8.
Merchants or acquirers supply this field, and it appears in 0100 authorization requests
and in 0200 financial requests. VisaNet does not return it in 0110 or 0210 responses.
NOTE
Field 126.9 is an optional field for SMS quasi-cash 0100 transactions.


For additional information about the CAVV Verification Service, refer to the following
documents:
• Visa International Operating Regulations, Volume 1 and Volume 2
• April 2003 VisaNet Business Enhancements Technical Letter , Update Bulletin #1,
Publication 80015–02, dated 17 December 2002
• April 2003 VisaNet Business Enhancements Member Implementation Guide,
Update Bulletin #1, Publication 80016–01, dated 13 January 2003


Chapter 27 Custom Payment Service (CPS)/ATM
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
IN BRIEF 27-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
BASE I and SMS CPS Processing Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-4
CPS/ATM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-5
Liability for Non-Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-5
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-6
Custom Payment Service (CPS)/ATM

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
HOW CUSTOM PAYMENT SERVICE (CPS)/ATM WORKS 27-77
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
PROCESS FLOWS 27-77
Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-8
Downgraded Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
Special ATM Handling Fee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
Authorization vs. Clearing Amounts. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .27-10
Reclassified Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
Delivering the Transaction to the Issuer. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .27-10
Exception Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-11
V.I.P. Field Edit and DRC Requirements for CPS/ATM Authorization Requests. . . .27-13
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
14
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-
15
Other Related Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-15


Chapter 27 Custom Payment Service (CPS)/ATM
27.1 IN BRIEF
Custom Payment Service (CPS)/ATM is an incentive program that provides accurate
settlement and improved management of cardholders' accounts through better matching of
messages, from authorization through clearing, using a unique transaction identifier (TID).
In addition, CPS/ATM ensures more timely delivery of clearing records by acquirers and
reduces exception item processing by improving transaction integrity and life-cycle control.
NOTE
This service description applies only to international participants. Visa U.S.A. (U.S.) participants should see
the latest U.S. Interchange Reimbursement Fee (IRF) Rate Qualification Guide.
NOTE
Visa charges a special handling fee for international ATM transactions that are not submitted for CPS/ATM
consideration or that fail to meet CPS/ATM fee edit criteria. This special ATM handling fee is USD$5.00
and appears on the monthly Integrated Billing statement. The fee is not charged for a representment nor

returned to the acquirer for a chargeback. Additionally, a CPS/ATM transaction submitted for clearing after
the 3-calendar-day processing limit is not returned to the acquirer but is settled and assessed a minimum
special ATM handling fee of USD$5.00.
CPS/ATM is available to members in all Visa regions.
BASE I
SMS CPS/ATM is available both to BASE I System users and to Single Message
System (SMS) users.
BASE I and SMS
I Participation in CPS/ATM is optional for BASE I System issuers and to Single

Issuer
Participation in international (non-domestic) CPS/ATM or in the Single Message

A System (SMS) is mandatory for all existing ATM acquirers.
For details about acquirer liability, refer to “Liability for Non-Participation” in

Acquirer this chapter.


Custom Payment Service (CPS) is a set of special transaction processing requirements that
help members reduce fraud and exception item processing costs by providing features such
as improved transaction integrity and life-cycle control. Built on the Payment Services 2000
foundation introduced in 1993, CPS supports domestic POS transactions and international
ATM transactions with custom rate incentive programs for different markets.
27.3.1 BASE I and SMS CPS Processing Overview

This section summarizes CPS processing as it applies to all CPS programs.
For acquirers, CPS protects against authorization-related chargebacks by requiring the

authorization request to contain certain key information that might not otherwise be present
to provide a more complete picture of the transaction conditions and to help validate
cardholder authenticity.
For issuers, CPS increases risk control and improves account balance management.
Issuers can accurately match a transaction's authorization and clearing messages using
a unique transaction identifier (TID) that is assigned by the Visa Integrated Payment
(V.I.P.) System.
Transactions ineligible for CPS are described in the operating regulations and include
quasi-cash and transactions submitted from certain “high-risk” merchants. Refer to the
Visa International Operating Regulations for more information about high-risk merchants.
V.I.P. applies CPS processing rules by editing authorization and full financial requests for
specific field values. If, during the authorization phase, a request cannot qualify because
it fails an edit or a combination of edits, and if the failure of an edit does not cause
the message to be returned to the sender as a reject, V.I.P. assigns the request a CPS
downgrade reason code (DRC) that indicates which requirement was not met. Downgraded
requests can still be approved; non-CPS processing continues, assuming that there are no
conditions to cause an outright message reject.
BASE I only attempts to assign an authorization characteristics indicator (ACI) or a

downgrade reason code (DRC) during the processing of an 0100 authorization request.
Not all CPS key fields required in a request for it to qualify for a given CPS program are
checked during the authorization phase, only those necessary to determine initial CPS
qualification. Incentive fee assignments for dual-message transactions are made during the
BASE II clearing process in which the BASE II clearing record's “CPS key field content”
from the authorization request is examined along with BASE II-specific data. To qualify for
a particular CPS incentive program, dual-message transactions may require an acquirer
to provide more information in a BASE II clearing message than was necessary for the
respective authorization request to qualify.
For single-message transactions, SMS assigns the ACI or the DRC, and if the request
qualifies, clears the transaction according to CPS parameters. The requested incentive fee
is included with the 0200 financial request in Field 63.11—Reimbursement Attribute. In the
case of a POS BASE I acquirer and an SMS issuer, the acquirer conveys the incentive fee
information to the issuer in BASE II-generated 0220 deferred clearing advices.

27.3.2 CPS/ATM
Custom Payment Service (CPS)/ATM applies to international Visa or Plus transactions
that originate at an ATM at which the card and the personal identification number (PIN)
are present.
This service description describes the CPS/ATM incentive program processing

requirements for BASE I dual-message cash disbursement transactions.
To qualify for the CPS/ATM program rate, a transaction must have the following
characteristics:
• The request includes Track 2 magnetic stripe or chip card track data and a
cardholder-entered PIN. If Field 35—Track 2 Data in an authorization request or balance
inquiry does not contain the Track 2 magnetic stripe data, V.I.P. rejects the message with
reject code 0291 (field missing).
• The merchant category code (MCC) must be 6011 (ATM).
• The ATM location and the card acceptor information that are required in fields 41, 42,
and 43, are present.
• The clearing transaction must include the ACI, the TID, and the validation code received
from V.I.P. with the authorization response.
• One authorization per clearing transaction is allowed.

• The authorization amount must match the clearing amount exactly.
• The transaction must clear within three days.
NOTE
The CPS/ATM rate structure can also be obtained using the Single Message System (SMS).
27.3.3 Liability for Non-Participation

Participation in CPS/ATM or in SMS and compliance with Tier II requirements are
mandatory for ATM acquirers. Acquirers that meet both the business and technical
qualifications receive Tier II fees.
SMS processing is mandated for all ATM acquirers in the U.S. region and for all new ATM
acquirers in all regions. All existing ATM acquirers must successfully complete testing for
SMS or for CPS/ATM processing and thereby meet Tier II requirements.
International ATM transactions that do not meet these criteria lose all international cash
disbursement fees. International ATM transactions that do not qualify for SMS or for
CPS/ATM are returned to acquirers for resubmission and are assessed a minimum special
ATM handling fee of USD$5.00.

CPS acquirers and issuers must successfully complete testing to send and to receive
CPS-specific fields. U.S.-domestic acquirers and issuers must participate in CPS. Non-U.S.
region participation is optional.
There are two levels of Visa International ATM Service that correspond to different cash
disbursement fees. Acquirers receive a fee based on the tiered service level for which
they qualify.
Tier I requirements for acquirers are as follows. Acquirers must:

• Provide the basic ATM cash withdrawal service and accept Visa cards and cards bearing
the Plus symbol.
• Comply with the applicable Visa International Operating Regulations requirements,
including but not limited to:
- Online reversal processing
- Authorization and clearing processing through the same network
- Acceptance of Visa and Plus cards encoded with an unrecognized service code
- No expiration date editing
• Use the V.I.P. System Multicurrency Service for authorization requests.
• Perform timely installation and use of the Visa and Plus routing tables for transaction
routing.
Tier II requirements for acquirers are as follows. Acquirers must:
• Meet Tier I requirements
• Participate in SMS or, for dual-message acquirers, participate in the CPS/ATM Service.
• Comply with the Visa international acquirer quality service standards.
• Participate in the Card Verification Value (CVV) Service. Plus authorization requests
must include code 05 or 90 in Field 22—Point-of-Service Entry Mode Code to be eligible
for CVV checking.
• Comply with customer account selection standards.
NOTE
To qualify for the Tier II fee, an acquirer must have completed the necessary service testing, demonstrating that
it meets business and technical qualifications.
27.4.1 Testing
CPS/ATM testing is currently available for dual-message Visa/Plus international ATM
acquirers and issuers. Members can contact their Visa representatives to make
arrangements for testing.

Although all members should review their own processing as it relates to participation in
CPS/ATM, Visa regional offices also review ATM activity to identify possible problems
that may require acquirers to make system changes to meet the CPS/ATM technical and
business requirements.
Some areas of review include:

• Identifying acquirers not submitting valid Track 2 data.
• Matching the account selection code in BASE I authorization request messages with
the value provided in the clearing records.
• Matching the BIN used in the acquirer ID of the BASE I authorization messages against
the acquirer ID in the BASE II clearing records.
• Ensuring that the authorization codes provided in BASE I responses are provided
accurately in the BASE II clearing records.

See the CPS/ATM for BASE I and BASE II Members Member Implementation Guide for
details about implementation.

Chapter 27 How Custom Payment Service (CPS)/ATM Works
27.5 HOW CUSTOM PAYMENT SERVICE (CPS)/ATM WORKS

V.I.P. examines ATM authorization requests from acquirers to see if they meet the eligibility
requirements for CPS/ATM.
If the authorization request qualifies:

• V.I.P. changes the authorization characteristics indicator (ACI) in field 62.1 to reflect
the successful evaluation.
• V.I.P. inserts its generated TID in field 62.2 in the message.
• V.I.P. forwards the message to the issuer (or to STIP) for an approval or decline decision.
If the authorization request fails to qualify for CPS/ATM, and V.I.P. has found no reason to
reject the message:
• V.I.P. changes the ACI in field 62.1 to indicate a non-qualified transaction, inserts a
system-generated TID in field 62.2, and forwards the message to the issuer for an
approval or decline decision.
• V.I.P. returns the downgrade reason code 22 in field 62.3.
• If field 35 does not contain the Track 2 magnetic stripe data, V.I.P. rejects the
authorization request or balance inquiry with reject code 0291 (field missing).
If the issuer approves the CPS/ATM-qualified request, V.I.P. ensures that the ACI is
present in the response for the acquirer and adds the validation code in field 62.3. If the

issuer declines the CPS/ATM-qualified request, the system returns the ACI unchanged to
the acquirer and adds downgrade reason code NA to field 62.3.
If the issuer approves the non-qualified request, V.I.P. sets the ACI to N (not qualified),
inserts the appropriate DRC in field 62.3, and forwards the response to the acquirer. If the
issuer declines a qualified request, V.I.P. sets the ACI to N and adds downgrade reason
code NA to field 62.3.
27.6 PROCESS FLOWS

This section provides an overview the ATM payment service process by illustrating a
transaction from authorization through clearing in a dual-message environment.
In dual-message processing, the acquirer submits separate authorization and clearing

transactions. All dual-message ATM transactions must be authorized through the V.I.P.
System and be cleared through the BASE II System.
NOTE
All international ATM transactions must qualify for CPS/ATM processing. Issuers not participating in CPS/ATM
are not required to make changes either to their authorization systems or to their clearing systems. They will
not receive any new fields relating to CPS/ATM.
The CPS/ATM process flow consists of the following steps:

1. The acquirer submits an authorization request with an authorization characteristics
indicator (ACI) to indicate that this is a CPS transaction.
2. V.I.P. ensures that the transaction meets the criteria and evaluates the characteristics
of the request, then replaces the ACI value to reflect the authorization characteristics
of the transaction.

- V.I.P. generates a unique TID and passes it with the ACI to the issuer (if the issuer
is participating in CPS/ATM and chooses to receive it).
3. The issuer approves the transaction, sends the transaction back to V.I.P. with the
authorization response code, and optionally returns the ACI and the TID.
4. V.I.P. generates a validation code based on key authorization fields. Table 27-1
identifies the fields protected by the validation code. V.I.P. forwards the validation code
with the ACI, the TID, and the authorization response code to the acquirer.
NOTE
The validation code is not present in advices to issuers.
Table 27-1 CPS/ATM Fields Protected by CPS Validation Code
Fields Protected by the Validation Code

Field Name Default
2 Primary Account Number None
3 Processing Code, positions 3–4, Account Type “from” None
4 Amount, Transaction None
18 Merchant Type None
22 POS Entry Mode Code (positions 1–2) None

28 Amount, Transaction Fee None
32 Acquiring Institution Identification Code None
38 Authorization ID Response None
39 Response Code None
43 Card Acceptor Name/Location; positions 39–40, Country Code None
49 Currency Code, Transaction None
62.1 Authorization Characteristics Indicator None
62.2 Transaction Identifier None
62.23 Card-Level Results None
5. The acquirer submits a clearing message to BASE II with a Requested Payment Service
(RPS), which specifies CPS/ATM. The clearing transaction contains the ACI, the TID,
and the validation code received from V.I.P. with the authorization response.
6. BASE II regenerates the validation code and validates that the key authorization fields
contained in the clearing transaction match those sent in the authorization request and
in the CPS fields received in the outgoing response. BASE II applies edits to ensure that
the transaction qualifies for CPS/ATM.
VisaNet then forwards the transaction to the issuer with the ACI, the TID, TCR 5 record,
and the RPS (if the issuer participates in CPS/ATM and chooses to receive these).
The issuer uses the TID to match the clearing transaction to the authorization.
27.6.1 Authorization
Transactions requesting qualification for the CPS/ATM Service contain the following key
data elements:

• Authorization characteristics indicator (ACI).

• ATM owner and location data.
• Entire, unaltered Track 2 magnetic stripe contents in field 35. If field 35 does not contain
the Track 2 magnetic stripe data, V.I.P. rejects the authorization request or balance
inquiry with reject code 0291 (field missing).
All Visa and Plus international ATM transactions must be processed through the V.I.P.
System. CPS/ATM requests must include an ACI value of Y.
Plus transactions must include POS entry mode code 05 or 90 in field 22 to be eligible
for CVV checking.
Table 27-2 correlates the ACIs supplied by the acquirer with the values returned by V.I.P.
Table 27-2 Authorization Characteristics Indicator (ACI) Values
Value
Submitted V.I.P. Value
by Validation Returned to
Acquirer Authorization Criteria Result Acquirer
Y • Full contents of the Track 2 data of the magnetic Card present E
stripe were transmitted. with valid data.

• Card authentication performed through Card
Verification Value (CVV) Service.
• ATM owner and location data submitted in the
authorization request.
• Retrieval reference number value contains a valid
date.
• Acquirer BIN is valid.
Y Authorization does not qualify as a CPS/ATM Transaction N
transaction. downgraded.
Not = Y Field 62 is not forwarded to issuer or returned to ACI invalid. Omitted
acquirer.
27.6.1.1 Downgraded Transactions

V.I.P. inserts a CPS downgrade reason code for transactions intended for CPS/ATM
qualification but that fail to meet the validation criteria. See V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, for more information about CPS downgrade
reason codes.
27.6.1.2 Special ATM Handling Fee

Visa does not charge the fee on a representment and does not return it to the acquirer on a
chargeback. The fee appears on the monthly Integrated Billing statement in addition to any
other special ATM handling fees, such as that for submitting a transaction for clearing after
the 3–calendar-day limit.
27.6.2 Clearing
All Visa and Plus international ATM transactions using dual-message processing must be
cleared through BASE II. One authorization per clearing record is allowed.
Each CPS/ATM clearing message must include the transaction identifier (TID), an
authorization characteristics indicator (ACI) with the value E, the validation code from

the authorization response, and key CPS/ATM fields used to develop the validation
code. All authorization requests must have been approved and the clearing message
submitted within three calendar days from the transaction date (as opposed to four days
for non-CPS/ATM transactions).
Additionally, the clearing transaction must include the acquirer's request for the CPS/ATM
fee through the use of the Requested Payment Service (RPS). The RPS value 9 indicates
that the transaction complies with the CPS/ATM authorization and clearing qualification
rules.
To qualify a transaction for CPS/ATM, V.I.P. performs a validation code check to ensure
that key authorization and clearing data elements are identical. A successful validation
confirms that the transaction has been properly authorized.
If the criteria is met (ACI = E, RPS = 9, clearing occurs within the 3-day period), BASE II
qualifies the transaction for the CPS/ATM Tier II rate.
• If all of the criteria except the clearing timeliness is met, BASE II reclassifies the
transaction, and acquirers receive a TC 04—Reclassification Advice with reclassification
reason code 1R (transaction does not meet the timeliness criteria for the requested
interchange). These transactions qualify for the Tier I rate.
• If all of the criteria except the validation code matching is met, BASE II reclassifies the
transaction, and acquirers receive a TC 04—Reclassification Advice with reclassification
reason code HO (validation code in the authorization and clearing transactions do not
match). These transactions still qualify for the Tier II rate. Visa will use the product ID
from the cardholder database (CDB) for account ranges that participate in ALP or the Edit
Package ARDEF Table for account ranges that do not participate in ALP.
27.6.2.1 Authorization vs. Clearing Amounts

Authorization amounts must be equal to (but can be greater than) their clearing amounts.
If the source amount in the TCR 0, BASE II Draft Data, is equal to or less than the
authorized amount in the TCR 5, Payment Service Data, BASE II allows the transaction to
be eligible for the CPS/ATM Tier II rate. This processing supports misdispense transactions.
27.6.2.2 Reclassified Transactions

BASE II reclassifies transactions that do not meet the authorization-related edits for
CPS/ATM as non-CPS transactions. BASE II updates the ACI to X, indicating that the
transaction does not qualify for CPS/ATM. If a transaction fails to qualify for CPS/ATM,
VisaNet applies non-CPS cash disbursement fees.
27.6.2.3 Delivering the Transaction to the Issuer

If the issuer participates in CPS/ATM, a TCR 5 record is included as part of the draft data.
This record includes the TID.
27.6.3 Exception Transaction Processing

All transactions contain a TID in the TCR 5. V.I.P. assigns a TID to all transactions at the
time of authorization. BASE II assigns a TID to all transactions.
Issuer processing centers can choose to receive the TCR 5 in incoming original ATM
cash disbursement transactions. An issuer receiving the TID is able to better manage
cardholders' open-to-buy balances by matching authorization and clearing records. VisaNet

delivers the TCR 5 to those issuer processors that choose to receive it. If the issuer
receives the TID in the TCR 5, it must retain it and return it in subsequent chargebacks.
Acquirers may also choose to receive the TCR 5 in incoming chargebacks.
Members must contact their regional representatives to request the option to receive the
TCR 5. This option is available both at the BIN level and at the processor level.
Chargebacks for international ATM cash disbursement transactions may be submitted with
Chargeback Reason Code 62 62—Counterfeit Transaction.
27.6.3.1 Key Data Requirements

Table 27-3 identifies key CPS fields and explains how the BASE I fields are carried forward
by the acquirer to populate the related fields in the BASE II records. It also shows which
key CPS/ATM fields are used to develop the validation code.
Table 27-3 CPS/ATM Key Data Requirements
BASE I Authorization Message Fields BASE II Transaction Fields Used to

Determine
Validation
BASE I Field Field Name BASE II Field Field Name Code

2 Primary Account Number TCR 0, Account Number ✓
positions 5–20
3 Processing Code (Transaction TCR 0, Transaction Code
Type, positions 1–2) positions 1–2
NOTE:
A value of 01 (with a value of 6011
in Field 18—Merchant Type)
indicates that an ATM transaction
code is to be used in the BASE II
field.
3 Processing Code (Account Type TCR 1, ATM Account Selection ✓

“from,” positions 3–4) position 130
NOTE:
The first digit of the BASE I value
must be used in the BASE II field.
4 Amount, Transaction TCR 5, Authorized Amount ✓

positions 20–31
NOTE:
In the case of a misdispense,
field 61.1 contains the amount of
the actual cash dispensed, and
field 4 contains the amount of the
original authorization. Field 4,
the authorized amount, must be
provided in the BASE II TCR 5
record.
18 Merchant Type TCR 0, Merchant Category Code

positions 133–136

Table 27-3 CPS/ATM Key Data Requirements (continued)

BASE I Authorization Message Fields BASE II Transaction Fields Used to
Determine
Validation
BASE I Field Field Name BASE II Field Field Name Code
22 POS Entry Mode Code TCR 0, POS Entry Mode ✓
(position 1–2) positions 162–163
32 Acquiring Institution Identification TCR 0, Acquirer BIN (in the Acquirer ✓
Code positions 28–33 Reference Number)
35/45 Track 2 Data/Track 1 Data n/a n/a
NOTE:
Track 2 is required or V.I.P. rejects
the message.
38 Authorization Identification TCR 0, Authorization Code

Response positions 152–157
39 Response Code TCR 5, Authorization Response
positions 35–36 Code
41 Card Acceptor Terminal TCR 1, Terminal ID
Identification positions 96–103

42 Card Acceptor Identification Code TCR 1, Card Acceptor ID
positions 81–95
(Contains ATM owner's name)
43 Card Acceptor Name/Location: TCR 0, Merchant Name
ATM Location (positions 1–25) positions 92–116 ✓
Merchant City
City Name (positions 26–38) TCR 0,
positions 117–129 Merchant Country Code
Country Code (positions 39–40)
TCR 0,
positions 130–132
49 Currency Code, Transaction TCR 5, Authorization Currency Code ✓
positions 22–34
54 Additional Amounts n/a n/a
59 National POS Geographic Data TCR 0, Merchant State/Province
(positions 1–2) positions 142–144 Code
(U.S. region only) (U.S. region only)

62.1 Authorization Characteristics TCR 0, Authorization Characteristics
Indicator (ACI) position 151 Indicator (ACI)
62.2 Transaction Identifier TCR 5, Transaction Identifier
positions 5–19
62.3 Validation Code TCR 5, Validation Code
positions 37–40
— Not applicable TCR 0, Reimbursement Attribute
positions 168

27.6.4 V.I.P. Field Edit and DRC Requirements for CPS/ATM Authorization Requests
Table 27-4 lists the key field edit requirements and related downgrade reason code (DRC)
conditions for a CPS/ATM dual-message authorization request. Multicurrency fields are
not included in the table.
The “DRC or Action If Requirement Not Met” column contains the action the V.I.P. System
takes if the requirements are not met; actions can include downgrading the message
or rejecting it outright. For more information about CPS downgrade reason codes, see
V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2.
Table 27-4 CPS/ATM Field Edit Requirements and DRC Conditions
DRC or Action
If Requirement
Key Field Not Met
General Requirements
Acquirers must be successfully tested CPS/ATM participants. NT
Non-U.S. acquirers must participate in the Multicurrency Service. MC
00).
The authorization or financial request must be approved (field 39 response code = 00 NA

The request must be for a Visa card or a Plus card. NV
Field-Specific Requirements
Field 2—Primary Account Number: Primary account number must be present. 02
Primary account number in field 2 must match the account number in field 35 or field 45 TA
when magnetic stripe or chip data is included.
Field 3—Processing Code: Positions 1–2 must be 01 for cash disbursement. IM
NOTE:
If the transaction is an account selection transaction, the “from” account type is in positions 3-4.
Field 4—Amount, Transaction: The amount is either in U.S. dollars or in the currency specified by the No DRC
currency code in Field 49—Currency Code, Transaction. If the transaction is a misdispense, field 4
contains the original amount, and field 61.1 contains the amount of the cash actually dispensed.
Field 14—Date, Expiration: The expiration date in field 14 must match the date in field 35 or in TD
90, and the ACI from
field 45 if: magnetic stripe or chip data is included, field 22 contains 05 or 90
the acquirer is Y.
BASE I and SMS—If magnetic stripe or chip data was read, and field 22 contains 05 or 90 and ED
the ACI from the acquirer is Y, the track data must contain the expiration date.
Field 18—Merchant Type: Field 18 must be present and the merchant category code (MCC) No DRC
6011.
must be 6011
Field 19—Acquiring Institution Country Code: If the country code is non-U.S., the acquirer must be MC
a Multicurrency Service participant.
Field 22—Point-of-Service Entry Mode Code: The code must be 05 (chip) or 90 (magnetic stripe) for 22
possible CVV or iCVV in complete, unaltered field 35 track data.
NOTE:
Plus transactions do not require CVV checking—any valid field 22 code is acceptable.

Table 27-4 CPS/ATM Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
90, track data is included, and the request is an original submission
If the code is 05 or 90 CV; CX if acquirer
CV
(ACI = Y), the acquirer must be a full CVV Service participant. is on temporary
exception list
Field 32—Acquiring Institution Identification Code: Required and must contain the 6–11-digit Visa No DRC; reject if
or Plus acquirer BIN. missing or if invalid
Field 35—Track 2 Data: The account numbers in the track data and in field 2 must match. TA
Track data must contain the expiration date if: magnetic stripe or chip data was read, field 22 ED
90, and the ACI from the acquirer is Y.
contains 05 or 90
Expiration date in field 14 must match the date in field 35 or in field 45 if: magnetic stripe or TD
90, and the ACI from the acquirer is Y.
chip data was read, field 22 contains 05 or 90
Field 41—Card Acceptor Terminal ID: Must be present with a code that indicates a specific ATM No DRC; reject if
within the acquirer's network. The value cannot be all zeros. missing
Field 42—Card Acceptor ID Code: The field must be present with the ATM owner's name. 42
Field 43—Card Acceptor Name/Location: The ATM location, the card acceptor name, and the city IC
and country code must be present. The country code must be valid.
The state code must be valid. IS
Field 49—Currency Code, Transaction: Required. In CPS-qualified responses, field 49 is protected No DRC
by the validation code in field 62.3.
Field 59—National POS Geographic Data: BASE I and SMS—The merchant's ZIP or postal code 59
must be present.
Field 59—National POS Geographic Data: For U.S.-domestic, the state code must be valid. IS
For Canada-domestic, a valid province code is required.
Field 61—Other Amounts: If present in ATM confirmations for misdispenses, this field contains the No DRC; reject
actual amount dispensed. if invalid
Field 62.1—Authorization Characteristics Indicator: BASE I and SMS—If qualified, V.I.P. assigns the Acquirer receives N
ACI for the response. For CPS/ATM—Y Y in request, E in response. if transaction is
declined
Field 62.2—Transaction Identifier: The TID in the initial approved authorization or financial request TI
must appear in all subsequent messages.
Field 62.3—Validation Code: BASE I—This field is generated by V.I.P. and is present in qualified Validation code
transaction responses. If the request is downgraded, the DRC is present instead of the validation or DRC
code.

This section lists and describes key fields associated with CPS/ATM.

Field 62.1—Authorization Characteristics Indicator (ACI)

The acquirer uses this field to indicate that a CPS/ATM transaction is being submitted.
If the code in this field is other than one of those allowed, V.I.P. drops field 62 and
processes the request as a non-CPS transaction.
V.I.P. changes the value to reflect the results of its CPS evaluation. For CPS/ATM, a
request with a value of Y will have an E in the response on an approved and qualified
transaction. Acquirers whose requests do not qualify receive an N (not qualified) in
this field in the response.
Field 62.2—Transaction Identifier

The TID is a unique system-generated identifier assigned to each transaction (CPS and
non-CPS alike) that links original authorizations to subsequent messages such as
reversals. Transaction identifiers are based on the date and time.
Field 62.3—Validation Code

The system-generated validation code is added only to 0110 authorization responses
and ensures that the values in the authorization request's key CPS fields match their
respective fields in the BASE II deferred clearing message.
If an authorization request fails CPS qualification but is nevertheless approved by the

issuer, V.I.P. uses field 62.3 to insert the CPS downgrade reason code instead of
the validation code in the response to the acquirer. When an N is present in Field
62.1—Authorization Characteristics Indicator (ACI) (indicating that the authorization
did not qualify for CPS), the code in field 62.3 indicates the reason. The downgrade
reason code is not passed to BASE II in the deferred clearing message; the acquirer
enters spaces instead.

For further information about CPS/ATM, refer to the following documents:
• Visa/Plus Global ATM Planning Guide
27.8.1 Other Related Processing

Several services are closely related to CPS/ATM because they also ensure quality in
the processing of ATM transactions. For more information, see the following chapters
in this manual:
• Card Verification Value (CVV) Service
• Multicurrency Service


Chapter 28 Custom Payment Service (CPS)/POS
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
IN BRIEF 28-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
BASE I and SMS CPS Processing Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-4
CPS/POS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-5
Qualifying for CPS/POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-5
CPS/POS Programs—All National Markets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-5
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
HOW CUSTOM PAYMENT SERVICE (CPS)/POS WORKS 28-66
Reclassification From CPS/POS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
CPS/POS Program Clearing Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
Qualification Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
Fee Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
Ineligible CPS/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Amount Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Adjusting Amounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Chargeback Reduction Service (CRS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Custom Payment Service (CPS)/POS

CPS Authorization-Related Chargeback Protection. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .28-8
Chargeback Reduction Service Life-Cycle Control. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .28-9
FLOW.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
CPS/POS PROCESS FLOW 28-99
MARKETS.. . . . . . . . . . .28-
COMMON CPS/POS DATA REQUIREMENTS: ALL NATIONAL MARKETS 28-99
Common CPS/POS Authorization Field Edit Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
Common CPS/POS Clearing Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-12
BRAZIL.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
NATIONAL MARKET CPS/POS PROGRAM: BRAZIL 28-13
13
Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-14
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
15
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-
17


Chapter 28 Custom Payment Service (CPS)/POS
28.1 IN BRIEF
Custom Payment Service (CPS)/POS is a series of payment services that are customized
to serve the needs of distinct merchant segments for point-of-sale (POS) transactions.
CPS/POS accommodates different merchant procedures and decreases fraud losses
and operating expenses associated with each transaction. CPS/POS increases Visa
member profitability by reducing member operating costs, by improving risk management
techniques, and by increasing member revenues through increased card usage.
CPS POS transactions can be processed as dual messages through BASE I and BASE II.
NOTE
This service description only describes CPS/POS for international participants. Visa U.S.A. (U.S.) participants
should see the U.S. Interchange Reimbursement Fee (IRF) Rate Qualification Guide.
CPS/POS is available to members in all Visa regions.
BASE I

CPS/POS is available both to BASE I System users and to Single Message
SMS System (SMS) users.
BASE I and SMS
I Participation in CPS/POS is optional for BASE I System issuers and to Single

Issuer
A
Participation in CPS/POS is optional for BASE I System acquirers.
Acquirer

Custom Payment Service (CPS) is a set of special transaction processing requirements
that helps members reduce fraud and exception item processing costs by providing
features such as improved transaction integrity and life-cycle control. Built on the Payment

Services 2000 foundation introduced in 1993, CPS supports domestic POS transactions
and international ATM transactions with custom rate incentive programs for different
markets.
28.3.1 BASE I and SMS CPS Processing Overview

This section summarizes CPS processing as it applies to all CPS programs.
For acquirers, CPS protects against authorization-related chargebacks by requiring the

authorization request to contain certain key information that might not otherwise be present
to provide a more complete picture of the transaction conditions and to help validate
cardholder authenticity.
For issuers, CPS increases risk control and improves account balance management.
Issuers can accurately match a transaction's clearing and authorization messages using
a unique transaction identifier (TID) that is assigned by the Visa Integrated Payment
(V.I.P.) System.
Non-U.S. acquirers can submit both dual-message and single-message formats for CPS
consideration by acquirers connected either to BASE I or to SMS.
Transactions ineligible for CPS are described in the operating regulations and include
certain “high-risk” merchants. Refer to Visa International Operating Regulations for more
information about high-risk merchants.
CPS processing rules are applied by editing authorization and full financial requests for
specific field values. If, during the authorization phase, a request cannot qualify because
it fails an edit or a combination of edits, and if the failure of an edit does not cause
the message to be returned to the sender as a reject, the request is assigned a CPS
downgrade reason code (DRC) that indicates which requirement was not met. Downgraded
requests can still be approved; non-CPS processing continues, assuming that there are no
conditions to cause an outright message reject. Refer to V.I.P. System BASE I Technical
Specifications, Volume 1 and Volume 2, for the CPS downgrade reason codes.
BASE I only attempts to assign an authorization characteristics indicator (ACI) or a

downgrade reason code (DRC) during the processing of an 0100 authorization request.
Not all CPS key fields required in a request to qualify for a given CPS program are checked
during the authorization phase, only those necessary to determine initial CPS qualification.
Incentive fee assignments for dual-message transactions are made during BASE II clearing
when BASE II examines the BASE II clearing record's “CPS key field content” from the
authorization request along with BASE II-specific data. To qualify for a particular CPS
incentive program, dual-message transactions may require an acquirer to provide more
information in a BASE II clearing message than was necessary to qualify the respective
authorization request.
For single-message transactions, SMS assigns the ACI or the DRC and if the request
qualifies, clears the transaction according to CPS parameters. Acquirers include the
requested incentive fee in Field 63.11—Reimbursement Attribute of the 0200 financial
request. In the case of a BASE I POS acquirer and an SMS issuer, the acquirer conveys the
incentive fee information to the issuer in BASE II-generated 0220 deferred clearing advices.

28.3.2 CPS/POS
This service description describes the CPS/POS incentive program processing
requirements for card-present (CP) and card-not-present (CNP) transactions. This service
description applies only to international participants. Brazil national market is also covered
by this service.
NOTE
This service description does not specify actual CPS/POS rates. Refer to the appropriate regional operating
regulations contained in Visa International Operating Regulations to determine current CPS/POS rates.
Also refer to the documents listed in “For More Information” in this chapter.
28.3.3 Qualifying for CPS/POS

The following criteria must be met for a transaction to qualify for CPS/POS:
• A transaction must qualify for a CPS/POS program in its national market to receive
authorization-related chargeback protection.
• A transaction must then meet additional requirements to qualify for an applicable CPS
rate. Subsequent sections of this chapter describe program qualification requirements.
• All CPS/POS clearing transactions must contain the TID, the ACI, and the validation code
from the authorization response.
• For transactions with multiple authorizations, with an authorization reversal, or with
both, these data elements must be identical to those contained in the first authorization
response.
• The clearing transaction must include the acquirer's request for a specific CPS/POS
program in the RPS field. A valid RPS value indicates that the transaction complies with
the set of authorization and clearing qualification rules for the CPS program requested.
To qualify a transaction for any CPS/POS program, a validation code check ensures that
certain authorization and clearing data elements are identical. A successful validation
confirms that VisaNet has properly authorized the transaction. For more information about
the fields VisaNet uses to calculate the validation code, see “Common CPS/POS Data

Requirements: All National Markets” in this chapter.
BASE I-acquired POS transactions that contain PINs do not qualify for CPS. If BASE I
acquirers request CPS qualification for such transactions, V.I.P. returns an ACI value of T.
VisaNet stores qualified CPS transactions in a history database and systematically protects
them from invalid authorization-related chargebacks using the Chargeback Reduction
Service (CRS). For more information about CRS, see “Chargeback Reduction Service
(CRS)” in this chapter.
28.3.4 CPS/POS Programs—All National Markets

Table 28-1 identifies the CPS/POS programs for the national market of Brazil. Brazil
national market processes CPS/POS transactions as dual-message transactions.
Table 28-1 CPS/POS Programs
Card
Card Not
CPS/POS Program Description Present Present
Brazil

Table 28-1 CPS/POS Programs (continued)

Card
Card Not
CPS/POS Program Description Present Present
CPS/Retail For retail transactions including those initiated at ✓
restaurants at which the magnetic stripe is read.

CPS acquirers and issuers must successfully complete testing to send and to receive
CPS-specific fields. U.S.-domestic acquirers and issuers must participate in CPS. Non-U.S.
region participation is optional.
28.4.1 Testing
CPS/POS testing requirements are generally the same for the different national markets.
Members can contact their Visa representatives to make arrangements for testing.
28.5 HOW CUSTOM PAYMENT SERVICE (CPS)/POS WORKS

All dual-message CPS transactions must be authorized through the V.I.P. System and
be cleared through the BASE II System.
28.5.1 Reclassification From CPS/POS

VisaNet reclassifies transactions that fail to meet CPS/POS program edit requirements
as non-CPS transactions.
Acquirers may choose to have VisaNet return these transactions. If acquirers do not
request this option, VisaNet reclassifies these transactions and delivers them to the issuer.
BASE II changes the ACI to X, which indicates that the transaction does not qualify as a
CPS transaction. VisaNet sends an advice to the acquirer as notification that it reclassified
the transaction.
Reclassified transactions do not receive authorization-related chargeback protection and

are not eligible for the requested CPS rate, but do continue to receive life-cycle control.
For more information, see “Chargeback Reduction Service (CRS)” in this chapter.
Transactions that VisaNet reclassifies as non-CPS receive the next best rate that VisaNet
can apply, for instance, the Electronic Interchange Reimbursement Fee (EIRF) Rate
or Standard Rate. VisaNet updates the reimbursement attribute (RA) to reflect the
appropriate rate applied. VisaNet changes the value in the requested payment service
space.
(RPS) field to a space
Some national market participants participate in the National Net Settlement Service
(NNSS). In those cases, the NNSS rate structure applies. Refer to the appropriate regional
operating regulations contained in Visa International Operating Regulations for more
information.

Chapter 28 How Custom Payment Service (CPS)/POS Works
28.5.2 CPS/POS Program Clearing Times

For dual-message transactions, each CPS/POS program has defined clearing times
between the transaction date and the BASE II central processing date (CPD). Table 28-2
lists the clearing times for specific CPS programs.
Table 28-2 CPS/POS Clearing Times
National Market Clearing

Times
Custom Payment Service Brazil
CPS/Retail Credit Card 2 days (Retail, Petrol,
Restaurant)
CPS/Card Not Present1 n/a
1. The clearing timeframe is measured from the date of goods shipment, checkout, or return date, as opposed to the
authorization date.
When calculating clearing times, VisaNet does not include the transaction date, the BASE II
CPD, Sundays, and specific holidays. Holidays depend on the national market.
28.5.2.1 Qualification Schedules

Refer to Visa International Operating Regulations for processing timeframes between
transaction dates and clearing central processing dates. Also refer to the appropriate
operating regulations for holidays and for other days that regions may exclude from the
clearing time calculations.
28.5.3 Fee Changes

Transactions that meet the requirements for the requested CPS/POS program (but fail to
qualify for the CPS/POS rate) receive a fee change for the following reasons:
• The transaction fails to meet the clearing timeliness requirement for the CPS/POS rate

associated with the program.
• The transaction fails to meet industry-specific clearing data requirements.
Transactions that meet the requirements for the requested CPS/POS program (but fail to
qualify for the CPS/POS rate) still receive authorization-related chargeback protection.
VisaNet changes the RA to reflect the appropriate rate applied. VisaNet does not change
the RPS value and the ACI when a transaction qualifies for a particular CPS/POS program
but does not qualify for a CPS/POS rate.
All transactions that qualify for the CPS/POS program requested but fail either the clearing
timeliness or the industry-specific data requirements for the interchange reimbursement
fee (IRF) associated with the requested CPS program receive a fee change to the next
best rate that VisaNet can apply—EIRF or standard. VisaNet changes the RA to reflect
the rate at which the transaction was settled. VisaNet does not change the value in the
requested payment service field.
For specific national-market CPS information about fee changing circumstances and
procedures, members can contact their Visa representatives.

Chapter 28 How Custom Payment Service (CPS)/POS Works
28.5.4 Ineligible CPS/POS Transactions

Ineligible Brazil national-market CPS/POS transactions are those not specifically identified
as CPS/Retail purchases including those for petrol and restaurant purchases. Ineligible
transactions include cash disbursements and quasi-cash transactions.
NOTE
U.S. domestic quasi-cash transactions from consumer debit, consumer prepaid, business debit, and
commercial prepaid cards can qualify for CPS.
28.5.5 Amount Tolerance

Authorizations initiated by certain merchants, such as hotels and car rental companies,
contain amounts that may vary significantly from the final transaction amounts. VisaNet
reclassifies or returns transactions that fail to meet the amount tolerance edits. Table 28-3
identifies the amount tolerances for Brazil.
Table 28-3 Amount Tolerances—Brazil
CPS/POS Program Amount Tolerance

Brazil
CPS/Retail, including Petrol The clearing amount must equal the authorization amount.
CPS/Retail, Restaurant The clearing amount must be equal to or no greater than 20%
of the authorization amount.
Whether members can use amount adjustments depends on the applicable regional
operating regulations outlined in Visa International Operating Regulations.
28.5.5.1 Adjusting Amounts

Visa does not allow the adjustment of amounts with full or partial reversals or with
incremental authorizations. VisaNet applies a fee change when transactions do not meet
amount tolerances. These fee-adjusted transactions still retain authorization-related

chargeback protections.
28.5.6 Chargeback Reduction Service (CRS)

A chargeback is a transaction that an issuer returns to an acquirer. An acquirer can
accept financial liability for the transaction or can re-present the transaction to the issue.
The Chargeback Reduction Service (CRS) can reduce member costs associated with
dispute processing.
28.5.6.1 CPS Authorization-Related Chargeback Protection

VisaNet stores qualified CPS transactions in a history database and systematically protects
them from invalid authorization-related chargebacks through the Chargeback Reduction
Service (CRS). These chargebacks fall into eight categories based on their authorization
characteristics and the merchant category of the original purchase transactions (Travel and
Entertainment [T&E] or non-T&E). CRS determines which category of protection a CPS
transaction receives by using the ACI, the RPS, and the merchant category code (MCC).
For more information about CRS, refer to the documents listed in “For More Information”
in this chapter. For more information about MCCs, refer to the Visa International VisaNet
Merchant Data Standards Handbook.

Chapter 28 CPS/POS Process Flow
BASE II forwards a chargeback rights indicator to the issuer in the original purchase
transaction that identifies which set of authorization-related chargeback protection rights
applies to the transaction.
28.5.6.2 Chargeback Reduction Service Life-Cycle Control

BASE II provides CRS life-cycle control for Brazil-domestic purchase transactions. BASE II
suspends all non-CPS exception transactions for one settlement cycle. During this
suspension, BASE II checks the exception transaction against the history of the transaction
to ensure that processing rules for the sequence of the transaction are followed, and to
determine whether the exception transaction complies with Visa's operating regulations
for the different regions.
28.6 CPS/POS PROCESS FLOW

The CPS/POS process flow consists of the following steps.
1. The acquirer submits an authorization request with an authorization characteristics
indicator (ACI) to indicate that this is a CPS transaction.
2. The V.I.P. System ensures that the transaction meets the CPS/POS criteria and
evaluates the characteristics of the request, then replaces the value of the ACI to reflect
the authorization characteristics of the transaction.
- V.I.P. generates a unique transaction identifier (TID) and passes it to the issuer if the
issuer has successfully completed testing and has chosen to receive it. VisaNet
can also pass the ACI.
3. The issuer approves the transaction, sends the transaction back to the V.I.P. System
with the authorization response code, and optionally returns the ACI and the TID.
4. The V.I.P. System generates a validation code based on key authorization fields.
VisaNet forwards the validation code with the ACI, the TID, and the authorization
response code to the acquirer.
5. The acquirer submits a clearing message to BASE II with a value in the Requested
Payment Service (RPS) field, which specifies the CPS program desired. The clearing

transaction also contains the ACI, the TID, and the validation code received from V.I.P.
with the authorization response.
6. BASE II validates that the key authorization fields in the clearing transaction match
those used in the authorization message by recalculating the validation code. BASE II
applies edits to ensure that the transaction qualifies for the requested CPS program.
BASE II sets a chargeback rights indicator to identify the set of chargeback rights for
which the transaction is ineligible.
VisaNet then forwards the transaction to the issuer with the ACI, the TID, the validation
code, the requested payment service, and the chargeback rights indicator.
The issuer uses the TID to match the clearing transaction to the authorization.
28.7 COMMON CPS/POS DATA REQUIREMENTS: ALL NATIONAL MARKETS

This section summarizes the authorization and clearing data requirements common to
all CPS/POS transactions. The following sections that describe particular programs list
additional requirements specific to each CPS/POS program.
28.7.1 Common CPS/POS Authorization Field Edit Requirements

Table 28-4 contains the POS key field edit requirements and the downgrade reason code
(DRC) conditions for authorization requests and for their responses. The “DRC or Action

Chapter 28 Common CPS/POS Data Requirements: All National Markets
If Requirement Not Met” column contains the action V.I.P. takes if the transaction does
not meet the requirements; actions can include downgrading the message or rejecting it
outright. For more information about CPS downgrade reason codes, see V.I.P. System
BASE I Technical Specifications, Volume 1 and Volume 2.
Table 28-4 CPS/POS Field Edit Requirements and DRC Conditions
DRC or Action
If Requirement
Key Field Not Met
General Requirements
The acquirers must be a successfully tested CPS participant. NP
The member must participate in CPS/ATM. NT
The request must be for a Visa card. NV
The acquirer and the issuer must participate in the Multicurrency Service. MC
00).
The request must be approved (the response code in field 39 must be 00 NA
The CVV2 authorization request data must be 1, 2, or 9. PI
The CVV2 result code must be U, M, or P. I2
The e-commerce transaction must qualify. NE
The e-commerce transaction must be secure. NS
The purchase identifier must be valid. IP
Field-Specific Requirements
Field 2—Primary Account Number: The primary account number must be 02
present.
The primary account number must match the account number in field 35 or TA
in field 45 when the message includes magnetic stripe or chip data.
Field 14—Date, Expiration: The expiration date in field 14 must match the date TD
in field 35 or in field 45 if the message includes magnetic stripe or chip data,
field 22 must contain 05 or 90 90, and the ACI from the acquirer must be Y.
If the terminal read magnetic stripe or chip data, the track data must contain ED
90, and the ACI from the
the expiration date, field 22 must contain 05 or 90
acquirer must be Y.
Field 18—Merchant Type: The merchant category code (MCC) must be 18
present and be one of the valid codes listed in the system tables.
The MCC must be valid for the target CPS program. IM
5542, 5960
If field 25 contains 71 (key entry), the MCC cannot be 5542 5960, 5962
5962, CK
5964–5969
5964 5969,
5969 or quasi-cash.
Field 19—Acquiring Institution Country Code: This field must be present and IC; reject if
IC
must contain a valid acquirer country code. missing
The code in field 19 or in field 43 must be a valid U.S.-region code if the MC
acquirer does not participate in the Multicurrency Service.
Field 22—Point-of-Service Entry Mode Code: The code must be 02 02, 05
05, 90
90, 22
95. The CPS/Retail credit value must be 05 or 90
or 95 90. Key-entry requests
01.
must contain 01

Table 28-4 CPS/POS Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
90, track data must be present in field 35 or in
If field 22 contains 05 or 90 22
45.
field 45
90, the message includes track data from
If the code in field 22 is 05 or 90 CV; CX if the
CV
the magnetic stripe or from the chip, and the request is an original CPS acquirer is on
request (the ACI is Y), the acquirer must be a full participant in the Card the temporary
Verification Value (CVV) Service. exception list
Cash must qualify for CPS/Retail. CN
For U.S. mail order or telephone order (MOTO) transactions (field 25 CD
08), field 22.1 must contain 01 (manual key entry), and track data
contains 08
must not be present in the message.
Field 35—Track 2 Data or Field 45—Track 1 Data: If the terminal read AN
magnetic stripe or chip data, the full, unaltered Track 1 or Track 2 data must
be present and must contain the account number. Track data is mandatory if
90.
field 22 contains 90
NOTE:
The magnetic stripe or the chip image of the magnetic stripe can contain track data.
If the terminal read magnetic stripe or chip data, the account numbers in the TA
track data and in field 2 must match.
Track data must contain the expiration date if: the terminal read magnetic ED
90, and the ACI from the
stripe or chip data, and field 22 contains 05 or 90
acquirer is Y.
The expiration date in field 14 must match the date in field 35 or in field 45 if TD
the terminal read magnetic stripe or chip data, field 22 contains 05 or 90 90,
and the ACI from the acquirer is Y.

Field 42—Card Acceptor ID Code: Visa requires this field to be present in all 42
0100 and 0200 requests and it must contain an ID or a name.
Field 43—Card Acceptor Name/Location: Visa requires the field and it must EM
include the merchant's name and location. (This process results in an ACI
of Y in the response.)
The code in field 43 or in field 19 must be a valid U.S. code if the acquirer MC
does not participate in the Multicurrency Service.
The state code must be valid. IS
Field 44.5—CVV/iCVV Results Code: BASE I and SMS—If track data is No DRC
present, and if CVV or iCVV checking is performed, field 44.5 must be blank
(not checked) or be 2 (passed) in requests forwarded to issuers or in responses.
Field 49—Currency Code, Transaction: BASE I and SMS—Visa requires this No DRC; reject
field to be present. BASE I—In CPS-qualified responses, the validation code if missing or if
in field 62.3 protects field 49. invalid
Field 59—Merchant ZIP Code must be present and must be valid for the U.S. 59
acquirer.

Table 28-4 CPS/POS Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
Field 62.1—Authorization Characteristics Indicator: This field must contain Y RV
in the request, and contain A or E in the response, depending on the
transaction type. Acquirer
receives N if
VisaNet declines
the transaction
Field 62.2—Transaction Identifier: V.I.P. inserts this field. The TID in the initial TI
approved authorization or financial request must appear in all subsequent
messages, including incremental authorization requests and reversals.
Field 123—Address Verification is requested. AV
28.7.2 Common CPS/POS Clearing Requirements

All CPS/POS transactions must meet the following minimum clearing requirements.
They must have:
• A valid reimbursement attribute (RA) for the requested CPS/POS program.
• Valid combinations of the following for CPS/POS programs:
- The requested payment service (RPS) field and an authorization characteristics
indicator (ACI)
- The requested payment service (RPS) field and the cardholder ID method
- The requested payment service (RPS) field, authorization characteristics indicator
(ACI), POS entry mode code, and reimbursement attribute (RA)
- The requested payment service (RPS), authorization characteristics indicator (ACI),
and transaction code qualifier (TCQ)
Table 28-5 lists the valid data element combinations for the Brazil CPS/POS market.
NOTE
Refer to the appropriate regional operating regulations for more information about valid combinations of data
element values. Also see “For More Information” in this chapter for a list of other national market documents.
Table 28-5 Valid Data Element Value Combinations for CPS/POS National Markets
Requested Payment Service Authorization Characteristics

(RPS) Indicator (ACI)
Reimbursement
Code Definition Code Definition Attribute Cardholder I.D. Method
Brazil
A CPS/Retail, A Card present A 1
including Petrol
E Card present with A 1
merchant name and
location data
B CPS/Retail— A Card present A 1
Restaurant
E Card present with A 1
merchant name and
location data

Chapter 28 National Market CPS/POS Program: Brazil
NOTE
Participants also can use the authorization characteristics indicator M for non-U.S. MOTO and Visa Secure
Electronic Commerce (VSEC) transactions that do not include address verification data.
NOTE
BASE II specifically edits for POS entry mode code 90 if:
- The RPS field contains A, C, D, 1, 4, 6, or 9.
- The ACI is A or E.
- The reimbursement attribute is A or 4.
For approved transactions, V.I.P. computes a validation code using key elements in the
authorization message. Participants must submit the values of the protected data fields'
key elements unchanged from authorization through clearing. If a participant changes any
values from authorization through clearing, V.I.P. reclassifies the transaction to a non-CPS
transaction or returns it. Table 28-6 lists the protected fields.
Table 28-6 Validation Code Protected Fields
V.I.P. System Field BASE II Field (Definition)

2 Account Number
4 Authorized Amount
18 Merchant Category Code
22 (positions 1–2) POS Entry Mode
38 Authorization Code
39 Authorization Response Code
49 Authorization Currency Code

61.1 Other Amount, Transaction, Cashback1
62.1 Authorization Characteristics Indicator
62.2 Transaction Identifier
62.1 Authorization Characteristics Indicator
62.23 Card-Level Results (applicable for validation code calculation only for
U.S. domestic transactions)
1. If the specified subfield is not present, V.I.P. substitutes the default value, which the acquirer must provide in the clearing
transaction sent to BASE II.
The validation code algorithm also uses the following fields for international CPS/ATM
transactions: field 3 (positions 3–4), field 32, and field 43. These fields do not have default
values. See the Custom Payment Service (CPS)/ATM chapter in this volume for more
information.
28.8 NATIONAL MARKET CPS/POS PROGRAM: BRAZIL

The Brazil national market supports the following CPS/POS program:

Chapter 28 National Market CPS/POS Program: Brazil
• Retail, including Petrol and Restaurant
VisaNet processes all CPS/POS transactions for Brazil as dual-message transactions.

To qualify for the CPS/POS program and for its associated rate, a transaction must have
the following characteristics:
• The card must be present, and the cardholder signature obtained.
• The program allows only one authorization per clearing transaction.
• The terminal must read and transmit the complete and unaltered contents of Track 1
or Track 2 of the card's magnetic stripe.
• The POS entry mode code in field 22 must be 90 and must be present in the authorization
request.
• The purchase date (transaction date) must be the authorization date.
• The transaction must clear within two days.
• For Retail transactions including Petrol, the clearing amount must equal the authorized
amount.
• For Restaurant transactions, the clearing amount must be equal to or not more than
20% above the authorized amount.
• The merchant category code must be valid:
5541.
- Petrol must be 5541
5814.
- Restaurant must be 5812 or 5814
28.8.1 Key Data Requirements

In addition to meeting the requirements described in “Common CPS/POS Data
Requirements: All National Markets,” a transaction must also meet the key data
requirements listed in Table 28-7 to qualify for the Brazil national market CPS/Retail
program and for its associated rate.

Table 28-7 CPS/Retail Key Data Requirements for Brazil
Authorization Clearing
Data Element Field Value BASE II Field Value
Merchant Category Code (MCC) 18 4815, 5960
Retail: not 4815 5960, 5962
5962, TCR 0, 4815,
Retail: not 4815
5964–5969
5964 5969, 6010–6011
5969 6010 6011 5960, 5962
positions 133–136 5960 5962,
5964–5969
5964 5969,
5969
Petrol: 5541 6010–6011
6010 6011
Restaurant: 5812 or 5814 Petrol: 5541
Restaurant: 5812
or 5814
POS Entry Mode 22 90 TCR 0, 90
positions 162–163
Track Data 35 or 45 Full Track 1 or Track 2 — —
Authorization Characteristics 62.1 Y in request TCR 0, A or E
Indicator (ACI) A or E in response position 151
Transaction Code Qualifier (TCQ) — — All TCRs, 0
position 3
Requested Payment Service — — TCR 0, A for Retail
(RPS) position 145 including Petrol
B for Restaurant
Authorization Date — — TCR 5, In transaction
positions 5–191 identifier
Purchase Date — — TCR 0, Within one day of
positions 58–61 authorization date
Cardholder ID Method — — TCR 0, 1

position 160
Central Processing Date (CPD) — — TCR 0, Within two days
positions 164–167 of purchase date
Reimbursement Attribute (RA) n/a — TCR 0, A
position 168
1. Embedded in the transaction identifier.

This section describes key fields associated with CPS/POS. The sections indicate
applicability for specific national markets where necessary.

Field 62.1—Authorization Characteristics Indicator (ACI)

This field indicates the result of the V.I.P. System evaluation of the authorization
characteristics of a CPS/POS transaction.
At the point of sale, the merchant terminal or the electronic cash register sends an
authorization request to the V.I.P. System. If the authorization request is for a potential
CPS/POS transaction, it must include a valid authorization characteristics indicator
(ACI).
After V.I.P. receives the message, it examines and validates the contents of the
authorization request. V.I.P. assigns an appropriate ACI value. V.I.P. downgrades
transactions that do not meet authorization-related edits and do not qualify for CPS/POS
and for the associated rate. When V.I.P. downgrades a transaction, it sets the ACI
value to N.
For technical details, refer to Table 28-8, which correlates the ACI supplied by the
acquirer with the value returned by the V.I.P. System.
Table 28-8 Authorization Characteristics Indicator (ACI) Values
Returned National
Submitted Value Authorization Criteria Definition Value Markets
Y 1. The full contents either of Card present, A All
Track 1 or of Track 2 of or cardholder or
the magnetic stripe are card present,
transmitted to allow card or select
authentication through developing
Card Verification Value market MCC
(CVV) processing.
2. The cardholder
is present and
the transaction is
key-entered.
3. The transaction is from a
select developing market
MCC.
Y 1. The full contents either of Card present E All
Track 1 or of Track 2 of with merchant
the magnetic stripe are name and
transmitted to allow card location data
authentication through or select
CVV processing. developing
2. The transaction is from market MCC
a select developing with merchant
market merchant. name and
The authorization location data
request contains
additional merchant
name and location data.

Table 28-8 Authorization Characteristics Indicator (ACI) Values (continued)

Returned National
Submitted Value Authorization Criteria Definition Value Markets
Any Other 1. The authorization Not a CPS N All
request does not qualify transaction
as a CPS transaction.
2. The acquirer or the
merchant is not
participating in CPS.

Field 62.2 contains a code that uniquely identifies a transaction as a CPS transaction.
The V.I.P. System assigns a unique transaction identifier (TID) to all authorization
requests. The TID stays with the transaction through its life cycle, providing a reference
number that ties together all aspects of the transaction from authorization through
clearing.
Field 62.3—Validation Code

This field contains a unique value that V.I.P. includes as part of the authorization
response for CPS transactions to ensure that further processing preserves key
authorization fields in the clearing record.
For approved transactions, V.I.P. computes a validation code by using key elements
in the authorization message. Refer to “Common CPS/POS Data Requirements:
All National Markets” in this chapter for the fields V.I.P. uses to calculate the validation
code. The BASE II System uses this code to ensure that the clearing message includes
required elements from the authorization message. The V.I.P. System sends the
authorization response to the acquirer, including the TID, the updated ACI, the updated
market-specific authorization data indicator, and the validation code.

Declined or referred transactions cannot qualify for a CPS program and V.I.P.
downgrades them.

For additional information about CPS/POS, refer to the following documents:
• V.I.P System BASE I Technical Specifications, Volume 1 and Volume 2
• PaymentService 2000 Technical Specifications—Brazil (DS-941075)
• U.S. Interchange Reimbursement Fee (IRF) Rate Qualification Guide


Chapter 29 Deferred Clearing Advice File (DCAF) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
IN BRIEF 29-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
DCAF Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
File Delivery Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
File Content and Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-5
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-5
Deferred Clearing Advice File (DCAF) Service

Issuer Host Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-7
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
WORKS.. . . . . . . . . . . . .29-
HOW DEFERRED CLEARING ADVICE FILE (DCAF) SERVICE WORKS 29-88
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
PROCESS FLOWS 29-88
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
MESSAGE FLOWS 29-99
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
10
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-
10


Chapter 29 Deferred Clearing Advice File (DCAF) Service
29.1 IN BRIEF
The Deferred Clearing Advice File (DCAF) Service enables Single Message System (SMS)
issuers to receive deferred clearing advices, in bulk files, in addition to receiving advices
individually online.
Deferred advices are those that are not created and sent immediately in response to the
single message request, but are deferred, that is, created later, and sent to the issuer after
they are generated. Deferred clearing advices originate from dual-message, BASE II
acquirers that do not generate online clearing messages.
The DCAF Service can help issuers manage large volumes of advices without negatively
affecting system capacity and resource allocation.

The DCAF Service is available to members in all Visa regions.
BASE I
SMS The DCAF Service is available to SMS issuers.
SMS only
I
Participation in the DCAF Service is optional for SMS issuers in all Visa regions.
Issuer

The DCAF Service delivers deferred clearing advices in bulk files, using separate lines from
those delivering online interchange traffic.
This process is different from standard online advice recovery, in which V.I.P. sends
advices one at a time to each issuer station signed on to Advice Recovery mode and
requires an acknowledgment (advice response) for each advice. An issuer could have
many online connections receiving advices. The transmission of tens of thousands of
advices and responses requires significant online communications capacity and hardware.
With the DCAF Service, online capacity is augmented by a file transfer process by which
many deferred clearing advices are collected into a bulk file or bulk files. V.I.P. delivers the

bulk files to participating issuers using network transmission lines that are separate from
the issuer's online station lines.
29.3.1 DCAF Service Options

When implementing and using the DCAF Service, issuers can:
• Choose one of two file transfer methods:
1. VisaNet Access Point (VAP)
2. Direct connectivity method
See “File Delivery Methods” in this chapter for information about both options.
• Specify bulk file delivery at the BIN level. V.I.P. can create separate bulk files for each
processor ID. Processors with more than one processor ID can also choose to combine
them in one file.
• Receive files as many as four times during a processing cycle. V.I.P. delivers the queued
DCAF advice records to each issuer on a time-initiated basis. Delivery times are initially
set to 11:00 p.m. Pacific time, 12:30 a.m. (the next day), 2:00 a.m., and 3:15 a.m. Issuers
can change delivery times and can request fewer delivery times.
NOTE
All times are approximate.
• Receive advices that provide the same information contained in online clearing advices.
• Retrieve and research advices using either:
- VisaNet Transaction Research Service (VTRS)
- Visa Exceptions
• Select the format in which advices are delivered:
- International Organization for Standardization (ISO) format
- Fixed format
See “File Content and Record Format” in this chapter for information about both formats.
29.3.2 File Delivery Methods

V.I.P. delivers the bulk files either:
• Through the issuer's VAP.
• Directly to the issuer's host computer through a direct connectivity method. This method
is called host-to-host delivery.
VAPs are available for issuers in all Visa regions. Issuers can use the same VAP for
multiple Visa applications, such as for online processing and for DCAF file receipt. Visa
staff can help issuers determine appropriate processing combinations, depending on
member volumes, timing requirements, and other processing considerations.
Visa has direct VisaNet connections for all members. These connectivity options enable
members to connect directly to VisaNet. See About This Manual for documentation about
VisaNet connections.
IMPORTANT
Regardless of the method of delivery, V.I.P. delivers the bulk files through file transfer connectivity that is
independent from the issuer's online connectivity to VisaNet.

Issuers receive DCAF files at their VisaNet connection or VAP at one or more of the
delivery windows. Delivery is not controlled by any issuer options. If there are advices to
send, V.I.P. sends them. Otherwise, V.I.P. sends nothing. Issuers can start processing
advices when a file delivered from V.I.P. reaches the issuer's host computer.
DCAF files delivered to the VisaNet connection or VAP can be restaged to an issuer's host
system at the issuer's option, without requiring retransmission from V.I.P.
NOTE
Host-to-host transmissions must be restarted if an issuer system failure requires retransmission.
Refer to “For More Information” in About This Manual for documentation that provides
information about connecting to VisaNet and about VAPs.
29.3.3 File Content and Record Format

The DCAF Service provides advice records in one of two formats:
• ISO bulk file format, in which each Visa online bit-mapped advice is captured as is and
written to a file of variable-length records.

• Fixed format, in which each Visa online bit-mapped advice is translated into a set of
fixed-length records with static field definitions.
See the Deferred Clearing Advice File (DCAF) Service Technical Specifications Manual
for details about the two formats. Members can contact their Visa representatives to get
this document.
Complete details about advice record formats are located in the various V.I.P. System
technical specifications manuals. Refer to “For More Information” in About This Manual
for a list of these V.I.P. System manuals.

Participation in the DCAF Service is optional for SMS issuers in all Visa regions. To
participate, issuers must be connected to SMS and must clear their transactions through
SMS.
To activate DCAF processing, Visa staff must make changes to V.I.P. system table entries.
Each affiliate BIN that will use DCAF requires the change. The issuer must inform Visa of
all such change requests.
Visa representatives handle the Visa internal table changes based on information supplied
by the issuer's technical staff.
Members can contact their Visa representatives to make all service activation arrangements
and changes to their existing service specifications.
29.4.1 Testing
DCAF Service participants. VCMS staff help the issuer prepare for testing and develop test
cases. Members can contact their Visa representatives to make the arrangements.
A batch file communications connection must exist (or be established) between the issuer
and VisaNet. Existing VAP connections must be modified for file delivery connectivity.

Once the communications link is established, delivery tests can start. Refer to the Deferred
Clearing Advice File (DCAF) Service Technical Specifications Manual for complete details
and for sample network definitions.
VCMS supports the creation and delivery of test files directly to the issuer's VisaNet
connection or to a VAP, after which the issuer must transfer the test file. Visa
representatives help issuers work with the member Testing Support Services group to
arrange for this part of the implementation.
Testing is not required for implementing the DCAF Service. However, VisaNet testing
specialists perform specific tests with the member to ensure that the issuer's host
applications meet minimum requirements before they begin interfacing with the production
systems.

Service monitoring is not available for the DCAF Service.

The DCAF Service does not require any additional participation agreement. Issuers can
send a letter of intent to their Visa representatives, confirming their interest in using the
DCAF Service, and the representatives can begin making the arrangements.
Members should consider the following impacts when planning for implementation of DCAF.
Impacts—Changes to connectivity may affect the cost of Visa-supplied equipment

Billing Impacts—
or services. Advices recovered using DCAF have the same billing charges as advices
recovered online.
Impact—DCAF does not affect issuer participation, Treasury processing, or BIN

Legal Impact—
licensing. An issuer processor, or a third-party processor, that is considering implementing
the DCAF Service should review its legal processing agreements to determine if any
changes must be made.
Table 29-1 provides an overview of issues that Visa staff and members must consider when
implementing the DCAF Service.
Table 29-1 DCAF Service Implementation Issues
Area of Consideration Visa Activity Issuer Activity

Communications Check necessary connectivity: Check necessary connectivity:
• Make file delivery VIC • Assist with Visa VIC
connection: direct connection: direct
connection or VAP. connection or VAP.
• For VAPs, assist with • For VAPs, make member file
member host connection. delivery session connection.
Computer Programming Visa may supply a file transfer • Develop new programs
program or direct-connection required to receive DCAF
samples or assist the member. data.
Program DCAF file record
processing, or integrate
it with existing advice
processing.

Table 29-1 DCAF Service Implementation Issues (continued)

Area of Consideration Visa Activity Issuer Activity
Online Capacity Consider capacity reduction Issuers can leave the existing
during the post-implementation capacity in place for fallback
phase of the project. purposes while the issuer
confirms satisfactory operation
of DCAF.
Security n/a Review and audit host-to-host
connections (required).
Staffing n/a • Determine resource
estimates (required).
• Analyze programming and
operations staff impact.
Legal Agreements No change required. For issuer processors or
third-party processors, review
legal processing agreements
before implementing the DCAF
Service.

Participation Request commitment letter. Provide commitment letter.
Billing n/a Understand how changes to
connectivity affect the cost of
Visa-supplied equipment or
services.
Training Visa may supply or assist. Schedule and receive training
on file delivery processing.
Refer to the VisaNet Access
Point Operator's Guide.
Testing Pre-production testing is Perform pre-production testing
required. (required).
29.4.4 Issuer Host Changes

The issuer's host computer must be able to read the file sent from VisaNet (either through
the VAP or through a direct connection), extract the advice records, and process them.
If file delivery processing currently does not exist at the issuer site, issuers must establish a
new communications link from the issuer host to VisaNet using either a VisaNet connection
or a VAP's Generic File subsystem.
For more information about VisaNet connections and VAP processing, refer to “For More
Information” in About This Manual for documentation about VisaNet connections and VAPs.

The following messages pertain to the DCAF Service. Regardless of the file format chosen
or the file delivery mechanism used, all DCAF files contain only the following financial
transactions.
Advice—This advice contains processing

0220: POS (Original Financial Transaction) Advice—
00.
code 00

Chapter 29 How Deferred Clearing Advice File (DCAF) Service Works
Advice—This advice contains

0220: Cash Disbursement (Original Financial Transaction) Advice—
01.
processing code 01
Advice—This advice contains processing code 20

0220: Merchandise Credit Transaction Advice— 20.
All other deferred clearing advices, both financial and non-financial, are delivered online
through the standard advice retrieval process.
NOTE
SMS issuers that participate in the ATM Format Conversion Service do not receive deferred clearing advices
for cash disbursement transactions. See the ATM Format Conversion Service chapter in this manual for
information about this service.
29.6 HOW DEFERRED CLEARING ADVICE FILE (DCAF) SERVICE WORKS

V.I.P. delivers DCAF files as often as four times during a daily processing cycle. The first
file is available as early as 11:00 p.m. Pacific time. Actual delivery times vary, depending
on the volume of deferred clearing advices. Default DCAF file deliveries are scheduled to
begin at the following times:
• 11:00 p.m. Pacific time
• 12:30 a.m. Pacific time

• 2:00 a.m. Pacific time
• 3:15 a.m. Pacific time (the file is available as soon as BASE II clearing finishes)
NOTE
All times are approximate.
Once VisaNet delivers a file of deferred clearing advices to the VisaNet connection or VAP,
the file is available for transfer to the member's host system for processing.
As part of the DCAF Service, V.I.P. can provide participants with a list of all of the files
delivered and can notify participants that the last file for the settlement cycle has been
delivered. Members can use the file inventory and the last file notification to schedule
internal processing.
NOTE
The inventory file and last file notification are available to all DCAF participants regardless of the file format or
file delivery mechanism they choose. However, last file notification processing differs depending on whether
the issuer uses a VAP or a direct VisaNet connection.
For detailed information about inventory file and last file notification processing for VisaNet
connection and VAP DCAF file recipients, refer to the Deferred Clearing Advice File (DCAF)
Service Technical Specifications Manual.
The following sections describe the DCAF process flow and message flow.
29.7 PROCESS FLOWS

The DCAF Service process flow consists of the following steps.

1. The dual-message acquirer sends deferred clearing drafts to V.I.P.

2. V.I.P. collects the advices in bulk files and reformats them (into ISO bulk file format or
fixed format depending on the issuer's requirement), if necessary.
3. V.I.P. forwards the bulk files to the issuer at the requested time, using the connection
established by the issuer for the file delivery.
NOTE
The issuer does not return advice responses.
Figure 29-1 illustrates the basic DCAF process flow.
Figure 29-1 DCAF Service Process Flow

The dual-message V.I.P. reformats the drafts The issuer retrieves
acquirer submits the into advices and, if the advice files and
TC 05, TC 06, and necessary, to the format processes them.
TC 07 deferred clearing specified by the issuer
drafts to VisaNet. and bundles the records
into bulk files. At the
specified delivery time,
V.I.P. delivers the bulk
files to the issuer using
the connection specified
by the issuer.
29.8 MESSAGE FLOWS

Figure 29-2 illustrates the message flow when the acquirer submits a deferred clearing
draft. After reformatting the draft to an advice record, and the format if necessary to satisfy
the issuer's requirement, V.I.P. bundles the advice records into bulk files and forwards
them to the issuer.

Figure 29-2 DCAF Service Deferred Clearing Advice Message Flow
TC 05, TC 06, or TC 07 Draft TC 05, TC 06, or TC 07 Draft 0220 Advice Message

Field 3: Processing Code Field 3: Processing Code Field 3: Processing Code

This section describes the key field associated with the DCAF Service.

This field contains the processing code for the transaction. Valid codes for DCAF
advice records are:
• 00 = POS financial transaction advice (from dual-message TC 05)
• 01 = Cash disbursement advice (from dual-message TC 07)
• 20 = Merchandise credit transaction advice (from dual-message TC 06)

For further information about the DCAF Service, refer to the following documents:
• Deferred Clearing Advice File (DCAF) Service Technical Implementation Guide
• Deferred Clearing Advice File (DCAF) Service Technical Specifications Manual
• Deferred Clearing Advice File (DCAF) Service Member Implementation Guide
• Deferred Clearing Advice File (DCAF) Service, Service Activation Guide
and Volume 2
• Visa International Operating Regulations, Volume 1

Chapter 30 Dynamic Key Exchange (DKE) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
IN BRIEF 30-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
Implementation Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
Key Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
Key Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
Number of Keys Maintained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-5
Support Fallback to Static Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-5
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
On-Request Key Exchange Messages (V.I.P. Master). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6
Automatic Key Exchange Message Flow (V.I.P. Master). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6
Member-Provided Key Exchange Messages (V.I.P. Slave). . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . .30-
HOW DYNAMIC KEY EXCHANGE (DKE) SERVICE WORKS 30-77
Dynamic Key Exchange (DKE) Service

FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
PROCESS FLOWS 30-77
On-Request Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-8
Automatic Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-10
Member-Provided Key Exchange Process Flow (V.I.P. Slave). . . . . . . . . . . . . . . . . . . . . . .30-11
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
MESSAGE FLOWS 30-12
12
On-Request Key Exchange Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-13
Automatic Key Exchange Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-15
Member-Provided Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-17
Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-19
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
20
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-
23


Chapter 30 Dynamic Key Exchange (DKE) Service
30.1 IN BRIEF
The Dynamic Key Exchange (DKE) Service is an optional service that enables Single
Message System (SMS) members to change working keys that are used to protect
cardholder' PINs through the use of online messages.
Dynamic Key Exchange Service is available to members in all Visa regions.
BASE I
SMS Dynamic Key Exchange Service is available to Single Message System (SMS)
users.
SMS only
I
Participation in Dynamic Key Exchange Service is optional for issuers.
Issuer

A
Participation in Dynamic Key Exchange Service is optional for acquirers.
Acquirer

The Dynamic Key Exchange (DKE) Service makes it practical to change PIN encryption
keys frequently, thereby increasing the security of the payment system and reducing the
chances of key compromise. There are two types of PIN encryption keys: Acquirer Working
Keys (AWKs) and Issuer Working Keys (IWKs). VisaNet and a member share AWKs and
IWKs. Acquirers use AWKs to encrypt the PIN when it sends a message to VisaNet.
VisaNet uses the IWK to encrypt the PIN when it sends the message to the issuer. The
DKE Service enables members to change these keys through online messages.
The DKE Service also reduces the effort involved in managing keys manually. In addition
to cost reductions, the service eliminates manual intervention, minimizing errors.
Visa has modified its PIN processing and cryptographic key management practices and
requirements in accordance with national and international Data Encryption Standard
(DES) specifications, which include the use of the Triple DES Encryption Algorithm

(DEA). To facilitate this transition, VisaNet currently supports both single-length (16-byte)
cryptographic keys and double-length (32-byte) cryptographic keys. Various Triple DES
mandates require members to use Triple DES keys now or in the near future.

The DKE Service is flexible. Participants can configure the service to suit their specific
needs. This section describes the options that are available to participants. Members
select these options based on their preferences when they set up their service participation.
30.3.1.1 Implementation Level

Participants can establish their DKE options at the following implementation levels:
• BIN Level: This option uses a single set of dynamic AWKs or IWKs for a BIN or a
collection of BINs.
• PCR Level: This option uses a single set of dynamic AWKs or IWKs across a PCR.
• Station Level: This option uses a single set of dynamic AWKs or IWKs for a station.
For a PCR, members can implement the DKE Service at only one of the above mentioned
levels.
30.3.1.2 Key Generation

Either VisaNet or a member can generate a key and send it to the other party. If VisaNet
generates the key, VisaNet is the “V.I.P. Master”. If a member generates the key, VisaNet
is the “V.I.P. Slave.”
30.3.1.3 Key Delivery

Members can choose to receive keys either periodically or on request when they set up the
service with VisaNet as the V.I.P. Master. VisaNet takes responsibility for generating the
key and sending it to the member in this capacity.
Members can choose the times they want VisaNet to generate a new key:
Delivery—VisaNet delivers the key automatically. Members can choose one

Automatic Key Delivery—
of the following options for the frequency of key delivery.

• Set hourly interval: Members can specify the time, in hours, that should elapse between
automated key exchanges.
• Daily: Members can specify the time, in GMT, when they want VisaNet to send a new key.
Members that implement the DKE Service at the PCR level and at the station level
must specify the station to which VisaNet should deliver the key. Acquirers and issuers
can receive key management messages without signing on to a station. In this case,
the member does not need to specify the network.
Members that implement the DKE Service at the BIN level can optionally specify the station.
In this case, the member must select a network to which VisaNet should deliver the key.
Members that are set up for automatic key delivery also can request a key delivery at any
time at its discretion as necessary.
Delivery—Members send an 0800 message to request a key.

On-Request Key Delivery—
When VisaNet receives a request, it generates a key and sends it to the member.

30.3.1.4 Number of Keys Maintained

This section contains information about the number of keys that acquirers and issuers
must maintain.
Acquirers—Acquirers have the option of maintaining either one Acquirer Working Key
Acquirers—
(AWK) or two AWKs. The acquirer specifies the AWK it used to encrypt the PIN in field 53.4
(Field 53—Security-Related Control Information, positions 7–8, Zone Key Index) of the
request. For the DKE Service, this coding enables participants to use either the single-key
arrangement or the two-key arrangement.
If an acquirer selects the two-key arrangement and the acquirer subscribes to automatic
key delivery, VisaNet alternates from one key to another with each key delivery.
If an acquirer selects the two-key arrangement and the acquirer wants to initiate an
on-request key delivery, it must specify which key it wants to change in field 53.4 in the
request message.
Acquirers can send the PIN in the request encrypted with either of the two keys. The
acquirer must specify the key it used to encrypt the PIN in field 53.4 so VisaNet can select
the appropriate key for decrypting the PIN.
Issuers—Issuers have the option of maintaining either one Issuer Working Key (IWK) or
Issuers—
two IWKs.
If an issuer selects the one-key arrangement, VisaNet always delivers the key specified
by code 01 in the Zone Key Index subfield. VisaNet always uses that IWK to encrypt
the PIN sent to that issuer.
If an issuer selects the two-key arrangement, VisaNet alternates from one key to another
with each key delivery.
The Zone Key Index code used for the last key delivery is the active Zone Key Index.

VisaNet uses the key specified in the active Zone Key Index for encrypting the PIN in
the transaction sent to the issuer.
30.3.1.5 Support Fallback to Static Key

Participating members have the option to set up a static key as back-up. If the back-up
key has been set up in advance and the member has chosen this option, V.I.P. operations
staff have the capability to fall back to the static key at the member's request and perform
a manual intervention.

To participate in the service, members must obtain a Zone Control Master Key (ZCMK).
For a dynamic key exchange, a ZCMK is referred to as a Key Exchange Key (KEK).
Members use a KEK for encrypting the working key when they convey it in an online
message. A ZCMK used to protect an AWK is called an Acquirer Key Exchange Key
(AKEK), and a ZCMK used to protect an IWK is called an Issuer Key Exchange Key (IKEK).
Before establishing the actual service, participants must complete the Key Management
and ZCMK Request forms. Upon receipt of the ZCMK Request Form, VisaNet generates
the Zone Control Master Key. VisaNet sends the ZCMK in component form to the recipients
in a secure mailer within 14 days of receipt of the request forms.

Service participants must also complete a Dynamic Key Exchange Enrollment Form, which
is part of the Member Implementation Questionnaire.
30.4.1 Testing
Testing is mandatory for all acquirers and issuers that want to use the service.

Service monitoring is not available for the DKE Service.

Refer to the Payment Technology Standards Manual for information about planning and
implementing encryption and decryption technology.
Members interested in using the DKE Service can contact their Visa representatives.

The following messages pertain to the Dynamic Key Exchange Service.
Request—Members use this message to request an

0800: Network Management Request—
encryption key change. V.I.P. also uses 0800 messages to deliver automatic encryption
key changes.
Response—Members use this message to acknowledge an

0810: Network Management Response—
0800 message for an encryption key change. V.I.P. uses an 0810 message to respond to
a member's on-request encryption key change. Field 39 indicates the acknowledgment
response information.
30.5.1 On-Request Key Exchange Messages (V.I.P. Master)

The following messages are used when VisaNet delivers a key to a member at the
member’s request.
V.I.P.)—Members use this 0800 message to

0800: Key Change Request (Member to V.I.P.)—
request an encryption key change.
Member)—V.I.P. uses this 0810

0810: Key Change Request Acknowledgment (V.I.P. to Member)—
message to acknowledge a member’s message for an on-request key change.
Member)—V.I.P. uses this 0800 message to deliver

0800: Key Delivery Message (V.I.P. to Member)—
the key to the member.
V.I.P.)—Members use this 0810

0810: Key Delivery Acknowledgment (Member to V.I.P.)—
message to acknowledge receipt of the key.
30.5.2 Automatic Key Exchange Message Flow (V.I.P. Master)

The following messages are used when VisaNet automatically delivers the keys to the
member.
Member)—V.I.P uses this 0800 message to deliver key

0800: Key Delivery (V.I.P. to Member)—
to the member.
V.I.P.)—Members use this 0810

0810: Key Delivery Acknowledgment (Member to V.I.P.)—
message to acknowledge receipt of key delivery.

Chapter 30 How Dynamic Key Exchange (DKE) Service Works
30.5.3 Member-Provided Key Exchange Messages (V.I.P. Slave)

The following messages are used when a member delivers a key to VisaNet.
V.I.P.)—Members use this 0800 message

0800: Key Delivery Message (Member to V.I.P.)—
to deliver a key to V.I.P.
Member)—V.I.P. uses this 0810 message

0810: Key Delivery Acknowledgment (V.I.P. to Member)—
to acknowledge receipt of the key.
30.6 HOW DYNAMIC KEY EXCHANGE (DKE) SERVICE WORKS

This section contains the process flows and message flows for the DKE Service. It also
describes exception conditions.
Key exchange is the process by which a Working Key is synchronized between a member
and VisaNet. Key exchange is necessary to give a member the capability to set a new
Working Key and synchronize it with VisaNet to preclude the possibility of the existing
Working Key being compromised.
Key exchange may be dynamic or static, depending on member settings. In either case,
the key exchange procedure is similar except that dynamic key exchange occurs online in
V.I.P. and is used only for Issuer Working Keys (IWKs) and Acquirer Working Keys (AWKs).
30.7 PROCESS FLOWS

The process flows vary depending on how the member configures the service. The
following sections describe high-level flows for the following scenarios:
• On-Request Key Exchange
• Automatic Key Exchange
• Member-Provided Key Exchange

30.7.1 On-Request Key Exchange Process Flow

Figure 30-1 illustrates the DKE process flow when the member at its discretion (on request)
asks VisaNet for a new AWK or IWK. The member asks VisaNet to change the key.
VisaNet sends the member the new key.
Figure 30-1 DKE Process Flow—On-Request Key Exchange Request (V.I.P. Master)
Issuer or Acquirer V.I.P.
Zone Key
Index File
Me mbe r a sks Visa Ne t to cha nge Visa Ne t re ce ive s me mbe r

e ncryption ke y (IWK or AWK). ke y cha nge re que st.
Me mbe r re ce ive s VisaNet s e nds me mbe r cha nge

a cknowle dge me nt. request a cknowle dge me nt.
Member receives new ke y. VisaNet de live rs ne w ke y

to me mbe r.
Member sends key delivery VisaNet re ce ive s

acknowledgement . acknowledgement a nd be gins
using new key.

.
1. The member requests an AWK or an IWK change with an 0800 key change request.
2. V.I.P. processes the 0800 key change request in the following manner:
a. V.I.P. rejects the request with reject code 0384 if a dual-key V.I.P.-format member
does not send in Field 53—Security-Related Control Information.
b. V.I.P. rejects the request with reject code 0621 if:
• a single-key member wants V.I.P. to perform PIN verification and the code for the
01.
ZKI in field 53 is not 01
• a V.I.P. format member tries to do PIN DKE with NMI other than 0160 (AWK)
or 0161 (IWK) in the request.
• for a BIN-based DKE member, the source station and the BIN in field 33 of the
request do not have the same PCR.
• for a BIN-based DKE member, the BIN in field 33 does not have encryption data
defined.

• for a station- or PCR-based DKE member, the source station does not have
encryption data defined.
• the member is requesting AWK change when they do not have an AKEK set up.
• the member is requesting IWK change when they do not have an IKEK set up.
c. V.I.P. rejects the request with reject code 0622 if the member requesting key
exchange does not participate in DKE.
d. V.I.P. declines with an 0810 Key Change Request Acknowledgment using response
code 06 if:
• DKE has been globally stopped with ZQOKE STOP.
• only one VIC in the complex is up.
• the inter-VIC link with the member-connected primary VIC is down.
• member requests key change when a key change for that member is already
in progress.
• security module key generation fails.
• inter-VIC synchronization fails because of fluctuating inter-VIC linkage.
• a member sends in a key change request during the cool-off period (1 minute)
for that key.
e. V.I.P. responds with an 0810 Key Change Request Acknowledgment using response
code 00 if none of the above errors are encountered. This response is followed up
by the next message.
3. V.I.P. sends an 0800 Key Delivery to the member with the requested Working Key.
4. Member responds to the 0800 Key Delivery in the following manner:
a. Member declines with an 0810 Key Delivery Acknowledgment using response
code 06 if they encounter problems translating and/or storing the Working Key
delivered by V.I.P.
b. Member responds with an 0810 Key Delivery Acknowledgment using response
00, which completes the process of dynamic key exchange.
code 00

30.7.2 Automatic Key Exchange Process Flow

Acquirer or issuer processors can choose to receive new encryption keys automatically.
Figure 30-2 illustrates the dynamic key exchange process flow when V.I.P. initiates the
change of an encryption key (according to a prearranged agreement with the member).
Figure 30-2 DKE Process Flow—Automatic Key Exchange Request (V.I.P. Master)
V.I.P. Issuer or Acquirer
Zone Key
Index File
VisaNet sends the new

The member receives
working key to the
the new key.
member.
VisaNet receives delivery The member sends a

acknowledgment. delivery acknowledgment
to Visa indicating receipt
of new key.
1. V.I.P. sends an 0800 key delivery request to the member with the requested Working
Key.
2. Member responds to the 0800 key delivery request in the following manner:
• Member declines with an 0810 Key Delivery Acknowledgment using response code 06
if they encounter problems translating, storing, or both, the Working Key delivered
by V.I.P.
• Member responds with an 0810 Key Delivery Acknowledgment using response
code 0000, which completes the process of dynamic key exchange.

30.7.3 Member-Provided Key Exchange Process Flow (V.I.P. Slave)

The acquirer or issuer processor sends the new key to Visa. Figure 30-3 illustrates the
dynamic key exchange process flow when a member delivers a new key to Visa.
Figure 30-3 DKE Process Flow—Automatic Key Exchange Request (V.I.P. Slave)
Zone Key
Index File
Member sends new VisaNet receives

key to VisaNet. new key.
Member receives VisaNet sends key

acknowledgment. delivery acknowledgment.
The dynamic key exchange process flow when a member delivers a new key to Visa
consists of the following steps:

1. Member requests an AWK or IWK change with an 0800 Key Delivery message.
2. V.I.P. processes the 0800 Key Delivery in the following manner:
a. V.I.P. rejects the request with reject code 0384 if a dual-key V.I.P.-format member
did not indicate the key to be changed in field 53.
b. V.I.P. rejects the request with reject code 0621 if:
• a single-key member tries to do PIN DKE with ZKI in field 53 not 0101.
• a V.I.P.-format member tries to update PIN Working keys with an NMI other
than 0164 (AWK) or 0165 (IWK).
• for a BIN-based DKE participant, the source station and the BIN in field 33 of the
request do not have the same PCR.
• for a BIN-based DKE participant, the BIN in field 33 does not have encryption
data defined.
• for a station- or PCR-based DKE participant, the source station does not have
encryption data defined.
• the member is requesting an AWK change when they do not have an AKEK set up.
• the member is requesting an IWK change when they do not have an IKEK set up.
c. V.I.P. rejects the request with reject code 0622 if the member requesting key
exchange does not participate in the DKE Service.
d. V.I.P. declines with an 0810 Key Delivery Acknowledgment using response code 06
if:
• DKE has been globally stopped with ZQOKE STOP.
• only one VIC in the complex is up.
• the inter-VIC link with the member-connected primary VIC is down.
• the member is not set up as V.I.P. Slave.
• the member requests key change when a key change for that member is already
in progress.
• the security module key translation fails.
• the inter-VIC synchronization fails because of fluctuating inter-VIC linkage.
• a member sends in a key change request during the cool-off period (1 minute)
for that key.

e. V.I.P. responds with an 0810 Key Delivery Acknowledgment using response code 00
if none of the above errors are encountered. This completes the process of dynamic
key exchange.
30.8 MESSAGE FLOWS

Network management messages are used both to exchange keys on-request, when
initiated by members, and to exchange keys automatically, when initiated by V.I.P.
according to prearranged agreement.
VisaNet uses a 10-second timeout value for all messages containing a new encryption key.
If the member does not respond within 10 seconds or if the member responds indicating
improper receipt of the new key, V.I.P. resends the key delivery message. If the second
attempt to deliver the new key fails, V.I.P. cancels the key exchange.
If members encounter encryption or decryption errors from their security module, they
should respond to V.I.P. with response code 81 (cryptographic error). This response notifies
the V.I.P. System that it must generate a new encryption key for delivery to the member.

30.8.1 On-Request Key Exchange Message Flow

As illustrated in Figure 30-4, members use an 0800 message to initiate a new encryption
key. The 0800 message originator must indicate, in Field 53—Security-Related Control
Information, which key to change. V.I.P. uses an 0810 response to acknowledge receipt of
the key request. The trace number, in field 11, which is assigned by the 0800 message
originator (the member), must be returned unchanged in the 0810 response. If the member
resends a new request, it uses the trace number from the original request.
V.I.P. delivers a single-length key using Field 96—Message Security Code in the 0800
Key Delivery Message. It delivers double-length key requests using Field 105—Message
Security Code—Double-Length Key.
Acquirer processors can begin using the new key after sending the 0810 key delivery
response to V.I.P. For acquirers supporting a single key, V.I.P. will process messages
with the new key or the old key for five minutes, after which time all acquirer-generated
messages must have PINs encrypted with the new key.
For issuers, V.I.P. begins using the new key upon receipt of the 0810 response (in which
the code in Field 39—Response Code is 00 00). In an on-request exchange, V.I.P. continues
sending messages using the old key until it receives the 0810 response.

Figure 30-4 DKE Message Flow—On-Request Key Exchange Request (V.I.P. Master)
Zone Key
Index File
0800 Key Change Request 0800 Key Change Request

F7: Transmission Date and Time (Required) F7: Transmission Date and Time (Required)
F11: System Trace Audit Number (Required) F11: System Trace Audit Number (Required)
F33: The Institution ID for which a Working Key is requested F33: The Institution ID for which a Working Key is requested
(Required for BIN-based DKE; not required for station- or (Required for BIN-based DKE; not required for station- or
PCR-based DKE) PCR-based DKE)
F53: Security Related Control Information (Not required for VIP F53: Security Related Control Information (Not required for VIP
format Single-Key members; required otherwise) format Single-Key members; required otherwise)
F63.1: Network ID (Required) F63.1: Network ID (Required)
F70: Network Management Information (Required) F70: Network Management Information (Required)
0810 Key Change Request Acknowledgement 0810 Key Change Request Acknowledgement
F39: Response Code (Required) F39: Response Code (Required)
0800 Key Delivery 0800 Key Delivery

F48: Check Digit of Key Delivered F48: Check Digit of Key Delivered
F96: SDES Working Key, or F105--TDES Working Key F96: SDES Working Key, or F105--TDES Working Key
0810 Key Delivery Acknowledgement 0810 Key Delivery Acknowledgement
F39: Response Code F39: Response Code
F96: SDES Working Key, or F105--TDES Working Key F96: SDES Working Key, or F105--TDES Working Key

30.8.2 Automatic Key Exchange Message Flow

Figure 30-5 illustrates the DKE message flow when V.I.P. automatically initiates the
change of an encryption key (according to a prearranged agreement with the member).
The main difference in the message flow for automatic key exchange and for on-request
key exchange is that, in automatic key exchange, V.I.P. initiates the first 0800 transaction.

Figure 30-5 DKE Message Flow—Automatic Key Exchange Request (V.I.P. Master)
Zone Key
Index File

F7: Transmission Date and Time F7: Transmission Date and Time
(Required) (Required)
F11: System Trace Audit Number F11: System Trace Audit Number
F33: The Institution ID for which a Working F33: The Institution ID for which a Working
Key is requested (Required for BIN-based Key is requested (Required for BIN-based
DKE; not required for station- or DKE; not required for station- or
F53: Security Related Control Information F53: Security Related Control Information
(Not required for VIP format Single-Key (Not required for VIP format Single-Key
members; required otherwise) members; required otherwise)
F70: Network Management Information F70: Network Management Information
F96: SDES Working Key, or F105--TDES F96: SDES Working Key, or F105--TDES
Working Key Working Key
0810 Key Delivery Acknowledgment 0810 Key Delivery Acknowledgment


30.8.3 Member-Provided Key Exchange Process Flow

Figure 30-6 illustrates the DKE message flow when member uses 0800 Key
Delivery Message to deliver the key to Visa. The member must indicate, in Field
53—Security-Related Control Information, which key to change. The trace number, in
field 11, is assigned by the 0800 message originator (the member),
V.I.P. uses an 0810 response to acknowledge receipt of the key request. The trace
number, in field 11, which is assigned by the 0800 message originator (the member), must
be returned unchanged in the 0810 response. If the member resends a new request, it
uses the trace number from the original request.

V.I.P. begins using the new key upon receipt of the 0800 key delivery message.
Figure 30-6 DKE Message Flow—Automatic Key Exchange Request (V.I.P. Slave)
Zone Key
Index File

Working Key Working Key only)
0810 Key Delivery Acknowledgment 0810 Key Delivery Acknowledgment


30.8.4 Exception Conditions

Table 30-1 provides the exception conditions that may occur in the DKE Service message
flow and their recommended solutions.
Table 30-1 DKE Exception Conditions
Condition Action Taken by Visa Member Response

Undeliverable response (to an The 0810 key response The member should be able to
on-request request). message is discarded. process the 0800 key delivery
message even if the 0810 key
The 0800 key delivery message request response does not
is still sent to the member. arrive.
Undeliverable request. The 0800 key delivery message None.
is discarded, and V.I.P.
processes it as if a timeout
occurred.
Timeout. If V.I.P. does not receive a None.
response to an 0800 key
delivery message within
10 seconds:
• V.I.P. resends the request a
second time.
• If no response is received to
the second request, V.I.P.
cancels the key exchange.
PIN block errors detected by If V.I.P. encounters PIN block None.
V.I.P. during normal PIN-based errors while attempting to
transaction processing. decrypt the acquirer's PIN
block:
• V.I.P. returns response
code 81 in response to the

authorization or financial
transaction.
• V.I.P. then initiates an
automatic key change for the
AWK.
PIN block errors detected During normal transaction The issuer must return
by the issuer during normal processing, if the issuer response code 81 to V.I.P.
transaction processing. encounters a PIN block error Upon receiving this response,
while attempting to decrypt the V.I.P. then initiates an
PIN block received from V.I.P.: automatic key change for
• The issuer returns response the IWK.
code 81 in the financial
response.
• V.I.P. then initiates an
automatic key change for the
Issuer Working Key.
V.I.P. not accepting key change V.I.P. returns an 0810 response The member may re-initiate the
messages. with response code 0606. key change request at a later
time.


The following fields are used in the Dynamic Key Exchange Service.
Field 33—Forwarding Institution Identification Code

Field 33 contains the 6-digit BIN to which the new encryption key is applied. This field
appears in all DKE messages including the 0810 response. This field is not used for
station-level or PCR-level DKE processing.

Field 39 appears in 0810 response messages to acknowledge receipt of the request
message and to indicate the ability of V.I.P. or the member to comply with the request.
The following response codes are used:
Comply)—V.I.P. returns this code

Response Code 00, Request Acknowledged (Will Comply)—
when it accepts the member's request for a key change. The member must use this
response code to indicate that the encryption key has been accepted and is ready for
use.
Response Code 06, Request Acknowledged (Unable to Comply)— Comply)—V.I.P. returns

code 06 when it cannot accept a member's request for a key change. This condition
occurs if the identifying institution is not set up as a service participant or if a key change
is already in progress when V.I.P. receives the request. This condition also occurs if
a key change request has the wrong Zone Key Index in field 53. For instance, if an
acquirer sends a request with a key index of 01 and 01 is the current active key, V.I.P.
responds with code 06 06.
The member must use this code when it cannot accept the new key because the key
check value does not match or the security module is in error.
PIN—The member returns code 81 to

Response Code 81, Cryptographic Error Found in PIN—
V.I.P. when a security module finds a cryptographic error during PIN decryption.
Field 48, Usage 14—Dynamic Key Exchange Working Key Check Value
Field 48 is used for encryption key check values and appears in 0800 requests with
network management codes 162 and 163 in field 70.
The format of field 48 is as follows:

• Field length: 1 byte binary
• Field identifier: & (ampersand) character (EBCDIC)
• Check digits: four alphanumeric characters (EBCDIC)
The check digits are the first four hexadecimal digits of output resulting from
encrypting zeros with the newly issued key in the message security code field (in
field 96).

Field 52—Personal Identification Number (PIN) Data

Field 52 contains a PIN or password, encrypted and formatted as a block of
16 hexadecimal digits.
The format of this field in an outgoing request must be that indicated by the PIN block
format code in Field 53—Security-Related Control Information of the request. In an
incoming request or advice, the format conforms to the PIN block format of the issuer as
specified to Visa.
The personal identification data type subfield within field 53 indicates whether this field
contains a PIN or a password.
This field must appear:

• In an outgoing 0100 or 0200 request when the customer enters a PIN or password at
the point of sale or point of service (POS).
• In account transfer request messages. When applicable, the acquirer includes a PIN
or password only in an original request.
V.I.P. rejects the message with reject code 0752 if this field is present in advices,
completions, reversals (full and partial), representments, adjustments, and their
responses.
If field 52 or field 53 carrying PIN data appears in a non-original or exception item,

SMS rejects the message with reject code 06990699—Presence of PIN/Track/AVS data
inconsistent with message type.
This field is not allowed:

• If the cardholder is not present to key in the PIN or password at the POS.
• If the code in field 25 is 01 (customer not present) or 08 (mail or telephone order).
For STIP advices, if STIP authorizes a request with a PIN, it zero-fills this field so the
issuer knows the PIN was provided and included in the original request. Thus, this field

may contain all zeros only in a request or advice incoming to the issuer. However,
for Interlink issuers, this field is not zero-filled. It contains the PIN translated using
the issuer's key.
The Visa Security Module edits the contents of this field during PIN translation and PIN
verification. If there is an error (most commonly an acquirer key problem) V.I.P. does
not reject the request message. Instead, V.I.P. sets the response code in field 39 of
the 0110 or 0210 response to 81 or 86 86.

Field 53—Security-Related Control Information

Index—The index in field 53.4 indicates which key was used
Positions 7–8, Zone Key Index—
to encrypt the PIN. In Dynamic Key Exchange messages, this subfield is used to
indicate which key is being changed. If the PIN in field 52 is zeroed out before the
request reaches the issuer, this code is the original for the acquirer's key. Positions 7–8
02.
must contain 01 or 02
The code in field 53 indicates which of the possible encryption keys that can be changed:
01 = Encryption key 1 is to be changed.
02 = Encryption key 2 is to be changed.
Field 53.4 tells V.I.P. which key is being exchanged.
Code 01 in field 53.4 in a DKE 0800 key delivery message is always for single-key
DKE players. V.I.P. rejects requests with code 02 in field 53.4 for single-key members.
Single-key members may not send in field 53 at all in the DKE request, or when they do,
they should send code 01 in field 53.4.
The code in field 53.4 changes from 01 to 02 in automatic key delivery requests for
dual-key members. For DKE requests, V.I.P. populates field 53.4 with the value from
the request in the 0800 key delivery response.
Field 53.3 (positions 5-6) has no significance for the DKE Service. The field is primarily
for decrypting and encrypting PIN blocks. However, it is part of ISO field 53, which DKE
needs, and is set to 01 for all formats other than Plus.
Field 63.1—Network ID Code

Field 63.1 provides the network identification code of the BIN to which the new
encryption key applies. The field appears in all dynamic key exchange messages. The
network ID code must be 0002 (Visa), 0003 (Interlink), or 0004 (Plus).

NOTE
If members are using the same encryption keys for multiple services, they can use one network ID for
key exchange. The keys apply to all applicable services.

Field 70 must contain valid codes indicating which entity initiated the key request,
whether the key is being delivered to an issuer or an acquirer, and whether the key is
single-length or double-length.
Field 96—Message Security Code

Field 96 contains the new encryption key and appears in all 0800 messages.

Field 105—Message Security Code—Double-Length DES Key

Field 105 contains the new 16-byte, 32-position double-length DES key and may appear
in 0800 key exchange messages from VisaNet. The field content is hexadecimal
16 bytes. This field must be present in an 0800 DKE message when Field 70—Network
Management Information Code contains one of the following values:
162 = Deliver a New Acquirer Working Key (Switch to Acquirer)
163 = Deliver a New Issuer Working Key (Switch to Issuer)

For further information about the Dynamic Key Exchange Service, refer to the following
documents:
• Single Message System (SMS) Dynamic Key Exchange Service Announcement and
Specifications, September 1998


Chapter 31 International Automated Referral Service (IARS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
IN BRIEF 31-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
International Automated Referral Service (IARS)

REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
WORKS.. . . . . . .31-
HOW INTERNATIONAL AUTOMATED REFERRAL SERVICE (IARS) WORKS 31-55
Currency Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-5
Translation Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
Equipment Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
PROCESS FLOWS
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
31-99
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
MESSAGE FLOWS 31-10
10
IARS Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-11
Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
12
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-
13


Chapter 31 International Automated Referral Service (IARS)
31.1 IN BRIEF
The International Automated Referral Service (IARS) enables acquirers to reach any Visa
issuer promptly whenever the issuer needs more information from the acquirer before
making an authorization decision. IARS guarantees a response to every referral call,
even when the issuer is unavailable. This service helps reduce Visa sales losses caused
by authorization delays.

NOTE
This service is not applicable for any ATM messages.
IARS is available to members in all Visa regions.
BASE I
SMS IARS is available both to BASE I System users and to Single Message System
(SMS) users.
BASE I and SMS
I Participation in IARS is mandatory for point-of-sale and point-of-service (POS)

issuers that process international referrals.
Issuer
A Participation in IARS is mandatory for Visa POS acquirers that process

international referrals.
Acquirer

The International Automated Referral Service (IARS) provides a single toll-free number
for acquirers to reach any Visa issuer promptly whenever the issuer (or the V.I.P. System,
on the issuer's behalf) generates a referral in response to an authorization request.
A referral indicates that an issuer must speak with the acquirer to get additional information
needed to process the authorization request.

NOTE
The term “voice” in the V.I.P. documentation manuals refers to the way cardholder information is obtained
for the 0100 authorization request message. For instance, the field 22 field description in the technical
specifications manuals specifies that the field is included in a request for which the card number is entered
directly into a computer through a series of digitized voice prompts, for instance, through VoiceTec. This use
of the term "voice" is different from the term's usage in the Visa International Operating Regulations, which
addresses voice authorizations as a method of responding to an authorization request.
IARS provides:
• Call messaging when more information is needed to decide whether to approve or
decline an authorization request.
• Immediate responses so that merchants and cardholders are not kept waiting
unnecessarily at the POS.
• Support for rotary telephones or other pulse-generating telephones when touch-tone
telephones are not available.
• Stand-in authorization processing when the issuer is unavailable.
• 24-hour member Help Desk Support to ensure high-quality performance.
• Service incentives to acquirers for responding promptly to referrals.
• Translation services in eight languages: United Kingdom (U.K). English, United States
(U.S). English, French, Spanish, German, Mandarin, Japanese, and Italian.
• Reports that cover service effectiveness and referral decision details.

IARS participation is mandatory for BASE I POS and SMS POS issuers and acquirers in
all regions for the processing of their international referrals. Some regions may require
members to use IARS to resolve domestic referrals as well.
IMPORTANT
All issuers and acquirers and their processors must register with Visa before participating in IARS. Members
must contact their Visa representatives to complete a member registration form.
31.4.1 Testing
Testing is optional for IARS; however, registration is mandatory for all issuer and acquirer
participants. Members can contact their Visa representatives about registration.
Issuers must be able to receive advice/response reason code 9 (also known as an

authorization source code) in Field 44.1—Response Source/Reason Code.
• Issuers that are able to process advice/response reason code 9 need to notify Visa
that they can receive it.
• If an issuer cannot process advice/response reason code 9, V.I.P. sends the default
code 4 (issuer unavailable) in the advice.
for IARS participants. Members can contact their Visa representatives to make
the arrangements.

Regions perform service monitoring. Members can contact their Visa representatives
for information.


Issuers implementing IARS must follow recommended telephone requirements, as
described in this section.
Issuers participating in IARS must:

• Offer an international direct-dial telephone number to accept calls from IARS participants
and provide this number to Visa. (Issuers can choose to offer a toll-free number.)
• Answer their calls by a live operator within 30 seconds.
• Be available to receive the call or fax, and respond with an approval or decline response
immediately upon receiving the requested information whenever the issuer or its agent

generates a referral response.
Issuers must provide their regions with information about language support and the
preferred method of communication (telephone or fax). In addition, the issuer must
establish individual V.I.P. stand-in processing (STIP) parameters for the referral service or
must accept region-specified default values.

The following messages pertain to IARS:
Request—This authorization message contains the IARS request.

STIP generates an 0100 message when the issuer is unavailable to handle an IARS
request.
Response—This message is the response to an 0100 message.

Advice—Issuers receive this advice when BASE I STIP is invoked for IARS requests.
0120: Advice—
The code in Field 38—Authorization Identification Response identifies the source of the
authorization decision. Field 44.1—Response Source/Reason code contains an 0120
advice to identify the source of the response. Advice/response reason code 9 indicates
that the advice is generated by IARS. If participating issuers are unable to receive code 9,
V.I.P. sends the default code 4 (issuer unavailable) instead.
31.6 HOW INTERNATIONAL AUTOMATED REFERRAL SERVICE (IARS) WORKS

IARS enables members to deliver real-time referral authorization decisions worldwide,
regardless of language or equipment compatibilities. The service is available 24 hours
a day, 7 days a week, and accommodates touch-tone telephones and rotary or other
pulse-generating telephones. IARS also provides translation services and currently
operates in eight languages.
Acquirers and processors worldwide can access the service by dialing a single telephone
number. An interactive Voice Response Unit (VRU) prompts acquirers to provide necessary
issuer information and then routes the call to the appropriate issuer.
If the issuer center is unavailable, the transaction can be directed to IARS stand-in
processing for the authorization or decline decision based on member-specified or regional
default parameters.
31.6.1 Currency Conversion

IARS also allows for currency conversions through the Multicurrency Service for cases in
which the acquirer and the issuer do not use the same currency.

Chapter 31 How International Automated Referral Service (IARS) Works
This service allows members to authorize and to settle transactions in any nominated
currency. The service supports authorization, clearing, and settlement processing in
selected international currencies. The converted amount is read to the issuer after the
call is bridged.
For further information about the Multicurrency Service, refer to the Multicurrency Service
chapter in this manual.
31.6.2 Translation Services

IARS provides automated scripts and referral center assistance in eight core languages:
• French • Mandarin
• German • Spanish
• Italian • U.K. English
• Japanese • U.S. English
IARS connects the acquirer and the issuer, depending on their language compatibility.
If the acquirer and the issuer have the same primary language, the VRU calls the
issuer. If connected, the VRU requests that the issuer enter tones using the telephone
keypad to signal that it is ready to be connected to the acquirer. (Calls to issuers without
tone-generating telephone systems are connected automatically once the issuer answers.)
The VRU then bridges the call between the acquirer and the issuer, allowing the issuer to
obtain the information required to make an authorization decision.
If a language match is found but it is the secondary language of either the acquirer or the
issuer, the VRU places the call to the issuer and bridges the call after verifying that both
parties are able to process the call in the selected language. Figure 31-1 illustrates the
automated language-matching scenario.
Figure 31-1 Automated Language Matching
Acquirer VRU Issuer

English German
French Italian
German Spanish
If the acquirer and the issuer share no common language but one of the parties is willing
to speak English, IARS transfers the call to the IARS Referral Center for translation

assistance. The referral center agent then bridges the call to the issuer. Figure 31-2 shows
the referral center translation service flow.
Figure 31-2 IARS Referral Center Translation Service
VRU
Acquirer Issuer
French

Japanese
Italian
English
Spanish
Referral Center
31.6.3 Equipment Compatibility

IARS bridges calls between acquirers and issuers with any combination of the following
telecommunications equipment:
• Tone-generating telephones
• Rotary or other pulse-generating telephones
If the acquirer has a tone-generating telephone system, the VRU prompts the acquirer
to enter information with the telephone keypad and then bridges the call to the issuer
(once language compatibility has been determined).
Figure 31-3 illustrates how IARS bridges a referral call for an acquirer with a tone-generating
telephone system.
Figure 31-3 Acquirer With Tone-Generating Telephone System
Acquirer VRU Issuer
If the acquirer has a pulse-generating (rotary) telephone system, the VRU transfers the
call to the IARS Referral Center. A referral center agent who speaks the acquirer's chosen

language helps complete the call. In this case, the issuer can have either a rotary or other
pulse-generating telephone or a tone-generating telephone.
Figure 31-4 illustrates how IARS bridges a referral call for an acquirer with a rotary or
pulse-generating telephone.
Figure 31-4 Acquirer With Rotary or Pulse-Generating Telephone
Acquirer VRU Issuer

Referral Center

31.7 PROCESS FLOWS

IARS processes referrals in the following manner:
1. When a merchant receives a response referral (also known as a “call” message) on a
POS terminal, the merchant calls the acquirer.
2. The acquirer confirms that the issuer or V.I.P. has generated a referral (usually by
submitting another authorization request) and contacts IARS through the IARS number
provided by the Visa regional representative.
3. IARS receives the call and through the VRU:
- Identifies itself as the Visa International Automated Referral Service in the acquirer's
selected language.

- Asks the acquirer to enter the Visa account number in question, the acquirer's BIN,
and the transaction amount using the telephone keypad. If no tones are detected,
the VRU transfers the call to the IARS Referral Center.
The agent enters the Visa account number, followed by the number sign.
EXAMPLE
4000 0075 4321 0278 #
If the acquirer's agent makes an error when inputting the account number, the agent can
push the star key and the number key (** #) and start over.
The acquirer enters its 6-digit BIN followed by the number sign.
EXAMPLE
400000 #
If the agent makes an error when inputting the BIN, the agent can push the star key
followed by the number key (** #) and start over. If no tones are detected, the VRU
transfers the call to the IARS Referral Center, which:
- Validates the account number.
- Requests the transaction amount for non-U.S. acquirers.
- Looks up the acquirer and the issuer by BIN in the IARS database to determine
language compatibility.
4. IARS establishes the appropriate connection to the issuer.
When the issuer answers, IARS directs the issuer's agent to press any key to accept the
call in the primary language of both the issuer and the acquirer.

Figure 31-5 illustrates the basic IARS process flow.
Figure 31-5 IARS Process Flow
VRU
Merchant Acquirer Issuer
Referral Center
31.8 MESSAGE FLOWS

The IARS message flow consists of the following steps:

1. The merchant initiates an 0100 authorization request to the acquirer. The acquirer
forwards the request to V.I.P. (BASE I or SMS), which sends the request to the issuer.
The issuer responds with an 0110 response containing code 01 or 02 (refer to card
issuer) in Field 39—Response Code.
NOTE
SMS acquirers send 0200 requests, which V.I.P. converts to 0100 requests for BASE I processing.
2. When the merchant calls the acquirer for referral assistance, the acquirer submits the
0100 request again. If the request response is again a referral, the acquirer contacts

IARS.
3. IARS attempts to contact the issuer. If the issuer is unavailable (the issuer does not
respond within 30 seconds, the line is busy, or after the automated call distributor (ACD)
answers the referral call, the call remains in queue for more than 30 seconds before an
agent takes the call) for a decision, IARS sends its own 0100 request for the transaction
to BASE I for an approval or decline decision.
a. If the issuer responds (field 44.1 = 5) to the IARS 0100 request with a referral
02), IARS sends a final 0100 request to BASE I. This 0100 request
(field 39 = 01 or 02
is an account verification destined for BASE I STIP. It requests a check of the
exception file to see whether or not the account number is listed in the BASE I
exception file or if the card has expired.
b. If the response to the account verification contains response code 85 (no reason
to decline) or code 00 (approved), IARS makes the final decision using its own
stand-in processing parameters. For account verification purposes, V.I.P. treats both
responses in the same manner.
c. If, however, the issuer is unavailable and BASE I STIP responds (field 44.1 = 1),
IARS bypasses the account verification request and makes the final decision using
its own stand-in processing parameters.
31.8.1 IARS Stand-In Processing

IARS uses the following operational parameters to determine issuer availability:
• A busy signal classifies the issuer as not available.
• A maximum response time of 30 seconds is allowed for the Issuer's agent or ACD to
answer referral calls. To meet this standard, issuers might have to adjust their ACD
parameters or give priority to incoming referral calls.
• After the ACD answers the referral call, the call can remain in queue for an additional
30 seconds before an agent takes the call.
If any of these parameters are not met, IARS handles the call using stand-in processing.
The following parameters are used in IARS stand-in processing, referred to in step 3:
• BIN
• Transaction amount
• Product type (such as Classic®, Premier/Gold®)
• Transaction type (cash or purchase)
Issuers can establish specific parameters based on BIN or business ID as well as by
product type. Issuers also can set different parameters for different countries. If, for
instance, an issuer has experienced high fraud rates on transactions in certain countries,

it can stipulate lower limits in those countries. IARS supports up to four such “exception
countries” for each issuer.
For cases in which issuers have established no parameters, regional default parameters
apply.
IARS stand-in processing authorizes only those transactions that meet the following tests:
• Cardholder ID verification performed, which confirms that the cardholder has presented
appropriate identification at the POS.
• Card expiration verification performed, which ensures that the card is still current.
• Transaction velocity monitoring performed, which ensures that no more than four IARS
stand-in transactions (whether for purchase or for cash) or with a cumulative value of
no more than twice the applicable IARS stand-in approval limit, are approved for the
same account within 24 hours.
When STIP processes IARS transactions, it uses merchant category code (MCC) 6010
for non-bank cash advances, and uses MCC 9700 for purchases and bank branch cash
advances.
VisaNet considers approvals generated by IARS stand-in, whether automatically through

the VRU or through an agent at the referral center, to be valid, and the issuer cannot
generate an authorization-related chargeback.
NOTE
To limit the number of referral responses, V.I.P. rejects referral responses from issuers for transactions
involving specific combinations of merchant location, issuer location, and transaction amount. For instance,
if the merchant category code is 5411 (supermarkets and grocery stores), and both the merchant and the
issuer are in the Central Europe, Middle East, and Africa (CEMEA) region (region 6), and the transaction
amount is below USD$150.00, V.I.P. rejects an issuer's referral response. Refer to Field 39—Response Code
in V.I.P. System BASE I Technical Specifications, Volume 1, for further information about which transactions
are rejected.
31.8.2 Advices
The 0120 advices generated by IARS contain advice/response reason code 9 in field 44.1
indicating that IARS provided the response. Advices generated by IARS stand-in
processing have characteristics listed in Table 31-1.
Table 31-1 IARS Referral Center Codes
Field Number Field Name Contents Notes

38 Authorization ID nnnnnR or nnnnnX n = numeric
44.1 Response 9 or 4 All IARS responses
Source/Reason Code
For further information about response source/reason codes, see V.I.P. System BASE I
Technical Specifications, Volume 1 and Volume 2.

This section lists and describes key fields related to IARS.

Field 38—Authorization Identification Response

This field appears in both BASE I and SMS messages. Field 38 contains a 6-position
alphanumeric code identifying the source of the authorization decision. When the field is
present in an 0120 STIP advice, the first five positions are derived from the retrieval
reference number, account number, date, and time. The sixth position contains either
an X (authorization decision made by the referral center) or an R to indicate the IARS
interactive VRU.

In an 0110 response, field 39 contains code 01 or 02 (refer to card issuer).

If the issuer finds no negative condition, and the account is in good standing, the issuer
returns response code 85 (no reason to decline) or code 00 (approved). For account
verification purposes, V.I.P. treats both responses in the same manner.

This field appears in BASE I and SMS messages. V.I.P. inserts this field in 0120
advices to identify the source of the response. Code 5 means the issuer was the source.
Code 9 in this field indicates that the advice was generated by IARS. Issuers that have
not successfully tested to receive code 9 instead receive code 4 (issuer unavailable for
processing) from STIP. Issuers that receive TC 48 advices through BASE II also receive
code 4 in this field.

For SMS only, this field contains a code identifying the source of the authorization
approval. Code 9029 in this field indicates that the request was responded to by IARS
stand-in processing.

For additional information about IARS, refer to the following documents:
• Visa International Automated Referral Service Planning and Implementation Guide
• Visa International Automated Referral Service User's Guide
and Volume 2


Chapter 32 Multicurrency Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
IN BRIEF 32-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-5
Decimal Positioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-5
Clearing and Settlement Currency Conversion. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .32-6
The Currency Precision Service for Acquirers. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .32-6
Multicurrency Service
The Currency Precision Service for Issuers. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .32-6
Optional Issuer Fee (OIF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-7
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
HOW MULTICURRENCY SERVICE WORKS 32-77
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
PROCESS FLOWS 32-77
Multicurrency Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-7
Processing VisaNet-Acquired MasterCard Transactions. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .32-9
Processing for Non-Participating Members. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .32-10
VisaNet BASE II Currency Rate Delivery Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-10
Currency Conversion Charge Calculation Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-10
How VisaNet Applies Buy and Sell Currency Conversion Rates to Transactions. . .32-11
Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-11
Currency Conversion Approach. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .32-12
Using USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
Using Non-USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .32-20
Classifying Transactions by Exchange Direction Type. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .32-25
Currency Precision Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-28
One Position Decimal Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .32-29
Two Position Decimal Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .32-29
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
MESSAGE FLOWS 32-30
30
Message Flows Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-31
BASE I, POS, and ATM Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-31
SMS POS Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-33

Chapter 32
SMS Visa/Plus ATM Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-40

SMS Interlink Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-48
Partial Amount Authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-61
Processing POS Balance Returns With Multiple Currencies. . . . . . . . . . . .. . . . . . . . . . . .32-62
Acquirer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-62
Issuer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-63
Message Flow Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-64
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
66
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-
70

Chapter 32 Multicurrency Service
32.1 IN BRIEF
The Multicurrency Service allows members to authorize and to settle transactions in
any nominated currency. The service supports authorization, clearing, and settlement
processing in selected international currencies.

The Multicurrency Service is available to members in all Visa regions.
The Multicurrency Service is available both to BASE I System users and to

BASE I Single Message System (SMS) users.
SMS
BASE I and SMS
Participation in the Multicurrency Service is mandatory for:

I • SMS Visa and Plus ATM issuers, except for those whose cardholder billing
currency and settlement currency are United States (U.S.) dollars.
• All non-U.S. issuers that process BASE I POS and ATM transactions,
and SMS POS and Interlink POS transactions.
Issuer
The Multicurrency Service is optional for U.S. issuers. Plus issuers must be
directly attached to VisaNet to participate.
The Multicurrency Service is available to all processors.

Participation in the Multicurrency Service is mandatory for:
• SMS Visa and Plus ATM acquirers, except for those whose settlement
A currency is U.S. dollars.
• All non-U.S. acquirers that process BASE I POS and ATM transactions,
and SMS POS and Interlink POS transactions.
Acquirer
The Multicurrency Service is optional for U.S. acquirers.
The Multicurrency Service is available to all merchants whose acquirers

participate in the service and to all processors.

The Multicurrency Service supports V.I.P. and BASE II processing for transaction amounts
up to the equivalent of USD$499,999.99. Acquirers must manually authorize larger
transactions by telephoning or telexing the issuer center.
Visa uses buy and sell rates for currency conversion. These rates are paired into:

• USD-based rates that are used when converting non-USD currencies against the U.S.
dollar.
• Cross rates (non-USD-based rates) that are used for selected currencies for which the
rates quoted are against a currency other than the U.S. dollar.
The Multicurrency Service includes the following transaction currency processing features:
Conversion—This feature automatically converts the transaction currency to the

Clearing Conversion—
cardholder's billing currency. The transaction currency is generally the currency in which
a transaction takes place. The cardholder's billing currency is usually the currency of
the country in which the account is domiciled. VisaNet supports virtually every currency
recognized by the International Organization for Standardization (ISO). Currently, there are
approximately 148 transaction currencies.
Conversion—This feature automatically converts the transaction currency to

Settlement Conversion—
the acquirer's settlement currency (if the two are different), and automatically converts the
cardholder's billing currency to the issuer's settlement currency (if the two are different),
to one of 20 settlement currencies.
Service—This feature delivers the conversion rate and provides

Currency Rate Delivery Service—
members (five days a week, Monday through Friday) with the currency conversion rates
Visa uses to process transactions.
With this feature, VisaNet calculates the optional issuer interregional and intraregional
currency conversion fees and any issuer interregional and intraregional currency conversion
fees that issuers apply to specific issuer BINs and includes them in Field 6—Amount,
Cardholder Billing. VisaNet sends the transaction to the issuer for clearing.
The Multicurrency Service offers one additional processing option.
Service—Available for SMS Multicurrency Service participants only,

Currency Precision Service—
this service uses Field 63.13—Decimal Positions Indicator to indicate how many decimal
positions are in the message amount fields. The field accommodates three different values
for transaction, settlement, and cardholder amounts. These values override the values in
the Visa Currency Table.
The Currency Precision Service is available only to SMS participants using the
Multicurrency Service. Visa card, Interlink, and Plus acquirers and issuers participating in
this service must use the V.I.P. ISO format and must have successfully completed testing.
Plus acquirers and issuers must be directly attached to VisaNet.

This section describes the participation requirements for the Multicurrency Service.
Members—Participation does not affect a U.S. member's settlement,

Impacts to U.S. Members—
which remains in U.S. dollars. Members can receive additional information about the
transactions they initiate outside the U.S. or acquire in the U.S. for a cardholder whose
billing currency is other than U.S. dollars. Participating U.S. members receive the standard
multicurrency fields in their online messages and reports. U.S. members choosing not to
participate in the Multicurrency Service do not receive the fields specific to multicurrency
in their online messages.

Participants—Issuer participants always receive multicurrency

Impacts to All Other Service Participants—
fields whether or not the currencies are the same. Acquirers receive multicurrency fields
only in responses containing code 01 or 02 (refer card to issuer).
Non-Participants—If a member chooses not to participate, it neither provides

Impacts to Non-Participants—
nor receives the unique multicurrency data fields.
For SMS members, V.I.P. sends all amounts in Field 4—Amount, Transaction in U.S.
dollars (USD).
32.4.1 Testing
Participating issuers and acquirers must have successfully completed testing that they can
process multicurrency-specific data fields in both outgoing and incoming messages.
During service implementation, issuers must specify which currency or currencies they
will support.
Multicurrency Service participants. Members can contact their Visa representatives to
Service monitoring is not applicable to the Multicurrency Service.

Members should consider the following key points when planning their implementation of
the Multicurrency Service.
32.4.3.1 Decimal Positioning

Service participants using a currency with three decimal places must configure their
systems to:
• Replace the third decimal position with zero when generating amount fields.
(This requirement does not apply to Currency Precision Service participants.) SMS
participants using the Currency Precision Service may override the number of minor units.
NOTE
BASE I and SMS obtain the transaction's minor units of currency from the currency rate file. (The contents
of the Visa International Currency Conversion Rate File (that is, rate update records or TC 56 files) are
confidential and may be used only by Visa and its authorized member financial institutions. Any other use is
strictly prohibited unless expressly authorized by Visa International.
• Receive two-place accuracy in any amount field supplied by VisaNet. (This requirement
is not applicable to V.I.P. online.)
Currencies are defined as having zero, two, or three minor units of currency. For instance,
the U.S. dollar has two minor units of currency (the two positions to the right of the decimal
point); the Japanese yen has no minor units.
VisaNet supports up to three significant decimal places in amount fields in online messages;
however, the third digit is assumed to be zero. In online transactions processed by VisaNet,
amounts have an implied decimal point preceding the rightmost zero, and they have one,
two, or three digits to handle these minor units of currency.

The following set of examples explains decimal positioning:

EXAMPLE
If the transaction amount is 3.129, it must be entered in the request as 3.130.
EXAMPLE
A numeric value of 6789 is interpreted by the Multicurrency Service as 6.789 (three minor units of currency),
67.89 (two minor units of currency), or 6789 (no minor units of currency).
32.4.3.2 Clearing and Settlement Currency Conversion

The service automatically converts member or processing center net financial positions into
any of 20 predetermined currencies supported by the International Settlement Service.
• If the local currency is one of the settlement currencies, members can choose to settle
either in the local currency or in U.S. dollars.
• If the local currency is not one of the settlement currencies, the member can choose any
supported settlement currency.
32.4.3.3 The Currency Precision Service for Acquirers

Acquirers that choose to participate in the Currency Precision Service must be able to set
the decimal positions indicator in the following transactions and receive the indicator in
corresponding responses:
• Authorizations
• Preauthorizations
• Financial requests
• Reversals
• Adjustments
• Representments
Acquirers must be able to receive the decimal positions indicator in the following messages:
• Balance inquiry responses
• Representment status advices
• Chargebacks
• Reconciliation messages
• Copy request messages
32.4.3.4 The Currency Precision Service for Issuers

Issuers participating in the Currency Precision Service must be able to set the decimal
positions indicator in partial preauthorization approval responses and in balance inquiry
responses. They must also be able to send the indicator in chargebacks and in copy
requests.
Issuers must be able to receive the decimal positions indicator in the following messages:
• Authorizations
• Financial requests
• Reversals
• Adjustments
• Representments

• Issuer status advices

• Reconciliation messages
32.4.3.5 Optional Issuer Fee (OIF)

Issuers can choose to charge an optional service assessment to the cardholder for
transactions that require currency conversion. The issuer can specify an intraregional or
interregional optional issuer service assessment, or both assessments.
The optional issuer service assessment, which may be a mark-up or rebate, is maintained
in VisaNet databases according to issuer BINs. This optional service assessment is
calculated at the time of currency conversion using the percentage rate established by the
issuer. To implement an optional issuer fee (OIF), the member must contact Visa.
All VisaNet systems that support Multicurrency Service processing use common conversion
rates.
In cross-border money transfer enhanced OCTs, the optional issuer fee (OIF) is not
deducted from the amount that the recipient receives.

Multicurrency processing is valid for the following types of messages:
• 0100: Authorization and Preauthorization Requests
• 0110: Authorization and Preauthorization Responses
• 0120: Advices
• 0200: Financial Requests
• 0210: Financial Responses
• 0220 and 0230: Financial Advices
• 0282: Representment Status Advices
• 0400: Reversal Requests
• 0420: Reversal Responses
• 0422: Chargeback Requests and Reversals and Issuer Fee Collections and
Funds Disbursements
• 0432: Chargeback Responses
• 0480: Issuer Status Advices
• 0520: Reconciliations for Visa, Interlink, and Plus
• 0600: Copy Request Messages
For more information regarding the multicurrency-specific data for these messages,
see “Key Fields Glossary” in this chapter.
32.6 HOW MULTICURRENCY SERVICE WORKS

This following sections explain the Multicurrency Service process flow. They also include
information about the currency conversion process as well as the message flows.
32.7 PROCESS FLOWS
32.7.1 Multicurrency Process Flow

The process flow for a multicurrency transaction is as follows:

1. The acquirer sends a request that indicates the transaction currency used at the point of
sale or point of service (POS).
2. V.I.P. performs standard request processing, and the clearing and settlement conversion
process. V.I.P. then routes the transaction to the issuer for further message processing.
3. The issuer sends the appropriate authorization response to V.I.P.
4. V.I.P. stores the multicurrency information and forwards the issuer's response to the
acquirer.
NOTE
V.I.P. does not send field 6 to the acquirer in the response unless the response code in field 39 is 01
or 02 (refer card to issuer).

Figure 32-1 illustrates a Multicurrency Service process flow for a transaction acquired in
U.S. dollars for an Australian cardholder.
Figure 32-1 Multicurrency Service Process Flow
The acquirer sends: V.I.P. performs standard request The issuer receives:
processing, including:
• •
Transaction currency = Original transaction amount
USD100 Clearing Conversion • Conversion fees
•
Cardholder billing currency = Obtains issuer settlement currency •
Converted transaction
AU from the BIN
amount in cardholder’s billing
Converts transaction currency to currency
cardholder billing currency
Settlement Conversion
The issuer sends a
response to V.I.P.
Obtains issuer settlement currency
from the BIN
Converts transaction currency to the
acquirer settlement currency
Conversion Charge Calculation
Uses a buy or sell rate to obtain the TADC
Uses a Visa currency conversion percentage
to obtain the currency conversion charge
Uses an optional issuer fee rate to obtain the
optional issuer fee
V.I.P. stores the Multicurrency

information and forwards the
issuer’s response to the acquirer.
32.7.1.1 Processing VisaNet-Acquired MasterCard Transactions

Multicurrency Service participants that also acquire MasterCard transactions can by default
send and receive those transactions in the acquirer’s initially defined local currency.
The field 4 amount and the field 49 currency code do not change when the V.I.P. Gateway
converts a VisaNet 0100 authorization message to the Banknet format; that is, the field 4
amount entered by the acquirer is transferred to DE 4, and the currency code entered by
the acquirer is transferred from field 49 to DE 49.

The other BASE I multicurrency fields (Field 6—Cardholder Billing Amount;

Field 10—Cardholder Billing Conversion Rate; Field 51—Cardholder Billing Currency Code)
are not included. If MasterCard returns them in the response (DE 6—Cardholder Billing
Amount; DE 10—Cardholder Billing Conversion Rate; DE 51—Cardholder Billing Currency
Code, the gateway drops them before the message is converted to VisaNet format.
To use this capability, the PCR and acquiring BIN must both be Multicurrency Service
participants. Acquirers of MasterCard transactions that do not participate in the Visa
Multicurrency Service will continue to have their currency changed to U.S. dollars before
the gateway converts the message to the Banknet format.
32.7.1.2 Processing for Non-Participating Members

Although currently Visa does not require participation in the Multicurrency Service for
issuers using U.S. dollars for their cardholder billing and settlement currencies, VisaNet
supports currency conversion for all international transactions in that:
• VisaNet does not notify service participants whether or not the non-participating members
receive the multicurrency data fields.
• Non-participating acquirers can receive the country code of the issuer in Field 20—
PAN Extended, Country Code.
• Non-participating issuers can identify the country of the acquirer from the value in
Field 19—Acquiring Institution Identification Code.

• BASE I accepts non-U.S. dollar transactions from non-participating acquirers.
BASE I converts the amounts to U.S. dollars for non-participating issuers.
• V.I.P. rejects non-U.S. dollar transactions from non-participating issuers with Reject
Code 0009—Invalid Value.
See V.I.P. System BASE I Processing Specifications and V.I.P. System International SMS
POS (Visa & Visa Electron) Processing Specifications for more information.
32.7.2 VisaNet BASE II Currency Rate Delivery Service

Five days a week (Monday through Friday), Visa obtains and verifies international currency
rates from various sources around the world. Visa uses these currency rates for that day's
financial transactions. Visa offers these rates to subscribing members as part of the
VisaNet BASE II System Currency Rate Delivery Service. The service allows processors
to choose to receive the rates with their interchange files or several hours before their
BASE II System processing cycle begins.
32.7.3 Currency Conversion Charge Calculation Process

During the BASE I System and BASE II System processing cycles, VisaNet accumulates
counts and amounts of transactions and charges.
VisaNet uses two components for the currency conversion calculation:

• A buy or sell rate to obtain the Transaction Amount in Destination Currency (TADC)
• An optional issuer service assessment rate to obtain the optional issuer service
assessment
The sum of TADC and optional issuer service assessment is carried in Field 6—Amount,
Cardholder Billing.

NOTE
V.I.P. calculates the conversion rate in Field 10—Conversion Rate, Cardholder Billing from the amounts in
field 4 and field 6 after the conversion process is completed.
32.7.4 How VisaNet Applies Buy and Sell Currency Conversion Rates to Transactions
This section describes how VisaNet applies buy and sell rates to transactions during
authorization, and during clearing and settlement.
32.7.4.1 Terminology
The new Visa currency conversion rate system involves new terminology. Table 32-1
defines the new terminology.
Table 32-1 New Rate-Related Terminology
Term Description
Base This term is associated with a currency. Within VisaNet, variable units of a base currency
are equivalent to one unit of a counter currency.
Counter This term is associated with a currency. Within VisaNet, one unit of a counter currency is
equivalent to variable units of a base currency.
Buy Rate The buy rate in VisaNet is the number of units of base currency required to buy one unit
of the counter currency.
Sell Rate The sell rate in VisaNet is the number of units of base currency received from selling
one unit of the counter currency.
USD-Based Rate Pair In this type of pair, the U.S. dollar is always the base currency and fluctuates against the
counter currency. The counter currency will be a currency other than USD.
Exchange Direction This term is used to designate the set of currency conversion processing rules that will be
applied to a transaction based on the transaction type.
Transaction Amount in This term is used to identify the submitted transaction amount in the currency that is
Destination Currency (TADC) appropriate to the destination endpoint. The TADC is included in Field 6—Amount,
Cardholder Billing and in BASE II TCRs that include positions named destination amount.
Besides the TADC, these fields may contain the optional issuer service assessment. The
optional service assessment will not be affected by these changes.
The V.I.P. amount, cardholder billing, and BASE II destination amount fields are provided
in clearing transactions to the issuer. Issuers have the discretion to increase or to
decrease the amount in these fields when billing cardholders.
In this section, standardized terminology is used for amount fields in both V.I.P. and
BASE II transactions.
Table 32-2 provides a mapping of the terminology used to the corresponding fields in
V.I.P. and BASE II.
Table 32-2 Map of Section Terminology to V.I.P. and BASE II Fields in Purchase Transactions
V.I.P. Field/Name
Article Terminology BASE I SMS BASE II TCR/Position
Source Amount Field 4—Amount Transaction Field 4—Amount, Draft Data TCR 0,
Transaction Positions 77–88

Table 32-2 Map of Section Terminology to V.I.P. and BASE II Fields in Purchase Transactions (continued)
V.I.P. Field/Name
Article Terminology BASE I SMS BASE II TCR/Position
TADC Field 6—Cardholder Billing1 Field 6—Cardholder Billing1 Draft Data TCR 0,
Positions 62–731
Settlement Amount—Source n/a Field 5—Amount, Settlement n/a
or Destination
1. In this section, only the TADC component is described and displayed in these fields. The OIF is not addressed.
32.7.4.2 Currency Conversion Approach

The following section describes how VisaNet determines the type of rate pair to use for a
transaction, and within a pair, which rate to use; buy or sell.
When converting currencies, VisaNet compares the currencies of the source amount and
the TADC to determine whether to use a USD-based or a non-USD-based rate pair.
The USD-based rates are applied to all settlement services and to all amounts, including
assessments that are displayed on daily settlement reports, except for the following
amounts that meet the conditions required to qualify for a non-USD-based rate:
• TADC
• Settlement amounts, source or destination

VisaNet applies USD-based rates to transactions when a match between the currencies in
the transaction and a corresponding non-USD-based rate pair is not found on the rate file.
IMPORTANT
The contents of the Visa International Currency Conversion Rate File (that is, rate update records or TC 56
files) are confidential and may be used only by Visa and its authorized member financial institutions. Any other
use is strictly prohibited unless expressly authorized by Visa International.
Once the rate pairing type is established, VisaNet applies the actual buy and sell rates to
the transaction based on what is happening to the counter currency. Both a buy rate and a
sell rate can be applied in the same transaction if more than one conversion is required.
The following are the basic formulas that VisaNet uses for all transactions when converting
currencies:
• When converting from the counter currency to the base currency, the formula is:
Counter currency x rate = Base currency
• When converting base currency to counter currency, the formula is:
Base currency ÷ rate = Counter currency
From these basic formulas, Visa has established sets of processing rules for each type
of transaction and has categorized them into the following exchange direction groupings:
• Buy–Sell
• Sell–Buy
VisaNet uses exchange direction processing rules for the rate pair type that is appropriate
for the transaction and for the type of conversion required when performing the currency
conversion.

32.7.4.3 Using USD-Based Rates

VisaNet uses USD-based rates to determine amounts in transactions, regardless of
transaction type, when the following conditions are met:
• Either or both the source amount or the TADC is specified in a non-USD currency.
• A non-USD-based rate pair that matches the currencies in the transaction is not on the
rate file.
VisaNet uses the source amount submitted in the transaction to calculate the TADC.
Table 32-11 shows the processing rules that are applied to determine the TADC using
USD-based rates. The information in the Exchange Direction column indicates a grouping of
transaction types to which the currency conversion processing rules will apply. For a listing
of the transaction types that map to each exchange direction, refer to the following tables:
• Table 32-17
• Table 32-18
The information in the Rule column indicates which rule was applied to a transaction in the
scenarios that follow in this section. The information in the Currency Combination column
indicates the type of conversion required.
Table 32-3 Processing Rules for USD-Based Rate Calculations
Exchange Currency
Direction From Field To Field Rule1 Combination Processing Rule
Buy–Sell Source Amount TADC DB–1 Non-USD to USD Source amount x
buy rate of source
currency
DB–2 USD to non-USD Source amount

÷ sell rate
of destination
currency
DB–3 Non-USD to same No conversion
non-USD required.
DB–4 Non-USD to other This type of
non-USD transaction
requires the
following
conversion
processes:
• Source currency
to USD: Source
amount x buy
rate of source
currency
• USD to
destination:
USD amount
÷ sell rate of
destination
currency

Table 32-3 Processing Rules for USD-Based Rate Calculations (continued)

Exchange Currency
Sell–Buy Source Amount TADC DB–5 Non-USD to USD Source amount x
sell rate of source
currency
DB–6 USD to non-USD Source amount

÷ buy rate
of destination
currency
DB–7 Non-USD to same No conversion
non-USD required.
DB–8 Non-USD to other This type of
non-USD transaction
requires the
following
conversion
processes:
• Source currency
to USD: Source
amount x sell
rate of source
currency
• USD to
destination:
USD amount
÷ buy rate
of destination
currency
1. DB = U.S. dollar-based

Figure 32-2 shows the flow of the transaction and money for original purchase transactions.
Figure 32-2 Purchase Transaction—USD-Based Currency
Purchase Transaction
USD-Based Currency
Merchant Cardholder
VisaNet
Authorization &
Source Clearing System Destination
Acquirer Issuer
Settlement System
Legend
= Transaction Flow
= Money Flow
Table 32-4 lists the USD-based rate pairings and rates that are used to calculate the TADC
in the scenarios that follow.
Table 32-4 Example of USD-Based Rates
Scenario Counter Currency Base Currency Buy Rate Sell Rate

1&2 ABC USD Buy–A Sell–A
2&3 XYZ USD Buy–B Sell–B
The following scenarios are provided to illustrate how VisaNet applies USD-based rates to
original purchase transactions to calculate the TADC. The calculated TADC only reflects

the conversion from the amount submitted in the source amount field and does not include
any assessments or charges.
Scenario 1
An original purchase transaction is submitted to VisaNet for a purchase made by a USD
cardholder at an ABC merchant. The purchase amount of the transaction is ABC 1,000.00.
The relationship between the originator of the transaction and the type of currency in the
transaction is as follows:
• Source = ABC = Counter currency
• Destination = USD = Base currency
Because the currency of the TADC is USD, only the buy rate is applied to this transaction.
VisaNet converts the source amount to the TADC using the:
• USD-based rate pairing of ABC/USD
• DB–1 rule: Non-USD to USD formula: source amount x buy rate of source currency
As applied to this transaction, the calculation is:
ABC 1,000.00
x Buy–A (Buy rate)
USD TADC
Table 32-5 shows how the USD-based rate is displayed in a currency entry segment of
the TC 56 record.
Table 32-5 Currency Entry for USD-Based Rate in TC 56 Record for Scenario 1
Counter Base Buy Scale Sell Scale

Currency Currency Factor and Factor and
Position Name Action Code Code Code Effective Date Rate Rate
Record n/a Numeric value 840 1002 Value Value
Content for currency
code ABC

Table 32-6 shows the content of the source amount and TADC fields and corresponding
currency code fields in V.I.P. original purchase and BASE II sales draft transactions. For
BASE II transactions, all positions referenced are carried in the Draft Data TCR 0 record.
Table 32-6 Populating Amount Fields in V.I.P. and BASE II Transactions for Scenario 1
Visa Performed
System Populated by Acquirer Populated by Visa Calculation
V.I.P. Field 4 000000100000 Field 6 Amount in U.S. • DB–1 rule:
dollars Non-USD to
USD: Source
Field 49 Numeric value Field 51 840
amount x buy
for currency code
rate of source
BASE II Positions 77–88 ABC
000000100000 Positions 62–73 Amount in U.S. currency
dollars - As applied
to the
transaction:
ABC
Positions 89–91 Numeric value Positions 74–76 840 1,000.00
for currency code x Buy–A =
ABC USD TADC
Scenario 2
An original purchase transaction is submitted to VisaNet for a purchase made by an XYZ
cardholder at a USD merchant. The purchase amount of the transaction is USD$400.00.
• Source = USD = Base currency
• Destination = XYZ = Counter currency
Because the currency of the source amount is USD, only the sell rate is applied to the
transaction. VisaNet converts the source amount to the TADC using the:
• USD-based rate pairing of XYZ/USD
• DB–2 rule: USD to non-USD formula: source amount ÷ sell rate of destination currency
USD 400.00
÷ Sell–B (Sell rate)
XYZ TADC

the TC 56 record.

code XYZ
VisaNet
Performed
System Populated by Acquirer Populated by VisaNet Calculation
V.I.P. Field 4 000000040000 Field 6 Amount in XYZ • DB–2 rule: USD

currency to non-USD
currency:
Field 49 840 Field 51 Numeric value
- Source
for currency code
amount ÷
XYZ
sell rate of
destination
BASE II Positions 77–88 000000040000 Positions 62–73 Amount in XYZ
currency
currency
• As applied to
Positions 89–91 840 Positions 74–76 Numeric value the transaction:
for currency code - USD
XYZ 400.00 ÷
Sell–B =
XYZ TADC
Scenario 3
An original purchase transaction is submitted to VisaNet for a purchase made by an XYZ
cardholder at an ABC merchant. The purchase amount of the transaction is ABC 1,000.00.
• Source = ABC = Counter currency
• Destination = XYZ = Counter currency
In this scenario, the source currency and the TADC are both counter currencies to the U.S.
dollar. However, the rate file does not contain a non-USD-based rate pair that matches
the currencies in the transaction, so USD-based rate pairs are used for the conversion.
Because the source currency and the TADC are in currencies other than USD, both buy
and sell rates are applied to this transaction. To convert the source amount to the TADC,
VisaNet performs two calculations converting the currencies through the U.S. dollar using
the:

• USD-based rate pairing of ABC/USD

• USD-based rate pairing of XYZ/USD
• DB–4 rule: Non-USD to other non-USD-formula:
- Source amount x buy rate of source currency
- USD amount ÷ sell rate of destination currency
As applied to this transaction, the calculations are:
ABC 1,000.00
x Buy–A (Buy rate)
USD = VisaNet interim amount
÷ Sell–B (Sell rate)
XYZ = TADC
the TC 56 record.
code ABC
n/a Numeric value 840 1002 Value Value
for currency
code XYZ

VisaNet
Performed
V.I.P. Field 4 000000100000 Field 6 Amount in XYZ • DB–4 rule:
currency Non-USD to
other non USD:
Field 49 Numeric value Field 51 Numeric value
- Source
for currency code for currency code
amount x
ABC XYZ
buy rate
of source
BASE II Positions 77–88 000000100000 Positions 62–73 Amount in XYZ
currency
currency
- USD
Positions 89–91 Numeric value Positions 74–76 Numeric value amount ÷
for currency code for currency code sell rate of
ABC XYZ destination
currency
• As applied to the
transaction:
- ABC
1,000.00
x Buy–A
= USD
amount
- USD
amount ÷
Sell–B =
XYZ TADC
32.7.4.4 Using Non-USD-Based Rates

VisaNet uses non-USD-based rates to determine the TADC in transactions, regardless
of transaction type, when the source amount and the TADC are in different non-USD
currencies and a non-USD-based rate pair exists. The base currency will be in a currency
other than U.S. dollars.
Non-USD-based rates are also used to calculate settlement amounts under the following
conditions:
• A non-USD-based rate was used to calculate the TADC.
• A non-USD-based rate exists that matches the currencies of the source amount and the
specified settlement amount, either source settlement amount or destination settlement
amount.
USD-based rates are applied to all other amounts in the transaction.
VisaNet uses the source amount submitted in the transaction to calculate the TADC.
Table 32-11 shows the processing rules that are applied to determine the TADC using
non-USD-based rates. The information in the Exchange Direction column indicates a
grouping of transaction types to which the currency conversion processing rules apply.

NOTE
For a listing of the transaction types that map to each exchange direction, refer to the following tables:
• Table 32-17
• Table 32-18
The information in the Rule column is provided to indicate which rule was applied to a
transaction in the scenarios that follow. The information in the Currency Combination
column indicates the type of conversion required.
Table 32-11 Processing Rules for USD-Based Rate Calculations
Exchange Currency
Buy–Sell Source Amount TADC NDB–1 Counter currency Source amount x
to base currency buy rate of source
currency
NDB–2 Base currency to Source amount

counter currency ÷ sell rate
of destination
currency
Sell–Buy Source Amount TADC NDB–3 Counter currency Source amount x
to base currency sell rate of source
currency
NDB–4 Base currency to Source amount
counter currency ÷ buy rate
of destination
currency
1. DB = U.S. dollar-based

Figure 32-3 shows the flow of the transaction and money for original purchase transactions.
Figure 32-3 Purchase Transaction—Non-USD-Based Currency
Purchase Transaction
Non-USD-Based Currency
Merchant Cardholder
VisaNet
Authorization &
Source Clearing System Destination
Acquirer Issuer
Settlement System
Legend
= Transaction Flow
= Money Flow
Table 32-12 lists the non-USD-based rate pairings and rates that are used to calculate the
TADC in the scenarios that follow.
Table 32-12 Example of Non-USD-Based Rates
Scenario Counter Currency Base Currency Buy Rate Sell Rate

4 XYZ MNO Buy–C Sell–C
5 MNO ABC Buy–D Sell–D
The following scenarios are provided to illustrate how VisaNet applies the non-USD-based
rates in original purchase transactions to calculate the TADC. The calculated TADC only

reflects the conversion from the amount submitted in the source amount field and does not
include any service assessments or charges.
Scenario 4
An original purchase transaction is submitted to VisaNet for a purchase made by an MNO
cardholder at an XYZ merchant. The purchase amount of the transaction is XYZ 700.00.
• Source = XYZ = Counter currency
• Destination = MNO = Counter currency
Because the currency of the TADC is the same as the base currency, only the buy rate is
applied to this transaction. VisaNet converts the source amount to the TADC using the:
• Non-USD-based rate pairing of XYZ/MNO
• NDB–1 rule: Counter currency to base currency formula: source amount x buy rate
of source currency
XYZ 700.00
x Buy–C (Buy rate)
MNO = TADC
Table 32-13 shows how the non-USD-based rate is displayed in a currency entry segment
of the TC 56 record.
Table 32-13 Currency Entry for Non-USD-Based Rate in TC 56 Record for Scenario 4

Record n/a Numeric value Numeric value 1002 Value Value
Content for currency for currency
code XYZ code MNO

VisaNet Performed
V.I.P. Field 4 000000070000 Field 6 Amount in MNO • NDB–1 rule: Counter
currency currency to base
currency
Field 49 Numeric value Field 51 Numeric value for
- Source amount x
for currency code currency code MNO
buy rate of source
XYZ
currency
• As applied to the
BASE II Positions 77–88 000000070000 Positions 62–73 Amount in MNO –
transaction:
Source amount x buy
- XYZ 700.00 x
rate of source currency
Buy–C = MNO
TADC
Positions 89–91 Numeric value Positions 74–76 Numeric value for
for currency code currency code MNO
XYZ
Scenario 5
An original purchase transaction is submitted to VisaNet for a purchase made by an MNO
cardholder at an ABC merchant. The purchase amount of the transaction is ABC 500.00.
• Source = ABC = Base currency
• Destination = MNO = Counter currency
Because the currency of the source amount is the same as the base currency, only the
sell rate is applied to the transaction. VisaNet converts the source amount to the TADC
using the:
• Non-USD-based rate pairing of MNO/ABC
• NBD–2 rule: Base currency to counter currency formula: source amount ÷ sell rate
of destination currency
ABC 500.00
÷ Sell–D (Sell rate)
MNO = TADC

Table 32-15 shows how the non-USD-based rate is displayed in a currency entry segment
of the TC 56 record.
Table 32-15 Currency Entry for Non-USD-Based Rate in TC 56 Record for Scenario 5

Record n/a Numeric value Numeric value 1002 Value Value
Content for currency for currency
code MNO code ABC
VisaNet
Performed
V.I.P. Field 4 000000050000 Field 6 Amount in MNO • NDB–2 rule:
currency Base currency
to counter
Field 49 Numeric value Field 51 Numeric value
currency:
for currency code for currency code
- Source
ABC MNO
amount ÷
sell rate of
BASE II Positions 77–88 000000050000 Positions 62–73 Amount in MNO
destination
currency
currency
Positions 89–91 Numeric value Positions 74–76 Numeric value • As applied to the
for currency code for currency code transaction:
ABC MNO - ABC 500.00
÷ Sell–D =
MNO TADC
32.7.4.5 Classifying Transactions by Exchange Direction Type

The exchange direction classification, either buy–sell or sell–buy, is used to group types
of transactions together that will use the same set of currency conversion processing
rules. All original transactions, and their chargebacks and reversals are assigned the same
exchange direction classification as shown in the following tables:
• Table 32-17
• Table 32-18
The tables also show the transaction flow and money flow as indicated using arrows as
follows:
—> = Indicates that the flow is from the acquirer to the issuer.
<— = Indicates that the flow is from the issuer to the acquirer.

<-> = Indicates that the flow can be from either:

• Acquirer to issuer
• Issuer to acquirer
Table 32-17 Buy–Sell Currency Conversion Direction by Transaction Type
Money
Processing Transaction Flow
System Type of Transactions Code Value Flow Acq–Iss Acq–Iss
V.I.P. 01xx/02xx /04xx for the following types of transactions: – —> n/a
• Authorizations
• Authorization Reversals
02xx originals and adjustments for the following types of 00, 01
00 01, 02
02, 10
10, —> <—
transactions: or 11
• Purchases
• Preauthorization Completions
• Cash Disbursements1
• ATM Debit Adjustments
• Debit Adjustments
• Quasi-Cash
04xx reversals for the following types of transactions: 00, 01

00 01, 02
02, 10
10, —> —>
• Purchases or 11
• Preauthorization Completions
• Cash Disbursements1
• ATM Debit Adjustments
• Debit Adjustments
• Quasi-Cash
0422/0432 chargebacks for the following types of transactions: 00, 01
00 01, 02
02, 10
10, <— —>
• Purchases or 11
• Cash Disbursements
NOTE:
• ATM Debit Adjustments Field 25
• Debit Adjustments must contain
• Quasi-Cash 17.
code 17
0422 chargeback reversals for the following types of 22 <— <—

transactions:
NOTE:
• Purchases Field 25
• Cash Disbursements must contain
• Debit Adjustments code 54.
• Quasi-Cash
0220/0422—Fee Collections 19 <-> <->

Table 32-17 Buy–Sell Currency Conversion Direction by Transaction Type (continued)

Money
BASE II TC 05—Sales Drafts n/a —> <—
TC 25—Sales Draft Reversals n/a —> —>
TC 15—Sales Draft Chargebacks n/a <— —>
TC 35—Sales Draft Chargeback Reversals n/a <— —>

TC 07—Cash Disbursements n/a —> <—
TC 27—Cash Disbursement Reversals n/a —> —>
TC 17—Cash Disbursement Chargebacks n/a <— —>
TC 37—Cash Disbursement Chargeback Reversals n/a <— <—
TC 10—Fee Collections n/a <-> <->
1. 6011.
For cash disbursements or ATM debit adjustments, the MCC must be 6011

Table 32-18 Sell–Buy Currency Conversion Direction by Transaction Type
Money
V.I.P. 02xx for the following types of transactions: 20, 22
20 22, or 26 —> —>
• Merchandise Returns
• Credit Adjustments
• Original Credits
• ATM Credit Adjustments1
04xx reversals for the following types of transactions: 20, 22
20 22, or 26 —> <—
• Credit Adjustments
• Original Credits
0422—Chargebacks for the following types of transactions: 20, 22
20 22, or 26 <— <—
NOTE:
• Credit Adjustments Field 25
• Original Credits must contain
• ATM Credit Adjustments1 17.
code 17
0422—Chargeback reversals for the following types of 02 or 26 <— —>

transactions:
NOTE:
• Merchandise Returns Field 25
• Credit Adjustments must contain
• Original Credits 54.
code 54
0220/0422—Funds Disbursements 29 <-> <->
BASE II TC 06—Credit Vouchers n/a —> —>
TC 26—Credit Voucher Reversals n/a —> <—
TC 16—Credit Voucher Chargebacks n/a <— <—
TC 07—Cash Disbursements n/a —> —>
NOTE:
ATM credit adjustments only that originated in SMS.
TC 27—Cash Disbursement Reversals n/a —> <—
NOTE:
ATM credit adjustments only that originated in SMS.
TC 36—Credit Voucher Chargeback Reversals n/a <— —>

TC 20—Funds Disbursements n/a <-> <->
1. 6011.
For ATM credit adjustments and their reversals, the MCC must be 6011
32.7.5 Currency Precision Service

SMS Multicurrency Service participants can participate in the Currency Precision Service,
which uses Field 63.13—Decimal Positions Indicator to indicate how many decimal

positions are in the message amount fields. Field 63.13 accommodates three different
values for transaction, settlement, and cardholder amounts. These values override the
number of minor units in the Currency Rate Table.
NOTE
For non-participants, VisaNet always uses the values in the Currency Rate Table.
32.7.5.1 One Position Decimal Adjustment

If the number of decimal positions specified in field 63.13 is less than that in the Currency
Rate Table, VisaNet adjusts the applicable amount fields.
EXAMPLE
An acquirer sends a transaction amount of 12345 with a value of 02 in positions 1 and 2 of field 63.13.
The Currency Rate Table, however, indicates that the acquirer's currency has three decimal positions.
123450.
VisaNet reports the amount as 123450 and sends the issuer a transaction amount of 123450
A participating issuer also receives a value of 03 in position 1 and position 2 of field 63.13. A non-participating
issuer receives a value of 123450 in field 4; however, the request will have no decimal positions indicator.
The acquirer receives the transaction amount 123450 and a value of 03 in positions 1 and 2 of field 63.13.
123450. All reports and raw data reflect the
The settlement amount is based on the transaction amount 123450
123450.
transaction amount 123450
The following figure shows an example of decimal position conversion for one decimal position.
Figure 32-4 Example of One-Decimal Position Conversion
Incoming Message
Currency = Pa’anga
Amount = 12345
Decimal Positions = 02
Visa Currency Table
Pa’anga Decimal Positions = 03
Amount = 123450
32.7.5.2 Two Position Decimal Adjustment

If the number of decimal positions specified in field 63.13 is greater than that in the
Currency Rate Table, the last digit (which must be zero) is removed.

EXAMPLE
An acquirer sends a transaction amount 12340 with a value of 03 in positions 1 and 2 of field 63.13.
The Currency Rate Table, however, indicates that the acquirer's currency has two decimal positions.
1234. A participating issuer also receives a value of 02 in position 1
The issuer receives the transaction amount 1234
1234; however, the request has no
and 2 of field 63.13. Non-participating issuers receive transaction amount 1234
1234. All reports and raw data reflect 1234
decimal positions indicator. The settlement amount is based on 1234 1234.
The following figure shows an example of decimal position conversion for two decimal positions.
Figure 32-5 Example of Two-Decimal Position Conversion
Incoming Message
Amount = 12340
Visa Currency Table
Pa’anga Decimal Positions = 02

Amount = 1234
32.8 MESSAGE FLOWS

VisaNet messages contain several multicurrency fields supporting the various amounts
involved in currency exchange calculation. These fields contain the following data:
• The transaction amount in the transaction currency
• The transaction amount in the cardholder billing currency
• The settlement amount
• The conversion rates
• The date of the Currency Rate Table used by V.I.P.
Participating members receive standard multicurrency fields in their online messages,
reports, and raw data.
For non-participating members, transaction and settlement amounts appear in online

messages, raw data, and reports in U.S. dollars only.
Non-participating members that migrate to the Multicurrency Service have the advantage of
using the additional information.

32.8.1 Message Flows Key

The definitions for the abbreviations used in the message flow figures for this section
include:
Field = field
Amt. = amount
Bal. = balance
Acct. = account
Trans = transaction
32.8.2 BASE I, POS, and ATM Multicurrency Message Flows

The following figures show the Multicurrency Service BASE I POS transaction message
flows:
• Figure 32-6
• Figure 32-7
Figure 32-6 illustrates the message flow for BASE I POS and ATM transactions with no
cashback requested. The acquirer sends V.I.P. the 0100 request. V.I.P. performs BASE I
processing and forwards the request to the issuer. The issuer sends an 0110 response.

NOTE
Multicurrency fields appear only for output referral responses (when field 39 contains code 01 or 02
02).
Figure 32-6 Message Flow—BASE I POS ATM Transactions, No Cashback
0100 Request BASE I Processing 0100 Request or 0120

Field 4: Transaction Amount Convert Field 4 to cardholder Advice
Field 49: Currency Code, billing amount currency, Field 4: Amount, Trans.
Trans. include conversion fees, put in Field 49: Currency Code,
Field 6: Amount, Cardholder Trans.
Billing
Field 6: Amount, Cardholder
Calculate and add Field 10: Billing

Conversion Rate, Cardholder
Field 10: Conversion Rate
Billing
Field 51: Currency Code,
Add Field 51: Currency Code,
Cardholder Billing
Cardholder Billing
0110 Response BASE I Processing 0110 Response

Field 4: Amount, Trans. Add Field 6, field 10, and Field 4: Amount, Trans.
Field 6: Amount, Cardholder field 51 Field 49: Currency Code,
Billing Trans.
Field 10: Conversion Rate
Trans.
Cardholder Billing
Figure 32-7 illustrates the message flow for a BASE I POS transaction with cashback and
an ATM partial dispense requested. The acquirer sends V.I.P. the 0100 message. V.I.P.
performs BASE I processing and forwards the request to the issuer. The issuer sends an
0110 response. For partial approval, if the original transaction amount is not present in
field 54, V.I.P. inserts the amount in field 54 and then forwards the 0110 response to the
acquirer.

NOTE
Multicurrency fields appear only for output referral responses (when field 39 contains code 01 or 02
02).
Figure 32-7 Message Flow—BASE I POS ATM Transactions, Cashback, and ATM Partial Dispenses
0100 Request BASE I Processing 0100 Request

Field 4: Amount, Trans. Convert Field 4: Amount, Trans. or 0120 Advice
Field 49: Currency Code, Trans. to Field 6: Amount, Cardholder Field 4: Amount, Trans.
Billing, include conversion fees Field 49: Currency Code, Trans.
Field 61.1: Other Amount, Trans.
(Cash Back/Actual Dispensed Add Field 10: Conversion Rate, Field 6: Amount, Cardholder
Amt.) Cardholder Billing
Billing
Add Field 51: Currency Code, Field 10: Conversion Rate,
Cardholder Billing Cardholder Billing
Add Field 61.2: Cash Back/ Field 51: Currency Code,
Actual Dispensed Amt. in Cardholder Billing
cardholder billing currency
Field 61.1: Other Amount,
Trans. (Cash Back/Actual
Dispensed Amt.)
Add Field 61.2: Cash Back Amt.
in cardholder billing currency
0110 Response BASE I Processing 0110 Response

Field 4: Amount, Trans. Add the following fields: Field 4: Amount, Trans.
Field 6: Amount, Cardholder Field 5: Amount, Settlement Field 49: Currency Code, Trans.
Billing Field 6: Amount, Cardholder Field 61.1: Other Amount,
Field 10: Conversion Rate, Billing Trans. (Cash Back/Actual
Cardholder Billing Field 10: Conversion Rate, Dispensed Amt.)
Field 49: Currency Code, Trans. Cardholder Billing
Cardholder Billing
Field 61.1: Other Amount, Trans.
(Cash Back/Actual Dispensed
Amt.)
32.8.3 SMS POS Multicurrency Message Flows

The following figures show the Multicurrency Service SMS POS transaction message flows:
• Figure 32-8
• Figure 32-9
• Figure 32-10

• Figure 32-11
• Figure 32-12
• Figure 32-13
• Figure 32-14
NOTE
Billing amounts may differ from the purchase amount because of issuer optional charges being deducted.
For more information, members can contact their Visa representatives.
Figure 32-8 illustrates the message flow for an SMS POS or Visa Electron authorization
transaction. The acquirer sends V.I.P. the 0100 request. V.I.P. performs SMS processing
and forwards the request to the issuer. The issuer sends an 0110 or 0130 response.
NOTE
An 0130 advice response does not contain field 4 or field 49.
Figure 32-8 Message Flow—SMS POS or Visa Electron Authorization

0100 Request SMS Processing 0100 Request or 0120

Field 4: Amount, Trans. Convert Field 4 to Field 6: Advice
Field 49: Currency Code, Amount, Cardholder Billing, Field 4: Amount, Trans.
Trans. include conversion fees Field 49: Currency Code,
Calculate, add Field 10: Trans.
Conversion Rate, Cardholder Field 6: Amount, Cardholder
Billing Billing
Cardholder Billing
0110 Response SMS Processing 0110 or 0130 Response

Field 4: Amount, Trans. No Multicurrency processing Field 4: Amount, Trans.
Field 49: Currency Code, Field 49: Currency Code,
Trans. Trans.
Figure 32-9 illustrates the message flow for an SMS POS or Visa Electron purchase
transaction. The acquirer sends V.I.P. the 0200 request or the 0220 advice. V.I.P. performs
SMS processing and forwards the request to the issuer. The issuer sends an 0210 or
0230 response.

NOTE
An 0230 advice does not contain field 4 or field 49.
Figure 32-9 Message Flow—SMS POS or Visa Electron Purchase
0200 Request or 0220 SMS Processing 0200 Request or 0220

Advice Convert Field 4 to Field 6: Advice
Field 4: Amount, Trans. Amount, Cardholder Billing, Field 4: Amount, Trans.
Field 49: Currency Code, include conversion fees Field 49: Currency Code, Trans.
Trans. Add Field 10: Conversion Field 6: Amount, Cardholder
Rate, Cardholder Billing
Billing
Convert Field 4 to Field 5: Field 51: Currency Code,
Settlement Amt. Cardholder Billing
Add Field 9: Conversion Rate, Field 5: Amount, Settlement
Settlement
Field 9: Conversion Rate,
Add Field 16: Date, Settlement
Conversion
Field 16: Date, Conversion
Settlement
Settlement
0210 or 0230 Response SMS Processing 0210 or 0230 Response

Field 4: Amount, Trans. If transaction qualifies for Field 4: Amount, Trans.
Field 49: Currency Code, settlement: Field 49: Currency Code, Trans.
Trans. Convert Field 4 to Field 5:
Field 5: Settlement amount Settlement Amount
Field 9: Conversion Rate, Add Field 9: Conversion Rate,
Settlement Settlement
Field 16: Date, Conversion Add Field 16: Date,
Conversion
Settlement Add Field 50: Currency Code,
Settlement
Figure 32-10 illustrates the message flow for an SMS POS adjustment transaction. The
acquirer sends V.I.P. the 0220 advice. V.I.P. performs SMS processing and forwards the
advice to the issuer. The issuer sends an 0230 response.

NOTE
Figure 32-10 Message Flow—SMS POS Adjustment
0220 Advice SMS Processing 0220 Advice

Field 4: Amount, Trans. Convert Field 4 to Field 6: Field 4: Amount, Trans.
Field 49: Currency Code, Amount, Cardholder Billing, Field 49: Currency Code, Trans.
Trans. include conversion fees Field 6: Amount, Cardholder
Field 3: Processing Code = Add Field 10: Conversion Rate, Billing
22xxxx credit adjustment Cardholder Billing Field 10: Conversion Rate,
Add Field 51: Currency Code, Cardholder Billing

Cardholder Billing
Convert Field 4 to Field 5: Cardholder Billing
Amount, Settlement
Field 5: Amount, Settlement
Add Field 9: Conversion Rate,
Add Field 16: Date, Conversion Field 16: Date, Conversion
Settlement
Settlement
0230 Response SMS Processing 0230 Response

Field 5: Amount, Settlement Add Field 5, Amount, No Multicurrency fields
Field 9: Conversion Rate, Settlement
Settlement Add Field 9: Conversion Rate,
Field 16: Date, Conversion Settlement
Field 50: Currency Code, Add Field 16: Date, Conversion
Settlement
Figure 32-11 illustrates the message flow for an SMS POS representment transaction. The

NOTE
Figure 32-11 Message Flow—SMS POS Representment

Field 4: Amount, Trans Convert Field 4 to Field 6: Field 4: Amount, Trans.
Amount, Cardholder Billing,
Field 49: Currency Code, Trans Field 49: Currency Code, Trans.
include conversion fees
Field 3: Procdessing Code = Field 6: Amount, Cardholder
22xxxx credit adjustment Billing
Cardholder Billing
Field 10: Conversion Rate.
Cardholder Billing
Cardholder Billing
Convert Field 4 to Field 5:
Cardholder Billing
Amount, Settlement
Settlement Field 9: Conversion Rate,
Settlement
Add Field 16: Date, Conversion
Settlement Field 50: Currency Code,

Settlement
Settlement
Settlement
Figure 32-12 illustrates the message flow for an SMS POS reversal transaction. The
acquirer sends V.I.P. the 0400 request or 0420 advice. V.I.P. performs SMS processing

NOTE
Figure 32-12 Message Flow—SMS POS Reversal
0400 Request or SMS Processing 0400 Request or

0420 Advice Convert Field 4 to Field 6: 0420 Advice
Field 4: Amount, Transaction Amount, Cardholder Billing, Field 4: Amount, Transaction
Add Field 10: Conversion Rate
Transaction Transaction
Add Field 51: Currency Code, Field 6: Amount, Cardholder
Cardholder Billing Billing
For reversal of 02xx settled Field 10: Conversion Rate,
transactions: Cardholder Billing
Convert Field 4 to Field 5, Field 51: Currency Code,
Amount, Settlement Cardholder Billing
Settlement
Add Field 16: Date Conversion Settlement
Add Field 50: Currency Code, Field 16: Date, Conversion
Settlement
Settlement

Field 5: Amount, Settlement For reversal of 02xx settled Field 4: Amount, Transaction
transactions:
Field 9: Conversion Rate, Field 49: Currency Code,
Settlement Add Field 5: Amount, Transaction
Settlement
Settlement
Settlement
Settlement

Under normal circumstances, the acquirer sends an 0420 request to the issuer.
Because pre-existing acquirers can also generate 0400 requests, issuers respond with
0410 messages that include field 4 and field 49.
Figure 32-13 illustrates the message flow for an SMS POS chargeback and chargeback
reversal transaction. The issuer sends V.I.P. the 0422 advice. V.I.P. performs SMS
processing and forwards the advice to the acquirer. The acquirer sends an 0432 response.
Figure 32-13 Message Flow—SMS POS Chargeback and Chargeback Reversal
Field 4: Amount, Transaction Convert Field 4 to Field 5, Field 4: Amount, Transaction
Amount, Settlement (from Field 6 in original
request/advice)
Transaction Add Field 9: Conversion Rate,
Transaction
Settlement
Settlement

No Multicurrency fields Add Field 5, Amount, Field 5: Amount, Settlement
Settlement
Add Field 9: Conversion Rate, Settlement
Settlement
Add Field 50: Currency Code, Settlement
Settlement
Figure 32-14 illustrates the message flow for an SMS POS merchandise return transaction.
The acquirer sends V.I.P. the 0200 request. V.I.P. performs SMS processing and forwards
the request to the issuer. The issuer sends an 0210 or 0230 response.

NOTE
Figure 32-14 Message Flow—SMS POS Merchandise Return

Trans. include conversion fees Field 49: Currency Code, Trans.
Add Field 10: Conversion Rate, Field 6: Amount, Cardholder
Add Field 51: Currency Code, Field 51: Currency Code,

Convert Field 4 to Field 5: Field 10: Conversion Rate,
Amount, Settlement Cardholder Billing
Settlement
Add Field 16: Date, Conversion Settlement
Settlement

Field 5: Amount, Settlement If transaction qualifies for Field 4: Amount, Trans.
Field 9: Conversion Rate, settlement: Field 49: Currency Code, Trans.
Settlement Add Field 5, Amount,
Field 50: Currency Code, Add Field 9: Conversion Rate,
Settlement
32.8.4 SMS Visa/Plus ATM Message Flows

The following figures show the Multicurrency Service ATM transaction message flows:
• Figure 32-15
• Figure 32-16
• Figure 32-17

• Figure 32-18
• Figure 32-19
• Figure 32-20
Figure 32-15 illustrates the message flow for an SMS Visa/Plus ATM cash disbursement
transaction, with balance information requested. The acquirer sends V.I.P. the
0200 request. V.I.P. performs SMS processing and forwards the request to the issuer.
The issuer sends an 0210 or 0230 response.
The issuer can send Field 54—Additional Amount in 0210 cash disbursement responses if
they do not support balance Inquiries.
Field 54 contains account balance information, including up to four different balance

amounts: account type, amount type, currency code, and sign.

NOTE
Figure 32-15 Message Flow—SMS Visa/Plus ATM Cash Disbursement With Balance Information

Add Field 10: Conversion Rate Field 6: Amount, Cardholder
Add Field 51: Currency Code, Billing
Cardholder Billing Field 51: Currency Code,

Convert Field 4 to Field 5: Cardholder Billing
Amount, Settlement Field 10: Conversion Rate
Settlement
Settlement

Trans. Convert Field 4 to Field 5, Field 54A: Additional Amount
Field 5: Amount, Settlement Amount, Settlement
Field 16: Date, Conversion Add Field 16: Date, Conversion
Field 50: Currency Code, Add Field 50: Currency Code,
Field 54A: Billing Currency Field 54B: Additional Amt.
(54C)
Field 54B: Additional Amt.
(54C) Convert Field 54A value,
subtract conversion fee(s) for
Field 54A-converted, put in
Field 54A
For service participants, SMS
converts Field 54A to
Field 54C

Figure 32-16 illustrates the message flow for an SMS Visa or Plus adjustment transaction.
The acquirer sends V.I.P. the 0220 advice. V.I.P. performs SMS processing and forwards
the advice to the issuer. The issuer sends an 0230 response.
NOTE
Figure 32-16 Message Flow—SMS Visa/Plus Adjustment
Field 3: Processing Code = Add Field 10: Conversion Rate, Billing
22xxxx credit adjustment Cardholder Billing
Cardholder Billing
Convert Field 4 to Field 5, Cardholder Billing
Amount, Settlement
Add Field 9: Conversion Rate, Field 9: Conversion Rate,
Settlement
Settlement
Settlement
Settlement

Field 5: Amount, Settlement If transaction qualifies for No Multicurrency fields
Field 9: Conversion Rate, settlement:
Settlement Add Field 5: Amount,
Settlement

Figure 32-17 illustrates the message flow for an SMS Visa/Plus representment transaction.
The acquirer sends V.I.P. the 0220 advice. V.I.P. performs SMS processing and forwards
the advice to the issuer. The issuer sends an 0230 response.
NOTE
Figure 32-17 Message Flow—SMS Visa/Plus Representment


Cardholder Billing
Cardholder Billing
Cardholder Billing
Cardholder Billing
Amount, Settlement
Settlement

Settlement
Settlement
Settlement

Figure 32-18 illustrates the message flow for an SMS Visa or Plus balance inquiry
and forwards the request to the issuer. The issuer sends an 0210 response.
Figure 32-18 Message Flow—SMS Visa/Plus Balance Inquiry
0200 Request SMS Processing 0200 Request

Field 3: Processing Code = No Multicurrency processing Field 49: Currency Code,
3020xx Trans.
Trans.

Field 54A, Bal. A: Conversion for Participants: Field 54A: Additional
Acct. type Convert Field 54A to Field 54C Amount, Bal. A:
Amt. type Convert Field 54B to Field 54D Acct. type
Bal. A currency code Amt. type
Conversion to Non-U.S.
Amt. sign (C or D) Bal. A currency code
Dollars for Nonparticipants:
Bal. A amount, issuer currency Amt. sign (C or D)
Convert Field 54A balance to
Field 54B, Bal. B: Field 54A-converted, subtract Bal. A amount, issuer currency
Acct. type conversion fee from Field 54B, Additional
Amt. type Field 54A-converted value amount, Bal. B:
Bal. B currency code
Convert Field 54B balance to Acct. type
Amt. sign (C or D) Field 54B-converted, subtract Amt. type
Bal. B amount, issuer currency conversion fee from Bal. B currency code
Field 54A, Bal. A Converted: Field 54B-converted value Amt. sign (C or D)
Acct. type Bal. B amount, issuer currency
Amt. type
Bal. A currency code
Amt. sign (C or D)
Bal. A amount, issuer currency
Field 54B, Bal. B Converted:
Acct. type
Amt. type
Amt. sign (C or D)
Bal. B amount, issuer currency
Field 54B is optional. If V.I.P. does not provide field 54B in the response, the acquirer
receives this field zero-filled and does not receive field 54B-converted. If SMS issuers do

not support balance inquiries, they can send Field 54—Additional Amount in 0210 cash
disbursement responses.
Figure 32-19 illustrates the message flow for an SMS Visa or Plus reversal transaction. The
acquirer sends V.I.P. the 0400 request or 0420 advice. V.I.P. performs SMS processing

NOTE
Some acquirers may send an 0400 request, which issuers must be able to receive. The issuer's 0410 response
contains fields 4 and 49. (An 0430 advice response does not contain these fields.)
Figure 32-19 Message Flow—SMS Visa/Plus Reversal

Transaction Add Field 10: Conversion Rate, Transaction
Cardholder Billing
Field 6: Amount, Cardholder
Add Field 51: Currency Code, Billing
Cardholder Billing
For reversal of 02xx settled Cardholder Billing
transactions:
Convert Field 4 to Field 5, Cardholder Billing
Amount, Settlement
Settlement
Add Field 16: Date Conversion
Settlement

Field 5: Amount, Settlement For reversal of 02xx settled Field 4: Amount, Transaction
transactions:
Field 9: Conversion Rate, Field 49: Currency Code,
Settlement Add Field 5: Amount, Transaction
Settlement
Settlement
Settlement
Settlement

Figure 32-20 illustrates the message flow for an SMS Visa/Plus chargeback transaction.
The issuer sends V.I.P. the 0422 advice. V.I.P. performs SMS processing and forwards the
advice to the acquirer. The acquirer sends an 0432 response.
NOTE
The issuer provides the chargeback amount in the cardholder billing currency the same way it was received in
field 6 of the original request or advice.
Figure 32-20 Message Flow—SMS Visa/Plus Chargeback


Field 4: Amount, Trans Convert Field 4 to Field 5, Field 4: Amount, Trans. (from
Amount, Settlement Field 6 in original request)
Field 49: Currency Code, Trans
Add Field 9: Conversion Rate, Field 49: Currency Code, Trans.
Settlement
Settlement
Settlement
Field 50: Currency Code

Settlement
Settlement
Settlement
32.8.5 SMS Interlink Message Flows

The following figures show the Multicurrency Service Interlink transaction message flows.

• Preauthorization (0100)
- Figure 32-21
- Figure 32-22
• Financial Transactions (0200 and 0220)
- Figure 32-23
- Figure 32-24
- Figure 32-25
- Figure 32-26
- Figure 32-27
• Reversal Transactions (0400 and 0420)
- Figure 32-28
• Chargeback (0422)
- Figure 32-29
- Figure 32-30
- Figure 32-31
Figure 32-21 illustrates the message flow for an Interlink preauthorization full approval

NOTE
An 0120 advice contains the same fields usually received by the issuer in the 0100 request. An 0130 message
does not contain field 4 or field 49 because it is an advice.
Figure 32-21 Message Flow—Interlink Preauthorization—Full Approval


Cardholder Billing

Field 4: Amount, Trans. No Multicurrency processing Field 4: Amount, Trans.
Field 49: Currency Code, Field 6: Amount, Cardholder
Trans. Billing
Field 49: Currency Code, Trans.
Figure 32-22 illustrates the message flow for an Interlink preauthorization partial approval

NOTE
Figure 32-22 Message Flow—Interlink Preauthorization—Partial Approval

Cardholder Billing

Field 4: Amount, Trans. Calculate and subtract fees Field 4: Amount, Trans.
Field 49: Currency Code, from Field 6 amount; convert Field 6: Amount, Cardholder
Trans. remaining amount to Field 4 Billing (partial approval amount)
Field 61.1: Other Amount, Return original Field 4 amount Field 39, Response code
Trans. (full amount of purchase) in (partial approval)
Field 39: Response code Field 49: Currency Code, Trans.
Trans.
Cardholder Billing
Figure 32-23 illustrates the message flow for an Interlink preauthorization completion
Preauthorization completion messages cannot include PIN data (field 52 and field 53 must
not be included); otherwise, V.I.P. rejects them.
NOTE
If the acquirer sends an 0200 preauthorization completion message, V.I.P. rejects it with Reject
0599—Consistency Error/Transaction Not Defined.
Code 0599

NOTE
Figure 32-23 Message Flow—Interlink Preauthorization Completion

Field 61.1: Other Amount, Add Field 10: Conversion Rate, Field 6: Amount, Cardholder
Trans. Cardholder Billing Billing

Convert Field 61.1 amount to Field 51: Currency Code,
Field 61.2: Other Amt., Cardholder Billing
Cardholder Billing, include
conversion fees
Trans.
Convert U.S. currency amount
Field 5: Amount Settlement
Cardholder Billing
Settlement
Settlement
Settlement
Settlement

Field 5: Amount Settlement Amount, Settlement

Figure 32-24 illustrates the message flow for an Interlink purchase transaction. The
acquirer sends V.I.P. the 0200 request. V.I.P. performs SMS processing and forwards the
request to the issuer. The issuer sends an 0210 or 0230 response.

NOTE
Figure 32-24 Message Flow—Interlink Purchase

Field 61.1: Other Amount, Add Field 10: Conversion Rate, Field 6: Amount, Cardholder
Trans. Cardholder Billing Billing

Convert Field 61.1 amount to Field 51: Currency Code,
Field 61.2: Other Amt., Cardholder Billing
conversion fees
Trans.
Convert U.S. currency amount
Cardholder Billing
Settlement
Settlement
Settlement
Settlement

Field 5: Amount Settlement Amount, Settlement
Figure 32-25 illustrates the message flow for an Interlink adjustment transaction. The

NOTE
Field 61.1 is used when the amount from the original transaction is different from the adjusted amount.
(An 0230 advice response does not contain field 4 or field 49.)
Figure 32-25 Message Flow—Interlink Adjustment

Field 61.1: Other Amount, Add Field 10: Conversion Rate, Billing
Cardholder Billing
Trans. Field 10: Conversion Rate,
Cardholder Billing Field 51: Currency Code,
Convert Field 61.1 amount to Cardholder Billing
Field 61.2: Other Amt.,
Trans.
conversion fees
Field 61.2: Other amount,
Convert Field 4 amount to cardholder billing
Settlement
Settlement
Settlement
Settlement

Field 5: Amount, Settlement Add Field 5: Amount, No Multicurrency fields
Field 9: Conversion Rate, Settlement
Field 50: Currency Code, Add Field 16: Date, Conversion
Settlement

Figure 32-26 illustrates the message flow for an Interlink representment transaction. The
Figure 32-26 Message Flow—Interlink Representment


Cardholder Billing
Cardholder Billing
Cardholder Billing
Cardholder Billing
Amount, Settlement
Settlement

Settlement
Settlement
Settlement

Figure 32-27 illustrates the message flow for an Interlink balance inquiry transaction. The
acquirer sends V.I.P. the 0200 request. V.I.P. performs SMS processing and forwards the
request to the issuer. The issuer sends an 0210 response.
Figure 32-27 Message Flow—Interlink Balance Inquiry
0200 Request SMS Processing 0200 Request

Field 49: Currency Code, Trans. No Multicurrency processing Field 49: Currency Code,
Trans.
Field 54A, Bal. A: Convert Field 54A balance Field 54A: Additional
Acct. type Field 54A-converted
Amount, Bal. A:
Amt. type Calculate conversion fee(s), Acct. type
Bal. A currency code subtract from Amt. type
Amt. sign (C or D) Field 54A-converted value Bal. A currency code
Bal. A amount, issuer currency Add Field 54A-converted Amt. sign (C or D)
Field 54B, Bal. B: Convert Field 54B balance to Bal. A amount, issuer currency
Acct. type Field 54B-converted Field 54B, Additional
Amt. type
Calculate conversion fee (or Amount, Bal. B:
fees), subtract from Acct. type
Amt. sign (C or D)
Field 54B-converted value Amt. type
Bal. B amount, issuer currency Bal. B currency code
Add Field 54B-converted
Field 54A, Bal. A Converted: Amt. sign (C or D)
Acct. type Bal. B amount, issuer currency
Amt. type
Bal. A currency code
Amt. sign (C or D)
Bal. A amount, issuer currency
Field 54B, Bal. B Converted:
Acct. type
Amt. type
Amt. sign (C or D)
Bal. B amount, issuer currency
Figure 32-28 illustrates the message flow for an Interlink reversal transaction. The acquirer
sends V.I.P. the 0400 request or 0420 advice. V.I.P. performs SMS processing and
forwards the request to the issuer. The issuer sends an 0410 or 0430 response.

NOTE
Figure 32-28 Message Flow—Interlink Reversal

Transaction Transaction
Cardholder Billing
Field 61.1: Other Amount, Field 6: Amount, Cardholder
Transaction Add Field 51: Currency Code, Billing
Cardholder Billing
Convert Field 61.1 amount to Cardholder Billing
Field 61.2 billing amount
For reversal of 02xx settled Cardholder Billing
transactions:
Convert Field 4 amount to Field Transaction
5: Amount, Settlement
Field 61.2: Cardholder Billing
Settlement Field 5: Amount, Settlement
Add Field 16: Date Conversion Field 9: Conversion Rate,

Settlement
Settlement Field 16: Date, Conversion
Settlement

Add Field 5: Amount, For reversal of 02xx settled Field 4: Amount, Transaction
Settlement transactions:
Add Field 9: Conversion Rate, Add Field 5: Amount, Transaction
Add Field 16: Date, Conversion Add Field 9: Conversion Rate,
Settlement
Settlement Add Field 16: Date, Conversion
Settlement

Under normal conditions, the acquirer sends an 0420 advice to the issuer, and the issuer
responds with an 0430 response. Some acquirers continue to use 0400 requests and
issuers need to be able to receive them. If the acquirer sends an 0400 request to the issuer,
the issuer responds with an 0410 response. However, Visa recommends 0420 advices.
Figure 32-29 illustrates the message flow for an Interlink chargeback transaction for the
full amount. The issuer sends V.I.P. the 0422 advice to the acquirer. V.I.P. performs SMS
processing and forwards the advice to the acquirer. The acquirer sends an 0432 response.
Figure 32-29 Message Flow—Interlink Chargeback—Full Amount
Field 4: Amount, Trans Convert Field 4 to Field 5, Field 4: Amount, Trans. (from
Amount, Settlement Field 6 in original request)
Field 49: Currency Code, Trans
Add Field 9: Conversion Rate, Field 49: Currency Code, Trans.
Settlement
Settlement
Settlement

Settlement
Settlement
Settlement

Figure 32-30 illustrates the message flow for an Interlink chargeback transaction for a
partial amount. The issuer sends V.I.P. the 0422 advice. V.I.P. performs SMS processing
and forwards the advice to the acquirer. The acquirer sends an 0432 response.
Figure 32-30 Message Flow—Interlink Chargeback—Partial Amount

Field 4: Amount, Transaction Convert Field 4 to settlement Field 4: Amount, Transaction
currency; put in Field 5, (billing currency)
Amount, Settlement
Transaction Field 49: Currency Code,
Add Field 9: Conversion Rate, Transaction
Field 61.1: Partial amount
Settlement
Field 61.1: Partial Amount (if
Add Field 16: Date, Conversion original transaction amount
Field 9: Conversion Rate, different than Field 4)
Settlement
Settlement
Field 16: Original Conversion
Date
Settlement

Settlement
Settlement
Add Field 50: Currency Code, Settlement
Settlement

Figure 32-31 illustrates the message flow for an Interlink merchandise credit transaction.
The acquirer sends V.I.P. the 0200 request to the issuer. V.I.P. performs SMS processing
Figure 32-31 Message Flow—Interlink Merchandise Credit

Field 4: Amount, Trans. Convert Field 4 to Field 5, Advice
Field 49: Currency Code, Amount, Settlement Field 4: Amount, Trans.
Trans. Add Field 10: Conversion Rate, Field 49: Currency Code,
Cardholder Billing Trans.
Add Field 51: Currency Code, Field 6: Amount, Cardholder
Convert Field 4 amount to Field 10: Conversion Rate,
Field 5: Amount Settlement Cardholder Billing
Add Field 50: Currency Code, Field 16: Date, Conversion
Settlement

Field 5: Amount, Settlement If transaction qualifies for Field 4: Amount, Trans.
Field 9: Conversion Rate, settlement: Field 49: Currency Code,
Settlement Add Field 5, Amount, Trans.
Settlement
32.8.6 Partial Amount Authorizations

VisaNet supports partial amount authorizations involving multicurrency processing for cards
processed as BASE I dual-message and SMS single-message transactions for all regions.
The key fields for partial approval 0110 and 0210 responses are:

• Field 4—Transaction Amount: For multicurrency issuers, this field must contain the
original amount from the request. For issuers that do not participate in the Multicurrency
Service, the field must contain the partially approved amount. The acquirer always
receives the partially approved amount in this field.
• Field 6—Cardholder Billing Amount: For multicurrency participating issuers, the request
contains field 6, which contains the field 4 amount in the cardholder billing currency.
The multicurrency participating issuer must insert the approved partial amount in field 6.
• Field 39—Response Code: Must contain code 10 for partial approvals.
• Field 49—Transaction Currency Code: Must identify the currency of the amount in field 4.
• Field 54—Additional Amounts: This field must contain amount in field 4 from the 0100
authorization or 0200 financial request. Field 54 has the capacity for six “sets” of amount
data; for instance, the field could contain the original amount in field 4 followed by an
account balance. Each set comprises position 1 through position 20; set two begins with
position 21, and so on. There is no required order of information for populating field 54
with POS services. (ATM balance inquiries still require the current defined order.) Issuers
must populate the field beginning with the first available set; for instance, position 1,
position 21, and so on. The field positions for partial approvals are:
- Positions 1–2—Account Type: Must contain code 00 00.
- Positions 3–4—Amount Type: Must contain code 57 (for original amount).
- Positions 5–7—Currency Code: Must contain the currency code from field 49.
- Position 8—Amount Sign: Must contain C (positive balance) or D (negative balance).

- Positions 9–20—Amount: Must contain the amount from field 4 in the request.
NOTE
V.I.P. drops field 54 from the response message before forwarding it to the acquirer if the acquirer does not
participate in POS balance services.
The Optional Issuer Fee (OIF) rates for partial approval card transactions involving
multicurrency processing may vary between the time a transaction is authorized and the
time it is settled. If the OIF rates between authorization and settlement differ, the settlement
amount of the transaction may not be the same as the authorized amount.
32.8.6.1 Processing POS Balance Returns With Multiple Currencies

When the cardholder billing currency is not the same as the transaction currency in an
authorization transaction and the issuer returns a balance, V.I.P. replaces the balance
amount in the cardholder billing currency with the balance amount converted to the
transaction currency.
Multicurrency Service participating issuers should first deduct the OIF from the balance
amount before sending the balance to the acquirer. V.I.P. does not deduct the OIF from
the balance amount when it converts the balance from the cardholder billing currency to
the transaction currency.
32.8.6.2 Acquirer Processing

This section summarizes the fields and values that acquirers send and receive for partial
authorization processing.
Messages—Acquirers must include code 1 (terminal accepts partial approvals) in

Request Messages—
field 60.10 in 0100 and 0200 request messages.

Messages—Acquirers know that an approval is for a partial amount when

Response Messages—
field 39 contains code 10 (partial approval) in 0110 and 0210 responses. Also, the following
values must be present in the response message:
• Field 4—Contains the approved partial amount in the transaction currency.
• Field 49—Contains the transaction currency code.
• Field 54 set—Contains the original transaction amount in the transaction currency.
32.8.6.3 Issuer Processing

This section summarizes the fields and values that issuers receive and send for partial
authorization processing.
Messages—Issuers know that a transaction is eligible for a partial authorization

Request Messages—
when field 60.10 contains code 1 in 0100 and 0200 requests. If the transaction is eligible
for a partial authorization and the issuer supports multicurrency processing, the following
values are present in the request:
• Field 4—Contains the transaction amount in the transaction currency.
• Field 6—Contains the transaction amount in the cardholder billing currency.
• Field 10—Contains the conversion factor between the transaction currency and the
cardholder billing currency.
• Field 51—Contains the cardholder billing currency code.
• Field 60.10—Contains code 1 (partial amount approval is allowed).
If the transaction is eligible for partial authorization and the issuer does not support
multicurrency processing, the following values are present in the request:
• Field 4—Contains the transaction amount in the cardholder billing currency.
• Field 60.10—Contains code 1 (partial amount approval is allowed).
Messages—Issuers indicate that they approve a partial amount by placing
Response Messages—
code 10 in field 39 in 0110 and 0210 responses. If the issuer approves a partial amount and
supports multicurrency processing, it should return the following values in the response:
• Field 4—Contains the original transaction amount in the transaction currency.
• Field 6—Contains the authorized partial amount in the cardholder billing currency.
NOTE
Field 51 is required in response messages that contain field 6.
• Field 54 set—Contains the original transaction amount in the cardholder billing currency.
If the issuer approves a partial amount and does not support multicurrency processing,
it should return the following values in the response:
• Field 4—Contains the authorized partial amount in the cardholder billing currency.
• Field 54 set—Contains the original transaction amount in the cardholder billing currency.

32.8.6.4 Message Flow Examples

The message flow examples include the processing that V.I.P. performs for multicurrency
and non-multicurrency transactions. The required V.I.P. fields, field values, and V.I.P.
processing depend on whether the:
• Issuer supports multicurrency processing.
• Acquirer’s transaction currency is the same as the issuer’s cardholder billing currency.
The examples illustrate the message flows for the following combinations of parameters:

• From an acquirer to a non-multicurrency issuer with the same currencies.

• From an acquirer to a multicurrency issuer with different currencies.
• From an acquirer to a non-multicurrency issuer with different currencies.
Figure 32-32 Acquirer and Non-Multicurrency Issuer With the Same Currency
V.I.P . P ro ces s in g Is s u er P ro ces s in g

Acq u irer P ro ces s in g
S a m e Curre nc ie s Nonm ultic urre nc y
0100/0200 Re que s t Me s s a ge
Fie ld 4 = Tra ns a ction a mount in U.S . dolla rs Fie ld 4 = Tra ns a ction a mount in U.S . dolla rs
Fie ld 49 = 840 (U.S . dolla rs) V.I.P . route s the re que s t Fie ld 49 = 840 (U.S . dolla rs)
me s s a ge to the Is s ue r.
Fie ld 60.10 = 1 (pa rtia l a uthoriza tion) Fie ld 60.10 = 1 (pa rtia l a uthoriza tion)
0110/0210 Re s pons e Me s s a ge
Fie ld 4 = Authorize d pa rtia l a mount in U.S . Ve rify tha t in Fie ld 54 S e t A the a mount = Fie ld 4 = Authorize d pa rtia l a mount in U.S .
dolla rs Fie ld 4 in the re que s t me s s a ge, a nd the dolla rs
Fie ld 39 = 10 (pa rtia l a uthoriza tion) curre ncy code = Fie ld 49 in the re que s t Fie ld 39 = 10 (pa rtia l a uthoriza tion)
Fie ld 49 = 840 (U.S . dolla rs) me s s a ge . If not, ove rla y a mount = Fie ld 49 = 840 (U.S . dolla rs)
Fie ld 54 S e t A = Tra ns a ction a mount in U.S . Fie ld 4 a nd, curre ncy code = Fie ld 49 Fie ld 54 S e t A = Tra ns a ction a mount in U.S .
dolla rs (a mount = Fie ld 4, a nd curre ncy from the re que s t me s s a ge . dolla rs (a mount = Fie ld 4, a nd curre ncy
= Fie ld 49 from the re que s t me s s a ge) = Fie ld 49 from the re que s t me s s a ge)
Figure 32-33 Acquirer and Multicurrency Issuer With Different Currencies
V.I.P . P ro ces s in g Is s u er P ro ces s in g

Acq u irer P ro ces s in g
Diffe re nt Curre nc ie s Multic urre nc y
Fie ld 4 = Tra ns a ction a mount in Add the following fie lds: Fie ld 4 = Tra ns a ction a mount in tra ns a ction
tra ns a ction curre ncy Fie ld 6 = Tra ns a ction a mount in ca rdholde r curre ncy
Fie ld 49 = Tra ns a ction curre ncy code billing curre ncy (ca lcula te d from Fie ld 6 = Tra ns a ction a mount in ca rdholde r
Fie ld 60.10 = 1 (pa rtia l a uthoriza tion) Fie ld 4, us ing Fie ld 51, plus optiona l billing curre ncy
Is s ue r curre ncy conve rs ion fe e s ) Fie ld 10 = Ca rdholde r billing conve rs ion ra te
Fie ld 10 = Ca rdholde r billing conve rs ion ra te Fie ld 49 = Tra ns a ction curre ncy code
( ra te us e d in ca lcula ting Fie ld 6) Fie ld 51 = Ca rdholde r billing curre ncy code
Fie ld 51 = Ca rdholde r billing curre ncy code Fie ld 60.10 = 1 (pa rtia l a uthoriza tion)
Fie ld 4 = Authorize d pa rtia l a mount in Conve rt Fie ld 4 = Authorize d pa rtia l a mount Fie ld 4 = Tra ns a ction a mount in tra ns a ction
tra ns a ction curre ncy in tra ns a ction curre ncy (ca lcula te d from curre ncy
Fie ld 39 = 10 (pa rtia l a uthoriza tion) Fie ld 6, le s s re ca lcula te d optiona l Is s ue r Fie ld 6 = Authorize d pa rtia l a mount in
Fie ld 49 = Tra ns a ction curre ncy code curre ncy conve rs ion fe e ba s e d on ca rdholde r billing curre ncy
Fie ld 54 S e t A = Tra ns a ction a mount in re turne d Fie ld 6, a nd Fie ld 49 in the Fie ld 39 = 10 (pa rtia l a uthoriza tion)
tra ns a ction curre ncy (a mount = Fie ld 4, re s pons e me s s a ge) Fie ld 49 = Tra ns a ction curre ncy code
a nd curre ncy = Fie ld 49 from the Ve rify tha t in Fie ld 54 S e t A the a mount = Fie ld 51 = Ca rdholde r billing curre ncy code
re que s t me s s a ge ) Fie ld 4 in the re que s t me s s a ge, a nd the Fie ld 54 S e t A = Tra ns a ction a mount in
curre ncy code = Fie ld 49 in the re que s t tra ns a ction curre ncy (a mount = Fie ld 4,
me s s a ge . If not, ove rla y a mount = a nd curre ncy = Fie ld 49 from the
Fie ld 4, a nd curre ncy code = Fie ld 49 re que s t me s s a ge )
from the re que s t me s s a ge .

Figure 32-34 Acquirer and Non-Multicurrency Issuer With Different Currencies
Acq u irer P ro ces s in g V.I.P . P ro ces s in g Is s u er P ro ces s in g

Diffe re nt Curre nc ie s Nonm ultic urre nc y
Fie ld 4 = Tra ns a ction a mount in tra ns a ction Conve rt Fie ld 4 = Tra ns a ction a mount in Fie ld 4 = Tra ns a ction a mount in U.S . dolla rs
curre ncy U .S . dolla rs (ca lcula te d from Fie ld 4 in Fie ld 49 = 840 (U.S . dolla rs)
Fie ld 49 = Tra ns a ction curre ncy code re que s t me s s a ge ) Fie ld 60.10 = 1 (pa rtia l a uthoriza tion)
Fie ld 60.10 = 1 (pa rtia l a uthoriza tion) Ove rla y Fie ld 49 = 840 (U.S . dolla rs)
Fie ld 4 = Authorize d pa rtia l a mount in Conve rt Fie ld 4 = Authorize d pa rtia l a mount Fie ld 4 = Authorize d pa rtia l a mount in U.S .
tra ns a ction curre ncy in tra ns a ction curre ncy (re ca lcula te d from dolla rs
Fie ld 39 = 10 (pa rtia l a uthoriza tion) Fie ld 4 in U.S . dolla rs us ing the curre ncy Fie ld 39 = 10 (pa rtia l a uthoriza tion)
Fie ld 49 = Tra ns a ction curre ncy code code from Fie ld 49 in the re que s t Fie ld 49 = 840 (U.S . dolla rs)
Fie ld 54 S e t A = Tra ns a ction a mount in me s s a ge from the Acquire r) Fie ld 54 S e t A = Tra ns a ction a mount in U.S .
tra ns a ction curre ncy (a mount = Fie ld 4, Ove rla y Fie ld 49 = Fie ld 49 in the re que s t dolla rs (a mount = Fie ld 4, a nd curre ncy
a nd curre ncy = Fie ld 49 from the re que s t me s s a ge from the Acquire r = Fie ld 49 in the re que s t me s s a ge
re que s t me s s a ge ) Ove rla y Fie ld 54 S e t A with a mount = from V .I.P .)
Fie ld 4, a nd curre ncy code = Fie ld 49 in
re que s t me s s a ge from the Acquire r

This section describes the key fields associated with the Multicurrency Service.

Applies to: ATM transactions
This field identifies the transaction type and balance inquiry account type.

Applies to: BASE I and SMS
This field contains the transaction amount in the acquirer's transaction currency.
Multicurrency issuers receive the transaction amount submitted by the acquirer.
Field 5—Amount, Settlement

This field contains the field 4 amount converted to the issuer's settlement currency. It
does not include the optional issuer service assessment.
Field 6—Amount, Cardholder Billing

This field contains the transaction amount (field 4 value) converted to the cardholder
billing currency. It includes the TADC and the optional issuer-specified conversion
charge.

Field 9—Conversion Rate, Settlement

This field contains the currency exchange rate used to convert the field 4 amount to
the field 5 amount.
Field 10—Conversion Rate, Cardholder Billing

Field 10 contains a calculated value that represents a factor that may be applied to the
field 4 amount to obtain the field 6 amount. It is not the rate that VisaNet actually uses
for currency conversion.
V.I.P. converts the transaction amount using the current conversion buy-sell rate for
the applicable currencies. The system applies optional issuer service assessments to
the converted field 4 amount to yield the field 6 amount.
After the conversion process, V.I.P. then calculates the conversion rate in field 10 from
the field 4 amount and the field 6 amount. The resulting field 10 value may differ from
published conversion rates because it reflects conversion charges and differences
resulting from rounding.
Field 16—Date, Conversion

This field contains the effective date of the field 4-to-field 5 currency conversion. It
appears only if field 5 is present.

Applies to: Interlink
This field contains the request's approval or decline code. Field 39 appears in partial
approvals involving multicurrency.

This field contains the code that identifies the field 4 currency and the field 61.1 currency.
Field 50—Currency Code, Settlement

This field contains the code that identifies the field 5 currency.
Field 51—Currency Code, Cardholder Billing

This field contains the code that identifies the currency in field 6 and in Field 61.2—
Other Amount, Cardholder Billing.

Field 54—Additional Amounts

Applies to: BASE I, ATM, and Interlink
Field 54 provides account balance information. It contains the following for up to four
different balance amounts:
• Account type
• Amount type
• Currency code
• Sign
The issuer provides the account balance in the cardholder's billing currency in field 54A
(required) and in 54B (optional). If the issuer does not provide a value for field 54B,
the acquirer receives it zero-filled and does not receive field 54B-converted.
V.I.P. converts the value (or values) from field 54A and 54B to the acquirer's transaction
currency and applies the value to field 54A-converted and field 54B-converted
(if applicable).
NOTE
If the converted transaction currency amount in field 54 exceeds the 12-character converted amount
limit, the converted currency amount value is 999999999999 (12 nines).
Table 32-19 lists the values for field 54.
Table 32-19 Field 54 Values
Values Supplied by the Issuer Values Sent to the Acquirer After Conversion
54A: Account Balance—Required; must be 54C-Converted Account Balance—Required;
provided in the cardholder's billing currency. must be provided in the transaction currency.
54B: Account Balance—Optional; if supplied, 54D-Converted Account Balance—If supplied,
must be provided in the cardholder's billing must be provided in the transaction currency.
currency.
Field 61.1—Other Amount, Transaction

Applies to: Interlink and Plus
Field 61.1 contains the amount of a partial ATM dispense, applicable to BASE I and
SMS. Fields 61.1 and 61.2 in the request or advice are used for the cashback amount of
a purchase transaction, if any.

Field 61.2—Other Amount, Cardholder Billing

Applies to: Interlink and Plus
This field contains the field 61.1 amount converted into the cardholder billing currency,
and is only present when field 61.1 is present. V.I.P. drops field 61.1 and field 61.3
from a Plus chargeback if the acquirer does not participate in multicurrency, or if the
chargeback relates to an ATM financial transaction. The valid values for all subfields of
field 61.2 are:
00 = Currency has no minor units
02 = Currency has two minor units
03 = Currency has three minor units
99 = Currency not applicable in this message

NOTE
No known currencies have one minor unit. However, no system restrictions or edits prohibit the use
01.
of code 01
Field 63.13—Decimal Positions Indicator
Applies to: SMS and is used only by the Currency Precision Service.
Field 63.13 is a three-part field that contains the number of decimal positions for field 4,
field 5, and field 6, if present.
Participants must be capable of sending and receiving field 63.13 in their online
messages. The user of a currency with three decimal positions must place a zero in the
last digit. If a participating member sends a 3 in one of the field 63.13 subfields and the
corresponding amount does not end in a zero, V.I.P. rejects the message for invalid
amount. The reject codes and the conditions under which they occur are as follows:
0009 = Invalid field 4
0106 = Invalid field 61.1
V.I.P. also sends reject messages if a member participating in the Currency Precision
Service fails to include field 63.13 or sends an invalid value. The reject codes are:
0468 = field 63.13 missing, and 0157 = invalid field 63.13.

Field 126.19—Dynamic Currency Conversion Indicator

This field contains a value that indicates whether the merchant performed dynamic
currency conversion (DCC). DCC occurs when a registered merchant performs currency
conversion locally, and then submits the transaction in the cardholder's billing currency.
Acquirers must provide field 126.19 in all non-ATM, authorization, and full-financial
original transactions when the merchant performs currency conversion at the point of
sale. V.I.P. logs this field, but does not send it to issuers.

For more information about the Multicurrency Service, refer to the following documents:
• BASE I Multicurrency Conversion Service VisaNet Operations Fact Sheet
• BASE II Clearing Data Codes

Chapter 33 PIN Verification Service (PVS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
IN BRIEF 33-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-5
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-6
Prerequisites for Using the PVV Method. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .33-7
Prerequisites for Using the IBM PIN Offset Method. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .33-9
Placement of Data on Track 1 of the magnetic stripe. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .33-11
Placement of Data on Track 2 of the magnetic stripe. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .33-11
MasterCard PIN Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-12
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
12
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
HOW PIN VERIFICATION SERVICE (PVS) WORKS 33-12
12
PIN Verification Value (PVV) Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-12
IBM PIN Offset Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
PIN Verification Service (PVS)

Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
Acquirer Zone and Working Key. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
Issuer Zone and Working Key. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .33-15
PIN Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-15
Triple Data Encryption Standard Requirements and Timeline. . . . . . . . . . . . . . . . . . . . . . . .33-15
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
PROCESS FLOWS 33-17
17
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
MESSAGE FLOWS 33-19
19
MasterCard PIN Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-20
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
20
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-
25


Chapter 33 PIN Verification Service (PVS)
33.1 IN BRIEF
The PIN Verification Service (PVS) is a V.I.P. service that provides fulltime or stand-in
verification of personal identification numbers (PINs) used for Visa and Plus ATM
transactions, Visa point of service (POS), Visa POS Electron, and Interlink POS
transactions, and Visa Smart Debit/Smart Credit (VSDC) transactions. A personal
identification number is a secret code that identifies a cardholder at an ATM or terminal. A
PIN serves as an electronic substitute for a cardholder's signature.
At the issuer's option, the V.I.P. System can verify PINs on behalf of the issuer center, at all
times or only when the center is unavailable. When V.I.P. verifies PINs, it intercepts all
authorization requests containing PINs, verifies the PINs, and passes the requests to
the issuers or to the V.I.P. stand-in processor (STIP), as appropriate, for authorization
processing.
NOTE
The functions that PVS performs are in addition to the basic PIN translation that V.I.P. performs on all
incoming PIN-based authorization and financial requests regardless of whether the issuer participates in PVS.
PVS is available to members in all Visa regions.

BASE I
SMS
BASE I and SMS

PVS is available both to BASE I System and to Single Message System (SMS)
users.
Participation in PVS is optional for Visa issuers, Plus issuers, Interlink issuers,
I and VSDC issuers.
NOTE:
VisaNet must perform PIN translation for Interlink issuers. However, Interlink issuers
Issuer can perform PIN verification or have VisaNet provide this service at the issuer’s
option.


When V.I.P. receives a PIN-based authorization or financial request and the issuer
participates in PVS, V.I.P. verifies the PIN and handles the request based on the
authentication results.
PINs are required for all ATM and automated dispensing machine (ADM) cash
disbursements and for an increasing number of point-of-service (POS) and
cardholder-acceptance terminal (CAT) transactions at merchant locations. Card issuers are
responsible for verifying their cardholders' PINs. Issuers or their agents can perform PIN
verification on either a permanent or a stand-in arrangement.
In addition to verifying the PIN, PVS checks to prevent trial-and-error entry of a PIN.
V.I.P. records each incorrect PIN entry and accumulates the total in the Activity File in the
Cardholder Database. Refer to Chapter 16, Cardholder Database Overview, for information
about the Activity File.
Depending on issuer service elections, if the number of unsuccessful PIN entries exceeds
the issuer-set limit, V.I.P. declines the transaction even when the correct PIN is finally
entered.
• If the PIN is correct but too many incorrect PIN entry attempts have accrued
(issuer-defined limits exceeded), STIP assigns interim response code 75 (allowable
PIN-entry tries exceeded), converts it to 0505, but forwards response code 75 in field 39
to the issuer in the 0120 advice. If the issuer returns response code 7575, V.I.P. forwards
it unchanged to the acquirer. Otherwise, STIP declines the transaction with response
code 05 in field 39 of the 0110 response to the acquirer.
• If the PIN is incorrect and the number of incorrect PIN-entry attempts is below issuer-set
limits, V.I.P. increments the retry counter by one, returns an invalid PIN response code to
the acquirer, and creates an advice for the issuer.
• If the PIN is incorrect and too many incorrect PIN-entry attempts have accrued
(issuer-defined limits exceeded), STIP assigns interim response code 75 (allowable
PIN-entry tries exceeded), converts it to 0505, but forwards response code 75 in field 39
to the issuer in the 0120 advice. If the issuer returns response code 7575, V.I.P. forwards
it unchanged to the acquirer. Otherwise, STIP declines the transaction with response
code 05 in field 39 of the 0110 response to the acquirer.
NOTE
VisaNet does not send MasterCard PIN-based ATM transactions to MasterCard issuers connected to
Banknet. However, VisaNet does send MasterCard PIN-based transactions to VisaNet-connected issuers that
participate in the PIN/No-PIN Split Routing Service or in the Visa Shortest Online Path (VSOP) Service.
Successful PIN verification results in V.I.P. removing fields 52 and 53 from the message.
If verification fails (an error is detected during the verification process), V.I.P. leaves field 52
and field 53 in the message and forwards it to the issuer.
NOTE
Fields 52 and 53 remain with the request message when the message requires PIN translation only.
Once PIN verification is complete, the issuer or STIP approves or declines the transaction
and returns a response to the acquirer. Issuers can instruct the POS or the ATM to retain
the card if the number of unsuccessful PIN-entry attempts exceeds specified limits. See

Chapter 2, V.I.P. System Fundamentals, in Volume 1, for basic information about STIP
processing.
On the issuer's behalf, PVS can optionally maintain an issuer's PIN Verification Value
(PVV) database or IBM Offset database at the VisaNet Interchange Center (VIC).
NOTE
The Pin Verification Service and the VSDC PIN Management Service are different. The VSDC PIN
Management Service allows VSDC cardholders to change or unblock their PINs. Refer to Chapter 15,
Visa Smart Debit/Smart Credit (VSDC) Service, in Volume 1, for information about this service.

Issuers can use the optional PIN Verification Service on a permanent or stand-in basis.
When VisaNet performs PIN verification for an issuer, it uses the PVS algorithm selected
by that issuer.
Verification—If an issuer's processing center cannot or does not want to verify

Fulltime PIN Verification—
PINs in incoming interchange messages, it can have PVS verify PINs fulltime. When the
issuer selects this option, V.I.P. intercepts any request containing a PIN and forwards it to
the Visa Security Module for PIN verification. V.I.P. then forwards the request to STIP for a
PIN-entry activity check.
• When the PIN is correct and PIN retry activity is below the limit, V.I.P.:
- Removes PIN-related fields from a BASE I message or zero-fills the fields in an SMS
message.
- Routes the request to the issuer or to STIP as though it did not have a PIN.
• If the PIN is incorrect or the PIN is correct but too many unsuccessful PIN-entry attempts
have occurred, V.I.P. forwards the request to STIP for a decline or pick-up response.
Verification—When an issuer prefers to verify its own PINs, it can choose
Stand-In PIN Verification—
to use STIP for backup when the issuer's processing center is not available. STIP can

perform PIN verification and check the exception file for special processing requirements.
Refer to the Cardholder Database Overview chapter in this manual, for information about
the exception file.
The issuer can also choose to have VisaNet verify PINs and forward the results, including
excessive tries, to the issuer for the approval or decline decision. If the issuer is
unavailable, STIP can approve or decline on the issuer's behalf depending on the issuer's
system parameters.
Issuers have two options for supplying PIN information. Issuers can:
• Encode the offset or PVV for a given card on that card's magnetic stripe or, for chip
cards, on the chip image. For Visa Gold® cards, PVVs are encoded both on Track 1
and on Track 2.
• Store the PVV or offset for each account in VisaNet's Cardholder Database. Refer to
“Planning and Implementation” in this chapter for information about this storage option.
In either case, the issuer's PIN Verification Keys, which are used to calculate the PVVs
or offsets, must be loaded by Visa and the member. “Planning and Implementation”
in this chapter contains guidelines for encrypting, sending, and receiving these keys.
The Payment Technology Standards Manual contains full instructions.

Refer to the Cardholder Database Overview chapter in this manual, for information about
the PIN Verification File and the Cardholder Database.

Issuers that issue PINs to cardholders must provide PIN verification capability or subscribe
to PVS. To participate in PVS, issuers must:
• Select a method for calculating PVVs or offsets.
• Create their own PIN Verification Keys for STIP verification.
NOTE
PIN verification as part of PVS is different from PIN translation. V.I.P. performs PIN translation on all incoming
PIN-based transactions; it does not matter whether the issuer participates in PVS.
If the issuer verifies its own PINs, VisaNet currently supports the following methods for
calculating encrypted PINs:
• Visa PIN Verification Value (PVV)
• IBM PIN Offset
NOTE
Under certain specific conditions, issuers can verify their own PINs using Atalla Technovations encryption
systems. Refer to the Payment Technology Standards Manual for more information.
Acquirers must use the zone encryption scheme to ensure PIN secrecy as requests pass
from acquirers through VisaNet to issuers. When V.I.P. receives a transaction containing a
PIN, V.I.P. uses the Acquirer Working Key (AWK) to decrypt the PIN. When V.I.P. transmits
the PIN to the issuer, the Visa Security Module encrypts the PIN with the Issuer Working
Key (IWK). The issuer uses the IWK to decrypt the PIN.
Each card issuer must use unique PIN Verification Keys for STIP verification. Issuers must
maintain these keys using the same principles for safekeeping as for all other encryption
keys used to provide PIN security. PIN Verification Keys must be unique and must not be
related to any other encryption key except by chance. Refer to “How PIN Verification
Service Works” in this chapter for information about key management.
33.4.1 Testing
Testing for PVS is optional; however, PINs are required in ATM and Plus transactions as
well as in POS authorization and financial requests originating from other unattended
terminals (for instance, gasoline/petrol pumps). Issuers are responsible for verifying their
cardholders' PINs.
PINs used in interchange transactions must be processed by Visa-certified hardware

security modules.

When an issuer uses PVS, V.I.P. monitors transactions containing PINs and sends the
issuer a warning message when unusual activity occurs. Unusual activity means that
one of the following two conditions exists:

• Within a certain period for a given BIN, the number of invalid PIN attempts is unusually
high.
• For BASE I processing, a large volume of automated transactions has been approved
by STIP.
In both cases, unusual activity could be the first sign of a security breach or a large-scale
attempt to defraud the issuer.
IMPORTANT
After V.I.P. discovers unusual activity on an account and sends the issuer the warning message, V.I.P.
continues to provide PVS processing on subsequent transactions for that account unless the issuer sends
V.I.P. a response code to change the status of the account.

The following Visa PIN security and encryption rules apply to interchange transactions.
NOTE
VisaNet currently supports both single-length (16-byte) cryptographic keys and double-length (32-byte)
cryptographic keys. Members can contact their Visa representatives for information about migrating from
using single-length to double-length keys.
• PINs must be encrypted when they are beyond the protection of POS terminals or
hardware security modules (for instance, ATMs and PIN pads).
• PINs, including encrypted versions, must never be logged.
• Cryptographic keys must be protected.
• Visa key management procedures must be used for Zone Control Master Keys (ZCMKs),
Issuer Working Keys (IWKs), Acquirer Working Keys (AWKs), and PIN Verification
Keys (PVKs).
• PVS participants must use either the Visa PVV or IBM PIN Offset verification method.
For a more detailed overview of PIN processing, refer to the V.I.P. System Overview.

Refer to the Payment Technology Standards Manual for complete information about PIN
processing requirements and standards. Refer also to the Dynamic Key Exchange (DKE)
Service chapter in this manual, for information about that service, which enables issuers
to exchange some keys online.
33.4.3.1 Prerequisites for Using the PVV Method

The following are prerequisites for using the PIN Verification Value (PVV) method of PIN
verification under the PIN Verification Service.
Prerequisites—Acquirers must generate at least one AWK or instruct Visa to

Acquirer Prerequisites—
create AWKs on their behalf. Acquirers can create two AWKs to enable them to more
quickly change working keys. Acquirers must generate the keys in a random process in a
physically secure machine using all required security precautions.
Acquirers must only use AWKs to provide cryptographic security between the acquirer
and Visa. When an acquirer stores an AWK outside a physically secure machine, it must
encrypt the AWK using a master key.
Acquirers can send the keys to Visa through the mail, encrypted under the ZCMK.

Prerequisites—Issuers must generate at least one IWK or instruct Visa to create

Issuer Prerequisites—
IWKs on their behalf. Issuers can create two IWKs to enable them to more quickly change
working keys. Visa recommends that issuers generate the keys in a random process in a
physically secure machine using all security precautions.
Issuers must create at least one pair of PIN Verification Keys (a PVK pair) and convey
those keys to Visa. Issuers can create up to six pairs. At the issuer's request, V.I.P. can
create these keys.
Issuers can send the keys to Visa through the mail, encrypted under the ZCMK.
Issuers that generate PVVs must follow the steps in Figure 33-1.
Visa must have access to the issuer-generated PVVs at the VIC. An issuer provides PVVs
in either or both of the following ways:
• The issuer encodes PVVs and related PIN Verification Key Indexes (PVKIs) in the
magnetic stripe or on the chip image as specified in the Payment Technology Standards
Manual.
• The issuer stores PVVs and related PVKIs in the PIN Verification File located at the VIC.
Refer to the Cardholder Database Overview chapter in this manual , for information
about this file.
For PVVs, the PVKI is a 1-digit value that points to a pair of PIN Verification Keys stored
at the VIC. These keys are the same as those used by the issuer to generate the PVV in
the record. Because the issuer can store up to six pairs of PIN Verification Keys at the
VIC, the PVKI can be any value between 1 and 6. If the issuer uses the IBM PIN Offset
method, the issuer does not use the PVKI.
NOTE
Members should use the PVKI only for transactions using the PVV verification method. If transactions use the
IBM Offset method, V.I.P. does not check the PVKI to verify the PIN.
A PVKI of 0 indicates that the PIN cannot be verified through PVS. If the issuer uses
PVS for a specific account range and an individual card has a PVKI of 0, V.I.P. declines
transactions with PINs for that card.
If PVVs and PVKIs appear both in the magnetic stripe or chip image and in the PIN
Verification File, the data in the PIN Verification File overrides the data in the magnetic
stripe or chip image.
IMPORTANT
Visa requires that the issuer not use the same verification keys for the PVV that it uses for the Card
Verification Value (CVV) with the Card Verification Value Service. If the common keys were compromised,
it would affect both the issuer's PVVs and CVVs.
Refer to the Card Verification Value (CVV) Service chapter in this manual for information
about this service.

Figure 33-1 illustrates the PVV generation process. This process occurs within a secure
environment outside VisaNet. Members convey the keys using a security module.
Figure 33-1 Overview of PVV Generation
Rightmost 11 digits of account number

(excluding the modulus-10 check digit) PVKI First 4 digits of PIN
12345678901 3 3872
DES Encrypt
With Key A
Cipher Text A
DES Decrypt
With Key B
Cipher Text B
DES Encrypt
With Key A

Cipher Text C
Decimalization
0963
Secure Environment
33.4.3.2 Prerequisites for Using the IBM PIN Offset Method

The following are prerequisites for using the IBM PIN Offset method of PIN verification
with the PIN Verification Service.
If the issuer chooses to have V.I.P. verify all or some of its PINs using the IBM PIN Offset
method, it must supply Visa with the following data elements:

• Account number length

• Number of account number digits to be used in the verification process
• Displacement of the digits
NOTE
V.I.P. uses the data elements (above) to build a block of verification data from the request message.
• Location of the specified digits in the account number

The displacement is calculated from the beginning of the account number field.
12), V.I.P.
For instance, if the displacement is 4 (and the account number length is 12
16.
selects digits 5 through 16
• Hexadecimal pad character (zero through F)
• Character to be used to pad the account number length to 16 digits, if fewer than 16
are specified
Further, the issuer must place the offsets in the magnetic stripe or on the chip image of
its cards or maintain them in the PIN Verification File at the VIC. Refer to the Cardholder
Database Overview chapter in this manual, for information about this file.

Figure 33-2 illustrates the IBM PIN Offset verification method.
Figure 33-2 Example of IBM PIN Offset Method of PIN Verification
Authorization or Financial Request

Account Number Offset Value
4839 1234 5678 9010 4708
System Globals Clear PIN

from Step 1
PVK Pairs
3589
Length: 12
Displacement: 4 Extract
Pad Character: F
1234 5678 9019 FFFF

Padded Data
PIN Key DES DES

Decrypt Encrypt
9881 337C 1730 9202

Encrypted Data
Decimalization Table
Decimalization
0123456789012345
9881 3372 1730 9202

Decimalized Data
PIN Length: 4 9881
“Natural” PIN

Check Length: 4 9881 + 4708
Match
3589 ?
PIN Check Number
Visa Security Module
33.4.3.3 Placement of Data on Track 1 of the magnetic stripe

Issuers encode the PIN data in Field 9—PIN Verification on Track 1:
• The PVKI in position 1
• The PVV in positions 2, 3, 4, and 5
33.4.3.4 Placement of Data on Track 2 of the magnetic stripe

Participation in PVS affects the placement of data on the magnetic stripe. The location of
the PVV affects the location of the Card Verification Value (CVV). Issuers can place the
CVV anywhere in the discretionary data field of Track 2. If an acquirer participates in PVS,
however, both the PVV and the CVV must be positioned in the discretionary data field.

Refer to Chapter 2, V.I.P. System Fundamentals, in Volume 1 for information about PIN
encryption. Refer to the Card Verification Value (CVV) Service chapter in this manual,
for more information about CVV placement and the influence of PVS. Refer to the Dynamic
Key Exchange (DKE) Service chapter in this manual, for details on this optional service that
enables members to manage some keys online.
33.4.4 MasterCard PIN Verification

PVS supports MasterCard PIN transactions. PVS works without changes to MasterCard
BINs that supply Visa with their encryption keys. Field 32—Acquiring Institution
Identification Code must indicate the acquirer associated with the Acquirer Working Key
(AWK) used to encrypt the PIN.

The following messages pertain to the PIN Verification Service.
Request—These messages
0100: Authorization, Balance Inquiry, or Preauthorization Request—
support several functions related to authorization and verification of cards or customer
transactions. V.I.P. checks the account activity in the activity file and also checks the
account number in the 0100 request message to determine if the account is listed in the
exception file.
Response—This message is the authorization, balance inquiry,

or preauthorization response message.
Advice—This advice notifies issuers that V.I.P. performed PIN verification,

0120: Advice—
authorization, or both, on their behalf.
0200: Purchase Transaction or ATM Cash Disbursement Request—

Request—These messages
support various financial, purchase, and cash transactions, which must receive concurrent
authorization and clearing. V.I.P. checks the account activity in the activity file and also
checks the account number in the 0200 request message to determine if the account is
listed in the exception file.
Response—This message is the response to an 0200 or

0201 financial transaction request.
33.6 HOW PIN VERIFICATION SERVICE (PVS) WORKS

PIN verification authenticates the user of a card. Issuers or V.I.P. use an algorithm to
verify the PIN the customer enters. The Visa Security Module, a secure hardware device
specifically designed to protect PINs, verifies PINs.
If V.I.P. verifies the PINs, it first checks the PVVs or IBM Offsets in the PIN Verification File
in the Cardholder Database. If they are not in the file, V.I.P. checks the magnetic stripe or
the chip image for the PIN data. For PVS participants, V.I.P. also checks the account activity
in the Activity File and checks the account number to determine if the account is listed in
the Exception File. These files reside in the Cardholder Database. Refer to the Cardholder
Database Overview chapter in this manual, for information about the database and its files.
33.6.1 PIN Verification Value (PVV) Method

The PVV method of PIN verification is a mathematical transformation of the account
number and PIN performed by a Data Encryption Standard (DES) algorithm. In addition

Chapter 33 How PIN Verification Service (PVS) Works
to using the account number and the cardholder PIN, the algorithm incorporates a PIN
Verification Key Index (PVKI) value and a pair of PIN Verification Key (PVK) values. Issuers
store the PVV (plus its 1-digit PVKI that appears on the card's magnetic stripe or chip
image) in a PIN database at the VIC, or within their systems. This stored PVV is called the
reference PVV for comparison purposes.
To verify a cardholder's PIN entry, the issuer or V.I.P. generates a transaction PVV using:
• The encrypted PIN entered at the terminal by the cardholder.
• A portion of the primary account number.
• The past PVKI.
V.I.P. compares the reference PVV to the transaction PVV using a validation process that
occurs in a physically secure, dedicated hardware security module. If the transaction PVV
and the reference PVV match, the PIN and the cardholder are considered validated.
33.6.2 IBM PIN Offset Method

The IBM PIN Offset verification method involves a special value that represents the
difference between the combination of the account number, a PIN key, and other data.
Some of the data used to calculate the value is located on the magnetic stripe or in the chip
image and some is located in the Cardholder Database or at the issuer's processing center.
The calculated value is compared with the PIN selected by the cardholder. For more
information about the IBM PIN Offset method, refer to the IBM 3624 Consumer Transaction
Facility Programmer's Reference and Component Descriptions manual. Contact IBM for a
copy of this manual or for more information.
33.6.3 Key Management

VisaNet uses the zone encryption scheme to ensure PIN secrecy as requests pass from
acquirers to VisaNet and to issuers.
PIN processing in a DES-based zone encryption scheme is characterized by two zones:

an acquirer zone and an issuer zone. V.I.P. is a participant in each of these zones and
functions as a cryptographic intermediary.

Figure 33-3 shows a typical PIN-based authorization request using the PVV scheme
traveling from the cardholder and acquirer through VisaNet to the issuer. It illustrates
encryption working key management zones.
Figure 33-3 Encryption Zones
VisaNet’s Encryption Zones
Acquirer VIC Issuer

First Second Third
POS Device Encryption: Encryption: Encryption: PIN
53412 25132 31254 verified by
hardware
module
Cardholder
PIN: 12345 Device-Acquirer AWK IWK
Key
ATM
Acquirer’s Zone Issuer’s Zone
As illustrated in Figure 33-4, the zone encryption scheme uses pairs of zone working keys
in the key replacement process: one pair for the acquirer-VIC connection, and another
pair for the VIC-issuer connection.
Figure 33-4 Zone Encryption Key Pairs

Acquirer VIC Issuer

Acquirer-Visa Encryption Zone Issuer-Visa Encryption Zone
PIN PIN
PIN Encrypted Under AWK PIN Encrypted Under IWK

PIN Verification
33.6.3.1 Acquirer Zone and Working Key

The acquirer zone begins at the point of PIN entry and provides an avenue through which
acquirers send enciphered PINs to VisaNet. Customers enter their PINs at qualified
PIN-entry devices, which encipher the PINs for transmission to the acquirers' central

processing centers. Acquirers translate the PINs from encipherment under their PIN
device's unique key to encipherment under an AWK shared with Visa. Acquirers then send
the PINs, which are now enciphered under the AWK, to VisaNet.
33.6.3.2 Issuer Zone and Working Key

The issuer zone begins at the VIC and ends at the issuer center's host computer system.
When sending a PIN to the issuer center, V.I.P. encrypts it using an IWK that is known only
to V.I.P. and the issuer center. Like an AWK, issuers and V.I.P. store the IWK securely to
protect it from disclosure.
If the IWK is disclosed, PINs encrypted with that IWK are at risk, but the security of other
issuer keys is unaffected.
33.6.3.3 PIN Translation

Under VisaNet zone encryption, the VIC is located in both the acquirer and issuer zones.
When the VIC receives a PIN request, V.I.P. determines where the PIN is to be verified and
whether the request is destined for the issuer or for STIP for authorization. If the request
is destined for the issuer and the issuer does not use PVS for all PINs, V.I.P. acts as an
intermediary by performing PIN translation.
PIN translation can be either a one- or two-step process that involves:

1. Changing the key under which the PIN is encrypted (that is, from the AWK to the IWK).
2. If necessary, changing the format of the PIN block from the acquirer center's format to
the issuer center's format.
All PIN translation is performed in the Visa Security Module.
33.6.4 Triple Data Encryption Standard Requirements and Timeline

Visa has incorporated the industry-standard Triple Data Encryption Standard (TDES)
throughout VisaNet and its members' systems. TDES is based on the Data Encryption
Algorithm (DEA) that uses at minimum double-length keys to provide a significant increase

in security for PIN-based transactions. VisaNet, Plus, Interlink, and the Visa Debit
Processing Service (DPS) currently support TDES host-to-host working key relationships.
This mandated change applies to all PIN-based Visa, Interlink, and Plus transactions.
Visa members and member processors began moving to TDES in October 2005.
The migration included important milestones for each region.
Table 33-1 Triple Data Encryption Migration Dates
Region Milestone Objective No Later Than…

All regions All newly deployed ATMs, including replacements, must 1 January 2003
support1 TDES.
All newly deployed point-of-service (POS) PIN acceptance 1 January 2004
devices, including replacements, must support1 TDES.
All cardholder PINs must be TDES-encrypted from all 1 July 2010
point-of-transaction devices to the issuer (end-to-end).
However, each Visa region’s TDES dates supersede the global
TDES date when the Visa region date precedes the global date.

Table 33-1 Triple Data Encryption Migration Dates (continued)

Region Milestone Objective No Later Than…
Asia-Pacific Issuers must be able to receive and process TDES 1 July 2007
transactions.
All ATMs must support1 TDES.
All PIN-based POS acceptance devices must support1 TDES.
All transactions initiated at TDES-capable devices must be
TDES-encrypted from the point of acceptance to VisaNet and
V.I.P.
Visa Canada All ATMs must be TDES-capable. 1 July 2010
All online PIN-based transactions initiated at ATMs must be
TDES-encrypted end-to-end using double-length keys.
Central Europe, Middle All PIN transactions must be TDES-encrypted from point of 1 January 2006
East, and Africa acceptance (where the card is initiating the transaction) to
(CEMEA) VisaNet and V.I.P.
All PIN transactions between VisaNet and issuers must be
TDES-encrypted.
• A non-compliance grace period is in place until 1 July 2007,
at which time all CEMEA members must be fully compliant
with the regional TDES requirements.
• A non-compliance fee structure specific to TDES migration
will be introduced and rigidly enforced by the end of the
grace period. (Non-compliance fee details will be announced
at a later date.)
Visa Europe All transactions passed host-to-host (including processor 31 December 2003
systems) should be TDES-encrypted (not a mandate but a
Visa recommendation); furthermore, all TDES device-initiated
transactions must be TDES-encrypted from that point to
VisaNet.
All ATMs should support TDES (not a mandate but a Visa 1 April 2005
recommendation).
All POS PIN acceptance devices should support TDES (not a
mandate but a Visa recommendation).
Latin America and Cardholder PINs must be TDES-encrypted from all 1 July 2010
Caribbean (LAC) point-of-transaction devices to the issuer.
Visa U.S.A. All new VisaNet, Interlink, Debit Processing Service (DPS), 1 October 2005
and Plus endpoints must be installed with TDES issuer working
keys (IWKs), acquirer working keys (AWKs), or both.
All VisaNet, Interlink, DPS, and Plus endpoint IWKs, AWKs, or 31 December 2007
both must use TDES.
All transactions originating at ATMs must contain encrypted
PINs using TDES from the point of transaction to the issuer
(end-to-end).
All transactions originating at POS PIN-entry devices (PEDs) 1 July 2010
must contain encrypted PINs using TDES from the point of
transaction to the issuer (end-to-end).
1. “Must support” means the device has all the necessary TDES hardware and software and requires only loading a TDES key.

33.7 PROCESS FLOWS

Figure 33-5 illustrates the flow of a PIN-based message, using either the Visa PVV method
or the IBM PIN Offset method of PIN verification.
PVS performs PIN verification tasks using:

• DES working keys created by the issuer or by the acquirer.
• DES master keys created by V.I.P.
PVS uses the working keys (AWKs and IWKs) to decrypt and to encrypt PINs. These
working keys are themselves encrypted until they are used. V.I.P. creates master keys to
protect working keys while the AWKs or IWKs are transmitted through VisaNet.
Figure 33-5 PVS Process Flow
V.I.P.
Acquirer Issuer
PIN
Verification
File
The acquirer sends V.I.P. a V.I.P. verifies the PIN and The issuer receives the
request with an encrypted sends the request to the request.
PIN. issuer.

For PVS participants, STIP continues PIN processing after the PIN is decrypted and verified
by V.I.P. If a PIN is invalid, STIP checks to determine if the limit for unsuccessful PIN-entry
attempts has been exceeded. STIP maintains a count of consecutive unsuccessful
PIN-entry attempts made on the current day for a given account number.
STIP performs processing based on the current unsuccessful PIN-entry attempt count,
as described below.

• The count (not including the current attempt) does not exceed the limit:
- If the PIN is valid, STIP clears the count to zero.
- If the PIN is invalid, STIP increases the count by one. STIP then compares the updated
count to the limit. If the updated count now exceeds the limit, STIP updates the
count and assigns the interim response code 75 (allowable number of PIN entry tries
exceeded) to the request. STIP changes the code 75 to code 05 but sends the issuer
code 75 in the 0120 advice to clarify the reason for the decline.
• STIP then checks the exception file for a negative code. If STIP does not find a
negative code, and if the issuer has not sent an 0110 response with code 75 in
field 39, STIP declines the transaction using response code 05 in the response to
the acquirer.
• The count (not including the current attempt) exceeds the limit:
- STIP assigns response code 75 (allowable number of PIN entry tries exceeded) and
does not update the count.
- Once a count exceeds the limit, STIP continues to assign response code 75 to all
subsequent requests for the rest of the day. The cardholder is not able to complete any
more transactions requiring a PIN for the rest of the day. The cardholder can retry the
next day after STIP clears PIN counts at the end of the current day.
Issuers control PIN-retry activity by selecting the limit for the number of consecutive
unsuccessful PIN-entries attempts allowed in a day. Refer to V.I.P. System BASE I
Processing Specifications, V.I.P. System International SMS ATM Processing Specifications,
and V.I.P. System International SMS POS (Visa & Visa Electron) Processing Specifications
for more information about STIP processing and how PIN attempts accumulate in the
activity file. Refer also to the V.I.P. System Overview for an overview of STIP processing.
IMPORTANT
For Visa transactions, V.I.P. declines the transaction but does not request card pick-up. Some members,
however, have reciprocal agreements to pick-up the cards after the specified number of unsuccessful
PIN-entry attempts has occurred.

33.8 MESSAGE FLOWS

Figure 33-6 illustrates the PVS message flow.
Figure 33-6 PVS Message Flow
PIN
Verification
File

Field 22—Point-of-Service Field 22—Point-of-Service Field 22—Point-of-Service
Entry Mode Code Entry Mode Code Entry Mode Code
Field 25—Point-of-Service Field 25—Point-of-Service Field 25—Point-of-Service
Condition Code Condition Code Condition Code
Field 26—Point-of-Service PIN Field 26—Point-of-Service PIN Field 26—Point-of-Service PIN
Capture Code Capture Code Capture Code
Field 35—Track 2 Data Field 35—Track 2 Data Field 35—Track 2 Data
Field 45—Track 1 Data Field 45—Track 1 Data Field 45—Track 1 Data
Field 52—Personal Field 52—Personal Field 39—Response Code
Identification Number (PIN) Identification Number (PIN)
Data Data
Field 53—Security-Related Field 53—Security-Related
Control Information Control Information

0110 Response 0110 Response 0110 or 0210 Response
Field 39—Response Code = Field 39—Response Code = Field 39—Response Code =
00, 55, or 81 00, 55, or 81 00, 55, or 81

Field 63.4—STIP/Switch Field 63.4—STIP/Switch
Reason Code Reason Code
NOTE
VisaNet always forwards field 52 and field 53 to available issuers when PINs are translated (decrypted).
VisaNet also forwards the two PIN fields when unsuccessful PIN verifications occur. V.I.P. drops field 52 and
field 53 from request messages when PIN verifications are successful.

33.8.1 MasterCard PIN Processing in Malaysia

In Malaysia, PVS is available for MasterCard PIN-based POS transactions. Transactions
have to be domestic (the merchant, the acquirer, and the issuer are all in the same country)
dual message POS transactions; ATM cash disbursement transactions are not allowed,
nor are MasterCard chip transactions. Participating issuers must be directly connected to
VisaNet so they can receive their transactions through VisaNet. They can choose to use
PVS on a fulltime basis for issuer-available as well as issuer-unavailable requests, or only
during issuer-unavailable stand-in processing. Participating members must supply Visa
with the necessary encryption keys, and testing is required.

This section describes key fields used in PVS processing.

Field 22 contains a series of codes that identify the following for transactions processed
through VisaNet:
• When a terminal is used.
• The method used to capture the account number and the expiration date.
• The PIN capture capability of the terminal.
This field is fixed length with three subfields.
Positions:
1–2 3 4
PAN and date entry mode PIN-entry capability Fill
Mode—This subfield contains a 2-digit code

Positions 1 and 2, PAN and Date Entry Mode—
that identifies the method used to enter the cardholder account number and the card
expiration date. This code specifies whether the entire magnetic stripe is included
in an authorization or financial request.
A value of 90 or 91 in positions 1 and 2 indicates that the acquirer has included the
complete, unaltered magnetic stripe contents in the message. For reversals, V.I.P.
accepts a value of 90 in field 22 but does not require the magnetic stripe content.
91,
V.I.P. rejects authorization requests with code 0142 if the value in field 22 is 90 or 91
but no magnetic stripe data appears in field 35 or in field 45.
90, but the

V.I.P. rejects authorization requests with code 0019 if the value in field 22 is 90
acquirer has not successfully completed testing to transmit a value of 90 90.
If issuers have not successfully complted testing for PVS participation, V.I.P. replaces a
value of 90 submitted by a participating acquirer with a value of 02 before it forwards
the request to available issuers.
Capability—This subfield contains a 1-digit code that identifies the

Position 3, PlN Entry Capability—
capability of the terminal to capture PINs. This code does not necessarily mean that a
PIN was entered or that it is included in the message.
EXAMPLE

Using a value of 1 does not imply the presence of a PIN in the message. If the value is 2 or 8, however, it
is reasonable to assume that a PIN is not present.
IMPORTANT
If a BASE I 0100 authorization or balance inquiry message contains the value 2 and field 52 is present,
BASE I rejects the message with reject reason code 0592 (field present when not allowed).
A value of 1 (PIN entry supported) in position 3 indicates an ADM or ATM with PIN-entry
capability. A value of 2 (PIN entry not supported) identifies a self-service terminal.
(Unused)—This 1-digit subfield is zero-filled. This requirement is an

Position 4, Fill (Unused)—
exception to the general rule of using a leading zero to fill a field.
The coding in this field relates to position 2 of Field 60—Additional POS Information that
describes the capability of the terminal used. Values used in field 22 affect other fields
(fields 25, 35, 45, and 52) in SMS messages. Refer to the appropriate V.I.P. System
technical specifications manuals for details.

Field 25 contains a code identifying transaction conditions at the point of sale or point
of service (POS), thus identifying a type of original, or subsequent, transaction in
many cases.
This field is used in all customer transaction-related 01xx and 04xx messages. The code
in the original request appears in all subsequent messages.
Field 26—Point-of-Service PIN Capture Code

Field 26 contains the maximum number of PIN characters the POS device can accept.
Valid field values are 00 (unknown or unspecified POS device length) or a value between

04 and 1212. This field is required in requests and advices only when Field 52—PIN Data
is also present, and the POS device cannot accept the standard 12-digit maximum PIN
length (per ISO/TC68/SC2/WG6, draft proposal 9546/1); for example, a POS device
with a maximum 11-digit PIN length. Field 26 is optional if the POS device accepts
12-character PINs. When V.I.P. verifies the PIN as part of PIN Verification Service
processing, the value is not zeroed-out before the message is forwarded to the issuer.

This field indicates the location of the PVV, which affects the location of the Card
Verification Value (CVV). Both the PVV and the CVV must be positioned in the
discretionary data field.
for Track 2.


Field 39 contains a code that defines the response to a request or the message
disposition. This field appears in all responses except those for reconciliation and most
network management functions.
When the authorization message requests PVS PIN verification, V.I.P. places response
code 00 (approved) in field 39 to inform the issuer that the PIN in the message is correct.
If the PIN is incorrect, V.I.P. places response code 55 (incorrect PIN) in field 39.
If V.I.P. encounters PIN block errors during normal message processing, it returns
response code 81 (PIN cryptographic error found) in the 0110, 0210, or 0810 response
message. V.I.P. then initiates an automatic acquirer key change. If the issuer
encounters a PIN block error during verification, it returns response code 81 in the
0110, 0210, or 0810 response.

This field contains the PIN data encoded on Track 1 of the magnetic stripe. If both
Track 1 and Track 2 appear in a message, Track 1 takes precedence.
for Track 1.

Field 52—Personal Identification Number (PIN) Data

Field 52 contains a PIN or password, encrypted and formatted as a block of
16 hexadecimal digits.
The format of this field in an outgoing request must be that indicated by the PIN Block
Format Code in Field 53—Security-Related Control Information of the request. In an
incoming request or advice, the format conforms to the PIN block format of the issuer as
specified to Visa.
The personal identification data type subfield within field 53 indicates whether this field
contains a PIN or a password.
This field must appear:

• In an outgoing 0100 or 0200 request when the customer enters a PIN or password at
the POS.
• In account transfer request messages. When applicable, the acquirer includes a PIN
or password only in an original request.
If field 52 or field 53 carrying PIN data appears in a non-original or exception item,
SMS rejects the message with Reject Code 0699 0699—Presence of PIN/Track/AVS data
This field is not allowed:

• If the cardholder is not present to key in the PIN or password at the POS.
• If the code in field 25 is 01 (customer not present) or 08 (mail or telephone order).
For STIP advices, if STIP authorizes a request with a PIN, it zero-fills this field so the
issuer knows the PIN was provided and included in the original request. Thus, this field
may contain all zeros only in a request or advice incoming to the issuer. However,
for Interlink issuers, this field is not zero-filled. It contains the PIN translated using

the issuer's key.
The Visa Security Module edits the contents of this field during PIN translation and PIN
verification. If there is an error (most commonly an acquirer key problem), V.I.P. does
not reject the request message. Instead, V.I.P. sets the response code in field 39 of
the 0110 or 0210 response to 81 or 86 86.
For PIN translations, fields 52 and 53 and their contents remain with the message when
VisaNet forwards it to available issuers or to STIP on the issuer's behalf for the approval
or decline decision. The fields are not included in responses to acquirers or in advices.
For successful PIN verifications, that is, no error is detected, VisaNet drops fields 52
and 53 before it forwards the message to available issuers. If verification fails (an error
is detected during the verification attempt), field 52 and field 53 remain in the message
and VisaNet forwards them to the issuer.
Field 53—Security-Related Control Information

Field 53 contains data needed by the issuer or the Visa Security Module to process
PINs entered at the POS.
Field 53 is a fixed-length field with six subfields as this illustration shows.

Positions:
1–2 3–4 5–6 7–8 9–10 11–16
PIN Data
Security Algorithm ID PIN Block Zone Key Type, Not Not
Format Format Index Applicable Applicable
Code—The code in field 53.1 defines the security

Positions 1–2, Security Format Code—
20.
technique used. The code in positions 1–2 must be 20
Identifier—The code in field 53.2 defines the

Positions 3–4, PIN Encryption Algorithm Identifier—
encryption technique used. Code 01 is the only code allowed in this subfield.
Positions 5–6, PIN Block Format Code—Code—The code in field 53.3 defines the format of
field 52. In acquirer-initiated requests, this code describes the PIN block format used by
the acquirer. In requests received by the issuer, it describes the PIN block format used
by that issuer. If V.I.P. validates the PIN as part of PVS processing, this field contains
the original code inserted by the acquirer. Positions 5–6 must contain code 01 01, 02
02, or 03
03.
Index—The index in field 53.4 indicates which key was used to

Positions 7–8, Zone Key Index—
encrypt the PIN. In dynamic key exchange messages, this subfield is used to indicate
which key is being changed. If the PIN in field 52 is zeroed-out before the request
reaches the issuer, this code is the original for the acquirer's key. Positions 7–8 must
contain code 01 or 02
02.
The code in field 53 indicates which of the possible encryption keys is to be changed:
01 = Encryption key 1 is to be changed
02 = Encryption key 2 is to be changed
Type—The code in this subfield code defines the personal ID

Positions 9–10, PIN Data Type—
data type (PIN or password) contained in field 52. Positions 9–16 must contain zeros in
outgoing requests.
Reserved—This subfield is used by BASE I.

Positions 11–16: Visa Reserved—
Positions 9–16 are reserved for BASE I use at the VIC. They must be zero-filled by
the acquirer.
Table 33-2 lists valid values for field 53.
Table 33-2 Field 53 Security Codes
Code Definition
Positions 1–2: Security Format Code
20 Zone encryption
Positions 3–4: PIN Encryption Algorithm Identifier
01 ANSI DES
Positions 5–6: PIN Block Format Code

Table 33-2 Field 53 Security Codes (continued)

Code Definition
01 Visa recommends this format. The format is based on the PIN, the PIN
length, selected rightmost digits of the account number, and the pad
characters 0 and F, combined through an exclusive-OR operation.
02 The format is based on the PIN, the PIN length, and a user-specified
numeric pad character.
03 The format is based on the PIN and the F pad character.
Positions 7–8: PIN Zone Key Index
00 Reserved for future use.
01 Working Key 1 is to be changed or used.
02 Working Key 2 is to be changed or used.
Field 53 is required in any message containing a PIN in field 52.
For PIN translations, fields 52 and 53 and their contents remain with the message when
VisaNet forwards it to available issuers or to STIP on the issuer's behalf for the approval
or decline decision. The fields are not included in responses to acquirers or in advices.
For successful PIN verifications, that is, no error is detected, VisaNet drops fields 52
and 53 before it forwards the message to available issuers. If verification fails (an error
is detected during the verification attempt), field 52 and field 53 remain in the message
and VisaNet forwards them to the issuer.
V.I.P. rejects the message with reject code 0753 if this field is present in advices,
completions, reversals (full and partial), representments, adjustments, and their
responses.

Field 63.4—STIP/Switch Reason Code (SMS only)
Field 63.4 contains a code that identifies why STIP responded for the issuer or why
V.I.P. generated an advice. This field appears in an advice generated by STIP when
STIP has performed authorization processing on behalf of the issuer.
Valid error codes for PIN verification processing are:
9041 = There was a PIN verification error.
9045 = V.I.P. was unable to translate the PIN.

For more information about the PIN Verification Service, refer to the following documents:
• V.I.P. System BASE I Technical Specifications
• V.I.P. System SMS Interlink Technical Specifications

and Volume 2
• IBM 3624 Consumer Transaction Facility Programmer's Reference and Component
Descriptions

Chapter 34 POS Check Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
IN BRIEF 34-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
POS Check Service Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
Acquirer or Processor Implementation. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .34-6
Merchant Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-7
Participating Drawee Financial Institution Implementation. . . . . . . . . . . . . .. . . . . . . . . . . . . .34-7
Delivery Methods for POS Check Service Requests. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .34-8
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
HOW POS CHECK SERVICE WORKS 34-99
POS Check Service

FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
PROCESS FLOWS 34-99
Authorization Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-10
Settlement Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-11
Settlement Through VisaNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-11
Settlement Through the ACH. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-12
ABA Account Number Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-13
MICR Line Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-13
Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-14
POS Check Exception Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-14
Visa Resolve Online (VROL) Processing of POS Check Transactions. . . . . . . . . . . . . . .34-15
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
15
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-
19

POS Check Service

Chapter 34 POS Check Service
34.1 IN BRIEF
The POS Check Service offers merchants the ability to accept consumer and business
checks as source documents and to convert the paper checks to electronic transactions
at the point of sale, and from mail, telephone, or electronic commerce merchants.
As electronic transactions, converted checks can be cleared and settled quickly and
efficiently. Merchants using this service can realize the benefits of cost and risk reduction
for check payments. Participating drawee financial institutions, serving as online authorizing
agents for their customers' checks, can clear and settle electronic debits quickly, increasing
revenue opportunities and reducing check processing costs.
The POS Check Service is currently available to acquirers, to processors, and

to drawee financial institutions in the U.S. region only.
BASE I
SMS The POS Check Service is available to Single Message System (SMS) users.
POS Check Service

SMS only
A Participation in the POS Check Service is optional for U.S. acquirers,

processors, and their merchants. It is also optional for participating drawee
financial institutions in the U.S. region or for their authorized third-party agents.
Acquirer

When a customer pays for a purchase with a paper check, the sales clerk informs the
customer that the check is being used as a source document for conversion to an electronic
transaction by passing the check through a check reader. The check reader captures
checking account information from the Magnetic Ink Character Recognition (MICR) line of
data encoded on a customer's check. Merchants can also receive key-entered checking
account information through an Internet connection or through a telephone or mail order
device.
If the customer asks that the check not be converted, the sales clerk follows the merchant's
standard paper check-handling procedures. If the customer agrees to the check conversion,
the merchant initiates a POS check transaction. The POS Check Service:
• Validates that the check can be processed electronically.
• Enables the merchant to return the voided check to the customer.

• Creates an 0200 full financial transaction that automatically transfers the check amount
from the customer's checking account to the merchant's bank account through VisaNet or
through the Automated Clearing House (ACH).
• Handles exception items for VisaNet- and ACH-settled transactions.
• Processes fee collection and funds disbursement transactions, which route funds
between participants to settle obligations between them, and which disburse funds to
(or collect funds from) them, for VisaNet-settled transactions.
• Provides reports—for instance, settlement reports and exception item reports.
NOTE
The POS Check Service does not support electronic transactions for Internet gambling.

The service offers three options for converting checks at the point of sale, as shown in
Table 34-1. Participating acquirers, merchants, and drawee financial institutions must
support at least one of the options and may choose to support any combination of the three.
Third-party authorizing agents must support all three service options.
Table 34-1 POS Check Service Options
Option Description
Conversion Only The authorization request message is routed to the participating drawee
financial institution or to a third-party authorizing agent, which approves
or declines the transaction by checking the status of the account. The
merchant retains the risk of loss.
Verification With The authorization request message is routed to the participating drawee
Conversion financial institution or to a third-party authorizing agent for verification
POS Check Service
of the probability that the transaction will be paid by the customer. The
participating drawee financial institution makes an approval or decline
decision based on access to the demand deposit account (DDA) and on
information about funds availability at the time of the request. The third-party
authorizing agent makes an approval or decline decision based on its risk
management database. The merchant retains the risk of loss.
Guarantee With The authorization request message is routed to the participating drawee
Conversion financial institution or to the third-party authorizing agent to guarantee the
transaction. If the transaction is approved, the risk of loss is transferred to
the participating drawee financial institution or to the third-party authorizing
agent, provided that all merchant acceptance criteria have been met. The
guarantor bears the risk of loss.
34.3.2 POS Check Service Participants

In addition to Visa U.S.A., entities participating in or impacted by the POS Check Service
include those listed in Table 34-2.
Table 34-2 POS Check Service Participants
Term Meaning
Acquirer A bank that has a signed agreement with one or more merchants
participating in the service and submits POS check transactions for clearing
and for settlement through VisaNet or through the ACH.

Table 34-2 POS Check Service Participants (continued)

Term Meaning
Automated Clearing A funds transfer system governed by the rules of the National Automated
House Clearing House Association (NACHA). ACH allows financial institutions to
clear interbank entries electronically.
Customer A person who agrees to a transaction for payment to a merchant for goods,
services, and/or cash back.
Drawee Financial A financial institution whose demand deposit account customers may have
Institution POS check transactions processed by the service at the point of sale.
Merchant An entity that accepts consumer POS check transactions as payment for
merchandise or for services, and that processes the transactions through
the POS Check Service.
Originating A depository financial institution that sends entries to the ACH.
Depository
Financial Institution
(ODFI)
Processor A member, or a Visa-approved non-member acting as the agent of a
member, providing authorization, clearing, and/or settlement services for
members and for merchants.
Receiving A depository financial institution that receives transactions from the ACH.
Depository
Financial Institution
(RDFI)
Third-Party An entity that authorizes POS check transactions for non-participating banks
Authorizing Agent and creates ACH items that are sent to the ODFIdebtor agent.
VisaNet The data processing systems, networks, and operations used by the service
POS Check Service

to support and to deliver authorization, clearing, and settlement services.
Participants may also need to work with ancillary parties, such as point-of-sale integrators,
image repositories, imaging processors, and collection agencies.

This section summarizes participation requirements. For more details, refer to the POS
Check Service Member Planning Guide.
A participating acquirer (or its processor) and merchant must support at least one of the
service options. An acquirer needs to establish with each of its participating merchants
which of the service options will be supported and which third-party authorizing agent will
be used for POS check transactions drawn on non-participating banks.
A participating drawee financial institution may support any combination of the three options.
All transactions must comply with applicable provisions of:

• National Automated Clearing House Association (NACHA) rules.
• Federal Reserve Regulation E, Electronic Fund Transfers.
• The POS Check Service Operating Regulations and other applicable laws or regulations.
• Visa International Operating Regulations

34.4.1 Testing
All merchants, acquirers, processors, participating drawee financial institutions, and
third-party authorizing agents with a connection to VisaNet for online messages that want
to participate in the POS Check Service must conduct comprehensive testing with Visa to
ensure that POS check transactions can be exchanged correctly among all parties.
POS Check Service testing ensures that acquirers and drawee financial institutions can
send and can receive the correct values in POS Check Service key fields for requests,
reversals, and exception item processing messages. These fields include:
• Field 3—Processing Code
• Field 22—Point-of-Service Entry Mode Code
• Field 25—Point-of-Service Condition Code
• Field 44.11—Original Response Code
• Field 44.12—Check Settlement Code
• Field 48—Additional Data–Private
• Field 60—Additional POS Information
• Field 61.1—Other Amount, Transaction
• Field 62.2—Transaction Identifier
• Field 63.3—Message Reason Code
• Field 63.6—Chargeback Reduction/BASE II Flags (Mail/Telephone or Electronic
Commerce Indicator)
• Field 100—Receiving Institution Identification Code
• Field 125—Supporting Information (MICR Data)
POS Check Service participants. Participants can contact their Visa representatives to
POS Check Service

Service monitoring is available for the POS Check Service. Members can contact their Visa
representatives for information.

A POS Check Service participant is an organization that agrees to comply with the
terms and the conditions of the POS Check Service Operating Regulations, completes
comprehensive testing with Visa, participates in one or more of the service options
(Conversion Only, Verification With Conversion, and Guarantee With Conversion), and
performs functions and activities appropriate for participation in the service.
34.4.3.1 Acquirer or Processor Implementation

The acquirer or its processor needs to:
• Maintain a merchant interface system that complies with the technical and operational
standards of V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications,
Volume 1 and Volume 2, including:
- Receiving, reformatting, and forwarding POS check transactions—V.I.P.
SMS-connected acquirers and processors use V.I.P. SMS ISO message formats.
- Processing voids and reversals.
- Selecting and supporting all applicable service options.
• Pre-qualify and have a Merchant Agreement with each of its merchants.

• Provide a unique merchant identifier for each merchant name and location that originates
transactions.
• Select the third-party authorizing agent to be used for transactions drawn on
non-participating banks.
• Establish an ODFI relationship.
• Provide back-office support for exceptions both from VisaNet and from the ACH.
• Support settlement and reconciliation.
• Meet the requirements for participation, as defined in the operating regulations for the
service.
• With its merchant or merchants, be successfully tested by Visa, and ensure that its
merchants comply with the requirements of the operating regulations for the service.
The acquirer or its processor works with the merchant and with the point-of-sale terminal
vendor to establish an integrated point-of-sale solution.
34.4.3.2 Merchant Implementation

The merchant needs to:
• Work with its acquirer or its processor to develop and maintain a point-of-sale application
including check readers and terminals that can:
- Send and receive POS check transactions (including reversals) and process
customer-initiated voids electronically at the point of sale.
- Read the MICR line on checks.
- Allow key entry of supplemental identification data.
- Transmit the check information, the customer identification information (if present), and
the sales amount with other required data elements to the acquirer or to its processor,
or to VisaNet.
- Support all applicable service options.
POS Check Service

- Print a transaction receipt and a decline transaction receipt, and include the city and
the state of the terminal used to initiate the transaction on the customer statement, as
specified in the operating regulations for the service.
• Designate a bank account into which electronic check funds can be deposited.
• Define minimum and maximum cashback amounts, if supported.
• Work with its acquirer or its processor to agree on the settlement process and on
reconciliation procedures.
To ensure efficient operations and to enhance customer acceptance, merchant sales staff:
• Follow normal paper check-acceptance procedures for any checks that cannot be
processed electronically.
• May submit an online reversal request, when necessary, to void the previously approved
POS check transaction.
• Process merchandise returns as traditional cash refunds or as store credit returns to
the customer.
• Handle cashback transactions according to merchant policies, if the merchant supports
cashback transactions.
34.4.3.3 Participating Drawee Financial Institution Implementation

The participating drawee financial institution needs to:

• Maintain an authorization system that complies with the technical and the operational
requirements of V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications,
Volume 1 and Volume 2, including:
- Receiving and responding to POS check transactions—V.I.P. SMS-connected banks
and their processors use V.I.P. SMS ISO message formats.
- Receiving non-parsed MICR (in raw TOAD format) or parsed MICR, and returning
parsed MICR data elements in the routing transit number, customer account number,
and check serial number fields.
- Processing reversals.
- Processing adjustments.
- Supporting all applicable service options.
• Receive settlement, reports, and raw data from VisaNet or from its drawee processor.
• Provide back-office support for exceptions from VisaNet.
• Develop a means of reporting POS check transactions on the customer checking account
statement.
• Meet the requirements for participation as defined in the operating regulations for the
service.
• Be successfully tested with Visa or with its drawee processor.
34.4.3.4 Delivery Methods for POS Check Service Requests

Acquirers can send POS Check Service requests directly through their VisaNet connection
or can use a VisaNet Access Point (VAP) as follows:
Using a VisaNet Connection—

Connection—If an acquirer chooses to send requests from its VisaNet
connection, it must modify its application programs and its host interface to create check
conversion requests that can be sent to V.I.P.
POS Check Service
VAP—When a center uses a VAP to submit POS Check Service requests, the VAP
Using a VAP—
reformats the requests into SMS messages.
For information about VisaNet connections and VAPs, refer to “For More Information”
in About This Manual.

The following message types apply to the POS Check Service:
• 0200 financial request and 0210 financial response
• 0200 resubmission and 0210 resubmission response
• 0220 STIP advice and 0230 STIP advice response
• 0420 financial reversal request and 0430 financial reversal response
• 0420 resubmission reversal and 0430 resubmission reversal response
• 0600 request for copy and 0610 request for copy response (not applicable for third-party
authorizing agents)
• 0422 chargeback or chargeback reversal and 0432 chargeback or chargeback reversal
response (not applicable for third-party authorizing agents)
• 0422 STIP chargeback or chargeback reversal advice and 0432 STIP advice response
(not applicable for third-party authorizing agents)
• 0220 representment and 0230 representment response
• 0220 STIP representment advice and 0230 STIP advice response
• 0220 adjustment request and 0230 adjustment request response
• 0220 STIP adjustment request advice and 0230 STIP advice response

Chapter 34 How POS Check Service Works
• 0220 acquirer-generated fee collection, returned check fee, or funds disbursement

request, and 0230 fee collection, returned check fee, or funds disbursement request
response
• 0422 issuer-generated fee collection, returned check fee, or funds disbursement request,
and 0432 fee collection, returned check fee, or funds disbursement request response
• 0520 reconciliation advices (not applicable for third-party authorizing agents and is
optional for acquirers and for drawee financial institutions)
• 0600 free text messages and 0610 free-text responses
• 0620 funds transfer totals and 0630 funds transfer totals responses (not required by
third-party authorizing agents)
• 0800 network management messages and 0810 network management responses
• 9620 fraud advices and 9630 fraud advice responses
34.6 HOW POS CHECK SERVICE WORKS

A merchant participating in the POS Check Service initiates a POS check transaction by
entering the amount of the sale and electronically capturing checking account data from the
MICR line encoded on a customer's check. Merchants can also use key-entered checking
account data for Internet, telephone, or mail order transactions.
The merchant may also optionally key enter customer identification information, such as a
driver's license number, at the point of sale. The check data, customer identification data
(if present), and the sales amount must be combined with other required data elements and
be formatted into an 0200 financial POS check request message. The request message is
forwarded to VisaNet for processing.
Approved POS check transactions that VisaNet has exchanged with participating drawee
financial institutions are settled daily by the VisaNet payment system. POS Check Service
POS Check Service

settlement totals may be combined with settlement totals for other activity processed by
VisaNet if the same BIN is used for activity other than POS check transaction processing.
POS check transactions exchanged by VisaNet and by third-party authorizing agents

are settled by the Automated Clearing House (ACH). All post-settlement exception items
relating to these transactions must be processed according to the ACH rules published by
the National Automated Clearing House Association (NACHA).
34.7 PROCESS FLOWS

This section provides authorization and settlement process flows for the POS Check
Service.

34.7.1 Authorization Process Flow

The POS Check Service authorization process flow, shown in Figure 34-1, includes the
following steps.
Figure 34-1 POS Check Authorization Processing Flow
Participating
Drawee Financial
Institution
Customer POS Merchant Acquirer V.I.P.
Third Party
POS Check Service
1. At the point of sale, the sales clerk identifies the type of check to ensure that it can be
accepted by the service and tells the customer that the check is being used as a source
document for conversion to an electronic item.
Optionally, the sales clerk can key enter the checking account information received
from the customer through an Internet connection or for a telephone order or mail
order transaction.
2. The sales clerk passes the check through a check reader, which electronically captures
the checking account information from the MICR line encoded on the check.
3. The sales clerk enters the amount of the purchase and, optionally, key-enters additional
customer identification information. This information varies, depending on the
requirements of participating merchants, acquirers or their processors, and third-party
authorizing agents—but could include, for instance, the customer's driver's license
number, state, and date of birth.
4. The check reader converts the MICR data into an electronic POS check transaction and
sends it to the acquirer or to its processor.
5. The acquirer or its processor formats the transaction into an authorization request
message (0200 full financial message) and forwards it to VisaNet.
6. V.I.P. edits and validates the transaction, based on the routing information contained in
the message, and routes the transaction:

- To the drawee financial institution if the routing transit number in the authorization
request is that of a participating bank. This transaction is referred to as a participating
transaction.
- To a third-party authorizing agent if the routing transit number in the authorization
request is that of a non-participating bank. This transaction is referred to as a
non-participating transaction.
7. The participating drawee financial institution or the third-party authorizing agent
performs authorization processing (for instance, checking the status of the account,
verifying the account balance, or checking a risk management database) and sends
a response to VisaNet.
8. VisaNet forwards the authorization response to the acquirer or to its processor.
9. The acquirer or its processor forwards the response to the merchant.
10.The sales clerk completes the transaction at the point of sale by voiding the paper check
and printing two copies of the transaction receipt—one for the customer to sign and the
other to be returned to the customer with the voided paper check.
34.7.2 Settlement Process Flows

The means of settlement is determined at the time the transaction is authorized, based on
how it is routed for authorization.
• A POS check transaction authorized by a participating drawee financial institution settles
through VisaNet.
• A POS check transaction authorized by a third-party authorizing agent (a check
transaction drawn on a non-participating bank) settles through the ACH network.
• Acquirers receive an ACH settlement and a VisaNet settlement.
34.7.2.1 Settlement Through VisaNet
POS Check Service

On a daily basis, VisaNet distributes settlement files for approved POS check transactions
to acquirers and to participating drawee financial institutions. If the same BIN is used for
activity other than POS check transaction processing, POS Check Service settlement totals
are combined with settlement totals for other activity processed by VisaNet.
Figure 34-2 shows the settlement process for transactions settled by VisaNet. The flow
shows one transaction, but represents the delivery of batches of POS check transactions to
multiple acquirers or to their processors, and to participating drawee financial institutions.
Figure 34-2 POS Check Service VisaNet Settlement Flow
Participating
Drawee Financial
POS Merchant Acquirer Visa Institution Customer

For POS check transactions authorized by participating drawee financial institutions, at

the end of the day:
1. VisaNet provides settlement information to an acquirer or its processor, and to
participating drawee financial institutions or their processors.
2. VisaNet sends raw data and reports to an acquirer or its processor, and to participating
drawee financial institutions or their processors.
3. VisaNet initiates the movement of funds between the settlement accounts of the
participating drawee financial institution or its processor, and those of the acquirer or
its processor.
4. The acquirer or its processor reconciles the credit amounts to its merchants' accounts.
5. Participating drawee financial institutions apply debits to their customers' checking
accounts.
34.7.2.2 Settlement Through the ACH

For settlement of transactions drawn on non-participating banks, the ACH enables the
settlement of transactions from the designated Originating Depository Financial Institution
(ODFI) to the Receiving Depository Financial Institution (RDFI).
NOTE
In this context, the ODFI is the institution that initiates the ACH item, and the RDFI is the institution that
receives the item and debits it from the customer's checking account.
POS check transactions authorized by third-party authorizing agents are settled by the
ACH as shown in Figure 34-3. All settled transactions and post-settlement exception items
relating to these transactions must be processed according to the NACHA rules.
POS Check Service
Figure 34-3 POS Check Service ACH Settlement Flow
RDFI Customer
On-Us
Third Party Debtor Agent ACH
Acquirer/
Debtor Agent POS Merchant

For POS check transactions authorized by a third-party authorizing agent, at the end of the
day:
1. The third-party authorizing agent sends its ACH batches to the ODFI.
2. The ODFI processes all on-us transactions and forwards all non-on-us transactions to
the ACH.
3. The ACH forwards all debits to the RDFI.
4. The ACH forwards an offsetting credit to the ODFI to be forwarded to the acquirer
or to its processor.
5. The ACH initiates movement of funds between the settlement accounts belonging to the
ODFI and to the RDFI.
6. The RDFI forwards the debits to the customers' checking accounts.
7. The acquirer or its processor sends the credit amounts to its POS merchants.
34.7.3 ABA Account Number Table

VisaNet maintains a table of American Banking Association (ABA) account number ranges
that are ineligible for this service and accesses this table for each POS check authorization
request to ensure compliance.
VisaNet and authorizing endpoints decline transactions for any check that falls into one of
the following categories:
• Checks drawn on invalid or fraudulent ABA account numbers.
• Checks at the point of sale that do not contain a pre-printed serial number.
• Checks that have been previously negotiated.
• Checks that have been previously voided in connection with another POS check
transaction or with another program according to NACHA check conversion rules.
• Checks not containing an ABA routing and transit number and a demand deposit account
POS Check Service

(DDA) number.
• Federal Reserve Bank and Federal Home Loan Bank checks.
• Government checks, including checks drawn on a state or local government.
• Third-party checks.
• U.S. Treasury checks.
• Obligations of a financial institution, such as travelers checks, convenience checks,
cashier checks, official checks, and money orders.
• Checks payable in a currency other than U.S. dollars.
34.7.4 MICR Line Overview

The conversion of paper checks to electronic items depends on the accuracy and the
integrity of the data in the Magnetic Ink Character Recognition (MICR) line. The MICR line
consists of a line of characters printed at the bottom of a check. These characters are
printed in magnetic ink that allows the merchant's check-reading device to capture the
data through a single pass. The five specific fields of the MICR line include the Auxiliary
On-Us Field, External Processing Code, Routing Field, On-Us Field, and Amount Field.
The drawee financial institution, following rules that must adhere to ANSI check standards,
controls the contents of the MICR line. See ANSI Standard X9.13-1999 Placement and
Location of MICR Printing Specifications for more information.

Figure 34-4 shows the layout of a check MICR line.
Figure 34-4 Layout of Check MICR Line
EPC Field
6 6 6 6 6 6 5 5 5 55 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
5 4 3 2 1 0 9 8 7 65 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1
Auxiliary On-Us Routing On-Us Amount

Field Field Field Field
Extended Encoding Strip
NOTE
Figure 34-4 is not to scale. The proper scale is eight characters per inch.
The MICR data is transmitted in Field 125—Supporting Information of the full financial
message. For information about field 125, see “Key Fields Glossary” in this chapter.
POS Check Service
34.7.5 Reporting
VisaNet provides participants with comprehensive activity reports (showing all POS
check transactions processed) and with settlement reports (showing all VisaNet-settled
transactions). In addition, participants may choose to receive daily raw data files of POS
check transactions. For information about raw data, see VisaNet Settlement Service (VSS)
User's Guide, Volume 2, Reports.
34.7.6 POS Check Exception Transactions

POS Check Service merchants, acquirers, processors, and participating drawee financial
institutions must use the following exception transactions to correct errors when they occur:
• Request for Copy
• Chargeback
• Representment
• Second Chargeback
These exception transactions may only be used by merchants, acquirers, processors,
and participating drawee financial institutions. They also may only be used for POS check
transactions originally settled by VisaNet.
The following sections explain the requirements and the processing rules for each of these
exception transactions.

Exception processing for POS check transactions that originally settled through the
Automated Clearing House (ACH) must be handled according to NACHA rules and is
not handled by VisaNet.
Adjustments are processed to correct a processing error during a merchant's end-of-day

balancing. Adjustments may be submitted to V.I.P. for transactions that originally settled
through VisaNet or through the ACH, and VisaNet routes the adjustments to the appropriate
endpoints for settlement.
34.7.7 Visa Resolve Online (VROL) Processing of POS Check Transactions

Visa Resolve Online (VROL), the Internet-based exception processing system, may be
used by POS Check Service participants to originate and to receive POS check exception
transactions, fee collection and funds disbursement transactions, and fraud advices.
VROL can only be used for exception transaction processing by acquirers and by
participating drawee financial institutions for POS check transactions originally settled
by VisaNet, but can be used to submit adjustments. Resubmissions cannot be initiated
through VROL.
POS Check Service participants may use VROL for transaction inquiries for all POS check
transactions, both those settled by the VisaNet payment system and those settled by
the ACH.
Before originating an exception transaction, a POS Check Service participant may use
VROL to obtain the original POS check transaction. The participant uses the retrieved
transaction to create the related exception transaction or transactions.
For further information about VROL processing requirements for the POS Check Service,
POS Check Service

refer to V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1
and Volume 2.

This section lists and describes key fields associated with the POS Check Service.

This field contains coding that identifies the customer transaction type in positions 1
and 2. For the POS Check Service, these positions identify the type of POS check
transaction: Guarantee With Conversion (03 03), 04),
03 Verification With Conversion (04
04 or
Conversion Only (1818).
18

This field identifies the method used to capture the Magnetic Ink Character Recognition
(MICR) data for transactions processed through VisaNet. For the POS Check Service,
these positions are as follows:
• Positions 1–2, Entry Mode—Must contain 84 (MICR reader) or 01 (key-entered).
• Position 3, PIN Entry Capability—Must contain 0 (unknown).
• Position 4, Fill—Must contain 0 (unused).


Field 25 serves as an identifier, in conjunction with the processing code. The POS
condition code for POS check transactions must be 52 for all original full financial
transactions.
Field 44.12—Check Settlement Code

This field is provided by V.I.P. in responses to indicate the settlement disposition of the
transaction. Field 44.12 (1, alphanumeric) is in position 14 of field 44. The POS Check
Service requires one of the following codes:
• Visa Settlement Code = 1
• ACH Settlement Code = 2
Field 44.12 is not present if the item will not be settled.
Field 48—Additional Data—Private

Field 48 may be used for any customer identification information specifically required
by an authorizer. It allows merchants and third-party authorizing agents to exchange
information specific to their participation in the POS Check Service.
Field 60—Additional POS Information

Field 60 is a private-use field defined by Visa to provide additional information about the
point of sale or service.
Subfields 60.1 and 60.2 are required:

• Position 1 (60.1), Terminal Type—Must contain 0 (mail order and Internet),
4 (electronic cash register), or 7 (telephone order).
• Position 2 (60.2), Terminal Entry Capability—Must contain 0 (mail order and
telephone order), 1 (Internet), 6 (MICR read), 7 (MICR read and image capable),
POS Check Service
or 9 (POS key entry).
Field 61.1—Other Amount, Transaction

This field should contain the cashback amount from the transaction, if any. The
cashback amount may not exceed the transaction amount in field 4.

This field contains a unique transaction identifier (TID) assigned by VisaNet. It is sent to
transaction recipients and is returned to transaction originators.
Field 63.3—Message Reason Code

Field 63.3 identifies the reason for the message, if it is other than an original request.
The following codes are used for the POS Check Service:
• 2523 = Original resubmission reversal
• 5203 = Resubmission

Field 63.6—Chargeback Reduction/BASE II Flags

Position 4, Mail/Telephone or Electronic Commerce Indicator—Identifies the
environment in which the transaction occurred. Valid values for position 4 include:
• Space = POS, Customer Present
• 1 = Telephone Order
• 4 = Mail Order
• 8 = Internet
Field 100—Receiving Institution Identification Code

Field 100 must contain the BIN ID of the third-party authorizing agent that the originator
wants to receive the transaction.
If the check is drawn on a participating drawee financial institution, and that bank
supports the requested service option, VisaNet routes the transaction to that bank.
If not, VisaNet routes the transaction to the designated third-party authorizing agent.
For adjustment transactions initiated by the merchant or by the acquirer, field 100 must
contain the third-party authorizing agent's BIN ID if the item was originally settled by the
ACH system.
Field 125—Supporting Information

The MICR line from the customer's paper check must be captured and populated
in field 125. Acquirers populate field 125 with the unformatted (raw) MICR data
captured from the check, or they may key-enter the MICR data as supplied to them
from the consumer through a secure Internet connection, a mail order form, or a
telephone-initiated payment request in parsed format. Parsed MICR is the check MICR
data separated into the individual components of the check MICR line.
POS Check Service

Drawee financial institutions and third-party authorizing agents must parse the raw
MICR, if necessary, to determine the customer's checking account number, perform
authorization processing, and return the parsed MICR back in the response to V.I.P.
Table 34-3 and Table 34-4 provide a detailed description of formatting requirements
for field 125. Unformatted MICR data is only used in POS check request messages.
Parsed MICR data is required in all approved POS check response messages, and may
be used in POS check request messages.
Table 34-3 POS Check Field 125 Format Requirements—Unformatted MICR
Field
Number/Name Position/Size Data Content Format
125, Supporting 1–255 Contains customer financial institution n/a
Information account information captured from the
MICR line on customers' checks. Data
capture occurs when the MICR line is
read by a terminal at the point of sale.
Length 1 Contains the length of the data contents
in the entire field.
Field Identifier 2–3 $V Identifies use of the field as “POS
2 check.”

Table 34-3 POS Check Field 125 Format Requirements—Unformatted MICR (continued)
Field
Number/Name Position/Size Data Content Format
Data Type 4–5 RM Identifies the data contents as
Identifier 2 unformatted MICR information.
Must be present in the request, and
the MICR data that follows must be
unformatted.
Data Length 6–8 999 Indicates the length of the MICR data
Identifier 3 contained in the field.
Unformatted MICR 9, variable Must contain the entire unaltered The unformatted MICR data is the exact
Information contents of the MICR line, with spaces MICR line from the check, including
preserved, read from the customer's spaces, except that the MICR symbols
check by a terminal. At a minimum, are replaced as follows (“raw TOAD”
the routing transit number and the format):
customer account number (on-us field)
must be present. The Transit symbol (II) must be replaced
by the letter T either in upper or lower
case.
The on-us symbol (II II)

II must be replaced
by the letter O either in upper or lower
case.
The dash symbol (––) must be replaced

by the letter D either in upper or lower
case.
125, Supporting Contains customer bank account n/a
Information information captured from the MICR
POS Check Service
line on customers' checks. Data

capture occurs in either of two ways:
• The MICR line is read by a terminal
at the point of sale.
• The MICR line is key-entered
through a merchant or an acquirer
Internet connection or through a
telephone or mail order device.
Table 34-4 POS Check Field 125 Format Requirements—Parsed MICR
Field
Number/Name Required Data Format
Field Identifier $V Identifies the use of the field as “POS Check.” The POS
Check Service field identifier must appear in the first two
bytes of the field, exactly as shown.
Following the field identifier, subfields may be in any order within field 125.
NOTE:
Any of the alpha characters sent in this field in the request message (tt, o, d) must be stripped out when the field is returned.

Table 34-4 POS Check Field 125 Format Requirements—Parsed MICR (continued)
Field
Number/Name Required Data Format
Routing Transit The drawee financial institution's routing The routing transit number has a fixed length of 9 numeric
Number transit number (ABA number). AB999dddd,
characters and must be formatted as follows: AB999dddd
where AB identifies the subfield, 999 the length of the data,
and dddd the actual data content.
Customer Account The customer deposit account number. The customer deposit account number must be present, be
Number a maximum of 19 characters and be formatted as follows:
AN999dddd, where AN identifies the subfield, 999 the
AN999dddd
length of the data, and dddd the actual data content.
Check Serial The check serial number of the check The check serial number, when present, is a maximum of
Number being converted. CK999dddd,
15 characters and is formatted as follows: CK999dddd
where CK identifies the subfield, 999 the length of the data,
and dddd the actual data content. The check serial number
is optional for Internet, mail order, or telephone order
request messages, but must be provided in all subsequent
messages if it is in the original request.

For further information about the POS Check Service, refer to the following sources:
• POS Check Service Planning Guide
• POS Check Service Operating Regulations
and Volume 2
• ANSI Standard X9.13-1999 Placement and Location of MICR Printing Specifications
POS Check Service

• www.ansi.org; click on Standards Info
Info.
• www.nacha.org

POS Check Service

Chapter 35 Positive Authorization Capacity Management (PACM) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
IN BRIEF 35-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
Determining Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
Advice Message Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-5
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-5
RELATED MESSAGES
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
35-55
HOW POSITIVE AUTHORIZATION CAPACITY MANAGEMENT (PACM)

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
SERVICE WORKS 35-55
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
PROCESS FLOWS 35-66
Positive Authorization Capacity Management (PACM) Service

Determining Which Transactions To Divert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-6
Transactions Always Routed To STIP. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .35-6
Transactions Eligible for STIP Diversion. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .35-6
Transactions Not Eligible for STIP Diversion. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .35-7
Calculating a Diversion Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
BASE I and SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-8
BASE I Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-8
SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
Stand-In Processing of PACM-Diverted Transactions. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .35-10
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
11
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-
11


Chapter 35 Positive Authorization Capacity Management (PACM) Service
35.1 IN BRIEF
The Positive Authorization Capacity Management (PACM) Service establishes limits
that route transactions to the issuer or to STIP primarily using an issuer limit as well as
a dynamic limit called the diversion threshold. STIP determines this limit by comparing
transaction volume to issuer capacity.
PACM monitors the issuer's transaction volume every 60 seconds. When the volume of
authorization and financial request messages exceeds the issuer's processing capacity,
PACM routes low-risk transactions to the stand-in processor (STIP) for the next 60 seconds.
PACM continues to balance volume with capacity until the issuer is able to process all
transactions. PACM creates advices with optional PACM indicators.
PACM is available to issuers in all Visa regions.

BASE I
SMS PACM is available both to BASE I users and to SMS users.
BASE I and SMS
Participation in PACM is optional for issuers. PACM is available for point-of-sale

I or point-of-service (POS) transactions (including Visa Electron and Interlink
transactions), and for Visa Secure Electronic Commerce (VSEC) transactions,
as well as for MasterCard transactions. It is also available for proprietary and
Issuer private-label cards

PACM protects issuers against periods of excessive message volume by ensuring that
their processing capacity is available for transactions with the greatest implications for
customer service and risk control.
When the volume of request messages exceeds the issuer's processing capacity, PACM
routes a calculated number of low-risk transactions to STIP for the next minute. This
diversion to STIP enables issuers to process higher-risk financial transactions, which
reduces overall risk. PACM supports higher levels of customer service by reducing the
frequency of unnecessary declines.
PACM also provides issuers with flexibility in scheduling processor upgrades.

PACM continually checks transaction volume every 60 seconds and adjusts the number of
transactions routed to STIP so that the optimum number of messages can be processed by
the issuer without exceeding the issuer's capacity.
PACM is similar to Positive Cardholder Authorization Service (PCAS) in that both route
low-risk transactions to STIP.
• PCAS routes transactions to the issuer or to STIP using issuer limits.
• PACM routes transactions to the issuer or to STIP using a dynamic limit called the
diversion threshold, which is a sliding dollar amount.
IMPORTANT
This diversion threshold replaces the use of issuer-specified issuer limits when determining whether a
transaction should go to available issuers or to STIP. However, mandatory minimum issuer limits still apply as
an initial issuer-or-STIP decision tool.
PACM transactions with amounts in excess of the amount threshold are sent to the issuer if
available; transactions below the amount threshold are sent to STIP. Mail order/telephone
order (MOTO), risky purchase, and cash transactions are not eligible for PACM and are
always forwarded to issuers when they are available.
Once in STIP, PACM and PCAS use most of the same PCAS parameters.
Visa recommends that issuers review their activity checking parameters and default
response codes before enrolling in PACM to avoid excessive STIP non-approvals or

high-risk exposure.
IMPORTANT
SMS performs activity checking even if the issuer has set the issuer BIN activity count to zero.
For further PCAS information, refer to Chapter 36, Positive Cardholder Authorization
Service (PCAS).

Participation in PACM does not require any special VisaNet connections.
PACM participation is established at the BIN level. PACM diversion to STIP is controlled
at the Processor Control Record (PCR) level. Issuers can specify which BINs are subject
to PACM processing and which are not. Issuer processors with both participating and
non-participating BINs should be aware that although PACM monitors all transaction traffic,
PACM STIP diversion occurs only for PACM-participating BINs.
35.4.1 Determining Capacity

Capacity is established and managed at the issuer processor level. Visa recommends that
participating issuer processors use PACM for most of their transaction traffic. Otherwise,
a greater proportion of high-risk transactions would go to STIP when volume exceeds
the processor capacity. Issuers that want to participate in PACM should confirm service
requirements with their processors.

Visa assigns PACM participants a default capacity rating that is equal to the capacity of their
connection to VisaNet. Issuers must notify Visa Member Services if their issuer-specified
host capacity is less than its assigned default.
IMPORTANT
An issuer-specified capacity cannot exceed the capacity of its VisaNet connection.
35.4.1.1 Advice Message Management

PACM suspends advice traffic when total processor volume exceeds capacity. This
precaution preserves issuer processor capacity for real-time authorization decisions.
STIP creates advices of STIP transactions and holds them for the issuer until V.I.P.
determines that issuer volume is below capacity. When transaction volume drops below
capacity, V.I.P. resumes advice delivery and includes advice volume in overall processor
volume.
Many SMS issuers receive a large volume of advices. Because SMS advices may be
postable to the cardholder's account, they are time-critical and some issuers may choose
to continue receiving advice messages when volume exceeds capacity. Thus, SMS
issuers have the option of specifying that PACM not suspend advice traffic during PACM
diversion. Selecting this option means that STIP processes more real-time authorization
and full-financial requests during high-volume periods. STIP creates advices for these
transactions.

35.4.2 Testing
While participating issuers do not have to test for PACM participation, Visa recommends
testing for new participants. If issuers choose to receive PACM data in 0120 and 0220
advices, they must test for fields 44.6 and 44.7.

for PACM participants. Members can contact their Visa representatives to make the
arrangements.

Service monitoring is not available for PACM. The authorization profile reports and capacity
management reports provide weekly and monthly summaries of PACM activity.

PACM monitors the volume of all traffic to the issuer processor, which includes authorization
and financial messages, advices, file updates, acquirer traffic, and other transactions.
35.6 HOW POSITIVE AUTHORIZATION CAPACITY MANAGEMENT (PACM)

SERVICE WORKS
PACM monitors the flow rate (volume) of all messages to the participating issuer's
processor and compares this rate to the issuer's processor capacity information, which is
stored in the V.I.P. system tables.
The volume-to-capacity ratio determines the percent of authorization requests to be

diverted to STIP.

35.7 PROCESS FLOWS

When PACM monitoring detects that per-minute volume exceeds the issuer processor's
capacity, PACM routes low-risk transactions to STIP for the next 60 seconds. Figure 35-1
illustrates diversion processing.
Figure 35-1 PACM Diversion Processing
$295
$66 STIP sends transactions

above the limit to the
issuer
$38
Diversion Threshold
$17
STIP processes transactions at
or below the diversion threshold:
$11 - Exception file check
- Activity check (optional)
$0 - Advice created for all transactions
PACM generates an advice containing optional PACM indicators for each transaction
processed by STIP.
35.7.1 Determining Which Transactions To Divert

PACM makes the decision to divert transactions based on the transaction amount,
the diversion threshold, and whether the transaction is eligible for diversion.
35.7.1.1 Transactions Always Routed To STIP

PACM always routes the following transactions to STIP:
• Authorization requests under the travel and entertainment (T&E) mandated limits.
• Up to USD$499,999.99 for Visa Signature, Visa Signature Preferred, Visa Infinite,
Visa Signature Business.
• Up to USD$499,999.99 for Visa Business, Visa Corporate, Visa Business Check Card,
Prepaid Commercial, Visa Purchasing, Visa Purchasing with Fleet, Visa Purchasing
GSA, and Visa Purchasing GSA with Fleet, wherein the ARDEF participation flag (large
ticket) is OFF for the card number.
NOTE
If the ARDEF participation flag (large ticket) is ON for the card number, the limit on the transaction
amount is up to US$9,999,999.99.
• Preauthorization completions and reversals if STIP handled the original requests.
35.7.1.2 Transactions Eligible for STIP Diversion

PACM also considers the following transactions eligible for diversion to STIP:

• Purchases, purchases with cashback, preauthorizations

• Restaurant
• Medical
• T&E transactions over the mandated minimum issuer limits or exempt from the mandated
minimum limits
If dual-card issuers that participate in the Visa Shortest Online Path (VSOP) Service
choose to send issuer-unavailable MasterCard transactions to Banknet, V.I.P. routes the
transactions diverted by PACM to Banknet. For details on VSOP, refer to Chapter 10,
Visa Shortest Online Path (VSOP) Service, in Volume 1.
35.7.1.3 Transactions Not Eligible for STIP Diversion

PACM never diverts the following transactions:
• ATM cash, quasi-cash, and other cash
• Mail and telephone orders
• Risky purchases (certain merchant category codes with higher than average fraud rates)
• Status checks (single unit of currency authorizations) and balance inquiries. For details
about the Status Check Service, refer to Chapter 38, Status Check Service.
• Resubmissions
• Traffic destined for acquirers
• Issuer traffic for BINs not enrolled in PACM
35.7.2 Calculating a Diversion Level
Every 60 seconds, PACM checks the transaction volume between the issuer and VisaNet

and compares it to the issuer's rated capacity. If the volume for a given minute is greater
than 1/60 of the rated hourly capacity, PACM invokes (or continues) transaction diversion
for the next minute.
The diversion level corresponds to the percentage by which transaction volume exceeds
the processor's rated capacity. PACM continuously monitors transaction volume and

capacity to ensure that it is diverting the optimum transaction volume and adjusts the
diversion level accordingly. Figure 35-2 illustrates how PACM calculates a diversion level.
Figure 35-2 PACM Calculation of Diversion Level
Diversion Table
Diversion Transaction
Target Amount
Volume – Capacity % Diversion-Eligible 0% $0
Diversion-Eligible Volume = Volume to Divert
0 – 5% $7
5 – 10% $12
Example
10 – 15% $17
Issuer capacity is 100 transactions per minute,
volume reaches 118 transactions per minute. 15 – 20% $23
Of these, 80 are eligible for diversion to STIP: 20 – 25% $29
118 – 100 25 – 30% $37
80 = 22.5%
30 – 35% $48
BASE I routes diversion-eligible transactions — —

below $29 to STIP. — —
— —
95 – 100% —
35.7.3 BASE I and SMS Diversion Tables

V.I.P. stores diversion levels in multiple PACM diversion tables. BASE I and SMS each
have separate PACM diversion tables.
PACM refers exclusively to the applicable diversion table during the initial diversion minute.
During each subsequent diversion minute, PACM monitors how close it has come to
diverting the targeted volume of transactions. PACM factors in this percentage to select
the diversion level for the next minute. This continuous monitoring reduces the effects of
transaction mixes that differ from the percentages in the diversion table.
35.7.3.1 BASE I Diversion Tables

For BASE I issuers, each region can define its own diversion tables. Table 35-1 lists BASE I
regional defaults for the six Visa regions:
1 = Visa U.S.A. (U.S.)
2 = Visa Canada (CAN)
3 = Visa Europe (VE)
4 = Asia-Pacific (AP)
5 = Latin American and Caribbean (LAC)

6 = Central and Eastern Europe, Middle East, and Africa (CEMEA)
Table 35-1 BASE I PACM Diversion Tables by Visa Region
Percentage
of Eligible
Diversion Level BASE I DIVERSION TABLES
Transactions
Diverted to STIP Dollar Value of Diverted Transactions (Eligible
if Below Listed Amount)
Regions 1
(U.S.), 2 (CAN), Regions 3 (VE),
5 (LAC) 6 (CEMEA) Region 4 (AP)
00 00 0 0 0
01 05 8 14 11
02 10 12 20 14
03 15 14 26 16
04 20 17 31 19
05 25 19 38 22
06 30 22 44 25

07 35 25 52 29
08 40 28 59 33
09 45 31 68 38
10 50 36 76 45
11 55 40 87 54
12 60 46 102 64
13 65 52 118 75
14 70 59 140
15 75 70 160 107
16 80 85 188 131
17 85 105 235 160
18 90 151 314 212
19 95 253 403 321
20 100 All All All
99,999 99,999 99,999
35.7.3.2 SMS Diversion Tables

SMS issuers can select their diversion table from one of the three listed in Table 35-2.
The “Visa SMS” column shows amount limits for Visa SMS transactions that are eligible for
diversion. The “SMS and Interlink” column shows amount limits for a mix of Visa SMS and
Interlink transactions. The “Interlink” column shows amounts for Interlink transactions.

As with the BASE I tables, each region can define its own tables. SMS issuers can also
select the diversion table for the processor. If issuers do not make a selection, PACM uses
established defaults. The “Visa SMS” column lists these defaults.
Table 35-2 SMS PACM Diversion Tables
Percentage
of Eligible
Diversion Level
Transactions SMS DIVERSION TABLES
Diverted to STIP Dollar Value of Diverted Transactions (Eligible
if Below Listed Amount)
SMS and
Visa SMS Interlink Interlink
00 00 0 0 0
01 05 7 6 4
02 10 10 8 5
03 15 13 11 6
04 20 15 13 7
05 25 17 15 8
06 30 18 16 9
07 35 20 18 10
08 40 22 20 11
09 45 24 22 13
10 50 26 24 14
11 55 29 26 16
12 60 32 29 17
13 65 36 33 20
14 70 40 37 22
15 75 47 42 24
16 80 54 50 27
17 85 66 60 33
18 90 90 80 42
19 95 155 135 54
20 100 All All All
35.7.3.3 Stand-In Processing of PACM-Diverted Transactions

STIP processes PACM-diverted transactions in almost the same way as it processes
non-PACM-diverted transactions. This processing can include:

• Performing modulus-10 checking on the account number.

• Checking the exception file for negative account information.
• Performing personal identification number (PIN) and Card Verification Value (CVV)
verification, as required.
For information about PIN verification, refer to Chapter 33, PIN Verification Service (PVS).
For information about CVV, refer to Chapter 24, Card Verification Value (CVV) Service.
For PACM diversion to STIP, V.I.P. considers the issuer unavailable. V.I.P. performs testing
against issuer-unavailable limits for all members that participate in PCAS. For non-PCAS
members (SMS only), V.I.P. performs edits against SMS daily activity. V.I.P. declines or
refers the transaction depending on activity test results.
IMPORTANT
When BASE I issuers do not select the between-limits activity checking option, STIP does not perform
issuer-available activity checking for transactions below their issuer limits. Visa recommends that all PACM
participants use between-limits activity checking and review their activity checking parameters. Issuers
may also want to set issuer limits to zero.

PACM uses the following three fields to convey diversion information to participating
issuers in BASE I 0120 advices and in SMS 0220 advices.

Code 2 in this field indicates that the transaction amount is below the sliding dollar

amount.
Field 44.6—PACM Diversion Level

The value in this field indicates which of the 20 diversion levels PACM used at the time
the transaction was processed. Each diversion level indicates by what percentage the
volume exceeded the issuer's processor capacity.
Field 44.7—PACM Diversion Reason Code

The value in this field indicates the reason PACM diverted the transaction to STIP.
Currently, the only diversion reason code available is A (volume exceeded capacity).

SMS 0220 STIP advices also contain this field, which uses code 9022 to indicate that
PACM diverted the transaction to STIP.
Refer to V.I.P. System BASE I Technical Specifications, Volume 1 for more information
about these fields.

For further information about the PACM service, refer to V.I.P. System BASE I Processing
Specifications.


Chapter 36 Positive Cardholder Authorization Service (PCAS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
IN BRIEF 36-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
Key Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-3
Positive Cardholder Authorization Service (PCAS)

SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
WORKS.. . . . . .36-
HOW POSITIVE CARDHOLDER AUTHORIZATION SERVICE (PCAS) WORKS 36-44
Merchant Category Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
Merchant Category Group Activity Limits. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .36-7
Total Purchase and Total Cash Activity Limits. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .36-7
Issuer-Available- and Issuer-Unavailable-Activity Limits. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .36-7
Count, Amount, and 4-Day Multiplier Activity Limits. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .36-8
Mandated Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-8
Mandatory Minimum (T&E) Issuer Limits. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .36-8
Mandatory Minimum Non-T&E Issuer Limits. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .36-9
Mandatory Minimum Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .36-9
Applying Appropriate Issuer and Activity Limits: Issuer-Specified or
Visa-Mandated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-9
Overriding Mandatory Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .36-10
Mandatory Zero MOTO Issuer Limit. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .36-10
Advice Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-10
Activity Checking and Accumulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-10
Cardholder Risk Levels and Individual Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-11
Defining Risk-Level Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-12
Multiple Limit Selection Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-12
Random Selection Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-13
BIN Blocking and Country Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-13
Risky Countries and Country-to-Country Embargoes. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .36-13
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
14

Chapter 36
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-
14

Chapter 36 Positive Cardholder Authorization Service (PCAS)
36.1 IN BRIEF
Issuers use the Positive Cardholder Authorization Service (PCAS) to establish routing
parameters such as issuer, advice, and activity limits to route transactions to the issuer
or to STIP using issuer limit dollar amounts.
If V.I.P. routes the transaction to the issuer, the issuer provides the response. If V.I.P.

routes the transaction to STIP, stand-in authorization options and PCAS processing limits
(selected by the issuer), determine the response.
Refer to Appendix A in V.I.P. System BASE I Processing Specifications for mandatory

minimum (MM) limits that can apply to international or domestic transactions in a given
region.
PCAS is available to issuers in all Visa regions.
PCAS is available to BASE I System issuers.

BASE I
SMS
BASE I only
I Participation in PCAS is optional for issuers. PCAS is available for all card
types, including private label cards.
Issuer
36.2.1 Key Terms

These key terms are essential for understanding how PCAS works:
Limit—This limit is the transaction amount that determines whether a transaction

Issuer Limit—
is processed by BASE I STIP or by the issuer processor.
Limit—This limit is the transaction amount that controls accumulated cardholder

Activity Limit—
spending.
Limit—This limit is the transaction amount that determines whether STIP performs
Advice Limit—
optional functions when processing transactions that are below the issuer limit.


The Positive Cardholder Authorization Service (PCAS) provides options to issuers to
control risk, cardholder service, and authorization volume and expense by:
• Switching higher-risk transactions to the issuer.
• Processing low-risk transactions in stand-in processing.
• Providing stand-in processing during issuer-unavailable conditions.
PCAS makes three kinds of decisions:
Decision—PCAS-established limits determine whether V.I.P. is to

Initial STIP or Switch Decision—
route the transaction to the issuer for processing, based on the transaction amount and
merchant type. For international transactions, another routing factor can be whether the
system files list the acquirer country as a risky country.
Decision—PCAS-established limits determine

Issuer-Available Approve or Forward-Refer Decision—
whether V.I.P. is to approve or forward-refer (switch) the transaction to the issuer, based on
the credit or fraud risk of the transaction being processed.
Decision—PCAS-established limits determine

Issuer-Unavailable Approve or Refer Decision—
whether V.I.P. is to send an approval or referral response to the acquirer, based on whether
the customer service risk of an inappropriate referral is greater than the credit or fraud
risk of an inappropriate approval.

All BASE I issuers can participate in PCAS. PCAS issuers must specify issuer limit amounts
for specific merchant category groups (MCGs), at minimum for each of the 11 Purchase
and Cash MCGs. They must also specify Total Purchase and Total Cash activity limits.
These limits, however, can be set to zero so issuers can receive all transactions if they
are available. In addition to the limits and processing factors mandated for PCAS, issuers
can also specify additional limits such as individual cardholder account daily and monthly
spending limits, cardholder risk levels, and random selection parameters. All limits are
specified in U.S. dollars.
36.4.1 Testing
Testing is optional for authorization processing. The VisaNet Certification Management
Service (VCMS) provides testing assistance. Members can contact their Visa

Service monitoring is not available for PCAS.

PCAS operates on 0100 authorization requests and their reversals.
36.6 HOW POSITIVE CARDHOLDER AUTHORIZATION SERVICE (PCAS) WORKS

PCAS compares transaction characteristics and cardholder spending activity to
issuer-specified parameters when making routing and STIP decisions. PCAS parameters
are specified at the BIN level. Certain parameters can also be specified at the account level.
PCAS provides issuers with options to define which transactions VisaNet should forward
and which transactions should be approved in issuer-available or issuer-unavailable

Chapter 36 How Positive Cardholder Authorization Service (PCAS) Works
stand-in processing. Transaction characteristics for balancing the cost, risk, and customer
service implications are merchant type, account activity, and cardholder risk. The PCAS
capabilities that can define these characteristics are:
• Merchant Category Groups
• Issuer Limits
• Activity Limits
• Mandatory Limits
• Advice Limits
• Activity Checking and Accumulation
• Cardholder Risk Levels and Individual Limits

• Random Selection Factors
• BIN Blocking and Country Restrictions, including Risky Countries
Along with the transaction type, merchant category, geographical jurisdiction, and issuer
processing center availability, PCAS uses issuer limits to route transactions to the issuer or
to STIP. This routing capability is accomplished by categorizing all authorization requests
into one of the following categories:
Transactions—Transactions in which the transaction

Category A: Below-Advice-Limit Transactions—
amount is less than the advice limit. Verification-only requests (address or account)
are placed in Category A.
Category B: Between-Limits Transactions—

Transactions—Transactions in which the transaction amount
is equal to or greater than the advice limit but less than the issuer limit. Depending on
issuer specifications, PCAS sends Category B transactions to STIP.
Transactions—Transactions in which the transaction

Category C: Above Issuer Limit Transactions—
amount is equal to or greater than the issuer limit. PCAS sends Category C transactions
to the issuer if available (“force-routing”).
EXAMPLE
Examples of Category C transactions are Visa Infinite and Visa Signature Preferred transactions with
amounts between USD$100,000.00 and USD$500,000.00; Visa Distribution transactions; United Kingdom
(U.K.)-domestic transactions with address data; and ATM balance inquiry transactions.
Issuer-unavailable conditions result in PCAS sending the transaction to STIP where,

depending on issuer specifications, STIP declines the request with a issuer-defined or
default response code.
For instance, if the issuer sets up the BIN default response code for the Airlines/Travel
MCG with a non-approval response code, such as code 91 (issuer unavailable), STIP does
not perform PCAS activity and the transaction has the chance to bypass the approval
due to PCAS activity processing.
Each category implies a distinct application of tests using issuer-specified, and in

some cases, Visa-specified limits. As a rule, in addition to Category A transactions,
STIP processes transactions in which the transaction amounts are less than the issuer limit;
exceptions include ATM transactions and transactions designated as risky.

When the issuer processor is not available, transactions with amounts above the issuer
limit are also processed in STIP. STIP declines these transactions under certain conditions.
Rules for specific card programs can override the issuer limit.
IMPORTANT
V.I.P. sends all risky transactions (for instance, electronic commerce online gambling transactions) to the
issuer. If the issuer is unavailable, STIP processes them according to issuer-defined parameters.
36.6.1 Merchant Category Groups

Merchant category groups (MCGs) are collections of similar merchant types. Visa has
defined 11 MCGs to allow issuers to specify processing parameters according to the varying
risk and customer service implications of different merchant or transaction environments.
The 11 MCGs can be separated into two broad transaction categories: Purchase and Cash.
Purchase Cash
• Commercial Travel • ATM
• Lodging • Quasi-Cash
• Auto Rental • Other Cash
• Restaurant
• Medical
• Mail Order/Telephone
• Risky Purchase
• Other Purchase
Each MCG has its own set of related merchant category codes (MCCs) that designate a
specific business or service. The MCC appears in the authorization request message, and
V.I.P. uses it, along with the issuer-specified STIP parameters, to determine authorization
routing and processing.
NOTE
6011),
If the processing code in field 3 is 01 (cash disbursement) and Field 18—Merchant Type is not ATM (6011
6011
V.I.P. assigns the transaction to the Other Cash MCG.
36.6.2 Issuer Limits

Issuer limits can be established for each MCG described in the previous section.
V.I.P. uses the issuer limit in the initial switch or STIP decision. V.I.P. routes transactions to
issuer processors for approval or denial decisions when transaction amounts are greater
than or equal to the issuer limit. STIP processes transactions with transaction amounts
less than the issuer limit. When the issuer processor is not available, STIP processes
transactions with amounts above the issuer limit.
36.6.3 Activity Limits

Activity limits are amounts that allow issuers to control accumulated cardholder spending.
Issuers can specify cardholder activity limits in several different areas to customize risk
control and customer service according to varying transaction characteristics. These
areas include:
• Merchant category group
• Total Purchase and Total Cash
• Issuer available and issuer unavailable

• Number of approved transactions for this account (count)

• Total value of approved transactions for this account (amount)
• Activity over one day and over four days (4-day multiplier)
Refer to the “Issuer Specification Requirements for BIN-Level Issuer and Activity Limits”
table in chapter 4 of V.I.P. System BASE I Processing Specifications for the requirements
for establishing issuer limits and activity limits. The table also shows the relationship
between issuer-available and issuer-unavailable activity limits at the BIN level.
36.6.3.1 Merchant Category Group Activity Limits

Issuers may optionally specify activity limits for the following merchant category groups:

• Commercial Travel
• Lodging
• Automobile Rental
• Restaurant
• Mail Order/Telephone Order (MOTO)
• Risky Purchase
• ATM Cash
V.I.P. uses these limits in addition to the Total Purchase limits when checking activity.
For detailed information on MCG activity limits, refer to “Activity Checking and
Accumulation” in this chapter.
36.6.3.2 Total Purchase and Total Cash Activity Limits

Issuers must establish activity limits for Total Purchase and for Total Cash. If issuers
have not set activity limits at the MCG level, V.I.P. uses Total Purchase activity limits and
Total Cash activity limits.
36.6.3.3 Issuer-Available- and Issuer-Unavailable-Activity Limits

The issuer also can set different activity limits for issuer-available and issuer-unavailable
processing.
Limits—V.I.P. uses these activity limits when the issuer processor is

Issuer-Available Limits—
available. To be considered available, the issuer must be signed on to the network.
The available limits allow issuers to set normal activity limits for STIP processing.
NOTE
If STIP processes the transaction and the transaction fails an activity limit check, V.I.P. forwards the
transaction to the issuer for approval. If V.I.P. does not receive a response from the issuer, V.I.P. completes
STIP processing using issuer-available PCAS parameters.
Limits—These activity limits apply to transactions processed by STIP

Issuer-Unavailable Limits—
when the center is unavailable for one of the following reasons:
• Center is not linked to the network.
• Center is signed off.
• Communications link is down.
• Number of messages awaiting delivery to the processor exceeds a system-defined limit.
• Issuer processor fails to respond within the Assured Transaction Response (ATR)
time-out period.

Using both available and unavailable limits allows the issuer to choose one set of limits
when the center is operating normally and another set of higher limits when the issuer
processor is unavailable.
Transactions that fail issuer-available STIP are forward-referred (switched) to the issuer.
The advantage of conservative available limits is greater risk control. The consequence is
increased transaction volume at the host for the relatively small number of transactions that
exceed limits. Thus, issuers may choose relatively conservative available limits.
When transactions fail issuer-unavailable activity checking, V.I.P. sends a referral

response to the acquirer (assuming no other STIP test generates a higher priority
response). The advantage of more liberal activity limits is that fewer referrals are sent
to the acquirer. This reduction in traffic results in improved cardholder service and less
demand on the issuer's customer service operations or referral center. The disadvantage is
increased credit and fraud risk. The fraud and credit risk is lessened, however, because
issuer-unavailable transactions should be relatively infrequent and difficult to predict. For
these reasons, issuers may choose more generous issuer-available limits.
36.6.3.4 Count, Amount, and 4-Day Multiplier Activity Limits

For most MCGs and for Total Purchase and Total Cash, the issuer can specify both count
and amount activity limits.
Limit—This limit applies to the current day's transactions. The amount can
1-Day Count Limit—
be any integer value between 0 and 255
255.
Limit—This limit applies to the current day's transactions. The amount can
1-Day Amount Limit—
be any U.S. dollar amount between $0.00 and $65,535.00.
Multiplier—The 1-day count and amount limits are multiplied by the 4-day multiplier
4-Day Multiplier—
to determine the 4-day count and amount limits. The multiplier can be any value between 1
and 4, in increments of .05. Fractional results on the calculation of the count limit are
raised to the next higher integer.
EXAMPLE
A 1-day count of 2 times a 4-day multiplier of 2.1 would yield a 4-day count of 4.2, which would be rounded
up to 5.
36.6.4 Mandated Minimum Limits

In addition to the issuer limits and activity limits specified by the issuer (described in the
previous sections), Visa requires the following mandatory issuer and activity limits for
PCAS participants.
NOTE
The V.I.P. System does not apply mandatory minimum issuer or activity limits to debit or prepaid card
transactions.
36.6.4.1 Mandatory Minimum (T&E) Issuer Limits

Visa International Operating Regulations require mandatory minimum issuer and activity
limits for international transactions within the Travel & Entertainment (T&E) merchant
category groups, which include Commercial Travel, Lodging, and Auto Rental.

The issuer may specify T&E limits different from the mandated T&E limits. V.I.P. uses the
higher of the mandated limits or the issuer limits for international transactions. These limits
are defined in V.I.P. System BASE I Processing Specifications.
36.6.4.2 Mandatory Minimum Non-T&E Issuer Limits

V.I.P. uses the lower of the mandatory minimum issuer limits or the issuer limits for MOTO
transactions. V.I.P uses the higher of the mandated limits or the issuer limits for other
transaction categories such as Purchase or Cash.
36.6.4.3 Mandatory Minimum Activity Limits

When STIP checks a cardholder's activity limits, it uses the higher of the issuer-specified

activity limits or the mandatory minimum (MM) activity limits. MM activity limits are defined
in Appendix A of V.I.P. System BASE I Processing Specifications.
36.6.4.4 Applying Appropriate Issuer and Activity Limits: Issuer-Specified or Visa-Mandated

V.I.P. uses a transaction’s transaction type to determine which issuer or activity limit
applies. Depending on the risk associated with the transaction type, V.I.P. chooses the limit
with the greater or larger threshold amount. Table 36-1 summarizes V.I.P. limit application.
Table 36-1 Choosing Issuer-Specified or Visa-Mandated Limits
For this Issuer-specified Visa-Mandatory

To determine the Transaction Issuer Limit Minimum Issuer Use the
following limit... Type Limit following limit
Issuer Limit Visa Mandatory
T&E Lower Higher Minimum Issuer
Limit
Issuer-specified
T&E Higher Lower
Issuer Limit
Issuer-specified
MOTO Lower Higher
Issuer Limit
Visa Mandatory
MOTO Higher Lower Minimum Issuer
Limit
Visa Mandatory
Purchase and
Lower Higher Minimum Issuer
Cash
Limit
Purchase and Issuer-specified
Higher Lower
Cash Issuer Limit
Activity Limit Visa Mandatory

Lower Higher Minimum Activity
All transactions Limit
Issuer-specified
Higher Lower
Activity Limit
NOTE
Activity limits can be overridden by limits stored in the Cardholder Database or in the exception file.

36.6.4.5 Overriding Mandatory Minimum Limits

Depending on regional rulings, issuers can request that their BINs be exempted from
domestic and international mandatory minimum Limits. However, exemptions apply to both
domestic and international limits; issuers cannot request an exemption from one but not
the other. As with international mandatory minimum limits, the higher of issuer-specified
or overridden U.S.-domestic limits apply when issuers do not request exemption.
V.I.P. System BASE I Processing Specifications defines these limits.
36.6.4.6 Mandatory Zero MOTO Issuer Limit

If a region mandates a zero issuer limit for all MOTO transactions, this mandate overrides
any issuer-specified issuer limits.
36.6.5 Advice Limit

In addition to the optional and mandatory issuer and activity limits, PCAS parameters
include an advice limit. An advice is a record of stand-in processing actions taken on
the issuer's behalf. The advice limit is a threshold for performing advice creation and
activity checking. Transactions below this limit receive neither activity checking nor advice
creation. Transactions processed in STIP that are above this limit receive either activity
checking, advice creation, or both, depending on issuer specifications.
Issuers specify a single advice limit for each BIN. Regardless of issuer specifications, an
advice limit of zero is in effect for all Cash and MOTO transactions.
36.6.6 Activity Checking and Accumulation

As a general rule, if MM activity limits apply, V.I.P. performs activity checking and
accumulation using the greater of the MM activity limits or the issuer-specified activity limits.
V.I.P. performs activity checking based on the advice limit as described in the previous
section. Accumulators are running totals of transactions approved in STIP. While issuers
specify activity limits at the BIN level, V.I.P. maintains accumulators at the account level.
IMPORTANT
The following description of activity checking and accumulation assumes that the combination of issuer
specifications and transaction characteristics would result in activity checking being performed, and, that the
transaction passed all other STIP tests.
A transaction passes activity checking if adding the current transaction to the accumulators
would not cause the accumulators to exceed the limits. Failing any of the limits (1-day
count, 1-day amount, 4-day count, 4-day amount) prevents STIP approval. Accumulators
are incremented only when the transaction passes all STIP tests, and STIP sends
an approval to the acquirer. Transactions approved by the issuer, including those
forward-referred from issuer-available STIP, do not increment accumulators.
V.I.P. compares the activity accumulators to the appropriate available or unavailable limits,
depending on processing conditions.
NOTE
V.I.P. uses the same set of accumulators for both issuer-available and issuer-unavailable processing.

Issuer-available activity checking differs from issuer-unavailable activity checking in the

following ways:
• Which set of limits (available and unavailable) is used.
• The consequences of failing activity checking (forward-referring when the issuer is
available, sending a referral response to the acquirer when the issuer is unavailable).
In all other respects, the same activity checking and accumulation rules apply.
Accumulation—V.I.P. checks Total Purchase activity

Total Purchase Activity Checking and Accumulation—
limits when the issuer has not specified limits for the Non-Cash MCG.

Accumulation—If mandatory minimum
Travel and Entertainment Activity Checking and Accumulation—
limits apply, V.I.P. checks and accumulates activity limits using the greater of
issuer-specified or mandatory minimum activity limits. If mandatory minimum activity limits
do not apply, V.I.P. checks and accumulates activity limits using the issuer-specified limits.
If MCG limits do not apply, or if activity checking failed at the MCG level, V.I.P. checks and
accumulates Total Purchase activity limits.
Accumulation—When specified, V.I.P.

MOTO and Risky Purchase Activity Checking and Accumulation—
checks and accumulates MCG-level activity limits. If the issuer has not specified MCG-level
limits, V.I.P. checks and accumulates Total Purchase activity limits.
Accumulation—V.I.P. checks
Medical and Other Purchase Activity Checking and Accumulation—
the activity limits that issuers establish for Total Purchase and updates the activity
accumulators. MCG-level activity limits are not available for these MCGs. For transactions
that fall within the Other Purchases MCG, issuers can instruct STIP through CORE settings
to compare the mandatory minimum activity limit with the issuer-specified Total Purchase
activity limit and select the higher of the two for checking the transaction's activity. When
activity checking is completed, V.I.P. updates the activity accumulators accordingly.
Accumulation—V.I.P. checks and accumulates Total

Total Cash Activity Checking and Accumulation—
Cash activity limits for Quasi-Cash and other Cash transactions. MCG-level activity limits
are not available for these MCGs.
Accumulation—When limits are specified, V.I.P. checks

ATM Cash Activity Checking and Accumulation—
and accumulates activity limits at the MCG level.
NOTE
For more information about activity checking and accumulation, refer to V.I.P. System BASE I Processing
Specifications.
36.6.7 Cardholder Risk Levels and Individual Limits

Cardholder risk levels allow issuers to tailor authorization parameters according to varying
risk control and customer service requirements for different cardholder profiles within a
single BIN. By assigning cardholders one of up to four cardholder risk levels (A, B, C, or D),
issuers can further control V.I.P. routing and stand-in processing.
Issuers establish the default risk level for the BIN, typically risk level C.

NOTE
Risk level D cannot be used for the BIN default.
Issuers that choose to use risk levels must also specify processing parameters for the
non-default risk levels. Issuers may choose to specify more restrictive parameters for
higher risk accounts (typically risk levels B and D). They may also choose to specify more
generous parameters for their premier accounts (typically risk level A).
Issuers must also assign accounts non-default risk levels by one of two methods:
• By adding the account to the risk level file in the V.I.P. Cardholder Database. See the
Cardholder Database Overview chapter in this manual for basic information about the
risk level file.
• By encoding the risk level on Track 1 of the magnetic stripe.
IMPORTANT
Visa does not recommend the latter option because of a relatively high percentage of transactions that
do not contain Track 1 data.
A risk level specified in the risk level file takes precedence over a risk level encoded on
the magnetic stripe. If a risk level is not specified in either the transaction data or in the
Cardholder Database, V.I.P. uses the default risk level file parameters for the BIN.
36.6.7.1 Defining Risk-Level Limits

Issuers can specify the following parameters at the risk level:
• Issuer limits (by MCG)
• Activity limits (by MCG)
- Count and amount
- 4-day multipliers
- Issuer available and issuer unavailable limits
• Between-limits random selection factor
• Below-advice-limit random selection factor
• Between-limits advice creation and activity checking options
Issuers can also establish cardholder-specific activity limits in the exception file in the
Cardholder Database, which can contain both positive and negative information in the form
of action codes. These limits take precedence over risk level limits.
36.6.7.2 Multiple Limit Selection Rules

When limits are specified at multiple levels, V.I.P. uses the following hierarchy:
1. Account-specific limits
2. Risk level D limits
3. Mandatory minimum limits (when applicable and when greater than issuer-specified
limits)
4. BIN (default risk level) limits
For further information about multiple limit selection rules, refer to V.I.P. System BASE I
Processing Specifications.

36.6.8 Random Selection Factors

Issuers can use random selection factors to reduce the predictability of STIP. Using
random selection, an issuer can specify a portion of issuer traffic for additional scrutiny.
The process is weighted in favor of selecting higher-amount transactions to counteract
authorization predictability based on dollar values alone. Issuers can specify separate
random selection factors for transactions that are:
Limit—Issuers designate a random selection factor (a certain percentage)

Below the Advice Limit—
for below-advice-limit transactions. STIP then selects that percentage of the transactions
with amounts below the advice limit and processes them as if they were between the

advice and issuer limits. V.I.P. processes the remaining transactions as below-advice-limit
transactions. When the advice and issuer limits are equal, V.I.P. sends randomly selected
below-advice-limit transactions to the issuer.
Limit—Issuers designate a random selection factor

Between the Advice Limit and Issuer Limit—
(a certain percentage) for between-limit transactions. STIP then selects that percentage
of the transactions with amounts between the advice limit and the issuer limit and sends
them to the issuer.
36.6.9 BIN Blocking and Country Restrictions

Issuers can block entire BINs as well as certain transaction types. In addition to blocking
an entire BIN, issuers can block BINs for domestic cash transactions, international cash
transactions, or both. At the BIN level, issuers can specify that their cards can be used:
• In all countries
• Only in the country of issuance.
• Only in a selected list of countries.
• In all countries except a selected list of countries.
36.6.9.1 Risky Countries and Country-to-Country Embargoes

Issuers can specify that requests originating in risky acquirer countries be routed
immediately to them when they are available. Risky country transactions switched to
the issuer bypass mandatory minimum limits such as those for travel and entertainment
(T&E) transactions. Risky country transactions also bypass Positive Authorization Capacity
Management (PACM) Service diversion and any issuer-specified limits.
If issuers are unavailable, they can have STIP either respond immediately with predefined
response codes (referral or decline), or continue processing according to the issuers'
normal processing parameters. Up to 20 countries can be identified as high-risk in the
Risky Countries Table in the system files. The available risky country response codes are
00, 05
A (Approval), D (Decline), or R (Referral). V.I.P. translates these codes to 00 05, and 01
01,
respectively, before V.I.P. forwards the response to the acquirer.
NOTE
V.I.P. searches the Country Exclusion List before it searches the Risky Countries Table. If a country is listed
in both tables, the country exclusion processing specifications take precedence.
Issuers can block transactions in or between embargoed countries, for instance, between
acquirers in country A and issuers in country B. In addition to using embargo settings
for Visa cards, they can be used for other card products such as American Express
or MasterCard.


This section describes the key fields associated with PCAS.

When an authorization advice is created, STIP generates a reason code explaining why
it processed the transaction. For instance, reason code 2 indicates that the transaction
amount is below the issuer limit for PCAS processing.

For further information about PCAS, refer to the following documents:

Chapter 37 Preauthorized Payment Cancellation Service (PPCS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
IN BRIEF 37-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
HOW PREAUTHORIZED PAYMENT CANCELLATION SERVICE (PPCS) WORKS

WORKS.. . 37-
37-55
Updating the Cardholder Database Portfolio File (PF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-5
Preauthorized Payment Cancellation Service (PPCS)

File Edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-6
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
FOR MORE INFORMATION

INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-
37-99


Chapter 37 Preauthorized Payment Cancellation Service (PPCS)
37.1 IN BRIEF
Issuers use the Preauthorized Payment Cancellation Service (PPCS) to stop payments on
preauthorized payment transactions, such as those for recurring or installment payments.
Participating issuers place stop-payment orders in the Portfolio File (PF) in the V.I.P.
Cardholder Database (CDB). When acquirers submit a preauthorized payment transaction,
V.I.P. checks the database, and if it encounters a stop-payment order for that account
number, it declines the request.
PPCS enables members to meet Federal Reserve Regulation E requirements, which

govern electronic funds transfers and provide Visa U.S. region cardholders with certain
dispute rights for check card transactions. Members that issue check cards must comply
with the terms of those regulations.

Preauthorized Payment Cancellation Service (PPCS) is available to members
in all Visa regions.
BASE I
SMS PPCS is available both to BASE I System users and to Single Message System
(SMS) users.
BASE I and SMS
I
Participation in PPCS is optional for issuers in all regions.
Issuer
Participation in PPCS is optional for acquirers and for merchants in all regions.
PPCS is not an acquirer service, and acquirers and merchants have no ability
A to determine if their transactions are checked by PPCS. If a merchant deals in
preauthorized-type transactions, then any of those transactions is potentially
eligible for PPCS checking on behalf of participating issuers.
Acquirer
IMPORTANT
All acquirers in all regions must be able to receive PPCS response codes.

PPCS enables participating issuers to stop payments on preauthorized transactions
such as those for recurring or installment payments. The initial transaction can be

card-present (face-to-face POS) or card-not-present (mail order or telephone order [MOTO]

or electronic-commerce). Merchants automatically initiate subsequent recurring electronic
funds transfers (EFTs) without notifying the cardholder beforehand or requiring the
cardholder to be present.
Participating issuers place stop payment instructions from their cardholders in the Portfolio
File in the Cardholder Database (CDB) using 0302 file maintenance request messages.
Issuers place an action code in Field 91—File Update Code to indicate the action V.I.P. is
to take with the file record: add, delete, replace, or inquire.

Issuer participation in PPCS is optional and is established at the BIN level. Issuers must
successfully complete testing that they can support the new response codes and the new
formats for file maintenance transactions.
Acquirers that support preauthorized transactions must be prepared to support the new
response code values in authorization messages (and return reason code values for
BASE II clearing transactions).
Issuers
BASE I and SMS issuers must successfully complete testing that they can support changes
to 0302 and 0312 message formats for the stop-order codes. The 0302 message contains
information for the CDB about the cardholder, the merchant, and the preauthorized
payment.
Issuers also must successfully complete testing that they can receive the new response
codes in 0120 and 0220 advices. V.I.P. uses these advices to notify issuers that
acquirer-initiated preauthorized payment authorizations were declined.
Acquirers
BASE I and SMS acquirers must modify their systems to recognize the PPCS decline
R0, R1
response codes R0 R1, and R3
R3, in 0110 authorization and 0210 financial response
messages.
37.4.1 Testing
The VisaNet Certification Management Service (VCMS) is available for testing. Members
can contact their Visa representatives for more information.

Service monitoring is not available for PPCS.

The following messages pertain to PPCS.
0302: File Maintenance Request—

Request—Only format 2 0302 file maintenance requests are valid
for accessing or for updating the PPCS format 2 Portfolio File. Field 91—File Update Code
indicates the action required by the issuer: add, delete, replace, or inquire. Field 101—
File Name must be present and must contain the file name PF for PPCS updates.
Response—This message is the response to an 0302 file

0312: File Maintenance Response—
maintenance request.

Chapter 37 How Preauthorized Payment Cancellation Service
(PPCS) Works
Acquirers submit preauthorized payment transactions as 0100 authorization or 0200

financial requests. Issuers receive advices for declined transactions.
37.6 HOW PREAUTHORIZED PAYMENT CANCELLATION SERVICE (PPCS) WORKS

V.I.P. checks the Portfolio File in the CDB when it receives an 0100 or 0200 automatic
payment request from an acquirer or a merchant and uses the results to determine
authorization decisions. V.I.P. supports the following types of cardholder-initiated stop
payment commands:
• R0
R0—Stop specific payment
• R1
R1—Revocation of Authorization Order
• R3
R3—Revocation of All Authorizations Order
• C2
C2—Revocation of All Authorizations Order (used only by BASE II System users)
If V.I.P. does not find a stop-payment code, it continues with normal request processing.
If V.I.P. encounters a stop-payment order, it routes the request to STIP. STIP declines
the request, using the stop-payment code (R0R0,
R0 R1R1, or R3
R3) from the Portfolio File record
as the response in Field 39—Response Code. A value of 4 in Field 44.1—Response
Source/Reason Code in responses and in issuer advices indicates the STIP action. SMS
0220 advices include the value 9031 in Field 63.4—STIP/Switch Reason Code.
37.6.1 Updating the Cardholder Database Portfolio File (PF)

The Portfolio File (PF) in the CDB contains the stop-payment orders for preauthorized
payments. The stop-payment orders are stored as format 2 tag-length-value (TLV)
records. Issuers use online 0302 requests to update the PF; V.I.P. does not support batch
processing.
Depending on the action specified in PF update requests, 0302 messages contain the
following information:
• The account number (in field 2)
• A transaction identifier (TID). If no TID is included in the 0302 request, V.I.P. assigns
one, and inserts it in field 62.2 in the 0312 response. See “Key Fields Glossary” in this
chapter for complete message field details.
• The type of stop order (in field 127.PF).
• The acquirer institution country code (in field 19).
• The card acceptor identification code (in field 42), the card acceptor name/location (in
field 43), or the merchant verification value (in field 62.20). The PF record must contain at
least one of these three data elements to sufficiently identify the merchant.
NOTE
V.I.P. uses the first nine characters in field 43 in 0100 and 0200 request messages for message matching.
IMPORTANT
Fields 42, 43, or 62.20 cannot be present in a 0302 add (field 91 contains 1) or replace (field 91 contains 4)
R3 request (revocation of all authorizations order).
• The PF record can optionally include the amount, the cardholder’s name, the merchant’s
name, and the merchant account number. V.I.P. does not use these fields, if present,
for message matching.

V.I.P. checks on issuer participation to prevent issuers that are not properly configured for
PPCS from adding PPCS records to the CDB. If the issuer sending in an 0302 maintenance
transaction with code PF in field 101 and code 1 (add), 3 (delete), 4 (replace), or 5 (inquiry)
in field 91, V.I.P. checks CORE to see if the issuer is a participant. If not, V.I.P. declines
the transaction with code 06 (error) in field 39 and inserts error code 0684 (BIN does not
participate in service) in field 48, Usage 1B.
The fields in an 0100 or 0200 request must match the account’s PF record fields except for
field 42, field 43, and field 62.20. Only one of these fields must match the corresponding
field in the authorization or financial request. (V.I.P. only matches field 43 on the first
nine characters.)
37.6.1.1 File Edits

Table 37-1 lists the V.I.P. edits for PPCS 0302 file maintenance messages. Field 48—
Card Authentication Results Code contains the error codes in 0312 responses.
Table 37-1 Portfolio File Error Codes
Error Code Condition

0586 An R3 0302 add or replace message includes
field 42, field 43, or field 62.20. These fields
cannot be present in an R3 message.

0588 The total length of the TLV fields do not match
the value in the length field in the message.
The TLV fields’ total length must match the
message’s field length value.
0589 An R0 or R1 0302 add or replace message
does not include field 42, field 43, or field 62.20.
R0 and R1 messages must include these fields.
0590 For 0302 delete or replace messages, field 62.2
is not present. The TID must be included in
delete or replace messages.
0591 Field 19 is required in 0302 messages
for R0 and R1 stop-payment codes. The
field is optional in 0302 requests for the R3
stop-payment code.
0592 For 0302 add and replace messages, the
DF11. The stop-order
stop-order type is not DF11
type DF11 is required in all add and replace
messages.

This section describes key PPCS matching fields for the 0302 online file maintenance
requests and for the 0100 authorization or 0200 financial requests.
Field 2—Primary Account Number

This field is required unless the account number is in Field 102—Account Identification 1
or in Field 103—Account Identification 2.


If provided, the amount in an 0100 or 0200 request must match the amount in the PF
record exactly; otherwise, V.I.P. rejects the message.
Field 42—Card Acceptor Identification Code

This field identifies the merchant to which the recurring payments are being made.
Field 42 is required if:
• Field 91—File Update Code contains 1 (add) or 4 (replace), and
• Field 43—Card Acceptor Name/Location or Field 62.20—Merchant Verification Value
(MVV) is not present.
Field 42 is not allowed in 0302 requests containing an R3 stop-payment code.
Otherwise, the field is conditional in 0302 add or replace requests.

This field contains the merchant name. The field with the merchant name is required if:
• Field 42—Card Acceptor Identification Code and Field 62.20—Merchant Verification
Value (MVV) are not present.

Field 43 is not allowed in 0302 requests containing an R3 stop-payment code.

For audit trail purposes, V.I.P. assigns a unique transaction identifier (TID) in field 62.2
to all transactions. The TID is returned in the 0312 responses and is required in all
subsequent 0302 delete (field 91 contains 3), replace (field 91 contains 4), or inquiry
(field 91 contains 5) messages.
Field 62.20—Merchant Verification Value (MVV)

This field contains the MVV assigned to merchants. The field is required if:
• Field 42—Card Acceptor Identification Code and Field 43—Card Acceptor
Name/Location, are not present.
Field 62.20 is not allowed in 0302 requests containing an R3 stop-payment code.
IMPORTANT
Acquirers must provide the MVV in all authorization, clearing, and exception-item messages if the
merchant has an MVV assigned. Issuers must retain and return the MVV in all exception items.
Field 73—Date, Action

This field contains the record purge date. It is required in 0302 add (field 91 contains 1)
and replace (field 91 contains 4) requests. It is not required in delete (field 91 contains 3)
or inquiry (field 91 contains 5) requests.
Field 101—File Name

This field is required in 0302 requests and must contain PF for the format 2 Portfolio File.
Field 127.PF—Portfolio File (PF)

Field 127.PF is in an ISO-based tag-length-value (TLV) format based on Organization

for Standardization (ISO) standards. The layout is defined as follows:
• The tag field contains a 2-byte hexadecimal code that identifies the content of the
value field.
• The length field is a 1-byte field that defines the length of the value position.
• The value field is a variable length field that contains the requested data.
Table 37-2 contains field 127.PF data elements.
Table 37-2 PF Data Elements for Field 127
Position Name Length Position Description

Field 127 Length 1 byte, binary No change.
Dataset ID 1 byte, binary 1 Must be:
hexadecimal 69
Dataset Length 2 bytes, binary 23 Variable, depending
on the data that
follows: the total
length of the type of
the stop order, the

cardholder name,
and the merchant
account number TLV
fields.
Type of Stop Order 5 bytes: Variable; the 1-byte stop-order
• Tag = 2 bytes subfields for the type must be in
• Length = 1 byte type of stop order binary format. Tag
• Value = 2 bytes; TLV, the cardholder value must be DF11
stop-order type name TLV, and the (type of stop order).
merchant account
number TLV may be Required in 0302
present in any order. messages if field 91
= 1 (add) or = 4
(replace).
Returned in 0312
messages if field 91
= 5 (inquiry) in 0302
request.
Valid data values:

• R0 = Stop-Payment
Order
• R1 = Revocation of
Authorization Order
• R3 = Revocation of
All Authorizations
Order

Table 37-2 PF Data Elements for Field 127 (continued)

Position Name Length Position Description
Cardholder Name Variable; 26 bytes Optional field,
maximum: EBCDIC format. Tag
• Tag = 2 bytes value must be DF12
• Length = 1 byte (cardholder name).
• Value = 1–23 bytes;
cardholder name If present, the
cardholder name
is returned in the
0312 response.
Merchant Account Variable; 30 bytes Optional field,
Number maximum: EBCDIC format. Tag
• Tag = 2 bytes value must be DF13
• Length = 1 byte (merchant account
• Value = 1–27 bytes; number).
merchant account
number If present, the
merchant account
number is returned
in the 0312 response.

For further information about the Preauthorized Payment Cancellation Service (PPCS),
members can contact their Visa representatives.


Chapter 38 Status Check Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
IN BRIEF 38-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
HOW STATUS CHECK SERVICE WORKS

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
38-44
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
PROCESS FLOWS 38-55
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
MESSAGE FLOWS 38-66
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-
Status Check Service


Chapter 38 Status Check Service
38.1 IN BRIEF
The Status Check Service offers participants the ability to obtain approval on an 0100
authorization request for one unit of currency, such as one U.S. dollar, reducing over-limit
situations. This service can be used to verify a customer's account status when the final
transaction amount is not yet known. This service is available for hotels, automated fuel
dispensers, and other eligible merchants. When the status check request is approved, the
merchant receives chargeback protection up to the floor limit.
A status check transaction provides increased assurance that the account is in good
standing with the issuer, thus reducing merchant risk.
The Status Check Service is available to members in all Visa regions.
BASE I
SMS The Status Check Service is available both to BASE I System users and to
Single Message System (SMS) users.
BASE I and SMS

I
Participation in the Status Check Service is mandatory for issuers.
Issuer
A
Participation in the Status Check Service is optional for acquirers.
Acquirer

The Status Check Service offers participants the ability to obtain authorization approval for
one unit of currency for hotels, automated fuel dispensers, and other eligible merchants,
reducing over-limit situations. When the status check request is approved, the merchant
receives chargeback protection up to the floor limit.

A status check transaction provides increased assurance that the account is in good
standing with the issuer, thus reducing merchant risk.

Status Check Service participants must fulfill the requirements documented in this section.
38.4.1 Testing
Status Check Service testing is mandatory for service participants only when they use the
service with the Custom Payment Service (CPS) Automated Fuel Dispenser Service.
Otherwise, it is optional.
To test this service, members must contact their Visa representatives.

Service monitoring is not available for the Status Check Service.

The following messages pertain to the Status Check Service.
Request—This message contains the single currency unit

(in Field 4—Amount, Transaction) that initiates the status check.
Response—This message provides the status check response to

the 0100 message.
Response—This message contains the status check response when STIP

0120: Advice Response—
processes the transaction on the issuer's behalf.
38.6 HOW STATUS CHECK SERVICE WORKS

A status check request includes the same content as an authorization request, except that
in a status check request:
• The transaction amount in field 4 is one unit of currency.

• The value in Field 3—Processing Code, is 00xxxx.
• The merchant category code (MCC) in Field 18—Merchant Type is not 6011 (ATM).
NOTE
Requests that do not meet the field 3, field 4, and field 18 requirements listed above and that did not originate
from the Single Message System (SMS) as 0200 financial transactions are not considered status check
requests, and they are subject to currency conversion.
Without the Status Check Service, hotel merchants typically authorize an amount based
on the cardholder's anticipated length of stay. The issuer processes this transaction
and, in most cases, decreases the cardholder's open-to-buy amount for the amount of
the transaction. If the cardholder's actual length of stay is less than anticipated, the
cardholder's open-to-buy amount may still reflect the original, higher authorization amount.
If this happens repeatedly within a short period of time, the cardholder's open-to-buy
amount may be unnecessarily reduced.
If the issuer participates in multicurrency processing, the field 6 value remains one unit but
the currency code in field 51 reflects the billing currency.

Each status check transaction must be followed by a corresponding clearing transaction or

an authorization reversal in the case of a cancelled sale or timeout event.
Issuers can respond to a status check request with a partial approval. The partial approval
amount is the maximum authorized amount for the purchase. For acquirers to receive a
response with a partial approval, the status check request must contain the values specified
above for fields 3, 4, and 18, along with a value of 1 in field 60.10 to indicate that a partial
authorization can be returned.
Issuers return the partial approval amount in field 4 (or field 6, which is used for
multicurrency transactions), along with field 39 response code 10 to indicate that the
amount in field 4 is a partial authorization. In addition, field 54 contains the original amount
from the 0100 authorization request.
38.7 PROCESS FLOWS

The Status Check Service process flow consists of the following steps:
1. VisaNet routes authorization requests containing one unit of currency to the issuer for
verification without any other indicator of special status.
2. If the issuer is unavailable, STIP processes the request and returns the authorization
response to the acquirer, as required with standard STIP processing procedures.
3. If the transaction is approved, the merchant receives chargeback protection up to the
floor limit.

Figure 38-1 illustrates the Status Check Service process flow.
Figure 38-1 Status Check Service Process Flow
The acquirer sends an V.I.P. routes the request The issuer processes the
authorization or financial to the issuer. request and sends the
request to the issuer. appropriate response
message.

response message to the
acquirer.
38.8 MESSAGE FLOWS

The acquirer sends an 0100 request to the issuer through VisaNet, and VisaNet then sends
the request message to the issuer. The issuer responds with an 0110 message indicating
its response in Field 39—Response Code. VisaNet forwards the response to the acquirer.
If STIP processes the transaction, VisaNet sends an 0120 advice message to the issuer.

Figure 38-2 illustrates the Status Check Service message flow. (See the format descriptions
for the fields in “Key Fields Glossary” in this chapter.)
Figure 38-2 Status Check Service Message Flow

Field 2: Visa account number Field 2: Visa account number Field 2: Visa account number
Field 3: Processing Code Field 3: Processing Code Field 3: Processing Code
Field 4: Amount, Transaction Field 4: Amount, Transaction Field 4: Amount, Transaction
Field 18: Merchant Type Field 18: Merchant Type Field 18: Merchant Type
Field 49: Currency Code Field 49: Currency Code Field 49: Currency Code


This section lists and describes key fields associated with the Status Check Service.
Field 2—Primary Account Number

Field 2 must contain a Visa account number.

This field contains the code that identifies:
- The customer transaction type.
- The customer account types, if any, affected by the transaction.
The value in Field 3—Processing Code is 00xxxx.

This field appears in most messages related to a customer transaction. The amount
in field 4 must be one whole unit of currency.


This field is present in request messages. The code cannot be 6011 (ATM).

This field is used in all responses except those for reconciliation and most network
management functions. Field 39 contains response code 00 for a successful status
check.

Field 49 must contain the currency code for the currency specified in field 4.
Currently, the value must be one unit of any valid currency.

For further information about the Status Check Service, refer to V.I.P. System BASE I
Processing Specifications.

Chapter 39 Visa Cashback Processing: VisaNet Cashback Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
IN BRIEF 39-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-5
Issuer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-6
Magnetic Stripe Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .39-6
Chip Card Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-6
Acquirer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-7
Chip Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-7
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
VisaNet Cashback Service

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
HOW VISANET CASHBACK SERVICE WORKS 39-88
Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-8
PIN Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-9
VSDC Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-9
Participating Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-9
Other Cashback Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
United Kingdom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
United States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-10
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
10
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-
11


Chapter 39 Visa Cashback Processing: VisaNet Cashback Service
39.1 IN BRIEF
The VisaNet Cashback Service provides cashback transaction capability for participating
regions. Regions can choose to implement cashback processing capability as either a
domestic-specific solution without VisaNet, or they can participate in the VisaNet Cashback
Service.
A domestic cashback transaction is one for which the merchant, the acquirer, and the issuer
reside in the same country. V.I.P. checks the acquirer and issuer BINS, Field 19—Acquiring
Institution Country Code, and the merchant country code in Field 43—Card Acceptor
Name/Location to determine if the POS cashback transaction is domestic.
The cashback amount field is Field 61.1—Other Amounts. If the transaction is

non-domestic, V.I.P. converts the cashback amount in field 61.1 to the issuer currency code
and forwards the converted amount in field 61.2 to the issuer
Cashback processing is optional for merchants, acquirers, and issuers in all Visa regions.
Participating regions and countries within those regions establish maximum cashback
amounts. Regions that use the VisaNet Cashback Service can control member and country
participation, and can set maximum cashback limits and different pricing options by country.
NOTE

Only Visa card transactions with chip and proximity payment service codes of 2 or 6 in the first digit, and
acquirer transactions with chip and payWave values in the POS Entry Mode Code (field 22 = 05 05, 07
07, 91 or 95
95)
are eligible for cashback. V.I.P. rejects cashback transactions that do not meet these criteria.

The VisaNet Cashback Service is available to members in all Visa regions.
BASE I
SMS The VisaNet Cashback Service is available both to BASE I System users and
to Single Message System (SMS) users.
BASE I and SMS
I
Participation in the VisaNet Cashback Service is optional for issuers.
Issuer
A
Participation in the VisaNet Cashback Service is optional for acquirers.
Acquirer

The VisaNet Cashback Service supports cashback transactions processed through
VisaNet. This service allows regions to control member and country participation, and to
set maximum cashback limits and different pricing options by country.
A Visa region might choose to participate in the VisaNet Cashback Service when it has
one or more countries in which:
• Chargeback protection is provided for below-floor-limit transactions.
• Domestic transactions are authorized or are settled through VisaNet.
• Domestic transactions are settled through a National Net Settlement Service.
• Strong controls over cashback transactions would be appropriate.
The VisaNet Cashback Service is currently being offered in several regions including
Asia-Pacific (AP) and Central Europe, Middle East, and Africa (CEMEA).
Acquirers and acquirer processors in the U.S. region, and those in the AP and LAC (Latin
America and Caribbean) regions with merchants in U.S. territories, that process Visa and
Interlink POS transactions with cashback must support partial authorizations.

The following table lists the cashback services currently supported by VisaNet.
Table 39-1 Cashback Services Currently Supported by VisaNet
Cashback Service Region Cards Maximum Amounts

VisaNet Cashback Asia-Pacific, CEMEA, Visa, Visa Electron Defined by regions,
Service Visa Europe (VE) (in countries
progress)
U.K. Cashback United Kingdom only Visa, Visa Electron Defined by merchant,
Service cardholder, and issuer
This service description is a summary of a more in-depth description of the VisaNet

Cashback Service. Members can contact their Visa representatives for complete service
information.

Participation in the VisaNet Cashback Service is optional for issuers, acquirers, and
merchants.
Visa International Operating Regulations (VIOR) allow cashback for domestic transactions
only at the option of a region and prohibit international cashback transactions.
Maximum cashback amounts are established by regions and by countries within regions.

Participants establish service options and limits for the VisaNet Cashback Service in the
Customer Online Repository (CORE) at the BIN level, and the region must be activated
for the service in V.I.P. The BIN flag must be set both for issuers and for acquirers. If
the participation flag is not set, V.I.P. declines transactions with a cashback amount in
Field 61.1—Other Amount, Transaction that originate in participating regions.
NOTE
For risk management purposes, Visa recommends a zero-dollar floor limit for all cashback transactions.
39.4.1 Testing
Testing are optional for the VisaNet Cashback Service. Visa recommends that regions
make testing mandatory for members participating in the VisaNet Cashback Service.
NOTE
Testing is required in the Asia-Pacific (AP) region.

Service monitoring is not available for the VisaNet Cashback Service.

Implementing cashback services requires completing the following activities:
• Successfully complete testing for the service with the Visa region, if required by the region.
• Working with merchants to test cashback transactions between the acquirer and
the merchant.

• Identifying the purchase amount and the cashback amount separately on receipts.
• Promoting the service availability with merchant training and with domestic cashback
signage at the point of sale.
• Providing domestic cashback signage and decals to participating merchants.
• Developing and delivering merchant education materials and ongoing training as
necessary to support the cashback service.
39.4.4 Issuer Implementation Considerations

Issuers need to review their product strategies and determine how cashback will be
incorporated in their card product portfolio. Considerations include:
• Deciding how cardholder daily cash limits will be affected by cashback.
• Reviewing Positive Cardholder Authorization Service (PCAS) parameters and adjusting
purchase limits as needed to incorporate cashback amounts. PCAS processing applies to
the total transaction amount as it represents the issuer’s total exposure for the transaction
amount. PCAS does not consider the cashback amount separately.
39.4.4.1 Magnetic Stripe Considerations

For magnetic stripe cards, issuers should review the service code used on the magnetic
stripe to ensure that the appropriate code is encoded on the card.
39.4.4.2 Chip Card Considerations

Issuers of chip cards need to evaluate the impact of cashback processing on personalization
and on transaction processing. Issuers should refer to the EMV and VIS guidelines on the
changes needed for cashback at the point of sale.
Personalization considerations for cashback include:

• CVM Condition Code—Indicates the cardholder verification method required for
cashback.
• Velocity Checking by Amount—Indicates the total amount of purchase and cashback.
NOTE
Velocity checking is performed on the total transaction amount, including purchase plus cashback.
• Application Usage Control—Specifies cashback. To allow domestic cashback, the

Application Usage Control (Tag 9F07), Byte 2 Bit 8, must be set to 1.
Issuers should ensure that their authorization systems can accept and can process
cashback data included in the Authorization Request Cryptogram (ARQC) and in the
following fields:
• Cryptogram Amount (field 147)—The field contains the total of the purchase amount
plus the cashback amount.
• Cashback Cryptogram Amount (field 149)—The field contains the cashback amount.
If the transaction involves cashback, field 149 must be present and must be included in
the ARQC algorithm. If the transaction does not involve cashback, this field may be
present and the ARQC calculated with a zero cashback amount.
Refer to the Visa Smart Debit/Visa Smart Credit System Technical Manual for information
about technical specifications for cashback transactions performed with chip cards.

39.4.5 Acquirer Implementation Considerations

Acquirers participating in the VisaNet Cashback Service must be able to format an
authorization request with the total transaction amount (purchase plus cashback) in
Field 4—Amount, Transaction and the cashback amount in Field 61.1—Other Amounts,
along with other required transaction data.
Acquirers must also be able to receive and to act upon these response and reject codes:
• N3
N3—Cash service not available. This response code indicates that the issuer does
not participate in the VisaNet Cashback Service.
• N4
N4—Cash request exceeds issuer limit. This response code indicates that the cardholder
has requested an amount greater than the maximum cash limit for the country or greater
than the limit established between the issuer and the cardholder.
Merchants should advise the cardholder that the transaction may have exceeded their
cashback limit, and that the cardholder either can request a smaller cashback amount
or can re-enter the transaction for the purchase only.
• 106
106—Invalid value. This reject code is returned when the cashback amount is equal to
or greater than the total transaction amount.
• 57
57—Transaction not permitted to cardholder. V.I.P. returns this response code when
the issuer does not participate in the U.K. Cashback Service, or the transaction is an
international cashback transaction acquired in the U.K.
• 13
13—Invalid amount. V.I.P. returns this response code for U.K.-domestic cashback
transactions when the cashback amount is greater than the transaction amount.
NOTE

The cashback amount can equal the transaction amount where permitted for domestic transactions by
country operating regulations.
NOTE
VisaNet declines cashback transactions destined to non-U.S.issuers from U.S. acquirers with response
code N3 (cash service not available).
39.4.5.1 Chip Transaction Processing

Acquirers processing chip card transactions must modify their systems to support inclusion
of cashback data, pass the cashback amount to the card when requested, and then
pass the resulting cryptogram data to the acquirer for inclusion in the VisaNet message.
Impacted fields include:
If the transaction involves cashback, field 149 must be present and be included in the
Authorization Request Cryptogram (ARQC) algorithm. If the transaction does not
involve cashback, this field may be present and the ARQC may be calculated with a
zero cashback amount.

The following messages pertain to the VisaNet Cashback Service.

Chapter 39 How VisaNet Cashback Service Works
• BASE I 0100 authorizations, 0400 reversals, and their advices

• SMS 0100 authorization requests, 0200 full financial requests, 0120 and 0220
stand-in-advices, 0220 acquirer advices, 0220 deferred clearing advices, 9620 fraud
advices, 0422 chargebacks, and 0220 representments
39.6 HOW VISANET CASHBACK SERVICE WORKS

Regardless of region or country, all cashback transactions share certain common
processing characteristics and requirements. Unless otherwise indicated, information in
this section applies to all cashback transactions.
VisaNet cashback transactions are supported in both dual-message and single-message

processing environments and are subject to standard VisaNet edits.
Acquirers submit 0100 authorization or 0200 financial requests with the cashback amount
in Field 61.1—Other Amounts. V.I.P. determines if:
• The transaction is domestic (the merchant, the acquirer, and the issuer are all in the
same country).
• The acquirer and the issuer are participants in the service.
• The cashback amount (in field 61.1) is less than the total transaction amount (in field 4),
except where country operating regulations allow the cashback amount to be equal to the
transaction amount for domestic transactions.
• The cashback amount is less than the country’s maximum cashback limit, if a limit has
been established.
If the transaction is non-domestic, V.I.P. converts the cashback amount in field 61.1 to the
issuer currency and forwards the converted amount in field 61.2 to the issuer.
If any of the remaining conditions are not met, VisaNet returns the authorization message
to the acquirer with the appropriate response code:
• N3
N3—Cash service not available. This response code indicates that the issuer does
not participate in the VisaNet Cashback Service.
• N4
N4—Cash request exceeds issuer limit. This response code indicates that the
cardholder has requested an amount greater than the maximum cash limit for the
country. Cardholders either can request a smaller cashback amount or can re-enter the
transaction for the purchase amount only.
• 106
106—Invalid value. This reject code is returned when the cashback amount is equal to or
greater than the total transaction amount.
The transaction is then routed to the issuer or to STIP. Depending on the issuer’s
parameters, STIP may generate an authorization response for the acquirer or may send
the transaction to the issuer.
STIP processing applies to the total transaction amount; STIP does not consider the
cashback amount separately. If STIP authorizes the transaction on the issuer’s behalf,
it generates an authorization response and sends it to the acquirer without routing the
transaction to the issuer.
39.6.1 Stand-In Processing

Maximum cashback limits for participating countries are maintained in CORE. Valid values
for the limit are:

Chapter 39 How VisaNet Cashback Service Works
• USD$0.00—None; no cashback allowed. V.I.P. declines all cashback transactions for

N3—Cash service not available. This is also the default value for the
this country with N3
field. This value may be used to shut off the VisaNet Cashback Service for a country
that previously participated in the service.
• USD$1.00–USD$998.00—Cashback limit in U.S. dollars. V.I.P. declines transactions
with a cashback amount over the limit with N4 N4—Cash request exceeds issuer limit.
• USD$999.00—No cashback limit; any cashback amount is allowed. V.I.P. treats
countries that are not in the table as if the cashback limit were USD$999.00.
39.6.2 PIN Processing

If cardholder PIN data is required for a cashback transaction, Field 52—PIN Data and
Field 53—Security-Related Control Information are included with the 0100 or 0200 request.
If field 52 or field 53 carrying PIN data is submitted in a non-original or exception item,
SMS rejects the message with Reject Code 0699 0699—Presence of PIN/Track/AVS data
V.I.P. translates the PIN, and, if the issuer participates in the PIN Verification Service
(PVS), also performs PIN verification.
U.S. domestic POS transactions with cashback initiated using Visa debit cards must
contain PIN data; otherwise, V.I.P. declines these transactions with response code 57
(transaction not permitted to cardholder).
39.6.3 VSDC Processing

A chip card-based Visa Smart Debit/Smart Credit (VSDC) cashback transaction may

include offline PIN processing results as well as chip card-specific cashback fields. VSDC
fields include:
If the transaction involves cashback, field 149 must be present and must be included in
the Authorization Request Cryptogram (ARQC) algorithm. If the transaction does not
involve cashback, this field may be present and the ARQC may be calculated with a zero
cashback amount.
39.6.4 Participating Regions

Visa currently provides cashback services in the following regions and countries:
• AP
• CEMEA
• U.S.
• U.K. (and soon for Visa Europe [VE])
The information in the following sections applies in addition to the general processing
requirements already described.

NOTE
Some countries have placed specific checks for the VisaNet Cashback Service:
• U.K.—The issuer BIN should be participating the U.K. Cashback Service.
U.K.
• Australia—The transaction should be a PIN transaction.
U.S., New Zealand, and Australia
• Australia—The service restriction code of the transaction should be chip or proximity card (field 40 begins
Australia
91, or 95
with 2 or 6). The POS entry mode code in field 22 should be 5, 7, 91 95.
Members can contact their Visa regional representatives for maximum cashback amounts
and for other region-specific information.
39.6.5 Other Cashback Services

The cashback programs in the U.K. and the U.S. are different from the VisaNet Cashback
Service, although they rely on VisaNet for processing. Requirements for participation and
for processing distinguish the services from one another. The following table lists these
services.
Table 39-2 Cashback Programs in the U.K. and the U.S.
Region Cashback Service

United Kingdom U.K. Cashback Service
United States U.S. Supermarket Cashback Service
39.6.5.1 United Kingdom

The U.K. Cashback Service uses Visa cards and Visa Electron cards. V.I.P. processes
U.K. cashback requests as dual-message transactions. The 0100 authorization requests

must include a valid merchant category code.
If the merchant, the acquirer, and the issuer are not all in the U.K., V.I.P. declines
the transaction with response code 57 (transaction not permitted to cardholder).
Members can contact their Visa regional representatives for maximum cashback amounts
and for other region-specific information.
39.6.5.2 United States

The following Visa cashback service is available in the U.S. region:
• Supermarket Cashback Service
The U.S. region permits cashback with purchase for Interlink and for POS Check Service
transactions. For further information about Interlink and about POS Check Service
processing requirements, refer to V.I.P. System SMS Processing Specifications (U.S.).

This section describes key fields associated with the VisaNet Cashback Service.

This field contains the total transaction amount, which is the purchase amount plus the
cashback amount in field 61.1.

Field 61.1—Other Amounts

This field contains the cashback amount in Field 49—Currency Code, Transaction.
The amount in this field cannot exceed the amount in field 4, except where country
operating regulations permit the cashback amount to be equal to the transaction amount
for domestic transactions.
Field 61.2—Other Amounts

If the transaction is non-domestic, V.I.P. converts the cashback amount in field 61.1
to the currency of the issuer currency code and forwards the converted amount in
field 61.2 to the issuer.

For further information about the VisaNet Cashback Service, refer to the Cashback Service
Description (Doc ID 40080-01).


X Index
A advice limit 36-10

Account Verification Service advice recovery 21-10
eligibility 19-3 Advice Retrieval Service—BASE I
fields 19-8 to 19-9 eligibility 21-3
message flow 19-6 fields 21-12
messages message flow 21-11
Index
related messages 19-4 messages
participation requirements 19-4 advice message creation 21-6
process flow 19-6 processing modes 21-7
activity checking and accumulation 36-10 related messages 21-6
activity file participation requirements 21-4
in PIN Verification Service (PVS) 33-12, process flow
33-18 during and after VIC switchover 21-10
Activity File 16-5 offline 21-4
description 16-5 online 21-7, 21-9
file layout 16-3 Advice Retrieval Service—SMS
activity limits fields 22-13
in Positive Cardholder Authorization Service message flow 22-12
(PCAS) 36-6 messages
issuer available and unavailable 36-7 advice message creation 22-8
Address Verification File processing modes 22-9
description 16-7, 20-7 related messages 22-5
file layout 16-3 participation requirements 22-4
Address Verification Service (AVS) process flow 22-9
address data 20-12 during and after VIC switchover 22-12
data compression 20-15 ATM Format Conversion Service
eligibility 20-3 eligibility 23-3
fields 20-6, 20-34, 20-37 fields 23-11
message flow 20-24, 20-33 message flow 23-9, 23-11
messages messages
related messages 20-5 augmentation 23-6
participation requirements 20-4 related messages 23-5
process flow participation requirements 23-4
basic 20-8, 20-10 process flow 23-7
variations 20-23 authorization database services
sample results 20-22 Automatic Cardholder Database Update
Advice File (Auto-CDB) Service 17-3, 17-9
file layout (basic) 16-3 Merchant Central File Service (MCFS) 18-3,
advice file—BASE I 18-30
advice retrieval 21-10 authorization services
description 16-7, 21-3 Account Verification Service 19-3, 19-10
advice file—SMS Address Verification Service (AVS) 20-3,
advice retrieval 22-12 20-37
description 16-7, 22-3
1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 IX-1

X Index
Advice Retrieval Service—BASE I 21-3, Exception File 21-6

21-12 BASE II System
Advice Retrieval Service—SMS 22-3, 22-14 advice delivery 21-4
ATM Format Conversion Service 23-3, 23-12 Brazil national market program
Card Verification Value (CVV) Service 24-3, Custom Payment Service (CPS)/POS 28-13
24-30
Card Verification Value 2 (CVV2) C
Service 25-25
Custom Payment Service (CPS)/ATM 27-3,
eligibility 24-6
27-15
emergency replacement 24-23
Index
Custom Payment Service (CPS)/POS 28-3,

fields 24-27, 24-30
28-17
iCVV description 24-3
Deferred Clearing Advice File (DCAF)
issuer options
Service 29-3, 29-10
default response codes 24-23
Dynamic Key Exchange (DKE) Service 30-23
receiving results 24-22
International Automated Referral Service
messages 24-20
(IARS) 31-13
participation requirements 24-8, 24-18
Multicurrency Service 32-70
PIN Verification Service (PVS) 33-25
calculation 25-10
POS Check Service 34-3, 34-19
eligibility 25-4
Positive Authorization Capacity Management
(PACM) Service 35-3, 35-11
encryption 25-10
Positive Cardholder Authorization Service
fields 25-21 to 25-22
(PCAS) 36-14
Preauthorized Payment Cancellation Service
messages
(PPCS) 37-9
message flow 25-19
Status Check Service 38-8
related messages 25-9
VisaNet Cashback Service 39-11
process flow 25-19
authorization-related chargeback protection
processing options
Custom Payment Service (CPS)/POS 28-8
description 25-12
Auto-CDB Service, See Automatic Cardholder
stand-in processing (STIP) 25-13
Database Update (Auto-CDB) Service
variations 25-14
Automatic Cardholder Database Update
specifications for card 25-8
(Auto-CDB) Service 17-3, 22-4
Cardholder Authentication Verification Value
eligibility 17-3
(CAVV) Verification Service 26-3
fields 17-8
messages
(CAVV) Verification Service
advices 17-5
fields 26-17
message flow 17-7
participation requirements 17-4
how the service works 26-8
pick-up action codes 17-5
process flow 17-5
AVS, See Address Verification Service (AVS)
eligibility 26-4
B (CAVV) Verification Service
BASE I System related messages 26-7
advice file 21-9 to 21-10
IX-2 Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

X Index
Cardholder Authentication Verification Value CAVV Service, See Cardholder Authentication

(CAVV) Verification Service Verification Value (CAVV) Verification
participation requirements 26-5 Service
Cardholder Authentication Verification Value chargeback rights indicator values
(CAVV) Verification Service Custom Payment Service (CPS)/POS 28-8
service monitoring 26-7 conversion rate, See currency conversion
Cardholder Database CPS, See Custom Payment Service (CPS)
activity file CPS/POS, See Custom Payment Service
in PIN Verification Service (PVS) 33-12, (CPS)/POS
33-18 currency conversion 32-7
Index
Activity File clearing and settlement currency
description 16-5 conversion 32-6
file layout 16-3 conversion charge 32-4
Address Verification File decimal positioning 32-5
description 16-7, 20-7 for International Automated Referral Service
file layout 16-3 (IARS) 31-5
Advice File non-participants 32-10
file layout (basic) 16-3 processing 32-3
advice file—BASE I Currency Precision Service, See Multicurrency
advice retrieval 21-10 Service
description 16-7, 21-3, 21-9 to 21-10 Currency Rate Delivery Service, See
advice file—SMS Multicurrency Service
advice retrieval 22-12 Custom Payment Service (CPS)/ATM
description 16-7, 22-3 eligibility 27-3
Exception File fields 27-14
advices 17-5 participation requirements 27-5
description 16-4, 16-8, 17-3 process flow 27-7
discrepancy advice 17-5 service monitoring 27-6
layout 16-3 Custom Payment Service (CPS)/POS
update advice 21-6 authorization characteristics indicator 28-16
PIN Verification File authorization-related chargeback
description 16-12, 33-8 protection 28-8
file layout 16-4 Brazil national market program 28-13
Portfolio File chargeback rights indicator values 28-8
description 16-13 common clearing requirements 28-12
file layout 16-4 eligibility 28-3
risk level file fee changes 28-7
description 36-12 fields 28-15
risk-level file life-cycle control 28-9
description 16-14 participation requirements 28-6
Risk-Level File process flow 28-9
file layout 16-4 programs 28-5
cardholder ID verification 31-12 validation code 28-17
cardholder risk levels 36-11 CVV Service, See Card Verification Value (CVV)
CAVV, See Cardholder Authentication Service
Verification Value (CAVV) CVV2 Service, See Card Verification Value 2
(CVV2) Service

X Index
D Advice Retrieval Service—BASE I 21-12

DCAF, See Deferred Clearing Advice File Advice Retrieval Service—SMS 22-13
(DCAF) Service ATM Format Conversion Service 23-11
decimal positioning 32-5 Automatic Cardholder Database Update
decimal positions indicator (Auto-CDB) Service 17-8
acquirer 32-6 Card Verification Value (CVV) Service 24-27,
one-position adjustment 32-29 24-30
two-position adjustment 32-29 Card Verification Value 2 (CVV2)
Deferred Clearing Advice File (DCAF) Service Service 25-21 to 25-22
eligibility 29-3 emergency replacement 25-24
Index
fields 29-10 Cardholder Authentication Verification Value

file content 29-5 (CAVV) Verification Service 26-17
file delivery 29-4 Custom Payment Service (CPS)/ATM 27-14
message flow 29-9 Custom Payment Service (CPS)/POS 28-15
participation requirements 29-5 Deferred Clearing Advice File (DCAF)
process flow 29-8 Service 29-10
record format 29-5 Dynamic Key Exchange (DKE) Service 30-20,
related messages 29-7 30-23
service monitoring 29-6 International Automated Referral Service
service options 29-4 (IARS) 31-12
DKE, See Dynamic Key Exchange (DKE) Merchant Central File Service (MCFS) 18-25,
Service 18-27
Dynamic Key Exchange (DKE) Service Multicurrency Service 32-66, 32-69
eligibility 30-3 PIN Verification Service (PVS) 33-20, 33-25
fields 30-20, 30-23 POS Check Service 34-15, 34-19
message flow 30-12, 30-15 Positive Authorization Capacity Management
messages (PACM) Service 35-11
exception conditions in messages 30-19 Positive Cardholder Authorization Service
participation requirements 30-5 (PCAS) 36-14
process flow Preauthorized Payment Cancellation Service
automatic key exchange 30-10 (PPCS) 37-6
on-demand key exchange 30-8 Status Check Service 38-7
related messages 30-6 VisaNet Cashback Service 39-10
files
activity file
E
in PIN Verification Service (PVS) 33-12,
Exception File
33-18
advices 17-5
Activity File
description 16-5
discrepancy advice 17-5
file layout 16-3
layout 16-3
Address Verification File
updating 16-4
file layout 16-3
F Advice File
fields file layout (basic) 16-3
Account Verification Service 19-8 to 19-9 advice file— BASE I
Address Verification Service (AVS) 20-6, description 21-10
20-34, 20-37

X Index
advice file—BASE I messages

advice retrieval 21-10 message flow 31-10
description 16-7, 21-3, 21-9 related messages 31-5
advice file—SMS participation requirements 31-4
advice retrieval 22-12 process flow 31-9
description 16-7, 22-3 referral process 31-9
Exception File stand-in processing (STIP) 31-11 to 31-12
description 16-4, 16-8, 17-3, 21-6 telecommunications matching 31-7
discrepancy advice 17-5 translation 31-5 to 31-6
layout 16-3 Voice Response Unit (VRU) 31-7
Index
Merchant Central File issuer limits 35-11, 36-6
update messages 18-7
PIN Verification File K
key fields, See fields
file layout 16-4
Portfolio File
description 16-13
L
file layout 16-4 language matching, See International Automated
risk level file Referral Service (IARS)
description 36-12 life-cycle control
risk-level file Custom Payment Service (CPS)/POS 28-9
description 16-14 limits
Risk-Level File activity 36-6
file layout 16-4 issuer available and unavailable 36-7
floor limit 19-3 advice 36-10
individual 36-11
issuer 35-11, 36-6
G mandatory minimum (MM) 36-8
GCAS, See Global Customer Assistance
Services (GCAS)
Global Customer Assistance Services
M
(GCAS) 16-12 mandatory minimum (MM) limits 36-8
MasterCard
updating merchant ID 18-19
I MCFS, See Merchant Central File Service
IARS, See International Automated Referral
(MCFS)
Service (IARS)
merchant category groups 36-6
iCVV, See Integrated Chip Card card verification
Merchant Central File
value (iCVV)
update messages 18-7
individual limits 36-11
updating 18-15
Integrated Chip Card card verification value
(iCVV) 24-3
eligibility 18-3
fields 18-25, 18-27
currency conversion 31-5
message flow 18-25
eligibility 31-3
messages
equipment 31-7
fields 31-12
issuer-set parameters 31-11
process flow 18-22
language matching 31-6

X Index
Merchant Fraud Performance Program 21-3, messages

22-4 message flows 32-30, 32-61
message related messages 32-7
advice message creation participation requirements 32-4
BASE I 21-6 processing
Single Message System (SMS) 22-8 for non-participants 32-10
processing modes service monitoring 32-5
BASE I 21-7 transaction currency 32-3
Single Message System (SMS) 22-9 Multiple-Stations-per-PCR 21-9
message flow
Index
Account Verification Service 19-6 P

Address Verification Service (AVS) 20-24,
PACM, See Positive Authorization Capacity
20-33
Management (PACM) Service
Advice Retrieval Service—BASE I 21-11
parameters
Advice Retrieval Service—SMS 22-12
CVV 24-15
ATM Format Conversion Service 23-9, 23-11
(PCAS) 35-4, 36-4
(Auto-CDB) Service 17-7
advice limit 36-10
Card Verification Value 2 (CVV2)
authorization 36-11
Service 25-19
merchant category groups 36-6
risk level file 36-12
Service 29-9
participation requirements
Dynamic Key Exchange (DKE) Service 30-12,
Account Verification Service 19-4
30-15
Address Verification Service (AVS) 20-4
(IARS) 31-10
Merchant Central File Service (MCFS) 18-25
ATM Format Conversion Service 23-4
BASE I POS ATM 32-31
SMS POS 32-33
Card Verification Value (CVV) Service 24-8,
SMS Visa/Plus ATM 32-40
24-18
messages
Custom Payment Service (CPS)/ATM 27-5
Service 25-9
Service 29-5
clearing and settlement currency
conversion 32-6
Currency Precision Service 32-4, 32-6, 32-28
(IARS) 31-4
Currency Rate Delivery Service 32-4, 32-10
decimal positioning 32-5
decimal positions indicator
acquirer 32-6
POS Check Service 34-5
one-position adjustment 32-29
two-position adjustment 32-29
(PACM) Service 35-4
eligibility 32-3
fields 32-66, 32-69
(PCAS) 36-4

X Index
Preauthorized Payment Cancellation Service Positive Authorization Capacity Management

(PPCS) 37-4 (PACM) Service
Status Check Service 38-4 diversion tables
VisaNet Cashback Service 39-5 BASE I 35-8
pick-up action codes 17-5 Single Message System (SMS) 35-10
PIN (personal identification number) eligibility 35-3
data on magnetic stripe 33-11 fields 35-11
encryption issuer limits 35-11
calculating 33-6 messages 35-5
zone 33-14 participation requirements 35-4
Index
entry 33-4 process flow 35-6
options for verifying 33-5 Positive Cardholder Authorization Service
verification methods (PCAS)
IBM PIN Offset 33-9, 33-13 activity checking and accumulation 36-10
PIN Verification Value (PVV) 33-7, 33-12 activity limits 36-6
PIN Verification File issuer available and unavailable 36-7
description 16-12, 33-8 advice limit 36-10
file layout 16-4 cardholder risk levels and individual
PIN Verification Key Index (PVKI) 33-8 limits 36-11
PIN Verification Service (PVS) eligibility 36-3
eligibility 33-3 fields 36-14
fields 33-20, 33-25 issuer limits 36-6
IBM PIN Offset method 33-9, 33-13 key terms 36-3
messages mandatory minimum (MM) limits 36-8
message flow 33-19 merchant category groups 36-6
related messages 33-12 messages 36-4
participation requirements 33-6 parameters 35-4
process flow 33-17 participation requirements 36-4
verification methods random selection factors 36-13
PIN Verification Value (PVV) 33-7, 33-12 Preauthorized Payment Cancellation Service
Portfolio File (PPCS)
description 16-13 eligibility 37-3
file layout 16-4 fields 37-6
POS Check Service messages
eligibility 34-3 related messages 37-4
fields 34-15, 34-19 participation requirements 37-4
messages process flow
related messages 34-8 Account Verification Service 19-6
MICR line 34-13 Address Verification Service (AVS)
participation requirements 34-5 basic 20-8, 20-10
process flow variations 20-23
authorization 34-9 Advice Retrieval Service—BASE I
settlement 34-11 offline through BASE II 21-4
roles of participants 34-4 online through V.I.P. 21-7, 21-9
service options 34-4 Advice Retrieval Service—SMS 22-9

X Index
Card Verification Value 2 (CVV2) risk-level file

Service 25-19 description 16-14
Custom Payment Service (CPS)/ATM 27-7 Risk-Level File
Custom Payment Service (CPS)/POS 28-9 file layout 16-4
Service 29-8 S
service monitoring
(IARS) 31-9
Account Verification Service 19-4
Address Verification Service (AVS) 20-5
Index
POS Check Service 34-9, 34-13

(PACM) Service 35-6
processing
Card Verification Value (CVV) Service 24-12
advice recovery
during and after VIC switchover
Service 25-8
(BASE I) 21-10
during and after VIC switchover
(SMS) 22-12
Custom Payment Service (CPS)/ATM 27-6
modes
Service 29-6
for non-participants 32-10
(IARS) 31-4
transaction currency 32-3
parameters
CVV 24-15
POS Check Service 34-6
(PCAS) 35-4, 36-4, 36-6
(PACM) Service 35-5
PVKI, See PIN Verification Key Index (PVKI)
Preauthorized Payment Cancellation Service
PVS, See PIN Verification Service (PVS)
(PPCS) 37-4
PVV, See PIN Verification Value (PVV)
VisaNet Cashback Service 39-5
R services
random selection factors 36-13 Automatic Cardholder Database Update
regions (Auto-CDB) Service 22-4
Positive Authorization Capacity Management Cardholder Authentication Verification Value
(PACM) Service (CAVV) Verification Service 26-3
BASE I diversion tables 35-8 to 35-9 Merchant Fraud Performance Program 21-3,
Single Message System (SMS) diversion 22-4
tables 35-9 to 35-10 SMS, See Single Message System (SMS)
related messages SMS. See Single Message System (SMS) 37-3
Dynamic Key Exchange (DKE) Service 30-6 stand-in processing (STIP)
risk level file authorization tests 31-12
description 36-12 through International Automated Referral
risk levels, cardholder 36-11 Service (IARS) 31-11 to 31-12
through V.I.P. 35-6, 35-10

X Index

eligibility 38-3
fields 38-7
messages
message flow 38-6
process flow 38-5
STIP, See stand-in processing (STIP)
system parameters, See processing, parameters
Index
T
telecommunications
equipment 31-7
Voice Response Unit (VRU) 31-7
telephone
pulse-generating (rotary) 31-7
tone-generating 31-7
transaction velocity monitoring 31-12
U
updating
Merchant Central File 18-15
V
validation code
eligibility 39-4
fields 39-10
messages
Voice Response Unit (VRU) 31-7
VRU, See Voice Response Unit (VRU)

03 v.I.P. System Services Volume 2 0853B

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 v.I.P. System Services Volume 2 0853B

Uploaded by

Copyright:

Available Formats

V.I.P.

System Services, Volume 2

© 1999 - 2013 Visa. All Rights Reserved. 0853B–22

Visa and other trademarks are trademarks or registered trademarks of Visa.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR

Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

PART 6 AUTHORIZATION DATABASE FILES AND SERVICES

CHAPTER 16 CARDHOLDER DATABASE OVERVIEW

CHAPTER 17 AUTOMATIC CARDHOLDER DATABASE UPDATE (AUTO-CDB) SERVICE

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 i

17.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-

17.6.1.2 Exception File Discrepancy Advices. . . . . . . . . . . . .17-5

CHAPTER 18 MERCHANT CENTRAL FILE SERVICE (MCFS)

ii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

18.6.4 Updating Merchant IDs for Visa, American Express,

PART 7 AUTHORIZATION SERVICES

CHAPTER 19 ACCOUNT VERIFICATION SERVICE

CHAPTER 20 ADDRESS VERIFICATION SERVICE (AVS)

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 iii

20.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-

20.7.1 When V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . .20-12

CHAPTER 21 ADVICE RETRIEVAL SERVICE—BASE I

iv Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

21.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-4

CHAPTER 22 ADVICE RETRIEVAL SERVICE—SMS

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 v

CHAPTER 23 ATM FORMAT CONVERSION SERVICE

23.4.3.1 Existing Card Range Considerations. . . . . . . . . . . .23-4

CHAPTER 24 CARD VERIFICATION VALUE (CVV) SERVICE

vi Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

24.5.5.2 Planning and Implementation for Acquirers. . .24-17

CHAPTER 25 CARD VERIFICATION VALUE 2 (CVV2) SERVICE

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 vii

25.6.2 Issuer Option Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12

25.6.9 American Express, Diners Club, and Discover Processing. . . . .25-17

CHAPTER 26 CARDHOLDER AUTHENTICATION VERIFICATION VALUE (CAVV)

viii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

26.6.5 Ineligible Transactions Passing CAVV Validation. . . . . . . . . . . . . . .26-16

CHAPTER 27 CUSTOM PAYMENT SERVICE (CPS)/ATM

CHAPTER 28 CUSTOM PAYMENT SERVICE (CPS)/POS

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 ix

Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . . .28-8

CHAPTER 29 DEFERRED CLEARING ADVICE FILE (DCAF) SERVICE

CHAPTER 30 DYNAMIC KEY EXCHANGE (DKE) SERVICE

x Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

30.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-

CHAPTER 31 INTERNATIONAL AUTOMATED REFERRAL SERVICE (IARS)

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xi

31.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-

CHAPTER 32 MULTICURRENCY SERVICE

32.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-

xii Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

32.8.6 Partial Amount Authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-61

CHAPTER 33 PIN VERIFICATION SERVICE (PVS)

CHAPTER 34 POS CHECK SERVICE

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xiii

34.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-

Institution Implementation. . . . . . . . . . . . . . . . . . . . . . . .34-7

CHAPTER 35 POSITIVE AUTHORIZATION CAPACITY MANAGEMENT (PACM) SERVICE

xiv Visa Confidential V.I.P. System Services, Volume 2 1 June 2013

35.7.1.3 Transactions Not Eligible for STIP Diversion. . .35-7

1 June 2013 Visa Confidential V.I.P. System Services, Volume 2 xv

36.6.9.1 Risky Countries and

CHAPTER 37 PREAUTHORIZED PAYMENT CANCELLATION SERVICE (PPCS)