Vip System Services Volume 2

V.I.P.
System Services, Volume 2

V.I.P. System
Effective: 1 June 2016
Visa Supplemental Requirements
© 1999 - 2016 Visa. All Rights Reserved. 0853B–28
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 the Visa Rules, 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.
About Visa Supplemental Documents
This document is a supplement of the Visa Core Rules and Visa Product and Service
Rules. In the event of any conflict between any content in this document, any document
referenced herein, any exhibit to this document, or any communications concerning this
document, and any content in the Visa Core Rules and Visa Product and Service Rules, the
Visa Core Rules and Visa Product and Service Rules shall govern and control.
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 questions about
this document, please contact your Visa representative.
Contents
About This Manual............................................................................................1

Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Manual Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Document Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
System Documentation Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
System Information Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
How To Use This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Obtaining Report Samples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Part 6 • Authorization Database Files and Services

Chapter 16 • Cardholder Database Overview
16.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
16.2 Database Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
16.3 File Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4
16.3.1 How V.I.P. Determines Effective and Update Date and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4
16.4 File Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
16.4.1 Related Services Listings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
16.5 Activity File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
16.5.1 Merchant Group Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
16.5.2 PIN-Entry Attempt Activity Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
16.6 Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 i

Contents
16.7 Advice File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
16.8 Card-Level Product ID File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
16.9 Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
16.9.1 Visa International Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
16.9.2 Online Exception File Editing Summary (0302 Messages). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
16.9.3 Exception File Purge Date Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
16.9.4 Global Customer Assistance Services (GCAS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
16.10 PIN Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
16.11 Portfolio File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14
16.12 Risk-Level File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14
16.13 For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-15
Chapter 17 • Automatic Cardholder Database Update (Auto-CDB) Service

17.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
17.2 Eligible Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
17.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
17.4 Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
17.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
17.4.2 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
17.5 Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
17.6 How Automatic Cardholder Database Update (Auto-CDB) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.6.1 Advice Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.6.1.1 Exception File Update Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.6.1.2 Exception File Discrepancy Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
17.7.1 Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6
17.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7
17.8.1 Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7
17.9 Key Fields Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
17.10 For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-9
ii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
Chapter 18 • Merchant Central File Service (MCFS)

18.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
18.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
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.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
18.4.3 File Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
18.5.1 MCFS-Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
18.5.2 Merchant Central File Update Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7
18.6 How Merchant Central File Service (MCFS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-8
18.6.1 Establishing Merchant Central File Augmentation Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10
18.6.1.1 Merchant Category Code (Field 18). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10
18.6.1.2 Merchant Name, Location, Country (Field 43). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
18.6.1.3 Card Acceptor Identification Code (Field 42). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11
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
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
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 iii

Contents
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
18.6.6.1 Using Field 41 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
18.6.6.2 Using Field 42 Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-21
18.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-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 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-25
18.9 Key Fields Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-25
18.9.1 Key Fields Glossary for Merchant Central File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-27
Part 7 • Authorization Services

Chapter 19 • Account Verification Service
19.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3
19.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3
19.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4
19.6 How Account Verification Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-5
19.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6
iv Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
19.7.1 MasterCard AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8
Chapter 20 • Address Verification Service (AVS)

20.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3
20.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4
20.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
20.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
20.4.3 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
20.5.1 Visa Custom Payment Services (CPS)/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6
20.6 How Address Verification Service (AVS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7
20.6.1 Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8
20.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-9
20.7.1 When V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-11
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-17
20.7.5 Translating Fixed and TLV Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-17
20.7.6 Field 123 Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
20.7.6.1 U.S.-Domestic Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
20.7.6.2 U.K.-Domestic Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
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-20
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 v

Contents
20.7.6.5 Result Code Conversion Based on Acquirer Participation

(U.K. and U.S. Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-21
20.7.7 AVS Process Flow Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-22
20.7.7.1 V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-22
20.7.7.2 When the Issuer Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-23
20.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-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.10.1 Merchant Guide for AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-37
Chapter 21 • Advice Retrieval Service—BASE I

21.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-3
21.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-3
21.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-5
21.6 How BASE I Advice Retrieval Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-6
21.6.1 BASE I Advice Message Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
21.6.2 BASE I Message Processing Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
21.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
21.7.1 Multiple Stations per PCR Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-9
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
vi Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
21.7.3.3 After Switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-10
21.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-11
Chapter 22 • Advice Retrieval Service—SMS

22.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-3
22.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-3
22.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-4
22.5.1 VisaNet-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-6
22.5.2 Client-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-7
22.6 How SMS Advice Retrieval Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-8
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 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-9
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 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12
Chapter 23 • ATM Format Conversion Service

23.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-3
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 vii

Contents
23.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4
23.3.1 ATM Format Conversion Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4
23.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
23.4.3.1 Existing Card Range Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
23.4.3.2 New Card Range Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
23.6 How ATM Format Conversion Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-6
23.6.1 Message Augmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-7
23.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-8
23.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-10
Chapter 24 • Card Verification Value (CVV) Service

24.1 Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-3
24.2 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-4
24.2.1 CVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-4
24.2.2 dCVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-5
24.4 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-6
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.1 Issuer Participation Requirements (CVV and iCVV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-8
24.5.2 Acquirer Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-9
viii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
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-11
24.5.4 Service Monitoring for CVV and iCVV Service Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-12
24.5.4.1 Issuer Monitoring Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-12
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
24.5.5.2 Planning and Implementation for Acquirers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-16
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 Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-20
24.7 How Card Verification Value (CVV) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-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
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-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
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 ix

Contents
Chapter 25 • Card Verification Value 2 (CVV2) Service

25.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-3
25.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-4
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-8
25.5.1 BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
25.5.2 BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
25.6 How Card Verification Value 2 (CVV2) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
25.6.1 CVV2 Calculation, Encryption, and Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
25.6.1.1 CVV2 Expiration Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
25.6.1.2 DES Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
25.6.1.3 Encryption Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
25.6.1.4 Card Verification Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
25.6.2 Issuer Option Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
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-12
25.6.4 CVV2 Processing Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-13
25.6.5 CVV2 Verification-Only Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-14
25.6.6 CVV2 Emergency Replacements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-14
x Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
25.6.6.1 CVV2 Emergency Replacement Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
25.6.7 When Transactions Contain Both a CVV2 and a CAVV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
25.6.8 MasterCard CVV2 Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
25.6.9 American Express, Diners Club, and Discover Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
25.6.9.1 American Express. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
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-17
25.6.12 Visa Europe CVV2 CNP Fee Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
25.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-18
25.7.1 CVV2 Pass-Through Processing for Card-Present Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-20
25.8.1 Key Fields Glossary for CVV2 Emergency Replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-23
Chapter 26 • Cardholder Authentication Verification Value (CAVV) Verification Service

26.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-3
26.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-4
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.1 BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
26.5.2 BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-8
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xi

Contents
26.6 How Cardholder Authentication Verification Value (CAVV) Verification Service Works. . . . . . . . . . . . . . . . . . . .26-8
26.6.1 CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-9
26.6.2 Verifying CAVV Results From Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-13
26.6.3 Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-13
26.6.4 Dispute Resolution Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
26.6.5 Ineligible Transactions Passing CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
26.6.6 When Transactions Contain Both a CAVV and a CVV2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
26.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-15
Chapter 27 • Custom Payment Service (CPS)/ATM

27.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-3
27.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-4
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-6
27.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-6
27.5 How Custom Payment Service (CPS)/ATM Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-7
27.6 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-8
27.6.1 Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
27.6.1.1 Downgraded Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
27.6.1.2 Special ATM Handling Fee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
27.6.2 Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
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-11
xii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
27.6.3 Exception Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-11
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.8.1 Other Related Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-16
Chapter 28 • Custom Payment Service (CPS)/POS

28.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-3
28.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-4
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-6
28.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
28.5 How Custom Payment Service (CPS)/POS Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
28.5.1 Reclassification From CPS/POS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28.5.2 CPS/POS Program Clearing Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28.5.2.1 Qualification Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
28.5.3 Fee Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.4 Ineligible CPS/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.5 Amount Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
28.5.5.1 Adjusting Amounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
28.5.6 Chargeback Reduction Service (CRS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
28.5.6.1 CPS Authorization-Related Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . .28-9
28.5.6.2 Chargeback Reduction Service Life-Cycle Control. . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
28.6 CPS/POS Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
28.7 Common CPS/POS Data Requirements: All National Markets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-10
28.7.1 Common CPS/POS Authorization Field Edit Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-10
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xiii

Contents
28.7.2 Common CPS/POS Clearing Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-12
28.8 National Market CPS/POS Program: Brazil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-14
28.8.1 Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-14
Chapter 29 • Deferred Clearing Advice File (DCAF) Service

29.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-3
29.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
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.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-6
29.4.4 Issuer Host Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-7
29.6 How Deferred Clearing Advice File (DCAF) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-8
29.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-9
29.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-10
Chapter 30 • Dynamic Key Exchange (DKE) Service

30.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-3
30.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1.1 Implementation Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
30.3.1.2 Key Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4
xiv Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
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.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6
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-7
30.5.3 Client-Provided Key Exchange Messages (V.I.P. Slave). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
30.6 How Dynamic Key Exchange (DKE) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
30.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
30.7.1 On-Request Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-8
30.7.2 Automatic Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-10
30.7.3 Client-Provided Key Exchange Process Flow (V.I.P. Slave). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-11
30.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-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 Client-Provided Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-17
30.8.4 Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-19
Chapter 31 • Multicurrency Service

31.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-3
31.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-4
31.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-5
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xv

Contents
31.4.3.1 Decimal Positioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-5
31.4.3.2 Clearing and Settlement Currency Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
31.4.3.3 The Currency Precision Service for Acquirers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
31.4.3.4 The Currency Precision Service for Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
31.4.3.5 Optional Issuer Fee (OIF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
31.6 How Multicurrency Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
31.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-8
31.7.1 Multicurrency Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-8
31.7.1.1 Processing VisaNet-Acquired MasterCard Transactions. . . . . . . . . . . . . . . . . . . . .31-9
31.7.1.2 Processing for Non-Participating Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
31.7.2 VisaNet BASE II Currency Rate Delivery Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
31.7.3 Currency Conversion Charge Calculation Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
31.7.4 How VisaNet Applies Buy and Sell Currency Conversion Rates to Transactions. . . . . . . . .31-11
31.7.4.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-11
31.7.4.2 Currency Conversion Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
31.7.4.3 Using USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
31.7.4.4 Using Non-USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-20
31.7.4.5 Classifying Transactions by Exchange Direction Type. . . . . . . . . . . . . . . . . . . . .31-25
31.7.5 Currency Precision Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-28
31.7.5.1 One Position Decimal Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-29
31.7.5.2 Two Position Decimal Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-29
31.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-30
31.8.1 Message Flows Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-31
31.8.2 BASE I, POS, and ATM Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-31
31.8.3 SMS POS Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-33
31.8.4 SMS Visa/Plus ATM Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-40
31.8.5 SMS Interlink Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-47
31.8.6 Partial Amount Authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-59
31.8.6.1 Processing POS Balance Returns With Multiple Currencies. . . . . . . . . . . . . .31-60
xvi Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
31.8.6.2 Acquirer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-60
31.8.6.3 Issuer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-61
31.8.6.4 Message Flow Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-61
Chapter 32 • PIN Verification Service (PVS)

32.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-3
32.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-4
32.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-5
32.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-7
32.4.3.1 Prerequisites for Using the PVV Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-8
32.4.3.2 Prerequisites for Using the IBM PIN Offset Method. . . . . . . . . . . . . . . . . . . . . . .32-10
32.4.3.3 Placement of Data on Track 1 of the magnetic stripe. . . . . . . . . . . . . . . . . . . . .32-12
32.4.3.4 Placement of Data on Track 2 of the magnetic stripe. . . . . . . . . . . . . . . . . . . . .32-12
32.4.4 MasterCard PIN Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
32.5 Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
32.6 How PIN Verification Service (PVS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
32.6.1 PIN Verification Value (PVV) Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
32.6.2 IBM PIN Offset Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-14
32.6.3 Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-14
32.6.3.1 Acquirer Zone and Working Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-15
32.6.3.2 Issuer Zone and Working Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
32.6.3.3 PIN Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
32.6.4 Triple Data Encryption Standard Requirements and Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
32.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-18
32.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-20
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xvii

Contents
32.8.1 MasterCard PIN Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-21
Chapter 33 • POS Check Service

33.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-3
33.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-3
33.3.1 Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-4
33.3.2 POS Check Service Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-5
33.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-6
33.4.3.1 Acquirer or Processor Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-6
33.4.3.2 Merchant Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-7
33.4.3.3 Participating Drawee Financial Institution Implementation. . . . . . . . . . . . . . . .33-8
33.4.3.4 Delivery Methods for POS Check Service Requests. . . . . . . . . . . . . . . . . . . . . . . . .33-8
33.6 How POS Check Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-9
33.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-9
33.7.1 Authorization Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-10
33.7.2 Settlement Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-11
33.7.2.1 Settlement Through VisaNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-11
33.7.2.2 Settlement Through the ACH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-12
33.7.3 ABA Account Number Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
33.7.4 MICR Line Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
33.7.5 Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
33.7.6 POS Check Exception Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
33.7.7 Visa Resolve Online (VROL) Processing of POS Check Transactions. . . . . . . . . . . . . . . . . . . . . . . .33-15
xviii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
Chapter 34 • Positive Authorization Capacity Management (PACM) Service

34.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-3
34.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4
34.4.1 Determining Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-5
34.4.1.1 Advice Message Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-5
34.4.2 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-5
34.6 How Positive Authorization Capacity Management (PACM) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
34.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
34.7.1 Determining Which Transactions To Divert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
34.7.1.1 Transactions Always Routed To STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
34.7.1.2 Transactions Eligible for STIP Diversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-7
34.7.1.3 Transactions Not Eligible for STIP Diversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-7
34.7.2 Calculating a Diversion Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-7
34.7.3 BASE I and SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-8
34.7.3.1 BASE I Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-8
34.7.3.2 SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-9
34.7.3.3 Stand-In Processing of PACM-Diverted Transactions. . . . . . . . . . . . . . . . . . . . . .34-10
Chapter 35 • Positive Cardholder Authorization Service (PCAS)

35.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-3
35.2.1 Key Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
35.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xix

Contents
35.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
35.6 How Positive Cardholder Authorization Service (PCAS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-5
35.6.1 Merchant Category Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-6
35.6.2 Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-6
35.6.3 Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
35.6.3.1 Merchant Category Group Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
35.6.3.2 Total Purchase and Total Cash Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
35.6.3.3 Issuer-Available- and Issuer-Unavailable-Activity Limits. . . . . . . . . . . . . . . . . . . .35-7
35.6.3.4 Count, Amount, and 4-Day Multiplier Activity Limits. . . . . . . . . . . . . . . . . . . . . . .35-8
35.6.4 Mandated Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
35.6.4.1 Mandatory Minimum (T&E) Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
35.6.4.2 Mandatory Minimum Non-T&E Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
35.6.4.3 Mandatory Minimum Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
35.6.4.4 Applying Appropriate Issuer and Activity Limits:

Issuer-Specified or Visa-Mandated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
35.6.4.5 Overriding Mandatory Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
35.6.4.6 Mandatory Zero MOTO Issuer Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
35.6.5 Advice Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
35.6.6 Activity Checking and Accumulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-11
35.6.7 Cardholder Risk Levels and Individual Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-12
35.6.7.1 Defining Risk-Level Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
35.6.7.2 Multiple Limit Selection Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
35.6.8 Random Selection Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
35.6.9 BIN Blocking and Country Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
35.6.9.1 Risky Countries and Country-to-Country Embargoes. . . . . . . . . . . . . . . . . . . . .35-14
Chapter 36 • Preauthorized Payment Cancellation Service (PPCS)

36.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-3
xx Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
36.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-4
36.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-5
36.6 How Preauthorized Payment Cancellation Service (PPCS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-5
36.6.1 Updating the Cardholder Database Portfolio File (PF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
36.6.1.1 File Edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-7
Chapter 37 • Status Check Service

37.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-3
37.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-4
37.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-4
37.6 How Status Check Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-5
37.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-6
37.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-7
Chapter 38 • Visa Cashback Processing: VisaNet Cashback Service

38.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-3
38.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-4
38.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-5
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xxi

Contents
38.4.4 Issuer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
38.4.4.1 Magnetic Stripe Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
38.4.4.2 Chip Card Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
38.4.5 Acquirer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-7
38.4.5.1 Chip Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-7
38.6 How VisaNet Cashback Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-8
38.6.1 Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-9
38.6.2 PIN Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-9
38.6.3 VSDC Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-9
38.6.4 Participating Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
38.6.5 Other Cashback Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
38.6.5.1 United Kingdom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
38.6.5.2 United States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
Chapter 39 • Visa Token Service

39.1 In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-3
39.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-3
39.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-5
39.5 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-6
39.6 Token Data Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-7
xxii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Contents
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IX-1
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xxiii

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

Figures
1 Sample Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

17-1 Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7
17-2 Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
18-1 Record Type Structure by Merchant (Card Acceptor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-9
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-13
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-14
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-9
23-2 ATM Format Conversion Service Authorization Request Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-10
23-3 ATM Format Conversion Service Reversal (Misdispense) Request Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-11
23-4 ATM Format Conversion Service Reversal Request Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-12
25-1 CVV2 Process Flow and Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-19
29-1 DCAF Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-9
29-2 DCAF Service Deferred Clearing Advice Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-11
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 Multicurrency Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-9
31-2 Purchase Transaction—USD-Based Currency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-15
31-3 Purchase Transaction—Non-USD-Based Currency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-22
31-4 Example of One-Decimal Position Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-29
31-5 Example of Two-Decimal Position Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-30
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xxv

Figures
31-6 Message Flow—BASE I POS ATM Transactions, No Cashback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-32

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

Tables
1 Document Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
2 V.I.P. System Manual Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
16-1 Purchase and Cash Activity Merchant Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
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-6
18-1 Effective Date for File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5
18-2 MCF Record Types and Data by Card Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10
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-16
20-3 Fixed Format Address and Postal or ZIP Code Compression by First Five Numerics for U.K. Participants.20-16
20-4 AVS Format Matching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-17
20-5 Field 44.2 Address Verification Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-19
20-6 AVS Result Code Conversion Based on Jurisdiction and Representment Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-20
20-7 AVS Result Code Conversion Based on Acquirer Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-21
20-8 Sample Address Verification Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-21
20-9 Abbreviations Used in Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-25
20-10 Full and Compressed Data Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-35
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
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xxvii

Tables
24-11 dCVV Verification Service Options for Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-27

25-1 CVV2 Processing Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-13
25-2 CVV2 Error Codes for Emergency Replacement Cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
25-3 CVV2 Key Data Requirements and Fee Program Edit Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-18
25-4 Subfield 126.10 Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-23
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-11
26-4 Chargeback Reason Codes the CAVV Verification Service Does Not Allow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
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
28-1 CPS/POS Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
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-13
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-7
30-1 DKE Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-19
31-1 New Rate-Related Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-11
31-2 Map of Section Terminology to V.I.P. and BASE II Fields in Purchase Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-11
31-3 Processing Rules for USD-Based Rate Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-13
31-4 Example of USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-15
31-5 Currency Entry for USD-Based Rate in TC 56 Record for Scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-16
31-6 Populating Amount Fields in V.I.P. and BASE II Transactions for Scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-17
31-11 Processing Rules for USD-Based Rate Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-21
31-12 Example of Non-USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-22
31-13 Currency Entry for Non-USD-Based Rate in TC 56 Record for Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-23
31-15 Currency Entry for Non-USD-Based Rate in TC 56 Record for Scenario 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-25
31-17 Buy–Sell Currency Conversion Direction by Transaction Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-26
31-18 Sell–Buy Currency Conversion Direction by Transaction Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-28
31-19 Field 54 Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-65
32-1 Triple Data Encryption Migration Dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
32-2 Field 53 Security Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-25
33-1 POS Check Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-4
33-2 POS Check Service Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-5
33-3 POS Check Field 125 Format Requirements—Unformatted MICR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-17
33-4 POS Check Field 125 Format Requirements—Parsed MICR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-18
34-1 BASE I PACM Diversion Tables by Visa Region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-9
34-2 SMS PACM Diversion Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-10
35-1 Choosing Issuer-Specified or Visa-Mandated Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
xxviii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Tables
36-1 Portfolio File Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-7

36-2 PF Data Elements for Field 127. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-8
38-1 Cashback Services Currently Supported by VisaNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-5
38-2 Cashback Programs in the U.K. and the U.S.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 xxix

Tables
xxx Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

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

information about various services available from the VisaNet Integrated Payment (V.I.P.)
System, including processing specification details. Message and process flow diagrams
illustrate ways the services work. Examples address situations, questions, and problems.
Each service chapter lists available documents containing additional information, technical
specifications, service implementation specifics, and service activation information.
Audience
This manual is intended for Visa clients’ technical and non-technical staff and managers,
and Visa customer support personnel who answer clients’ system and production
questions. Non-technical staff may find this information useful in making decisions about
subscribing to services and selecting service options.
Readers without a working knowledge of VisaNet and the V.I.P. System should see
Chapter 1, Introduction to System Services, and Chapter 2, System Fundamentals,
before reading the service descriptions.
Manual Structure
The two-volume V.I.P. System Services manual has seven parts, based on service functions.
Volume 1
Part 1: System Basics (Chapters 1 and 2)—Part 1 defines V.I.P. services and the manual’s
scope. It also describes the V.I.P. System, VisaNet components, and V.I.P. transaction
processing.
Part 2: Routing Services (Chapters 3 through 10)—Part 2 describes routing messages

to networks and systems outside VisaNet and additional, optional services for routing
messages within VisaNet.
Part 3: Risk Management Services (Chapters 11 and 12)—Part 3 describes risk

management services available through the V.I.P. System.
Part 4: Visa Secure Electronic Commerce (VSEC) Services (Chapter 13)—Part 4

describes the VSEC service available through the V.I.P. System providing security for
electronic payment transactions sent over the Internet.
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 1

System Documentation Descriptions About This Manual
Part 5: Chip Card Services (Chapters 14 and 15)—Part 5 describes services available
through the V.I.P. System using chip cards and terminals that read chip cards in addition
to magnetic stripe cards.
Volume 2
Part 6: Authorization Database Files and Services (Chapters 16 through 18)—Part 6

describes the Cardholder Database and the Automatic Cardholder Database Update
(Auto-CDB) Service, which clients can use to update the Cardholder Database. Part 6 also
describes the Merchant Central File and the Merchant Central File Service (MCFS).
Part 7: Authorization Services (Chapters 19 through 39)—Part 7 describes services

related to message authorization.
Document Conventions
Table 1 Document Conventions
Document
Convention Purpose in This Manual
boldface Extra emphasis (stronger than italics); field values and codes.
EXAMPLE Identifies what the accompanying text describes or explains.
IMPORTANT Highlights important information in 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 not directly involved in the process being
shaded illustrations
illustrated in the graphic.
white boxes in flow
Represent request messages.
diagrams
shaded boxes in flow
Represent response messages.
diagrams
dotted line boxes in flow
Illustrate advice messages.
diagrams
System Documentation Descriptions

This two-volume book is part of the V.I.P. documentation suite. V.I.P. System Services,
Volume 1 and Volume 2, is a companion to the V.I.P. System Overview. (See “System
Information Sources” for sources used to prepare this manual.)
The first 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 to BASE I System and Single Message
System (SMS) processing.
2 Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

About This Manual System Documentation Descriptions
The next 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, Interlink, and POS are consolidated in one manual, V.I.P. System SMS Processing
Specifications (U.S.). For the international audience, there are processing specifications
manuals for ATM and POS.
Table 2 V.I.P. System Manual Descriptions
General Information
V.I.P. System Overview
Describes the VisaNet network and its components, connection methods, processing concepts,
requirements, and options. Defines the V.I.P. System, the BASE I System, and the Single Message
System (SMS), Direct Exchange (DEX) and Visa Extended Access Servers (EA Servers), issuer
and acquirer responsibilities, and Visa Interchange Center (VIC) operations. Briefly introduces
V.I.P. services.
Doc ID 0851-28
V.I.P. System Reports
Provides sample reports for BASE I and SMS processing and V.I.P. services.
Doc ID 0852-28
V.I.P. System Services, Volume 1
Describes V.I.P. services available to BASE I and SMS users. Service descriptions include basic
information, processing requirements, options, features, key message fields, and message flows.
Volume 1 contains:
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-28
Describes V.I.P. services available to BASE I and SMS users. Service descriptions include basic
information, processing requirements, options, features, key message fields, and message flows.
Volume 2 contains:
Part 6: Authorization Database Files and Services

Part 7: Authorization Services
Doc ID 0853B-28
BASE I
V.I.P. System BASE I Processing Specifications
Describes V.I.P. transaction processing in the BASE I environment, including message types,
processing considerations, related services, and VisaNet connection methods.
Doc ID 0847-28

System Documentation Descriptions About This Manual
Table 2 V.I.P. System Manual Descriptions (continued)
V.I.P. System BASE I Technical Specifications, Volume 1
Defines technical specifications of V.I.P. transaction processing in the BASE I environment.

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

This companion to V.I.P. System BASE I Processing Specifications describes message formats
and file specifications for BASE I.
Doc ID 0844B-29
Interlink
V.I.P. System SMS Processing Specifications (U.S.)
Contains information about SMS, including message types, processing considerations,

VisaNet connection methods, and related services for Interlink, Visa and Plus ATM, Visa POS,
and Visa Electron.
Doc ID 0857-28
V.I.P. System SMS Interlink Technical Specifications
Companion to V.I.P. System SMS Processing Specifications (U.S.). Describes message formats,
field descriptions, and file specifications for Interlink.
Doc ID 0866-27
SMS ATM

VisaNet connection methods, and related services for Visa and Plus ATM, Interlink, Visa POS,
and Visa Electron for clients in the Visa U.S.A. (U.S.) region.
Doc ID 0857-28
V.I.P. System International SMS ATM Processing Specifications
Contains information about SMS ATM processing, including message types, processing
considerations, VisaNet connection methods, and related services for clients outside the
U.S. region.
Doc ID 0839-28
V.I.P. System SMS ATM Technical Specifications, Volume 1
Companion to V.I.P. System SMS Processing Specifications (U.S.) and V.I.P. System International
SMS ATM Processing Specifications. Contains information about field descriptions for ATM.
Doc ID 0868A-27
V.I.P. System SMS ATM Technical Specifications, Volume 2
Companion to V.I.P. System SMS Processing Specifications (U.S.) and V.I.P. System International SMS
ATM Processing Specifications. Contains information about message formats and file specifications
for ATM.
Doc ID 0868B-27

About This Manual Other Documents
Table 2 V.I.P. System Manual Descriptions (continued)
SMS POS

VisaNet connection methods and related services for Visa POS, Visa Electron, Visa and Plus
ATM, and Interlink for clients in the U.S. region.
Doc ID 0857-28
V.I.P. System International SMS POS (Visa & Visa Electron) Processing Specifications
Contains information about SMS POS processing, including message types, processing
considerations, VisaNet connection methods, related services, and reports for clients outside
the U.S. region.
Doc ID 0835-28
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1
Companion to V.I.P. System SMS Processing Specifications (U.S.) and V.I.P. System International SMS
POS (Visa & Visa Electron) Processing Specifications. Describes fields for Visa POS and Visa Electron.
Doc ID 0869A-28
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 2
Companion to V.I.P. System SMS Processing Specifications (U.S.) and V.I.P. System International
SMS POS (Visa & Visa Electron) Processing Specifications. Describes message formats and file
specifications for Visa POS and Visa Electron.
Doc ID 0869B-27
System Information Sources

This section lists primary sources for information in V.I.P. System Services. Information is
analyzed, rewritten, and reorganized, when necessary. Technical staff and subject matter
experts review and verify these updates. Additionally, this revised manual incorporates
all approved comments and change requests received from clients and Visa staff.
V.I.P. System Manuals

See Table 2.
VisaNet Business Enhancements Global Technical Letters and

Implementation Guides
The V.I.P. System Services, Volume 1 and Volume 2, include information from the April 2016
VisaNet Business Enhancements Global Technical Letter and Implementation Guide,
Version 3.0, effective 10 March 2016.
Other Documents
Other documents used as sources for V.I.P. System Services include the Visa Core Rules and
Visa Product and Service Rules, RTN publications, general and detailed design documents,
and service advisories.

Chapter Structure About This Manual
How To Use This Book

This manual has seven parts, based on service functions, to help readers quickly find
information about available services.
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 “Manual Structure.” Except for
introduction and overview chapters, which appear first, service chapters within each part
are listed alphabetically.
Each service description chapter follows a standard structure, sharing section headings to
make finding information as easy as possible. A service description chapter explains the
service and presents the following sections.
Eligible Participants
This section contains text and icons (simple graphics) identifying which entities can use
the service. Icons indicate:
—The regions in which the service is available

Icons identify the five Visa regions and Visa Europe. Each icon indicates the service is
available to clients in that region or Visa Europe. The “ALL” icon indicates the service is
available to clients in all Visa regions and Visa Europe.
Represents all Visa regions and Visa Europe
Represents the Asia-Pacific (AP) region
Represents the Visa Canada (CAN) region

NOTE
V.I.P. internally refers to Visa Canada as CA, but V.I.P. documentation refers to Visa Canada as CAN.

About This Manual Chapter Structure
Represents the Central and Eastern Europe, Middle East, and Africa (CEMEA) region
Represents Visa Europe (VE)
Represents the Latin America and Caribbean (LAC) region

Chapter Structure About This Manual
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
SMS only
BASE I
SMS
BASE I and SMS

About This Manual Interpreting Flow Diagrams
—The client for which the service is available (issuer or acquirer)
Issuer
Acquirer
Service Summary
This section describes the service and available options.
Participation Requirements
This section describes all prerequisites and requirements for participating in the service.
It provides information about:
• Testing.
• Service monitoring.
• Planning and implementation.
Related Messages
This section lists message types the service directly uses or that contain key service fields.
How the [Service Name] Works
This section provides processing details about each service, including:

• Process flows, which visually represent processing.
• Message flows, which illustrate message flows and significant field information from the
message initiator through VisaNet to the message recipient.
In some cases, the process and message flows are combined.
Key Fields Glossary

This section lists fields directly influencing service processing and describes them and
their contents.
For More Information

This section lists other publications providing additional service information.
Interpreting Flow Diagrams

The process and message flow diagrams in each chapter illustrate the path messages take
from message originator to message recipient.
• Icons show the message destinations (acquirer, V.I.P., issuer, merchant, network, vendor).
• Arrows indicate the entity creating the message and the entity receiving it (acquirer, V.I.P.,
issuer, merchant, network, vendor).

Interpreting Flow Diagrams About This Manual
Boxes list key message fields and values contained in the messages.
• White boxes represent request messages. Shaded boxes represent response messages.
• Boxes with dotted lines illustrate advice messages. Arrows between boxes indicate
advice message creators and advice paths.
NOTE
V.I.P. typically creates advice messages for issuers to let them know it performed processing on their behalf.
In Figure 1, the acquirer creates the request message and sends it to V.I.P. within VisaNet.
V.I.P. processes the message and, 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 and sends it to the acquirer.
In Figure 1, V.I.P. creates an advice for the issuer to recover. When the issuer receives the
advice, it responds with an advice response message.
NOTE
Responding to some advices is optional. For other advices, responses are mandatory.
Figure 1 Sample Message Flow
Acquirer V.I.P. Issuer
0100 Request 0100 Request 0100 Request
0110 Response 0110 Response 0110 Response
0x2x Advice 0x2x Advice
0x3x Advice Response 0x3x Advice Response

About This Manual Related Publications
NOTE
Message flows indicate key fields.
Obtaining Report Samples

Visa offers reports to clients. Many reports clarify and track service processing.
These manuals provide report samples:
• V.I.P. System Reports
• VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports
For More Information

Visa provides documentation to support products and services. For many services
described in this manual, Visa develops implementation guides containing regional details
about signing up for a service, selecting options, and installing, testing, and operating the
service. Clients can ask their Visa representatives for regional guides.
The V.I.P. documentation does not contain details about the BASE II System.
Related Publications
The publications listed provide information about Visa systems, rules, and additional
services not covered in this manual.
Use the following information to get publications, to be added to or removed from

distribution lists, or to ask about other publications.
• U.S. clients and third-party processors can contact Publication Orders at
publicationorders@visa.com.
• Clients and third-party processors in other Visa regions or Miami can contact their
Visa representatives.
If you have comments or questions about this document or technical questions about a
Visa service or capability, contact your Visa representative.
Visa Rules
Visa Core Rules and Visa Product and Service Rules contain the Visa Rules.
Qualifying merchants and third-party agents can also request the Interchange Qualification
Guide.
PIN Management Requirements
Payment Card Industry PIN Security Requirements Manual—Contains requirements for

securely managing, processing, and transmitting personal identification number (PIN) data
during online and offline payment card transaction processing at ATMs and attended
and unattended terminals.
PIN-Entry Device Security Requirements—The following contain physical and logical

security device requirements and management procedures for online and offline PIN-entry
devices and procedures and forms to measure compliance:

Related Publications About This Manual
• Payment Card Industry Encrypting PIN PAD (EPP) Security Requirements Manual
• Payment Card Industry POS PIN-Entry Device Security Requirements Manual
POS Check Service
Visa Core Rules and Visa Product and Service Rules
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
Card Recovery Bulletin Service User's Guide
Fraud Reporting System (FRS) User's Guide
Issuer's Clearinghouse Service User's Guide
Risk Management Process Guide
Visa Fraud Monitoring Program Guide
Visa Risk Manager
Security
Payment Technology Standards Manual—Contains standards for PINs and encoding

account and cardholder data on Visa payment form factors.
Visa Extended Access Servers (EA Servers)
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)
Visa Incentive Network Service Description
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
Visa Traditional Rewards Registration Toolkit
Visa Signature Registration Toolkit

About This Manual Related Publications
Visa Resolve Online (VROL)
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
Visa Resolve Online Reference Manual
Visa Resolve Online User's Guide
Visa Smart Debit/Smart Credit (VSDC) Service
JCB, MasterCard, Visa (EMV) Specifications, EMV '96 Version 3.1.1 and EMV 2000
Version 4.0—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—Briefly describes VSDC
program features and benefits.
Visa Smart Debit and Credit Planning Guide—Helps clients plan VSDC programs and
migration strategies.
Visa Smart Debit and Credit Member Implementation Guide for Acquirers—Provides
guidelines for acquirers implementing VSDC programs.
Visa Smart Debit and Credit Member Implementation Guide for Issuers—Provides guidelines
for issuers implementing VSDC programs.
Visa Smart Debit/Visa Smart Credit System Technical Manual—Provides information for
clients and Visa staff responsible for implementing and operating VSDC programs.
Visa Integrated Circuit Card Specifications (VIS)—Contains technical specifications for the
VSDC card application, describing VSDC transaction functionality and flow.
Miscellaneous Systems and Services

Authorization Gateway Service Cross-Reference Guide—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—Contains information about the Visa and Plus
International ATM Program. It includes a program overview, 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

Related Publications 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:
Chapter 16, Cardholder Database Overview—This chapter describes the Cardholder

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—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.
Chapter 18, Merchant Central File Service (MCFS)—This chapter provides an overview
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.
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2

Visa Confidential V.I.P. System Services, Volume 2 1 June 2016
Cardholder Database Overview 16
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
Database Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
File Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4

How V.I.P. Determines Effective and Update Date and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4
File Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5

Related Services Listings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5
Activity File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5

Merchant Group Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
PIN-Entry Attempt Activity Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7
Advice File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
Card-Level Product ID File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9

Visa International Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9
Online Exception File Editing Summary (0302 Messages). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11
Exception File Purge Date Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
Global Customer Assistance Services (GCAS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
PIN Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
Portfolio File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14
Risk-Level File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14
For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-15
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 16-1

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

Cardholder Database Overview 16
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

File Record Format Chapter 16: Cardholder Database Overview
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 Spending
Number Account Purge Country Action Region Amount Count Update Effective
Length Number Date Code Code Coding Limit Limit Time Time
PIN Verification File

Account Cardholder
Number Account PIN Verification
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 Daily Group
Number Account Purge Country Issuer 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 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.

Chapter 16: Cardholder Database Overview Activity File
For the Exception File, update time refers to the first date and time that VisaNet updates
the file with an action code other than an approval, that is, pick-up codes 01, 04, 07, 41,
or 43. VisaNet keeps this date and time and does not change it during subsequent
updates 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.).
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)—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.
The Positive Cardholder Authorization Service (PCAS)—Issuers establish activity limits

(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.

Activity File Chapter 16: Cardholder Database Overview
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.
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

Chapter 16: Cardholder Database Overview Address Verification File
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
Travel Lodging Rental Restaurant Phone Purchase Purchase Total Cash ATM 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.
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:
The Address Verification Service (AVS)—When V.I.P. verifies addresses, it checks 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.

Card-Level Product ID File Chapter 16: Cardholder Database Overview
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.
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—Product ID with the appropriate product
value for the card 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:

Chapter 16: Cardholder Database Overview Exception File
• 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 client should confiscate the card if a cardholder presents it.
• STIP should provide a referral response. Acquirers try to contact issuers directly.
• The issuer should process the request whenever possible.
• STIP should approve transactions on this account regardless of cardholder activity.
Exception File—V.I.P. uses this file for authorizations and issuers maintain it. Issuers use it
to list accounts in the CRB
The Exception File types are:
E1—Exception File (V.I.P. Auth-Only)—batch file update only
E2—Exception File (V.I.P. Auth-Only)
E3—Exception File (V.I.P. Auth-Only and V.I.P. Full Service)
E4—Exception File (V.I.P. Full Service)
Issuers can update the Exception File using an online transaction. To list an account
number, issuers use message type 0302 specifying file type E1, E2, E3, or E4. Once issuers
list an account number using file type E3, for any future updates for that account number,
issuers must always use file type E3; 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:

Exception File Chapter 16: Cardholder Database Overview
Account Verification Service—When V.I.P. STIP receives an account verification request,

it checks the card expiration date and the Exception File.
ATM/POS Split Routing Service—The ATM/POS Split Routing Service allows issuers that
operate as alternate processors to update and to access exception file account records
on behalf of the primary issuer.
Automatic Cardholder Database Update (Auto-CDB) Service—If an issuer participates

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-up
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—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,
non-fraudulent), 07 (pick-up card (special conditions [other than lost, stolen, or counterfeit card]), (41 (pick-up
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.
Visa Shortest Online Path (VSOP) Service—As part of standard request processing,
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.

Chapter 16: Cardholder Database Overview Exception File
16.9.2 Online Exception File Editing Summary (0302 Messages)

Clients 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 client 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
Code 530—Invalid File Type. Valid file types are E1, E2, E3, and 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 Error—0565
Delete E2 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
Add E3—
Network specified Add/Replace Add/Replace Replace
Add E3—
Network not specified Replace Add/Replace Add/Replace Replace
Add E4 Replace Replace Replace
Change E3—
Network specified Add Add/Change Add/Change

PIN Verification File Chapter 16: Cardholder Database Overview
Table 16-3 V.I.P. Format Exception File Update Processing Actions (continued)
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
Change E3—
Network not specified Add Add/Change Add/Change
Change E4 Add Add Add Add
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.
Format 2 Additions and Changes—For additions and changes to Exception File records,
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.
Purge Date Assignments—When the Auto-CDB Service initiates an update to the

Exception 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 can 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.

Chapter 16: Cardholder Database Overview PIN Verification File
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.
Related Services
The following V.I.P. System services rely on the PIN Verification File:
ATM/POS Split Routing Service—The ATM/POS Split Routing Service allows issuers that
operate as alternate processors to update and to access PIN Verification File account
records on behalf of the primary issuer.
PIN Verification Service (PVS)—The issuer must place PVVs and PVKIs or offsets on the
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.
PIN/No-PIN Split Routing Service—If the issuer uses the Split Routing option for
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.
Visa Shortest Online Path (VSOP) Service—For VSOP issuers, V.I.P. uses information in
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.

Risk-Level File Chapter 16: Cardholder Database Overview
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
all authorizations order). SMS advices contain code 9031 in Field 63.4—STIP/Switch
Reason Code.
NOTE
Only BASE II transactions use code C2.
Related Services
The following V.I.P. System service relies on the Portfolio File:
Preauthorized Payment Cancellation Service (PPCS)—PPCS enables issuers 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.
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

Chapter 16: Cardholder Database Overview For More Information
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—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) 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.
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
If the issuer has not specified a risk level (A, B, C, or D), V.I.P. assigns the default risk
level (C).
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.)

For More Information Chapter 16: Cardholder Database Overview

Automatic Cardholder Database 17
Update (Auto-CDB) Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
Eligible Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3
Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4
How Automatic Cardholder Database Update (Auto-CDB) Service Works. . . . . . . . .17-5

Advice Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
Exception File Update Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
Exception File Discrepancy Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5

Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7

Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7
Key Fields Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8
For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-9


Automatic Cardholder Database 17
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 clients in all Visa regions.
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.

Related Messages Chapter 17: Automatic Cardholder Database Update
(Auto-CDB) Service
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.
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, clients must contact their Visa representatives.
17.4.2 Service Monitoring

Service monitoring is not available for the Auto-CDB Service.
17.5 Related Messages

The following messages pertain to the Auto-CDB Service.
0110: Auto-CDB Authorization 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.)
0120: Advice of Exception File Update—This message notifies issuers that V.I.P. has
updated the Exception File (Field 44.1—Response Source/Reason Code contains CRB
reason code 0).
0210: Financial Transaction Response—When issuers specify the pick-up action code in
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.
0322: File Update Advice—This message notifies issuers that choose to receive 0322
advices that V.I.P. updated the Exception File; it includes the updated authorization

Chapter 17: Automatic Cardholder Database Process Flows
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.
0332: File Update Advice Response—This message notifies V.I.P. that the issuer received
the 0322 advice.
17.6 How Automatic Cardholder Database Update (Auto-CDB)

Service Works
This section explains advice generation for the Auto-CDB Service.
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.
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.

Process Flows Chapter 17: Automatic Cardholder Database Update
(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 Pick-Up Card (non-fraud)—This code is a decline-and-pick-up response. For an
unspecified but non-fraud reason, the issuer wants the card recovered at the
point of sale or point of service (POS).
07 Pick-Up Card—Special Condition (fraud)—This code is a decline-and-pick-up
response. For a reason other than a lost or stolen card, the issuer wants the
card recovered at the POS.
41 Pick-Up Card—Lost Card (fraud)—This code is a decline-and-pick-up response.
A cardholder has reported a lost card; the issuer wants the card recovered.
43 Pick-Up Card—Stolen Card (fraud)—This code is a decline-and-pick-up
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.

Chapter 17: Automatic Cardholder Database Message Flows
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.
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, 07, 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 can respond
with an 0332 advice acknowledging receipt of the advice.

Key Fields Glossary Chapter 17: Automatic Cardholder Database Update
(Auto-CDB) Service
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
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.

Chapter 17: Automatic Cardholder Database For More Information
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
an advice. It appears in 0322 advices and contains code 9030, indicating a pick-up
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
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

For More Information Chapter 17: Automatic Cardholder Database Update
(Auto-CDB) Service

Merchant Central File Service 18
(MCFS)
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4

Updating the Merchant Central File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Effective Date for File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4
Acquirer Review of File Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
File Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6

MCFS-Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6
Merchant Central File Update Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7
How Merchant Central File Service (MCFS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-8

Establishing Merchant Central File Augmentation Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10
Merchant Category Code (Field 18). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-10
Merchant Name, Location, Country (Field 43). . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .18-11
Card Acceptor Identification Code (Field 42). . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .18-11
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
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
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-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
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-25
Key Fields Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-25

Key Fields Glossary for Merchant Central File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-27

Merchant Central File Service 18
(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
Network 0002.
BASE I and SMS
A Participation in MCFS is optional for both BASE I and SMS acquirers and
processors.
Acquirer

Service Summary Chapter 18: Merchant Central File Service (MCFS)

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).
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:
Online Update Through a VisaNet Connection—This method enables acquirers to

perform 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.)
Batch File Update—MCFS offers a batch update option. Clients must coordinate all batch
MCF update tape updates through their account managers. These files require additional
VIC processing time. Visa can provide clients 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. Clients 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:

Chapter 18: Merchant Central File Service (MCFS) Participation Requirements
Online Method—The effective date and time is the date and time the VIC receives the
message.
Batch Method—The effective date and time is the center-specified date and time in the
file 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... number 707).
The database effective date and time is equal For an update processed by the same VIC as
to the effective date and time of the update the previous update, V.I.P. accepts the change.
record... Otherwise, if a different VIC processes the
update, V.I.P. rejects the update with an 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.

Related Messages Chapter 18: Merchant Central File Service (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. Clients can contact their Visa representatives to make the
arrangements.
NOTE
Acquirers must submit their intended test MCFS records directly to the V.I.P. test system environment (VCMS).

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.
Acquirer Responsibilities—Acquirers are responsible for the contents and the

maintenance 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).
Visa Responsibilities—Visa is responsible for:
• 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:
0100: Authorization Request and 0200: Financial Request—When V.I.P. receives

an 0100 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):

Chapter 18: Merchant Central File Service (MCFS) Related Messages
• 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.
0110: Authorization Response and 0210: Financial Response—This message provides

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).
0400: Reversal Request—When V.I.P. receives an 0400 request for an acquirer, 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—This message is the response to an 0400 message,

acknowledging receipt of the reversal request. For an approval response, field 39 contains
response code 00.
18.5.2 Merchant Central File Update Messages

The following messages pertain to updating the MCF:
0300: Acquirer File Update Request—Acquirers use this message to add, change, delete,
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.
0310: Acquirer File Update Response—This message is the response to an 0300 file
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

How Merchant Central File Service (MCFS) Works Chapter 18: Merchant Central File Service (MCFS)
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 client's settings in the system tables (that Visa
representatives establish on behalf of the client) determine how V.I.P. adds or overlays the
MCF information and how it maintains the file records. Clients 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.

Chapter 18: Merchant Central File Service (MCFS) How Merchant Central File Service (MCFS) Works
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, clients 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
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 Discover American Express Terminal identification for
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 Core Rules and Visa Product and Service Rules lists valid codes.
Visa publishes amendments, additions, and changes in VisaNet Business Enhancements
Global Technical Letters and Implementation Guides for clients. 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 client. 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
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.

(field 41, field 42). The maximum merchant identifier for Universal card types is 23 bytes
(8 bytes 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

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
Express and record. This logic assumes the defined key pointer field is present in the
Discover request:
• 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
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 in the MCF MCF
Acceptance, ID 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 Institution Identification Institution
Acceptance, ID The 4- to 11-digit acquiring Code Identification Code
Discover, (Acquiring institution ID. (It is usually 6 digits.)
MasterCard BIN) 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 Type Merchant Record Type
Acceptance, The 1-character code identifying
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 is
MasterCard MMDDYY. The date 999900 means
an indefinite purge date.
Visa, Universal, Merchant Function: key identifier Field 41—Card Acceptor Field 41—Card
American Express, Identifier Terminal Identification Acceptor Terminal
Check Acceptance, A unique 1- to 15-digit code for Identification
Discover, the acquirer BIN's merchant or Field 42—Card Acceptor
MasterCard merchant's terminal. This field Identification Code Field 42—Card
along with the acquiring institution Acceptor Identification
ID constitutes the MCFS file key. 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.
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.

Table 18-5 Merchant Central File Record Fields (continued)
Record
Record Type Field Description 0100/0400 Fields 0300 Fields
American Express, Replacement Function: augmentation data Field 41—Card Acceptor Field 127M.2—Format 2,
Discover Terminal ID Terminal Identification Merchant Data 1
The 1- to 15-character terminal
identification replacement value Field 42—Card Acceptor
in field 41 or field 42 of the Identification Code
authorization request. V.I.P. adds
the identifier to the request
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 Acceptor Field 127M.3—Format 2,
MasterCard Acceptor Name/Location Merchant Data 2
Name, The 40-digit merchant identifier
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),
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),
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.
If field 41 contains 123456bb and field 42 contains 123456789bbbbbb,
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),
the resulting key is bbbbbbbbbbbbbbb1234bbbb.

Chapter 18: Merchant Central File Service (MCFS) Process Flows

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.
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.
If field 42 contains 123456789bbbbbb and field 41 contains 123456bb,
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),

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

Process Flows Chapter 18: Merchant Central File Service (MCFS)
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).

Chapter 18: Merchant Central File Service (MCFS) Process Flows
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.

Process Flows Chapter 18: Merchant Central File Service (MCFS)
• 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.
- If the first two digits of field 42 are 93, V.I.P. performs check-digit validation using
positions 1–10 of field 42.
- If the first two digits are not 93, 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
equal 60110, V.I.P. performs check-digit validation using positions 6–15 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. 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,
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.

Chapter 18: Merchant Central File Service (MCFS) Key Fields Glossary
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.

Key Fields Glossary Chapter 18: Merchant Central File Service (MCFS)
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 Core Rules and
Visa Product and Service Rules and to the Visa Charter Documents, as amended by
additions and changes published in VisaNet Business Enhancements and Technical
Letters for clients, 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:
U.S. Card Acceptors—This identifier is a numeric state code, a numeric ZIP code,
or both.
Canadian Card Acceptors—This identifier is a numeric province code, an alphanumeric

postal code, or both.
Card Acceptors Outside the U.S. or Canada—This identifier is a 1- to 14-position

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 client. 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 and A–F.
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

Clients 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.

Key Fields Glossary Chapter 18: Merchant Central File Service (MCFS)
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
with Error Code 0568—Invalid Value in Field 127—Format 1: File Maintenance.
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 BASE I format 2 MCF update requests,
and codes M9 and MCF for SMS 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:
American Express, Discover, Visa, Check Acceptance, and MasterCard—Field 127M.2

must appear in an 0300 request (except for check acceptance requests) if the code
in Field 101—File Name is M9 or MCF and the code in Field 91—File Update Code
is 1 or 2 (add or change).
Universal Data Format—Field 127M.2 appears if the code in field 101 is M9 or MCF,
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—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.
American Express, Discover, and Visa—This field does not apply for format 2
requests.
Check Acceptance, Universal Data, and MasterCard—This field appears in 0300

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.

For More Information Chapter 18: Merchant Central File Service (MCFS)
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.
American Express, Discover, Visa, and Check Acceptance—This field does not apply.
Universal Data—This field appears in 0300 format 2 add or change requests for the
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
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.
Universal Data—This field appears in 0300 format 2 add or change requests for the
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:
• V.I.P. System SMS ATM Technical Specifications, Volume 1 and Volume 2
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—Multicurrency Service
Chapter 32—PIN Verification Service (PVS)
Chapter 33—POS Check Service
Chapter 34—Positive Authorization Capacity Management (PACM) Service
Chapter 35—Positive Cardholder Authorization Service (PCAS)
Chapter 36—Preauthorized Payment Cancellation Service (PPCS)
Chapter 37—Status Check Service
Chapter 38—Visa Cashback Processing: VisaNet Cashback Service
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2

Visa Confidential V.I.P. System Services, Volume 2 1 June 2016
Account Verification Service 19
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-3

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-4
How Account Verification Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-5
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-6

MasterCard AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8


Account Verification Service 19
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 clients 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.

Related Messages Chapter 19: Account Verification Service
NOTE
A merchant's floor limit is an amount limit set by the acquirer (subject to Visa Rules 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 account.
• 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. Clients 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.
0100: Authorization Request—This message supports several functions related to

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.

Chapter 19: Account Verification Service How Account Verification Service Works
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.
0110: Authorization Response—This message is the authorization response.
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), 72 (PIN unblock or prepaid
activation), 00 (goods or service purchase), 01 (withdrawal or cash advance), or 11
(quasi-cash transaction) for BASE I.
• Field 25—Point-of-Service Condition Code contains 51 (zero amount account
verification).
If the 0100 message contains code 51 in field 25, but field 4 does not contain zero, V.I.P.
rejects the account verification request with Reject Code 0018—Invalid Value.
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

Process Flows Chapter 19: Account Verification Service
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.

Chapter 19: Account Verification Service Process Flows
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

Key Fields Glossary Chapter 19: Account Verification Service
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 Authorization Gateway Service Cross-Reference Guide.

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

Chapter 19: Account Verification Service Key Fields Glossary
Field 4—Amount, Transaction

This field should contain all zeros. V.I.P. ignores any other value. If the verification
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 85.
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. 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.

For More Information Chapter 19: Account Verification Service
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:
Volume 2

Address Verification Service (AVS) 20
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4

Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5
Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5

Visa Custom Payment Services (CPS)/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6
How Address Verification Service (AVS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-7

Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-9

When V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-11
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
Matching Merchant Address Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-17
Translating Fixed and TLV Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-17
Field 123 Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
U.S.-Domestic Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
U.K.-Domestic Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-18
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-20
Result Code Conversion Based on Acquirer Participation (U.K. and U.S. Only). . . .20-21

AVS Process Flow Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-22
V.I.P. Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-22
When the Issuer Performs Address Verification. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .20-23
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-24

V.I.P. Performs Address Verification and Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-25
V.I.P. Performs Address Verification Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-28
Issuer Does Not Support Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-29
Issuer Performs Address Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-30

Merchant Guide for AVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-37

Address Verification Service (AVS) 20
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.
For MasterCard transactions, U.S. acquirers can also use AVS service for cards issued
in Canada.
NOTE
The V.I.P. stand-in processor (STIP) performs address verification for Visa and proprietary and private-label
transactions only.

Service Summary Chapter 20: Address Verification Service (AVS)
AVS is available to clients 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.
Participation in AVS is optional for acquirers in all regions. Acquirers can

A 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.

Chapter 20: Address Verification Service (AVS) Participation Requirements
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. Clients can contact their Visa representatives to make the arrangements
for testing.

Clients 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.

Related Messages Chapter 20: Address Verification Service (AVS)

The following messages pertain to AVS:
0100: Authorization 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.
0110: Authorization 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.
0120: Advice—An 0120 advice notifies issuers when STIP processes an address
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.
0200: Financial Request—An 0200 financial request can include the address verification
request information. Acquirers can also use 0200 messages for address-verification-only
requests. V.I.P. and issuers send 0210 response messages to acquirers.
0210: Financial Transaction 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.
0220: Advice—An 0220 advice notifies issuers when V.I.P. processes an address
verification request on their behalf. V.I.P. sends 0220 advices to issuers and to acquirers
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.
0420: Advice—An 0420 advice notifies acquirers when V.I.P. sends an 0400 reversal
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:

Chapter 20: Address Verification Service (AVS) How Address Verification Service (AVS) Works
• 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 field 123, SMS rejects the message with Reject Code 0699—Presence of PIN/Track/AVS Data Inconsistent
With Message Type.
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.
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

How Address Verification Service (AVS) Works Chapter 20: Address Verification Service (AVS)
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:
Postal or ZIP Code—This field in AVF records contains either the cardholder's 5-digit or
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.
Address Verification Value (AVV)—This field in AVF records contains the leading digits
(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 20: Address Verification Service (AVS) Process Flows
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.

Process Flows Chapter 20: Address Verification Service (AVS)
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:
Full Format—The issuer receives the full 9-position postal or ZIP code and up to the first
20 alphanumeric characters of the street address.
Compressed Format—The issuer receives the 9-position postal or ZIP code and the
leading 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. clients.
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. Clients 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. can 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, clients 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
Length Subfield—The value in this subfield indicates the number of bytes of field 123
after the Length subfield.

Postal Code Subfield (Positions 1–9)—The value in this subfield is the postal or ZIP
code. 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, clients use a unique U.K.-only compressed format for sending address data
in field 123.
Cardholder Street Address (Positions 10–29)—This subfield contains up to 20 characters

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 can 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—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.)
Dataset ID (Position 1)—This subfield contains a one-byte binary identifier assigned

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.
Dataset Length (Positions 2–3)—This subfield contains a two-byte binary number that
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.

Address Verification TLV Elements (Positions 4–255)—This 252-byte maximum subfield

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

• 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.
Leading Numerics—V.I.P. scans the street address subfield from left to right, extracting
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.
First Five Numerics—V.I.P. scans the street address subfield from left to right, as it does
in 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 Compressed
Postal/ZIP by Leading by First Five
Code Actual Street Address Uncompressed 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
Postal or ZIP Code Actual Street Address Five 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 field 123, SMS rejects the message with Reject Code 0699—Presence of PIN/Track/AVS Data Inconsistent
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. clients 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.

Table 20-5 Field 44.2 Address Verification Result Codes (continued)
Code Applies to
Code Definition Domestic Global
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.
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. 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 client 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 (applies to the M D
United Kingdom only)

Table 20-6 AVS Result Code Conversion Based on Jurisdiction and

Representment Rights (continued)
Converted Result Code to Acquirer

Global Transaction
Issuer or V.I.P. Domestic Representment No Representment
Result Code Transaction Rights Rights
M1 Y (applies to the U.S. D
region only) or F
(applies to the United
Kingdom only)
D1 Y (applies to the U.S. M
region only) or F
(applies to the United
Kingdom only)
U I G
I2 U G
G2 U I
1. Only V.I.P. should use these codes. Issuers should use Y (or F, only in the United Kingdom).
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, 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 (in the U.S. region only) or
F (in the United Kingdom only)
I U
M Y (in the U.S. only) or F (in
the United Kingdom only)
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 Postal/ZIP Code AVV Code
Data (Field 123) Data Extracted (AVF) (AVF) (Field 44.2)
91234^^^ÔneÊlm^Street 91234 91234 1 Z

Table 20-8 Sample Address Verification Results (continued)
Visa's or
Issuer's Result
Merchant-Supplied Address Verification Postal/ZIP Code AVV Code
Data (Field 123) Data Extracted (AVF) (AVF) (Field 44.2)
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) 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, 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.

Message Flows Chapter 20: Address Verification Service (AVS)
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.

Chapter 20: Address Verification Service (AVS) Message Flows
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 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.

Chapter 20: Address Verification Service (AVS) Key Fields Glossary
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.

Key Fields Glossary Chapter 20: Address Verification Service (AVS)

Requests for address verification only (indicated by code 51 in Field 25—Point-of-Service
Condition Code), must include field 4 set to zeros. If STIP processes the request on
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
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1 and
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).

Chapter 20: Address Verification Service (AVS) Key Fields Glossary

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

For More Information Chapter 20: Address Verification Service (AVS)
Table 20-10 Full and Compressed Data Formats (continued)
Actual Field 123: Compressed

Address ZIP Code Field 123: Full Format Format
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

Chapter 20: Address Verification Service (AVS) For More Information
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.

For More Information Chapter 20: Address Verification Service (AVS)

Advice Retrieval Service—BASE I 21
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-3

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-5
How BASE I Advice Retrieval Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-6

BASE I Advice Message Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
BASE I Message Processing Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-7

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
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21-11


Advice Retrieval Service—BASE I 21
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).

Participation Requirements Chapter 21: Advice Retrieval Service—BASE I
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.
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
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
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.

Chapter 21: Advice Retrieval Service—BASE I Participation Requirements
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, clients
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. Clients 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.
Recovering Advices—Issuers can choose to recover advices throughout the day or only
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.
Cardholder's Open-to-Buy Options—Issuers should consider the impact of STIP

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.

How BASE I Advice Retrieval Service Works Chapter 21: Advice Retrieval Service—BASE I
Increased Advice Message Traffic—Issuers must be able to handle the increased advice
throughput. Processor host constraints may limit the number of stations that issuers can
sign on to Advice Retrieval mode at one time.
Multiple Stations per PCR Method—Issuers can sign on to multiple stations per V.I.P.
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.
0120: STIP Action or Exception File Update Advice—This advice is a notice of a request
and its response data when BASE I STIP processes 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.
0130: STIP Action or Exception File Update Advice Response—BASE I issuers that
choose to receive 0120 file update advices can optionally send 0130 file update advice
response messages.
0322: File Maintenance Advice—This advice indicates that V.I.P. updated the Cardholder
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.
0420: Reversal Advice—This advice notifies the issuer when STIP processes an 0400
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.
0430: Reversal Advice Response—Issuers can optionally send this response message to
acknowledge receipt of an 0420 reversal advice.
0800: Network Management Request—This message allows issuers to sign on to

Advice 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.

Chapter 21: Advice Retrieval Service—BASE I Process Flows
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.
Normal Mode—Issuers can receive and can send real-time messages but cannot receive
advices from V.I.P.
Advice Recovery Mode—V.I.P. sends advices to issuers (at the time V.I.P. stores them
in 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.

Process Flows Chapter 21: Advice Retrieval Service—BASE I
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.

Chapter 21: Advice Retrieval Service—BASE I Process Flows
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.

Process Flows Chapter 21: Advice Retrieval Service—BASE I
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.

Chapter 21: Advice Retrieval Service—BASE I Key Fields Glossary
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.

For More Information Chapter 21: Advice Retrieval Service—BASE I

This field appears in 0100 and 0400 requests and contains a code describing the
merchant's type of business product or service. The Visa Core Rules and Visa Product
and Service Rules, as amended by additions and changes published in the VisaNet
Business Enhancements and Technical Letters for clients, 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
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

Advice Retrieval Service—SMS 22
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-3

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-4

VisaNet-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-6
Client-Generated Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-7
How SMS Advice Retrieval Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-8

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
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-9

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
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22-12


Advice Retrieval Service—SMS 22
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 clients 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 clients to

Participation Requirements Chapter 22: Advice Retrieval Service—SMS
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.
• Fraud reporting advices.
• BASE II deferred clearing advices—These advices originate from dual-message acquirers
that do not generate online clearing messages. Clients 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.
• Funds transfer totals messages.
• BASE II 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—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.
Multiple Stations per PCR Method—Using a single PCR, 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 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 client can successfully send and receive
the following messages:
• 0120 and 0130—STIP advices.
• 0220 and 0230—STIP advices.

Chapter 22: Advice Retrieval Service—SMS Participation Requirements
• 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, clients
can contact their Visa representatives.
• 0420 and 0430—Reversal advices.
• 0620 and 0630—Funds transfer advices.
• 0800 and 0810—Advice Recovery mode sign-on and sign-off network management
messages.
The VisaNet Certification Management Service (VCMS) provides testing assistance for SMS
Advice Retrieval Service participants. Clients can contact their Visa representatives to
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.
Recovering Advices—Participants can choose to recover advices throughout the day

or only during certain periods.
Managing Cardholder Open-to-Buy Amounts—Participants should consider the impact

of 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.
Same Station for Advice Retrieval and Response—VisaNet must receive the response
from 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.
Multiple Stations per PCR Option—Clients can sign on to multiple stations per V.I.P.
connection identifier (known as a Processing Center Record [PCR]) to speed up advice
recovery. Each client 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
Increased Advice Message Traffic—Participants must be able to handle the increased
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.

Related Messages Chapter 22: Advice Retrieval Service—SMS

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

• VisaNet-generated advices
• Client-generated advices
22.5.1 VisaNet-Generated Advices

VisaNet-generated advices include:
0220: STIP Processing Advice—This advice notifies an issuer that STIP has acted
on its behalf: STIP processed an 0200 financial transaction (original or adjustment);
or it responded to an 0200 balance inquiry, account transfer, 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
0220: Advice of BASE II Transaction (Deferred Clearing Advice)—This advice notifies

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.
0220: Representment Validation Request—An SMS acquirer uses an 0220 message to

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.
0230: Financial Transaction Advice Response—This message acknowledges receipt of

an 0220 advice message.
0282: Representment Status Advice—Visa defines this message as a private-use

message 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.
0292: Representment Status Advice Response—Visa defines this advice as a private-use

message type that acknowledges receipt of an 0282 representment status advice.
0322: File Maintenance Advice—This message notifies an issuer that V.I.P. updated
the Cardholder Database file on the issuer's behalf; the advice includes the updated
record content.
0332: File Maintenance Advice Response—SMS issuers must send this 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.)
0420: Reversal Advice—The issuer receives this advice when STIP processes an 0400
reversal on behalf of the issuer. The issuer must respond with an 0430 advice.

Chapter 22: Advice Retrieval Service—SMS Related Messages
0430: Reversal Advice Response—This message acknowledges receipt of an 0420

reversal advice.
0422: Chargeback Advice—Clients use this message for chargeback reversals, 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.
0432: Chargeback Advice Response—This message acknowledges receipt of a

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

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.
0490: Issuer Status Advice Response—This message acknowledges the issuer's receipt
of an 0480 chargeback or chargeback reversal status advice. The response code must
be 00, indicating acceptance of the 0480 advice.
0520: Reconciliation Advice—This is an advice that conveys that the settlement day is
closed and no more transactions will be settled for that settlement date.
0530: Reconciliation Advice Response— This message is the response to an 0520

reconciliation advice.
0620: Administrative Advice—This message includes copy request and administrative

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

administrative advice. The response code from an SMS center must be 00.
22.5.2 Client-Generated Advices

Service participants (both issuers and acquirers) can retrieve client-generated advices
provided that the advices exist in the advice file. These client-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.
Issuers must respond with an 0230 advice. The response code must be 00.
0220: Good-Faith Collection Advice Usage 1b (Interlink Only)—This advice applies

when 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.
0220: Representment Advice Response Usage 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.

How SMS Advice Retrieval Service Works Chapter 22: Advice Retrieval Service—SMS
0220: Acquirer Fee Collection/Funds Disbursement Advice Usage 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 clients 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.
Deferred Clearing Advices—SMS issuers receive deferred clearing advices (0220s) when
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.
• Field 63.3—Message Reason Code contains 2105.
• Field 63.4—STIP/Switch Reason Code contains 9100 or 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
clients manage receipt of large volumes of advices.

Chapter 22: Advice Retrieval Service—SMS Process Flows
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

Clients 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 clients' 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.
Normal Mode—Clients can receive and can send real-time messages but cannot receive
advices from V.I.P.
Advice Recovery Mode—V.I.P. sends advices (as it stores them in the SMS advice file)
to clients.
Normal and Advice Recovery Mode—Clients can send and can receive real-time
messages as well as receive stored advices. The client “signs on to recovery” while it is still
signed on for normal message processing.
22.7 Process Flows

The SMS advice retrieval process includes:
Signing Off From Request Processing—If the client chooses to operate only in
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.
Signing On for Advice Recovery—V.I.P. delivers SMS advices in the following priority
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, clients 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

Process Flows Chapter 22: Advice Retrieval Service—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)
NOTE
Advice recovery does not interrupt authorization traffic. The same client station may be signed on for normal
traffic and for advice recovery at the same time.
When V.I.P. performs advice recovery for clients that participate in the Positive
Authorization Capacity Management (PACM) Service, the system pauses or stops advice
recovery when the client 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.
Selecting More Rapid Advice Recovery (Optional)—Clients can choose to speed up the
advice recovery process by having multiple stations “sign on to recovery.” See “Multiple
Stations per PCR Option” in this chapter for information.
Concluding Advice Recovery—To stop (and to sign off from) Advice Recovery mode,
the client 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 client must submit another “sign on to recovery” message.
Clients 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 client recovers the last advice in the file. By default,
clients always remain signed on to Advice Recovery mode.
Signing Back On to Request Processing—If the client is operating only in Advice

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.

Chapter 22: Advice Retrieval Service—SMS Process Flows
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 client 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 client wants to have three stations actively processing advices, it must first send
three separate “sign on to recovery” messages. The client 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.

Message Flows Chapter 22: Advice Retrieval Service—SMS
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 client's primary VIC includes advices for all of the
transactions STIP processed on the client's behalf. A client usually receives service
through its primary VIC. A client 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
client 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 client's primary VIC becomes
unavailable.
During the switchover, V.I.P. stores advices in the advice file at the secondary VIC. Clients
that choose to recover advices during the switchover should be aware that some advices
may still be on file at the primary VIC. Clients cannot recover these advices until VisaNet
switches them back to the primary VIC.
22.7.2.2 After Switchover

When VisaNet switches a client back to its primary VIC, the secondary VIC transfers all of
the advices it created to the primary VIC. If the client 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
Clients 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
client, 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
client retrieves them.
Figure 22-2 illustrates the message flow for SMS advice recovery.

Chapter 22: Advice Retrieval Service—SMS Key Fields Glossary
NOTE
If possible, clients 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.

For More Information Chapter 22: Advice Retrieval Service—SMS
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

Chapter 22: Advice Retrieval Service—SMS For More Information
• V.I.P. System SMS Interlink Technical Specifications

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

For More Information Chapter 22: Advice Retrieval Service—SMS

ATM Format Conversion Service 23
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4

ATM Format Conversion Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
Existing Card Range Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
New Card Range Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-5
How ATM Format Conversion Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-6

Message Augmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-7
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-8
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23-10


ATM Format Conversion Service 23
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.

Service Summary Chapter 23: ATM Format Conversion Service
The ATM Format Conversion Service is available to clients 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.
Clients 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.
Clients 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 client 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.

Chapter 23: ATM Format Conversion Service Participation Requirements

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.
The VisaNet Certification Management Service (VCMS) provides testing assistance for ATM
Format Conversion Service participants. Clients can contact their Visa representatives to

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. Clients can contact their Visa representatives for regional
specifics.
Clients 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
Clients 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.

How ATM Format Conversion Service Works Chapter 23: ATM Format Conversion Service
Clients 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.
0100: Authorization—V.I.P. converts this message to an 0200 cash disbursement request

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

forwards the message to the acquirer.
0200: Cash Disbursement—V.I.P. converts a BASE I 0100 cash disbursement authorization

request to an SMS 0200 cash disbursement request before it forwards the message to the
issuer. The issuer must respond with an 0210 response.
0210: Response—V.I.P. converts this response to an 0110 response before it forwards the
BASE I 0400: Reversal—V.I.P. converts this message to an SMS 0420 reversal before it
forwards the message to the issuer. The issuer must respond with an SMS 0410 reversal
response.
BASE I 0410: Response—V.I.P. converts the SMS 0410 response to a BASE I 0410
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.

Chapter 23: ATM Format Conversion Service How ATM Format Conversion Service Works
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.
- 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

Process Flows Chapter 23: ATM Format Conversion Service
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.

Chapter 23: ATM Format Conversion Service Process Flows
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.

Message Flows Chapter 23: ATM Format Conversion Service
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


Chapter 23: ATM Format Conversion Service Message Flows
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 response
to the acquirer.
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)


Key Fields Glossary Chapter 23: ATM Format Conversion Service
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.

Chapter 23: ATM Format Conversion Service For More Information
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:
Code 2547—Indicates a potential duplicate financial transaction.
Code 2548—Indicates a duplicate (including retrieval reference number) financial

transaction.

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

For More Information Chapter 23: ATM Format Conversion Service

Card Verification Value (CVV) 24
Service
Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-3
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-4
CVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-4
dCVV Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-5
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-6

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

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-11
Service Monitoring for CVV and iCVV Service Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-12
Issuer Monitoring Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-12
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-16
Initiating Full Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-18
Acquirer and Issuer Participation Requirements—dCVV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-18
Acquirers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-19
Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-19

Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-20
How Card Verification Value (CVV) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-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
MasterCard CVV Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-24
Application Transaction Counter (ATC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-24
How Dynamic Card Verification Value (dCVV) Service Works. . . . . . . . . . . . . . . . . . . . . .24-25

dCVV Processing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-26
STIP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-27
Emergency Replacement dCVV Cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .24-27

Card Verification Value (CVV) 24
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.

In Brief Chapter 24: Card Verification Value (CVV) Service
• 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.
NOTE
Clients 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.

Chapter 24: Card Verification Value (CVV) Service In Brief
• 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.
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.

Service Summary Chapter 24: Card Verification Value (CVV) Service
The CVV Service is available to clients 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 client CVV Service options,
are the same. All options, parameters, and keys specified for CVV processing are used to
process iCVVs.

Chapter 24: Card Verification Value (CVV) Service Service Summary
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
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, which represents a magnetic stripe-initiated
transaction, V.I.P. or the issuer performs CVV verification.
• If the POS entry mode code is 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.

Participation Requirements Chapter 24: Card Verification Value (CVV) Service
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 clients 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 clients 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,

clients 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.

Chapter 24: Card Verification Value (CVV) Service Participation Requirements
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
forwards the results to the issuer in the request messages.
ALL RESPOND—V.I.P. verifies the CVV or the iCVV on all eligible

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.
STIP ONLY—V.I.P. verifies the CVV or the iCVV when the transaction
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,

STIP does not check the CVV or the iCVV.
NOTE:
The STIP ONLY and NONE options are not available in the Asia-Pacific region.
Clients 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.
BASE I Issuers—Issuers must generally provide three test cards, depending on regional
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. Clients can contact their Visa representatives to get
a copy of the MIQ and testing specifics.
SMS 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:
Phase IIA, Key and Advice Testing—The CVV is properly encoded using the keys loaded
into VisaNet. The issuer can receive advices containing CVV information.
Phase IIB, Stripe and Response Testing—Transactions are generated to verify that the
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.
Adding an Additional BIN—Issuers wanting to add additional BINs using previously

tested 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.
Adding a New BIN—Visa strongly recommends testing for issuers adding a new BIN
using 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 clients 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 system 3. V.I.P. tests the ability of the issuer's
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. 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
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 V.I.P. processes the CVV or the iCVV according
start 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 issuers)
in 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, 05, 95
specified values in
Field 22—Point-of- 05 NOTE:
V.I.P. converts code 02
Service Entry Mode
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
• 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. Clients can
contact their Visa representatives for the forms or contact Global Client Testing Support
(IGSS) at itest@visa.com.
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 transmit Yes No, because: No, because:
complete, unaltered Track 1 • Track 1—not • Track 1—not
and Track 2 magnetic stripe applicable applicable
content. • Track 2—Interlink • Track 2—Visa ATM
acquirers have and Plus acquirers
successfully have successfully
completed testing completd testing
that complete that complete
Track 2 data can Track 2 data can
be sent. be sent.
Send the specified value 90 or 05 if 90 90, 02, or 05, 95
in field 22 to indicate that chip-initiated
complete, unaltered magnetic NOTE: Visa recommends
V.I.P. converts using a value of 90
stripe data is included in the
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.
Must be monitored before Varies by region Varies by region Varies by region
full participation.

Table 24-7 Acquirer Implementation Activities (continued)
Type of Acquirer
Implementation Activity Visa POS Interlink Visa ATM and Plus
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. Clients 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.

How Card Verification Value (CVV) Service Works Chapter 24: Card Verification Value (CVV) Service
• 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
• 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, V.I.P. rejects the message with Reason Code 0699—Presence of PIN/Track/AVS Data
Inconsistent With Message Type.
1. Interlink does not support VSDC-based iCVV processing.

Chapter 24: Card Verification Value (CVV) Service How Card Verification Value (CVV) Service Works
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 90; if acquirers submit
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:
- 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.

Chapter 24: Card Verification Value (CVV) Service How Card Verification Value (CVV) Service Works
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 SMS Invalid Card Product. 02
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: Card Verification Value (CVV) Service 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, 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
Clients 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.

How Dynamic Card Verification Value (dCVV) Service Works Chapter 24: Card Verification Value (CVV) Service
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 as
Issuer dCVV Service • Performs all dCVV follows:
verifications on the issuer’s • Places the dCVV result value
behalf. 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 code 05.
that are not declined to the - Returns the dCVV results
issuer. 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 as
Verification Results to Issuer • Performs dCVV verifications 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 as
Issuer Supports Own dCVV • Does not verify the dCVV in follows:
Verification the transaction. • V.I.P. forwards Track 2 data to
• Forwards the Track 2 data to the issuer to perform dCVV
the issuer for the issuer to 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.

Chapter 24: Card Verification Value (CVV) Service Key Fields Glossary
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) (MDKs) • Places the dCVV result value in the CVV
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
NOTE: option. The options are:
Issuers can choose to establish dCVV MDKs at
Visa. If issuers provide dCVV MDKs, V.I.P. processes • Decline all transactions that contain a Track 2
transactions using the STIP processing rules for with a contactless indicator with response
verification options 1 and 2. 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.

Key Fields Glossary Chapter 24: Card Verification Value (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
NOTE
Interlink transactions require code 90. If acquirers submit code 02 in Interlink requests, V.I.P. changes it
to code 90.
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
is 90, 02, or 91, but there is no magnetic stripe data in field 35 or in field 45.
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 90.
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.

Chapter 24: Card Verification Value (CVV) Service Key Fields Glossary

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 field format when a CVV is returned in this field.

For More Information Chapter 24: Card Verification Value (CVV) Service
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
Volume 2
• Visa Smart Debit/Visa Smart Credit System Technical Manual (document ID 6001-02)

Card Verification Value 2 25
(CVV2) Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-4

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

BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9
How Card Verification Value 2 (CVV2) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-9

CVV2 Calculation, Encryption, and Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
CVV2 Expiration Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
DES Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-10
Encryption Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
Card Verification Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
Issuer Option Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-11
CVV2 ALL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
CVV2 NONE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12

Stand-In Processing and CVV2 Failure Response Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-12
CVV2 Processing Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-13
CVV2 Verification-Only Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-14
CVV2 Emergency Replacements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-14
CVV2 Emergency Replacement Error Codes. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .25-15
When Transactions Contain Both a CVV2 and a CAVV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
MasterCard CVV2 Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-15
American Express, Diners Club, and Discover Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
American Express. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-16
Diners Club and Discover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
Japan Credit Bureau (JCB). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
Account Funding Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
Visa Europe CVV2 CNP Fee Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-17
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-18

CVV2 Pass-Through Processing for Card-Present Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . .25-20

Key Fields Glossary for CVV2 Emergency Replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25-23

Card Verification Value 2 25
(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.
Clients 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.

Service Summary Chapter 25: Card Verification Value 2 (CVV2) Service
The CVV2 Service is available to all clients 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 51.
• Field 126.10—CVV2 Authorization Request Data must be present.

Chapter 25: Card Verification Value 2 (CVV2) Service Participation Requirements
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 61—Fraudulent Mail/Telephone Order Transaction, if the transaction is fraudulent.
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 clients 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.
Issuer Processor Requirements—Participating issuer processors must modify their

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.

Participation Requirements Chapter 25: Card Verification Value 2 (CVV2) Service
Issuer BIN Requirements—Full CVV2 Service participation requires issuers, processing

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. Clients 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.
• 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:

Chapter 25: Card Verification Value 2 (CVV2) Service Participation Requirements
• 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.

Participation Requirements Chapter 25: Card Verification Value 2 (CVV2) 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.
Clients 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 Rules. 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 Core Rules and Visa Product and Service Rules.
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

Chapter 25: Card Verification Value 2 (CVV2) Service How Card Verification Value 2 (CVV2) Service Works
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.
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.

How Card Verification Value 2 (CVV2) Service Works Chapter 25: Card Verification Value 2 (CVV2) Service
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
Clients 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, 05, or 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 (M, 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, 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, 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.

Process Flows Chapter 25: Card Verification Value 2 (CVV2) Service
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)
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.
• Last five positions cannot be: ^^^^^ (all
spaces), 00000 (all zeros), 0000^, 0000N,
0000P, or 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.

Chapter 25: Card Verification Value 2 (CVV2) Service Process Flows
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.

Key Fields Glossary Chapter 25: Card Verification Value 2 (CVV2) Service
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 clients 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.
Clients 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, 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.
Subfield 44.10—CVV2 Result Code (Request Message)—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.
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

Chapter 25: Card Verification Value 2 (CVV2) Service Key Fields Glossary
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.
Subfield 44.10—CVV2 Result (Response Message)—If the issuer decides to override
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.
Diners Club/Discover—V.I.P. includes this field in responses to the acquirer if

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.
American Express—As indicated in the above note, American Express CID processing
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.

Key Fields Glossary Chapter 25: Card Verification Value 2 (CVV2) Service
Subfield 126.10—CVV2 Authorization Request 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
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.

Chapter 25: Card Verification Value 2 (CVV2) Service Key Fields Glossary
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
not providing a CVV2 value for 1-digit CVV2 presence indicator code.
verification. Merchants use this code to indicate
whether the CVV2 is imprinted on
1 = The CVV2 value is present: Indicates
the card. A value other than 1 in this
that the merchant is providing the
field provides information about why
CVV2 value for verification.
the CVV2 was not included in the
2 = The CVV2 value is on the card but is authorization request message.
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
1 = The merchant wants the response
data they want returned to them in
code in field 39 and the CVV2
response 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.

For More Information Chapter 25: Card Verification Value 2 (CVV2) Service

The code in this field identifies a CVV2 emergency replacement value request.
The code must be 0171.

For additional information about the CVV2 Service, refer to the following documents:
• Visa Core Rules and Visa Product and Service Rules

Cardholder Authentication 26
Verification Value (CAVV)
Verification Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-4

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

BASE I and SMS Authorization Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-7
BASE I and SMS Authorization Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-8
How Cardholder Authentication Verification Value (CAVV) Verification

Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-8
CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-9
Verifying CAVV Results From Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-13
Chargeback Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-13
Dispute Resolution Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
Ineligible Transactions Passing CAVV Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
When Transactions Contain Both a CAVV and a CVV2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-14
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26-15


Cardholder Authentication 26
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.

Service Summary Chapter 26: Cardholder Authentication Verification
Value (CAVV) Verification Service
The CAVV Verification Service is available to clients in all Visa regions.

To participate in the CAVV Verification Service, clients 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

Chapter 26: Cardholder Authentication Verification Participation Requirements
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
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. 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.
All CAVV Verification Results to the Issuer Option—With this option, VisaNet performs
all validations on the issuer's behalf and forwards all status results of transactions to
the issuer.
Issuer Supports Own CAVV Verification Option—With this option, VisaNet forwards
the 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.

Participation Requirements Chapter 26: Cardholder Authentication Verification
• 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 The merchant or the
Positions 1–2 (key entry) 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 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 data The merchant
Usage 2 or 3 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)

Chapter 26: Cardholder Authentication Verification Related Messages
• 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. Clients can contact their Visa representatives to

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

How Cardholder Authentication Verification Value Chapter 26: Cardholder Authentication Verification
(CAVV) Verification Service Works Value (CAVV) Verification Service
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:
• 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)
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.

Chapter 26: Cardholder Authentication Verification How Cardholder Authentication Verification Value
Value (CAVV) Verification Service (CAVV) Verification Service Works
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) and:
Issuer CAVV Service - CAVV validation fails, V.I.P. declines the transaction with Response
Code 05—Do Not Honor.
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.
Authentication The issuer does not provide Visa with its CAVV DES key(s). V.I.P. does not
option 3: Issuer perform CAVV validation. V.I.P. processes the transaction according to
Supports Own CAVV the existing issuer STIP parameters and either declines all transactions
Verification that contain a CAVV or ignores the presence or content of field 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 Visa. - Returns the CAVV results code value in response and advice
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.:
- 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 does • Decline all transactions that contain CAVV data in field 126.9 with
not require issuers to response code 05.
establish CAVV DES • Ignore the presence and the content of field 126.9 and respond based
keys at Visa.) on existing issuer STIP parameters.
NOTE: If issuers establish CAVV DES keys at Visa, V.I.P. processes transactions
Issuers can choose to
using the STIP processing rules for Authentication options 1 and 2.
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.
All 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.
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 of
the CAVV for the CAVV validation in the CAVV results code field in response messages.
transaction. • If CAVV ACS result = 8 (authentication attempted, not able to complete
• Forwards the CAVV because issuer ACS is unavailable) and:
field to the issuer - CAVV validation fails, V.I.P. declines the transaction with CAVV results
for the issuer to code 9.
perform CAVV - CAVV validation is successful, V.I.P. forwards the transaction to the
validation. issuer with CAVV results code A.
• Forwards the XID,
if present, to the NOTE:
issuer. 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
Attempt Options—STIP Processing
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.
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.) response code 05. V.I.P. does not include field 44.13 in response
or advice messages.
NOTE:
- Ignore the presence and the content of field 126.9 and respond
Issuers can choose
to establish CAVV based on existing issuer STIP parameters.
DES keys at Visa. • If the CAVV ACS result is 8 (authentication attempted, not able to
If the issuer does complete because issuer ACS is unavailable), V.I.P.:
provide CAVV DES - Processes the transaction based on existing issuer STIP parameters.
keys, V.I.P. processes - Returns the CAVV results code in response and advice messages.
transactions using the
STIP processing rules NOTE:
for Attempt options 1 Only the Visa U.S.A. (U.S.) region uses CAVV ACS results code 8.
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
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 “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. 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:

Chapter 26: Cardholder Authentication Verification Key Fields Glossary
• 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.
Refer to V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2, and to the
SMS POS technical specifications manuals for detailed field descriptions.

Key Fields Glossary Chapter 26: Cardholder Authentication Verification

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 08, 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
by Visa.
Attempt—The issuer or the cardholder does not participate in Verified by Visa.
Non-Secure—Both the acquirer and the issuer do not participate in Verified by Visa.
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—Secure electronic commerce transaction.
• 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—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.

Chapter 26: Cardholder Authentication Verification Key Fields Glossary
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 More Information Chapter 26: Cardholder Authentication Verification

For additional information about the CAVV Verification Service, refer to the following
documents:
• 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

Custom Payment Service 27
(CPS)/ATM
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-4

BASE I and SMS CPS Processing Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-4
CPS/ATM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-5
Liability for Non-Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-6

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-6
How Custom Payment Service (CPS)/ATM Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-7
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-8

Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
Downgraded Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-9
Special ATM Handling Fee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
Authorization vs. Clearing Amounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
Reclassified Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-10
Delivering the Transaction to the Issuer. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .27-11
Exception Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-11
Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-11
V.I.P. Field Edit and DRC Requirements for CPS/ATM Authorization Requests. . . . . . . .27-13

Other Related Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27-16


(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.

Service Summary Chapter 27: Custom Payment Service (CPS)/ATM
CPS/ATM is available to clients 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

A Message 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 clients 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 Visa Rules and include quasi-cash and
transactions submitted from certain “high-risk” merchants. Refer to the Visa Core Rules
and Visa Product and Service Rules 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

Chapter 27: Custom Payment Service (CPS)/ATM Service Summary
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).

Participation Requirements Chapter 27: Custom Payment Service (CPS)/ATM
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 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.
Acquirers receive a cash disbursement fee if the transaction meets the Tier II business and
technical requirements. All SMS and dual message acquirers must meet the following
business and technical requirements.
Business Requirements:
• Provide the basic ATM cash withdrawal service and accept Visa cards and cards bearing
the Plus symbol.
• Comply with the applicable Visa Rules 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.
Technical 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 (refer to regional Interchange Reimbursement Fee Guides for
ATM Cash Disbursement fee programs).
27.4.1 Testing
CPS/ATM testing is available for dual-message Visa/Plus international ATM acquirers and
issuers. Clients can contact their Visa representatives to make arrangements for testing.

Chapter 27: Custom Payment Service (CPS)/ATM How Custom Payment Service (CPS)/ATM Works

Although all clients 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 and Tier II for BASE I and BASE II Technical/Implementation Guide for
details about implementation.
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.

Process Flows Chapter 27: Custom Payment Service (CPS)/ATM
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 to their authorization systems. They will not receive any new authorization
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
28 Amount, Transaction Fee None
32 Acquiring Institution Identification 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

Chapter 27: Custom Payment Service (CPS)/ATM Process Flows
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, the TCR 5
record, and the RPS.
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
Acquirer Authorization Criteria Result to Acquirer
Y • Full contents of the Track 2 data of the magnetic Card present E
stripe were transmitted. with valid
• Card authentication performed through Card data.
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 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.
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 do not qualify for international cash disbursement fees.
• 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 do not qualify for international cash disbursement fees.
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, the
transaction does not qualify for international cash disbursement fees.
27.6.2.3 Delivering the Transaction to the Issuer

BASE II clearing drafts delivered to the issuer include a TCR 5 record. 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.
An issuer can use the TID to better manage cardholders' open-to-buy balances by
matching authorization and clearing records.
The TID, Fee Program Indicator, and Terminal ID must be retained and returned on all
exception transactions.
Chargebacks for international ATM cash disbursement transactions may be submitted with
Chargeback Reason Code 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.

Table 27-3 CPS/ATM Key Data Requirements (continued)

Determine
Validation
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
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)

Table 27-3 CPS/ATM Key Data Requirements (continued)

Determine
Validation
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
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
field 45 if: magnetic stripe or chip data is included, field 22 contains 05 or 90, and the ACI from
the acquirer is Y.

Table 27-4 CPS/ATM Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
BASE I and SMS—If magnetic stripe or chip data was read, and field 22 contains 05 or 90 ED
and 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
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: It must be one of the following codes: 05 (chip), 90 22
(magnetic stripe), 07 (chip proximity) or 91 (magnetic stripe proximity) for 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.
If the code is 05 or 90, track data is included, and the request is an original submission CV; CX if acquirer
(ACI = Y), the acquirer must be a full CVV Service participant. is on temporary
exception list
Field 28—Amount, Transaction Fee, required to carry the access fee and must be present in all V.I.P. rejects the
domestic and international Visa and Plus ATM transactions. message with reject
code 0308 (field
missing).
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
contains 05 or 90, and the ACI from the acquirer is Y.
Expiration date in field 14 must match the date in field 35 or in field 45 if: magnetic stripe or TD
chip data was read, field 22 contains 05 or 90, and the ACI from the acquirer is Y.
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 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.

Chapter 27: Custom Payment Service (CPS)/ATM For More Information
Table 27-4 CPS/ATM Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
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

For More Information Chapter 27: Custom Payment Service (CPS)/ATM
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

(CPS)/POS
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-4

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

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6
How Custom Payment Service (CPS)/POS Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-6

Reclassification From CPS/POS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
CPS/POS Program Clearing Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
Qualification Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-7
Fee Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Ineligible CPS/POS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Amount Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-8
Adjusting Amounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
Chargeback Reduction Service (CRS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
CPS Authorization-Related Chargeback Protection. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .28-9
Chargeback Reduction Service Life-Cycle Control. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .28-9
CPS/POS Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-9
Common CPS/POS Data Requirements: All National Markets. . . . . . . . . . . . . . . . . . . . . .28-10

Common CPS/POS Authorization Field Edit Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-10
Common CPS/POS Clearing Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-12
National Market CPS/POS Program: Brazil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-14

Key Data Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28-14

(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 client
profitability by reducing client operating costs, by improving risk management techniques,
and by increasing client 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.

Service Summary Chapter 28: Custom Payment Service (CPS)/POS
CPS/POS is available to clients 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 clients 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.

Chapter 28: Custom Payment Service (CPS)/POS Service Summary
Transactions ineligible for CPS are described in the Visa Rules and include certain
“high-risk” merchants. Refer to Visa Core Rules and Visa Product and Service Rules 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 Visa Rules contained in
Visa Core Rules and Visa Product and Service Rules 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.

How Custom Payment Service (CPS)/POS Works Chapter 28: Custom Payment Service (CPS)/POS
• 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
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.
Clients 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.

Chapter 28: Custom Payment Service (CPS)/POS How Custom Payment Service (CPS)/POS Works
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
(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 Visa Rules
contained in Visa Core Rules and Visa Product and Service Rules for more information.
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 Core Rules and Visa Product and Service Rules for processing timeframes
between transaction dates and clearing central processing dates. Also refer to the
appropriate Visa Rules for holidays and for other days that regions may exclude from the
clearing time calculations.

How Custom Payment Service (CPS)/POS Works Chapter 28: Custom Payment Service (CPS)/POS
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, clients can contact their Visa representatives.
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 clients can use amount adjustments depends on the applicable Visa Rules
outlined in Visa Core Rules and Visa Product and Service Rules.

Chapter 28: Custom Payment Service (CPS)/POS CPS/POS Process Flow
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 client 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 Merchant
Data Standards Manual.
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 the Visa Rules 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.

Common CPS/POS Data Requirements: All National Markets Chapter 28: Custom Payment Service (CPS)/POS
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
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 client 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
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.

Chapter 28: Custom Payment Service (CPS)/POS Common CPS/POS Data Requirements: All National Markets
Table 28-4 CPS/POS Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
The primary account number must match the account number in field 35 TA
or 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 TD
date in field 35 or in field 45 if the message includes magnetic stripe or chip
data, field 22 must contain 05 or 90, and the ACI from the acquirer must be Y.
If the terminal read magnetic stripe or chip data, the track data must ED
contain the expiration date, field 22 must contain 05 or 90, and the ACI
from the acquirer must be Y.
Field 18—Merchant Type: The merchant category code (MCC) must be present 18
and be one of the valid codes listed in the system tables.
The MCC must be valid for the target CPS program. IM
If field 25 contains 71 (key entry), the MCC cannot be 5542, 5960, 5962, CK
5964–5969, or quasi-cash.
Field 19—Acquiring Institution Country Code: This field must be present and IC; reject if
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, 05, 90, 22
or 95. The CPS/Retail credit value must be 05 or 90. Key-entry requests
must contain 01.
If field 22 contains 05 or 90, track data must be present in field 35 or 22
in field 45.
If the code in field 22 is 05 or 90, the message includes track data from CV; CX if the
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
contains 08), field 22.1 must contain 01 (manual key entry), and track data
must not be present in the message.
Field 35—Track 2 Data or Field 45—Track 1 Data: If the terminal read magnetic AN
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 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 TA
the track data and in field 2 must match.
Track data must contain the expiration date if: the terminal read magnetic ED
stripe or chip data, and field 22 contains 05 or 90, and the ACI from the
acquirer is Y.
The expiration date in field 14 must match the date in field 35 or in field 45 TD
if the terminal read magnetic stripe or chip data, field 22 contains 05
or 90, and the ACI from the acquirer is Y.

Common CPS/POS Data Requirements: All National Markets Chapter 28: Custom Payment Service (CPS)/POS
Table 28-4 CPS/POS Field Edit Requirements and DRC Conditions (continued)
DRC or Action
If Requirement
Key Field Not Met
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 present, No DRC
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 in if missing or if
field 62.3 protects field 49. invalid
Field 59—Merchant ZIP Code must be present and must be valid for the 59
U.S. acquirer.
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.

Chapter 28: Custom Payment Service (CPS)/POS Common CPS/POS Data Requirements: All National Markets
NOTE
Refer to the appropriateVisa Rules 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 Cardholder I.D.
Code Definition Code Definition Attribute 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
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

National Market CPS/POS Program: Brazil Chapter 28: Custom Payment Service (CPS)/POS
Table 28-6 Validation Code Protected Fields (continued)
V.I.P. System Field BASE II Field (Definition)

62.2 Transaction Identifier
62.1 Authorization Characteristics Indicator
62.23 Product ID (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:
• 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:
- Petrol must be 5541.
- 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.

Chapter 28: Custom Payment Service (CPS)/POS Key Fields Glossary
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 Retail: not 4815, 5960, 5962, TCR 0, Retail: not 4815,
5964–5969, 6010–6011 positions 133–136 5960, 5962,
5964–5969,
Petrol: 5541 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 (RPS) — — TCR 0, A for Retail
position 145 including Petrol
B for Restaurant
Authorization Date — — TCR 5, In transaction
positions 5–191 identifier
Purchase Date — — TCR 0, Within one day
positions 58–61 of 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.

Key Fields Glossary Chapter 28: Custom Payment Service (CPS)/POS
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
Submitted Returned National

Value Authorization Criteria Definition Value Markets
Y 1. The full contents either Card present, or A All
of Track 1 or of Track 2 of 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 Card present E All
of Track 1 or of Track 2 with merchant
of the magnetic stripe name and
are transmitted to allow location data
card authentication or select
through 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.
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.

Chapter 28: Custom Payment Service (CPS)/POS For More Information

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
• U.S. Interchange Reimbursement Fee (IRF) Rate Qualification Guide

For More Information Chapter 28: Custom Payment Service (CPS)/POS

Deferred Clearing Advice File 29
(DCAF) Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4

DCAF Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
File Delivery Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-4
File Content and Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-5

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-6
Issuer Host Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-7
How Deferred Clearing Advice File (DCAF) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . .29-8
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-9
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29-10


Deferred Clearing Advice File 29
(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 clients 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

Service Summary Chapter 29: Deferred Clearing Advice File (DCAF) Service

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 connection method
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 VisaNet connection method.
• Directly to the issuer's host computer through a direct connectivity method. This
method is called host-to-host delivery.

Chapter 29: Deferred Clearing Advice File (DCAF) Service Participation Requirements
VisaNet connection methods are available for issuers in all Visa regions. Issuers can use the
same connection 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 client volumes, timing requirements, and other processing considerations.
Visa has direct VisaNet connections for all clients. These connectivity options enable
clients 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 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 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 VisaNet connection methods.
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. Clients 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.

Participation Requirements Chapter 29: Deferred Clearing Advice File (DCAF) Service
Visa representatives handle the Visa internal table changes based on information supplied
by the issuer's technical staff.
Clients 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. Clients 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 VisaNet 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, after which the issuer must transfer the test file. Visa representatives help
issuers work with Global Client Testing Support (IGSS) 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 client 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.
Clients should consider the following impacts when planning for implementation of DCAF.
Billing Impacts—Changes to connectivity may affect the cost of Visa-supplied equipment

or services. Advices recovered using DCAF have the same billing charges as advices
recovered online.
Legal Impact—DCAF does not affect issuer participation, Treasury processing, or BIN
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.

Chapter 29: Deferred Clearing Advice File (DCAF) Service Participation Requirements
Table 29-1 provides an overview of issues that Visa staff and clients 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 • Help with Visa VIC
connection: direct connection: direct
connection or VisaNet connection or VisaNet
connection method. connection.
• For VisaNet connections, • For VisaNet connections,
assist with client host make client file delivery
connection. 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 client. data.
Program DCAF file record
processing, or integrate
it with existing advice
processing.
Online Capacity Consider capacity Issuers can leave the existing
reduction during the capacity in place for fallback
post-implementation phase of purposes while the issuer
the project. 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.
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 VisaNet connection or through a direct connection), extract the advice records, and
process them.

How Deferred Clearing Advice File (DCAF) Service Works Chapter 29: Deferred Clearing Advice File (DCAF) Service
If file delivery processing does not currently exist at the issuer site, issuers must establish
a new communications link from the issuer host to VisaNet using a VisaNet connection.
For more information about VisaNet connections, refer to “For More Information” in
About This Manual for documentation about VisaNet connections.

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.
0220: POS (Original Financial Transaction) Advice—This advice contains processing

code 00.
0220: Cash Disbursement (Original Financial Transaction) Advice—This advice

contains processing code 01.
0220: Merchandise Credit Transaction Advice—This advice contains processing code 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, the file
is available for transfer to the client'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. Clients can use the file inventory and the last file notification to schedule
internal processing.

Chapter 29: Deferred Clearing Advice File (DCAF) Service Process Flows
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 VisaNet connection method or a direct VisaNet connection.
For detailed information about inventory file and last file notification processing for
VisaNet connection anddirect connection 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.

Message Flows Chapter 29: Deferred Clearing Advice File (DCAF) Service
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.

Chapter 29: Deferred Clearing Advice File (DCAF) Service For More Information
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
Volume 2

For More Information Chapter 29: Deferred Clearing Advice File (DCAF) Service

Dynamic Key Exchange (DKE) 30
Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-4

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

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6

On-Request Key Exchange Messages (V.I.P. Master). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-6
Automatic Key Exchange Message Flow (V.I.P. Master). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
Client-Provided Key Exchange Messages (V.I.P. Slave). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
How Dynamic Key Exchange (DKE) Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-7

On-Request Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-8
Automatic Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-10
Client-Provided Key Exchange Process Flow (V.I.P. Slave). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-11
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-12

On-Request Key Exchange Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-13
Automatic Key Exchange Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-15

Client-Provided Key Exchange Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-17
Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30-19

Dynamic Key Exchange (DKE) 30
Service
30.1 In Brief
The Dynamic Key Exchange (DKE) Service is an optional service that enables Single
Message System (SMS) clients to change working keys that are used to protect cardholder'
PINs through the use of online messages.
Dynamic Key Exchange Service is available to clients 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

Service Summary Chapter 30: Dynamic Key Exchange (DKE) Service

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 client 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 clients 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 clients 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. Clients 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, clients can implement the DKE Service at only one of the above mentioned
levels.
30.3.1.2 Key Generation

Either VisaNet or a client 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 client generates the key, VisaNet
is the “V.I.P. Slave.”
30.3.1.3 Key Delivery

Clients 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 client in this capacity.
Clients can choose the times they want VisaNet to generate a new key:
Automatic Key Delivery—VisaNet delivers the key automatically. Clients can choose one
of the following options for the frequency of key delivery.
• Set hourly interval: Clients can specify the time, in hours, that should elapse between
automated key exchanges.
• Daily: Clients can specify the time, in GMT, when they want VisaNet to send a new key.

Chapter 30: Dynamic Key Exchange (DKE) Service Service Summary
Clients 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 client
does not need to specify the network.
Clients that implement the DKE Service at the BIN level can optionally specify the station.
In this case, the client must select a network to which VisaNet should deliver the key.
Clients that are set up for automatic key delivery also can request a key delivery at any
time at its discretion as necessary.
On-Request Key Delivery—Clients send an 0800 message to request a key. When VisaNet
receives a request, it generates a key and sends it to the client.
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
(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
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 clients 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 client has chosen this option, V.I.P. operations
staff have the capability to fall back to the static key at the client's request and perform
a manual intervention.

Related Messages Chapter 30: Dynamic Key Exchange (DKE) Service

To participate in the service, clients must obtain a Zone Control Master Key (ZCMK). For a
dynamic key exchange, a ZCMK is referred to as a Key Exchange Key (KEK). Clients 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.
Clients interested in using the DKE Service can contact their Visa representatives.

The following messages pertain to the Dynamic Key Exchange Service.
0800: Network Management Request—Clients use this message to request an

encryption key change. V.I.P. also uses 0800 messages to deliver automatic encryption
key changes.
0810: Network Management Response—Clients use this message to acknowledge an

0800 message for an encryption key change. V.I.P. uses an 0810 message to respond to
a client'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 client at the client’s
request.
0800: Key Change Request (Client to V.I.P.)—Clients use this 0800 message to request
an encryption key change.
0810: Key Change Request Acknowledgment (V.I.P. to Client)—V.I.P. uses this 0810
message to acknowledge a client’s message for an on-request key change.

Chapter 30: Dynamic Key Exchange (DKE) Service Process Flows
0800: Key Delivery Message (V.I.P. to Client)—V.I.P. uses this 0800 message to deliver
the key to the client.
0810: Key Delivery Acknowledgment (Client to V.I.P.)—Clients use this 0810 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
client.
0800: Key Delivery (V.I.P. to Client)—V.I.P uses this 0800 message to deliver key to
the client.
0810: Key Delivery Acknowledgment (Client to V.I.P.)—Clients use this 0810 message
to acknowledge receipt of key delivery.
30.5.3 Client-Provided Key Exchange Messages (V.I.P. Slave)

The following messages are used when a client delivers a key to VisaNet.
0800: Key Delivery Message (Client to V.I.P.)—Clients use this 0800 message to deliver
a key to V.I.P.
0810: Key Delivery Acknowledgment (V.I.P. to Client)—V.I.P. uses this 0810 message 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 client and
VisaNet. Key exchange is necessary to give a client 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 client 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 client configures the service. The following
sections describe high-level flows for the following scenarios:
• On-Request Key Exchange
• Automatic Key Exchange
• Client-Provided Key Exchange

Process Flows Chapter 30: Dynamic Key Exchange (DKE) Service
30.7.1 On-Request Key Exchange Process Flow

Figure 30-1 illustrates the DKE process flow when the client at its discretion (on request)
asks VisaNet for a new AWK or IWK. The client asks VisaNet to change the key. VisaNet
sends the client 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
1. The client 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 client 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 client wants V.I.P. to perform PIN verification and the code for the
ZKI in field 53 is not 01.
• a V.I.P. format client tries to do PIN DKE with NMI other than 0160 (AWK) or
0161 (IWK) in the request.
• for a BIN-based DKE client, the source station and the BIN in field 33 of the
request do not have the same PCR.
• for a BIN-based DKE client, the BIN in field 33 does not have encryption data
defined.

• for a station- or PCR-based DKE client, the source station does not have
encryption data defined.
• the client is requesting AWK change when they do not have an AKEK set up.
• the client 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 client 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 client-connected primary VIC is down.
• client requests key change when a key change for that client is already in progress.
• security module key generation fails.
• inter-VIC synchronization fails because of fluctuating inter-VIC linkage.
• a client 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 client with the requested Working Key.
4. Client responds to the 0800 Key Delivery in the following manner:
a. Client 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. Client responds with an 0810 Key Delivery Acknowledgment using response
code 00, which completes the process of dynamic key exchange.

Process Flows Chapter 30: Dynamic Key Exchange (DKE) Service
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 client).
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 client with the requested Working Key.
2. Client responds to the 0800 key delivery request in the following manner:
• Client 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.
• Client responds with an 0810 Key Delivery Acknowledgment using response code 00,
which completes the process of dynamic key exchange.

30.7.3 Client-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 client 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 client delivers a new key to Visa consists
of the following steps:

Message Flows Chapter 30: Dynamic Key Exchange (DKE) Service
1. Client 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 client 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 client tries to do PIN DKE with ZKI in field 53 not 01.
• a V.I.P.-format client 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 client is requesting an AWK change when they do not have an AKEK set up.
• the client 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 client 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 client-connected primary VIC is down.
• the client is not set up as V.I.P. Slave.
• the client requests key change when a key change for that client is already in
progress.
• the security module key translation fails.
• the inter-VIC synchronization fails because of fluctuating inter-VIC linkage.
• a client 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 clients, 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 client does not respond within 10 seconds or if the client 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 clients 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 client.

Chapter 30: Dynamic Key Exchange (DKE) Service Message Flows
30.8.1 On-Request Key Exchange Message Flow

As illustrated in Figure 30-4, clients 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 client), must be returned unchanged in the 0810 response. If the client
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). 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 client). 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 Client-Provided Key Exchange Process Flow

Figure 30-6 illustrates the DKE message flow when client uses 0800 Key Delivery Message
to deliver the key to Visa. The client 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 client),
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 client), must be returned
unchanged in the 0810 response. If the client 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 Client Response

Undeliverable response (to an The 0810 key response The client 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 client. arrive.
Undeliverable request. The 0800 key delivery None.
message 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 V.I.P. then initiates an automatic
the PIN block received from key change for the IWK.
V.I.P.:
• The issuer returns response
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 client can re-initiate the
messages. with response code 06. key change request at a later
time.

Key Fields Glossary Chapter 30: Dynamic Key Exchange (DKE) Service

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 client to comply with the request.
The following response codes are used:
Response Code 00, Request Acknowledged (Will Comply)—V.I.P. returns this code
when it accepts the client's request for a key change. The client 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)—V.I.P. returns

code 06 when it cannot accept a client'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.
The client 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.
Response Code 81, Cryptographic Error Found in PIN—The client returns code 81
to 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).

Chapter 30: Dynamic Key Exchange (DKE) Service Key Fields Glossary
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 0699—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.

Key Fields Glossary Chapter 30: Dynamic Key Exchange (DKE) Service
Field 53—Security-Related Control Information

Positions 7–8, Zone Key Index—The index in field 53.4 indicates which key was
used 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
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 clients.
Single-key clients cannot 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 clients. 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 clients 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)

Chapter 30: Dynamic Key Exchange (DKE) Service For More Information

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

For More Information Chapter 30: Dynamic Key Exchange (DKE) Service

Multicurrency Service 31
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-5
Decimal Positioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-5
Clearing and Settlement Currency Conversion. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .31-6
The Currency Precision Service for Acquirers. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .31-6
The Currency Precision Service for Issuers. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .31-6
Optional Issuer Fee (OIF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
How Multicurrency Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-7
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-8

Multicurrency Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-8
Processing VisaNet-Acquired MasterCard Transactions. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .31-9
Processing for Non-Participating Clients. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
VisaNet BASE II Currency Rate Delivery Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
Currency Conversion Charge Calculation Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-10
How VisaNet Applies Buy and Sell Currency Conversion Rates to Transactions. . . . . .31-11
Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-11
Currency Conversion Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
Using USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-12
Using Non-USD-Based Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-20
Classifying Transactions by Exchange Direction Type. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .31-25
Currency Precision Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-28
One Position Decimal Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-29

Two Position Decimal Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-29
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-30

Message Flows Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-31
BASE I, POS, and ATM Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-31
SMS POS Multicurrency Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-33
SMS Visa/Plus ATM Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-40
SMS Interlink Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-47
Partial Amount Authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-59
Processing POS Balance Returns With Multiple Currencies. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .31-60
Acquirer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-60
Issuer Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-61
Message Flow Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31-61

Multicurrency Service 31
31.1 In Brief
The Multicurrency Service supports authorization, clearing, and settlement processing
in selected international currencies.

The Multicurrency Service is available to clients 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.

Participation Requirements Chapter 31: Multicurrency Service

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:
Clearing Conversion—This feature automatically converts the transaction currency to the

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.
Settlement Conversion—This feature automatically converts the transaction currency to

the acquirer's settlement currency (if the two are different), and automatically converts the
cardholder's billing currency to the issuer's settlement currency.
Currency Rate Delivery Service—This feature delivers the conversion rate and provides
clients (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.
Currency Precision Service—Available for SMS Multicurrency Service participants only,

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.
Impacts to U.S. Clients—Participation does not affect a U.S. client's settlement, which
remains in U.S. dollars. Clients 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. clients receive the standard multicurrency

Chapter 31: Multicurrency Service Participation Requirements
fields in their online messages and reports. U.S. clients choosing not to participate in the
Multicurrency Service do not receive the fields specific to multicurrency in their online
messages.
Impacts to All Other Service Participants—Issuer participants always receive

multicurrency 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).
Impacts to Non-Participants—If a client chooses not to participate, it neither provides

nor receives the unique multicurrency data fields.
For SMS clients, V.I.P. sends all amounts in Field 4—Amount, Transaction in U.S. dollars
(USD).
31.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. Clients can contact their Visa representatives to make
the arrangements.

Service monitoring is not applicable to the Multicurrency Service.

Clients should consider the following key points when planning their implementation of
the Multicurrency Service.
31.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 client 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.

Participation Requirements Chapter 31: Multicurrency Service
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).
31.4.3.2 Clearing and Settlement Currency Conversion

The service automatically converts client or processing center net financial positions into
the client’s settlement currency supported by the International Settlement Service.
• If the local currency is one of the settlement currencies, settlement will be in the local
currency.
• If the local currency is not one of the settlement currencies, the client can choose any
supported settlement currency.
31.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
31.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

Chapter 31: Multicurrency Service How Multicurrency Service Works
• Reversals
• Adjustments
• Representments
• Issuer status advices
• Reconciliation messages
31.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 client 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
• 0600: Copy Request Messages
For more information regarding the multicurrency-specific data for these messages,
see “Key Fields Glossary” in this chapter.
31.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.

Process Flows Chapter 31: Multicurrency Service
31.7 Process Flows
31.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).

Chapter 31: Multicurrency Service Process Flows
Figure 31-1 illustrates a Multicurrency Service process flow for a transaction acquired in
U.S. dollars for an Australian cardholder.
Figure 31-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.
31.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.
31.7.1.2 Processing for Non-Participating Clients

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 clients
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.
31.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 clients 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.
31.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.

31.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.
31.7.4.1 Terminology
The new Visa currency conversion rate system involves new terminology. Table 31-1
defines the new terminology.
Table 31-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 31-2 provides a mapping of the terminology used to the corresponding fields
in V.I.P. and BASE II.
Table 31-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
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.

31.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 client 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.
31.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 31-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 31-17
• Table 31-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 31-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 31-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 31-2 shows the flow of the transaction and money for original purchase
transactions.
Figure 31-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 31-4 lists the USD-based rate pairings and rates that are used to calculate the
TADC in the scenarios that follow.
Table 31-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 31-5 shows how the USD-based rate is displayed in a currency entry segment
of the TC 56 record.
Table 31-5 Currency Entry for USD-Based Rate in TC 56 Record for Scenario 1
Counter Base Buy Scale Sell Scale

Position Currency Currency Factor and Factor and
Name Action Code Code Code Effective Date Rate Rate
Record n/a Numeric value 840 1002 Value Value
Content for currency
code ABC

Table 31-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 31-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
ABC
currency
BASE II Positions 77–88 000000100000 Positions 62–73 Amount in U.S. - As applied
dollars to the
transaction:
Positions 89–91 Numeric value Positions 74–76 840
ABC
for currency code
1,000.00 x
ABC
Buy–A =
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


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 for
- Source
currency code XYZ
amount ÷
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 for the transaction:
currency code XYZ - USD 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

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 for
- Source
for currency code currency code XYZ
amount x
ABC
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 for amount ÷
for currency code currency code XYZ sell rate of
ABC destination
currency
• As applied to
the transaction:
- ABC
1,000.00
x Buy–A
= USD
amount
- USD
amount ÷
Sell–B =
XYZ TADC
31.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 31-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 31-17
• Table 31-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 31-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 31-3 shows the flow of the transaction and money for original purchase
transactions.
Figure 31-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 31-12 lists the non-USD-based rate pairings and rates that are used to calculate the
TADC in the scenarios that follow.
Table 31-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 31-13 shows how the non-USD-based rate is displayed in a currency entry segment
Table 31-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
for currency code currency code MNO
x buy rate of
XYZ
source currency
BASE II
• As applied to the
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 31-15 shows how the non-USD-based rate is displayed in a currency entry segment
Table 31-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
for currency code for currency code the transaction:
ABC MNO - ABC 500.00
÷ Sell–D =
MNO TADC
31.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 31-17
• Table 31-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 31-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, 02, 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, 02, 10, —> —>
• Purchases or 11
• Preauthorization Completions
• Cash Disbursements1
• ATM Debit Adjustments
• Debit Adjustments
• Quasi-Cash
0422/0432 chargebacks for the following types of 00, 01, 02, 10, <— —>
transactions: or 11
• Purchases
NOTE:
• Cash Disbursements Field 25
• ATM Debit Adjustments must contain
• Debit Adjustments code 17.
• Quasi-Cash
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 31-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. For cash disbursements or ATM debit adjustments, the MCC must be 6011.

Table 31-18 Sell–Buy Currency Conversion Direction by Transaction Type
Money
V.I.P. 02xx for the following types of transactions: 20, 22, or 26 —> —>
• Merchandise Returns
• Credit Adjustments
• Original Credits
• ATM Credit Adjustments1
04xx reversals for the following types of transactions: 20, 22, or 26 —> <—
• Credit Adjustments
• Original Credits
0422—Chargebacks for the following types of transactions: 20, 22, or 26 <— <—
NOTE:
• Credit Adjustments Field 25
• Original Credits must contain
• ATM Credit Adjustments1 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 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. For ATM credit adjustments and their reversals, the MCC must be 6011.
31.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.
31.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. 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.
The settlement amount is based on the transaction amount 123450. All reports and raw data reflect the
transaction amount 123450.
The following figure shows an example of decimal position conversion for one decimal position.
Figure 31-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
31.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.

Message Flows Chapter 31: Multicurrency Service
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.
The issuer receives the transaction amount 1234. A participating issuer also receives a value of 02 in position 1
and 2 of field 63.13. Non-participating issuers receive transaction amount 1234; however, the request has no
decimal positions indicator. The settlement amount is based on 1234. All reports and raw data reflect 1234.
The following figure shows an example of decimal position conversion for two decimal positions.
Figure 31-5 Example of Two-Decimal Position Conversion
Incoming Message
Amount = 12340
Visa Currency Table
Pa’anga Decimal Positions = 02
Amount = 1234
31.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 clients receive standard multicurrency fields in their online messages, reports,
and raw data.
For non-participating clients, transaction and settlement amounts appear in online

messages, raw data, and reports in U.S. dollars only.
Non-participating clients that migrate to the Multicurrency Service have the advantage of
using the additional information.

Chapter 31: Multicurrency Service Message Flows
31.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
31.8.2 BASE I, POS, and ATM Multicurrency Message Flows

The following figures show the Multicurrency Service BASE I POS transaction message
flows:
• Figure 31-6
• Figure 31-7
Figure 31-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).
Figure 31-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 31-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).
Figure 31-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.)
31.8.3 SMS POS Multicurrency Message Flows

The following figures show the Multicurrency Service SMS POS transaction message flows:
• Figure 31-8
• Figure 31-9
• Figure 31-10
• Figure 31-11
• Figure 31-12

• Figure 31-13
• Figure 31-14
NOTE
Billing amounts may differ from the purchase amount because of issuer optional charges being deducted. For
more information, clients can contact their Visa representatives.
Figure 31-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 31-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 31-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 31-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 31-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 31-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
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,
Settlement
Settlement
Add Field 16: Date, Conversion
Add Field 50: Currency Code, Field 50: Currency Code,
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 31-11 illustrates the message flow for an SMS POS representment transaction. The

NOTE
Figure 31-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
Settlement Field 50: Currency Code,

Settlement
Settlement
Settlement
Figure 31-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 and

NOTE
Figure 31-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
Transaction Add Field 10: Conversion Rate 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 31-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 31-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 31-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 31-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
31.8.4 SMS Visa/Plus ATM Message Flows

The following figures show the Multicurrency Service ATM transaction message flows:
• Figure 31-15
• Figure 31-16
• Figure 31-17
• Figure 31-18

• Figure 31-19
• Figure 31-20
Figure 31-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 31-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 31-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
NOTE
Figure 31-16 Message Flow—SMS Visa/Plus Adjustment

Trans. include conversion fees
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 Field 5: Amount, Settlement
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 31-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

NOTE
Figure 31-17 Message Flow—SMS Visa/Plus Representment

Cardholder Billing
Cardholder Billing
Cardholder Billing
Cardholder Billing
Amount, Settlement
Settlement

Settlement
Settlement
Settlement

Figure 31-18 illustrates the message flow for an SMS Visa or Plus balance inquiry
forwards the request to the issuer. The issuer sends an 0210 response.
Figure 31-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 Conversion to Non-U.S. Amt. type
Amt. sign (C or D) Dollars for Nonparticipants: Bal. A currency code
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 31-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 and
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 31-19 Message Flow—SMS Visa/Plus Reversal

Transaction Add Field 10: Conversion Rate, Transaction
Cardholder Billing
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 31-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 31-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
31.8.5 SMS Interlink Message Flows

The following figures show the Multicurrency Service Interlink transaction message flows.

• Preauthorization (0100)
- Figure 31-21
- Figure 31-22
• Financial Transactions (0200 and 0220)
- Figure 31-23
- Figure 31-24
- Figure 31-25
- Figure 31-26
- Figure 31-27
• Reversal Transactions (0400 and 0420)
- Figure 31-28
• Chargeback (0422)
- Figure 31-29
- Figure 31-30
- Figure 31-31
Figure 31-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 31-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 31-22 illustrates the message flow for an Interlink preauthorization partial approval

NOTE
Figure 31-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 31-23 illustrates the message flow for an Interlink preauthorization completion
transaction. The acquirer sends V.I.P. the 0220 request. V.I.P. performs SMS processing
and forwards the request to the issuer. The issuer sends an 0210 or 0230 response.
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
Code 0599—Consistency Error/Transaction Not Defined.

NOTE
Figure 31-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 31-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 31-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 31-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 31-25 Message Flow—Interlink Adjustment

Trans. include conversion fees Field 6: Amount, Cardholder
Field 61.1: Other Amount, Add Field 10: Conversion Rate, Billing
Trans. Cardholder Billing
Cardholder Billing Field 51: Currency Code,
Convert Field 61.1 amount to Cardholder Billing
Field 61.2: Other Amt., Field 61.1: Other Amount,
Trans.
conversion fees
Field 61.2: Other amount,
Convert Field 4 amount to cardholder billing
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 31-26 illustrates the message flow for an Interlink representment transaction. The
Figure 31-26 Message Flow—Interlink Representment

Cardholder Billing
Cardholder Billing
Cardholder Billing
Cardholder Billing
Amount, Settlement
Settlement

Settlement
Settlement
Settlement

Figure 31-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 31-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
Add Field 54B-converted Bal. B currency code
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)
Figure 31-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 31-28 Message Flow—Interlink Reversal

Transaction Add Field 10: Conversion Rate, 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 31-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 31-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 31-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 31-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 31-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 and
Figure 31-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
31.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.
- 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.
31.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.
31.8.6.2 Acquirer Processing

This section summarizes the fields and values that acquirers send and receive for partial
authorization processing.
Request Messages—Acquirers must include code 1 (terminal accepts partial approvals) in

field 60.10 in 0100 and 0200 request messages.
Response Messages—Acquirers know that an approval is for a partial amount when

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.
31.8.6.3 Issuer Processing

This section summarizes the fields and values that issuers receive and send for partial
authorization processing.
Request Messages—Issuers know that a transaction is eligible for a partial authorization

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).
Response Messages—Issuers indicate that they approve a partial amount by placing
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.
31.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 31-32 Acquirer and Non-Multicurrency Issuer With the Same Currency
Figure 31-33 Acquirer and Multicurrency Issuer With Different Currencies

Chapter 31: Multicurrency Service Key Fields Glossary
Figure 31-34 Acquirer and Non-Multicurrency Issuer With Different Currencies

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.

Key Fields Glossary Chapter 31: Multicurrency Service
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.

Chapter 31: Multicurrency Service Key Fields Glossary
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 31-19 lists the values for field 54.
Table 31-19 Field 54 Values
Values Sent to the Acquirer After

Values Supplied by the Issuer 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.

Key Fields Glossary Chapter 31: Multicurrency Service
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
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 client 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 client 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.

Chapter 31: Multicurrency Service For More Information

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

For More Information Chapter 31: Multicurrency Service

PIN Verification Service (PVS) 32
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-4

Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-5

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-7
Prerequisites for Using the PVV Method. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .32-8
Prerequisites for Using the IBM PIN Offset Method. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .32-10
Placement of Data on Track 1 of the magnetic stripe. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .32-12
Placement of Data on Track 2 of the magnetic stripe. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .32-12
MasterCard PIN Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
How PIN Verification Service (PVS) Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13

PIN Verification Value (PVV) Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-13
IBM PIN Offset Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-14
Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-14
Acquirer Zone and Working Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-15
Issuer Zone and Working Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
PIN Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
Triple Data Encryption Standard Requirements and Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-16
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-18
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-20

MasterCard PIN Processing in Malaysia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32-21


PIN Verification Service (PVS) 32
32.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.

Service Summary Chapter 32: PIN Verification Service (PVS)
PVS is available to clients 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 unattended
cardholder-acceptance (UCAT) 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.

Chapter 32: PIN Verification Service (PVS) Service Summary
• 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 05, but forwards response code 75 in field 39
to the issuer in the 0120 advice. If the issuer returns response code 75, 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 05, but forwards response code 75 in field 39
to the issuer in the 0120 advice. If the issuer returns response code 75, 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.
For successful BASE I and V.I.P. authorization-only PIN verification transactions, that is,
when no error is detected, VisaNet drops fields 52 and 53 before it forwards the message
to available Issuers. For V.I.P. SMS full financial messages, in the case of successful PIN
verifications, VisaNet forwards field 52 and field 53 to the available issuer; however,
field 52 is zero-filled in the outgoing message to the Issuer. If PIN verification fails,
V.I.P. declines the message in STIP with the applicable response code as determined
during STIP processing.
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.
Fulltime PIN Verification—If an issuer's processing center cannot or does not want to
verify 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

Participation Requirements Chapter 32: PIN Verification Service (PVS)
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.
Stand-In PIN Verification—When an issuer prefers to verify its own PINs, it can choose
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.
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 client. “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.

Chapter 32: PIN Verification Service (PVS) Participation Requirements
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.
32.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. Clients 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.
32.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.
Acquirer Prerequisites—Acquirers must generate at least one AWK or instruct Visa to

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.
Issuer Prerequisites—Issuers must generate at least one IWK or instruct Visa to create
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 32-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
Clients 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 32-1 illustrates the PVV generation process. This process occurs within a secure
environment outside VisaNet. Clients convey the keys using a security module.
Figure 32-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
32.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.
For instance, if the displacement is 4 (and the account number length is 12), V.I.P.
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 32-2 illustrates the IBM PIN Offset verification method.
Figure 32-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
32.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
32.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,

Chapter 32: PIN Verification Service (PVS) How PIN Verification Service (PVS) Works
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 clients to manage some keys online.
32.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.
0100: Authorization, Balance Inquiry, or Preauthorization Request—These messages

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.
0110: Authorization Response—This message is the authorization, balance inquiry,

or preauthorization response message.
0120: Advice—This advice notifies issuers that V.I.P. performed PIN verification,
authorization, or both, on their behalf.
0200: Purchase Transaction or ATM Cash Disbursement 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.
0210: Financial Transaction Response—This message is the response to an 0200 or

0201 financial transaction request.
32.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.
32.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

How PIN Verification Service (PVS) Works Chapter 32: PIN Verification Service (PVS)
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.
32.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.
32.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 32-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 32-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 32-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 32-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
32.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

How PIN Verification Service (PVS) Works Chapter 32: PIN Verification Service (PVS)
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.
32.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.
32.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.
NOTE
Fields 52 and 53 remain with the request message when the message requires PIN translation only.
32.6.4 Triple Data Encryption Standard Requirements and Timeline

Visa has incorporated the industry-standard Triple Data Encryption Standard (TDES)
throughout VisaNet and its clients' 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 clients and client processors began moving to TDES in October 2005. The migration
included important milestones for each region.
Table 32-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 32-1 Triple Data Encryption Migration Dates (continued)
Region Milestone Objective No Later Than…

Asia-Pacific Issuers must be able to receive and process TDES transactions. 1 July 2007
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 clients 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), and 1 October 2005
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, 31 December 2007
or 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.

Process Flows Chapter 32: PIN Verification Service (PVS)
32.7 Process Flows

Figure 32-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 32-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.

Chapter 32: PIN Verification Service (PVS) Process Flows
• 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 clients, however,
have reciprocal agreements to pick-up the cards after the specified number of unsuccessful PIN-entry attempts
has occurred.

Message Flows Chapter 32: PIN Verification Service (PVS)
32.8 Message Flows

Figure 32-6 illustrates the PVS message flow.
Figure 32-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
V.I.P. always forwards field 52 and field 53 to available issuers when PINs are translated (decrypted). V.I.P. will
decline the message in STIP when unsuccessful PIN verification occurs. V.I.P. drops field 52 and field 53 from
Base I and Authorization only request messages when PIN verifications are successful. V.I.P. retains field 52 and
field 53 for V.I.P. full financial request messages, however, field 52 is zero filled for successful PIN verification.

Chapter 32: PIN Verification Service (PVS) Key Fields Glossary
32.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 clients 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
Positions 1 and 2, PAN and Date Entry Mode—This subfield contains a 2-digit code
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.
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.
V.I.P. rejects authorization requests with code 0019 if the value in field 22 is 90, but the
acquirer has not successfully completed testing to transmit a value of 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.
Position 3, PlN Entry Capability—This subfield contains a 1-digit code that identifies
the 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.

Key Fields Glossary Chapter 32: PIN Verification Service (PVS)
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.
Position 4, Fill (Unused)—This 1-digit subfield is zero-filled. This requirement is an

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 12. 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.

Key Fields Glossary Chapter 32: PIN Verification Service (PVS)
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,
V.I.P. rejects the message with Reject Code 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.
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 BASE I PIN and V.I.P. authorization-only verification transactions, that
is, when no error is detected, VisaNet drops fields 52 and 53 before it forwards the
message to available issuers. For V.I.P. SMS full financial messages, in the case of
successful PIN verifications, VisaNet forwards field 52 and field 53 to the available
issuer; however, V.I.P. zero-fills field 52 in the outgoing message to the issuer. If PIN
verification fails, V.I.P. declines the message in STIP with the applicable response code
as determined during STIP processing.
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
Positions 1–2, Security Format Code—The code in field 53.1 defines the security
technique used. The code in positions 1–2 must be 20.
Positions 3–4, PIN Encryption Algorithm Identifier—The code in field 53.2 defines
the encryption technique used. Code 01 is the only code allowed in this subfield.
Positions 5–6, PIN Block Format 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, 02, or 03.
Positions 7–8, Zone Key Index—The index in field 53.4 indicates which key was used
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 must
contain code 01 or 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
Positions 9–10, PIN Data Type—The code in this subfield code defines the
personal ID data type (PIN or password) contained in field 52. Positions 9–16 must
contain zeros in outgoing requests.
Positions 11–16: Visa Reserved—This subfield is used by BASE I.
Positions 9–16 are reserved for BASE I use at the VIC. They must be zero-filled by the
acquirer.
Table 32-2 lists valid values for field 53.
Table 32-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
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.

For More Information Chapter 32: PIN Verification Service (PVS)
Table 32-2 Field 53 Security Codes (continued)
Code Definition
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 BASE I and V.I.P. authorization-only PIN verification transactions, that
is, when no error is detected, VisaNet drops fields 52 and 53 before it forwards the
message to available issuers. For V.I.P. SMS full financial messages, in the case of
successful PIN verifications, VisaNet forwards field 52 and field 53 to the available
issuer; however, V.I.P. zero-fills field 52 in the outgoing message to the issuer. If PIN
verification fails, V.I.P. declines the message in STIP with the applicable response code
as determined during STIP processing.
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

Chapter 32: PIN Verification Service (PVS) For More Information
Volume 2
• IBM 3624 Consumer Transaction Facility Programmer's Reference and Component
Descriptions

For More Information Chapter 32: PIN Verification Service (PVS)

POS Check Service 33
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-3

Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-4
POS Check Service Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-5

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-6
Acquirer or Processor Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-6
Merchant Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-7
Participating Drawee Financial Institution Implementation. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .33-8
Delivery Methods for POS Check Service Requests. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .33-8
How POS Check Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-9
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-9

Authorization Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-10
Settlement Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-11
Settlement Through VisaNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-11
Settlement Through the ACH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-12
ABA Account Number Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
MICR Line Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-13
Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
POS Check Exception Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33-14
Visa Resolve Online (VROL) Processing of POS Check Transactions. . . . . . . . . . . . . . . . . . . . .33-15


POS Check Service 33
33.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.
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

Service Summary Chapter 33: POS Check Service
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 33-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 33-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
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.

Chapter 33: POS Check Service Participation Requirements
33.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 33-2.
Table 33-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.
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 client, or a Visa-approved non-client acting as the agent of a client,
providing authorization, clearing, and/or settlement services for clients
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
Authorizing Agent banks and creates ACH items that are sent to the ODFIdebtor agent.
VisaNet The data processing systems, networks, and operations used by the 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:

Participation Requirements Chapter 33: POS Check Service
• 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.
33.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)
The VisaNet Certification Management Service (VCMS) provides testing assistance for POS
Check Service participants. Participants can contact their Visa representatives to make
the arrangements.

Service monitoring is available for the POS Check Service. Clients 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.
33.4.3.1 Acquirer or Processor Implementation

The acquirer or its processor needs to:

Chapter 33: POS Check Service Participation Requirements
• 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 Visa Rules for the service.
• With its merchant or merchants, be successfully tested by Visa, and ensure that its
merchants comply with the requirements of the Visa Rules 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.
33.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.
- 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 Visa Rules 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.

Related Messages Chapter 33: POS Check Service
33.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 Visa Rules for the service.
• Be successfully tested with Visa or with its drawee processor.
33.4.3.4 Delivery Methods for POS Check Service Requests

Acquirers can send POS Check Service requests directly through their VisaNet connection
as follows:
Using a VisaNet 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.
For information about VisaNet connections, 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
• 0220 STIP advice and 0230 STIP advice response
• 0420 financial reversal request and 0430 financial 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
• 0220 acquirer-generated fee collection, returned check fee, or funds disbursement
request, and 0230 fee collection, returned check fee, or funds disbursement request
response

Chapter 33: POS Check Service Process Flows
• 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
33.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
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).
33.7 Process Flows

This section provides authorization and settlement process flows for the POS Check
Service.

Process Flows Chapter 33: POS Check Service
33.7.1 Authorization Process Flow

The POS Check Service authorization process flow, shown in Figure 33-1, includes the
following steps.
Figure 33-1 POS Check Authorization Processing Flow
Participating
Drawee Financial
Institution
Customer POS Merchant Acquirer V.I.P.
Third Party
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.
33.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.
33.7.2.1 Settlement Through VisaNet

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 33-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 33-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.
33.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 33-3. All settled transactions and post-settlement exception items
relating to these transactions must be processed according to the NACHA rules.
Figure 33-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.
33.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 (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.
33.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 33-4 shows the layout of a check MICR line.
Figure 33-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 33-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.
33.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.
33.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.

Chapter 33: POS Check Service Key Fields Glossary
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.
33.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.
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,
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), Verification With Conversion (04), or
Conversion Only (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.

Key Fields Glossary Chapter 33: POS Check Service
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),
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.
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

Chapter 33: POS Check Service Key Fields Glossary
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.
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 33-3 and Table 33-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 33-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.”
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.

Key Fields Glossary Chapter 33: POS Check Service
Table 33-3 POS Check Field 125 Format Requirements—Unformatted MICR (continued)
Field
Number/Name Position/Size Data Content Format
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 (I) must be replaced
by the letter T either in upper or lower
case.
The on-us symbol (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
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 33-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 (t, o, d) must be stripped out when the field is returned.
Routing Transit The drawee financial institution's routing The routing transit number has a fixed length of 9 numeric
Number transit number (ABA number). 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
length of the data, and dddd the actual data content.

Chapter 33: POS Check Service For More Information
Table 33-4 POS Check Field 125 Format Requirements—Parsed MICR (continued)
Field
Number/Name Required Data Format
Check Serial The check serial number of the check The check serial number, when present, is a maximum of
Number being converted. 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
Volume 2
• ANSI Standard X9.13-1999 Placement and Location of MICR Printing Specifications
• www.ansi.org; click on Standards Info.
• www.nacha.org

For More Information Chapter 33: POS Check Service

Positive Authorization Capacity 34
Management (PACM) Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-4

Determining Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-5
Advice Message Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-5
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-5
How Positive Authorization Capacity Management (PACM) Service Works. . . . . . .34-6
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6

Determining Which Transactions To Divert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
Transactions Always Routed To STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-6
Transactions Eligible for STIP Diversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-7
Transactions Not Eligible for STIP Diversion. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .34-7
Calculating a Diversion Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-7
BASE I and SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-8
BASE I Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-8
SMS Diversion Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34-9
Stand-In Processing of PACM-Diverted Transactions. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .34-10


Positive Authorization Capacity 34
34.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

Participation Requirements Chapter 34: Positive Authorization Capacity Management
(PACM) Service

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 35, 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

Chapter 34: Positive Authorization Capacity Participation Requirements
non-participating BINs should be aware that although PACM monitors all transaction
traffic, PACM STIP diversion occurs only for PACM-participating BINs.
34.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 their Visa representatives 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.
34.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.
34.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.
The VisaNet Certification Management Service (VCMS) provides testing assistance

for PACM participants. Clients 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.

Process Flows Chapter 34: Positive Authorization Capacity Management
(PACM) Service

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.
34.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.
34.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 34-1
illustrates diversion processing.
Figure 34-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.
34.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.
34.7.1.1 Transactions Always Routed To STIP

PACM always routes the following transactions to STIP:

Chapter 34: Positive Authorization Capacity Process Flows
• 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.
34.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.
34.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 37, Status Check Service.
• Traffic destined for acquirers
• Issuer traffic for BINs not enrolled in PACM
34.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

(PACM) Service
capacity to ensure that it is diverting the optimum transaction volume and adjusts the
diversion level accordingly. Figure 34-2 illustrates how PACM calculates a diversion level.
Figure 34-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% —
34.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.
34.7.3.1 BASE I Diversion Tables

For BASE I issuers, each region can define its own diversion tables. Table 34-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)

Chapter 34: Positive Authorization Capacity Process Flows
6 = Central and Eastern Europe, Middle East, and Africa (CEMEA)
Table 34-1 BASE I PACM Diversion Tables by Visa Region
Percentage
of Eligible
Diversion Level Transactions BASE I DIVERSION TABLES
Diverted to Dollar Value of Diverted Transactions (Eligible
STIP 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
34.7.3.2 SMS Diversion Tables

SMS issuers can select their diversion table from one of the three listed in Table 34-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.

(PACM) Service
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 34-2 SMS PACM Diversion Tables
Percentage
of Eligible
Diversion Level Transactions
Diverted to SMS DIVERSION TABLES
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
34.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:

Chapter 34: Positive Authorization Capacity For More Information
• 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 32, 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 clients that participate in PCAS. For non-PCAS client
(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.

For More Information Chapter 34: Positive Authorization Capacity Management
(PACM) Service

Positive Cardholder Authorization 35
Service (PCAS)
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-3

Key Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-4
How Positive Cardholder Authorization Service (PCAS) Works. . . . . . . . . . . . . . . . . . . . . .35-5

Merchant Category Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-6
Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-6
Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
Merchant Category Group Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .35-7
Total Purchase and Total Cash Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .35-7
Issuer-Available- and Issuer-Unavailable-Activity Limits. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .35-7
Count, Amount, and 4-Day Multiplier Activity Limits. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .35-8
Mandated Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
Mandatory Minimum (T&E) Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
Mandatory Minimum Non-T&E Issuer Limits. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .35-9
Mandatory Minimum Activity Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-9
Applying Appropriate Issuer and Activity Limits: Issuer-Specified or
Visa-Mandated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
Overriding Mandatory Minimum Limits. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
Mandatory Zero MOTO Issuer Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
Advice Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-10
Activity Checking and Accumulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-11
Cardholder Risk Levels and Individual Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-12

Defining Risk-Level Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
Multiple Limit Selection Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
Random Selection Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
BIN Blocking and Country Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35-13
Risky Countries and Country-to-Country Embargoes. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .35-14

Positive Cardholder Authorization 35
Service (PCAS)
35.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.
BASE I
SMS PCAS is available to both BASE I and SMS System issuers.
BASE I and SMS
I Participation in PCAS is optional for issuers. PCAS is available for all card
types, including private label cards.
Issuer

Participation Requirements Chapter 35: Positive Cardholder Authorization Service (PCAS)
35.2.1 Key Terms

These key terms are essential for understanding how PCAS works:
Issuer Limit—This limit is the transaction amount that determines whether a transaction
is processed by BASE I STIP or by the issuer processor.
Activity Limit—This limit is the transaction amount that controls accumulated cardholder
spending.
Advice Limit—This limit is the transaction amount that determines whether STIP performs
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:
Initial STIP or Switch Decision—PCAS-established limits determine whether V.I.P. is to

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.
Issuer-Available Approve or Forward-Refer Decision—PCAS-established limits

determine 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.
Issuer-Unavailable Approve or Refer Decision—PCAS-established limits determine

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.
35.4.1 Testing
Testing is optional for authorization processing. The VisaNet Certification Management
Service (VCMS) provides testing assistance. Clients can contact their Visa representatives
to make the arrangements.

Chapter 35: Positive Cardholder Authorization Service (PCAS) How Positive Cardholder Authorization Service (PCAS) Works

Service monitoring is not available for PCAS.

PCAS operates on 0100 authorization requests and their reversals.
35.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
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:
Category A: Below-Advice-Limit Transactions—Transactions in which the transaction

amount is less than the advice limit. Verification-only requests (address or account)
are placed in Category A.
Category B: Between-Limits 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.
Category C: Above Issuer Limit Transactions—Transactions in which the transaction

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.

How Positive Cardholder Authorization Service (PCAS) Works Chapter 35: Positive Cardholder Authorization Service (PCAS)
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.
35.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
If the processing code in field 3 is 01 (cash disbursement) and Field 18—Merchant Type is not ATM (6011),
V.I.P. assigns the transaction to the Other Cash MCG.
35.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.
35.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.
35.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.
35.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.
35.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.
Issuer-Available Limits—V.I.P. uses these activity limits when the issuer processor is
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.
Issuer-Unavailable Limits—These activity limits apply to transactions processed by STIP

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.
35.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.
1-Day Count Limit—This limit applies to the current day's transactions. The amount can
be any integer value between 0 and 255.
1-Day Amount Limit—This limit applies to the current day's transactions. The amount
can be any U.S. dollar amount between $0.00 and $65,535.00.
4-Day Multiplier—The 1-day count and amount limits are multiplied by the 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.

35.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.
35.6.4.1 Mandatory Minimum (T&E) Issuer Limits

Visa Core Rules and Visa Product and Service Rules 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.
35.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.
35.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.

35.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 35-1 summarizes V.I.P. limit application.
Table 35-1 Choosing Issuer-Specified or Visa-Mandated Limits
To determine For this Issuer-specified Visa-Mandatory

the following Transaction Issuer Limit Minimum Use the
limit... Type Issuer 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.
35.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.
35.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.
35.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.
35.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.
Total Purchase Activity Checking and Accumulation—V.I.P. checks Total Purchase

activity limits when the issuer has not specified limits for the Non-Cash MCG.
Travel and Entertainment Activity Checking and Accumulation—If mandatory

minimum 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.

MOTO and Risky Purchase Activity Checking and Accumulation—When specified, V.I.P.
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.
Medical and Other Purchase Activity Checking and Accumulation—V.I.P. checks

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.
Total Cash Activity Checking and Accumulation—V.I.P. checks and accumulates Total
Cash activity limits for Quasi-Cash and other Cash transactions. MCG-level activity limits
are not available for these MCGs.
ATM Cash Activity Checking and Accumulation—When limits are specified, V.I.P. checks
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.
35.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.

35.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.
35.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.
35.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:
Below the Advice Limit—Issuers designate a random selection factor (a certain

percentage) 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.
Between the Advice Limit and Issuer Limit—Issuers designate a random selection factor
(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.
35.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.

For More Information Chapter 35: Positive Cardholder Authorization Service (PCAS)
• Only in a selected list of countries.

• In all countries except a selected list of countries.
35.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
A (Approval), D (Decline), or R (Referral). V.I.P. translates these codes to 00, 05, and 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:

Preauthorized Payment 36
Cancellation Service (PPCS)
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-5
How Preauthorized Payment Cancellation Service (PPCS) Works. . . . . . . . . . . . . . . . . . .36-5

Updating the Cardholder Database Portfolio File (PF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-6
File Edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36-7


Preauthorized Payment 36
Cancellation Service (PPCS)
36.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 clients 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. Clients that issue check cards must comply with the
terms of those regulations.

Participation Requirements Chapter 36: Preauthorized Payment Cancellation Service (PPCS)
Preauthorized Payment Cancellation Service (PPCS) is available to clients 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).

Chapter 36: Preauthorized Payment Cancellation How Preauthorized Payment Cancellation Service
Service (PPCS) (PPCS) Works
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
response codes R0, R1, and R3, in 0110 authorization and 0210 financial response
messages.
36.4.1 Testing
The VisaNet Certification Management Service (VCMS) is available for testing. Clients 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—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.
0312: File Maintenance Response—This message is the response to an 0302 file

maintenance request.
Acquirers submit preauthorized payment transactions as 0100 authorization or 0200

financial requests. Issuers receive advices for declined transactions.
36.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—Stop specific payment
• R1—Revocation of Authorization Order
• R3—Revocation of All Authorizations Order
NOTE
See the BASE II Data Codes manual – Return Reason codes for additional information on stop payment codes.

How Preauthorized Payment Cancellation Service (PPCS) Works Chapter 36: Preauthorized Payment Cancellation Service (PPCS)
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 (R0, R1, or 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.
36.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. 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.)

Chapter 36: Preauthorized Payment Cancellation Key Fields Glossary
Service (PPCS)
36.6.1.1 File Edits

Table 36-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 36-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
stop-order type is not DF11. The stop-order
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.

Key Fields Glossary Chapter 36: Preauthorized Payment Cancellation Service (PPCS)

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 36-2 contains field 127.PF data elements.
Table 36-2 PF Data Elements for Field 127
Position Name Length Position Description

Field 127 Length 1 byte, binary No change.

Chapter 36: Preauthorized Payment Cancellation Key Fields Glossary
Service (PPCS)
Table 36-2 PF Data Elements for Field 127 (continued)
Position Name Length Position Description

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 subfields 1-byte stop-order
• Tag = 2 bytes for the type of type must be in
• Length = 1 byte stop order TLV, the binary format. Tag
• Value = 2 bytes; cardholder name TLV, value must be DF11
stop-order type and the merchant (type of stop order).
account number TLV
may be present in Required in 0302
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
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 More Information Chapter 36: Preauthorized Payment Cancellation Service (PPCS)

For further information about the Preauthorized Payment Cancellation Service (PPCS),
clients can contact their Visa representatives.

Status Check Service 37
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-4
How Status Check Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-5
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-6
Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37-7


Status Check Service 37
37.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.

Participation Requirements Chapter 37: Status Check Service
The Status Check Service is available to clients in all Visa regions.
BASE I
SMS The Status Check Service is available both to BASE I System users and to Single
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.
37.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, clients must contact their Visa representatives.

Service monitoring is not available for the Status Check Service.

Chapter 37: Status Check Service How Status Check Service Works

The following messages pertain to the Status Check Service.
0100: Authorization Request—This message contains the single currency unit

(in Field 4—Amount, Transaction) that initiates the status check.
0110: Authorization Response—This message provides the status check response to

the 0100 message.
0120: Advice Response—This message contains the status check response when STIP
processes the transaction on the issuer's behalf.
37.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 one of the following
values:
- 5542 (Automated fuel dispenser)
- 8062 (Hospitals) with merchant located in Latin America.
• Lodging merchant (MCC) and Field 62.6—Prestigious Property Indicator, with one
of the following values:
- D (Prestigious property with a USD$500 limit)
- B (Prestigious property with a USD$1000 limit)
- S (Prestigious property with a USD$1500 limit)
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.

Process Flows Chapter 37: Status Check Service
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.
37.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.

Chapter 37: Status Check Service Message Flows
Figure 37-1 illustrates the Status Check Service process flow.
Figure 37-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.
37.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.

Key Fields Glossary Chapter 37: Status Check Service
Figure 37-2 illustrates the Status Check Service message flow. (See the format descriptions
for the fields in “Key Fields Glossary” in this chapter.)
Figure 37-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).

Chapter 37: Status Check Service For More Information

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.

For More Information Chapter 37: Status Check Service

Visa Cashback Processing: VisaNet 38
Cashback Service
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-4

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-5
Issuer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
Magnetic Stripe Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
Chip Card Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-6
Acquirer Implementation Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-7
Chip Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-7
How VisaNet Cashback Service Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-8

Stand-In Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-9
PIN Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-9
VSDC Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-9
Participating Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
Other Cashback Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
United Kingdom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10
United States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38-10


Visa Cashback Processing: VisaNet 38
Cashback Service
38.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 client 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, 07, 91 or 95)
are eligible for cashback. V.I.P. rejects cashback transactions that do not meet these criteria.

Service Summary Chapter 38: Visa Cashback Processing: VisaNet Cashback Service
The VisaNet Cashback Service is available to clients 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 client 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 Visa
Canada (CAN), 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.

Chapter 38: Visa Cashback Processing: VisaNet Participation Requirements
Cashback Service
The following table lists the cashback services currently supported by VisaNet.
Table 38-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), Visa Canada
(CAN)
U.K. Cashback Service United Kingdom only Visa, Visa Electron Defined by merchant,
cardholder, and issuer
IMPORTANT
Specific card products might apply for specific regions. For more information, contact your Visa representative.
This service description is a summary of a more in-depth description of the VisaNet

Cashback Service. Clients can contact their Visa representatives for complete service
information.

Participation in the VisaNet Cashback Service is optional for issuers, acquirers, and
merchants.
Visa Core Rules and Visa Product and Service Rules 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.
38.4.1 Testing
Testing are optional for the VisaNet Cashback Service. Visa recommends that regions
make testing mandatory for clients 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.

Participation Requirements Chapter 38: Visa Cashback Processing: 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.
38.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.
38.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.
38.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:

Chapter 38: Visa Cashback Processing: VisaNet Participation Requirements
Cashback Service
• 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.
38.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—Cash service not available. This response code indicates that the issuer does
not participate in the VisaNet Cashback Service.
• 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—Invalid value. This reject code is returned when the cashback amount is equal to
or greater than the total transaction amount.
• 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—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 the
Visa Rules.
NOTE
VisaNet declines cashback transactions destined to non-U.S.issuers from U.S. acquirers with response
code N3 (cash service not available).
38.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:

How VisaNet Cashback Service Works Chapter 38: Visa Cashback Processing: VisaNet Cashback Service
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.
• 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
38.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 applicable Visa Rules 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—Cash service not available. This response code indicates that the issuer does
not participate in the VisaNet Cashback Service.
• 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—Invalid value. This reject code is returned when the cashback amount is equal to
or greater than the total transaction amount.

Chapter 38: Visa Cashback Processing: VisaNet How VisaNet Cashback Service Works
Cashback Service
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.
38.6.1 Stand-In Processing

Maximum cashback limits for participating countries are maintained in CORE. Valid
values for the limit are:
• USD$0.00—None; no cashback allowed. V.I.P. declines all cashback transactions for this
country with N3—Cash service not available. This is also the default value for the
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—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.
38.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—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).
38.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.

How VisaNet Cashback Service Works Chapter 38: Visa Cashback Processing: VisaNet Cashback Service
38.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])
• Canada
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.S., New Zealand, and Australia—The transaction should be a PIN transaction.
• Australia—The service restriction code of the transaction should be chip or proximity card (field 40 begins
with 2 or 6). The POS entry mode code in field 22 should be 5, 7, 91, or 95.
Clients can contact their Visa regional representatives for maximum cashback amounts
and for other region-specific information.
38.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 38-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
38.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).
Clients can contact their Visa regional representatives for maximum cashback amounts
and for other region-specific information.
38.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.).

Chapter 38: Visa Cashback Processing: VisaNet For More Information
Cashback Service

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 applicable
Visa Rules 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).

For More Information Chapter 38: Visa Cashback Processing: VisaNet Cashback Service

Visa Token Service 39
In Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-3
Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-3

Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-5
Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-6
Token Data Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39-7


Visa Token Service 39
39.1 In Brief
The Visa Token Service is available to clients in all Visa regions.
BASE I
SMS The Visa Token Service is available both to BASE I System users and to Single
BASE I and SMS
I Participation in the Visa Token Service is mandatory for issuers.
Issuer
A Participation in the Visa Token Service is mandatory for acquirers.
Acquirer

The Visa Token Service provides clients with an increased protection against counterfeit,
account misuse, and other forms of fraud. These protections are needed for
card-not-present and hybrid transaction environments to help minimize unauthorized use

Service Summary Chapter 39: Visa Token Service
of cardholder account data and prevent cross-channel fraud. The Visa Token Service uses
the EMVCo Payment Tokenization Specification–Technical Framework (payment token
framework) published by EMVCo that addresses processing considerations and use of
payment tokens to protect cardholder payment credentials. The payment token framework
describes the data elements and their intended use by the payment ecosystem in order to
support the use of payment tokens in transactions.
Visa supports the payment token framework for Visa (network 0002) and Interlink (network
0003). This allows endpoints to optionally support the designated token fields and enable
payment token processing according to the payment token framework.
Visa supports the payment industry implementation of the payment token framework
by passing token data elements in transaction messages.
The Visa Token Service provides token provisioning, payment processing, and token
lifecycle management for consumer mobile devices. Issuers that support this service
will support payment token processing initiated from consumer devices for NFC Visa
payWave, application-based e-commerce, and card-on-file channels for POS transactions.
The Visa Token Service replaces the original payment credential, the primary account
number (PAN), with a payment token that may be used to initiate, authorize, and settle a
Visa transaction. The Visa Token Service enables consumer devices to be provisioned with
a payment token as the payment credential.
Visa offers token services that are comprised of a number of discrete functions, that
include, but are not limited to:
• Establishment and management of the Visa Token Vault that maintains the token to
PAN mapping.
• Generation and issuance of payment tokens.
• Provisioning of payment tokens.
• Application of security and controls.
• Transaction processing with payment tokens.
• Ongoing operation of the Visa Token Vault to manage lifecycle events.
A Lightweight Implementation Option is available for both SE (Secure Element) and HCE
(Host Card Emulation) mobile devices and eases the implementation process by providing
tools that help enable the functionality for seamless deployment.
NOTE
Contact your regional client support representative for information about onboarding, enrollment,
configuration, and provisioning.
Issuers that choose to implement the Visa Token Service for SE (Secure Element) or
HCE (Host Card Emulation) mobile devices with the lightweight implementation option
must be prepared to process transactions using the Visa Mobile Contactless Payment
Specification (VMCPS).
NOTE
Contact your regional client support representative to obtain the Visa Mobile Contactless Payment Specification
(VMCPS).

Chapter 39: Visa Token Service Participation Requirements

Participants in the Visa Token Service include, but are not limited to, the following
payment token requestors:
• Card-on-file merchants
• Acquirers, acquirer processors, and payment gateways on behalf of merchants
• Payment enablers, such as original equipment manufacturer (OEM) device manufacturers
• Digital wallet providers
• Card issuers
Token Requestors are required to register with Visa as Token Service Providers and comply
with the participation requirements, systems, and processes. After successful registration,
the Token Requestor is assigned a Token Requestor ID. After successful registration, the
Token Requestor can initiate Payment Token Requests in accordance with the processes
and technologies specified within the interface specification.
Card issuers maintain their current role in terms of owning the account relationship with
the cardholder, as well as owning authorization and ongoing risk management in the
Payment Token ecosystem. The service offers the issuer’s cardholders more innovative
payment methods with a reduced risk of their payment credentials being compromised.
Issuers can provide cardholders visibility into their spending behavior.
The network service provides the same seamless experience to cardholders today and
does not change the cardholder experience. Issuers continue to issue cards to cardholders
just as they do currently. In most cases, cardholders are not expected to know that a
payment token has been issued to represent their account. Optionally, token requestors
can choose to make cardholders aware and can also ask the cardholder to participate
in the identification and verification process for token assurance. Token assurance offers
the advantage of not needing to re-issue physical plastic if the cardholder database
gets compromised.
The structure of a token is very similar to a PAN and there is minimal impact to merchants
and their back-end systems. Tokens offer increased data protection as account numbers
are not being passed around during transaction processing. Merchants also gain the
advantage of a fully authenticated e-commerce transaction when implementing the
network token service.
Acquirers process all transactions in the same manner they do today, including
authorization, capture clearing, and exception processing. Additional fields may be
required to support the specification. The service offers reduced threat of attacks,
breaches and cross channel fraud for the Acquirers.
39.4.1 Testing
Contact your regional client support representative for more information on testing.

Service monitoring is not available for the Visa Token Service.

Process Flows Chapter 39: Visa Token Service
39.5 Process Flows

This figure illustrates the major steps for the issuer and token requestor. This flow
represents a general overview of the process.
Figure 39-1 Token Interaction Processing

Chapter 39: Visa Token Service Token Data Elements
This process flow represents a general overview of a token transaction.
Figure 39-2 Token Transaction Processing
39.6 Token Data Elements

Endpoints, including acquirers, merchants, and processors, must be aware of the following
required token data elements:
• Token—A surrogate value for a PAN that is consistent with ISO 8583 message
requirements and is a 13 to 19-digit numeric value that must pass basic validation rules
of an account number, including the LUHN check. Payment tokens are generated within
a BIN range that has been designated as a token BIN range and flagged accordingly
in all appropriate BIN tables. Payment tokens must not have the same value as or
conflict with a cardholder PAN.
• Token Expiration Date—The expiration date of the token that is generated by
and maintained in the token vault and passed in the PAN Expiration Date field
during transaction processing to ensure interoperability and minimize the impact
of tokenization implementation.
• POS Entry Mode—A value that is used to indicate the token presentment mode through
which the token is presented for payment. Each network will define and publish any
new POS entry mode values as part of its existing message specifications.

For More Information Chapter 39: Visa Token Service
• Token Requestor ID—A value that uniquely identifies the pairing of token requestor with
the token domain. Thus, if a given token requestor needs tokens for multiple domains,
it will have multiple token requestor IDs, one for each domain. It is assigned by the
token service provider and is unique within the token vault.
• Token Assurance Level—A value that allows the token service provider to indicate the
confidence level of the payment token to PAN/cardholder binding. It is determined as
a result of the type of identification and verification (ID&V) performed and the entity
that performed it. The token assurance level is set when issuing a payment token and
may be updated if additional ID&V is performed. The token assurance level value
is defined by the token service provider.
• Token Cryptogram—A cryptogram that is uniquely generated by the token service
provider through cryptography to validate authorized use of the token.

Contact your regional client support representative.

Index
A advice file—BASE I
advice retrieval 21-10
Account Verification Service
description 16-8, 21-3
eligibility 19-3
advice file—SMS
fields 19-8 to 19-9
message flow 19-6
messages
advice limit 35-10
related messages 19-4
advice recovery 21-10
participation requirements 19-4
Advice Retrieval Service—BASE I
process flow 19-6
eligibility 21-3
activity checking and accumulation 35-11
fields 21-11
activity file
message flow 21-11
in PIN Verification Service (PVS) 32-13, 32-19
messages
Activity File 16-5
advice message creation 21-7
description 16-5
processing modes 21-7
file layout 16-3
activity limits
in Positive Cardholder Authorization Service (PCAS) 35-7
process flow
issuer available and unavailable 35-7
during and after VIC switchover 21-10
Address Verification File
offline 21-4
online 21-7, 21-9
file layout 16-4
Advice Retrieval Service—SMS
Address Verification Service (AVS)
fields 22-13
address data 20-12
message flow 22-12
data compression 20-15
messages
eligibility 20-4
advice message creation 22-8
fields 20-7, 20-33, 20-36
processing modes 22-9
message flow 20-24, 20-33
messages
process flow 22-9
during and after VIC switchover 22-12
process flow
ATM Format Conversion Service
basic 20-9 to 20-10
eligibility 23-4
variations 20-22 to 20-23
fields 23-12
sample results 20-21
Advice File
file layout (basic) 16-3
1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 IX-1

Index
messages
augmentation 23-7
B
BASE I System
advice file 21-9 to 21-10
Exception File 21-6
process flow 23-8
BASE II System
authorization database services
advice delivery 21-4
Automatic Cardholder Database Update (Auto-CDB)
Brazil national market program
Service 17-3, 17-9
Custom Payment Service (CPS)/POS 28-14
Merchant Central File Service (MCFS) 18-3, 18-30
authorization services
Account Verification Service 19-3, 19-10 C
Address Verification Service (AVS) 20-3, 20-36 Card Verification Value (CVV) Service
Advice Retrieval Service—BASE I 21-3, 21-12 eligibility 24-6
Advice Retrieval Service—SMS 22-3, 22-14 emergency replacement 24-23
ATM Format Conversion Service 23-3, 23-13 fields 24-27, 24-29
Card Verification Value (CVV) Service 24-3, 24-30 iCVV description 24-4
Card Verification Value 2 (CVV2) Service 25-24 issuer options
Custom Payment Service (CPS)/ATM 27-3, 27-15 default response codes 24-23
Custom Payment Service (CPS)/POS 28-3, 28-17 receiving results 24-22
Deferred Clearing Advice File (DCAF) Service 29-3, 29-11 messages 24-20
Dynamic Key Exchange (DKE) Service 30-23 participation requirements 24-8, 24-18
Multicurrency Service 31-67 Card Verification Value 2 (CVV2) Service
PIN Verification Service (PVS) 32-26 calculation 25-10
POS Check Service 33-3, 33-19 eligibility 25-4
Positive Authorization Capacity Management (PACM) emergency replacement 25-14
Service 34-3, 34-11 encryption 25-10
Positive Cardholder Authorization Service (PCAS) 35-14 fields 25-20 to 25-21
Preauthorized Payment Cancellation Service (PPCS) 36-10 emergency replacement 25-23
Status Check Service 37-9 messages
Visa Token Service 39-8 message flow 25-18
VisaNet Cashback Service 38-11 related messages 25-9
authorization-related chargeback protection process flow 25-18
Custom Payment Service (CPS)/POS 28-9 processing options
Auto-CDB Service, See Automatic Cardholder Database Update description 25-11
(Auto-CDB) Service stand-in processing (STIP) 25-12
Automatic Cardholder Database Update (Auto-CDB) Service 17-3, variations 25-13
22-5 specifications for card 25-8
eligibility 17-3 Cardholder Authentication Verification Value (CAVV) Verification
fields 17-8 Service 26-3
messages eligibility 26-4
advices 17-5 fields 26-15
message flow 17-7 how the service works 26-8
related messages 17-4 participation requirements 26-5
participation requirements 17-4 related messages 26-7
pick-up action codes 17-6 service monitoring 26-7
process flow 17-6 Cardholder Database
AVS, See Address Verification Service (AVS) activity file
IX-2 Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Index
Activity File Currency Rate Delivery Service, See Multicurrency Service

description 16-5 Custom Payment Service (CPS)/ATM
file layout 16-3 eligibility 27-4
Address Verification File fields 27-15
description 16-7, 20-8 participation requirements 27-6
file layout 16-4 process flow 27-8
Advice File service monitoring 27-7
file layout (basic) 16-3 Custom Payment Service (CPS)/POS
advice file—BASE I authorization characteristics indicator 28-16
advice retrieval 21-10 authorization-related chargeback protection 28-9
description 16-8, 21-3, 21-9 to 21-10 Brazil national market program 28-14
advice file—SMS chargeback rights indicator values 28-9
advice retrieval 22-12 common clearing requirements 28-12
description 16-8, 22-4 eligibility 28-4
Exception File fee changes 28-8
advices 17-5 fields 28-15
description 16-4, 16-9, 17-4 life-cycle control 28-9
discrepancy advice 17-5 participation requirements 28-6
layout 16-4 process flow 28-9
update advice 21-6 programs 28-6
PIN Verification File validation code 28-17
description 16-12, 32-9 CVV Service, See Card Verification Value (CVV) Service
file layout 16-4 CVV2 Service, See Card Verification Value 2 (CVV2) Service
Portfolio File
description 16-14
file layout 16-4
D
DCAF, See Deferred Clearing Advice File (DCAF) Service
risk level file
decimal positioning 31-5
description 35-12
decimal positions indicator
risk-level file
acquirer 31-6
description 16-14
one-position adjustment 31-29
Risk-Level File
two-position adjustment 31-29
file layout 16-4
Deferred Clearing Advice File (DCAF) Service
cardholder risk levels 35-12
eligibility 29-3
CAVV, See Cardholder Authentication Verification Value (CAVV)
fields 29-11
CAVV Service, See Cardholder Authentication Verification Value
file content 29-5
(CAVV) Verification Service
file delivery 29-4
chargeback rights indicator values
message flow 29-10
conversion rate, See currency conversion
process flow 29-9
CPS, See Custom Payment Service (CPS)
record format 29-5
CPS/POS, See Custom Payment Service (CPS)/POS
currency conversion 31-7
service monitoring 29-6
clearing and settlement currency conversion 31-6
service options 29-4
conversion charge 31-4
DKE, See Dynamic Key Exchange (DKE) Service
Dynamic Key Exchange (DKE) Service
non-participants 31-10
eligibility 30-3
processing 31-4
fields 30-20, 30-22
Currency Precision Service, See Multicurrency Service

Index
messages Activity File

exception conditions in messages 30-19 description 16-5
participation requirements 30-6 file layout 16-3
process flow Address Verification File
automatic key exchange 30-10 description 16-7, 20-8
on-demand key exchange 30-8 file layout 16-4
related messages 30-6 Advice File
file layout (basic) 16-3
E advice file— BASE I

description 21-10
Exception File
advice file—BASE I
advices 17-5
description 16-8, 21-3, 21-9
discrepancy advice 17-5
advice file—SMS
layout 16-4
updating 16-4
Exception File
F description 16-4, 16-9, 17-4, 21-6
fields discrepancy advice 17-5
Account Verification Service 19-8 to 19-9 layout 16-4
Address Verification Service (AVS) 20-7, 20-33, 20-36 Merchant Central File
Advice Retrieval Service—BASE I 21-11 update messages 18-7
Advice Retrieval Service—SMS 22-13 PIN Verification File
ATM Format Conversion Service 23-12 description 16-12, 32-9
Automatic Cardholder Database Update (Auto-CDB) file layout 16-4
Service 17-8 Portfolio File
Card Verification Value (CVV) Service 24-27, 24-29 description 16-14
Card Verification Value 2 (CVV2) Service 25-20 to 25-21 file layout 16-4
emergency replacement 25-23 risk level file
Cardholder Authentication Verification Value (CAVV) description 35-12
Verification Service 26-15 risk-level file
Custom Payment Service (CPS)/ATM 27-15 description 16-14
Custom Payment Service (CPS)/POS 28-15 Risk-Level File
Deferred Clearing Advice File (DCAF) Service 29-11 file layout 16-4
Dynamic Key Exchange (DKE) Service 30-20, 30-22 floor limit 19-4
Merchant Central File Service (MCFS) 18-25, 18-27
Multicurrency Service 31-63, 31-66 G
PIN Verification Service (PVS) 32-21, 32-26 GCAS, See Global Customer Assistance Services (GCAS)
POS Check Service 33-15, 33-19 Global Customer Assistance Services (GCAS) 16-12
Positive Authorization Capacity Management (PACM)
Service 34-11
Positive Cardholder Authorization Service (PCAS) 35-14 I
Preauthorized Payment Cancellation Service (PPCS) 36-7 iCVV, See Integrated Chip Card card verification value (iCVV)
Status Check Service 37-8 individual limits 35-12
VisaNet Cashback Service 38-11 Integrated Chip Card card verification value (iCVV) 24-4
files issuer limits 34-11, 35-6
activity file

Index
K Card Verification Value 2 (CVV2) Service 25-18

Deferred Clearing Advice File (DCAF) Service 29-10
key fields, See fields
Dynamic Key Exchange (DKE) Service 30-12, 30-15
Merchant Central File Service (MCFS) 18-25
L Multicurrency Service
life-cycle control BASE I POS ATM 31-31
Custom Payment Service (CPS)/POS 28-9 SMS POS 31-33
limits SMS Visa/Plus ATM 31-40
activity 35-7 PIN Verification Service (PVS) 32-20
issuer available and unavailable 35-7 Status Check Service 37-7
advice 35-10 messages
individual 35-12 Card Verification Value 2 (CVV2) Service 25-9
issuer 34-11, 35-6 Multicurrency Service 31-7
mandatory minimum (MM) 35-9 clearing and settlement currency conversion 31-6
Currency Precision Service 31-4, 31-6, 31-28
M Currency Rate Delivery Service 31-4, 31-10

mandatory minimum (MM) limits 35-9 decimal positions indicator
MasterCard acquirer 31-6
updating merchant ID 18-19 one-position adjustment 31-29
MCFS, See Merchant Central File Service (MCFS) two-position adjustment 31-29
merchant category groups 35-6 eligibility 31-3
Merchant Central File fields 31-63, 31-66
update messages 18-7 messages
updating 18-15 message flows 31-30, 31-59
Merchant Central File Service (MCFS) related messages 31-7
eligibility 18-3 participation requirements 31-4
fields 18-25, 18-27 processing
message flow 18-25 for non-participants 31-10
messages service monitoring 31-5
related messages 18-6 transaction currency 31-4
participation requirements 18-5 Multiple-Stations-per-PCR 21-9
process flow 18-22
Merchant Fraud Performance Program 21-4, 22-5
message P
advice message creation PACM, See Positive Authorization Capacity Management (PACM)
BASE I 21-7 Service
Single Message System (SMS) 22-8 parameters
processing modes CVV 24-15
BASE I 21-7 Positive Cardholder Authorization Service (PCAS) 34-4, 35-4
Single Message System (SMS) 22-9 advice limit 35-10
message flow authorization 35-12
Account Verification Service 19-6 merchant category groups 35-6
Address Verification Service (AVS) 20-24, 20-33 risk level file 35-13
Advice Retrieval Service—BASE I 21-11 participation requirements
Advice Retrieval Service—SMS 22-12 Account Verification Service 19-4
ATM Format Conversion Service 23-10, 23-12 Address Verification Service (AVS) 20-5
Automatic Cardholder Database Update (Auto-CDB) Advice Retrieval Service—BASE I 21-4
Service 17-7 Advice Retrieval Service—SMS 22-4

Index
ATM Format Conversion Service 23-5 file layout 16-4

Automatic Cardholder Database Update (Auto-CDB) POS Check Service
Service 17-4 eligibility 33-3
Card Verification Value (CVV) Service 24-8, 24-18 fields 33-15, 33-19
Cardholder Authentication Verification Value (CAVV) messages
Verification Service 26-5 related messages 33-8
Custom Payment Service (CPS)/ATM 27-6 MICR line 33-13
Custom Payment Service (CPS)/POS 28-6 participation requirements 33-5
Deferred Clearing Advice File (DCAF) Service 29-5 process flow
Dynamic Key Exchange (DKE) Service 30-6 authorization 33-9
Merchant Central File Service (MCFS) 18-5 settlement 33-11
Multicurrency Service 31-4 roles of participants 33-5
PIN Verification Service (PVS) 32-6 service options 33-4
POS Check Service 33-5 Positive Authorization Capacity Management (PACM) Service
Positive Authorization Capacity Management (PACM) diversion tables
Service 34-4 BASE I 34-8
Positive Cardholder Authorization Service (PCAS) 35-4 Single Message System (SMS) 34-10
Preauthorized Payment Cancellation Service (PPCS) 36-4 eligibility 34-3
Status Check Service 37-4 fields 34-11
VisaNet Cashback Service 38-5 issuer limits 34-11
pick-up action codes 17-6 messages 34-6
PIN (personal identification number) participation requirements 34-4
data on magnetic stripe 32-12 process flow 34-6
encryption Positive Cardholder Authorization Service (PCAS)
calculating 32-6 activity checking and accumulation 35-11
zone 32-15 activity limits 35-7
entry 32-4 issuer available and unavailable 35-7
options for verifying 32-5 advice limit 35-10
verification methods cardholder risk levels and individual limits 35-12
IBM PIN Offset 32-10, 32-14 eligibility 35-3
PIN Verification Value (PVV) 32-8, 32-13 fields 35-14
PIN Verification File issuer limits 35-6
description 16-12, 32-9 key terms 35-4
file layout 16-4 mandatory minimum (MM) limits 35-9
PIN Verification Key Index (PVKI) 32-8 merchant category groups 35-6
PIN Verification Service (PVS) messages 35-5
eligibility 32-4 parameters 34-4
fields 32-21, 32-26 participation requirements 35-4
IBM PIN Offset method 32-10, 32-14 random selection factors 35-13
messages Preauthorized Payment Cancellation Service (PPCS)
message flow 32-20 eligibility 36-4
related messages 32-13 fields 36-7
participation requirements 32-6 messages
process flow 32-18 related messages 36-5
verification methods participation requirements 36-4
PIN Verification Value (PVV) 32-8, 32-13 process flow
Portfolio File Account Verification Service 19-6
description 16-14

Index
Address Verification Service (AVS) risk level file

basic 20-9 to 20-10 description 35-12
variations 20-22 to 20-23 risk levels, cardholder 35-12
Advice Retrieval Service—BASE I risk-level file
offline through BASE II 21-4 description 16-14
online through V.I.P. 21-7, 21-9 Risk-Level File
Advice Retrieval Service—SMS 22-9 file layout 16-4
ATM Format Conversion Service 23-8
Service 17-6
S
service monitoring
Card Verification Value 2 (CVV2) Service 25-18
Account Verification Service 19-4
Custom Payment Service (CPS)/ATM 27-8
Address Verification Service (AVS) 20-5
Advice Retrieval Service—BASE I 21-5
Advice Retrieval Service—SMS 22-5
Merchant Central File Service (MCFS) 18-22
ATM Format Conversion Service 23-5
PIN Verification Service (PVS) 32-18
POS Check Service 33-9, 33-13
Service 17-4
Card Verification Value (CVV) Service 24-12
Service 34-6
Card Verification Value 2 (CVV2) Service 25-7
Status Check Service 37-6
Cardholder Authentication Verification Value (CAVV)
Visa Token Service 39-6
Verification Service 26-7
processing
Custom Payment Service (CPS)/ATM 27-7
advice recovery
during and after VIC switchover (BASE I) 21-10
Dynamic Key Exchange (DKE) Service 30-6
during and after VIC switchover (SMS) 22-12
Multicurrency Service 31-5
modes
PIN Verification Service (PVS) 32-7
Advice Retrieval Service—BASE I 21-7
POS Check Service 33-6
Advice Retrieval Service—SMS 22-9
Multicurrency Service
Service 34-5
for non-participants 31-10
Preauthorized Payment Cancellation Service (PPCS) 36-5
transaction currency 31-4
Status Check Service 37-4
parameters
Visa Token Service 39-5
CVV 24-15
VisaNet Cashback Service 38-5
Positive Cardholder Authorization Service (PCAS) 34-4,
services
35-4, 35-6
PVKI, See PIN Verification Key Index (PVKI)
Service 22-5
PVS, See PIN Verification Service (PVS)
Cardholder Authentication Verification Value (CAVV)
PVV, See PIN Verification Value (PVV)
Verification Service 26-3
Merchant Fraud Performance Program 21-4, 22-5
R SMS, See Single Message System (SMS)
random selection factors 35-13 SMS. See Single Message System (SMS) 36-4
regions stand-in processing (STIP)
Positive Authorization Capacity Management (PACM) Service through V.I.P. 34-7, 34-10
BASE I diversion tables 34-8 to 34-9 Status Check Service
Single Message System (SMS) diversion tables 34-9 to eligibility 37-4
34-10 fields 37-8
related messages
Dynamic Key Exchange (DKE) Service 30-6

Index
messages
message flow 37-7
process flow 37-6
STIP, See stand-in processing (STIP)
system parameters, See processing, parameters
U
updating
Merchant Central File 18-15
V
validation code
Visa Token Service
eligibility 39-3
process flow 39-6
VisaNet Cashback Service
eligibility 38-4
fields 38-11
messages

Vip System Services Volume 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vip System Services Volume 2

Uploaded by

Copyright:

Available Formats

V.I.P.

System Services, Volume 2

Visa Supplemental Requirements

© 1999 - 2016 Visa. All Rights Reserved. 0853B–28

Visa and other trademarks are trademarks or registered trademarks of Visa.

About Visa Supplemental Documents

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL

About This Manual............................................................................................1

System Documentation Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

System Information Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

How To Use This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Obtaining Report Samples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Part 6 • Authorization Database Files and Services

16.2 Database Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3

16.3 File Record Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4

16.4 File Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5

16.4.1 Related Services Listings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5

16.5 Activity File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5

16.5.1 Merchant Group Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6

16.5.2 PIN-Entry Attempt Activity Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7

16.6 Address Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-7

1 June 2016 Visa Confidential V.I.P. System Services, Volume 2 i

16.7 Advice File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8

16.8 Card-Level Product ID File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8

16.9 Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9

16.9.1 Visa International Exception File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-9

16.9.2 Online Exception File Editing Summary (0302 Messages). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-11

16.9.3 Exception File Purge Date Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12

16.9.4 Global Customer Assistance Services (GCAS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12

16.10 PIN Verification File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12

16.11 Portfolio File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14

16.12 Risk-Level File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14

16.13 For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-15

Chapter 17 • Automatic Cardholder Database Update (Auto-CDB) Service

17.2 Eligible Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3

17.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3

17.4 Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4

17.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4

17.4.2 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4

17.5 Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-4

17.6.1 Advice Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5

17.6.1.1 Exception File Update Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5

17.6.1.2 Exception File Discrepancy Advices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5

17.7 Process Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-5

17.7.1 Auto-CDB Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-6

17.8 Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7

17.8.1 Auto-CDB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-7

17.9 Key Fields Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8

17.10 For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-9

ii Visa Confidential V.I.P. System Services, Volume 2 1 June 2016

Chapter 18 • Merchant Central File Service (MCFS)

18.2 Eligible Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-3

18.3 Service Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-4

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 Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-5

18.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6

18.4.2 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6

18.4.3 File Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6

18.5 Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6

18.5.1 MCFS-Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6