Account Funding Transaction (AFT): The Definitive Guide for 2026

An Account Funding Transaction (AFT) is a card-based transaction where the cardholder’s purpose is to move money into an account — not to buy goods or services. With Visa and Mastercard now mandating proper AFT classification, understanding how AFT transactions work is essential for any business that processes money transfers, wallet loads, prepaid funding, or remittances through card payments.

This guide covers everything you need to know about account funding transactions: what they are, how they work, how they differ from standard purchase transactions, who needs AFT processing, the Visa AFT mandate timeline, transaction codes and data fields, PayPal’s role in the AFT ecosystem, compliance requirements, and how to implement AFT processing correctly.

What Is an Account Funding Transaction?

An Account Funding Transaction (AFT) is a card payment where the cardholder uses their debit or credit card to transfer funds into an account, rather than to purchase a product or service. The defining characteristic of an AFT is intent: the cardholder is moving money, not buying something.

Common examples of account funding transactions include:

• Loading funds into a digital wallet (such as PayPal, Venmo, or a proprietary wallet)
• Funding a money transfer or international remittance
• Loading a prepaid card using another debit or credit card
• Topping up a mobile phone account via card payment
• Funding a brokerage or investment account with a card
• Paying into a peer-to-peer (P2P) payment platform
• Purchasing cryptocurrency or stablecoins via card (on-ramp transactions)

In each of these cases, the cardholder’s card is debited, but no goods or services are delivered in return. Instead, the funds land in another account — whether that account belongs to the cardholder themselves, another person, or a third-party platform.

Until recently, many businesses processed AFTs using standard purchase transaction codes. The card networks have now mandated that these transactions be properly classified, carrying specific indicators and data fields that distinguish them from ordinary purchases. This classification is not optional — it is a compliance requirement enforced by both Visa and Mastercard.

How AFT Transactions Work: Step by Step

An AFT follows a specific processing flow that differs from a standard card purchase. Understanding each step is critical for businesses implementing AFT processing for the first time.

Step 1: Cardholder Initiates Fund Transfer

The cardholder enters their card details to fund a transfer, load a wallet, or top up an account. This can happen through an online checkout page, a mobile app, an API integration, or a physical terminal at an agent location. The cardholder may also provide sender information required for compliance (name, address, reference number).

Step 2: Merchant/Acquirer Submits AFT Authorization

The merchant’s payment system sends an authorization request to its acquiring bank (or payment processor). This request must include the AFT indicator flag — a specific field in the authorization message that identifies this as an account funding transaction, not a purchase. The request also includes all required sender data fields.

Step 3: Card Network Routes the Transaction

The acquiring bank forwards the authorization request through the card network (Visa or Mastercard) to the cardholder’s issuing bank. The card network recognizes the AFT indicator and applies AFT-specific processing rules, interchange rates, and risk parameters.

Step 4: Issuing Bank Authorizes or Declines

The issuing bank evaluates the AFT request. Issuers may apply different risk thresholds and fraud rules to AFTs compared to purchases. Some issuers have specific AFT velocity limits or spending caps. The issuer sends an authorization response back through the network.

Step 5: Funds Are Settled

If authorized, the transaction enters the settlement process. AFTs follow standard settlement timelines, but the interchange rate applied is from the AFT interchange schedule — not the purchase interchange schedule. The acquirer receives the settled funds, minus interchange and network fees.

Step 6: Funds Are Delivered (OCT or Internal Transfer)

Once the AFT settles, the merchant or platform delivers the funds to the intended destination. For money transfers and remittances, this is typically done via an OCT (pushing funds to a recipient’s card or bank account). For wallet loads and prepaid funding, the platform credits the user’s internal balance.

AFT vs. Purchase Transactions: Key Differences

Understanding the differences between an AFT and a standard purchase transaction is fundamental to compliance. While both involve a cardholder’s card being charged, they differ in purpose, processing, and regulatory treatment.

Attribute	Account Funding Transaction (AFT)	Standard Purchase
Purpose	Move funds into an account	Buy goods or services
Transaction Indicator	AFT flag required in authorization	Standard purchase indicator
Sender Data	Required (name, address, reference)	Not required
Interchange Rates	AFT-specific schedule (often lower for debit)	Standard purchase schedule
Refund Mechanism	Typically processed as an OCT	Standard refund/credit
Issuer Risk Treatment	AFT-specific fraud and velocity rules	Standard fraud screening
Regulatory Implications	AML/KYC sender data requirements	Standard merchant compliance
Chargeback Rules	AFT-specific dispute rules apply	Standard chargeback rules

The most common mistake businesses make is treating all card transactions the same. A customer loading $200 into a digital wallet is fundamentally different from a customer buying a $200 product — even though the cardholder experience may look similar. The card networks now require that this difference be reflected in how the transaction is classified, processed, and reported.

Who Needs AFT Processing?

AFT processing requirements apply to any business that accepts card payments for the purpose of funding an account. The following business types are directly affected:

Money Transfer Operators (MTOs)

Businesses that accept card payments to fund domestic or international money transfers. When a customer uses their debit card to send $500 to a family member abroad, that card transaction is an AFT. The subsequent delivery of funds to the recipient is an OCT or bank payout. MTOs operating under MCC 4829 are among the most directly affected by the AFT mandate.

Digital Wallet Providers

Platforms where users load funds via debit or credit card into a stored-value wallet. Every card-funded wallet load is an AFT. This applies whether the wallet is used for P2P payments, online purchases, or as a general-purpose spending account.

Prepaid Card Programs

Issuers and program managers that allow users to fund prepaid cards using another debit or credit card. The card-to-card funding transaction is classified as an AFT, subject to the full set of sender data and classification requirements.

Remittance Providers

Cross-border remittance services that accept card payments face particularly complex AFT requirements. Cross-border AFTs require additional sender data fields (identification documents, purpose of transfer) and are subject to corridor-specific rules that vary by destination country.

Mobile Top-Up & Airtime Providers

Services that accept card payments to add credit to mobile phone accounts. Depending on the specific transaction flow and how the card network classifies the activity, these may fall under AFT requirements.

Bill Payment Platforms

Platforms where users pay bills using a card, and the funds are routed to a payee account. The classification depends on the specific arrangement: if the platform is acting as an intermediary that receives funds and then forwards them, the inbound card transaction may qualify as an AFT.

Cryptocurrency & Stablecoin On-Ramps

Platforms where users purchase digital assets using a card. The classification of these transactions is evolving, but many card networks treat card-funded crypto purchases as AFTs, particularly when the transaction involves loading a custodial account rather than directly purchasing a specific asset.

Lending & Financial Services Platforms

Services that accept card payments to fund loan disbursements, investment accounts, or insurance premium payments where the funds are deposited into an intermediary account.

The Visa AFT Mandate: Timeline & Requirements

Visa’s AFT mandate requires that all transactions which fund an account be properly classified using the AFT transaction indicator in the authorization message. This mandate replaces the previous practice of processing fund transfers under standard purchase codes.

Visa AFT Mandate Timeline

What Visa Requires

Under the Visa AFT mandate, businesses must:

• Set the AFT indicator in every qualifying authorization request (Field 60.8 in Visa’s Base I format, or the equivalent field in your processor’s API)
• Include complete sender data with every AFT authorization (name, address, account number, reference number)
• Use the correct MCC for the type of business and transaction being processed
• Apply AFT-specific interchange rates as published in Visa’s interchange schedule
• Handle refunds and reversals according to AFT rules (typically via OCT rather than standard purchase refund)

Non-compliance carries real consequences: fines from Visa, retroactive interchange adjustments, mandatory remediation plans, and — in persistent cases — potential loss of processing privileges.

Mastercard AFT Mandate

Mastercard is implementing its own AFT mandate on a parallel timeline. While the fundamental concept is the same — transactions that fund an account must be classified differently from purchases — the specific requirements differ from Visa in several important ways.

Mastercard AFT Timeline

• March 2026 — AFT mandate effective for the United Kingdom, European Economic Area (EEA), and Middle East & North Africa (MENA) regions.
• 2026–2027 — Global rollout expected, with additional regions phased in over the following months.

Mastercard uses different message formats and field names than Visa for AFT classification. The transaction type indicator, sender data field mappings, and validation rules are network-specific. Any business processing on both networks — which is most businesses — must implement separate logic for each.

AFT Transaction Codes & Data Fields

AFT transactions use specific codes and data fields that distinguish them from standard purchases at the network level. Understanding these technical details is essential for developers and integration teams implementing AFT processing.

Visa AFT Technical Fields

Field	Description	Value for AFT
Processing Code (Field 3)	Identifies the transaction type	Account Funding indicator
Transaction Type Indicator	Specifies AFT vs. purchase	AFT (value varies by processor API)
Sender Name (Field 104)	Full legal name of fund sender	Required for all AFTs
Sender Address	Street, city, state, country, postal code	Required for all AFTs
Sender Account Number	PAN or token of funding source	Required for all AFTs
Sender Reference Number	Unique originator-assigned identifier	Required for all AFTs
Additional ID (cross-border)	Sender date of birth, ID type/number	Required for select cross-border corridors

Mastercard AFT Technical Fields

Mastercard uses its own field structure for AFT classification. While the conceptual data is similar to Visa, the field names, positions, and formatting rules differ. Key Mastercard AFT fields include:

• Payment Transaction Type Indicator — Identifies the transaction as an AFT within Mastercard’s authorization message format
• Additional Data — Payment Facilitator — Contains sender information in Mastercard’s prescribed format
• Funding/Payment Transaction Indicator — Further classifies the AFT subtype (wallet load, money transfer, etc.)

Visa vs. Mastercard Sender Data Comparison

Data Field	Visa AFT	Mastercard AFT
Sender Name	Required	Required
Sender Street Address	Required	Required (select regions)
Sender City	Required	Required
Sender State/Province	Required (US/CA)	Required (US/CA)
Sender Country	Required	Required
Sender Postal Code	Required	Required
Sender Account Number	Required	Required
Sender Reference Number	Required	Required
Sender Date of Birth	Cross-border (select corridors)	Required (select regions)
Sender ID Type & Number	Cross-border (select corridors)	Cross-border (select corridors)
Transaction Purpose	Cross-border (select corridors)	Cross-border (select corridors)

AFT Sender Data Requirements

One of the most operationally significant aspects of AFT processing is the requirement to collect and transmit sender data with every authorization request. This data serves dual purposes: regulatory compliance (anti-money laundering and counter-terrorism financing) and card network compliance.

Required Sender Fields (All AFTs)

• Sender Name — Full legal name of the cardholder initiating the transaction
• Sender Address — Street address, city, state/province, country, and postal code
• Sender Account Number — The card number (PAN) or a token representing the funding source
• Sender Reference Number — A unique identifier assigned by the originator to trace the transaction

Additional Fields for Cross-Border AFTs

Cross-border AFTs — where the sender and recipient are in different countries — may require additional data depending on the corridor:

• Sender Date of Birth — Required for many cross-border corridors
• Sender Identification Type & Number — Government-issued ID (passport, national ID, driver’s license)
• Purpose of Transfer — Coded or free-text description of why funds are being sent
• Recipient Information — Name and account details of the funds recipient (for certain corridors)

PayPal & Account Funding Transactions

PayPal is one of the most visible examples of a platform that processes account funding transactions at scale. When a user links a debit or credit card to their PayPal account and uses it to add funds to their PayPal balance, that card transaction is classified as an AFT. Similarly, when a PayPal user sends money to another person and funds the transfer with a linked card, the underlying card transaction is an AFT.

How PayPal AFTs Appear on Statements

Cardholders may see PayPal AFTs appear on their bank or card statement with descriptors that reference “PayPal” and sometimes include the term “AFT” or “account funding.” This can cause confusion for consumers who are unfamiliar with the AFT classification. The transaction is legitimate — it represents the cardholder’s own action of funding their PayPal account or a PayPal-facilitated transfer.

Why PayPal AFTs Matter for the Industry

PayPal’s scale means that a significant volume of AFT transactions flow through the card networks via PayPal. For smaller money transmitters and fintech platforms, PayPal’s AFT processing demonstrates the industry standard that card networks expect all participants to meet. If your business processes similar types of card-funded account loads or money transfers, the same AFT classification requirements apply to you.

The AFT mandate is not limited to large platforms. Every business — regardless of size — that accepts card payments to fund an account must comply with the same classification, sender data, and processing requirements.

AFT Interchange & Processing Costs

AFTs are subject to their own interchange rate schedules, published separately from standard purchase interchange by both Visa and Mastercard. Understanding AFT interchange is critical for financial planning, pricing, and evaluating the economic impact of compliance.

AFT Interchange vs. Purchase Interchange

• Debit AFTs — In many cases, AFT interchange rates for debit cards are lower than standard purchase debit interchange. For high-volume money transmitters, this can represent meaningful cost savings once transactions are properly classified.
• Credit AFTs — Credit card AFT interchange rates vary more widely. Some credit AFT rates are comparable to or higher than purchase rates, depending on the card program and region.
• Cross-border AFTs — Cross-border AFTs carry their own interchange schedule, typically higher than domestic AFT rates but potentially different from cross-border purchase rates.

The Hidden Cost of Misclassification

Misclassifying transactions has financial consequences in both directions:

• AFTs submitted as purchases: You may pay higher interchange than necessary, and you face compliance violations and fines from the card networks.
• Purchases submitted as AFTs: You risk compliance violations, potential penalties, and issuer-side declines (issuers may flag transactions that appear miscategorized).

The card networks use automated transaction monitoring to identify potential misclassification. Businesses that consistently submit transactions under the wrong category can expect inquiries, mandatory remediation, and financial penalties.

AFT Compliance Requirements

AFT compliance operates at multiple levels: card network rules, federal regulations, and state-level requirements. Businesses must satisfy all three to process AFTs legally and without risk of penalties.

Card Network Compliance

Both Visa and Mastercard require proper AFT classification, sender data transmission, and use of AFT-specific processing flows. Non-compliance can result in:

• Fines assessed by the card network (escalating with repeated violations)
• Retroactive interchange adjustments
• Mandatory remediation plans with deadlines
• Increased monitoring and reporting requirements
• In severe cases, suspension or termination of processing privileges

AML/KYC Regulatory Requirements

AFT sender data requirements align with broader anti-money laundering (AML) and know-your-customer (KYC) regulations. In the United States, businesses that process money transfers must comply with:

• Bank Secrecy Act (BSA) — Requires MSBs (money services businesses) to maintain AML programs, file SARs (suspicious activity reports), and maintain records
• FinCEN Registration — Money services businesses must register with the Financial Crimes Enforcement Network
• State Licensing — Most US states require separate money transmitter licenses
• OFAC Screening — All transactions must be screened against the Office of Foreign Assets Control sanctions lists

The sender data collected for AFT compliance — name, address, identification — directly supports these regulatory requirements. Proper AFT implementation creates a unified compliance framework that satisfies both card network rules and regulatory obligations.

PCI DSS Considerations

AFT processing involves handling cardholder data (the sender’s PAN, at minimum) and additional personally identifiable information (sender name, address, identification). Businesses must ensure their AFT data handling complies with PCI DSS requirements for data security, encryption, and access controls.

How to Implement AFT Processing

Implementing AFT processing requires coordination across product, engineering, operations, and compliance teams. The following checklist provides a structured approach.

1. Audit your transactions

   Map every transaction type your business processes. Identify which ones involve funding an account (AFT) versus purchasing goods or services (purchase). Document this classification clearly.

2. Review your MCCs

   Confirm which Merchant Category Codes are assigned to your processing accounts. If you operate under MCC 4829, 6540, 6012, 6051, or similar codes, AFT classification likely applies to some or all of your transactions.

3. Update your payment integration

   Work with your payment processor to send the AFT indicator flag on qualifying transactions. This typically involves updating authorization request API calls to include the correct transaction type identifier for both Visa and Mastercard.

4. Build sender data collection

   Update checkout flows, onboarding processes, and agent interfaces to collect all required sender data fields. For card-not-present transactions, update web forms and API calls. For card-present transactions, update terminal configurations.

5. Implement network-specific logic

   Build separate field mapping for Visa and Mastercard. Sender data format, field positions, and validation rules differ between networks. A single generic implementation will likely fail.

6. Test thoroughly

   Test AFT integration in sandbox environments. Verify AFT flags, sender data formatting, authorization responses, and settlement flows. Test domestic and cross-border scenarios separately.

7. Update card-present terminals

   If you operate physical terminals, ensure terminal software supports AFT processing. This may require firmware updates, configuration changes, or new hardware.

8. Deploy and monitor

   After go-live, monitor authorization approval rates, decline reasons, and settlement reports. Watch for patterns that may indicate classification issues or missing sender data.

How Inyo Simplifies AFT Processing

Inyo Global’s payment platform was built from the ground up for money movement transactions. Unlike general-purpose payment gateways that bolt on AFT support as an afterthought, Inyo’s infrastructure is AFT-native — Account Funding Transactions are a core transaction type, not an edge case.

As a licensed payment processor with 50-state money transmitter licensing, FinCEN MSB registration, PCI Level 1 certification, and SOC2 Type II compliance, Inyo understands the regulatory landscape that money transmitters and fintech platforms operate in. AFT compliance is not just a technical checkbox — it intersects with AML/KYC requirements, state licensing obligations, and network rules that must all work together.

Frequently Asked Questions About Account Funding Transactions