Visa AFT Mandate 2026: What Money Transmitters Need to Know

The card networks are redefining how money movement transactions are classified, authorized, and settled. If your business processes money transfers, wallet loads, prepaid card funding, or mobile top-ups through card payments, the Visa AFT mandate affects you directly — and the compliance deadlines are already here.

For years, many money transmitters and fintech platforms processed what were effectively fund transfers using standard purchase transaction codes. That era is ending. Visa now requires these transactions to be properly identified as Account Funding Transactions (AFTs), carrying specific data fields and processing indicators that distinguish them from ordinary card purchases. Mastercard is following suit with its own mandate timeline extending through 2026 and 2027.

This article breaks down everything you need to know: what the mandate requires, who it affects, what changes in your transaction processing, and how to achieve compliance before enforcement actions begin.

What Is the Visa AFT Mandate?

An Account Funding Transaction is a card transaction where the purpose is to load funds into an account — rather than to purchase goods or services. Think of a customer using their Visa debit card to fund a money transfer, load a digital wallet, top up a prepaid card, or send an international remittance. The cardholder is not buying something; they are moving money from their bank account (via their card) into another account or to another person.

Visa’s AFT mandate requires that these transactions be correctly classified using the AFT transaction indicator in the authorization message, rather than being submitted as standard purchase transactions. This classification carries specific requirements for sender data, interchange treatment, and processing flows.

This is not optional. Non-compliance can result in fines from the card networks, increased interchange rates applied retroactively, mandatory remediation plans, or — in severe cases — loss of processing privileges. For money transmitters already operating under tight regulatory scrutiny, adding a card network compliance violation is a risk no business can afford.

Which Businesses Are Affected?

The Visa AFT mandate applies broadly to any business that accepts card payments for the purpose of funding an account rather than selling goods or services. In practice, this includes a wide range of money movement businesses:

• Money transfer operators (MTOs) — Businesses that accept card payments to fund domestic or international money transfers.
• Digital wallet providers — Platforms where users load funds via debit or credit card into a stored-value wallet.
• Prepaid card programs — Issuers and program managers that allow cardholders to fund prepaid cards using another card.
• Mobile top-up and airtime providers — Services that accept card payments to add credit to mobile phone accounts.
• Bill payment services — Platforms where users pay bills using a card, and the funds are routed to a payee account.
• Lending platforms — Services that accept card payments to fund loan disbursements or repayments.
• Cryptocurrency and stablecoin on-ramps — Platforms where users purchase digital assets using a card (depending on classification).

MCCs Under Scrutiny

The mandate is particularly relevant for businesses operating under certain Merchant Category Codes (MCCs):

MCC	Description	Common Use
4829	Money Transfer / Wire Transfer	MTOs, remittance providers, wire services
6540	Stored Value / Prepaid Load	Prepaid card programs, wallet loads
6012	Financial Institutions / Digital Wallets	Digital wallet providers, neobanks
6051	Non-Financial Institutions / Foreign Currency	Currency exchange, crypto on-ramps

If your business operates under any of these MCCs — or if you process transactions that functionally move money from a cardholder’s account into another account — the AFT mandate applies to you.

What Changes in Practice

The AFT mandate introduces several concrete changes to how transactions are processed. Understanding these changes is essential for both technical integration and operational compliance.

1. AFT Indicator Flag

Every qualifying transaction must now carry the AFT indicator in the authorization request message. This flag tells the issuing bank, the card network, and all intermediaries that this transaction is an account funding transaction — not a standard purchase. Without this flag, the transaction may be misclassified, potentially triggering compliance issues on both the acquiring and issuing sides.

2. Mandatory Sender Data

AFTs require specific information about the sender (the cardholder initiating the fund transfer). This goes beyond what a standard purchase transaction requires. The sender data fields include name, address, account number, and reference number — with additional fields required for cross-border transactions. We cover the full requirements in the next section.

3. Different Interchange Rates

AFTs are subject to their own interchange rate schedules, which differ from standard purchase interchange. In many cases — particularly for debit transactions — AFT interchange rates are lower than purchase rates. However, the rates vary by card type, transaction type (domestic vs. cross-border), and region. Misclassification in either direction can result in penalties.

4. Authorization and Settlement Differences

AFTs follow different authorization and settlement flows compared to standard purchases. The authorization response may include different response codes, and settlement timelines can differ. Refunds and reversals also follow AFT-specific rules — an AFT refund is typically processed as an Original Credit Transaction (OCT), not a standard purchase refund.

5. Card-Present Considerations

For businesses operating physical terminals — such as money transfer agent locations — the terminal must be configured to send the AFT indicator and collect the required sender data. This is not just an e-commerce concern; card-present AFT compliance requires terminal software updates and potentially new hardware.

AFT Sender Data Requirements

One of the most operationally significant aspects of the AFT mandate is the requirement to collect and transmit sender data with every AFT authorization request. This data serves both regulatory (anti-money laundering) and network compliance purposes.

Visa AFT Sender Data Fields

Visa requires the following sender information for AFTs:

• Sender Name — Full legal name of the cardholder initiating the transaction.
• Sender Address — Street address, city, state or 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.

For cross-border AFTs, additional fields may be required depending on the destination country and corridor. These can include sender date of birth, sender identification type and number, and the purpose of the transfer.

Visa vs. Mastercard: Sender Data Comparison

Both Visa and Mastercard require sender data for AFTs, but the specific fields and formats differ. The following table provides a side-by-side 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)

Impact on Interchange & Processing Costs

The shift to AFT classification has direct economic implications for businesses processing these transactions. Understanding the interchange impact is critical for financial planning and pricing.

AFT vs. Purchase Interchange

Visa and Mastercard publish separate interchange rate schedules for AFTs. The rates differ from standard purchase interchange in several important ways:

• 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.
• 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, which is typically higher than domestic AFT rates but may differ from cross-border purchase rates.

The Cost of Misclassification

Misclassifying transactions cuts both ways — and both directions carry risk:

• Submitting AFTs as purchases: You may pay higher interchange than necessary, and you risk compliance violations and fines from the card networks for failing to properly classify fund transfer transactions.
• Submitting purchases as AFTs: You risk compliance violations in the opposite direction, potential penalties, and issuer-side declines (issuers may flag or decline transactions that appear to be miscategorized).

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

Mastercard AFT Mandate Timeline

While much of the industry focus has been on Visa’s AFT mandate, Mastercard is implementing its own parallel requirements. Businesses that process on both networks — which is most businesses — must prepare for compliance with both mandates simultaneously.

Mastercard’s Rollout Schedule

• 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’s AFT framework shares the same fundamental concept as Visa’s: transactions that fund an account must be classified differently from purchases. However, the specific message formats, data field requirements, and processing rules differ between the two networks.

How to Prepare: A Compliance Checklist

Achieving AFT compliance requires coordination across your product, engineering, operations, and compliance teams. The following checklist provides a structured approach to preparing for the mandate.

1. Audit your current MCCs

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

2. Identify which transactions qualify as AFTs

   Not every transaction under these MCCs is necessarily an AFT. Map your transaction types to determine which ones involve funding an account (AFT) versus purchasing a good or service (standard purchase). Document this mapping clearly.

3. Update your payment gateway integration

   Work with your payment processor to ensure your API integration sends the AFT indicator flag on qualifying transactions. This typically involves updating authorization request messages to include the correct transaction type identifier.

4. Collect required sender data

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

5. Test in sandbox environments

   Before going live, thoroughly test your AFT integration in your processor’s sandbox or test environment. Verify that AFT flags are being sent correctly, sender data is properly formatted, and authorization responses are handled appropriately.

6. Validate with your processor

   Work with your payment processor to confirm that AFT transactions are being received and settled correctly on their end. Request a compliance review of your integration before full deployment.

7. Update card-present terminals

   If you operate physical terminals at agent locations, ensure terminal software is updated to support AFT processing. This may require firmware updates, configuration changes, or new terminal hardware.

8. Monitor for compliance

   After deployment, establish ongoing monitoring to ensure AFT classification is being applied consistently. Watch for authorization declines that may indicate classification issues, and review network compliance reports regularly.

Common Mistakes to Avoid

Based on the industry’s experience with AFT compliance, several common pitfalls consistently trip up businesses. Avoiding these mistakes can save significant time, money, and regulatory headaches.

1. Misclassifying Transaction Types

The most fundamental mistake is getting the classification wrong. Not every transaction a money transmitter processes is an AFT, and not every card transaction at a fintech is a purchase. Take the time to properly map each transaction type. A customer buying a physical product from your website is a purchase — even if your primary business is money transmission. A customer loading their wallet is an AFT — even if the user experience looks similar to a checkout flow.

2. Incomplete Sender Data

Submitting AFTs with missing or incomplete sender data fields is a common cause of authorization declines and compliance flags. Ensure your data collection flows capture all required fields — including address components that are easy to overlook, such as postal code and state/province. Validate data completeness before submitting the authorization request.

3. Ignoring Card-Present Channels

Many businesses focus their AFT compliance efforts on e-commerce and API channels while neglecting card-present terminals at agent locations. The mandate applies equally to card-present transactions. Terminals must be configured to send AFT indicators and collect sender data, which often requires coordination with terminal vendors and field operations teams.

4. Assuming Your Processor Handles Everything

While a good payment processor will support AFT processing and provide guidance, the responsibility for correctly classifying transactions and collecting sender data ultimately rests with the merchant or payment facilitator. Your processor can provide the technical infrastructure, but you must ensure your business logic correctly identifies which transactions are AFTs and that your systems collect and transmit the required data.

5. Not Testing Cross-Border Flows

Cross-border AFTs have additional sender data requirements that domestic AFTs do not. If your business processes international transfers, test cross-border AFT flows separately and verify that all corridor-specific fields are populated correctly. A domestic AFT integration that works perfectly may fail for cross-border transactions due to missing fields.

6. Treating Visa and Mastercard Identically

While the concept is the same, Visa and Mastercard have different field formats, validation rules, and timeline requirements. A single generic implementation that does not account for network-specific differences will likely encounter issues on one or both networks. Build network-aware logic into your integration from the start.

How Inyo Simplifies AFT Compliance

Inyo Global’s payment platform was designed from the ground up with money movement transactions in mind. Unlike general-purpose payment gateways that bolt on AFT support as an afterthought, Inyo’s infrastructure is AFT-native — meaning 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.

For businesses evaluating their payment gateway or orchestration strategy, choosing an AFT-native platform eliminates a significant compliance burden and reduces the risk of costly misclassification errors.