Account Funding Transaction AFT Processing Guide
Account Funding Transaction AFT Processing Guide
Transaction (AFT)
Processing Guide
Version 1.12
Notice: The Visa Confidential label signifies that the information in this document 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.
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 not part of the Visa 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 Rules, the Visa Rules shall govern and control.
Visa does not provide legal, regulatory, tax or financial advice. Each participant is fully responsible for ensuring that its
program operates in compliance with applicable legal and regulatory requirements and is responsible for conducting
independent legal and regulatory reviews through its legal counsel.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE
PERIODICALLY ADDED TO THE INFORMATION HEREIN: THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS
OF THE PUBLICATION. VISA MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE
PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.
If you have technical questions or questions regarding a Visa service or questions about this document, please
contact your Visa representative.
Contents
Chapter 1 • Account Funding Transaction (AFT) Overview
About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Cross-Border AFTs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
AFT Flow – SMS Originating Entity to Dual Message/BASE II Issuer (Approval/Decline). . . . 136
AFT Flow – Dual Message Originating Entity to SMS Issuer (Approval/Decline). . . . . . . . 138
AFT Flow – Dual Message Originating Entity to Dual Message/BASE II Issuer (Approval/
Decline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Credit Adjustment: SMS Originating Entity to Dual Message/BASE II Recipient Issuer. . . . . 141
Credit Adjustment: Dual Message Originating Entity to SMS Recipient Issuer. . . . . . . . .142
Credit Adjustment: Dual Message Originating Entity to Dual Message/BASE II Recipient Issuer 143
Issuer Response Delay – SMS Originating Entity to SMS Issuer (Results in Decline). . . . . . 144
Issuer Response Delay – SMS Originating Entity to Dual Message/BASE II Issuer (Results in
Decline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Issuer Response Delay – Dual Message Originating Entity to SMS Issuer (Results in Decline). . 147
Issuer Response Delay – Dual Message Originating Entity to Dual Message/BASE II Issuer
(Results in Decline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Glossary
The Account Funding Transaction (AFT) is a transaction in which funds are pulled from a Visa account
and are subsequently used to fund another Visa or non-Visa account.
When used independently to fund another Visa or non-Visa account, AFTs must only be used to fund
an account belonging to the same individual or entity holding the Visa account.
The AFT must be processed with the Account Funding Transaction indicator and the correct Business
Application Identifier (BAI) in the authorization and clearing record.
Important: An AFT is not intended for payment of goods and services, funding a merchant
account, or for debt repayment. An AFT can be used to fund the Original Credit Transaction
(OCT) in a Scan to Pay purchase.
In the case of a person-to-person or account-to-account Money Transfer, the AFT can be paired with
an OCT that pushes funds to an eligible Visa card account. For more information about the OCT, refer
to the Visa Direct Original Credit Transaction: Global Implementation Guide.
Appropriate processing of AFTs is critical to ensure that cardholders are able to perform the
transactions they expect with their Visa cards.
Chapter Description
2 – Requirements and Consider Requirements for Submitting a PIF
ations for AFT Origination
Updated this section to clarify when to submit a new PIF.
Chapter Description
2 Partial Authorization
Minor updates to the section.
3 – Issuer Requirements and l Added LAC to the list of countries mandated to support AFTs
Considerations
l Added a new section – Sanctions Screening Scoring Service
Chapter Description
Appendix A – AFT Key Data Table – AFT Key Data Elements
Elements
Updated the AFT Data Elements table with these changes relevant to AFTs.
Added:
l Field 34: New dataset and Tags C0, C1, C2, C3, C4, C5 and C6 to support
acquirer and merchant information
l Field 44.13: CAVV Results Code
l Field 59: New Dataset to support National Point-of-Service Geographical
Data
l Field 104: New Dataset to support Transaction Description and
Transaction-Specific Data
Updated:
Appendix B – Purpose of Payment Added a note to clarify not all codes may be applicable to an AFT.
- Standardized Codes List
Chapter Description
Appendix C – API Formats ISO Field - API Field Mapping
Added and updated these V.I.P. fields and their corresponding API field
name:
Acronyms
This table contains a list of AFT-related acronyms.
Table 2: Acronyms (1 of 3)
Acronyms Meaning
3DS 3-D Secure
Table 2: Acronyms (2 of 3)
Acronyms Meaning
DAF Digital Authentication Framework
MP Merchant Payment
PP Person-to-Person or Peer-to-Peer
P2P Same as PP
Table 2: Acronyms (3 of 3)
Acronyms Meaning
WT Wallet Transfer (Staged Digital Wallets only)
Related Publications
Below is a list of other relevant documents.
The current versions of these documents are available on Visa Online (www.visaonline.com) or
through your Visa representative:
l Visa Direct Original Credit Transaction: Global Implementation Guide
l Push Payment Gateway Client Implementation Guide
l Visa Core Rules and Visa Product and Service Rules
l V.I.P. System BASE I Technical Specifications, Volume 2
l Full Service POS Online Messages – Technical Specifications
l Fraud Reporting System (FRS) User's Guide
l Global Visa Acquirer Risk Quick Reference Guide
l Global Visa Acquirer Fraud Control Manual
l Visa Partial Authorization Service Description and Implementation Guide, Visa Supplemental
Requirements, Version 3.1
l April 2023 Global Technical Letter and Implementation Guide, Articles 3.1, 3.2, 3.19, 4.3
l October 2022 Global Technical Letter and Implementation Guide, Articles 3.1, 3.5, 3.14 and
3.18
l April 2022 Global Technical Letter and Implementation Guide, Articles 3.1 and 3.10
l April 2022 Global Technical Letter and Implementation Guide, Articles 3.9, 3.12
l April 2021 Global Technical Letter and Implementation Guide, Articles 3.2, 11.2.12
l April 2020 Global Technical Letter and Implementation Guide, Articles 2.3, 4.8, 8.1.2, 7.4.1,
10.1.1
l October2019 Global Technical Letter and Implementation Guide, Article 2.11
l April 2019 Global Technical Letter and Implementation Guide, Article 3.4
l October 2018 Global Technical Letter (Business Enhancement Release (BER)), Articles 3.4, 3.14
l October 2017 Global Technical Letter and Implementation Guide, Articles 2.12, 2.15, 11.2.1
Risk l Use existing authorization l Use existing author l Use existing authorization
Management tools; CVV2, AVS, Visa ization tools; CVV2, tools; CVV2, AVS, Visa
Secure, etc. AVS, Visa Secure, Secure, etc.
etc.
l Authorize and make l Authorize and make
approval decisions using l Authorize and make approval decisions using
standard decline reason approval decisions standard decline reason
codes using standard codes
decline reason
l Apply new or existing l Apply new or existing
codes
spending limits and purchase limits and
monitoring l Apply new or monitoring
existing purchase
l Include Velocity limits to
limits and
mitigate possible fraud
monitoring
and money laundering
risk if the subsequent OCT
is a money transfer
transaction
Pricing Existing AFT rates apply Existing purchase rates Existing purchase rates apply
apply
Data Processing 10 00 11
Elements: Code
Transaction 05 05 05
Code
Tran Code 1 0 0
Qualifier
1 If the funds will be used for a high-brand risk transaction, use the applicable high-brand risk MCC.
2 If the funds will be used for a high-brand risk transaction, use the applicable high-brand risk MCC.
3 Will be used by issuers on the cardholder’s statement.
The entity that offers a service using an AFT may be a Visa acquirer, merchant, or service provider,
sponsored by a Visa acquirer. This chapter includes the requirements and considerations that
acquirers, service providers, or merchants should take into account when planning an AFT program.
Acquiring Relationship
AFT origination programs require a relationship with a Visa acquirer. A Visa client with a Visa
acquiring license must act as the originating entity or must sponsor a third-party agent that acts as
the originating entity. The Visa acquirer must take all liability and responsibility for AFT origination
programs operated using their Visa acquiring identifier.
Transaction Usage
AFTs cannot be used for the purchase of goods, services, or with the intention of transferring funds
to a merchant account.
AFTs are the required transaction to load or top-up prepaid cards in all regions. An AFT is the
required pull transaction to be used for disbursing payroll funds, P2P or me-to-me transactions, and
pre-funding a consumer’s digital wallet in a card not present environment. When used independently
to fund another Visa or non-Visa account, AFTs must only be used to fund an account belonging to
the same individual or entity holding the Visa account.
Fraud Reporting
As with all purchase transactions, AFT fraud is required to be reported to the Visa Fraud Reporting
System (FRS), as specified in the Fraud Reporting System (FRS) User's Guide.
Disputes
AFTs have the same dispute rights as purchase transactions outlined in the Visa Core Rules and Visa
Product and Service Rules.
1A program is defined as a product or service offered by an acquirer, service provider, or merchant. Visa-
defined Program Types are listed in the table in the Business Application Identifier (BAI) section of this
chapter.
2A single PIF submission may only request BAIs within one BAI category (i.e., Money Transfer or Funds
Disbursement (non-Money Transfer). If a proposed program requires BAIs from both categories, then two
PIFs must be submitted.
Processing Changes
Issuers in the AP, CEMEA, LAC, and Europe Regions must be aware that Visa has implemented
changes to convert domestic AFTs with the processing code 10 (Account Funding) to a purchase
transaction with the processing code 00 (Goods/Service purchase–debit) before sending the
transaction to issuers that are not enabled to receive/have opted not to process the AFT processing
code. AFTs converted to purchase will include a Business Application Identifier in Field 104 based on
Core configuration. Refer to the appendix AFT Data Elements and Processing Rules, AFT Key Data
Elements for more information on the data elements for Field 104.
The issuer, acquirer, or merchant are in different countries Intra-EEA, including the U.K. and Gibraltar
within the EEA, U.K., or Gibraltar
Note: European Economic Area (EEA), which includes the member states of the European
Union, Iceland, Liechtenstein, and Norway. Member states include Austria, Belgium, Bulgaria,
Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany,
Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.
BAI AFT Category Merchant Category Code (MCC) BAI Usage Requirements
BI Financial Institution-offered 6012 Financial Institutions – P2P Money Transfer is initiated from
Bank-Initiated P2P Money Merchandise and Services an online banking system, making it
Transfer a bank-initiated transaction.
Important: BAI BI is used Note: BAI BI should only be used in
for very specific scenarios combination with MCC 6012.
and is enabled only in
Note: Domestic AFT from a bank/
limited markets. Contact
financial institution can use BAI=BI
your Visa Representative
for me-to-me, person-to-person
for information on the
transactions (e.g., AA, PP type of use
availability of BAI BI in your
cases).
market, and applicability of
BAI BI to your program.
PP Person-to-person (P2P) l 4829 Non-Financial Institution This is applicable for services that
Money Transfer Wire Transfer Money Orders support AFT and OCT. If only AFT is
(transferring funds to supported, BAI FT must be used.
l 6012 Financial Institutions –
another individual’s non-
Merchandise and Services
merchant account)
BAI AFT Category Merchant Category Code (MCC) BAI Usage Requirements
WT Staged Digital Wallet (SDW) l 6051 Non-Financial Institutions – Note: When a Visa card is used to
transfer (adding value to a Foreign Currency, Non-Fiat fund a Staged Digital Wallet before
digital wallet with a Currency (example, Crypto the cardholder makes a purchase, an
proprietary merchant currency), Money Orders (not AFT with a BAI of WT must be used.
acceptance network) Money Transfer), Account WT must be used only by registered
Funding (not Stored Value Load), Staged Digital Wallet Operators
Travelers Cheques, and Debt (SDWO).
Repayment For additional information on
l If the funds will be used for a Staged Digital Wallet transactions,
high-brand risk transaction, the visit the Staged Digital Wallet
applicable high-brand risk MCC Operators section at Visa Online
must be used. (VOL). Contact your Visa represen
tative for additional information and
l If the funds are used for a
requirements for digital wallets.
gambling transaction, the
applicable gambling MCC must Note: Effective October 2023: Field
be used. 104 – Sender Data and Recipient
Name will be required to support
l If the wallet is used to purchase
cross-border AFT.
non-fiat currency (for example:
cryptocurrency), the applicable V.I.P. will reject AFTs with the existing
special condition indicator must reject code 0494 (when Field or data
be used. is missing or invalid).
TU Prepaid card load or top-up l 6012 Financial Institutions – Note: Merchants that sell other
(adding value to an eligible Merchandise and Services goods and services in addition to
reloadable prepaid card or stored value cards and offer prepaid
l 6051 Non-Financial Institutions –
funding the cardholder’s card load capability can use the
Foreign Currency, Non-Fiat
own prepaid account) MCC associated with the merchant’s
Currency (example, Crypto
primary business in accordance with
currency), Money Orders (not
the Visa Merchant Data Standards
Money Transfer), Travelers
Manual.
Cheques, and Debt Repayment
l 6540 Non-Financial Institutions –
Stored Value Card Purchase/Load
FD Funds Disbursement Any MCC associated to the Insurance payouts where a third
merchant party uses an AFT to fund the
disbursement of OCT on behalf of
the insurance company.
Table 7: BAI and MCC usage for P2P and Digital Wallet Programs
Use Me-to-me funding/adding cash N/A AFT (AA) AFT (FT) AFT (WT)
Cases
Me-to-me withdrawal/Cash out N/A OCT (AA) OCT (FT) OCT (WT)
OCT not
Send funds to AFT (FT) AFT (FT) AFT (FT) AFT (WT)
enabled
someone else
OCT enabled AFT (PP or BI) AFT (PP or BI) AFT (PP or BI) AFT (PP or BI)
Receive funds
from someone OCT enabled OCT (PP or BI) OCT (PP or BI) OCT (PP or BI) OCT (PP or BI)
else
Note:
l AFTs with BAI = WT should only be used by registered Staged Digital Wallet
Operators (SDWO).
l To ensure the correct BAI is applied, the acquirer should confirm with the merchant if
OCT will be enabled through another means. This information should also be
included in the program description if submitting an AFT-only PIF.
Definition Stored Value Digital Wallets are offered A Staged Digital Wallet operates a proprietary
with P2P or merchant payment capability. network of merchants for their users to transact with.
The user can add and store funds in the SDW is a wallet that uses “stages” to complete the
digital account (wallet) that will be used to transaction and does not necessarily pass along card
send funds to others or cash out to an and/or merchant information to the card brand or
unaffiliated account. Stored Value Digital issuer:
Wallets must limit usage to the available
l Funding stage — the wallet is funded by the
balance in the wallet and must not
consumer or reimbursed after a purchase
facilitate Back-to-Back Funding.
l Payment stage — the wallet operator pays money
SVDW may have a general-purpose
to the merchant
payment network card/account at the
“front” of the wallet. It is not primarily used Payment may happen leveraging Back-to-Back
1
to pay a merchant. Funding to complete a transaction .
SDWs are permitted to facilitate Back-to-Back
Funding transactions but must not have a general-
purpose payment network card/account at the
"front" of the wallet.
Usage of funds l to send funds to other users l to send to other wallet users on the platform
in the wallet (P2P)
l to cash out to an unaffiliated account
l send payments at multiple merchants under the
l send payments at multiple merchants
operator's brand mark
under the operator's brand mark
l to cash out to an unaffiliated account
l send payments at multiple merchants
under the general-purpose payment l can support cryptocurrency
network's brand mark
l can support cryptocurrency
Stored funds to Stored funds may be used to pay Payments to merchants include:
pay merchants merchants.
l Face-to-face SDW brand acceptance mark at a
Payments to merchants include: physical POS
l Face-to-face SVDW-brand or general- l e-Commerce SDW brand acceptance mark
purpose payment network acceptance
l Merchant wallets where users instruct buyers to
mark at a physical POS
send money to a merchant’s digital wallet
l eCommerce SVDW-brand or general-
l Back-to-Back Funding purchase transaction
purpose payment network acceptance
mark
l Merchant wallets where users instruct
buyers to send money to a merchant's
digital wallet
Note: A wallet evolving to support a Back-
to-Back funding for real-time purchases
(i.e., where the funding transaction occurs
simultaneous with the purchase) will be
classified as a Staged Digital Wallet. The
wallet may no longer have a general-
purpose payment network card/account at
the "front" of the wallet.
Digital Wallet Stored Value Digital Wallet may be The Staged Digital Wallet may be structured as a
as a prepaid structured as a prepaid account or offer a prepaid account but must not offer or attach a
account general-purpose payment network prepaid general-purpose payment network card as a physical
card as a physical access tool to the funds access tool to the funds in the digital wallet. This
in the digital wallet. This scenario does not scenario does not alter the transaction or BAI
alter the transaction or BAI coding. coding.
Important: BAI BI is used for very specific scenarios and is enabled only in limited markets.
Contact your Visa Representative for information on:
l the availability of BAI BI in your market, and
l 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 before enabling
bank P2P services on behalf of the bank and its customers. The processes for ensuring participating
banks are compliant with the Fast Funds requirement, as well as the status of all participating banks
must be made available to Visa upon request.
Contact your account representative for more details on bank-initiated P2P programs.
Note: Not all MITs are relevant for AFTs (e.g., Installments, No Show).
Examples of MITs relevant to AFTs are:
l Recurring: Reload $50 every week into digital wallet or move $500 every month from bank
account #1 to bank account #2.
l Use Card-on-File: When digital wallet balance hits $10, automatically reload $50.
l Resubmission: In this case, the merchant, i.e., the digital wallet operator or the bank—
whoever is debiting the card is the entity conducting the load; but if the customer has an
automated top-up using the customer's Visa card "on file", then it's an MIT using a Stored
Credential.
MITs with an AFT must use these transaction coding:
Initial AFT (full 3D Secure):
l MCC 6012 (if bank led), if not bank led, MCC must represent the appropriate merchant for
the pull.
l Field 60.8 = 05 (ECI)
l Field 22 = 0100
l Field 25 = 59
l Field 126.9 = CAVV
l Field 126.13 = C or R
n C, if being captured for the first time. C is used for unscheduled payment using a Card-
on-File.
n R, if using in the first of a recurring payment and card is already on file.
Recurring AFT:
l MCC 6012
l Field 22 = 1000
l Field 25 = 59
l Field 60.8 = 07 (ECI)
l Field 126.13 = C or R
n R, if being captured for use in a recurring payment.
n C, is used for unscheduled use of a Card-on-File if the payment is not a recurring
transaction, but initiated by the merchant based on standing instructions.
l Field 62.2 or Field 125, DS 03, Tag 03 = original transaction ID
Cross-Border AFTs
AFTs are available for domestic and cross-border transactions in certain countries. AFTs must be
enabled for acquirers and issuers to participate.
Acquirers must have an approved PIF that specifically includes cross-border AFTs. As with all
domestic AFTs, for cross-border AFTs, Visa requires that acquirers and their agents must ensure that
all necessary licenses, registrations, notifications, authorizations, and approvals necessary to engage
in AFT programs are obtained from the appropriate authorities in the originating entity’s jurisdiction.
Cross-border AFTs must be processed using the unique AFT processing code 10.
Effective 23 April 2022, cross-border AFTs will be made available globally for merchants and
acquirers, except in the U.S. U.S. acquirers will not be allowed to originate cross-border AFTs. U.S.
issuers can continue to receive cross-border AFTs and must fulfill requirements for additional data
elements. Please contact your Visa representative for more information.
Exceptions that were available for select cross-border AFTs will continue to be supported. The
exceptions included:
l U.K., Gibraltar, and European Economic Area (EEA), which includes the member states of the
European Union, and Iceland, Liechtenstein, and Norway. Member states include Austria,
Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.
l All Regions – Wallet transfer (WT) can be cross-border in all regions.
Note: In the EU:
l Effective 23 April 2022: participating acquirers must support domestic and cross-
border AFTs
l Effective October 2022: issuers are required to support domestic and cross-border
AFTs
Note: Issuers and participating acquirers must be compliant with these mandates:
l Effective October 2022: AP will be required to support domestic and cross-border
AFTs.
l Effective April 2023: LAC, CEMEA, and Canada will be required to support domestic
and cross-border AFTs.
l Funds Transfer Attributes Inquiry: Allows the acquirers, service providers, and merchants to
determine whether the sender’s or recipient’s non-Visa account is eligible for domestic AFTs.
The Funds Transfer Attributes Inquiry (FTAI) API is often used with AFTs to determine key
characteristics of a recipient card before initiating the transfer like country, card-type, block
status, etc. Refer to the Visa Developer Center at https://developer.visa.com/products/paai for
additional information on this API.
Note:
n Effective 1 January 2020: Visa Direct clients are recommended to use the latest
ACNL file.
n Effective 15 January 2023: Originating entities in Canada and U.S. will be required
to use Version 5 of the FTAI API.
l Foreign Exchange Rate: Foreign exchange rate look-up and conversion
Note: Acquirers, service providers, and merchants must obtain a unique acquiring identifier
if using the Funds Transfer API. A unique acquiring identifier is not required for the Payment
Account Attributes Inquiry, Payment Account Validation, or Foreign Exchange Rate APIs.
Funds Transfer APIs
l Create Multi Push Funds Transaction POST
l Create Push Funds Transaction POST
l Read Multi Pull Funds Transaction GET
l Create Pull Funds Transaction POST
l Read Reverse Funds Transaction GET
l Read Multi Reverse Funds Transaction GET
l Create Reverse Funds Transaction POST
l Create Multi Reverse Funds Transaction POST
l Read Multi Push Funds Transaction GET
l Read Push Funds Transaction GET
l Read Pull Funds Transaction GET
l Create Multi Pull Funds Transaction POST
For more information on the Visa Direct APIs and their availability in your region, contact your Visa
representative. In addition, refer to the Visa Developer Center at https://developer.visa.com/
capabilities/visa_direct. Also refer to the Original Credit Transaction (OCT) – Global Implementation
Guide for OCT-related APIs.
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.
3 AVS is available in the U.S., Canada, UK, and Ireland. Check with your regional Visa representative for
availability of verification tools.
These documents are available on VOL. You may also contact your Fraud Manager for a copy of the
documents. For more information on PSD2 SCA applicability to Visa Direct, refer to Payment Services
Directive 2 (PSD2) on VOL.
For additional information about the Visa risk services available to AFT acquirers, service providers,
and merchants, contact your Visa representative.
Acquirers are currently able to test and activate ANI through either ISO or API.
Refer to this page on Visa Online for additional information on Account Name Inquiry, Account
Verification and Address Verification: https://secure.visaonline.com/SitePages/Content.aspx?
pageid=3.1.9.10.0.
The general guidance on the timeframe for when to use an AFT reversal or an AFT credit adjustment
should be based on whether the transaction was already cleared and settled in Visa’s end-of-day
settlement and reconciliation process.
To provide a better experience for cardholders and standardize timeframes for processing AFT credit
adjustment advice, issuers are required to process and post AFT credit adjustment advice within
these timeframes:
l In the AP, CEMEA, LAC, and North American (Canada, U.S.) regions: Within two business days
after receipt of the acquirer’s AFT credit adjustment advice.
l In the Europe region: The next business day after receipt of the acquirer’s AFT credit
adjustment advice.
For all credit adjustment advices, an acquirer must originate the credit adjustment containing the
original AFT transaction ID. It must also be originated in 30 calendar days or less of the original
transaction and cannot be originated if the original transaction is over 30 days old.
This table provides an overview of the reversal and credit adjustment advice and associated
processing considerations.
SMS processing clients l A full-financial AFT reversal (0420) l A credit adjustment transaction
must be used to refund within the (0220) with processing code 22
first 24 hours of the original (Adjustment-Credit) and reason
transaction time, but before the code 2140 (Account funding
settlement of the transaction. transaction: credit adjustment)
must be used to process refunds
to the sender's card.
l These refunds can be applied
before and after the settlement
cut-off window.
Note: Issuers may manage AFT credit
adjustments as a back-office process
instead of posting the transaction
directly into the cardholder's account.
Therefore, the timeframe for when
the cardholder should expect the
refund will vary by issuer.
Dual Message Processing clients l Originating clients using Dual An adjustment transaction (TC25 with
Message Processing can use an TCQ1) can also be used to process
authorization reversal (0400) as a refunds to the sender's card after the
way to refund. This can only be original AFT has been cleared.
used before the original AFT has
l These get processed as batch
been cleared and settled.
clearing transactions
Note:
l Transaction ID of the original AFT
– Visa rules presently require should be included to make it
clearing to be performed easier for issuers to reconcile the
within seven (7) days of the adjustment with the original
original authorization.
transaction.
However, as a best practice,
Visa recommends clearing the
original AFT within three (3)
days to ensure better
cardholder experience.
– Clients should not be
submitting a clearing once the
authorization reversal has been
processed. They should be
deleted from the batch.
l Clients also have the option of
processing a reversal transaction
in the clearing (as TC25, TCQ-1) if
the original transaction has been
cleared.
Important: If the service provider is attempting to process an AFT Refund request that is
missing the transaction ID of the original AFT, this may result in issuers being unable to
process the refund quickly. This can be an unpleasant experience for the cardholder as they
wait for the funds to be deposited to their card. It is a best practice to include the original
AFT transaction ID in the OCT transactions and also in the refund request to enable faster
reconciliation and return of funds when needed.
The flows presented here are used to give a more detailed understanding of how the AFT credit
adjustment advice and the AFT reversal work from the origination of the adjustment through to the
issuer processing of the adjustment, based on the originating entity and issuer connections to Visa.
1. Originating entity submits 0220 advice message to Visa to request refund of money to
sender's account.
2. Visa sends 0220 authorization message to issuer.
3. Issuer uses the 0220 message to restore balance to the Cardholder's account.
4. Issuer responds with 0230.
5. Visa receives 0230 message.
6. Visa sends 0230 confirmation back to originating entity to confirm success of submission.
Credit Adjustment Flow – SMS Originating Entity to Dual Message/BASE II Recipient Issuer
1. Originating entity submits a 0220 advice message to Visa to request refund of money to
sender's account.
2. Visa receives 0220 advice message to issuer.
3. Visa creates 0230 STIP advice and returns to originating entity to confirm.
4. Visa creates TC25 TCQ1 and sends to issuer for processing.
5. The issuer receives the TC25 and restores the balance to the Cardholder. The balance must be
restored within the rule timeline of one business day for Europe and two business days for all
other regions.
Credit Adjustment Flow – Dual Message Originating Entity to SMS Recipient Issuer
1. Originating entity raises TC25 to Visa to request refund of money to sender's account.
2. Visa receives TC25 in incoming files.
3. Visa creates 0220 advice and forwards to SMS recipient issuer.
4. SMS issuer receives 0220 and creates 0230 message.
5. SMS issuer creates 0230 response and sends to Visa.
6. Visa receives the 0230 response confirming receipt and processing of 0220 advice.
Credit Adjustment Flow – Dual Message Originating Entity to Dual Message/BASE II Recipient
Issuer
1. Originating entity submits a TC25 outgoing to Visa to request refund of money to sender's
account.
2. Visa receives TC25 and forwards to issuer for processing.
3. Issuer processes TC25 and restores balance to Cardholder’s account. This balance must be
restored within the rule timeline of one business day for Europe and two business days for all
other regions.
AFT Reversals
1. Originating entity submits 0420 advice message to Visa to initiate refund of money to
sender’s account.
2. Visa sends 0420 authorization message to issuer.
3. Issuer uses the 0420 advice message to restore balance to cardholder’s account.
4. Issuer responds with 0430 advice message, which must be an approval.
Note: If an issuer were to decline a 0420 message, V.I.P. will reject that decline response
from the issuer and respond in STIP with a 0430 approval to the originating entity).
AFT Reversal Flow – SMS Originating entity to Dual Messaging/BASE II Recipient Issuer
1. Originating entity submits 0420 advice message to Visa to request refund of money to
sender’s account.
2. Visa receives 0420 advice and converts it to a 0400 reversal request.
3. Visa sends 0400 reversal request to the recipient issuer. The issuer should use this 0400
reversal request to memo post the balance to the Cardholders’ account using the “Open to
Buy” parameters.
4. Issuer receives 0400 reversal request and responds with a 0410 reversal response to Visa.
5. Visa receives 0410 reversal response.
6. Visa forwards 0430 confirmation advice to the SMS Originating entity.
7. Visa creates a TC25 outgoing to the issuer.
8. The issuer receives the TC25 from Visa and uses this to complete processing of refund back
to Cardholders’ account.
AFT Reversal Flow – Dual Message Originating Entity to SMS Recipient Issuer
1. Originating entity raises TC25 to Visa to request refund of money to sender's account.
2. Visa receives TC25 in incoming files.
3. Visa creates 0220 advice and forwards to SMS recipient issuer.
4. SMS issuer receives 0220 and creates 0230 message.
5. SMS issuer creates 0230 response and sends to Visa.
6. Visa receives the 0230 response confirming receipt and processing of 0220 advice.
AFT Reversal Flow – Dual Message Originating entity to Dual Message/BASE II Recipient Issuer
1. Originating entity submits a TC25 outgoing to Visa to request refund of money to sender's
account.
2. Visa receives TC25 and forwards to issuer for processing.
3. Issuer processes TC25 and restores balance to Cardholder’s account. This balance must be
restored within the rule timeline of one business day for Europe and two business days for all
other regions.
For dispute information, see Issuers - Dispute Resolutions.
This section includes information for issuers to support the processing and authorization of AFTs for
their cardholders.
Issuers must comply with the Visa Core Rules and Visa Product and Service Rules, their applicable Visa
regional operating regulations, and local law.
Note: All AFT-enabled issuers must be able to receive and process AFTs. AFT support is
mandated for issuers in Canada, CEMEA, LAC and U.S. regions.
Effective 15 October 2022: AFT support will be required in the Europe Region.
AP, EU, and LAC must be aware that Visa has implemented changes to convert domestic AFTs
with the processing code 10 (Account Funding) to a purchase transaction with the processing
code 00 (Goods/Service purchase–debit) before sending the transaction to issuers that are
not enabled, or have not opted in, to receive the AFT processing code 10. AFTs converted to
a purchase transaction contain a BAI in Field 104 that issuers must be able to receive and
process.
Note: U.S. acquirers cannot originate cross-border AFTs. U.S. issuers can continue to receive
cross-border AFTs and must fulfill requirements for additional data elements.
Effective 22 April 2022: cross-border AFTs will be made available and the above velocity limits will
apply.
In the U.S., issuers, and issuer processors, are required to differentiate their daily spend limits by AFT
and purchase transactions. AFTs can be differentiated from a purchase transaction by a unique
Processing Code: AFT = 10, Purchase = 00 in ISO Field 3.1.
Note: Per Issuer Requirement to Evaluate Each Transaction (IREET) rule, issuers must not
systematically decline all transactions based solely on transaction amount and, instead, must
approve or decline transactions on multiple factors. Issuers can still choose to decline an AFT,
irrespective of the transaction amount, if it does not meet the issuer’s approval criteria.
In the U.S., if issuers apply internal limits, it is recommended that issuers and issuer processors set
AFT spend limits to a minimum of $5000 to drive adoption of new higher-ticket use cases, such as
brokerage and small-business payroll accounts. Visa also recommends issuers review AFT limits
proactively on a periodic basis based on cardholder and merchant risk profiles, cardholder tenure
(e.g., raise limit after 30 days, raise limit again after 60 days, etc.), and based on history of accounts
that have previously received a velocity limit decline.
10.4—Fraud Category This dispute may be used when the cardholder did not authorize or
participate in a transaction conducted in a Card Not Present
environment.
11.2—Declined Authorization This dispute may be used when an Authorization Request received a
Decline Response or a Pickup Response and the merchant completed
the transaction.
11.3—No Authorization The dispute may be used when Authorization was required but was
not obtained on the date. Refer to the Approval Response Validity
Timeframes section in the Visa Core Rules and Visa Product and
Service Rules
12.1—Late Presentment This dispute applies only if the transaction was not processed within
the required time limit. Refer to the Acquirer Processing Timeframes
section in the Visa Core Rules and Visa Product and Service Rules
12.4—Incorrect Account Number This dispute applies when the transaction was processed using an
incorrect payment credential and for which either an Imprint or an
Authorization was not obtained.
12.6—Duplicate Processing This dispute may be used when a duplicate AFT was submitted.
13.1—Merchandise/ Services Not Received This dispute may be used for either of these situations:
13.8—Original Credit Transaction Not This dispute may be used for either of these situations:
Accepted
l Legal restrictions prevent accepting the credit
l Recipient refuses the credit
This appendix provides the data elements and message requirements unique to AFTs.
Field 2 TCR 0, pos. 5-20 Sender's Visa payment credential. This field contains the sender's
primary account number (PAN).
Primary Account Account Number
Number Mandatory for Domestic and
Length: 16
Cross-border Money and Non-
Length: variable
Format: UN money Transfer AFTs.
Format: 1 byte
binary + up to
19 N, 4-bit BCD
(unsigned
packed);
maximum 11
bytes
Field 4 TCR 0, pos. 77-88 If acquirers, service providers, or The total amount of the AFT
merchants use Field 28 Transaction including all fees.
Amount, Source Amount
Fee Amount/AFT Service Fee or Field
Transaction Conceptual Example:
Length: 12 54 Additional Amount/AFT Foreign
Length: 6 Exchange Markup Fee, they must Transaction Amount: 50.00
Format: UN
Format: 12 BCD include those amounts in Field 4. AFT Service Fee: 2.00
AFT Foreign Exchange Markup
Fee: 2% of 50.00 = 1.00 (not
applicable to prepaid load)
Field 4 contains: 50.00 + 2.00 +
1.00 = 53.00
Field 28 contains: 2.00
Field 54 contains: 1.00
Note:
Field 18 TCR 0, pos. 133-136 Value depends on value of BAI (Field For AA, use 4829, 6012, or 6211
104) and the type of merchant
Merchant Type Merchant Category l 4829 – Non-Financial
performing the transaction:
(Row 1 of 2) Code Institution Wire Transfer Money
Merchant Category Code (MCC): Orders (WTMOs) (Not
Length: 2 Length: 4
For AA, use 4829, 6012, or 6211 (In applicable in the U.S. with BAI
Format: 4 BCD Format: UN AA)
the U.S, MCC 4829 is not applicable
with BAI AA) l 6012 – Financial Institution -
For BI, use 6012 Merchandise Services
For PP, use 4829 or 6012 For PD, use 8931 Accounting,
Auditing and Bookkeeping services
For TU, use 6012, 6051 or 6540 including Payroll
2
For WT, use 6051 For PP, use 4829 or 6012
3
For FT, use 4829, 6540 or 6012
l 4829 – Non-Financial
Institution Wire Transfer Money
Orders (WTMOs)
l 6012 – Financial Institutions -
Merchandise and Services
For BI, use 6012
l 4829 – Non-Financial
Institution Wire Transfer Money
Orders (WTMOs)
l 6540 – Non-Financial
Institutions –Stored Value Card
Purchase/Load
l 6012 – Financial Institutions –
Merchandise and Services
l If the stored value wallet is a
Cryptocurrency wallet the
MCC must be 6051 – Non-
Financial Foreign Currency,
Non-Fiat Currency (example,
Cryptocurrency), Money Orders
(not Money Transfer), Travelers
Cheques, and Debt Repayment
Mandatory for Domestic and
Cross-border (Money and Non-
money Transfer) AFTs.
Field 25 Not applicable Examples of valid values include: Contains the POS Condition Code
applicable to the access channel.
POS Condition 59 indicates an e-commerce
Code transaction Note: The value 05 should not be
used for online merchants,
Length: 2 01 indicates a cardholder not
including online gambling.
present transaction
Format: 2 BCD
Note: For CPS qualification, a value
05 indicates a cardholder present,
59 is required.
card not present transaction
For all valid values and complete
Note: Acquirers must select the
details on this field, refer to the
appropriate value for card present or
V.I.P. manuals.
card not present transactions. If the
transaction data is not accurate, Visa
will charge Data Integrity Fees on
the acquirer.
Field 28 TCR 4, pos. 51-58 Acquirers, service providers, or Values in this field must be in the
merchants supporting Field 28 and same currency and format as the
AFT Service Fee AFT Service Fee
charging senders a fee for the AFT currency code outlined in Field
Length: 9 Length: 8 may provide the fee in this field. 49/TCR 0.
Format: AN Format: UN When present, this field contains the
This field is not present in response
sender’s AFT Service Fee as assessed
messages.
by the originating entity.
Refer to Field 4 for an example.
For V.I.P:
Important: The Prefix value
Position 1: Prefix—Must be
(position 1) is for informational
populated with a value of D (Debit
purposes only. Clients should not
to cardholder).
use the prefix for settlement
Note: The 0220 Deferred Clearing purposes. Instead, they should
Advice will contain a value of C look at the message type and
(Credit to cardholder) even though Processing Code to determine if
this is actually a debit. the amount is a credit or a debit.
Positions 2-9: AFT Service Fee— Note: Field is not sent unless the
Contains the AFT service fee issuer opts in.
assessed by the originating entity (if
applicable). Must be right-justified
with leading zeros and include an
implied decimal relative to the
currency code specified in Field 49.
The amount in this subfield must be
in the same currency as Field 49.
Important: Originating entity must
include the amount in this field in
the total amount in Field 4.
Field 32 Not applicable A valid number provided by Visa. This code identifies the financial
institution acting as the acquirer of
Acquiring
the AFT.
Institution
Identification Field 32 reject codes are:
Code
0020 = Invalid length
Length: Variable
0021 = Invalid value
and up to 11
digits 0287 = Field missing
Field 34 Not Applicable Contains value of 01 (DAF indicator) This field is Tag-Length-Value
(TLV).
Dataset ID: 01
Testing and activation are required
Authentication
to implement this field for the first
Data
time.
Tag: C0
Acquirers and issuers in the AP
Authentication (except for Bangladesh, India,
Program Japan, and Nepal), Canada, CEMEA,
Length: 2 Europe, LAC, and U.S. regions that
support receiving Field 34 will
Format: AN receive the Authentication
Program tag in AFT request and
response messages to identify
transactions that are authenticated
as part of the Digital Authenti
cation Framework.
Field 42 Not applicable Must contain a unique identifier for The unique CAID from the original
the originating entity. transaction message is required in
Card Acceptor
any subsequent messages,
Identification
including reversals, disputes, and
Code
representments.
Length: 15
V.I.P. Edit:
Format: ANS,
This field must contain a non-zero
EBCDIC, 15
value.
bytes
Mandatory for Domestic and
Cross-border (Money and Non-
money Transfer) AFTs.
Field 43 TCR 0, pos. 92-132 Merchant Name position 1-25 Mandatory for Domestic and
Cross-border (Money and Non-
Card Acceptor Merchant Name, Merchant City Name position 26-38
money Transfer) AFTs.
Name/Location, Merchant City, and
Merchant Country Code position
pos. 1–40 Merchant Country Money Transfer Field Format
39-40 (two-character country code)
Code
Length: 40 The Card Acceptor Name field
Transaction Type: Money Transfer
Length: 40 must contain the "Doing Business
Format: 40 ANS , (BAI = AA, BI, FT, PP, WT)
As" name or abbreviation of the
EBCDIC Format: AN
This field must contain merchant or merchant (1-4 characters) and be
Row 1 of 2 service provider information (name, the name most recognizable to the
city, and country code). cardholder in addition to the
For an AFT that is used to fund a recipient's name.
Money Transfer transaction, this field The Merchant Name field must
may also contain the name of the contain the full Merchant Name or
4
recipient of the funds . conform to this format when
All regions: Must contain Money including a recipient name:
Transfer provider's name or Format Field Position Data
abbreviation. Inclusion of recipient
Pos. 1-4: Merchant Name
name is optional but recommended.
(abbreviated)
If recipient name is included, the
field will contain an asterisk (*) in Pos. 5: Asterisk (*)
position 5, followed by the
Pos. 6-25: Recipient Name
recipient's name.
(optional, but recommended)
Examples:
Example #1: AFT for a P2P
payment (BAI – PP)
MTMT*MarySmith
MTMT = generic example of a
Money Transfer Merchant
Transaction
Mary Smith = Recipient Name
Example #2: Bank-Initiated P2P
(BAI = BI)
FNBA*Mary Smith FNBA =
abbreviated name of bank
initiating the AFT
Mary Smith = Recipient Name
This information will appear on the
card statement to help the
cardholder identify the transaction.
Including the recipient's name can
prevent unnecessary calls from
cardholders to their issuers.
Field 48, Usage TC05, TCR 1 Positions Position 1, Field Identifier: This is a Data will be available in V22255
2, 24 – 73, Member 1-position code, *(asterisk). This (Financial Transaction Record/Fee
Message Text code indicates that this field Collections/Funds Disbursement
Unformatted
contains unformatted, user- Text Message Record) in the SMS
Text in Authori
determined text for the destination raw data report to include this data
zation/Reversal
acquirer or issuer.
Messages Visa Direct API Field name:
Positions 2-255, Text: In authori member Comments
Length: Variable
zation or reversal requests, the input
maximum 256
consists of acquirer comments for
bytes
the issuer. In authorization or
Format: ANS, reversal request responses, the input
EBCDIC consists of issuer comments for the
acquirer, such as a referral telephone
number.
Field 49 TCR 0 This field contains a 3-digit code If AFT Service Fee (Field 28/TCR 4)
that identifies the currency of and/or AFT Foreign Exchange
Currency Code, Source Currency Code
transaction amount. Markup Fee (Field 54/TCR4) is
Transaction
Length: 3 present in the message, the fees in
Length: 3 those fields must be in the same
Format: AN
Format: 4 BCD currency and format as the
currency listed in this field.
Note: Refer to the V.I.P. and BASE II
manuals for normal processing
instructions.
Field 54 TCR 4, pos. 112-119 Note: This field is applicable only if When present, this field contains
the AFT is a cross-border the sender’s AFT Foreign Exchange
AFT Foreign AFT Foreign Exchange
transaction. Markup Fee as assessed by the
Exchange Markup Fee
originating entity.
Markup Fee Acquirers, service providers, or
Length: 9
merchants that support Field 54 and Values in this field must be in the
Length: 20
Format: UN charge senders a Foreign Exchange same currency and format as the
Format: 1 byte Markup Fee on cross-border AFTs currency code outlined in Field
binary + 20 ANS may provide the foreign exchange 49/TCR 0.
fee in this field.
This field is not present in response
The V.I.P. format of this field follows: messages.
Positions 1-2: Account Type—Must Refer to Field 4 for an example.
contain a value of 00 (Not applicable
Note: Field is not sent unless the
or not specified).
issuer opts in.
Positions 3-4: Amount Type—Must
V.I.P. Edit:
contain a value of 95 (VMT).
If the Currency Code (positions
Positions 5-7: Currency Code—Must
5-7) is not the same currency code
contain the same currency code
as in Field 49, V.I.P. will decline the
value as in Field 49 Currency Code,
request message with the response
Transaction.
code value of 12 (Invalid
Position 8: Amount, Sign—Must transaction).
contain a value of D (Negative
Important: The Amount, Sign
balance).
(position 8) is for informational
Note: While C (Positive balance) is a purposes only. Clients should not
valid value in this field, it is not use the sign for settlement
applicable to this usage. purposes. Instead, they should
look at the message type and
Positions 9-20: Amount—Contains
Processing Code to determine if
the sender's AFT Foreign Exchange
the amount is a credit or a debit.
Markup Fee as assessed by the
acquirer, service provider, or Note: Refer to the V.I.P. manuals
merchant (if applicable). This for complete details on the length
subfield must be right-justified with and format of this field.
leading zeros, and include an
V.I.P. Edit:
implied decimal relative to the
currency code specified in Field 49. If the Amount (positions 9-20) is
The amount in this subfield must be not correctly formatted according
in the same currency as Field 49. to the currency code outlined in
Field 49, V.I.P. will decline the
Note: Acquirers, service providers,
request message with the response
or merchants must include the
code 12 (Invalid transaction).
amount in this field in the total
amount in Field 4.
Field: 56 Not applicable The valid values are: This field is Tag-Length-Value
(TLV).
Tag: 9F1F l 05 (Payer (sender))
Containing a code that denotes
Length: 2 l 06 (Payee (recipient))
whether the customer identifi
Customer cation data belongs to the sender
Reference or the recipient.
Number
Required: Customer ID of recipient
Format: N is required for transactions out of
and within Brazil.
Optional: for all other countries,
but strongly recommended.
Important: If this tag is present,
the following tags must also be
present:
l Tag 9F20
l Tag 9F22
Tag 9F21 is optional. Tag 9F24 is
conditional, depending on the
value populated in Tag 9F20.
Field: 56 Not applicable This tag will contain the type of This field is Tag-Length-Value
sender or recipient identification. (TLV).
Tag: 9F20
The valid values are: Containing the type of sender
Length: 4
identification.
Identification l BTHD (Date of birth)
Type Code l CUID (Customer identification
Format: A (unspecified))
l NTID (National identification)
l PASN (Passport number)
l DRLN (Driver license)
l TXIN (Tax identification)
l CPNY (Company registration
number)
l PRXY (Proxy identification)
l SSNB (Social security number)
l ARNB (Alien registration number)
l LAWE (Law enforcement identifi
cation)
l MILI (Military identification)
l TRVL (Travel identification (non-
passport))
l EMAL (Email)
l PHON (Phone number)
Field: 56 Not applicable The valid values are: This field is Tag-Length-Value
(TLV).
Tag: 9F21 l 0B (Business)
This tag denotes whether the tax
Length: 2 l 0I (Individual)
ID pertains to a business or
Identification individual, when Tag 9F20 contains
Subtype the value of TXIN (Tax identifi
Format: AN cation).
Field: 56 Not applicable When Tag 9F20 contains the value of This field is Tag-Length-Value
BTHD (Date of birth), this tag must (TLV).
Tag: 9F22
contain a date of birth in ccyymmdd
This tag will contain an acquirer-
Length: 35 format where:
populated value associated with
Identification l cc = century the Identification Type Code
Value provided in Tag 9F20.
l yy = year
Format: ANS
l mm = month
l dd = day
Field: 56 Not applicable This tag will contain the 3-digit ISO This field is Tag-Length-Value
country code of the issuing country (TLV).
Tag: 9F24
when Tag 9F20 contains an
Length: 3 applicable value.
Identification
Issuing Country
Format: N
Field: 56 Not applicable Required for cross-border and This field is Tag-Length-Value
domestic money transfer and non- (TLV).
Usage 2
money transfer out of and within
Required for transactions out of
Dataset ID 05 South Africa.
and within South Africa, optional
Account Owner In Canada, Cross-border transactions for all other countries.
Data into and out of Canada must include
The field is defined with the
Length: Various the address of the person or entity
following tags:
receiving the funds from the AFT.
Format: ANS l Tag 80: Account Reference
Number
l Tag 83: Account Owner Name,
Given
l Tag 84: Account Owner Name,
Middle
l Tag 85: Account Owner Name,
Last
Field 56 Not applicable Required for cross-border money This tag identifies to which account
and non-money transfer transactions or entity the name data belongs.
Account
out of South Africa.
Reference If this tag is present, it must
Number Sender Name and/or Recipient contain one of the these values:
Name is mandatory.
Tag: 80 l 05 (Sender Name)
Field 56 Not applicable Required for cross-border money This tag identifies the first name of
and non-money transfer transactions the account or entity.
Account Owner
out of South Africa.
Name, Given If this tag is present, it must only
Sender Name and/or Recipient contain alphanumeric characters A
Tag: 83
Name is mandatory. - Z and 0 - 9.
Length: 35
This field must not contain:
Format: AN
l All spaces
l All zeroes
l A question mark
l All numeric
Note: The tags are mandatory in
certain markets for them to follow
the instructions as defined in the
detail for each tag. In the markets
it is not listed as mandatory, it is
considered optional.
Field 56 Not applicable Required for cross-border money This tag identifies the middle name
and non -money transfer of the account or entity.
Account Owner
transactions out of South Africa.
Name, Middle If this tag is present, it must only
Sender Name and/or Recipient contain alphanumeric characters A
Tag: 84
Name is mandatory. - Z and 0 - 9.
Length: 35
This field must not contain:
Format: AN
l All spaces
l All zeroes
l A question mark
l All numeric
Note: The tags are mandatory in
certain markets for them to follow
the instructions as defined in the
detail for each tag. In the markets
it is not listed as mandatory, it is
considered optional.
Field 56 Not applicable Required for cross-border money This tag identifies the last name of
and non -money transfer the account or entity.
Account Owner
transactions out of South Africa.
Name, Last If this tag is present, it must only
Sender Name and/or Recipient contain alphanumeric characters A
Tag: 85
Name is mandatory. - Z and 0 - 9.
Length: 35
This field must not contain:
Format: AN
l All spaces
l All zeroes
l A question mark
l All numeric
Note: The tags are mandatory in
certain markets for them to follow
the instructions as defined in the
detail for each tag. In the markets
it is not listed as mandatory, it is
considered optional.
Field: 56 Not applicable Optional for Domestic and Cross- This field is Tag-Length-Value
border money and non-money (TLV).
Usage 2
transfer AFTs.
Contains the recipient's full
Dataset ID 05
In Canada, Cross Border transactions address.
Length: Various into and out of Canada must include
Note: Must be the recipients
Recipient the address of the person or entity
primary residential address and
Address receiving the funds from the AFT.
not a P.O. Box Address.
Format: ANS The field is defined with the these
tags:
Field 56 Not applicable Required for cross-border money This tag will contain the first line of
and non-money transfer the recipient address.
Account Owner
transcriptions into and out of
Address Line 1 Note: This tag is required for
Canada.
transactions into and out of
Tag 86
Canada. Otherwise, it is optional.
Length: 99
Format: ANS
Field 56 Not applicable This tag will contain the second line Note: This tag is optional.
of the recipient address.
Account Owner
Address Line 2
Tag: 87
Length: 99
Format: ANS
Field 56 Not applicable This tag will contain the street name Note: This tag is optional.
of the recipient address.
Account Owner
Street Name
Tag: 88
Length: 99
Format: ANS
Field 56 Not applicable This tag will contain the house or Note: This tag is optional.
building number of the recipient
Account Owner
address.
Building
Number
Tag: 89
Length: 16
Format: ANS
Field 56 Not applicable This tag will contain the postal code Note: This tag is optional.
of the recipient address.
Account Owner
Postal Code
Tag: 8A
Length: 16
Format: ANS
Field 56 Not applicable This tag will contain the city name of Note: This tag is mandatory for
the recipient address. transactions into and out of
Account Owner
Canada. Otherwise, it is optional.
City Name
Tag: 8B
Length: 25
Format: ANS
Field 56 Not applicable This tag will contain the country ISO Note: This tag is optional.
subdivision code of the recipient
Account Owner
address.
Country
Subdivision
Code, Minor
Tag: 8C
Length: 16
Format: ANS
Field 56 Not applicable This tag will contain the state or Note: This tag is mandatory if Tag
province ISO subdivision code of the 8E contains the value of CAN or
Account Owner
recipient address. USA. Otherwise, it is optional.
Country
Subdivision
Code, Major
Tag: 8D
Length: 3
Format: ANS
Field 56 Not applicable This tag will contain the fixed length Note: This tag is mandatory for
alpha-3 ISO country code of the transactions into and out of
Account Owner
recipient address. Canada. Otherwise, it is optional.
Country Code
Tag: 8E
Length: 3
Format: A
Field 60.2 Not applicable Valid values for Terminal Entry Refer to Full Service POS Online
Capability are: Messages – Technical Specifications
Terminal Entry
for a complete list of valid values
Capability l 1 Terminal not used
and for the details of this field.
Length: 1 Note: For card not present
Format: 1 N transactions, use this value.
l 2 Magnetic stripe read capability
l 3 QR Code
l 5 Contact chip, magnetic stripe,
or proximity-capable terminal,
indicating that the terminal can
read the chip and the magnetic
stripe on the card.
If contact chip is supported, value
5 should be used regardless of
whether Visa contactless is also
supported.
l 8 Proximity-read-capable. For
Visa contactless, an 8 should be
used only if Visa contactless is
supported and contact chip is
not.
l 9 Terminal does not read card
data
Note: Acquirers must select the
appropriate value for card present or
card not present transactions. If the
transactions data is not accurate,
Visa will charge Data Integrity Fees
on the acquirer.
Field 60.8 Not applicable Examples of valid values for e- Refer to existing BASE I manuals
commerce transactions include 5–8. for a complete list of valid values
Mail/Phone/
and for the details of this field. For
Electronic l 05 Fully authenticated e-
Europe, also refer to 3DS manual.
Commerce commerce transaction
Payment
l 06 Merchant attempted to
Indicator
authenticate the cardholder
(BASE I only)
l 07 Non-authenticated e-
Length: 1 commerce transaction
Format: 2N, 4- l 08 Non-secure e-commerce
bit BCD transaction
Field 62.1 TCR 0, pos. 151 Y – Request a CPS Qualification For U.S. only: Send a value of Y to
Authorizations For dual message, check check transaction for CPS qualifi
Characteristics include the Authori cation.
Indicator zation Characteristics
Indicator that was
Fixed length;
sent in the authori
Format: 1 AN,
zation message.
EBCDIC; 1 byte
Field 62.20 Not applicable Visa assigns the first six positions MVV is used to identify merchants
and assists the acquirer in assigning that participate in a variety of
Merchant Verifi
the last four. programs. The MVV is unique to
cation Value
the merchant.
(MVV) Acquirers are not required to provide
the last four digits of the MVV. V.I.P. edits:
Length: 10
If the MVV is not valid, V.I.P. rejects
Format: 4-bit
the transaction with reject code
BCD, 5 bytes
0720.
Field 63.1 Not applicable Acquirers, service providers, or Note: If an acquirer, service
merchants must send a value of provider, or merchant sends the
Network Identi
0000 (Priority Routing) or 0002 transaction with a value of 0000
fication Code
(Network ID 2). (Priority Routing), it will be routed
Length: 2 over network 2.
Issuers will receive a value of 0002 in
Format: 4 BCD this field.
Field 63.6, pos. 4 Not applicable Examples of valid values for e- Refer to existing SMS manuals for
commerce transactions include 5–8. a complete list of valid values and
Mail/Phone/
the details of this field.
Electronic l 05 Fully authenticated e-
Commerce and commerce transaction
Payment
l 06 Merchant attempted to
Indicator
authenticate the cardholder
(SMS only)
l 07 Non-authenticated e-
Length: 1 commerce transaction
Format: 1 ANS, l 08 Non-secure e-commerce
EBCDIC transaction
Field 63.6, pos. 7 TCR 1—Additional This field must contain the value of 7
Data cryptocurrency, if the AFT is used to
Special
fund a wallet that can be used to
Condition position 74 - 75
purchase cryptocurrency.
Indicator,
Merchant Transaction
Merchant
Indicator
Transaction
Field: 104 Not applicable Contains the Payment Facilitator ID This field is Tag-Length-Value
(TLV).
Usage 2
Required when the AFT transaction
Dataset ID 56
is related to facilitating payments
Tag: 01 such as funds disbursements.
Length: 11
Payment
Facilitator ID
Format: AN
Field: 104 Not applicable Contains the Sponsored Merchant This field is Tag-Length-Value
ID, where Payment Facilitator is (TLV).
Usage 2
included.
Required when the AFT transaction
Dataset ID 56
is related to facilitating payments
Tag: 02 such as funds disbursements.
Length: 15
Sponsored
Merchant ID
Format: AN
Field 104 Not applicable Contains the Full Acceptor Legal Full acceptor legal business name
Business name required
Usage 2
Optional for Domestic Money and
Dataset ID 56
Non-money Transfer transactions.
Acceptor Legal
Mandatory for Cross-border
Business Name
Money and Non-money Transfer
Tag: 81 AFTs.
Length: 25 Use this field to populate the
Format: ANS, merchant name for all cross-border
EBCDIC AFTs destined to Canada and
Australia (for all BAIs).
Field: 104 Not applicable Contains the Full Payment Facilitator This field is Tag-Length-Value
Name (TLV).
Usage 2
Full Payment Facilitator name is
Dataset ID 56
required to assist issuer screening.
Tag: 82
Required when the AFT transaction
Length: 25 is related to facilitating payments
Payment such as funds disbursements.
Facilitator Name
Format: ANS
Field 104, Usage TCR 3, pos. 19-20 AA (Account-to-account Money Inclusion of a valid BAI is required
2, Dataset Value Transfer) for AFTs as specified in the table
Business Application
Hex 57 AFT Categories.
Identifier (BAI) BI (Financial institution-offered P2P
Business Money Transfer) Important: A valid BAI is required
Application for all AFTs globally.
PP (Person-to-person Money
Identifier (BAI)
Transfer) Note: V.I.P will reject any AFT
Tag: 01 transaction without a valid BAI with
TU (Prepaid top-up/reload)
reject code 0494 (Field or data
Length: 2
WT (Wallet Transfer) missing or invalid).
Format: AN
FT (Funds Transfer)
PD (Payroll Disbursement)
FD (Funds Disbursement)
Field 104, Usage Not applicable Values are 00-99 Contains the risk score for the Visa
2, Dataset Value transaction.
Hex 5B
Advisor E-Commerce Scoring
Visa Risk Service. It indicates the degree of
Assessment risk associated with a transaction.
Data
There is PCR level participation to
Tag: 01 receive this score in the response.
A valid MVV is also required.
Risk Score
Note: Tag 01—Risk Score is always
Length: 2
present in Field 104, Usage 2,
Format: N Dataset ID 5B.
Field 104, Usage Not applicable Values are 00-10 Contains the risk potential for
2, Dataset Value fraud to occur on the card account
Hex 5B over the next 30 days.
Visa Risk Note: Tag 02—Risk Condition
Assessment Code may not be present in all
Data Tag: 02 transactions.
Risk Condition
Code
Length: 2
Format: N
Field 104 Not applicable Tag 84 will contain the sanctions This field is Tag-Length-Value
screening scoring results code for (TLV).
Usage 2
AFT messages and will be present in
Full financial request messages are
Dataset ID 5B 0100 Authorization and 0200
sent to issuers that choose to
Tag: 84 receive screening scores.
Length: 3
Sanctions
Screening
Scoring Results
Code
Format: N
Field: 104 Not applicable A numeric identifier provided to This field is Tag-Length-Value
uniquely identify the recipient of the (TLV).
Usage 2
AFT funds. Could represent an
This field is optional for Domestic
Dataset ID 5F invoice number, other account
and Cross-Border Money and Non-
Tag: 01 identifier, or specific transaction
money Transfer AFTs.
reference number.
Length: 16 Inclusion of this tag is conditional;
This tag is conditional; if the
Sender if the sender’s account number
recipient’s account number (Tag 02)
Reference (Tag 02) is not available or not
is not available or not applicable this
Number applicable to the transaction, this
tag must be present and contain a
tag must be present and contain a
Format: AN reference number for the intended
reference number for the sender.
recipient of the funds. This tag can
also be present along with Tag 01.
Field: 104 Not applicable Cross-border: Account number of In an AFT this field contains the
the recipient account being funded account number of the Recipient
Usage 2
by the AFT, is mandatory in cross- Account being funded by the AFT.
Dataset ID 5F border Money Transfer AFTs.
Note: Inclusion of this tag is
Tag: 02 Domestic: Optional in domestic conditional; Tag 01 or Tag 02 are
Length: 34 AFTs. required. If this tag is not included,
Sender Reference number (Tag 01)
Sender Account Europe intra-EEA cross-border:
must be present and contain a
number Account number of the recipient
reference number for the recipient
account being funded is mandatory
Format: AN account.
in domestic and intra-EEA Money
Transfer AFTs.
Field 104 Positions: 74–103 Cross-border: Must contain This field contains the valid legal
sender’s name. name of the person or entity
Usage 2 Length: 30
funding the AFT.
Format: AN Europe intra-EEA cross border:
Dataset Value
Must contain sender’s name. Sender Name Example:
Hex 5F
Domestic: May contain sender’s The Sender Name can be up to
Tag: 03
name; if not applicable, do not thirty characters long and must be
Length: 30 include the tag. the sender’s legal name. If the
Format: AN, Note: Sender’s name must be sender’s name is greater than
EBCDIC populated using the Latin (i.e., thirty (30) characters, use only the
English) character set and be an first thirty characters of the name.
Sender Name actual person’s name. Use of a The required format for the Sender
effective from phone number, email address or Name field is:
23 April 2022 alias is not permitted.
l Last Name/Family Surname 1
plus space
l Last Name/Family Surname 2
(optional) plus space
l First Name plus space
l Middle Initial or Middle Name
(optional) plus space
Note: This field must not contain
special characters.
l Doe Jane A.
l Vellaichary Jabachardinat Savi
Optional for Domestic Money and
Non-money Transfer AFTs, except
in:
l Europe
Mandatory for Cross-border
Money and Non-Money Transfer
AFTs.
Field 104, Positions: 104–138 Cross-border (including Europe Should include the details that the
intra-EEA): Must contain sender’s originating entity has collected
Usage 2, Length: 35
address. from their customer and should
Dataset Value Format: AN Domestic: May contain sender’s ideally reflect the details registered
Hex 5F Sender Address address; if not required, do not by the sender with the sender’s
Tag: 04 include this tag. issuer to whom the AFT request is
made.
Length: 35
Note: Must be the sender's
Format: AN primary residential address and
Sender Address not a P.O. Box Address.
effective from Optional for Domestic Money and
23 April 2022 Non-Money Transfer AFTs.
Mandatory for Cross-border
Money and Non-Money Transfer
AFTs.
Field 104, Usage Positions: 139–163 Cross-border (including Europe Should include the details that the
2, intra-EEA): Must contain sender’s originating entity has collected
Length: 25
city. from their customer and should
Dataset Value
Format: AN ideally reflect the details registered
Hex 5F Domestic: May contain sender’s city;
Sender City by the sender with the sender’s
if not required, do not include this
Tag: 05 issuer to whom the AFT request is
tag.
Length: 25 made.
Field 104 Positions: 164–165 Cross-border: U.S. or Canada: Must The geographical state or province
contain sender’s state/province in associated with the sender’s
Usage 2 Length: 2
this field on cross-border primary residential address.
Dataset Value Format: AN transactions when Sender Country
Hex 5F l Optional for Domestic Money
Sender State/Province (Tag 07) contains the value of 840 and Non-money Transfer AFTs.
Tag: 06 (U.S.) or 124 (Canada).
l Mandatory for Cross-border
Length: 2 Other Domestic and Cross-border:
Money and Non-money
May contain sender’s state/province;
Format: AN Transfer AFTs.
if not required, do not include this
Sender State/ tag.
Province
effective from
23 April 2022
Field 104 Positions: 166–168 Cross-border: Must contain Contains the Country of the person
sender’s country. funding the transaction.
Usage 2 Length: 3
Note: Sender country must be the Optional for Domestic Money
Dataset Value Format: AN l
sender’s country based on the and Non-money Transfer AFTs.
Hex 5F Sender Country
primary residential address.
Tag: 07 l Mandatory for Cross-border
Other Domestic: May contain Money and Non-money
Length: 3 sender’s country; if not required, do Transfer AFTs.
Format: AN not include this tag.
Field 104, Not applicable Cross-border: Recipient name is This field contains the name of
mandatory in cross-border Money the individual or entity that is
Usage 2, See Note.
Transfer AFTs. the intended recipient of the
Dataset Value funds. Recipient name is
U.S. Domestic: Optional in domestic
Hex 5F mandatory for cross-border money
AFTs.
Tag: 0A transfer AFTs.
Europe Domestic and Europe
Length: 30 Issuers must be prepared to
intra-EEA cross border: Recipient
receive Tag 0A/Recipient Name in
Format: AN, name is mandatory in domestic and
any AFT.
EBCDIC intra-EEA Money Transfer AFTs.
5 The maximum length of the
Recipient Name recipient name is 30 characters.
(Row 1 of 2)
effective from Recipient Name Example:
23 April 2022 The Recipient Name can be up to
thirty characters long and must be
the recipient individual or entity's
legal name. 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 for individual recipient
is:
l 0-9
l A-Z
Examples:
l Doe Jane A.
l 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.
V.I.P. Edit: Effective October
2023, V.I.P. rejects AFTs with the
existing reject code 0494 (Field or
data missing or invalid) if this field
is not populated for cross-border
AFTs.
Field 123 Not applicable Zip code or full address AVS is required in the U.S for CPS
Address Verifi Note: Zip code can be 5 or 9 qualification for card not present
cation Data characters. transactions.
Note: AVS Results Code will be
Length: 1 byte,
returned in Field 44.2 of the
binary + Fixed
response message.
Format: 29 ANS,
EBCDIC;
maximum 30
bytes
Bytes 2-10:
Postal Code
Bytes 11-30:
Card holder
street address
Field 123 Usage Not applicable Token that is used to replace the
2, Dataset ID 68 cardholder PAN and is a required
data element for token processing.
Tag: 01
Token
Length: 13 - 19
Format: N
Field 123 Usage Not applicable Contains the Token Requestor ID.
2, Dataset ID 68
Tag: 03
Token Requestor
ID
Length: 11
Format: N
Field 123 Usage Not applicable Value can be 01–63 (in hexadecimal Contains the Index number from
2, Dataset ID 68 format). (Decimal 1-99). the Visa database where the device
ID is stored.
Tag: 80
Note: Authorization transactions
Bound Device
with a token can contain tag 80
Index
with a zero value. This indicates
Length: 1 a device index is not available
Format: Binary for the transaction.
Field 123 Usage Not applicable Application types are: Application type of token user.
2, Dataset ID 68 Entities can be a merchant, a
l 00 = Unknown
marketplace, or a check out host.
Tag: 82
l 01 = Web
Token User
l 02 = Mobile web
Application Type
l 03 = Mobile application
Length: 1
l 04 = Marketplace application
Format: Binary
l 05 = Voice application
l 06 = Biometric application
l 07-FF = Reserved
Field 123 Usage Not applicable Authentication Values are: Contains authentication factor
2, Dataset ID 68 used by token requestors and
l 00 = No authentication method
merchants to authenticate
Tag: 83, acquired
cardholder at the time of
Token Authenti l 01 = Username/password transaction.
cation Factor A
l 02 = Passcode or password Applicable for e-commerce
Length: 1 transactions (device and card-on-
Consumer Device Cardholder
Format: Binary file token types).
Verification Method (CDCVM):
Row 1 of 2 l 10 = Passcode
l 11 = Password
l 12 = Pattern
l 13 = Biometric fingerprint
l 14 = Biometric facial recognition
l 15 = Biometric iris recognition
l 16 = Biometric voice recognition
l 17 = Behavioral biometric
One Time Passcode (OTP):
l 30 = Short message system
(SMS)
l 31 = Email
l 32 = Hardware token without
user verification
l 33 = Hardware token with user
verification
l 34 = Soft token
l 35 = Any other method
l 40 = Knowledge based authenti
cation
l 41 = Out of band (OOB) authenti
cation
l 42 = Local authentication
Fast Identity Online (FIDO):
Field 125 Usage Not applicable This tag contains the Device ID.
2, Dataset ID 01
Tag: 03
Device ID
Length: 48
Format: ANS
Field 125 Usage Not applicable This tag contains the full phone
2, Dataset ID 01 number or partial phone number
when available.
Tag: 04
Device Number
Length: 15
Format: N
Field 125 Usage Not applicable This tag contains the obfuscated
2, Dataset ID 01 geographic location of the device
or the coarse location of the
Tag: 06
device. Location is latitude/
Device Location longitude with 4 digits of precision,
Length: 25 for instance, +37.7799/-122.4290.
Precision is rounded off to a less
Format: ANS granular level, for instance,
+37/-122 or +37.78/-122.43.
Field 125 Usage Not applicable The value will be in the format: This tag contains the IP address of
2, Dataset ID 01 255.255.255.255. Each octet (255) the device at the time of the
may be 1–3 digits in length. provisioning request.
Tag: 07
IP Address
Length: 15
Format: ANS
Field 126.8 Not applicable For 3DS and token transactions, the 3-D Secure TAVV, Version and
acquirer can: Authentication Action for payment
Transaction ID
tokens and token cryptograms
(XID) l Populate Field 126.8 with the
present in e-commerce POS
Length: 20 TAVV
authorization and full financial
bytes, fixed l Populate Field 126.9 with the messages, is used in conjunction
Format: Binary CAVV with Field 126.9 for 3-D Secure
(3DS) and non-3DS token
For transaction with Visa tokeni
transactions.
zation only (acquirer not using 3DS),
the acquirer should : Testing and activation are required
to implement Field 126.8 for the
l Populate Field 126.8 with the
first time.
TAVV
There is no CAVV here.
Field 126.9 Not applicable For transactions with 3DS authenti This field may be present in an AFT.
cation & authorization only (not Refer to the Full Service POS
CAVV Data
including tokenization), the acquirer Technical Specifications for
Length: 20 should populate this field with the information about this field.
bytes, fixed CAVV.
Format: Binary
Field 127, Not applicable l A (Account number change (the Indicates the account status.
Dataset ID 41 account number or account
Account Status number and expiration date are
being updated))
Length: 1
l C (Closed account advice)
Format: AN,
EBCDIC l E (Expiration date change)
Field 127, Not applicable Valid values are: This field indicates if replacement
Dataset ID 41 occurred in the response message
l Y (Requesting for replacement
sent to the originating entity.
Request from PAN details)
Merchant for
l Y (Replacement occurred)
Updated
Account l N (No replacement)
Length: 1
Format: AN,
EBCDIC
Tag: 07
Field 127, Not applicable l VAU001 (Transaction did not Indicates the reason a transaction
Dataset ID 41, qualify for Real Time Visa Account did not qualify for account
Updater (VAU) because the information replacement.
Error Reason
Code transaction contains token)
Not Applicable Business Format Code Value = CR Code indicating the type of
(AI) business that is applicable to this
transaction.
Positions: 17–18
This field must contain CR (for
Length: 2
Business Application Data).
Format: AN
1 Effective April 2020, CEMEA is mandating support of AFT with Processing Code 10.
2 If the funds will be used for a high-brand risk transaction, use the applicable high-brand risk MCC.
3 If the funds are used for a high-brand risk transaction, use the applicable high-brand risk MCC.
4 The recipient’s name is not required but recommended in all regions.
5 Effective 23 April 2022, Visa will also require recipient account number or reference number to be included in all AFTs.
The Purpose of Payment code list is required to classify and report the nature and purpose of the
payment.
Note: This is a standardized list and not all codes may be applicable to an AFT. The acquirer must
submit the correct purpose of payment code for the recipient issuer's jurisdiction and restrict clients
to a predetermined list.
Important: An AFT is not intended for:
l payment of goods and services
l funding of a merchant account
l debt repayment
ISCOMM Commission
ISENRG Energies
ISINSM Installment
ISINTE Interest
ISINVS Investment
ISLOAN Loan
ISOTHR Other
ISPAYR Payroll
ISROYA Royalties
ISSECU Securities
ISSTDY Study
ISSUBS Subscription
1. Originating entity submits 0220 advice message to Visa to request refund of money to
sender's account.
2. Visa sends 0220 auth message to recipient issuer.
3. Recipient issuer uses the 0220 message to restore balance to the cardholder’s account.
4. Recipient issuer responds with 0230.
5. Visa receives the 0230.
6. Visa sends the 0230 confirmation back to originating entity to confirm success of submission.
1. Originating entity submits 0220 advice message to Visa to request refund of money to
sender's account.
2. Visa receives the 0220 advice message.
3. Visa creates 0230 STIP advice and returns to originating entity to confirm.
4. Visa creates TC25 TCQ01 and sends to recipient issuer for processing.
5. The recipient issuer receives the TC25 TCQ01 and restores the balance to the cardholder.
1. Originating entity raises TC25 TCQ 01 to Visa to request refund of money to senders account.
2. Visa receives the TC25 TCQ01 incoming files.
3. Visa creates 0220 advice and forwards to recipient issuer.
4. Recipient issuer receives 0220 advice and creates 0230 message.
5. Recipient issuer creates 0230 response and sends to Visa.
6. Visa receives the 0230 response confirming receipt and processing of 0230 advice.
1. Originating entity submits TC025 TCQ01 outgoing to Visa to request refund of money to
sender’s account.
2. Visa receives the TC25 TCQ01 and forwards to the recipient issuer for processing.
3. Recipient issuer processes the TC25 TCQ 01 and restores balance to cardholder’s account.
Table 15: Business Application Identifier (BAI) Acronyms (Permitted BAIs for AFTs in Bold)
(1 of 2)
Acronyms Meaning
AA Account-to-Account
BB Supplier Payments
CD Cash Deposit
CI Cash In (Deposit)
Table 15: Business Application Identifier (BAI) Acronyms (Permitted BAIs for AFTs in Bold)
(2 of 2)
Acronyms Meaning
CO Cash Out (Withdrawal)
FD Funds Disbursement
FT Funds Transfer
GD Government Disbursement
MD Merchant Settlement
MP Merchant Payment
PP Person-to-Person or Peer-to-Peer
3-D Secure (3DS) 3-D Secure is the name of a security protocol used for online credit and debit
card transactions. The name refers to the three domains governed by the
protocol: the merchant/acquirer domain, the issuer domain, and the
interoperability domain. The interoperability domain refers to the underlying
infrastructure that supports the payment card or scheme.
Access Channel A channel, such as an ATM or a mobile app, provided by an originating entity to
offer AFT program services to its customers.
Account Funding Transaction A Transaction where funds are pulled from a Visa account and are subsequently
(AFT) used to fund another Visa or non-Visa account. Required when loading a prepaid
card account, moving funds into another financial account, funding a person-to-
person Money Transfer, funding payroll disbursements, or adding value to a
digital wallet.
Account Name Inquiry (ANI) Account Name Inquiry (ANI) is a functionality offered by Visa that enables an
account cardholder’s name to be checked against the name held by their issuing
bank. The check is carried out by Visa or the issuing bank in advance of a
transaction at the time of customer onboarding, just before a transaction,
periodically, or on an ad hoc basis.
Verifying the name provided by a cardholder can help reduce exposure to fraud
and scams in many types of payment flows, such as Card-Not-Present
transactions, but in particular in push and pull transactions (OCTs/AFTs).
Account-to-Account (AA) An AFT in which the funds will be transferred to another of the cardholder’s own
accounts at the same or a different financial institution (Me-to-Me money
transfer transaction).
Acquirer In relation to AFTs, a licensed Visa client that originates transactions or that
sponsors a third-party agent to originate transactions. Acquirers are responsible
and liable for all AFT programs that they operate or sponsor.
Account Verification A message sent by an acquirer to the issuer, using a currency unit of zero, for
confirmation that a transaction can be completed using the Card.
Address Verification Service A VisaNet service through which a merchant verifies a cardholder’s billing
(AVS) address. This service is available in the U.S., Canada, and Europe regions only.
AFT Program The AFT services and access channels that an originating entity offers to its Visa
cardholders.
Back-to-Back Funding A payment flow that automatically transfers value via a funding transaction or
transaction that is directly connected to a specific purchase.
In Back-to-Back Funding:
l Two separate accounts are involved. One account is used to make the
purchase, and the other automatically funds or reimburses that account.
l Both accounts are held by the same person or corporate entity, and at least
one account is a Visa account.
Business Application Identifier A data element in the AFT message that identifies the business application for
(BAI) which funds are being pulled from a Visa account. Values are:
Card-on-File (COF) This is most applicable to merchants who store user credentials, including the
PAN.
Cardholder Account Verification The Cardholder Authentication Verification Value (CAVV) is a cryptographic value
Value (CAVV) the issuer or V.I.P. generates and sends to the merchant during the authentication
process in a Visa Secure transaction.
Card Verification Method (CVM) Instructions encoded within a chip that define how the authenticity of a
cardholder's identity is to be verified.
Card Verification Value 2 (CVV2) A card verification tool used by issuers to validate that a genuine payment card is
present at the cardholder location during a transaction.
Digital Authentication DAF builds upon Visa Secure for authentication and Visa Token Service for
Framework (DAF) network tokenization. This framework is designed to elevate the performance of
merchants’ for Card Not Present transactions. Merchants and token requestors
that meet the DAF criteria (as set by Visa) will be allocated ECI value of 05 on
qualified authenticated transactions and will receive fraud dispute protection (as
per Visa rules) on those transactions.
Digital Wallet An electronic device that allows an individual to make electronic commerce
transactions, such as purchasing an item online with a computer or using a
smartphone to purchase something at a store.
Electronic Commerce Indicator Numeric code specifying the type of mail order, phone order, or electronic
(ECI) commerce transaction.
E-Commerce (ECOM) A platform that allows sales and purchases of goods and services over an
electronic network – typically the internet.
European Economic Area (EEA) European Economic Area (EEA), which includes the member states of the
European Union, and Iceland, Liechtenstein, and Norway. Countries/member
states include Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, in addition to Iceland, Liechtenstein,
and Norway.
Financial Institution–Offered A P2P Money Transfer offered by a financial institution through their own mobile
P2P Money Transfer or online banking application.
Foreign Exchange Rate API An API that allows the originating entity to look up the current day’s foreign
exchange rate using Visa rates and, using this rate, to convert the amount in the
originating entity’s currency to the amount in the recipient’s currency.
Funds Transfer API The financial API used to initiate an AFT and its associated reversal.
Host Card Emulation (HCE) HCE enables mobile applications running on supported operating systems with
the ability to offer payment card and access card solutions independently of third
parties while leveraging cryptographic processes traditionally used by hardware-
based secure elements without the need for a physical secure element.
ISO 8583 Message International Organization for Standardization financial transaction card–
originated message specifications for systems that exchange electronic
transactions made by cardholders using payment cards. Basis of Visa's V.I.P.
message format (BASE I and SMS).
Issuer The Visa client financial institution that has entered into a contractual relationship
with a cardholder for the issuance of one or more Visa card products. Issuers
receive authorization requests for AFTs and debit the cardholder’s account
accordingly.
Merchant A merchant is defined as an entity that enters into an agreement with an acquirer
for the acceptance of cards for purposes of originating payment transactions
under the Visa-Owned Marks.
Merchant Category Code (MCC) A code designating the principal trade, profession, or line of business in which a
merchant is engaged.
Money Transfer The ability for an individual to send funds from their Visa account to a different,
non-merchant account.
Non-Merchant Account A financial account that is eligible to receive a funds transfer initiated by an AFT.
Original Credit Transaction A VisaNet transaction that can be used to send funds to an eligible Visa account.
(OCT) Visa acquirers can use the OCT to enable services such as Money Transfers, funds
disbursements, prepaid loads, and credit card bill payments.
Originator Term no longer used. Replaced with acquirer, service provider, merchant and/or
originating entity as applicable. Formerly: An entity (a Visa acquirer or a sponsored
third-party agent) that generates AFTs as a service to its customers.
Primary Account Number (PAN) The 16 to 19-digit number assigned to the payment account. Also known as the
Card Number.
Payment Account Attributes An API that allows the merchant, service provider or acquirer to obtain
Inquiry API information about the sender's account and to determine whether domestic and
cross-border AFT eligibility is available for the sender’s or recipient’s non-Visa
accounts.
Payment Account Validation An API that allows the merchant, service provider or acquirer to perform CVV2
(PAV) API and/or address verification on the sender’s account.
Person-to-Person (PP) Money Transfer in which AFT funds will be sent to another individual’s non-
merchant account.
Prepaid Load (TU) An AFT in which the funds will be used to add value to a prepaid card.
Purchase Transaction A VisaNet transaction using Transaction Code (TC) 05 or Processing code of 00.
Push Payment Gateway Service (U.S. region only) Allows originating entities in the U.S. to send AFTs to Visa for
(PPGS) routing to multiple U.S. debit networks.
Real Time Visa Account Updater Visa Account Updater (VAU) is a service that facilitates exchanging updated
(VAU) account information between participating merchants and Visa card issuers and
thus encouraging customer satisfaction, retention, and loyalty. Real Time VAU is a
feature that eliminates the multi-step process to update account information.
Receiving Account The account that will receive the funds that have been pulled by an AFT.
Recipient The person who owns the account that receives the funds pulled by an AFT.
Recipient Issuer The issuer of the card account that receives the funds pulled by an AFT.
Sender's Issuer The Visa client financial institution that issued the Visa card used to fund an AFT.
The issuer authorizes the transaction and debits the sender’s Visa account.
Service Provider An acquirer sponsored third-party entity that enables AFT-based services on
behalf of an acquirer or offers AFT-based services to merchants.
Staged Digital Wallet (SDW) A wallet where funds can be added and stored to a digital account with a
proprietary merchant acceptance network. The funds can be used to:
Standard Purchase Transaction A transaction that pulls funds from a Visa account for the purpose of purchasing
goods and services or otherwise funding a merchant account.
Stored Value Digital Wallet A wallet where funds can be added and stored to a non-Staged Digital Wallet
account. The funds can be used to send to other users, make payments to
multiple merchants, or to cash out to an unaffiliated account.
Stored Value Digital Wallets must limit usage to the available balance in the wallet
and must not facilitate real-time or live-load Back-to-Back Funding. SVDW may
have a general-purpose payment network card/account at the “front” of the
wallet.
Token Authentication E-commerce token transactions require the use of a token authentication
Verification Value (TAVV) verification value (TAVV) with the token as part of the capabilities provided by the
Visa Token Service.
Third-Party Agent An entity, not defined as a VisaNet Processor, that provides payment-related
services to a client and/or that stores, transmits, or processes cardholder data. In
the context of AFT programs, any third-party entity or service provider that
manages or facilitates AFT programs; for example, payment facilitators, load
partners, etc.
Token Substitute values that replace the cardholder primary account number in
payment transactions during transaction processing.
Token Requestor (TR) A token requestor - token service provider is a third-party, Visa-compliant
business entity that provides products and services to participating token
requestors under and subject to the Visa Digital Enablement Program Token
Service Provider Program. Token requestor-token service providers are directly
connected to the Visa Token Service and enable token requestors to develop
consumer digital payment solutions powered by the Visa Token Service. The
token requestor-token service provider will be the integration partner facilitating
the provisioning, cryptogram request, and lifecycle management of Visa payment
tokens to the token requestor.
Visa Account Updater (VAU) Is a key service to support payment continuity in recurring billing and credential-
on-file segments. Real Time VAU is a feature that eliminates the multi-step
process to update account information.
Visa Direct The Visa product platform that provides funds transfer capabilities using AFTs and
OCTs.
Visa Direct Application Web services–based request and response messages that originating entities can
Programming Interfaces (APIs) use to communicate with Visa to initiate AFTs and to support related value-added
services.
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 clients.
VisaNet Integrated Payment The online component of VisaNet that provides routing and processing of
(V.I.P.) System authorizations and financial messages.
Visa Payment Token A Payment Token is an “alternate identifier” that can be used in place of a PAN to
initiate a payment transaction.
Visa Secure A Visa-approved authentication method based on the 3-D Secure Specification.
Visa Token Service The Visa Token Service (VTS) replaces Primary Account Numbers (PANs) with
Payment Tokens that can be used as payment credentials during payment
transaction processing. VTS stores the Payment Tokens and performs PAN
mapping to enable functions like detokenization and life-cycle management.
Wallet Transfer (WT) An AFT in which the funds will be used to add value to a digital wallet with a non-
general-purpose payment network brand acceptance mark. BAI = WT is used
only for Staged Digital Wallets in these circumstances:
l In AFTs when funding a Staged Digital Wallet before the cardholder makes a
purchase.
l To fund a purchase when initiated by the Staged Digital Wallet provider and
corresponding to, or otherwise directly connected to a specific purchase (also
called Back-to-Back Funding live-load or real-time funding). In this scenario,
the transaction must be processed as a purchase transaction, with a BAI value
= WT.