Visa Direct Original Credit Transaction PDF

Visa Direct Original Credit Transaction
(OCT) – Global Implementation Guide

Visa Supplemental Requirements
Version 2.5
April 2019
Visa Confidential
Important Information on Confidentiality and Copyright
© 2013–2019 Visa. All Rights Reserved.
Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants
for use exclusively in managing their Visa programs. It must not be duplicated, published, distributed
or disclosed, in whole or in part, to any other person without prior written permission from Visa.
The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively
the “Trademarks”) are Trademarks owned by Visa. All other trademarks not attributed to Visa are the
property of their respective owners.
Note: 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.
Disclaimers:
The Original Credit Transaction (OCT) is a VisaNet transaction that Visa clients and program
participants can use to send funds to an eligible Visa account. For purposes of this document, Visa
clients and participants may include merchants, issuers, acquirers, service providers, payment
facilitators, and/or third party agents. “Visa Direct” is the product platform for the funds transfer
services enabled by the OCT, (e.g., Money Transfer, Funds Disbursement, prepaid load, and credit card
bill pay). Any references to “Visa Direct” in this and other documents and materials refer to the OCT
transactions described in this guide.
The Visa client and program participant must ensure that all necessary licenses, registrations,
notifications, authorizations, and approvals necessary to engage in an OCT-based program are
obtained from the competent authorities in the client‘s local jurisdiction. This Visa Direct Original
Credit Transaction (OCT) - Global Implementation Guide is strictly for information purposes only and is
not an approval to commercially launch a Visa Direct or related program that uses the OCT.
Visa may at any time change or remove any of the attributes, requirements, and functional
specifications related to the OCT and the Visa Direct or related program, or withdraw the Visa Direct
program entirely. Changes and enhancements are made continuously and are communicated to
clients through periodic Visa communications and as updates to this Visa Direct Original Credit
Transaction - Global Implementation Guide and other related documents.
Contents
Visa Direct Original Credit Transaction (OCT) Global Implementation Guide: Visa Supplemental Requirements
Contents
Tables ...............................................................................................................................................................................ix
Figures .............................................................................................................................................................................xi
About This Guide ......................................................................................................................................................... 13
Audience ..................................................................................................................................................................................... 13
Scope ......................................................................................................................................................................................... 13
Acquirers, Merchants, and Service Providers............................................................................................................. 14
Recipient Issuers ................................................................................................................................................................... 14
Document Organization ....................................................................................................................................................... 14
Summary of Changes in this Version............................................................................................................................... 16
Related Publications and URLs .......................................................................................................................................... 18
Global Technical Letters (Business Enhancement Release (BER)) ...................................................................... 19
Visa Direct Regional Mailboxes ......................................................................................................................................... 19
1 Original Credit Transactions (OCT) Overview............................................................................................... 21
1.1 What is an OCT? ........................................................................................................................................................ 22
1.1.1 Identifying Domestic and Cross-border OCT Transactions................................................................... 24
1.1.2 OCT Message Formats ........................................................................................................................................ 25
1.1.3 Fast Funds ................................................................................................................................................................ 27
1.2 How it Works .............................................................................................................................................................. 27
1.2.1 Benefits ..................................................................................................................................................................... 30
2 Origination Requirements and Considerations .......................................................................................... 33
2.1 General Origination Program Considerations................................................................................................ 33
2.2 Program Approval, Licensing, Registration, and Forms ............................................................................. 36
2.2.1 Visa Direct Program Approval .......................................................................................................................... 36
2.2.2 Licensing and Registration ................................................................................................................................ 37
2.2.3 Third-Party Agent Registration ........................................................................................................................ 37
2.2.4 Forms ......................................................................................................................................................................... 38
2.3 Acquirers, Service Providers and Merchants – OCT Transaction Processing and Message
Formats ......................................................................................................................................................................... 39
16 May 2019 Visa Confidential i

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants for use exclusively in managing their Visa programs. It must
not be duplicated, published, distributed or disclosed, in whole or in part, to merchants, cardholders or any other person without prior written permission from Visa.
Contents
2.3.1 Transaction Processing and Message Format ............................................................................................ 40

2.3.2 BIN Requirements and Best Practices ........................................................................................................... 44
2.3.3 Push Payments Tokenization ............................................................................................................................ 44
2.3.4 Network Routing Options .................................................................................................................................. 45
2.3.4.1 VisaNet Connectivity Using ISO Messaging ............................................................................................... 45
2.3.4.2 Application Programming Interfaces (APIs) ................................................................................................ 45
2.3.4.2.1 API Terms of Use............................................................................................................................................ 46
2.3.4.3 Push Payment Gateway Service (PPGS): (U.S. Only) ................................................................................. 47
2.3.4.4 Network Routing Alternative: (U.S. Only) ..................................................................................................... 47
2.3.4.5 Proprietary ATM Card – PLUS Symbol/Network 4.................................................................................... 47
2.3.5 Business Application Identifier (BAI), Merchant Category Code (MCC) and Use Cases ............. 47
2.3.5.1 P2P Digital Payment Platforms (DPP) Framework .................................................................................... 52
2.3.5.2 Use Cases ................................................................................................................................................................. 54
2.3.5.2.1 Bank Initiated P2P Money Transfer ......................................................................................................... 54
2.3.5.2.2 Merchant Processing – Sales Tax Reclaim ............................................................................................ 55
2.3.5.2.3 Alternative/Online Lending ........................................................................................................................ 55
2.3.5.2.4 Earned Wage Access (U.S. only): .............................................................................................................. 56
2.3.5.2.5 Gambling and Gaming Program Overview .......................................................................................... 56
2.3.6 Card Acceptor Identification Code (CAID) ................................................................................................... 57
2.3.7 Perform Recipient Account Checks Including Fast Funds Status ........................................................ 58
2.3.8 Reversals and Disputes ....................................................................................................................................... 58
2.3.9 Settlement................................................................................................................................................................ 59
2.3.10 VisaNet Host Testing ........................................................................................................................................... 59
2.4 Acquirers, Service Providers and Merchants – General Systems Changes.......................................... 59
2.4.1 Customer Access Channels................................................................................................................................ 60
2.4.2 Consumer Data Collection and Sender Authentication.......................................................................... 60
2.4.3 Transaction Screening ......................................................................................................................................... 61
2.4.4 Confirmation of Funds Transfer ....................................................................................................................... 62
2.4.5 Transaction Receipt and Notifications .......................................................................................................... 62
2.4.6 Currency Conversion............................................................................................................................................ 63
ii Visa Confidential 16 May 2019

Contents
2.4.7 Recipient Registry and Recurring Transactions ......................................................................................... 64

2.5 Acquirers, Service Providers, and Merchants – Customer Considerations.......................................... 64
2.5.1 Providing Description of Fees (Mandatory) ................................................................................................ 64
2.5.2 Developing Terms and Conditions (T&Cs) .................................................................................................. 65
2.6 Acquirers, Service Providers, and Merchants – Risk Management Considerations ......................... 66
2.6.1 Fraud Detection and Prevention ..................................................................................................................... 67
2.6.1.1 Data Security – PCI Compliance ...................................................................................................................... 68
2.6.1.2 Transaction Identification and Tracking ....................................................................................................... 68
2.6.1.3 User Interface Controls ....................................................................................................................................... 68
2.6.2 Transaction Limits ................................................................................................................................................. 69
2.6.3 Transaction Monitoring and Controls ........................................................................................................... 70
2.6.3.1 Acquirer Velocity Controls ................................................................................................................................. 71
2.6.4 Watch List Screening ........................................................................................................................................... 71
2.6.4.1 International and Country-Specific Regulatory Restrictions................................................................. 72
2.6.4.2 Government or Bank-Specific Lists................................................................................................................. 72
2.7 Acquirers and Merchants – SMS Reconciliation............................................................................................ 72
2.8 Acquirer– Reports ..................................................................................................................................................... 73
2.8.1 Report Delivery Mechanisms ............................................................................................................................ 74
2.8.1.1 Acquirer Reports via Visa Online ..................................................................................................................... 74
2.8.1.2 Visa File Exchange Service (VFES) ................................................................................................................... 75
2.8.2 Visa Direct Transaction Reconciliation Report (TRR) ............................................................................... 75
2.9 Acquirers, Service Providers, and Merchants – Training and Customer Service ............................... 76
3 Recipient Issuer Requirements and Considerations .................................................................................. 77
3.1 Recipient Issuers – General Program Considerations ................................................................................. 77
3.1.1 General Visa Compliance ................................................................................................................................... 77
3.1.1.1 Working with Third-Party Agents ................................................................................................................... 78
3.2 Recipient Issuers – Requirements for Receiving and Processing OCTs................................................ 79
3.2.1 Receiving and Processing OCTs ...................................................................................................................... 79
3.2.2 Optional Issuer Fee (OIF) Processing ............................................................................................................. 80
3.3 Recipient Issuers – Applying OCTs to Visa Account Types ....................................................................... 80
16 May 2019 Visa Confidential iii

Contents
3.3.1 Special considerations for Credit Cards........................................................................................................ 81

3.4 Recipient Issuers – OCT Enhanced Data Element Requirements ............................................................ 82
3.5 Recipient Issuer OCT Authorization Decisions – Declining OCTs ........................................................... 87
3.6 Recipient Issuer OCT Authorization Decisions – Approving OCTs......................................................... 87
3.6.1 Issuer Option for Receiving/Approving Inbound Cross-Border Enhanced Original Credit
Transactions (OCTs) ..................................................................................................................................................... 87
3.7 Recipient Issuers – VisaNet Stand-in Processing (STIP) ............................................................................. 88
3.8 Recipient Issuer Host System Testing ............................................................................................................... 88
3.9 Recipient Issuers – Best Practices for Effective OCT Processing ............................................................. 89
3.10 Recipient Issuers – Funds Availability ................................................................................................................ 89
3.10.1 Funds Availability Overview .............................................................................................................................. 90
3.10.2 Fast Funds vs. Conventional Funds ................................................................................................................ 90
3.10.3 Conventional Funds Availability ...................................................................................................................... 92
3.10.4 Fast Funds ................................................................................................................................................................ 92
3.10.4.1 Fast Funds Enablement and Mandates ..................................................................................................... 92
3.10.4.2 Fast Funds Reconciliation – BASE I/Base II/Dual Message (Recipient Issuers) ........................... 94
3.10.4.3 Additional Guidance to Achieving Fast Funds Processing Capabilities (Recipient Issuers) .. 95
3.10.4.4 VisaNet Set Up for Fast Funds – Client Information Questionnaire (CIQ) ................................... 97
3.10.4.5 Fast Funds Testing Requirements ............................................................................................................... 97
3.10.4.6 Fast Funds Modifying Fraud Monitoring Systems ................................................................................ 98
3.10.4.7 Fast Funds Interchange Rates ....................................................................................................................... 98
3.10.4.8 Fast Funds Customer Service and Exception Management .............................................................. 98
3.11 Recipient Issuers – Back Office Activities ......................................................................................................... 98
3.12 Recipient Issuers - Risk Management ............................................................................................................... 98
3.12.1 Risk Controls ........................................................................................................................................................... 98
3.12.2 Data Elements in Identifying OCTs ................................................................................................................. 99
3.12.3 Using Visa Velocity Limit Checking to Mitigate Risk ............................................................................... 99
3.12.3.1 VisaNet Maximum Velocity Limits ........................................................................................................... 100
3.12.3.2 VisaNet Minimum Velocity Limits ............................................................................................................ 101
3.12.3.3 Velocity Limits Exceeded - Processing Options .................................................................................. 101
iv Visa Confidential 16 May 2019

Contents
3.12.3.3.1 Option 1: VisaNet Forwards OCT to Recipient Issuer with Information about Exceeded
Velocity Limit ................................................................................................................................................ 102
3.12.3.3.2 Option 2: VisaNet Declines OCT and Optionally Sends Stand-in Advice with Information
about Exceeded Velocity Limit .............................................................................................................. 102
3.12.4 Transaction Monitoring ................................................................................................................................... 104
3.12.5 Watch List Screening Service ......................................................................................................................... 104
3.12.5.1 Watch List Screening Service Overview ................................................................................................. 104
3.12.5.2 Watch List Screening Transaction Flow.................................................................................................. 105
3.12.5.3 Watch List Scoring Methodology............................................................................................................. 105
3.13 Recipient Issuers - Customer Considerations ............................................................................................. 105
3.13.1 Customer Service Inquiries and Exceptions ............................................................................................. 106
3.13.2 Customer Statements – Identifying Transactions .................................................................................. 106
3.13.3 Customer Statements – Funds Availability ............................................................................................... 106
3.13.4 Customer Notifications .................................................................................................................................... 107
3.14 Recipient Issuers - Reports ................................................................................................................................. 107
4 Bank Identification Number (BIN) Blocking .............................................................................................. 108
4.1 Blocking by Country.............................................................................................................................................. 108
4.1.1 International and Country-Specific Regulatory Restrictions.............................................................. 108
4.1.2 BINs Blocked by Country................................................................................................................................. 108
4.2 Additional Restrictions ......................................................................................................................................... 110
4.2.1 Issuer Blocking and Regulatory Compliance ........................................................................................... 110
4.2.2 Prepaid Restrictions........................................................................................................................................... 110
5 Exception Processing ........................................................................................................................................ 112
5.1 Acquirers, Service Providers, and Merchants: Reversals and Adjustments ...................................... 112
5.1.1 Reversals ................................................................................................................................................................ 112
5.1.2 Good Faith Adjustments.................................................................................................................................. 113
5.1.3 Prepaid Load OCT Reversals – LAC Region .............................................................................................. 114
5.2 Exception Scenarios for Fast Funds................................................................................................................. 114
5.3 Issuers – Disputes .................................................................................................................................................. 116
5.4 Acquirers, Service Providers, Merchants, and Issuers – Dispute Considerations ........................... 117
5.5 Non/Late Posting Process .................................................................................................................................. 122
16 May 2019 Visa Confidential v

Contents
5.5.1 Process for Complaints Related to Non-Posting of Funds................................................................. 122

6 Visa Direct Risk Management Framework ................................................................................................. 124
6.1 Visa’s Obligations as an “Operator of a Credit Card System” ............................................................... 124
6.2 Visa Client Licensing Process ............................................................................................................................. 124
6.3 Visa Direct Program Diligence and Approval .............................................................................................. 125
6.4 Key Controls ............................................................................................................................................................. 125
6.5 Watch List Screening ............................................................................................................................................ 126
7 Regulatory Compliance and Legal Considerations .................................................................................. 128
7.1 Regulatory Compliance ....................................................................................................................................... 128
7.2 Key Standards and Legislation .......................................................................................................................... 129
A Enhanced Original Credit Transaction (OCT) Data Elements and Processing Rules ....................... 132
A.1 Source of Funds (Field 104, Dataset ID 5F, Tag 08) .................................................................................. 167
A.2 High-Level Summary – Enhanced OCT Processing Rules by Business Application Identifier (BAI)
...................................................................................................................................................................................... 169
A.3 V.I.P., BASE II, and Edit Package Decline Response and Reject Reason Codes............................... 173
B Sample Reports ................................................................................................................................................. 178
B.1 VSS Sample Reports.............................................................................................................................................. 178
B.2 SMS Sample Report .............................................................................................................................................. 188
B.3 Visa Direct Transaction Reconciliation Report (TRR) (U.S. Only) .......................................................... 190
C API Formats ........................................................................................................................................................ 192
D Visa Direct Account Lookup File ................................................................................................................... 198
D.1 Visa Direct Account Lookup File Data Elements ........................................................................................ 198
D.2 Table Creation SQL................................................................................................................................................ 201
D.3 Primary Account Number Retrieval SQL ....................................................................................................... 201
D.4 Interpreting Visa Direct Account Lookup File Data................................................................................... 202
E Transaction Flows ............................................................................................................................................. 206
E.1 SMS Merchant to SMS Recipient Issuer—Approval ................................................................................. 207
E.2 SMS Merchant to BASE I/BASE II Recipient Issuer—Approval.............................................................. 208
E.3 SMS Merchant to SMS Recipient Issuer – Decline .................................................................................... 209
E.4 SMS Merchant to BASE I/BASE II Recipient Issuer – Decline ................................................................. 210
E.5 SMS Merchant to SMS Recipient Issuer – Merchant Becomes Unavailable .................................... 211
vi Visa Confidential 16 May 2019

Contents
E.6 SMS Merchant to BASE I/BASE II Recipient Issuer – Merchant Unavailable .................................... 212
E.7 SMS Merchant to SMS Issuer—Recipient Issuer Unavailable ............................................................... 213
E.8 SMS Merchant to BASE I/BASE II Recipient Issuer – Recipient Issuer Unavailable ....................... 214
E.9 SMS Merchant to SMS or BASE I/BASE II Recipient Issuer – Velocity Limits Exceeded and Issuer
Opts for VisaNet to Decline OCT on their Behalf ...................................................................................... 215
E.10 SMS Merchant to SMS Recipient Issuer—Issuer Response Delay....................................................... 216
E.11 SMS Merchant to BASE I/BASE II Recipient Issuer – Recipient Issuer Response Delay ............... 217
E.12 SMS/Dual Message Recipient Issuer Charges Back OCT ........................................................................ 218
E.13 SMS Merchant to BASE II (TC06 Only) ........................................................................................................... 219
E.14 BASE II (TC06 Only) Merchant to SMS Recipient Issuer – Approval ................................................... 220
E.15 BASE II (TC06 Only) Merchant to BASE I/BASE II Recipient Issuer – Approval ............................... 221
E.16 BASE II (TC06 Only) Merchant to BASE II (TC06 Only) Recipient Issuer ............................................ 222
F Enhanced TC06 OCTs ....................................................................................................................................... 224
F.1 Processing Rules..................................................................................................................................................... 224
F.1.1 Merchants ............................................................................................................................................................. 224
F.2 Data Elements ......................................................................................................................................................... 224
F.3 Reversals.................................................................................................................................................................... 228
F.4 Disputes ..................................................................................................................................................................... 228
F.5 Edit Package and BASE II Edits.......................................................................................................................... 228
F.6 Blocking ..................................................................................................................................................................... 229
F.7 Funds Availability ................................................................................................................................................... 229
F.8 Online Gambling OCTs ........................................................................................................................................ 230
F.9 Adjustments ............................................................................................................................................................. 230
F.10 Edit Package and BASE II Edits.......................................................................................................................... 230
F.11 Blocking ..................................................................................................................................................................... 231
F.12 Online Gambling OCTs ........................................................................................................................................ 231
G U.S. OCT Switch Service .................................................................................................................................. 232
H CEMEA-Specific Requirements for Money Transfer ................................................................................ 234
H.1 License Requirements for Visa Direct in CEMEA ........................................................................................ 234
H.2 CEMEA Merchant Requirements ...................................................................................................................... 234
H.2.1 Fast Funds ............................................................................................................................................................. 235
16 May 2019 Visa Confidential vii

Contents
H.2.2 Payment Methods and Access Channels .................................................................................................. 235

H.2.3 CEMEA Money Transfer OCT Service Options ........................................................................................ 235
H.3 CEMEA Implementation Requirements ......................................................................................................... 236
H.3.1 CEMEA Money Transfer Implementation Requirements..................................................................... 236
H.3.2 Card-to-Card Money Transfer OCT Requirements (AFT and OCTs) ............................................... 236
H.3.3 Cash-to-Card Money Transfer OCT Requirements (OCT Only) ........................................................ 237
H.3.4 Cash-to-Card at ATM/Kiosk Money Transfer (OCT Only) ................................................................... 238
H.3.5 Cash-to-Card at ATM Money Transfer OCT Requirements for Third Party ................................. 239
H.3.6 AFT-Based Card-to-Card Money Transfer OCT Implementation Requirements........................ 240
H.3.7 Transaction Coding and Testing at SMS Host ........................................................................................ 241
H.3.8 Reporting and Reconciliation ........................................................................................................................ 242
H.3.9 Merchant ............................................................................................................................................................... 242
I Acronyms and Glossary...................................................................................................................................244
I.1 Acronyms .................................................................................................................................................................. 244
I.2 Glossary ..................................................................................................................................................................... 246
viii Visa Confidential 16 May 2019

Tables
Tables
Table 1-1: Document Organization.................................................................................................................................... 14

Table 1-2: Summary of Changes ......................................................................................................................................... 16
Table 1-1: Visa Account Types for OCT ............................................................................................................................ 22
Table 1-2: OCT Services .......................................................................................................................................................... 24
Table 1-3: Domestic vs. Cross-border Definition .......................................................................................................... 24
Table 2-1: Forms........................................................................................................................................................................ 38
Table 2-2: High-Level Overview of Key OCT Data Elements for Acquirers, Service Providers and
Merchants ............................................................................................................................................................... 41
Table 2-3: Visa Developer Platform (VDP) APIs ............................................................................................................. 46
Table 2-4: BAI and MCC Usage............................................................................................................................................ 48
Table 2-5: BAI and MCC usage for P2P Digital Wallet Programs ........................................................................... 53
Table 2-6: Gambling Merchants Onboarding Requirements ................................................................................... 57
Table 2-7: Terms and Conditions Considerations ........................................................................................................ 65
Table 2-8: Transaction Limits - Velocity Limits .............................................................................................................. 70
Table 3-1: Recipient Issuer Forms ....................................................................................................................................... 78
Table 3-2: Visa Account Types ............................................................................................................................................. 80
Table 3-3: Key Enhanced OCT Data Elements ................................................................................................................ 82
Table 3-4: Fast Funds vs. Conventional Funds ............................................................................................................... 91
Table 3-5: Country-specific Rules ....................................................................................................................................... 93
Table 3-6: Mandated Fast Funds Locations .................................................................................................................... 94
Table 3-7: VisaNet Maximum Velocity Limits.............................................................................................................. 101
Table 3-8: VisaNet Minimum Velocity Limits .............................................................................................................. 101
Table 4-1: BIN Blocking By Country ................................................................................................................................ 108
Table 5-1: Fast Funds Exception Scenarios .................................................................................................................. 115
Table 5-2: OCT Dispute Reason Codes .......................................................................................................................... 116
Table 5-3: Dispute Scenario Examples ........................................................................................................................... 118
Table 6-1: Key Controls for Managing Risk ................................................................................................................. 125
16 May 2019 Visa Confidential ix

Tables
Table A-1: Enhanced OCT Data Elements ..................................................................................................................... 133

Table A-2: Source of Funds................................................................................................................................................. 168
Table A-3: High-Level Summary – Enhanced OCT Processing Rules by BAI ................................................... 169
Table A-4: V.I.P. Decline Response Codes ..................................................................................................................... 173
Table A-5: Other BASE II Return Reason Codes and Edit Package Reject Reason Codes........................... 176
Table C-6: API tags – ISO Fields Mapping .................................................................................................................... 194
Table D-7: Visa Direct Account Lookup File Data Elements ................................................................................... 198
Table D-8: Interpreting Visa Direct Account Lookup File Data ............................................................................. 202
Table E-9: Transaction Flows ............................................................................................................................................. 206
Table F-10: Enhanced TC06 OCT Data Elements......................................................................................................... 224
Table H-11: CEMEA Money Transfer OCT Service Options ....................................................................................... 235
Table H-12: CEMEA Card-to-Card Money Transfer OCT Requirements (AFT and OCT) ................................ 236
Table H-13: CEMEA Cash-to-Card Money Transfer OCT Requirements (OCT Only) ....................................... 237
Table H-14: CEMEA Cash-to-Card at ATM Money Transfer OCT Requirements (OCT Only) ....................... 238
Table H-15: CEMEA Card-to-Card Money Transfer OCT Requirements .............................................................. 240
Table H-16: Other BASE II Return Reason Codes and Edit Package Reject Reason Codes........................... 243
Table I-17: Acronyms ............................................................................................................................................................. 244
x Visa Confidential 16 May 2019

Figures
Figures
Figure 1-1: Visa Direct Process Flow ................................................................................................................................... 28

Figure 1-2: Example Card-to-Card P2P Money Transfer Process Flow .................................................................. 29
Figure 1-3: Example of Funds Disbursement/Non-Money Transfer Process Flow ............................................ 30
Figure 3-1: Velocity Limit Exceeded Processing Flow ................................................................................................ 103
Figure 6-1: Visa Direct Key Controls Overview .............................................................................................................. 126
Figure B-1: VSS-110 Sample Report ................................................................................................................................. 179
Figure B-2: VSS-120 Sample Report (Acquirer) ............................................................................................................ 180
Figure B-5: VSS-300 Sample Report (Acquirer) ............................................................................................................. 183
Figure B-6: VSS-120 Sample Report (Issuer) ................................................................................................................. 184
Figure B-9: SMS 600C Report.............................................................................................................................................. 188
Figure B-10: Transaction Reconciliation Report .......................................................................................................... 191
Figure E-11: SMS Merchant to SMS Recipient Issuer—Approval......................................................................... 207
Figure E-12: SMS Merchant to BASE I/BASE II Recipient Issuer ............................................................................ 208
Figure E-13: SMS Merchant SMS Recipient Issuer—Decline ................................................................................. 209
Figure E-14: SMS Merchant to BASE I/BASE II Recipient Issuer—Decline ........................................................ 210
Figure E-15: SMS Merchant to SMS Recipient Issuer—Merchant Becomes Unavailable ........................... 211
Figure E-16: SMS Merchant to BASE I/BASE II Recipient Issuer—Merchant Unavailable ........................... 212
Figure E-17: SMS Merchant to SMS Recipient Issuer—Decline ............................................................................ 213
Figure E-18: SMS Merchant to BASE I/BASE II Recipient Issuer – Unavailable................................................ 214
Figure E-19: SMS Merchant to SMS or BASE I/BASE II Recipient Issuer—Velocity Limits Exceeded and
Recipient Issuer Opts for VisaNet to Decline OCT on their Behalf ................................................ 215
Figure E-20: SMS Merchant to SMS Recipient Issuer—Recipient Issuer Response Delay .......................... 216
Figure E-21: SMS Merchant to BASE I/BASE II Recipient Issuer—Recipient Issuer Response Delay ...... 217
16 May 2019 Visa Confidential xi

Figure E-22: SMS/Dual Message Issuers Charges Back OCT ................................................................................. 218
Figure E-23: SMS Merchant to BASE II (TC-06 Only)................................................................................................. 219
Figure E-24: BASE II (TC06 Only) Merchant to SMS Recipient Issuer—Approval........................................... 220
Figure E-25: BASE II (TC06 Only) Merchant to BASE I/BASE II Recipient Issuer – Approval ....................... 221
Figure E-26: BASE II (TC06 Only) Merchant to BASE II (TC06 Only) Recipient Issuer.................................... 222
xii Visa Confidential 16 May 2019

About This Guide
About This Guide

The Original Credit Transaction (OCT) is a VisaNet transaction that can be used to send funds to an
eligible Visa account. Visa acquirers, service providers and merchants can use the OCT to enable Visa
Direct services such as Money Transfers, Funds Disbursement, prepaid loads, and credit card bill
payments.
This document provides:
 An overview of the OCT
 OCT implementation requirements and considerations for acquirers, service providers, merchants,
and issuers
 OCT implementation requirements and considerations for recipient issuers
 Data element requirements for each type of OCT
Note: “Visa Direct” is the brand name for the funds transfer services enabled by the OCT described in
this guide. Any and all references to “Visa Direct” in this and other documents and materials
refer to the OCT transactions described in this guide. Additionally, to make this distinction
clear, the name of the document has been changed to Visa Direct Original Credit Transaction
(OCT): Global Implementation Guide from Visa Original Credit Transaction (OCT): Global
Implementation Guide.
Audience
This document is intended for use by Visa financial institutions and financial institution partners
involved with establishing a Visa Direct program.
In this document, entities requesting the initiation of OCTs are now referred to as acquirers,
merchants, or service providers, as applicable, and Visa financial institutions receiving OCTs are
referred to as recipient issuers1.
Scope
This section provides information on the scope of this document.
1 ‘Originator’ is no longer being used as a term/entity; it has been replaced by acquirers, service providers, and/or merchants
throughout the guide, as applicable.
16 May 2019 Visa Confidential 13

About This Guide
Acquirers, Merchants, and Service Providers
This document provides acquirers, merchants and service providers with implementation
requirements, guidelines, and considerations related to OCT origination programs, along with the data
element requirements for OCTs.
Recipient Issuers
This document provides Visa recipient issuers with implementation guidelines to support the receipt
of OCTs. All issuer requirements are gathered in this document giving issuers a single document for all
OCT information.
Document Organization
This document contains the following chapters and appendices:

Table 1-1: Document Organization
Chapter Description Audience
Chapter 1: Original Credit An overview of OCTs. Acquirers,

Transactions Overview Merchants, and
Service Providers
Recipient Issuers
Chapter 2: Origination Provides acquirers, merchants, and service Acquirers,

Requirements and Considerations providers with details of program requirements Merchants, and
and business considerations. Includes general Service Providers
program considerations, customer considerations,
OCT processing requirements, information on
funds availability, and risk management
requirements and guidelines.
Chapter 3: Recipient Issuer Provides recipient issuers with requirements and Recipient Issuers
Requirements and Considerations business considerations for OCT-based programs.
Includes general program considerations,
customer considerations, OCT processing
requirements, information on funds availability,
velocity limits, watch list screening, and other risk
management requirements and guidelines.
Chapter 4: Bank Identification Provides information on BIN blocking. Acquirers,

Number (BIN) Blocking Merchants, and
Service Providers
Recipient Issuers
14 Visa Confidential 16 May 2019

About This Guide
Chapter 5: Exception Processing Provides information on exceptions including Acquirers,

reversals, rejects, adjustments, and disputes. Merchants, and
Service Providers
Recipient Issuers
Chapter 6: Visa Direct Risk Provides information on Visa Direct Program Acquirers,
Management Framework approvals, key controls, licensing process etc. Merchants, and
Service Providers
Recipient Issuers
Chapter 7: Regulatory Compliance Outlines considerations for regulatory compliance Acquirers, Merchants
and Legislation Considerations and provides a list of key standards and legislation and Service
that merchants and issuers should be aware of. Providers
Recipient Issuers
Appendix A: Enhanced Original Provides the data element requirements for Acquirers,
Credit Transaction (OCT) Data enhanced 0200 OCTs. Merchants, and
Elements and Processing Rules Service Providers
Recipient Issuers
Appendix B: Sample Reports Provides sample VisaNet reports related to OCTs. Acquirers,
Merchants, and
Service Providers
Recipient Issuers
Appendix C: API Formats Provides sample of the common data elements of Acquirers,
Visa Direct APIs in XML format. Merchants, and
Service Providers
Recipient Issuers
Appendix D: Visa Direct Account Outlines information on the Visa Direct Account Acquirers,
Lookup File Lookup File. This is a file that merchants can Merchants, and
receive from Visa that contains the issuer country Service Providers
code, billing currency account type, Fast Funds
participation status, and whether the issuer can
receive OCTs. (Formerly, the Visa Personal
Payments (VPP) Account Lookup File.)
Appendix E: Transaction Flows Provides sample transaction flows. Acquirers,

Merchants, and
Service Providers
Recipient Issuers

About This Guide
Appendix F: Enhanced TC06 OCTs Provides the data element requirements for Acquirers,
enhanced TC06 OCTs. Merchants, and
Service Providers
Recipient Issuers
Appendix G: U.S. OCT Switch Provides information on the Visa Direct OCT U. S. Acquirers,
Service Switch Service Merchants, and
Service Providers
Appendix H: CEMEA-Specific Provides CEMEA-specific requirements for Money Acquirers, Merchants

Requirements for Money Transfer Transfer transactions processed within CEMEA and Service
countries. Providers
(This appendix does not apply to Money Transfer
transactions initiated outside of CEMEA destined
for CEMEA countries.)
Appendix I: Acronyms and Provides a list of acronyms and a glossary of Acquirers, Merchants
Glossary terms. and Service,
Providers
Recipient Issuers
Summary of Changes in this Version
This version of the Visa Direct Original Credit Transaction (OCT) – Global Implementation Guide
contains updates for the following topics. Changes also include minor edits and modifications for
clarity and accuracy of rules. Changes are highlighted in the Guide with underscored text.
Table 1-2: Summary of Changes
Chapter Description
General  Removed all references to Basic OCTs as this is no longer supported.
(Throughout  All references to SMS Full Financial 0200 are replaced with SMS 0200 OCTs.
guide)
 Removed all references to VEAS and VECSS as they are no longer in use.

About This Guide
Chapter Description
Chapter 1  Added a detail that ACNL file should only be used for Visa Direct programs.
Original Credit  Updated OCT Services table to detail on the services included under Money
Transaction Transfer and Funds Disbursement.
(OCT) Overview  Added a section to clarify the difference between Domestic and Cross-border OCT
transactions in the Europe region.
 Added clarity to the definition of SMS 0200 OCT Message Format.
 Added detail that all Money Transfer OCTs must be processed as SMS 0200 OCTs.
 Added details on Staged Digital Wallet.
 Added Loyalty and Offers to the Visa Direct Services that use OCTs.
2 Origination  Updated General Origination Program Considerations to include requirement for
Requirements domestic Money Transfer programs.
and  Updated requirements on Program Approval process.
Considerations  Updated the section name from Visa Direct Program Information Form (PIF) to
Visa Direct Program Approval.
 Updated the Forms section to include Visa Direct Program Implementation
Questionnaire.
 Updated the conditions for High Brand Risk Acquirer Registration form.
 Removed references to Addendum B as they were no longer in use.
 Added a new section for Push Payments Tokenization.
 Added a new table to introduce Visa Developer Platform (VDP) APIs for AFTs and
OCTs.
 Added a new section for API Terms of Use.
 Added information on the option to support OCTs for Visa-branded products on
Network 0004 (PLUS).
 Updated the use case for BAI WT in the BAI table.
 Updated the BAI table to include FT.
 Added a new section on P2P Digital Payment Platform (DPP).
 Updated information on Sales Tax Reclaim.
 Updated Alternate Lending section to remove reference to Small Business as there
are no small business guidelines.
 Added information about Earned Wage Access program.
 Added a new section for Gambling and Gaming Program Overview to provide
gambling and gaming requirements.
 Updated Acquirer forms to remove: VSS100-R – Revised Settlement Reporting
Hierarchy List, VSS610 – Pending Fee Settlement Report, and VSS640 – Pending
Visa Charges Report.

About This Guide
Chapter Description
3 Recipient  Added information on the option to support OCTs for Visa-branded products on
Issuer Network 0004 (PLUS).
Requirements  Updated a note to inform availability of MCC 7995 from October 18, 2019 for U.S.
and face-to-face gambling establishments.
Considerations  Updated VisaNet Stand-in Processing (STIP) requirements for Europe.
 Added a note to indicate VisaNet Minimum Velocity Limits will be available to
Europe in the near future.
 Updated language for Watch List Screening Service.
4 Bank  Updated this section to include Crimea and Japan to the BIN Blocking by Country
Identification table.
Number (BIN)  Added a note for U.S. region to inform availability of MCC 7995 from October 18,
Blocking 2019 for face-to-face gambling establishments.
5 Exception  Added details on exception handling when a cardholder is attempting to send
Processing funds to a recipient and the OCT is rejected, declined, or expired.
 Updated the Disputes section to include the VCR process.
6 Visa Direct Added new chapter to address Visa’s framework outside of the Watch List screening
Risk service.
Management
Framework
Appendix A  Updated Field 104 to include fields for Business and Individual Tax ID.
Enhanced
 Updated requirements for Field 14 Expiration Date.
Original Credit
Transaction
(OCT) Data
Elements and
Processing
Rules
Appendix C API Added new Appendix to provide examples of an OCT API message for Send and
Formats Receive. Included a table mapping API tags to its corresponding ISO fields.
Appendix I  Updated Acronyms table to include FT and MVV.
Acronyms and
 Updated Glossary to include definition for Financial Institution.
Glossary
Related Publications and URLs
Please contact your regional Visa representative for the latest versions of these documents.
Available Documents and URLs

 Visa Direct: User Experience Brand Requirements
 Visa Account Funding Transaction (AFT) Processing Guide

About This Guide
 Visa File Exchange Service (VFES) Implementation Guide

 Visa Extended Access Server Endpoint Guide
 Changes to the Account Range Lookup File Technical Letter and Implementation Guide, Version
1.0 Effective: 19 July 2017
 Visa Global Acquirer Risk Standards
 Visa Developer Center/Platform (VDP) (for information on the current Visa Direct APIs)
https://developer.visa.com/ , https://developer.visa.com/capabilities/visa_direct ,and
https://developer.visa.com/products/visa_direct/reference
 Visa Developer Center (for legacy information on the Visa Direct APIs for users who have not
completely transitioned to new Visa Developer Platform)
https://developer.visa.com/legacy/products/vpp/ & Visa Direct Visa Developer Center (VDC)
Application Programming Interface (API) Client Implementation Guide
Global Technical Letters (Business Enhancement Release (BER))
 April 2019 Global Technical Letter and Implementation Guide

Articles 2.10, 2.11, 3.3, 4.3, 9.3.4, 11.2.2
 October 2018 Global Technical Letter and Implementation Guide
Articles 2.4, 2.8, 3.4, 4.7, 5.1, 11.5.4
 April 2018 Global Technical Letter and Implementation Guide
Articles 2.2, 2.3,3.9, 3.13, 3.16, 7.1.1, 9.5.2, 10.3.1
 October 2017 Global Technical Letter and Implementation Guide
Articles 2.14, 2.4, 3.2, 4.2, 9.2.5, 9.3.
Visa Direct Regional Mailboxes
To reach the various regional product office please use these email addresses.
USVisaDirect@visa.com
CanadaVisaDirect@visa.com
EUVisaDirect@visa.com
VE_FF@visa.com – Note: This mailbox is specific for the Fast Funds migration in the region and will
retire in the future.
LACVisaDirect@visa.com
CEMEAVisaDirect@visa.com

About This Guide
APVisaDirect@visa.com
For all other regions, please reach out to local Visa representatives.

Original Credit Transactions (OCT) Overview
1 Original Credit Transactions (OCT) Overview

The Original Credit Transaction (OCT) is a VisaNet transaction that can be used to send funds to an
eligible Visa card2. OCTs alone cannot be used for the purchase of goods or services. Examples of Visa
Direct services that use the OCT include:
 Money Transfer—A service that uses the OCT to enable consumers to send funds to their Visa
account or to another consumer’s Visa account.
 Funds Disbursement—A service that uses the OCT to enable merchants, government entities, or
corporations to send funds to a Visa account. Examples include insurance claims, corporate and
manufacturing rebates, affiliate and contractor payouts, expense reimbursements, government
disbursements (such as value-added tax refunds), and online gambling and lottery payouts3.
 Merchant Settlement—Acquirers or Third Party Agent service providers using the OCT to speed
up settlement payments between acquirers or payment facilitators and their merchants
 Digital Wallets4 and Instant Deposit— A Digital wallet or electronic wallet service enables faster
payments to move funds out of a digital wallet and to convert a check into a digital payment
delivered to a cardholders Visa account. This is considered a Money Transfer for risk control
purposes in the Visa processing network. A Staged Digital Wallet functions as a brand acceptance
mark.
 Loyalty and Offers - A service that pays a loyalty reward or merchant offer onto a card using the
OCT as part of a Loyalty program.
 Prepaid Load—a service that uses the OCT to enable consumers to add value to an eligible Visa
reloadable prepaid card.
Note: The U.S. market currently supports a separate prepaid load service called Visa ReadyLink.
For more information on Visa ReadyLink, contact your Visa representative.
 Credit Card Bill Payment—a service that uses the OCT to enable consumers to pay a Visa credit
card bill.
2
Clients should differentiate OCT processing from merchandise credit refund processing which in some cases has other
consequences including reversal of reward points etc.
3 Where permitted by law, and current Visa policy, and the Visa Rules.
4 Contact your Visa representative for additional information and requirements on digital wallets. For further information on
the requirements that apply to digital wallet transactions, visit the Staged Digital Wallet Operators (SDWO) section at Visa
Online (VOL).

Note: Visa clients may not use data provided to them by Visa, including but not limited to
transaction, reporting and the ACNL file, in support of a Visa Direct program for any purpose
other than as necessary to operate the Visa program.
1.1 What is an OCT?
The OCT is a powerful VisaNet financial transaction that delivers funds directly to a recipient’s eligible
Visa account.
Unlike a purchase transaction, which debits a cardholder’s Visa account, the OCT credits the
cardholder’s Visa account as outlined in the following examples:
Table 1-1: Visa Account Types for OCT
OCT to Visa Account Types Description Example
Visa Credit Accounts An OCT to a Visa credit account If the amount owed on the
serves as a payment to the account is $800.00 and an OCT for
account. $100.00 is received to the account,
a payment of $100.00 will be
posted to the account. The new
outstanding balance is $700.00.
Visa Debit Accounts An OCT to a Visa debit account If the account balance is $800.00
serves to add value to the and the OCT received is in the
underlying bank account amount of $100.00, the new
associated with the Visa debit account balance is $900.00.
account.
Visa Reloadable Prepaid Accounts An OCT to an eligible Visa prepaid If the prepaid account balance is
account serves to add value to the $25.00 and the OCT received is in
prepaid account balance. the amount of $100.00, the new
prepaid balance is $125.00.
Visa Deferred Debit Deferred Debit cards have a line of If the underlying account has a
credit and an underlying bank balance on $800.00 and an OCT
account. An OCT to a Visa for $100.00 is received to the
Deferred Debit account serves as a account, the new account balance
deposit to the underlying account is $900.00. The credit balance
when both the line of credit and owed on the card is not impacted
underlying account are with the by the receipt of the OCT.
same bank.

OCT to Visa Account Types Description Example
If the Deferred Debit card The card has a balance owed for
underlying account is with a $200.00 and an OCT for $100.00 is
different bank than the line of received the payment of $100.00
credit, it is appropriate to post the will be posted to the credit
funds to the card account. account. The new outstanding
balance would be $100.
Visa Combo Card (Brazil) Combo cards give cardholders the If the deposit account linked to the
option to use credit or debit card has a balance of $800.00, and
functionality during a transaction. an OCT for $100.00 is received to
An OCT to a Visa Combo card the account, the new account
account and processed as debit balance is $900.00.
serves to add value to the
underlying deposit account linked
to the card.
The credit balance owed on the

card is not impacted by the receipt
of the OCT, funds will only be
applied to the debit balance in the
deposit account. The OCT for
combo cards should not be
presented as credit using the
proper values specified in Field 3
described in Appendix A.
The OCT can be used for a variety of services. For each OCT service type, the following table details
the types of Visa cards that are eligible to receive that OCT type, and whether that OCT-type is
domestic only or domestic and cross-border.

Table 1-2: OCT Services
OCT Services Destination Visa Account Types Geographic Scope
Visa Credit Visa Debit Visa Domestic Cross-Border

Prepaid5
Money Transfer X X X X X
(includes digital wallet
and instant deposits)
Funds Disbursement X X X X X
(includes Merchant
settlement, and Loyalty
and Offers)
Prepaid Load6 X X
Credit Card Bill Payment X X
1.1.1 Identifying Domestic and Cross-border OCT Transactions
Visa redefined domestic and cross-border OCT transactions in the Europe region due to passporting7
rights within the European Economic Area (EEA). This came into effect in V.I.P as of April 2018.
The following table defines domestic and cross-border OCT transactions within EEA regions and
Outside EEA.
Table 1-3: Domestic vs. Cross-border Definition
European Economic Area (EEA)
Geographic Scope Outside EEA
Money Transfer Funds Disbursement /Non-
Money Transfer
Domestic  Sender country (as  Merchant country and Merchant,

provided by the merchant recipient account range acquirer, and
originator/acquirer) and within the same EEA country, recipient issuer are
recipient account range AND
5
OCTs are mandated for all reloadable prepaid card accounts but are not permitted on non-reloadable prepaid or prepaid
card accounts where cardholder data is not on file or where the source of loads may be restricted (e.g., government,
healthcare and insurance programs).
6 Not available in the U.S. Region. The U.S. market currently supports a separate prepaid load service called Visa ReadyLink.
For more information on ReadyLink, contact your Visa representative.

7 Passporting is the ability for firms authorized in the European Economic Area to carry out activities in any other EEA state.

European Economic Area (EEA)

Geographic Scope Outside EEA
Money Transfer Funds Disbursement /Non-
Money Transfer
within the same EEA  Acquirer and Issuers within in the same
country, AND the EEA country.
 Acquirer and Issuers within (Example: Funds Disbursement
the EEA between merchant and person in
(Example: Person-to-person the United Kingdom)
Money Transfer between two
persons in the United Kingdom)
Cross-border Anything that does not meet Anything that does not meet the Recipient Issuer is
the above definition would be above definition would be in a different
considered cross-border considered cross-border country than the
(Example: Person-to-person (Example: Funds Disbursement merchant/acquirer.
Money Transfer between a from merchant in the United
sender in the United Kingdom Kingdom to a recipient in Malta)
and a recipient in France)
1.1.2 OCT Message Formats
There are 2 OCT Message Formats:

 Single Message Service (SMS) Full Financial 0200 OCT
 Enhanced TC06 OCT
Single Message Service (SMS) Full Financial 0200 OCT
A single message service (SMS) full financial 0200 OCT is an Original Credit Transaction in which the
authorization/clearing and settlement messages are combined in a single real-time message.
All U.S. programs must be implemented with the SMS 0200 OCT (including use of compliant Visa
Direct APIs.) Likewise, all OCTs sent to U.S. issuers must be originated as SMS 0200 OCT messages. In
all other regions, all new programs and all Money Transfer programs must be implemented with the
SMS 0200 OCTs.
As of 12 April 2019, all Europe region OCT programs, including all Money Transfer OCTs must be
processed as SMS 0200 OCTs through V.I.P., all batch-only TC06 Funds Disbursement OCT
submissions must cease. Clients in Europe will have two alternatives for sending SMS 0200 OCTs:
 Via ISO 8583: Set up a single message endpoint connected to the V.I.P. System.
 Via Visa Direct APIs: Connect to Visa Direct APIs on the Visa Developer platform, which
originates OCTs into V.I.P. For details, see the Visa Direct page at the Visa Developer Center.

Important
This document focuses on the SMS 0200 OCTs, unless otherwise specified. Through this document,
SMS 0200 OCTs may also be referred to as:
 OCT
 Enhanced format OCT
 Enhanced format
 0200 OCT
 0200, or
 Enhanced 0200 OCT
Enhanced TC06 OCT
OCTs may also be sent as a TC06 clearing record, i.e. without an authorization.
The Enhanced TC06 format is an enhanced version of the Basic TC06 format OCT, updated in 2009.
Since then, all OCT modifications have been made to the Enhanced TC06 and SMS Full Financial 0200
formats, primarily the latter. The main changes to the enhanced TC06 messages are characterized by
the mandatory presence of a Business Application Identifier and the introduction of new fields to:
 provide information on the use case (the ‘Business Application Identifier’).
 provide information required for Anti-Money Laundering/Watch list screening.
The TC06 format was never allowed in the U.S., which adopted origination with the SMS Full Financial
0200 OCT. No new Enhanced TC06 OCT origination programs will be approved. As of 12 April 2019,
all Europe region OCT programs, including all Money Transfer OCTs must be processed as SMS 0200
OCTs through V.I.P., all batch-only TC06 Funds Disbursement OCT submissions must cease. While
Europe may continue to allow some Enhanced TC06 origination programs for existing OCT-enabled
acquirers, any new acquirers with new programs will be required to originate using the SMS 0200
OCTs instead of the Enhanced TC06.
Message Format Details and Data Elements
For details of the enhanced 0200 OCT message formats, including data elements, refer to Appendix A:
Enhanced Original Credit Transaction (OCT) Data Elements and Processing Rules. For a list of Business
Application Identifiers (BAIs), refer to 2.3.4: Business Application Identifier (BAI) and Merchant Category
Code (MCC) Usage.
For details of the enhanced TC06, refer to Appendix F: Enhanced TC06 OCTs.
For information on Visa Direct APIs, refer to:

 Section 2.3.3.2: Application Programming Interfaces (APIs)
 Visa Developer Center/Platform https://developer.visa.com/ and the Visa Direct Resources page
https://developer.visa.com/capabilities/visa_direct

1.1.3 Fast Funds
The speed of the transfer, time to receive funds, and ability for cardholders to use those funds are
important determinants in the customer experience. Visa has incorporated these capabilities in the
OCT message set using the Fast Funds enhancement.
An issuer that participates in Fast Funds must make funds available to the recipient within 30 minutes
of approving the authorization or full financial OCT message. In other words, increment the
cardholder’s open-to-buy or operating limit with the OCT payment amount within 30 minutes of
approving the OCT.
Note: For detailed information on posting funds for different card types, refer to Section 1.1 What is
an OCT?
The Fast Funds option gives recipients faster access to their funds and greatly improves the experience
for both senders and recipients. Fast Funds issuers may also benefit from interchange incentives on
their enhanced OCTs.
For detailed information on Fast Funds, refer to Section 3.10: Recipient Issuer—Funds Availability.
1.2 How it Works
Visa Direct services enable payments to be sent to any eligible Visa card, through any channel using
any source of funds, utilizing the Original Credit Transaction (OCT), as shown in the following diagram.

Figure 1-1: Visa Direct Process Flow8
There are two potential flows for OCT based services.

 Money Transfer (Example: Money Transfer, including digital wallet and instant deposits).
 Funds Disbursement/Non-Money Transfer (Examples: Funds Disbursement (including Merchant
settlement, and Loyalty and Offers), Prepaid Load, and Credit Card Bill Pay).
8If a Visa account is used to fund the transfer, the acquirers, service providers, and/or merchants must use the Account
Funding Transaction (AFT). In the U.S. and Canada, if a Visa transaction is used to fund the OCT, acquirers, service providers,
and/or merchants must process the transaction as an AFT. Please refer to the Visa Account Funding Transaction (AFT)
Processing Guide for additional details.

Figure 1-2: Example Card-to-Card P2P Money Transfer Process Flow
Step 1: Transaction Initiation9—a sender initiates a P2P Money Transfer from their Visa card (AFT) to
a recipient’s eligible Visa account (OCT) typically through a P2P Money Transfer service provider,
merchant or their financial institution.
Step 2: OCT—the service provider, merchant or financial institution receives the transfer/payment
instructions and uses this information to create an OCT. The service provider, merchant or their
financial institution sends the OCT to the issuer through VisaNet.
Step 3: Funds Availability—the recipient issuer receives the OCT and uses it to make funds available
to the recipient’s Visa account. There are two timeframes for funds availability:
 Conventional Funds Availability—Recipient issuer makes funds available to the recipient’s
account as soon as possible, but no later than two business days after receiving the SMS 0200
OCT or TC06 clearing message associated with the OCT. In the Europe Region, the requirement
is to make funds available to recipient on the same business day as the receipt of clearing and
settlement message.
9The example provided assumes a Visa card is used to fund the OCT in which case there is a Visa AFT followed by a Visa
OCT. The funding source for an OCT in a P2P scenario could be from other sources, not just a Visa card.

 Fast Funds Availability—Recipient issuer makes funds available to the recipient’s account
within 30 minutes of approving the SMS 0200 OCT (for single message issuers) or the 0100 OCT
authorization (for dual message issuers).
For more information on funds availability, issuers should refer to Section 3.10: Recipient Issuer—Funds
Availability.
Figure 1-3: Example of Funds Disbursement/Non-Money Transfer Process Flow
In a Funds Disbursement/non-Money Transfer OCT, the sender or merchant is the business or

government entity that is disbursing funds to a Visa card accountholder. A business or government
entity can:
 Submit transactions directly into VisaNet via the Visa Direct APIs (requires the business or
government entity to have an acquirer sponsor).
 Work through an acquirer processor to send Funds Disbursement OCTs (may require the
business or government entity to have an acquirer sponsor).
 Work with a third party service provider to submit Funds Disbursement instructions (acquirer
sponsor relationship is with the service provider vs. individual business or government entities;
however, acquirers should consider a merchant agreement or contract with all merchants even
if not directly on-boarded by the acquirer; i.e., on boarded by the service provider).
Settlement of the funds used for the disbursement transactions between the business or government
entity and the acquirer are managed outside of Visa.
1.2.1 Benefits
OCTs have multiple benefits including the following:

 One Transaction/Many Uses—the OCT is a powerful Visa transaction. This single transaction
can be used to enable a wide range of services including Money Transfers, Funds

Disbursements, merchant settlement, Digital Wallet transfers, instant deposits, prepaid loads,
and Credit Card bill payments.
 Trust—a Visa acquirer (or Visa-sponsored/registered third-party agents/payment facilitators)
submit every OCT and funds are only sent to Visa accounts that have been issued following
appropriate “Know Your Customer (KYC)” procedures.
 Reliability—For over 50 years, Visa has operated a transaction processing and clearing
payment system with an established daily funds settlement process on behalf of its financial
institution clients all over the world. Visa has an established system for processing transactions,
handling exceptions, addressing fraud situations, and providing value-added capabilities that
meet a financial institution’s needs.
 Global Reach—the OCT utilizes the existing VisaNet infrastructure to reach financial institutions
and Visa cardholders across the world.
 Security—to ensure that transactions are secure, Visa provides its clients with risk control tools
and straight-through electronic processing capabilities.
 Convenience—the OCT enables a consumer to receive funds directly into his or her Visa
account. Consumers can then access these funds at ATMs and merchants that accept Visa cards.
 Speed—With Fast Funds, consumers should receive access to the funds in their account within
30 minutes of issuer approval of the transaction, giving them virtually instant access to their
funds.
 Ease of Use—Consumers do not have the burden of maintaining an additional account to get
access to their funds. With the OCT, funds are sent directly to an existing Visa account of their
choice giving them greater flexibility in managing their funds.
 Currency Handling—VisaNet provides currency conversion and transaction settlement over
multiple currencies.


Origination Requirements and Considerations
2 Origination Requirements and Considerations

This chapter provides details of requirements and considerations for Visa Direct origination programs.
This chapter also provides recipient issuers with an understanding of the roles and responsibilities of
acquirers, service providers, and merchants.
2.1 General Origination Program Considerations
This section outlines general program considerations for acquirers, service providers and merchants:
 Acquirer—in the context of Visa Direct, an acquirer is a Visa financial institution approved by
Visa to originate Visa Direct transactions (AFTs and/or OCTs) or signs merchants or service
providers to originate Visa Direct transactions. The acquiring BIN used for Visa Direct
transactions is licensed to the acquirer and the acquirer is liable for all activities conducted with
their BIN. These responsibilities include:
 All activities conducted with their BIN(s)
 All programs that they operate or sponsor
 All activities of any sponsored merchants and service providers including ensuring they
comply with Visa Rules and Requirements.
In addition, acquirers are required to comply with the Visa Core Rules and Visa Product and
Service Rules as well as the Visa’s Global Acquirer Risk Standards (available on VOL) and are
required to ensure that all participants in all Visa Direct programs comply with applicable laws,
regulations, and Visa Rules. Acquirers must perform due-diligence and monitoring in
connection with its Visa Direct programs.
 Merchant—an entity that originates OCTs only for themselves and their customers. Merchants
can be sponsored directly by an acquirer or on boarded through an acquirer-sponsored service
provider.
 Service Provider— An acquirer-sponsored Third Party Agent that enables OCT-based services
on behalf of an acquirer or offers OCT-based services to merchants.
 Sender—A customer of the merchant or service provider (consumer or business) with a need to
push payments.
 Fees—Merchants must provide senders with information and related terms in connection with
their OCT-based service. A clear itemized description of all merchant-assessed fees, including
any applicable foreign exchange fees associated with the transaction must be communicated to
senders in accordance with applicable laws and regulations of the area of operation of the
merchant. Senders must be provided the opportunity to agree to the fees or cancel the
transaction. Refer to Section 2.2.4: Forms and Section 2.5.1: Providing Description of Fees.

 Risk Management and Regulatory Compliance—Acquirers, service providers, and merchants

must comply with the Visa Rules and local laws and regulations. Service providers and
merchants must have the appropriate license, if required, and must ensure they comply with all
applicable sanctions and “Know Your Customer”, anti-money laundering, and anti-terrorist
financing laws. If an acquirer uses or sponsors a third party agent, the acquirer is responsible for
ensuring that the third party agent is also in compliance. For detailed information on acquirer,
service provider, and merchant risk management considerations, refer to Section 2.6: Acquirers,
Service Providers, and Merchants - Risk Management Considerations. For an overview of
regulatory requirements and key laws, refer to Chapter 7: Regulatory Compliance and Legal
Considerations.
 Terms and Conditions (T&Cs)—Merchants must provide the T&Cs for their program to the
customer. It is strongly recommended that merchants prompt senders to agree to the T&Cs
prior to sending any transactions and retain evidence of such consent. Refer to Section 2.5:
Acquirers, Service Providers, and Merchants: Customer Considerations for details.
 OCT Permitted Uses—Examples of OCT use cases to enable payments to Visa cards include
Money Transfers, Funds Disbursements, merchant settlement, Digital Wallet transfers and
instant deposits, prepaid loads, select gambling and gaming winnings, and Credit Card bill
payments. All Visa Direct and OCT-based programs require Visa approval prior to program
launch. Each OCT must only involve one sender and one recipient. Refer to Section 2.3.4.1.4
Gambling and Gaming Program Overview for information on gambling and gaming winnings.
 OCT Funding Options—Service providers and merchants determine how senders of Money
Transfers can fund OCTs (e.g., cash, bank account, digital wallet, or Visa account) and are
responsible for ensuring that sufficient funds are available.
If the OCT is funded using a bank account or digital wallet, the service provider or merchant
may use a proprietary message to debit the sender’s account for the money transfer amount.
For Visa approved Money Transfer programs, merchant service providers are responsible to ensure
that the source of funds used for the Money Transfer is domestic. They must carry out this validation
prior to initiating the OCT. Refer to Section 2.4.3 Transaction Screening for more details.
Important:
If a Visa account is used to fund the OCT, merchants must process the transaction as an AFT and a BAI
must be used to identify the use of the AFT transaction. Any AFT submitted without a valid BAI is
rejected by Visa.
For details on the Account Funding Transaction (AFT), refer to the Visa Account Funding Transaction
(AFT) Processing Guide.
For additional details on funding sources, refer to Appendix A.1: Source of Funds (Field 104, Dataset ID
5F, Tag 08).

 Speed of Funds Delivery10— Issuers must post funds to the recipient account as soon as possible
upon receiving and authorizing an OCT, but no longer than two business days of receiving the
OCT message. However, many issuers around the world support Fast Funds and must make
funds available in the recipient account within 30 minutes of approving the OCT
authorization message. See the following for updated regional Fast Fund mandate timelines:
- Fast Funds Japan – Effective 13 October 2018, all debit issuers are required to support
domestic enhanced original credit transactions and fast funds processing.
- Fast Funds Canada – Fast Funds participation is required for all debit and prepaid issuers.
Effective 14 April 2018, the Fast Funds mandate will apply to all proprietary ATM and debit
cards that carry the PLUS mark.
- Fast Funds Europe Region – Effective 14 October 2018, issuers of Direct Debit Cards,
Deferred Debit Cards (with 16-digit primary account number and Card Verification Value 2),
and Prepaid cards will be required to support Fast Funds processing.
- Fast Funds Latin America Region – Effective 14 April 2018, debit and prepaid issuers are
required to support Fast Funds processing.
For additional information, Refer to Section 3.10: Recipient Issuer—Funds Availability.
 General Systems Changes—Acquirers, service providers, and merchants must make general
systems changes related to access channels, system interfaces, transaction screening, and currency
conversion. They must also consider making system changes to support notifications, recipient
registries, and recurring transactions. Refer to Section 2.4: Acquirers, Service Providers, and
Merchants: General Systems Changes.
 Disputes and Reversals—Reversals and disputes are allowed under limited circumstances. Refer
to Chapter 5: Exception Processing for exception processing requirements.
 Visa Brand Requirements— Acquirers, service providers, and merchants are required to comply
with the Visa Direct: User Experience Brand Requirements for the usage of the Visa brand into the
user experience for online and mobile applications supporting push payment services. The
requirements are available on Visa Online (VOL).
10In Europe, the requirement is to make funds available to recipient on the same business day as the receipt of clearing and
settlement message.

2.2 Program Approval, Licensing, Registration, and Forms
2.2.1 Visa Direct Program Approval
All Visa Direct programs must be approved by Visa prior to program launch. Acquirers must obtain
approval by completing the Visa Direct—Program Information Form (PIF). The PIF details the scope of
the proposed origination program and related controls, including information on program
participants, program details, third party agents, and regulatory compliance and risk controls (e.g.
regulatory licenses/registrations required for specific programs, program controls including anti-
money laundering, anti-terrorist financing, suspicious activity monitoring and reporting, etc.). A PIF is
required for all new Visa Direct programs11 and for any updates or changes to existing Visa Direct
programs; for example, change in acquirer, BIN, Participants, program types (BAI), addition of new
countries and/or non-fiat currency capabilities (e.g. cryptocurrency). Refer to Visa Direct Program
Approval Process on Visa Online for more information on the program approval process.
Additional Information:
 All PIFs are required to be submitted by the acquirer and must be signed by an officer of the
acquiring financial institution. In certain markets and/or for higher risk programs, a compliance
officer of the acquiring financial institution may also be required to sign the PIF. Please refer to the
regional Visa Direct Product team for regional specific requirements.
 A new PIF must be submitted if the acquirer, service provider, or merchant plans to initiate new
Visa Direct program types or BAIs not indicated in a prior PIF.
 For Funds Disbursement/non-Money Transfer services, an acquirer, service provider, or merchant
offering multiple Visa Direct program types is not required to submit a separate PIF for each type
of program, as long as all other information in the PIF is consistent between service offerings. For
Money Transfer programs such as Account to Account (AA), Person to Person (PP), and Wallet
Transfer (WT), a new PIF is required for every new merchant origination program.
 Only approved programs are permitted to submit OCTs, edits exist in VisaNet that prevent OCTs
originating from acquirers that have not submitted a Visa Direct PIF that was approved by Visa.
Note: For bank-initiated P2P programs, acquirers are required to submit a list of all banks
participating in the bank P2P platform. All participating banks must be reviewed and approved by Visa
prior to initiating OCT-based services. Participating banks can be submitted with the initial PIF or
following the initial PIF approval.
11A program is defined as product or service being offered by an acquirer, service provider, or merchant. Visa defined
Program Types are listed in Table 2-4.

Visa typically reviews and responds to program submissions within 10 business days of the receipt of a
completed PIF; however, in some cases, the review process may take longer depending on the
complexity of the Visa Direct program. Contact your Account Representative for additional
information regarding the PIF and the process for submission.
2.2.2 Licensing and Registration
Acquirers and their agents must obtain all appropriate licenses, registrations, notifications,
authorizations, and approvals necessary to engage in Visa Direct services, including but not limited to
those required to engage in high risk programs, foreign exchange and cross-border transactions.
For all Visa Direct programs, there must be a properly licensed Visa client with RIGHTS TO ACQUIRE
that either acts as the merchant or sponsors another entity that acts as the merchant. The licensed
acquirer is liable for all Visa Direct programs operated using their licensed Visa BIN.
Each region needs to be aware of the requirements in their markets related to Visa Acquiring rights.
Processes, timelines and fees associated with licensing applications vary by market. Visa licensing
information can be obtained from VOL or by contacting your Visa Account Representative.
Note: For specific information on Visa Direct licensing requirements in CEMEA, refer to Appendix H
CEMEA-Specific Requirements for Money Transfer.
2.2.3 Third-Party Agent Registration
Third Party Agents offer a wide range of services to both acquirers and recipient issuers including on
boarding of merchants for push-to-card services, developing and managing customer facing touch
points such as computer/mobile phone user interfaces, Internet banking portals, and/or kiosks.
Acquirers partnering with a Third Party Agent to offer or support OCT-based services must register the
third party as an agent with Visa as outlined in the Visa Rules prior to any Visa Direct program launch
if they perform any of the following activities:
 Stores, processes or transmits cardholder information
 Manages or has access to funds related to the OCT based services
 Solicits other entities (e.g., merchants, corporate clients, government entities, other businesses,
etc.) for push payment programs or services.
The client must register and designate the third party agent activities that they have been authorized
to perform on the client’s behalf. Before registering a third party agent, the acquirer must perform a
due diligence review on the agent to ensure that they understand the agent’s business model,
financial condition, background and Payment Card Industry Data Security Standards (PCI DSS)
compliance status (if required). If PCI DSS compliance is required, compliance must be validated prior
to the launch of a Visa Direct program.

Note: Acquirers that contract with Third-Party Agents are liable for all activities associated with the
Visa Direct programs.
Review the Third Party Agent Registration Program page on www.visa.com to better understand the
TPA program.
2.2.4 Forms
Acquirers must complete required forms to participate in a Visa Direct program. Acquirers should
contact their Visa Account Representative for information on obtaining any necessary forms.
Table 2-1: Forms
Form Requirements
Visa Direct Program Mandatory

Information Form (PIF)
All acquirers must complete this form and receive approval prior to launching a
Visa Direct program.
BIN License Agreement Conditional

The BIN License Agreement is used to request a new BIN or change the
designated used status of a currently licensed BIN.
A unique acquiring BIN is required if the acquirer, service provider, or merchant
is using any of the APIs except the Funds Transfer Attribute Inquiry API and/or
FX Lookup Foreign Exchange Rate APIs (if the Acquirer, service provider, or
merchant is using these APIs exclusively, a new BIN is not required).
Client Information Conditional

Questionnaire (CIQ)
If a new acquiring BIN is requested, a CIQ will need to be completed to
(or geographical equivalent)
configure and install the BIN at Visa.
Visa License Agreement Conditional

This form is required if the acquirer, service provider or merchant is using a new
BIN for Visa Direct transactions. Each region needs to be aware of the
requirements in their markets related to Visa Acquiring rights. The Licensing
team can assist with Visa licensing requests. Timelines and fees associated with
licensing applications vary by market. Information on licensing requirements
and processes can be found on Visa Online.
For specific information on Visa Direct licensing requirements in CEMEA, refer to
Appendix H CEMEA-Specific Requirements for Money Transfer.

Form Requirements
Visa Direct API - Client Conditional

Onboarding Form
Required if the acquirer, service provider, or merchant is using any of the APIs. It
registers which Visa Direct APIs the acquirer, service provider or merchants will
use to provide the Visa Direct services. This is required when the client is ready
to be certified for VDP. This is automated for new clients.
Third-Party Agent Conditional

Registration Required if the acquirer is using a third party agent to manage any aspect of
their Visa Direct origination program.
Funds Transfer Paperwork Optional

Acquirers may want to set up a new Funds Transfer Settlement Reporting Entity
(FTSRE) for their OCT-based programs to separate OCT transactions from other
acquired transactions. For new FTSREs, the acquirer or acquirer processor must
complete funds transfer paperwork. Contact your regional Visa representative
for assistance.
High Brand Risk Acquirer Conditional

Registration
This is an online form accessible through Visa Online (VOL). See Global Brand
Protection Program Guide for Acquirers.
Visa Direct Program Conditional

Implementation
This is available on VDP. This is required when acquirers, service providers and
Questionnaire merchants are prepared to move projects and programs into production. This
helps assess if the client can integrate the Visa Direct program.
2.3 Acquirers, Service Providers and Merchants – OCT Transaction

Processing and Message Formats
This section outlines the transaction processing and OCT message format requirements for acquirers,
service providers, and merchants.
Additionally, it provides information on:

 BIN requirements and best practices
 Network routing options
 Business Application Identifier (BAI) Merchant Category Code (MCC) usage
 Performing recipient account checks
 Methods to determine an issuer’s Fast Funds status
 High-level information on disputes and reversals

 Settlement
 VisaNet host testing
2.3.1 Transaction Processing and Message Format
All new OCT origination programs must use the enhanced12 SMS 0200 OCT message format or use the
Visa Direct APIs. In order for recipient issuers to be able to post OCTs as Fast Funds in real-time, the
acquirers, service providers and merchants must send SMS 0200 OCTS.
Note:
 The enhanced 0200 format is documented in:

 Appendix A: Enhanced OCT Data Elements and Processing Rules
 For more information on Fast Funds, refer to Section 3.10: Recipient Issuer—Funds Availability.
 For transaction flows, refer to Appendix E: Transaction Flows.
 For details on the enhanced TC06 OCT, refer to Appendix F: Enhanced TC06 OCTs.
 For information on Visa Direct APIs, refer to:
 Section 2.3.3.2: Application Programming Interfaces (APIs)
 Visa Developer Center/Platform https://developer.visa.com/ and the Visa Direct Resources page
https://developer.visa.com/capabilities/visa_direct
All of the OCT data elements are critical to the effective processing of an OCT. However, there are
some fields and data elements that garner special attention as they are critical to:
 Anti-Money Laundering (AML) requirements.
 Ensuring positive cardholder experience and authorizations.
 Facilitating back-end reporting and exception management.
Examples of some of these key fields are in Table 2-2.
There are some non-U.S. legacy programs where acquirers, service providers, and/or merchants initiate OCTs as TC06
12
messages in the enhanced format. Refer to Appendix E: Enhanced TC06 OCTs for details on the enhanced TC06 format.

Table 2-2: High-Level Overview of Key OCT Data Elements for Acquirers, Service Providers and Merchants
V.I.P. Money Funds Prepaid Load Credit Card Bill Notes

(0100/0200) Transfer (MT) Disbursement Pay
(BAI = TU
Field Name
(BAI = AA, BI, (BAI = BP, FD, (BAI = CP)
PP, WT GD, GP, LO,
MD, OG, PD)
Field 42 Must contain Must contain a Must contain a Must contain a Card Acceptor Identification Code
Card Acceptor a unique unique unique identifier unique identifier (CAID) is used to uniquely identify
Identification identifier for identifier for for the merchant. for the merchant. individual merchants and merchants
Code the merchant. the merchant who use the OCT to push payments to
or government Visa accounts. The CAID is used to
entity that is differentiate data under a single
disbursing acquiring BIN by unique merchant or
funds to a Visa merchant and aids in back office
account services like reconciliation and dispute
holder. processing.
Field 43 Contains the Contains the Contains one of Contains one of This information will appear on the
Card Acceptor name, or name of the the following: the following: cardholder’s statement and helps the
Name abbreviated merchant or  Name of the  Name of the cardholder identify the transaction and
name of the government load partner entity avoids unnecessary calls by the
merchant of entity sending providing the providing the cardholder to their issuer to help
the MT OCT the Funds reload service, credit card bill identify the transaction
and the name Disbursement or payment
of the sender service, or
 Bank
designated  Bank
service name, if designated
offered over service name, if
bank channels. offered over
bank channels.

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants for use exclusively in managing their Visa programs. It must not be duplicated, published, distributed or disclosed, in
whole or in part, to merchants, cardholders or any other person without prior written permission from Visa. © 2013–2017 Visa. All Rights Reserved.

(BAI = TU
Field Name
PP, WT GD, GP, LO,
MD, OG, PD)
Field 104 Value = AA, Value= BB, Value – TU Value = CP The BAI is used to identify the type of
Business BI, PP, WT FD, GD, GP, payment that is being facilitated with
Application For more LO, MD, OG, the OCT. The accuracy of the BAI is
Identifier information PD critical in ensuring effective processing,
(BAI)13 on BAIs, refer pricing, reporting, and risk
to Section management of OCTs, as well as
2.3.4 Business providing essential information to the
Application issuer to use in risk assessment.
Identifier (BAI),
Merchant A valid BAI must be included in all
Category Code OCTs.
(MCC), and
Use Cases.
Field 104 Contains Contains the Contains the Contains the Fields available for Field 104 sender
Sender Data sender’s name account account number, name of the data, recipient data and source of
, account number, name, name, address, sender, address, funds are required for AML screening
Sender
number, address, city, city, city, purposes depending on the region,
Account
reference state/province, state/province, state/province, use case etc.
Number,
number, and country of country of the country,
Sender
address, city, the merchant sender, the recipient’s name,
13All BAIs listed are available for use in the U.S., but may not be available for use in other, non-U.S. markets. Contact your Visa account representative for a list of available
BAIs.


(BAI = TU
Field Name
PP, WT GD, GP, LO,
MD, OG, PD)
Reference state/province, or government recipient’s name, and source of
Number, country, the entity and source of funds
Sender Name, recipient’s disbursing funds.
Sender name, and funds to a Visa
Address, source of account
Sender City, funds. holder, the
Sender recipient’s
State/Province, name, and
Sender source of
country, funds.
Recipient
Name, Source
of Funds
Note: Refer to Appendix A: Enhanced OCT Data Elements and Processing Rules for a more comprehensive list of field and data
requirements

2.3.2 BIN Requirements and Best Practices
Acquirers must:
 Use a new or existing SMS acquiring BIN to initiate OCTs as 0200 full financial messages.
 Use a unique acquiring BIN if using the Visa Direct API to submit OCTs. A unique BIN is not
required if only using the Payment Account Attributes Inquiry, Payment Account Validation, or
Foreign Exchange Rate APIs.
While not required, acquirers may prefer using a unique BIN for their OCT programs. A separate BIN
allows acquirers to support:
 Separate reporting for OCT transaction processing, exception management, and dispute
resolution.
 Separate financial reconciliation for their OCT processing (for settlement and treasury
reconciliation purposes).
2.3.3 Push Payments Tokenization
A Payment Token is an “alternate identifier” that can be used in place of a PAN to initiate a payment
transaction. Push Payments tokenization enables Visa Direct service providers that submit account
funding transactions (AFTs) and original credit transactions (OCTs) with Personal Account Numbers
(PANs) to process with tokens.
Visa supports Visa Token Service for AFTs and OCTs for all available token types.
 AFTs and OCTs that are submitted for token processing must comply with all the existing
processing rules for AFTs and OCTs.
 Acquirers, service providers, and merchants that submit an AFT or an OCT for token processing
must be a valid token requestor.
 Acquirers, service providers, and merchants that submit AFTs and OCTs for token processing
may only send these transactions to recipient issuers that support AFTs, OCTs, and Visa Token
Service.
 In the U.S. region, OCTs with a token are eligible to be sent and received on Network 0002
(Visa), Network 0003 (Interlink), and Network 0004 (PLUS).
For more information on the impacted token types for AFTs and OCTs, contact your regional client
support representative.
For more information on Tokens, refer to Visa Token Service.

2.3.4 Network Routing Options
Acquirers, service providers, and merchants have multiple options for connecting to VisaNet to route
their OCTs including traditional VisaNet connectivity using ISO messaging or using the Visa Direct
APIs. The sections below outline the available routing configurations that are available to issuers.
2.3.4.1 VisaNet Connectivity Using ISO Messaging
Visa provides flexible, reliable, and secure access to Visa's payment systems using one of two single-
pipe connections.
 Visa Direct Exchange (DEX) is a closed, private, TCP/IP-based connection to VisaNet. DEX provides
secure access to VisaNet core processing as well as the ability to receive reports through file
exchange.
 The Extended Access Server (EAS), available outside the U.S., provides secure connectivity to
VisaNet and performs authorization routing, file staging, and delivery services. It incorporates
open standards with powerful IP technologies.
For more information, refer to the Visa Processing Services section on Visa Online or contact your Visa
representative.
2.3.4.2 Application Programming Interfaces (APIs)
Visa offers a series of Application Programming Interfaces (APIs) to acquirers, service providers, and
merchants to initiate transactions and support value-added services related to OCTs and Visa Direct.
Some acquirers, service providers, and merchants may find using APIs simpler to implement than
traditional ISO-8583 based V.I.P. messaging. Acquirers, service providers, and merchants may choose
to use all the APIs or a subset of them.
Important
Visa Direct programs require the acquirer, service provider, or merchant to ensure that all stages of
transaction processing including transaction submission, financial settlement, dispute management,
reporting are in place and effectively managed before launching a Visa Direct program using the APIs.
The APIs available on the Visa Developer platform help to manage certain stages of the transaction
specifically those related to financial transaction submission. The acquirer, service provider, or
merchant needs to be aware and ensure that the necessary capabilities are in place to support the
complete transaction cycle. Only acquirers, service providers, or merchants who can account for every
aspect of the payment stack will be allowed to move API projects into production.
Completion of a Visa Direct Program Implementation Questionnaire (available on VDP) is required

prior to moving an API from sandbox into production. The questionnaire is meant to aide acquirers,
service providers, and merchants in determining if they are prepared with the necessary elements to
offer a full service Visa Direct program and move their project into production. Based on responses to

the questionnaire, Visa may be able to provide insight or guidance to finding enabled acquirers and
partners that may be able to help move projects and programs into production.
Table 2-3: Visa Developer Platform (VDP) APIs
Visa Developer Platform APIs Visa API Characteristics
PullFundsTransactions POST (AFT related)
PullFundsTransactions GET (AFT related)
MultiPullFundsTransactions POST (AFT related)
MultiPullFundsTransactions GET (AFT related)
ReverseFundsTransactions POST (AFT related)
ReverseFundsTransactions GET (AFT related)
MultiReverseFundsTransactions POST (AFT related) Financial Funds Transfer APIs that require VisaNet
connectivity
MultiReverseFundsTransactions GET (AFT related)
Adjustment ReverseFundsTransactions POST (AFT
related)
PushFundsTransactions POST
PushFundsTransactions GET
MultiPushFundsTransactions POST
MultiPushFundsTransactions GET
Foreign Exchange Rates API

Value-Added APIs not sent to VisaNet and do not
Fund Transfer Attributes Inquiry API require VisaNet connectivity
Payment Account Validation API

Value Added APIs that do require VisaNet connectivity
Watch List Screening API
For more information on the Visa Direct APIs and their availability in your region or country, contact
your regional Visa representative. In addition, refer to the Visa Developer Center at the following
address: https://developer.visa.com/capabilities/visa_direct.
2.3.4.2.1 API Terms of Use
If acquirers or their VisaNet processor(s), service provider(s), third party agent(s) or any other third parties
involved in the acquirer’s program access any APIs through the Visa Developer Program (“VDP”) in connection
with the program, the Visa Developer Terms of Use (https://developer.visa.com/terms) and the Visa Developer
Security Terms (https://developer.visa.com/pages/security-terms) apply. The acquirer must comply, and be
responsible for all third parties’ compliance with such terms in connection with its program.

2.3.4.3 Push Payment Gateway Service (PPGS): (U.S. Only)
The Visa Push Payment Gateway Service (PPGS) allows acquirers, service providers, and merchants to
send their OCTs and AFTs to Visa for routing to multiple debit networks in the U.S. The service
provides authorization, clearing, settlement, reporting and exception processing support for Accel,
CU24, Maestro, NYCE, Pulse, and STAR networks.
Acquirers, service providers, and merchants can use PPGS to send OCTs and AFTs to VisaNet using the
Visa Direct APIs or Visa's standard V.I.P. ISO message format. VisaNet translates and reformats the
message into the correct network format, rather than an acquirer, service provider, or merchant having
to develop and maintain transaction formats for each debit network.
Additional information on the PPGS can be found in the Push Payment Gateway Client Implementation
Guide available on VOL or by contacting your Visa account representative.
2.3.4.4 Network Routing Alternative: (U.S. Only)
U.S. Only. Due to Visa Direct requirements that all OCTs be submitted to Visa as an enhanced full
financial 0200 message, originating acquirers that operate in a dual processing environment on
Network 2 may find it easier to implement OCT origination on Network 3, which is a SMS only
network. OCT origination on Network 3 is currently available for U.S. domestic and cross-border OCTs.
Refer to Appendix G: U.S. OCT Switch Service.
2.3.4.5 Proprietary ATM Card – PLUS Symbol/Network 4
As of April 2019, acquirers may optionally support OCTs for Visa-branded products processed on
Network 0004 (also known as PLUS network).
In Canada, effective 14 April 2018, Network 4 (PLUS network) was enabled to support domestic
OCTs. Additionally, issuers of PLUS branded products will be required to support incoming OCTs and
enable Fast Funds.
2.3.5 Business Application Identifier (BAI), Merchant Category Code (MCC)

and Use Cases
Acquirers, service providers, and merchants must use an appropriate Business Application Identifier
(BAI) and a Merchant Category Code (MCC) in the OCT authorization request message and clearing
and settlement message, to correctly identify the type of OCT and merchant or business entity that is
originating the transaction. Both the BAI and the MCC allow the issuer to be able to recognize the
underlying business use of the OCT. The MCC should represent the merchant, acquirer or service
provider/payment facilitator of the OCT transaction. Acquirers are instructed at the time of program
approval which BAI they are required to use for their OCTs. Table 2-4 lists the available BAIs and
provides examples of relevant use cases that would be used. For additional detail, refer to Appendix A:
Enhanced OCT Data Elements and Processing Rules, Field 104, Dataset ID 57.

Certain industries are highly regulated by federal, provincial, and local laws (e.g., healthcare, insurance,
payroll, gambling, etc.). Acquirers, merchants, service providers are, at all times, solely responsible for
ensuring that your program complies with all applicable law (including ensuring that any and all
required disclosures are made and consents are obtained, as applicable, and that OCTs are not sent
from/destined for countries where gambling is illegal).
Note: The MCCs in the table below are listed based on the use case. This is not a complete and
exhaustive list of all the MCCs used with the OCT. Refer to the Visa Merchant Data Standards
Manual on VOL for a complete list of MCCs that can be used in an OCT.
Note: All BAIs listed (except FT) are available for use in the OCT.14
Table 2-4: BAI and MCC Usage
BAI Use Case MCC Examples of Use
Money Transfer
AA Account to Account 4829 Non-Financial Institution For OCT, this is a sender moving
Remote Deposit Check Wire Transfer Money Orders money from his own account to
capture (RDC) (WTMOs) his card account. Me-to-me
6012 Financial Institutions – Money Transfer.
Consumer Funding of
their own account Merchandise and Services
BI Bank Initiated P2P 6012 Financial Institutions – P2P Money Transfer is initiated
Money Transfer Merchandise and Services from an online banking system,
Important: BAI BI is Note: BAI BI should only be used making it a bank-initiated
used for very specific in combination with MCC 6012. transaction.
scenarios and is
enabled only in limited
markets. Contact your
Visa Representative for
information on:
 the availability of
BAI BI in your
market, and
 applicability of BAI
BI to your program.
14 Other BAIs may be available in Technical Specs but are not for use for Visa Direct transactions.

PP P2P Money Transfer 4829 Non-Financial Institution For OCT, this is a sender sending
Wire Transfer Money Orders money to someone else’s
(WTMOs) account.
6012 Financial Institutions –
Merchandise and Services15
Note: BAI PP and 4829 must be
used for non-financial institution–
offered P2P Money Transfer. BAI PP
may be used for bank initiated P2P
Money Transfer with 6012.
WT Staged Digital Wallet 4829 Non-Financial Institution For OCT this is the withdrawal or
(SDW) Transfer Wire Transfer Money Orders cash out of funds from a staged
(WTMOs) digital wallet to a card account.
15 Based on the type of services, combine MCC 6012 with a valid BAI. Bank initiated P2P services must use a combination of
BI and 6012. Non-bank offered P2P services must use a combination of PP and 4829.

Funds Disbursement/Non-Money Transfer
BB Business to Business Any MCC associated to the Business to business payments for
Supplier Payments merchant, acquirer, or service business related supplies.
provider business (example:
5812=restaurant,
5311=department store)
BP Non-Card bill pay MCC associated to the recipient For non-card Bill payment.
business
CP Credit Card Bill Pay 4829 Non-Financial Institution Pushing funds to a credit card
Wire Transfer Money Orders account as a payment.
(WTMOs)
6012 Financial Institutions –
Merchandise and Services
FD General Funds Any MCC associated to the Funds Disbursements not covered
Disbursement – used merchant, acquirer, or service by other BAI use cases listed
for all others Funds provider business ( example: above.
Disbursements not 5812=restaurant,
listed above. Examples: 5311=department store)
Commission Payments
Digital Goods–Games
Insurance Payments
Loan Disbursements
Alternative/Online
Lending or Peer-to-
Peer Lending
Shared Economy
Tax refund services -
non-Government
initiated; e.g., tax
preparation businesses
VAT Tax Reclamation
FT (Target Funds Transfer (Stored 4829 Non-Financial Institution Cashing out a non-SDW account
availability Value Digital Wallet) Wire Transfer Money Orders
October (WTMOs)
2019) 6012 Financial Institutions –
Merchandise and Services

GD Government 9399 Government Services (Not Government payments including

Disbursements and Elsewhere Classified) social security payments,
Gov’t Initiated Tax 9402 Postal Services – Government unemployment, disability, jury
Refunds Only duty, and disaster
9405 U.S. Federal Government relief/emergency
Agencies or Departments
9222 Fines; government
administered
9211 Court Costs, Including
Alimony and Child Support
9311 Tax Payments
GP Gambling/Gaming 7800 Government owned lottery Casino payouts at gaming floor

Payouts (other than (U.S. only) counter and sports books.
online gambling) 7801 Government-Licensed Advanced deposit wagering.
Casinos (U.S. only) Gambling that is not considered
7802 Government-Licensed online gambling.
Horse/Dog Racing16 (U.S. only)
7995 Betting, including Lottery
Tickets, Casino Gaming Chips, Off-
Track Betting, and Wagers at Race
Tracks
LO Loyalty Payments Any MCC associated to the Payment for cancelled services,
merchant, acquirer, or service deposit refunds, employee
provider business ( example: rewards, and purchase rebate
5812=restaurant, payments.
5311=department store)
MD Merchant Settlement 6012 – Acquirers sending Merchant payments for purchase

settlement payments to merchants transaction processing where the
4829 – Payment Facilitator processor sends settlement
(includes sponsored processors, payments to a Visa card account
and ISOs) sending settlement using OCT.
payments to merchants
7800, 7801, and 7802 are U.S. only MCCs that also require the use of a valid Merchant Verification Value (MVV). Merchants
16
must register with Visa to obtain an MVV.

OG Online Gambling 7800 Government owned lottery Payout of winnings from online
Payouts (U.S. only) gambling merchants including:
7801 Government-Licensed casinos, horse/dog racing wagers,
Casinos (U.S. only) lottery, digital and social gaming
payouts.
7802 Government-Licensed
Horse/Dog Racing (U.S. only)
7995 Betting, including Lottery
Tickets, Casino Gaming Chips,
Off-Track Betting, and Wagers at
Race Tracks
PD Payroll & Pensions 8931 Accounting, Auditing, and Independent contractor works for
Disbursements Bookkeeping Services temporary staffing agency or
directly with an employer, submits
timesheet or completes project,
and is paid to bank account by
using a debit card.
TU Prepaid Card Load 6012 Financial Institutions – Loads, reloads, and top-ups to
Merchandise and Services Visa prepaid card accounts.
6540 Non-Financial Institutions – Note: Restricts use to Prepaid
Stored Value Card Purchase/Load card only. VisaNet edit declines
the transaction if the card product
is not prepaid and BAI is TU.
2.3.5.1 P2P Digital Payment Platforms (DPP) Framework
Person-to-Person Digital Payment Platforms are digital payment solutions to facilitate movement of
funds between the sender’s accounts, or from the sender to another individual’s account.
To clearly distinguish Money Transfer from P2P, accurate BAI coding is critical. This helps ensure:
 Implementing the right economics.
 Managing risks: arbitrage, fraud, money laundering, etc.
 Maintaining compliance and transparency across all parties in the payments chain.
 Taking into account a variety of emerging and evolving digital payment platform business
models.

The table below maps out the different P2P digital payment business models and provides guidance
to acquirers and merchants on the proper use of transaction type, MCC and BAI coding to facilitate
the movement of funds.
Table 2-5: BAI and MCC usage for P2P Digital Wallet Programs
Digital Payment Platform Model
Straight- Financial Stored-value

Staged wallet
through P2P Institution wallet
MCCs  4829  6012  4829  6051
 6012 (if bank-  6211  6012 (if bank-  6012 (if bank-
offered)  6051 offered) offered)
 Merchant’s
MCC if back-
to-back
Use cases
Me-to-me funding/adding cash N/A AFT (AA) AFT (FT)* AFT (WT)
Me-to-me withdrawal/ Cash out N/A OCT (AA) OCT (FT)* OCT (WT)
OCT not
AFT (FT)* AFT (FT)* AFT (FT)* AFT (WT)
Send funds to enabled
someone else
OCT enabled AFT (PP) AFT (PP or BI) AFT (PP) AFT (PP)
Receive funds from

OCT enabled OCT (PP) OCT (PP or BI) OCT (PP) OCT (PP)
someone else
* BAI FT targeted to be available in October 2019. In the interim, new programs must use the BAI AA.
Stored-Value Digital Wallet Considerations:

 Offered with P2P payment capability only.
 Can add and store funds in the digital account (wallet).
 Stored funds in the account can be used:
 to send funds to other users.
 to cash out to an unaffiliated account.
 Stored funds cannot be used to pay merchants.
 The digital wallet may be structured as a prepaid account or offer a prepaid card as a physical
access tool to the funds in the digital wallet. This scenario does not alter the transaction or BAI
coding.
Staged Digital Wallet Considerations:

 Can add and store funds in the digital account (wallet).
 The funds in the account can be used:

 to send to other wallet users on the platform.

 under the operator’s brand mark, to make payments at multiple merchants.
 to cash out to an unaffiliated account.
 Payments to merchants include:
 Face-to-face brand acceptance mark at a physical POS
 e-commerce brand acceptance mark
 Merchant wallets where users instruct buyers to send money to a merchant’s digital wallet.
2.3.5.2 Use Cases
The following sections describe rules specific to use cases that have unique requirements.
2.3.5.2.1 Bank 17 Initiated P2P Money Transfer
To better service customer needs and support the Federal Reserve’s Faster Payments initiative, banks
are developing easy-to-use, real-time interbank P2P payment services. To enable banks to fully
leverage the benefits of the Visa Direct platform, Visa is enabling processing and a unique pricing fee
schedule for bank-initiated P2P programs. Programs defined under this category must meet the
following requirements:
 The bank initiating the OCT must comply with the Fast Funds mandate for receiving OCTs on all
eligible Visa debit and reloadable prepaid card accounts.
 OCTs must be submitted with a business application identifier (BAI) of “BI.”
 OCTs with a BAI of BI may be used for domestic P2P payments offered by banks through bank
channels. Direct-to-consumer services provided by third-party service providers (including client-
sponsored third parties) are not eligible.
Important: BAI BI is used for very specific scenarios and is enabled only in limited markets.
Contact your Visa Representative for information on:
 the availability of BAI BI in your market, and
 applicability of BAI BI to your program.
In addition, service providers that enable bank P2P Money Transfer platforms on behalf of banks must
ensure Fast Funds compliance of all sending banks participating in their service prior to enabling bank
P2P services on behalf of the bank and its customers. The process for ensuring participating banks are
17 “Bank” as defined by the U.S. Code of Federal Regulations to include credit unions.

compliant with the Fast Funds requirement as well as the status of all participating banks must be
made available to Visa upon request.
Acquirers are required to have all participating banks in a bank P2P platform or service reviewed and
approved by Visa prior to initiating any OCT-based services. Acquirers can submit a list of participating
banks as part of the PIF process or following an initial PIF approval.
Contact your account representative for more details on bank initiated P2P programs.
2.3.5.2.2 Merchant Processing – Sales Tax Reclaim
A Sales Tax Reclaim rule was created for the rebate of VAT Tax incurred during international travel. The
merchants who provide these rebates must use an OCT to issue the rebate to the customer. This will
be a Funds Disbursement (BAI = FD). Field 104, Usage 2, DSI63 (Non-Industry Specific Data) will also
be optionally available; the exact value for this field is still to be determined.
For a VAT tax rebate only, a debit adjustment is performed when there is a regulatory requirement to
take back OCT funds. The debit adjustment must include the transaction identifier, BAI and
authorization response code from the OCT of the VAT Rebate to help with reconciliation.
Effective 13 October 2018 (Sales Tax Reclaim): A Merchant that provides a sales tax rebate to a
Cardholder must process the rebate as an Original Credit Transaction. A Sales tax rebate is a rebate of
only the tax paid on the purchase, including value-added tax (VAT), goods and services tax (GST), or
other general consumption tax that is rebated to the Cardholder. A Merchant that offers Dynamic
Currency Conversion (DCC) for a sales tax rebate must comply with all DCC requirements.
2.3.5.2.3 Alternative/Online Lending
Visa Direct can be used to support the following types of small-dollar credit products:
1. Small-Dollar Credit Loans – new guidelines below (U.S. only):
 Only unsecured loans.
 The lender does not have automatic recourse in the event the loan is not repaid or as a
condition of making the loan (e.g., does not require an authorization to automatically
debit the borrower’s account or require a post-dated check or electronic check).
 Repayment terms are in substantially equal installments.
 There is no automatic rollover or renewal.

2.3.5.2.4 Earned Wage Access (U.S. only):
Visa Direct OCT transactions can be used for Earned Wage Access (EWA) programs (i.e. Wage Advance
Programs and No Cost Advances) when the following guidelines are met:
a) Wage Advance Programs:

 The advance is made only against accrued wages.
 The advance is offered by the employer or the employer’s business partner.
 The program is either a no fee advance or charges only a fee for participating in the
program.
 Participating service providers have no legal or contractual claim or remedy against the
consumer based on the consumer’s failure to repay.
 Participating service providers will not engage in debt collection activities or report to a
consumer reporting agency.
b) No Cost Advances:
 The consumer is not required to pay any charge or fee to receive the advance (this does
not preclude voluntary tips-based advance programs).
 Service providers have no legal or contractual claim or remedy against the consumer
based on the consumer’s failure to repay.
 Service providers will not engage in debt collection activities or report to a consumer
reporting agency.
Merchants, Acquirers, Processors, Service Providers, and Issuers in the Visa Direct ecosystem will
continue to abide by the requirements detailed in the Visa Core Rules and Visa Product and Services
Rules in addition to this OCT Implementation Guide.
2.3.5.2.5 Gambling and Gaming Program Overview
To support continued compliance with applicable laws, regulations, and Visa Rules, acquirers must
carefully review their gambling merchants’ transaction coding and business practices for the following:
 Merchant Category Code (MCC)
 POS condition codes (Field 25, Values: 00, 01, 08, 59)
 Processing code
 Business Application Identifier (BAI)
 Fraud and AML controls
Acquirers must also perform enhanced due diligence reviews during onboarding and monitor
gambling merchants to prevent the introduction of unlawful internet gambling transactions into the
payments system.

Acquirers must have processes to validate the legality of all gambling and gaming merchants. The
table below describes the registration requirements and process for each MCC.
Table 2-6: Gambling Merchants Onboarding Requirements
MCCs Requirement Process
7800 (Government In the U.S, Gambling merchants  Register with Visa to obtain a unique
Owned Lotteries) must pass an enhanced due Merchant Verification Value (MVV).
(U.S. Only) diligence review to validate Submit registrations through the High
compliance with applicable laws Risk Merchant (HRM) module in
7801 (Government-
and the Visa Rules. Program Request Management (PRM)
Licensed Casinos)
tool on Visa Online.
(U.S. Only)
 Contact your Visa Representative for
7802 (Government-
more details on this required
Licensed Horse/Dog
registration process.
Racing) (U.S. Only)
Note: Visa blocks merchants that do not have a
valid MVV.
7995 Gambling merchants intending to  Follow the standard program review

use MCC 7995 must submit a process through the Visa Direct PIF
Note: In the U.S.,
Program Information Form (PIF) Program Request Management (PRM)
MCC 7995 will be in
for Visa approval prior to tool on Visa Online.
effect October 18,
production transactions.
2019 for select face-  In the U.S, in addition to the standard PIF
to-face gambling In the U.S, Visa will introduce the process, the acquirer will be required to
establishments. face-to-face casino MCC 7995 use complete the Visa AML addendum
case in a controlled, phased questionnaire.
approach starting October 2019.
 Contact your Visa Representative for more
Participants must be approved by
details on this required registration
Visa.
process.
Notes:
 In the U.S., online merchants that have

opted out of registration under MCCs
7800, 7801 and/or 7802 (U.S. only) may
operate under MCC 7995 (Betting,
including Lottery Tickets, Casino Gaming
Chips, Off-Track Betting, and Wagers at
Race Tracks).
2.3.6 Card Acceptor Identification Code (CAID)
Acquirers, service providers, and merchants must use a unique Card Acceptor Identification Code
(CAID) in the OCT authorization request message to identify the merchant that is disbursing funds to

Visa account holders. The unique CAID from the original transaction message is required in any
subsequent messages, including reversals, disputes, and representments.
For bank initiated programs where a processor or service provider offers OCT-based services for other
financial institutions, it is recommended that the CAID be populated with an ABA or other bank
routing number that uniquely identifies each financial institution acting as the merchant of push
payments.
For additional information on the CAID refer to Appendix A: Enhanced OCT Data Elements and
Processing Rules, Field 42.
2.3.7 Perform Recipient Account Checks Including Fast Funds Status
Before submitting an OCT to VisaNet, it is recommended that the acquirer, service provider, or
merchant perform checks on the destination Visa account to determine eligibility to receive OCTs and
Fast Funds posting capabilities.
There are several ways that acquirers, service providers, and merchants can obtain details about the
receiving BIN and card account.
 Account Range Definition (ARDEF) Table—Contains information on issuer participation in Fast
Funds.
 Payment Account Attributes Inquiry API—Contains information on issuer country code and
billing currency, account type, Fast Funds participation status, and whether the recipient issuer can
receive OCTs. Refer to the Visa Developer Center at https://developer.visa.com/products/paai for
additional information on this API. Available to all regions.
 Account Lookup File— Contains information on issuer country code, billing currency, account
type, Fast Funds participation status, and the recipient issuer’s ability to receive OCTs. Merchants
and service providers can receive the file from their acquirer, VisaNet processor, or through a Visa
File Exchange Service (VFES) connection. Refer to Appendix B: Visa Direct Account Lookup File for
details. In the Europe Region, the report is only available on Visa Online (VOL), monthly and
contains static data as a spreadsheet, which acquirers can use and download to their
software/terminals.
 Consolidated Routing File— Contains information on issuer Money Transfer OCT and Fast Funds
participation status.
2.3.8 Reversals and Disputes
Reversals and disputes are allowed under limited circumstances. See Chapter 5 for exception
processing requirements.

2.3.9 Settlement
Although not required, acquirers may want to set up a new Funds Transfer Settlement Reporting Entity
(FTSRE) for OCT-based programs to separate OCT transaction volume from other acquired
transactions. For new FTSREs, the acquirer or acquirer processor must complete funds transfer
paperwork. Contact your regional Visa representative for information on processes and fees.
2.3.10 VisaNet Host Testing
Before an acquirer can begin submitting OCTs to VisaNet, host system testing with Visa is required on
both ISO and API implementation.
Testing with Visa is also required if the acquirer is migrating from submitting OCTs as TC06s only to
submitting them as 0200 full financial messages in the enhanced format.
For information on Visa Direct and API testing, contact your regional Visa representative, refer to the
Visa Developer Center (for API: https://developer.visa.com/products/visa_direct) or to the following
documents:
 VCMS Testing, V.I.P., Client Version
 VisaNet Test Service - V.I.P. User's Guide
 VisaNet Test Service - V.I.P. Quick Start
2.4 Acquirers, Service Providers and Merchants – General Systems

Changes
Acquirers, service providers, and merchants must make general systems changes related to:
Customer Access Channels Clear and simple user interface (UI) for the customer
Consumer Data Collection and Sender Ensure systems and processes are in place to collect and verify
Authentication sender information and to ensure the collection and verification
of sender information complies with Visa Rules as well as
applicable laws and regulations
Systems Interfaces Ensure systems interfaces are in place to connect the user
interface to other merchant systems, as required.
Transaction Screening Screen the transactions to help mitigate risk and minimize
processing errors
Confirmation of Funds Transfer Provide senders with a way to confirm the funds transfer

Transaction Receipt and Notifications Ensure processes are in place to provide transaction receipts and
notifications in compliance with Visa Rules and applicable laws
and regulations.
Currency Conversion Determine and implement approach for currency conversion
Recipient Registry and Recurring Consider setting up recipient registries and processes to support
Transactions senders who routinely send to the same recipient.
2.4.1 Customer Access Channels
Acquirers, service providers, and merchants must develop and manage user interfaces for each of the
funds transfer customer access channels they plan to support, such as Internet/online banking, bank
branches, ATMs/unattended kiosks, and phone and/or mobile banking.
Acquirers, service providers, and merchants should implement a customer experience that is simple,
straightforward, and streamlined, especially important for ATMs, internet, and mobile channels.
Acquirers, service providers, and merchants should minimize the number of steps and screens
presented to the user and track the access channel used as this information may be valuable in
customer service and during disputes.
Customer user interfaces should address authentication and branding, obtain information (e.g.,
sender, recipient, and money transfer amount), and provide transaction confirmation, receipt
information, disclosures, and customer service details.
2.4.2 Consumer Data Collection and Sender Authentication
Acquirers are responsible for ensuring that all OCT-based programs are collecting and verifying
sender data in accordance with local AML laws and regulations.
Acquirers, service providers, and merchants must collect sender and recipient data and are responsible
for verifying the sender, regardless of the payment method or the access channel, for the purpose of
risk, sanctions enforcement and anti-money laundering and anti-terrorist financing control.
Acquirers, service providers, and merchants should consider how they would collect sender and
recipient data and verify sender data in each customer segment supported. The sender authentication
method should be appropriate to the access channel and should follow regulatory and industry
standards and best practices. Examples are government-issued photo identification, ATM PIN, Internet
banking identification and password, and telephone banking PIN/password.
When enabling channels such as ATMs and mobile devices, acquirers, service providers, and
merchants may want to consider requiring senders to register, either online or at a bank branch, prior
to the use of these channels.

When collecting card account data, acquirers, service providers, and merchants should consider
performing a Modulus-10 Check to ensure that the sender’s and recipient’s Visa account numbers
have been entered correctly.
Note: Acquirers, service providers, and merchants must ensure that the collection of sender and
recipient data and the processes implemented to enable sender authentication are compliant
with the Payment Card Industry Data Security Standard and applicable laws.
Acquirers’, service providers’, and merchants’ risk and compliance teams should review sender data
collection and authentication methods to ensure they follow internal requirements, applicable “Know
Your Customer” (KYC) procedures, and applicable local laws and regulations.
For Funds Disbursement OCT-based programs where the sender is a business or government entity,
the acquirer is responsible for ensuring that due diligence is conducted for each new customer that
uses the OCT-based services. The acquirer is responsible for due diligence regardless of whether the
acquirer itself or a third party on boards the business or government entity.
Note: Recipient card account holder address, card expiration date, or CVV2 are not required to be
collected to initiate OCTs, however, some issuers might decline an OCT if expiration date
and/or CVV2 is not included in the transaction message. Issuers should not decline OCTs solely
due to the absence of expiration date or CVV2. For details, refer to Table 2-7: Terms and
Conditions Considerations, Use of Sender’s and Recipient’s Personal Information.
Refer to Section 2.6: Acquirers, Service Providers and Merchants - Risk Management Considerations for
additional information.
For required sender and recipient data elements specific to each program, refer to Appendix A:
Enhanced Original Credit Transaction (OCT) Data Elements and Processing Rules.
2.4.3 Transaction Screening
Acquirers, service providers, and merchants must implement transaction screening procedures to flag
high-risk transactions for review prior to submission. These should include limits (such as count,
amount, and rolling limits), and other checks to determine whether the sender and/or the recipient are
on any applicable government or bank-specific blocked lists.
Refer to Section 2.6: Acquirers, Service Providers and Merchants - Risk Management Considerations for
additional details.
Note: Merchant/service providers and their acquirers approved by Visa to offer domestic Money
Transfer programs via OCTs must also ensure that both of the following entities fall within the same
country:
 the sender’s source of funds for the Money Transfer, and
 the recipient’s account.

Merchant/Service Providers offering these programs are required to carry out this validation prior to
initiating the OCT, as part of the conditions of their program approval. Merchant/Service Providers
must have appropriate controls to satisfy this requirement.
2.4.4 Confirmation of Funds Transfer
Depending on the type of payment, (e.g., P2P Money Transfer, Funds Disbursement, prepaid card load,
Credit Card bill pay, etc.), acquirers, service providers, and merchants may need to provide senders
with a way to confirm the payment including the amount, currency conversion rates, and recipient
details prior to executing the payment. This is an important step as it allows the sender to confirm all
details are correct and it helps reduce customer service issues and disputes.
All fees, currency conversion rates, and any foreign exchange markup must be disclosed to the sender
in accordance with applicable laws and regulations. Refer to Section 2.5: Acquirers, Service Providers
and Merchants - Customer Considerations.
2.4.5 Transaction Receipt and Notifications
Merchant transaction receipts must comply with Visa Rules and applicable local laws and regulations.
Merchants may want to consider including the following information in either the actual receipt or a
separate transaction record:
 Sender name
 Recipient name
 Sender account number (masked and/or truncated)
 Date and time of transfer
 Amount of transfer in the sender’s currency and/or recipient’s currency
 Total amount paid (i.e., amount of transfer plus any fees)
 Fees associated with the transaction
 Foreign currency conversion rates for cross-border transactions
 Sender Reference Number
 Description (e.g., Money Transfer)
Acquirers, service providers, and merchants should consider providing senders and recipients with
notifications related to funds transfer transactions. Notifications are defined as emails and/or SMS/text
messages to senders and recipients to provide them with the status of the transfer. They are
particularly important for web and mobile channels. Within the transfer process, Acquirers, service
providers, and merchants should ask senders if they want a notification provided to them or the
recipient and capture sender and recipient email addresses and mobile phone numbers (if available):

 For sender notifications, acquirers, service providers, and merchants should consider providing
date and time, amount, recipient name, transfer status, and other related information.
 For recipient notifications, acquirers, service providers, and merchants should consider providing
date and time, amount, sender name, and other related information.
For CEMEA transaction receipt requirements, refer to Appendix H: CEMEA-Specific Requirements for
Money Transfer.
2.4.6 Currency Conversion
Currency conversion takes place on transactions where the sender’s transaction currency is different
from the billing currency of the recipient’s Visa account.
To support currency conversion, acquirers, service providers, and merchants can utilize Visa’s currency
conversion service. Although the final rate is not known until VisaNet clearing and settlement has
been completed, acquirers, service providers, and merchants can provide senders with an indicative
rate and an estimate of the amount the recipient will receive in the recipient’s billing currency.
Acquirers, service providers, and merchants can use the Visa Direct APIs, the Foreign exchange rate
look up API, or the Visa Currency Conversion Rate Update File (TC56 file) to look up the foreign
exchange rate of a currency pair. The Visa Direct APIs also provide the acquirers, service providers and
merchant with a calculation of the destination amount (a conversion of the amount in the sender’s
currency to the amount in the recipient’s currency).
Note: The Visa Direct API can also be used to look up the recipient’s billing currency.
Alternatively, acquirers, service providers, and merchants can perform their own currency conversion
for the Money Transfer amount using the following options:
 Sender specifies amount in sender currency, using the API or ACNL look up to provide an estimate
of recipient currency amount
 Sender specifies amount in recipient currency, merchant applies their own currency conversion to
quote sender currency amount
Note: Acquirers, service providers, and merchants should be aware that there may be situations
where they send a Money Transfer in a sender’s transaction currency that they believe is below
the billing currency of the recipient issuer limit, but the foreign exchange rate that Visa applies
to the transaction amount results in the limit being exceeded and the transaction being
declined.
Note: The requirements related to the Dynamic Currency Conversion (DCC) indicator as outlined in
the VisaNet Technical Specifications are not applicable to Money Transfer-related OCTs and
AFTs.

2.4.7 Recipient Registry and Recurring Transactions
A sender may send funds to the same recipient on a regular basis. This can be set up as a recurring
transaction. To facilitate recurring transactions, acquirers, service providers, and merchants should
consider the following to allow the sender to quickly and easily send funds to one of their frequent
recipients:
 Set up a recipient registry with the recipient’s name and account number
 Provide easy access to the registry to look up the recipient
 Specify the funding account
 Define the interval for sending funds.
2.5 Acquirers, Service Providers, and Merchants – Customer

Considerations
Information provided in this section is intended to identify key considerations (some of which are
mandatory) for acquirers, service providers, and merchants in developing their terms and conditions.
This should not be taken as legal advice. Acquirers, service providers, and merchants should seek their
own legal advice when implementing an OCT-based service.
2.5.1 Providing Description of Fees (Mandatory)
Acquirers, service providers, and merchants must provide senders with information related to fees and
other material terms in connection with their OCT-based service. A clear itemized description of all
acquirer, service provider, and merchant-assessed fees, including foreign exchange fees, if applicable,
associated with the transaction must be communicated to senders. Senders must be provided with the
opportunity to agree to the fees and proceed with or cancel the transaction.
When different sender and recipient currencies are involved, acquirers, service providers, and
merchants should provide senders with the currency conversion rate, if known, or an indicative rate.
All fees, currency conversion rates, and any foreign exchange markup must be disclosed to the sender.
Acquirers, service providers, and merchants should consider notifying senders of the following:
 Base exchange rate
 Currency conversion markup fixed by the acquirers, service providers, or merchant
 Final currency rate offered to the sender
 Foreign currency fees that were incurred by the sender in the transaction

2.5.2 Developing Terms and Conditions (T&Cs)
Acquirers, service providers, and merchants must provide the terms and conditions for their service.
This service must not be represented as being provided by Visa. It is strongly recommended that
Acquirers, service providers, and merchants prompt senders to agree to/accept the terms and
conditions prior to sending any transactions and retain evidence of such consent.
The terms and conditions provided to customers should include, but not be limited to, the topics
described in Table 2-7.
Table 2-7: Terms and Conditions Considerations
Topic Considerations
Product/Service Acquirers, service providers, and merchants should provide clear description and
Description details of product/service functionality and features.
Security of PINs and  Customers should protect PINs and passwords.

Passwords  Acquirers, service providers, and merchants should provide customers with
customer service contacts should the security of PINs/passwords be
compromised.
Limits  Right of the acquirers, service providers, and merchants to apply maximum
transaction and/or volume limits
 Details of limits
Fees/Charges  Sender agrees to pay fees (set out in transaction fee schedules)
 Fees may include service fees, cancellation fees, fees for returns and refunds,
and foreign exchange fees
 Sender should be aware that the issuer may charge fees to the recipient
Use  Who can participate
 Whether the service is domestic, cross-border, or both and, where applicable,
which currencies are supported on cross-border transactions
 How the transaction may be funded (e.g., cash, bank account, Visa account)
 What channels are supported (e.g., Internet, kiosk, ATM, mobile), including any
restrictions/terms of service
 Right of refusal (e.g., the acquirers, service providers, or merchant may refuse
to accept the funding source without reason or explanation)
 How the sender will be informed if a funds transfer is not possible and what
this means to the sender’s account
 P2P Money Transfers are not to be used by merchants as a replacement for
purchase transactions.
Sending Funds  The sender will not send funds for illegal, unlawful, or fraudulent activity.
 The sender is wholly responsible for providing the correct Visa account number
of the recipient as well as the correct Money Transfer amount.

Topic Considerations
Use of Sender’s and  Personal information collected from a Visa cardholder as part of a Visa Direct
Recipient’s Personal service must only be used for activities related to the Visa Direct service.
Information  The following information can be requested from senders using a Visa card to
fund a Visa Direct transaction for use in card and cardholder verification:
- Cardholder address (for account verification check)
- Expiration date
- CVV2
 Acquirers, service providers, and merchants are prohibited from storing the
CVV2 information following authorization of a Visa transaction. If card account
number and expiration date are stored, data must be stored in accordance with
the PCI DSS.
 Recipient card accountholder address, card expiration date, or CVV2 are not
required to be collected to initiate OCTs.
See Section 2.5 for more information on risk management and requirements related
to cardholder data and verification.
Compliance The acquirer, service provider, and merchant reserves the right at any time to block
or reject transactions that would or may infringe on legal or regulatory
requirements in either the sender’s or the recipient’s country.
Liability  Merchant and sender liability associated with the transaction

 Merchant policies in the case of sender error (i.e., sender initiated the
transaction to the wrong account number or sent the wrong amount)
Dispute Policies and  Clear dispute policies and procedures including information to the sender in
Procedures case of a dispute such as a customer service telephone number or an email
address
- Refer to Chapter 5: Exception Processing for additional information.
Funds Availability  Any delays in availability of funds
 The fact that the sender should contact the acquirers, service providers, or
merchant if the recipient has not received funds within the specified timeframe.
Contact Information Acquirers, service providers, and merchants should provide relevant customer
service information, such as phone numbers, website URLs, and/or an email
address to the sender.
2.6 Acquirers, Service Providers, and Merchants – Risk Management

Considerations
Acquirers, service providers, and merchants must comply with the Visa Rules and local laws and
regulations, including applicable sanctions and “Know Your Customer”, anti-money laundering, and
anti-terrorist financing laws. If an acquirer uses a service provider to support any aspect of their Visa

Direct OCT program (e.g., risk management, customer service, etc.), the acquirer must ensure service
providers, as well as merchants, are also compliant.
Before implementing any program, acquirers, service providers, and merchants should complete a
comprehensive risk assessment of their business policies and practices, fraud prevention and
detection techniques, anti-money laundering program and other risk controls. In addition to the
recommended fraud prevention tools, acquirers, service providers, and merchants should ensure
adequate practices are in place to minimize fraud losses and excessive customer service inquiries.
For specific legal and regulatory compliance considerations, refer to Chapter 7: Regulatory Compliance
and Legal Considerations.
2.6.1 Fraud Detection and Prevention
Fraud prevention should occur on both the funding transaction (e.g., AFT or on-us proprietary
message) for Money Transfer programs as well as on the OCT for all types of programs.
The acquirer, service provider, and merchant have little recourse with the issuer if the funding
transaction proves fraudulent. Risk management tools for the funding transaction should be built into
processing systems to detect and prevent fraud, errors, sanctions, violations, and money laundering
and terrorist financing.
Such tools include government-issued photo identification, ATM PIN, Internet or telephone banking
identification and password, CVV2 verification, Verified by Visa, Address Verification Service (AVS),18
negative files and screening, and systems control tools to identify processing errors and suspicious
activity.
While fraud reporting on an OCT is generally low, acquirers, service providers, and merchants must
still have processes in place for monitoring OCTs to recipient accounts to identify suspicious activity,
potential fraud, and misuse of OCT programs. See Section 2.6.3: Transaction Monitoring and Controls
for requirements and recommended best practices on OCT monitoring.
For more information and best practices on managing risk related to Account Funding Transactions
(AFTs), refer to the Visa Account Funding Transaction (AFT) Processing Guide.
Note: CVV2 and/or AVS checking associated with the AFT can be accomplished using the Visa
Direct APIs. “Verified by Visa” applies only to AFTs (i.e., sender verification) and not to OCTs.
18AVS is available in the U.S., Canada, UK, and Ireland. Check with your regional Visa representative for availability of
verification tools.

2.6.1.1 Data Security – PCI Compliance
Acquirers, service providers, and merchants must ensure that the data contained in OCTs and any
other sender or recipient data collected during the transaction is handled in compliance with the
Payment Card Industry Data Security Standard (PCI DSS) and applicable law.
Sound data security practices reduce fraud risk and also foster customer confidence in the secure
handling of personal information.
Acquirers, service providers, and merchants should:

 Implement procedures to control employee access to customer account data and ensure that
customer service screens and customer receipts do not display full account numbers.
 Legislation in most countries requires personal and financial information about customers involved
in funds transfers to be collected and stored by the service provider according to set standards of
security and accountability.
2.6.1.2 Transaction Identification and Tracking
The ability to identify and track customer transactions is a key element to quick, inexpensive resolution
of customer inquiries and disputes. Acquirers, service providers, and merchants should use the
Transaction Identifier (Field 62.2) to enable efficient identification, reconciliation, and tracking of
transactions.
If an Account Funding Transaction (AFT) precedes the OCT, acquirers, service providers, and merchants
are recommended to populate the Transaction Identifier from the AFT in the OCT to link the two
transactions together.
For more information on AFTs, refer to the Visa Account Funding Transaction (AFT) Processing Guide.
2.6.1.3 User Interface Controls
Implementing appropriate controls within the customer interface can greatly reduce customer
inquiries and back-office processing costs. Acquirers, service providers, and merchants may choose to:
 Ensure the recipient’s account is not blocked from receiving OCTs.
 Notify senders of potential delays.
 Perform an exact calculation of service fees at the time of the transaction.
 Display a “transaction being processed” message during wait time.

2.6.2 Transaction Limits
Acquirers, service providers, and merchants must adhere to transaction limits for each funds transfer
type as identified by Business Application Identifier (BAI). Limits vary by jurisdiction, country, and
program basis.
Acquirers, service providers, and merchants should confirm that the funds transfer amount is equal to
or less than the Visa limits.
For specific country and program limits, refer to Appendix A: Enhanced OCT Data Elements and
Processing Rules, Field 4 Amount Transaction.
The following transaction limits have recently been updated and are outlined here for reference:
 Transaction Limits— For domestic and cross border enhanced Money Transfer OCTs, Acquirers,
service providers, and merchants cannot send more than US$2,500.00 in a single OCT, unless Visa
permits a higher country limit. For other, higher domestic Money Transfer limits, refer to Appendix
A.
For other OCTs, the VisaNet system edit/transaction limit is US$50,000.00, although lower limits
may be defined on a country or program basis – see Appendix A.
Note: Transactions above these limits will be rejected by VisaNet.
 U.S. Non-Money Transfers: The VisaNet system edit/transaction limit for all U.S. domestic non-
Money Transfer OCTs (Funds Disbursement, prepaid load, credit card bill payment, etc.) was
changed from US$10,000 to US$50,000.
 Europe Non-Money Transfer: Transaction limit for non-Money Transfer was decreased from
80,000Euro to 50,000USD.
 Canada Domestic Money Transfers: The VisaNet system edit/transaction limit for all Canada
domestic Money Transfer OCTs increased from US$2,500 to US$10,000.
Velocity Limits
Acquirers should also be aware that VisaNet implements maximum velocity limits for OCTs by count
and amount. These are the maximum number or dollar amounts of OCTs that a single recipient can
receive in any 1, 7 or 30-day period. Any OCTs in excess of these amounts will be declined by VisaNet.
Acquirers, service providers, and merchants should ensure that they are not allowing senders to send
OCTs to single recipient accounts in excess of the VisaNet limits. Limits are outlined in Table 2-8.
Note: In the U.S., inbound cross-border OCTS are blocked by VisaNet. These blocks may be removed
upon request and approval by Visa on a case-by-case basis only.

Table 2-8: Transaction Limits - Velocity Limits
Key:
2 Money Transfer/Person-to-person (PP), account-to-account (AA), or wallet transfers (WT).
3 Funds Disbursement/Non-Money Transfer - Funds Disbursement, insurance settlement, payroll, government disbursement,
etc.
2.6.3 Transaction Monitoring and Controls
Acquirers, service providers, and merchants of OCTs must establish controls and monitor transaction
activity for signs of fraud as well as misuse of the OCT for the payment of goods and services.
Controls and monitoring for fraud, including money laundering and terrorist financing, should include:
 Transaction controls and velocity limits based on transaction risk (e.g., by use case – P2P Money
Transfer vs. Funds Disbursement, domestic vs. cross border transactions, etc.)
 Suspicious activity monitoring, for example:
 A significantly large number of transactions initiated by a single sender to multiple recipients
within a specified time period.
 A large number of transactions from multiple senders to the same recipient account within a
specified time period.
 A high number of OCTs followed by disputes, especially involving the same sender and/or
recipient.
 Corridor definition for payments and watch list screening:
 Define the countries to which OCTs will be allowed to be sent.
 Screen senders and recipients against relevant watch lists per applicable local laws and
regulations. Specific issuers, countries, or products may be blocked from receiving OCTs in
VisaNet.
 Ensure that the sender and the recipient are not on any applicable government or bank-specific
blocked lists (e.g., Office of Foreign Asset Control (OFAC) list). If the sender is already a
customer of the acquirer, service provider, or merchant, he/she may have already been

screened as part of the acquirer’s, service provider’s, or merchant’s ongoing customer due
diligence program and may not need to be screened again.
 Include sender and recipient data as required in the Money Transfer regulations.
Note: Visa applies all current restrictions regarding cross-border purchase transactions to OCTs.
For example, due to U.S. government restrictions, U.S. banks may not send or receive OCTs
from comprehensively sanctioned countries including to Crimea, Cuba, Iran, Syria, North
Korea and Sudan. For a list of the blocked countries, refer to Chapter 4: Bank Identification
Number (BIN) Blocking.
To mitigate against the risk of the misuse of the OCT for the payment of goods and services (OCTs
alone cannot be used for the payment of goods and services), acquirers, service providers, and
merchants must establish and enforce per transaction and cumulative velocity limits for OCTs. Limits
may include, but are not limited to:
 Per transaction count and amount limits by day, week, and month.
 Set limits on the number of P2P Money Transfers that can be initiated and sent from/to any single
account in any given day, week, month.
2.6.3.1 Acquirer Velocity Controls
Acquirers 19who support service providers and merchants using Visa Direct APIs have the ability to
establish limits by count and amount at the BIN or merchant level to manage fraud and settlement
risk. Acquirers also have the ability to receive notifications when any established thresholds have been
breached, enabling them to stop transactions until further due-diligence has been performed.
Access to set acquirer controls is managed via Visa Online.
For information on how to obtain access to or manage acquirer velocity controls please contact your
regional Visa account manager.
2.6.4 Watch List Screening
Acquirers, service providers, and merchants must screen senders and recipients against relevant watch
lists per applicable local laws and regulations, such as government or bank-specific block lists.
Acquirers, service providers, and merchants should check whether the issuer can receive OCTs. To
comply with local regulations, specific issuers, countries, or products may be blocked from receiving
OCTs in VisaNet.
19 Acquirer velocity control functionality is now available to all regions.

At their discretion, acquirers, service providers, and merchants can define the countries to which they
will allow OCTs (i.e., corridor definitions).
For a list of the blocked countries, refer to Chapter 4: Bank Identification Number (BIN) Blocking.
For more information on Visa’s Watch List Screening Service for recipient issuers, see section 3.12.5
Watch List Screening Service.
2.6.4.1 International and Country-Specific Regulatory Restrictions
On cross-border transactions, acquirers, service providers, and merchants should check to ensure that
the country that the recipient resides in is part of the acquirer’s, service provider’s, and merchant’s
program (as defined in the acquirer submitted PIF).
Note: Visa applies all current restrictions regarding cross-border purchase transactions to OCTs. For
example, due to U.S. government restrictions, U.S. banks may not send or receive OCTs to
comprehensively sanctioned countries.
2.6.4.2 Government or Bank-Specific Lists
Acquirers, service providers, and merchants should ensure (per applicable local law or regulation) that
the sender and the recipient are not on any applicable government or bank-specific blocked lists (e.g.,
Office of Foreign Asset Control (OFAC) list). If the sender is already a customer of the acquirer, service
provider, or merchant, he/she may have already been screened as part of the acquirer’s, service
provider’s, or merchant’s ongoing customer due diligence program and may not need to be screened
again.
2.7 Acquirers and Merchants – SMS Reconciliation
SMS acquirers and merchants may apply their existing reconciliation practices to OCTs. General
considerations may include the following:
 Step 1: Match the end of day SMS reports from Visa with the SMS raw data from the acquirer or
merchant’s Switch log.
Note: The acquirer’s or merchant’s Switch log should have more transactions than SMS raw data
since the SMS raw data only contains settled transactions.
 Step 2: Identify the following scenarios:
 Scenario 1: Transaction appears successful in SMS reports/SMS raw data but appears
unsuccessful/with an error on the Switch log or vice versa.
 Scenario 2: Transaction appears on SMS reports but does not appear on the Switch log.
 Scenario 3: Transaction appears on Switch log but not on SMS reports (this situation could be
a result of transactions that have not yet settled).

 Step 3: Place transactions associated with Scenario 1 and Scenario 2 into an exception queue for
manual intervention and analysis.
Note: Acquirers or merchants will need to match time-zones across their Switch log, SMS reports,
and SMS raw data to facilitate transaction matching.
In addition to using SMS raw data, acquirers should consider using the Visa-generated Visa
Settlement Service (VSS) reports for an overview of settled transactions and applicable interchange.
Contact your Visa account representative for information on subscribing to receive the Visa VSS and
SMS reports.
Note: Only Visa acquirers can receive Visa-generated VSS reports.
Refer to Appendix B: Sample Reports for examples of reports.
2.8 Acquirer– Reports
OCTs are incorporated into existing VisaNet reports. For samples of Visa Settlement Service (VSS)20
and Single Message System (SMS) reports refer to Appendix B: Sample Reports.
Acquirers should refer to the VisaNet Settlement Service (VSS) reports for information on OCTs. For
information on OCT-related interchange, refer to the VSS-120, VSS-130, VSS-130-M, and VSS-135
reimbursement fees reports where OCTs are identified through the fee descriptor.
In addition to the settlement reports available from VSS, merchants and acquirers can use the
applicable SMS reports. For information about settlement, refer to the Visa Settlement Funds Transfer
Guide.
The Sender Reference Number is provided in SMS Raw Data, positions 106-121; the Business
Application Identifier (BAI) is provided in positions 22-23; and, the Source of Funds is provided in
position 24.
Refer to the VSS User’s Guide, Volume 2, Reports for details.

Note: Due to data security reasons, all other sender data is removed and not present in SMS Raw
Data.
20 VSS reports are only available to Visa acquirers

2.8.1 Report Delivery Mechanisms
Visa offers acquirers, service providers, and merchants options for receiving reports in addition to the
more traditional means of receiving via an acquiring VisaNet processor (e.g., SMS and BI/BII endpoint
connections). Below are additional options that can be configured for report delivery.
Acquirers, service providers, and merchants should contact their Visa representative to discuss delivery
options available in their markets.
2.8.1.1 Acquirer Reports via Visa Online
Visa Direct uses Visa Online (VOL) to deliver content, applications, and collaboration tools. In addition
to implementation guides, onboarding material, risk framework and, best practices, acquirers can
obtain access to reports via VOL to support their Visa Direct programs. Acquirer reports available
include:
 Visa Direct Transaction Reconciliation Report – This report provides end-of-day transaction and
exception data at the BIN level to support reconciliation. Other data elements such as the Card
Acceptor ID (CAID) are also provided to facilitate easy reconciliation. Refer to Section 2.8.2 Visa
Direct Transaction Reconciliation Report (TRR).
 VSS Reports – Acquirers who do not utilize services of an acquirer processor will be provided
access to VSS reports. Currently the following reports are available at the Settlement Reporting
Entity (SRE) level within a BID.
 VSS 110 – Settlement Summary Report (mandatory)
 VSS110-M – Monthly Settlement Summary Report (mandatory)
 VSS 115 – SRE Settlement Recap Report
 VSS115-M – Monthly SRE Settlement Recap Report
 VSS 120 - Interchange Value Report
 VSS 130 - Reimbursement Fees Report
 VSS130-M – Monthly Reimbursement Fees Report
 VSS 140 - Visa Charges Report
 VSS 300 – SRE Financial Recap Report
 VSS 900 - Reconciliation Report Additional VSS reports may be made available in future
releases.
For information on how to obtain access to Visa Direct reports on VOL, please contact your regional
Visa account manager.

2.8.1.2 Visa File Exchange Service (VFES)
VFES is Visa’s public internet-based file transfer offering that routes non-clearing and settlement files
(less than 2 GB). VFES allows endpoints to securely send and receive smaller files over the public
Internet directly to/from Visa. VFES is an encrypted FTP Session (over SSL or SSH) using strong
authentication, client digital credentials, and IP whitelisting to provide robust security. It allows Visa
clients to receive Visa report files such as the ACNL file, VSS and SMS raw data reports that are needed
to effectively manage Visa Direct programs.
Note: Visa clients may not use data provided to them by Visa, including but not limited to transaction,
reporting and the ACNL file, in support of a Visa Direct program for any purpose other than as
necessary to operate the Visa Direct program.
Visa requires a 6–10 week lead time to set up and test new file types for existing VFES endpoints, and
a 10–12 week lead time to set up and test new VFES endpoints.
For more information on VFES or to initiate a VFES implementation project, refer to the Visa File
Exchange Service (VFES) Implementation Guide or contact your Visa representative.
2.8.2 Visa Direct Transaction Reconciliation Report (TRR)
The Visa Direct Transaction Reconciliation Report (TRR) is available to acquirers via a Visa Direct API
and VOL. The TRR provides a sub-set of information that is available in a full SMS raw data report. This
report provides key data elements that may be needed to reconcile Visa Direct transactions. A sample
of the report can be found in Appendix B: Sample Reports. The TRR is delivered in a machine readable
CSV format and includes the following data elements:
 Processing Date
 Acquirer BIN
 Visa Transaction ID
 Transaction State
 Reason Code
 Card Acceptor ID
 Card Acceptor Name
 System Trace Audit number
 Account Number
 Transaction date, time, amount and currency
 Authorization Code
 Retrieval Reference Number (RRN)
 Fee Program Indicator (FPI) and description
 Settlement date and time

For more information on the Visa Direct APIs and their availability in your region or country, contact
your regional Visa representative. In addition, refer to the Visa Developer Center at the following
address: https://developer.visa.com/products/visa_direct.
2.9 Acquirers, Service Providers, and Merchants – Training and

Customer Service
Acquirers, service providers, and merchants should ensure all customer service and customer-facing
staff and agents are trained on the Visa Direct product.
Customer service staff should be able to assist consumers with queries relating to:
 Product information
 Transaction processing status
 Unsuccessful transactions
 Disputes
In the event of an unsuccessful delivery of funds to a recipient, acquirers, service providers, and
merchants should have the appropriate procedures in place to refund the sent amount to the sender.
To support this, acquirers, service providers, and merchants should obtain sender contact details that
will allow them to notify and return the transaction to the sender. Local legal and regulatory
requirements may apply with regards to returning funds to a sender.

Recipient Issuer Requirements and Considerations
3 Recipient Issuer Requirements and Considerations
3.1 Recipient Issuers – General Program Considerations
This section provides recipient issuers with general program considerations related to OCTs.
3.1.1 General Visa Compliance
Recipient issuers must comply with the Visa Core Rules and Visa Product and Service Rules, which
include the following requirements:
 All Visa credit, debit and prepaid21 issuers must accept an incoming Original Credit Transactions
(OCTs) unless prohibited by applicable laws or regulations. If prohibited by applicable laws or
regulations, the issuer must submit a written request to Visa to block incoming Original Credit
Transactions.
 OCTs can only be received into a valid and eligible Visa account.22
 Issuers are prohibited from allowing any OCT to a card that does not have “Know Your Customer”
Information on file (such as non-reloadable BAIs), and any account that is prohibited from
receiving OCTs per government regulations or other restrictions.
 Issuers must make funds available to recipient cardholders within two business days of receiving
the OCT message unless otherwise mandated to meet the Visa Fast Funds rules where funds must
be made available to cardholders within 30 minutes of approving an OCT23. Refer to Section 3.10:
Recipient Issuer—Funds Availability.
 Issuers must decline an OCT authorization or dispute specific transactions when the funds cannot
be posted into the recipient account. Refer to Chapter 5: Exception Processing.
 Issuers must inform Visa of any prohibitions with respect to their receiving OCTs on all or part of
their Visa account base. These accounts will then be blocked in VisaNet from receiving OCTs. Refer
to Chapter 4: Bank Identification Number (BIN) Blocking.
21 OCTs are mandated for all reloadable prepaid card accounts but are not permitted on non-reloadable prepaid or prepaid
card accounts where cardholder data is not on file or where the source of loads may be restricted (e.g., government,
healthcare and insurance programs).
22 In Canada as of April 2018, this will also include proprietary accounts with PLUS network capability.
23 In Europe the requirement is to make funds available to recipient on the same business day as the receipt of clearing and
settlement message.

Table 3-1: Recipient Issuer Forms
Form Requirements
Client Information Conditional

Questionnaire (CIQ) Issuers who can process OCTs under the Fast Funds rules are required to
(or geographical equivalent) submit a CIQ to Visa so that their BINs can be configured for Fast Funds in
Visa systems. This will:
 provide critical information to acquirers, service providers, and
merchants to help them understand the speed for which OCTs will be
made available to cardholder’s accounts
 insert a Fast Funds indicator in the TC06 clearing message for Fast
Funds enabled dual message BINs
 have an impact on interchange.
Third-Party Agent Registration Conditional

Required if the issuer is using a third party agent in the management of any
aspect of their Visa issuing program.
3.1.1.1 Working with Third-Party Agents
Recipient issuers may choose to work with third party agents to support the receipt of OCTs or their
card issuing programs. Third-Party Agents are not connected to VisaNet for authorization, clearing
and settlement. Recipient issuers must ensure that all Third-Party Agents are registered with Visa as
outlined in the Visa Core Rules and Visa Product and Service Rules and are compliant with PCI DSS.
Note: Recipient issuers that contract with Third Party Agents are fully responsible for all cards issued
by them and solicited, sold, marketed or processed by the companies or organizations with
which they contract.
TPA program, or contact your regional Visa representative.

3.2 Recipient Issuers – Requirements for Receiving and Processing

OCTs
All Visa issuers are required to receive and process all types of OCTs (regardless of Business Application
Identifier (BAI)) to eligible Visa accounts24.
This section outlines:

 Changes issuers must make to their host systems to support incoming OCTs
 Processing requirements for non-U.S. and U.S. issuers.
As of April 2019, acquirers and issuers globally may optionally support SMS 0200 OCTs for Visa-
branded products on Network 4 (PLUS network).
For regional requirements related to support of enhanced OCTs and Fast Funds, refer to
Section 3.10.4: Fast Funds.
3.2.1 Receiving and Processing OCTs
Europe region
In the Europe region, Visa requires issuers to process all Money Transfer 0100 or 0200 messages for
OCTs online, that is, no Stand-in Processing (STIP), whether they support Fast Funds or not.
If the recipient issuer supports Fast Funds, it must process the OCT as either a 0100 message followed
by a TC06, or as a 0200 message. For Fast Funds requirements in Europe, refer to Section 3.1.1 General
Visa Compliance.
U.S.
U.S. issuers are required to receive and process OCTs as a 0200 full financial message or a 0100
message followed by a TC06 (they may not receive them as a TC06 only).
U.S. issuers may enable OCT and Fast Funds posting capabilities on Network 2 (Visa network), Network
3 (Interlink network), or on Network 4 (PLUS network) and must enable OCT and Fast Funds
capabilities on at least one of these networks, but not all. Based on issuer direction via the Client
Information Questionnaire (CIQ), Visa will be able to route an incoming OCT to the issuer’s network of
choice.
24 Eligible Visa accounts include all credit, debit, and (unless prohibited by local law) reloadable prepaid card accounts.

Refer to Appendix G: U.S. OCT Switch Service for additional information.

Note: U.S. BINs will continue to be blocked for all incoming cross-border OCTs and gambling OCTs
initiated from MCC 7995. MCC 7995 will be in effect October 18, 2019 for select U.S face-to-
face gambling establishments.
Canada
Canadian issuers are required to receive and process OCTs as an SMS 0200 message for debit and
reloadable prepaid products. As of April 2018, the same requirement applies to proprietary products
with PLUS network capability.
All other Markets
If the recipient issuer supports Fast Funds, it must process the OCT as either a 0100 message followed
by a TC06, or as a 0200 message.
3.2.2 Optional Issuer Fee (OIF) Processing
OIF processing is suppressed for all enhanced 0200 OCTs. OIF processing is not suppressed for OCTs
initiated as basic 0200s or TC06s.
Note: OIF processing still applies to enhanced, Funds Disbursement/non-Money Transfer 0200 OCTs
sent to the Europe Region.
3.3 Recipient Issuers – Applying OCTs to Visa Account Types
Recipient issuers can apply an incoming OCT to any of the following Visa account types.
Table 3-2: Visa Account Types
Visa Account Types Description
Visa Credit Accounts An OCT to a Visa credit account serves as a payment to the account.
Recipient issuers must apply an incoming OCT to a Visa credit account as

a payment to the line of credit and not as a refund.
Visa Debit Accounts An OCT to a Visa debit account serves to add value to the underlying
bank account associated with the Visa debit account.
Visa Reloadable Prepaid Accounts An OCT to an eligible Visa prepaid account serves to add value to the
prepaid account balance.

Visa Account Types Description
Visa Deferred Debit Deferred Debit cards have a line of credit and an underlying bank
account. An OCT to a Visa Deferred Debit account serves as a deposit to
the underlying account when both the line of credit and underlying
account are with the same bank.
If the Deferred Debit card underlying account is with a different bank than
the line of credit, it is appropriate to post the funds to the card account.
Visa Combo Card (Brazil) Combo cards give cardholders the option to use credit or debit
functionality during a transaction. An OCT to a Visa Combo card account
and processed as debit serves to add value to the underlying deposit
account linked to the card.
The credit balance owed on the card is not impacted by the receipt of the
OCT, funds will only be applied to the debit balance in the deposit
account. The OCT for combo cards should not be presented as credit
using the proper values specified in Field 3 described in Appendix A.
Deposit-only Account Numbers An issuer may establish a Visa account number as a deposit-only account
number used exclusively to receive OCTs (and related exception items) on
behalf of one of its customers. These accounts must follow the Visa Rules
for Deposit-only Account Numbers.
Please contact your regional Visa representative for details.
3.3.1 Special considerations for Credit Cards
There may be situations where the OCT results in a positive credit balance to the Visa credit account
and as a consequence, change the status of the credit card account. This may require issuers to take
specific steps to comply with specific legal and/or regulatory requirements. Customer service,
customer expectations, and the standing of an account should be considered when developing a
policy for applying OCT funds to a Visa credit account.
In addition, issuers should consider the impact on the following:

 Re-ageing of a credit account that was not in good standing.
 The application of service fees, over-limit fees, overdraft fees, cash advance fees, and late payment
fees to credit accounts.
 Credit line increases triggered by funds sent to a credit account balance.
 OCTs funded by credit accounts that are sent to other credit accounts. Issuers can identify OCTs
funded by credit accounts through the Source of Funds field (Field 104, Dataset ID 5F, Tag 08) (if
present).

Note: Issuers may wish to apply different policies for increasing credit lines when the cause of the
improved credit account status was from one or more OCTs, rather than standard payments by
the Visa cardholder.
3.4 Recipient Issuers – OCT Enhanced Data Element Requirements
This section provides a high-level overview of the enhanced OCT data element an Issuer must be
prepared to receive to identify an OCT. The V.I.P. fields and BASE II TCRs are referenced in this section.
For detailed information on enhanced 0200 messaging, refer to Appendix A: Enhanced OCT Data
Elements and Processing Rules.
For information on the enhanced TC06 format, refer to Appendix F: Enhanced TC06 OCTs.
Table 3-3: Key Enhanced OCT Data Elements
Field Name VIP Base II Definition

Field Name Field Name
Primary Account Number Field 2 TCR 0 Recipient’s account number
Processing Code Field 3 N/A Value of 26 in first two positions of the field
Transaction Code N/A All TCRs Value of 06
Transaction Code Qualifier N/A All TCRs Value of 2
Transaction Amount Field 4 TCR 0 Money Transfer OCT:

 Domestic: US $2,500 except for the
following:
o U.S., Canada: US$10,000
o Australia, Russia, Singapore:
US$15,000
 Cross-border: US$2,500
OCT: US$50,000
Refer to Table A-1: Enhanced OCT Data
Elements for more information.


Merchant Category Code Field 18 TCR 0 Merchant Category Code (MCC)

Field 18/TCR 0 An MCC designates the principal trade,
profession or line of business in which a
merchant is engaged, as specified in the Visa
Merchant Data Standards Manual (PDF). Each
acquirer must assign the most appropriate
MCC for its merchant from among those
specified in the Visa Merchant Data Standards
Manual. If a merchant engages in different
types of trade or business, the assigned MCC
must reflect the nature of business for which
the greatest number of the merchant's
transactions are processed.
For more details about BAIs and MCCs, refer
to Section 2.3.4 Business Application Identifier
(BAI), Merchant Category Code (MCC), and Use
Cases.
Money Transfer OCTs:
AA and PP: 6012 or 4829
BI: 6012
WT: 4829
Funds Disbursement OCTs: In a Funds

Disbursement OCT, the sender or merchant is
the business or government entity that is
disbursing funds to a Visa card account
holder. Refer to Section 2.3.4 Business
Application Identifier (BAI), Merchant Category
Code (MCC), and Use Cases.
TU (Prepaid Top Up): 6012 or 6540
CP (Credit Card Bill Pay): 4829 or 6012


Card Acceptor Name/ Field 43 TCR 0 Depending on the type of OCT, this field
Merchant Data contains the name of the entity providing the
OCT-based service and the sender’s name in a
Money Transfer transaction followed by “Visa
Direct” in the merchant city field. For
examples, refer to Appendix A: Enhanced
Original Credit Transactions (OCT) Data
Elements and Processing Rules.
For BAI MD/Merchant settlement – this must
contain the name of the acquirer or payment
facilitator that is sending settlement payments
to the merchant.
This information is provided so that it can
appear on the recipient’s statement.
Prepaid Balance Field 54 N/A TU (Prepaid Load):

LAC Region: On domestic transactions, issuers
are required to provide prepaid account
balance information in this field in response
messages. Merchants need to be prepared to
receive the prepaid account balance in this
field and they must provide this information
to the load partner for displaying to the
customer.
Other Countries: In other countries, issuers
may optionally return the prepaid balance in
this field. Merchants need to be prepared to
receive the prepaid account balance in this
field and they may be required to provide this
information to the load partner for displaying
to the customer. Contact your regional Visa
representative for the requirements in your
country.
Business Application Field 104, TCR 3 Business Application Identifiers

Identifier Dataset ID 57 Refer to Section 2.3.4 Business Application
Identifier (BAI), Merchant Category Code
(MCC), and Use Cases for a list of BAIs.
V.I.P. rejects 0200 OCTs with reject code
0494 (Field or data missing or invalid) if
they do not contain the BAI in Field 104
Dataset ID 57.


Sender Data Field 104, TCR 3 Sender Reference Number (Tag 01) and
Dataset ID 5F Source of Funds (Tag 08)
Sender reference number (Tag 01) or sender
account number (Tag 02) must be present;
both may be present
Source of Funds (Tag 08) must be present on
enhanced Money Transfer OCTs to U.S. issuers
(domestic and cross-border); it is
recommended on all other OCTs.
Sender Data Field 104, Tags 03, 05, Sender Name (Tag 03), Sender City (Tag 05),
Dataset ID 5F and 07 and Sender Country (Tag 07)
 Sender name and address, city, and
country25 (Tag 03 – Tag 0726) must be
present on cross-border OCTs and U.S.,
Europe, and Canada domestic OCTs.
 VIP declines cross-border or domestic
Money Transfers with no national net
settlement service (NNSS) with a BAI of
AA or PP with RC 64 (Transaction does not
fulfill AML requirements). Refer to Section
1.1.1 Identifying Domestic and Cross-
border OCT Transactions.
 Sender Name Tag 03 – For BAI MD –
Merchant settlements needs to contain
the name of the acquirer or payment
facilitator that is sending settlement
payments to the merchant.
25For Funds Disbursements, this is the merchant/government entity name and address.
26Tag 06 (State/Province) is only required on transactions when the Sender Country (Tag 07) contains the value of 840 (U.S.)
or 124 (Canada).


Sender Data: Sender Name Field 104, Tag 03 Sender Name (Tag 03)
Dataset ID 5F V.I.P. declines 0200 OCTs with a BAI of AA/PP
with RC 64 (Transaction does not fulfill AML
requirements) if the Sender Name (Tag 03) or
Recipient Name (Tag 0A) in Field 104 Dataset
ID 5F, Tag 03 (or 0A), contains:
 ? (Question mark)
 All numerics
 Only one character
Sender Data: Recipient Field 104, Tag 0A Recipient Name (Tag 0A)
Name Dataset ID 5F  Recipient Name (Tag 0A) must be
present on cross-border enhanced Money
Transfer OCTs and domestic Money
Transfers in countries with no NNSS; it is
optional on all other OCTs. Refer to
Section 1.1.1 Identifying Domestic and
Cross-border OCT Transactions.
 V.I.P. declines 0200 OCTs with a BAI of
AA/PP with RC 64 (Transaction does not
fulfill AML requirements) if the Sender
Name (Tag 03) or Recipient Name (Tag
0A) in Field 104 Dataset ID 5F, Tag 03 or
0A, contains:
- ? (Question mark)
- All numerics
- Only one character
Additional Sender Data Field 104, TCR 1 Sender reference number or sender account
Dataset ID 5 number must be present.
Sender address, city, and country27 must be
present on cross-border transactions.
Sender’s address may not be required on
domestic OCTs. If not required under local
AML/ATF laws, tag may be populated with
“not applicable”.
27 For Funds Disbursement, this is the merchant/government entity address.

3.5 Recipient Issuer OCT Authorization Decisions – Declining OCTs
While issuers should always attempt to approve OCTs, they may need to decline OCTs in the following
situations:
 Recipient’s account is closed.
 Recipient’s account is not in good standing.
 Recipient’s account is being monitored or has been flagged for suspicious activity, fraud, or anti-
money laundering.
 Value or velocity limit defined in VisaNet has been exceeded. Refer to Section 3.12.3: Using Visa
Velocity Limit Checking to Mitigate Risk.
 The transaction amount or transaction activity is high or unusual.
 Recipient’s account is a credit account and the issuer’s policies are being violated.
 Recipient’s account is a prepaid account and the amount results in the prepaid amount on the
account being above the maximum amount limit.
 Recipient’s account is not allowed to accept OCTs. Issuers must ensure that these accounts are
blocked in VisaNet from receiving OCTs. For more information, refer to Chapter 4: Bank
Identification Number (BIN) Blocking.
 Recipient’s account is an account that is not permitted to receive funds from other sources (e.g.,
government-issued prepaid accounts that can only be loaded by the government). Issuers must
ensure that these accounts are blocked in VisaNet for OCTs. For more information, refer to Chapter
4: Bank Identification Number (BIN) Blocking.
 Watch List Management (WLM) score of sender exceeds threshold established by issuer or sender
fails AML/AFT screening by the issuer. For more information, refer to Section 3.12.5: Watch List
Screening Service.
 OCTs should be approved or declined.
Note: Recipient issuers should be aware that most OCTs will appear as Card Not Present transactions.
Some issuers request VisaNet to decline online Card Not Present purchase transactions on
their behalf but this will not apply to OCTs.
3.6 Recipient Issuer OCT Authorization Decisions – Approving OCTs
3.6.1 Issuer Option for Receiving/Approving Inbound Cross -Border Enhanced

Original Credit Transactions (OCTs)
Recipient issuers have the option to restrict receipt of POS authorizations to domestic only. Issuers
that restrict their card programs to domestic-use only can choose to receive cross-border enhanced
0200 or 0100 OCTs. This option will apply to all types of OCTs initiated as enhanced 0200s and allows

issuers in countries with high volumes of inbound remittances to accept cross-border enhanced OCTs,
while continuing to maintain their domestic-only card programs.
Note: There is no similar option for issuers to restrict BASE II POS transactions to domestic only.
Issuers with domestic-only programs will continue to receive cross-border OCTs initiated as
TC06s.
To participate, contact your regional Visa representative.
3.7 Recipient Issuers – VisaNet Stand-in Processing (STIP)
When Issuers that are set up to receive and process enhanced 0100 or 0200 OCTs online are not
available at the time of the transaction, VisaNet will decline the OCTs on their behalf (VisaNet never
approves the enhanced OCT on the issuer’s behalf).
In Europe, when Issuers are not set up to receive and process the enhanced 0100 or 0200 OCTs online,
Issuers must request Visa to process the OCT on their behalf. This is not applicable to Fast Funds
transactions.
3.8 Recipient Issuer Host System Testing
VisaNet host testing using the VisaNet Certification Management Service (VCMS) is required for the
following:
 Recipient issuers that are getting enabled to receive OCTs for the first time.
 Recipient issuers that support receipt of the TC06 only and want to upgrade to receive 0100 OCTs.
For information on testing, please contact your regional Visa representative.

3.9 Recipient Issuers – Best Practices for Effective OCT Processing
To ensure a positive cardholder experience, recipient issuers should review their OCT handling
processes by:
 Reviewing and modifying velocity limits so that OCT transactions are not declined because of low
transaction counts and dollar amounts.28
 Ensuring that OCT approval rates are consistent and better than other Visa transactions.
 Implementing clear and accurate messaging on cardholder statements to reflect an OCT.
 Ensure the payment on the cardholder statement is clearly labeled as an Original Credit
Transaction and not labeled as any kind of refund.
 Ensuring that unnecessary or inappropriate fees are not being applied.
 Effective April 2018: Must not apply additional funds transfer fees for consumer cards.
 Ensuring the recipient issuers conduct anti-money laundering (AML) check on the sender.
3.10 Recipient Issuers – Funds Availability
Making funds available to cardholders is defined as the posting and increasing of the cardholders’
open-to-buy or operating limit on their Visa card account. Simple memo posting where the
cardholder cannot have access to the funds is not considered compliant with funds availability
requirements.
Refer to Table 1-1 for the different Visa account types for OCT.
This section provides recipient issuers with information on both Conventional and Fast Funds
availability.
28As push payment services grow, cardholders may begin receiving OCTs that represent more than just P2P. OCTs may also
include Funds Disbursements, such as funds obtained for tickets sold through a ticket broker, disbursements from an
insurance company for a claims payment, etc. Issuers should ensure that their velocity limits can accommodate a variety of
use cases for push payments.

3.10.1 Funds Availability Overview
There are two timeframes for funds availability:

 Conventional Funds Availability—Recipient issuer makes funds available to the recipient’s
account as soon as possible, but no later than 2 business days after receiving the full financial or
clearing message associated with the OCT (or same business day for Europe).
 Fast Funds Availability—Recipient issuer makes funds available to the recipient’s account within
30 minutes of approving the enhanced OCT authorization or full financial request.
3.10.2 Fast Funds vs. Conventional Funds
Table 3-4 provides an overview of Fast Funds vs. Conventional Funds:

 The types of OCTs acquirers, service providers, and merchants can send (i.e., 0200 message or
TC06).
 The types of OCTs issuers can receive. This depends on whether the issuer supports Fast Funds
and whether the issuer is BASE I/BASE II/Dual Message (DMS) or Single Message System (SMS).
Note: Non-U.S. BASE I/BASE II issuers can only receive the 0100 OCT message if they participate
in Fast Funds. Not applicable in Europe.
 Whether the transaction will be processed as Fast Funds or Conventional Funds.
Note: There is no Fast Funds indicator in 0100 or SMS 0200 OCTs sent to issuers. Issuers that are
Fast Funds-enabled must support Fast Funds on all OCTs. Only the TC06 clearing record
may contain a Fast Funds indicator for dual message.

Table 3-4: Fast Funds vs. Conventional Funds
Recipient Issuer BIN Supports Fast Funds Recipient Issuer BIN Does Not Support Fast
Funds
Acquirer, BASE I/BASE II/Dual SMS Issuer BASE I/BASE II/Dual SMS Issuer
Service Message Issuer Message Issuer
Provider,
Merchant
Sends 0200 Receives: 0100 Receives: 0200 Non-U.S. Issuer: Receives: 0200
followed by TC06, Fast Funds Receives TC0629 Conventional Funds
TC06 contains Fast U.S. Issuers receive
Funds indicator in 0100 followed by
TCR3, position 16. TC06. No Fast Funds
Fast Funds indicator in TC06.
Europe issuers may
receive 0100 followed
by TC06. No Fast
Funds indicator in
TC06.
Conventional Funds
Sends Receives: TC06 Receives: 0220 Receives: TC06 Receives: 0220

TC0630 31 Conventional Funds Conventional Funds Conventional Funds Conventional Funds
Note: For SMS
issuers, VisaNet
converts the TC06 to
a 0220.
For additional information, refer to Appendix E: Transaction Flows.
29 Outside Europe Region, if the non-U.S. BASE I/BASE II recipient issuer does not participate in Fast Funds, they cannot
receive the 0100 OCT (they will receive the TC06 only and VisaNet will approve the 0100 on their behalf assuming there is no
reason for a decline). In Europe systems, all recipient issuers must process the 0100 for Money Transfer OCTs i.e. they are not
STIPed.
30 The acquirer, service provider, or merchant must initiate the OCT as a 0200 to enable Fast Funds. If the originator only
sends the TC06, the recipient issuer will not receive the 0100 and therefore, cannot make funds available until receipt of the
TC06.
31 Not applicable to the U.S. or Canada; OCTs must be originated as 0200s when sent to U.S. or Canadian recipient issuers.

3.10.3 Conventional Funds Availability
Except where Fast Funds capabilities have been mandated, Visa Core Rules and Visa Product and
Service Rules state that a recipient issuer must make funds from an incoming OCT available into the
recipient’s account within a maximum of 2 business days:
 For SMS issuers, the OCT funds must be posted/increment the cardholder’s open-to-buy or
operating limit within 2 business days (or same business day in Europe) of approving the SMS
0200 OCT or obtaining the 0220 OCT.
 For BASE I/BASE II/Dual Message issuers, the OCT must be posted/increment the cardholder’s
open-to-buy or operating limit within 2 business days of receiving and approving the 0100 or the
TC06 if only the TC06 is sent (or same business day in Europe).
 Issuers must dispute the transaction if funds cannot be posted within 2 business days (or same
business day in Europe).
Recipient issuers should be aware that the two business days do not include the day that the OCT is
received by the issuer. Also, non-working days (Sundays) and local holidays are not considered part of
the 2 business days. For example, a 2-day posting requires that an OCT received Friday, must be
posted by end of day Monday (excludes Sunday). For information about settlement, refer to the Visa
Settlement Funds Transfer Guide.
Important: If recipient issuers have any requirements or policies that prevent them from making OCT
funds available to recipients within 2 business days, such as local regulatory requirements
that require issuers to hold funds for a specified period before releasing them into the
cardholder’s account, they should contact their regional Visa representative.
3.10.4 Fast Funds
3.10.4.1 Fast Funds Enablement and Mandates
For Fast Funds to be possible, the following must take place:

 Acquirer, service provider, or merchant must initiate the transaction as an SMS 0200 OCT message.
 Recipient issuer must make the system changes to receive the enhanced 0100 or SMS 0200 OCT
message.
 Recipient issuer must make the system changes to make funds available to the recipient’s account
within 30 minutes of approving the 0100 or SMS 0200 OCT message.
 Submit to Visa an updated Customer Information Questionnaire (CIQ) to enable the Fast Funds
indicator on the issuer’s BIN configuration.
Note: If the recipient issuer is not set up to receive the enhanced 0100 or 0200 OCT, they need to
make system changes to begin processing the 0100 or 0200 message set, including all
associated financial and non-financial messages such as advices, reversals, disputes, and
representments.

Recipient issuer participation in Fast Funds is governed by rules.
General Issuer Requirements: Once an issuer participates in Fast Funds, they must support Fast Funds
on all incoming 0100 or 0200 OCTs.
Enhanced OCTs and Fast Funds are linked together. Issuers that support the enhanced 0100 or SMS
0200 OCT must support Fast Funds as per country or region’s mandate. If a non-U.S. BASE I/BASE
II/Dual Message issuer is not set up for Fast Funds, Visa will approve the 0100 on the issuer’s behalf
(assuming there is no reason for a decline) and send the issuer the TC06 only.
Issuers migrating from the TC06 only to receipt of the 0100 and TC06 must support enhanced OCTs
and Fast Funds processing.
The setting of STIP parameters should not be allowed where Fast Funds mandate is in effect. In
locations where Fast Funds mandate are not yet in effect, Issuers that are not Fast funds enabled are
allowed STIP approval.
Rules specific to each country are listed in the table below:

Table 3-5: Country-specific Rules
Country Rules
Europe Issuers that do not support Fast Funds are mandated to process the 0100
online for Money Transfer OCTs; i.e., STIP will not be applied.
Effective 14 October 2018, issuers must support Fast Funds processing for
Direct Debit Cards, Deferred Debit Cards (with 16-digit primary account
number and Card Verification Value 2), and Prepaid cards and support Fast
Funds for all approved OCTs by making funds available to the cardholder
within 30 minutes of approving an OCT.
AP and CEMEA Visa requires issuers in most AP and CEMEA countries to support Fast Funds
(which requires support for the enhanced 0100 or 0200 OCT). Refer to Table
3-6: Mandated Fast Funds Locations for details.
Canada Fast Funds participation is required for all debit and prepaid issuers. Effective
14 April 2018, the Fast Funds mandate will apply to all proprietary ATM and
debit cards that carry the PLUS mark.
Latin America and Caribbean Any participating issuer that wants to benefit from the prepaid reload
(LAC) network (enabled via the OCT using the TU BAI), must accept the enhanced
OCT message (0100 or 0200) and make funds available immediately after
receiving the OCT. This rule applies to all enhanced OCTs.
Effective 14 April 2018, Fast Funds participation is required for all debit and
prepaid issuers.
U.S. U.S. issuers must support the enhanced 0100 or 0200 OCT, and Fast Funds
participation is required for all U.S. debit and prepaid issuers.

Table 3-6 shows the locations where Fast Funds is mandated.

Table 3-6: Mandated Fast Funds Locations
Country Audience Effective Date
All new issuers in AP and CEMEA New debit and prepaid issuers 1 January 2012
All countries in Asia (AP) and Central Debit and prepaid issuers 13 October 2012
Europe, Middle East, and Africa (CEMEA)32,
including India (15 April 2015)
Armenia, Azerbaijan, Belarus, Georgia, Credit, debit, and prepaid issuers 14 April 2012
Kazakhstan, Kyrgyzstan, Moldova, the
Philippines33, Tajikistan, Ukraine, and
Uzbekistan
Australia Debit and prepaid issuers; domestic only 19 April 2013
Japan Debit issuers, domestic only 13 October 2018
Canada Debit, prepaid, proprietary and 14 April 2018

proprietary ATM cards that carry the
PLUS mark
Europe Region Direct Debit Card, Deferred Debit Cards 13 October 2018
with CVV2 and PAN on the card, and
Prepaid cards
LAC All debit and prepaid issuers 14 April 2018
Russia Credit, debit, and prepaid issuers 15 October 2011
U.S. Debit and prepaid issuers 16 October 2015
3.10.4.2 Fast Funds Reconciliation – BASE I/Base II/Dual Message (Recipient

Issuers)
BASE I/BASE II/Dual Message issuers participating in Fast Funds are required to make OCT funds
available to the recipient within 30 minutes of approving an OCT. Assuming the recipient issuer will
make funds available to the recipient as part of the 0100 OCT processing, issuers should take steps to
ensure that they are not also posting funds to the cardholder’s account with the processing of the
TC06 (i.e., double posting).
32 Excludes China, Guam, Hong Kong, Korea, Macau, Saudi Arabia, and Taiwan.
33 Excludes Visa cards that are issued as credit cards.

As part of their reconciliation efforts, the recipient issuer can match each TC06 they receive to its
associated 0100 OCT. To do so, they can use the Transaction ID, which is located in the following
fields:
 0100: Field 62.2
 TC06: TCR 5, positions 5-19
A Fast Fund indicator is also present in the TCR3, position 16. This indicator will be populated for all
transactions qualifying for Fast Funds and can be used by the issuer to help in reconciliation.
Although the difference may be minimal, there may be situations (due to foreign exchange
fluctuations) where the amount of the 0100 message is more or less than the amount in the TC06. This
means that the amount that the recipient issuer posted to the recipient’s account may not be the
exact amount that the recipient issuer received in their settlement file. To ensure the best cardholder
experience, we recommend considering absorbing the difference in amount, allowing the cardholder
to keep the specific amount communicated at the time of the transaction.
3.10.4.3 Additional Guidance to Achieving Fast Funds Processing Capabilities

(Recipient Issuers)
Enablement of Fast Funds availability will better position Visa issuers to meet competitive market
demands for faster payments, driven by consumer expectations and competition from central banking
systems and government agencies such as efforts by the U.S. Federal Reserve and National Automated
Clearinghouse to increase the speed of payments.
The speed and process in which a recipient issuer makes OCT funds available to the recipient
cardholder is controlled by each issuer and often varies in each issuer processing environment. Due to
the variety of issuer processing scenarios related to funds availability/incrementing the open-to-buy
or operating limit in Visa accounts, it is not always possible for Visa to provide specific direction on
how to manage this process. However, Visa can provide guidance on information available in the OCT
messages that should help recipient issuers manage and reconcile OCT funds.
Considerations
Making OCT funds available depends on the systems and controls for incrementing funds in a Visa
account (e.g. systems used to manage incrementing the funds available, open-to-buy or operating
limit) and who owns those systems). The recipient issuer processor, issuer internal operations, or
another third-party provider under contract with the issuer, could manage these systems. Whoever
manages these systems and controls will need to evaluate the triggers that increment funds added to
the account and ensure they comply with the requirements for funds availability on an OCT.
Important: All OCTs are considered good funds the minute the transaction is submitted to Visa. As
OCTs are not allowed to be reversed by the acquirer, service provider, or merchant, the
funds are considered “good funds” for the recipient issuer. The issuer can be confident

that these funds will be settled during normal settlement processes with Visa. For more
information on reversals, refer to Chapter 5: Exception Processing.
Because an OCT is a credit to the cardholder’s account, one way to consider OCT funds is to think of
these transactions the same as other deposits and how these are posted to an account and funds
made available to cardholders. For example, what are the rules and triggers to make the funds
associated to other types of credits or deposits available? Can those be adjusted for an OCT to ensure
funds are made available/added to the open-to-buy or operating limit upon receiving and approving
the OCT?
Below are some questions and considerations that may provide guidance to recipient issuers in their
research to identify solutions for Fast Funds capabilities.
 Who manages funds availability?
 Recipient issuer
 Processor
 Third-party host system provider
 What triggers the posting and funds availability/incrementing the open-to-buy or operating limit
on the account?
 Do you receive OCT’s today through the Visa Network?
 How quickly are funds made available/added to the open-to-buy or operating limit?
 If funds are made available within 30 minutes, have you set the Fast Funds Indicators at Visa? A
Client Information Questionnaire (CIQ) should be submitted to update the Fast Funds
Indicators.
 What do you do with other credit transactions received on the Visa network in terms of funds
availability; (e.g., a merchandise return credit)?
 How quickly are funds made available/open-to-buy or operating limit incremented as the result
of receiving these credits?
 If they are done quickly, can the same process of making funds available be followed for OCTs?
 Are your cards Interlink enabled (U.S. Only)?
 If so, would you be able to accept OCT transactions on Network 3 (Interlink network)?
 Are funds made available quickly for Interlink transactions and would this be an option for
OCTs on Network 3 and for reaching the Fast Funds requirement?
 Are your processing systems single message or dual message?
Single Message Issuers (SMS)

 Single message processing issuers may find it easier to make funds available quickly and to meet
Fast Funds requirements because the authorization and clearing/funds are combined in just one
message.
 Issuers should post funds to the cardholders account upon receipt of the 0200 message.

Dual Message Issuers (BASE I/BASE II)

 Even if an OCT is originated as a single message (full financial transaction (0200)) if the receiving
issuer processor is dual processing, VisaNet converts the 0200 into two messages; a 0100
authorization immediately followed by the TC06 clearing message.
 In many cases, these two messages are treated and processed independently with the TC06 held
and batch processed only once a day. Funds availability may be triggered off of the 0100 message
only for Fast Funds.
 As of 12 April, 2019 all Europe region OCT programs must be processed as SMS 0200 OCT
messages through V.I.P., all batch only TC06 Funds Disbursement OCT submissions must cease.
 If there are concerns that making funds available based on the approval of the 0100 for an OCT
may lead to double posting (posting based on the authorization as well as the TC06 clearing
message), the transaction ID is a way to isolate or identify a TC06 that is linked to an OCT 0100.
 TCQ (Transaction Code Qualifier; Position 3) will have a value of 2 that identifies the TC06 as
being associated to an OCT.
 TCR 3, Position 16 “Fast Funds Indicator” will have a value of Y if the recipient BIN is configured
for Fast Funds.
Note:
 Issuers would need to look for both the TCQ position 3 value of 2 AND the TCR 3, position
16 value of Y to know that the TC06 was the clearing message of an OCT 0100. Either of
these values alone, without the other, may not be indicative of an OCT 0100.
 TCR 3, position 16 will only have a value of Y if the issuers BIN has been set up and
configured to include the Fast Funds indicator AND the 0100 OCT was approved by the
issuer. If the issuer’s BIN has not been configured with the Fast Funds indicator, then this
field will include a space.
3.10.4.4 VisaNet Set Up for Fast Funds – Client Information Questionnaire (CIQ)
All recipient issuers that are capable of meeting the Fast Funds requirements, whether required by
Visa mandate or not, must submit a Client Information Questionnaire (CIQ) to Visa so that they can be
set up in the VisaNet with the appropriate Fast Funds indicator. This indicator is critical to OCT
origination programs so that acquirers, service providers, and merchants can properly message their
customers about the timing for which a Visa cardholder will have access to their funds and thereby
improving Visa cardholder experiences when using push payment services enabled by Visa Direct.
3.10.4.5 Fast Funds Testing Requirements
VisaNet testing using the VisaNet Certification Management Service (VCMS) is required for recipient
issuers that do not yet support enhanced OCTs and Fast Funds processing.

If the issuer has already tested their systems for enhanced OCTs, they are not required to re-test to
support Fast Funds.
3.10.4.6 Fast Funds Modifying Fraud Monitoring Systems
Recipient issuers may need to modify fraud models and policies to account for Fast Funds availability
and, for BASE I/BASE II issuers, the availability of funds based on authorization messages.
3.10.4.7 Fast Funds Interchange Rates
For a list of Fast Funds Fee Program Indicators (FPIs), refer to the BASE II Clearing Data Codes manual.
For Interchange Fees, refer to Interchange Fee page in Visa Online (VOL).
3.10.4.8 Fast Funds Customer Service and Exception Management
Recipient issuers must modify procedures to handle customer inquiries and exceptions around Fast
Funds availability. Refer to Chapter 5: Exception Processing for details.
3.11 Recipient Issuers – Back Office Activities
Reversals and disputes are allowed under limited circumstances. See Chapter 5: Exception Processing
for exception processing requirements.
3.12 Recipient Issuers - Risk Management
This section provides a summary of the various risk controls available to recipient issuers participating
in an OCT-based program. Issuers should review all sections to gain a comprehensive view of the risk
controls related to OCTs.
3.12.1 Risk Controls
The following are recipient issuer-related risk controls:

 Recipient issuers must be Visa clients. Visa clients are regulated financial institutions that have
undergone financial and regulatory compliance due diligence by Visa.

 Visa enables issuers to block acceptance of OCTs at the BIN level within VisaNet when such
transactions are prohibited by law. For an overview of key laws, refer to Chapter 7: Regulatory
Compliance and Legal Considerations.
 Recipient issuers can dispute OCT transactions (in a timely manner) when delivered to non-eligible
accounts. See Chapter 5: Exception Processing.
 Visa allows issuers to dispute transactions that either do not comply with the local regulatory
requirements or that the recipient refuses to accept. See Chapter 5: Exception Processing.
 On cross-border and domestic Money Transfer transactions in countries without National Net
Settlement service, Visa screens the sender against specific regulatory watch lists (such as the U.S.
Office of Foreign Assets Control (OFAC) Specially Designated Nationals (SDN) List) and provides
Canada, U.S., France, Germany, Italy, Spain, Poland, Ireland, and the United Kingdom issuers with a
score indicating how closely the sender matches an entry on the watch lists. See Section 3.12.5:
Watch List Screening Service.
 All recipient issuers must implement and maintain an anti-money laundering/anti-terrorist
financing program and must support Visa in its efforts to protect the Visa system.
 Recipient issuers can set velocity limits on OCTs that VisaNet can use to decline the transaction on
the issuer’s behalf or forward the OCT to the issuer with the information about the exceeded limit.
Issuers can also choose to set their own velocity limits outside of the VisaNet structure. Refer to
Section 3.12.3: Velocity Limits Exceeded – Processing Options.
 Recipient issuers can use their own authorization tools to make the authorization decision on each
OCT.
3.12.2 Data Elements in Identifying OCTs
Enhanced OCTs are identified by a set of data elements that can be used to aid recipient issuers in
managing risks that may be unique to OCTs including: unique OCT Processing Code (26), a unique
Business Application Identifier (BAI) to identify each type of OCT (Field 104, Dataset value 57), and the
presence of sender data (Field 104, Dataset value 5F). Refer to Appendix A: Enhanced OCT Data
Elements and Processing Rules for the details on these fields.
3.12.3 Using Visa Velocity Limit Checking to Mitigate Risk
Recipient issuers that support enhanced OCTs can use OCT velocity limit checking in VisaNet. Issuers
can establish velocity limits to either of the following:
 Default maximum limits for all OCTs, or
 Custom velocity limits, which is lower than the default maximum and more than the minimum
limit.
For all enhanced SMS 0200 OCTs processed by VisaNet, during the authorization step, VisaNet will
validate that the OCT does not exceed any velocity limits established by the issuer. If a limit is

exceeded, VisaNet can either decline on the issuer’s behalf or forward the OCT to the issuer with
information about the exceeded limit.
Note: Velocity limit checking is not available for OCTs originated as TC06 clearing record only.
The recipient issuer’s velocity limits are set at the BIN level, but applied at the account level. For
example, if the domestic 1-day count limit for a BIN is set to a maximum of 50 transactions, every card
issued with that BIN is allowed to receive up to 50 enhanced OCTs per day. Visa increments the count
and amount limits only on approved enhanced OCTs sent to issuers that support enhanced OCTs.
Refer to Table 3-7 for the updated changes and the updated velocity limits.
Recipient issuers should consider reviewing and modifying velocity limits periodically so that OCT
transactions are not declined because of low transaction counts and dollar amounts and ensure the
limits can accommodate a variety of use cases for push payments. OCTs may represent P2P Money
Transfers, Funds Disbursements (e.g. payouts related to insurance claims, shared economy payments,
government disbursements, merchant loyalty rebates, transfers of funds from digital wallets, etc.).
Overly conservative limits will impact Visa cardholder experiences with push payment services enabled
by Visa Direct.
Recipient issuers can communicate their velocity limit options to Visa via the Client Information
Questionnaire (CIQ). Contact your regional Visa representative for details.
Note: Recipient issuers are not required to set their own customized velocity limits in VisaNet. Any
issuer who does not set their own limits in VisaNet, will have the VisaNet maximum velocity
limits applied to their OCTs. See Table 3-7.
It should also be noted that custom and default are not applicable in countries where domestic
processing exists; e.g., Russia.
3.12.3.1 VisaNet Maximum Velocity Limits 34
The limits in this table are the maximum number and dollar amount that a single Visa account holder
can receive in a 1, 7, or 30- day period. The time period is a rolling timeframe and is based upon the
first transaction sent to a recipient account. If limits are exceeded on count or amount, VisaNet
declines any subsequent transactions. Unless an issuer has established their own customized OCT
velocity limits, these limits will be applied to all OCTs.
34All limits are based on GMT with tracking starting from the beginning of a GMT day and resetting at the end of/beginning
of the next GMT day

Table 3-7: VisaNet Maximum Velocity Limits
Key
2
Person-to-person (PP), account-to-account (AA), or wallet transfers (WT).
3 Funds Disbursement/Non-Money Transfers, insurance settlement, payroll, government disbursement, etc.
3.12.3.2 VisaNet Minimum Velocity Limits
For U.S. ONLY, effective 15 January 2019, Issuers who use the Velocity Limit Service must set their
limits at or above required minimum values in VisaNet. The settings can be differentiated between
Money Transfer OCT and Funds Disbursement/non-Money Transfer OCT.
Note: VisaNet Minimum Velocity Limits will be available in Europe in the near future.
Table 3-8: VisaNet Minimum Velocity Limits
1
Person-to-person (P2P), account-to-account or wallet transfers.
2
Funds Disbursement, insurance settlement, payroll, government disbursement, etc.
Incoming cross-border OCTs to the U.S. are not permitted and are blocked by VisaNet.
3.12.3.3 Velocity Limits Exceeded - Processing Options
For issuers with the custom velocity limits in VisaNet, limits are only checked on enhanced SMS 0200
OCTs where the recipient issuer is available to respond to the OCT authorization request. If the issuer
is not available, VisaNet automatically declines the transaction and velocity limit checking does not
apply. This does not apply if the issuer supports the TC06 only. Refer to Section 3.7: VisaNet Stand-in
Processing (STIP) for additional information.

When the limit is exceeded and the recipient issuer is available, the issuer has two options, outlined in
the following sections:
1. VisaNet can forward the OCT to the recipient issuer with information related to the exceeded
velocity limit.
2. VisaNet can decline the OCT on the recipient issuer’s behalf and optionally send the issuer a
Stand-in Advice with information related to the exceeded velocity limit.
Note: These options ONLY apply when an issuer establishes customized limits. These options do
NOT apply for transactions that exceed the VisaNet maximum limits. OCTs that exceed the
VisaNet maximum limits outlined in Error! Reference source not found. will be declined b
y VisaNet.
3.12.3.3.1 Option 1: VisaNet Forwards OCT to Recipient Issuer with Information about
Exceeded Velocity Limit
When recipient issuers have opted for VisaNet to forward them the OCT when a velocity limit has
been exceeded, they must be prepared to receive the OCT with Field 48, Usage 37, position 11. This
field will contain the following velocity limit related information that issuers can use in making their
authorization decision:
 1 = 1-day count or amount exceeded
Note: V.I.P. will populate this field with the priority order of 1, 2, and then 3.
3.12.3.3.2 Option 2: VisaNet Declines OCT and Optionally Sends Stand -in Advice with
Information about Exceeded Velocity Limit
With this option, VisaNet will decline the OCT when a velocity limit has been exceeded. The recipient
issuers can opt to receive Stand-in Advices from Visa for these situations. The Stand-in Advices will
contain Field 48, Usage 37, position 11 with velocity limit values of 1, 2, or 3 as outlined in the above
bullets.
The following figure provides a summary of the processing flows associated with the velocity limit
exceeded scenarios. In addition, refer to Appendix E: Transaction Flows, E-9.

Figure 3-1: Velocity Limit Exceeded Processing Flow
Issuer participates in
VisaNet velocity
limit checking
Issuer Available Issuer Unavailable
VisaNet performs VisaNet does not

velocity limit perform velocity
checking limit checking
VisaNet continues to VisaNet declines

process transaction/ Limit OCT and sends
No
forwards transaction Exceeded decline response
to issuer code 91 to
originator
Yes
VisaNet sends issuer

a standard issuer
Issuer opts to unavailable Stand-in
have VisaNet: Advice (does not
1. Forward OCT to them contain velocity limit
2. Decline OCT on their checking info)
behalf
Option 1: Forward Option 2: Decline
VisaNet declines
VisaNet forwards
OCT and sends
OCT to issuer with
decline response
F48, U37, pos 11
code 61 (amount
with info about
exceeded) or 65
velocity limit
(count exceeded) to
exceeded
originator
Issuer receives OCT

and makes VisaNet does not
Issuer opts to
authorization No send issuer a Stand-in
receive advice?
decision advice
Yes
VisaNet sends issuer a

Stand-in advice with
F48, U37, pos 11 with
info about velocity
limit exceeded

3.12.4 Transaction Monitoring
Recipient Issuers should monitor OCT transaction activity for any signs of fraud or misuse, including
money laundering and terrorist financing. Issuers should consult their appropriate fraud, risk, and
compliance teams to ensure their program meets their institution’s monitoring requirements, the Visa
Core Rules and Product and Service Rules, and applicable law and regulations.
Suspicious activity may include:

 High volumes of OCTs in short periods of time to new or existing accounts
 High volumes of OCTs in short periods of time to new or existing accounts followed by cash
withdrawals
 A high number of new accounts opened up that receive OCTs and from which funds are
withdrawn as cash.
 Disruption in the usual pattern of OCTs in either transaction count or amount of transfers.
 Monitor activity to identify the movement of money between credit accounts held by the same
person to avoid falling into bad standing or to take advantage of reward points.
3.12.5 Watch List Screening Service
This section provides recipient issuers with implementation considerations related to the watch list
screening service.
Important:
Visa provides watch list screening as a service for the convenience of the sending acquirers,
service providers, merchants, and recipient issuers. The Issuer is solely responsible for its own
compliance with applicable laws and regulations.
3.12.5.1 Watch List Screening Service Overview
Visa provides a watch list screening service for enhanced Money Transfer OCTs, with Money Transfer
BAIs. The service covers both cross-border and domestic OCTs (where NNSS (National Net
Settlement35) is not in place). Refer to Section 1.1.1 Identifying Domestic and Cross-border OCT
Transactions.
35In the European Economic Area, the definition of domestic vs cross-border Money Transfers is not related to the
availability of a National Net Settlement Service (NNSS).

The acquirer, service provider, or merchant sends the enhanced Money Transfer OCT using an ISO
2000 message or an API to VisaNet. VisaNet checks sender data against applicable watch lists to arrive
at a score that indicates how closely the sender and recipient data matches any watch list entries. If
the transaction is a match on any screening list, the transaction will be declined and not forwarded to
the issuers.
3.12.5.2 Watch List Screening Transaction Flow
The following steps describe the transaction flow for watch list screening:
1. The acquirer, service provider, or merchant sends the enhanced Money Transfer 0200 OCT
containing sender data and the recipient’s account number and name.
2. Visa uses the recipient’s account number to determine the recipient issuer’s country.
3.12.5.3 Watch List Scoring Methodology
Watch list screening evaluates how closely the Sender Name, Sender City, and Sender Country input
fields with each field given a percentage weighting36, matched against entries on the regulatory watch
list(s) for the recipient issuer’s country. The score provided in the screening message and subsequently
in the OCT is an aggregate of how closely the Sender Name, Sender City, and Sender Country fields
matched an entity on the regulatory watch list(s) for the recipient issuer’s country.
3.13 Recipient Issuers - Customer Considerations
This section describes the customer service considerations that recipient issuers need to think through
and address.
 Disclosures—Issuers are responsible for making all necessary disclosures required by applicable
law with respect to fees, costs, rewards, and other material terms in connection with OCTs.
 Rewards Programs—Issuers should consider the impact of OCTs on account programs that
receive rewards such as purchase points, merchant discounts, or travel miles (for example, unlike
policies related to reducing rewards points upon receipt of a merchandise return, issuers may want
to consider not reducing rewards point balances based on the receipt of OCT funds).
 Account Protection—Issuers should be aware that the OCT only requires the recipient’s Primary
Account Number (PAN); it does not require the CVV2 or expiration date. Therefore, to protect
36In the new weighting % variables configuration model, the hard-coded % value for each sender data element (sender
name, sender city, sender country) is: Sender Name 60%; Sender City 10%; Sender Country 30%. Additionally, the
weighting % variables can be changed, if absolutely necessary, with sufficient approvals by Visa Compliance.

accounts against fraud, issuers may want to advise their cardholders not to provide information
other than the PAN to senders.
3.13.1 Customer Service Inquiries and Exceptions
Recipient Issuers need to handle customer service inquiries and disputes. This may include training
customer service staff and upgrading customer service screens to include transaction details for OCTs.
Customers may have questions about expected transactions that have not yet posted to their account.
Customer service staff needs to be prepared to answer these questions.
Refer to Chapter 5: Exception Processing.
3.13.2 Customer Statements – Identifying Transactions
Issuers
Recipient Issuers must not refer to, describe, label, or treat the Original Credit Transaction as a refund
on cardholder facing material or communications, including cardholder statements. Additionally, the
recipient issuer must not charge additional service fees or funds transfer fees to the cardholder’s
account for receiving funds related to OCTs. Other charges may be applied in accordance with the
Cardholder agreements.
Merchants
To help reduce customer inquiries, the merchant name and merchant city fields should contain
information about the OCT that identifies the source of the transaction. For example, for a Money
Transfer OCT, the merchant name portion of the statement may include the sender’s name while the
merchant city portion will include “Visa Direct.” From a recipient issuer perspective, the issuer that
receives the OCT should be using what is in the Merchant Name field to populate the cardholder
statement as a means to help the cardholder better identify the transaction.
Refer to Appendix A: Enhanced Original Credit Transaction (OCT) Data Elements and Processing Rules
(Field 43) for details.
3.13.3 Customer Statements – Funds Availability
Recipient issuers should update online and/or paper statements to reflect that the funds have been
made available to the recipient.

3.13.4 Customer Notifications
If they have an appropriate platform, recipient issuers may want to provide notifications (e.g., mobile
phone alerts or email messages) to recipients to indicate when OCT funds have been made available
to their Visa account.
3.14 Recipient Issuers - Reports
Recipient Issuers should refer to the VisaNet Settlement Service (VSS) reports for information on OCTs.
For information on OCT-related interchange, refer to the VSS-120, VSS-130, VSS-130-M, and VSS-135
reimbursement fees reports where OCTs are identified through the fee descriptor. Contact your
regional Visa representative for the fee descriptors in your territory.
Issuers can also use the applicable SMS reports. Samples of the VSS and SMS reports related to OCTs
are provided in Appendix B: Sample Reports. For information about settlement, refer to the Visa
Settlement Funds Transfer Guide.
The Sender Reference Number is provided in SMS Raw Data, positions 106-121; the Business
Application Identifier (BAI) is provided in positions 22-23; and, the Source of Funds is provided in
position 24.
Note: Due to data security reasons, all other sender data is removed and not present in SMS Raw
Data.
Refer to the VSS User’s Guide, Volume 2, Reports for details.

Bank Identification Number (BIN) Blocking
4 Bank Identification Number (BIN) Blocking

This chapter provides recipient issuers and acquirers, service providers, and merchants with
information related to Bank Identification Number (BIN) blocking. The following table provides
information on countries where all BINs are blocked from receiving OCTs.
4.1 Blocking by Country
4.1.1 International and Country-Specific Regulatory Restrictions
On cross-border transactions, acquirers, service providers, and merchants should check to ensure that
the recipient’s country of residence is part of the acquirer’s, service provider’s and merchant’s program
(as defined in the acquirer submitted PIF).
Note: Visa applies all current restrictions regarding cross-border purchase transactions to OCTs. For
example, due to U.S. government restrictions, U.S. banks may not send or receive OCTs to
Crimea, Cuba, Iran, North Korea, Syria, or Sudan.
4.1.2 BINs Blocked by Country
Table 4-1 provides information on BINs that are blocked in the VisaNet system by country:
Table 4-1: BIN Blocking By Country
Country All BINs Blocked for All BINs Blocked for Online Special Blocking
All OCTs Gambling OCTs
Bangladesh X
Crimea X Blocked for all transactions

including OCTs (both origination
and receipt)
Cuba X Blocked for all transactions

and receipt)
Hong Kong X
India X Credit Card BINs blocked for

cross-border OCTs
Indonesia X

Country All BINs Blocked for All BINs Blocked for Online Special Blocking
All OCTs Gambling OCTs
Iran X Blocked for all transactions

and receipt)
Japan Blocked for cross-border money

transfer OCTs due to regulatory
limitations.
North Korea X Blocked for all transactions

and receipt)
Malaysia X
Nepal X
Singapore X
Sudan X Blocked for all transactions

and receipt)
Syria X Blocked for all transactions

and receipt)
U.S. All BINs blocked for gambling Inbound cross-border OCTs are
OCTs from MCC 7995. blocked by VisaNet. These blocks
Note: MCC 7995 will be in may be removed upon request,
effect October 18, 2019 for on a case-by-case basis.
select U.S face-to-face
gambling establishments.
Gambling OCTs from 7800
(government-owned lotteries),
7801 (government-licensed
casinos), and 7802
(government-licensed
horse/dog racing) are
allowed/NOT blocked.
Vietnam X
Note: When an issuer is blocked from receiving OCTs, VisaNet declines the transaction with Reason
Code 93 (Transaction cannot be completed – violation of law) except for embargoed countries
(Cuba, Iran, Syria, and Sudan,) where Reason Code 62 (Restricted card – card invalid in this
region or country) is used.

Note: When “All BINs Blocked for OCTs” or “All BINs Blocked for Online Gambling OCTs” is selected,
OCTs initiated as both 0200s and TC06s are blocked.
4.2 Additional Restrictions
4.2.1 Issuer Blocking and Regulatory Compliance
Recipient issuers must only allow OCT funds to be received into a Visa account to which the issuer has
applied its “Know Your Customer”/Customer Identification Program (CIP). Issuers must identify the
BINs associated with accounts that do not have “Know Your Customer”/CIP so that Visa can block
them from receiving OCTs.
The VisaNet system is able to block OCTs at the BIN level as follows:
 Block all OCTs.
 Block online gambling OCTs.
 Block Money Transfer OCTs.
4.2.2 Prepaid Restrictions
OCTs are not permitted for certain types of prepaid accounts where cardholder data is not on file,
where the source of loads may be restricted, or where prohibited by law. Recipient issuers must
identify the prepaid BINs or account ranges associated with these account types to Visa so that Visa
can block them from receiving OCTs.
Non-U.S. recipient issuers need to ensure that the identified BINs or account ranges are blocked in
both V.I.P. and BASE II to avoid receiving OCTs initiated as 0200s and as TC06s.
Visa will proactively block all OCTs to the following prepaid product types:
 Non-reloadable Visa prepaid cards
 Government disbursement cards
 Insurance reloadable cards including all healthcare card products
For the above programs, recipient issuers may opt-in if the program construct allows it.

In the U.S., all other prepaid card programs will be set up to allow the receipt of an OCT. Recipient
issuers in these programs must accept OCTs. Issuers may contact their regional Visa representative to
request a block on receipt of OCTs if the program meets any of the following criteria:
 Program does not include the collection and verification of cardholder information.
 Loads are restricted to a single source (such as a corporation, government agency, or university)
and do not allow for consumer loads.
 OCTs are prohibited by local law or regulation.
Contact your regional Visa representative for additional details.

Exception Processing
5 Exception Processing
This chapter provides acquirers, service providers, merchants, and recipient issuers with information
on reversals, adjustments, and disputes.
5.1 Acquirers, Service Providers, and Merchants: Reversals and

Adjustments
Acquirers, service providers, and merchants are responsible for sender or acquirer, service provider, or
merchant system errors. Acquirers, service providers, and merchants must ensure that they follow
appropriate measures to eliminate sender errors (double entry, confirmation screens, etc.) and
perform extensive testing to prevent system errors.
5.1.1 Reversals
Acquirers, service providers, and merchants are not permitted to initiate reversals of SMS 0200 OCTs
to resolve processing errors or disputes37. However, there may be VisaNet system-generated reversals
for timeout scenarios but these typically happen within seconds of the initial OCT.
In the event of a VisaNet system-generated reversal, the recipient issuer will not receive funds
associated with the OCT during settlement. If the issuer has already made funds available before
receiving a timeout reversal, the issuer should attempt to retrieve the credit to the recipient’s account.
Note: If a connection disruption occurred between Visa and the originating entities (acquirers, service
providers, and/or merchants) that prevents Visa from delivering an OCT response message, the
originating entities may not know that an OCT completed delivery to an issuer. The connection
was lost after the OCT was sent but before a response message could be sent to the
originating entities. In this scenario, the originating entities must not send a reversal if it did
not receive an OCT response message, but should resubmit the OCT. (If the OCT was
completed with the original submission, the repeat submission of the same OCT would be
rejected by Visa as a duplicate transaction.)
37 Although this is an OCT rule, it is not enforced by VisaNet system edits.

Acquirers and merchants of TC06 OCTs may continue to send reversals associated with processing
errors within 1 business day of the initial OCT and only for the following reasons:
 Incorrect account number
 Incorrect transaction amount
 Duplicate processing
 Incorrect Transaction Code
For details, refer to Appendix F: Enhanced TC06 OCTs.
5.1.2 Good Faith Adjustments
If an exception scenario arises, acquirers, service providers, and merchants may use good faith
adjustments (i.e., adjustments agreed to with the recipient issuer) to correct errors and address
disputes. Acquirers, service providers, and merchants may only send an adjustment to the issuer to
recover funds if agreed to as a result of good faith negotiations. If a recipient issuer receives an
adjustment that is not part of a good faith agreement which results in a loss, they should contact Visa
or consider filing for compliance to address the situation.
If an exception scenario arises due to the following reasons, the acquirer submits a Request Proof of
Posting (RPP) on Visa Resolve Online (VROL):
 Recipient did not receive funds
 Funds sent to the wrong recipient
 Wrong amount sent to the recipient
In such scenarios, the issuer must respond to the RPP within 5 calendar days. In the absence of a
response or if issuer responds with a non-posting, the acquirer can send a debit adjustment to the
issuer or pull funds back from the issuer. These adjustments must be processed within 30 calendar
days of the original transaction.
To make an adjustment, when a cardholder attempts to send funds to a recipient, an AFT pull is
performed on those funds. The OCT to send the funds is rejected, declined, or expires. The service
provider must ensure funds are returned to the original cardholder.
If the service provider attempting to process a standalone TC06 is missing the Tran ID, this may result
in issuers being unable to match the transaction to the original AFT. This can be a bad cardholder
experience as they wait for the funds to be deposited to their card. The Tran ID field is optional,
however, it is key information that helps the Issuers connect the two transactions.
Note: Adjustments associated with OCTs must contain a Processing code 22 in Field 3.1 with a
Message Reason Code (Field 63.3) value of 2150.

Specific types of reversals are permitted on domestic prepaid load OCTs in the LAC region.
Issuers in this region must be prepared to receive reversals for these scenarios. Refer to the
following section in this guide.
Note: Reversals contain Field 104, Dataset IDs 57, and 5F.
5.1.3 Prepaid Load OCT Reversals – LAC Region
Load partners and merchants are not allowed to initiate reversals to correct errors or address
disputes38 but, system-generated reversals are permitted on domestic transactions in the LAC region
as long as they take place within seconds of sending the OCT. The following outlines the types of
system-generated reversals that are permitted:
 Response Stopped at VisaNet: If VisaNet receives the issuer’s authorization response but is unable
to forward it to the merchant, VisaNet will automatically generate a reversal and send it to the
issuer.
 Response Stopped at Merchant: Similarly, if the merchant is unable to forward the issuer’s
authorization response to the load partner’s system, the merchant may automatically generate a
reversal and send it to the load partner and to VisaNet.
 Load Partner Never Receives Response: If the load partner’s device does not receive an
authorization response from the merchant and therefore times out, the load partner’s device may
automatically generate a message to notify the merchant that the transaction was not completed
at the point of service, thus resulting in a reversal.
Note: Reversals must contain Field 104, Dataset IDs 57, and 5F.
5.2 Exception Scenarios for Fast Funds
To support Fast Funds, acquirer, service provider, and merchant reversals are not allowed for OCTs
initiated as 0200s.
VisaNet, however, may send the issuer one of the following messages:
 Reversal advice (when acquirer, service provider, or merchant system becomes unavailable)
 Timeout advice (when issuer response is delayed)
 When a recipient issuer receives a VisaNet reversal or timeout advice, they must act on the advice
and should attempt to retrieve the funds from the recipient’s account, if the issuer had already
posted funds to the recipient account. The scenarios associated with these advices are not
38 Load partners and originating entities may use good faith adjustments to correct errors and address disputes.

common. Issuers will receive advices within seconds of the 0100 or 0200 message. These scenarios
are outlined in Table 5-1.
Table 5-1: Fast Funds Exception Scenarios
# Exception Description Notes

Scenarios
1. Acquirer, service Acquirer, service provider, or merchant sends Acquirer, service provider, or
provider, or the OCT to the issuer. merchant must notify the
merchant System The recipient makes the OCT funds available in sender that the transaction was
Becomes the recipient’s account and provides their not successful.
Unavailable authorization response to VisaNet. Refer to Appendix E: Transaction
When VisaNet attempts to forward the issuer’s Flows for an example of this
authorization response to the acquirer, service scenario.
provider or merchant, the acquirer, service
provider, or merchant’s system is unavailable.
VisaNet sends:
 Reversal advice to a SMS issuer, or
 Reversal request to a BASE I/BASE II issuer
2. Recipient Issuer Acquirer, service provider, or merchant sends Acquirer, service provider, or
Response Delay the OCT to the issuer. merchant must notify the
The issuer makes the OCT funds available to sender that the transaction was
the recipient and provides their authorization not successful.
response to VisaNet but the issuer’s response Recipient issuer must act on the
is received outside the response window. timeout advice39 and attempt to
VisaNet sends: retrieve the funds from the
recipient’s account.
 Timeout advice to the issuer
Refer to Appendix E: Transaction
 Decline to the acquirer, service provider, or
Flows for an example of this
merchant (issuer unavailable)
scenario.
39 SMS issuers may also receive a reject for this situation.

5.3 Issuers – Disputes
In order to make the dispute process faster and simpler, the 22 dispute reason codes under Visa
Resolve Online (VROL) are being migrated to Visa Claims Resolution (VCR). VCR presents a simplified
set of dispute categories broadly classified into the following:
 Fraud
 Authorization
 Processing Errors
 Consumer Disputes
Fraud and Authorization categories will be processed through automation, where decisions will be
based on rules and Visa data to determine liability automatically.
Processing Errors and Consumer Disputes categories follow a collaboration process. This is similar to
the traditional exchange of data between clients; however, this is a streamlined process and the
resolution is expected to be faster.
Table 5-2 maps the VROL Dispute reason codes with the VCR Dispute categories.
Table 5-2: OCT Dispute Reason Codes
VCR Dispute Categories VROL Description Dispute Member Message Text

Dispute Situations
VCR Corresponding Reason
Condition VCR Workflow Code
Code
12.4 – Collaboration 77 Non- This dispute This dispute must contain

Incorrect Matching may be used Member Message Text with
Account Account for either of either:
Number Number the following “Account closed” or “Account
situations: not on file”
 Recipient’s
account is
closed
 Recipient’s
account is
not on file
12.6 – Collaboration 82 Duplicate A duplicate Refer to the Visa Core Rules and
Duplicate Processing OCT was Visa Product and Service Rules
Processing submitted for details

VCR Dispute Categories VROL Description Dispute Member Message Text

Dispute Situations
VCR Corresponding Reason
Condition VCR Workflow Code
Code
13.8 – Collaboration 85 Credit Not This dispute This dispute must contain
Original Processed may be used Member Message Text with
Credit for either of either:
Transaction the following  “Not allowed by local law”
Not situations: or
Accepted  Legal  “Recipient refuses credit”
restrictions
prevent
accepting
the credit
 Recipient
refuses the
credit
Issuers must be prepared to send OCT dispute and dispute reversals (as applicable) as well as receive
OCT representments and representment reversals. If a dispute reversal is to be sent, the issuer should
send it within one business day of the initial dispute.
5.4 Acquirers, Service Providers, Merchants, and Issuers – Dispute

Considerations
This section outlines a number of possible dispute scenarios and options for addressing them.
Acquirers, service providers, merchants, and recipient issuers should review this information and use it
to develop their dispute policies and associated procedures.

Table 5-3: Dispute Scenario Examples
# Dispute Scenario Scenario Description Proposed Best Practices for Financial

Origination Liability as Institutions to Mitigate
Per Visa Liability or Handle Errors
Rules40
1 Acquirer, Sender or At the time of Acquirer,  At the time of enrollment

Service recipient enters enrollment or while Service and transaction initiation,
Provider, incorrect card adding card details, the Provider, validate that the account
Merchant or information. sender or recipient Merchant number is accurate by
receiving enters incorrect card utilizing mechanisms such
issuer information. as Mod-10 verification,
AVS, etc.
 Match the sender or
recipient name with
cardholder name and
consider including
additional verification
steps in case of mismatch.
40 Liability is based on Visa’s operating rules and does not constitute any regulatory or legal advice.


Rules40
2 Acquirer, Sender error The sender realizes that Acquirer,  Before authorizing the
Service he or she sent the Service transaction, add a
Provider, wrong amount to the Provider, confirmation screen that
Merchant recipient or sent the Merchant41 allows the sender to
funds to the wrong confirm / verify the details
recipient (selects of the transaction before
incorrect contact / submission.
email address) or sends  Disclose sender liability for
a duplicate fund transaction error as a pre-
request condition for submission /
authorization of
transaction.
Where the sender disputes
the transaction, in some
cases, the dispute can be
resolved based on good
faith negotiations and
support from the recipient
issuer.
There are two options:
Option 1: Acquirer, service
provider, merchant may
contact recipient issuer to
determine if an adjustment
can be made. If recipient
issuer agrees to a good faith
adjustment, merchant may
send adjustment.
Option 2: Sender may contact
the recipient and then the
recipient may contact the
recipient issuer to resolve. The
recipient issuer could charge
back the OCT using dispute.
41
Acquirer, service provider, or merchant may decide to pass on the liability to the sender


Rules40
3 Acquirer, Acquirer, Service Acquirer, Service Acquirer,  Establish good faith

Service Provider, Provider, Merchant Service adjustment procedures to
Provider, Merchant realizes that it sent the Provider, contact a recipient issuer
Merchant processing error. wrong amount to the Merchant in the event of an error.
(Sender bank / recipient or sent the  Upon approval by the
third-party funds to the wrong recipient issuer, submit
provider). recipient (wrong transactions for dispute
account number). resolution using Visa
Resolve Online
 Acquirer, service provider,
merchant is liable,
recipient issuer would
receive a good faith
adjustment from the
acquirer, service provider,
merchant related to
obtaining the OCT funds.
4 Receiving Recipient does not Sender or recipient Recipient Where Fast Funds is required,
Issuer receive funds due relays that recipient has issuer recipient issuer is required to
to non/late not received the funds. make the funds available
posting. within 30 minutes. If the
recipient does not post the
funds within 30 minutes or
delays the posting, acquirers,
service providers, merchants
can follow the Non/Late
Posting Process. The process
allows acquirer, service
provider, merchant to pull
funds back from the recipient
issuer.
5 Receiving Recipient issuer Sender or recipient Recipient Acquirers, service providers,

issuer system error. relays that recipient has issuer merchants can follow the
not received the funds Non/Late Posting Process. The
or received the wrong process allows the acquirer,
amount. service provider, merchant to
pull funds back from the
recipient issuer.


Rules40
6 Receiving Recipient Recipient contacts the Recipient Recipient issuer is required to

issuer (customer) refuses recipient issuer and issuer dispute the OCT (as credit is
receipt. relays that he or she not processed, recipient
does not want to accept refuses credit) to the acquirer,
the funds. service provider, merchant.
7 Receiving Fraudulent receipt Unauthorized user takes Acquirer, Acquirer, service provider,
issuer of Money Transfer. over the recipient bank Service merchant should retain the
account or third party Provider, authorization response to
account or gets access Merchant demonstrate an approval.
to recipient’s personal Acquirer, service provider,
credentials (e.g., phone, merchant may submit a
email). request using Visa Resolve
Online to the recipient issuer
for proof of posting.
The recipient issuer will
receive a good faith
adjustment from the acquirer,
service provider, merchant
related to obtaining the OCT
funds.
8 Receiving Recipient account The funds leave the Recipient The recipient issuer is required
issuer does not exist or sender’s account and issuer to dispute the OCT to the
is closed. the recipient issuer acquirer, service provider,
approves the merchant.
transaction, however
cannot post the funds
as the recipient account
is closed or does not
exist.

5.5 Non/Late Posting Process
For OCT-based services, the recipient issuer is required to make funds available to the recipient’s
account either:
 Within 30 minutes of approving the enhanced 0100 or 0200 OCT when the issuer participates in
Fast Funds.
 Within 2 business days of receiving the 0200 message or TC06 when the issuer does not
participate in Fast Funds.
5.5.1 Process for Complaints Related to Non-Posting of Funds
This section outlines the process that acquirers, service providers, and merchants must follow to
address a complaint for the non-receipt of funds (e.g., the recipient either did not receive the funds or
did not receive the funds within the required timeframe):
 The acquirer, service provider, or merchant receives a complaint from a sender that the recipient
either did not receive funds or received funds late.
 The acquirer, service provider, or merchant may submit a request over Visa Resolve Online (VROL)
to the recipient issuer for proof of posting. This request will be of non-financial nature and is
intended for compliance.
 The recipient issuer should respond within 5 calendar days.
 If the recipient issuer does not respond within the 5 calendar days or responds that they have not
posted yet42, the acquirer, service provider, or merchant can send an OCT adjustment message to
the issuer through VROL or through their existing process. This request will be of a financial nature
and serves to pull the OCT funds back from the issuer to the acquirer, service provider or
merchant. This adjustment must be processed and settled within 30 calendar days.
The adjustment must contain a Message Reason Code (Field 63.3) with a value of 2150. It must be
in the same amount and currency as the original OCT43. If the acquirer, service provider, or
merchant sends an adjustment, the acquirer, service provider, or merchant must return the funds
to the sender once the adjustment has been processed.
42 If the recipient issuer communicates that they posted the OCT but posted late, the originating entity can send a good faith
adjustment to the recipient issuer if deemed appropriate based on the specific circumstances of the dispute.
43 The processing code needs to be the debit or credit adjustment processing code, as opposed to the OCT processing code.


Visa Direct Risk Management Framework
6 Visa Direct Risk Management Framework

Visa Direct was built with speed, security, and flexibility in mind, including a focus on controls to help
minimize the risks associated with push payments and OCTs. Visa’s multi-layer risk approach is
intended to give participants confidence in the Visa Direct platform.
There are four layers of the risk management framework:
6.1 Visa’s Obligations as an “Operator of a Credit Card System”
In the U.S., Visa must comply with the provisions of the BSA and USA Patriot Act that are applicable to
an “operator of a credit card system”. As such, Visa is required to have in place:
 AML/ATF Policy, Procedures and Internal Controls
 Independent Testing
 Designated AML/ATF and Sanctions Officer
 Employee Training
6.2 Visa Client Licensing Process
Visa has a rigorous process of evaluating issuers and acquirers (clients) before granting licenses to
participate directly in the Visa payment system, including completing the following:
 Financial and regulatory compliance diligence on each prospective Visa client.
 Evaluation of key country risk factors based on guidance from OFAC, FinCEN, IMF, Transparency
International CPI, FATF Mutual Evaluations, Presidential Major Drug Transit/Producing List.

 Screening for and prohibiting business dealings with FIs located or domiciled in
comprehensively sanctioned countries (currently, Cuba, Iran, Sudan, Syria, North Korea, and
Crimea) or that are owned by those comprehensively sanctioned countries’ governments.
 Screening of clients and their owners/directors against OFAC SDN list, both at the time of
registration and on a periodic, ongoing basis.
All Visa clients are bound by Visa Rules including, but not limited to requiring clients to assist Visa in
guarding against card issuance and merchant acquiring in circumstances that could facilitate money
laundering or terrorist financing.
6.3 Visa Direct Program Diligence and Approval
All new Visa Direct programs must be registered, vetted and approved by Visa in order for acquirers or
merchants to start using OCTs. Acquirers must submit a Program Information Form (PIF) that includes
information on:
 Program details and geographic scope: funding sources, domestic or cross border and target
destination countries.
 Compliance measures: licensing details, Know-Your-Customer (KYC) practices, screening practices
and AML Policies.
 Risk controls: transaction limits, velocity controls, volume estimates for credit settlement risk
assessment.
6.4 Key Controls
Comprehensive risk management is a layered approach where all participants play a role in applying
key controls. Examples of the Visa Direct key controls are in Table 6-1: Key Controls for Managing Risk
and in Figure 6-1: Visa Direct Key Controls Overview.
Table 6-1: Key Controls for Managing Risk
All Acquirers are required to conduct due diligence of their merchants
and service providers.
Due Diligence All Visa Direct programs must comply with applicable law and non-
financial institutions that offer money transfer services must have
appropriate money transmitter licenses as required under local law.
Acquirers must require merchants and service providers to complete KYC on

their customers as required under applicable local law.
Know Your Customer Issuers are required to complete KYC on their cardholders as required under
applicable local law.

All programs must comply with local laws and regulations and AML/ATF,
fraud monitoring, sanction screening, suspicious activity monitoring
Anti-Money Laundering requirements.
Acquirers are required to implement an AML/ATF program consistent with
domestic and international standards, e.g., FATF, EU, U.S.
Acquirers must require merchants and service providers who originate OCTs
Transaction Controls and
to establish controls and monitor transaction activity for signs of fraud as
Monitoring
well as misuse of the OCT for the payment of goods and services.
Visa Direct uses a multi-layer compliance and risk management approach
Compliance and Risk requiring key stakeholders (Merchants, Service Providers, Acquirers and
Management Issuers) to perform critical activities to help minimize risks associated with
these transactions.
Figure 6-1: Visa Direct Key Controls Overview
6.5 Watch List Screening
On domestic and cross-border Money Transfer transactions for countries without National Net
Settlement service (NNSS), Visa screens the sender against specific regulatory watch lists (such as the
U.S. Office of Foreign Assets Control (OFAC) Specially Designated Nationals (SDN) List) for its own
compliance purposes. In some markets, issuers can choose to get an optional score indicating how
closely the sender matches an entry on the watch lists. See Section 3.12.5: Watch List Screening Service.


Regulatory Compliance and Legal Considerations
7 Regulatory Compliance and Legal Considerations

This chapter provides regulatory and legal requirements, and considerations for the OCT-based
programs.
Important:
Information provided in this chapter does not constitute or replace legal advice. It should be
considered informational only. It is not meant to be comprehensive but only to serve as a starting
point for legal reviews of a funds transfer program. By offering a funds transfer program, Visa does
not imply regulatory approval of the acquirer, service provider, merchant’s or issuer’s funds
transfer services. Acquirers, service providers, merchants and issuers should seek their own legal
advice when implementing a funds transfer program.
7.1 Regulatory Compliance
Acquirers, service providers, merchants, and recipient issuers must satisfy the relevant legal and
regulatory requirements in their jurisdiction of operation for the origination and receipt of OCTs. This
includes compliance with all applicable sanctions and “Know Your Customer,” anti-money laundering,
and anti-terrorist financing laws.
If an acquirer or recipient issuer uses a third party agent, the third party agent must follow all Visa
Rules related to working with such agents.
Many jurisdictions may require acquirers, service providers, merchants, and issuers to report
suspicious activity, examples of which might include but are not limited to: excessive payment to an
account, transfers above a defined maximum amount, or payments made to or from particular
geographical areas. Acquirers, service providers, merchants, and issuers should be aware of reporting
requirements and other mechanisms required to adhere to local anti-money laundering and anti-
terrorist financing laws.

7.2 Key Standards and Legislation
This section provides acquirers, service providers, merchants, and issuers with an overview of select
international standards and U.S. laws that they need to be familiar with, including but not limited to,
those related to Payment Card Industry Data Security Standards (PCI DSS), anti-money laundering
(AML) and anti-terrorist financing (ATF):
 International Money Laundering Information Network website: Details of relevant standards
and legislation can be found at the International Money Laundering Information Network website:
http://www.imolin.org/.
 Financial Action Task Force (FATF)—FATF publishes recommendations designed to prevent the
financial system from being used for money laundering and terrorist financing. The
recommendations are being incorporated into national and regional laws in different ways, to
accommodate for the variety of constitutional structures and national circumstances. Refer to the
Wolfsberg Group documents at the following link: http://www.wolfsberg-
principles.com/standards.html.
 Payment Card Industry Data Security Standard (PCI DSS)—This is a worldwide information
security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC).
The standard applies to all organizations which hold, process, or pass cardholder information from
any card branded with the logo of one of the card brands. Refer to:
https://www.pcisecuritystandards.org/ .
 Bank Secrecy Act—The U.S. Bank Secrecy Act of 1970 (or BSA, or otherwise known as the
Currency and Foreign Transactions Reporting Act) requires U.S financial institutions to assist U.S.
government agencies to detect and prevent money laundering. Specifically, the act requires
financial institutions to keep records of cash purchases of negotiable instruments, file reports of
cash transactions exceeding US$10,000.00 (daily aggregate amount), and to report suspicious
activity that might signify money laundering, tax evasion, or other criminal activities.
 USA PATRIOT Act—The purpose of the USA PATRIOT Act, which amended the Bank Secrecy Act,
is to deter and punish terrorist acts in the U.S. and around the world, to enhance law enforcement
investigatory tools, and other purposes, some of which include:
 To strengthen U.S. measures to prevent, detect, and prosecute international money laundering
and financing of terrorism.
 To require all appropriate elements of the financial services industry to report potential money
laundering.
 Office of Foreign Assets Controls (OFAC)—Under the U.S. Department of the Treasury, OFAC
administers and enforces economic and trade sanctions based on U.S. foreign policy and national
security goals against targeted foreign countries and regimes, terrorists, international narcotics
traffickers, those engaged in activities related to the proliferation of weapons of mass destruction,
and other threats to the national security, foreign policy or economy of the United States.
Acquirers, service providers, merchants, and issuers may need to block transfers received from and
sent to specified countries and persons. Acquirers, service providers, merchants must be prepared

to provide recourse for exception items resulting from transactions rejected due to a recipient
institution’s inability to perform the necessary checks to comply with these programs.
URL: http://www.treasury.gov/about/organizational-structure/offices/Pages/Office-of-Foreign-
Assets-Control.aspx
 Data Privacy— Acquirers, service providers, merchants and issuers must comply with applicable
data privacy legislation, such as the Gramm-Leach-Bliley Act, which may place certain limitations
on financial institutions to protect the confidentiality, security, and integrity of consumer
information.
 Electronic Funds Transfer (EFT) Act/Regulation E—This U.S. statute and regulation establishes
the rights and liabilities of consumers as well as the responsibilities of all participants in EFT
activities. It outlines the steps that consumers and financial institutions need to take if the
consumer recognizes an error related to an EFT on his or her statement as well as consumer and
financial institution liability related to stolen or lost cards.
 Truth in Lending Act/Regulation Z/Card Act—This U.S. statute and regulations govern certain
aspects of the granting of credit by financial institutions to consumers. Certain provisions of Truth
in Lending Act and Regulation Z apply to credit cards and may be applicable to OCTs sent to Visa
credit accounts.
 Fair Credit Reporting Act—This U.S. act governs the assemblage, evaluation, maintenance, and
dissemination of information on consumers that has been collected for the purpose of evaluating
their eligibility for credit, insurance, employment, or certain other transactions initiated by such
consumers. Compliance with this act is required when a consumer report is used to determine the
eligibility of a Visa cardholder to send or receive Money Transfers or otherwise participate in a
Money Transfer program.


Enhanced Original Credit Transaction (OCT) Data Elements and Processing Rules
A Enhanced Original Credit Transaction (OCT) Data Elements and Processing Rules
This appendix provides the enhanced OCT data elements and processing rules for OCTs initiated as 0200 full financial messages. Field 43
and 104 may contain relevant data as required by the Wire Transfer Regulations44. This is particularly relevant for all EEA countries.
 Table A–1: Enhanced OCT Data Elements—Provides the enhanced OCT data element requirements for each type of OCT (Money
Transfer, Funds Disbursements, prepaid load, and credit card bill payment) along with the associated VisaNet edits. This appendix
focuses on the data elements that have unique requirements for OCTs. For the latest information on these fields, refer to the V.I.P.
manuals Base II system manuals.
 Table A–2: Source of Funds—Outlines the values for Field 104, Dataset ID 5F, Tag 08. This tag provides issuers with the source of funds
used to fund the OCT (e.g., Visa Credit, Visa Debit, Visa Prepaid, or cash). Issuers can use this information to assist them with their
authorization decision.
 Table A–3: Enhanced OCT Processing Rules—Provides the enhanced OCT data element processing rules for each type of OCT.
 Table A–4: V.I.P., BASE II, and Edit Package Decline Response and Reject Reason Codes—Provides an overview of the decline
response and reject reason codes. For a complete listing of Response Codes, refer to the SMS Technical Specifications, Vol. 1.
Note: This appendix outlines the VisaNet OCT data elements and processing rules. Acquirers, Service Providers, and Merchants using the
Visa Direct APIs should refer to the Visa Developer Center. (https://developer.visa.com/)
(https://developer.visa.com/capabilities/visa_direct).
This appendix does not include all the data elements required in the OCT; it only highlights those data elements that have
unique data. For all other data elements and for more detailed information on existing VisaNet data elements, refer to the VisaNet
system manuals. SMS POS (Visa & Visa Electron) Technical Specifications, Volume 2 V.I.P. System.
44 Regulation (EU) 2015/847 of the European Parliament and of the Council of 20 May 2015 on information accompanying transfers of funds.

Table A-1: Enhanced OCT Data Elements

V.I.P. BASE II Money Funds Prepaid Load Credit Card Notes/VisaNet Edits
(0100/0200) (TC06) Transfer Disbursement (BAI = TU) Bill Payment
Field Name Field Name (BAI = AA, BI, (BAI = BP, FD, (BAI = CP)
PP, WT GD, GP, LO,
MD, OG, PD)
Field 2 TCR 0 Recipient’s Same Same Same

Primary Positions: 5– Visa account
Account 20 number.
Number Account
Length: Number
variable Length: 16
Format: 1- Format: UN
byte binary
and up to 19
N, 4-bit BCD
(unsigned
packed);
maximum 11
bytes
Field 3 n/a Must contain a Same Same Same V.I.P. Edit: If an acquirer, service provider, merchant sends
Processing value of 26 an OCT to a recipient issuer BIN that is blocked from
Code (positions 1–2). receiving them, V.I.P. will decline the transaction with the
Brazil: Position Brazil: Note: Position
Brazil: response code value of 93 (Transaction could not be
Length: 3 3-4 must Position 3-4 3-6 contains
Position 3-4 completed—Violation of law) (unless it is being sent to an
Format: 6 BCD contain a value must contain a 0000.
must contain a of 20 for a embargoed country; in this case, a response code value of
value of 20 for
value of 20 for combo card. 62 is used).
a combo card.
a combo card. Position 5-6 Position 5-6 V.I.P. Edit (Money Transfer OCTs): For SMS issuers, if the
Position 5-6 contain 00. contain 00. PCR cannot accept a Processing Code of 26, V.I.P. will
contain 00. decline the OCT with Response Code 57.

PP, WT GD, GP, LO,
MD, OG, PD)
Note: Note: Position Note: Position V.I.P. Edit (Funds Disbursement/Non-Money Transfer
Positions 3-6 3-6 contains 3-6 contains OCTs): For SMS issuers, if the PCR cannot accept a
contain 0000 0000. 0000. Processing Code of 26, V.I.P. changes the Processing Code
for all of 26 to 20.
countries but Brazil: Some Issuers in Brazil Issue "Combo Cards" that
Brazil.
have both a checking/prepaid account as well as a credit
line linked to the same card. For such cards, it is important
to send "20" in position 3-4, so that the OCT deposits funds
into the checking/prepaid account.
n/a All TCRs Value = 2 Same Same Same Note: TCQ value of 2 must be present in all OCT-associated
Position: 3 transactions including the TC06, TC16, TC26, and TC36.
Transaction
Code Qualifier
(TCQ)
Length: 1
Format: AN
Field 4 TCR 0 Domestic and Cross Border Same as Funds Same as All OCTs except Money Transfer:
Amount, Positions: Cross-Border and Domestic Disbursement. Funds Unless otherwise noted, the VisaNet system limit per
Transaction 77–88 Limit: must be less Note: Disbursement. transaction is US$50,000.00.
Source Must be less than or equal Although
Length: 6 Amount limits will be defined for each program below the
Amount than or equal to US$50,000.00
Format: 12 US$50,000.00 limit as necessary or as required by local laws
to US$2,500.00 US$50,000.00 is the VisaNet
BCD Length: 12 or regulations.
except for: limit, individual
Format: UN VisaNet Edits (Funds Disbursement/Non-Money
 Singapore, country
Transfer): 0200 messages (enhanced or basic) exceeding
Australia, programs may
the US$50,000.00 limit are declined with response code 13
Russia: impose lower

PP, WT GD, GP, LO,
MD, OG, PD)
US$15,000.00 limits for (invalid amount). TC06 transactions exceeding the limit are
Domestic prepaid load returned with response code D3 (the US dollar value of a
Limit OCTs. transaction exceeds the maximum amount allowable). Some
 U.S. specific domestic transaction limits apply – see specific
Domestic limits and effective dates in the Funds Disbursement
Limit column to the left. This edit will be applied based on the
US$10,000 limits listed.
 Canada V.I.P. Edit (Enhanced Format Money Transfer): On
Domestic enhanced Money Transfer OCTs (Processing Code 26 and
Limit BAI AA or PP), if the amount is greater than US$2,500.00,
US$10,000 V.I.P. will decline the transaction with the response code
value of 61 (Exceeds amount limit) (except on specific
domestic transactions – see specific limits and effective
dates in the Money Transfer column to the left. This edit will
be applied based on the limits listed).
V.I.P. Edit (Enhanced Format OCT) – Velocity Limits: On
enhanced OCTs, if transaction exceeds an issuer-defined
velocity limit (1-day, 7-day or 30-day amount or count limit)
and issuer option is to decline when a limit is exceeded,
V.I.P. will decline the transaction with the response code
value of 61 (exceeds amount limit) or 65 (exceeds count
limit).
Note: Response Code 61 is used if both an amount and
count limit are exceeded.
Field 14 n/a n/a n/a n/a n/a The expiration date is an optional field for acquirers, service
Expiration providers, and merchants; however, some issuers will not
Date approve if the expiration date information is missing. If it is

PP, WT GD, GP, LO,
MD, OG, PD)
Length: 2 present in the OCT, the transaction will be forwarded to the
Format: 4 BCD issuer with the expiration date.
Issuers need to be prepared to receive OCTs with or without
the expiration date.
Field 18 TCR 0 AA or PP: BB, FD, LO, 6012 or 6540 4829 or 6012 Refer to Section 2.3.4 Business Application Identifier (BAI),
Merchant Positions: 4829 or 6012. MD (For BAI Merchant Category Code (MCC), and Use Cases for a full list
Type 133–136 WT, 4829 MD – of BAI and MCC usage.
Merchant Merchant V.I.P. Edit: OCTs may be initiated at ATMs but a Merchant
Length: 2 US Domestic:
Category settlements; Category Code of 6011 must not be used. If an MCC of
Format: 4 BCD If an OCT is MCC should
Code 6011 is used on an OCT, it is declined with Response Code
initiated by a be 6012 for
Length: 4 57.
non-bank, Acquirers who
Format: UN 4829 is used. V.I.P. Edit (Enhanced Money Transfer): On enhanced
are sending
Money Transfer OCTs (Processing Code 26 and BAI AA or
If an OCT is settlement
PP), if this field does not contain 4829 or 6012, V.I.P. will
initiated by a payments to
reject the transaction with the reject code value of 0635
bank, 6012 is merchants and
(Invalid Merchant Category Code).
used. 4829 – for
Payment V.I.P. Edit (Enhanced Money Transfer, U.S. Only): When
Facilitator U.S. Acquirers, service providers, and merchants send
sending enhanced Money Transfer OCTs with an MCC value of 4829
settlement or 6012, the OCT must contain a BAI of AA or PP. If not,
payments to V.I.P. will decline the transaction with Response Code 93.
merchants.) BASE II returns TC06 OCTs with MCC 4829 or 6012 with
GD: 9399, Reason Code 02 (The transaction type of the source BIN or
9402, 9405, center is invalid).
9222, 9211,
9311

PP, WT GD, GP, LO,
MD, OG, PD)
GP: 7800, 7802 Edit Package rejects domestic TC06 OCTs with MCC 4829
(US only), 7995 or 6012 with Reject Code V1120 (Money Transfer OCT
PD: 8931 transaction is not allowed).
OG: 7800, Edit Package rejects cross-border TC06 OCTs with MCC
7801, 7802 (US 4829 or 6012 with Reject Code V1195.
only), 7995 US Domestic:
Based on the type of services, combine MCC 6012 with a
valid BAI.
 Bank initiated P2P services can use a combination
of BI or PP and 6012.
 Non-bank offered P2P services must use a
combination of PP and 4829.
Field 23 TCR 7 Acquirers, service providers, and merchants in S. Africa,

Card Positions: 7–9 Kenya, and Nigeria may send in domestic OCTs. Issuers in
Sequence Card those countries must be prepared to receive this field in
Number Sequence domestic OCTs.
Number
Fixed length
3 N, 4-bit BCD
(unsigned
packet); w
bytes
Field 25 n/a Contains the Same Same Same Valid values include the following:
POS POS Condition 59 indicates an e-commerce transaction.
Condition Code
05 indicates a cardholder present, card not present
Code applicable to
transaction.

PP, WT GD, GP, LO,
MD, OG, PD)
Length: 1 the access For all valid values and for complete details on this field,
Format: 2 BCD channel. refer to the V.I.P. manuals.
Field 35 n/a Optional only Same Same Same Contains the information encoded on Track 2 of the
Track 2 Data on domestic magnetic stripe or chip. Acquirers, service providers, and
transactions in merchants may send in domestic OCTs and issuers must be
S. Africa, prepared to receive this field in domestic OCTs.
Kenya, Nigeria, Refer to the V.I.P. manuals for the details of this field.
Kazakhstan,
Russia, and
Ukraine
Field 39 TCR 5 V.I.P. Edits (All OCTs):

Positions: 35- Refer to Table A-4: V.I.P. Decline Response Codes
Response
Code 36
Length: 2 Authorization
Response
Format: 2 AN
Code
EBCDIC
Length: 2
Format: AN
Field 42 Must contain a Must contain a Must contain a Must contain The unique CAID from the original transaction message is
Card Acceptor unique unique unique a unique required in any subsequent messages, including reversals,
Identification identifier for identifier for identifier for identifier for disputes, and representments.
Code the merchant. the merchant the merchant. the merchant. V.I.P. Edits:
or government
Length: 15 This field must contain a non-zero value.
entity that is
disbursing

PP, WT GD, GP, LO,
MD, OG, PD)
Format: ANS, funds to a Visa
EBCDIC, 15 account
bytes holder.
Field 43 TCR 0 Cross-border Contains the Contains one Contains one This information will appear on the cardholder’s statement
Card Acceptor Positions: 92– and name of the of the of the and helps the cardholder identify the transaction and avoids
Name/ 116 Domestic: merchant or following: following: unnecessary calls by the cardholder to their issuer to help
Location, Merchant Must contain government Name of the Name of the identify the transaction.
Positions: 1– Name sender’s name. entity sending load partner entity Money Transfer Field Format (required for US; strongly
25 U.S. and the Funds providing the providing the recommend for all other countries):
Length: 25
Europe Disbursement. reload service, credit card bill The Card Acceptor Name field must contain the “Doing
Length: 25 Format: AN
Domestic: For BAI or Bank payment Business As” (DBA) name or abbreviation of the merchant
Format: 25
Must contain MD/merchant designated service, or (1–4 characters) and be the name most recognizable to the
ANS
provider's settlement – service name, Bank cardholder in addition to the sender’s name.
name or this needs to if offered over designated
abbreviation, contain the bank channels. The Merchant Name field must conform to the following
service name,
asterisk (*), name of the format:
if offered over
and the acquirer or Format Field Position Data
bank channels.
sender’s name. payment Pos. 1–4: Merchant Name or abbreviation
facilitator that Pos. 5: Asterisk (*)
Other
Pos. 6–25: Sender Name
Domestic: It is is sending
recommended settlement For bank initiated P2P Money Transfer programs facilitated
that it contain payments to via a service provider or processor, it is recommended that
the sender’s the merchant
an abbreviation of the sender banks name be used.
name; MCCs: Recommendations for abbreviations include:
additionally, 6012 –  If a bank is publicly traded, the ticker symbol should be
may also Acquirers used as the abbreviation.
include the sending

PP, WT GD, GP, LO,
MD, OG, PD)
name of the settlement  If the bank is not publically traded then either the first
Money payments to four letters of the institution name or the first letter of
Transfer merchants each word in the institution name can be used; for
provider, the 4829 – example,
name of the Payment - Bank of America (publically traded) would be
merchant, or a Facilitator abbreviated as BOA
generic sending - First National Bank might be abbreviated as FNB
identifier such settlement Sender Name Example:
as “Money payments to
Transfer”.  Last Name/Family Surname 1 plus space
merchants
 Last Name/Family Surname 2 (optional) plus space
Note: Sender’s
 First Name plus space
name must be
populated  Middle Initial or Middle Name (optional) plus space
using the Latin Examples:
(i.e., English) Doe Jane A.
character set. Vellaichary Jabachardinat Savi
Field 43 TCR 0 Value = Visa Same Same Same This information will appear on the cardholder’s statement
Card Acceptor Positions: Direct and helps the cardholder identify the transaction and avoids
Name/ 117–129 unnecessary calls by the cardholder to their issuer to help
Location, Merchant City identify the transaction.
Positions: 26– Length: 13 Issuers must be prepared to accept any valid value in this
38 field.
Format: AN
Length: 13
Format: 13
ANS

PP, WT GD, GP, LO,
MD, OG, PD)
Field 43 TCR 0, Contains the Same Same Same Refer to the V.I.P. manuals for the details of this field.
Card Acceptor Positions: 2-character
Name/ 130–132 alpha country
Location, Merchant code of the
Positions: 39– Country Code merchant’s
40 location.
Length: 3
Length: 2 Format: AN
Format: 2 ANS
Field 44.1 n/a Contains the Same Same Same Visa provides the response source/reason code in this field.
Response response Refer to the V.I.P. manuals for details.
Source/ source/reason
Reason Code code that
identifies the
source of the
Field 39
response
decision (e.g.,
whether the
issuer
responded or
Visa
responded on
the issuer’s
behalf).
Field 45 n/a Optional only Same Same Same Contains the information encoded on Track 1 of the
Track 1 Data on domestic magnetic stripe or chip.

PP, WT GD, GP, LO,
MD, OG, PD)
transactions in Acquirers, service providers, and merchants may send in
Kazakhstan, domestic OCTs and issuers must be prepared to receive this
Russia, and field in domestic OCTs.
Ukraine. Refer to the V.I.P. manuals for the details of this field.
Field 48, n/a Issuers Same Same Same This subfield will contain a value of binary 11 when the OCT
Usage 37 supporting Activity Check Result field is present.
Original enhanced
This field will contain a value of binary 10 when the OCT
Credit OCTs must
Activity Check Result is not present but a watch list score is
Transaction support this
present.
(Field Length) field.
Length:
Binary 11 or
10
Format: Binary
Field 48, n/a Issuers Same Same Same This subfield will contain a value of OCT.
Usage 37, supporting
Positions: 1–3 enhanced
Original OCTs must
Credit support this
Transaction field.
(Field
Identifier)
Length: 3
Format: AN

PP, WT GD, GP, LO,
MD, OG, PD)
Field 48, n/a Issuers Same Same Same When subsequent positions in this field are present,
Usage 37, supporting positions 4–7 are present and filled with spaces.
Position: 4–7 enhanced
Reserved OCTs must
support this
Length: 4
field.
Format: AN
Field 48, n/a Issuers n/a n/a n/a This field contains the Watch List Management score on
Usage 37, supporting cross-border transactions when watch list screening is
Position: 8–10 enhanced required for the recipient issuer’s country.
Watch List OCTs must This subfield will contain a code from 000 through 100 that
Management support this indicates the results of watch list screening when it has
(WLM) Results field. been successfully completed. Issuers can use this
Code This field is information in their authorization decision.
Length: 3 populated by
Visa for
Format: AN
Canada and
U.S. issuers
Field 48, n/a Issuers Same Same Same This subfield will contain OCT activity check results for
Usage 37, supporting issuers that have elected to not have Visa decline a
Position: 11 enhanced transaction on their behalf when a count or amount limit
OCT Activity OCTs must has been exceeded.
Check Result support this Valid values are:
field.
Length: 1 1 = 1-day count or amount exceeded
This is
Format: AN 2 = 7-day count or amount exceeded
populated by
Visa if the

PP, WT GD, GP, LO,
MD, OG, PD)
issuer is 3 = 30-day count or amount exceeded
participating in Note: V.I.P. will populate this field with the priority order of
activity limit 1, 2, and then 3.
checks.
Note: If watch list screening does not apply to the
transaction but velocity checking does, Field 48, Usage 37,
positions 4–10 will contain spaces and position 11 will
contain the OCT Activity Check Result.
Field 48 Acquirers, service providers, and merchants may send Field

Usage 37 48, Usage 37 in an enhanced 0200 OCT when they choose
to include the sender’s date of birth. Issuers that do not
Positions: 12–
participate in watch list scoring or velocity limits must be
19
prepared to receive Field 48, Usage 37.
Length: 8
Refer to the V.I.P. manuals for complete details on this field.
Format UN
Sender Date
of Birth
Format:
mmddyyyy
Field 52 n/a Optional only Same Same Same Contains a PIN or password, encrypted and formatted as a
Personal on domestic block 16 hexadecimal digits.
Identification transactions in Acquirers, service providers, and merchants may send in
Number (PIN) S. Africa, domestic OCTs and issuers must be prepared to receive this
Data Kenya, Nigeria, field in domestic OCTs.
Kazakhstan,
Refer to the V.I.P. system manuals for the details of this
Russia, and
field.
Ukraine

PP, WT GD, GP, LO,
MD, OG, PD)
Field 53 n/a Optional only Same Same Same Provides data needed by the issuer or the VisaNet Security
Security- on domestic Module to process PINs entered at the point of service.
Related transactions in Acquirers, service providers, and merchants may send in
Control S. Africa, domestic OCTs and issuers must be prepared to receive this
Information Kenya, Nigeria, field in domestic OCTs.
Kazakhstan,
Refer to the V.I.P. system manuals for the details of this
Russia, and
field.
Ukraine.
Field 54 n/a n/a n/a LAC n/a This field may contain the prepaid account balance after a
(Row 1 of 2) Domestic: prepaid load.
Issuers are Contact your regional Visa representative for the
Additional
required to requirements in your country.
Amounts
provide
variable VisaNet Edit: This field may be present in a prepaid load
prepaid
length OCT response message (BAI of TU). If it is present in any
account
other type of OCT, the field will be dropped from the
1 byte, binary balance
response prior to forwarding the message to the merchant.
and 54 ANS information in
this field in
response
messages.
Merchants
must be
prepared to
receive the
prepaid
account
balance in this
field and must

PP, WT GD, GP, LO,
MD, OG, PD)
display it to
the customer.
Field 54 n/a n/a n/a Other n/a Field Layout:

(Row 2 of 2) Regions: For Byte 1: Length
Additional issuers in other Byte 2–3 (positions 1–2):
Amounts Visa regions, Account Type—This 2-digit code identifies the account
this field is type. A value of 28 (prepaid load transaction) must be used.
variable
optional in Byte 4–5 (positions 3–4):
length
responses. Amount Type—This 2-digit code describes the use of the
1 byte, binary Merchants amount. A value of 00 must be used.
and 54 ANS must be
Byte 6–8 (positions 5–7):
prepared to
Currency Code—This 3-digit code defines the currency used
receive the
in the amount (positions 9-20).
prepaid
Byte 9 (position 8):
account
Amount Sign—This 1-digit code (Field 54.4) defines the
balance in this
value of the amount as either positive (value of C) or
field and they
negative (value of D). A value of C must be used.
may be
required to Byte 10–21 (positions 9–20):
provide this Amount—This 12-character amount (Field 54.5) is right-
information to justified and contains leading zeros. This is the prepaid
the load account balance. The amount also includes an implied
partner for decimal relative to the currency code specified in positions
displaying to 5–7.
the customer. Refer to the V.I.P. system manuals for complete details on
this field.
Field 55, TCR 7 Optional for Same Same Same Issuers in these countries must support either Field 55
Usage 1 acquirers, Usage 1 or the third bit map in OCT authorization request

PP, WT GD, GP, LO,
MD, OG, PD)
VSDC Chip Chip Card service and response messages. BASE I issuers must be prepared to
Data Transaction providers, and receive TCR 7 in the BASE II messages.
Variable Data merchants to Refer to the V.I.P. system manuals for complete details on
length send for this field.
1 byte binary domestic only
and up to 255 in S. Africa,
bytes (510 hex Kenya, Nigeria.
digits),
variable by
usage;
maximum 256
bytes
Field 60.8 Refer to Same Same Same Valid values for e-commerce transactions are 05–08.
Mail/Phone/ existing BASE I  05 Fully authenticated e-commerce transaction
Electronic manuals for
 06 Merchant attempted to authenticate the
Commerce the details of
cardholder
Payment this field.
 07 Non-authenticated e-commerce transaction
Indicator
 08 Non-secure e-commerce transaction
(BASE I only)
Length: 1
On e-commerce OCTs, a value of 07 (non-authenticated
Format: 2N, 4
security transaction) is generally the most applicable value.
bit BCD
Note: Visa Secure Electronic Commerce (VSEC) with Verified
by Visa (VbV) does not apply to OCTs.

PP, WT GD, GP, LO,
MD, OG, PD)
Field 62.2 TCR 5 Acquirers, Same Same Same The Transaction ID tracks the transaction through its entire
Transaction ID Position: 5–19 service lifecycle. It is available for reconciliation, transaction
Length: 8 Transaction ID providers, research, and disputes.

and Note: If an AFT precedes the OCT, acquirers, service
Format: 15 Length: 15
merchants, providers, and merchants are strongly recommended to
BCD Format: UN and issuers take the Transaction ID from the AFT and populate it into
are required to the OCT. Acquirers, service providers, and merchants must
receive it on all not populate Field 62.2 with a value other than the
OCTs. Transaction ID from the preceding AFT.
Note: Visa will not override the Transaction ID if sent by
acquirers, service providers, and merchants in an enhanced
0200 OCT.
Field 62.20 TCR5 For Gambling AP, Canada, CEMEA, and LAC: To support the Visa Direct
MVV Position 82-91 use cases, refer Strategic Program, Issuers must be prepared to receive the
to Section MVV in domestic transactions.
Length:10 MVV
2.3.4.1.4
Format: Length: 10 Gambling and
Format: Gaming
Program
Overview for
information on
gambling and
gaming
winnings.

PP, WT GD, GP, LO,
MD, OG, PD)
Field 63.1 n/a Acquirers, Same Same Same Refer to the V.I.P. manuals for the details of this field.
service
Network Values that support OCTs:
providers and
Identification Network 2, Network 3, and Network 4
merchants:
Code
Must send a
Length: 2 value of 0000
Format: 4 BCD (Priority
Routing) or
0002 (Network
ID 2) in this
field.
Note: If an
acquirer,
service
provider, or
merchant
sends the
transaction
with a value of
0000 (Priority
Routing), it will
be routed over
Network 2.
Issuers:
Issuers will
receive a value
of 0002 in this
field.

PP, WT GD, GP, LO,
MD, OG, PD)
Field 63.6, On e- Same Same Same This is a value that indicates the level of authentication on
Position: 4 commerce the transaction; it is based on the response that the
Mail/Phone/ transactions, merchant receives during Verified by Visa processing.
Electronic the applicable Valid values for e-commerce transactions are 5–8.
Commerce value must be
 5 Fully authenticated e-commerce transaction
and Payment provided in
this field.  6 Merchant attempted to authenticate the cardholder
Indicator
 7 Non-authenticated security transaction
(SMS only)
 8 Non-secure e-commerce transaction
Length: 1
On e-commerce OCTs, a value of 7 (non-authenticated
Format: 1
security transaction) is generally the most applicable value.
ANS, EBCDIC
Refer to the V.I.P. manuals for the details of this field.
Field 63.19 TCR 1 Support of Same Same Same Refer to the BASE II Clearing Data Codes manual for details.
Fee Program Positions: 76– FPIs is
Indicator 78 according to
Fee Program regional and
Length: 3
Indicator domestic
Format: 1 requirements.
ANS, EBCDIC If clients do
not support
the FPI field
today, they are
not required
to do so for
Money
Transfer.

PP, WT GD, GP, LO,
MD, OG, PD)
n/a TCR 3 BASE II will set Same Same Same Issuers participating in Fast Funds can use this field as
Position: 16 the value of follows:
Fast Funds this field to  If the indicator is set to Y, it means that the issuer
Indicator one of the already received the associated 0100 message.
following Assuming that the issuer made funds available upon
values in the receipt of the 0100 message, issuer does not need to
TC06: post the TC06.
Y (OCT is  If the indicator is set to a space, it means that the issuer
eligible for did not receive the associated 0100 message and
Fast Funds) therefore, the issuer should use the TC06 to post the
Space (OCT is funds into the recipient’s account.
not eligible for
Fast Funds)
n/a TCR 3 Value = CR Same Same Same

Pos. 17–18
Business
Format Code
Field 104, TCR 3 AA (account to BB = Supplier Value = TU Value = CP Refer to Section 2.3.4 Business Application Identifier (BAI),
Usage 2, Positions: 19–
account) must payments Merchant Category Code (MCC), and Use Cases for a full list
Dataset Value 20 be used if the FD = Funds of BAI definitions and sample use cases.
Hex 57 Business transfer is to Disbursement All BAIs listed are available for use in OCTs.
Business Application the sender’s
GD = This field uniquely identifies the type of enhanced OCT.
Application Identifier (BAI) own account. Government V.I.P. Edit: This field must be present in OCT authorization
Identifier (BAI) PP (person to Disbursement and SMS 0200 OCT responses.
Tag: 01 person) must
be used if the

PP, WT GD, GP, LO,
MD, OG, PD)
Length: 2 transaction is GP = V.I.P. Edit: If an enhanced SMS 0200 OCT is sent with BAI of
Format: AN sent to Gambling TU to a non-prepaid Visa account, it is declined with
another payout (non- Response Code 57 (Transaction not permitted to
person’s online cardholder).
account. gambling) V.I.P. Edit: If an SMS 0200 OCT with a BAI of CP is sent to a
WT Wallet LO = Loyalty non-credit Visa account, V.I.P. will decline the OCT with
transfer; i.e., credits and Response Code 57 (Transaction not permitted to
unloading of a rebates cardholder).
digital wallet MD = V.I.P. Edit: If an SMS 0200 OCT with a BAI of TU or CP is
to a Visa Merchant sent on a cross-border transaction, V.I.P. will decline the
account settlement OCT with Response Code 93. (Transaction cannot be
US Domestic: OG = Online completed – violation of law).
In the U.S. PP Gambling V.I.P. Edit: If the issuer does not support Money Transfer
is for use by Payout OCTs with BAIs AA or PP, V.I.P will decline the OCT with
non-banks PD = Payroll Response Code 57 (Transaction not permitted to
only. and pension cardholder).
BI (bank disbursement V.I.P. Edit: V.I.P. rejects an SMS 0200 OCTs with reject code
initiated 0494 (Field or data missing or invalid) if they do not contain
person to the BAI in Field 104 Dataset ID 57.
person) must
be used if the
Edit Package will continue to reject the transactions with
transaction is
the existing reject code value of V1161 (Business application
initiated by a
ID of AA and PP is not valid for the specific transaction).
bank and is
sent to US Domestic:
another Based on the type of services, combine MCC 6012 with a
valid BAI.

PP, WT GD, GP, LO,
MD, OG, PD)
entities  Bank initiated P2P services can use a combination
account. of BI or PP and 6012.
 Non-bank offered P2P services must use a
combination of PP and 4829.
Field 104, TCR 3 Dataset 5F Same Same Same Important: Field 104, Dataset ID 5F is a Tag-Length-Value
Usage 2, Position: must be (TLV) encoded field that is currently defined with eight
Dataset Value 24–168 present in OCT different tags (Tag 01–Tag 08. 0A.)
Hex 5F Industry requests. Tag 01 or Tag 02 must be present (or both may be present).
Sender Data Specific All the other tags are conditional or optional based on the
Note: This Data— specific type of OCT (i.e., BAI) and the transaction specifics
field is Tag- Original (e.g., domestic vs. cross-border). Following basic TLV coding
Length-Value Credit principles, issuer systems need to be flexible enough to
(TLV). accommodate these variations and flexible enough to
accommodate new tags in this field as they are introduced.
If you are not familiar with how to code your system to
support TLV fields, please contact your regional Visa
representative for support.
Important:
 Acquirers, service providers, and merchants must not
format tags as right-justified with leading spaces.
 Acquirers, service providers, and merchants should not
pad tags to their maximum length with spaces or binary
zeros.
V.I.P. Edit (Enhanced 0200 OCTs):
For enhanced OCTs, if the acquirer, service provider, or
merchant provides sender data (name, address, city, state,

PP, WT GD, GP, LO,
MD, OG, PD)
country) and recipient name in Field 104 Dataset 5F and
exceeds the maximum length in any of the TLV fields in
dataset 5F, the transaction will be declined with existing
reject code of 0494 (Field or data missing or invalid).
Field 104, TCR 3 Dataset 5F Same Same Same V.I.P. Edit: This field should not be present in authorization
Usage 2, Positions: must be and full financial responses and if present, it will be dropped
Dataset Value 24–168 present in OCT from the message by V.I.P.
Hex 5F Industry requests. V.I.P. Edit (Money Transfer): On enhanced Money Transfer
Sender Data Specific transactions (Processing Code 26 and BAI of AA/PP or BI),
Note: This Data— if the issuer PCR is not set up in the VisaNet system to
field is Tag- Original support Field 104 in TLV format, V.I.P. will decline the
Length-Value Credit transaction with the response code value of 57 (Transaction
(TLV). not permitted to cardholder).
(Row 1 of 2) V.I.P. Edit (Enhanced Money Transfer): On enhanced

Money Transfer OCTs (Processing Code 26 and BAI AA or
PP), Field 104, Dataset ID 5F must be present. If this dataset
is not present, V.I.P. will reject the transaction with the reject
code value of 0494 (Field or data missing). For all other
OCTs, this data element must be present but will not be
enforced with VisaNet edits.
V.I.P. Edit (Enhanced): If the acquirer, service provider, or
merchant does not provide a given tag in this dataset, the
tag must be omitted from the message. If any of Tags 01 to
07 are included and filled with all spaces or all zeros. V.I.P.
will decline the transaction with the response code value of
64 (Transaction does not fulfill AML requirements).

PP, WT GD, GP, LO,
MD, OG, PD)
(Continued TCR 3 Dataset 5F Same Same Same (Continued from prior row.)
from prior Position: 24– must be V.I.P. Edit (All OCTs Other Than Money Transfer): If the
row.) 168 present in OCT issuer PCR is not set up in the VisaNet system to support
Field 104, Industry requests. Field 104 in TLV format and this field is present in the
Usage 2, Specific message, Visa drops Field 104 from the message and
Dataset Value Data— forwards the transaction to the issuer.
Hex 5F Original V.I.P. Edit (All OCTs): VIP rejects enhanced OCTs with the
Sender Data Credit existing reject code 0494 (Field or data missing or invalid)
Note: This for which any of the following tags in Field 104 Dataset ID
field is Tag- 5F exceeds its maximum length: Tags 01–07 and 0A.
Length-Value V.I.P. Edit for Tags 03 (Sender Name), 05 (Sender City),
(TLV). and 07 (Sender Country): For transactions originated in
(Row 2 of 2) non-U.S. or a country that does not have a national net
settlement service (NNSS), V.I.P. declines domestic OCTs
with a BAI of AA or PP with RC 64 (Transaction does not
fulfill AML requirements) if they do not include Sender
Name (03), Sender City (05), and Sender Country (07) in
Field 104 Dataset ID 5F.
V.I.P. Edit: V.I.P. rejects domestic 0200 OCTs with a BAI of
AA or PP with reject code 0494 (Field or data missing) if
they do not contain Field 104 Dataset IDs 5F.
Field 104, Positions: 24– This tag is Must be Same as Same as A transaction reference number provided by the originating
Usage 2, 39 conditional; if present. Money Money entity that can be used to uniquely identify the sender.
Dataset Value Length: 16 the sender’s May contain a Transfer. Transfer. Tag 01 or Tag 02 must be present; both may be present.
Hex 5F account number used V.I.P. Edit (Enhanced Money Transfer): On all cross-
Format: AN
Tag: 01 number (Tag by the border and U.S. domestic enhanced Money Transfer OCTs

PP, WT GD, GP, LO,
MD, OG, PD)
Length: 16 Sender 02) is not acquirer, (Processing Code 26 and BAI AA or PP), if this tag and/or
Format: AN Reference available or service Tag 02 (Sender Account Number) are not present, V.I.P. will
Number not applicable provider, or decline the transaction with the response code value of 64
Sender
to the merchant to (Transaction does not fulfill AML requirements).
Reference
transaction, track the
Number
this tag must Funds
be present and Disbursement
contain a (i.e., invoice
reference number or
number for the other type of
sender. tracking
number). Or, if
not applicable,
it must contain
a value of 123.
Field 104, Positions: 40– This tag is Optional. Same as Same as The sender’s account number.
Usage 2, 73 conditional; it Money Money Tag 01 or Tag 02 must be present; both may be present.
Dataset Value Length: 34 is required Transfer. Transfer.
V.I.P. Edit (Enhanced Money Transfer): On all cross-
Hex 5F when an This tag is This tag is
Format: AN border and U.S domestic enhanced Money Transfer OCTs
Tag: 02 account was conditional; it conditional; it
Sender (Processing Code 26 and BAI AA or PP), if this tag and/or
used to fund is required is required
Length: 34 Account Tag 01 (Sender Reference Number) are not present, V.I.P.
the Money when an when an
Format: AN Number will decline the transaction with the response code value of
Transfer (e.g., account was account was 64 (Transaction does not fulfill AML requirements).
Sender sender used a used to fund used to fund
Account credit, debit, the prepaid the credit card
Number or other load (e.g., bill payment
account sender used a (e.g., sender
(including a credit, debit, used a bank

PP, WT GD, GP, LO,
MD, OG, PD)
digital wallet or other account
account) to account (including a
fund the (including a digital wallet
Money digital wallet account) to
Transfer). account) to pay his/her
fund the credit card
prepaid load). bill).
Field 104, Positions: 74– Cross-border: Cross-border: Cross-border: Cross-border: This field contains the name of the person or entity
Usage 2, 103 Must contain Must contain n/a. n/a. funding the OCT transaction.
Dataset Value Length: 30 sender’s name. merchant/ U.S. and U.S. V.I.P. Edit (Enhanced Money Transfer): On all cross-
Hex 5F U.S., Canada, government Canada Domestic: border and U.S domestic enhanced Money Transfer OCTs
Format: AN
Tag: 03 and Europe entity’s name Domestic: Must contain (Processing Code 26 and BAI AA or PP), If this field is not
Sender Name sending funds.
Length: 30 Domestic: Must contain sender’s present, V.I.P. will decline the transaction with the response
Must contain U.S., Canada, sender’s name. name. code value of 64 (Transaction does not fulfill AML
Format: AN
sender’s name. and Europe Other Other requirements).
Sender Name Domestic:
Other Domestic: Domestic: Sender Name Example:
Domestic: Must contain May contain May contain The Sender Name can be any alphanumeric value up to
May contain merchant/ sender’s name; sender’s thirty characters long. If the sender’s name is greater than
sender’s name; government if not name; if not thirty (30) characters, use only the first thirty characters of
if not entity’s name. applicable, do applicable, do the name. The suggested format for the Sender Name field
applicable, do Other not include not include is:
not include the Domestic: this tag. this tag.
 Last Name/Family Surname 1 plus space
tag. May contain Note: Sender’s Note:  Last Name/Family Surname 2 (optional) plus space
Note: Sender’s merchant/ name must be Sender’s name  First Name plus space
name must be government populated must be  Middle Initial or Middle Name (optional) plus space
populated entity’s name; using the Latin populated
Examples:
using the Latin if not (i.e., English) using the Latin

PP, WT GD, GP, LO,
MD, OG, PD)
(i.e., English) applicable, do character set (i.e., English)  Doe Jane A.
character set not include and be an character set  Vellaichary Jabachardinat Savi
and be an this tag. actual person’s and be an V.I.P. Edit for Tag 03 (and 05 and 07): For transactions
actual person’s Note: name. Use of a actual originated in non-U.S. or a country that does not have a
name. Use of a Merchant/ phone person’s national net settlement service (NNSS), V.I.P. declines
phone government number, email name. Use of domestic OCTs with a BAI of AA/PP with RC 64 (Transaction
number, email entity’s name address or a phone does not fulfill AML requirements) if they do not include
address or must be alias is not number, email Sender Name (03) (and Sender City (05) and Sender
alias is not populated permitted. address or Country (07)).
permitted. using the Latin alias is not V.I.P. Edit for Tags 03 (or 0A): V.I.P. declines 0200 OCTs
(i.e., English) permitted. with a BAI of AA/PP with RC 64 (Transaction does not fulfill
character set. AML requirements) if the Sender Name (03) (or Recipient
Name (0A)) contains:
 All numerics
For BAI MD - Merchant Settlements; Sender Name needs
to contain the name of the acquirer or payment facilitator
that is sending settlement payments to the merchant.
MD MCCs:
6012 – Acquirers sending settlement payments to
merchants
4829 – Payment Facilitator sending settlement payments to
merchants
Field 104, N/A Cross-border: Cross-border, Cross-border, Cross-border, This field contains the name of the person or entity
Usage 2, See Note. Recipient U. S. U. S. U. S. receiving the funds. Recipient name is an optional data
name Domestic, and Domestic, Domestic, element in Field 104 Dataset ID 5F, Tag 0A, in an enhanced

PP, WT GD, GP, LO,
MD, OG, PD)
Dataset Value mandatory in Other and Other and Other OCT initiated as an 0200 for domestic and mandatory for
Hex 5F cross-border Domestic: Domestic: Domestic: cross-border OCTs.
Tag: 0A Money Recipient Recipient Recipient Exception: This tag is required in all 0200 full financial
Transfer. name optional name may be name may be request messages sent by acquirers, service providers, and
Length: 30
U.S. and may be present in, present in merchants for cross-border enhanced Money Transfer
Format: AN Europe present in domestic and domestic and OCTs.
Recipient Domestic: domestic and cross-border cross-border Issuers must be prepared to receive
Name Optional to send cross-border prepaid card bill Tag 0A/Recipient Name in any enhanced OCT.
for domestic Funds loads/re-loads. payment.
The maximum length of the recipient name is 30 characters.
Disbursements.
Recipient Name Example:
The Recipient Name can be any alphanumeric value up to
thirty characters long. If the recipient’s name is greater than
thirty (30) characters, use only the first thirty characters of
the name. The suggested format for the Recipient Name
field is:
 Last Name/Family Surname 1 plus space
 Last Name/Family Surname 2 (optional) plus space
 First Name plus space
 Middle Initial or Middle Name (optional) plus space
Examples:
 Doe Jane A.
 Vellaichary Jabachardinat Savi
Requirements for support of Recipient Name in responses,
etc., are the same as for Sender Name in Field 104 Dataset
ID 5F.

PP, WT GD, GP, LO,
MD, OG, PD)
Note: Visa will not populate the TC06 OCT with recipient
name, so there is no equivalent BASE II data element.
V.I.P. Edit for Tag 0A (or 03): V.I.P. declines 0200 OCTs
with a BAI of AA/PP with RC 64 (Transaction does not fulfill
AML requirements) if the Recipient Name (0A) (or Sender
Name (03)) contains:
 All numerics
Field 104, Positions: Cross-border: Cross-border: Cross-border: Cross-border: For Money Transfer, prepaid load, and credit card bill
Usage 2, 104–138 Must contain Must contain n/a. n/a. payment, this should be the sender’s primary address.
Dataset Value Length: 35 sender’s merchant/ U.S. and U.S. and For Funds Disbursement, this should be the merchant or
Hex 5F address. government Canada Canada government entity’s primary business address in the
Format: AN
Tag: 04 U.S. entity’s Domestic: Domestic: country where the transaction was initiated.
Sender address.
Length: 35 Address
Domestic: Must contain Must contain V.I.P. Edit (Enhanced Money Transfer): On all cross-
May contain U.S. and sender’s sender’s
Format: AN border and U.S. domestic enhanced Money Transfer OCTs
sender’s Canada address. address.
Sender (Processing Code 26 and BAI AA or PP), if this field is not
address. If not Domestic:
Address Other Other present, V.I.P. will decline the transaction with the response
required (may Must contain Domestic: Domestic: code value of 64 (Transaction does not fulfill AML
not be merchant/ May contain May contain requirements).
required to be government sender’s sender’s
collected in all entity’s address; if not address; if not
circumstances address. required, do required, do
under local
Other not include not include
AML/ATF
Domestic: this tag. this tag.
laws), populate
May contain
the tag with
merchant/

PP, WT GD, GP, LO,
MD, OG, PD)
“not government
applicable” entity’s
Other address; if not
Domestic: required, do
May contain not include
sender’s this tag.
address; if not
required, do
not include
this tag.
Field 104, Positions: Cross-border: Cross-border: Cross-border: Cross-border: V.I.P. Edit (Enhanced Money Transfer): On all cross-
Usage 2, 139–163 Must contain Must contain n/a. n/a. border and U.S. domestic enhanced Money Transfer OCTs -
Dataset Value sender’s city. merchant/ Processing Code 26) and BAI AA or PP if this field is not
Length: 25 U.S. and U.S. and
Hex 5F government present, V.I.P. will decline the transaction with the response
Format: AN U.S. and Canada Canada
entity’s city. code value of 64 (Transaction does not fulfill AML
Tag: 05 Canada Domestic: Domestic:
Sender City requirements).
Length: 25 Domestic: U.S. and Must contain Must contain
Must contain Canada sender’s city. sender’s city. V.I.P. Edit for Tags 05 (Sender City) (and 03 (Sender
Format: AN Name) and 07 (Sender Country)): For transactions
sender’s city. Domestic: Other Other
Sender City Must contain originated in non-U.S. or a country that does not have a
Other Domestic: Domestic:
merchant/ national net settlement service (NNSS), V.I.P. declines
Domestic: May contain May contain
government domestic OCTs with a BAI of AA/PP with RC 64 (Transaction
May contain sender’s city; if sender’s city; if
does not fulfill AML requirements) if they do not include
sender’s city; if entity’s city. not required, required, do
Sender City (05), (Sender Name (03), and Sender Country
not required, Other do not include not include
(07)) in Field 104 Dataset ID 5F, Tags 03, 05, and 07.
do not include Domestic: this tag. this tag.
this tag. May contain
merchant/
government

PP, WT GD, GP, LO,
MD, OG, PD)
entity’s city; if
not required,
do not include
this tag.
Field 104; Positions: Domestic and Domestic and Cross-border: Cross-border: The geographical state or province associated with the
Usage 2; 164–165 Cross-border Cross-border n/a. n/a. sender’s primary residential address.
Dataset Value Length: 2 from U.S. or from U.S. or U.S. and U.S. and V.I.P. Edit (Enhanced Money Transfer): On all cross-
Hex 5F; Tag: Canada: Must Canada: Must Canada Canada border and U.S. domestic enhanced Money Transfer OCTs
Format: AN
06; Length: 2; contain contain Domestic: Domestic: (Processing Code 26 and BAI AA or PP), if this field is not
Format: AN Sender State/ sender’s merchant/ present and Sender Country (Tag 07) contains the value of
Must contain Must contain
Province state/province government 840 (U.S.) or 124 (Canada), V.I.P. will decline the transaction
Sender sender’s sender’s
State/Province in this field on entity’s state/province. state/province with the response code value of 64 (Transaction does not
cross-border state/province fulfill AML requirements).
Other Other
transactions in this field on
Domestic: Domestic:
when Sender cross-border
May contain May contain
Country (Tag transactions
sender’s sender’s
07) contains when Sender
state/province; state/province;
the value of Country (Tag
if not required, if not
840 (U.S.) or 07) contains
do not include required, do
124 (Canada). the value of
this tag. not include
Other 840 (U.S.) or
this tag.
Domestic and 124 Canada).
Cross-Border:
May contain Other
sender’s Domestic and
state/province; Cross-Border:
if not required, May contain

PP, WT GD, GP, LO,
MD, OG, PD)
do not include merchant/
this tag. government
entity’s
state/province;
if not required,
do not include
this tag.
Field 104, Positions: Cross-border: Cross-border: Cross-border: Cross-border: V.I.P. Edit (Enhanced Money Transfer): On all cross-
Usage 2, 166–168 Must contain Must contain n/a n/a border and U.S. domestic enhanced Money Transfer OCTs
Dataset Value Length: 3 sender’s merchant/ U.S. and U.S. and (Processing Code 26 and BAI AA or PP), if this field is not
Hex 5F country. government Canada Canada present, V.I.P. will decline the transaction with the response
Format: AN
Tag: 07 U.S., Canada entity’s Domestic: Domestic: code value of 64 (Transaction does not fulfill AML
Sender country. requirements).
Length: 3 and Europe Must contain Must contain
Country
Domestic: U.S., Canada, sender’s sender’s V.I.P. Edit (Cross-Border Enhanced Money Transfer): On
Format: AN
Must contain and Europe country. country. cross-border enhanced Money Transfer OCTs, if this tag
Sender sender’s Domestic: does not contain a 3-digit value, V.I.P. will decline the
Other Other
Country country. Must contain message with the response code value of 93 (Transaction
Domestic: Domestic:
Other merchant/ May contain May contain cannot be completed – violation of law).
Domestic: government sender’s sender’s V.I.P. Edit (Sanctioned OFAC Countries): For enhanced
May contain entity’s country; if not country; if not 0200 OCTs, if the sender country is on the list of U.S. OFAC
sender’s country. required, do required, do comprehensively sanctioned countries that currently
country; if not Other not include not include consists of Crimea, Cuba, Iran, North Korea, Sudan, and
required, do Domestic: this tag. this tag. Syria, VIP declines the transaction with response code 93
not include May contain Note: This is Note: This is (Transaction cannot be completed – violation of law).
this tag. merchant/ the 3-digit ISO the 3-digit ISO V.I.P. Edit for Tags 07 (Sender Country) (and 03 (Sender
Note: This is government numeric numeric Name) and 05 (Sender City): For transactions originated in
the entity’s country code. country code. non-U.S. or a country that does not have a national net

PP, WT GD, GP, LO,
MD, OG, PD)
3-digit ISO country; if not settlement service (NNSS), V.I.P. declines domestic OCTs
numeric required, do with a BAI of AA/PP with RC 64 (Transaction does not fulfill
country code. not include AML requirements) if they do not include Sender Name
this tag. (03), Sender City (05), and Sender Country (07) in Field 104
Note: This is Dataset ID 5F, Tags 03, 05, and 07.
the 3-digit ISO
numeric
country code.
Field 104, Note: While Cross-border Same as Cross-border: Same as Identifies how the OCT was funded (cash, Visa card, non-
Usage 2, there is a to U.S.: Must Money n/a. Prepaid Load Visa debit account, or non-Visa credit account).
Dataset Value BASE II Source contain Source Transfer U.S. Note: Visa Acquirers, service providers, and merchants can check the
Hex 5F of Funds field of Funds. Note: For Domestic: Rules do not account number against the ARDEF tables to populate the
in the TCR 3
Tag: 08 Cross-border Funds Recommended allow source of funds as Visa Credit, Visa Debit or Visa Prepaid
(position 21),
Length: 2 to non-U.S. Disbursement, that Source of cardholders to (refer to Section A-1 for details on the Source of Funds.).45
Tag 08 does (new the most likely Funds is pay their
Format: AN not map to Valid values in this field are:
programs): value will be provided. credit debt
Source of this field. Tag  Visa Credit = 01
Recommended 05 to identify Other with a credit
Funds 08 does not  Visa Debit = 02
that Source of that the Domestic: instrument.
have a  Visa Prepaid = 03
Funds is merchant or (new Therefore, this
corresponding
provided. government programs): field must not  Cash = 04
BASE II field
U.S. entity used a Recommended contain a  Debit/deposit access accounts other than those linked
location. deposit
Domestic: that Source of to a Visa card (includes checking/savings accounts,
45 Acquirers, service providers, and merchants may also use the Visa Direct APIs or the Account Lookup File to determine the Source of Funds when the card is a Visa card.

PP, WT GD, GP, LO,
MD, OG, PD)
Must contain account to Funds is value of 01 or proprietary debit/ATM cards, and digital wallet
Source of fund the provided. 06. accounts) = 05.
Funds. disbursement.  Credit accounts other than those linked to a Visa card
Other (includes credit cards and proprietary credit lines) = 06
Domestic V.I.P. Edit (Enhanced Money Transfer): On enhanced
(new Money Transfer OCTs destined to a U.S. recipient issuer, if
programs): this field is not present, V.I.P. will decline the transaction
Recommended with the response code value of 64 (Transaction does not
that Source of fulfill AML requirements).
Funds is
provided.
Field 104, U.S. Only

Usage 2, New tag, 10, added for STAR and PULSE networks only. Pass
Dataset Value through to STAR & PULSE (MasterCard). Refer to the Push
Hex 5F Payment Gateway Client Implementation Guide.
Tag: 10
Length: 5-10
Format: AN
Sender Postal
Code
Field 104, N/A LAC Only

Usage 2, Added to support business sender tax identification in
Dataset Value OCTs. The sender’s tax ID is sent to the recipient
Hex 63; Tag: cardholder’s issuing bank.
05; Length:
Note: This field is Mandatory for Brazil, Colombia, and Peru.
20; Format:
Issuers may need this information for reporting or for other
AN;

PP, WT GD, GP, LO,
MD, OG, PD)
Business regulatory reasons. Contact your regional Visa
Sender Tax representative to confirm if this field is required in your
Identification country.
V.I.P. Edit: V.I.P. rejects transactions with reject code 0494
(Field or data missing or invalid) if the transaction contains
Business Sender Tax ID (Tag 05) and Individual Sender Tax
ID (Tag 06).
Field 104, N/A LAC Only

Usage 2; Added to support individual sender tax identification in
Dataset ID 63; OCTs. The sender’s tax ID is sent to the recipient
Tag 06; cardholder’s issuing bank.
Length: 13;
Note: This field is Mandatory for Brazil, Colombia, and Peru.
Format: AN;
Issuers may need this information for reporting or for other
Individual regulatory reasons. Contact your regional Visa
Sender Tax representative to confirm if this field is required in your
Identification country.
V.I.P. Edit: V.I.P. rejects transactions with reject code 0494
(Field or data missing or invalid) if the transaction contains
Individual Sender Tax ID (Tag 06) and Business Sender Tax
ID (Tag 05).
Field 104, TCR 1 V.I.P. Edit: This field should not be present in authorization
Usage 2; Positions: and full financial responses and if present, it will be dropped
Dataset Value 24–73 from the message by V.I.P.
Hex 71; Member Issuers must be able to process OCT without this field.
Additional Message Text
Sender Data

PP, WT GD, GP, LO,
MD, OG, PD)
Tag: 01;
Length: 45;
Format:
EBCDIC (Row
1 of 2)
A.1 Source of Funds (Field 104, Dataset ID 5F, Tag 08)
This tag provides issuers with the source of funds used to fund the OCT (e.g., Visa Credit, Visa Debit, Visa Prepaid, or cash). Issuers can use
this information to assist them with their authorization decision. This tag must be present on transactions destined to U.S. issuers (domestic
and cross-border); it is recommended on all other transactions.
Acquirers, service providers, and merchants can use the Account Range Definition (ARDEF) table, use the Visa Direct Account Lookup API
(refer to the Visa Developer Center), (https://developer.visa.com/) (https://developer.visa.com/capabilities/visa_direct) or obtain the Visa
Direct Account Lookup File (Visa Direct Account Lookup File) to determine the type of account (Visa Credit, Visa Debit, or Visa Prepaid) to
populate as the source of funds.
Table A-2 outlines the values for Field 104, Dataset ID 5F, Tag 08 and provides the information for the ARDEF table where applicable:

Table A-2: Source of Funds
Source of Funds Value in Field 104, ARDEF Table,

Dataset ID 5F, Tag 08 Account Funding Source,
Position 90
Visa Credit 01 C46
Visa Debit 02 D
Visa Prepaid 03 P
Cash* 04 n/a
Debit/deposit access accounts other than those linked to a Visa card (includes 05 n/a
checking/savings accounts and proprietary debit/ATM cards)*
Credit accounts other than those linked to a Visa card (includes credit cards and proprietary 06 n/a
credit lines)*
* Acquirers, service providers, and merchants are responsible for identifying the source of funds for non-Visa products and correctly
populating the Source of Funds field.
When the acquirers, service providers, or merchants use the ARDEF table to determine the source of funds for Money Transfer transactions
funded from a Visa card, they should:
 Take the account number and look it up in the ARDEF table.
 Check the Account Funding Source (Position 90) to determine if the Source of Funds is Visa Credit (Value = C), Visa Debit (Value = D), or
Visa Prepaid (Value = P).
46 When a customer is sending an OCT to his or her own Visa credit account, the “Source of Funds” must not be a Visa credit account.

A.2 High-Level Summary – Enhanced OCT Processing Rules by Business Application Identifier
(BAI)
This section provides a high-level summary of the processing rules for enhanced OCTs by Business Application Identifier (BAI).
Table A-3: High-Level Summary – Enhanced OCT Processing Rules by BAI
Processing Rule Money Transfer Funds Disbursement Prepaid Load Credit Card Notes
(BAI = AA, BI, PP, or WT (BAI = FD, GD, GP LO (BAI = TU) Bill Payment
MD, or OG) (BAI = CP)
General Processing Issuers must apply OCTs as a Same as Money n/a Same as Money
payment to a Visa credit Transfer. Transfer
account.
Issuers must not accept OCTs Same as Money Same as Money Same as Money
to an account that does not Transfer. Transfer Transfer
have “Know Your Customer”
information on file.
Account Types Can be sent to Visa credit, Same as Money Can be sent to Visa Can be sent to
debit, and prepaid accounts. Transfer. prepaid accounts Visa credit
only. accounts only.
Geographic Scope Domestic Domestic Domestic only Domestic only

Cross-border Cross-border

Fast Funds In specific AP and CEMEA Same as Money General: Same as Same as Money Participation in Fast
Refer to Section countries, issuers are Transfer. Money Transfer. Transfer Funds requires issuers to
3.10.4.1 Fast Funds required to support Fast LAC: Participating support the enhanced
Enablement and Funds. issuers must OCT (either 0100
Mandates for a U.S. Issuers are required to support Fast Funds messages followed by a
complete list of Fast support Fast Funds. (Prepaid on all enhanced TC06, or 0200 messages.)
Funds enablement and Debit) OCTs.
and mandates in Canada: Issuers in Canada are
various geographies. required to support Fast
Funds (Prepaid and Debit)
Europe region: Effective 13
October 2018, issuers must
support Fast Funds
processing for Direct Debit
Card, Deferred Debit Cards
(with 16-digit primary
account number and Card
Verification Value 2), and
Prepaid cards and support
Fast Funds for all approved
OCTs by processing OCT
authorization within 30
minutes of approving an
OCT.

Transaction Types Acquirers, service providers, General: Same as General: Same as Same as Money
and merchants must initiate Money Transfer Money Transfer Transfer
enhanced OCTs as 0200 Cross-border: LAC Domestic:
messages or use the Visa Acquirers, service Participating issuers
Direct APIs. providers, and must support
Issuers supporting Fast Funds merchants may send enhanced OCTs
must receive enhanced OCTs enhanced OCTs as (either 0100
as 0100 messages followed TC06s. messages followed
by a TC06 or as 0200 by a TC06 or 0200
messages. messages).
In the Europe region, issuers
must process all 0100 or
0200 Money Transfer
messages online, regardless
of whether Fast Funds is
supported or not.

Reversals and Acquirers, service providers, General: Same as General: Same as Same as Money OCT reversals contain
Adjustments and merchants sending Money Transfer Money Transfer Transfer Field 104, Dataset IDs 57,
enhanced 0200 OCTs are not Cross-border: if an LAC Domestic: 5F, and 71.
permitted to initiate OCT acquirer, service Load partner and OCT adjustments contain
reversals. Good faith provider, or merchant merchant reversals a Message Reason Code
adjustments may be used. sends an enhanced are allowed in (Field 63.3) value of
Issuers continue to need to TC06, reversals are specific situations. 2150.
be prepared to receive allowed only for See Section 5.1.3 Note: The processing
reversals for timeout processing errors and Prepaid Load OCT code needs to be the
scenarios. within 1 business day Reversals – LAC debit or credit
of the original. Region for details. adjustment processing
code, not the OCT
processing code.
Disputes Only dispute reason codes Same as Money Same as Money Same as Money Disputes do not contain
77, 82, and 85 may be used Transfer Transfer Transfer Field 104. If Field 104 is
U.S.: dispute reason code 77 present in a dispute, it
not allowed will be dropped by V.I.P.
prior to forwarding the
OCT dispute reversals are
transaction to the
only allowed within one
acquirers, service
business day of the dispute.
providers, or merchant.

A.3 V.I.P., BASE II, and Edit Package Decline Response and Reject
Reason Codes
For a complete listing of Response Codes, refer to the SMS POS Technical Specifications, Vol. 1.
Table A-4 outlines V.I.P. decline response codes related to OCTs.

Table A-4: V.I.P. Decline Response Codes
Value OCT Edits
12 (Invalid If the recipient issuer has received a waiver related to the receipt of OCTs, the
transaction) recipient issuer should decline an OCT with Response Code 12.
If an acquirer, service provider, or merchant sends an enhanced OCT to an issuer as a

0100 authorization request, V.I.P. will decline it with Response Code 12.
13 (Invalid Amount) For Funds Disbursement/non-Money Transfer OCTs, if the amount exceeds the
US$50,000.00 limit, V.I.P. will decline it with Response Code 13.
57 (Transaction not If the issuer PCR is not set up in VisaNet to support Field 104 in TLV format, V.I.P. will
permitted to decline the transaction with Response Code 57.
cardholder)
For Money Transfer OCTs destined to an issuer PCR that cannot accept Processing
Code 26, V.I.P. will decline the transaction with Response Code 57.
OCTs may be initiated at ATMs but a MCC of 6011 must not be used. If an MCC of
6011 is used on an OCT, Visa will decline with Response Code 57.
If an acquirer, service provider, or merchant sends a 0200 enhanced prepaid load

OCT with a BAI of TU to a non-prepaid Visa account, V.I.P. will decline the transaction
with Response Code 57.
If an acquirer, service provider, or merchant sends a 0200 enhanced credit card bill
pay OCT with a BAI of CP to a non-credit Visa account, V.I.P. will decline the
transaction with Response Code 57.
61 (Exceeds On enhanced OCTs, if transaction exceeds an issuer-defined 1-day, 7-day or 30-day

approved amount amount limit and the issuer option is to decline when a limit is exceeded, V.I.P. will
limit) decline the transaction with Response Code 61.
On enhanced OCTs, if transaction exceeds both an issuer-defined amount limit and

an issuer-defined count limit and the issuer option is to decline when a limit is
exceeded, V.I.P. will decline the transaction with Response Code 61.
62 (Restricted card – If an OCT is sent to an embargoed country (Cuba, Iran, Syria, or Sudan), V.I.P. will
card invalid in this decline the transaction with Response Code 62.
region or country)

Value OCT Edits
64 (Transaction does On enhanced Money Transfer OCTs, if either the Sender Reference Number (Tag 01)
not fulfill or the Sender Account Number (Tag 02) in Field 104, Usage 2, Dataset Value 5F is not
AML requirements) present, V.I.P. will decline the transaction with Response Code 64.
For all domestic U.S. and all cross-border enhanced Money Transfer OCTs, if Sender
Name (Tag 03), Sender Address 47(Tag 04), Sender City (Tag 05), Sender State (Tag
06) (if Field 43, pos. 39–40 is US or CA), and Sender Country (Tag 07) in Field 104,
Usage 2, Dataset Value 5F are not present, V.I.P. will decline the transaction with
Response Code 64.
On enhanced Money Transfer OCTs, if Source of Funds (Tag 08) in Field 104, Usage 2,
Dataset ID 5F is not present on transactions destined to the U.S, V.I.P. will decline the
V.I.P. Processing Rule for the Recipient/Name

On cross-border enhanced Money Transfer OCTs, if the Recipient Name (Tag 0A) in
Field 104, Usage 2, Dataset ID 5F is not present or contains all spaces or zeros, V.I.P.
will decline with Response Code 64.
V.I.P. Processing Rule for Sender Name (Tag 03), Sender City (Tag 05), and
Sender Country (Tag 07) in Field 104 Dataset ID 5F
For transactions originated in a country that does not have a national net settlement
service (NNSS), V.I.P. declines domestic OCTs with a BAI of AA or PP with Response
Code 64 if they do not include Sender Name (Tag 03), Sender City (Tag 05), and
Sender Country (Tag 07) in Field 104 Dataset ID 5F, Tags 03, 05, and 07.
V.I.P. Processing Rule for Sender Name (Tag 03) and Recipient Name (Tag 0A)
in Field 104 Dataset ID 5F
V.I.P. declines 0200 OCTs with a BAI of AA/PP with Response Code 64 if the Sender
Name (Tag 03) or Recipient Name (Tag 0A) in Field 104 Dataset ID 5F, Tag 03 or 0A,
contains:
 All numerics
65 (Exceeds On enhanced OCTs, if transaction exceeds an issuer-defined 1-day, 7-day or 30-day
approved count limit) count limit and the issuer option is to decline when a limit is exceeded, V.I.P. will
decline the transaction with Response Code 65.
47Sender’s address may not be required on domestic OCTs. If not required under local AML/ATF laws, tag may be populated
with “not applicable”

Value OCT Edits
91 (Issuer If the issuer is unavailable for an OCT, V.I.P. will decline the transaction with Response
unavailable) Code 91.
93 (Transaction If an acquirer, service provider, or merchant sends an OCT to a recipient issuer BIN
cannot be completed that is blocked from receiving it, V.I.P. will decline the transaction with Response
– violation of law) Code 93.
If an acquirer, service provider, or merchant sends a 0200 enhanced prepaid load

OCT with a BAI of TU on a cross-border transaction, V.I.P. will decline the transaction
with Response Code 93.
If an acquirer, service provider, or merchant sends a 0200 enhanced credit card bill
pay OCT with a BAI of CP on a cross-border transaction, V.I.P. will decline the
When a U.S. acquirer, service provider, or merchant send OCTs with an MCC value of
4829 or 6012, the OCT must contain a BAI of AA or PP. If not, V.I.P. will decline the
On U.S. and non-US domestic and all cross border enhanced Money Transfer OCTs, if
Field 104, Dataset ID 5F, Tag 07 (Sender Country) does not contain a 3-digit ISO
numeric country code, V.I.P. will decline the transaction with Response Code 93.
If a recipient issuer is blocked from receiving the OCT, VisaNet will decline the
transaction with Response Code 93 except for embargoed countries (Cuba, Iran,
Syria, and Sudan), where the Response Code is 62 (Restricted Card – card invalid in
this region or country.
On domestic enhanced Money Transfer OCTs, if the amount is greater than US

$2,500.00 or the specific country limit, V.I.P. will decline the transaction with
Response Code 93.
On cross-border enhanced Money Transfer OCTs, if the amount is greater than US
$2,500, V.I.P. will decline the transaction with Response Code 93.
V.I.P. Processing Rule for the Sender’s Country

On enhanced OCTs, if Sender Country (Tag 07) in Field 104, Usage 2, Dataset ID 5F is
for a country on the list of U.S. OFAC comprehensively sanctioned countries or
regions that currently consists of Iran, Sudan, Syria, Crimea, and North Korea V.I.P.
will decline the transaction with Response Code 93
Note: Visa currently blocks transactions when the acquirer, service provider, or merchant’s
and/or issuer's country is on the list of U.S. OFAC comprehensively sanctioned countries.
V.I.P. will decline online gambling 0200 OCTs with RC 93 (Transaction cannot be
completed – violation of law) when sent to an issuer in Singapore.
94 (Duplicate If a duplicate transaction is received, V.I.P. will decline it with Response Code 94.
transmission)

Value OCT Edits
96 (System On cross-border enhanced Money Transfer OCTs where the recipient issuer’s country
Malfunction) requires watch list scoring and WLM scoring could not be performed (e.g., there was
an error), V.I.P. will decline the transaction with Response Code 96.
0494 (Field or data V.I.P. Processing Rule

missing or invalid) V.I.P. rejects 0200 OCTs with reject code 0494 if they do not contain the Business
Application Identifier (BAI) in Field 104 Dataset ID 57.
V.I.P. Processing Rule

V.I.P. rejects domestic 0200 OCTs with a BAI of AA or PP with reject code 0494 (Field
or data missing) if they do not contain both Field 104 Dataset IDs 5F and 71.
V.I.P. rejects enhanced OCTs with the existing reject code 0494 (Field or data missing
or invalid) for which any of the following tags in Field 104 Dataset IDs 5F exceeds its
maximum length: Tags 01–07 and 0A.
This table outlines BASE II and Edit Package Reject Reason Codes related to OCTs.
Table A-5: Other BASE II Return Reason Codes and Edit Package Reject Reason Codes
Value Description
BASE II: Return Reason If an OCT originated as a BASE II message is sent to a U.S. issuer:
Code 1N BASE II will return it with Return Reason Code 1N.
Edit Package: Reject Edit Package will reject it with Reject Reason Code V1161.
Reason Code V1161
Acquirer, service provider, or merchant of enhanced OCTs must be SMS-

connected.
If an acquirer, service provider, or merchant sends an enhanced OCT as a BASE II
message:
BASE II will return it with the return reason code of 1N.
Edit Package will reject it with reject reason code V1161.
BASE II: Return Reason BASE II returns domestic TC06 OCTs with MCC 4829 or 6012 with reason code 02
Code 02 (The transaction type of the source BIN or center is invalid).
Edit Package: Reject Edit Package rejects domestic TC06 OCTs with MCC 4829 or 6012 with reject code
Reason Code V1120 V1120 (Money Transfer OCT transaction is not allowed).
BASE II Return Reason BASE II returns online gambling TC06 OCTs with reason code GQ (Transaction
Code GQ could not be completed – violation of law) when sent to an issuer in Singapore.
Edit Package: Reject Edit Package rejects online gambling TC06 OCTs with reject code V1131 (Account
Reason Code V1131 number is invalid for online gambling OCTs) when sent to an issuer in Singapore.

Value Description
BASE II Return Reason Base II returns OCT or OCT reversal transactions with existing return reason code
Code P6 P6 (Business application ID (BAI) is invalid) if BAI value is missing or invalid.
Edit Package Reject Edit Package rejects OCT transactions with existing reason code V0082 (Business
Reason Code V0082 application ID is invalid) if BAI value is missing or invalid.

Sample Reports
B Sample Reports
Like other VisaNet transactions, OCTs appear on existing VisaNet reports. This appendix provides samples of select VisaNet Settlement
Service (VSS) and SMS reports containing OCT transactions as well as an example of the Visa Direct Transaction Reconciliation Report (TRR).
Note: The fee descriptor for OCTs is ORIGINAL CREDIT.
B.1 VSS Sample Reports
This section contains acquirer and issuer sample VSS reports:

 VSS-110 Sample Report
 VSS-120 Sample Report (Acquirer)
 VSS-120 Sample Report (Issuer)
For each report, the section containing information on OCTs is highlighted.

Sample Reports
Figure B-1: VSS-110 Sample Report

Sample Reports
Figure B-2: VSS-120 Sample Report (Acquirer)

Sample Reports

Sample Reports

Sample Reports

Sample Reports
Figure B-6: VSS-120 Sample Report (Issuer)

Sample Reports

Sample Reports

Sample Reports

Sample Reports
B.2 SMS Sample Report
In the SMS reports, the Processing Code column (“PROCSS CODE”) identifies the transaction as an OCT (“260000”). This applies to all SMS
6XX reports.
Figure B-9: SMS 600C Report

Sample Reports

Sample Reports
B.3 Visa Direct Transaction Reconciliation Report (TRR) (U.S. Only)
The Visa Direct TRR provides a sub-set of information that is available in a full SMS raw data report. This report provides the key data
elements that may be needed to reconcile Visa Direct transactions. The TRR is delivered in a machine readable CSV format and includes the
following data elements:
 Processing Date
 Acquirer BIN
 Visa Transaction ID
 Transaction State
 Reason Code
 Card Acceptor ID
 Card Acceptor Name
 System Trace Audit number
 Account Number
 Transaction date, time, amount and currency
 Authorization Code
 Retrieval Reference Number (RRN)
 Fee Program Indicator (FPI) and description
 Settlement date and time

Sample Reports
Figure B-10: Transaction Reconciliation Report

API Formats
C API Formats
This section provides examples of the Visa Direct API formats found in Visa Developer Platform (VDP)
applicable for OCTs sent and received. API is an XML format. The example shows the common data
elements.
Table C-6 provides a brief description of the API tags and its corresponding ISO fields. Acquirers, service
providers, and merchants can use this table to interpret the API information in the Visa Developer
Platform (VDP).
Following is a sample payload for OCT Request:

<?xml version="1.0" encoding="UTF-8"?>
<oct:OctV2V2Request
xmlns:dd="http://www.visa.com/vpp/api/dd"
xmlns:oct="http://www.visa.com/vpp/api/oct">
<systemsTraceAuditNumber
xmlns="">451004
</systemsTraceAuditNumber>
<retrievalReferenceNumber
xmlns="">412770451004
</retrievalReferenceNumber>
<localTransactionDateTime
xmlns="">2019-02-21T23:43:30
</localTransactionDateTime>
<acquiringBin
xmlns="">400171
</acquiringBin>
<acquirerCountryCode
xmlns="">643
</acquirerCountryCode>
<senderReference
xmlns="">1234567890123456
</senderReference>
<senderAccountNumber
xmlns="">4957XXXXXXXX0488
</senderAccountNumber>
<senderCountryCode
xmlns="">124
</senderCountryCode>
<transactionCurrencyCode
xmlns="">USD

API Formats
</transactionCurrencyCode>
<senderName
xmlns="">Mohammed Qasim
</senderName>
<recipientName
xmlns="">Tom Smith
</recipientName>
<senderAddress
xmlns="">901 Metro Center Blvd
</senderAddress>
<senderCity
xmlns="">Foster City
</senderCity>
<senderStateCode
xmlns="">CA
</senderStateCode>
<recipientPrimaryAccountNumber
xmlns="">4957XXXXXXXX0496
</recipientPrimaryAccountNumber>
<amount
xmlns="">124.05
</amount>
<businessApplicationId
xmlns="">AA
</businessApplicationId>
<transactionIdentifier
xmlns="">381228649430015
</transactionIdentifier>
<sourceOfFundsCode
xmlns="">05
</sourceOfFundsCode>
<cardAcceptor
xmlns="">
<name>Acceptor 11</name>
<terminalId>TID-9999</terminalId>
<idCode>CA-IDCode-77765</idCode>
<address>
<county>San Mateo</county>
<country>United States</country>
<zipCode>94404</zipCode>
<state>CA</state>
</address>
</cardAcceptor>

API Formats
</oct:OctV2V2Request>
</Body>
Following is a sample payload for OCT Response:

<?xml version="1.0" encoding="UTF-8"?>
<ns3:OctV2V2Response xmlns:ns3="http://www.visa.com/vpp/api/oct"
xmlns:ns2="http://www.visa.com/vpp/api/dd">
<transactionIdentifier>252294725789275</transactionIdentifier>
<actionCode>65</actionCode>
<responseCode>5</responseCode>
<transmissionDateTime>2019-03-14T17:02:07.000Z</transmissionDateTime>
<retrievalReferenceNumber>412770451004</retrievalReferenceNumber>
</ns3:OctV2V2Response>
Table C-6: API tags – ISO Fields Mapping

API Maps to ISO Field
systemsTraceAuditNumber Field 11 - System Trace Audit Number

UMF tag 0111
retrievalReferenceNumber Field 37 - Retrieval Reference Number
localTransactionDateTime Field 12 - Time, Local Transaction
acquiringBin Field 32 - Acquiring Institution Identification Code
acquirerCountryCode Field 19 - Acquiring Institution Country Code
senderReference Field 104 - Sender Data
Dataset Value Hex 5F, Tag 01, UMF Tag 2883

TCR 3
Field 104, Usage 2—Transaction-Specific Data
senderAccountNumber Field 104 - Sender Data
Dataset Value Hex 5F, Tag 02, UMF Tag 2883

TCR 3
senderCountryCode Field 104 - Sender Data
Usage 2—Transaction-Specific Data

Dataset Value Hex 5F
transactionCurrencyCode Field 49 - Currency Code, Transaction

API Formats
senderName Field 104 - Sender Data
Usage 2—Transaction-Specific Data

recipientName Field 104 - Recipient Name, Usage 2, Dataset Value Hex

5F
Tag: 0A Length: 30 Format: AN
senderAddress Field 104 - Sender Data, Usage 2—Transaction-Specific

Data
senderCity Field 104 - Sender Data, Usage 2—Transaction-Specific

Data
senderStateCode Field 104 - Sender Data, Usage 2—Transaction-Specific

Data
recipientPrimaryAccountNumber Field 2 - Primary Account Number
amount Field 4 - Amount, Transaction, ISO Fields 49 and 63.13

positions 1-2; UMF tag 2664 for amountValue; UMF tag
2665 for amountCurrencyCode
businessApplicationId Field 104 - Business application type, Dataset 57, UMF

2050
transactionIdentifier Field 62.2 - Transaction Identifier (Bitmap Format)
sourceOfFundsCode Field 104 - Source of Funds, Dataset Value Hex 5F, Tag
08
UMF tag 3331
<cardAcceptor> name Field 43 - Card Acceptor Name/Location
<cardAcceptor> terminalId Field 41 - Card Acceptor Terminal Identification
<cardAcceptor> idCode Field 42 - Card Acceptor Identification Code
<cardAcceptor> <address> county Field 59 - National Point-of-Service Geographic Data
<cardAcceptor> <address> country Field 43 - Card Acceptor Name/Location

Positions: 39– 40
<cardAcceptor> <address> zipCode Field 59 - National Point-of-Service Geographic Data

API Formats
<cardAcceptor> <address> state Field 59 - National Point-of-Service Geographic Data
accountType Field 3 - Processing Code; Positions 3 and 4; UMF tag

2460
recipientCardExpiryDate Field 14 - Date, Expiration
merchantCategoryCode Field 18 - Merchant Type
<pointOfServiceData>motoECIIndicator Field 60.8 / 63.6 - Point-of-service indicator; Position 4;

UMF tag 0109
<pointOfServiceData>panEntryMode Field 22 - Point-of-Service Entry Mode; Positions 1 and

2; UMF tag 0095
<pointOfServiceData>posConditionCode Field 25 - Point-of-Service Condition Code; Length: 1

Format: 2 BCD; UMF tag 1093
Surcharge (U.S. only) Field 28 - Amount, Transaction Fee; VIP Field 28; 2003
ISO Field 54; UMF tag 0271 for amountValue; UMF tag
2665 for amountCurrencyCode
senderFirstName Field 48 MC - Sender’s 1st name
senderMiddleInitial Field 48 MC - Sender’s middle initial
senderLastName Field 48 MC - Sender’s last name
recipientState Field 48 MC - Recipient’s state
recipientCountryCode Field 48 MC - Recipient’s country code
recipientFirstName Field 48 MC - Recipient’s first name
recipientMiddleInitial Field 48 MC - Recipient’s middle initial
recipientLastName Field 48 MC - Recipient’s last name
senderDateOfBirth Field 48 - Sender’s DOB; Usage 37
<merchantVerificationValue> Field 62.20 - Merchant Verification Value
<merchantVerificationValue> mvvVisaAssigned Field 62.20 - Merchant Verification Value
<merchantVerificationValue> mvvAcquirerAssigned Field 62.20 - Merchant Verification Value
messageReasonCode VIP Field 63.3 - Use case identifier; UMF tag 2553
merchantPseudoAbaNumber Field 63.10 - Gateway Merchant Data

API Formats
sharingGroupCode Field 63.12 - Sharing Group Code
feeProgramIndicator Field 63.19 - Fee Program Indicator; Length: 3

Format: 1 ANS, EBCDIC
senderPostalCode Field 104 - Sender Postal Code; Usage 2; Dataset Value

Hex 5F
Tag: 10 Length: 5-10 Format: AN
nationalReimbursementFee Field 119 - Settlement Service Data; Usage 1:
senderIdentificationNumberBusiness Field 104 - Business Sender Tax ID; Usage 2; Dataset ID

63; Tag 05 Length: 20; Format: AN
senderIdentificationNumberIndividual Field 104 - Individual (Customer) Sender Tax ID; Usage

2; Dataset ID 63; Tag 06; Length: 13; Format: AN

Visa Direct Account Lookup File
D Visa Direct Account Lookup File

The Visa Direct Account Lookup File provides acquirers, service providers, and merchants with
information about Visa accounts including issuer country code and billing currency, account type, Fast
Funds participation status, and whether the issuer can receive OCTs. Acquirers, service providers, and
merchants can receive this file from the Visa File Exchange Service (VFES) or via APIs. This file is
available to all acquirers, service providers, and merchants48. Acquirers, service providers, and
merchants should contact their Visa representative to request receipt of the account lookup file and
discuss available delivery methods and frequency.
The following provides information about the Visa Direct Account Lookup File.
 File Name: Account Lookup
 File Type: Visa Direct
 File Format: Comma Separated Value (CSV)
 Delivery: The account lookup file can be delivered daily, weekly or monthly. Additional
information on delivery options can be found in Section 2.7.1, Report Delivery Mechanisms.
D.1 Visa Direct Account Lookup File Data Elements
The data elements in the Visa Direct Account Lookup File are provided in the following table:
Important:
Refer to Table D-8: Interpreting Visa Direct Account Lookup File Data for details on how to
interpret the data in this file.
Table D-7: Visa Direct Account Lookup File Data Elements
This table has been updated per changes to the Account Range Lookup File Technical Letter and
Implementation Guide, Version 1.0.
48 The same information provided in this file can be obtained by sending the Visa Direct Account Lookup API to Visa.

Flag # Data Element Description
1. Account Range Min The lower boundary of the account number range.
2. Account Range Max The upper boundary of the account number range.
Note: OCT and Fast Funds enablement may differ between account
ranges under a single BIN, therefore it is critical that acquirers,
service providers, or merchants (entity initiating OCTs) look at the
account range min and max to determine OCT and Fast Funds
eligibility and NOT just at the BIN level.
3. BIN The Bank Identification Number.
4. Card Product Type Code Specifies the type of the card:

C = Credit
D = Debit
P = Prepaid
N = Unknown
5. Country Code Numeric ISO country code of the recipient issuer’s country.
6. Country Name Name of the recipient issuer’s country.
7. Issuer Name Name of the recipient issuer.
8. Billing Currency
Recipient issuer’s billing currency code.
Note: If the billing currency is all zeros, it indicates that the account
range is not active; the information for this account can be ignored.
9. Blocked For All OCTs? Whether or not the account is blocked for all OCTs:
Y = Account is blocked for all OCTs
N = Account is not blocked for all OCTs
For U.S. issuers, when this flag is set to N, it means that the issuer
can receive enhanced Funds Disbursement/non-Money Transfer
OCTs.
Refer to Table D-8: Interpreting Visa Direct Account Lookup File
Data for details on how to interpret this flag.

Flag # Data Element Description
10. Blocked For Basic Money Whether or not the account is blocked for basic Money Transfer
Transfer OCTs? OCTs:
Y = Account is blocked for basic Money Transfer OCTs
N = Account is not blocked for basic Money Transfer OCTs
This flag is not applicable to U.S. issuers (basic Money Transfer OCTs
are not applicable to the U.S).
11. Available For Enhanced Whether or not the account is able to receive enhanced Money
Money Transfer OCTs? Transfer OCTs:
Y = Account is able to receive enhanced Money Transfer OCTs
N = Account is not able to receive enhanced Money Transfer OCTs
Even if this flag is set to N for non-U.S. issuers, it does not mean that
the acquirers, service providers, or merchants (entity initiating OCTs)
cannot send an enhanced Money Transfer OCT to the issuer. Non-
U.S. issuers must receive all types of OCTs unless they are blocked
from receiving them due to local laws or regulations. Refer to Table
D-8: Interpreting Visa Direct Account Lookup File Data for details
on how to interpret this flag.
12. Blocked For Online Whether or not the account is blocked for online gambling OCTs:
Gambling OCTs? Y = Account is blocked for online gambling OCTs
N = Account is not blocked for online gambling OCTs
13. Fast Funds Enabled? Whether or not the recipient issuer participates in Fast Funds:
B = Recipient issuer participates in Fast Funds for all transactions
C = Recipient issuer participates in Fast Funds for cross border
transactions only
D = Recipient issuer participates in Fast Funds for domestic
transactions only
N = Recipient issuer does not participate in Fast Funds

D.2 Table Creation SQL
Because accessing the data directly from a flat file results in poor performance, it is recommended that
the acquirer, service provider, or merchant transfer the data from the Visa Direct Account Lookup File
into a database. In order to transfer the data to a database, the data first needs to be loaded into a
table. The following provides an SQL query to create the table:
CREATE TABLE "AccountRangeLookup"
(
"AccountRangeMin" VARCHAR2(21 BYTE) NOT NULL ENABLE,
"AccountRangeMax" VARCHAR2(21 BYTE) NOT NULL ENABLE,
"Bin" CHAR(6 BYTE) NOT NULL ENABLE,
"CardProductTypeCode" CHAR(1 BYTE) NOT NULL ENABLE,
"CountryCode" NUMBER(3,0),
"CountryName" VARCHAR2(50 BYTE),
"IssuerName" VARCHAR2(240 BYTE),
"BillingCurrency" NUMBER(sd22,0),
"BlockedAllOcts" CHAR(1 BYTE),
"BlockedBasicOcts" CHAR(1 BYTE),
"EnhancedOcts" CHAR(1 BYTE),
"BlockedGamblingOcts" CHAR(1 BYTE),
"FastFundsEnabled" CHAR(1 BYTE)
);
D.3 Primary Account Number Retrieval SQL
Once the data has been loaded into the database, acquirers, service providers, and merchants can use
the following SQL query to retrieve information for a given Primary Account Number (PAN).
Note: If the PAN cannot be retrieved from the database, then it is not a valid PAN.
SELECT AccountRangeMin, AccountRangeMax, Bin, CardProductTypeCode,
CountryCode, CountryName, IssuerName, BillingCurrency, BlockedAllOcts,
BlockedBasicOcts, EnhancedOcts, BlockedGamblingOcts, FastFundsEnabled FROM
AccountRangeLookup WHERE AccountRangeMin<=PAN AND AccountRangeMax>=PAN;

D.4 Interpreting Visa Direct Account Lookup File Data
Acquirers, service providers, and merchants must use the following table to determine how to
interpret the information in the Visa Direct Account Lookup File. U.S. Acquirers, service providers, and
merchants should use the ‘U.S. Merchant’ column while non-U.S. Acquirers, service providers, and
merchants should use the ‘Non-U.S. Merchant’ column.
Note: The flags referenced in the below table are cross referenced from Table D-7: Visa Direct
Account Lookup File Data Elements.
Table D-8: Interpreting Visa Direct Account Lookup File Data
OCT Services U.S. Merchant Non-U.S. Merchant
Fast Funds— Acquirer, Step 1: Determine Country Code Same

service provider, or Determine the issuer’s country code
merchant wants to by checking “Country Code” (Flag 5).
determine if recipient issuer
participates in Fast Funds
Step 2a: If transaction is domestic: Same

Check “Fast Funds Enabled?” (Flag 13):
If it is set to B or D, then the issuer
supports Fast Funds (and therefore
enhanced Money Transfer OCTs).49
If it is set to N, then the issuer does
not support Fast Funds.
49 While a value of B or D allows the acquirers, service providers, or merchants (entity initiating OCTs) to assume both Fast
Funds and enhanced OCT support, non-U.S. acquirers, service providers, or merchants (entity initiating OCTs) should not use
a value of N to conclude that they should not send an enhanced OCT to a non-U.S. recipient issuer. They need to follow the
steps outlined in the Enhanced Money Transfer section of this table to determine whether to send the transaction to the
issuer.

Step 2b: If transaction is cross-border: Same

Check “Fast Funds Enabled?” (Flag 13):
If it is set to B, then the issuer
supports Fast Funds (and therefore
enhanced Money Transfer OCTs).50
If it is set to N, then the issuer does
not support Fast Funds.
Enhanced Money Transfer Step 1: Determine Country Code Same

OCT— Acquirer, service Determine the issuer’s country code
provider, or merchant by checking “Country Code” (Flag 5).
wants to send an enhanced
Money Transfer 0200 OCT
Step 2a: Country Code is 840 Step 2a: Country Code is 840
Check “Available For Enhanced Money NEW: All cross-border OCTs to U.S.
Transfer OCTs” (Flag 11): issuers are currently declined by
 If it is set to Y, send the VisaNet, unless the U.S. recipient
transaction. issuer has specifically requested that
VisaNet allow cross-border OCTs to
 If it is set to N, do not send the
said recipient issuer. If a U.S. recipient
transaction.
issuer would like to receive inbound
cross-border OCTs, they should
contact their regional Visa
representative.
Step 2b: Country Code is not 840 Same
Check “Blocked For All OCTs” (Flag 9)
and “Blocked For Basic Money Transfer
OCTs” (Flag 10):
If both are set to N, send the
transaction.
If these flags have any other
combination of values, do not send
the transaction.
50While a value of B allows the originator to assume both Fast Funds and enhanced OCT support, non-U.S. acquirers, service
providers, or merchants (entity initiating OCTs) should not use a value of N to conclude that they should not send an
enhanced OCT to a non-U.S. recipient issuer. They need to follow the steps outlined in the Enhanced Money Transfer section
of this table to determine whether to send the transaction to the issuer.

Enhanced Funds Check “Blocked For All OCTs” (Flag 9): Step 1: Determine Country Code
Disbursement/Non- If it is set to N, send the transaction. Determine the issuer’s country code
Money Transfer OCT— by checking “Country Code” (Flag 5).
If it is set to Y, do not send the
Acquirer, service provider,
transaction. Step 2a: Country Code is 840
or merchant wants to send
an enhanced Funds NEW: All cross-border OCTs to U.S.
Disbursement/non-Money issuers are currently declined by
Transfer 0200 OCT. VisaNet, unless the U.S. recipient
issuer has specifically requested that
VisaNet allow cross-border OCTs to
said recipient issuer. If a U.S. recipient
issuer would like to receive inbound
cross-border OCTs, they should
contact their regional Visa
representative.
Step 2b: Country Code is not 840

Check “Blocked For All OCTs” (Flag 9):
 If it is set to N, send the
transaction.
 If it is set to Y, do not send the
transaction.
Online Gambling OCT— N/A Step 1: Determine Country Code
Acquirer, service provider U.S. acquirers, service providers, or Determine the issuer’s country code
or merchant wants to send merchants (entity initiating OCTs) with by checking “Country Code” (Flag 5).
an online gambling (BAI = MCC 7995 are not allowed to send
OG/GP & MCC = 7995) online gambling OCTs. MCC 7995 will Step 2a: Country Code is 840
0200 OCT. be in effect October 18, 2019 for select Online Gambling OCTs to U.S. issuers
Note: For government U.S face to face gambling are not allowed. If sent, they will be
owned or licensed establishments. declined by VisaNet.
gambling payouts (MCCs
7800/7801/7802 (U.S. Step 2b: Country Code is not 840
only)), these rules do not Check “Blocked For All OCTs” (Flag 9)
apply. and “Blocked For Online Gambling
OCTs” (Flag 12):
 If both are set to N, send the
transaction.
If these flags have any other
combination of values, do not
send the transaction.


Transaction Flows
E Transaction Flows
This appendix provides OCT-related transaction flows as outlined in the following table. The actor in
the diagram labeled as Originator is the Originating Entity. The Originating Entity could be a
merchant, acquirer or service provider, for simplicity the table only states Merchant but is applicable to
all Originating Entity types.
Note: These flows are provided for informational purposes only; check the V.I.P. technical
specifications for the most recent requirements.
Table E-9: Transaction Flows
Originating Entity Recipient Issuer Transaction Scenario Flow
SMS Merchant SMS Recipient Issuer Approval E.1
SMS Merchant BASE I/BASE II Recipient Issuer Approval E.2
SMS Merchant SMS Recipient Issuer Decline E.3
SMS Merchant BASE I/BASE II Recipient Issuer Decline E.4
SMS Merchant SMS Recipient Issuer Merchant Unavailable E.5
SMS Merchant BASE I/BASE II Recipient Issuer Merchant Unavailable E.6
SMS Merchant SMS Recipient Issuer Recipient Issuer Unavailable E.7
SMS Merchant BASE I/BASE II Recipient Issuer Recipient Issuer Unavailable E.8
SMS Merchant SMS or BASE I/BASE II Recipient Velocity Limits Exceeded and E.9
Issuer Recipient Issuer Opts for VisaNet
to Decline OCT on their Behalf
SMS Merchant SMS Recipient Issuer Recipient Issuer Response Delay E.10
SMS Merchant BASE I/BASE II Recipient Issuer Recipient Issuer Response Delay E.11
Any Merchant Any Recipient Issuer Recipient Issuer Charges Back E.12
OCT
SMS Merchant BASE II (TC06 Only) Recipient Issuer Approval E.13
BASE II (TC06) Merchant SMS Recipient Issuer Approval E.14
BASE II (TC06) Merchant BASE I/BASE II Recipient Issuer Approval E.15
BASE II (TC06) Merchant BASE II (TC06 Only) Recipient Issuer Approval E.16

Transaction Flows
E.1 SMS Merchant to SMS Recipient Issuer—Approval
Figure E-11: SMS Merchant to SMS Recipient Issuer—Approval
1. Merchant sends 0200 message to VisaNet.

2. VisaNet forwards 0200 message to recipient issuer (assuming issuer can accept OCTs and there is
no other reason for VisaNet to decline).
3. Recipient issuer receives 0200 message, processes it, and approves it:
4. Fast Funds: If the recipient issuer participates in Fast Funds, the issuer makes funds available into
the recipient’s account within 30 minutes.
5. Conventional Funds: If the recipient issuer does not participate in Fast Funds, the issuer makes
funds available into the recipient’s account within 2 business days.51
6. Recipient issuer creates 0210 response and sends it to VisaNet.
7. VisaNet forwards 0210 response to merchant.
8. Merchant receives 0210 response and completes transaction with the sender.
51 In Europe region, for an Intraregional Transaction, the funds must be made available on the same business day.

Transaction Flows
E.2 SMS Merchant to BASE I/BASE II Recipient Issuer—Approval
Figure E-12: SMS Merchant to BASE I/BASE II Recipient Issuer

2. VisaNet receives 0200 message from merchant.
3. VisaNet converts 0200 message into a 0100 message and sends it to recipient issuer (assuming
issuer can accept OCTs and there is no other reason for VisaNet to decline).
 Fast Funds: If the issuer participates in Fast Funds, the issuer makes funds available into the
recipient’s account within 30 minutes.
Note: If a non-U.S. issuer does not participate in Fast Funds, VisaNet approves the 0100 on
the issuer’s behalf (assuming there is no reason to decline it) and sends the TC06 only
to the issuer.
5. Recipient issuer sends 0110 response to VisaNet.
6. VisaNet receives 0110 response, converts it to a 0210 response and forwards it to the merchant.
7. Merchant receives 0210 response and completes transaction with sender.
8. VisaNet creates a TC06 message and sends it to the recipient issuer.

Transaction Flows
9. The recipient issuer receives the TC06:

 Fast Funds: If the recipient issuer participates in Fast Funds, the issuer must not make funds
available using the TC06 into the recipient’s account because the funds were already made
available as part of the processing of the 0100 message. Refer to Step 4 for details.
 Conventional Funds: If the recipient issuer does not participate in Fast Funds, the issuer uses
the TC06 to make funds available into the recipient’s account within 2 business days or the
same business day in Europe region.
E.3 SMS Merchant to SMS Recipient Issuer – Decline
Figure E-13: SMS Merchant SMS Recipient Issuer—Decline

3. Recipient issuer receives 0200 message, processes it, and declines it.
4. Recipient issuer sends 0210 response to VisaNet
5. VisaNet forwards 0210 response to merchant.
6. Merchant receives 0210 response. The merchant notifies the sender that the transaction cannot
be successfully completed.

Transaction Flows
E.4 SMS Merchant to BASE I/BASE II Recipient Issuer – Decline
Figure E-14: SMS Merchant to BASE I/BASE II Recipient Issuer—Decline

3. If the recipient issuer participates in Fast Funds, VisaNet converts 0200 message into a 0100
message and sends it to issuer (assuming issuer can accept OCTs and there is no other reason for
VisaNet to decline).
Note: If a non-U.S. recipient issuer does not participate in Fast Funds, VisaNet approves the 0100
message on the issuer’s behalf (unless there is a reason to decline it such as card is on
exception file or issuer is blocked from receiving OCTs) and sends the TC06 only to the
issuer.
4. Recipient issuer receives 0100 message, processes it, and declines it.
6. VisaNet receives 0110 response, converts it to a 0210 response, and forwards it to the merchant.

Transaction Flows
E.5 SMS Merchant to SMS Recipient Issuer – Merchant Becomes

Unavailable
Figure E-15: SMS Merchant to SMS Recipient Issuer—Merchant Becomes Unavailable

 Fast Funds: If the recipient issuer participates in Fast Funds, the issuer makes funds available
into the recipient’s account within 30 minutes.
 Conventional Funds: If the recipient issuer does not participate in Fast Funds, the issuer makes
funds available into the recipient’s account within 2 business days (or same business day in
Europe for an Intraregional Transaction).
5. VisaNet receives 0210 response from the issuer.
6. VisaNet attempts to send 0210 response to merchant but merchant is not available.
7. VisaNet creates 0420 reversal and sends it to the recipient issuer.
8. Recipient issuer receives and processes 0420 reversal:
 Fast Funds: Upon receipt of the 0420 reversal, the recipient issuer needs to obtain the funds
from the recipient’s account.

Transaction Flows
E.6 SMS Merchant to BASE I/BASE II Recipient Issuer – Merchant

Unavailable
Figure E-16: SMS Merchant to BASE I/BASE II Recipient Issuer—Merchant Unavailable

3. VisaNet converts 0200 messages into a 0100 message and sends it to recipient issuer (assuming
 Fast Funds: Recipient issuers participating in Fast Funds makes funds available into the
Note: If a non-U.S. recipient issuer does not participate in Fast Funds, VisaNet approves the
0100 message on the issuer’s behalf (assuming there is no reason to decline it) and
sends the TC06 to the issuer.
6. VisaNet receives 0110 response, converts it to a 0210 response, and forwards it to the merchant.
7. Merchant is not available.
8. VisaNet creates 0420 reversal advice, converts it to 0400 reversal request, and sends it to the
issuer.
9. Recipient issuer receives and processes 0400 reversal:
 Fast Funds: Upon receipt of the 0400 reversal, the recipient issuer needs to obtain the funds
from the recipient’s account.

Transaction Flows
E.7 SMS Merchant to SMS Issuer—Recipient Issuer Unavailable
Figure E-17: SMS Merchant to SMS Recipient Issuer—Decline

2. VisaNet receives 0200 message from merchant. VisaNet converts 0200 message into a 0100
message and attempts to send it to the recipient issuer (assuming issuer can accept OCTs and
there is no other reason for VisaNet to decline) but the issuer is unavailable.
3. VisaNet creates 0210 response and sends it to the merchant with a response code value that
indicates that the issuer is unavailable (response code 91).
5. VisaNet sends the issuer and 0220 advice, indicating that it was declined because the recipient
issuer was unavailable.

Transaction Flows
E.8 SMS Merchant to BASE I/BASE II Recipient Issuer – Recipient

Issuer Unavailable
Figure E-18: SMS Merchant to BASE I/BASE II Recipient Issuer – Unavailable

3. VisaNet converts 0200 message into a 0100 message and attempts to send it to the recipient
issuer (assuming issuer can accept OCTs and there is no other reason for VisaNet to decline) but
the issuer is unavailable.
4. VisaNet creates 0210 response and sends it to the merchant with a response code value that
indicates that the issuer is unavailable (response code 91).
6. VisaNet sends the recipient issuer and 0120 advice, indicating that it was declined because the
issuer was unavailable.

Transaction Flows
E.9 SMS Merchant to SMS or BASE I/BASE II Recipient Issuer –

Velocity Limits Exceeded and Issuer Opts for VisaNet to Decline
OCT on their Behalf
Figure E-19: SMS Merchant to SMS or BASE I/BASE II Recipient Issuer—Velocity Limits Exceeded
and Recipient Issuer Opts for VisaNet to Decline OCT on their Behalf
1. Merchant sends 0200 message to VisaNet

3. VisaNet determines that recipient issuer is available. VisaNet checks amount against velocity
limits and determines that velocity limits are exceeded. Issuer’s velocity limit’s preferences
indicate that VisaNet should decline the OCT on the issuer’s behalf when a velocity limit is
exceeded.
4. If the recipient issuer opts to receive an advice, VisaNet creates a Stand-in Advice and sends it to
the issuer with Field 48, Usage 37, position 11 containing information about the exceeded
velocity limit. If not, no advice is created.
5. VisaNet responds to the acquirer with Response Code (RC) 61 or 65 indicating that velocity limits
were exceeded.
6. Merchant receives 0210 response with Response Code 61 or 65.
For additional information, refer to Section 3.12.3.1: Velocity Limits Exceeded - Processing Options.

Transaction Flows
E.10 SMS Merchant to SMS Recipient Issuer—Issuer Response Delay
Figure E-20: SMS Merchant to SMS Recipient Issuer—Recipient Issuer Response Delay

 Fast Funds: If the recipient issuer participates in Fast Funds, the issuer makes funds available
into the recipient’s account within 30 minutes.
 Conventional Funds: If the recipient issuer does not participate in Fast Funds, the issuer makes
funds available into the recipient’s account within 2 business days (or same business day in
Europe for an Intraregional Transaction).
5. VisaNet receives 0210 response from issuer but the response took too long. VisaNet sends the
issuer a timeout advice and may also send the issuer a reject if the issuer has opted to receive
rejects for this situation.
6. Recipient issuer receives advice (and reject if supported by issuer):
 Fast Funds: Issuers participating in Fast Funds need to retrieve the funds from the recipient’s
account.
 Conventional Funds: The issuer must not make funds available into the recipient’s account.
7. VisaNet sends a 0210 response to the merchant with a response code value that indicates that
the recipient issuer is unavailable (response code of 91).

Transaction Flows
E.11 SMS Merchant to BASE I/BASE II Recipient Issuer – Recipient

Issuer Response Delay
Figure E-21: SMS Merchant to BASE I/BASE II Recipient Issuer—Recipient Issuer Response Delay

3. VisaNet converts 0200 messages into a 0100 message and sends it to recipient issuer (assuming
 Fast Funds: Recipient issuers participating in Fast Funds makes funds available into the
Note: If a non-U.S. recipient issuer does not participate in Fast Funds, VisaNet approves the
0100 message on the issuer’s behalf (unless there is a reason to decline it) and sends
the TC06 to the issuer
6. VisaNet receives 0110 response from issuer but the response took too long.
7. VisaNet sends the recipient issuer a 0120 timeout advice indicating that the response was
received outside of the response window.
8. Recipient issuer receives the advice:
 Fast Funds: Issuers participating in Fast Funds need to retrieve the funds from the recipient’s
account.

Transaction Flows
9. VisaNet creates 0210 response, includes a response code that indicates that the recipient issuer is
unavailable (response code of 91), and forwards it to the merchant. Merchant receives 0210
response. The merchant notifies the sender that the transaction cannot be successfully
completed.
E.12 SMS/Dual Message Recipient Issuer Charges Back OCT
Figure E-22: SMS/Dual Message Issuers Charges Back OCT
1. Recipient issuer sends OCT dispute to VisaNet using dispute condition code 12 or 13. Disputes
can be originated from VROL or sent as a transaction. SMS transactions use a 0422 message; Dual
Message use a 0422 with TC16.
2. VisaNet forwards OCT dispute to the merchant.
3. Merchant processes dispute and returns the funds to the sender, or
4. If the merchant has representment rights, the merchant can represent the dispute.

Transaction Flows
E.13 SMS Merchant to BASE II (TC06 Only)
Figure E-23: SMS Merchant to BASE II (TC-06 Only)

2. VisaNet converts 0200 message into TC06 and forwards it to the recipient issuer (assuming issuer
can accept OCTs and there is no other reason for VisaNet to decline).
3. Recipient issuer receives TC06 message and makes funds available into recipient’s account within
2 business days (or same business day in Europe for an Intraregional Transaction).
Note: Fast Funds is not applicable to issuers that support the TC06 only. Issuers need to receive a
0100 or 0200 message in order to enable Fast Funds.
4. VisaNet creates 0210 response.
5. VisaNet provides 0210 response to the merchant.

Transaction Flows
E.14 BASE II (TC06 Only) Merchant to SMS Recipient Issuer –

Approval
Figure E-24: BASE II (TC06 Only) Merchant to SMS Recipient Issuer—Approval
Fast Funds functionality is not applicable to transactions originated as TC06s. Issuers need to receive a
0100 or 0200 in order to enable Fast Funds. In this scenario, the merchant only supports the sending
of a TC06 OCT (the merchant does not support SMS 0200 origination). Even though SMS issuers
normally receive a 0200, they will receive a 0220 in this scenario.
1. BASE II (TC06 only) merchant sends a TC06 to VisaNet.
2. VisaNet converts the TC06 into a 0220 and sends it to recipient issuer (assuming issuer can
accept OCTs and there is no other reason for VisaNet to decline).
3. VisaNet forwards the 0220 to the recipient issuer (this 0220 is referred to as a deferred clearing
advice). The recipient issuer should make funds available to the recipient’s account as soon as
possible but no later than 2 business days (or same business day in Europe for an Intraregional
Transaction).
Note: Fast Funds is not applicable to transactions originated as TC06s. Issuers need to receive a
0200 or a 0100 in order to enable Fast Funds.

Transaction Flows
E.15 BASE II (TC06 Only) Merchant to BASE I/BASE II Recipient Issuer

– Approval
Figure E-25: BASE II (TC06 Only) Merchant to BASE I/BASE II Recipient Issuer – Approval
This scenario applies to origination of enhanced TC06 OCTs.
In this scenario, the originating entity only supports the sending of a TC06 OCT. Even though BASE
I/BASE II issuers normally receive a 0100 message followed by a TC06, they will only receive a TC06 in
this scenario.
2. VisaNet forwards the TC06 (assuming issuer can accept OCTs).
3. VisaNet forwards the TC06 to the recipient issuer. The issuer must make funds available to the
recipient’s account within 2 business days (or same business day in Europe for an Intraregional
Transaction).
Note: Fast Funds is not applicable to transactions originated as TC06s. Issuers need to receive a 0100
or 0200 in order to enable Fast Funds.

Transaction Flows
E.16 BASE II (TC06 Only) Merchant to BASE II (TC06 Only) Recipient

Issuer
Figure E-26: BASE II (TC06 Only) Merchant to BASE II (TC06 Only) Recipient Issuer
This scenario applies to origination of enhanced TC06 OCTs.

2. VisaNet forwards the TC06 (assuming issuer can accept OCTs).
3. Recipient issuer receives TC06 message and makes funds available into recipient’s account as
soon as possible but no later than 2 business days (or same business day in Europe for an
Intraregional Transaction).
Note: Fast Funds is not applicable to issuers that support the TC06 only. Issuers need to receive a
0100 or a 0200 messages in order to enable Fast Funds.

Transaction Flows

Enhanced TC06 OCTs
F Enhanced TC06 OCTs

Important
All new OCT programs must be initiated as enhanced format 0200 messages.
This appendix outlines the processing rules and data requirements for the enhanced TC06 OCTs.
This appendix does not include all the data elements required in the enhanced TC06 OCT; it only
highlights those data elements that have unique requirements associated with the OCTs. For all other
data elements and for more detailed information on existing VisaNet data elements, refer to the
VisaNet manuals.
F.1 Processing Rules
F.1.1 Merchants
Merchants must initiate cross-border Funds Disbursement OCTs as one of the following:
 Enhanced 0200 full financial message in enhanced OCT format.
 Enhanced TC06 only in enhanced OCT format.
F.2 Data Elements
This section provides an overview of the enhanced TC06 OCT data element requirements. The BASE II
TCRs are referenced in this section.
Table F-10: Enhanced TC06 OCT Data Elements
Field Name Definition Notes/Edits
Transaction Code Value of 2 Refer to Section F.5: Edit Package and

Qualifier BASE II Edits for VisaNet edits.
All TCRs, pos. 3
Primary Account Recipient’s Visa account number.

Number
TCR 0, pos. 5–20

Enhanced TC06 OCTs
Transaction Amount Must be less than or equal to Transactions exceeding the

TCR 0, pos. 77–88 US$50,000.00. US$50,000.00 limit are returned with
(Source Amount) Response Code D3 (the US dollar value
of a transaction exceeds the maximum
amount allowable).
Merchant Category Any valid MCC OCTs may be initiated at ATMs but a
Code Merchant Category Code of 6011 must
TCR 0, pos. 133–136 not be used. If an MCC of 6011 is used
on an OCT, BASE II returns it with
reason code 3A.
Online Gambling OCTs: Important:

Value must be 7995. In addition to an MCC of 7995, online
gambling OCTs must contain an
Electronic Commerce Indicator of 5-8 in
TCR 1. Merchants must ensure that
online gambling merchants properly
identify online gambling OCTs.
Refer to Section F.8: Online Gambling
OCTs for additional rules related to
online gambling payout OCTs.
Refer to Section 2.3.4.1.4 Gambling and
Gaming Program Overview for
information on gambling and gaming
considerations.
Merchant Name Contains the name of the merchant or Merchants must populate the merchant
TCR 0, Pos. 92–116 government entity sending the Funds name using the Latin (i.e., English)
Disbursement. character set.
Merchant City Value = Visa Direct

TCR 0, Pos. 117–129
Merchant Country Code Contains the 2-character alpha country

TCR 0, Pos. 130–132 code that matches the 3-digit numeric
acquiring Institution Country Code in this
field.

Enhanced TC06 OCTs
Member Message Text Must be present.

TCR 1, Pos. 24–73 May contain a number used by the
merchant or merchant to track the Funds
Disbursement (i.e., invoice number or
other type of tracking number). Or, if not
applicable, it must contain a value of
123.
Merchants must provide the
merchant/government entity address.
The format of this field is:
 - Invoice number/tracking number or
‘123’
 Space (as a delimiter)
 Merchant/government entity’s
primary business address
Fee Program Indicator Support of FPIs is according to regional
TCR 1, Pos. 76–78 and domestic requirements. If clients do
not support the FPI field today, they are
not required to do so for Money
Transfer or other OCTs/BAIs. Refer to
the BASE II Clearing Data Codes manual
for details.
Mail/Phone/Electronic Must be present in electronic commerce

Commerce and Payment OCTs, including online gambling, with
Indicator value 5–8.
TCR 1
Reserved for Future Use Spaces

TCR 3 Pos. 4–15
Fast Funds Indicator Value must be a space If the merchant sends the Fast Funds
TCR 3, Pos. 16 Indicator with any value other than
space, BASE II will return the transaction
with the existing return reason code GF
(Invalid data flags).
If sent with a value other than space,
Edit Package will reject the transaction
with the existing code V1187.
Business Format Code Value = CR

TCR 3, Pos. 17–18

Enhanced TC06 OCTs
Business Application Must be present.

Identifier Value = FD, GD, MD, or OG
TCR 3, Pos. 19–20
FD = Funds Disbursement
GD = Government Disbursement
MD = Merchant settlement
OG = Online Gambling Payout
Source of Funds Space While there is a V.I.P. Source of Funds

TCR 3, Pos. 21 field in Field 104 Dataset ID 5F Tag 08,
the Source of Funds in TCR 3 does not
map to this field. The Source of Funds in
TCR 3 is not related to OCTs.
Payment Reversal Space This field is not related to OCTs.

Reason Code
TCR 3, Pos. 22–23
Sender Reference Must be present.

Number May contain a number used by the
TCR 3, Pos. 24–39 merchant or merchant to track the Funds
Disbursement (i.e., invoice number or
other type of tracking number). Or, if not
applicable, it must contain a value of
123.
Sender Account Number Optional.

TCR 3, Pos. 40–73
Sender Name Must contain merchant/ Merchants must populate the sender
TCR 3, Pos. 74–103 government entity’s name. name using the Latin (i.e., English)
character set.
Sender Address Must contain sender or

TCR 3, Pos. 104–138 merchant/government entity’s city.
Sender City Must contain sender or

TCR 3, Pos. 139–163 merchant/government entity’s city.
Sender State For U.S. or Canada: Must contain

TCR 3, Pos. 164–165 merchant/government entity’s
state/province when Sender Country in
TCR 3 contains the value of 840 (U.S.) or
124 (Canada).

Enhanced TC06 OCTs
Sender Country Must contain merchant/government

TCR 3, Pos. 166–168 entity’s country.
Transaction ID This field is used for transaction lifecycle

TCR 5, Pos. 5–19 management.
Can also be used to associate an AFT
with an OCT in a P2P combination,
resulting in a Transaction Set.
Visa populates the field.
F.3 Reversals
Merchant-initiated reversals are allowed for enhanced TC06 OCTs as long as they are submitted for
the following processing errors only:
 Wrong account number
 Wrong amount
 Duplicate processing
 Wrong transaction code
These reversals must be submitted within one business day of the original transaction. After the one-
day period, OCT reversals are not permitted.
Issuers can challenge reversals submitted after the one-day period; however, issuers may choose to
allow such a reversal as a result of good faith negotiations with the merchant.
F.4 Disputes
The same dispute reason codes that apply to SMS 0200 OCTs apply to TC06 OCTs. Refer to Chapter 5:
Exception Processing for details. For the dispute reason codes that apply to enhanced OCTs, refer to
Section 5.3: Issuer -Disputes for details.
F.5 Edit Package and BASE II Edits
All data elements in supporting enhanced TC06 OCTs must match the original OCT or the Edit
Package rejects the file and BASE II rejects the batch.

Enhanced TC06 OCTs
OCTs must contain a Transaction Code Qualifier of 2 and the transaction must be a TC06, TC16, TC26,
or TC36. If the Transaction Code Qualifier is not 2:
 Edit Package rejects the transaction and sends a Reject Code V1080.
 BASE II returns the transaction with Return Reason Code B2.
If all the TCRs within a transaction do not contain the same Transaction Code Qualifier:
 BASE II rejects the batch that contains the invalid transaction and sends a Batch Reject Reason
Code 61.
 BASE II returns domestic TC06 OCTs with MCC 4829 or 6012 with Reason Code 02 (The transaction
type of the source BIN or center is invalid).
 Edit Package rejects domestic TC06 OCTs with MCC 4829 or 6012 with Reject Code V1120 (Money
Transfer OCT transaction is not allowed).
For Custom Payment Service (CPS) members, OCTs must contain a Transaction Code Qualifier of 2 and
the Authorization Characteristic Indicator (ACI) in TCR 0 must contain a value of N. (There are no edits
on the ACI field for transactions originated from non-CPS members.)
F.6 Blocking
OCTs may be blocked at the BIN level. Issuers have the option to block all OCTs, block online
gambling OCTs52, or block Money Transfer OCTs. Refer to Chapter 4: Bank Identification Number (BIN)
Blocking for details.
If a merchant sends an OCT to an issuer BIN that is blocked from receiving them, BASE II will return
the transaction with a Return Reason Code of M6 (Invalid Destination BIN).
F.7 Funds Availability
Issuers must make funds available within 2 business days of receiving the enhanced TC06 OCT.53
52 U.S. issuers are automatically blocked from receiving online gambling OCTs.
53 In Europe region, for an Intraregional Transaction, the funds must be made available on the same business day.

Enhanced TC06 OCTs
F.8 Online Gambling OCTs
In Europe, an enhanced TC06 OCT may be used for online gambling payouts to a cardholder provided
that both:
 The OCT is processed to the same Visa account number used in the initial purchase transaction to
place the bet with the merchant.
 The transaction representing the winning bet was lawfully made and properly identified and
processed in accordance with the Visa Core Rules and Visa Product and Service Rules.
F.9 Adjustments
Adjustments may be used to correct OCT errors. These adjustments must contain a Message Reason
Code (Field 63.3) value of 215054.
F.10 Edit Package and BASE II Edits
All data elements in supporting OCTs must match the original OCT or the Edit Package rejects the file
and BASE II rejects the batch.
OCTs must contain a Transaction Code Qualifier of 2 and the transaction must be a TC06, TC16, TC26,
or TC36. If the Transaction Code Qualifier is not 2:
 BASE II returns the transaction with Return Reason Code B2.
If all the TCRs within a transaction do not contain the same Transaction Code Qualifier:
 BASE II rejects the batch that contains the invalid transaction and sends a Batch Reject Reason
Code 61.
 BASE II returns domestic TC06 OCTs with MCC 4829 or 6012 with Reason Code 02 (The transaction
type of the source BIN or center is invalid).
 Edit Package rejects domestic TC06 OCTs with MCC 4829 or 6012 with Reject Code V1120 (Money
Transfer OCT transaction is not allowed).
54 The processing code needs to be the debit or credit adjustment processing code, not the OCT processing code.

Enhanced TC06 OCTs
For Custom Payment Service (CPS) members, OCTs must contain a Transaction Code Qualifier of 2 and
the Authorization Characteristic Indicator (ACI) in TCR 0 must contain a value of N. (There are no edits
on the ACI field for transactions originated from non-CPS members.)
F.11 Blocking
OCTs may be blocked at the BIN level. Issuers have the option to block all OCTs, block online
gambling OCTs55, or block Money Transfer OCTs. Refer to Chapter 4 Bank Identification Number (BIN)
Blocking for details.
If a merchant sends an OCT to a recipient issuer BIN that is blocked from receiving them, V.I.P. will
decline the transaction with the response code value of 93 (Transaction could not be completed—
Violation of law) and BASE II will return the transaction with a Return Reason Code of M6 (Invalid
Destination BIN).
F.12 Online Gambling OCTs
An OCT may be used for online gambling payouts to a cardholder provided that both:
 The OCT is processed to the same Visa account number used in the initial purchase transaction to
place the bet with the merchant.
 The transaction representing the winning bet was lawfully made and properly identified and
processed in accordance with the Visa Core Rules and Visa Product and Service Rules.
55 U.S. issuers are automatically blocked from receiving online gambling OCTs.

U.S. OCT Switch Service
G U.S. OCT Switch Service

The Visa Direct OCT Switch Service launched with the October 2015 Business Enhancement Release
(BER). Included in the OCT Switch Service is:
 Enabling the OCT message on Network 3. Issuers may enable OCT and Fast Funds posting
capabilities on Network 2 (Visa network), Network 3 (Interlink network), or Network 4 (PLUS
network) but MUST support incoming OCTs and Fast Funds posting capabilities on Network 2,
Network 3, or Network 4.
 Routing capabilities to direct an OCT to an issuer’s network of choice (Network 2, Network 3,
Network 4).
With these changes, Visa and its clients will:

 Meet consumer and commercial demands for faster payments
 Ensure a solution for commercial opportunities for Funds Disbursement
 Support new push payment use cases
 Provide flexible options for senders and receivers to connect to Visa for push payment services
 Build consumer confidence in push payments to Visa card accounts
 Offer a robust platform to replace cash and checks payments
Reference Materials
Available from Visa Online:

 Visa Direct - OCT Changes to Improve Effectiveness VBN (4-Jun-15)
 U.S. Original Credit Transaction Guidelines for Issuers VBN (16-Jul-15)
 U.S. Original Credit Transaction Requirements for Merchants VBN (16-Jul-15)
 October 2015 VisaNet Business Enhancements Global Technical Letter and Implementation Guide,
Version 3.0:
 Article 11.1.1—Mandatory Changes to Support Enhanced Original Credit Transactions
 Article 11.3.3—Changes to Support Enhanced Original Credit Transactions

U.S. OCT Switch Service

CEMEA-Specific Requirements for Money Transfer
H CEMEA-Specific Requirements for Money Transfer

This appendix provides CEMEA-specific requirements for Money Transfer transactions processed
within CEMEA countries.
This appendix does not apply to Money Transfer transactions initiated outside of CEMEA destined to
CEMEA countries. For these types of transactions, merchants and recipient issuers must follow the OCT
global requirements that are included in previous chapters and additional appendices of this
document.
Note: This appendix was previously included in the VPP Money Transfer Global Implementation Guide,
which is now retired.
H.1 License Requirements for Visa Direct in CEMEA
This section details the licensing requirements for the CEMEA Region.
Push (OCT) Transaction Licensing Requirements
The following licenses are eligible to originate OCTs:

 Principal (Issuing)
 Associate (Issuing)
 PLUS Principal/Associate
 ATM Acquiring Principal/Associate
Pull (AFT or Quasi Cash) Transaction Licensing Requirements
In order to originate pull transactions such as Account Funding Transactions (AFT) or Quasi Cash
transactions, a Principal or Associate client must hold a:
 Merchant Acquiring License (Associate or Principal-level) – if the transaction is initiated at a
physical Point-Of-Sale or ATM.
 e-Commerce Acquiring License (Associate or Principal-level) – if the transaction is initiated via the
Internet or Card Not Present environment.
H.2 CEMEA Merchant Requirements
This section provides information on merchant requirements.

H.2.1 Fast Funds
For information on Fast Funds, refer to Chapter 3, Section 3.10: Recipient Issuers - Funds Availability.
H.2.2 Payment Methods and Access Channels
The originating banks may choose which payment method and access channels to offer to customers.
Funding options include cash, bank account, and Visa card. Access channels include branch-based
POS terminals, Internet-banking, mobile-banking, ATMs (cash or card accepting), and kiosk terminals.
A merchant’s decision regarding which payment methods and access channels to use will be
determined by a number of factors, including:
 Whether a bank wishes to extend the service to only their own Visa cardholders or Visa
cardholders of other issuing banks.
 To what extent a bank wishes to offer Money Transfer OCTs using the existing infrastructure or
develop new channels.
 How a bank intends to comply with Know Your Customer (KYC) and anti-money laundering (AML)
regulations.
The following outlines specific requirements for each channel:

 In Branch POS: The merchant must use Visa Single Message System (SMS) only to submit OCT
transactions. AFTs could be submitted over either the Dual Message System (V.I.P./BASE I and
BASE II) or SMS.
 Internet-Banking, Mobile-Banking: The merchant must use SMS for OCTs and offer Visa Direct
Money Transfer OCTs through Internet banking or mobile banking only to their own customers.
 ATM/Kiosk Terminals: The merchant must use the SMS system to offer the Visa Direct Money
Transfer OCT service.
H.2.3 CEMEA Money Transfer OCT Service Options
The following four service options are available to Visa merchants in CEMEA wishing to implement the
Visa Direct Money Transfer OCT service:
Table H-11: CEMEA Money Transfer OCT Service Options
Service Option Originating Originating Service Type Recipient

Mechanism Channel Mechanism
Card-to-Card Visa Card ATM Domestic Visa Card

Cash In-branch POS International
Sender’s bank Internet banking
account Mobile banking

Service Option Originating Originating Service Type Recipient

Mechanism Channel Mechanism
Cash-to-Card Cash In-branch POS Domestic Visa Card

Sender’s bank International
account
Cash-to-Card at Cash ATM/Kiosk Domestic only Visa Card

ATM
AFT-based Card-to- Visa Card ATM Domestic only Visa Card issued
Card In-branch POS by the merchant
Internet banking
Mobile banking
H.3 CEMEA Implementation Requirements
This section provides merchants with implementation requirements.
H.3.1 CEMEA Money Transfer Implementation Requirements
Merchants implementing a Visa Direct Money Transfer OCT service must comply with the
requirements stated below.
H.3.2 Card-to-Card Money Transfer OCT Requirements (AFT and OCTs)
This service is based on both AFTs and OCTs.

Table H-12: CEMEA Card-to-Card Money Transfer OCT Requirements (AFT and OCT)
Money Transfer OCT Service Channel (Customer Interface) Visa System Transaction
Card-to-Card In-branch POS SMS AFT and OCT
Internet banking SMS AFT and OCT
Mobile banking SMS AFT and OCT
ATM SMS AFT and OCT
Domestically, this service is restricted to transfers in local currency, unless the use of foreign currency
is permitted by the local regulations and the program has been approved by Visa. This information
must be provided on the ATM screen or in branch at the point of transfer and included in the
merchant’s Terms and Conditions.

When international Money Transfers are offered at ATMs to Visa cardholders who are customers of
another bank, i.e. not on-us transfers, a customer registration process must be implemented to
identify and capture the sender’s name and address to be included into the OCT message. For the
bank’s own customers, sender data must be captured either through a registration process or track
data.
A standard Visa Account Funding Transaction (AFT) must be used as a funding transaction to collect
the transfer funds from the sender’s Visa card to be sent on to a receiving Visa card. An AFT must be
used to fund a Visa card when the AFT is reserved for use along with OCT for P2P type of services.
Processing requirements for this transaction are MCC 6012, TC05, TCQ1 or VisaNet Integrated
Payment System (V.I.P.) 0100/0200 request with a value of “10” in the processing code (Field 3).
For domestic OCTs, the Merchant Name field in the OCT message must contain the name of the
merchant and must not be filled with blanks. If blank, the OCT will be rejected. Merchants may choose
to include the sender name, Member’s (Client’s) name, name of the third-party agent (if involved), or a
generic identifier, such as “Money Transfer”.
The service fee must be clearly disclosed to the sender at the point of transfer (displayed on the
screen) and printed on the transaction receipt. The customer must be given an opportunity to cancel
the transaction without incurring additional charges. This information must be provided in the
customer’s Terms and Conditions and on the ATM screen.
Visa cards from which funds are sent must be subject to sending limits. The merchant must define and
implement sending limits and advise customers on this information.
H.3.3 Cash-to-Card Money Transfer OCT Requirements (OCT Only)
This service is based on OCTs only.

Table H-13: CEMEA Cash-to-Card Money Transfer OCT Requirements (OCT Only)
Money Transfer OCT Channel (Customer Visa System Transaction

Service Interface)
Cash-to-Card In-branch POS SMS OCT
Domestically, this service is restricted to transfers in local currency, unless it is permitted by the local
regulation and the program has been approved by Visa.
Over-the-counter transfers funded by cash or from a bank account can be provided at in-branch POS.
Merchants providing cash-funded or bank account-funded transfers at their branches using POS
terminals must comply with all the requirements listed above for the card-to-card Money Transfer
OCT service. Merchants must also comply with the OCT sender data requirements.

H.3.4 Cash-to-Card at ATM/Kiosk Money Transfer (OCT Only)
This service is based on the OCT only. Visa acquirers can offer cash-funded transfers at cash-accepting
ATM terminals.
Table H-14: CEMEA Cash-to-Card at ATM Money Transfer OCT Requirements (OCT Only)

Service Interface)
Cash-to-Card at ATM ATM/Kiosk SMS OCT
H.3.4.1 Transfer Process
The basic steps are as follows:

1. Sender selects ‘transfer to Visa’ service option and keys in the transfer amount and recipient Visa
card number.
2. The transfer details and service fee displayed on the ATM/kiosk screen for sender to confirm.
3. Sender deposits cash into the ATM/kiosk terminal.
4. The merchant builds an OCT 0200 message, including the sender’s reference number into the
‘sender data’ field, and submits it to VisaNet. The sender’s reference number is a randomly
generated number connected to the time of the transfer and terminal where the transfer has
occurred.
5. If the recipient issuer can accept the OCT 0100 authorization message, they respond with the
0110. If the recipient issuer cannot accept the OCT 0100 authorization message, then the VisaNet
Stand-in responds on the issuer’s behalf with a 0210, checking the recipient card against the list
of blocked BINs.
6. ATM/kiosk terminal displays and prints out the transfer receipt with the transfer details.
7. The OCT is cleared within normal SMS clearing cycle.
H.3.4.2 Sending Limits
The merchant must ensure that the transaction amount for the cash-to-card ATM/kiosk Money
Transfer does not exceed limits per local regulations. The merchant must define and implement
velocity limits (transaction limit, daily limit, weekly limit, monthly limit). The customer must be
informed about the sending limits at the point of transfer.

H.3.4.3 Service Requirements
The service must be restricted to domestic transfers and must be offered in local currency only, unless
permitted by local regulation, and the program has been approved by Visa. This information must be
provided on the ATM screen at the point of transfer; and
The service fee must be clearly displayed on the screen and printed on the transaction receipt. The
customer must be given an opportunity to cancel the transaction without incurring additional charges.
This information must be provided in the customer’s Terms and Conditions and on the ATM/kiosk
screen.
H.3.4.4 OCT Coding
In cases where the transfer funds are sent to a Visa card, which was used to identify the sender, the
OCT 0200 message must be coded as PIN-based as follows:
 Field 22 = 9010 or 0510 (90 = mag. stripe; 05 = chip), Field 25 = 02, Field 35 = track 2 data and
Fields 52/53 = PIN data.
H.3.5 Cash-to-Card at ATM Money Transfer OCT Requirements for Third Party
Merchants have an option to provide the cash-to-card Visa Direct Money Transfer OCT via an ATM’s
funds transfer service through a third party’s terminals. In addition to the above requirements,
merchants providing the ATM service through the third party must comply with the following:
 Only Visa acquirers can offer a cash-to-card Visa Direct Money Transfer OCT at third party ATM
terminals.
 Visa acquirers wishing to implement this service must register each of the third party’s programs
with Visa separately.
 The Visa acquirers must register each of the third parties with Visa.
 The Visa acquirers must ensure the third party is compliant with all service requirements and with
local regulations.
 Merchants and the third parties must comply with the Payment Card Industry Data Security
Standard. For more details, please refer to the Payment Card Industry Data Security Standard,
Payment Card Industry PIN Entry Device, and the Payment Card Industry PIN Security Standard.
 The Visa acquirer is responsible for the third party’s compliance with customer service
requirements. The Visa acquirers must demonstrate to Visa as a part of the registration process
that it has a well-established dispute resolution system, such as a call center that can handle
customer inquiries. The Visa acquirers must clearly communicate customer service contact details
to the sender.

H.3.6 AFT-Based Card-to-Card Money Transfer OCT Implementation

Requirements
This section provides information on AFT-based card-to-card implementation requirements for the
Visa Direct Money Transfer OCT.
Note: For more information, refer to the Visa Account Funding Transaction (AFT) Processing Guide.
H.3.6.1 AFT-Based Card-to-Card Money Transfer OCT Requirements
This service is based on AFTs only.
This service is for Visa card-funded transfers only and can be provided at bank branch-based POS
terminals, Internet or mobile banking, or at ATMs.
Table H-15: CEMEA Card-to-Card Money Transfer OCT Requirements

Service Interface)
Card-to-Card/Account In-branch POS V.I.P. BASE I / BASE II AFT
Internet banking V.I.P. BASE I / BASE II / SMS AFT
Mobile banking V.I.P. BASE I / BASE II / SMS AFT
ATM SMS AFT
Merchants implementing the service must comply with the following requirements:
 The service is restricted to domestic funding.
 The service is restricted to transfers to the recipient’s accounts within the merchant. This
information must be included in the merchant’s Terms and Conditions.
 The sender must be prompted to authorize a specific service fee prior to completing the
transaction. The service fee must be clearly disclosed to the sender (displayed on the screen) at the
point of transfer and printed on the transaction receipt. The customer must be given an
opportunity to cancel the transaction without incurring additional charges. This information must
be provided in the Terms and Conditions and on the ATM screen.
 Visa cards to which funds are credited must be subject to sending limits. The merchant must
advise the customer of this information.
 Processing requirements for the AFT transaction are as follows: TC05, MCC 6012, TCQ1, or VIP
0100/0200 request with a value of “10” in the Processing Code (Field 3).

H.3.7 Transaction Coding and Testing at SMS Host
The implementation model uses a 0200 AFT (PIN-based) to debit the sender's account and a 0200
OCT (key entered) to credit the recipient's account.
H.3.7.1 ECS VAP
VTS/3 in VisaNet loop-back functionality is not available for ECS VAP connections. In this case,
transaction testing must be done with a direct connection between the Visa client’s test host and a PC
loaded with VTS/3.
H.3.7.2 Priority Routing
OCTs submitted from SMS-connected BINs must include network 0002 or network 0000 in the original
request messages and their associated reversals. SMS-connected acquirers that currently use priority
routing and submit transactions with network 0000 (Priority Routing) in Field 63.1 - Network ID Codes,
can use this network ID when submitting original credit original request messages and their
associated reversals. V.I.P. will change the Network ID in these transaction types from 0000 to 0002.
H.3.7.3 Transaction Coding
The following transaction coding must be applied to the ATM acquirers connected to SMS:
Account Funding Transaction

 PIN-based 0200 full financial request. The sending cardholder will be at the terminal and will enter
a PIN for their card to be debited for the transfer amount. This transaction is technically
considered as PIN at POS.
 In case of an EMV ATM terminal, the authorization amount of funding transaction could be
different from the cryptogram amount. Please refer to the Visa Smart Debit/Credit System
Technical Manual.
Original Credit Transaction

 In most cases the OCT is coded as a key-entered transaction. The recipient card is not present in
the transaction, but the sending cardholder is. Since an OCT is a “push” (i.e. credit) message, the
recipient account must be included in Field 4.
 V.I.P. Field 3, positions 1–2 = 26; Field 18 = 6012; Field 22, positions 1–2 = 01;
Field 25 = 05 "cardholder present but card not present"; Field 60 = 32.
 Field 43. The sender’s name, in positions 1–25 of this field, must be present in international
transactions. The sender’s name is required for domestic and cross border transactions, Field 43
must be present and not filled with blanks.

 Field 104 in TLV format. Refer to Appendix A: Enhanced Original Credit Transaction (OCT) Data
Elements and Processing Rules for details.
BIN Blocking
When an SMS merchant sends an OCT, this is checked against the list of recipient BINs that are
blocked in VisaNet to receive OCTs. If they are blocked, a response of 93 is given. In this case, it is
important that the merchant reverse the AFT if the OCT has been rejected.
Transaction Coding at Internet and Mobile Banking
Where the Money Transfer OCT service is offered to consumers over the Internet banking channel, an
AFT must be coded as an electronic commerce transaction with following coding: Field 3 (processing
code) = 10, Field 18 = 6012, Field 22 = 0100, Field 25 = 59. The AFTs must be fully authenticated with
ECI Field 63.6, value 5. Any exception to the use of other ECI values must be approved prior to coding.
Please contact your regional Visa representative.
An exception allowing for the use of other ECI values was approved for the CIS SEE sub-region by the
CEMEA region. The ECI Field 63.6 will contain the ECI value that represents the result of the VBV
authentication.
 05 Fully authenticated e-commerce transaction
 06 Merchant attempted to authenticate the cardholder
 07 Non-authenticated e-commerce transaction
Where the Visa Direct Money Transfer OCT service is offered to consumer over the mobile banking
channel, a funding AFT transaction must be coded as card-not-present (CNP) transaction with
following coding: Field 3 (processing code) = 10, Field 18 = 6012, Field 22 = 0100, Field 25 = 5.
To enhance the Money Transfer OCT service security, the merchant must include CVV2 fields F126.10
into the authorization request and must expect to receive CVV2 results in Field 44.10 (as per standard
CVV2 processing).
H.3.8 Reporting and Reconciliation
Merchants must report Visa Direct Money Transfer OCT and AFT volumes in their CEMEA Quarterly
Operating Certificate.
H.3.9 Merchant
Merchants with licenses that include acquiring rights must report AFT as positive merchant volume
(MV) and OCT volumes as negative merchant volume (MV).
Merchants without a merchant acquiring license must report AFT and OCT volumes as POS volume.

H.3.9.1 Recipient Issuer
Recipient issuers must report OCT volumes as positive POS volume. Recipient issuers must not deduct
OCT volumes from POS volume as for refund.
H.3.9.2 Sending Issuer
Sending issuers must report AFT volumes as POS volume.
H.3.9.3 Reconciliation
The AFT and OCT messages are reported in standard SMS and VSS reports.
 SMS601R contains original financials for both the AFT and OCT 0200 messages reported there with
the appropriate fee descriptors.
 AFT and OCTs will also appear in VSS reports (VSS-120/VSS-130) and the appropriate counts and
amounts shown for these message types (including the fee descriptors in VSS-130). The fee
descriptors for AFTs are: "AFT NATL" and "AFT INT SETL". The fee descriptors for OCTs are:
“OCTRANFR NATL” and “OCTRANFR INT”. For the AFT, the merchant must request such a fee by
applying the relevant transaction edits in the clearing message: MCC 6012, TCQ1 or 0100/0200
V.I.P. authorizations with a value of “10” in the Processing Code (Field 3).
Table H-16: Other BASE II Return Reason Codes and Edit Package Reject Reason Codes
Value Description
BASE II: Return BASE I/BASE II endpoints cannot send OCTs to U.S. issuers. An enhanced OCT
Reason Code 02 destined to a U.S. issuer must originate as an SMS transaction.
Edit Package: Reject If an OCT originates as a BASE II message to a U.S. issuer:
Reason Code V1161 BASE II will return it with the return reason code of 02.
Merchants of enhanced OCTs must be SMS-connected.

If a merchant sends an enhanced OCT as a BASE II message:
BASE II will return it with the return reason code of 02.

Acronyms and Glossary
Visa Direct Original Credit Transaction (OCT) Global Implementation Guide: Visa Supplemental
Requirements
I Acronyms and Glossary

This appendix contains a list of OCT-related acronyms as well as a glossary of terms.
I.1 Acronyms
Table I-17: Acronyms
Acronyms Meaning
AA Account-to-Account (Money Transfer BAI)
AFT Account Funding Transaction
AML Anti-Money Laundering
API Application Programming Interface
ARDEF Account Range Definition
ATF Anti-Terrorist Financing
ATM Automated Teller Machine
BAI Business Application Identifier
BB Supplier Payments (Funds Disbursement/Non-Money Transfer BAI)
BI Bank Initiated P2P (Money Transfer BAI)
BIN Bank Identification Number
CIQ Client (Customer) Information Questionnaire
CP Credit Card Bill Payment
FD Funds Disbursement
FT (Target Funds Transfer (Stored Value Digital Wallet)

availability
October 2019)
GD Government Disbursement (Funds Disbursement/Non-Money Transfer BAI)
GP Gambling payout (non-online gambling) (Funds Disbursement/Non-Money

Transfer BAI)
LO Loyalty credits and rebates (Funds Disbursement/Non-Money Transfer BAI)

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants for use exclusively in managing their Visa programs.
It must not be duplicated, published, distributed or disclosed, in whole or in part, to merchants, cardholders or any other person without prior written
permission from Visa. © 2013–2017 Visa. All Rights Reserved.
Requirements
Acronyms Meaning
MCC Merchant Category Code
MD Merchant Settlement (Funds Disbursement/Non-Money Transfer BAI)
MVV Merchant Verification Value
OCT Original Credit Transaction
OFAC Office of Foreign Assets Control
OG Online Gambling Payout (Funds Disbursement/Non-Money Transfer BAI)
PAN Primary Account Number
PD Payroll and pension disbursement (Funds Disbursement/Non-Money Transfer

BAI)
PIF Program Information Form
POS Point of Sale
PP Person-to-Person or Peer-to-Peer (Money Transfer BAI)
SMS Single Message System (part of VisaNet V.I.P.)
TCR Transaction Component Record
TU Top Up (Prepaid Load) (Funds Disbursement/Non-Money Transfer BAI)
V.I.P. System VisaNet Integrated Payment System
VMT Visa Money Transfer
VSS VisaNet Settlement Service
WLM Watch List Management
WT Wallet Transfer (Money Transfer BAI)

Requirements
I.2 Glossary
Access Channels
Access channels are the channels that the service provider (i.e., merchant, merchant/government
entity, or load partner) defines and sets up to offer their service to recipients. Examples include
Internet/online website, merchant location, and/or mobile device.
Account Funding Transaction (AFT)

A type of VisaNet purchase transaction that can be used to pull funds from Visa card accounts for
the purpose of funding other non-merchant accounts; the receiving account, for example,
 Loading or topping up prepaid card accounts
 Moving funds into another financial account such as a CD or IRA
 Acting as a funding source for person-to-person (P2P) Money Transfers
 Adding value to a digital wallet
Account Lookup File

Contains information on issuer country code and billing currency, account type, Fast Funds
participation status, and whether the recipient issuer can receive OCTs. Refer to Visa Direct Account
Lookup File for details.
Acquirer
In relation to Visa Direct programs, an acquirer is a Visa financial institution that is approved by Visa
to originate Visa Direct transactions (AFTs and/or OCTs) or signs merchants or service providers to
originate Visa Direct transactions. Acquirers are liable for all Visa Direct programs that they operate
or sponsor.
Agent
An entity, not defined as a VisaNet Processor, that provides payment-related services, directly or
indirectly, to a Member (client) and/or stores, transmits, or processes cardholder data.
In the context of Visa Direct programs, an agent is any third-party merchant or service provider that
manages or facilitates Visa Direct programs (e.g., payment facilitators, load partners, etc.).
Anti-Money Laundering (AML)

A term used to describe those statutorily required controls that must be utilized by financial
institutions to prevent their product or services from being used for money laundering activities.
Anti-Terrorist Financing (ATF)

A term used to describe those statutorily required controls that must be utilized by financial
institutions to prevent their product or services from being used for terrorist financing activities.

Requirements
Application Programming Interfaces (API)

Web-services based messages that merchants can use to send value-add and financial messages to
Visa. Visa Direct APIs include financial APIs for OCTs and Account Funding Transactions (AFTs) and
non-financial APIs such as foreign exchange, account look-up, and account verification.
ARDEF Tables
Account Range Definition (ARDEF) Tables that can be used to determine the source of funds (i.e.,
Visa Credit, Visa Debit, or Visa Prepaid) when a Visa card is used to fund the OCT.
Business Application Identifier (BAI)

A data element provided in an OCT message that is used to identify the type of OCT (e.g., Money
Transfer, Funds Disbursement, prepaid load, or credit card bill payment).
Refer to Section 2.3.5: Business Application Identifier (BAI), Merchant Category Code (MCC), and Use
Cases for a full list of BAIs.
Card Verification Value 2 (CVV2)
CVV2 is a card verification tool. Issuers imprint a 3-digit security number (the CVV2) on the back of
Visa cards. Issuers can use the CVV2 number to validate that a genuine Visa card is present at the
cardholder location during a transaction. It provides a cryptographic check of the information
embossed on the card. CVV2 is applicable to AFTs but is not applicable to OCTs.
Conventional Funds
The OCT processing framework that makes funds available to the recipient’s account no later than
two business days after receiving the full financial or clearing message associated with the OCT.
In Europe, the requirement is to make funds available to recipient on the same business day as the
receipt of clearing and settlement message.
Credit Card Bill Payment

An OCT-based program that provides the ability for an individual to transfer funds to a Visa credit
card account to pay a credit card bill.
Enhanced 0200 OCT

An OCT initiated as a 0200 full financial transaction that contains the following data:
 Field 104, Usage 2, Dataset ID 57, Tag 01—Business Application Identifier
 Field 104, Usage 2, Dataset ID 5F—Sender Data
 Field 104, Usage 2, Dataset ID 71—Additional Sender Data

Requirements
Enhanced Money Transfer 0200 OCT

The Enhanced format OCT is characterized by the mandatory presence of a Business Application
Identifier (BAI) along with certain sender data fields (e.g., name, address, city, country) in the OCT
message.
Fast Funds
The capability whereby an issuer makes funds available to a Visa cardholder within 30 minutes of
approving an OCT.
The OCT processing framework that facilitates the transfer of funds to the recipient’s Visa account
within 30 minutes of approving the authorization or full financial OCT message. This is accomplished
through a combination of transaction specifications and operating rules for merchants and recipient
issuers. If a recipient issuer participates in Fast Funds, the issuer agrees to accept enhanced data or
full financial message, and make funds available in the recipient’s Visa account within 30 minutes of
approving the OCT authorization message.
Note: If a recipient issuer does not participate in Fast Funds, they must make funds available to
the recipient’s account within two business days. In Europe, the requirement is to make
funds available to recipient on the same business day as the receipt of clearing and
settlement message.
Note: In LAC, all enhanced OCT issuers must participate in Fast Funds.
Financial Institution
A financial institution can be broadly classified into:
 Bank: Entities licensed and regulated as banks.
 Non-Bank financial institutions: All other non-bank entities including Money Services
Businesses (MSB), eMoney companies, Payment Institutions, brokerage and investment
houses, etc.
Funds Availability
Making funds available to cardholders is defined as the posting and incrementing of the
cardholders’ open-to-buy or operating limit on their Visa card account. The funds are made
available to the cardholder. Simple memo posting where the cardholder cannot access the funds is
not considered compliant with funds availability requirements.
Funds Disbursement
An OCT-based program that provides the ability for a government entity or merchant (such as
corporations, insurance companies, and government agencies) to send funds directly to a recipient’s
Visa account.
Examples include:
 Insurance claims
 Corporate and manufacturing rebates

Requirements
 Affiliate and contractor payouts

 Expense reimbursements
 Government disbursements (such as value-added tax refunds)
 Online gambling and lottery payouts
Issuer (Recipient Issuer)

In the context of this guide, the Visa client financial institution that has issued the recipient’s Visa
card. The recipient issuer receives the OCT and credits the recipient’s Visa account with the funds.
Also referred to as recipient issuer.
Issuers also receive authorization requests for Account Funding Transactions (AFT) that may be used
in conjunction with some OCTs (e.g., P2P Money Transfers or prepaid card top ups).
Note: In this guide, issuer and recipient issuer are used interchangeably unless specified otherwise.
Load Partner
The entity (i.e., merchant or agent) that provides load services to consumers. In general, this entity is
assumed to be a Visa merchant as defined in the Visa Core Rules and Visa Product and Service
Rules. All Load Partners must be registered with Visa.
Merchant
In the context of Visa Direct, an entity requesting the initiation of OCTs only for themselves and their
customers. Merchants must be sponsored directly by an acquirer or on-boarded through an
acquirer-sponsored service provider.
Merchant Agreement
A contract between a merchant and a merchant/acquirer or between a sponsored merchant and a
merchant/payment facilitator, containing their respective rights, duties, and obligations for
participation in the Visa Direct program.
Money Transfer
A Visa Direct OCT-based program that provides the ability for an individual to send funds to his/her
own Visa account, to another individual’s Visa account, or movement of funds from a digital wallet
to a Visa card account.
While all OCTs represent the transfer of funds, in this guide and Visa Direct documentation, Money
Transfer refers to Person-to-Person (P2P) or (PP) Money Transfer services, Account to Account (AA)
Money Transfer, bank initiated P2P Money Transfer services and the transfer of funds from/to a
digital wallet (WT).
Office of Foreign Assets Controls (OFAC)

OFAC is an agency of the United States Department of the Treasury under the auspices of the Under
Secretary of the Treasury for Terrorism and Financial Intelligence. OFAC administers and enforces
economic and trade sanctions based on U.S. foreign policy and national security goals against
targeted foreign states, organizations, and individuals.

Requirements
Originator
This term is being phased out and is replaced by acquirer, service provider, and merchant – these
are the entities that initiate Visa Direct, OCT-based programs. For complete definitions of new
nomenclature and usage, see Visa Direct Role and Definition Changes.
Historical Use of Terms/Related Terms – No longer used
Originator: Formerly, the entity (e.g., Visa acquirer or third party agent/facilitator) that offered the
OCT-based services to its customers. The originator may or may not also be the Visa acquirer. If the
originator is not a Visa acquirer, the originator must be sponsored by a Visa acquirer.
Master Originators: (originator that offers Visa Direct services to other originators) are required to
submit a list of all sub-originators with the initial PIF and on a monthly basis.)
Sub-Originator: An Originator that was on boarded by a Master Originator and whereby the Master
Originator submitted OCTs on behalf of the Sub-Originator.
Original Credit Transaction (OCT)

The OCT is a type of VisaNet transaction that can be used to send funds to an eligible Visa account.
The merchant sends the OCT to the recipient issuer via VisaNet and the recipient issuer uses it to
credit the recipient’s eligible Visa account with the funds. Visa acquirers can use the OCT to enable
services such as Money Transfers, Funds Disbursements, prepaid loads, and credit card bill
payments.
Payment Facilitator
An acquirer-sponsored third party agent that enables OCT-based services on behalf of an acquirer
and/or offers OCT-based services to merchants. In this guide, more commonly referred to as Service
Provider.
Prepaid Load
A Visa Direct OCT-based program that provides the ability for an individual to add value to a Visa
reloadable prepaid account.
Prepaid Account (Eligible Prepaid Account)

An account established by an issuer, with previously deposited, authorized, or transferred funds,
which is decreased by purchase Transactions, Cash Disbursements, or account fees.
In the context of Visa Direct and what types of prepaid accounts are eligible to receive OCTs; unless
prohibited by local law, OCTs are mandated for all reloadable prepaid card accounts, but are not
permitted on
 Non-reloadable prepaid
 Prepaid card accounts where cardholder data is not on file
 Prepaid card accounts where the source of loads may be restricted (e.g., government, healthcare
and insurance programs).

Requirements
Program Information Form (PIF)

The method by which Visa Direct Programs are reviewed and approved by Visa. A PIF is required for
all new Programs and any changes to an existing Program; for example, change in acquirer, BIN,
Participants, or Program types.
Recipient
The recipient is the Visa cardholder that receives the OCT funds from the sender or merchant.
Sender
A customer of the merchant or service provider with a need to push payments. Sender may be
either a consumer or a business.
Sender’s Issuer
The sender’s issuer is the issuer of the Visa account associated with the sender. The sender’s issuer
may or may not be the same as the merchant.
Service Provider
An acquirer-sponsored third party agent that enables OCT-based services on behalf of an acquirer
and/or offers OCT-based services to Merchants. (Throughout guide, occasionally referred to as
Payment Facilitator.)
Sponsored Merchant
In the context of Visa Direct and this guide, an entity that accepts a Visa Card for the purposes of a
P2P Money Transfer or Funds Disbursement and submits the resulting Transaction to an acquirer for
Interchange, directly or via a Payment Facilitator.
Third-Party Agent
See Agent. Refer to Section 2.2.3 Third-Party Agent Registration in this guide for more information.
TPA program.
U.S. Routing Tables

U.S. Routing Tables are available to any Visa client (they are not limited to U.S. clients). They can be
used by merchants to determine if a recipient issuer participates in Fast Funds.
Velocity Limits
Limits to the number or total value of OCTs received to a particular Visa account.
Visa Direct
Visa Direct is a product platform that includes the OCT transaction and associated operating rules
and guidelines that allow clients to create push payment services (e.g., Money Transfers, Funds
Disbursements, etc.).

Requirements

The Visa Direct Account Lookup File provides merchants with information about Visa accounts
including issuer country code, billing currency, account type, Fast Funds participation status, and
whether the recipient issuer can receive OCTs. Merchants can receive this file via the Visa File
Exchange Service (VFES). (Formerly, the Visa Personal Payments (VPP) Account Lookup File.)
Visa Direct Application Programming Interfaces (APIs)

See Application Programming Interfaces (APIs).
VisaNet
The systems and services, including the V.I.P. System, and BASE II, through which Visa delivers online
financial processing, authorization, clearing, and settlement services to members (clients).
VisaNet Processor
A client (Member), or Visa-approved non-Member, that is directly connected to VisaNet and that
provides Authorization, Clearing, or Settlement services to Merchants and/or other Visa Members


Visa Direct Original Credit Transaction PDF

Uploaded by

Copyright:

Available Formats

Visa Direct Original Credit Transaction PDF

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

Visa Direct Original Credit Transaction PDF

Uploaded by

Copyright:

Available Formats

Visa Direct Original Credit Transaction

(OCT) – Global Implementation Guide

© 2013–2019 Visa. All Rights Reserved.

16 May 2019 Visa Confidential i

2.3.1 Transaction Processing and Message Format ............................................................................................ 40

ii Visa Confidential 16 May 2019

2.4.7 Recipient Registry and Recurring Transactions ......................................................................................... 64

16 May 2019 Visa Confidential iii

3.3.1 Special considerations for Credit Cards........................................................................................................ 81

iv Visa Confidential 16 May 2019

16 May 2019 Visa Confidential v

5.5.1 Process for Complaints Related to Non-Posting of Funds................................................................. 122

vi Visa Confidential 16 May 2019

16 May 2019 Visa Confidential vii

H.2.2 Payment Methods and Access Channels .................................................................................................. 235

viii Visa Confidential 16 May 2019

Table 1-1: Document Organization.................................................................................................................................... 14

16 May 2019 Visa Confidential ix

Table A-1: Enhanced OCT Data Elements ..................................................................................................................... 133

x Visa Confidential 16 May 2019

Figure 1-1: Visa Direct Process Flow ................................................................................................................................... 28

16 May 2019 Visa Confidential xi

xii Visa Confidential 16 May 2019

About This Guide

This section provides information on the scope of this document.

16 May 2019 Visa Confidential 13

Acquirers, Merchants, and Service Providers

This document contains the following chapters and appendices:

Chapter Description Audience

Chapter 1: Original Credit An overview of OCTs. Acquirers,

Chapter 2: Origination Provides acquirers, merchants, and service Acquirers,

Chapter 4: Bank Identification Provides information on BIN blocking. Acquirers,

14 Visa Confidential 16 May 2019

Chapter Description Audience

Chapter 5: Exception Processing Provides information on exceptions including Acquirers,

Appendix E: Transaction Flows Provides sample transaction flows. Acquirers,

16 May 2019 Visa Confidential 15

Chapter Description Audience

Appendix H: CEMEA-Specific Provides CEMEA-specific requirements for Money Acquirers, Merchants

Summary of Changes in this Version

16 Visa Confidential 16 May 2019

16 May 2019 Visa Confidential 17

Related Publications and URLs

Available Documents and URLs

18 Visa Confidential 16 May 2019

 Visa File Exchange Service (VFES) Implementation Guide

Global Technical Letters (Business Enhancement Release (BER))

 April 2019 Global Technical Letter and Implementation Guide

Visa Direct Regional Mailboxes

16 May 2019 Visa Confidential 19

20 Visa Confidential 16 May 2019

1 Original Credit Transactions (OCT) Overview

16 May 2019 Visa Confidential 21

1.1 What is an OCT?

22 Visa Confidential 16 May 2019

OCT to Visa Account Types Description Example

The credit balance owed on the

16 May 2019 Visa Confidential 23

Table 1-2: OCT Services