An account funding transaction (AFT) is a card payment that loads money into an account. With no goods or services changing hands, the cardholder is simply moving their own money from a card onto a wallet balance, a prepaid card, a trading account, or into a transfer they intend to send to someone else.
That distinction used to be a technicality. It is now a card scheme requirement. Visa has required forex and crypto deposits to be processed as AFTs since January 2025, and Mastercard’s equivalent rules took effect in August 2025. Merchants in the affected categories who still process deposits as ordinary purchases are non-compliant, and the consequences show up as declines before they show up as fines.
AFT, purchase, and OCT: three different things
Card payments that look similar at checkout behave differently in the scheme rules, and the three transaction types here are easy to confuse.
A purchase exchanges money for goods or services. The cardholder pays a merchant and receives something in return.
An account funding transaction pulls money from a card to fund an account. Nothing is bought. The money lands in a balance the cardholder or a recipient controls, and the card networks classify it as funding instead of spending.
An original credit transaction (OCT) pushes money in the other direction, from a merchant out to a card. This is the payout leg: winnings, withdrawals, refunds of balance, disbursements.
AFTs and OCTs frequently pair in the same business, since a deposit-and-payout platform pulls funds in with an AFT and pays them out with an OCT. Visa is explicit that the two are independent transactions even when an AFT precedes a corresponding OCT, so they are authorised, priced, and settled separately.
For the related distinction between who initiates a transaction, Gr4vy’s guide to merchant-initiated and customer-initiated transactions covers a different axis of the same classification problem.
Which merchants have to use AFTs
The requirement follows merchant category code. Acquirers generally require AFT origination for merchants operating under codes covering money transfer, stored value and prepaid top-up, quasi-cash and cryptocurrency, gambling, and securities or trading accounts. Two of the most commonly cited are MCC 4829 for money transfer and MCC 6540 for stored value account funding, where all authorisation requests must be processed as AFTs.
In practice this captures a recognisable set of businesses: forex and CFD brokers taking client deposits, crypto exchanges funding customer balances, online gambling operators accepting stake deposits, remittance and money transfer services, prepaid card issuers handling reloads, and digital wallet providers whose customers top up by card.
There are exceptions worth knowing. Single merchant wallets, where the balance can only be spent with that one merchant, are topped up as purchase transactions instead of AFTs. Certain staged digital wallet transfers carrying the relevant business application identifier are also treated as genuine purchases. The exact rules vary by network and jurisdiction, so the acquirer is the authority on any specific case.
What an AFT requires that a purchase does not
The processing difference is mostly about data. Visa and Mastercard require sender and recipient information on account funding transactions, which a standard purchase does not carry.
The transaction must be flagged with the appropriate identifier, the Business Application Identifier for Visa or the Transaction Type Identifier for Mastercard, so the networks can apply AFT rules rather than purchase rules. Alongside that flag, the request carries details of the party sending the funds and the account being funded. For money transfer use cases this extends to recipient name and account details, which exists to support anti-money-laundering obligations instead of payment mechanics.
Two downstream consequences follow. AFTs are priced from a separate interchange schedule, so the cost of an AFT differs from the cost of an equivalent purchase. And issuers commonly apply different risk treatment to AFTs, including their own velocity limits and spending caps, which means approval behaviour is not the same as it would be for a purchase of identical value.
How an AFT is processed
The flow resembles a normal authorisation with additional payload and different rules applied along the way.
The cardholder enters card details to fund a deposit, top-up, or transfer, and provides any sender information the merchant is required to collect. The merchant’s payment system sends an authorisation request to its acquirer, flagged as an AFT and carrying the sender and recipient data. The acquirer routes it through Visa or Mastercard, which recognises the AFT indicator and applies AFT processing rules, interchange, and risk parameters instead of the purchase equivalents.
The issuer then evaluates the request under its own AFT risk thresholds, which may differ materially from how it would treat a purchase. If approved, settlement proceeds on standard timelines but prices from the AFT interchange schedule. Once settled, the merchant credits the funded account, and if a payout follows it is originated separately as an OCT.
What happens if you classify deposits wrongly
This is the part that turns a technical detail into an operational problem. Processing a deposit as a purchase in a category where AFT is mandated is a compliance failure, and it surfaces in several ways.
Issuers increasingly decline transactions that appear to be funding but arrive classified as purchases, particularly in higher-risk categories, so the first symptom is usually an unexplained rise in declines. Beyond that sit scheme fines and, in sustained cases, restrictions on processing. Merchants in affected verticals also risk acquirer intervention, since the acquirer carries responsibility for AFT origination being enabled correctly.
The reverse error matters too. Flagging ordinary purchases as AFTs applies the wrong interchange and the wrong risk treatment, which costs money and can distort approval rates. Correct classification, in both directions, is the requirement.
Setting up AFT processing
Three things need to be true before a merchant in an affected category can process deposits compliantly.
The acquirer has to have AFT origination enabled for the merchant, under the correct MCC. This is the gating step and is handled with the acquirer instead of in the merchant’s own systems.
The payment provider or payment stack has to support sending the AFT flag and the required sender and recipient fields. A provider that cannot populate the identifier and the compliance data cannot process compliant AFTs, regardless of what the acquirer has enabled. Gr4vy supports account funding transactions, including the data fields the schemes require.
The merchant’s own checkout and back office have to collect and retain the required information, which for money transfer cases includes recipient details that a normal checkout would never ask for.
Merchants operating across several acquirers or markets face this setup repeatedly, because AFT enablement and the exact rules vary by acquirer and jurisdiction. Keeping transaction classification consistent across providers is one of the practical arguments for managing acceptance through a single coordinating layer, which is what payment orchestration provides.
Frequently asked questions
What is an account funding transaction?
An account funding transaction (AFT) is a card transaction that pulls money from a cardholder’s card to fund an account instead of buying goods or services. The funded account might be the cardholder’s own wallet, prepaid card, or trading balance, or an account belonging to someone else in the case of money transfer. Card networks classify it as funding instead of spending, which carries different rules, data requirements, and interchange.
What is the difference between an AFT and a purchase?
A purchase exchanges money for goods or services; an AFT moves money into an account with nothing bought. The practical differences are that AFTs must be flagged with a specific identifier, must carry sender and recipient data that purchases do not, are priced from a separate interchange schedule, and are assessed by issuers under different risk rules.
What is the difference between an AFT and an OCT?
An AFT is a pull transaction that takes money from a cardholder’s card into an account. An original credit transaction (OCT) is a push transaction that sends money from a merchant out to a card, used for payouts and withdrawals. Deposit-and-payout businesses use both, and Visa treats them as independent transactions even when an AFT precedes a related OCT.
Which merchants must process AFTs?
Requirements follow merchant category code, and typically capture money transfer services, stored value and prepaid top-up, quasi-cash and crypto, gambling, and securities or trading accounts. MCC 4829 and MCC 6540 are commonly cited as codes where all authorisation requests must be processed as AFTs. Acquirers confirm the requirement for a specific merchant.
When did AFT become mandatory?
Visa required forex and crypto deposit transactions to be processed as AFTs from January 2025, and Mastercard’s corresponding rules took effect in August 2025. Merchants in these categories processing deposits as ordinary purchases after those dates are not compliant with scheme rules.
What data does an AFT require?
Beyond a normal authorisation, an AFT carries a flag identifying it as account funding, the Business Application Identifier for Visa or Transaction Type Identifier for Mastercard, and sender and recipient information covering the party funding the transaction and the account being funded. Money transfer use cases require fuller recipient detail, reflecting anti-money-laundering obligations.
Does an AFT cost more than a purchase?
It is priced differently. AFTs draw on a separate interchange schedule from purchases, so the cost of an AFT is not the same as the cost of an equivalent purchase, and whether it is higher depends on the category, region, and card type. Merchants should confirm AFT pricing with their acquirer rather than assuming purchase rates carry over.
Are AFTs declined more often?
They can be. Issuers frequently apply different risk treatment to account funding transactions, including separate velocity limits and caps, so approval behaviour differs from purchases of the same value. A sudden rise in declines is also a common first symptom of deposits being misclassified as purchases in a category where AFT is mandated.
Getting classification right
Account funding transactions are a good example of a payment detail that looks like paperwork until it starts costing money. The classification carries real consequences: different data, different interchange, different issuer risk treatment, and, in mandated categories, a compliance obligation with deadlines that have already passed.
For merchants in forex, crypto, gambling, remittance, prepaid, or wallet businesses, the practical questions are whether the acquirer has AFT origination enabled under the right MCC, whether the payment stack can send the required identifiers and compliance data, and whether the checkout collects what the schemes ask for. Getting any of the three wrong produces the same symptom, which is transactions failing for reasons that look unrelated to the actual cause.
Gr4vy supports account funding transactions alongside more than 400 payment providers and methods through a single integration, so classification stays consistent as acquirers and markets are added. To talk through AFT setup for your category, get in touch with our team.
